ICMP 메시지 구조와 ping·경로·MTU 해석

01ICMP는 IP의 결과를 보고한다

• IP 제어 메시지ICMPv4는 IP 전달 중의 오류나 제어 정보를 호스트와 라우터 사이에 전달한다. IPv4 Protocol 필드 값 1로 구분되며 TCP나 UDP 포트를 사용하지 않는다.

  • ICMP 메시지를 운반하는 바깥 IP 패킷은 존재하므로 “IP 없이 동작한다”는 뜻도 아니다.
  • ICMPv6는 별도의 메시지 유형과 Next Header 58을 사용한다.
• 보장하지 않는 기능ICMP가 IP의 비신뢰성을 신뢰적인 연결로 바꾸는 것은 아니다. ICMP도 유실·차단될 수 있고 모든 실패에 오류를 반환하지 않으며 자체적으로 원래 IP 패킷을 재전송하지 않는다.

  • 오류 보고·상태 진단과 재전송·순서 복구는 별개이며 후자는 TCP나 응용이 담당한다.

02공통 헤더와 종류별 나머지 필드

• Type·CodeICMPv4의 공통 시작은 Type 1바이트, Code 1바이트, Checksum 2바이트이다. Code가 2바이트가 아니라는 점에 주의한다.

  • 다음 4바이트의 의미는 메시지 유형에 따라 달라지며 그 뒤에 데이터가 온다.
  • Echo에서는 Identifier 2바이트와 Sequence 2바이트이고, Fragmentation Needed에서는 다음 홉 MTU가 관련되며, Parameter Problem에서는 문제 위치를 가리키는 pointer가 들어간다.
• ChecksumChecksum은 ICMP 메시지 전체를 대상으로 하는 16비트 1의 보수 오류 검사이다. 바깥 IPv4 헤더 체크섬과 검사 범위가 다르다.

  • 데이터가 손상되었는지 검출하기 위한 값이지 송신자의 신원을 인증하는 서명은 아니다.
  • Type만 같다고 동일 의미로 처리하지 말고 Code와 뒤의 필드를 함께 읽어야 한다.

03Echo Request와 Reply의 대응

• Echo 요청·응답ping은 Echo Request를 보내고 Reply를 기다린다. Type 8인 요청에서 Identifier와 Sequence를 정해 여러 요청을 구별하며 응답은 Type 0으로 해당 식별 정보와 데이터를 돌려준다.

  • 캡처 도구가 big-endian과 little-endian 해석을 함께 보여줄 수 있으므로 두 가지 표기를 서로 다른 세션으로 세지 않는다.
  • 실제 프로토콜 바이트와 도구 표시를 구분해야 한다.
• Identifier·SequenceEcho Identifier는 포트가 아니지만 NAT가 여러 내부 단말의 Echo를 나누기 위해 이 값을 대응시킬 수 있다. Reply의 IP 출발지는 보통 시험 대상이고 목적지는 요청자이다.

  • 반면 오류 메시지의 발신자는 중간 라우터일 수 있다.
  • Ping 출력의 “응답한 주소”와 “시험한 주소”가 다른 경우는 요청의 도착과 중간 실패 보고를 구별하는 단서이다.

04오류 메시지 안에는 원래 패킷이 인용된다

• 원래 패킷의 인용Destination Unreachable이나 Time Exceeded의 바깥 IP는 오류를 만든 장비→원래 송신자이다. ICMP 본문에는 오류를 일으킨 원래 IP 헤더와 데이터 일부가 들어가 어느 요청에 대한 실패인지 연결한다.

  • RFC 792의 기본 형식은 원래 IP 헤더와 그 뒤 최소 8바이트를 포함하며, 후속 요구사항과 확장에 따라 더 많은 원래 패킷 내용이 실릴 수 있다.
• 요청과 오류 연결예를 들어 UDP 요청이 포트 33434로 나갔다가 중간 TTL이 만료되면 ICMP 본문에서 원래 목적지와 UDP 포트를 읽어 해당 probe를 찾을 수 있다. 캡처에서 IPv4 헤더가 두 번 보인다고 반드시 IP-in-IP 터널은 아니다.

  • 바깥은 오류 운반용, 안쪽은 실패한 원래 패킷의 인용본이라는 구조를 먼저 확인한다.

06Ping 성공과 실패가 증명하는 범위

• ping 성공 범위Echo 성공은 해당 시각·출발지·크기의 요청과 응답이 오갔음을 뜻한다. 웹 서버의 인증, TCP 포트, DNS 해석 또는 대용량 전송까지 검증한 것은 아니다.

  • loopback ping은 로컬 IP 스택을, gateway ping은 인접 경로를, 원격 목적지 ping은 그 목적지까지의 Echo 왕복을 각각 제한된 범위에서 보여준다.
• 응답 TTL 해석응답 TTL은 응답 패킷이 돌아오며 남은 값이다. 상대의 초기 TTL을 모르면 홉 수를 정확히 계산할 수 없고, 초기값의 흔한 패턴만으로 운영체제를 확정할 수도 없다.

  • RTT는 요청·응답 왕복과 종단·제어 처리 시간이 합쳐진 관측값이며 경로 길이나 순수 전파 지연 하나와 같지 않다.
  • 실패 시 “장비가 꺼졌다” 대신 timeout·unreachable·local error 등 관찰된 형태를 적는다.

07Traceroute의 TTL 증가와 응답

• Probe 종류전통적 UDP traceroute는 높은 목적지 포트와 최종 Port Unreachable을 이용한다. Windows tracert는 ICMP Echo를 사용하며 TCP probe 도구도 있다.
• 출력의 범위각 줄은 해당 probe에 응답한 주소와 RTT다. ICMP 제한·ECMP·비대칭 귀환 때문에 고정된 서비스 왕복 경로 지도와 같지는 않다.
• 별표·긴 RTT중간 홉이 별표여도 뒤 홉이 응답하면 중간 장비의 전달 중단을 뜻하지 않는다. 한 홉만 RTT가 크면 제어 응답 처리 지연도 고려한다.

1. TTL 1 전송첫 probe를 TTL=1로 보낸다. 첫 라우터가 TTL을 소모해 폐기하고 Time Exceeded를 보낼 수 있다.
2. 첫 홉 기록송신자는 오류 응답과 원래 probe를 연결해 응답 주소·왕복 시간을 기록한다. 응답이 없으면 제한 시간 후 미응답으로 표시한다.
3. TTL을 늘려 반복TTL을 2, 3으로 늘리면 더 먼 라우터에서 만료된다. 각 TTL의 probe와 응답을 별도로 대응시킨다.
4. 목적지 응답 판정선택한 probe 방식의 최종 응답을 받으면 목적지 도달을 판정한다. 중간 ICMP 응답과 목적지의 응용 서비스 성공은 별도다.

08DF와 다음 홉 MTU로 크기를 줄이는 절차

• IPv4 PMTUDIPv4에서 DF=1인 패킷이 출력 링크 MTU보다 크면 라우터는 이를 임의로 조각낼 수 없다. 적절한 조건에서 Type 3 Code 4와 다음 홉 MTU를 돌려보낸다.

  • 송신자는 이 정보를 바탕으로 경로 MTU 추정을 낮추어 다시 전송한다.
  • MTU 정보가 없는 오래된 피드백에 대한 처리와 현대의 Packetization Layer PMTUD 등 확장은 기본 예와 별도로 이해한다.
• IPv6 PMTUDIPv6 라우터는 전달 중 조각화를 하지 않으며 ICMPv6 Packet Too Big을 사용한다. 작은 SYN과 작은 요청은 통과하지만 큰 데이터만 멈추는 현상은 PMTU 피드백이 사라지는 black hole의 단서가 될 수 있다.

  • 단, 패킷 크기와 DF·재전송·ICMP를 확인하지 않은 채 모든 대용량 장애를 MTU로 단정하지 않는다.

09Ping payload·IP 길이·MSS의 계산

• ping 데이터 길이Windows ping의 -l은 ICMP 데이터 크기이고 -f는 IPv4에서 DF를 설정한다. IPv4 옵션이 없을 때 데이터 1472+ICMP 8+IPv4 20=1500이다.

  • 그러므로 MTU 1500 경로에서 1472는 이 형식의 대표 시험값이다.
  • 터널이나 더 작은 링크가 있으면 허용되는 값은 낮아지며 이 수치를 설정값으로 무조건 복사하는 것이 아니다.
• TCP MSSTCP의 MSS는 TCP payload 크기에 관한 협상 값이다. IPv4·TCP 기본 헤더 각 20바이트인 단순 예에서는 MTU 1500에 MSS 1460을 연결할 수 있지만 TCP 옵션과 IP 확장 조건도 계산에 반영한다.

  • MSS 조정은 UDP·ICMP나 모든 터널 문제를 대신 해결하지 않는다.
  • 인터페이스 MTU, 경로 MTU, ping 데이터, TCP MSS는 측정 대상이 서로 다르다.

ping -4 -n 4 203.0.113.20
ping -4 -n 4 -f -l 1472 203.0.113.20
tracert -4 -d 203.0.113.20

Wireshark display filter:
icmp
icmp.type == 3 && icmp.code == 4
icmp.type == 11

Windows IPv4의 문서용 시험 예. 허가된 격리 토폴로지의 주소를 가정하며 여기서 실행하지 않는다.

11오류에 오류를 되돌리지 않는 조건

• 오류 응답 제한ICMPv4 오류 메시지를 받은 결과에 다시 ICMP 오류를 생성하면 오류가 무한 증폭할 수 있으므로 오류에 대한 오류는 보내지 않는다. 이는 Echo 같은 정보 메시지에 대한 모든 오류를 일괄 금지한다는 뜻과 다르다.

  • IPv4 라우터의 규칙에는 IP 또는 링크 브로드캐스트·멀티캐스트로 받은 패킷, 첫 조각이 아닌 fragment, 유효하지 않은 출발지 등의 오류 억제 조건도 있다.
• 차단과 rate limit장비의 오류 응답 속도 제한과 보안 정책도 추가로 작용한다. 따라서 “잘못된 패킷마다 반드시 ICMP 하나”라는 모델은 틀리다.

  • 운영 정책 역시 ICMP 전체 차단·전체 허용이라는 이분법보다 Echo, PMTU 오류, 경로 진단과 IPv6 ND 등 메시지의 기능을 구분해야 한다.
  • IPv6에는 필요한 메시지와 예외가 달라 IPv4 억제 규칙을 그대로 옮기면 안 된다.

12실습을 패킷 순서로 다시 읽기

• ARP·IP·ICMP 연결허브·스위치 실습에서 ARP Request→Reply가 선행하고 이어 Echo Request→Reply가 나타나는 것은 주소 해석과 도달성 시험이 연결된 흐름이다. 다만 캐시가 있으면 ARP가 생략된다.

  • DHCP 캡처의 Discover·Offer를 ICMP의 D·O 메시지라고 부르면 안 된다.
  • DHCP는 UDP 응용이고 ICMP는 별개의 IP 프로토콜이다.
• 분석 기록분석 기록에는 probe 종류·출발지·목적지·크기·시각, Type/Code, 원래 패킷 인용, 어느 위치에서 응답이 관측되었는지를 남긴다.

  • 두 캡처 지점과 장비 출력으로 작은 패킷 성공·큰 패킷 실패의 경계를 재현하면 단순 ping 성공 화면보다 경로와 MTU에 대한 기술 설명이 구체적이 된다.