인터넷 제어 메시지 프로토콜
Internet Control Message Protocol| 통신 프로토콜 | |
 ICMPv4의 일반 헤더 | |
| 목적 | IPv4용[1] 보조 프로토콜 |
|---|---|
| 개발자 | DARPA |
| 서론 | 1981 |
| RFC | RFC 792 |
ICMP(Internet Control Message Protocol)는 인터넷 프로토콜 스위트의 지원 프로토콜입니다.라우터를 포함한 네트워크 디바이스에서 다른 IP 주소와 통신할 때 성공 또는 실패를 나타내는 오류 메시지 및 동작 정보를 보내기 위해 사용됩니다.예를 들어 요청된 서비스를 사용할 수 없거나 호스트 또는 라우터에 도달할 [2]수 없는 경우 오류가 나타납니다.ICMP는 일반적으로 시스템 간의 데이터 교환에 사용되지 않으며 최종 사용자 네트워크 애플리케이션(ping 및 traceroute와 같은 일부 진단 도구를 제외하고)에 정기적으로 사용되지 않는다는 점에서 TCP 및 UDP와 같은 전송 프로토콜과 다릅니다.
IPv4 의 ICMP 는, RFC 792 에 정의되어 있습니다.IPv6 에서는, RFC 4443 로 정의되고 있는 개별의 ICMPv6 가 사용됩니다.
| 인터넷 프로토콜 스위트 |
|---|
| 응용 프로그램레이어 |
| 트랜스포트 레이어 |
| 인터넷 레이어 |
| 링크 레이어 |
기술적 세부사항
ICMP는 RFC 792에 정의된 인터넷 프로토콜 스위트의 일부입니다.ICMP 메시지는 일반적으로 진단 또는 제어 목적으로 사용되며 IP 동작 오류에 대한 응답으로 생성됩니다(RFC 1122에서 규정).ICMP 에러는, 발신기지 [2]패킷의 송신원IP 주소로 송신됩니다.
예를 들어 IP 데이터그램을 전송하는 모든 디바이스(중간 라우터 등)는 처음에 IP 헤더의 Time to Live(TTL; 존속가능시간) 필드를 1개씩 줄입니다.결과 TTL이 0일 경우 패킷은 폐기되고 전송 중 ICMP 시간이 초과된 메시지가 데이터그램의 송신원주소로 송신됩니다.
일반적으로 사용되는 네트워크 유틸리티의 대부분은 ICMP 메시지를 기반으로 합니다.traceroute 명령어는 특별히 설정된IP TTL 헤더필드를 사용하여 IP 데이터그램을 전송하고 전송 중에 초과된ICMP 시간 및 응답으로 생성된 수신처 도달 불능 메시지를 검색함으로써 구현할 수 있습니다.관련된 ping 유틸리티는 ICMP 에코 요구 및 에코 응답 메시지를 사용하여 구현됩니다.
ICMP는 IP의 기본 지원을 보다 높은 수준의 프로토콜인 것처럼 사용하지만 ICMP는 실제로 IP의 필수적인 부분입니다.ICMP 메시지는 표준 IP 패킷 내에 포함되지만 보통 ICMP 메시지는 일반 IP 처리와 구별되는 특수한 경우로 처리됩니다.대부분의 경우 ICMP 메시지의 내용을 검사하고 ICMP 메시지의 송신을 촉구한IP 패킷의 송신을 담당하는 애플리케이션에 적절한 에러 메시지를 전달할 필요가 있습니다.
ICMP는 네트워크 계층 프로토콜입니다.ICMP 패킷에는 TCP 또는 UDP 포트 번호가 관련되어 있지 않습니다.이 번호는 [3]위의 트랜스포트 레이어와 관련되어 있기 때문입니다.
데이터그램 구조
ICMP 패킷은, IPv4 [2]패킷에 캡슐화 됩니다.패킷은 헤더 섹션과 데이터 섹션으로 구성됩니다.
헤더
ICMP 헤더는 IPv4 헤더 다음에 시작되며 IP 프로토콜 번호 '1'[4]로 식별됩니다.모든 ICMP 패킷에는 8바이트의 헤더와 가변 크기의 데이터 섹션이 있습니다.헤더의 처음 4바이트는 고정 포맷이지만 마지막 4바이트는 해당 ICMP [2]패킷의 유형 또는 코드에 따라 달라집니다.
| 오프셋 | 옥텟 | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 옥텟 | 조금 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | 유형 | 코드 | 체크섬 | |||||||||||||||||||||||||||||
| 4 | 32 | 나머지 헤더 | |||||||||||||||||||||||||||||||
- 유형
- ICMP 타입, 「Control messages 」를 참조해 주세요.
- 코드
- ICMP 서브타입, 「Control messages 」를 참조해 주세요.
- 체크섬
- 오류 체크용 인터넷체크섬(RFC 1071)은 ICMP 헤더와 이 필드를 값 0으로 치환한 데이터로 계산됩니다.
- 나머지 헤더
- 4바이트 필드, 내용은 ICMP 유형과 코드에 따라 달라집니다.
데이터.
ICMP 에러 메시지에는, IPv4 헤더 전체의 카피와 에러 메시지의 원인이 된 IPv4 패킷으로부터의 최초의 8 바이트의 데이터를 포함한 데이터 섹션이 포함됩니다.ICMP 오류 메시지의 길이는 576바이트를 [5]초과할 수 없습니다.이 데이터는 호스트에서 메시지를 적절한 프로세스와 일치시키기 위해 사용됩니다.상위 수준의 프로토콜이 포트 번호를 사용하는 경우, 원래 데이터그램 데이터의 [6]처음 8바이트에 있는 것으로 가정합니다.
ICMP 패킷 데이터 섹션의 가변 크기가 부정 이용되었습니다.「Ping of Death」에서는, 대규모 또는 fragment화된 ICMP 패킷이 DoS 공격에 사용됩니다.ICMP 데이터는 통신을 위한 비밀 채널을 만드는 데도 사용할 수 있습니다.이러한 채널은 ICMP 터널이라고 불립니다.
메시지 제어
제어 메시지는 type 필드의 값으로 식별됩니다.코드 필드에는 메시지의 추가 컨텍스트 정보가 표시됩니다.프로토콜이 처음 도입된 이후 일부 제어 메시지는 더 이상 사용되지 않습니다.
| 유형 | 코드 | 상황 | 묘사 |
|---|---|---|---|
| 0 – 에코[6]: 14 응답 | 0 | 에코 응답(ping에 사용) | |
| 1과 2 | 할당되어 있지 않다 | 예약필 | |
| 3 – 수신처에 도달할[6]: 4 수 없음 | 0 | 대상 네트워크에 연결할 수 없음 | |
| 1 | 대상 호스트에 연결할 수 없음 | ||
| 2 | 대상 프로토콜에 연결할 수 없음 | ||
| 3 | 수신처 포트에 도달할 수 없음 | ||
| 4 | 플래그멘테이션이 필요하며 DF 플래그가 설정됩니다. | ||
| 5 | 소스 루트 실패 | ||
| 6 | 대상 네트워크를 알 수 없음 | ||
| 7 | 대상 호스트를 알 수 없음 | ||
| 8 | 소스 호스트가 분리됨 | ||
| 9 | 네트워크 관리상 금지 | ||
| 10 | 호스트가 관리상 금지됨 | ||
| 11 | ToS에 대한 네트워크 도달 불가 | ||
| 12 | ToS의 호스트에 도달할 수 없음 | ||
| 13 | 관리상 통신 금지 | ||
| 14 | 호스트 우선 순위 위반 | ||
| 15 | 우선 순위 컷오프 유효 | ||
| 4 – 소스 퀀치 | 0 | 소스 퀀치(congestion 제어) | |
| 5 – 리다이렉트 메시지 | 0 | 네트워크용 데이터그램 리다이렉트 | |
| 1 | 호스트의 데이터그램 리다이렉트 | ||
| 2 | ToS 및 네트워크용 데이터그램 리다이렉트 | ||
| 3 | ToS 및 호스트의 데이터그램 리다이렉트 | ||
| 6 | 대체 호스트 주소 | ||
| 7 | 할당되어 있지 않다 | 예약필 | |
| 8 – 에코 요구 | 0 | 에코 요구(ping에 사용) | |
| 9 – 라우터 애드버타이즈먼트 | 0 | 라우터 애드버타이즈먼트 | |
| 10 – 라우터 요청 | 0 | 라우터 검출/선택/요청 | |
| 11 – 시간 초과[6]: 6 | 0 | TTL이 전송 중에 만료되었습니다. | |
| 1 | 단편 재구성 시간을 초과했습니다. | ||
| 12 – 파라미터 문제:잘못된 IP 헤더 | 0 | 포인터가 오류를 나타냅니다. | |
| 1 | 필수 옵션 누락 | ||
| 2 | 잘못된 길이 | ||
| 13 – 타임스탬프 | 0 | 타임스탬프 | |
| 14 – 타임스탬프 응답 | 0 | 타임스탬프 응답 | |
| 15 – 정보 요청 | 0 | 정보 요구 | |
| 16 – 정보 회신 | 0 | 정보 회신 | |
| 17 – 주소 마스크 요구 | 0 | 주소 마스크 요구 | |
| 18 – 주소 마스크 응답 | 0 | 주소 마스크 응답 | |
| 19 | 예약되어 있다 | 보안을 위해 예약됨 | |
| 20 ~ 29 | 예약되어 있다 | 견고성 실험용으로 예약됨 | |
| 30 – traceroute | 0 | 정보 요구 | |
| 31 | 데이터그램 변환 오류 | ||
| 32 | 모바일 호스트 리다이렉트 | ||
| 33 | Where-Are-You(원래는 IPv6용) | ||
| 34 | Here-I-Am(원래는 IPv6용) | ||
| 35 | 모바일 등록 요청 | ||
| 36 | 모바일 등록 응답 | ||
| 37 | 도메인 이름 요구 | ||
| 38 | 도메인 이름 회신 | ||
| 39 | SKIP 알고리즘 탐색 프로토콜, 인터넷 프로토콜용 간이 키 관리 | ||
| 40 | 포토리스, 보안 장애 | ||
| 41 | 실험적인 | Seamoby [RFC4065]와 같은 실험적인 모빌리티 프로토콜을 위한 ICMP | |
| 42: 확장 에코[9] 요구 | 0 | 확장 에코 요구(XPing - '확장 Ping(Xping)' 참조) | |
| 43 – 확장 에코[9] 응답 | 0 | 오류 없음 | |
| 1 | 잘못된 형식의 쿼리 | ||
| 2 | 해당 인터페이스 없음 | ||
| 3 | 해당 테이블 항목 없음 | ||
| 4 | 여러 인터페이스가 쿼리를 만족시키다 | ||
| 44 ~ 252 | 할당되어 있지 않다 | 예약필 | |
| 253 | 실험적인 | RFC3692 스타일의 Experiment 1(RFC 4727) | |
| 254 | 실험적인 | RFC3692 스타일의 Experiment 2(RFC 4727) | |
| 255 | 예약되어 있다 | 예약필 |
소스 퀀치
Source Quench는 송신원이 라우터 또는 호스트에 송신되는 메시지의 레이트를 낮추도록 요구합니다.이 메시지는 라우터 또는 호스트에 요구를 처리하기에 충분한 버퍼 영역이 없는 경우 생성되거나 라우터 또는 호스트버퍼가 한계에 도달한 경우에 생성될 수 있습니다.
데이터는 호스트 또는 여러 호스트에서 네트워크상의 특정 라우터로 동시에 매우 빠른 속도로 전송됩니다.라우터는 버퍼링 기능을 갖추고 있지만 버퍼링은 지정된 범위 내로 제한됩니다.라우터는 제한된 버퍼링 공간의 용량보다 많은 데이터를 큐잉할 수 없습니다.따라서 큐가 가득 차면 큐가 가득 찰 때까지 착신 데이터는 폐기됩니다.그러나 네트워크층에는 확인 응답 메커니즘이 존재하지 않기 때문에 클라이언트는 데이터가 수신처에 정상적으로 도달했는지 여부를 알 수 없습니다.따라서 이러한 상황을 피하기 위해 네트워크 계층에서 몇 가지 개선책을 강구해야 합니다.이러한 척도를 소스 퀀치라고 합니다.소스 퀀치 메커니즘에서는 라우터는 착신 데이터 레이트가 발신 데이터 레이트보다 훨씬 빠른 것을 인식하고 클라이언트에 ICMP 메시지를 발송합니다.이 메시지는 클라이언트에 대해 데이터 전송 속도를 늦추거나 일정 시간 대기한 후 더 많은 데이터를 전송해야 함을 알려줍니다.클라이언트가 이 메시지를 수신하면 발신 데이터 레이트가 자동으로 느려지거나 충분한 시간이 대기하므로 라우터는 큐를 비울 수 있습니다.따라서 source quench ICMP 메시지는 네트워크층에서 흐름 제어로 기능합니다.
연구 결과, 「ICMP Source Quench(ICMP 소스 퀀치)는 [10]congestion에 대한 무효(부당한) 해독제」라고 하는 것이 판명되었기 때문에, 라우터의 소스 퀀치 메시지의 작성은 1995년에 RFC 1812에 의해서 폐지되었습니다.게다가 (플로우 제어 액션) 송신원 퀀치메시지 전송 및 그 대응은 RFC 6633에 의해 2012년부터 폐지되었습니다.
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 유형 = 4 | 코드 = 0 | 체크섬 | |||||||||||||||||||||||||||||
| 미사용의 | |||||||||||||||||||||||||||||||
| IP 헤더 및 원본 데이터그램의 첫 번째 8바이트 | |||||||||||||||||||||||||||||||
장소:
- 유형은 4로 설정해야 합니다.
- 코드를 0으로 설정해야 합니다.
- IP 헤더 및 추가 데이터는 응답과 관련된 요구를 대조하기 위해 송신자에 의해 사용됩니다.
리다이렉트
리다이렉트 요구 데이터 패킷은 대체 루트로 전송됩니다.ICMP 리다이렉트는 라우터가 라우팅 정보를 호스트에 전달하는 메커니즘입니다.이 메시지는 호스트에게 라우팅 정보를 갱신하도록 지시합니다(대체 루트로 패킷을 송신합니다).호스트가 라우터(R1)를 경유해 데이터를 송신하려고 하고, R1이 다른 라우터(R2)로 데이터를 송신해, 호스트에서 R2 로의 직접 패스를 사용할 수 있는 경우(즉, 호스트와 R2 가 같은 서브 네트워크상에 있는 경우), R1 는 수신처에 최적인 루트가 R2 를 경유하는 것을 호스트에 통지하는 리다이렉트메시지를 송신합니다.그 후, 호스트는 루트 정보를 변경해, 그 행선지의 패킷을 R2 에 직접 송신할 필요가 있습니다.라우터는 원래의 데이터그램을 목적의 수신처에 [11]송신합니다.단, 데이터그램에 라우팅 정보가 포함되어 있는 경우 보다 나은 루트를 사용할 수 있어도 이 메시지는 전송되지 않습니다.RFC 1122 에서는, 리다이렉트는 게이트웨이에 의해서만 송신할 수 있고, 인터넷호스트에 의해서 송신되지 않는 것이 규정되어 있습니다.
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 유형 = 5 | 코드 | 체크섬 | |||||||||||||||||||||||||||||
| IP 주소 | |||||||||||||||||||||||||||||||
| IP 헤더 및 원본 데이터그램의 첫 번째 8바이트 | |||||||||||||||||||||||||||||||
장소:
- 유형을 5로 설정해야 합니다.
- 코드는 리다이렉트 이유를 지정합니다.다음 중 하나입니다.
코드 묘사 0 네트워크 리다이렉트 1 호스트의 리다이렉트 2 서비스 유형 및 네트워크 리다이렉트 3 서비스 유형 및 호스트 리다이렉트
- IP 주소는 리다이렉션을 송신하는 게이트웨이의 32비트주소입니다
- IP 헤더와 추가 데이터가 포함되어 호스트가 응답을 리다이렉션 응답의 원인이 된 요구와 일치시킬 수 있습니다.
시간 초과
Time Exceededed 는 게이트웨이에 의해 생성되며 필드의 존속시간이 제로에 달하기 때문에 폐기된 데이터그램이 송신원에 통지됩니다.fragment화된 데이터그램을 제한 시간 내에 재구성할 수 없는 경우 호스트가 time exceed 메시지를 발송할 수 있습니다.
traceroute 유틸리티는 time exceeded 메시지를 사용하여 2개의 호스트 간의 경로 상의 게이트웨이를 식별합니다.
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 유형 = 11 | 코드 | 체크섬 | |||||||||||||||||||||||||||||
| 미사용의 | |||||||||||||||||||||||||||||||
| IP 헤더 및 원본 데이터그램의 첫 번째 8바이트 | |||||||||||||||||||||||||||||||
장소:
- 유형을 11로 설정해야 합니다.
- Code는 시간 초과 메시지의 이유를 지정합니다.다음은 예를 제시하겠습니다.
코드 묘사 0 운송 중 수명이 초과되었습니다. 1 단편 재구성 시간을 초과했습니다.
- 송신원호스트는, IP 헤더와 원래의 페이로드의 최초의 64 비트를 사용하고, 폐기된 데이터 그램에 시간 초과 메시지를 일치시킵니다.UDP 및 TCP와 같은 고급 프로토콜의 경우 64비트 페이로드에는 폐기된 패킷의 소스 및 대상 포트가 포함됩니다.
타임스탬프
타임스탬프는 시간 동기화에 사용됩니다.발신기지 타임스탬프는, 송신자가 마지막으로 패킷을 터치한 시각(자정 이후 밀리초 단위)으로 설정됩니다.수신 및 송신 타임스탬프는 사용되지 않습니다.
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 유형 = 13 | 코드 = 0 | 체크섬 | |||||||||||||||||||||||||||||
| 식별자 | 시퀀스 번호 | ||||||||||||||||||||||||||||||
| 발신 타임스탬프 | |||||||||||||||||||||||||||||||
| 수신 타임스탬프 | |||||||||||||||||||||||||||||||
| 송신 타임스탬프 | |||||||||||||||||||||||||||||||
장소:
- 유형을 13으로 설정해야 합니다.
- 코드를 0으로 설정해야 합니다.
- 클라이언트는 식별자와 시퀀스 번호를 사용하여 타임스탬프 응답과 타임스탬프 요청을 일치시킬 수 있습니다.
- Origin timestamp는 UT(Universal Time) 자정 이후 경과한 밀리초 수입니다.UT 참조를 사용할 수 없는 경우 최상위 비트를 설정하여 비표준 시간 값을 나타낼 수 있습니다.
타임스탬프 응답
타임스탬프 메시지에 대한 타임스탬프 회신.타임스탬프 송신원이 송신한 타임스탬프, 타임스탬프가 수신된 시각을 나타내는 수신 타임스탬프, 타임스탬프 응답이 송신된 시각을 나타내는 송신 타임스탬프로 구성됩니다.
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 유형 = 14 | 코드 = 0 | 체크섬 | |||||||||||||||||||||||||||||
| 식별자 | 시퀀스 번호 | ||||||||||||||||||||||||||||||
| 발신 타임스탬프 | |||||||||||||||||||||||||||||||
| 수신 타임스탬프 | |||||||||||||||||||||||||||||||
| 송신 타임스탬프 | |||||||||||||||||||||||||||||||
장소:
- 유형을 14로 설정해야 합니다.
- 코드를 0으로 설정해야 합니다.
- 클라이언트는 ID와 시퀀스 번호를 사용하여 응답을 발생시킨 요구와 일치시킬 수 있습니다.
- 발신 타임스탬프는 발신인이 메시지를 보내기 전에 마지막으로 터치한 시간입니다.
- 수신 타임스탬프는 에코어가 수신 시 처음 터치한 시간입니다.
- 송신 타임스탬프는 에코어가 메시지를 송신할 때 마지막으로 터치한 시간입니다.
- 모든 타임스탬프는 0시 UT 이후 밀리초 단위로 표시됩니다.시간을 밀리초 단위로 사용할 수 없거나 자정 UT에 대해 제공할 수 없는 경우 타임스탬프의 상위 비트도 이 비표준 값을 나타내도록 설정되어 있으면 타임스탬프에 임의의 시간을 삽입할 수 있습니다.
인터넷 노드의 클럭을 동기화하기 위한 타임스탬프 및 타임스탬프 응답 메시지의 사용은 UDP 기반의 Network Time Protocol 및 Precision Time [12]Protocol로 대체되었습니다.
주소 마스크 요구
주소 마스크 요구는 보통 적절한 서브넷마스크를 얻기 위해 호스트에서 라우터로 전송됩니다.
수신자는 이 메시지에 주소 마스크 회신 메시지로 회신해야 합니다.
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 유형 = 17 | 코드 = 0 | 체크섬 | |||||||||||||||||||||||||||||
| 식별자 | 시퀀스 번호 | ||||||||||||||||||||||||||||||
| 주소 마스크 | |||||||||||||||||||||||||||||||
장소:
- 유형을 17로 설정해야 합니다.
- 코드를 0으로 설정해야 합니다.
- 주소 마스크를 0으로 설정할 수 있습니다.
ICMP Address Mask Request는 타깃네트워크상의 정보를 수집하기 위한 정찰 공격의 일부로서 사용할 수 있습니다.따라서 Cisco IOS [13]에서는 ICMP Address Mask Reply는 디폴트로 디세블로 되어 있습니다.
주소 마스크 응답
주소 마스크 응답은 적절한 서브넷마스크를 사용하여 주소 마스크 요구 메시지에 응답하기 위해 사용됩니다.
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 타입 = 18 | 코드 = 0 | 체크섬 | |||||||||||||||||||||||||||||
| 식별자 | 시퀀스 번호 | ||||||||||||||||||||||||||||||
| 주소 마스크 | |||||||||||||||||||||||||||||||
장소:
- 유형을 18로 설정해야 합니다.
- 코드를 0으로 설정해야 합니다.
- 주소 마스크를 서브넷 마스크로 설정해야 합니다.
수신처에 도달할 수 없음
수신처 도달 불능은 호스트 또는 수신[6] 게이트웨이에 의해 생성되어 어떤 이유로 수신처에 도달할 수 없음을 클라이언트에 알립니다.이 메시지의 이유로는 호스트에 대한 물리적 연결이 존재하지 않음(거리 제한이 없음), 표시된 프로토콜 또는 포트가 활성화되지 않음, 데이터가 조각화되어야 하지만 '조각화하지 않음' 플래그가 켜져 있음 등이 있습니다.도달할 수 없는 TCP 포트는, 예상대로 행선지 도달 불능 타입 3이 아니고, TCP RST 로 응답합니다.IP 멀티캐스트 전송에서는, 행선지 도달 불능은 보고되지 않습니다.
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 유형 = 3 | 코드 | 체크섬 | |||||||||||||||||||||||||||||
| 미사용의 | 넥스트 홉 MTU | ||||||||||||||||||||||||||||||
| IP 헤더 및 원본 데이터그램의 첫 번째 8바이트 | |||||||||||||||||||||||||||||||
장소:
- 유형 필드(비트 0~7)를 3으로 설정해야 합니다.
- 코드 필드(비트 8~15)는 오류 유형을 지정하는 데 사용되며 다음 중 하나입니다.
코드 묘사 0 네트워크 도달 불능 오류입니다. 1 호스트 도달 불능 오류입니다. 2 프로토콜 도달 불가능 오류입니다(지정된 전송 프로토콜은 지원되지 않음). 3 Port Unreachable 오류(지정된 프로토콜이 수신 메시지를 호스트에 알릴 수 없습니다. 4 데이터그램이 너무 큽니다.패킷 플래그멘테이션이 필요하지만 'Don't fragment'(DF) 플래그가 켜져 있습니다. 5 소스 루트 실패 오류입니다. 6 대상 네트워크를 알 수 없는 오류입니다. 7 대상 호스트를 알 수 없는 오류입니다. 8 소스 호스트 분리 오류입니다. 9 행선지 네트워크는 관리상 금지되어 있습니다. 10 대상 호스트는 관리상 금지되어 있습니다. 11 Type Of Service 네트워크에 연결할 수 없습니다. 12 호스트에 연결할 수 없는 서비스 유형입니다. 13 관리상 통신이 금지되어 있습니다(관리 필터링에 의해 패킷이 전송되지 않습니다). 14 호스트 precedence 위반(호스트 또는 네트워크와 포트의 조합에 대해 요청된 precedence가 허용되지 않음을 나타냅니다). 15 유효한 우선순위 컷오프(데이터그램의 우선순위가 네트워크 관리자가 설정한 수준을 밑돌고 있습니다).
- 넥스트 홉 MTU 필드(비트 48 ~63)에는 코드4 에러가 [14]발생했을 경우의 넥스트홉 네트워크의 MTU가 포함됩니다.
- IP 헤더와 추가 데이터가 포함되어 클라이언트가 응답을 수신처 도달 불능의 원인이 된 요구와 일치시킬 수 있습니다.
「 」를 참조해 주세요.
레퍼런스
- ^ F. Baker (June 1995). Baker, F (ed.). Requirements for IP Version 4 Routers. p. 52. RFC 1812.
- ^ a b c d Forouzan, Behrouz A. (2007). Data Communications And Networking (Fourth ed.). Boston: McGraw-Hill. pp. 621–630. ISBN 978-0-07-296775-3.
- ^ "The OSI Model's Seven Layers Defined and Functions Explained". Microsoft Support. Retrieved 2014-12-28.
- ^ "Protocol Numbers". Internet Assigned Numbers Authority. Retrieved 2011-06-23.
- ^ Requirements for IP Version 4 Routers. doi:10.17487/RFC1812. RFC 1812.
- ^ a b c d e f g h i j k Postel, J. (September 1981). Internet Control Message Protocol. IETF. doi:10.17487/RFC0792. RFC 792.
- ^ "IANA ICMP Parameters". Iana.org. 2012-09-21. Retrieved 2013-01-07.
- ^ Kurose, J.F; Ross, K.W. (2006). Computer Networking: A Top-Down Approach. World student series. Addison-Wesley. ISBN 9780321418494.
- ^ a b PROBE: A Utility for Probing Interfaces. doi:10.17487/RFC8335. RFC 8335.
- ^ RFC 6633
- ^ "When Are ICMP Redirects Sent?". Cisco Systems. 2008-06-28. Retrieved 2013-08-15.
- ^ D.L. Mills (September 1985). Network Time Protocol (NTP). doi:10.17487/RFC0958. RFC 958.
It is evolved from the Time Protocol and the ICMP Timestamp message and is a suitable replacement for both.
- ^ "Cisco IOS IP Command Reference, Volume 1 of 4: Addressing and Services, Release 12.3 - IP Addressing and Services Commands: ip mask-reply through ip web-cache". Cisco Systems. Archived from the original on 2013-01-02. Retrieved 2013-01-07.
- ^ Extended ICMP to Support Multi-Part Messages. doi:10.17487/RFC4884. RFC 4884.
원천
RFC
- RFC 792, 인터넷 제어 메시지 프로토콜
- RFC 950, 인터넷 표준 서브넷화 절차
- RFC 1016, 호스트가 소스 퀀치를 사용하여 수행할 수 있는 작업: Source Quench에 의해 도입된 지연(SQU아이디)
- RFC 1122, 인터넷호스트 요건 - 통신층
- RFC 1716, IP 라우터의 요건을 향해서
- RFC 1812, IP 버전4 라우터의 요건
- RFC 4884, 멀티 파트메시지를 지원하기 위한 확장 ICMP
외부 링크
- IANA ICMP 파라미터
- IANA 프로토콜 번호
- 웨이백 머신에서의 ICMP 리다이렉트 동작 설명(2015-01-10 아카이브)
