태그: ARP

Network Study – 4주차 : TCP/IP

 

지난 주에는 패킷 교환망에서 패킷의 경로를 결정하는 방법인 라우팅 프로토콜에 대해 알아보았다.
그리고, 이번 주에는 TCP/IP 네트워크에서 핵심적인 역할을 하는 TCP와 IP에 대해 알아보자

1. IP(Internet Protocol)의 역사

IP는 본래, TCP/IP Protocol Suite에 속한 하나의 프로토콜이다. 이것은 IAB(Internet Architecture Board)에 의해 관리되는 IANA(Internet Assigned Number Authority), IRTF(Internet Research Task Force), IETF(Internet Engineering Task Force)에서 관리된다.
이들 중 하나인 IETF에서 TCP/IP 표준인 RFC(Request for Comments)를 배포한다. 단, 모든 RFC가 표준인 것은 아니다. IAB의 검토를 거친 RFC만이 인터넷 스텐다드로써 등재되고, 전체 네트워크에서 지켜야 할 표준으로 지정된다.
그러므로, 대부분의 RFC들은 실험적인 적용이나 단순 권고를 담고 있다.

TCP/IP에 대해 다루기 전에 먼저 TCP/IP의 역사를 알아보자.

– 1970년, ARPANET 호스트들이 TCP의 전신인 NCP(Network Control Protocol)을 사용하여 운영되기 시작한다.
– 1972년, Telnet 프로토콜이 만들어진다. Telnet은 서로 다른 시스템 터미널을 에뮬레이션 하기 위해 사용되었다. 1970년대 초, 이 시스템들은 서로 다른 종류의 메인프레임들로 이루어져 있었다.
– 1973년, FTP(File Transfer Protocol)이 사용된다. FTP는 서로 다른 시스템 사이에서 파일을 전송하기 위해 사용되었다.
– 1974년, TCP(Transmission Control Protocol)이 구체화된다. TCP는 NCP를 대체하였으며, 더 개선된 신뢰성 있는 통신을 제공하였다.
– 1981년, IP(Internet Protocol)이 구체화된다. IP는 단대단 전송에서 어드레싱과 라우팅을 제공하였다.
– 1982년, DCA(Defense Communications Agency)와 ARPA는 TCP와 IP를 합쳐 TCP/IP Protocol Suite를 만든다.
– 1983년, ARPANET이 NCP에서 TCP/IP로 이전한다.
– 1984년, DNS(Domain Name System)가 제안된다. DNS는 도메인 이름을 IP 주소로 바꾸어 주었다.
– 1995년, ISP(Internet Service Provider)들이 인터넷을 개인과 기업들에게 제공하기 시작한다.
– 1996년, HTTP(Hypertext Transfer Protocol)이 제안된다. WWW(World Wide Web)이 HTTP를 사용한다.
– 1996년, 최초의 IPv6 표준이 발표된다.

이상이 간략하게 살펴본 TCP/IP의 역사이다. 본래 TCP/IP는 TCP와 하나였으며, 네트워크 계층이 구체화되면서 TCP와 IP로 분리되게 되었다.
2017년 현재 IP에서 이슈가 되는 부분은 IPv6로의 전환과 4 to 6, 6 to 4의 터널링이며, 추후 IPv6를 다룰 때 더 자세히 알아보도록 하겠다.

2. TCP/IP Protocol Suite

IP를 다루다 보면 필연적으로 상위 계층의 프로토콜들이 따라온다. IP만으로는 인터넷을 운영하는 것이 불가능하기 때문이다.
이 중 특히 ARP와 ICMP에 대한 의존도가 특히 높다고 할 수 있으리라. 이 프로토콜들에 대해 이야기하기 전에, 먼저 TCP/IP Protocol Suite를 훑어보자.

TCP/IP Protocol Suite는 다음과 같은 구조로 이루어져 있다.

이를  OSI Layer와 비교해보면 L1~2가 Network Layer로, L3가 Internet Layer로, L4가 Transport Layer로. 그리고 L5~7이 Application Layer와 대응되는 것을 알 수 있다.
이렇듯, TCP/IP Protocol Suite는 ISO에서 제정한 OSI 7계층과는 다른 구조를 가지고 있음을 알 수 있다.
이것은 OSI Layer가 프로토콜에 대한 표준안을 제시하는 것이 아닌, 프로토콜의 발전을 위하여 각 계층에서 수행하는 일들을 체계적으로 나눠 놓은 것에 불과하기 때문이며, 실제로 프로토콜을 설계할 때는 더 세부적으로 구분된 OSI 7계층을 참조하여 개발이 이루어지고 있다.

또한, 특기할 점으로는 IP(v4)와 같은 Internet Layer에 속한 ARP와 IGMP, ICMP가 있는데, 목적지까지의 전달이라는 핵심 목표를 수행하는 것은 IP이지만, IP가 좀 더 효율적으로 동작하도록 도와주는 프로토콜들이 이들 프로토콜이 되겠다. 특히 ARP는 2계층과의 연동을 담당하는 프로토콜로써, ARP 없이 IP 단독으로는 사실상 데이터 전송이 불가능하다.

IGMP를 제외한 각 프로토콜에 대해서는 이미 별도의 문서로 다루었기에, 이 글에서는 간단하게 프로토콜의 역할 정도만 소개하고 넘어가고자 한다.

2-1. ARP(Address Resolution Protocol)

ARP는 IP 네트워크에서 IP주소를 물리적 주소(PHY Address)로 대응시키기 위해 사용하는 프로토콜이다.
L3 프로토콜 주소인 IP 주소를 이용해 최종 목적지까지 라우팅 되어 온 패킷은 하부 시스템에 전달되기 위하여 L2 프로토콜 주소(e.g. MAC Address)를 필요로 하게 된다. 이 때 사용되는 프로토콜이 바로 ARP이다.

ARP의 상세 동작과 RARP, gARP 등을 알고 싶다면, CCNA Study – ARP Protocol을 참조하자.

2-2. ICMP(Internet Control Message Protocol)

ICMP는 오류 보고와 흐름 제어 기능이 없는 IP를 보조하기 위하여 만들어진 프로토콜이다.
현대 인터넷에서는 오류 보고와 흐름 제어의 역할이 L4로 넘어갔기에 이 일은 TCP가 수행하지만, 실제로 TCP에서 흐름 제어 기능을 수행할 때, TCP는 ICMP를 이용하여 오류 제어와 흐름 제어를 수행한다.
이렇듯, ICMP는 현대 인터넷이 트래픽 폭증으로 인하여 다운되지 않고 운영될 수 있게 하는 역할의 한 축을 담당하고 있다.

ICMP의 상세 동작은 CCNA Study – ICMP를 참조하자.

2-3. IGMP(Internet Group Management Protocol)

IGMP는 IP 네트워크에서 라우터가 멀티캐스트 그룹을 판단할 때 사용하는 프로토콜이다.
IGMP의 동작을 다루기 위해선 먼저 멀티캐스트에 대해 알아볼 필요가 있다. 멀티캐스트란 Unicast/Broadcast로 구성되어 있던 IP 네트워크에서 일대 다수(One to many) 혹은 다수 대 다수(Many to many) 통신을 지원하기 위해서 개발되었다.
멀티캐스트를 지원하기 위하여 IP 대역의 일부(클래스 D/224.0.0.0 ~ 239.255.255.255)를 멀티캐스트 대역으로 할당하였으며, 특히 이 중에서 224.0.0.0/24 대역은 로컬 멀티캐스트 대역으로 지정되어 있다.

IGMP는 최초 RFC 1112를 통해 표준화되었으며, IGMPv3가 Proposed Standard로써 제안되었다.
여기서는 Internet Standard인 RFC 1112를 기반으로 IGMP의 동작을 알아본다.

IPv4 Protocol Suite은 이 정도로 해두고, IPv4의 핵심 역할인 고유 주소 할당과 경로 결정은 라우팅을 다루면서 충분히 설명하였다고 생각한다.
그렇기에 이 글에서는 이전에 미처 다루지 못하였던 IPv4 패킷의 구조 정도만을 짚고 넘어가고자 한다.

(1) Version : IPv4를 나타내기에 4의 값을 가진다.
(2) Header Length : 헤더의 크기를 워드(4Byte)단위로 나타낸다.
(3) ToS or DiffServ : 본래 IP 패킷의 응용에 따라 적절한 경로를 선택하기 위해 도입되었던 ToS 필드는 그 저조한 사용률 덕에 DiffServ 필드로 대체되었다. ‘최저 비용’, ‘처리량 최대’, ‘지연 최소’ 등의 상당히 모호하고 변동성이 심한 플래그를 담고 있던 ToS와는 달리, DiffServ는 ‘패킷의 클래스별 QoS’라는 정량화된 목표를 나타낸다. 이 클래스는 ECN 2비트를 제외하고 6비트를 사용, 최대 64개로 분류될 수 있으며, 네트워크 서비스 주체가 커스터마이징 할 수 있다.
(4) Total Length : 전체 패킷의 길이를 1바이트 단위로 나타낸다.
(5) Identifier : IP 패킷에 할당되는 고유 값. 패킷이 생성될 때 설정되며, 단편화된 패킷의 경우 같은 값을 갖는다. 이것은 루핑 때문에 발생한 패킷을 IP레벨에서 네트워크로부터 제거할 수 있다는 것을 의미한다. TCP의 Sequence Number와 유사.
(6) Flags : Fragment Flags. 첫 비트는 0, 두번째 비트는 DF(Don’t Fragment) 플래그로 1로 세트될 시 단편화 불가. 세번째 비트는 More Fragment로 단편화된 패킷이 뒤에 더 있을 경우 1로 세트된다.
(7) Fragment Offset : 해당 패킷이 단편화된 데이터그램에서 어느 부분에 해당하는지 알려주는 값이다.
(8) Time to Live(TTL) : 한 홉(Hop)을 건널 때마다 1씩 감소하여, 0이 되면 폐기된다. TTL 만료로 패킷을 폐기한 라우터는 해당 패킷의 발신지를 향하여 ICMP 11 – Time Exceeded를 전송한다.
(9) Protocol : IP 상위의 프로토콜을 알려주는 SAP.
(10) Header Checksum : 헤더 전체를 대상으로 CRC-16을 수행한다.
(11) Source Address : 출발지 IP 주소
(12) Destination Address : 목적지 IP 주소
(13) Options : IPv4에서 실험용으로 사용되었던 옵션들이 다수 존재. IANA에 등록되지 않은 옵션도 직접 정의하여 사용할 수 있으나, 실제 네트워크에서는 거의 사용되지 않는다.
(14) Padding : 패킷이 32Bit(4Byte)의 배수로 만들어지지 않을 경우, 효율적인 데이터 처리를 위하여 4바이트 배수로 맞추기 위한 필드. 더미값이 들어간다.

3. IPv6 (Internet Protocol Version 6)

지난 30여년간 IPv4가 보여주었던 여러 한계점들과 문제를 해결하기 위한 대안으로써 1998년, IPv6(RFC2460)가 제안되었다.
IPv6는 IPv4의 고갈된 주소 공간을 훨씬 큰 크기로 확장하고, 주소의 파편화로 복잡화된 라우팅 테이블을 최적화 하는 것, 프로토콜 헤더의 간략화, 추후 인터넷의 변화를 유연하게 수용할 수 있는 옵션과 확장들의 개선,  우선순위에 따른 흐름 제어와 QoS등을 목표로 하여 디자인되었다.

또한 흔히들 IPv4 대비 강화된 보안성을 추가적인 장점으로 들고 있지만, 아직 IPv6와 인접 프로토콜들은 표준화가 진행중이기 때문에 오히려 IPv4 시스템에서 발생하지 않는 보안 취약점이 추가로 발견될 수 있다는 점을 염두에 두어야 할 것이다.

IPv6에서 극명히 드러나는 IPv4와의 차이점은 바로 헤더이다. IPv6는 IPv4헤더를 간략화하고, 공통 헤더와 옵션 헤더를 나누어 전체 헤더 크기를 감소시키며 확장성을 확보하였다.

(1) IPv6 Basic Header

IPv6의 가장 기본이 되는 헤더이다. IPv4의 그것과 비교하여 확연히 간략화된 모습을 확인할 수 있다.

(1) Version : IPv6이기에 6의 값을 갖는다.
(2) Traffic Class : IPv4의 ToS와 유사한 역할. 아직 표준이 확정되지 않았기에 명확한 정의는 이루어지지 않음.
(3) Flow Label : IP 프로토콜은 비연결적인 프로토콜로 설계되었으나, IPv4의 사례에서 주로 연결 지향적 프로토콜로 사용하는 경향을 확인할 수 있었다. IPv4에 대하여 연결 지향적인 프로토콜 기능을 제공해주는 기술로 MPLS가 제안되었으며, IPv6에서는 MPLS가 담당하던 부분이 IP 프로토콜에 포함되었다. Flow Label은 같은 특성을 가지는 패킷의 ‘흐름’을 나타낼 수 있으며, 이를 통해 응용별 서비스를 제공할 수 있다. 이를테면 실시간 비디오 응용의 경우 처리에 필요한 자원을 미리 예약해둘 수 있으며, 이를 위해 RTP(Real Time Protocol)과 RSVP(Resource Preservation Protocol)이 사용된다.
(4) Payload Length : 헤더를 제외한 나머지의 크기를 바이트 단위로 나타낸다. 확장 헤더는 페이로드의 일부로 간주된다.
(5) Hop Limit : IPv4의 TTL과 동일.
(6) Next Header : IPv6 공통 헤더의 다음에 위치할 헤더의 종류를 나타내는 8bit 선택자. 상위 레벨 프로토콜이나 IPv6 Extension Header를 나타낼  수 있다.
(7) Source Address : 출발지 주소
(8) Destination Address : 목적지 주소

IPv4와 비교하면 다음과 같은 차이가 있다.

– 헤더 길이 필드의 제거 : 헤더의 길이가 고정되어 있기 때문에 제거되었다.
– 서비스 유형 필드의 제거 : ToS/DiffServ는 Flow Label로 대체되었다.
– Total Length 필드의 제거 : Payload Length 필드로 대체된다.
– 단편화 관련 필드의 제거 : 단편화 확장 헤더에서 제공된다.
– 프로토콜 필드의 제거 : Next Header 필드로 대체되었다.
– 옵션 필드의 제거 : 확장 헤더를 통하여 제공된다.
– 헤더 Checksum 제거 : 상위 계층에서 제공되기에 삭제되었다.

(2) IPv6 Extension Header

IPv6에서는 헤더 부분이 네트워크에서 차지하는 대역폭을 줄이고, 확장성을 도모하기 위하여 Extension Header(이하 확장 헤더)를 도입하였다. IPv4와는 달리 용도와 페이로드의 종류에 따라 확장 헤더를 사용할 수 있으며, 각각의 확장 헤더는 독립적이고, 동시에 중첩 가능하다.

RFC2460에서 정의된 확장 헤더는 다음과 같다.

– Hop by Hop Options
– Routing (Type 0)
– Fragment
– Destination Options
– Authentication (RFC2402)
– Encrypted Security Payload

확장 헤더는 IPv6의 표준화가 진행됨에 따라 더 늘어날 수 있으며, 임의의 확장 헤더를 정의하는 것 또한 허용된다.

(2-1) Hop-By-Hop Option Header

이 옵션 헤더는 발신자가 데이터그램이 통과하는 모든 라우터에 정보를 전달할 필요가 있을 경우 사용한다.
현재는 3가지 옵션(Pad1, PadN, Jumbo Payload)가 정의되어 있으며, 각 옵션에 대한 자세한 설명은 다음 절에서 다루겠다.

– Pad1 Option : Pad1 옵션은 어떤 옵션이 특정한 위치에서 시작될 필요가 있을 때 사용된다. 만약 지정 위치에서 1바이트가 부족하다면, 정렬(Alignment)을 위해 Pad1이 추가된다. Pad1은 1바이트의 크기를 가지며,  값은 0이다.
– PadN Option : 특정 옵션이 N Byte가 모자라다면 PadN이 사용된다. PadN의 첫번째 바이트(옵션 코드)는 1, 두번째 바이트(옵션 길이)는 패딩의 크기, 나머지 바이트들은 옵션 길이만큼의 크기를 가지며 0의 값을 갖는다.
– Jumbo Payload Option : IPv6에서는 데이터그램의 최대 크기가 65,535바이트로 증가하였다. 하지만 어떠한 이유로 이것보다 더 큰 페이로드가 요구된다면 점보 페이로드 옵션을 사용할 수 있다. 점보 페이로드 옵션은 ‘정렬 제한’을 갖는다. 즉, 옵션 헤더의 시작으로부터 (4n+2)바이트의 위치에서 시작해야 한다.

(2-2) Source Routing

IPv6의 Source Routing 옵션은 IPv4의 느슨한 라우팅 옵션과 엄격한 라우팅 옵션을 결합한 것이다.
Address Left 필드는 목적지까지 도달하기 위한 홉 수를 나타내며, Strict/Loose Mask를 통하여 느슨한/엄격한 라우팅 옵션을 선택한다.

IPv4의 그것과 마찬가지로, 엄격한 라우팅 옵션은 이 패킷이 반드시 정해진 순서의 라우터를 통과하여 전송되야 함을 의미하고, 느슨한 라우팅 옵션의 경우에는 각 라우터 사이에 다른 라우터들이 들어갈 수 있다.

(2-3) Fragment

IPv6에서는 IPv4헤더에 포함되어 있던 단편화 옵션이 별도의 확장 헤더로 분리되었다. 단, IPv6에서는 오로지 발신자만이 단편화를 수행할 수 있기에 반드시 최대 MTU 값을 찾아내는 일이 선행되어야 한다. 이것은 MTU 탐색 기법(Path MTU Discovery Technique)을 통해 이루어지며, 다음과 같은 순서로 수행된다.

IPv6에서의 MTU 탐색 기법은 RFC 1981으로 표준화 작업이 진행중이다.

1. 발신지 호스트는 큰 사이즈의 데이터그램을 전송한다
2. 라우팅 경로 상에 있는 장비가 자신의 MTU 값보다 더 큰 데이터그램을 수신하면 Packet too big 메시지를 발신지로 돌려보낸다.
3. 발신지 호스트는 Packet too big 메시지에 들어 있는 MTU 값으로 재전송을 수행한다.

이렇게 보면 참 단순한 방법이지만, 여기에는 몇가지 문제가 있다.
먼저, 1회의 Packet too big  메시지만으로 Path MTU를 결정할 수 없다. 최초로 에러를 발생시킨 라우터의 다음 홉에 있는 라우터가 가진 MTU 값이 더 작을 수도 있다.
그리고 Path MTU값이 하나의 값으로 고정되게 된다면, 토폴로지 변동에 따라서 증가할 수 있는 MTU 값을 효율적으로 사용하지 못한다.

첫번째 문제는 ICMP Error 메시지가 도착하지 않을 때까지 MTU를 감소시키는 것으로 대응할 수 있다. 하지만 두번째 문제의 경우는 좀 더 복잡하다.

RFC 1981은 호스트는 Path MTU값을 좀 더 높게 ‘추정할 수 있다’고 명시한다. 하지만 이것 또한 전송하려는 데이터의 크기가 PMTU보다 커서 MTU를 확장할 필요가 있을 경우에 한한다. 그리고 이러한 시도는 Packet too big 메시지를 수신한 뒤 5분 이내에는 이루어질 수 없다.

이것을 통해 알 수 있는 것은 현재 IPv6의 표준화에 참여하고 있는 사람들은 Path MTU를 최적화하는 것 보다, 이로 인해서 발생할 수 있는 회선의 부하를 좀 더 중시한다는 점이다.
그리고 당연하지만 Path MTU 값은 IPv6의 최소 패킷 길이보다 작을 수 없다.

또 하나 쟁점이 되는 부분은 ‘어느 레이어에서 PMTU 탐색을 진행할까?’ 라는 것이다.
PMTU 탐색을 전송 레이어에서 수행하는 것은 내부 구현적 측면에서 유리하지만, 전송 프로토콜마다 알고리즘을  새로 구현해야 하며 이것은 다른 프로토콜간의 MTU 공유를 방해한다.
이러한 이유로 IP 계층에서 PMTU Discovery를 구현하게 되었고, ‘IP 레이어에서 PMTU 정보를 저장하고, ICMP가 Packet too big 메시지를 처리하는’ 식으로 구현이 이뤄졌다.

(2-4) Destination Option

기본적으로 Hop-by-Hop Option과 동일하며, 발신자가 오직 목적지 호스트에게만 정보를 전달하고 싶을 때 사용한다. 현재까지는 Pad1과 PadN만이 정의되어 있다.

(2-5) Authentication

인증 확장 헤더는 두 가지의 목적을 갖는다. 메시지 송신자를 검증하는 것과, 데이터의 무결성을 검증하는 것이다.
Security Parameter Index에서 인증 방법을 전달하며, Authentication Data가 따라온다.

(2-6) Encrypted Security Payload

IPv6에서 제공하는 도청 방지 및 비밀 보장을 위한 확장이다. 터널 모드와 전송 모드로 구현되며, 대표적인 응용으로는 IPSec이 있다.

 

(3) IPv6의 주소 공간과 할당

IPv6가 만들어진 가장 큰 이유인 IPv4의 주소 고갈 문제, 이것을 해결하기 위하여 IPv6는 주소 공간의 크기를 128비트로 확장하였다.
IPv4 대비 4배의 길이를 가지는 이 주소값은 IPv4와는 다른 구분 방법, 분배 방법 및 읽는 방법이 필요하였다.

먼저, IPv6은 IPv4와 같은 점 10진법 표기법으로 나타낼 수 있다. 하지만 이것은 IPv4 대비 4배의 길이를 가지게 되므로, 잘 쓰이지 않는다.
두번째 방법이 흔히 사용되는 16진수 콜론 표기법으로, 10진법 표기 대비 길이를 절반으로 줄일 수 있었다.
이것만으로는 가독성이 떨어졌으므로, 이 16진수 표기를 축약하는 방법이 또 제공되는데, 하나의 콜론에서 앞에 위치하는 0들을 하나의 0으로 표현하는 방법과 0으로 이루어진 콜론의 연속을 제거하고 ::으로 표기하는 방법(Zero Compression)이 있다. 특히 제로 압축은 하나의 IPv6 주소에서 두 번 이상 사용시 정확한 해석이 불가능하기에 한번만 사용될 수 있음에 주의해야 할 것이다.

IPv6은 주소 공간의 구분을 위한 CIDR를 지원하며, IPv4와 같은 해석 방법을 갖는다.

IPv6 주소 공간은 현재 Global Unicast, Unique Local Unicast, Link-Scoped Unicast, Multicast 주소와 특수 목적용 주소가 할당되어 있으며, 7/8가량의 공간이 미래 사용을 위해 예약된 채로 남아있다.
이들 주소 중에서 특히 자주 사용되는 Global Unicast, Unique Local Unicast, Multicast의 주소 영역은 다음과 같다.

– Global Unicast : 2000::/3
– Unique Local Unicast : FC00::/7
– Multicast : FF00::/8

 

(4) ICMPv6

 

(5) RTP/RSVP

 

(6) MLD

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