27.2 IPv4 Options

In Figure A.1, we show options following the 20-byte IPv4 header. As noted there, the 4-bit header length field limits the total size of the IPv4 header to 15 32-bit words (60 bytes), so the size of the IP options is limited to 40 bytes. Ten different options are defined for IPv4:

1. NOP: no-operation鈥擜 one-byte option typically used for padding to make a later option fall on a four-byte boundary.

2. EOL: end-of-list鈥擜 one-byte option that terminates option processing. Since the total size of the IP options must be a multiple of four bytes, EOL bytes follow the final option.

3. LSRR: loose source and record route (Section 8.5 of TCPv1)鈥擶e will show an example of this shortly.

4. SSRR: strict source and record route (Section 8.5 of TCPv1)鈥擶e will show an example of this shortly.

5. Timestamp (Section 7.4 of TCPv1).

6. Record route (Section 7.3 of TCPv1).

7. Basic security (obsolete).

8. Extended security (obsolete).

9. Stream identifier (obsolete).

10. Router alert鈥擳his option is described in RFC 2113 [Katz 1997]. This option is included in IP datagrams that should be examined by all routers that forward the datagram.

Chapter 9 of TCPv2 provides further details on the kernel processing of the first six options, and the indicated sections in TCPv1 provide examples of their use.

The getsockopt and setsockopt functions (with a level of IPPROTO_IP and an optname of IP_OPTIONS) fetch and set the IP options. The fourth argument to getsockopt and setsockopt is a pointer to a buffer (whose size is 44 bytes or less), and the fifth argument is the size of this buffer. The reason that the size of this buffer for getsockopt can be four bytes larger than the maximum size of the options is because of the way the source route option is handled, as we will describe shortly. Other than the two source route options, the format of what goes into the buffer is the format of the options when placed into the IP datagram.

When the IP options are set using setsockopt, the specified options will then be sent on all IP datagrams on that socket. This works for TCP, UDP, and raw IP sockets. To clear these options, call setsockopt and specify either a null pointer as the fourth argument or a value of 0 as the fifth argument (the length).

Setting the IP options for a raw IP socket does not work on all implementations if the IP_HDRINCL socket option (which we will describe in the next chapter) is also set. Many Berkeley-derived implementations do not send the options set with IP_OPTIONS when IP_HDRINCL is enabled, because the application can set its own IP options in the IP header it builds (pp. 1056鈥?057 of TCPv2). Other systems (e.g., FreeBSD) allow the application to specify IP options using either the IP_OPTIONS socket option or by setting IP_HDRINCL and including them in the IP header that it builds, but not both.

When getsockopt is called to fetch the IP options for a connected TCP socket that was created by accept, all that is returned is the reversal of the source route option received with the client's SYN for the listening socket (p. 931 of TCPv2). The source route is automatically reversed by TCP because the source route specified by the client was from the client to the server, but the server needs to use the reverse of this route in datagrams it sends to the client. If no source route accompanied the SYN, then the value-result length returned by getsockopt through its fifth argument will be 0. For all other TCP sockets and for all UDP sockets and raw IP sockets, calling getsockopt to fetch the IP options just returns a copy of whatever IP options have been set by setsockopt for the socket. Note that for a raw IP socket, the received IP header, including any IP options, is always returned by the input functions, so the received IP options are always available.

Berkeley-derived kernels have never returned a received source route, or any other IP options, for a UDP socket. The code shown on p. 775 of TCPv2 to return the IP options has existed since 4.3BSD Reno, but has always been commented out since it does not work. This makes it impossible for a UDP application to use the reverse of a received route for datagrams back to the sender.