May support trailer encapsulation.

Partially: Net/3 does not send IP datagrams with trailer encapsulation but some Net/3 device drivers may be able to receive such datagrams. We have omitted all the trailer encapsulation code in this text. Interested readers are referred to RFC 893 and Section 11.8 of [Leffler et al. 1989] for additional details.

Must not send trailers by default without negotiation.

Not applicable: Net/2 would negotiate the use of trailers but Net/3 ignores requests to send trailers and does not request trailers itself.

Must be able to send and receive RFC 894 Ethernet encapsulation.

Yes: Net/3 supports RFC 894 Ethernet encapsulation.

Should be able to receive RFC 1042 (IEEE 802) encapsulation.

No: Net/3 processes packets received with 802.3 encapsulation but only for use with OSI protocols. IP packets that arrive with 802.3 encapsulation are discarded by ether_input (Figure 4.13).

May send RFC 1042 encapsulation, in which case there must be a software configuration switch to select the encapsulation method and RFC 894 must be the default.

No: Net/3 does not send IP packets in RFC 1042 encapsulation.

Must report link-layer broadcasts to the IP layer.

Yes: The link layer reports link-layer broadcasts by setting the M_BCAST flag (or the M_MCAST flag for multicasts) in the mbuf packet header.

Must pass the IP TOS value to the link layer.

Yes: The TOS value is not passed explicitly, but is part of the IP header available to the link layer.

Must implement IP and ICMP.

Yes: inetsw[0] implements the IP protocol and inetsw[4] implements ICMP.

Must handle remote multihoming in application layer.

Yes: The kernel is unaware of communication to remote multihomed hosts and neither hinders nor supports such communication by an application.

May support local multihoming.

Yes: Net/3 supports multiple IP interfaces with the ifnet list and multiple addresses per IP interface with the ifaddr list for each ifnet structure.

Must meet router specifications if forwarding datagrams.

Partially: See Chapter 18 for a discussion of the router requirements.

Must provide configuration switch for embedded router functionality. The switch must default to host operation.

Yes: The ipforwarding variable defaults to false and controls the IP packet forwarding mechanism in Net/3.

Must not enable routing based on number of interfaces.

Yes: The if_attach function does not modify ipforwarding according to the number of interfaces configured at system initialization time.

Should log discarded datagrams, including the contents of the datagram, and record the event in a statistics counter.

Partially: Net/3 does not provide a mechanism for logging the contents of discarded datagrams but maintains a variety of statistics counters.

Must silently discard datagrams that arrive with an IP version other than 4.

Yes: ipintr implements this requirement.

Must verify IP checksum and silently discard an invalid datagram.

Yes: ipintr calls in_cksum and implements this requirement.

Must support subnet addressing (RFC 950).

Yes: Every IP address has an associated subnet mask in the in_ifaddr structure.

Must transmit packets with host’s own IP address as the source address.

Partially: When the transport layer sends an IP datagram with all-0 bits as the source address, IP inserts the IP address of the outgoing interface in its place. A process can bind one of the local IP broadcast addresses to the local socket, and IP will transmit it as an invalid source address.

Must silently discard datagrams not destined for the host.

Yes: If the system is not configured as a router, ipintr discards datagrams that arrive with a bad destination address (i.e., an unrecognized unicast, broadcast, or multicast address).

Must silently discard datagrams with bad source address (nonunicast address).

No: ipintr does not examine the source address of incoming datagrams before delivering the datagram to the transport protocols.

Must support reassembly.

Yes: ip_reass implements reassembly.

May retain same ID field in identical datagrams.

No: ip_output assigns a new ID to every outgoing datagram and does not allow the ID to be specified by the transport protocols. See Chapter 32.

Must allow the transport layer to set TOS.

Yes: ip_output accepts any TOS value set in the IP header by the transport protocols. The transport layer must default TOS to all 0s. The TOS value for a particular datagram or connection may be set by the application through the IP_TOS socket option.

Must pass received TOS up to transport layer.

Yes: Net/3 preserves the TOS field during input processing. The entire IP header is made available to the transport layer when IP calls the pr_input function for the receiving protocol. Unfortunately, the UDP and TCP transport layers ignore it.

Should not use RFC 795 [Postel 1981d] link-layer mappings for TOS.

Yes: Net/3 does not use these mappings.

Must not send packet with TTL of 0.

Partially: The IP layer (ip_output) in Net/3 does not check this requirement and relies on the transport layers not to construct an IP header with a TTL of 0. UDP, TCP, ICMP, and IGMP all select a nonzero TTL default value. The default value can be overridden by the IP_TTL option.

Must not discard received packets with a TTL less than 2.

Yes: If the system is the final destination of the packet, ipintr accepts it regardless of the TTL value. The TTL is examined only when the packet is being forwarded.

Must allow transport layer to set TTL.

Yes: The transport layer must set TTL before calling ip_output.

Must enable configuration of a fixed TTL.

Yes: The default TTL is specified by the global integer ip_defttl, which defaults to 64 (IPDEFTTL). Both UDP and TCP use this value unless the IP_TTL socket option has specified a different value for a particular socket. ip_defttl can be modified through the IPCTL_DEFTTL name for sysctl.

Must allow transport layer to send IP options.

Yes: The second argument to ip_output is a list of IP options to include in the outgoing IP datagram.

Must pass all IP options received to higher layer.

Yes: The IP header and options are passed to the pr_input function of the receiving transport protocol.

Must silently ignore unknown options.

Yes: The default case in ip_dooptions skips over unknown options.

May support the security option.

No: Net/3 does not support the IP security option.

Should not send the stream identifier option and must ignore it in received datagrams.

Yes: Net/3 does not support the stream identifier option and ignores it on incoming datagrams.

May support the record route option.

Yes: Net/3 supports the record route option.

May support the timestamp option.

Partially: Net/3 supports the timestamp option but does not implement it exactly as specified. The originating host does not insert a timestamp when required but the destination host records a timestamp before passing the datagram to the transport layer. The timestamp value follows the rules regarding standard values as specified in Section 3.2.2.8 of RFC 1122 for the ICMP timestamp message.

Must support originating a source route and must be able to act as the final destination of a source route.

Yes: A source route may be included in the options passed to ip_output, and ip_dooptions correctly terminates a source route and saves it for use in constructing return routes.

Must pass a datagram with completed source route up to the transport layer.

Yes: The source route option is passed up with any other options that may have appeared in the datagram.

Must build correct (nonredundant) return route.

No: Net/3 blindly reverses the source route and does not check or correct for a route that was built incorrectly with a redundant hop for the original source host.

Must not send multiple source route options in one header.

No: The IP layer in Net/3 does not prohibit a transport protocol from constructing and sending multiple source route options in a single datagram.

Must be able to reassemble incoming datagrams of at least 576 bytes.

Yes: ip_reass supports reassembly of datagrams of indefinite size.

Should support a configurable or indefinite maximum size for incoming datagrams.

Yes: Net/3 supports an indefinite maximum size for incoming datagrams.

Must provide a mechanism for the transport layer to learn the maximum datagram size to receive.

Not applicable: Net/3 has an indefinite limit based on available memory.

Must send ICMP time exceeded error on reassembly timeout.

No: Net/3 does not send an ICMP time exceeded error. See Figure 10.30 and Exercise 10.1.

Should support a fixed reassembly timeout value. The remaining TTL value in a received IP fragment should not be used as a reassembly timeout value.

Yes: Net/3 uses a compile-time value of 30 seconds (IPFRAGTTL is 60 slow-timeout intervals, which equals 30 seconds).

Must provide the MMS_S (maximum message size to send) to higher layers.

Partially: TCP derives the MMS_S from the MTU found in the route entry for the destination or from the MTU of the outgoing interface. A UDP application does not have access to this information.

May support local fragmentation of outgoing packets.

Yes: ip_output fragments an outgoing packet if it is too large for the selected interface.

Must not allow transport layer to send a message larger than MMS_S if local fragmentation is not supported.

Not applicable: This is a transport-level requirement that does not apply to Net/3 since local fragmentation is supported.

Should not send messages larger than 576 bytes to a remote destination in the absence of other information regarding the path MTU to the destination.

Partially: Net/3 TCP defaults to a segment size of 552 (512 data bytes + 40 header bytes). Net/3 UDP applications cannot determine if a destination is local or remote and so they often restrict their messages to 540 bytes (512 + 20 + 8). There is no kernel mechanism that prohibits sending larger messages.

May support an all-subnets-MTU configuration flag.

Yes: The global integer subnetsarelocal defaults to true. TCP uses this flag to select a larger segment size (the size of the outgoing interface’s MTU) instead of the default segment size for destinations on a subnet of the local network.

Must silently discard ICMP messages with unknown type.

Partially: icmp_input ignores these messages and passes them to rip_input, which delivers the message to any waiting processes or silently discards the message if no process is prepared to receive the message.

May include more than 8 bytes of the original datagram.

No: The icmp_error function returns only a maximum of 8 bytes of the original datagram in the ICMP error message, Exercise 11.9.

Must return the header and data unchanged from the received datagram.

Partially: Net/3 converts the ID, offset, and length fields of an IP packet from network byte order to host byte order in ipintr. This facilitates processing the packet, but Net/3 neglects to return the offset and length fields to network byte order before including the header in an ICMP error message. If the system operates with the same byte ordering as the network, this error is harmless. If it operates with a different ordering, the IP header contained within the ICMP error message has incorrect offset and length values.

Must demultiplex received ICMP error message to transport protocol.

Yes: icmp_error uses the protocol field from the original header to select the appropriate transport protocol to respond to the error.

Should send ICMP error messages with a TOS field of 0.

Yes: All ICMP error messages are constructed with a TOS of 0 by icmp_error.

Must not send an ICMP error message caused by a previous ICMP error message.

Partially: icmp_error sends an error for an ICMP redirect message, which Section 3.2.2 of RFC 1122 classifies as an ICMP error message.

Must not send an ICMP error message caused by an IP broadcast or IP multicast datagram.

No: icmp_error does not check for this case.

Must not send an ICMP error message caused by a link-layer broadcast.

Yes: icmp_error discards ICMP messages in response to packets that arrived as link-layer broadcasts or multicasts.

Must not send an ICMP error message caused by a noninitial fragment.

Yes: icmp_error discards errors generated in this case.

Must not send an ICMP error message caused by a datagram with nonunique source address.

Yes: icmp_reflect checks for experimental and multicast addresses. ip_output discards messages sent from a broadcast address.

Must return ICMP error messages when not prohibited.

Partially: In general, Net/3 sends appropriate ICMP error messages. It fails to send an ICMP reassembly timeout message at the appropriate time (Exercise 10.1).

Should generate ICMP destination unreachable (protocol and port).

Partially: Datagrams for unsupported protocols are delivered to rip_input where they are silently discarded if there are no processes registered to accept the datagrams. UDP generates an ICMP port unreachable error.

Must pass ICMP destination unreachable to higher layer.

Yes: icmp_input passes the message to the pr_ctlinput function defined for the protocol (udp_ctlinput and tcp_ctlinput for UDP and TCP, respectively).

Should respond to destination unreachable error.

See Sections 23.9 and 27.6.

Must interpret destination unreachable as only a hint, as it may indicate a transient condition.

See Sections 23.9 and 27.6.

Must not send an ICMP redirect when configured as a host.

Yes: ip_forward, the only function that detects and sends redirects, is not called unless the system is configured as a router.

Must update route cache when an ICMP redirect is received.

Yes: ipintr calls rtredirect to process the message.

Must handle both host and network redirects. Furthermore, network redirects must be treated as host redirects.

Yes: ipintr calls rtredirect for both types of messages.

Should discard illegal redirects.

Yes: rtredirect discards illegal redirects (Section 19.7).

May send source quench if memory is unavailable.

Yes: ip_forward sends a source quench if ip_output returns ENOBUFS. This occurs when there is a shortage of mbufs or when an interface output queue is full.

Must pass source quench to higher layer.

Yes: icmp_input passes source quench errors to the transport layers.

Should respond to source quench in higher layer.

See Sections 23.9 and 27.6 for UDP and TCP processing. Neither ICMP nor IGMP accept ICMP error messages (they don’t define a pr_ctlinput function), in which case they are discarded by IP.

Must pass time exceeded error to transport layer.

Yes: icmp_input passes this message to the transport layers.

Should send parameter problem errors.

Yes: ip_dooptions complains about incorrectly formed options.

Must pass parameter problem errors to transport layer.

Yes: icmp_input passes parameter problem errors to the transport layer.

May report parameter problem errors to process.

See Sections 23.9 and 27.6 for UDP and TCP processing. Neither ICMP nor IGMP accept ICMP error messages.

Must support an echo server and should support an echo client.

Yes: icmp_input implements the echo server and the ping program implements the echo client using a raw IP socket.

May discard echo requests to a broadcast address.

No: The reply is sent by icmp_reflect.

May discard echo request to multicast address.

No: Net/3 responds to multicast echo requests. Both icmp_reflect and ip_output permit multicast destination addresses.

Must use specific destination address as echo reply source.

Yes: icmp_reflect converts a broadcast or multicast destination to the specific address of the receiving interface and uses the result as the source address for the echo reply.

Must return echo request data in echo reply.

Yes: The data portion of the echo request is not altered by icmp_reflect.

Must pass echo reply to higher layer.

Yes: ICMP echo replies are passed to rip_input for receipt by registered processes.

Must reflect record route and timestamp options in ICMP echo request message.

Yes: icmp_reflect includes the record route and timestamp options in the echo reply message.

Must reverse and reflect source route option.

Yes: icmp_reflect retrieves the reversed source route with ip_srcroute and includes it in the outgoing echo reply.

Should not support the ICMP information request or reply.

Partially: The kernel does not generate or respond to either message, but a process may send or receive the messages through the raw IP mechanism.

May implement the ICMP timestamp request and timestamp reply messages.

Yes: icmp_input implements the timestamp server functionality. The timestamp client may be implemented through the raw IP mechanism.

Must minimize timestamp delay variability (if implementing the timestamp messages).

Partially: The receive timestamp is applied after the message is taken off the IP input queue and the transmit timestamp is applied before the message is placed in the interface output queue.

May silently discard broadcast timestamp request.

No: icmp_input responds to broadcast timestamp requests.

May silently discard multicast timestamp requests.

No: icmp_input responds to broadcast timestamp requests.

Must use specific destination address as timestamp reply source address.

Yes: icmp_reflect converts a broadcast or multicast destination to the specific address of the receiving interface and uses the result as the source address for the timestamp reply.

Should reflect record route and timestamp options in an ICMP timestamp request.

Yes: icmp_reflect includes the record route and timestamp options in the timestamp reply message.

Must reverse and reflect source route option in ICMP timestamp request.

Yes: icmp_reflect retrieves the reversed source route with ip_srcroute and includes it in the outgoing timestamp reply.

Must pass timestamp reply to higher layer.

Yes: ICMP timestamp replies are passed to rip_input for receipt by registered processes.

Must obey rules for standard timestamp value.

Yes: icmp_input calls iptime, which returns a standard time value.

Must provide a configurable method for selecting the address mask selection method for an interface.

No: Net/3 supports only static configuration of address masks through the ifconfig program.

Must support static configuration of address mask.

Yes: This is accomplished indirectly by specifying static information when the ifconfig program configures an interface during system initialization, typically in the /etc/netstart start-up script.

May get address mask dynamically during system initialization.

No: Net/3 does not support the use of BOOTP or DHCP to acquire address mask information.

May get address with an ICMP address mask request and reply messages.

No: Net/3 does not support the use ICMP messages to acquire address mask information.

Must retransmit address mask request if no reply.

Not Applicable: Not required since this method is not implemented by Net/3.

Should assume default mask if no reply is received.

Not Applicable: Not required since this method is not implemented by Net/3.

Must update address mask from first reply only.

Not Applicable: Not required since this method is not implemented by Net/3.

Should perform reasonableness check on any installed address mask.

No: Net/3 performs no reasonableness check on address masks.

Must not send unauthorized address mask reply messages and must be explicitly configured to be agent.

Yes: icmp_input only responds to address mask requests if icmpmaskrepl is nonzero (it defaults to 0).

Should support an associated address mask authority flag with each static address mask configuration.

No: Net/3 consults a global authority flag (icmpmaskrepl) to determine if it should send address mask replies for any interface.

Must broadcast address mask reply when initialized.

No: Net/3 does not broadcast an address mask reply when an interface is configured.

Should support local IP multicasting (RFC 1112).

Yes: Net/3 supports IP multicasting.

Should join the all-hosts group at start-up.

Yes: in_ifinit joins the all-hosts group while initializing an interface.

Should provide a mechanism for higher layers to discover an interface’s IP multicast capability.

Yes: The IFF_MULTICAST flag in the interface’s ifnet structure is available directly to kernel code and by the SIOCGIFFLAGS command for processes.

May support IGMP (RFC 1112).

Yes: Net/3 supports IGMP.

Must use address mask in determining whether a datagram’s destination is on a connected network.

Yes: When an interface for a connected network such as an Ethernet is configured, its address mask is specified (or a default is chosen based on the class of IP address) and stored in the routing table entry. This mask is used by rn_match when it checks a leaf for a network match.

Must operate correctly in a minimal environment when there are no routers (all networks are directly connected).

Yes: The system administrator must not configure a default route in this case.

Must keep a “route cache” of mappings to next-hop routers.

Yes: The routing table is the cache.

Should treat a received network redirect the same as a host redirect.

Yes, as described in Section 19.7.

Must use a default router when no entry exists for the destination in the routing table.

Yes, if a default route has been entered into the routing table.

Must support multiple default routers.

Multiple defaults are not supported by the kernel. Instead, this should be provided by a routing daemon.

May implement a table of static routes.

Yes: These can be created at system initialization time with the route command.

May include a flag with each static route specifying whether or not the route can be overridden by a redirect.

No.

May allow the routing table key to be a complete host address and not just a network address.

Yes: Host routes take priority over a network route to the same network.

Should include the TOS in the routing table entry.

No: There is a TOS field in the sockaddr_inarp that we describe in Chapter 21, but it is not currently used.

Must be able to detect the failure of a next-hop router that appears as the gateway field in the routing table and be able to choose an alternate next-hop router.

Negative advice, the RTM_LOSING message generated by in_losing, is passed to any processes reading from a routing socket, which allows the process (e.g., a routing daemon) to handle this event.

Should not assume that a route is good forever.

Yes: There are no timeouts on routing table entries in the kernel other than those created by ARP Again, the standard Unix routing daemons time out routes and replace them with alternatives when possible.

Must not ping routers continuously (ICMP echo request).

Yes: The Net/3 kernel does not do this. The routing daemons don’t generate ICMP echo requests either.

Must use pinging of a router only when traffic is being sent to that router.

The Net/3 kernel never generates pings to a next-hop router.

Should allow higher and lower layers to give positive and negative advice.

Partially: The only information passed by other layers to the Net/3 routing functions is by in_losing, which is called only from TCP. The only action performed by the routing layer is to generate the RTM_LOSING message.

Must switch to another default router when the existing default fails.

Yes, although the Net/3 kernel does not do this, it is supported by the routing daemons.

Must allow the following information to be configured manually in the routing table: IP address, network mask, list of defaults.

Yes, but only one default is supported in the kernel.

Must provide a mechanism to flush out-of-date ARP entries. If this mechanism involves a timeout, it should be configurable.

Yes and yes: arptimer provides this mechanism. The timeout is configurable (the arpt_prune and arpt_keep globals) but the only ways to change their values are to recompile the kernel or modify the kernel with a debugger.

Must include a mechanism to prevent ARP flooding.

Yes, as we described with Figure 21.24.

Should save (rather than discard) at least one (the latest) packet of each set of packets destined to the same unresolved IP address, and transmit the saved packet when the address has been resolved.

Yes: This is the purpose of the la_hold member of the llinfo_arp structure.

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 t hat 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.