ICMP Version 4
ICMP 버전 4 프로토콜
- ICMP : Internet Control Message Protocol
- L3의 Support Protocol 중 하나로, 패킷 송수신 중 오류가 발생되어 패킷이 폐기되었음을 Source에게 알리는 데 사용되는 프로토콜이다.
- ICMP 프로토콜 밑에 IP 프토콜이 위치해있는데, 이는 ICMP 메시지가 Frame(L2 패킷)으로 구성될 때, IP 프로토콜을 필히 거치게 됨을 의미한다.
- IGMP는 Multi-Casting을 보조하기 위한 프로토콜이다.
- ARP는 패킷의 NHA 주소에 해당되는 물리 주소로 변환하는 프로토콜이다.
- IP 프로토콜은 패킷 송수신 과정 중 문제가 발생했을 때, 오류를 보고/보정하는 기능을 제공하지 않는다.
※ ICMP 메시지가 Frame으로 구성될 때, IP 프로토콜에 의해 IP-Datagram으로 재구성된다. (IP 헤더가 붙게 된다.)
ICMPv4 Message (ICMPv4 메시지)
- ICMPv4 메시지는 Error-Reporting Message(오류 보고 메시지), Query Message(질의 메시지)로 구성된다.
※ ICMPv6 메시지는 Error-Reporting Message(오류 보고 메시지), Informational Message(정보 메시지)로 구성된다.
- ICMP 메시지의 헤더(두 줄)는 총 8Byte이다.
\(\texttt{Type}\) Field
- 오류의 종류 혹은 이유를 구분짓는 필드이다.
\(\texttt{Code}\) Field
- Type 필드에서 구분지은 종류를 더욱 세분화하 할 필요가 있을 시에 사용하는 필드이다.
\(\texttt{Checksum}\) Field
\(\texttt{Rest of the header}\) Field
- Type에 따라, 여러 내용이 쓰여지는 필드이다.
- 필요에 따라, Rest of the header의 일부 혹은 전체가 사용될 수 있다.
\(\texttt{Data section}\)
- 오류 보고/질의에 따라 들어가는 내용이 다르다.
- 오류 보고 메시지일 경우, Data Section에는 폐기된 패킷의 IP-Header와 메시지의 초반 8Byte (보통, TCP/UDP 헤더)값이 첨부된다.
- Source는 Data Section의 내용을 보고 자신에게 발생한 문제를 진단할 수 있다.
Error-Reporting Message (오류 보고 메시지)
※ ICMP메시지가 오류 보고 메시지로 사용된다면 항상 Original Source에게만 전송된다.
\(\texttt{Type 3 : Destination Unreachable}\)
- 패킷이 목적지의 프로세스에 도달하지 못하여 패킷이 폐기된 상황이다.
- Code : 0에서 15 사이의 값을 갖는다. 즉, 16가지 문제를 분류할 수 있다.
(Code = 2, 3은 목적지 노드와 연관된 문제, 나머지 Code는 라우터와 연관된 문제이다.)
Code = 2 : Unreachable Protocol : 목적지의 IP의 상위 프로토콜에 문제가 발생한 상황이다.
Code = 3 : Unreachable Port : L4의 프로토콜(TCP/UDP) 필드의 목적지 포트 번호에 해당되는 프로세스에 문제가 발생한 상황이다.
- Data Section : 폐기된 패킷의 IP 헤더와 메시지의 초반 8Byte가 첨부된다.
- 중간 경로의 라우터, 목적지 노드가 속한 네트워크*, 목적지 노드**에서 발생할 수 있다.
* Host Unreachable : 목적지 노드의 전원이 꺼져있어 발생하는 형태이다.
** Port Unreachable : 목적지 노드의 해당 프로세스에 문제가 발생한 형태이다. (Code = 2 or 3)
\(\texttt{Type 4 : Source Quench}\)
- 중간 경로의 라우터에서 버퍼 오버플로우가 발생한 상황(Congestion) 혹은,
Source와 Destination 간의 통신 속도 차이로 인한 목적지 Host에서의 버퍼 오버플로우(Flow Problem)가 발생하여 패킷이 폐기된 상황이다.
- Data Section : 폐기된 패킷의 IP 헤더와 메시지의 초반 8Byte가 첨부된다.
- 버퍼 오버플로우가 발생하면, 다수의 패킷이 누락되는데, 누락된 패킷 하나하나에 대한 Quench 메시지가 Source에게 전송된다.
- Source Quench 메시지를 받은 Source는 Quench 메시지를 받지 않을 때까지, 패킷 전송 속도를 낮추게 된다.
※ L4의 TCP 프로토콜에서 Congestion Control(혼잡 제어)과 Flow Control(흐름 제어)를 제공하기 때문에, Source Quench는 ICMPv6에서 사라졌다.
\(\texttt{Tpye 11 : Time Exceeded}\)
- TTL값이 0이된 패킷을 라우터가 폐기한 상황(Code 0)이거나,
Fragmentation된 패킷들 전체가 정해진 시간 내에 목적지 Host에 도착하지 못해 패킷이 폐기된 상황(Code 1)이다.
- Data Section : 폐기된 패킷의 IP 헤더와 메시지의 초반 8Byte가 첨부된다.
\(\texttt{Type 12 : Parameter Problem}\)
- 패킷의 특정 필드에 문제가 생긴 상황(Code 0)이거나,
IP 헤더의 프로토콜 필드를 해석할 수 없는 상황(Unknwon Protocl, Code 1)이다.
- Pointer : 문제가 생긴 필드를 지목한다.
- ICMP 메시지에 문제가 생긴 헤더 부분을 알리는 정보가 첨부된다.
- Data Section : 폐기된 패킷의 IP 헤더와 메시지의 초반 8Byte가 첨부된다.
\(\texttt{Type 5 : Redirection}\)
- 네트워크 상에, 더욱 빠른 경로가 검색된 상황이다. (라우터의 추가 등)
- Code 0 : Network-Specific Route (목적지 노드가 해당되는 네트워크로 메시지를 보내는 모든 경우, 타겟 라우터로 전송할 것을 지시한다.)
- Code 1 : Host-Specific Route (목적지 노드로 메시지를 보낼 경우, 타겟 라우터로 전송할 것을 지시한다.)
- Rest of the header : 더욱 빠른 경로에 해당되는 라우터의 주소이다. (타겟 라우터)
- Data Section : 기전송된 패킷의 IP 헤더와 메시지의 초반 8Byte가 첨부된다.
※ Redirection 상황에서 패킷은 폐기되지 않고 정상적으로 Relaying(전송)된다.
- 일반적인 Host의 라우팅 테이블은 그 크기가 작고 수정이 거의 일어나지 않는다. 이 때문에 네트워크 상의 신설 라우터 정보들을 실시간으로 반영하지 못하는데, 이러한 제약을 인근의 라우터가 Redirection 메세지를 통해 Host에게 알리는 메커니즘이다.
※ Redirection은 본질적으로 오류가 아니므로, ICMPv6에서 Redirection은 Informational Message로 재분류된다.
※ Redirection Message는 Source가 속한 네트워크의 라우터만이 보낼 수 있다.
+ Packet Too Big
- ICMPv6에서 새로 추가된 Error-Reporting Message 타입이다.
- ICMPv6에서는 라우터의 처리 속도를 제고하기 위해, 라우터에서의 Fragmentation을 금지하는 방법을 채택했다.
- Source와 Destionation이 패킷을 주고 받으며, Source는 해당 네트워크 경로 상에서 MTU의 최솟값을 파악하여, 이후에 Destination과 통신할 때엔 MTU의 최솟값으로 미리 Fragmentation된 패킷을 전송한다. (라우터에서 단편화를 진행할 가능성을 원천 봉쇄한다.)
- 예외 상황이 발생하여, 패킷의 길이보다 작은 MTU를 요구하는 경로가 새로 발견되었을 경우에 Packet Too Big 메세지가 Source에게 전송된다.
Query Message (질의 메시지)
- Source와 Destination이 주고받는 메시지로, Request와 Reply 하나의 Pair로 구성된다.
\(\texttt{Type 8 or 0 : Echo Request or Reply}\)
- Source가 Destination에게 보낸 메세지를 Destinatino이 다시 그대로 Source에게 보내는 메시지이다. (Echo-Back)
- Echo Reply 메시지에는 Request 메세지의 Identifier와 Sequence number, Optional data 값이 그대로 복사된다.
- 네트워크 관리자가 IP 프로토콜이 정상적으로 동작하는지를 확인하기 위해 사용하는 메시지 형태이다.
- Timestamp 메시지와 더불어, Echo 메시지를 통해서도 클라이언트가 RTT를 측정할 수 있다.
- 네트워크 관리 프로그램인 Ping에서 Source와 Destination 사이의 네트워크가 원활히 동작하는가를 파악하기 위해 주로 이용되는 메시지 형태이다.
ex) \texttt{A> ping B}
- A가 B에게 Echo Request 메시지를 전송하고, B가 A에게 Echo Reply 메시지를 되돌려보내게 된다.
\(\texttt{Type 13 or 14 : Timestamp Request or Reply}\)
- Source와 Destination의 시간을 동기화하기 위해 사용하는 메시지 형태이다.
- Timestamp Reply 메시지에는 Request 메세지의 Identifier와 Sequence number 값이 그대로 복사된다.
- Timestamp 메시지를 주고 받으며, 클라이언트는 RTT*를 측정할 수 있으며, 서버의 시간과 동기화할 수 있다.
- Timestamp Request or Reply 메시지는 ICMPv6에서 없어진다.
* RTT(Round Trip Time) : 전송된 패킷을 되돌려받기까지 소요되는 시간이다. 타임 서버에서의 처리 시간은 포함되지 않는다.
※ 일반적으로, UNIX, Windows 머신에서 일반 사용자가 접하는 시간의 단위는 ms이다.
※ 클라이언트 머신에서는 오실레이터가 생성하는 CPU 클럭을 일정 상수로 나누어 1ms를 정의한다.
- Timestamp는 3개로 구성된다.
1. Original timestamp
- 클라이언트가 요청을 보낼 때의 시각값이다.
2. Receive timestamp
- 타임 서버가 클라이언트로부터 요청을 받은 시각값이다.
3. Transmit timestamp
- 클라이언트가 타임 서버로부터 응답을 받은 시각값이다.
- Ping 프로그램등을 통해 클라이언트가 계산한 RTT = 67 - 46 - 1(Processing Time) = 20ms
- 즉, RTT와 Timestamp 요청/응답 메시지를 통해 클라이언트의 시계는 서버 시간 보다 3ms 느린것을 파악하여 시계를 3ms만큼 앞당기게 된다.
※ 서버 시간보다 느릴 경우에는 시계를 거꾸로 돌리지 않고, CPU 클럭에 나누는 상수값을 증가시켜서 시스템 자체적으로 잠시동안 시간이 느리게 흐르도록 설정한다.
Network Debugging Tools (네트워크 디버깅 도구)
- 인터넷을 관리하기 위해 사용하는 도구(프로그램)이다.
- 대표적으로 Ping과 Traceroute가 있다.
1. Ping \(\texttt{A> ping B}\)
- 가장 단순한 형태의 Ping : 소스가 Echo Request 메시지를 보내고, 목적지에서 Echo Reply 메시지를 보내고 종료하는 형태이다. (RTT 측정과 IP 프로토콜의 정상 동작 여부(요청/응답 메시지의 정상적인 수신)를 확인할 수 있다.)
- 일반적인 Ping 프로그램은 다수의 Echo Request 메시지를 연달아 송신하고, 그에 따른 Echo Reply 메시지를 수신하는 방식으로 이루어진다.
- 이 때, 다수의 요청 메시지 각각을 분류하기 위해, Sequence number는 송신되는 순서에 따라 1씩 증가된다.
(같은 Ping 프로그램 내의 메시지들의 Identifier값은 서로 동일하다.)
- Host가 Interrupt를 발생(CTRL+C)시키기 전까지, Echo 요청 메시지를 계속해서 보내게 된다.
- Interrupt가 발생되면, 기존에 보내졌던 요청 메시지들에 대한 응답 메시지만 수신하게 된다.
- 응답 메시지는 요청 메시지가 송신된 순서대로 받는다는 보장이 없다. (ID와 개별적인 Sequence Number가 필요한 이유)
2. Traceroute \(\texttt{A> traceroute B}\)
- 목적지(B)에 UDP 패킷을 계속해서 보내는 데, 매 회 TTL 값을 1씩 증가시켜서 전송한다. (초기 TTL 값은 1이다.)
- 전송되는 패킷의 포트번호는 UDP가 지원하지 않는 것으로 사용하여 B에서 Destination Unreachable ICMP(Code: Unreachable Port) 오류 메시지를 수신하도록 유도한다.
- 위와 같은 방식으로 B에게 메시지를 순차적으로 전송하면, 해당 경로에 있는 라우터와 B로부터 ICMP 오류 메시지를 수신하게 되고, 해당 오류 메시지의 정보를 바탕으로 네트워크상의 전송 경로를 파악할 수 있게 된다.
※ IP 옵션 중 Record-Route 옵션으로는 traceroute 기능을 구현할 수 없다. Record-Route 옵션에서는 최대 9개의 라우터 주소만 저장할 수 있기 때문이다.
ICMP Package (ICMP 패키지)
1. Input Module (입력 모듈)
- 오류 보고 메시지, Request 메시지, Reply 메시지가 입력될 수 있다.
- 오류 보고 메시지는 해당 프로토콜이 위치한 계층으로 전달된다. (상위 계층으로 향한다.)
- Request 메시지가 수신되면, 그에 따른 Reply 메시지를 생성하여 해당 노드에게 전송한다. (하위 계층으로 향한다.)
- Reply 메시지가 수신되면, 해당 프로세스에게 전달된다. (상위 계층으로 향한다.)
ICMP_Input_Module (ICMP_Packet) {
// 요청 메시지를 수신한 경우
if (the type is a request){
Create a reply
Send the reply
}
// 응답 메시지를 수신한 경우
if (the type is a reply)
Send the reply to the process that requested it
// 리디렉션 메시지를 수신한 경우
if (the type defines a redirection)
Modify the routing table
// 오류 보고 메시지를 수신한 경우
if (the type defines other error messages)
Inform the appropriate source protocol
return
}
2. Output Module (출력 모듈)
- Request 메시지, 오류 보고 메시지를 출력할 수 있다.
- Request 메시지는 상위 계층의 Ping 메시지, Timestamp 메시지가 될 수 있다.
- 오류 보고 메시지는 L4의 TCP 혹은 UDP에서 발생한 오류, L3의 IP에서 발생한 오류에 관한 메시지가 될 수 있다.
ICMP_Output_Module (demand) {
// 오류 메시지인 경우
if (the demand defines an error message){
if (demand comes from IP AND is forbidden) // IP에서 발생한 오류에 대한 메시지를 송신하는 것이 금지되어 있는 경우
return
Create an error message
}
// 요청 메시지인 경우
if (demand defines a request)
Create a request message // 해당하는 ICMP 요청 메시지를 생성한다.
Send the message
return
}IP에서 발생한 오류 중 메시지 송신이 금지된 오류
1. ICMP 메시지를 전달하는 IP 패킷
- IP 패킷이 전달되는 과정에서 오류가 발생하면, 그에 따른 ICMP 오류 메시지가 IP 패킷에 캡슐화되어 전달되게 되는데, 이 ICMP 오류 메시지에 오류가 발생되는 경우에는 오류 사실을 알리지 않는다.
- 즉, ICMP 오류 메시지에 대한 오류 메시지는 따로 송신하지 않는다.
2. Fragmentation된 IP 패킷
3. Multicast IP 패킷
- 목적지 주소가 Multicast 주소 형태인 패킷을 의미한다.
- Multicast 방식의 경우, 다수의 Receiver가 있을 수 있는데, Source가 보낸 하나의 메시지에 대한 오류가 여러 Receiver에게서 동시다발적으로 발생했을 때, 오류 메시지를 Source에게 보낼 경우, Source는 수많은 오류 메시지를 한꺼번에 받게 된다. (흡사 Dos 공격을 받는 것과 비슷한 상황이 연출된다.)
- 그러므로, 멀티 캐스팅 방식에서 오류가 발생할 경우, 별다른 오류 메시지를 Source에게 전달하지 않는다.
4. 특수 주소를 가진 IP 패킷 (0.0.0.0 혹은 127.X.Y.Z 형태 주소)
- 0.0.0.0은 주로 DHCP 프로토콜에서 자신의 IP 주소를 표현할 때 사용하는 주소로, 0.0.0.0을 Source 주소로 사용할 수 없으므로, ICMP 메시지의 목적지가 될 수 없다.
- 127.X.Y.Z는 Loop-Back 주소로 한 머신 내에서의 목적지 주소로만 사용된다. 이로 인해, 네트워크 상에서 ICMP 메시지의 목적지가 될 수 없다.
Reference: TCP/IP Protocol Suite 4th Edition
(Behrouz A. Forouzan 저, McGraw-Hill, 2010)
Reference: Data Communications and Networking 5th Edition
(Behrouz A. Forouzan 저, McGraw-Hill, 2012)
