11.7 Request Processing
Net/3 responds to properly formatted ICMP request messages but passes invalid ICMP request messages to rip_input. We show in Chapter 32 how ICMP request messages may be generated by an application process.
Most ICMP request messages received by Net/3 generate a reply message, except the router advertisement message. To avoid allocation of a new mbuf for the reply, icmp_input converts the mbuf containing the incoming request to the reply and returns it to the sender. We discuss each request separately.
Echo Query: ICMP_ECHO and ICMP_ECHOREPLY
For all its simplicity, an ICMP echo request and reply is arguably the single most powerful diagnostic tool available to a network administrator. Sending an ICMP echo request is called pinging a host, a reference to the ping program that most systems provide for manually sending ICMP echo requests. Chapter 7 of Volume 1 discusses ping in detail.
The program ping is named after sonar pings used to locate objects by listening for the echo generated as the ping is reflected by the other objects. Volume 1 incorrectly described the name as standing for Packet InterNet Groper.
Figure 11.20 shows the structure of an ICMP echo and reply message.
icmp_code is always 0. icmp_id and icmp_seq are set by the sender of the request and returned without modification in the reply. The source system can match requests and replies with these fields. Any data that arrives in icmp_data is also reflected. Figure 11.21 shows the ICMP echo processing and also the common code in icmp_input that implements the reflection of ICMP requests.
235-237 icmp_input converts an echo request into an echo reply by changing icmp_type to ICMP_ECHOREPLY and jumping to reflect to send the reply.
277-282 After constructing the reply for each ICMP request, icmp_input executes the code at reflect. The correct datagram length is restored, the number of requests and the type of ICMP messages are counted in icps_reflect and icps_outhist[], and icmp_reflect (Section 11.12) sends the reply back to the requestor.
Timestamp Query: ICMP_TSTAMP and ICMP_TSTAMPREPLY
The ICMP timestamp message is illustrated in Figure 11.22.
icmp_code is always 0. icmp_id and icmp_seq serve the same purpose as those in the ICMP echo messages. The sender of the request sets icmp_otime (the time the request originated); icmp_rtime (the time the request was received) and icmp_ttime (the time the reply was transmitted) are set by the sender of the reply. All times are in milliseconds since midnight UTC; the high-order bit is set if the time value is recorded in nonstandard units, as with the IP timestamp option.
Figure 11.23 shows the code that implements the timestamp messages.
238-246 icmp_input responds to an ICMP timestamp request by changing icmp_type to ICMP_TSTAMPREPLY, recording the current time in icmp_rtime and icmp_ttime, and jumping to reflect to send the reply.
It is difficult to set icmp_rtime and icmp_ttime accurately. When the system executes this code, the message may have already waited on the IP input queue to be processed and icmp_rtime is set too late. Likewise, the datagram still requires processing and may be delayed in the transmit queue of the network interface so icmp_ttime is set too early here. To set the timestamps closer to the true receive and transmit times would require modifying the interface drivers for every network to understand ICMP messages (Exercise 11.8).
Address Mask Query: ICMP_MASKREQ and ICMP_MASKREPLY
The ICMP address mask request and reply are illustrated in Figure 11.24.
RFC 950 [Mogul and Postel 1985] added the address mask messages to the original ICMP specification. They enable a system to discover the subnet mask in use on a network.
RFC 1122 forbids sending mask replies unless a system has been explicitly configured as an authoritative agent for address masks. This prevents a system from sharing an incorrect address mask with every system that sends a request. Without administrative authority to respond, a system should ignore address mask requests.
If the global integer icmpmaskrepl is nonzero, Net/3 responds to address mask requests. The default value is 0 and can be changed by icmp_sysctl through the sysctl(8) program (Section 11.14).
In Net/2 systems there was no mechanism to control the reply to address mask requests. As a result, it is very important to configure Net/2 interfaces with the correct address mask; the information is shared with any system on the network that sends an address mask request.
The address mask message processing is shown in Figure 11.25.
247-256 If the system is not configured to respond to mask requests, or if the request is too short, this code breaks out of the switch and passes the message to rip_input (Figure 11.15).
Net/3 fails to increment icps_badlen here. It does increment icps_badlen for all other ICMP length errors.
Select subnet mask
257-267 If the request was sent to 0.0.0.0 or 255.255.255.255, the source address is saved in icmpdst where it is used by ifaof_ifpforaddr to locate the in_ifaddr structure on the same network as the source address. If the source address is 0.0.0.0 or 255.255.255.255, ifaof_ifpforaddr returns a pointer to the first IP address associated with the receiving interface.
The default case (for unicast or directed broadcasts) saves the destination address for ifaof_ifpforaddr.
Convert to reply
269-270 The request is converted into a reply by changing icmp_type and by copying the selected subnet mask, ia_sockmask, into icmp_mask.
Select destination address
271-276 If the source address of the request is all 0s ("this host on this net," which can be used only as a source address during bootstrap, RFC 1122), then the source does not know its own address and Net/3 must broadcast the reply so the source system can receive the message. In this case, the destination for the reply is ia_broadaddr or ia_dstaddr if the receiving interface is on a broadcast or point-to-point network, respectively. icmp_input puts the destination address for the reply in ip_src since the code at reflect (Figure 11.21) calls icmp_reflect, which reverses the source and destination addresses. The addresses of a unicast request remain unchanged.
Information Query: ICMP_IREQ and ICMP_IREQREPLY
The ICMP information messages are obsolete. They were intended to allow a host to discover the number of an attached IP network by broadcasting a request with 0s in the network portion of the source and destination address fields. A host responding to the request would return a message with the appropriate network numbers filled in. Some other method was required for a host to discover the host portion of the address.
RFC 1122 recommends that a host not implement the ICMP information messages because RARP (RFC 903 [Finlayson et al. 1984]), and BOOTP (RFC 951 [Croft and Gilmore 1985]) are better suited for discovering addresses. A new protocol, the Dynamic Host Configuration Protocol (DHCP), described in RFC 1541 [Droms 1993], will probably replace and augment the capabilities of BOOTP. It is currently a proposed standard.
Net/2 did respond to ICMP information request messages, but Net/3 passes them on to rip_input.
Router Discovery: icmp_routeradvert and icmp_routersolicit
RFC 1256 defines the ICMP router discovery messages. The Net/3 kernel does not process these messages directly but instead passes them, by rip_input, to a user-level daemon, which sends and responds to the messages.
Section 9.6 of Volume 1 discusses the design and operation of these messages.
| 
No comments:
Post a Comment