[🌐CN] ICMP - Internet Control Message Protocol

Posted Sep 29, 2025 Updated Sep 29, 2025

By xmoonanx

23 min read

🌐 Internet Protocol 전공 수업 정리

IP는 Best Effort 서비스로 패킷 손실이나 오류를 보장하지 않는다. 그렇다면 네트워크에서 발생하는 문제들을 어떻게 진단할 수 있을까? ICMP는 IP의 보조 프로토콜로, 에러 리포팅과 네트워크 진단을 담당한다.

ICMP의 필요성

Error/Status Reporting의 중요성

📚Silent Failure Problem: IP는 Best Effort 서비스로 에러 발생 시 알림 없이 패킷을 조용히 버릴 수 있음 → 진단이 매우 어려움!

라우터가 직면하는 에러 상황:

┌─────────────────────────────────────────────────────┐
│ ❌ 라우터가 패킷을 어디로 포워딩할지 모름            │
│ ❌ TTL(Hop count)이 만료됨                           │
│ ❌ 패킷이 링크의 MTU보다 너무 큼                     │
└─────────────────────────────────────────────────────┘

왜 에러 보고가 필요한가?

✅ IP는 Best Effort → 에러 알림 의무 없음
❌ 그러나 Silent Failure는 디버깅이 불가능!
✅ 해결책: ICMP로 에러 상황 전달

Best Effort의 의미: “Never having to say you’re sorry” - 하지만 실제로는 에러 보고가 필수적!

ICMP 개요

ICMP란?

📚ICMP (Internet Control Message Protocol): IP를 보조하는 프로토콜로 에러 리포팅과 간단한 쿼리 기능을 제공

IP 보조 프로토콜 구조:

        ┌─────────────────────────────────────┐
        │         Routing Protocols           │
        │  RIP    OSPF    BGP    PIM          │  ← 라우팅 테이블 구성
        └─────────────────────────────────────┘

        ┌─────────────────────────────────────┐
        │       Control Protocols             │
        │     ICMP           IGMP             │  ← 제어 메시지
        └─────────────────────────────────────┘

        ┌─────────────────────────────────────┐
        │              IP                     │
        └─────────────────────────────────────┘

ICMP의 계층적 위치

TCP/IP Stack에서의 위치:

┌──────────────────────────────────────┐
│  Application (Telnet, FTP, HTTP...)  │
├──────────────────────────────────────┤
│  Transport (TCP, UDP)                │
├──────────────────────────────────────┤
│  Network (IP)     ┌─────────┐        │
│                   │  ICMP   │ ◄────  IP 위에서 동작하지만
└───────────────────┴─────────┴────────┘    IP의 일부로 간주됨!
│  Data Link (Ethernet, WiFi...)       │
└──────────────────────────────────────┘

핵심 특징:

Runs on top of IP: TCP/UDP와 같은 레벨
Integral part of IP: Transport가 아닌 IP의 필수 구성 요소
Protocol Field = 1: IP 헤더에서 ICMP 식별

ICMP 메시지 구조

ICMP 헤더 포맷

bit # 0       7 8      15 16    23 24                            31
├──────┬────────┼─────────┼──────────────────────────────────────┤
│ Type │  Code  │       Checksum                                 │
│(1 byte)│(1 byte)│      (16 bits)                                │
├──────┴────────┴─────────┴──────────────────────────────────────┤
│              Rest of the header (4 bytes)                      │
├────────────────────────────────────────────────────────────────┤
│                                                                │
│                     Data section                               │
│                                                                │
└────────────────────────────────────────────────────────────────┘

헤더 필드:

필드	크기	설명
Type	1 byte	ICMP 메시지 타입
Code	1 byte	ICMP 메시지 서브타입
Checksum	2 bytes	전체 ICMP 메시지에 대한 체크섬 (IP와 유사)

최소 크기: 8 bytes (추가 데이터 없을 경우 4 bytes는 0으로 채움)

ICMP 캡슐화

IP Datagram 내부 구조:

┌──────────────┬────────────────────────────────────┐
│  IP Header   │         IP Payload                 │
│              │      (ICMP Message)                │
└──────────────┴────────────────────────────────────┘

ICMP Message 상세:
┌──────┬──────┬──────────┬─────────────────────────┐
│ Type │ Code │ Checksum │    Data Section         │
└──────┴──────┴──────────┴─────────────────────────┘

ICMP 메시지 타입

Error-Reporting vs Query Messages

ICMP 메시지 분류:

                    ICMP Messages
                         │
         ┌───────────────┴───────────────┐
         │                               │
    Error-Reporting                   Query
         │                               │
  ┌──────┴──────┐              ┌────────┴────────┐
  │Type 3, 4,   │              │Type 8/0, 13/14  │
  │5, 11, 12    │              │17/18, 9/10      │
  └─────────────┘              └─────────────────┘

ICMP 타입 전체 목록

Type	Code	Message	분류	설명
0	0	Echo Reply	Query	Ping 응답
3	0-15	Destination Unreachable	Error	목적지 도달 불가
4	0	Source Quench	Error	혼잡 제어 (현재 사용 안 함)
5	0-3	Redirect	Error	라우팅 경로 변경 알림
8	0	Echo Request	Query	Ping 요청
9	0	Router Advertisement	Query	라우터 알림
10	0	Router Solicitation	Query	라우터 요청
11	0, 1	Time Exceeded	Error	TTL 만료 또는 재조립 타임아웃
12	0, 1	Parameter Problem	Error	IP 헤더 오류
13	0	Timestamp Request	Query	시간 정보 요청
14	0	Timestamp Reply	Query	시간 정보 응답
17	0	Address Mask Request	Query	서브넷 마스크 요청
18	0	Address Mask Reply	Query	서브넷 마스크 응답

ICMP Error Messages

Error 메시지의 동작 원리

에러 발생 시 흐름:

Host A                Router                    Host B
  │                      │                         │
  ├──── IP Datagram ────►│                         │
  │                      │ (문제 발생: TTL=0,      │
  │                      │  목적지 unreachable 등) │
  │                      │                         │
  │                      ├─ Drop Datagram          │
  │                      │                         │
  │◄── ICMP Error ───────┤                         │
  │    Message           │                         │

Error 메시지 데이터 섹션

📚Error Message Content: 원본 패킷의 IP 헤더 + 첫 8 bytes payload를 포함하여 에러 원인 추적 가능

Error 메시지 구조:

┌──────────────┬──────────────┬──────────────┬─────────────────┐
│  IP Header   │ ICMP Header  │  IP Header   │ 8 bytes payload │
│  (new)       │              │  (original)  │  (original)     │
└──────────────┴──────────────┴──────────────┴─────────────────┘
                               └──────────────┬─────────────────┘
                                   에러가 발생한 원본 패킷 정보

ICMP Header:

┌──────┬──────┬──────────┬────────────────────────┐
│ Type │ Code │ Checksum │   Unused (0x00000000)  │
└──────┴──────┴──────────┴────────────────────────┘

왜 8 bytes payload?

TCP/UDP 헤더의 Source Port, Destination Port 포함 (각 2 bytes)
호스트가 어떤 소켓/애플리케이션과 관련된 에러인지 식별 가능

ICMP Error 발생 제한 조건

다음 경우에는 ICMP Error 메시지를 생성하지 않음:

❌ No ICMP Error for:

1. ICMP 에러 메시지를 전달하는 datagram
   → 무한 루프 방지!

2. Fragment가 첫 번째가 아닌 datagram
   → 첫 fragment만 에러 보고

3. Broadcast/Multicast 주소를 가진 datagram
   → 네트워크 폭주 방지

4. 특수 주소 (127.0.0.0, 0.0.0.0)를 가진 datagram

5. IP Checksum 에러가 있는 datagram

주요 Error 메시지 상세

Type 3: Destination Unreachable

📚Destination Unreachable: IP datagram이 목적지에 전달되지 못하고 폐기되었음을 알림

Code 값별 의미:

Code	설명	생성 주체
0	Network is unreachable	Router
1	Host is unreachable	Router
2	Protocol is unreachable	Host
3	Port is unreachable	Host
4	Fragmentation required but DF set	Router
5	Source routing not feasible	Router
6	Destination network unknown	Router
7	Destination host unknown	Router
8	Source host isolated	Router
9	Network administratively prohibited	Router
10	Host administratively prohibited	Router
11	Network unreachable for TOS	Router
12	Host unreachable for TOS	Router
13	Communication administratively prohibited	Router
14	Host precedence violation	Router
15	Precedence cutoff in effect	Router

라우터 vs 호스트: Code 2, 3만 호스트가 생성, 나머지는 라우터가 생성!

Code 3: Port Unreachable

발생 시나리오:

Client                              Server
  │                                    │
  ├─── UDP to port 80 ───────────────►│
  │                                    │ ❌ No process listening
  │                                    │    on port 80
  │                                    │
  │◄──── ICMP Port Unreachable ───────┤
  │      (Type=3, Code=3)              │

RFC 792 규정:

“목적지 호스트에서 IP 모듈이 프로토콜 모듈이나 프로세스 포트가 active하지 않아 datagram을 전달할 수 없으면, destination unreachable 메시지를 전송할 수 있다.”

실제 예시:

  
bsdi % tftp
tftp> connect svr4 8888
tftp> get temp.foo
Transfer timed out.

# tcpdump 출력:
bsdi.2924 > svr4.8888: udp 20
svr4 > bsdi: icmp: svr4 udp port 8888 unreachable

Type 5: Redirect

📚ICMP Redirect: 더 나은 경로가 있을 때 호스트의 라우팅 테이블을 업데이트하도록 알림

발생 상황:

특수한 상황: 같은 네트워크에 여러 라우터가 있을 때

                        ┌────┐
                ┌───────│ R1 │─────────┐
                │       └────┘         │
                │                      │
        ┌────┐  │                      │  Internet  ┌────┐
        │ S  │──┤                      ├───────────►│ D  │
        └────┘  │       ┌────┐         │            └────┘
                └───────│ R2 │─────────┘
                        └────┘

문제: Default Router = R1이지만, D로 가려면 R2가 더 빠름!

Redirect 동작:

S가 R1으로 패킷 전송
R1이 R2가 더 나은 경로임을 발견
R1이 S에게 ICMP Redirect (Type=5) 전송
S의 라우팅 테이블 업데이트: D → R2

Code 값:

Code	설명
0	Redirect for network
1	Redirect for host
2	Redirect for type-of-service and network
3	Redirect for type-of-service and host

Type 11: Time Exceeded

📚Time Exceeded: TTL이 0에 도달하거나 Fragment 재조립 타임아웃 발생

Code 값:

Code	설명	용도
0	Time-to-live equals 0 during transit	Traceroute
1	Time-to-live equals 0 during reassembly	Fragment 타임아웃

TTL 동작 예시:

패킷 경로:
  Host A (TTL=64) → R1 (TTL=63) → R2 (TTL=62) → ... → Destination

TTL=0이 되면:
  Router ──► Drop Packet
         │
         └─► Send ICMP Time Exceeded to Source

Wireshark 예시:

Internet Control Message Protocol
  Type: 11 (Time-to-live exceeded)
  Code: 0 (Time to live exceeded in transit)
  Checksum: 0xecbe [correct]
  Unused: 00000000

Internet Protocol Version 4, Src: 192.168.0.2, Dst: 192.168.1.2
User Datagram Protocol, Src Port: 33289, Dst Port: 44444

Type 12: Parameter Problem

발생 경우:

Code	설명
0	IP header bad (catchall error)
1	Required option missing

ICMP Query Messages

Query 메시지의 특징

Query vs Error:

Error Message:              Query Message:
┌──────────┐                ┌──────────┐
│ One-way  │                │ Request  │
│ (에러 통보)│                │   +      │
└──────────┘                │ Reply    │
                            └──────────┘

Query 종류:

                    Query Messages
                         │
      ┌──────────────────┼──────────────────┐
      │                  │                  │
   Echo            Timestamp         Address Mask
 (Type 8/0)        (Type 13/14)      (Type 17/18)
      │                  │                  │
   Router Solicitation/Advertisement
        (Type 10/9)

Type 8/0: Echo Request/Reply (Ping)

Ping의 동작 원리

📚Ping: 네트워크 연결성 테스트 도구, ICMP Echo Request/Reply 사용

Ping 동작:

Host A                              Router/Host B
  │                                       │
  ├───── ICMP Echo Request (Type=8) ─────►│
  │                                       │
  │                                   Kernel이
  │                                   직접 처리
  │                                       │
  │◄──── ICMP Echo Reply (Type=0) ────────┤
  │                                       │

핵심 특징:

✅ Kernel에서 직접 처리 (Application Layer 불필요)
✅ 매우 빠른 응답
✅ 라우터와 호스트 모두 응답 가능

Echo Request/Reply 포맷:

┌──────┬──────┬──────────┬────────────┬──────────────┐
│ Type │ Code │ Checksum │ Identifier │Sequence Number│
│ 8/0  │  0   │          │  (2 bytes) │   (2 bytes)  │
└──────┴──────┴──────────┴────────────┴──────────────┘
┌──────────────────────────────────────────────────────┐
│              Optional Data (가변 길이)               │
└──────────────────────────────────────────────────────┘

Identifier & Sequence Number:

Identifier: Ping 프로세스 식별
Sequence Number: 각 요청/응답 쌍을 매칭

Type 13/14: Timestamp Request/Reply

Timestamp 메시지

📚Timestamp: 시스템 간 시간 정보 교환 및 Round-Trip Time 측정

포맷:

┌──────────┬──────┬──────────┬────────────┬──────────────┐
│   Type   │ Code │ Checksum │ Identifier │Sequence Number│
│ 13 or 14 │  0   │          │            │              │
└──────────┴──────┴──────────┴────────────┴──────────────┘
┌──────────────────────────────────────────────────────────┐
│         32-bit Originate Timestamp                       │
│         (요청 전송 시간)                                  │
└──────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────┐
│         32-bit Receive Timestamp                         │
│         (요청 수신 시간)                                  │
└──────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────┐
│         32-bit Transmit Timestamp                        │
│         (응답 전송 시간)                                  │
└──────────────────────────────────────────────────────────┘

시간 형식:

UTC (Universal Coordinated Time) 자정 이후 경과 milliseconds
32-bit → 약 24시간 주기로 overflow

용도:

시스템 시계 동기화 (NTP의 전신)
Round-Trip Time (RTT) 측정

네트워크 경로 탐색

Path MTU Discovery

📚PMTU (Path MTU): End-to-end 경로상의 최소 MTU

문제 상황:

Host A                Router C               Host B
MTU=1500   MTU=1500   MTU=1400   MTU=1300
   │           │          │           │
   ├─ 1500B ──►│          │           │
   │           ├─ 1500B ─►│           │
   │           │          │ ❌ Too big!│
   │           │          │           │

RFC 1191 해결 방법:

Step 1: DF (Don't Fragment) 비트 설정하고 전송

Step 2: MTU 초과 시 ICMP 수신
  ┌─────────────────────────────────────────┐
  │ Type: 3 (Destination Unreachable)       │
  │ Code: 4 (Fragmentation needed but DF    │
  │          set)                            │
  │ MTU of next hop: 1400 ◄─── 중요!        │
  └─────────────────────────────────────────┘

Step 3: 더 작은 MTU로 재전송

Step 4: 성공할 때까지 반복

PMTU Discovery 과정:

Host A                                      Host E
  │                                            │
  ├─── Packet (MTU=1500, DF=1) ───────────────► ❌
  │                                            │
  │◄── ICMP: Use MTU=1400 ─────────────────────┤
  │                                            │
  ├─── Packet (MTU=1400, DF=1) ───────────────► ❌
  │                                            │
  │◄── ICMP: Use MTU=1300 ─────────────────────┤
  │                                            │
  ├─── Packet (MTU=1300, DF=1) ───────────────► ✅
  │                                            │
  │◄─────── Packet received ───────────────────┤

Wireshark 예시:

Internet Control Message Protocol
  Type: 3 (Destination unreachable)
  Code: 4 (Fragmentation needed)
  Checksum: 0x3147 [correct]
  Unused: 0000
  MTU of next hop: 1400 ◄─── 다음에 사용할 MTU!

Traceroute

Traceroute 원리

📚Traceroute: 패킷이 목적지까지 거치는 모든 라우터의 경로를 추적하는 도구

TTL을 이용한 경로 탐색:

TTL의 동작:
  ┌─────┐       ┌─────┐       ┌─────┐       ┌─────┐
  │ Src │       │ R1  │       │ R2  │       │ Dst │
  └──┬──┘       └──┬──┘       └──┬──┘       └──┬──┘
     │             │             │             │
     ├─ TTL=1 ────►│             │             │
     │             ├─ TTL=0 ❌   │             │
     │◄─ ICMP ─────┤             │             │
     │   R1 식별   │             │             │
     │             │             │             │
     ├──── TTL=2 ──┼────────────►│             │
     │             │             ├─ TTL=0 ❌   │
     │◄─── ICMP ───┼─────────────┤             │
     │      R2 식별│             │             │
     │             │             │             │
     ├──── TTL=3 ──┼─────────────┼────────────►│
     │             │             │             │ ✅ 도착

Traceroute 알고리즘:

TTL=1로 패킷 전송 → 첫 번째 라우터에서 Time Exceeded 수신
TTL=2로 패킷 전송 → 두 번째 라우터에서 Time Exceeded 수신
TTL=n로 패킷 전송 → 목적지 도달까지 반복

각 홉에서 받는 정보:

ICMP Time Exceeded 메시지:
  ┌─────────────────────────────────────┐
  │ Type: 11 (Time Exceeded)            │
  │ Code: 0 (TTL expired in transit)    │
  │ Source IP: 라우터의 IP 주소 ◄─ 중요! │
  └─────────────────────────────────────┘

Traceroute 실행 예시

명령어:

$ traceroute www.whitehouse.gov

출력 결과:

traceroute to www.whitehouse.gov (204.102.114.49), 30 hops max, 40 byte packets

cory115-1-gw.EECS.Berkeley.EDU (128.32.48.1)
829 ms  0.660 ms  0.565 ms

cory-cr-1-1-soda-cr-1-2.EECS.Berkeley.EDU (169.229.59.233)
953 ms  0.857 ms  0.727 ms

soda-cr-1-1-soda-br-6-2.EECS.Berkeley.EDU (169.229.59.225)
461 ms  1.260 ms  1.137 ms

g3-8.inr-202-reccev.Berkeley.EDU (128.32.255.169)
402 ms  1.298 ms  *  ◄─── Lost Reply (라우터가 ICMP 안 보냄)

* * *  ◄─── 이 라우터는 ICMP를 보내지 않도록 설정됨

a204-102-114-49.deploy.akamaitechnologies.com (204.102.114.49)
137 ms  14.905 ms  19.730 ms  ◄─── Final Hop (목적지 도달!)

각 줄의 의미:

Hop #  Hostname (IP Address)  RTT1  RTT2  RTT3
  │         │                  │     │     │
  │         │                  └─────┴─────┴─ 세 번의 측정값
  │         └─ 해당 라우터의 주소
  └─ 홉 카운트 (TTL 값)

특수 표시:

* : 응답 없음 (Timeout 또는 ICMP 차단)
No PTR record: DNS 역방향 조회 실패

Ping & Traceroute Q&A

자주 묻는 질문

Q: Ping은 라우터에 의해 포워딩되나요?

A: ✅ Yes! 그래서 인터넷 어디에나 ping을 보낼 수 있습니다.

Client ──► Router 1 ──► Router 2 ──► Server
   │                                    │
   └──── Ping은 모든 라우터를 통과 ──────┘

Q: 모든 장비가 Ping에 응답하나요?

A: ❌ No! 보안상의 이유로 많은 장비가 ICMP를 차단합니다.

차단 이유:
보안: DoS 공격 방지
정책: 네트워크 구조 숨김
성능: ICMP 처리 부담 감소

Q: 라우터가 다른 장비로 가는 Ping을 포워딩하지 않을 수 있나요?

A: ✅ Yes! 라우터는 다음과 같이 설정 가능:

Ping 응답 안 함 (자신에 대한)
Ping 포워딩 안 함 (다른 장비로 가는)

ICMPv6 (IPv6용 ICMP)

ICMPv4와의 차이점

📚ICMPv6: IPv6용으로 확장된 ICMP, ARP와 IGMP 기능까지 통합

주요 변경 사항:

ICMPv4 → ICMPv6 변화:

✅ 유지:
  - Error message (Destination Unreachable, Time Exceeded 등)
  - Query request/response (Echo, Timestamp 등)

❌ 제거:
  - 사용하지 않는 메시지 타입 삭제

➕ 추가:
  - Neighbor Solicitation (NS) - ARP request 역할
  - Neighbor Advertisement (NA) - ARP response 역할
  - Packet Too Big (Type 2) - Fragmentation 제거로 새로 추가
  - Multicast Listener Discovery (MLD) - IGMP 역할

ICMPv6 Neighbor Discovery

NS (Neighbor Solicitation):

┌──────────┬──────┬──────────┬────────────────────┐
│ Type=135 │Code=0│ Checksum │      Reserved      │
└──────────┴──────┴──────────┴────────────────────┘
┌────────────────────────────────────────────────┐
│         Target Address (128 bits)              │
└────────────────────────────────────────────────┘

NA (Neighbor Advertisement):

┌──────────┬──────┬──────────┬──┬──┬──┬──────────┐
│ Type=136 │Code=0│ Checksum │R │S │O │ Reserved │
└──────────┴──────┴──────────┴──┴──┴──┴──────────┘
┌────────────────────────────────────────────────┐
│         Target Address (128 bits)              │
└────────────────────────────────────────────────┘

Flags:

R (Router): 1이면 라우터가 전송, 0이면 호스트
S (Solicited): 1이면 NS에 대한 응답
O (Override): 1이면 기존 캐시 정보 업데이트

ICMPv6 주요 차이

1. Fragmentation 변경:

IPv4: 라우터가 Fragment 가능
  └─► Fragment 관련 ICMP 메시지

IPv6: Fragmentation 없음!
  └─► Packet Too Big (Type 2) 메시지
      MTU보다 큰 패킷은 무조건 Drop + ICMP 전송

2. Multicast 지원:

ICMPv6는 Multicast도 지원:
  - Neighbor Discovery에 Multicast 사용
  - Multicast Listener Discovery (MLD)

ICMP의 실전 활용

네트워크 진단 워크플로우

문제 진단 순서:

1. Ping으로 연결성 확인
   ├─► 성공 → 네트워크 정상
   └─► 실패 ↓

2. Traceroute로 경로 확인
   ├─► 어디서 끊기는지 확인
   └─► 문제 라우터 식별 ↓

3. PMTU Discovery로 MTU 문제 확인
   └─► Fragmentation 이슈 해결

4. ICMP Error 로그 분석
   └─► 근본 원인 파악

보안 고려사항

ICMP 남용 방지:

공격 유형:
1. ICMP Flood (Ping Flood)
   └─► 대량의 Echo Request로 과부하

2. Smurf Attack
   └─► Broadcast 주소로 Ping → 증폭 공격

3. ICMP Redirect 스푸핑
   └─► 악의적인 경로 변경

대응:
✅ Rate Limiting: ICMP 메시지 속도 제한
✅ Filtering: 불필요한 ICMP 타입 차단
✅ Validation: Source IP 검증

정리

ICMP의 핵심 역할

기능	설명	대표 메시지
Error Reporting	IP 전송 중 발생한 문제 보고	Type 3, 11, 12
Diagnostics	네트워크 연결 및 경로 진단	Ping, Traceroute
Path Discovery	MTU 및 경로 정보 탐색	PMTU Discovery
Control	라우팅 최적화 및 제어	Redirect

주요 ICMP 메시지 요약

Type	이름	용도	핵심 활용
0/8	Echo Reply/Request	연결성 테스트	Ping
3	Destination Unreachable	전달 실패 알림	디버깅
5	Redirect	경로 최적화	라우팅 테이블 업데이트
11	Time Exceeded	TTL 만료	Traceroute

ICMP의 핵심: IP의 Best Effort를 보완하여 네트워크를 진단 가능하고 디버깅 가능하게 만드는 필수 프로토콜!

ICMP 없이는 불가능한 것들:

❌ Ping으로 연결 확인
❌ Traceroute로 경로 추적
❌ PMTU Discovery로 최적 패킷 크기 결정
❌ 에러 발생 시 원인 파악

CS, Internet Protocol

This post is licensed under CC BY 4.0 by the author.