본문으로 이동

동적 호스트 구성 프로토콜

위키백과, 우리 모두의 백과사전.
동적 호스트 구성 프로토콜
클라이언트/서버 모델에 따른 동적 호스트 구성 프로토콜(DHCP)과 프로토콜 토폴로지 구성 요소 간의 트래픽 라우팅 유형.
상태활성
시작 연도1993년 10월(32년 전)(1993-10)
기초가 되는 표준RFC 1531

동적 호스트 구성 프로토콜(Dynamic Host Configuration Protocol, DHCP)은 클라이언트 서버 구조를 사용하여 네트워크에 연결된 장치에 IP 주소 및 기타 통신 매개변수를 자동으로 할당하기 위해 인터넷 프로토콜(IP) 네트워크에서 사용되는 네트워크 관리 프로토콜이다.[1]: Introduction 

이 기술은 네트워크 장치를 개별적으로 수동 구성할 필요성을 없애주며, 중앙에 설치된 네트워크 DHCP 서버와 각 컴퓨터 또는 장치의 프로토콜 스택에 있는 클라이언트 인스턴스라는 두 가지 네트워크 구성 요소로 이루어진다. 네트워크에 연결될 때와 그 이후 주기적으로, 클라이언트는 DHCP를 사용하여 서버에 매개변수 집합을 요청한다.

DHCP는 가정용 통신망부터 대규모 캠퍼스 통신망 및 지역 ISP 네트워크에 이르는 다양한 규모의 네트워크에서 구현될 수 있다.[2] 많은 라우터와 가정용 게이트웨이에는 DHCP 서버 기능이 있다. 대부분의 가정용 네트워크 라우터는 ISP 네트워크 내에서 고유한 IP 주소를 할당받는다. 로컬 네트워크 내에서 DHCP 서버는 각 장치에 로컬 IP 주소를 할당한다.

DHCP 서비스는 인터넷 프로토콜 버전 4(IPv4)와 버전 6(IPv6)을 실행하는 네트워크를 위해 존재한다. IPv6 버전의 DHCP 프로토콜은 보통 DHCPv6라고 불린다.

역사

[편집]

역순 주소 결정 프로토콜(RARP)은 디스크리스 워크스테이션과 같은 단순한 장치에 적절한 IP 주소를 구성하기 위해 1984년에 정의되었다.[3] 데이터 링크 계층에서 작동했기 때문에 많은 서버 플랫폼에서 구현이 어려웠다. 또한 각 개별 네트워크 링크마다 서버가 존재해야 했다. RARP는 1985년 9월에 정의된 부트스트랩 프로토콜(BOOTP)로 대체되었다.[4] 이는 릴레이 에이전트 개념을 도입하여 네트워크 간에 BOOTP 패킷을 전달할 수 있게 했으며, 하나의 중앙 BOOTP 서버가 많은 IP 서브넷의 호스트를 서비스할 수 있도록 했다.

DHCP는 1993년 10월에 처음 정의되었다.[5][6] 이는 BOOTP를 기반으로 하지만, 풀(pool)에서 IP 주소를 동적으로 할당하고 더 이상 사용되지 않을 때 회수할 수 있다. 또한 플랫폼별 매개변수를 포함하여 IP 클라이언트에 광범위한 추가 구성 매개변수를 전달하는 데 사용될 수 있다.[7]

4년 후, (WPAD를 위해 사용되는) DHCPINFORM 메시지 유형과 기타 소소한 변경 사항이 추가되었다. 1997년에 정의된 이 버전은[1] 여전히 IPv4 네트워크 표준의 핵심으로 남아 있다.

DHCPv6는 2003년에 처음 정의되었다.[8] 이후 많은 RFC를 통한 업데이트를 거쳐 2018년에 정의가 대체되었으며,[9] 여기에는 접두사 위임과 비상태 저장 주소 자동 구성이 통합되었다.

개요

[편집]

인터넷 프로토콜(IP)은 인터넷상의 로컬 네트워크 내부 및 네트워크 간에 장치가 통신하는 방식을 정의한다. DHCP 서버는 로컬 네트워크의 장치에 IP 주소를 자동적이고 동적으로 할당하는 등의 방식으로 해당 장치들의 IP 설정을 관리할 수 있다.[10]

DHCP는 클라이언트 서버 모델을 기반으로 동작한다. 컴퓨터나 다른 장치가 네트워크에 연결되면 DHCP 클라이언트 소프트웨어는 필요한 정보를 요청하는 DHCP 브로드캐스트 쿼리를 보낸다. 네트워크상의 모든 DHCP 서버가 이 요청을 처리할 수 있다. DHCP 서버는 IP 주소 풀과 기본 게이트웨이, 도메인 네임, 네임 서버, 시간 서버와 같은 클라이언트 구성 매개변수에 대한 정보를 관리한다. DHCP 요청을 받으면 DHCP 서버는 관리자가 이전에 구성한 대로 각 클라이언트에 특정한 정보를 제공하거나, 전체 네트워크에 유효한 특정 주소 및 할당(임대)이 유효한 기간 동안의 기타 정보를 제공하여 응답할 수 있다. DHCP 클라이언트는 일반적으로 부팅 직후에 이 정보를 쿼리하며, 이후 정보가 만료되기 전에 주기적으로 다시 쿼리한다. DHCP 클라이언트가 할당을 갱신할 때 처음에는 동일한 매개변수 값을 요청하지만, DHCP 서버는 관리자가 설정한 할당 정책에 따라 새 주소를 할당할 수도 있다.

여러 링크로 구성된 대규모 네트워크에서는 상호 연결된 라우터에 위치한 DHCP 릴레이 에이전트의 도움을 받아 단일 DHCP 서버가 전체 네트워크를 서비스할 수 있다. 이러한 에이전트는 서로 다른 서브넷에 위치한 DHCP 클라이언트와 DHCP 서버 간에 메시지를 전달한다.

구현 방식에 따라 DHCP 서버는 IP 주소를 할당하는 세 가지 방법을 가질 수 있다:

동적 할당
네트워크 관리자가 DHCP를 위해 IP 주소 범위를 예약하고, LAN상의 각 DHCP 클라이언트는 네트워크 초기화 중에 DHCP 서버로부터 IP 주소를 요청하도록 구성된다. 요청 및 승인 프로세스는 제어 가능한 기간의 임대(lease) 개념을 사용하므로, 갱신되지 않은 IP 주소를 DHCP 서버가 회수하여 다시 할당할 수 있다.
자동 할당
DHCP 서버가 관리자가 정의한 범위 내에서 요청하는 클라이언트에 IP 주소를 영구적으로 할당한다. 이는 동적 할당과 유사하지만, DHCP 서버가 과거의 IP 주소 할당 표를 유지하여 클라이언트가 이전에 가졌던 것과 동일한 IP 주소를 우선적으로 할당할 수 있게 한다.
수동 할당
이 방법은 정적 DHCP 할당, 고정 주소 할당, 예약, MAC/IP 주소 바인딩 등 다양하게 불린다. 관리자가 각 클라이언트의 고유 식별자(클라이언트 ID 또는 MAC 주소)를 IP 주소에 매핑하여 요청하는 클라이언트에 제공한다. DHCP 서버는 이 방법이 실패할 경우 다른 방법으로 대체되도록 구성될 수 있다.

DHCP 서비스는 IPv4 및 IPv6에 사용된다. IPv4와 IPv6를 위한 프로토콜의 세부 사항은 서로 충분히 다르기 때문에 별개의 프로토콜로 간주될 수 있다.[11] IPv6 작동을 위해 장치는 대신 비상태 저장 주소 자동 구성을 사용할 수 있다. IPv6 호스트는 로컬 네트워크 링크로 제한된 작업을 수행하기 위해 링크 로컬 주소 지정을 사용할 수도 있다.

동작

[편집]
일반적인 비갱신 DHCP 세션의 예시. 각 메시지는 DHCP 클라이언트의 기능에 따라 브로드캐스트 또는 유니캐스트일 수 있다.[1]

DHCP는 사용자 데이터그램 프로토콜(UDP)을 사용하는 비연결형 서비스 모델을 채택한다. 부트스트랩 프로토콜(BOOTP)과 동일한 두 개의 UDP 포트 번호를 사용하여 동작한다. 서버는 UDP 포트 번호 67번에서 리스닝하고, 클라이언트는 UDP 포트 번호 68번에서 리스닝한다.

DHCP 동작은 서버 발견(discovery), IP 임대 제안(offer), IP 임대 요청(request), IP 임대 확인(acknowledgement)의 네 단계로 나뉜다. 이 단계들은 흔히 발견, 제안, 요청, 확인의 앞글자를 따서 DORA라고 줄여 부른다.

DHCP 동작은 클라이언트가 요청을 브로드캐스팅하면서 시작된다. 클라이언트와 서버가 서로 다른 브로드캐스트 도메인에 있는 경우, DHCP 헬퍼 또는 DHCP 릴레이 에이전트가 사용될 수 있다. 기존 임대 갱신을 요청하는 클라이언트는 해당 시점에 이미 설정된 IP 주소를 가지고 있으므로 UDP 유니캐스트를 통해 직접 통신할 수 있다. 또한 클라이언트가 DHCPOFFER를 받을 방식(브로드캐스트 또는 유니캐스트)을 나타내기 위해 사용할 수 있는 BROADCAST 플래그(2바이트 플래그 필드 중 1비트, 나머지 비트는 예약되어 0으로 설정됨)가 있다. 브로드캐스트의 경우 0x8000, 유니캐스트의 경우 0x0000이다.[1] 보통 DHCPOFFER는 유니캐스트를 통해 전송된다. IP 주소가 구성되기 전에 유니캐스트 패킷을 수락할 수 없는 호스트의 경우, 이 플래그를 사용하여 이 문제를 해결할 수 있다.

발견 (Discovery)

[편집]

DHCP 클라이언트는 목적지 주소 255.255.255.255(제한된 브로드캐스트) 또는 특정 서브넷 브로드캐스트 주소(지정된 브로드캐스트)를 사용하여 네트워크 서브넷에 DHCPDISCOVER 메시지를 브로드캐스팅한다. DHCP 클라이언트는 DHCPDISCOVER에서 특정 IP 주소를 요청할 수도 있으며, 서버는 제안할 주소를 선택할 때 이를 고려할 수 있다.

예를 들어, HTYPE이 1로 설정되면 사용되는 매체가 이이넷임을 지정하며, 이더넷 주소(MAC 주소)의 길이는 6옥텟이므로 HLEN은 6으로 설정된다. CHADDR은 클라이언트가 사용하는 MAC 주소로 설정된다. 일부 옵션도 함께 설정된다.

DHCPDISCOVER 메시지가 포함된 이더넷 프레임 예시
오프셋 옥텟 0 1 2 3
옥텟 비트 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Destination MAC (FF:FF:FF:FF:FF:FF)
4 32    
8 64 Source MAC (00:05:3C:04:8D:59)
12 96 EtherType (0x0800)  
16 128 IPv4 패킷, DHCP 페이로드를 포함한 UDP PDU 함유...
20 160
⋮ ⋮
⋮ ⋮ Frame Check Sequence
IPv4 헤더
오프셋 옥텟 0 1 2 3
옥텟 비트 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 IPv4 헤더 시작
4 32
8 64 TTL 프로토콜 (17 UDP) 헤더 체크섬
12 96 소스 주소 (0.0.0.0)
16 128 목적지 주소
UDP 헤더
20 160 소스 포트 (68) 목적지 포트 (67)
24 192 길이 체크섬
DHCP 페이로드: DHCPDISCOVER
28 224 OP (0x01) HTYPE (0x01) HLEN (0x06) HOPS (0x00)
32 256 XID (0x3903F326)
36 288 SECS (0x0000) FLAGS (0x0000)
40 320 CIADDR (클라이언트 IP 주소: 0x00000000)
44 352 YIADDR (귀하의 IP 주소: 0x00000000)
48 384 SIADDR (서버 IP 주소: 0x00000000)
52 416 GIADDR (게이트웨이 IP 주소: 0x00000000)
56 448 CHADDR (클라이언트 하드웨어 주소: 0x00053C04
0x8D590000
0x00000000
0x00000000)
60 480
64 512
68 544
72 576 0으로 채워진 192옥텟, 또는 추가 옵션을 위한 오버플로 공간; BOOTP 유산.
⋮ ⋮
260 2080
264 2112 매직 쿠키 (0x63825363)
DHCP 옵션 (TLV 형식)
268 2144 첫 번째 옵션: 0x350101: 옵션 53 (DHCP 메시지 유형) 1옥텟 (DHCPDISCOVER 포함) 두 번째 옵션:↴
272 2176 ↪0x3204c0a80164: 옵션 50 (요청 IP 주소) 4옥텟 (192.168.1.100 포함)
276 2208 세 번째 옵션: 0x370401030f06: 옵션: 55 (매개변수 요청 목록) 4옥텟↴
280 2240 ↪PRL 계속... ff

제안 (Offer)

[편집]

DHCP 서버가 클라이언트로부터 IP 주소 임대 요청인 DHCPDISCOVER 메시지를 받으면, DHCP 서버는 클라이언트를 위해 IP 주소를 예약하고 클라이언트에 DHCPOFFER 메시지를 보내 임대 제안을 한다. 이 메시지에는 클라이언트의 클라이언트 ID(고유한 값을 포함하는 옵션 61, 전통적으로 MAC 주소), 서버가 제공하는 IP 주소, 서브넷 마스크, 임대 기간, 제안을 하는 DHCP 서버의 IP 주소가 포함될 수 있다. DHCP 서버는 CHADDR 필드에 지정된 하드웨어 레벨 MAC 주소도 주목할 수 있다. DHCP 패킷에 클라이언트 ID가 제공되지 않은 경우 이 필드를 사용하여 클라이언트를 식별해야 한다.[1]: §4.2 

DHCP 서버는 CHADDR(클라이언트 하드웨어 주소) 필드에 지정된 클라이언트의 하드웨어 주소를 기반으로 구성을 결정한다. 다음 예에서 서버(192.168.1.1)는 YIADDR(귀하의 IP 주소) 필드에 클라이언트의 IP 주소를 지정한다.

DHCPOFFER 메시지가 포함된 이더넷 프레임 예시
오프셋 옥텟 0 1 2 3
옥텟 비트 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Destination MAC (00:05:3C:04:8D:59)
4 32    
8 64 Source MAC (B4:0C:25:E3:7D:62)
12 96 EtherType (0x0800)  
16 128 IPv4 패킷, DHCP 페이로드를 포함한 UDP PDU 함유...
20 160
⋮ ⋮
⋮ ⋮ Frame Check Sequence
IPv4 헤더
오프셋 옥텟 0 1 2 3
옥텟 비트 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 IPv4 헤더 시작
4 32
8 64 TTL 프로토콜 (17 UDP) 헤더 체크섬
12 96 소스 주소 (192.168.1.1)
16 128 목적지 주소 (192.168.1.100)
UDP 헤더
20 160 소스 포트 (67) 목적지 포트 (68)
24 192 길이 체크섬
DHCP 페이로드: DHCPOFFER
28 224 OP (0x02) HTYPE (0x01) HLEN (0x06) HOPS (0x00)
32 256 XID (0x3903F326)
36 288 SECS (0x0000) FLAGS (0x0000)
40 320 CIADDR (클라이언트 IP 주소: 0x00000000)
44 352 YIADDR (귀하의 IP 주소: 0xC0A80164 또는 192.168.1.100)
48 384 SIADDR (서버 IP 주소: 0xC0A80101 또는 192.168.1.1)
52 416 GIADDR (게이트웨이 IP 주소: 0x00000000)
56 448 CHADDR (클라이언트 하드웨어 주소: 0x00053C04
0x8D590000
0x00000000
0x00000000)
60 480
64 512
68 544
72 576 0으로 채워진 192옥텟, 또는 추가 옵션을 위한 오버플로 공간; BOOTP 유산.
⋮ ⋮
260 2080
264 2112 매직 쿠키 (0x63825363)
DHCP 옵션 (TLV 형식)
268 2144 첫 번째 옵션: 0x350102: 옵션 53 (DHCP 메시지 유형) 1옥텟 (DHCPOFFER 포함) 두 번째 옵션:↴
272 2176 ↪0x0104ffffff00: 옵션 1 (서브넷 마스크) 4옥텟 (255.255.255.0 포함)
276 2208 세 번째 옵션: 0x0304c0A80101: 옵션: 3 (라우터) 4옥텟 (192.168.1.1 포함)↴
280 2240 ↪라우터 계속... 네 번째 옵션: 0x330400015080: 옵션 51 (주소 시간) 4옥텟 (86400초 임대 시간)↴
284 2272 ↪주소 시간 계속... 다섯 번째 옵션:
288 2304 0x060c09070a0f09070a1009070a13:
옵션 6 (도메인 서버) 14옥텟 (9.7.10.15,9.7.10.16,9.7.10.18 포함)
292 2336
296 2368
300 2400   ff

요청 (Request)

[편집]

DHCP 제안에 응답하여 클라이언트는 서버에 DHCPREQUEST 메시지를 브로드캐스팅하여[a] 제안된 주소를 요청한다. 클라이언트는 여러 서버로부터 DHCP 제안을 받을 수 있지만, 단 하나의 DHCP 제안만 수락한다.

클라이언트는 DHCPREQUEST 메시지에 서버 식별 옵션을 보내 클라이언트가 선택한 제안을 보낸 서버를 나타내야 한다.[1]: Section 3.1, Item 3  다른 DHCP 서버가 이 메시지를 받으면 클라이언트에게 했던 모든 제안을 철회하고 제안했던 IP 주소를 가용 주소 풀로 반환한다.

DHCPREQUEST 메시지가 포함된 이더넷 프레임 예시
오프셋 옥텟 0 1 2 3
옥텟 비트 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Destination MAC (FF:FF:FF:FF:FF:FF)
4 32    
8 64 Source MAC (00:05:3C:04:8D:59)
12 96 EtherType (0x0800)  
16 128 IPv4 패킷, DHCP 페이로드를 포함한 UDP PDU 함유...
20 160
⋮ ⋮
⋮ ⋮ Frame Check Sequence
IPv4 헤더
오프셋 옥텟 0 1 2 3
옥텟 비트 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 IPv4 헤더 시작
4 32
8 64 TTL 프로토콜 (17 UDP) 헤더 체크섬
12 96 소스 주소 (0.0.0.0)
16 128 목적지 주소 (255.255.255.255)
UDP 헤더
20 160 소스 포트 (68) 목적지 포트 (67)
24 192 길이 체크섬
DHCP 페이로드: DHCPREQUEST
28 224 OP (0x01) HTYPE (0x01) HLEN (0x06) HOPS (0x00)
32 256 XID (0x3903F326)
36 288 SECS (0x0000) FLAGS (0x0000)
40 320 CIADDR (클라이언트 IP 주소: 0x00000000)
44 352 YIADDR (귀하의 IP 주소: 0x00000000)
48 384 SIADDR (서버 IP 주소: 0xc0a80101 또는 192.168.1.1)
52 416 GIADDR (게이트웨이 IP 주소: 0x00000000)
56 448 CHADDR (클라이언트 하드웨어 주소: 0x00053C04
0x8D590000
0x00000000
0x00000000)
60 480
64 512
68 544
72 576 0으로 채워진 192옥텟, 또는 추가 옵션을 위한 오버플로 공간; BOOTP 유산.
⋮ ⋮
260 2080
264 2112 매직 쿠키 (0x63825363)
DHCP 옵션 (TLV 형식)
268 2144 첫 번째 옵션: 0x350103: 옵션 53 (DHCP 메시지 유형) 1옥텟 (DHCPREQUEST 포함) 두 번째 옵션:↴
272 2176 ↪0x3204c0a80164: 옵션 50 (요청 IP 주소) 4옥텟 (192.168.1.100 포함)
276 2208 세 번째 옵션: 0x3604c0a801601: 옵션: 54 (DHCP 서버) 4옥텟 (192.168.1.1 포함)↴
280 2240 ↪DHCP 서버 계속... ff

확인 (Acknowledgement)

[편집]

DHCP 서버가 클라이언트로부터 DHCPREQUEST 메시지를 받으면 구성 프로세스는 최종 단계에 들어간다. 확인 단계는 클라이언트에 DHCPACK 패킷을 보내는 것을 포함한다. 이 패킷에는 임대 기간과 클라이언트가 요청했을 수 있는 기타 구성 정보가 포함된다. 이 시점에서 IP 구성 프로세스가 완료된다.

프로토콜은 DHCP 클라이언트가 협상된 매개변수로 네트워크 인터페이스를 구성할 것을 요구한다.

DHCPACK 메시지가 포함된 이더넷 프레임 예시
오프셋 옥텟 0 1 2 3
옥텟 비트 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Destination MAC (00:05:3C:04:8D:59)
4 32    
8 64 Source MAC (B4:0C:25:E3:7D:62)
12 96 EtherType (0x0800)  
16 128 IPv4 패킷, DHCP 페이로드를 포함한 UDP PDU 함유...
20 160
⋮ ⋮
⋮ ⋮ Frame Check Sequence
IPv4 헤더
오프셋 옥텟 0 1 2 3
옥텟 비트 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 IPv4 헤더 시작
4 32
8 64 TTL 프로토콜 (17 UDP) 헤더 체크섬
12 96 소스 주소 (192.168.1.1)
16 128 목적지 주소 (192.168.1.100)
UDP 헤더
20 160 소스 포트 (67) 목적지 포트 (68)
24 192 길이 체크섬
DHCP 페이로드: DHCPACK
28 224 OP (0x02) HTYPE (0x01) HLEN (0x06) HOPS (0x00)
32 256 XID (0x3903F326)
36 288 SECS (0x0000) FLAGS (0x0000)
40 320 CIADDR (클라이언트 IP 주소: 0x00000000)
44 352 YIADDR (귀하의 IP 주소: 0xC0A80164 또는 192.168.1.100)
48 384 SIADDR (서버 IP 주소: 0xC0A80101 또는 192.168.1.1)
52 416 GIADDR (게이트웨이 IP 주소: 0x00000000)
56 448 CHADDR (클라이언트 하드웨어 주소: 0x00053C04
0x8D590000
0x00000000
0x00000000)
60 480
64 512
68 544
72 576 0으로 채워진 192옥텟, 또는 추가 옵션을 위한 오버플로 공간; BOOTP 유산.
⋮ ⋮
260 2080
264 2112 매직 쿠키 (0x63825363)
DHCP 옵션 (TLV 형식)
268 2144 첫 번째 옵션: 0x350105: 옵션 53 (DHCP 메시지 유형) 1옥텟 (DHCPACK 포함) 두 번째 옵션:↴
272 2176 ↪0x0104ffffff00: 옵션 1 (서브넷 마스크) 4옥텟 (255.255.255.0 포함)
276 2208 세 번째 옵션: 0x0304c0A80101: 옵션: 3 (라우터) 4옥텟 (192.168.1.1 포함)↴
280 2240 ↪라우터 계속... 네 번째 옵션: 0x330400015080: 옵션 51 (주소 시간) 4옥텟 (86400초 임대 시간)↴
284 2272 ↪주소 시간 계속... 다섯 번째 옵션:
288 2304 0x060c09070a0f09070a1009070a13:
옵션 6 (도메인 서버) 14옥텟 (9.7.10.15,9.7.10.16,9.7.10.18 포함)
292 2336
296 2368
300 2400   ff

IP 주소 선택 및 구성

[편집]

서버가 풀에서 IP 주소를 재사용할 때, 해당 주소가 이미 사용 중인지 확인하기 위해 먼저 (ping을 사용하여) 확인할 수 있다.[1]: sec. 2.2  이는 호스트가 DHCP 범위 내에 있는 IP 주소를 수동으로 구성한 경우에 발생할 수 있다.

IP 주소를 할당받기 전에 클라이언트는 제안된 IP 주소를 가진 다른 호스트가 네트워크에 있는지 확인하기 위해 수신된 주소를 조사해야 한다(예: ARP 사용).[1]: sec. 2.2  응답이 없으면 해당 주소는 다른 호스트와 충돌하지 않으므로 자유롭게 사용할 수 있다. 이 조사를 통해 해당 주소를 사용하는 다른 컴퓨터가 발견되면 클라이언트는 DHCP 서버에 DHCPDECLINE을 브로드캐스팅해야 한다.

정보

[편집]

DHCP 클라이언트는 서버가 원래 DHCPOFFER와 함께 보낸 정보보다 더 많은 정보를 요청할 수 있다. 클라이언트는 특정 애플리케이션에 대한 데이터 반복을 요청할 수도 있다. 예를 들어, 브라우저는 WPAD를 통해 웹 프록시 설정을 얻기 위해 DHCP Inform을 사용한다.

해제 (Releasing)

[편집]

클라이언트는 DHCP 서버에 DHCP 정보를 해제하라는 요청을 보내고 클라이언트는 해당 IP 주소를 비활성화한다. 클라이언트 장치는 일반적으로 사용자가 네트워크에서 장치를 언제 분리할지 알 수 없으므로 프로토콜에서 DHCP Release 전송을 의무화하지는 않는다.

클라이언트 구성 매개변수

[편집]

DHCP 서버는 클라이언트에 선택적 구성 매개변수를 제공할 수 있다. RFC 2132는 IANA(Internet Assigned Numbers Authority) - DHCP 및 BOOTP PARAMETERS에서 정의한 가용 DHCP 옵션을 설명한다.[12]

DHCP 클라이언트는 DHCP 서버가 제공하는 매개변수를 선택, 조작 및 덮어쓸 수 있다. 유닉스 계열 시스템에서 이러한 클라이언트 수준의 조정은 일반적으로 /etc/dhclient.conf 구성 파일의 값에 따라 이루어진다.

옵션

[편집]

옵션은 가변 길이의 옥텟 문자열이다. 이를 형식-길이-값(Type–length–value) 인코딩이라고 한다. 첫 번째 옥텟은 옵션 코드이고, 두 번째 옥텟은 뒤따르는 옥텟의 수이며, 나머지 옥텟은 코드에 따라 달라진다. 예를 들어, 제안에 대한 DHCP 메시지 유형 옵션은 0x35, 0x01, 0x02로 나타나는데, 여기서 0x35는 "DHCP 메시지 유형"에 대한 코드 53이고, 0x01은 한 옥텟이 뒤따름을 의미하며, 0x02는 "제안(offer)"의 값이다.

다음 표는 사용 가능한 DHCP 옵션을 나열한다.[13][12]

RFC 1497 (BOOTP Vendor Information Extensions) 벤더 확장[13]: Section 3 
코드이름길이비고
0패드 (Pad)0 옥텟워드 경계에 맞추기 위해 다른 옵션을 채우는 데 사용될 수 있음; 길이 바이트가 뒤따르지 않음
1서브넷 마스크4옥텟RFC 950에 따른 클라이언트의 서브넷 마스크. 서브넷 마스크와 라우터 옵션(옵션 3)이 모두 포함된 경우 서브넷 마스크 옵션이 먼저 와야 함.
2시간 오프셋4옥텟협정 세계시(UTC)로부터 클라이언트 서브넷의 시간 오프셋(초 단위). 오프셋은 2의 보수 32비트 정수로 표현됨. 양수 오프셋은 본초 자오선 동쪽을, 음수 오프셋은 본초 자오선 서쪽을 나타냄.
3라우터4옥텟의 배수사용 가능한 라우터 목록, 선호도 순으로 나열되어야 함
4시간 서버4옥텟의 배수동기화할 수 있는 가용 타임 프로토콜 서버 목록, 선호도 순으로 나열되어야 함
5네임 서버4옥텟의 배수사용 가능한 IEN 116 네임 서버 목록, 선호도 순으로 나열되어야 함
6도메인 네임 서버4옥텟의 배수사용 가능한 DNS 서버 목록, 선호도 순으로 나열되어야 함
7로그 서버4옥텟의 배수사용 가능한 로그 서버 목록, 선호도 순으로 나열되어야 함
8쿠키 서버4옥텟의 배수여기서 쿠키는 대형 컴퓨터의 로그온 프로세스 중에 전송되는 짧고 유머러스한 격언인 "포춘 쿠키"를 의미함; 웹사이트에서 전송하는 쿠키와는 아무런 관련이 없음.
9LPR 서버4옥텟의 배수클라이언트가 사용할 수 있는 라인 프린터 데몬 프로토콜 서버 목록, 선호도 순으로 나열되어야 함
10Impress 서버4옥텟의 배수클라이언트가 사용할 수 있는 Imagen Impress 서버 목록, 선호도 순으로 나열되어야 함
11자원 위치 서버4옥텟의 배수클라이언트가 사용할 수 있는 리소스 위치 프로토콜 서버 목록, 선호도 순으로 나열되어야 함
12호스트 네임최소 1옥텟클라이언트의 이름. 로컬 도메인 네임으로 수식될 수 있음.
13부트 파일 크기2옥텟512바이트 블록 단위의 부트 이미지 길이
14Merit 덤프 파일최소 1옥텟크래시 덤프를 저장할 경로
15도메인 네임최소 1옥텟
16스왑 서버4옥텟디스크리스 워크스테이션을 위해 스왑 서비스(예: NFS를 통한 스왑)가 제공되는 서버의 IP 주소[14]
17루트 경로최소 1옥텟클라이언트가 루트 파일 시스템으로 마운트해야 하는(예: NFS를 통해) siaddr 또는 sname에 지정된 원격 파일 시스템의 경로
18확장 경로최소 1옥텟
255종료 (End)0옥텟벤더 옵션 필드의 끝을 표시하는 데 사용됨
호스트당 IP 계층 매개변수[13]: Section 4 
코드이름길이비고
19IP 포워딩 활성화/비활성화1옥텟
20비로컬 소스 라우팅 활성화/비활성화1옥텟
21정책 필터8옥텟의 배수
22최대 데이터그램 재조립 크기2옥텟
23기본 IP TTL1옥텟
24경로 MTU 에이징 타임아웃4옥텟
25경로 MTU 고원 표 (plateau table)2옥텟의 배수
인터페이스당 IP 계층 매개변수[13]: Section 5 
코드이름길이비고
26인터페이스 MTU2옥텟
27모든 서브넷은 로컬1옥텟
28브로드캐스트 주소4옥텟
29마스크 발견 수행1옥텟
30마스크 공급자1옥텟
31라우터 발견 수행1옥텟
32라우터 권유 주소4옥텟
33정적 경로8옥텟의 배수목적지/라우터 쌍의 목록
인터페이스당 링크 계층 매개변수[13]: Section 6 
코드이름길이비고
34트레일러 캡슐화 옵션1옥텟
35ARP 캐시 타임아웃4옥텟
36이더넷 캡슐화1옥텟
TCP 매개변수[13]: Section 7 
코드이름길이비고
37TCP 기본 TTL1옥텟
38TCP 킵얼라이브 간격4옥텟
39TCP 킵얼라이브 가비지1옥텟
애플리케이션 및 서비스 매개변수[13]: Section 8 
코드이름길이비고
40네트워크 정보 서비스 도메인최소 1옥텟
41네트워크 정보 서버4옥텟의 배수
42네트워크 타임 프로토콜(NTP) 서버4옥텟의 배수
43벤더 특이 정보최소 1옥텟
44NetBIOS over TCP/IP 네임 서버4옥텟의 배수
45NetBIOS over TCP/IP 데이터그램 분배 서버4옥텟의 배수
46NetBIOS over TCP/IP 노드 유형1옥텟
47NetBIOS over TCP/IP 스코프최소 1옥텟
48X 윈도 시스템 폰트 서버4옥텟의 배수
49X 윈도 시스템 디스플레이 매니저4옥텟의 배수
64네트워크 정보 서비스+ 도메인최소 1옥텟
65네트워크 정보 서비스+ 서버4옥텟의 배수
68모바일 IP 홈 에이전트4옥텟의 배수
69간이 우편 전송 프로토콜(SMTP) 서버4옥텟의 배수
70포스트 오피스 프로토콜(POP3) 서버4옥텟의 배수
71네트워크 뉴스 전송 프로토콜(NNTP) 서버4옥텟의 배수
72기본 월드 와이드 웹(WWW) 서버4옥텟의 배수
73기본 Finger 프로토콜 서버4옥텟의 배수
74기본 인터넷 릴레이 챗(IRC) 서버4옥텟의 배수
75StreetTalk 서버4옥텟의 배수
76StreetTalk 디렉토리 지원(STDA) 서버4옥텟의 배수
DHCP 확장[13]: Section 9 
코드이름길이비고
50요청 IP 주소4옥텟
51IP 주소 임대 시간4옥텟
52옵션 오버로드1옥텟
53DHCP 메시지 유형1옥텟
54서버 식별자4옥텟
55매개변수 요청 목록최소 1옥텟
56메시지최소 1옥텟
57최대 DHCP 메시지 크기2옥텟
58갱신(T1) 시간 값4옥텟
59재바인딩(T2) 시간 값4옥텟
60벤더 클래스 식별자최소 1옥텟
61클라이언트 식별자최소 2옥텟
66TFTP 서버 이름최소 1옥텟
67부트파일 이름최소 1옥텟

DHCP 메시지 유형

[편집]

이 표는 DHCP 메시지 유형을 나열한다. 이 코드들은 위의 표에 표시된 DHCP 확장 53의 값이다.

DHCP 메시지 유형
코드이름길이RFC
1DHCPDISCOVER1옥텟2132[13]: §9.6 
2DHCPOFFER1옥텟2132
3DHCPREQUEST1옥텟2132
4DHCPDECLINE1옥텟2132
5DHCPACK1옥텟2132
6DHCPNAK1옥텟2132
7DHCPRELEASE1옥텟2132
8DHCPINFORM1옥텟2132
9DHCPFORCERENEW1옥텟3203[15]: §4 
10DHCPLEASEQUERY1옥텟4388[16]: §6.1 
11DHCPLEASEUNASSIGNED1옥텟4388
12DHCPLEASEUNKNOWN1옥텟4388
13DHCPLEASEACTIVE1옥텟4388
14DHCPBULKLEASEQUERY1옥텟6926[17]: §6.2.1 
15DHCPLEASEQUERYDONE1옥텟6926
16DHCPACTIVELEASEQUERY1옥텟7724[18]: §5.2.1 
17DHCPLEASEQUERYSTATUS1옥텟7724
18DHCPTLS1옥텟7724

클라이언트 벤더 식별

[편집]

DHCP 클라이언트의 벤더 및 기능을 식별하기 위한 옵션이 존재한다. 정보는 DHCP 클라이언트의 벤더가 지정한 의미를 갖는 가변 길이의 문자 또는 옥텟 문자열이다. DHCP 클라이언트가 특정 유형의 하드웨어나 펌웨어를 사용하고 있음을 서버에 알리는 한 가지 방법은 DHCP 요청에서 벤더 클래스 식별자(VCI)(옵션 60)라는 값을 설정하는 것이다.

이 옵션에 설정된 값은 DHCP 서버에 이 클라이언트가 DHCP 응답에서 필요로 하는 추가 정보에 대한 힌트를 제공한다. 일부 유형의 셋톱박스는 하드웨어 유형과 장치의 기능을 DHCP 서버에 알리기 위해 VCI를 설정한다. 예를 들어, 아루바 캠퍼스 무선 액세 포인트는 DHCPDISCOVER 메시지의 옵션 60으로 'ArubaAP' 값을 제공한다.[19] 그러면 DHCP 서버는 옵션 43에 아루바 무선 컨트롤러의 IP 주소를 포함하여 DHCPOFFER를 보강할 수 있으며, 이를 통해 액세스 포인트는 어디에 자신을 등록해야 할지 알게 된다.

클라이언트가 VCI를 설정하면 DHCP 서버가 클라이언트 기기를 차별화하고 해당 요청을 적절하게 처리할 수 있다.

기타 확장

[편집]
문서화된 DHCP 옵션
코드이름길이RFC
77사용자 클래스최소 2옥텟3004[20]
82릴레이 에이전트 정보최소 2옥텟3046[21]
85Novell Directory Service (NDS) 서버최소 4옥텟, 4옥텟의 배수2241[22]: §2 
86NDS 트리 이름가변2241[22]: §3 
87NDS 컨텍스트가변2241[22]: §4 
100시간대, POSIX 스타일가변4833[23]
101시간대, tz 데이터베이스 스타일가변4833
114DHCP 캡티브 포털가변8910[24]
119도메인 검색가변3397[25]
121비클래스 정적 경로가변3442[26]
209구성 파일가변5071[27]
210경로 접두사가변5071
211재부팅 시간가변5071
224–254사이트 특정 옵션가변3942

릴레이 에이전트 정보 하위 옵션

[편집]

릴레이 에이전트 정보 옵션(옵션 82)은 DHCP 릴레이와 DHCP 서버 간에 전송되는 DHCP 요청에 하위 옵션을 첨부하기 위한 컨테이너를 지정한다.[28]

릴레이 에이전트 하위 옵션
코드이름길이RFC
1에이전트 회선 ID최소 1옥텟3046[21]
2에이전트 원격 ID최소 1옥텟3046
4DOCSIS 장치 클래스4옥텟3256[29]
5링크 선택4옥텟3527[30]

릴레이

[편집]

단 하나의 IP 서브넷만 관리되는 소규모 네트워크에서 DHCP 클라이언트는 DHCP 서버와 직접 통신한다. 그러나 DHCP 서버는 여러 서브넷에 대해 IP 주소를 제공할 수도 있다. 이 경우, 아직 IP 주소를 획득하지 못한 DHCP 클라이언트는 자신의 브로드캐스트가 자신의 서브넷에서만 수신될 수 있기 때문에 동일한 서브넷에 있지 않은 DHCP 서버와 직접 통신할 수 없다.

DHCP 서버가 직접 서비스하지 않는 서브넷의 DHCP 클라이언트가 DHCP 서버와 통신할 수 있도록 해당 서브넷에 DHCP 릴레이 에이전트를 설치할 수 있다. DHCP 릴레이 에이전트는 클라이언트의 서브넷과 DHCP 서버의 서브넷 간에 라우팅이 가능한 네트워크 장치에서 실행된다. DHCP 클라이언트는 로컬 링크에서 브로드캐스팅하고, 릴레이 에이전트는 이 브로드캐스트를 수신하여 유니캐스트를 사용해 하나 이상의 DHCP 서버로 전송한다. DHCP 서버의 IP 주소는 릴레이 에이전트에 수동으로 구성된다. 릴레이 에이전트는 클라이언트의 브로드캐스트를 수신한 인터페이스의 자체 IP 주소를 DHCP 패킷의 GIADDR 필드에 저장한다. DHCP 서버는 GIADDR 값을 사용하여 IP 주소를 할당할 서브넷과 그에 해당하는 주소 풀을 결정한다. DHCP 서버가 클라이언트에 응답할 때, 다시 유니캐스트를 사용하여 GIADDR 주소로 응답을 보낸다. 릴레이 에이전트는 클라이언트의 MAC 주소로 향하는 이더넷 프레임에 새로 예약된 IP 주소를 담아 (대부분의 경우) 유니캐스트를 사용하여 로컬 네트워크에 응답을 재전송한다. 클라이언트는 해당 IP 주소가 아직 인터페이스에 설정되지 않았더라도 해당 패킷을 자신의 것으로 수락해야 한다.[1]: 25  패킷을 처리한 직후, 클라이언트는 인터페이스에 IP 주소를 설정하고 그 즉시 정규 IP 통신을 할 준비가 된다.

IP 스택의 클라이언트 구현이 IP 주소가 아직 없을 때 유니캐스트 패킷을 수락하지 않는 경우, 클라이언트는 DHCPDISCOVER 패킷을 보낼 때 FLAGS 필드에 브로드캐스트 비트를 설정할 수 있다. 릴레이 에이전트는 클라이언트에게 서버의 DHCPOFFER를 알리기 위해 255.255.255.255 브로드캐스트 IP 주소(및 클라이언트의 MAC 주소)를 사용한다.

릴레이 에이전트와 DHCP 서버 간의 통신은 일반적으로 소스 및 목적지 UDP 포트 67번을 모두 사용한다.

클라이언트 상태

[편집]
RFC 2131의 그림 5를 기반으로 한 단순화된 DHCP 클라이언트 상태 전이도

DHCP 클라이언트는 서버로부터 다음 메시지들을 받을 수 있다:[1]: §4.4 

  • DHCPOFFER
  • DHCPACK
  • DHCPNAK

클라이언트는 자신이 보내는 메시지에 서버가 어떻게 응답하느냐에 따라 DHCP 상태를 이동한다.

신뢰성

[편집]

DHCP는 주기적 갱신, 재바인딩,[1]: §4.4.5  그리고 페일오버 등 여러 가지 방법으로 신뢰성을 보장한다. DHCP 클라이언트는 일정 기간 동안 지속되는 임대권을 할당받는다. 클라이언트는 임대 간격의 절반이 지나면 임대 갱신 시도를 시작한다.[1]: §4.4.5 Paragraph 3  클라이언트는 원래 임대를 승인한 DHCP 서버에 유니캐스트 DHCPREQUEST 메시지를 보내 이 작업을 수행한다. 해당 서버가 다운되었거나 연결할 수 없는 경우 DHCPREQUEST에 응답하지 않는다. 그러나 이 경우 클라이언트는 때때로 DHCPREQUEST를 반복하므로,[1]: §4.4.5 Paragraph 8 [b] DHCP 서버가 다시 복구되거나 연결 가능해지면 DHCP 클라이언트는 서버에 성공적으로 접속하여 임대를 갱신하게 된다.

DHCP 서버를 장기간 연결할 수 없는 경우,[1]: §4.4.5 Paragraph 5  DHCP 클라이언트는 DHCPREQUEST를 유니캐스트가 아닌 브로드캐스팅하여 재바인딩을 시도한다. 브로드캐스트이므로 DHCPREQUEST 메시지는 사용 가능한 모든 DHCP 서버에 도달한다. 다른 DHCP 서버가 임대를 갱신할 수 있는 경우 이 시점에 갱신을 수행한다.

재바인딩이 작동하려면 클라이언트가 백업 DHCP 서버에 성공적으로 연결했을 때 해당 서버가 클라이언트의 바인딩에 대한 정확한 정보를 가지고 있어야 한다. 두 서버 간에 정확한 바인딩 정보를 유지하는 것은 복잡한 문제이다. 두 서버가 동일한 임대 데이터베이스를 업데이트할 수 있는 경우, 독립적인 서버들 간의 업데이트 충돌을 피하기 위한 메커니즘이 있어야 한다. 결함 허용 DHCP 서버 구현 제안이 국제 인터넷 표준화 기구(IETF)에 제출되었으나 공식화되지는 않았다.[31][c]

재바인딩이 실패하면 결국 임대가 만료된다. 임대가 만료되면 클라이언트는 임대 기간 동안 부여받은 IP 주소의 사용을 중단해야 한다.[1]: §4.4.5 Paragraph 9  그 시점에 클라이언트는 DHCPDISCOVER 메시지를 브로드캐스팅하여 처음부터 DHCP 프로세스를 다시 시작한다. 임대가 만료되었으므로 자신에게 제공되는 모든 IP 주소를 수락한다. (아마도 다른 DHCP 서버로부터) 새 IP 주소를 받으면 다시 네트워크를 사용할 수 있게 된다. 그러나 IP 주소가 변경되었으므로 진행 중인 모든 연결은 끊어진다.

IPv6 네트워크

[편집]

DHCP의 기본 방법론은 인터넷 프로토콜 버전 4(IPv4) 기반 네트워크를 위해 개발되었다. IPv6 네트워크의 개발 및 배포 이후, IPv6 고유의 비상태 저장 주소 자동 구성 기능에도 불구하고 이러한 네트워크에서 매개변수를 할당하기 위해 DHCP가 사용되어 왔다. 이 프로토콜의 IPv6 버전은 DHCPv6로 지정된다.[32]

보안

[편집]

기본 DHCP에는 인증 메커니즘이 포함되어 있지 않다.[21]: §7  이 때문에 다양한 공격에 취약하다. 이러한 공격은 크게 세 가지 범주로 나뉜다:[1]: sec. 7 

  • 승인되지 않은 DHCP 서버가 클라이언트에 허위 정보를 제공함.
  • 승인되지 않은 클라이언트가 자원에 접근함.
  • 악의적인 DHCP 클라이언트의 자원 고갈 공격.

클라이언트는 DHCP 서버의 신원을 확인할 방법이 없기 때문에, 네트워크에서 승인되지 않은 DHCP 서버(흔히 "rogue DHCP"라 함)를 운영하여 DHCP 클라이언트에 잘못된 정보를 제공할 수 있다.[33] 이는 클라이언트의 네트워크 접속을 방해하는 서비스 거부 공격이나[34] 중간자 공격으로 작용할 수 있다.[35] DHCP 서버는 하나 이상의 DNS 서버 IP 주소와 같은 서버 IP 주소를 DHCP 클라이언트에 제공하므로,[1]: sec. 7  공격자는 DHCP 클라이언트가 자신의 DNS 서버를 통해 DNS 조회를 하도록 유도하고 클라이언트의 DNS 쿼리에 대해 자신의 답변을 제공할 수 있다.[36] 이는 결과적으로 공격자가 네트워크 트래픽을 자신에게 리디렉션하여 클라이언트와 접속하는 네트워크 서버 간의 통신을 도청하거나 해당 네트워크 서버를 자신의 서버로 간단히 교체할 수 있게 한다.[36]

DHCP 서버는 클라이언트를 인증하는 보안 메커니즘이 없기 때문에, 클라이언트는 다른 DHCP 클라이언트에 속한 클라이언트 식별자와 같은 자격 증명을 제시하여 IP 주소에 무단으로 접근할 수 있다.[33] 또한 DHCP 클라이언트는 주소를 요청할 때마다 새로운 자격 증명을 제시함으로써 DHCP 서버의 IP 주소 저장소를 고갈시킬 수 있으며, 특정 네트워크 링크의 모든 가용 IP 주소를 소모하여 다른 DHCP 클라이언트가 서비스를 받지 못하게 할 수 있다.[33]

DHCP는 이러한 문제를 완화하기 위한 몇 가지 메커니즘을 제공한다. 릴레이 에이전트 정보 옵션 프로토콜 확장[21](업계에서는 보통 실제 번호인 옵션 82로 지칭됨[37][38])을 사용하면 네트워크 운영자가 메시지가 네트워크 운영자의 신뢰할 수 있는 네트워크에 도착할 때 DHCP 메시지에 태그를 부착할 수 있다. 이 태그는 클라이언트의 네트워크 자원 접근을 제어하기 위한 권한 부여 토큰으로 사용된다. 클라이언트는 릴레이 에이전트 상류의 네트워크에 접근할 수 없으므로, 인증이 없더라도 DHCP 서버 운영자가 권한 부여 토큰에 의존하는 것을 방해하지 않는다.[21]: sec. 7 

또 다른 확장인 DHCP 메시지 인증[39](RFC 3118)은 DHCP 메시지를 인증하기 위한 메커니즘을 제공한다. 2002년 기준으로 이 확장은 수많은 DHCP 클라이언트의 키 관리 문제로 인해 널리 채택되지 못했다.[40] DSL 기술에 관한 2007년 서적은 다음과 같이 언급했다:

RFC 3118에서 제안된 보안 조치에 대해 수많은 보안 취약점이 발견되었다. 이 사실은 802.1X의 도입과 결합되어 인증된 DHCP의 배포 및 채택 속도를 늦추었으며, 결과적으로 널리 배포된 적이 없다.[41]

2010년 서적은 다음과 같이 적고 있다:

DHCP 인증의 구현 사례는 매우 드물다. 키 관리의 어려움과 해시 계산으로 인한 처리 지연은 예상되는 이점에 비해 치러야 할 대가가 너무 큰 것으로 간주되어 왔다.[42]

2008년의 아키텍처 제안에는 802.1X 또는 PANA(둘 다 EAP를 전송함)를 사용하여 DHCP 요청을 인증하는 내용이 포함되어 있다.[43] DHCP 자체에 EAP를 포함시키자는 소위 EAPoDHCP라는 IETF 제안이 있었으나,[44] 이는 2010년 마지막 초안을 끝으로 IETF 드래프트 수준 이상으로 진전되지 않은 것으로 보인다.[45]

IETF 표준 문서

[편집]
  • RFC 2131 – "Dynamic Host Configuration Protocol,"[1] Draft Standard.
  • RFC 2132 – "DHCP Options and BOOTP Vendor Extensions,"[13] Draft Standard.
  • RFC 3046 – "DHCP Relay Agent Information Option,"[21] Proposed Standard.
  • RFC 3203 – "DHCP reconfigure extension,"[15] Proposed Standard.
  • RFC 3397 – "Dynamic Host Configuration Protocol (DHCP) Domain Search Option,"[25] Proposed Standard.
  • RFC 3442 – "The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4,"[26] Proposed Standard.
  • RFC 3942 – "Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options,"[46] Proposed Standard.
  • RFC 4361 – "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4),"[47] Proposed Standard.
  • RFC 4388 – "Dynamic Host Configuration Protocol (DHCP) Leasequery,"[16] Proposed Standard.
  • RFC 4436 – "Detecting Network Attachment in IPv4 (DNAv4),"[48] Proposed Standard.
  • RFC 6926 – "DHCPv4 Bulk Leasequery,"[17] Proposed Standard.
  • RFC 7724 – "Active DHCPv4 Lease Query,"[18] Proposed Standard.
  • RFC 8415 – "Dynamic Host Configuration Protocol for IPv6 (DHCPv6),"[9] Proposed Standard.

같이 보기

[편집]

각주

[편집]
  1. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 R. Droms (March 1997). Dynamic Host Configuration Protocol. IETF Network Working Group. RFC 2131. https://tools.ietf.org/html/rfc2131. Draft Standard. Obsoletes RFC 1541. Updated by RFC 3396, 4361, 5494 and 6842.
  2. ↑ Peterson, Larry L.; Davie, Bruce S. (2011). 《Computer Networks: A Systems Approach》 5판. Elsevier. ISBN 978-0-12-385060-7. 2019년 3월 21일에 확인함.
  3. ↑ R. Finlayson; T. Mann; J. Mogul; M. Theimer (June 1984). A Reverse Address Resolution Protocol. Network Working Group. STD 38. RFC 903. https://tools.ietf.org/html/rfc903. Internet Standard 38.
  4. ↑ Bill Croft; John Gilmore (September 1985). BOOTSTRAP PROTOCOL (BOOTP). Network Working Group. RFC 951. https://tools.ietf.org/html/rfc951. Draft Standard. Updated by RFC 1395, 1497, 1532, 1542 and 5494.
  5. ↑ R. Droms (October 1993). Dynamic Host Configuration Protocol. Network Working Group. RFC 1531. https://tools.ietf.org/html/rfc1531. Obsolete. Obsoleted by RFC 1541, due to errors in the editorial process.
  6. ↑ R. Droms (October 1993). Dynamic Host Configuration Protocol. Network Working Group. RFC 1541. https://tools.ietf.org/html/rfc1541. Obsolete. Obsoleted by RFC 2131. Obsoletes RFC 1531.
  7. ↑ Network+ Certification 2006 Published By Microsoft Press.
  8. ↑ J. Bound; B. Volz; T. Lemon; C. Perkins; M. Carney (July 2002). R. Droms. ed. Dynamic Host Configuration Protocol for IPv6 (DHCPv6). Network Working Group. RFC 3315. https://tools.ietf.org/html/rfc3315. Obsolete. Obsoleted by RFC 8415. Updated by RFC 4361, 5494, 6221, 6422, 6644, 7083, 7283, 7227 and 7550.
  9. 1 2 T. Mrugalski; M. Siodelski; B. Volz; A. Yourtchenko; M. Richardson; S. Jiang; T. Lemon; T. Winters (November 2018). Dynamic Host Configuration Protocol for IPv6 (DHCPv6). Internet Engineering Task Force. ISSN 2070-1721. RFC 8415. https://tools.ietf.org/html/rfc8415. Proposed Standard. Obsoletes RFC 3315, 3633, 3736, 4242, 7083, 7283 and 7550.
  10. ↑ “DHCP - Dynamic Host Configuration Protocol”.
  11. ↑ Droms, Ralph; Lemon, Ted (2003). 《The DHCP Handbook》. SAMS Publishing. 436쪽. ISBN 978-0-672-32327-0.
  12. 1 2 “Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters”. iana.org. 2018년 10월 16일에 확인함.
  13. 1 2 3 4 5 6 7 8 9 10 S. Alexander; R. Droms (March 1997). DHCP Options and BOOTP Vendor Extensions. IETF Network Working Group. RFC 2132. https://tools.ietf.org/html/rfc2132. Draft Standard. Obsoletes RFC 1533. Updated by RFC 3442, 3942, 4361, 4833 and 5494.
  14. ↑ Droms, Ralph; Lemon, Ted (2003). 《The DHCP handbook》 2판. Indianapolis, Indiana: Sams (October 2002에 출판됨). 134쪽. ISBN 978-0-672-32327-0.
  15. 1 2 Y. T'Joens; C. Hublet; P. De Schrijver (December 2001). DHCP reconfigure extension. Network Working Group. RFC 3203. https://tools.ietf.org/html/rfc3203. Proposed Standard. Updated by RFC 6704.
  16. 1 2 R. Woundy; K. Kinnear (February 2006). Dynamic Host Configuration Protocol (DHCP) Leasequery. Network Working Group. RFC 4388. https://tools.ietf.org/html/rfc4388. Proposed Standard. Updated by RFC 6148.
  17. 1 2 K. Kinnear; M. Stapp; R. Desetti; B. Joshi; N. Russell; P. Kurapati; B. Volz (April 2013). DHCPv4 Bulk Leasequery. Internet Engineering Task Force. ISSN 2070-1721. RFC 6926. https://tools.ietf.org/html/rfc6926. Proposed Standard. Updated by RFC 7724.
  18. 1 2 K. Kinnear; M. Stapp; B. Volz; N. Russell (December 2015). Active DHCPv4 Lease Query. Internet Engineering Task Force. ISSN 2070-1721. RFC 7724. https://tools.ietf.org/html/rfc7724. Proposed Standard. Updates RFC 6926.
  19. ↑ “Aruba DHCP Option 60”. 2020년 10월 7일. 2022년 4월 17일에 원본 문서에서 보존된 문서.
  20. ↑ G. Stump; R. Droms; Y. Gu; R. Vyaghrapuri; A. Demirtjis; B. Beser; J. Privat (November 2000). The User Class Option for DHCP. Network Working Group. RFC 3004. https://tools.ietf.org/html/rfc3004. Proposed Standard.
  21. 1 2 3 4 5 6 M. Patrick (January 2001). DHCP Relay Agent Information Option. Network Working Group. RFC 3046. https://tools.ietf.org/html/rfc3046. Proposed Standard. Updated by RFC 6607.
  22. 1 2 3 D. Provan (November 1997). DHCP Options for Novell Directory Services. Network Working Group. RFC 2241. https://tools.ietf.org/html/rfc2241. Proposed Standard.
  23. ↑ E. Lear; P. Eggert (April 2007). Timezone Options for DHCP. Network Working Group. RFC 4833. https://tools.ietf.org/html/rfc4833. Proposed Standard. Updates RFC 2132.
  24. ↑ W. Kumari; E. Kline (September 2020). Captive-Portal Identification in DHCP and Router Advertisements (RAs). Internet Engineering Task Force. ISSN 2070-1721. RFC 8910. https://tools.ietf.org/html/rfc8910. Proposed Standard. Obsoletes RFC 7710. Updates RFC 3679.
  25. 1 2 B. Aboba; S. Cheshire (November 2002). Dynamic Host Configuration Protocol (DHCP) Domain Search Option. Network Working Group. RFC 3397. https://tools.ietf.org/html/rfc3397. Proposed Standard.
  26. 1 2 T. Lemon; S. Cheshire; B. Volz (December 2002). The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4. Network Working Group. RFC 3442. https://tools.ietf.org/html/rfc3442. Proposed Standard. Updates RFC 2132.
  27. ↑ D. Hankins (December 2007). Dynamic Host Configuration Protocol Options Used by PXELINUX. Network Working Group. RFC 5071. https://tools.ietf.org/html/rfc5071. Informational.
  28. ↑ Patrick, Michael (January 2001). “DHCP Relay Agent Information Option”. 《IETF Documents》 (IETF). doi:10.17487/RFC3046. 2017년 7월 22일에 확인함.
  29. ↑ D. Jones; R. Woundy (April 2002). The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option. Network Working Group. RFC 3256. https://tools.ietf.org/html/rfc3256. Proposed Standard.
  30. ↑ K. Kinnear; M. Stapp; R. Johnson; J. Kumarasamy (April 2003). Link Selection sub-option for the Relay Agent Information Option for DHCPv4. Network Working Group. RFC 3527. https://tools.ietf.org/html/rfc3527. Proposed Standard.
  31. ↑ Droms, Ralph; Kinnear, Kim; Stapp, Mark; Volz, Bernie; Gonczi, Steve; Rabil, Greg; Dooley, Michael; Kapur, Arun (March 2003). DHCP Failover Protocol. IETF. I-D draft-ietf-dhc-failover-12. https://tools.ietf.org/html/draft-ietf-dhc-failover-12. Retrieved May 9, 2010.
  32. ↑ Weinberg, Neal (2018년 8월 14일). “Why DHCP's days might be numbered” (영어). 《Network World》. 2019년 8월 7일에 확인함.
  33. 1 2 3 Stapko, Timothy (2011). 《Practical Embedded Security: Building Secure Resource-Constrained Systems》. Newnes. 39쪽. ISBN 978-0-08-055131-9.
  34. ↑ Rountree, Derrick (2013). 《Windows 2012 Server Network Security: Securing Your Windows Network Systems and Infrastructure》. Newnes. 22쪽. ISBN 978-1-59749-965-1.
  35. ↑ Rooney, Timothy (2010). 《Introduction to IP Address Management》. John Wiley & Sons. 180쪽. ISBN 978-1-118-07380-3.
  36. 1 2 Golovanov (Kaspersky Labs), Sergey (June 2011). “TDSS loader now got "legs"”. 2021년 1월 25일에 원본 문서에서 보존된 문서.
  37. ↑ Hens, Francisco J.; Caballero, José M. (2008). 《Triple Play: Building the converged network for IP, VoIP and IPTV》. John Wiley & Sons. 239쪽. ISBN 978-0-470-75439-9.
  38. ↑ Ramirez, David H. (2008). 《IPTV Security: Protecting High-Value Digital Contents》. John Wiley & Sons. 55쪽. ISBN 978-0-470-72719-5.
  39. ↑ R. Droms; W. Arbaugh, eds. (June 2001). Authentication for DHCP Messages. Network Working Group. RFC 3118. https://tools.ietf.org/html/rfc3118. Proposed Standard.
  40. ↑ Lemon, Ted (April 2002). “Implementation of RFC 3118”.
  41. ↑ Golden, Philip; Dedieu, Hervé; Jacobsen, Krista S. (2007). 《Implementation and Applications of DSL Technology》. Taylor & Francis. 484쪽. ISBN 978-1-4200-1307-8.
  42. ↑ Rooney, Timothy (2010). 《Introduction to IP Address Management》. John Wiley & Sons. 181–182쪽. ISBN 978-1-118-07380-3.
  43. ↑ Copeland, Rebecca (2008). 《Converging NGN Wireline and Mobile 3G Networks with IMS》. Taylor & Francis. 142–143쪽. ISBN 978-1-4200-1378-8.
  44. ↑ Prasad, Ramjee; Mihovska, Albena (2009). 《New Horizons in Mobile and Wireless Communications: Networks, services, and applications》 2. Artech House. 339쪽. ISBN 978-1-60783-970-5.
  45. ↑ “Draft-pruss-DHCP-auth-DSL-07 - EAP Authentication Extensions for the Dynamic Host Configuration Protocol for Broadband”. 2015년 4월 3일에 원본 문서에서 보존된 문서. 2013년 12월 12일에 확인함.
  46. ↑ B. Volz (November 2004). Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options. Network Working Group. RFC 3942. https://tools.ietf.org/html/rfc3942. Proposed Standard. Updates RFC 2132.
  47. ↑ T. Lemon; B. Sommerfield (February 2006). Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4). Network Working Group. RFC 4361. https://tools.ietf.org/html/rfc4361. Proposed Standard. Updated by RFC 5494. Updates RFC 2131, 3315 and 2132.
  48. ↑ B. Aboba; J. Carlson; S. Cheshire (March 2006). Detecting Network Attachment in IPv4 (DNAv4). Network Working Group. RFC 4436. https://tools.ietf.org/html/rfc4436. Proposed Standard.
내용주
  1. ↑ 선택적인 클라이언트 동작으로서, DHCP 클라이언트가 이미 DHCP 서버의 IP 주소를 알고 있는 경우 DHCP 발견 및 요청 메시지를 포함하는 일부 브로드캐스트는 유니캐스트로 대체될 수 있다.[1]
  2. ↑ RFC에서는 클라이언트가 DHCPREQUEST 패킷을 재전송하기 전까지 T2까지 남은 시간의 절반을 기다릴 것을 요구한다.
  3. ↑ 이 제안은 두 서버가 서로 느슨하게 동기화된 상태를 유지하여 한 서버가 완전히 고장 나더라도 다른 서버가 임대 데이터베이스를 복구하고 운영을 계속할 수 있는 메커니즘을 제공했다. 사양의 길이와 복잡성으로 인해 표준으로 발표되지는 않았으나, 제안된 기술은 오픈 소스 및 여러 상용 구현체에서 널리 사용되고 있다.

외부 링크

[편집]
원본 주소 "https://ko.wikipedia.org/w/index.php?title=동적_호스트_구성_프로토콜&oldid=41726914"