4. Basic IP Support Protocols

Size: px

Start display at page:

Download "4. Basic IP Support Protocols"

Solomon Victor Bryan
5 years ago
Views:

1 4. Basic IP Support Protocols There are a number of protocols that support the operation of IP. This section will only discuss the most basic three: ICMP, RARP, and ARP. Other more sophisticated protocols such as dynamic routing protocols will be deferred to more appropriate sections of the course. Readings: Chapters 9, 6, and 5 of [Comer00] Section Table Of Contents 4. BASIC IP SUPPORT PROTOCOLS ICMP Ping-related ICMP Messages ICMP Redirect ICMP Router Discovery ADDRESS RESOLUTION PROTOCOL (ARP) ARP Cache Gratuitous ARP ARP Problems Proxy ARP REVERSE ADDRESS RESOLUTION PROTOCOL (RARP) RARP Servers Alternatives to RARP REFERENCES...24 Page 4-1 Page 4-2

2 4.1 ICMP The Internet Control Message Protocol is a relatively primitive support protocol for assisting in the administration of a IP internet. It actually sits on top of the IP layer, as all ICMP messages are sent as payload data within IP packets. Nonetheless, ICMP is a required part of the IP protocol suite. ICMP is officially defined in RFC 792. There are several dozen different ICMP message types. Some are requests, some are replies, and some are unsolicited error messages. A good table is shown in Figure 6.3 of [Stevens94]. Please recall that IP is a connectionless protocol. That means that there are no responses to packets that are received in error so that error correction can be performed, etc. On the other hand, IP via ICMP does support network error reporting. In particular, it supports networking errors such as need to fragment but not allowed to, no such network, no such destination host computer, and even some helpful efficiency messages such as would be better if next time you redirect via a different router. In addition, ICMP also provides some basic network testing and management support messages. The form of an ICMP message is: ICMP Message Sub-Code (8) Checksum (16) Type (8) ICMP payload depends on type and sub-code. Note that this message is placed within and IP packet, which in turn is typically placed within a data link layer frame (e.g. within an Ethernet frame). Notice that there is a checksum, that applies to the entire ICMP message (including the type and sub-code parts of its header). The reason this is needed is because IP does not check its payload. And since IP may be sitting on top of an unreliable data link layer like a modem connection, each higher level protocol using IP must protect itself. This is especially true of ICMP, as its messages are: often used to diagnose a poorly or non-functioning network, and it would be horrible in this sometimes critical situation to have the errors in information you are using to diagnose the situation. sometimes used to change the routes that packets are sent over. If there were errors in this kind of information, it would be like posting directional signs on a highway which point in the wrong direction! The type and sub-code fields in the ICMP header is chosen from among these decimal values: Page 4-3 Page 4-4

3 Type Sub-Code Message Meaning 0 (reply) 0 echo (i.e. ping) reply 3 (error) 0 network unreachable 1 host computer unreachable 2 protocol unreachable 3 port unreachable 4 fragmentation needed but DF bit set 5 source route failed 6 destination network unknown 7 destination host unknown 9 destination network administratively prohibited 10 destination host administratively prohibited 11 network unreachable for TOS 12 host unreachable for TOS 13 communication administratively prohibited by filtering 14 host precedence violation 15 precedence cutoff in effect 4 (advice) 0 source quench (primitive flow control) 5 (advice) 0 redirect for network 1 redirect for host 2 redirect for TOS and network 3 redirect for TOS and host 8 (request) 0 echo (ping) request 9 0 router advertisement (advice/reply) 10 (request) 0 router solicitation 11 (error) 0 time to live exceeded during transit 1 time to live exceeded during re-assembly 12 (error) 0 IP header bad (catch all error message) 1 required option missing 13 (request) 0 timestamp request 14 (reply) 0 timestamp reply 17 (request) 0 address mask request 18 (reply) 0 address mask reply Page 4-5 TakeagoodlookatallthedifferenttypesofICMP messages. Note that for certain types there are a variety of subcodes. The details of the ICMP payloads for each ICMP message type is described in RFC 792. Also, [Comer95] describes some, and [Stevens94] describes many of them (see his Figure 6.3 for pointers to where in his book these are described). Page 4-6

4 4.1.1 Ping-related ICMP Messages On most systems that support IP, the command: >ping will run a program called ping which sends an ICMP Echo Request message to the host computer whose IP address is Depending on the OS, one or possibly a series of echo requests will be sent. Sometimes one is sent, sometimes five, or sometimes they are sent once per second forever (until you type <cntl-c>). If host is reachable, it will send an Echo Reply ICMP message back, and the details of this reply are printed out by the ping program. Often additional information such as the round trip time for the echo request/reply is printed. And when the ping program ends, depending on the OS brand and version, the % of echo requests that got replies and some average times are printed on the console. Ping is called a destination reachability test program. If a destination is unreachable, some router along the way will discard the ping echo request packet (or whatever IP packet caused the problem) and reply with an ICMP Host Unreachable (Type 3) error report. An unreachable message is sent by a router if it knows the route to the host, but the link to that host is not currently up. It may also be sent if the router tried to ARP (to be discussed later) the host, and no host exists on the destination network. So the problem may be transient, and will fix itself when the link is restored, or power is re- applied, etc. Alternatively, it may be a permanent problem or dumb typing mistake. Also, not all failed deliveries will return in a host unreachable message. If: the host is on an Ethernet, and the last router enroute already has the destination in its ARP cache table, and the destination host is powered down, the router will send the packet and no host will be alive to receive it. And the source will NOT be notified of this failure. This is an example of why connectionless networking is unreliable, and why it needs a strong transport layer with end-to-end handshaking to be made reliable. Page 4-7 Page 4-8

5 4.1.2 ICMP Redirect An interesting ICMP message is the re-direct advisory message. Consider the following diagram: HOST ROUTER #1 ROUTER #2 NET #1 NET #2 Ethernet If the host wrongly sends an IP packet to Router #1, Router #1 will do two things. It will forward the packet to Router #2. And it will send and ICMP redirect message back to the host. The host, being a pretty smart machine, will update its routing tables such that this will not happen again during its current session. Unfortunately, the host routing table update is transient, and after a reboot of the host, the same thing will happen again. Network managers should therefore pay attention to ICMP redirect messages and update any static routing tables causing the problem ICMP Router Discovery Often in a host s routing table, directly attached routers, and the nets they provide a path to, are mentioned. In particular, there is often a default route entry, which specifies a router to send packets via for destinations which do not appear to be on any networks specifically mentioned in the table. Instead of having to maintain such tables in hundreds of hosts in a large network, ICMP router discovery messages can be used. After booting, a host broadcasts or multicasts a router solicitation ICMP message. Any directly attached routers can reply with an ICMP router advertisement message. The reply usually contains more than just the IP address of the router, but in addition contains information from the router s routing table about what other networks are reachable from the router. This might also include the router s default route. We will discuss routing more later. Page 4-9 Page 4-10

6 4.2 Address Resolution Protocol (ARP) When an IP packet finally arrives at a router which is directly connected to the destination host via a broadcast LAN, the router doesn t necessarily know the Ethernet address of the destination. This is a serious quandary! The solution is to use a net or LAN broadcast, asking if any stations recognize the IP address as their own. The Address Resolution Protocol is described in RFC 826. The protocol field of the Ethernet header of an ARP packet is set to 0806h, to indicate the payload of the Ethernet is an ARP packet. Thus ARP does not ride in IP packets, it is a low level protocol at the same level as IP. As Ethernet payload, an ARP packet looks like this: Hardware Address Type (2 bytes) Network Protocol Type (2) H/w Addr. Length (1) Net Address Length (1) Operation Code Sender Hardware Address (6) Sender Network (i.e. IP) Address (4) Target Hardware Address (6) Target Network (i.e. IP) Address (4) Destination hosts, which are always monitoring for ARP requests, examine every ARP request. If the request contains a Target Network Address that is its own, it will reply. If not, it will discard the ARP request. ARP requests and replies use the common format shown above. The Hardware Type field is normally 1, to indicate Ethernet. The Network Protocol type is normally 0800h to indicate IPv4. Page 4-11 Page 4-12

7 The next two bytes specify the length of the Ethernet and IP addresses (notice how other hardware and network protocols could be specified in detail). The Operation code is 1 for ARP request, 2 for ARP reply, 3 for RARP request, and 4 for RARP reply. On receiving an ARP targeted at itself, a host will: 1. copy its hardware (Ethernet) address to the target hardware address field, 2. change the operation code to 2, 3. swap all sender and target fields, and 4. finally, sent the ARP reply. Though the original destination has enough information to send the reply back in a properly addressed IP packet, the ARP protocol does not do this. It uses a low level ARP packet directly inside an Ethernet frame ARP Cache In order to reduce the ARP request broadcast traffic, and the ARP replies, which might otherwise be needed for every IP packet needing to be sent, hosts contain an ARP cache. This is a table of recently used IP addresses with their corresponding Ethernet addresses. To see a machine s ARP cache entries, use the command: >arp -a ARP cache entries are normally created by ARP. Also, since a station that received an ARP request will likely soon need to reply to the main IP packet that causes all the ARPing, that destination will also usually copy the IP and Ethernet hardware addresses of the router into its own ARP cache! In fact, all machines on the Ethernet segment can enter the addresses of the router into their ARP cache, and also the addresses of the destination which transmits the ARP reply. ARP cache entries are normally flushed after they age a certain amount of time (usually every 20 minutes, or in Berkeley-derived OSs 20 minutes since last being used). Also, a reboot will clean out the ARP cache tables of the rebooted machine. Page 4-13 Page 4-14

8 4.2.2 Gratuitous ARP Finally, if a host is rebooted with a different Ethernet card, I believe it will normally do an ARP Ethernet broadcast to itself. This should cause all stations on the local net to immediately overwrite the obsolete ARP cache table entry in their memories. Many, but not all brands of operating systems issue a gratuitous ARP at every boot. As described below, this checks that no other stations on the local net mistakenly have the same IP number. Page ARP Problems Actually, ARP works pretty well. But sometimes other problems will surface as an ARP malfunction. First, if a destination is non-existent or simply powered down, no reply will be forthcoming. Usually the router will try ARPing several times. If no reply is received, it may inform the upper layers (e.g. IP via ICMP) that the host is unreachable. But I have see books that say this doesn t happen, that in fact layers even further up are simply left to time out. You can sort out this problem by looking at the ARP cache within 3 minutes to see incomplete entries. When a station sends an ARP request, it enters the IP address for which it is requesting information in the cache table. If no reply is heard after 3 minutes of trying, this incomplete entry is deleted. So, try pinging the destination, abort the ping and immediately look in the cache. If the Ethernet hardware address is listed as (incomplete), you have found the problem. Also, if two stations on the same local network have mistakenly had their IP addresses set to the exact same value, serious problems occur. Possibly the wrong host s reply will be cached because it happened to get its reply to the ARP request sent back to the router first. You can delete an ARP cache entry in the router with the: >arp -d Unfortunately, this entry may re-appear very shortly due to normal traffic. You can delete an entry and immediately and permanently make a specific manual entry with the command: Page 4-16

9 >arp -s A3:56:CD:B1:1E:D9 [temp] Be warned though, that if you do not add the temp keyword, then you should remove this permanent entry manually when you finally get the source of the error fixed. Note that on systems that implement Gratuitous ARP, this situation may be obvious. If a station issues a Gratuitous ARP to itself during normal boot, it should get no replies. If it does, some other host out there has the same IP address as itself. The booting machine (possibly a user s machine, rather than the network administrator s) will display a message indicating this event, but of course it may scroll by the user rather quickly during boot. Also, not all brands of operating systems do Gratuitous ARPs Proxy ARP Proxy ARP is a form of ARP that is performed by routers on behalf of destinations. It will be discussed later. Page 4-17 Page 4-18

10 4.3 Reverse Address Resolution Protocol (RARP) We will soon see that IP address management is quite complex, especially if a major change is needed to an institution s network architecture. It is much better when dealing with hundreds of network client CPUs, to centralize their administration. That means it would be desirable if each CPU s IP number was not stored in the client machines, as changing the IP address of every CPU on the net would require visiting or telnetting hundreds of office locations all in one morning. But if it is not stored on a client machine, where is the client machine s IP address stored? At boot time, the client must check with a RARP server onthelocalnettofindoutitsipaddress. Inthis case, the client knows its Ethernet address but not its IP address. This is the reverse of the ARP situation, and so is called Reverse Address Resolution Protocol. RARP is described in RFC 903. Like ARP, RARP is not carried in an IP packet, because the originating client station doesn t know its IP address, and thus the RARP server couldn t reply using IP to the particular client! Thus RARP, like ARP, is a low level protocol at the same level as IP. RARP packets are carried directly inside Ethernet frames. RARP is also used for diskless workstations, which have no non-volatile memory in which to store their IP address. But because Ethernet addresses are burned into the Ethernet circuit cards, each diskless workstation does know its Ethernet address. Normally, the client workstation does not even know the IP address of the RARP server, so RARP Page 4-19 is designed to allow the inquiring host to broadcast the request. The payload section of an Ethernet frame carrying an RARP packet is almost exactly similar to the one for ARP. But the Ethernet header specifies the protocol type to be 8035h to indicate the Ethernet payload is RARP. A RARP packet looks almost exactly like an ARP packet: Hardware Address Type (2 bytes) Network Protocol Type (2) H/w Addr. Length (1) Net Address Length (1) Operation Code Sender Hardware Address (6) Sender Network (i.e. IP) Address (4) Target Hardware Address (6) Target Network (i.e. IP) Address (4) In contrast to ARP, RARP requests have an operation code of 3 for an RARP request, and 4 for an RARP reply. When the operation code is a 3, any RARP servers that receive the Page 4-20

11 reply know that the sender hardware address is valid and the sender IP address is junk RARP Servers To support RARP, a local net must have a RARP server, and preferably a secondary RARP server in case the primary is down. A RARP server normally has a file called /etc/ethers which contains the table of Ethernet to IP address mappings. A RARP server is normally a daemon process, rather than being part of the TCP/IP stack. And a RARP server must send and receive raw Ethernet frames, which means it can t just be listening on a well known transport layer port like most daemons do. This tends to make RARP servers very special, and hardware and OS dependent pieces of software (i.e. not portable). Listening for raw Ethernet frames requires, depending on the OS, either: BSD Packet Filter, Sun s Network Interface Tap, or Unix SVR4 Data Link Provider Interface. Finally, Section 6.4 of [Comer95] describes several issues involved in having two RARP servers on a local network, with one acting as a back-up. Page 4-21 Page 4-22

12 4.3.2 Alternatives to RARP You should be aware that there are other protocols that allow CPUs to boot and get some of their configuration data, and even their whole OS, from the network. Two protocols that come to mind are BOOTP and DHCP. In future, especially with the possible advent of the Net PC, these or even a more modern technique may supplant RARP. 4.4 References [Comer95] Internetworking with TCP/IP, Vol. 1, 4th Ed. by Douglas E. Comer, Prentice-Hall, [Stevens94] TCP/IP Illustrated, Vol. 1 by W. Richard Stevens, Addison-Wesley, Page 4-23 Page 4-24

Module 7 Internet And Internet Protocol Suite

Module 7 Internet And Internet Protocol Suite Lesson 22 IP addressing. ICMP LESSON OBJECTIVE General The lesson will continue the discussion on IPv4 along with the idea of ICMP. Specific The focus areas