Internet Protocol: Error and Control Messages (ICMP) Chapter 8 We have Unreliable Connectionless datagram delivery… Need a way to inform original source if: Router cannot forward or deliver a datagram Router detects unusual condition affecting the ability to forward a datagram Original source will need to avoid or correct the problem Internet Control Message Protocol Routers operate autonomously If everything works correctly, all ok. But: Communication lines fail Processors fail Destination machines get disconnected from the network TTL counters expire Intermediate routers get congested In an internet, no special hardware mechanisms to inform hosts of problems Don’t know if failure is local or remote problem Debugging is difficult IP has nothing itself to help out Added special-purpose message mechanism Internet Control Message Protocol (ICMP) Considered a required part of IP ICMP messages travel in data portion of IP datagrams ICMP: Allows sending of error or control messages to other routers or hosts Provides communication between IP software on one machine and IP software on another ICMP module handles ICMP messages Any machine can send an ICMP message Error Reporting vs Correction ICMP is technically a reporting mechanism ICMP only reports error condition to source Source must relate error to a specific application program or take other action Most errors stem from original source Some do not ICMP only informs original source Source may not be able to determine problem Have to restrict communication to original source: Datagrams don’t usually record complete route Can’t know path taken to a given router So cannot inform intermediate routers Inform original source Hope host administrators and network administrators will cooperate to solve problem ICMP Message Delivery ICMP uses two levels of encapsulation ICMP message in datagram data portion Datagram in frame data portion Datagrams carrying ICMP messages: Are forwarded the same way as others May themselves get lost or discarded May cause further congestion Figure 8.1 Exception for error messages ICMP messages not generated if error results from datagram carrying ICMP error message ICMP not a higher-level protocol It is a required part of IP IP used to carry because messages may have to travel across several networks Cannot be delivered by physical transport alone ICMP Message Format Each ICMP message has own format But, all begin with three fields: 8-bit integer message TYPE 8-bit CODE field 16-bit CHECKSUM Also includes first 64 data bits of datagram causing the problem Echo Reply and Request (0 & 8) Command on many systems is ping Sends echo request to a machine Receiver sends echo reply to sender Tests if destination is reachable & responding Verifies source, outbound path, destination, and return path Sophisticated versions send a series of requests and provide statistics about datagram loss C:\>ping google.com Pinging google.com [64.233.187.99] with 32 bytes of data: Reply from 64.233.187.99: bytes=32 time=31ms TTL=239 Reply from 64.233.187.99: bytes=32 time=32ms TTL=239 Reply from 64.233.187.99: bytes=32 time=31ms TTL=239 Reply from 64.233.187.99: bytes=32 time=30ms TTL=239 Ping statistics for 64.233.187.99: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 30ms, Maximum = 32ms, Average = 31ms C:\> Echo request and reply message format: 0 8 Type (8 or 0) 16 31 Code (0) Checksum Identifier Sequence Number Optional Data ... Unreachable Destination (3) Sent when router cannot forward or deliver a datagram 0 8 Type (3) 16 Code (0-12) 31 Checksum Unused (must be zero) Internet header + first 64 bits of datagram ... Discarding datagrams not taken lightly Messages sent when router determines destination unreachable Network unreachable: usually forwarding failure Host unreachable: usually delivery failure 13 types possible; specified in CODE field However, routers cannot know all delivery failures Destination on Ethernet Network HW doesn’t provide acknowledgements Source Quench (4) Congestion: routers overrun with traffic Can happen for two reasons: High-speed computer generate traffic too fast for network to handle Many computers sending thru same router Datagrams buffered if arrive too fast Helps with small burst If continues, memory gets exhausted Source quench used to report congestion Requests source to reduce rate of transmission Usually one message per discarded datagram May be more sophisticated Quench source with highest transmission rate Avoid congestion by sending before overflow 0 8 Type (4) 16 Code (0) 31 Checksum Unused (must be zero) Internet header + first 64 bits of datagram ... Redirect (Route Change)(5) Routers are assumed to know correct routes Hosts begin with minimal forwarding info Usually know the address of single router Learn new routes from routers One way is the ICMP redirect message Router detects host using a non-optimal route Redirect requests the host change its route Host routing table stays small but optimal Limitation: Only have interactions between directly connected host and router Later routers cannot send ICMP redirect Don’t know non-directly connected router’s address Redirect not used to solve general problem of propagating routing information 0 8 Type (5) 16 Code (0 to 3) 31 Checksum Router Internet Address Internet header + first 64 bits of datagram ... Code 0: redirect for net Code 1: redirect for host Code 2: redirect for TOS and net Code 3: redirect for TOS and host Figure 8.7 Time Exceeded (11) Can get routing cycles R1 sends datagrams for D to R2 R2 sends datagrams for D to R1 TTL (hop count) timer used to stop circle ICMP time exceeded message: Sent when datagram discarded due to TTL=0 Or, when timed out waiting for datagram fragments 0 8 Type (11) 16 Code (0 or 1) 31 Checksum Unused (must be zero) Internet header + first 64 bits of datagram ... Code 0: TTL count exceeded Code 1: Fragment reassembly time exceeded Parameter Problem (12) Problem exists with a datagram Severe enough to cause it to be discarded Uses pointer to ID octet that caused the problem 0 8 Type (12) Pointer 16 Code (0 or 1) 31 Checksum Unused (must be zero) Internet header + first 64 bits of datagram ... Code 1: required option is missing (pointer field not used) Timestamp Request & Reply (13 or 14) Can have clock synchronization problem Widely different clocks can confuse operations Several protocols exist to synchronize clocks One of simplest: Machine sends ICMP timestamp request message Receiver returns a timestamp reply 0 8 Type (13 or 14) 16 31 Code (0) Identifier Checksum Sequence Number Originate Timestamp Receive Timestamp Transmit Timestamp From originate time: - can compute total time From receive & transmit times: - can compute network transit time Then estimate differences in clocks Information Request and Reply (15 or 16) *OBSOLETE* Intended to allow hosts to discover internet address at startup Made obsolete by DHCP Address Mask Request & Reply (17 or 18) *OBSOLETE* Chap 9 – motivation for subnets Understand for now: Some bits in hostid identify a physical network Host needs to know: Which bits correspond to the physical network Which bits correspond to the host identifiers Subnet mask: 32-bit quantity allowing address interpretation Intended to allow host to obtain the address mask used on the local network Made obsolete by DHCP Router Solicitation & Advertisement *OBSOLETE* Intended to allow a host to discover routers available on the local network Made obsolete by DHCP Two differences from DHCP: Host got info directly from router Prevented hosts from retaining routes after a router crashes (soft state technique) Routers advertise their information periodically Host discards route when timer for it expires Summary Routers may need to communicate with network software on a particular host Report abnormal condition Send control information Internet Control Message Protocol is used Travels in data area of IP datagram Three fixed-length fields at the beginning Message type determines rest of format