IMT2000 3GPP - 동적 호스트 구성 프로토콜

Dynamic Host Configuration Protocol
"DHCP"는 여기로 리디렉션됩니다.기타 용도는 DHCP(동음이의)를 참조하십시오.
인터넷 프로토콜 모음
응용 계층
수송층
인터넷 계층
링크 계층

DHCP(Dynamic Host Configuration Protocol)는 IP(Internet Protocol) 네트워크에서 클라이언트-서버 아키텍처를 사용하여 네트워크에 연결된 장치에 IP 주소 및 기타 통신 매개 변수를 자동으로 할당하는 데 사용되는 네트워크 관리 프로토콜입니다.[1]

이 기술은 네트워크 장치를 수동으로 개별 구성할 필요가 없으며, 중앙에 설치된 네트워크 DHCP 서버와 각 컴퓨터 또는 장치에 프로토콜 스택의 클라이언트 인스턴스인 두 개의 네트워크 구성 요소로 구성됩니다.네트워크에 연결되면, 그리고 그 이후 주기적으로 클라이언트는 DHCP를 사용하여 서버에 일련의 파라미터를 요청합니다.

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

DHCP 서비스는 버전 6(IPv6)뿐만 아니라 인터넷 프로토콜 버전 4(IPv4)를 실행하는 네트워크에도 존재합니다.DHCP 프로토콜의 IPv6 버전을 일반적으로 DHCPv6라고 합니다.

역사

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

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

4년 후, (WPAD에 사용되는) DHCP INFORM 메시지 유형 및 기타 작은 변경 사항이 추가되었습니다.이 정의는 1997년부터 IPv4 네트워크 표준의 핵심으로 남아 있습니다.[8]

DHCPv6는 2003년에 처음 정의되었습니다.[9]이후 많은 RFC에서 업데이트를 거친 후 2018년에 정의가 바뀌었고,[10] 여기서 접두사 위임과 상태 비저장 주소 자동 구성이 병합되었습니다.

개요

IP(Internet Protocol)는 인터넷 상의 로컬 네트워크 내 및 로컬 네트워크 간에 장치가 통신하는 방법을 정의합니다.DHCP 서버는 로컬 네트워크에 있는 장치의 IP 설정을 관리할 수 있습니다. 예를 들어 IP 주소를 자동으로 동적으로 해당 장치에 할당합니다.[11]

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

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

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

동적할당
네트워크 관리자는 DHCP를 위한 IP 주소 범위를 예약하고 LAN의 각 DHCP 클라이언트는 네트워크 초기화 중에 DHCP 서버에 IP 주소를 요청하도록 구성됩니다.요청 및 허가 프로세스는 제어 가능한 기간의 리스 개념을 사용하므로 DHCP 서버가 갱신되지 않은 IP 주소를 회수한 다음 재할당할 수 있습니다.
자동할당
DHCP 서버는 관리자가 정의한 범위에서 요청 클라이언트에 IP 주소를 영구적으로 할당합니다.이는 동적 할당과 같지만 DHCP 서버는 과거 IP 주소 할당 테이블을 유지하여 클라이언트가 이전에 가지고 있던 것과 동일한 IP 주소를 우선적으로 클라이언트에 할당할 수 있습니다.
수동배정
이 방법은 정적 DHCP 할당, 고정 주소 할당, 예약, MAC/IP 주소 바인딩이라고도 다양하게 불립니다.관리자는 각 클라이언트에 대한 고유 식별자(클라이언트 ID 또는 MAC 주소)를 요청 클라이언트에 제공되는 IP 주소에 매핑합니다.DHCP 서버는 실패할 경우 다른 메서드로 폴백하도록 구성될 수 있습니다.

DHCP 서비스는 IPv4(Internet Protocol Version 4) 및 IPv6에 사용됩니다.IPv4와 IPv6에 대한 프로토콜의 세부사항은 별개의 프로토콜로 간주될 수 있을 정도로 충분히 다릅니다.[12]IPv6 작업의 경우 디바이스가 상태 비저장 주소 자동 구성을 사용할 수도 있습니다.IPv6 호스트는 로컬 네트워크 링크로 제한된 작업을 수행하기 위해 링크 로컬 주소 지정을 사용할 수도 있습니다.

작동

DHCP 클라이언트 기능에 따라 각 메시지는 브로드캐스트 또는 유니캐스트가 될 수 있습니다.[8]

DHCP는 UDP(User Datagram Protocol)를 사용하는 무연결 서비스 모델을 사용합니다.부트스트랩 프로토콜(BOOTP)과 동일한 두 개의 UDP 포트 번호로 구현됩니다.서버는 UDP 포트 번호 67을 수신하고 클라이언트는 UDP 포트 번호 68을 수신합니다.

DHCP 작업은 서버 검색, IP 리스 오퍼, IP 리스 요청 및 IP 리스 확인의 네 단계로 나뉩니다.이러한 단계는 종종 발견, 제안, 요청 및 확인을 위해 DORA라고 약칭됩니다.

DHCP 작업은 클라이언트가 요청을 브로드캐스트하는 것으로 시작됩니다.클라이언트와 서버가 서로 다른 브로드캐스트 도메인에 있는 경우 DHCP 도우미 또는 DHCP 릴레이 에이전트를 사용할 수 있습니다.기존 리스의 갱신을 요청하는 클라이언트는 UDP 유니캐스트를 통해 직접 통신할 수 있습니다. 클라이언트는 이미 설정된 IP 주소를 가지고 있기 때문입니다.또한 브로드캐스트 플래그(2바이트 플래그 필드에서 1비트)가 있으며, 여기서 다른 모든 비트는 예약되어 있으므로 0으로 설정됩니다. 클라이언트는 브로드캐스트 또는 유니캐스트의 경우 DHCPOFFER를 수신할 수 있는 방법(브로드캐스트 또는 유니캐스트)을 표시하는 데 사용할 수 있습니다. 0x8000, 유니캐스트의 경우 0x0000.[8]일반적으로 DHCPOFFER는 유니캐스트를 통해 전송됩니다.IP 주소가 구성되기 전에 유니캐스트 패킷을 허용할 수 없는 호스트의 경우 이 플래그를 사용하여 이 문제를 해결할 수 있습니다.

디스커버리

DHCP 클라이언트는 대상 주소 255.255.255(제한된 브로드캐스트) 또는 특정 서브넷 브로드캐스트 주소(방향 브로드캐스트)를 사용하여 네트워크 서브넷에서 DHCP DISCOVER 메시지를 브로드캐스트합니다.DHCP 클라이언트는 마지막으로 알려진 IP 주소를 요청할 수도 있습니다.클라이언트가 동일한 네트워크에 계속 연결되어 있는 경우, 서버는 요청을 승인할 수 있습니다.그렇지 않은 경우, 서버가 권한 있는 서버로 설정되었는지 여부에 따라 달라집니다.권한 있는 서버가 요청을 거부하여 클라이언트가 새 요청을 발행하게 됩니다.권한이 없는 서버는 단순히 요청을 무시하기 때문에 클라이언트가 요청을 만료하고 새 IP 주소를 요청하기 위해 구현에 의존하는 타임아웃이 발생합니다.

예를 들어, HTYPE이 1로 설정된 경우, 사용되는 매체를 이더넷으로 지정하려면 이더넷 주소(MAC 주소)가 6 옥텟 크기이므로 HLEN이 6으로 설정됩니다.CHADDR은 클라이언트가 사용하는 MAC 주소로 설정됩니다.일부 옵션도 설정되어 있습니다.

DHCP DISCOVER 메시지 예제

이더넷: source= sender의 MAC; destination=FF:FF:FF:FF:FF:FF

IP: source=0.0.0; destination=255.255.255
UDP: 소스 포트=68, 대상 포트=67

옥텟 0 옥텟 1 옥텟 2 옥텟 3
OP HTYPE HLEN 홉스
0x01 0x01 0x06 0x00
XID
0x3903F326
SECS Flags
0x0000 0x0000
CIADDR(클라이언트 IP 주소)
0x00000000
YIADDR(사용자 IP 주소)
0x00000000
SIADR (Server IP address)
0x00000000
GIADDR(게이트웨이 IP 주소)
0x00000000
CHADDR(클라이언트 하드웨어 주소)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 옥텟(0s) 또는 추가 옵션을 위한 오버플로 공간, BOOTP 레거시.
매직쿠키
0x63825363
DHCP 옵션
0x35010153:1 (DHCP Discover)
0x3204c0a8016450: 192.168.1.100 요청
0x370401030f0655 (파라미터 요청 목록):
  • 1(서브넷 마스크 요청),
  • 3(라우터),
  • 15(도메인 이름),
  • 6(도메인 네임 서버)
0xff 255 (엔드마크)

제공하다

DHCP 서버가 IP 주소 리스 요청인 DHCP DISCOVER 메시지를 클라이언트로부터 수신하면 DHCP 서버는 클라이언트에 대한 IP 주소를 예약하고 클라이언트에 DHCPOFFER 메시지를 전송하여 리스 제안을 합니다.이 메시지에는 클라이언트의 클라이언트 ID(전통적으로 MAC 주소), 서버가 제공하는 IP 주소, 서브넷 마스크, 임대 기간 및 제안을 수행하는 DHCP 서버의 IP 주소가 포함됩니다.DHCP 서버는 또한 기본 전송 계층의 하드웨어 수준 MAC 주소에 주목할 수 있습니다. 현재 RFC에 따르면 전송 계층 MAC 주소는 DHCP 패킷에 클라이언트 ID가 제공되지 않으면 사용될 수 있습니다.

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

DHCPOFFER 메시지 예제

이더넷: source= sender의 MAC; destination= 클라이언트 MAC 주소

IP: source=192.168.1.1; destination=192.168.1.100
UDP: 소스 포트=67, 대상 포트=68

옥텟 0 옥텟 1 옥텟 2 옥텟 3
OP HTYPE HLEN 홉스
0x02 0x01 0x06 0x00
XID
0x3903F326
SECS Flags
0x0000 0x0000
CIADDR(클라이언트 IP 주소)
0x00000000
YIADDR(사용자 IP 주소)
0xC0A80164(192.168.1.100)
SIADR (Server IP address)
0xC0A80101 (192.168.1.1)
GIADDR(게이트웨이 IP 주소)
0x00000000
CHADDR(클라이언트 하드웨어 주소)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 옥텟의 0초; BOOTP 레거시.
매직쿠키
0x63825363
DHCP 옵션
53:2 (DHCP 제공)
1 (subnet 마스크): 255.255.255.0
3(라우터): 192.168.1.1
51 (IP주소 임대시간) : 86400s (1일)
54 (DHCP 서버): 192.168.1.1
6(DNS 서버):
  • 9.7.10.15,
  • 9.7.10.16,
  • 9.7.10.18

부탁한다

DHCP 제안에 대한 응답으로, 클라이언트는 제안된 주소를 요청하는 [a]서버에 브로드캐스트되는 DHCPREQUEST 메시지로 응답합니다.클라이언트는 여러 서버에서 DHCP 제안을 받을 수 있지만, 한 개의 DHCP 제안만 수락합니다.IP 주소를 주장하기 전에 클라이언트는 제안된 IP 주소를 가진 다른 호스트가 네트워크에 존재하는지를 찾기 위해 ARP 요청을 브로드캐스트합니다.회신이 없는 경우 이 주소는 다른 호스트의 주소와 충돌하지 않으므로 자유롭게 사용할 수 있습니다.

클라이언트는 DHCPREQUEST 메시지에서 클라이언트가 제안을 선택한 서버를 나타내는 서버 식별 옵션을 전송해야 합니다.[8]: Section 3.1, Item 3 다른 DHCP 서버가 이 메시지를 수신하면 클라이언트에 제공한 모든 제안을 철회하고 제공된 IP 주소를 사용 가능한 주소 풀로 반환합니다.

DHCPREQUEST 메시지 예제

이더넷: source= sender의 MAC; destination=FF:FF:FF:FF:FF:FF

IP: source=0.0.0; destination=255.255.255;
UDP: 소스 포트=68, 대상 포트=67

옥텟 0 옥텟 1 옥텟 2 옥텟 3
OP HTYPE HLEN 홉스
0x01 0x01 0x06 0x00
XID
0x3903F326
SECS Flags
0x0000 0x0000
CIADDR(클라이언트 IP 주소)
0x00000000
YIADDR(사용자 IP 주소)
0x00000000
SIADR (Server IP address)
0xC0A80101 (192.168.1.1)
GIADDR(게이트웨이 IP 주소)
0x00000000
CHADDR(클라이언트 하드웨어 주소)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 옥텟의 0초; BOOTP 레거시.
매직쿠키
0x63825363
DHCP 옵션
53:3 (DHCP 요청)
50: 192.168.1.100 요청됨
54 (DHCP 서버): 192.168.1.1

확인

DHCP 서버가 클라이언트로부터 DHCPREQUEST 메시지를 수신하면 구성 프로세스가 마지막 단계로 들어갑니다.확인 단계에서는 DHCPACK 패킷을 클라이언트로 전송합니다.이 패킷에는 리스 기간과 클라이언트가 요청했을 수 있는 기타 구성 정보가 포함됩니다.이 시점에서 IP 구성 프로세스가 완료됩니다.

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

클라이언트가 IP 주소를 얻은 후에는 새로 수신한 주소(예: ARP Address Resolution Protocol)를[8]: sec. 2.2 탐색하여 DHCP 서버의 주소 풀이 중복되어 발생하는 주소 충돌을 방지해야 합니다.이 시도가 해당 주소를 사용하는 다른 컴퓨터를 찾으면 해당 컴퓨터는 DHCPDECLINE(방송)을 서버로 전송해야 합니다.

DHCPACK 메시지 예시

이더넷: source= sender의 MAC; destination= 클라이언트의 MAC

IP: source=192.168.1.1; destination=192.168.1.100
UDP: 소스 포트=67, 대상 포트=68

옥텟 0 옥텟 1 옥텟 2 옥텟 3
OP HTYPE HLEN 홉스
0x02 0x01 0x06 0x00
XID
0x3903F326
SECS Flags
0x0000 0x0000
CIADDR(클라이언트 IP 주소)
0x00000000
YIADDR(사용자 IP 주소)
0xC0A80164(192.168.1.100)
SIADR (Server IP address)
0xC0A80101 (192.168.1.1)
GIADDR(릴레이에 의해 스위칭되는 게이트웨이 IP 주소)
0x00000000
CHADDR(클라이언트 하드웨어 주소)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 옥텟 0s. BOOTP 레거시
매직쿠키
0x63825363
DHCP 옵션
53:5 (DHCP ACK)
1 (subnet 마스크): 255.255.255.0
3(라우터): 192.168.1.1
51 (IP주소 임대시간) : 86400s (1일)
54 (DHCP 서버): 192.168.1.1
6(DNS 서버):
  • 9.7.10.15,
  • 9.7.10.16,
  • 9.7.10.18

정보

DHCP 클라이언트는 원래 DHCPOFFER와 함께 전송된 서버보다 더 많은 정보를 요청할 수 있습니다.클라이언트는 특정 응용프로그램에 대한 반복 데이터를 요청할 수도 있습니다.예를 들어 브라우저에서는 DHCP Information을 사용하여 WPAD를 통해 웹 프록시 설정을 가져옵니다.

해제

클라이언트는 DHCP 정보를 해제하도록 DHCP 서버에 요청을 보내고 클라이언트는 해당 IP 주소를 비활성화합니다.일반적으로 클라이언트 장치는 사용자가 언제 네트워크에서 플러그를 뽑을 수 있는지 알 수 없으므로 프로토콜은 DHCP 릴리스 전송을 의무화하지 않습니다.

클라이언트 구성 매개변수

DHCP 서버는 클라이언트에 선택적 구성 매개변수를 제공할 수 있습니다.RFC 2132는 IANA(Internet Assigned Numbers Authority) - DHCP 및 BOOTP PARAMETAR에 의해 정의된 사용 가능한 DHCP 옵션에 대해 설명합니다.[13]

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

옵션들

옵션은 다양한 길이의 옥텟 문자열입니다.이를 Type-length-value 인코딩이라고 합니다.첫 번째 옥텟은 옵션 코드이고, 두 번째 옥텟은 다음 옥텟의 수이고 나머지 옥텟은 코드에 종속됩니다.예를 들어, 제안에 대한 DHCP 메시지 유형 옵션은 0x35, 0x01, 0x02로 나타나는데, 여기서 0x35는 "DHCP 메시지 유형"의 코드 53이고, 0x01은 한 옥텟이 뒤따른다는 것을 의미하며, 0x02는 "제안" 값입니다.

다음 표에는 사용 가능한 DHCP 옵션이 나와 있습니다.[14][13]

RFC 1497 (BOOTP 벤더 정보 확장) 벤더 확장[14]: Section 3
코드 이름. 길이 메모들
0 패드 0 옥텟 단어 경계에 정렬되도록 다른 옵션을 패드하는 데 사용할 수 있습니다. 길이 바이트 뒤에 나타나지 않습니다.
1 서브넷 마스크 4 옥텟 RFC 950에 따른 클라이언트의 서브넷 마스크.서브넷 마스크와 라우터 옵션(옵션 3)이 모두 포함되어 있는 경우 서브넷 마스크 옵션이 첫 번째여야 합니다.
2 시간 간격띄우기 4 옥텟 UTC(Coordinated Universal Time)에서 클라이언트 서브넷의 오프셋(초)입니다.오프셋은 2의 보 32비트 정수로 표시됩니다.양의 오프셋은 자오선 0의 동쪽 위치를 나타내고 음의 오프셋은 자오선 0의 서쪽 위치를 나타냅니다.
3 라우터 4옥텟의 배수 사용 가능한 라우터는 기본 설정 순서대로 나열되어야 합니다.
4 타임서버 4옥텟의 배수 동기화할 수 있는 Time Protocol 서버가 기본 설정 순서에 따라 나열되어야 합니다.
5 네임서버 4옥텟의 배수 사용 가능한 IEN 116 네임 서버, 선호하는 순서대로 나열되어야 함
6 도메인 네임 서버 4옥텟의 배수 사용 가능한 DNS 서버가 기본 설정 순서대로 나열되어야 합니다.
7 로그서버 4옥텟의 배수 사용 가능한 로그 서버를 기본 설정 순서대로 나열해야 합니다.
8 쿠키서버 4옥텟의 배수 이 경우 쿠키는 "포춘 쿠키" 또는 "오늘의 인용문"을 의미하며, 대형 컴퓨터에서 로그온 프로세스의 일부로 전송되는 인색하거나 유머러스한 일화입니다. 웹 사이트에서 전송되는 쿠키와는 아무런 관련이 없습니다.
9 LPR 서버 4옥텟의 배수 클라이언트에서 사용할 수 있는 Line Printer Daemon 프로토콜 서버 목록이 기본 설정 순서대로 나열되어야 합니다.
10 임프레션 서버 4옥텟의 배수 클라이언트가 사용할 수 있는 Impect 서버 목록이 기본 설정 순서대로 나열되어야 합니다.
11 자원위치서버 4옥텟의 배수 클라이언트가 사용할 수 있는 리소스 위치 프로토콜 서버 목록이 기본 설정 순서대로 나열되어야 합니다.
12 호스트명 최소 1 옥텟 클라이언트의 이름입니다.이름은 로컬 도메인 이름으로 한정할 수 있습니다.
13 부팅 파일 크기 옥텟 2개 부팅 이미지의 길이(512B 블록)
14 메리트덤프파일 최소 1 옥텟 충돌 덤프를 저장해야 하는 경로
15 도메인이름 최소 1 옥텟
16 스왑서버 4 옥텟
17 루트 경로 최소 1 옥텟
18 확장 경로 최소 1 옥텟
255 끝. 0 옥텟 공급업체 옵션 필드의 끝을 표시하는 데 사용됩니다.
호스트당[14]: Section 4 IP 계층 매개 변수
코드 이름. 길이 메모들
19 IP 전달 활성화/비활성화 옥텟 1개
20 로컬이 아닌 소스 라우팅 사용/사용 안 함 옥텟 1개
21 정책필터 8옥텟의 배수
22 최대 데이터그램 재조립 크기 옥텟 2개
23 기본 IP 존속 기간 옥텟 1개
24 경로 MTU 만료 시간 초과 4 옥텟
25 경로 MTU 고원 테이블 2 옥텟의 배수
IMT2000[14]: Section 5 3GPP - 인터페이스
코드 이름. 길이 메모들
26 인터페이스 MTU 옥텟 2개
27 모든 서브넷이 로컬임 옥텟 1개
28 방송주소 4 옥텟
29 마스크 검색 수행 옥텟 1개
30 마스크공급자 옥텟 1개
31 라우터 검색 수행 옥텟 1개
32 라우터 요청 주소 4 옥텟
33 정적 경로 8옥텟의 배수 목적지/라우터 쌍 목록
인터페이스당[14]: Section 6 링크 계층 파라미터
코드 이름. 길이 메모들
34 트레일러 캡슐화 옵션 옥텟 1개
35 ARP 캐시 시간 초과 4 옥텟
36 이더넷 캡슐화 옥텟 1개
TCP 매개[14]: Section 7 변수
코드 이름. 길이 메모들
37 TCP 기본 TTL 옥텟 1개
38 TCP keep alive 간격 4 옥텟
39 TCP keep alive 가비지 옥텟 1개
애플리케이션 및 서비스 파라미터[14]: Section 8
코드 이름. 길이 메모들
40 네트워크 정보 서비스 도메인 최소 1 옥텟
41 네트워크 정보 서버 4옥텟의 배수
42 NTP(Network Time Protocol) 서버 4옥텟의 배수
43 벤더별 정보 최소 1 옥텟
44 NetBIOS over TCP/IP 네임 서버 4옥텟의 배수
45 NetBIOS over TCP/IP 데이터그램 배포 서버 4옥텟의 배수
46 TCP/IP 노드 유형을 통한 NetBIOS 옥텟 1개
47 TCP/IP 범위를 통한 NetBIOS 최소 1 옥텟
48 X 윈도우 시스템 폰트 서버 4옥텟의 배수
49 X Window System 디스플레이 매니저 4옥텟의 배수
64 네트워크 정보 서비스+ 도메인 최소 1 옥텟
65 네트워크 정보 서비스 + 서버 4옥텟의 배수
68 모바일 IP 홈 에이전트 4옥텟의 배수
69 SMTP(Simple Mail Transfer Protocol) 서버 4옥텟의 배수
70 POP3(우체국 프로토콜) 서버 4옥텟의 배수
71 NNTP(Network News Transfer Protocol 4옥텟의 배수
72 WWW(World Wide Web) 서버 기본값 4옥텟의 배수
73 기본 핑거 프로토콜 서버 4옥텟의 배수
74 기본 IRC(Internet Relay Chat) 서버 4옥텟의 배수
75 스트리트토크 서버 4옥텟의 배수
76 STDA(StreetTalk Directory Assistance) 서버 4옥텟의 배수
DHCP 확장[14]: Section 9
코드 이름. 길이 메모들
50 요청한 IP 주소 4 옥텟
51 IP주소리스시간 4 옥텟
52 옵션오버로드 옥텟 1개
53 DHCP 메시지 유형 옥텟 1개
54 서버 식별자 4 옥텟
55 파라미터요청목록 최소 1 옥텟
56 메세지 최소 1 옥텟
57 최대 DHCP 메시지 크기 옥텟 2개
58 갱신(T1) 시간값 4 옥텟
59 재결합(T2) 시간값 4 옥텟
60 벤더클래스 식별자 최소 1 옥텟
61 클라이언트 식별자 최소 2 옥텟
66 TFTP 서버 이름 최소 1 옥텟
67 부트파일명 최소 1 옥텟

DHCP 메시지 유형

이 표에는 RFC 2132, RFC 3203,[15] RFC 4388,[16] RFC 6926[17] 및 RFC 7724에 문서화된 DHCP 메시지 유형이 나열되어 있습니다.[18]이 코드들은 위의 표에 나와 있는 DHCP 확장자 53의 값입니다.

DHCP 메시지 유형
코드 이름. 길이 RFC
1 DHCP DISCOVER 옥텟 1개 rfc2132[14]: Section 9.6
2 DHCP 제공 옥텟 1개 rfc2132[14]: Section 9.6
3 DHC 프리퀘스트 옥텟 1개 rfc2132[14]: Section 9.6
4 DHCP 감소 옥텟 1개 rfc2132[14]: Section 9.6
5 DHCPACK 옥텟 1개 rfc2132[14]: Section 9.6
6 DHCPNAK 옥텟 1개 rfc2132[14]: Section 9.6
7 DHC Prelease 옥텟 1개 rfc2132[14]: Section 9.6
8 DHCP INFORM 옥텟 1개 rfc2132[14]: Section 9.6
9 DHCPFORCHRENEW 옥텟 1개 rfc3203[15]: Section 4
10 DHCP 리스 쿼리 옥텟 1개 rfc4388[16]: Section 6.1
11 DHCP 리스 할당되지 않음 옥텟 1개 rfc4388[16]: Section 6.1
12 DHCPLEASE 알 수 없음 옥텟 1개 rfc4388[16]: Section 6.1
13 DHCPLEASE ACTIVE 옥텟 1개 rfc4388[16]: Section 6.1
14 DHCP 대량 임대 쿼리 옥텟 1개 rfc6926[17]: Section 6.2.1
15 DHCP 리스 쿼리 완료 옥텟 1개 rfc6926[17]: Section 6.2.1
16 DHCPACTIVE 리스 쿼리 옥텟 1개 rfc7724[18]: Section 5.2.1
17 DHCPREASE 쿼리 상태 옥텟 1개 rfc7724[18]: Section 5.2.1
18 DHCPTLS 옥텟 1개 rfc7724[18]: Section 5.2.1

클라이언트 공급업체 식별

DHCP 클라이언트의 벤더와 기능을 식별하기 위한 옵션이 있습니다.정보는 DHCP 클라이언트의 공급업체에서 지정한 의미를 가진 문자 또는 옥텟의 가변 길이 문자열입니다.DHCP 클라이언트가 특정 유형의 하드웨어 또는 펌웨어를 사용하고 있음을 서버와 통신할 수 있는 한 가지 방법은 VCI(Vendor Class Identifier)(옵션 60)라는 DHCP 요청에 값을 설정하는 것입니다.

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

클라이언트가 VCI를 설정하면 DHCP 서버가 클라이언트 시스템을 구별하고 클라이언트 시스템으로부터의 요청을 적절하게 처리할 수 있습니다.

기타 내선번호

문서화된 DHCP 옵션
코드 이름. 길이 RFC
82 릴레이 에이전트 정보 최소 2 옥텟 RFC 3046[20]
85 NDS(Novell Directory Service) 서버 최소 4 옥텟, 배수 4 옥텟 RFC 2241[21]: Section 2
86 NDS 트리명 변수 RFC 2241[21]: Section 3
87 NDS 컨텍스트 변수 RFC 2241[21]: Section 4
100 표준 시간대, POSIX 스타일 변수 RFC 4833[22]
101 표준 시간대, tz 데이터베이스 스타일 변수 RFC 4833[22]
114 DHCP Captive-Portal 변수 RFC 8910[23]
119 도메인 검색 변수 RFC 3397[24]
121 클래스 없는 정적 경로 변수 RFC 3442[25]
209 구성 파일 변수 RFC 5071[26]
210 경로 접두사 변수 RFC 5071[26]
211 재부팅 시간 변수 RFC 5071[26]

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

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

릴레이 에이전트 하위 옵션
코드 이름. 길이 RFC
1 에이전트 회로 ID 최소 1 옥텟 RFC 3046[20]
2 에이전트 원격 ID 최소 1 옥텟 RFC 3046[20]
4 IMT2000 3GPP - DOCSIS 디바이스 클래스 4 옥텟 RFC 3256[27]

릴레이

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

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

아직 IP 주소가 없을 때 클라이언트의 IP 스택 구현에서 유니캐스트 패킷을 허용하지 않는 경우, 클라이언트는 DHCP DISCOVER 패킷을 전송할 때 FLAGS 필드에 브로드캐스트 비트를 설정할 수 있습니다.릴레이 에이전트는 255.255.255 브로드캐스트 IP 주소(및 클라이언트 MAC 주소)를 사용하여 클라이언트에 서버의 DHCPOFFER를 알립니다.

릴레이 에이전트와 DHCP 서버 간의 통신은 일반적으로 67의 소스 및 대상 UDP 포트를 모두 사용합니다.

클라이언트 상태

RFC 2131의 그림 5를 기반으로 한 단순화된 DHCP 클라이언트 상태 전이 다이어그램.

DHCP 클라이언트는 서버로부터 다음과 같은 메시지를 수신할 수 있습니다.[8]: Section 4.4

  • DHCP 제공
  • DHCPACK
  • DHCPNAK

클라이언트는 클라이언트가 보낸 메시지에 서버가 응답하는 방식에 따라 DHCP 상태를 이동합니다.

신뢰성.

DHCP는 주기적 갱신, 재바인딩,[8]: Section 4.4.5 페일오버 등 여러 가지 방법으로 안정성을 보장합니다.DHCP 클라이언트는 일정 기간 지속되는 리스를 할당받습니다.고객은 임대 기간의 절반이 만료되면 임대 갱신을 시도하기 시작합니다.[8]: Section 4.4.5 Paragraph 3 이들은 원래 리스를 허가한 DHCP 서버에 유니캐스트 DHCPREQUEST 메시지를 전송함으로써 이 작업을 수행합니다.서버가 다운되었거나 연결할 수 없는 경우, 해당 서버는 DHCPREQUEST에 응답하지 못합니다.그러나 이 경우 클라이언트는 때때로 DHCPREQUEST를 반복하므로 DHCP 서버가 다시 작동하거나 다시 연결할 수 있게 되면 DHCP 클라이언트는 해당 서버에 성공적으로 연결하고 리스를 갱신합니다.[8]: Section 4.4.5 Paragraph 8 [b]

DHCP 서버에 장시간 연결할 수 없는 경우 DHCP 클라이언트는 DHCPREQUEST를 유니캐스트하는 대신 브로드캐스트하여 재결합을 시도합니다.[8]: Section 4.4.5 Paragraph 5 브로드캐스트되기 때문에 DHCPREQUEST 메시지는 사용 가능한 모든 DHCP 서버에 도달합니다.다른 DHCP 서버가 리스를 갱신할 수 있는 경우에는 이 시점에서 갱신합니다.

바인딩이 작동하려면 클라이언트가 백업 DHCP 서버에 성공적으로 연결할 때 해당 서버에 클라이언트 바인딩에 대한 정확한 정보가 있어야 합니다.두 서버 간에 정확한 바인딩 정보를 유지하는 것은 복잡한 문제입니다. 두 서버가 동일한 리스 데이터베이스를 업데이트할 수 있는 경우 독립적인 서버에서 업데이트 간의 충돌을 방지할 수 있는 메커니즘이 있어야 합니다.인터넷 엔지니어링 태스크 포스에 내결함성 DHCP 서버를 구현하기 위한 제안서가 제출되었지만 공식화되지는 않았습니다.[28][c]

재바인딩에 실패하면 리스가 만료됩니다.리스가 만료되면 클라이언트는 리스에서 해당 리스에 부여된 IP 주소 사용을 중지해야 합니다.[8]: Section 4.4.5 Paragraph 9 그러면 처음부터 DHCP 프로세스를 브로드캐스트하여 다시 시작합니다.DHCPDISCOVER메세지.임대 기간이 만료되었기 때문에 제공되는 모든 IP 주소를 승인합니다.새 IP 주소가 있으면(다른 DHCP 서버에서 온 것으로 추정됨) 다시 한 번 네트워크를 사용할 수 있습니다.그러나 IP 주소가 변경되었기 때문에 진행 중인 연결이 끊어집니다.

IPv6 네트워크

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

보안.

참고 항목: DHCP 스누핑

기본 DHCP에는 인증 메커니즘이 포함되어 있지 않습니다.[30]: sec. 7 이 때문에 다양한 공격에 취약합니다.이러한 공격은 크게 세 가지로 나뉩니다.[8]: sec. 7

  • 클라이언트에 잘못된 정보를 제공하는 무단 DHCP 서버.
  • 권한이 없는 클라이언트가 리소스에 액세스할 수 있습니다.
  • 악의적인 DHCP 클라이언트의 리소스 소진 공격입니다.

클라이언트는 DHCP 서버의 ID를 확인할 방법이 없기 때문에 네트워크에서 승인되지 않은 DHCP 서버(일반적으로 "로그 DHCP"라고 함)가 작동하여 DHCP 클라이언트에 잘못된 정보를 제공할 수 있습니다.[31]이는 서비스 거부 공격으로 작용하여 클라이언트가 네트워크 연결에 액세스하지 못하도록 하거나 [32]중간자 공격으로 작용할 수 있습니다.[33]DHCP 서버는 DHCP 클라이언트에게 하나 이상의 DNS 서버의 IP 주소와 같은 서버 IP 주소를 제공하므로 [8]: sec. 7 공격자는 DHCP 클라이언트가 자신의 DNS 서버를 통해 DNS 조회를 수행하도록 유인할 수 있으므로 클라이언트의 DNS 쿼리에 대한 자체 응답을 제공할 수 있습니다.[34]이를 통해 공격자는 자신을 통해 네트워크 트래픽을 리디렉션하여 자신이 접촉하는 클라이언트와 네트워크 서버 간의 연결을 도청하거나 단순히 해당 네트워크 서버를 자신의 네트워크 서버로 교체할 수 있습니다.[34]

DHCP 서버에는 클라이언트를 인증하는 보안 메커니즘이 없기 때문에 클라이언트는 다른 DHCP 클라이언트에 속한 클라이언트 식별자와 같은 자격 증명을 표시하여 IP 주소에 무단으로 액세스할 수 있습니다.[31]이를 통해 DHCP 클라이언트는 주소를 요청할 때마다 새로운 자격 증명을 제시함으로써 특정 네트워크 링크에서 사용 가능한 모든 IP 주소를 사용할 수 있으므로 다른 DHCP 클라이언트가 서비스를 받을 수 없습니다.[31]

DHCP는 이러한 문제를 완화하기 위한 몇 가지 메커니즘을 제공합니다.릴레이 에이전트 정보 옵션 프로토콜 확장[30](일반적으로 업계에서는 실제 번호로 Option 82로[35][36] 표시됨)을 사용하면 네트워크 운영자가 DHCP 메시지에 태그를 부착할 수 있으며 이러한 메시지가 네트워크 운영자의 신뢰할 수 있는 네트워크에 도착할 때 네트워크 운영자가 DHCP 메시지에 태그를 부착할 수 있습니다.그러면 이 태그는 네트워크 리소스에 대한 클라이언트의 액세스를 제어하기 위한 권한 부여 토큰으로 사용됩니다.클라이언트가 릴레이 에이전트의 네트워크 업스트림에 액세스하지 못하기 때문에 인증이 없다고 해서 DHCP 서버 운영자가 인증 토큰에 의존하는 것을 막지는 못합니다.[30]: sec. 7

또 다른 확장인 Authentication for DHCP Messages[37](RFC 3118)는 DHCP 메시지를 인증하는 메커니즘을 제공합니다.2002년 현재, 이 확장은 많은 수의 DHCP 클라이언트에 대한 키 관리 문제 때문에 널리 채택되지 않았습니다.[38]2007년 DSL 기술에 관한 책은 다음과 같이 언급했습니다.

[T]RFC 3118에 의해 제안된 보안 조치에 대해 확인된 수많은 보안 취약점이 여기에 있습니다.이러한 사실은 802.1x의 도입과 함께 인증된 DHCP의 배포 및 수용 속도가 느려졌으며, 널리 배포된 적은 없습니다.[39]

2010년 저서는 다음과 같이 언급하고 있습니다.

[T]DHCP Authentication의 구현은 거의 없었습니다.해시 계산으로 인한 키 관리 및 처리 지연 문제는 인지된 이점을 지불하기에는 너무 큰 비용이 드는 것으로 여겨졌습니다.[40]

2008년의 아키텍처 제안에는 802.1x 또는 PANA(이 둘 다 EAP 전송)를 사용하여 DHCP 요청을 인증하는 것이 포함됩니다.[41]EAP를 DHCP 자체에 포함시키기 위한 IETF 제안이 이루어졌는데,[42] 이는 IETF 초안 수준을 넘어서 진행되지 않은 것으로 보이며, 그 중 마지막은 2010년으로 거슬러 올라갑니다.[43]

IETF 표준문서

  • IMT2000 3GPP - RFC 2131 동적 호스트 구성 프로토콜
  • RFC 2132, DHCP 옵션 및 BOOTP 벤더 확장
  • RFC 3046, DHCP 릴레이 에이전트 정보 옵션
  • RFC 3397, DHCP 도메인 검색 옵션
  • RFC 3942, DHCPv4 옵션 재분류
  • IMT-2000 3GPP-RFC 4242, IPv6용 동적 호스트 구성 프로토콜
  • IMT-2000 3GPP-DHCPv4를 위한 노드-특정 클라이언트 식별자
  • RFC 4436, IPv4에서의 네트워크 부착 검출(DNAv4)
  • IMT2000 3GPP - DHCP 버전 4를 위한 클래스리스 정적 경로 옵션
  • RFC 3203, DHCP 재구성 확장
  • IMT-2000 3GPP-RFC 4388, DHCP 리스쿼리
  • RFC 6926, DHCPv4 대량 임대 쿼리
  • RFC 7724, Active DHCPv4 리스 쿼리

참고 항목

메모들

  1. ^ a b 선택적 클라이언트 동작으로 DHCP 검색 및 요청 메시지를 전송하는 브로드캐스트와 같은 일부 브로드캐스트는 DHCP 클라이언트가 이미 DHCP 서버의 IP 주소를 알고 있는 경우 유니캐스트로 대체될 수 있습니다.[8]
  2. ^ RFC는 클라이언트가 DHCPREQUEST 패킷을 재전송하기 전에 T2까지 남은 시간의 절반을 대기하도록 요구합니다.
  3. ^ 이 제안은 두 서버가 느슨하게 서로 동기화된 상태를 유지할 수 있는 메커니즘을 제공하여 한 서버에 전체 장애가 발생한 경우에도 다른 서버가 리스 데이터베이스를 복구하고 계속 운영할 수 있도록 했습니다.규격의 길이와 복잡성 때문에 표준으로 발표된 적은 없지만, 제안서에 설명된 기술은 오픈 소스 및 여러 상업적 구현과 함께 널리 사용되고 있습니다.

참고문헌

  1. ^ Gillis, Alexander S. "What is DHCP (Dynamic Host Configuration Protocol)?". TechTarget: SearchNetworking. Retrieved 19 February 2021.
  2. ^ Peterson, Larry L.; Davie, Bruce S. (2011). Computer Networks: A Systems Approach (5th ed.). Elsevier. ISBN 978-0123850607. Retrieved March 21, 2019.
  3. ^ R. Finlayson; T. Mann; J. Mogul; M. Theimer (June 1984). A Reverse Address Resolution Protocol. Network Working Group. doi:10.17487/RFC0903. STD 38. RFC 903. 인터넷 표준.
  4. ^ Bill Croft; John Gilmore (September 1985). BOOTSTRAP PROTOCOL (BOOTP). Network Working Group. doi:10.17487/RFC0951. RFC 951. 표준 초안.RFC 1395, 1497, 1532, 1542 및 5494에 의해 업데이트되었습니다.
  5. ^ R. Droms (October 1993). Dynamic Host Configuration Protocol. Network Working Group. doi:10.17487/RFC1531. RFC 1531. 구식입니다.편집 프로세스의 오류로 인해 RFC 1541에 의해 폐지되었습니다.
  6. ^ R. Droms (October 1993). Dynamic Host Configuration Protocol. Network Working Group. doi:10.17487/RFC1541. RFC 1541. 구식입니다.RFC 2131에 의해 폐지되었습니다.RFC 1531을 폐지합니다.
  7. ^ Network+ Certification 2006 Microsoft Press 발행.
  8. ^ a b c d e f g h i j k l m n o R. Droms (March 1997). Dynamic Host Configuration Protocol. Network Working Group. doi:10.17487/RFC2131. RFC 2131. 표준 초안.RFC 1541을 폐지합니다.RFC 3396, 4361, 5494 및 6842에 의해 업데이트되었습니다.
  9. ^ 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. doi:10.17487/RFC3315. RFC 3315. 구식입니다.RFC 8415에 의해 폐지되었습니다.RFC 4361, 5494, 6221, 6422, 6644, 7083, 7283, 7227 및 7550에 의해 업데이트되었습니다.
  10. ^ 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). IETF. doi:10.17487/RFC8415. ISSN 2070-1721. RFC 8415. 제안된 표준.RFC 3315, 3633, 3736, 4242, 7083, 7283 및 7550 폐지.
  11. ^ "DHCP - Dynamic Host Configuration Protocol".
  12. ^ Droms, Ralph; Lemon, Ted (2003). The DHCP Handbook. SAMS Publishing. p. 436. ISBN 978-0-672-32327-0.
  13. ^ a b "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters". iana.org. Retrieved 2018-10-16.
  14. ^ a b c d e f g h i j k l m n o p S. Alexander; R. Droms (March 1997). DHCP Options and BOOTP Vendor Extensions. Network Working Group. doi:10.17487/RFC2132. RFC 2132. 표준 초안.RFC 1533을 폐지합니다.RFC 3442, 3942, 4361, 4833 및 5494에 의해 업데이트되었습니다.
  15. ^ a b T'joens, Yves; De Schrijver, Peter (December 2001). DHCP reconfigure extension. IETF. doi:10.17487/RFC3203. RFC 3203. Retrieved November 13, 2020.
  16. ^ a b c d e Woundy, Rich; Kinnear, Kim (February 2006). Dynamic Host Configuration Protocol (DHCP) Leasequery. IETF. doi:10.17487/RFC4388. RFC 4388. Retrieved November 13, 2020.
  17. ^ a b c Kinnear, Kim; Stapp, Mark; Rao, D.T.V Ramakrishna; Joshi, Bharat; Russell, Neil; Kurapati, Pavan; Volz, Bernie (April 2013). DHCPv4 Bulk Leasequery. IETF. doi:10.17487/RFC6926. RFC 6926. Retrieved November 13, 2020.
  18. ^ a b c d Kinnear, Kim; Stapp, Mark; Volz, Bernie; Russell, Neil (December 2015). Active DHCPv4 Lease Query. IETF. doi:10.17487/RFC7724. RFC 7724. Retrieved November 13, 2020.
  19. ^ "Aruba DHCP Option 60". 7 October 2020.
  20. ^ a b c d Patrick, Michael (January 2001). "DHCP Relay Agent Information Option". IETF Documents. IETF. doi:10.17487/RFC3046. Retrieved 22 July 2017.
  21. ^ a b c Provan, Don (November 1997). "RFC 2241 – DHCP Options for Novell Directory Services". IETF Documents. IETF. doi:10.17487/RFC3256. Retrieved 23 July 2017.
  22. ^ a b Lear, E.; Eggert, P. (April 2007). "Timezone Options for DHCP". IETF Documents. IETF. doi:10.17487/RFC4833. Retrieved 28 June 2018.
  23. ^ Kumari, Warren (September 2020). "RFC 8910 - Captive-Portal Identification in DHCP and Router Advertisements (RAs)". ietf.org. IETF. Retrieved 25 March 2021.
  24. ^ Bernard, Aboba; Stuart, Cheshire (November 2002). "RFC 3397 – Dynamic Host Configuration Protocol (DHCP) Domain Search Option". IETF Documents. IETF. doi:10.17487/RFC3397. Retrieved 22 July 2017.
  25. ^ Lemon, T.; Cheshire, S.; Volz, B. (2002). "RFC 3442". doi:10.17487/RFC3442. {{cite journal}}:저널 요구사항 인용 journal=(도움말)
  26. ^ a b c Hankins, David (December 2007). "RFC 5071 - Dynamic Host Configuration Protocol Options Used by PXELINUX". ietf.org. IETF. doi:10.17487/RFC5071. Retrieved 25 March 2021.
  27. ^ Doug, Jones; Rich, Woundy (April 2002). "RFC 3256 – The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option". IETF Documents. IETF. doi:10.17487/RFC3256. Retrieved 23 July 2017.
  28. ^ 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. Retrieved May 9, 2010.
  29. ^ Weinberg, Neal (2018-08-14). "Why DHCP's days might be numbered". Network World. Retrieved 2019-08-07.
  30. ^ a b c M. Patrick (January 2001). DHCP Relay Agent Information Option. Network Working Group. doi:10.17487/RFC3046. RFC 3046. 제안된 표준.RFC 6607에 의해 업데이트되었습니다.
  31. ^ a b c Stapko, Timothy (2011). Practical Embedded Security: Building Secure Resource-Constrained Systems. Newnes. p. 39. ISBN 978-0-08-055131-9.
  32. ^ Rountree, Derrick (2013). Windows 2012 Server Network Security: Securing Your Windows Network Systems and Infrastructure. Newnes. p. 22. ISBN 978-1-59749-965-1.
  33. ^ Rooney, Timothy (2010). Introduction to IP Address Management. John Wiley & Sons. p. 180. ISBN 978-1-118-07380-3.
  34. ^ a b Golovanov (Kaspersky Labs), Sergey (June 2011). "TDSS loader now got "legs"". Archived from the original on 25 January 2021.
  35. ^ Hens, Francisco J.; Caballero, José M. (2008). Triple Play: Building the converged network for IP, VoIP and IPTV. John Wiley & Sons. p. 239. ISBN 978-0-470-75439-9.
  36. ^ Ramirez, David H. (2008). IPTV Security: Protecting High-Value Digital Contents. John Wiley & Sons. p. 55. ISBN 978-0-470-72719-5.
  37. ^ R. Droms; W. Arbaugh, eds. (June 2001). Authentication for DHCP Messages. Network Working Group. doi:10.17487/RFC3118. RFC 3118. 제안된 표준.
  38. ^ Lemon, Ted (April 2002). "Implementation of RFC 3118".
  39. ^ Golden, Philip; Dedieu, Hervé; Jacobsen, Krista S. (2007). Implementation and Applications of DSL Technology. Taylor & Francis. p. 484. ISBN 978-1-4200-1307-8.
  40. ^ Rooney, Timothy (2010). Introduction to IP Address Management. John Wiley & Sons. pp. 181–182. ISBN 978-1-118-07380-3.
  41. ^ Copeland, Rebecca (2008). Converging NGN Wireline and Mobile 3G Networks with IMS. Taylor & Francis. pp. 142–143. ISBN 978-1-4200-1378-8.
  42. ^ Prasad, Ramjee; Mihovska, Albena (2009). New Horizons in Mobile and Wireless Communications: Networks, services, and applications. Vol. 2. Artech House. p. 339. ISBN 978-1-60783-970-5.
  43. ^ "Draft-pruss-DHCP-auth-DSL-07 - EAP Authentication Extensions for the Dynamic Host Configuration Protocol for Broadband". Archived from the original on 2015-04-03. Retrieved 2013-12-12.

외부 링크