This section summarizes the UDP requirements from Section 4.1.5 of RFC 1122 and the compliance of the Net/3 code that we've examined to those requirements.
Should send ICMP port unreachable.
Yes: udp_input does this.
Must pass received IP options to application.
No: The code to do this is commented out in udp_input. This means that a process that receives a UDP datagram with a source route option cannot send a reply using the reversed route.
Must allow application to specify IP options to send.
Yes: The IP_OPTIONS socket option does this. The options are saved in the PCB and placed into the outgoing IP datagram by ip_output.
Must pass IP options down to IP layer.
Yes: As mentioned above, IP places the options into the IP datagram.
Must pass received ICMP messages to application.
Yes: We must look at the exact wording from the RFC: "A UDP-based application that wants to receive ICMP error messages is responsible for maintaining the state necessary to demultiplex these messages when they arrive; for example, the application may keep a pending receive operation for this purpose." The state required by Berkeley-derived systems is that the socket be connected to the foreign address and port. As the comments at the beginning of Figure 23.26 indicate, some applications create both a connected and an unconnected socket for a given foreign port, using the connected socket to receive asynchronous errors.
Must be able to generate and verify UDP checksum.
Yes: This is done by udp_input, based on the global integer udpcksum.
Must silently discard datagrams with bad checksum.
Yes: This is done only if udpcksum is nonzero. As we mentioned earlier, this variable controls both the sending of checksums and the verification of received checksums. If this variable is 0, the kernel does not verify a received nonzero checksum.
May allow sending application to specify whether outgoing checksum is calculated, but must default to on.
No: The application has no control over UDP checksums. Regarding the default, UDP checksums are generated unless the kernel is compiled with 4.2BSD compatibility defined, or unless the administrator has disabled UDP checksums using sysctl(8).
May allow receiving application to specify whether received UDP datagrams without a checksum (i.e., the received checksum is 0) are discarded or passed to the application.
No: Received datagrams with a checksum field of 0 are passed to the receiving process.
Must pass destination IP address to application.
Yes: The application must call recvmsg and specify the IP_RECVDSTADDR socket option. Also recall our discussion following Figure 23.25 noting that 4.4BSD broke this option when the destination address is a multicast or broadcast address.
Must allow application to specify local IP address to be used when sending a UDP datagram.
Yes: The application can call bind to set the local IP address. Recall our discussion at the end of Section 22.8 about the difference between the source IP address and the IP address of the outgoing interface. Net/3 does not allow the application to choose the outgoing interface�that is done by ip_output, based on the route to the destination IP address.
Must allow application to specify wildcard local IP address.
Yes: If the IP address INADDR_ANY is specified in the call to bind, the local IP address is chosen by in_pcbconnect, based on the route to the destination.
Should allow application to learn of the local address that was chosen.
Yes: The application must call connect. When a datagram is sent on an unconnected socket with a wildcard local address, ip_output chooses the outgoing interface, which also becomes the source address. The inp_laddr member of the PCB, however, is restored to the wildcard address at the end of udp_output before sendto returns. Therefore, getsockname cannot return the value. But the application can connect a UDP socket to the destination, causing in_pcbconnect to determine the local interface and store the address in the PCB. The application can then call getsockname to fetch the IP address of the local interface.
Must silently discard a received UDP datagram with an invalid source IP address (broadcast or multicast).
No: A received UDP datagram with an invalid source address is delivered to a socket, if a socket is bound to the destination port.
Must send a valid IP source address.
Yes: If the local IP address is set by bind, it checks the validity of the address. If the local IP address is wildcarded, ip_output chooses the local address.
Must provide the full IP interface from Section 3.4 of RFC 1122.
Refer to Section C.2.
Must allow application to specify TTL, TOS, and IP options for output datagrams.
Yes: The application can use the IP_TTL, IP_TOS, and IP_OPTIONS socket options.
May pass received TOS to application.
No: There is no way for the application to receive this value from the IP header. Notice that a getsockopt of IP_TOS returns the value used in outgoing datagrams, not the value from a received datagram. The received ip_tos value is available to udp_input, but is discarded along with the entire IP header.
No comments:
Post a Comment