IP(4P) — SPECIAL FILES
NAME
ip − Internet Protocol
SYNOPSIS
None; included by default with inet(4F).
DESCRIPTION
The Internet Protocol is designed for use in interconnected systems of packet-switched computer communication networks. It provides for transmitting blocks of data called “datagrams” from sources to destinations, where sources and destinations are hosts identified by fixed-length addresses. It also provides for fragmentation and reassembly of long datagrams, if necessary, for transmission through “small packet” networks.
IP is specifically limited in scope. There are no mechanisms to augment end-to-end data reliability, flow control, sequencing, or other services commonly found in host-to-host protocols. IP can capitalize on the services of its supporting networks to provide various types and qualities of service.
IP is called on by host-to-host protocols, including tcp(4P) a reliable stream protocol, udp(4P) a socket-socket datagram protocol, and nd(4P) the network disk protocol. Other protocols may be layered on top of IP using the raw protocol facilities described here to receive and send datagrams with a specific IP protocol number. The IP protocol calls on local network drivers to carry the internet datagram to the next gateway or destination host.
When a datagram arrives at a UNIX system host, the system performs a checksum on the header of the datagram. If this fails, or if the datagram is unreasonably short or the header length specified in the datagram is not within range, then the datagram is dropped. Checksumming of Internet datagrams may be disabled for debugging purposes by patching the kernel variable ipcksum to have the value 0.
Next the system scans the IP options of the datagram. Options allowing for source routing (see routing(4N)) and also the collection of time stamps as a packet follows a particular route (for network monitoring and statistics gathering purposes) are handled; other options are ignored. Processing of source routing options may result in an UNREACH icmp(4P) message because the source routed host is not accessible.
After processing the options, IP checks to see if the current machine is the destination for the datagram. If not, then IP attempts to forward the datagram to the proper host. Before forwarding the datagram, IP decrements the time to live field of the datagram by IPTTLDEC seconds (currently 5 from <netinet/ip.h>), and discards the datagram if its lifetime has expired, sending an ICMP TIMXCEED error packet back to the source host. Similarly if the attempt to forward the datagram fails, then ICMP messages indicating an unreachable network, datagram too large, unreachable port (datagram would have required broadcasting on the target interface, and IP does not allow directed broadcasts), lack of buffer space (reflected as a source quench), or unreachable host. Note however, in accordance with the ICMP protocol specification, ICMP messages are returned only for the first fragment of fragmented datagrams.
It is possible to disable the forwarding of datagrams by a host by patching the kernel variable ipforwarding to have value 0.
If a packet arrives and is destined for this machine, then IP must check to see if other fragments of the same datagram are being held. If this datagram is complete, then any previous fragments of it are discarded. If this is only a fragment of a datagram, it may yield a complete set of pieces for the datagram, in which case IP constructs the complete datagram and continues processing with that. If there is yet no complete set of pieces for this datagram, then all data thus far received is held (but only one copy of each data byte from the datagram) in hopes that the rest of the pieces of the fragmented datagram will arrive and we will be able to proceed. We allow IPFRAGTTL (currently 15 in <netinet/ip.h>) seconds for all the fragments of a datagram to arrive, and discard partial fragments then if the datagram has not yet been completely assembled.
When we have a complete input datagram it is passed out to the appropriate protocol’s input routine: either tcp(4P), udp(4P), nd(4P), icmp(4P) or a user process through a raw IP socket as described below.
Datagrams are output by the system-implemented protocols tcp(4P), udp(4P), nd(4P), and icmp(4P); as well as by packet forwarding operations and user processes through raw IP sockets. Output packets are normally subjected to routing as described in routing(4N). However, special processes such as the routing daemon routed(8C) occasionally use the SO_DONTROUTE socket option to make packets avoid the routing tables and go directly to the network interface with the network number which the packet is addressed to. This may be used to test the ability of the hardware to transmit and receive packets even when we believe that the hardware is broken and have therefore deleted it from the routing tables.
If there is no route to a destination address or if the SO_DONTROUTE option is given and there is no interface on the network specified by the destination address, then the IP output routine returns a ENETUNREACH error. (This and the other IP output errors are reflected back to user processes through the various protocols, which individually describe how errors are reported.)
In the (hopefully normal) case where there is a suitable route or network interface, the destination address is checked to see if it specifies a broadcast (address INADDR_ANY; see inet(4F)); if it does, and the hardware interface does not support broadcasts, then an EADDRNOTAVAIL is returned; if the caller is not the super-user then a EACCESS error will be returned. IP also does not allow broadcast messages to be fragmented, returning a EMSGSIZE error in this case.
If the datagram passes all these tests, and is small enough to be sent in one chunk, then the system calls the output routine for the particular hardware interface to transmit the packet. The interface may give an error indication, which is reflected to IP output’s caller; see the documentation for the specific interface for a description of errors it may encounter. If a datagram is to be fragmented, it may have the IP_DF (don’t fragment) flag set (although currently this can happen only for forwarded datagrams). If it does, then the datagram will be rejected (and result in an ICMP error datagram). If the system runs out of buffer space in fragmenting a datagram then a ENOBUFS error will be returned.
IP provides a space of 255 protocols. The known protocols are defined in <netinet/in.h>. The ICMP, TCP, UDP and ND protocols are processed internally by the system; others may be accessed through a raw socket by doing:
s = socket(AF_INET, SOCK_RAW, IPPROTO_xxx);
Datagrams sent from this socket will have the current host’s address and the specified protocol number; the raw IP driver will construct an appropriate header. When IP datagrams are received for this protocol they are queued on the raw socket where they may be read with recvfrom; the source IP address is reflected in the received address.
SEE ALSO
Internet Protocol, RFC791, USC-ISI (Sun 800-1063-01)
BUGS
One should be able to send and receive IP options.
Raw sockets should receive ICMP error packets relating to the protocol; currently such packets are simply discarded.
Sun Release 3.2 — Last change: 25 July 1985