태그: DHCP

CCNA Study – DHCP

 

DHCP (Dynamic Host Configuration Protocol)는 호스트의 네트워크 설정을 쉽게 하기 위하여 개발된 프로토콜이다.

이에 앞서 RARP라는 자동 IPv4 할당 프로토콜이 있었지만, RARP는 오로지 IP만을 정적(Static)으로 할당받을 수 있었기에 디폴트 게이트웨이, 서브넷 마스크, DNS 서버 주소 등의 통신에 필요한 추가적인 정보를 제공받을 수 있는 새로운 방법이 필요했고, IETF는 RFC 951에서 BOOTP를 정의하여 이 문제를 해결하였다.

그러나 BOOTP는 여전히 IP를 Static하게만 할당할 수 있었고, 유연성 부족과 확장 옵션의 비표준화 등의 문제로 인해 BOOTP를 개량한 DHCP가 RFC 2131에서 새로 정의되었다.

 

그럼, 일반적인 환경에서의 DHCP 동작 알고리즘을 살펴보자.

 

1. 클라이언트는 부팅이 완료된 뒤 UDP 68번 포트로 DHCP DISCOVER 메시지를 보낸다.

2. DHCP 서버는 DISCOVER 메시지를 수신한 뒤 해당 클라이언트에게 DHCP OFFER 메시지를 전송, 자신이 IP를 제공할 수 있음을 알린다.

3. DHCP 클라이언트는 자신이 수신한 OFFER 중 하나를 선택(DHCP 서버가 다수일 경우), DHCP REQUEST 메시지를 브로드캐스팅한다. 이는 자신이 선택한 IP 주소를 알리고, 선택받지 못한 다른 서버들이 IP 주소를 재사용할 수 있게 하기 위함이다.

4. DHCP 서버가 DHCP 클라이언트에게 DHCP ACK 메시지를 전송함으로써 IP 할당이 완료된다.

5. 클라이언트는 자신이 할당받은 IP로 ARP Probe를 전송함으로써 충돌 확인을 한다. 만약 ARP Reply가 돌아오지 않으면 이 IP를 사용하게 된다.

 

앞서 말했듯이 DHCP는 이전에 사용하던 RARP/BOOTP의 부족한 부분을 보완하여 만들어졌다. 또한 여러 상황들에 유연하게 대응할 수 있도록 확장성 있는 구조를 가지는데, 상세 동작을 다루기 위해서는 먼저 DHCP 패킷의 구조를 이해할 필요가 있다.

 

DHCP 패킷은 다음과 같이 구성되어 있다.

 

1. Opcode (1Byte): DHCP 메시지의 타입을 나타낸다. 1은 BOOTREQUEST(요청), 2는 BOOTREPLY(응답)라 한다.

2. Hardware Type (1Byte): L2 Protocol의 유형을 나타낸다. ARP의 그것과 동일하다.

3. Hardware Length (1Byte): 하드웨어 주소 길이를 바이트 단위로 나타낸다.

4. Hop Count (1Byte): DHCP Relay가 사용될 경우 패킷이 중계된 횟수를 나타낸다. 기본값은 0이며, 경유한 Relay Agent마다 1씩 증가한다.

5. Transaction ID (4Byte): 클라이언트가 선택하는 랜덤한 32비트짜리 수이다. DISCOVER와 OFFER를 짝짓는데 사용한다.

6. Number of Seconds (2Byte): 임대 획득/갱신 이후 경과한 시간을 나타낸다.

7. Broadcast Flags (2Byte): 첫번째 비트가 0이면 응답 메시지를 유니캐스트로, 1이면 브로드캐스트로 전송한다.

8. Client IP Address (4Byte): 클라이언트의 IP 주소를 나타낸다. 최초 요청시에는 IP가 할당되지 않았으므로 0.0.0.0이 들어간다.

9. Your IP Address (4Byte): 클라이언트에게 할당되는 IP 주소로, 서버의 응답 메시지에 포함된다.

10. Client H/W Address (16Byte): 할당을 요청한 클라이언트의 하드웨어 주소가 들어간다.

11. Server Name String (64Byte): 서버 호스트 이름. 널 문자로 끝난다.

12. Options (가변 길이): DHCP 옵션들을 나타낸다. 최초 4바이트가 0x63, 0x82, 0x53, 0x63으로 되어 있다. 이 ‘Magic Cookie’는 RFC 1497 (BOOTP Extension)에서 정의된 것으로, BOOTP와의 호환성을 유지하기 위해 사용된다.

 

이를 그림으로 나타내면 다음과 같다.

 

All Rights Reserved ktworld.co.kr
All Rights Reserved ktworld.co.kr

 

BOOTP 프로토콜과 비교해 보면, 마지막 Option Field만이 약간 달라진 것을 알 수 있다.

DHCP Option Field의 구조는 다음과 같으며, DHCP는 이 Option Field를 이용하여 BOOTP와는 다른 확장 기능들을 구현한다.

All Rights Reserved ktworld.co.kr
All Rights Reserved ktworld.co.kr

 

그러면 이제 DHCP Option들에 대해 알아보자.

실제 사용할 수 있는 DHCP Option은 굉장히 많으나, 이 중 RFC 2132에서 정의된 것은 다음과 같다.

DHCP Option
All Rights Reserved IANA

 

전체 옵션 리스트는 다음 파일을 참조하라.

 options.xlsx

 

이 글에서는 IP  할당 및 임대 갱신에 사용되는 Option 50, 51, 53, 54, 61과 네트워크 통신을 위한 추가 정보를 제공하는 Option 1, 3, 5, 6, 15에 대해 서술한다.

 

Option 1 (Subnet Mask): 해당 클라이언트의 Subnet Mask를 지정한다.

Option 3 (Router): 해당 클라이언트의 Default Gateway를 지정한다.

Option 5 (Name Server): 클라이언트가 사용할, IEN 116에 정의된 네임서버의 주소를 지정한다.

Option 6 (Domain Server): 클라이언트가 사용할 DNS 주소를 지정한다.

Option 15 (Domain Name): 클라이언트의 도메인 이름을 지정한다.

Option 50 (Address Request): DHCP 서버가 클라이언트에게 할당할 IP Address를 지정한다.

Option 51 (Address Time): 할당해줄 IP Address의 임대 만료 시간을 지정한다.

Option 53 (DHCP Msg Type): DHCP 메시지의 타입을 지정한다. 아래의 표를 참조하라.

dhcp_msg

Option 54 (DHCP Server ID): DHCP 메시지를 전송한 서버의 IP 주소를 알린다.

Option 61 (DHCP Client ID): 클라이언트를 식별할 수 있는 식별자가 들어간다. 이 식별자로는 클라이언트의 MAC Address, FQDN 등이 사용될 수 있다.

 

부록

A. DHCP Relay Agent

DHCP의 설정 과정에서 브로드캐스팅이 사용되기 때문에 DHCP의 동작 범위는 기본적으로 하나의 서브넷으로 한정된다. 그러나 대규모 네트워크에서 이러한 구성은 다수의 DHCP 서버를 필요로 하고, 높은 비용을 발생시키며, 관리를 어렵게 만든다.

이에 따라 제안된 것이 바로 DHCP Relay Agent이다.

DHCP Relay Agent는 DHCP 서버와 클라이언트 간의 메시지 전달을 중계하여 DHCP 메시지가 서브넷을 넘어서 이동할 수 있도록 한다.

 

다음으로 DHCP Relay Agent가 어떻게 동작하는지 알아보자.

1. 클라이언트가 DHCP Discover 메시지를 브로드캐스팅한다.

2. Relay Agent는 Discover 메시지를 수신, DHCP 서버로 유니캐스팅한다. 이 때 Giaddr(Gateway Address)에 0.0.0.0 대신 자신의 IP를 기록하여 이 메시지가 Relay Agent로부터 온 것임을 서버에게 알린다.

3. DHCP 서버는 Giaddr 필드의 주소에 맞는 IP 풀을 선택, IP를 할당하고 Relay Agent의 주소로 DHCP Offer 메시지를 보낸다.

4. Relay Agent는 DHCP Offer를 클라이언트에게 중계한다. 이 때 Discover 메시지 안의 Broadcast Flag가 0이면 유니캐스트로, 1이면 브로드캐스트로 전송한다.

 

이것으로 Relay Agent의 기본적인 동작을 알아보았다.

그런데 메시지가 Relay Agent를 지날 때 Giaddr 필드에 Relay 자신의 IP를 기록한다면, 다수의 Relay를 거쳐서 서버로 요청이 전송되는 경우에는 서버가 클라이언트의 IP 대역을 잃어버리게 된다(Giaddr 주소에 근거하여 판단하므로) 따라서 여러 릴레이를 거치는 구성은 불가능한데, 어째서 Hop Count가 존재할까?

나는 이것이 DHCP 패킷이 루핑 등의 이유로 네트워크를 계속 떠돌아다니는 것을 막기 위해서 사용된다고 결론지었다. 실제로 여러 네트워크 회사의 DHCP 서버 설정에 max-hop-count가 존재하기도 하고.

만약 다른 이유가 있거나, 다수의 릴레이를 거치는 구성이 가능하다면 의견을 남겨 주길 바란다.

 

B. APIPA

DHCP 클라이언트가 DHCP를 통한 IP 할당에 실패하는 경우, 클라이언트는 네트워크와의 연결을 위해 APIPA(Automatic Private IP Addressing)을 사용해 169.254.0.0/16의 주소 중 하나를 임의로 할당한다.

APIPA는 RFC3927에서 정의되었고, BOOTP와 마찬가지로 네트워크 구성에 필요한 여러 정보를 얻을 수 없기 때문에 소규모 사설 네트워크에서의 통신에서만 사용될 수 있다.

CCNA Study – ARP Protocol

 


 

목차

1. Introduction

2. ARP 동작 예시

3. ARP의 변형

3-1. Reverse ARP (RARP)

3-2. Inverse ARP (InARP)

3-3. DHCP ARP

3-4. Gratuitous ARP (gARP)

3-5. ARP Probe

3-5.1. ARP Probe의 동작

3-6. UnARP


 

1. Introduction

Ethernet에서 물리 계층 주소(MAC)을 얻어낼 때 사용하는 프로토콜인 ARP에 대해 RFC를 참조하여 알아본다.

ARP는 1982년, RFC 826에 처음으로 정의되었다. 여기서 ARP의 목적은 ‘프로토콜 주소를 로컬 네트워크 주소로 변환하는 방법을 제공하는 것’이라고 밝히고 있다. 즉, 기본적으로 Ethernet을 위해 개발된 프로토콜이긴 하지만, 경우에 따라서 다른 프로토콜 위에서 동작할 수 있으며, 실제로 X.25, HDLC, FDDI, 802.11, ATM 등에서도 ARP를 사용하고 있다. ARP는  STD 37이라는 이름의 인터넷 프로토콜로 승인되었고, RFC 1122에서의 ‘잘못된 ARP Entry에 대한 처리’에 대한 모호함을 보완하였다. (The ARP specification [LINK:2] suggests but does not require a timeout mechanism to invalidate cache entries when hosts change their Ethernet addresses.)[1]

그러면 다시 RFC 826으로 돌아가 ARP가 어떻게 동작하는지 알아보자.
RFC 826에서는 ARP 헤더를 다음과 같이 정의하고 있다.

1. Hardware Address (16bit) – 로컬 네트워크에서 사용하는 하드웨어 타입을 규정한다.

2. Protocol Address (16bit) – 하드웨어 타입 필드를 보완하며, 3계층 프로토콜의 종류를 규정한다. Ethernet의 경우 Ether-type 필드의 값과 동일하다.

3. Hardware Address Length (8bit) – 뒤에 올 하드웨어 주소의 길이를 바이트 단위로 지정한다. 예를 들어 Ethernet은 48bit이므로 6의 값을 갖는다.

4. Protocol Address Length (8bit) – 이 메시지에 포함된 3계층 프로토콜의 주소 길이를 바이트 단위로 지정한다. 예를 들어 IPv4는 4의 값을 갖는다.

5. Opcode (16bit) – 이 ARP 패킷의 목적을 밝힌다. Opcode의 값은 좀 더 뒤에서 다루겠다.

6. Sender Hardware Address (n Byte) – 앞서 말한 길이의 송신자 하드웨어 주소가 온다.

7. Sender Protocol Address – (m Byte) – 앞서 말한 길이의 송신자 프로토콜 주소가 온다.

8. Target Hardware Address – (n Byte) – 앞서 말한 길이의 수신자 하드웨어 주소가 온다. 당연히 ‘알고 있을 경우’에 한하여 기록된다.

9. Target Protocol Address (m Byte) – 앞서 말한 길이의 수신자 프로토콜 주소가 온다.

이것을 그림으로 나타내면 다음과 같다.

All Rights Reserved ktworld.co.kr
All Rights Reserved ktworld.co.kr

 

2. ARP 동작 예시

Host A가 Host B에게 ARP Request를 보내는 시나리오를 이용하여 일반적인 ARP의 동작을 알아본다.

1. Host A는 이더넷 프레임에 사용할 목적지 MAC 주소를 결정하기 위해 자신의 ARP 캐시 테이블을 확인한다.

2. 캐시 테이블에 MAC 주소가 없다면 Host B의 MAC을 얻기 위해 ARP Request를 Dst-MAC-Addr을 FF:FF:FF:FF:FF:FF로 설정하여 브로드캐스팅한다.

3-1. 동일한 네트워크 세그먼트 상의 시스템들은 모두 이 ARP 패킷을 수신하고, 자신의 Protocol Address와 패킷의 TPA를 비교, 같지 않으면 폐기한다.

3-2. 만약 패킷의 TPA와 자신의 Protocol Address가 일치한다면, 자신의 Protocol Address를 기록한 ARP Reply 패킷을 Request를 보낸 시스템에 유니캐스트로 전송한다.

4. ARP Reply를 수신한 Host A는 자신의 ARP 캐시 테이블에 그 정보를 기록한다.

5. ARP Request에는 응답 만료 시간(Timeout)이 존재하지 않기 때문에, 응답을 수신하지 못하더라도 상관없다. 물론 이 경우에는 호스트와의 통신이 이루어지지 않는다.

 

 

3. ARP의 변형

Ethernet이 확산되고, 증가하는 여러 요구들에 대응하기 위해 ARP의 변형들이 사용되게 되었다.

대표적으로 Reverse ARP, Inverse ARP, Gratuitous ARP 등이 존재하는데, 이것들을 다루기 전에 먼저 ARP Packet의 Operation Code를 살펴볼 필요가 있다.

 

from IANA Reference
from IANA Reference [2]

여기서 Opcode 1, 2번은 일반적인 ARP 요청과, 변형 ARP 중 gARP, DHCP ARP, ARP Probe 등에 사용되는 Request/Reply이고, 이 글에서는 이에 더하여 Reverse ARP(3,4번) Inverse ARP(8, 9번)을 다루겠다.

 

 

3-1. Reverse ARP (RARP)

IPv4를 사용하는 장비가 자신의 하드웨어 주소는 알고 있지만, 자신에게 할당된 IPv4 주소는 모를 때 사용한다.

과거에 저장 매체가 없는 단말들(터미널)이 라우팅이 필요하지 않은 LAN 통신을 위해 주로 사용했지만, 디폴트 게이트웨이, DNS 서버 주소, 서브넷 마스크 등을 알 수 없기 때문에 지금은 DHCP와 BOOTP로 대체되었다.

 

Reverse ARP의 동작 과정은 다음과 같다.

1. 부팅된 터미널 장비가 Sender MAC-Addr와 Target MAC-Addr을 자신의 하드웨어 주소로 채운 RARP Request 패킷을 브로드캐스팅한다. 이 때 Sender IP-Addr과 Target IP-Addr은 전부 0.0.0.0이다.

2. RARP 서버가 이것을 수신하고, Target Protocol Address를 터미널 장비에 할당된 IP로 넣은 RARP Reply 패킷을 L2 Unicast 한다.

3. 터미널이 RARP Reply를 수신하고, 자신의 IP를 설정한다. Calssful Network를 기반으로 한 LAN 통신만이 가능하다.

RARP에 대한 자세한 설명은 RFC 903[3]에 기술되어 있다.

 

 

3-2. Inverse ARP (InARP)

Inverse ARP는 Frame-Relay와 ATM과 같이 여러 물리 계층 장비가 연결되어 WAN 네트워크를 구성하고 있지만, 하나의 논리적인 회선을 구성하여 통신을 하는 네트워크에서 쓰인다.

Frame Relay 망에서 Inverse ARP는 네트워크 장비가 자신과 연결된 VC 단말의 정보를 얻는 데 사용되며, 이를 위해서는 당연히 L2 설정이 제대로 되어 있어야 한다.

L2 통신에 필요한 DLCI를 동적으로 할당하고, 링크의 상태를 확인하는 프로토콜로 LMI가 있는데, 이것은 추후 Frame Relay를 살펴볼 때 알아볼 것이다.

 

그럼 간단한 Frame Relay 망을 예시로 InARP가 어떻게 동작하는지 알아보자.

 

InARP

 

1. Router A는 자신에게 할당된 DLCI 10, 20이 어디에 연결되어 있는지를 알고 싶어한다.

2. Router A는 SHA를 DLCI 10, SPA를 ipA로 하여 InARP Request를 전송한다.

3. Router A의 InARP Request를 수신한 Router B는 자신의 InARP 캐시에 Router A의 DLCI와 IP를 기록하고, SHA에 DLCI 40, SPA에 ipB를 기록한 InARP Reply를 전송한다.

4. Router B의 InARP Reply를 수신한 Router A는  자신의 InARP 캐시에 RouterB의 DLCI와 IP를 기록한다.

5. 이제 L3 통신을 위한 모든 정보가 갖추어졌으므로 통신이 이루어질 수 있다.

 

Inverse ARP의 구현에 대한 자세한 정보는 RFC 2390[4]을 참조하자.

 

3-3. DHCP ARP

DHCP를 이용한 IPv4 자동 할당은 편리하지만, 자칫 IPv4 주소의 충돌이라는 문제를 발생시킬 우려가 있다.

이 문제를 미연에 방지하기 위해 DHCP ARP가 RFC 2131[5]을 통해 정의되었다.

 

DHCP ARP는 다음과 같이 구성된다.

 

Dst-MAC: FF-FF-FF-FF-FF-FF

Src-MAC: Client-MAC

Opcode: 1 (Request)

Src-Har-Addr: Client-MAC

Src-Pro-Addr: 0.0.0.0

Target-Har-Addr: 00-00-00-00-00-00

Target-Pro-Addr: Assigned-IP-Addr

 

여기서 출발지 프로토콜 주소가 0.0.0.0인 것은 이 ARP Request를 수신한 장비들이 자신의 ARP Cache Entry를 갱신하지 않도록 하기 위해서이며 (When broadcasting an ARP request for the suggested address, the client must fill in its own hardware address as the sender’s hardware address, and 0 as the sender’s IP address, to avoid confusing ARP caches in other hosts on the same subnet.[6]) 이 요청에 대한 ARP Reply를 수신하지 못한다면 클라이언트는 할당받은 IP 주소를 사용할 것이다.

RFC 2131은 또한 ‘IP 주소의 갱신을 다른 시스템에게 보고하기 위해 ARP Reply를 브로드캐스팅하여 다른 시스템이 오래된 ARP Entry를 갱신하도록 해야 한다’ ( The client SHOULD broadcast an ARP reply to announce the client’s new IP address and clear any outdated ARP cache entries in hosts on the client’s subnet.[7])고 규정하고 있으나, 대부분의 시스템에서는 Gratuitous ARP라 불리는 ARP Request를 이용해 이 기능을 구현하고 있다.

 

3-4. Gratuitous ARP (gARP)

Gratuitous ARP (이하 gARP)는 자신의 IP나 MAC이 변동되어, 같은 서브넷 내의 다른 장비들의 ARP Cache Entry를 갱신할 필요가 있을 때 사용된다.

예를 들어 DHCP로부터 새로운 IP를 할당받았거나, VRRP에서 Active Router를 변경할 때, 클라이언트에서 2개의 NIC를 이용하여 고가용성(HA) 구성을 하였을 경우 등이 있다.

 

gARP 패킷은 다음과 같이 구성된다.

 

Dst-MAC: FF-FF-FF-FF-FF-FF

Src-MAC: Client-MAC

Opcode: 1 (Request)

Src-Har-Addr: Client-MAC

Src-Pro-Addr: Client-IP-Addr

Target-Har-Addr: 00-00-00-00-00-00

Target-Pro-Addr: Client-IP-Addr

 

DHCP ARP 와는 다르게 출발지 프로토콜 주소 필드가 자신의 IP 주소로 설정되었다는 것을 알 수 있다.

gARP는 앞서 말했듯이 오래된 ARP 캐시 엔트리의 갱신이 목적이기 때문에 ARP Reply가 돌아오는 것을 기대하지 않지만, 만약 Reply가 돌아온다면 IP 주소가 충돌한다는 것을 의미하게 되므로 적절한 대처가 요구된다.

 

3-5. ARP Probe

ARP Probe는 IPv4 주소의 충돌을 감지하기 위한 수단으로써, RFC 5227[8]에 정의되어 있다.

ARP Probe는 기본적으로 DHCP ARP와 동일한 구성을 가지는데, 이것은 ARP Probe가 DHCP ARP를 참조했기 때문이다. (The DHCP specification [RFC2131] briefly mentions the role of ARP in detecting misconfiguration, as illustrated in the following three excerpts from RFC 2131: [9])

RFC 5227에서는 DHCP ARP를 확장하여, ‘IPv4를 할당받는 모든 경우에 ARP Request를 전송하도록'(Before beginning to use an IPv4 address (whether received from manual configuration, DHCP, or some other means)[10]) 규정하고 있으며

RFC 2131의 모호함을 (the DHCP specification does not give any guidance to implementers[11]) 해결하였다.

 

3-5.1. ARP Probe의 동작

ARP Probe는 크게 Probing – Announcing – Conflict Detection and Address Defense의 순으로 이루어진다.

먼저, Probing은 DHCP ARP의 패킷 구성을 따르되, IP 할당 이후 0~1초 사이의 랜덤한 시간을 대기한 뒤 3개의 Probing Packet을 전송한다. 이 Probing Packet의 사이에는 1~2초 사이의 임의의 시간 간격을 준다.

마지막 Proving Packet을 전송하고 2초가 지난 뒤에도 ‘Sender IP Address’가 할당받은 IP인 ARP Packet(Request/Reply)이 도착하지 않으면, 클라이언트는 이 IP를 사용해도 된다고 판단, ARP Announcement 패킷-gARP와 동일-을 전송하고, 마지막 단계인 Conflict Detection and Address Defense로 천이한다.

 

Conflict Detection and Address Defense 단계에서 호스트는 Sender IP Address가 자신이 할당받은 IP이면서 Sender Hardware Address가 자신이 아닌 ARP 패킷이 들어오는지를 계속 확인한다.

만약 그러한 패킷이 발견되면, 호스트는 다음 3가지 중 하나의 동작을 취한다.

 

A. 즉시 그 IP 주소의 사용을 포기한 뒤, 설정 Agent(e.g. DHCP Server)에게 오류를 보고한다.

B. 현재 열려있는 TCP 세션이 있어서 IP를 포기할 수 없고, 10초가 지나도 다른 문제가 되는 ARP 패킷이 들어오지 않는다면 그 IP를 계속 사용하도록 결정할 수 있다. 그리고 ARP Announcement 패킷을 한번 더 전송한다. 만약 추가로 문제가 되는 ARP 패킷이 들어오면 호스트는 즉시 그 IP를 폐기하고, 오류를 Agnet에게 보고한다.

C. 만약 이 클라이언트가 네트워크에서 매우 중요한 시스템(e.g. Default Gateway)이어서 IP를 무슨 일이 있어도 포기할 수 없다면, 이 IP를 계속 사용하도록 결정할 수 있다. 이 경우 클라이언트는 Sender-MAC-Addr와 같은 정보를 로그에 기록하고, 네트워크 관리자에게 문제를 알려야 한다. 10초가 지나도 문제가 되는 ARP 패킷이 추가로 유입되지 않으면, 호스트는 ARP Announcement를 1회 전송하고 이 IP를 계속 사용할 수 있다. 만약 10초 이내에 다시 문제가 되는 ARP 패킷이 유입되면, 호스트는 IP  Defense loop를 방지하기 위해 ARP Announcement를 전송해서는 안 된다.

 

 

3-6. UnARP

UnARP는 Proxy ARP 환경에서의 ARP Cache Invaild 문제를 해결하기 위해 RFC 1868[12]을 통해 제시되었고, 현재 실험 프로토콜(Experimental Protocol)로 지정되어 있다.

RFC 1868은 현재 사용되는 timeout을 통한 ARP Entry 제거 방식 대신 클라이언트가 네트워크로부터 접속을 종료할 때, 그것을 명시적으로 ARP를 통해 알리는 것을 골지로 하며, 실험 프로토콜의 특성상 이것을 준수하는 장비는 잘 없다.

 


각주

[1] https://tools.ietf.org/html/rfc1122#page-22

[2] http://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml#arp-parameters-1

[3] https://tools.ietf.org/rfc/rfc903.txt

[4] https://tools.ietf.org/html/rfc2390

[5] https://tools.ietf.org/html/rfc2131

[6] RFC 2131 – Section 4.4.1 : https://tools.ietf.org/html/rfc2131#section-4.4

[7] RFC 2131 – Section 4.4.1 : https://tools.ietf.org/html/rfc2131#section-4.4

[8] https://tools.ietf.org/html/rfc5227

[9] RFC 5227 – Section 1 (Introduction) : https://tools.ietf.org/html/rfc5227#section-1

[10] RFC 5227 – Section 2.1 : https://tools.ietf.org/html/rfc5227#section-2.1

[11] RFC 5227 – Section 1 : https://tools.ietf.org/html/rfc5227#section-1

[12] https://tools.ietf.org/html/rfc1868