DHCP(Dynamic Host Configuration Protocol): 호스트가 부팅되면 처음으로 수행하는 첫 번째 클라이언트/서버 응용 프로그램
TCP/IP에 접속되는 각 컴퓨터는 자신의 IP 주소를 알 필요가 있다.
다른 망과 통신하기 위해 디폴트 라우터의 주소를 알아야 하고, 주소 대신 이름을 사용하여 통신하기 위해서는 네임 서버의 주소도 알아야 한다.
1. 컴퓨터의 IP 주소
2. 컴퓨터의 해당 서브 넷 마스크
3. 라우터의 IP 주소
4. 네임서버의 IP 주소
DHCP가 호스트 설정을 위한 공식 프로토콜이 되기 전 다른 프로토콜
RARP
RARP(Reverse Address Resolution Protocol): 물리 주소를 IP 주소로 매핑
↔︎ ARP: IP 주소를 물리 주소로 매핑
요즘 RARP가 거의 사용되지 않음
이유 1) 데이터링크 계층의 브로드캐스드 서비스를 사용하는데, 이는 ARP 서버가 각 망에 존재해야 함을 의미함
이유 2) RARP는 오로지 IP 주소만을 제공함
BOOTP
BOOTP(Bootstrap Protocol): RARP 프로토콜의 두 가지 약점을 극복하기 위해 만들어진 클라이언트/서버 프로토콜
1) BOOTP 서버가 인터넷상의 어디에나 있을 수 있다. (∵ 클라이언트/서버 프로그램이므로)
2) IP 주소를 포함해 위의 4가지 항목 정보를 모두 제공 가능하다.
하지만, BOOTP는 정적인 설정 프로토콜이다.
클라이언트가 IP 주소를 요청하면 BOOTP 서버는 클라이언트의 물리 주소와 매핑되는 IP 주소를 테이블에서 찾는다.
이는 클라이언트의 물리 주소와 IP 주소 간의 바인딩이 이미 존재한다는 것, 바인딩이 미리 정해진다는 것이다.
동적인 설정 프로토콜이 필요한 몇 가지 상황
예를 들어, 호스트가 하나의 물리 망에서 다른 망으로 이동한 경우 물리 주소가 변경됨
- 호스트가 짧은 기간동안 임시 IP 주소를 사용하고 싶은 경우 → 물리 주소와 IP 주소 간의 바인딩이 정적이므로 테이블에 고정된 값을 가짐
- 관리자 수정 전까지는 반영 불가
DHCP
처음으로 부팅한 컴퓨터나 디스크가 없는 컴퓨터에게 4가지 정보를 제공하기 위해 설계된 클라이언트/서버 프로토콜
BOOTP와 역방향 호환성을 가진다. (호스트 설정을 위해 BOOTP 프로토콜을 사용하는 시스템이 아직 남아 있을 수 있음)
DHCP 동작 절차
DHCP 클라이언트와 서버는 동일한 망에 있을 수도 있고 서로 다른 망에 있을 수도 있다.
동일 망
보편적이지 않음
DHCP Request: 0s - 1s - 68 - 67 (CIP - SIP - CP - SP)
DHCP Reply: SIP - 1s - 67 - 68 (SIP - CIP - SP - CP)
(CP/SP: Client/Server Port Number, CIP/SIP: Client/Server IP Address)
1. DHCP 서버는 UDP 포트 번호 67에 수동 열기(passive open) 명령을 수행하고 클라이언트로부터 요청을 기다린다.
2. 부팅된 클라이언트는 포트 번호 68에 능동 열기 명령을 수행한다. 이 메시지는 목적지 포트 번호 67, 발신지 포트 번호 68을 가지는 UDP 사용자 데이터그램으로 캡슐화된다.
그 후 이 UDP 사용자 데이터그램은 IP 데이터그램으로 캡슐화된다.
Q. 이때 자신의 IP 주소(발신지 주소)도 모르고 서버의 IP 주소(목적지 주소)도 모르면서 어떤 식으로 클라이언트가 IP 데이터그램을 보내는가?
A. 클라이언트는 발신지 주소를 모두 0으로 지정하고 목적지 주소를 모두 1로 지정한다.
3. 서버는 UDP 목적지 포트 번호를 68, 발신지 포트 번호를 67로 지정한 뒤 유니캐스트 메시지나 브로드캐스트 메시지를 클라이언트에 보낸다.
Q. 응답이 유니캐스트 형태가 될 수 있는 이유
A. 서버가 클라이언트의 IP 주소를 알기 때문
+ 서버는 클라이언트의 물리적 주소를 알고 있음 → ARP 서비스가 필요하지 않음을 의미(논리적 주소를 물리적 주소로 매핑)
but, 몇몇 시스템은 ARP 과정을 건너뛰는 것을 허용하지 않을 수 있음 → 브로드캐스트 주소 사용
서로 다른 망
다른 응용 계층 프로세스에서와 같이 서로 다른 망으로 구분된 경우
한 가지 문제점이 존재: DHCP 요청은 클라이언트가 서버의 IP 주소를 모르기 때문에 브로드캐스트 되는데, 이렇게 브로드캐스트 된 IP 데이터그램은 어떠한 라우터도 통과하지 못함, 그러한 패킷을 수신한 라우터는 패킷을 버림
→ 중계자의 역할을 하는 것이 필요하다.
호스트 중의 하나 혹은 응용 계층에서 동작하도록 설정될 수 있는 라우터가 중계자로 사용될 수 있다.
이 호스트를 중계 에이전트(relay agent)라고 부름
중계 에이전트: DHCP 서버의 유니캐스트 주소를 알고 있음, 포트 번호 67로 들어오는 브로드캐스트 메시지를 기다림
패킷을 수신하면 이 메시지를 유니캐스트 메시지에 캡슐화하여 DHCP 서버로 보냄
유니캐스트 목적지 주소를 가지는 패킷은 라우터들에 의해 라우팅 됨, DHCP 서버에 도착함
DHCP 서버는 요구 메시지에 있는 필드 중 하나가 중계 에이전트의 IP 주소를 정의하고 있기 때문에 중계 에이전트로부터 온 메시지임을 알게 됨
→ 응답을 받은 중계 에이전트는 DHCP 클라이언트로 이를 전송함
UDP 포트
서버 포트 67은 일반적, 클라이언트 포트 68은 일반적이지 않음
Q. 클라이언트가 임시 포트를 사용하지 않고 잘 알려진 포트번호 68을 사용하는 이유
A. 서버로부터 클라이언트로 응답이 브로드캐스트될 때의 문제점을 방지하기 위해
e.g., IP 주소와 포트 번호의 조합으로 나타내어지는 소켓 주소에 기반을 둔 패킷의 역 다중화(demultiplexing) 때문, 양 호스트의 소켓 주소가 같음
- 잘 알려진 포트의 사용(1024보다 작은 값을 가짐)은 동일한 두 개의 목적지 포트 번호의 사용을 방지함
Q. 호스트 A/B가 모두 DHCP 클라이언트로 동작하는 경우 어떤 일이 일어나는가?
A. 소켓 주소는 같게 되고 양 호스트는 모두 메시지를 수신함, 클라이언트 간의 구별은 또 다른 식별자를 통해 수행
DHCP와 관련된 각 연결에 transaction ID라는, 임의로 선택되어지는 다른 번호를 사용함(동시에 같은 ID를 선택할 확률은 매우 낮음)
에러 제어
DHCP를 사용할 때 에러 제어의 필요성 - 요청이 분실되거나 손상될 때, 응답이 손상될 때
DHCP는 UDP를 사용하는데 UDP는 에러 제어 기능을 제공하지 않음
→ DHCP는 에러 제어 기능을 제공해야 함
[에러 제어의 두 가지 정책]
1) DHCP는 UDP에서 검사합(checksum)을 사용하도록 요구한다. UDP에서 검사합 기능은 선택적이기 때문.
2) DHCP 클라이언트는 요청에 대한 DHCP 응답을 수신하지 못하면 타이머 정책과 재전송 정책을 사용함.
but, 전원이 나간 후와 같이 여러 호스트가 동시에 재전송 요청을 하여 트래픽 혼잡이 발생하는 경우를 막기 위해, DHCP는 랜덤 변수를 사용하여 타이머 값을 설정함
고정 주소 할당
DHCP 서버는 물리 주소와 IP 주소를 정적으로 바인딩 한 데이터베이스를 가짐
이 경우 BOOTP와 역 방향 호환성을 가짐
동적 주소 할당
DHCP는 이용 가능한 IP 주소들의 풀(pool)을 가지는 다른 데이터베이스를 가지고 있음
이 두 번째 데이터베이스가 DHCP를 동적으로 만듦
DHCP 클라이언트가 임시의 IP 주소를 요청하게 되면 DHCP 서버는 주소 풀에서 활용 가능하고 사용되지 않는 IP 주소를 가져다 협상되는 기간 동안 할당함
1) DHCP 클라이언트가 DHCP 서버에 요청을 전송
2) 서버는 자신의 정적 데이터베이스를 찾음
3) 데이터베이스에 요청된 물리 주소가 있으면, 이 영구적인 IP 주소가 클라이언트에 반환됨
but, 정적 데이터베이스에 항목이 없으면, 서버는 활용 가능한 IP 주소를 풀에서 할당하고 동적 데이터베이스에 항목을 추가함
Q. DHCP 동적인 측면이 필요한 이유
A. 호스트가 한 망에서 다른 망으로 이동하는 경우, 서비스 제공자의 가입자처럼 망에 연결되었다가 끊어지는 경우 등
풀에서 할당된 주소는 임시, DHCP 서버는 일정 기간 동안 임대(leasing)
임대 기간이 끝나면, 클라이언트는 이 주소 사용을 그만두거나 임대를 새로 요청
상태 천이
동적인 주소 할당을 제공하기 위해 DHCP 클라이언트는 다른 상태로의 천이를 수행하는 상태 기계(state machine)로서 동작함
DHCP 패킷의 유형을 정의하기 위해 값을 어떻게 해석해야 하는지
초기 상태
DHCP 클라이언트가 처음 시작되면 초기화 상태에 있게 됨
클라이언트는 DHCP DISCOVER 메시지를 67번 포트를 사용하여 브로드캐스트함
선택 상태
DHCP DISCOVER 메시지를 전송한 후 클라이언트는 선택 상태로 천이함
이러한 유형의 서비스를 제공할 수 있는 서버들은 DHCP OFFER 메시지로 응답함 (서버는 이 메시지 안에 IP 주소, 임대 기간(기본 1h)를 제공)
DHCP OFFER를 전송한 서버는 제공한 IP 주소를 다른 클라이언트가 사용하지 못하도록 잠가 놓음
클라이언트는 이러한 것들 중 하나를 선택하고 이 선택된 서버로 DHCP REQUEST 메시지를 전송함, 그리고 요청 상태로 들어감
+ 만약 클라이언트가 DHCP OFFER 메시지를 하나도 못받는다면, 2초 간격으로 4번 재시도함
+ DHCP DISCOVER 메시지의 재시도에도 응답이 없으면 5분간 기다린 후 재시도함
요청 상태
클라이언트는 클라이언트 물리 주소와 그 IP 주소간의 연결(binding) 정보 생성을 수행하는 서버로부터 DHCP ACK 메시지를 수신할 때까지 요청 상태에 있게 됨
DHCP ACK를 수신한 이후 클라이언트는 바운드 상태로 감
바운드(Bound) 상태
클라이언트는 임대가 만료될 때까지 IP 주소를 사용함
임대 기간의 50%가 지나면 클라이언트는 다른 DHCP REQUEST 메시지를 보내 임대 기간을 새롭게 설정함
그리고 재설정(renewing) 상태로 들어감
바운드 상태에서 클라이언트는 임대를 취소하곡 초기화 상태로 갈 수 있음
재설정(Renewing) 상태
클라이언트는 다음 두 가지 이벤트 중 하나가 발생할 때까지 이 상태에 머무름
1) DHCP ACK를 수신하여 임대 계약을 새로 설정하는 것 - 클라이언트는 타이머를 재설정하고 바운드 상태로 돌아감
2) DHCP ACK가 수신되지 않고 임대 기간의 87.5%가 지나는 경우, 클라이언트는 재연결(rebinding) 상태로 감
재연결(Rebinding) 상태
클라이언트는 다음 세 가지 이벤트 중 하나가 일어날 때까지 이 상태에 머무름
클라이언트가 1) DHCP NACK를 수신하거나 2) 임대 기간이 만료되면, 초기화 상태로 들어가고 다른 IP 주소 임대를 시도함
3) DHCP ACK를 수신하면 바운드 상태로 들어가고 타이머를 재설정함
다른 이슈들
이른 해제
지정된 기간 동안 주소를 할당 받은 DHCP 클라이언트는 만료 시간 전에 임대를 해제할 수 있다.
클라이언트가 서버에게 DHCP RELEASE 메시지를 전송하여, 서버가 해당 주소를 다른 기다리는 클라이언트에게 할당할 수 있도록 함
타이머
위의 논의 사항들은 클라이언트에게 3가지 타이머 사용을 요구한다.
타이머 별 기본 값 (서버가 타이머 만료 값을 주소 할당할 때 설정하지 않은 경우)
- 재설정 타이머: 임대 시간의 50%
- 재연결 타이머: 임대 시간의 87.5%
- 만료 타이머: 임대 시간의 100%
Reference
Behrouz A. Forouzan (2009), TCP/IP 프로토콜(Protoccol Suite), 4th Edition
