ICMP: Difference between revisions
From IT Wiki
No edit summary |
(→기능) |
||
Line 5: | Line 5: | ||
==기능== | ==기능== | ||
*오류보고 : IP가 데이터그램을 폐기할 경우 최초 발신지에게 통보 (수정은 안함) | *오류보고: IP가 데이터그램을 폐기할 경우 최초 발신지에게 통보 (수정은 안함) | ||
*질의 : 라우터나 다른 호스트로부터 간단한 상태 정보 획득 | *질의: 라우터나 다른 호스트로부터 간단한 상태 정보 획득 | ||
==계층== | ==계층== | ||
Line 74: | Line 74: | ||
*코드 필드엔 데이터그램을 전달 할 수 없었던 이유를 명시한다. | *코드 필드엔 데이터그램을 전달 할 수 없었던 이유를 명시한다. | ||
*ex) 0 : 하드웨어 고장, 2 : 상위 프로토콜 도달 불가, 4 : 단편화 불가 (Don't fragment) | *ex) 0: 하드웨어 고장, 2: 상위 프로토콜 도달 불가, 4: 단편화 불가 (Don't fragment) | ||
{| class="wikitable" | {| class="wikitable" | ||
|Type : 3 | |Type: 3 | ||
|Code : 0 to 15 | |Code: 0 to 15 | ||
|Checksum | |Checksum | ||
|- | |- | ||
Line 87: | Line 87: | ||
'''Source Quench Message''' | '''Source Quench Message''' | ||
*IP는 흐름제어 기능이 없기 때문에 발신자 쪽에서 데이터를 너무 빨리 보내면 | *IP는 흐름제어 기능이 없기 때문에 발신자 쪽에서 데이터를 너무 빨리 보내면 오버플로가 발생할 수도 있고, 이럴 경우 데이터그램을 그냥 폐기 | ||
*ICMP는 이를 발신자에게 통보하여 송신을 억제 | *ICMP는 이를 발신자에게 통보하여 송신을 억제 | ||
**(ICMP의 한계) 어느 발신자가 혼잡을 유발하는지 알 수 없다. 따라서 엉뚱한 발신자가 희생될 수도 있다. | **(ICMP의 한계) 어느 발신자가 혼잡을 유발하는지 알 수 없다. 따라서 엉뚱한 발신자가 희생될 수도 있다. | ||
Line 98: | Line 98: | ||
두가지 경우가 있다. | 두가지 경우가 있다. | ||
*Code = '0' 인 경우, Time to live필드가 0이 되어 데이터그램이 | *Code = '0' 인 경우, Time to live필드가 0이 되어 데이터그램이 폐기된 경우 | ||
*Code = '1' 인 경우, 단편이 지정된 시간내에 도착하지 않아 재조립에 실패한 경우 | *Code = '1' 인 경우, 단편이 지정된 시간내에 도착하지 않아 재조립에 실패한 경우 | ||
Line 110: | Line 110: | ||
{| class="wikitable" | {| class="wikitable" | ||
|Type : 12 | |Type: 12 | ||
|Code : 0 or 1 | |Code: 0 or 1 | ||
|Checksum | |Checksum | ||
|- | |- | ||
Line 125: | Line 125: | ||
{| class="wikitable" | {| class="wikitable" | ||
|Type : 5 | |Type: 5 | ||
|Code : 0 to 3 | |Code: 0 to 3 | ||
|Checksum | |Checksum | ||
|- | |- | ||
Line 136: | Line 136: | ||
{| class="wikitable" | {| class="wikitable" | ||
|Type | |Type | ||
| | |메시지 이름 | ||
|주요목적 | |주요목적 | ||
|- | |- | ||
Line 157: | Line 157: | ||
'''Echo Request / Reply''' | '''Echo Request / Reply''' | ||
{| class="wikitable" | {| class="wikitable" | ||
|Type : 8 / 0 | |Type: 8 / 0 | ||
|Code : 0 | |Code: 0 | ||
|Checksum | |Checksum | ||
|- | |- | ||
Line 182: | Line 182: | ||
'''Timestamp Request / Reply''' | '''Timestamp Request / Reply''' | ||
{| class="wikitable" | {| class="wikitable" | ||
|Type : 13 / 14 | |Type: 13 / 14 | ||
|Code : 0 | |Code: 0 | ||
|Checksum | |Checksum | ||
|- | |- |
Latest revision as of 15:53, 26 May 2022
Internet Control Message Protocol, RFC 792
ICMP는 인터넷 프로토콜의 비신뢰적인 특성을 보완하기 위한 프로토콜로 IP 패킷 전송 중 에러 발생 시 에러 발생 원인을 알려주거나 네트워크 상태를 진단해주는 기능을 제공한다.
기능[edit | edit source]
- 오류보고: IP가 데이터그램을 폐기할 경우 최초 발신지에게 통보 (수정은 안함)
- 질의: 라우터나 다른 호스트로부터 간단한 상태 정보 획득
계층[edit | edit source]
- 3계층과 4계층 사이
- TCP/IP가 계층화가 제대로 이루어지지 않았다는 예시로 언급되는 프로토콜
- IP와 같은 3계층 보단 상위 계층이나 라우터와 같은 3계층 장비에서 처리 가능하여 3계층으로 보기도 함
문제점[edit | edit source]
- 명확하지 않은 계층
- 신뢰성이 없는 비연결형 데이터그램 방식 (Best Effort)
- 오류제어 메커니즘의 부재. 오로지 폐기만 할 뿐 다른 대응을 하지 않는다.
- 목적지를 찾지 못하면 폐기
- 타임아웃(TTL==0)이 될 경우 폐기
- 재조합 타이머가 만료되면 모든 fragment 폐기
- 라우터나 다른 호스트의 상태정보 수집 불가
ICMP 메시지[edit | edit source]
전체 메시지 정보는 ICMP 메시지 문서 참조
메시지 포맷[edit | edit source]
Type (8bit)
메세지 종류 |
Code (8bit)
오류 원인 코드 |
Checksum (16bit)
자기 자신에 대한 오류 검출 Checksum |
---|---|---|
Rest of the header | ||
Data section |
메시지 종류[edit | edit source]
ICMP Error Report Message
메세지 이름 | 주요목적 | Type |
---|---|---|
Destination unreachable | 목적지 도달 불가 | 3 |
Source quench | 혼잡으로 인한 데이터그램 폐기 | 4 |
Time exceeded | Timeout 또는 TTL == 0 | 11 |
Parameter problem | IP 패킷이나 헤더 오류 | 12 |
Redirection | 경로 재지정 필요 | 5 |
Destination unreachable message
- 코드 필드엔 데이터그램을 전달 할 수 없었던 이유를 명시한다.
- ex) 0: 하드웨어 고장, 2: 상위 프로토콜 도달 불가, 4: 단편화 불가 (Don't fragment)
Type: 3 | Code: 0 to 15 | Checksum |
Unused (All 0) | ||
IP header and front 8 bytes of datagram data |
Source Quench Message
- IP는 흐름제어 기능이 없기 때문에 발신자 쪽에서 데이터를 너무 빨리 보내면 오버플로가 발생할 수도 있고, 이럴 경우 데이터그램을 그냥 폐기
- ICMP는 이를 발신자에게 통보하여 송신을 억제
- (ICMP의 한계) 어느 발신자가 혼잡을 유발하는지 알 수 없다. 따라서 엉뚱한 발신자가 희생될 수도 있다.
- 혼잡이 해결된 후 속도를 회복시키는 메커니즘이 없다
- Source quench 메세지는 딱 한번만 보내진다.
- 그 뒤로 데이터그램이 계속 날아오더라도 다시 보내지 않고 그냥 데이터그램을 폐기시켜 버린다.
Time Exceeded Message
두가지 경우가 있다.
- Code = '0' 인 경우, Time to live필드가 0이 되어 데이터그램이 폐기된 경우
- Code = '1' 인 경우, 단편이 지정된 시간내에 도착하지 않아 재조립에 실패한 경우
Parameter Problem Message
데이터그램의 헤드에 에러가 있거나 부족한 부분이 있을 경우
- Code = '0' 인 경우, 필드 중에 불명료하거나 빠진 것이 있는 경우이다.
- Code = '1' 인 경우, 옵션의 요구사항이 빠져 있는 경우이다.
- 아래 Pointer 필드에 문제가 있는 바이트의 위치가 들어간다.
Type: 12 | Code: 0 or 1 | Checksum |
Pointer | Unused (All 0) | |
IP header and front 8 bytes of datagram data |
Redirection Message
- 라우터가 봤을때 자신이 아닌 다른 라우터를 경유 하는게 최종 목적지로 가는데 유리 할 경우 올바른 경로를 알려 준다.
- ICMP가 전달하는 메세지 중 특별한 경우이다. IP 데이터그램을 폐기시키지 않고 그냥 메세지만 전달한다.
Type: 5 | Code: 0 to 3 | Checksum |
IP address of the target router | ||
IP header and front 8 bytes of datagram data |
ICMP Query Message
Type | 메시지 이름 | 주요목적 |
8 / 0 | Echo request / reply | IP 프로토콜 점검, 호스트의 도달 가능성 검사 |
13 / 14 | Timestamp request / reply | 두 호스트간 IP 데이터그램의 왕복시간 측정 |
17 / 18 | Address mask request / reply | 네트워크 마스크를 모를 경우 라우터에 신청 (거의 안씀) |
10 / 9 | Router solicitation / advertise | 라우터 주소와 동작 상태 체크 |
Echo Request / Reply
Type: 8 / 0 | Code: 0 | Checksum |
Identifier
어떤 Request 인지 어떤 Request 에 대한 reply 인지 |
Sequence number
몇 번째 Request 인지 몇 번째 Request 에 대한 reply 인지 | |
Optional data
메시지를 포함시켜 보낼 경우 똑같은 메세지가 돌아오게 된다. |
Address Mask Request / Reply
디스크가 없는 호스트가 구동될 때 사용되는 것으로, 현재는 거의 안쓰인다
Timestamp Request / Reply
Type: 13 / 14 | Code: 0 | Checksum |
Identifier
어떤 Request 인지 어떤 Request 에 대한 reply 인지 |
Sequence number
몇 번째 Request 인지 몇 번째 Request 에 대한 reply 인지 | |
Original timestamp (보내는 시간) | ||
Receive timestamp (응답 메시지에만 기록된다. 발신 메시지에선 그냥 여백) | ||
Transmit timestamp (응답 메시지에만 기록된다. 발신 메시지에선 그냥 여백) |
PING[edit | edit source]
- ICMP를 사용한 대표적인 프로그램(또는 명령)
- ICMP Echo Reply를 이용