IP Stack compliance

RFC1122 Compliance

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

IP Requirements

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

Multihoming

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
Yes (cause it listen on
one interface)
May require packets to exit the system through the interface... No

Broadcast

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

IP Interface

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
No (but easily doable with transversal_layer_access
if icmp implemented)
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 ?)

IP Options Requirements

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

Source route forwarding

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

IP Fragmentation and Reassembly

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

ICMP Requirements

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

Multicasting requirements

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

IGMP Requirements

May support IGMP (RFC 1112) No

Routing Requirements

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
allow the following information to be configured manually in the routing table: IP address, network
mask, list of defaults
No

ARP Requirements

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

UDP Requirements

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

TCP Requirements

PSH

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

Window

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

Urgent Data

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

TCP Options

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

TCP Checksums

Must generate a TCP checksum in outgoing segments and must verify received checksums Yes

ISN

Must use the specified clock-driven selection from RFC 793 No

Opening connections

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

Closing Connections

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)

Retransmission

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

Generating ACKs

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

Sending Data

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

Connection Failures

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

Keepalive Packets

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

IP Options

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

Receiving ICMP Messages from IP

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

Application Programming Interface

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

Table Of Contents

Previous topic

PyStack development

Next topic

Troubleshooting

This Page