Note
This page intent to provide a brief overview of the functionalities provided regarding the RFC1122 about IP stack requirements. The informations provided are not 100% accurate.
Requirements for Internet Hosts
Communication Layers
May | Trailer encapsulation | No |
Must | Not send trailer by default | Yes |
Must | be able to send and receive RFC 894 Ethernet | Yes |
Should | receive RFC 1042 (IEEE 802) encapsulation | No |
May | Send RFC 1042 encapsulation | No |
Must | report link-layer broadcasts to the IP layer | No |
Must | pass the IP TOS value to the link layer | Yes (p.1175) |
Must | implement IP and ICMP | No (no ICMP yet) |
Must | handle remote multihoming in application layer | No (I don’t think so) |
May | support local multihoming | No |
Must | meet router specifications if forwarding datagrams | No |
Must | provide configuration switch for embedded router functionality | No |
Must | not enable routing based on number of interfaces | Yes |
Should | log discarded datagrams, including the contents of the datagram | No |
Must | silently discard datagrams that arrive with an IP version other than 4 | Yes |
Must | verify IP checksum and silently discard an invalid datagram | No (not discarded) |
Must | support subnet addressing (RFC 950) | No |
Must | transmit packets with host’s own IP address as the source address | Yes |
Must | silently discard datagrams not destined for the host | Yes |
Must | silently discard datagrams with bad source address | Yes |
Must | support reassembly | Yes (Hellyeah !) |
May | retain same ID field in identical datagrams | No |
Must | allow the transport layer to set TOS | No |
Must | pass received TOS up to transport layer | Yes |
Should | not use RFC 795 [Postel 1981d] link-layer mappings for TOS | Yes (no mapping is made :p) |
Must | not send packet with TTL of 0 | No (no verification made) |
Must | not discard received packets with a TTL less than 2 | Yes |
Must | allow transport layer to set TTL | Yes |
Must | enable configuration of a fixed TTL | No |
Should | select, as the source address for a reply, the specific address received as the destination address of the request | Yes |
Must | allow application to choose local IP address | No (only listen 1 interface) |
May | silently discard datagrams addressed to an interface other than the one on which it is received |
|
May | require packets to exit the system through the interface... | No |
Must | not select an IP broadcast address as a source address | Yes (no broadcast) |
Should | accept an all-0s or all-1s broadcast address | Yes (does not make the difference) |
May | support configurable option to send all 0s or all 1s as the broadcast | No |
Must | recognize all broadcast address formats | No |
Must | use an IP broadcast or IP multicast destination address in a link-layer broadcast | No |
Should | silently discard link-layer broadcasts when the packet does not specify an IP broadcast address as its destination | No |
Should | use limited broadcast address for connected networks | No |
Must | allow transport layer to use all IP mechanisms | Yes (giving transport layer access to all ip headers) |
Must | pass interface identification up to transport layer | No (but quite important) |
Must | pass all IP options to transport layer | No (but easily doable) |
Must | allow transport layer to send ICMP port unreachable and any of the ICMP query messages |
|
Must | pass the following ICMP messages to the transport layer:destination unreachable, source quench, echo reply, timestamp, reply, and time exceeded | No (but like previous point) |
Must | include contents of ICMP message in ICMP message passed to the transport layer | No (idem) |
Should | be able to leap tall buildings at a single bound | No (what’s that ?) |
Must | allow transport layer to send IP options | No (but why not) |
Must | pass all IP options received to higher layer | No (but why not) |
Must | silently ignore unknown options | Yes (ignore them all :p) |
May | support the security option | No |
Should | not send the stream identifier option and must ignore it in received datagrams | Yes (??) |
May | support the record route option | No |
May | support the timestamp option | No |
Must | support originating a source route and must be able to act as the final destination of a source route | No |
Must | pass a datagram with completed source route up to the transport layer | Yes (Why won’t it) |
Must | build correct (nonredundant) return route | No |
Must | not send multiple source route options in one header | No |
May | support packet forwarding with the source route option | No |
Must | obey corresponding router rules while processing source routes | No |
Must | update TTL according to gateway rules | No |
Must | generate ICMP error codes 4 and 5 | No |
Must | allow the IP source address of a source routed packet to not be an IP address of the forwarding host | No |
Must | update timestamp and record route options | No |
Must | support a configurable switch for nonlocal source routing | No |
Must | satisfy gateway access rules for nonlocal source routing | No |
Should | send an ICMP destination unreachable error (when forwarding fail) | No |
Must | be able to reassemble incoming datagrams of at least 576 bytes | Yes |
Should | support a configurable or indefinite maximum size for incoming datagrams | Yes (infinite) |
Must | provide a mechanism for the transport layer to learn the maximum datagram size to receive. | Yes |
Must | send ICMP time exceeded error on reassembly timeout | No (but doable) |
Should | support a fixed reassembly timeout value | Yes |
Must | provide the MMS_S to higher layers | No |
May | support local fragmentation of outgoing packets | Yes |
Must | not allow transport layer to send a message larger than MMS_S | No (but fragment it in ip layer in this case) |
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 | No (I don’t care :p) |
May | support an all-subnets-MTU configuration flag | No |
Must | silently discard ICMP messages with unknown type | No |
May | include more than 8 bytes of the original datagram | No |
Must | return the header and data unchanged from the received datagram | No |
Must | demultiplex received ICMP error message to transport protocol | No |
Should | send ICMP error messages with a TOS field of 0 | No |
Must | not send an ICMP error message caused by a previous ICMP error message | No |
Must | not send an ICMP error message caused by an IP broadcast or IP multicast datagram | No |
Must | not send an ICMP error message caused by a link-layer broadcast | No |
Must | not send an ICMP error message caused by a noninitial fragment | No |
Must | not send an ICMP error message caused by a datagram with nonunique source address | No |
Must | return ICMP error messages when not prohibited | No |
Should | generate ICMP destination unreachable | No |
Must | pass ICMP destination unreachable to higher layer | No |
Should | respond to destination unreachable error | No |
Must | interpret destination unreachable as only a hint, as it may indicate a transient condition | No |
Must | not send an ICMP redirect when configured as a host. | No |
Must | update route cache when an ICMP redirect is received | No |
Must | handle both host and network redirects | No |
Should | discard illegal redirects | No |
May | send source quench if memory is unavailable | No |
Must | pass source quench to higher layer | No |
Should | respond to source quench in higher layer | No |
Must | pass time exceeded error to transport layer | No |
Should | send parameter problem errors | No |
Must | pass parameter problem errors to transport layer | No |
May | report parameter problem errors to process | No |
Must | support an echo server and should support an echo client | No |
May | discard echo requests to a broadcast address | No |
May | discard echo request to multicast address | No |
Must | use specific destination address as echo reply source | No |
Must | return echo request data in echo reply | No |
Must | pass echo reply to higher layer | No |
Must | reflect record route and timestamp options in ICMP echo request message | No |
Must | reverse and reflect source route option | No |
Should | not support the ICMP information request or reply | No |
May | implement the ICMP timestamp request and timestamp reply messages | No |
Must | minimize timestamp delay variability | No |
May | silently discard broadcast timestamp request | No |
May | silently discard multicast timestamp requests | No |
Must | use specific destination address as timestamp reply source address | No |
Should | reflect record route and timestamp options in an ICMP timestamp request | No |
Must | reverse and reflect source route option in ICMP timestamp request | No |
Must | pass timestamp reply to higher layer | No |
Must | obey rules for standard timestamp value | No |
Must | provide a configurable method for selecting the address mask selection method for an inter | No |
Must | support static configuration of address mask | No |
May | get address mask dynamically during system initialization | No |
May | get address with an ICMP address mask request and reply messages | No |
Must | retransmit address mask request if no reply | No |
Should | assume default mask if no reply is received | No |
Must | update address mask from first reply only | No |
Should | perform reasonableness check on any installed address mask | No |
Must | not send unauthorized address mask reply message and must be explicitly configured as agent | No |
Should | support an associated address mask authority flag with each address mask configuration | No |
Must | broadcast address mask reply when initialized | No |
Should | support local IP multicasting (RFC 1112) | No |
Should | join the all-hosts group at start-up | No |
Should | provide a mechanism for higher layers to discover an interface’s IP multicast capability | No |
May | support IGMP (RFC 1112) | No |
Must | use address mask in determining whether a datagram’s destination is on a connected network | Yes (but made by scapy) |
Must | operate correctly in a minimal environment when there are no routers | Yes (it should I hope) |
Must | keep a “route cache” of mappings to next-hop routers | Yes |
Should | treat a received network redirect the same as a host redirect | No |
Must | use a default router when no entry exists for the destination in the routing table | Yes |
Must | support multiple default routers | No (i don’t think so) |
May | implement a table of static routes | Yes |
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 |
Should | include the TOS in the routing table entry | No (I do not hold the routing table directly) |
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 | No |
Should | not assume that a route is good forever | Yes (for sure) |
Must | not ping routers continuously (ICMP echo request) | Yes |
Must | use pinging of a router only when traffic is being sent to that router | No |
Should | allow higher and lower layers to give positive and negative advice | No |
Must | switch to another default router when the existing default fails | No |
Must |
|
No |
Must | provide a mechanism to flush out-of-date ARP entries | No (but easily doable) |
Must | include a mechanism to prevent ARP flooding | No |
Should | save (rather than discard) at least one (the latest) packet of each set of packets destined to the same unresolved IP address | Yes |
Should | send ICMP port unreachable | No |
Must | pass received IP options to application | No (just ipsrc, ipdst) |
Must | allow application to specify IP options to send | No |
Must | pass IP options down to IP layer | No |
Must | pass received ICMP messages to application | No |
Must | be able to generate and verify UDP checksum | Yes (made by scapy) |
Must | silently discard datagrams with bad checksum | No |
May | allow sending application to specify whether outgoing checksum is calculated, but must default to on | No |
May | allow receiving application to specify whether received UDP datagrams without a checksum | No |
Must | pass destination IP address to application | Yes |
Must | allow application to specify local IP address to be used when sending a UDP datagram | No |
Must | allow application to specify wildcard local IP address | No |
Should | allow application to learn of the local address that was chosen | No |
Must | silently discard a received UDP datagram with an invalid source IP address | No |
Must | send a valid IP source address | Yes |
Must | provide the full IP interface from Section 3.4 of RFC 1122 | ?? |
Must | allow application to specify TTL, TOS, and IP options for output datagrams | No |
May | pass received TOS to application | No |
May | aggregate data sent by the user without the PSH flag | No |
May | queue data received without the PSH flag | No |
Sender | should collapse successive PSH flags when it packetizes data | No |
May | implement PSH flag on write calls | Yes |
Since | PSH flag is not part of the write call, must not buffer data indefinitely | No |
May | pass received PSH flag to application | Yes |
Should | send maximum-sized segment whenever possible, to improve performance | No |
Must | treat window size as an unsigned number. | Yes | |
Receiver| must not shrink the window | Yes | |
Sender | must be robust against window shrinking | No | |
May | keep offered receive window closed indefinitely | No | |
Sender | must probe a zero window | No | |
Should | send first zero-window probe when the window has been closed for the RTO | No | |
Should | exponentially increase the interval between successive probes | No | |
Must | allow peer’s window to stay closed indefinitely | No | |
Sender | must not timeout a connection just because the other end keeps advertising a zero window | No |
Must | have urgent pointer point to last byte of urgent data | No |
Must | support a sequence of urgent data of any length | Yes |
Must | inform the receiving process (1) when TCP receives an urgent pointer and there was no previously pending urgent data | No |
Must | be a way for the process to determine how much urgent data remains | No |
Must | be able to receive TCP options in any segment | Yes |
Must | ignore any options not supported | Yes |
Must | cope with an illegal option length | No |
Must | implement both sending and receiving the MSS option | Yes |
Should | send an MSS option in every SYN when its receive MSS | yes |
Should | If an MSS option is not received with a SYN, must assume a default MSS of 536 | No |
Must | calculate the “effective send MSS.” | Yes |
Must | generate a TCP checksum in outgoing segments and must verify received checksums | Yes |
Must | use the specified clock-driven selection from RFC 793 | No |
Must | support simultaneous open attempts | No |
Must | keep track of whether it reached the SYN_RCVD state from the LISTEN or SYN_SENT states | No (but could be interesting to know) |
Must | A passive open must not affect previously created connections | Yes |
Must | allow a listening socket with a given local port at the same time that another socket with the same local port is in the SYN_SENT or SYN_RCVD state | Yes |
Must | ask IP to select a local IP address to be used as the source IP address when the source IP address is not specified by the process performing an active open on a multihomed host | No |
Must | continue to use the same source IP address for all segment sent on a connnection | Yes |
Must | not allow an active open for a broadcast or multicast foreign address | No |
Must | ignore incoming SYNs with an invalid source address | No |
Should | allow an RST to contain data | Yes |
Must | inform process whether other end closed the connection normally (FIN normal, RST aborted) | No |
May | implement a half-close | No |
Must | If the process completely closes a connection TCP should send RST indicating data was lost | Yes |
Must | linger in TIME_WAIT state for twice the MSL | No |
May | accept a new SYN from a peer to reopen a connection directly from the TIME_WAIT state | No (cause TIME_WAIT not implemented) |
Must | implement Van Jacobson’s slow start and congestion avoidance | No |
May | reuse the same IP identifier field when a retransmission is identical to the original packet | Yes may |
Must | implement Jacobson’s algorithm for calculating the RTO and Karn’s algorithm for selecting the RTT measurements | No |
Must | include an exponential backoff for successive RTO values | No |
Must | Retransmission of SYN segments should use the same algorithm as data segments | Yes |
Should | initialize estimation parameters to calculate an initial RTO of 3 seconds | Yes (static) |
Should | have a lower bound on the RTO measured in fractions of a second and an upper bound of twice the MSL | No |
Should | queue out-of-order segments | Yes |
Must | process all queued segments before sending any ACKs | No |
May | generate an immediate ACK for an out-of-order segment | Yes |
Should | implement delayed ACKs and the delay must be less than 0.5 second | No |
Should | send an ACK for at least every second segment | No |
Must | include silly window syndrome avoidance in the receiver | No |
Must | The TTL value for TCP segments must be configurable | No |
Must | include sender silly window syndrome avoidance | No |
Should | implement the Nagle algorithm | No |
Must | allow a process to disable the Nagle algorithm on a given connection | No |
Must | pass negative advice to IP when the number of retransmissions for a given segment exceeds some value R1 | No (Figure 25.26) |
Must | close a connection when the number of retransmissions for a given segment exceeds some value R2 | No (Figure 25.26) |
Must | allow process to set the value of R2 | No (Figure 25.26) |
Should | inform the process when R1 is reached and before R2 is reached | No |
Should | default R1 to at least 3 retransmissions and R2 to at least 100 seconds | No |
Must | handle SYN retransmissions in the same general way as data retransmissions | No |
Must | set R2 to at least 3 minutes for a SYN | No |
May | provide keepalives | No |
Must | allow process to turn keepalives on or off, and must default to off | No |
Must | send keepalives only when connection is idle for a given period | No |
Must | allow the keepalive interval to be configurable and must default to no less than 2 hours | No |
Must | not interpret the failure to respond to any given probe as a dead connection | No |
Must | ignore received IP options it doesn’t understand | Yes |
May | support the timestamp and record route options in received segments | No (but easily doable) |
Must | save a received source route in a connection that is passively opened and use the return route for all segments sent on this connection | No |
Receipt of an ICMP source quench should trigger slow start | No | |
Receipt of a network unreachable, host unreachable, or source route failed must not cause TCP to abort the connection and the process should be informed | No | |
Receipt of a protocol unreachable, port unreachable, or fragmentation required and DF bit set should abort an existing connection | No | |
Should | handle time exceeded and parameter problem errors | No |
Must | be a method for reporting soft errors to the process normally in an asynchronous fashion | No |
Must | allow process to specify TOS for segments sent on a connection | No |
May | pass most recently received TOS to process | No |
May | implement a “flush” call | No |
Must | allow process to specify local IP address before either an active open or a passive open | Yes (called by bind/accept or connect |