IP : 192.168.1.47
Subnet Mask : 255.255.255.0
Route : 192.168.1.1
DNS : 192.168.1.1

이때 새로운 네트워크에 연결할 때마다 새로운 IP 주소를 담당해서 배정해주는 프로토콜이 바로 DHCP이다.

다만 항상 DHCP의 동적 IP 할당이 필요한 것은 아니다. 학교 네트워크같은 경우는 DHCP가 아닌 고정된 IP 주소가 필요하다. 이처럼 고정된 IP 주소를 사용하는 경우는 DHCP가 필요 없다.

DHCP는 IP 주소를 일정 시간동안 대여해주고 이후 회수하는 방식으로 동작한다. 따라서 비교적 적은 수의 IP 주소를 갖고 돌려 쓸 수 있다. 이로 인해 고정 IP 방식에 비해 Address Pool을 더 유연하게 사용할 수 있다.

예를 들어 10,000명의 네트워크 사용자가 있으면, 고정 IP 방식에서는 10,000개의 IP 주소가 필요하지만 DHCP에서는 1,000개 정도의 IP만 갖고 그때그때 사용하는 사람에게 임대해주는 방식으로 동작이 가능하다.

DHCP client-server scenario

처음에 PC를 부팅하고 네트워크에 연결했을 때에는 IP 주소는 물론 DHCP 서버도 모른다. 다음과 같은 과정을 거쳐 IP 주소를 할당받는다.

1. DHCP discover

• src: 0.0.0.0, 68 : 아직 IP 주소를 할당받지 못했으며, DHCP 클라이언트로서 68번 포트에서 활동하고 있음을 의미.
• dest: 255.255.255.255, 67 : 목적지는 255.255.255.255 즉, 브로드캐스트.
  • 브로드캐스트란 동일 서브넷에 있는 모든 멤버들에게 이 메시지를 전송한다는 의미.
  • DHCP 프로토콜의 포트 번호는 67번을 사용. 따라서 DHCP와 관련 없는 다른 호스트들은 67번 포트를 닫아놓았기에 이 메시지를 무시하고, DHCP 서버만 67번 포트를 열어놔서 이 메시지를 수신.
• transaction ID: 654 : 클라이언트가 랜덤으로 선택한 ID.

2. DHCP offer

• 67번 포트를 열어놓은 DHCP 서버에서 discover 메시지를 받은 후 그 응답으로 offer를 전송.
• src: 223.1.2.5, 67 : 서버 자신의 IP 주소와 포트 번호.
• dest: 255.255.255.255, 68 : 브로드캐스트.
  • 서버는 아직 클라이언트가 누군지 모른다. 왜냐하면 그저 브로드캐스트로 어디에선가부터 날아들어온 메시지를 받았을 뿐이다.
  • 따라서 브로드캐스트로 offer를 전송하되, 포트를 68번으로 설정하여 DHCP 클라이언트만이 이 메시지를 수신할 수 있도록 설정한다.
• yiaddr: 223.1.2.4 / lifetime: 3600 secs : 223.1.2.4 라는 IP 주소를 3600초동안 사용할 수 있도록 대여해준다는 것을 의미.
• 이 정보 뿐만 아니라 라우터, DNS, 서브넷마스크의 IP 주소 역시 offer에 포함되어있음.
  • DHCP ACK가 온 순간부터 이들을 사용할 수 있음.
• 만약 DHCP가 여러 개 있다면 그 여러 개의 서버로부터 각각 offer가 온다. 이후 클라이언트는 이 offer 중에서 하나를 선택하여 request를 보내게 된다.

3. DHCP request

• offer를 받은 클라이언트가 이를 수락한다는 의미로 보내는 request 메시지.
• src: 0.0.0.0, 68 : 아직 IP 주소가 확정되지 않았기 때문에 IP 주소는 무명.
• dest: 255.255.255.255, 67 : 여러 개의 DHCP 서버에게 클라이언트가 선택한 DHCP 서버의 존재를 알리기 위해 브로드캐스트로 전송.
• yiaddr: 223.1.2.4 / lifetime: 3600 secs : offer와 동일.
  • 서버가 제안한 IP 주소와 lifetime을 클라이언트가 수락한다는 의미.
• transaction ID: 655 : DHCP discover에서 사용한 값과 동일 (RFC 2131 §4.4.1).

4. DHCP ACK

• DHCP request에서 요청한 내용을 확정(confirm)하는 응답이며, transaction ID는 request와 동일한 값을 사용한다 (RFC 2131 기준, +1 증가는 표준 동작이 아님).
• 서버가 DHCP request를 받고 ACK을 보낸 순간부터 클라이언트는 해당 IP 주소를 사용할 수 있음.

IP fragmentation and reassembly (IP 단편화)

데이터는 전송될 때 다수의 링크를 거쳐가는데, 각 링크마다 보낼 수 있는 데이터의 사이즈가 전부 다르다.

Note

MTU : Maximum Transmission Unit 각 링크가 한번에 보낼 수 있는 데이터의 사이즈

IPv4를 사용하는 링크는 MTU 보다 더 큰 사이즈의 데이터가 들어오면 이를 분리해서 MTU 사이즈에 맞는 독립적인 프레임으로 나누는데, 이를 IP fragmentation (IP 단편화)이라고 한다.

이렇게 쪼개진 데이터들은 목적지에 도착한 후 다시 하나로 합쳐지며, 이를 reassembly (재조립)라고 한다.

위 사진을 보면 처음 들어온 데이터는 4000 바이트지만, MTU는 1500바이트이다. 따라서 4000 바이트를 총 3개의 fragment로 쪼갠다. (1500, 1500, 1040) 각 fragment마다 IP 헤더 20바이트가 붙는다. 마지막 fragment는 헤더 20바이트 + 남은 페이로드(1020바이트)로 구성되어 총 1040바이트가 된다.

• ID : 원래는 하나의 데이터임을 표시하기 위해 동일하게 설정.
• fragflag : 쪼개진 데이터는 1로 설정. 쪼개진 데이터 중에서 가장 마지막 fragment는 0으로 설정.
  • 애초에 쪼개지지 않은 데이터 역시 0으로 설정.
• offset : 전체 데이터에서 쪼개진 데이터가 원래 있던 위치 중 첫 번째 값 / 8
  • 헤더의 데이터 저장 공간을 줄이기 위해 8로 나눈다.

만약 이렇게 쪼갠 fragment 중 하나라도 유실된다면 reassembly는 일어나지 않는다. 따라서 전체 데이터 역시 모두 폐기되고, 다시 처음부터 재전송해야 한다.