태그: ICMP

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 – ICMP

 

1. Introduction

ICMP(Internet Control Message Protocol)은 TCP/IP Suite에서 IP에 문제가 생겼을 때, IP 자신은 오류를 보고하고, 연결을 제어할 수 있는 기능이 없기 때문에, 이를 보조하기 위하여 만들어진 프로토콜이다.

ICMP는 RFC 792에서 처음으로 정의되었으며, 관련된 다른 RFC로는 RFC 1122, RFC 1812가 있다. 현재는 IPv6에 대응하는 ICMPv6가 나왔기 때문에 이전의 ICMP는 ICMPv4로 불리게 되었다.

ICMP는 IP 의 상위에서 캡슐화(Encapsulation)되어 동작하기 때문에 기본적으로 IP에 대해 의존적이지만, 실질적으로 IP가 잘 동작하려면 ICMP의 보조가 반드시 필요하기에 이 둘은 상호 보완적인 관계라고 볼 수 있다.

 

2. ICMP 패킷의 구조

ICMP 패킷은 다음과 같은 구조를 가진다.

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

 1. Type (1 Byte): ICMP 메시지의 타입을 지정하는 필드로, 자세한 내용은 나중에 다루겠다.

2. Code (1 Byte): ICMP 메시지 타입에 따른 하위 타입을 지정하는 필드로, 이것 또한 뒤에 다루겠다.

3. Checksum (2 Byte): ICMP 헤더의 무결성을 검증하기 위해 사용된다.

4. Data (N Byte): ICMP 메시지의 실제 데이터로, 길이는 타입과 코드에 따라 달라진다.

2-1. ICMP Type

ICMP 메시지의 타입(Type)에는 다음과 같은 것들이 있다.

All Rights Reserved IANA
All Rights Reserved IANA[1]
 

이 중에서 Deprecated된 타입을 제외한 Type 0, 3, 4, 5, 8, 9, 10, 11, 12에 대해 알아보자.

 

Type 0: Echo Reply 메시지를 나타낸다. Echo Reply는 Echo에 대한 응답으로, Identifier와 Sequence Number를 포함한다. RFC 792에 따르면 Identifier는 세션 구별을 위한 포트 넘버와 같은 것들이 들어가고, Sequence Number는 TCP의 그것과 동일하다.

 

Type 3: 목적지 도달 불가 메시지를 나타낸다. 이 메시지는 1바이트의 코드(Code) 값을 갖는데 이는 다음과 같다.

Typ3-Code

이 중에서 Code 0은 목적지 네트워크에 도달할 수 없음을 알리고(주로 라우팅 테이블 불일치), Code 1은 목적지 네트워크에는 도달했으나, 목적지 호스트에는 도달할 수 없었음을 말한다.

그리고 Code 4는 주로 링크 상의 최대 MTU를 찾는 용도로 사용된다.

 

Type 4: 발신지 억제 메시지를 나타낸다. IP는 데이터 전송 속도를 제어하는 흐름 제어 기능을 갖지 않고 있기 때문에(Best Effort) 라우터가 자신이 처리 가능한 용량을 넘어서는 패킷을 받는 경우(e.g Ingress Buffer Overflow) 나머지 패킷들을 폐기시켜야 하고, 패킷을 폐기할 때 그 패킷을 송신한 호스트에게 Source Quench 메시지를 전송한다.

그러나 폐기되는 모든 패킷에 대해 전송되는 메시지의 특성 상 이 메시지를 수신하더라도 호스트는 자신이 혼잡을 유발하고 있다고 단정지을 수 없다.

 

Type 5: 재지정 메시지를 나타낸다. 목적지로 데이터를 전송하는 경로 상에 있는 라우터가 해당 목적지로 가는 더 나은 경로가 있음을 알리기 위해 사용된다.

Type 5에는 2가지의 코드(Code)가 있는데, 이는 다음과 같다.

Typ5-code

Code 0: 네트워크 재지정. 해당 목적지 네트워크로 가는 모든 패킷의 경로를 재지정할 것을 권고한다.

Code 1: 호스트 재지정. 해당 목적지 호스트로 가는 패킷의 경로를 재지정할 것을 권고한다.

 

Type 8: Echo 메시지를 나타낸다. 이 메시지를 수신한 호스트는 발신자 주소를 목적지로 하여 Echo Reply 메시지를 전송한다.

Type 9, 10: IRDP (ICMP Router Discovery Protocol)에서 사용하는 메시지이다. 이것은 RFC 1256에서 정의되었으며, Type 9는 RS (Router Solicitation) 메시지, Type 10은 RA (Router Advertisement) 메시지이다.

각각의 패킷 구조는 다음과 같다.

RA Message

RA_Msg

RS Message

RS_Msg
All Rights Reserved ktworld.co.kr

이 때 IRDP 메시지는 Multicast 주소(224.0.0.1)로 전송되거나, Broadcast 주소를 사용한다. (Cisco는 기본적으로 Broadcast)

IRDP를 사용하는 라우터는 자신이 네트워크에 연결되었을 때 RS를 전송하고, 주기적으로 RA를 전송한다. 또한 RA는 RS에 대한 응답으로써 전송될 수도 있다.

 

Type 11: 시간 초과 메시지를 나타낸다. 이 메시지는 두 가지 경우에 전송되는데, 하나는 IP 패킷의 TTL이 0이 되었을 때이며, 다른 하나는 단편화 재조합 타이머(Fragment Reassembly Timer)가 만료되었을 경우이다.

여기서 재조합 타이머는 단편화되어 전송되는 패킷 중 일부가 전송 중 손실될 경우, 목적지 호스트가 손실된 패킷의 도착을 영구히 기다리는 상황을 막기 위해 타이머 만료 시간까지 전체 패킷이 도착하지 못했다면 버퍼에서 단편화된 패킷 조각들을 전부 폐기하고, 재전송을 위해 시간 초과 메시지를 보내기 위해 사용된다.

Code 0은 TTL 값의 만료, Code 1은 단편화 재조합 타이머 만료를 나타낸다.

 

Type 12: Parameter Problem. 이 메시지는 IP 데이터그램의 구조에 문제가 있어, 그 패킷을 폐기할 때 전송된다. 또한, Parameter Problem 메시지는 다른 ICMP 메시지에 해당되지 않는 모든 오류에 대해서도 전송되어야 한다.[2]

이 메시지가 가질 수 있는 Code는 다음과 같다.

Typ12-Code-1

Code 0: IP 데이터그램의 구조에 문제가 있음을 나타냄.

Code 1: 필요한 옵션이 정의되지 않음. 미 국방성에서 사용하는 특별한 보안 옵션과 이용됨[3]

Code 2: IP 데이터그램의 Header Length나 Total Packet Length값이 올바르지 않음.

 


각주

 

[1] IANA – ICMP Type Numbers

[2]  RFC 1122 Section 3.2.2.5 – “The ICMP Parameter Problem message is sent to the source host for any problem not specifically covered by another ICMP message.”

[3] RFC 1122  Section 3.2.2.5– “NOTE: This variant is currently in use in the military community for a missing security option.