IP(7P-SysV) RISC/os Reference Manual IP(7P-SysV)
NAME
ip - Internet Protocol
SYNOPSIS
None; included by default with inet(7F).
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 reassem-
bly of long datagrams, if necessary, for transmission
through ``small packet'' networks.
IP is specifically limited in scope. There are no mechan-
isms 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 sup-
porting networks to provide various types and qualities of
service.
IP is called on by host-to-host protocols, including
udp(7P), a socket-socket datagram protocol. Other protocols
may be layered on top of IP using the raw protocol facili-
ties 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 routed(1M)) 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(7P) 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
Printed 1/28/91 Page 1
IP(7P-SysV) RISC/os Reference Manual IP(7P-SysV)
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 unreach-
able host. Note however, in accordance with the ICMP proto-
col 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 pre-
vious 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 udp(7P),
icmp(7P), or a user process through a raw IP socket as
described below.
Datagrams are output by the system-implemented protocols
udp(7P) and icmp(7P) as well as by packet forwarding opera-
tions and user processes through raw IP sockets. Output
packets are normally subjected to routing as described in
routed(1M). However, special processes such as the routing
daemon routed(1M) 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.
Page 2 Printed 1/28/91
IP(7P-SysV) RISC/os Reference Manual IP(7P-SysV)
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(7F)); 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 EAC-
CESS error will be returned. IP also does not allow broad-
cast 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 documenta-
tion 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 and UDP 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
send(2), recv(2), inet(7F)
Internet Protocol, RFC791
ERRORS
One should be able to send and receive IP options.
Printed 1/28/91 Page 3
IP(7P-SysV) RISC/os Reference Manual IP(7P-SysV)
Raw sockets should receive ICMP error packets relating to
the protocol; currently such packets are simply discarded.
Page 4 Printed 1/28/91