[Network Layer] ICMPv4 (Internet Control Message Protocol Version 4)

ICMP의 필요성

IP 프로토콜의 한계

• IP는 오류 보고(error reporting)와 수정(error correction) 기능이 없음

예시 상황

• 라우터가 목적지로 가는 경로를 못 찾거나,
• TTL(Time to Live) 값이 0이 되어 데이터그램을 버려야 할 때
  → IP 자체로는 아무 조치도 못 함
• 목적지 호스트가 단편화된 조각들을 시간 내에 모두 받지 못해서 버릴 때도
  → 마찬가지로 IP는 반응할 수 없음
• IP는 호스트 상태 조회, 라우터 정보 확인 등 관리 쿼리 기능도 없음

해결책

• ICMP(Internet Control Message Protocol)는 위 문제들을 보완하기 위해 설계됨
  → IP의 오류 보고 및 네트워크 관리 기능 제공 (에러 report를 source host에게 전달)

IP는 오류 처리 및 관리 기능이 없어, 이를 보완하기 위해 ICMP가 설계되었다.

---

ICMP encapsulation

• ICMP 메시지는 IP 프로토콜에 의해 캡슐화되어 전송됨
  → 즉, IP 패킷의 데이터 부분에 ICMP 메시지가 들어간다

---

ICMP 메시지 종류

1.  오류 보고 메시지 (Error-reporting messages)

• IP가 발생시킬 수 있는 문제(예: 목적지 도달 불가, TTL 만료 등)를
  → 출발지에 알려주는 메시지

2. 질의 메시지 (Query messages)

• 호스트나 네트워크 관리자들이
  → 다른 호스트나 라우터에 특정 정보를 요청하거나
  → 네트워크 내 이웃을 발견하는 데 사용
• 라우터는 호스트에게 더 나은 경로를 알려주는 것도 가능함

ICMP는 오류를 출발지에 알리는 메시지와, 정보를 묻는 질의 메시지로 나뉘며 IP에 캡슐화되어 전송된다.

---

ICMP 메시지 포맷

ICMP 메시지의 전체 구성

• 총 8바이트의 고정 헤더 + 가변 크기의 데이터 영역
• IP의 Data field에 들어감

ICMP header

ICMP 헤더의 필드 구성

Type (타입)

• 메시지의 종류를 나타냄

 

Code (코드)

• 해당 타입의 세부 사유를 나타냄

Checksum (체크섬)

• 메시지의 오류 검출용 필드
• 송수신자가 데이터가 손상되지 않았는지 확인 가능

나머지 필드들

• 이 부분은 타입에 따라 달라짐

ICMP 메시지는 Type, Code, Checksum으로 시작되며, 타입에 따라 헤더 이후 필드와 데이터 내용이 달라진다.

---

Error Reporting Messages

• ICMP는 오류를 보고만 할 뿐 수정하지 않음
• IP 프로토콜 자체는 오류 제어 기능이 없음
• ICMP는 오류를 탐지하면 원래 송신자에게 알려줌
• 오류 수정은 상위 계층 프로토콜(TCP 등)에 맡김

오류 메시지는 항상 원래의 출발지 호스트에게 전송됨

• IP 헤더에 출발지 IP 주소가 있으므로

ICMP가 처리하는 5가지 주요 오류 유형

1. Destination Unreachable (목적지 도달 불가)
2. Source Quench (출발지 혼잡 알림)
3. Time Exceeded (시간 초과됨)
4. Parameter Problem (헤더에 잘못된 정보 존재)
5. Redirection (라우팅 경로 재지정)

ICMP 오류 메시지가 발생하지 않는 경우들

1. ICMP 오류 메시지를 포함한 데이터그램에 대해선 또 오류 메시지를 생성하지 않음 (ICMP에 대한 ICMP X)
2. 첫 번째 조각이 아닌 나머지 조각들에 대해서는 오류 메시지 발생 안 함 (첫번째 fragment만 ICMP 생성)
3. 멀티캐스트 주소를 가진 데이터그램에 대해서는 오류 메시지 생성 안 함 (다수 사용자에는 해당 X)
4. 127.0.0.1 (loopback)이나 0.0.0.0 (알 수 없는 주소) 같은 특수 주소에 대해서도 오류 메시지 발생 안 함

오류 메시지의 데이터 영역에는

• 원래 IP 헤더 + 해당 데이터그램(IP Data field)의 처음 8바이트가 포함됨
  → TCP/UDP 포트 정보 또는 TCP 시퀀스 번호 확인 가능

[ ICMP Header (8 bytes) ]
[ 원래 IP Header (≥20 bytes) ]
[ 원래 IP Data의 처음 8 bytes ]

• 결론적으로 ICMP 오류 메시지 구조는 다음과 같다

ICMP는 오류를 보고할 뿐 수정하지 않으며, 특정 조건에서는 오류 메시지를 생성하지 않는다.

ICMP Error Type 3: Destination Unreachable(목적지 도달 불가)

• 라우터나 호스트가 데이터그램을 목적지로 보낼 수 없을 때 발생
• 원래 송신자에게 오류 메시지를 되돌려 보냄
• 세부 사유는 code 값(0~5)으로 구분됨

코드별 의미

Code	의미	설명
0	Network unreachable	목적지 네트워크 자체를 찾을 수 없음 (예: 숭실대 네트워크 자체를 찾지 못함)
1	Host unreachable	네트워크는 도달했지만, 해당 IP 호스트는 도달 불가 (예: 숭실대 네트워크는 찾았지만, host를 못 찾음)
2	Protocol unreachable	해당 호스트에 도착했지만, 상위 계층 프로토콜(예: TCP, UDP 등)이 실행되지 않음
3	Port unreachable	애플리케이션(프로세스)이 해당 포트를 사용하지 않고 있음 (program이 꺼져있음)
4	Fragmentation needed but DF set	단편화가 필요한데, Flags의 2번째 비트 DF(Don’t Fragment)가 1로 설정되어 있어 전송 불가
5	Source routing failed	Source Routing 옵션에 따라 지정된 경로를 따르려 했지만 중간 라우터 중 일부에 도달하지 못함 (Strict-Source-Route Option을 지키지 못함)

ICMP Error Type 4: Source Quench (출발지 억제 메시지)

• IP는 원래 혼잡 제어 기능이 없음
• 그래서 ICMP는 Source Quench 메시지를 만들어, 라우터나 호스트가 혼잡 상태일 때 송신자에게
  → "속도 좀 줄여줘"라고 요청하는 역할
• 라우터나 호스트가 혼잡으로 인해 데이터그램을 버릴 경우
  → 송신자에게 Source Quench 메시지를 보냄

🚫 지금은 사용되지 않음

• 1980년대 이후, 혼잡 제어는 TCP가 완전히 맡게 되면서
  → Source Quench는 폐기됨 (비표준)

ICMP Type 11: Time Exceeded (시간 초과)

TTL(Time to Live) 초과

• IP 데이터그램에는 TTL 필드가 있음
• 각 라우터를 지날 때마다 TTL이 1씩 감소
• TTL이 0이 되면, 라우터는 데이터그램을 폐기하고 송신자에게 Time Exceeded 메시지를 보냄

단편화 조각 시간 초과

• 하나의 데이터그램이 여러 조각으로 나뉘어 도착하는 경우에서 일정 시간 내에 모든 조각이 도착하지 않으면 → 전체 폐기
• 이 경우에도 Time Exceeded 메시지 전송

Traceroute (using Time Exceeded, TTL)

• 출발지 → 목적지까지 패킷이 거치는 경로를 추적하는 명령어 도구
• UNIX or Windows에서 결로를 추적할 수 있게끔 해줌

작동 원리

• traceroute는 ICMP 메시지 + TTL(Time To Live)을 이용함
• 처음에는 TTL = 1로 설정한 패킷 전송
  → 첫 번째 라우터에서 TTL 0 → 폐기 → ICMP Time Exceeded 응답 받음
• 이후 TTL을 1씩 증가시키며 계속 전송
  → 각 홉(hop)을 지날 때마다 해당 라우터의 IP 주소와 응답 시간을 수집
• 각 줄은 한 홉(라우터)을 나타냄
• 괄호 안은 라우터의 IP
• 각 숫자는 해당 홉에서의 응답 시간(ms)

traceroute는 TTL을 활용해 각 라우터의 응답을 받아 경로를 추적하며, 네트워크 경로 진단에 유용하다.

 

ICMP Type 12: Parameter Problem (헤더 파라미터 오류)

• IP 헤더 안에 잘못된 값(해석 불가한 필드)이 있으면 발생
• 예: 옵션 필드가 이상하거나 예약된 비트를 잘못 썼을 경우
• 이 오류도 송신자에게 ICMP 메시지로 보고됨

ICMP Type 5: Redirection (경로 재지정)

• 인터넷에는 호스트 수가 라우터보다 훨씬 많기 때문에,
  → 호스트들이 동적으로 라우팅 테이블을 유지하면 오히려 트래픽 부담이 큼
  → 그래서 일반 호스트는 보통 정적 라우팅만 사용함
  → 즉, 기본 라우터 하나만 알고 있음

문제 상황

• 호스트가 잘못된 라우터로 데이터그램을 보냈을 경우, 그 라우터는 올바른 라우터로 전달은 해주지만
  → 동시에 ICMP Redirection 메시지를 원래 호스트에 보냄
  → "다음부터는 이 라우터로 직접 보내"라고 알려주는 것

Example

• 호스트 A는 기본 게이트웨이 R1만 알고 있음
• A가 목적지에 대해 잘못된 라우터로 패킷을 보냄 (R1)
• R1은 진짜 라우터 R2에게 넘기고,
  → A에게 Redirection 메시지를 보내 "R2로 바로 보내"라고 알려줌

ICMP Type 3 오류는 목적지 네트워크, 호스트, 포트, 프로토콜 문제 등으로 인한 전송 실패를 구체적인 코드로 구분해 보고한다.
Source Quench는 송신자에게 전송 속도를 줄이라는 메시지였지만, 현재는 더 이상 사용되지 않는다.
Time Exceeded는 TTL이나 조각 수신 시간 초과 시 발생하며, Parameter Problem은 헤더의 잘못된 값으로 인한 오류를 보고한다.
Redirection 메시지는 호스트가 잘못된 라우터를 사용했을 때, 라우터가 더 나은 경로를 알려주기 위해 사용된다.

 

---

Query Messages

ICMP Type 8 or 0: Echo Request and Reply

• 진단(diagnostic) 목적
• 두 시스템(호스트/라우터 포함)이 통신 가능한지 확인할 수 있게 해줌
• 이 메시지를 통해:
  • 상대가 살아 있는지 확인 가능 (alive check)
  • 네트워크 연결 상태 확인

작동 방식

• Echo Request (Type 8, Code 0):
  → 송신자가 전송하는 "너 거기 있어?" 메시지
• Echo Reply (Type 0, Code 0):
  → 수신자가 응답하는 "응, 나 여기 있어!" 메시지
• 이 구조를 활용한 도구가 바로 ping

Ping

• 목적지 호스트가 살아 있는지 확인하는 도구
• ICMP Echo Request(Type 8) 메시지를 보내고
  → 상대가 Echo Reply(Type 0)를 보내면 응답 성공

동작 과정

1. 송신자는 Echo Request에 전송 시간(Timestamp)을 담음
2. 수신자가 Echo Reply를 보낼 때 그 메시지를 그대로 되돌림
3. 송신자는 Echo Reply를 수신한 순간
   → 현재 시간 - 전송 시간으로 RTT(Round-Trip Time, 왕복 지연 시간)을 계산함

• icmp_seq: ICMP 메시지 순번
• ttl: 수신 시 남은 TTL 값
• time: RTT (왕복 지연 시간)

 

Echo Request/Reply는 호스트 간 연결 상태를 확인하는 데 사용되며, ping 명령의 기반이 된다.