IP(3)                                                       IP(3)

     NAME
          ip - network protocols over IP

     SYNOPSIS
          bind -a #Ispec /net

          /net/ipifc
          /net/ipifc/clone
          /net/ipifc/stats
          /net/ipifc/n
          /net/ipifc/n/status
          /net/ipifc/n/ctl
          ...

          /net/arp
          /net/log
          /net/ndb
          /net/iproute
          /net/ipselftab

          /net/esp
          /net/gre
          /net/icmp
          /net/il
          /net/ipmux
          /net/rudp
          /net/tcp
          /net/udp

          /net/tcp/clone
          /net/tcp/stats
          /net/tcp/n
          /net/tcp/n/data
          /net/tcp/n/ctl
          /net/tcp/n/local
          /net/tcp/n/remote
          /net/tcp/n/status
          /net/tcp/n/listen
          ...

     DESCRIPTION
          The IP device provides the interface to Internet protocol
          stacks.  Spec is an integer from 0 to 15 identifying a
          stack.  Each stack is physically independent of all others:
          the only information transfer between them is via programs
          that mount multiple stacks.  Normally a system uses only one
          stack.  However multiple stacks can be used for debugging
          new IP networks or implementing firewalls or proxy services.

          All addresses used are 16-byte IPv6 addresses.  Though we

     Page 1                       Plan 9             (printed 12/2/22)

     IP(3)                                                       IP(3)

          currently implement only IPv4, the IPv6 format is intended
          to prepare the way for an IPv6 implementation.  IPv4
          addresses are a subset of the IPv6 addresses and both stan-
          dard ASCII formats are accepted.  In binary, all v4
          addresses start with the 12 bytes:
               00 00 00 00 00 00 00 00 00 00 ff ff

        Configuring interfaces
          Each stack may have multiple interfaces and each interface
          may have multiple addresses.  The /net/ipifc directory con-
          tains a clone file, a stats file, and numbered subdirecto-
          ries for each physical interface.

          Opening the clone file reserves an interface.  The file
          descriptor returned from the open(2) will point to the con-
          trol file, ctl, of the newly allocated interface.  Reading
          ctl returns a text string representing the number of the
          interface.  Writing ctl alters aspects of the interface.
          The possible ctl messages are:

          bind ether path
               Treat the device mounted at path as an Ethernet medium
               carrying IP and ARP packets and associate it with this
               interface.  The kernel will dial(2) path!0x800 and
               path!0x806 and use the two connections for IP and ARP
               respectively.

          bind pkt
               Treat this interface as a packet interface.  Assume a
               user program will read and write the data file to
               receive and transmit IP packets to the kernel.  This is
               used by programs such as ppp(8) to mediate IP packet
               transfer between the kernel and a PPP encoded device.

          bind netdev path
               Treat this interface as a packet interface.  The kernel
               will open path and read and write the resulting file
               descriptor to receive and transmit IP packets.

          unbind
               Disassociate the physical device from an IP interface.

          add local mask remote mtu proxy
               Add a local IP address to the interface.  The mask,
               remote, mtu, and proxy arguments are all optional.  The
               default mask is the class mask for the local address.
               The default remote address is local ANDed with mask.
               The default mtu is 1514 for Ethernet and 4096 for
               packet media.  Proxy, if specified, means that this
               machine should answer ARP requests for the remote
               address.  Ppp(8) does this to make remote machines
               appear to be connected to the local Ethernet.

     Page 2                       Plan 9             (printed 12/2/22)

     IP(3)                                                       IP(3)

          remove local mask
               Remove a local IP address from an interface.

          mtu n
               Set the maximum transfer unit for this device to n. The
               mtu is the maximum size of the packet including any
               medium-specific headers.

          iprouting n
               Allow (nismissing or non-zero) or disallow (n is 0)
               forwarding packets between this interface and others.

          addmulti addr
               Treat the multicast addr on this interface as a local
               address.

          remmulti addr
               Remove the multicast address addr from this interface.

          Reading the interface's status file returns information
          about the interface, one line for each local address on that
          interface.  The first line has 9 white-space-separated
          fields: device, mtu, local address, mask, remote or network
          address, packets in, packets out, input errors, output
          errors.  Each subsequent line contains all but the device
          and mtu.  See readipifc in ip(2).

        Routing
          The file iproute controls information about IP routing.
          When read, it returns one line per routing entry.  Each line
          contains six white-space-separated fields: target address,
          target mask, address of next hop, flags, tag, and interface
          number.  The entry used for routing an IP packet is the one
          with the longest mask for which destination address ANDed
          with target mask equals the target address.  The one charac-
          ter flags are:

          4    IPv4 route

          6    IPv6 route

          i    local interface

          b    broadcast address

          u    local unicast address

          m    multicast route

          p    point-to-point route

          The tag is an arbitrary, up to 4 character, string.  It is

     Page 3                       Plan 9             (printed 12/2/22)

     IP(3)                                                       IP(3)

          normally used to indicate what routing protocol originated
          the route.

          Writing to /net/iproute changes the route table.  The mes-
          sages are:

          flush
               Remove all routes.

          tag string
               Associate the tag, string, with all subsequent routes
               added via this file descriptor.

          add target mask nexthop
               Add the route to the table.  If one already exists with
               the same target and mask, replace it.

          remove target mask
               Remove a route with a matching target and mask.

        Address resolution
          The file /net/arp controls information about address resolu-
          tion.  The kernel automatically updates the ARP information
          for Ethernet interfaces.  When read, the file returns one
          line per address containing the type of medium, the status
          of the entry (OK, WAIT), the IP address, and the medium
          address.  Writing to /net/arp administers the ARP informa-
          tion.  The control messages are:

          flush
               Remove all entries.

          add type IP-addr Media-addr
               Add an entry or replace an existing one for the same IP
               address.

          ARP entries do not time out.  The ARP table is a cache with
          an LRU replacement policy.  The IP stack listens for all ARP
          requests and, if the requester is in the table, the entry is
          updated.  Also, whenever a new address is configured onto an
          Ethernet, an ARP request is sent to help update the table on
          other systems.

          Currently, the only medium type is ether.

        Debugging and stack information
          If any process is holding /net/log open, the IP stack queues
          debugging information to it.  This is intended primarily for
          debugging the IP stack.  The information provided is
          implementation-defined; see the source for details.  Gener-
          ally, what is returned is error messages about bad packets.

     Page 4                       Plan 9             (printed 12/2/22)

     IP(3)                                                       IP(3)

          Writing to /net/log controls debugging.  The control mes-
          sages are:

          set arglist
               Arglist is a space-separated list of items for which to
               enable debugging.  The possible items are: ppp, ip, fs,
               tcp, il, icmp, udb, compress, ilmsg, gre, tcpmsg,
               udpmsg, ipmsg, and esp.

          clear arglist
               Arglist is a space-separated list of items for which to
               disable debugging.

          only addr
               If addr is non-zero, restrict debugging to only those
               packets whose source or destination is that address.

          The file /net/ndb can be read or written by programs.  It is
          normally used by ipconfig(8) to leave configuration informa-
          tion for other programs such as dns and cs (see ndb(8)).
          /net/ndb may contain up tp 1024 bytes.

          The file /net/ipselftab is a read-only file containing all
          the IP addresses considered local.  Each line in the file
          contains three white-space-separated fields: IP address,
          usage count, and flags.  The usage count is the number of
          interfaces to which the address applies.  The flags are the
          same as for routing entries.

        Protocol directories
          The ip device supports IP as well as several protocols that
          run over it: TCP, IL, UDP, GRE, ESP, ICMP, and RUDP.  TCP
          and UDP provide the standard Internet protocols for reliable
          stream and unreliable datagram communication.  IL provides a
          reliable datagram service for communication between Plan 9
          machines.  GRE is a general encapsulation protocol.  ESP is
          the encapsulation protocol for IPSEC.  ICMP is IP's catch-
          all control protocol used to send low level error messages
          and to implement ping(8). RUDP is a locally developed reli-
          able datagram protocol based on UDP.  IL is the protocol of
          choice for most Plan 9 services.

          Each protocol is a subdirectory of the IP stack.  The top
          level directory of each protocol contains a clone file, a
          stats file, and subdirectories numbered from zero to the
          number of connections opened for this protocol.

          Opening the clone file reserves a connection.  The file
          descriptor returned from the open(2) will point to the con-
          trol file, ctl, of the newly allocated connection.  Reading
          ctl returns a text string representing the number of the
          connection.  Connections may be used either to listen for

     Page 5                       Plan 9             (printed 12/2/22)

     IP(3)                                                       IP(3)

          incoming calls or to initiate calls to other machines.

          A connection is controlled by writing text strings to the
          associated ctl file.  After a connection has been estab-
          lished data may be read from and written to data.  A connec-
          tion can be actively established using the connect message
          (see also dial(2)). A connection can be established pas-
          sively by first using an announce message (see dial(2)) to
          bind to a local port and then opening the listen file (see
          dial(2)) to receive incoming calls.

          The following control messages are supported:

          connect ipaddress!port!r local
               Establish a connection to the remote address ipaddress
               and remote port port. If local is specified, it is used
               as the local port number.  If local is not specified
               but !r is, the system will allocate a restricted port
               number (less than 1024) for the connection to allow
               communication with Unix login and exec services.  Oth-
               erwise a free port number starting at 5000 is chosen.
               The connect fails if the combination of local and
               remote address/port pairs are already assigned to
               another port.

          announce X
               X is a decimal port number or `*'.  Set the local port
               number to X and accept calls to X. If X is `*', accept
               calls for any port that no process has explicitly
               announced.  The local IP address cannot be set.
               Announce fails if the connection is already announced
               or connected.

          bind X
               X is a decimal port number or `*'.  Set the local port
               number to X. This exists to support emulation of BSD
               sockets byt the APE libraries (see pcc(1)) and is not
               otherwise used.

          backlog n
               Set the maximum number of unanswered (queued) incoming
               connections to an announced port to n. By default n is
               set to five.  If more than n connections are pending,
               further requests for a service will be rejected.

          ttl n
               Set the time to live IP field in outgoing packets to n.

          tos n
               Set the service type IP field in outgoing packets to n.

          Port numbers must be in the range 1 to 32767.

     Page 6                       Plan 9             (printed 12/2/22)

     IP(3)                                                       IP(3)

          Several files report the status of a connection.  The remote
          and local files contain the IP address and port number for
          the remote and local side of the connection.  The status
          file contains protocol-dependent information to help debug
          network connections.  On receiving and error or EOF reading
          or writing the data file, the err file contains the reason
          for error.

          A process may accept incoming connections by open(2)ing the
          listen file.  The open will block until a new connection
          request arrives.  Then open will return an open file
          descriptor which points to the control file of the newly
          accepted connection.  This procedure will accept all calls
          for the given protocol.  See dial(2).

        TCP
          TCP connections are reliable point-to-point byte streams;
          there are no message delimiters.  A connection is determined
          by the address and port numbers of the two ends.  TCP ctl
          files support the following additional messages:

          hangup
               close down a TCP connection

          keepalive n
               turn on keep alive messages.  N, if given, is the mil-
               liseconds between keepalives (default 30000).

        UDP
          UDP connections carry unreliable and unordered datagrams.  A
          read from data will return the next datagram, discarding
          anything that doesn't fit in the read buffer.  A write is
          sent as a single datagram.

          By default, a UDP connection is a point-to-point link.
          Either a connect establishes a local and remote address/port
          pair or after an announce, each datagram coming from a dif-
          ferent remote address/port pair establishes a new incoming
          connection.  However, many-to-one semantics is also possi-
          ble.

          If, after an announce, one of the following messages is
          written to ctl, then all messages sent to the announced port
          are received on the announced connection prefixed with the
          given structure.

          headers4
               typedef struct Udphdr4 Udphdr4;
               struct Udphdr
               {
                    uchar     raddr[4];      /* v4 remote address and port */
                    uchar     laddr[4];      /* v4 local address and port */

     Page 7                       Plan 9             (printed 12/2/22)

     IP(3)                                                       IP(3)

                    uchar     rport[2];
                    uchar     lport[2];
               };

          headers
               typedef struct Udphdr Udphdr;
               struct Udphdr
               {
                    uchar     raddr[16];     /* v6 remote address and port */
                    uchar     laddr[16];     /* v6 local address and port */
                    uchar     rport[2];
                    uchar     lport[2];
               };

          The only difference in the two is the type of address, IPv4
          or IPv6.  Before a write, a user must prefix a similar
          structure to each message.  The system overrides the user
          specified local port with the announced one.  If the user
          specifies an address that isn't a unicast address in
          /net/ipselftab, that too is overridden.  Since the prefixed
          structure is the same in read and write, it is relatively
          easy to write a server that responds to client requests by
          just copying new data into the message body and then writing
          back the same buffer that was written.

        RUDP
          RUDP is a reliable datagram protocol based on UDP.  Packets
          are delivered in order.  RUDP does not support listen.  One
          must use either connect or announce followed immediately by
          headers or headers4.

          Unlike IL or TCP, the reboot of one end of a connection does
          not force a closing of the connection.  Communications will
          resume when the rebooted machine resumes talking.  Any unac-
          knowledged packets queued before the reboot will be lost.  A
          reboot can be detected by reading the err file.  It will
          have the message

               hangup address!port

          where address and port are of the far side of the connec-
          tion.  Retransmitting a datagram more than 10 times is
          treated like a reboot: all queued messages are dropped, an
          error is queued to the err file, and the conversation
          resumes.

        IL
          IL is a reliable point-to-point datagram protocol.  Like
          TCP, IL delivers datagrams reliably and in order. Also like
          TCP, a connection is determined by the address and port num-
          bers of the two ends.  Like UDP, each read and write trans-
          fers a single datagram.

     Page 8                       Plan 9             (printed 12/2/22)

     IP(3)                                                       IP(3)

          IL is efficient for LANs but doesn't have the congestion
          control features needed for use through the Internet.

        GRE
          GRE is the encapsulation protocol used by PPTP.  The kernel
          implements just enough of the protocol to multiplex it.
          Announce is not allowed in GRE, only connect.  Since GRE has
          no port numbers, the port number in the connect is actually
          the 16 bit eproto field in the GRE header.

          Reads and writes transfer a GRE datagram starting at the GRE
          header.  On write, the kernel fills in the eproto field with
          the port number specified in the connect message.

        ESP
          ESP is the Encapsulating Security Payload (RFC 1827).  It is
          used to set up an encrypted tunnel between machines.  Like
          GRE, ESP has no port numbers.  Instead, the port number in
          the connect message is the SPI (Security Association Identi-
          fier (sic)).  IP packets are written to and read from data.
          The kernel encrypts any packets written to data, appends a
          MAC, and prefixes an ESP header before sending to the other
          end of the tunnel.  Received packets are checked against
          their MAC's, decrypted, and queued for reading from data.
          The control messages are:

          esp alg secret
               Encrypt with the algorithm, alg, using secret as the
               key.  Possible algorithms are: null, des_56_cbc, and
               rc4_128.

          ah alg secret
               Use the hash algorithm, alg, with secret as the key for
               generating the MAC.  Possible algorithms are: null,
               hmac_sha1_96, and hmac_md5_96.

          header
               Turn on header mode.  Every buffer read from data
               starts with 4 unsued bytes, and the first 4 bytes of
               every buffer written to data are ignored.

          noheader
               Turn off header mode.

        IP packet filter
          The directory /net/ipmux looks like another protocol direc-
          tory.  It is a packet filter built on top of IP.  Each num-
          bered subdirectory represents a different filter.  The con-
          nect messages written to the ctl file describe the filter.
          Packets matching the filter can be read on the data file.
          Packets written to the data file are routed to an interface
          and transmitted.

     Page 9                       Plan 9             (printed 12/2/22)

     IP(3)                                                       IP(3)

          A filter is a semicolon-separated list of relations.  Each
          relation describes a portion of a packet to match.  The pos-
          sible relations are:

          proto=n
               the IP protocol number must be n.

          dat[n:m]=expr
               bytes n through m following the IP packet must match
               expr.

          ifc=expr
               the packet must have been received on an interface
               whose address matches expr.

          src=expr
               The source address in the packet must match expr.

          dst=expr
               The destination address in the packet must match expr.

          Expr is of the form:

               value

               value|value|...

               value&mask

               value|value&mask

          If a mask is given, the relevant field is first ANDed with
          the mask.  The result is compared against the value or list
          of values for a match.  In the case of ifc, dst, and src the
          value is a dot-formatted IP address and the mask is a dot-
          formatted IP mask.  In the case of dat, both value and mask
          are strings of 2 character hexadecimal digits representing 8
          bit values.

          A packet is delivered to only one filter.  The filters are
          merged into a single comparison tree.  If two filters match
          the same packet, the following rules apply in order (here
          '>' means is preferred to):

          1)   protocol > data > source > destination > interface

          2)   lower data offsets > higher data offsets

          3)   longer matches > shorter matches

          4)   older > younger

     Page 10                      Plan 9             (printed 12/2/22)

     IP(3)                                                       IP(3)

          So far this has just been used to implement a version of
          OSPF in Inferno.

        Statistics
          The stats files are read only and contain statistics useful
          to network monitoring.

          Reading /net/ipifc/stats returns a list of 19 tagged and new
          line separated fields representing:
               forwarding status (0 and 2 mean forwarding off, 1 means on)
               default TTL
               input packets
               input header errors
               input address errors
               packets forwarded
               input packets for unknown protocols
               input packets discarded
               input packets delivered to higher level protocols
               output packets
               output packets discarded
               output packets with no route
               timed out fragments in reassembly queue
               requested reassemblies
               successful reassemblies
               failed reassemblies
               successful fragmentations
               unsuccessful fragmentations
               fragments created

          Reading /net/icmp/stats returns a list of 25 tagged and new
          line separated fields representing:
               messages received
               bad received messages
               unreachables received
               time exceededs received
               input parameter problems received
               source quenches received
               redirects received
               echo requests received
               echo replies received
               timestamps received
               timestamp replies received
               address mask requests received
               address mask replies received
               messages sent
               transmission errors
               unreachables sent
               time exceededs sent
               input parameter problems sent
               source quenches sent
               redirects sent
               echo requests sent

     Page 11                      Plan 9             (printed 12/2/22)

     IP(3)                                                       IP(3)

               echo replies sent
               timestamps sent
               timestamp replies sent
               address mask requests sent
               address mask replies sent

          Reading /net/tcp/stats returns a list of 11 tagged and new
          line separated fields representing:
               maximum number of connections
               total outgoing calls
               total incoming calls
               number of established connections to be reset
               number of currently esablished connections
               segments received
               segments sent
               segments retransmitted
               retransmit timeouts
               bad received segments
               transmission failures

          Reading /net/udp/stats returns a list of 4 tagged and new
          line separated fields representing:
               datagrams received
               datagrams received for bad ports
               malformed datagrams received
               datagrams sent

          Reading /net/il/stats returns a list of 7 tagged and new
          line separated fields representing:
               checksum errors
               header length errors
               out of order messages
               retransmitted messages
               duplicate messages
               duplicate bytes

          Reading /net/gre/stats returns a list of 1 tagged number
          representing:
               header length errors

     SEE ALSO
          listen(8), dial(2), ndb(6)

     SOURCE
          /sys/src/9/ip

     BUGS
          Ipmux has not been heavily used and should be considered
          experimental.  It may disappear in favor of a more tradi-
          tional packet filter in the future.

     Page 12                      Plan 9             (printed 12/2/22)