호스트의 IP주소와 각종 TCP/IP 프로토콜의 기본 설정을 클라이언트에게 자동적으로 할당해주는 프로토콜을 말합니다. 일반적으로 새 장치를 네트워크에 연결하거나 기존 장치의 IP 주소를 변경할 때 사용됩니다.
DHCP Server
클라이언트로부터 IP 할당 요청이 들어오면 IP를 부여하고, 할당 가능한 IP들을 관리합니다.
ISP에서는 중앙집중형 관리 정책을 사용하고 가입자에 대해 인증기능, IP할당을 처리하는 큰 규모의 DHCP 서버를 운영합니다.
공유기에도 DHCP 서버가 탑재되어 있으므로 각각의 PC에 사설 IP를 할당하기도 합니다.
DHCP Client
DHCP 서버에 자신의 시스템을 위한 IP 주소를 요청하고, DHCP 서버로부터 IP 주소를 부여받으면 TCP/IP 설정이 초기화되고 다른 호스트와 TCP/IP를 사용해 통신할 수 있게 됩니다.
클라이언트에 해당하는 장비는 PC, 스마트폰, 등 최종 단말 장치로 모두 DHCP 클라이언트가 탑재되어 있습니다.
DHCP Relay
DHCP 요청을 다른 네트워크 대역에 있는 DHCP Server로 중계(relay)하며 DHCP 클라이언트와 서버 간의 요청을 관리합니다. 일반적으로 릴레이는 조직이 대규모 또는 복잡한 네트워크를 처리해야 할 때 사용됩니다.
DHCP Discover 브로드캐스트 요청을 받기위해서는 DHCP 서버가 각 서브넷마다 위치해야합니다. 하지만 실제 통신 사업자망 혹은 기업망 환경에서는 서브넷이 굉장히 많기에 서브넷마다 DHCP 서버를 구성하는 것은 실용적이지 못합니다.
DHCP 장점
DHCP 단점
사용자가 ip주소를 할당받기위해서는 DHCP 서버에 요청을 보내야한다. 하지만 클라이언트는 DHCP 서버의 ip정보도 모르기에 이를 파악하기위한 요청이 필요하다.
1. DHCP Discovery
출발지 ip에 0.0.0.0을 할당하고 목적지 ip에 255.255.255.255를 할당하여 네트워크 상의 모든 장치에게 요청을 전송하기위한 준비를 한다.
그리고 출발지 MAC주소에 자신의 MAC주소를 할당하고 목적이 MAC주소에 FF:FF:FF:FF:FF:FF값으로 할당하여 요청이 브로드캐스트임을 알수 있도록 한다. (DHCP 서버의 MAC주소도 모르기에 해당 방법 사용)
그리고 이를 브로드캐스트 요청을 보냅니다. 이 과정을 DHCP Discovery라고 한다.
2. DHCP Offer
브로드캐스트로 보내진 요청은 DHCP 서버를 제외한 곳에서는 버려지고 DHCP 서버는 요청을 받는다.
요청을 받은 DHCP 서버는 클라이언트에 할당할 ip를 생성하고 보낼 요청을 생성한다.
그리고 출발지 Mac주소와 ip주소는 DHCP서버의 정보를 넣고, 목적지 Mac주소에는 클라이언트의 Mac주소, ip는 방금 생성한 ip를 포함하여 네트워크 정보가 담긴 메세지를 생성한다.
그리고 이를 브로드캐스트 or 유니캐스트 요청을 보낸다. 이러한 과정을 DHCP Offer이라 부른다.
3. DHCP Request
클라이언트는 DHCP Offer과정으로 전달받은 메세지를 받는다.
그리고 이를 사용하겠다는 요청을 다시 DHCP 서버로 보낸다. 이 과정을 DHCP Request라 부른다. (해당 방식은 3 -Way Handshake 처럼 신뢰성을 확보하는 과정이라 생각했다....아닐수도..ㅎ)
4. DHCP ACK
최종적으로 DHCP 서버는 요청을 처리했다는 메세지를 클라이언트에 브로드캐스트 or 유니캐스트요청을 보낸다.
ip를 다른 서버에서 사용할 수 없도록 해당 ip를 사용 중이라 기록하고 한다. 이 과정을 DHCP ACK라고 한다. (ip 주소는 기본적으로 임대한 것이다. 때문에 일정 기간 사용하지 않으면 다시 반납되어 새로운 IP를 할당받아야 한다.)
DHCP Offer / DHCP ACK
https://stackoverflow.com/questions/52412385/is-dhcp-request-message-a-broadcast-or-unicast
DHCP가 할당해주는것
IP address, subnet mask, 첫 번째 홉 라우터의 IP 주소 (default gateway), DNS 서버의 이름 및 IP 주소
Discover / Request: 클라이언트 -> 서버
Offer / Acknowledge: 서버 -> 클라이언트
Discover Broadcast
현재 DHCP 서버가 어느 IP 주소에 있는지 모르기 때문에 메시지를 브로드캐스트로 보내야합니다.
Request : 마찬가지로 Request 단계에서 클라이언트는 아직 네트워크 정보를 확정하지 않았으므로 요청 패킷을 다시 브로드캐스트해야 합니다.
Request Broadcast
작업 부하의 균형을 위해 여러 DHCP 서버가 3대 존재하고 DHCP 서버가 공유 IP 주소 풀을 사용한다고 가정해보겠습니다.
호스트는 현재 자신과 가까운 DHCP서버의 존재를 모르고 모든 DHCP 서버에 대한 중간 경로의 정체를 인식하지 못합니다. 응답 시간을 줄이기 위해 DHCP_REQ 요청 메시지가 네트워크에 브로드캐스트된다. (DHCP 1,2,3은 FCFS 방식으로 작동한다.)
또한 해당 단계에서 클라이언트는 아직 네트워크 정보를 확정하지 않았다.. 때문에 요청 패킷을 다시 브로드캐스트해야 한다.
Offer / Acknowledge
DHCP OFFER의 flags옵션을 확인해보면 DISCOVER에 설정된 플래그값에 따라 브로드캐스트, 유니캐스트 요청방식이 결정되는 것을 확인할 수 있다. 단말이 보낸 DHCP Discover 메시지 내의 Broadcast Flag의 값에 따라 Flag=1이면 Broadcast로, Flag=0이면 Unicast로 보낸다.
임대기간이 끝나면 IP 주소를 반환하는데, 네트워크를 계속 사용해야한다면 또 요청하고, 할당받기까지 불필요한 브로드캐스팅 패킷이 발생하므로 네트워크에 부담이 될 수 있습니다.
그렇기 때문에 임대 기간이 50% 지났을때와 87.5%의 시간이 지났을때, IP를 사용하고 있다면 서버에 갱신을 요청하고 갱신이 성공하면 연장됩니다.
이 갱신은 Requset, Ack 두 개의 과정을 거칩니다. 갱신은 Unicast로 주고받게 됩니다.
임대기간이 끝났거나, IP주소를 더 사용하지 않는다면 IP 주소를 DHCP 주소풀에 반환하게 됩니다.
명령 프롬프트에서 ipconfig /release 명령으로 반환, ipconfig /renew 명령으로 임대 생성과 갱신을 할 수 있습니다.
IP 할당(임대) - Relay