DHCP 프로토콜은 네트워크 상에서 동적으로 IP 주소 및 기타 구성정보 등을 부여/관리하는 프로토콜을 의미한다.
특정 네트워크를 관리하는 네트워크 관리자는 개별 호스트들에 수동으로 고정 IP를 할당할 수 있는데
IP 주소 부족 등의 사유로 DHCP를 사용해서 자동으로 할당할 수 있다.
이때 자동으로 할당 가능한 IP 주소는 모두 DHCP 서버가 관리하는 풀에 저장되어 있는데
클라이언트로부터 IP 주소 요청이 들어오면
풀에서 하나의 IP 주소를 할당하고
사용이 끝나면 IP를 다시 풀로 반환해 다른 호스트가 사용할 수 있도록 한다.
IP 주소를 원하는 클라이언트는 DHCP 서버에 요청하게 되고 서버는 이으 대해 응답 메시지를 회신한다.
메시지의 형식은 위와 같고 자세한 내용을 아래에서 살펴보자.
• Opcode: 요청 메시지는 1을 지정하고, 응답 메시지는 2를 지정
- 요청인지 혹은 요청에 대한 회신인지 구분하기 위해서 Opcode를 1 혹은 2로 지정
• HardwareType: 이더넷 등과 같은 하위 계층의 하드웨어 유형을 지정
- 하드웨어의 유형이 저장되는 곳으로 이더넷이면 1, 와이파이면 2, 블루투스면 3 등등 이렇게 유형에 따라서 저장된다.
• HardwareLength: 하드웨어 주소의 길이를 지정
- 맥주소의 길이가 저장됨(맥주소는 대부분 6바이트, 48비트이다.)
• HOPCount: 패킷이 전달되는 최대 홉의 수를 지정
-
IP 헤더에서 time to live라는 필드가 있었는데 time to live의 역할은 생존 시간을 설정해 데이터가 네트워크에 잔류하는 것을 막았다.
-
이 HOPCount는 거치는 홉의 수를 설정해 데이터의 생존 시간을 설정해 놓은 것이다.
• Transaction Identifier: 클라이언트의 요청이 있을 때 지정하는 임의의 숫자이며, 서버는 지정한
번호로 응답
-
DHCP 메시지는 브로드캐스팅 방식으로 전송되기 때문에 클라이언트와 서버 간의 논리적인 세션을 형성하는 목적으로 사용
-
Transaction Identifier를 통해서 클라이언트가 요청하면 임의의 숫자를 지정하고 서버는 이 요청에 대해 응답할 때 Transaction Identifier 필드에 요청과 같은 숫자를 지정해 동일한 Transaction Identifier 필드 값을 가지게 하여 어느 클라이언트로부터의 요청에 대한 응답임을 구분하는 용도로 사용된다.
• Time Elapsed: 클라이언트가 부팅된 이후의 경과 시간을 지정
• Flag: 현재 첫 번째 비트만 사용되며, 유니캐스트인지 멀티캐스트인지를 구분
-
정확히는 유니캐스트인지 브로드캐스트인지를 구분한다가 맞음.
-
처음에 IP 주소가 없는 클라이언트가 요청을 위해 보낼 때는 DHCP 서버가 어디에 있는지 모르기 때문에 브로드캐스트 방식으로 전체에게 보냄. 이때 Flag를 통해 브로드캐스트임을 확인함.
-
이후 IP를 할당 받은 클라이언트가 DHCP 서버와 소통할 때는 서로 알기 때문에 유니캐스트 방식을 통해 소통을 진행함. 이때 Flag를 통해 유니캐스트임을 확인함.
• Client IP Address: 클라이언트가 자신의 IP 주소를 지정한다. 주소를 모르면 0으로 표시
• Your IP Address: 서버가 응답 메시지로 권고해주는 클라이언트의 IP 주소
- 클라이언트가 IP를 요청하면 DHCP 서버가 이 클라이언트에게 권유할 수 있는 IP 주소를 보내주는데 이 IP 주소가 저장되는 필드.
• Server IP Address: 서버의 IP 주소를 지정하는데, 주소를 모르는 경우에는 0으로 표시
- DHCP 서버의 IP 주소가 저장되는 필드
• Gateway IP Address: 클라이언트의 하드웨어 주소를 지정하며, 크기는 Hardware Length 필드에 표시
• Server Name: 서버의 도메인 네임을 지정하며, 크기는 64바이트
- 서버의 도메인 이름이 저장되는 곳
• Boot File Name: 추가 정보를 보관하고 있는 파일 경로명을 지정하며, 크기는 128바이트
- 추가 정보가 있는 파일 경로명에 대한 정보가 기입
• Options: 필요한 추가 정보를 지정하며, 크기는 64바이트
우리가 기억해야 하는 것은 DHCP 프로토콜의 진행 방식이다.
간단히 정리하면 다음과 같다.
-
IP 주소가 없는 클라이언트가 브로드 캐스트를 통해 DHCP 서버를 찾음과 동시에 요청을 진행하는 요청을 보냄
-
DHCP 서버는 이 요청을 받으면 풀에 있는 IP를 클라이언트에게 브로드캐스트 방식으로 응답을 보냄
(이때 클라이언트는 브로드캐스트 방식으로 요청했기에 다른 DHCP 서버도 클라이언트에게 응답을 보냄) -
클라이언트는 IP 중 마음에 드는 하나를 사용할 수 있는지 서버에게 요청
(서버 또한 하나의 클라이언트에게만 해당 IP를 보낸게 아니라 이미 다른 클라이언트가 먼저 잡으면 해당 IP를 할당 받을 수 없음) -
서버는 해당 IP가 클라이언트에게 할당할 수 있으면 긍정 응답 프레임을 전달하며 확정
-
클라이언트가 TI 필드 값을 임의의 값 500으로 정하고 브로드 캐스트 방식으로 요청
(DHCP_DISCOVER) -
서버가 TI 필드를 500으로 정해 1번에 대한 응답임을 표시하고 YIP에 권유하는 IP 주소를 저장하고 SIP에 자신(서버)의 IP를 저장해서 응답를 보냄
(DHCP_OFFER) -
클라이언트는 서버의 응답들 중에서 마음에 드는 IP 주소를 하나 골라서 해당 서버 주소에 대해 요청을 보냄 TI는 그대로, CIP는 클라이언트가 원하는 자신의 주소를 저장, SIP는 내가 보내는 DHCP 서버의 주소를 저장
(DHCP_REQUEST) -
서버는 해당 요청에 대해 IP가 사용 가능한지 확인 후 클라이언트에게 긍정 응답을 보냄, TI는 그대로 YIP도 권유한 IP 그대로, SIP도 DHCP 서버 IP를 그대로 저장해서 보냄.
(DHCP_ACK)
DHCP 메시지는 UDP 데이터그램에 캡슐화되어 전송되고,
클라이언트는 68번 포트를 사용하고
서버는 67번 포트를 사용한다.
-
DHCP_DISCOVER: 클라이언트가 DHCP 서버를 찾기 위해 전송하는 브로드캐스트 메시지
-
DHCP_OFFER: 클라이언트의 DHCP_DISCOVER 메시지에 대한 응답으로 DHCP 서버가 응답하는 메시지
-
DHCP_REQUEST: 클라이언트는 여러 서버로부터 다수의 DHCP_OFFER를 받을 수 있기 때문에 이 중에서 적당한 IP 주소를 선택
-
DHCP_ACK: 클라이언트로부터 DHCP_REQUEST 메시지를 받은 DHCP 서버는 권고한 IP 주소가 최종적으로 사용 가능한지 판단
-
DHCP_NACK: DHCP 서버는 동일한 IP 주소를 여러 클라이언트에 권고
DHCP 메시지가 UDP와 IP 프로토콜로 캡슐화되어 전송되는 과정
우리가 브로드 캐스트 방식으로 보내면 I_DA는 255.255.255.255으로 보내게 됨
-
DHCP_DISCOVER
I_SA는 Source Address로 송신 호스트의 IP인 0.0.0.0이 보내짐
이유 = 현재 클라이언트는 IP 주소가 없는 상태에서 요청을 보내는 것이기 때문
또한 브로드 캐스트 방식으로 요청을 보내기 때문에 I_DA가 255.255.255.255이다. -
DHCP_OFFER
서버 자신의 IP 주소가 I_SA에 저장되고
서버도 브로드 캐스트 방식으로 응답을 보내기 때문에 I_DA는 마찬가지로 255.255.255.255이다. -
DHCP_REQUEST
클라이언트가 하나의 IP를 고르고 서버에게 요청할 때 해당 IP 주소를 자신의 주소로 I_SA에 저장
이후 같은 브로드 캐스트 방식으로 보내기에 I_DA가 같음 -
DHCP_ACK
서버가 해당 IP를 클라이언트에게 할당할 수 있으면 I_SA에 자신(서버)의 IP 주소를 저장하고 I_DA는 브로드 캐스트 방식으로 보냄.
클라이언트는 포트를 68
서버는 포트를 67을 이용해
U_SP가 68
U_DP가 67이다.
