    Independent Submission                                        S. Deering
    Request for Comments: 8507                                       Retired
    Category: Historic                                        R. Hinden, Ed.
    ISSN: 2070-1721                                     Check Point Software
                                                               December 2018

                  Simple Internet Protocol (SIP) Specification

    Abstract

       This document is published for the historical record.  The Simple
       Internet Protocol was the basis for one of the candidates for the
       IETF's Next Generation (IPng) work that became IPv6.

       The publication date of the original Internet-Draft was November 10,
       1992.  It is presented here substantially unchanged and is neither a
       complete document nor intended to be implementable.

       The paragraph that follows is the Abstract from the original draft.

       This document specifies a new version of IP called SIP, the Simple
       Internet Protocol.  It also describes the changes needed to ICMP,
       IGMP, and transport protocols such as TCP and UDP, in order to work
       with SIP.  A companion document [SIP-ADDR] describes the addressing
       and routing aspects of SIP, including issues of auto-configuration,
       host and subnet mobility, and multicast.

    Status of This Memo

       This document is not an Internet Standards Track specification; it is
       published for the historical record.

       This document defines a Historic Document for the Internet community.
       This is a contribution to the RFC Series, independently of any other
       RFC stream.  The RFC Editor has chosen to publish this document at
       its discretion and makes no statement about its value for
       implementation or deployment.  Documents approved for publication by
       the RFC Editor are not candidates for any level of Internet Standard;
       see Section 2 of RFC 7841.

       Information about the current status of this document, any errata,
       and how to provide feedback on it may be obtained at
       https://www.rfc-editor.org/info/rfc8507.

    Deering & Hinden                Historic                        [Page 1]

    RFC 8507                     Simple IP (SIP)               December 2018

    Copyright Notice

       Copyright (c) 2018 IETF Trust and the persons identified as the
       document authors.  All rights reserved.

       This document is subject to BCP 78 and the IETF Trust's Legal
       Provisions Relating to IETF Documents
       (https://trustee.ietf.org/license-info) in effect on the date of
       publication of this document.  Please review these documents
       carefully, as they describe your rights and restrictions with respect
       to this document.

    Table of Contents

       1. Preface .........................................................3
       2. Introduction ....................................................3
       3. Terminology .....................................................4
       4. SIP Header Format ...............................................5
       5. Addresses .......................................................6
          5.1. Text Representation of Addresses ...........................6
          5.2. Unicast Addresses ..........................................6
          5.3. Multicast Addresses ........................................8
          5.4. Special Addresses ..........................................9
       6. Packet Size Issues .............................................12
       7. Source Routing Header ..........................................13
       8. Fragmentation Header ...........................................14
       9. Changes to Other Protocols .....................................16
          9.1. Changes to ICMP ...........................................16
          9.2. Changes to IGMP ...........................................20
          9.3. Changes to Transport Protocols ............................21
          9.4. Changes to Link-Layer Protocols ...........................22
       10. Security Considerations .......................................22
       11. Acknowledgments ...............................................23
       12. Informative References ........................................23
       Appendix A. SIP Design Rationale ..................................25
       Appendix B. Future Directions .....................................25
       Authors' Addresses ................................................26

    Deering & Hinden                Historic                        [Page 2]

    RFC 8507                     Simple IP (SIP)               December 2018

    1.  Preface

       This document is published for the historical record.

       Simple IP (SIP) was the basis for one of the candidates for the
       IETF's Next Generation (IPng) work; see "The Recommendation for the
       IP Next Generation Protocol" [RFC1752].  The original 1992
       Internet-Draft describing SIP is published here as part of the record
       of that work.

       SIP evolved into SIP Plus [RFC1710], which was assessed as a
       candidate for IPng [RFC1752] and led eventually to the development of
       IPv6, first published as [RFC1883].  The current specification for
       IPv6 is [RFC8200].

       The original Internet-Draft describing the Simple Internet Protocol
       was written by Steve Deering, and the Internet-Draft was posted on
       November 10, 1992.  The contents of this document are unchanged from
       that Internet-Draft, except for clarifications in the Abstract, the
       addition of this section, modifications to the authors' information,
       the updating of references, removal of the IANA considerations, and
       minor formatting changes.

       It should be noted that the original draft was not complete and that
       no attempt has been made to complete it.  This document is not
       intended to be implementable.

    2.  Introduction

       SIP is a new version of IP.  Its salient differences from IP
       version 4 [RFC791], subsequently referred to as "IPv4", are:

           o  expansion of addresses to 64 bits,

           o  simplification of the IP header by eliminating some
              inessential fields, and

           o  relaxation of length restrictions on optional data, such as
              source-routing information.

       SIP retains the IP model of globally-unique addresses,
       hierarchically-structured for efficient routing.  Increasing the
       address size from 32 to 64 bits allows more levels of hierarchy to be
       encoded in the addresses, enough to enable efficient routing in an
       internet with tens of thousands of addressable devices in every
       office, every residence, and every vehicle in the world.  Keeping the

    Deering & Hinden                Historic                        [Page 3]

    RFC 8507                     Simple IP (SIP)               December 2018

       addresses fixed-length and relatively compact facilitates
       high-performance router and host implementation, and keeps the
       bandwidth overhead of the SIP headers almost as low as IPv4.

       The elimination of inessential fields also contributes to
       high-performance implementation, and to the likelihood of correct
       implementation.  A change in the way that optional data, such as
       source-routing information, is encoded allows for more efficient
       forwarding and less stringent limits on the length of such data.

       Despite these changes, SIP remains very similar to IPv4.  This
       similarity makes it easy to understand SIP (for those who already
       understand IPv4), makes it possible to reuse much of the code and
       data structures from IPv4 in an implementation of SIP (including
       almost all of ICMP and IGMP), and makes it straightforward to
       translate between SIP packets and IPv4 packets for transition
       purposes [IPAE].

       The subsequent sections of this document specify SIP and its
       associated protocols without much explanation of why the design
       choices were made the way they were.  Appendix A presents the
       rationale for those aspects of SIP that differ from IPv4.

    3.  Terminology

        system      - a device that implements SIP.

        router      - a system that forwards SIP packets.

        host        - any system that is not a router.

        link        - a communication facility or medium over which systems
                      can communicate at the link layer, i.e., the layer
                      immediately below SIP.

        interface   - a system's attachment point to a link.

        address     - a SIP-layer identifier for an interface or a group of
                      interfaces.

        subnet      - in the SIP unicast addressing hierarchy, a
                      lowest-level (finest-grain) cluster of addresses,
                      sharing a common address prefix (i.e., high-order
                      address bits).  Typically, all interfaces attached to
                      the same link have addresses in the same subnet;
                      however, in some cases, a single link may support more
                      than one subnet, or a single subnet may span more than
                      one link.

    Deering & Hinden                Historic                        [Page 4]

    RFC 8507                     Simple IP (SIP)               December 2018

        link MTU    - the maximum transmission unit, i.e., maximum packet
                      size in octets, that can be conveyed in one piece over
                      a link (where a packet is a SIP header plus payload).

        path MTU    - the minimum link MTU of all the links in a path
                      between a source system and a destination system.

        packetization
        layer       - any protocol layer above SIP that is responsible for
                      packetizing data to fit within outgoing SIP packets.
                      Typically, transport-layer protocols, such as TCP, are
                      packetization protocols, but there may also be
                      higher-layer packetization protocols, such as
                      protocols implemented on top of UDP.

    4.  SIP Header Format

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Version|                        Reserved                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Payload Length        |  Payload Type |   Hop Limit   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                         Source Address                        +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                      Destination Address                      +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Version              4-bit IP version number = decimal 6.
                            <to be confirmed>

       Reserved             28-bit reserved field.  Initialized to zero
                            for transmission; ignored on reception.

       Payload Length       16-bit unsigned integer.  Length of payload,
                            i.e., the rest of the packet following the
                            SIP header, in octets.

       Payload Type         8-bit selector.  Identifies the type of
                            payload, e.g., TCP.

       Hop Limit            8-bit unsigned integer.  Decremented by 1
                            by each system that forwards the packet.
                            The packet is discarded if Hop Limit is
                            decremented to zero.

    Deering & Hinden                Historic                        [Page 5]

    RFC 8507                     Simple IP (SIP)               December 2018

       Source Address       64 bits.  See "Addresses" section, following.

       Destination Address  64 bits.  See "Addresses" section, following.

    5.  Addresses

    5.1.  Text Representation of Addresses

       SIP addresses are 64 bits (8 octets) long.  The text representation
       of a SIP addresses is 16 hexadecimal digits, with a colon between the
       4th and 5th digits, and optional colons between any subsequent pair
       of digits.  Leading zeros must not be dropped.  Examples:

              0123:4567:89AB:CDEF

              0123:456789ABCDEF

              0123:456789AB:CDE:F

       Programs that read the text representation of SIP addresses must be
       insensitive to the presence or absence of optional colons.  Programs
       that write the text representation of a SIP address should use the
       first format above (i.e., colons after the 4th, 8th, and 12th
       digits), in the absence of any knowledge of the structure or
       preferred format of the address, such as knowledge of the format in
       which it was originally read.

       The presence of at least one colon in the text representation allows
       SIP addresses to be easily distinguished from both domain names and
       the text representation of IPv4 addresses.

    5.2.  Unicast Addresses

       A SIP unicast address is a globally-unique identifier for a single
       interface, i.e., no two interfaces in a SIP internet may have the
       same unicast address.  A single interface may, however, have more
       than one unicast address.

       A system considers its own unicast address(es) to have the following
       structure, where different addresses may have different values for n:

        |                         n bits                     |  64-n bits |
        +----------------------------------------------------+------------+
        |                     subnet prefix                  |interface ID|
        +----------------------------------------------------+------------+

    Deering & Hinden                Historic                        [Page 6]

    RFC 8507                     Simple IP (SIP)               December 2018

       To know the length of the subnet prefix, the system is required to
       associate with each of its addresses a 'subnet mask' of the following
       form:

        |                         n bits                     |  64-n bits |
        +----------------------------------------------------+------------+
        |1111111111111111111111111111111111111111111111111111|000000000000|
        +----------------------------------------------------+------------+

       A system may have a subnet mask of all-ones, which means that the
       system belongs to a subnet containing exactly one system -- itself.

       A system acquires its subnet mask(s) at the same time, and by the
       same mechanism, as it acquires its address(es), for example, by
       manual configuration or by a dynamic configuration protocol such as
       BOOTP [RFC951].

       Hosts are ignorant of any further structure in a unicast address.

       Routers may acquire, through manual configuration or the operation of
       routing protocols, additional masks that identify higher-level
       clusters in a hierarchical addressing plan.  For example, the routers
       within a single site would typically have a 'site mask', such as the
       following:

        |                  m bits                 |       64-m bits       |
        +-----------------------------------------+-----------------------+
        |11111111111111111111111111111111111111111|00000000000000000000000|
        +-----------------------------------------+-----------------------+

       by which they could deduce the following structure in the site's
       addresses:

        |                  m bits                 |  p bits  | 64-m-p bits|
        +-----------------------------------------+----------+------------+
        |                site prefix              |subnet  ID|interface ID|
        +-----------------------------------------+----------+------------+

       All knowledge by SIP systems of the structure of unicast addresses is
       based on possession of such masks -- there is no "wired-in" knowledge
       of unicast address formats.

       The SIP Addressing and Routing document [SIP-ADDR] proposes two
       hierarchical addressing plans, one based on a hierarchy of SIP
       service providers, and one based on a geographic hierarchy.

    Deering & Hinden                Historic                        [Page 7]

    RFC 8507                     Simple IP (SIP)               December 2018

    5.3.  Multicast Addresses

       A SIP multicast address is an identifier for a group of interfaces.
       An interface may belong to any number of multicast groups.  Multicast
       addresses have the following format:

        |1|   7   |  4 |  4 |                  48 bits                    |
        +-+-------+----+----+---------------------------------------------+
        |C|1111111|flgs|scop|                  group ID                   |
        +-+-------+----+----+---------------------------------------------+

       where:

         C = IPv4 compatibility flag; see [IPAE].

         1111111 in the rest of the first octet identifies the address as
                 being a multicast address.

                                     +-+-+-+-+
         flgs is a set of 4 flags:   |0|0|0|T|
                                     +-+-+-+-+

           the high-order 3 flags are reserved, and must be initialized
           to 0.

           T = 0 indicates a permanently-assigned ("well-known") multicast
                 address, assigned by the global internet numbering
                 authority.

           T = 1 indicates a non-permanently-assigned ("transient")
                 multicast address.

         scop is a 4-bit multicast scope value:

           0 reserved
           1 intra-system scope
           2 intra-link scope
           3 (unassigned)
           4 (unassigned)
           5 intra-site scope
           6 (unassigned)
           7 (unassigned)
           8 intra-metro scope
           9 (unassigned)
           A (unassigned)
           B intra-country scope
           C (unassigned)

    Deering & Hinden                Historic                        [Page 8]

    RFC 8507                     Simple IP (SIP)               December 2018

           D (unassigned)
           E global scope
           F reserved

         group ID identifies the multicast group, either permanent or
         transient, within the given scope.

       The "meaning" of a permanently-assigned multicast address is
       independent of the scope value.  For example, if the "NTP servers
       group" is assigned a permanent multicast address with a group ID of
       43 (hex), then:

         7F01:000000000043 means all NTP servers on the same system as the
         sender.

         7F02:000000000043 means all NTP servers on the same link as the
         sender.

         7F05:000000000043 means all NTP servers at the same site as the
         sender.

         7F0E:000000000043 means all NTP servers in the internet.

       Non-permanently-assigned multicast addresses are meaningful only
       within a given scope.  For example, a group identified by the
       non-permanent, intra-site multicast address 7F15:000000000043 at one
       site bears no relationship to a group using the same address at a
       different site, nor to a non-permanent group using the same group ID
       with different scope, nor to a permanent group with the same
       group ID.

    5.4.  Special Addresses

       There are a number of "special purpose" SIP addresses:

         The Unspecified Address: 0000:0000:0000:0000

           This address shall never be assigned to any system.  It may be
           used wherever an address appears, to indicate the absence of an
           address.  One example of its use is in the Source Address field
           of a SIP packet sent by an initializing host, before it has
           learned its own address.

         The Loopback Address: 0000:0000:0000:0001

           This address may be used by a system to send a SIP packet to
           itself.

    Deering & Hinden                Historic                        [Page 9]

    RFC 8507                     Simple IP (SIP)               December 2018

         Anyone Addresses: <prefix><zero>

           Addresses of this form may be used to send to the "nearest"
           system (according the routing protocols' measure of distance)
           that "knows" it has a unicast address prefix of <prefix>.

           Since hosts know only their subnet prefix(es), and no
           higher-level prefixes, a host with the following address:

           +----------------------------------------------+----------------+
           |               subnet prefix = A              |interface ID = B|
           +----------------------------------------------+----------------+

           shall recognize only the following Anyone address as identifying
           itself:

           +----------------------------------------------+----------------+
           |               subnet prefix = A              |0000000000000000|
           +----------------------------------------------+----------------+

           An intra-site router that knows that one of its addresses has the
           format:

           +-------------------------------+--------------+----------------+
           |         site prefix = X       |subnet  ID = Y|interface ID = Z|
           +-------------------------------+--------------+----------------+

           shall accept packets sent to either of the following two Anyone
           addresses as if they had been sent to the router's own address:

           +-------------------------------+-------------------------------+
           |         site prefix = X       |0000000000000000000000000000000|
           +-------------------------------+-------------------------------+

           +-------------------------------+--------------+----------------+
           |         site prefix = X       |subnet  ID = Y|0000000000000000|
           +-------------------------------+--------------+----------------+

           Anyone Addresses work as follows:

             If any system belonging to subnet A sends a packet to
             subnet A's Anyone address, the packet shall be looped-back
             within the sending system itself, since it is the nearest
             system to itself with the subnet A prefix.  If a system outside
             of subnet A sends a packet to subnet A's Anyone address, the
             packet shall be accepted by the first router on subnet A that
             the packet reaches.

    Deering & Hinden                Historic                       [Page 10]

    RFC 8507                     Simple IP (SIP)               December 2018

             Similarly, a packet sent to site X's Anyone address from
             outside of site X shall be accepted by the first encountered
             router belonging to site X, i.e., one of site X's boundary
             routers.  If a higher-level prefix P identifies, say, a
             particular service provider, then a packet sent to <P> <zero>
             from outside of provider P's facilities shall be delivered to
             the nearest entry router into P's facilities.

           Anyone addresses are most commonly used in conjunction with the
           SIP source routing header, to cause a packet to be routed via one
           or more specified "transit domains", without the need to identify
           individual routers in those domains.

           The value zero is reserved at each level of every unicast address
           hierarchy, to serve as an Anyone address for that level.

         The Reserved Multicast Address:   7F0s:0000:0000:0000

           This multicast address (with any scope value, s) is reserved, and
           shall never be assigned to any multicast group.

         The All Systems Addresses:   7F01:0000:0000:0001
                                      7F02:0000:0000:0001

           These multicast addresses identify the group of all SIP systems,
           within scope 1 (intra-system) or 2 (intra-link).

         The All Hosts Addresses:   7F01:0000:0000:0002
                                    7F02:0000:0000:0002

           These multicast addresses identify the group of all SIP hosts,
           within scope 1 (intra-system) or 2 (intra-link).

         The All Routers Addresses:   7F01:0000:0000:0003
                                      7F02:0000:0000:0003

           These multicast addresses identify the group of all SIP routers,
           within scope 1 (intra-system) or 2 (intra-link).

       A host is required to recognize the following addresses as
       identifying itself: its own unicast addresses, the Anyone addresses
       with the same subnet prefixes as its unicast addresses, the Loopback
       address, the All Systems and All Hosts addresses, and any other
       multicast addresses to which the host belongs.

    Deering & Hinden                Historic                       [Page 11]

    RFC 8507                     Simple IP (SIP)               December 2018

       A router is required to recognize the following addresses as
       identifying itself: its own unicast addresses, the Anyone addresses
       with the same subnet or higher-level prefixes as its unicast
       addresses, the Loopback address, the All Systems and All Routers
       addresses, and any other multicast addresses to which the host
       belongs.

    6.  Packet Size Issues

       SIP requires that every link in the internet have an MTU of 576
       octets or greater.  On any link that cannot convey a 576-octet packet
       in one piece, link-specific fragmentation and reassembly must be
       provided at a layer below SIP.

           (Note: this minimum link MTU is NOT the same as the one in IPv4.
           In IPv4, the minimum link MTU is 68 octets [ [RFC791], page 25 ];
           576 octets is the minimum reassembly buffer size required in an
           IPv4 system, which has nothing to do with link MTUs.)

       From each link to which a system is directly attached, the system
       must be able to accept packets as large as that link's MTU.  Links
       that have a configurable MTU, such as PPP links [RFC1661], should be
       configured with an MTU of 600 octets or greater.

       SIP systems are expected to implement Path MTU Discovery [RFC1191],
       in order to discover and take advantage of paths with MTU greater
       than 576 octets.  However, a minimal SIP implementation (e.g., in a
       boot ROM) may simply restrict itself to sending packets no larger
       than 576 octets, and omit implementation of Path MTU Discovery.

       Path MTU Discovery requires support both in the SIP layer and in the
       packetization layers.  A system that supports Path MTU Discovery at
       the SIP layer may serve packetization layers that are unable to adapt
       to changes of the path MTU.  Such packetization layers must limit
       themselves to sending packets no longer than 576 octets, even when
       sending to destinations that belong to the same subnet.

           (Note: Unlike IPv4, it is unnecessary in SIP to set a "Don't
           Fragment" flag in the packet header in order to perform Path MTU
           Discovery; that is an implicit attribute of every SIP packet.
           Also, those parts of the RFC-1191 procedures that involve use of
           a table of MTU "plateaus" do not apply to SIP, because the SIP
           version of the "Datagram Too Big" message always identifies the
           exact MTU to be used.)

    Deering & Hinden                Historic                       [Page 12]

    RFC 8507                     Simple IP (SIP)               December 2018

    7.  Source Routing Header

       A Payload Type of <TBD> in the immediately preceding header indicates
       the presence of this Source Routing header:

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                            Reserved                           |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |   Num Addrs   |   Next Addr   |  Payload Type |    Reserved   |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                                                               |
          +                           Address[0]                          +
          |                                                               |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                                                               |
          +                           Address[1]                          +
          |                                                               |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          .                               .                               .
          .                               .                               .
          .                               .                               .
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                                                               |
          +                     Address[Num Addrs - 1]                    +
          |                                                               |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Reserved             Initialized to zero for transmission; ignored
                               on reception.

          Num Addrs            Number of addresses in the Source Routing
                               header.

          Next Addr            Index of next address to be processed;
                               initialized to 0 by the originating system.

          Payload Type         Identifies the type of payload following the
                               Source Routing header.

    Deering & Hinden                Historic                       [Page 13]

    RFC 8507                     Simple IP (SIP)               December 2018

       A Source Routing header is not examined or processed until it reaches
       the system identified in the Destination Address field of the SIP
       header.  In that system, dispatching on the Payload Type of the SIP
       (or subsequent) header causes the Source Routing module to be
       invoked, which performs the following algorithm:

           o  If Next Addr < Num Addrs, swap the SIP Destination Address and
              Address[Next Addr], increment Next Addr by one, and re-submit
              the packet to the SIP module for forwarding to the next
              destination.

           o  If Next Addr = Num Addrs, dispatch to the local protocol
              module identified by the Payload Type field in the Source
              Routing header.

           o  If Next Addr > Num Addrs, send an ICMP Parameter Problem
              message to the Source Address, pointing to the Num Addrs
              field.

    8.  Fragmentation Header

       A Payload Type of <TBD> in the immediately preceding header indicates
       the presence of this Fragmentation header:

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                         Identification                        |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |0 0 M|      Fragment Offset    |  Payload Type |    Reserved   |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Identification       A value that changes on each packet sent with
                               the same Source Address, Destination Address,
                               and preceding Payload Type.

          M flag               1 = more fragments; 0 = last fragment.

          Fragment Offset      The offset, in 8-octet chunks, of the
                               following payload, relative to the original,
                               unfragmented payload.

          Payload Type         Identifies the type of payload following the
                               Fragmentation header.

          Reserved             Initialized to zero for transmission; ignored
                               on reception.

    Deering & Hinden                Historic                       [Page 14]

    RFC 8507                     Simple IP (SIP)               December 2018

       The Fragmentation header is NOT intended to support general,
       SIP-layer fragmentation.  In particular, SIP routers shall not
       fragment a SIP packet that is too big for the MTU of its next hop,
       except in the special cases described below; in the normal case, such
       a packet results in an ICMP Packet Too Big message being sent back to
       its source, for use by the source system's Path MTU Discovery
       algorithm.

       The special cases for which the Fragmentation header is intended are
       the following:

           o  A SIP packet that is "tunneled", either by encapsulation
              within another SIP packet or by insertion of a Source Routing
              header en-route, may, after the addition of the extra header
              fields, exceed the MTU of the tunnel's path; if the original
              packet is 576 octets or less in length, the tunnel entry
              system cannot respond to the source with a Packet Too Big
              message, and therefore must insert a Fragmentation header and
              fragment the packet to fit within the tunnel's MTU.

           o  An IPv4 fragment that is translated into a SIP packet, or an
              unfragmented IPv4 packet that is translated into too long a
              SIP packet to fit in the remaining path MTU, must include the
              SIP Fragmentation header, so that it may be properly
              reassembled at the destination SIP system.

       Every SIP system must support SIP fragmentation and reassembly, since
       any system may be configured to serve as a tunnel entry or exit
       point, and any SIP system may be destination of IPv4 fragments.  All
       SIP systems must be capable of reassembling, from fragments, a SIP
       packet of up to 1024 octets in length, including the SIP header; a
       system may be capable of assembling packets longer than 1024 octets.

       Routers do not examine or process Fragmentation headers of packets
       that they forward; only at the destination system is the
       Fragmentation header acted upon (i.e., reassembly performed), as a
       result of dispatching on the Payload Type of the preceding header.

       Fragmentation and reassembly employ the same algorithm as IPv4, with
       the following exceptions:

           o  All headers up to and including the Fragmentation header are
              repeated in each fragment; no headers or data following the
              Fragmentation header are repeated in each fragment.

           o  the Identification field is increased to 32 bits, to decrease
              the risk of wraparound of that field within the maximum packet
              lifetime over very high-throughput paths.

    Deering & Hinden                Historic                       [Page 15]

    RFC 8507                     Simple IP (SIP)               December 2018

       The similarity of the algorithm and the field layout to that of IPv4
       enables existing IPv4 fragmentation and reassembly code and data
       structures to be re-used with little modification.

    9.  Changes to Other Protocols

       Upgrading IPv4 to SIP entails changes to the associated control
       protocols, ICMP and IGMP, as well as to the transport layer, above,
       and possibly to the link-layer, below.  This section identifies those
       changes.

    9.1.  Changes to ICMP

       SIP uses a subset of ICMP [[RFC792], [RFC950], [RFC1122], [RFC1191],
       [RFC1256]], with a few minor changes and some additions.  The
       presence of an ICMP header is indicated by a Payload Type of 1.

       One change to all ICMP messages is that, when used with SIP, the ICMP
       checksum includes a pseudo-header, like TCP and UDP, consisting of
       the SIP Source Address, Destination Address, Payload Length, and
       Payload Type (see section 8.3).

       There are a set of ICMP messages called "error messages", each of
       which, for IPv4, carries the IPv4 header plus 64 bits or more of data
       from the packet that invoked the error message.  When used with SIP,
       ICMP error messages carry the first 256 octets of the invoking SIP
       packet, or the entire invoking packet if it is shorter than
       256 octets.

       For most of the ICMP message types, the packets retain the same
       format and semantics as with IPv4; however, some of the fields are
       given new names to match SIP terminology.

       The changes to specific message types are as follows:

         Destination Unreachable

           The following Codes have different names when used with SIP:

             1 - destination address unreachable (IPv4 "host unreachable")
             7 - destination address unknown (IPv4 "dest. host unknown")
             2 - payload type unknown (IPv4 "protocol unreachable")
             4 - packet too big (IPv4 "fragmentation needed and DF set")

    Deering & Hinden                Historic                       [Page 16]

    RFC 8507                     Simple IP (SIP)               December 2018

           The following Codes retain the same names when used with SIP:

             3 - port unreachable
             5 - source route failed
             8 - source host isolated
            13 - communication administratively prohibited

           The following Codes are not used with SIP:

             0 - net unreachable
             6 - destination network unknown
             9 - comm. with dest. network administratively prohibited
            10 - comm. with dest. host administratively prohibited
            11 - network unreachable for type of service
            12 - host unreachable for type of service

           For "packet too big" messages (Code 4), the minimum legal value
           in the Next-Hop MTU field [RFC1191] is 576.

         Time Exceeded

           The name of Code 0 is changed to "hop limit exceeded in transit".

         Parameter Problem

           The Pointer field is extended to 16 bits and moved to the
           low-order end of the second 32-bit word, as follows:

           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |    Type     |      Code     |            Checksum         |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |          Reserved           |            Pointer          |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                                                           |
           |           first 256 octets of the invoking packet         |
           |                                                           |

    Deering & Hinden                Historic                       [Page 17]

    RFC 8507                     Simple IP (SIP)               December 2018

         Redirect

           Only Code 1 is used for SIP, meaning "redirect packets for the
           destination address".

           The Redirect header is modified for SIP, to accommodate the
           64-bit address of the "preferred router" and to retain 64-bit
           alignment, as follows:

           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |      Type     |      Code     |            Checksum         |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                            Reserved                         |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                                                             |
           +                        Preferred Router                     +
           |                                                             |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                                                             |
           |             first 256 octets of the invoking packet         |
           |                                                             |

    Deering & Hinden                Historic                       [Page 18]

    RFC 8507                     Simple IP (SIP)               December 2018

         Router Advertisement

           The format of the Router Advertisement message is changed to:

           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |     Type      |     Code      |           Checksum          |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |   Num Addrs   |Addr Entry Size|           Lifetime          |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                                                             |
           +                       Router Address[0]                     +
           |                                                             |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                      Preference Level[0]                    |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                          Reserved[0]                        |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                                                             |
           +                       Router Address[1]                     +
           |                                                             |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                      Preference Level[1]                    |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                          Reserved[1]                        |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                               .                             |
           |                               .                             |
           |                               .                             |

           The value in the Addr Entry Size field is 4, and all of the
           Reserved fields are initialized to zero by senders and ignored by
           receivers.

         Router Solicitation

           No changes.

         Echo and Echo Reply

           No changes.

    Deering & Hinden                Historic                       [Page 19]

    RFC 8507                     Simple IP (SIP)               December 2018

         The following ICMP message types are not used with SIP:

           Source Quench
           Timestamp
           Timestamp Reply
           Information Request
           Information Reply
           Address Mask Request
           Address Mask Reply

    9.2.  Changes to IGMP

       SIP uses the Internet Group Management Protocol, IGMP [RFC1112].  The
       presence of an IGMP header is indicated by a Payload Type of 2.

       When used with SIP, the IGMP checksum includes a pseudo-header, like
       TCP and UDP, consisting of the SIP Source Address, Destination
       Address, Payload Length, and Payload Type (see section 8.3).

       The format of an IGMP Host Membership Query message becomes:

           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |Version| Type  |    Reserved   |           Checksum            |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                            Reserved                           |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       The format of an IGMP Host Membership Report message becomes:

           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |Version| Type  |    Reserved   |           Checksum            |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                            Reserved                           |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                                                               |
           +                       Multicast Address                       +
           |                                                               |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       For both message types, the Version number remains 1, and the
       Reserved fields are set to zero by senders and ignored by receivers.

    Deering & Hinden                Historic                       [Page 20]

    RFC 8507                     Simple IP (SIP)               December 2018

    9.3.  Changes to Transport Protocols

       The service interface to SIP has some differences from IPv4's service
       interface.  Existing transport protocols that use IPv4 must be
       changed to operate over SIP's service interface.  The differences
       from IPv4 are:

           o  Any addresses passed across the interface are 64 bits long,
              rather than 32 bits.

           o  The following IPv4 variables are not passed across the
              interface: Precedence, Type-of-Service, Identifier,
              Don't Fragment Flag

           o  SIP options have a different format than IPv4 options.  (For
              SIP, "options" are all headers between, and not including, the
              SIP header and the transport header.  The only IPv4 option
              currently specified for SIP is Loose Source Routing.

           o  ICMP error messages for SIP that are passed up to the
              transport layer carry the first 256 octets of the invoking SIP
              packet.

       Transport protocols that use IPv4 addresses for their own purposes,
       such as identifying connection state or inclusion in a pseudo-header
       checksum, must be changed to use 64-bit SIP addresses for those
       purposes instead.

       For SIP, the pseudo-header checksums of TCP, UDP, ICMP, and IGMP
       include the SIP Source Address, Destination Address, Payload Length,
       and Payload Type, with the following caveats:

           o  If the packet contains a Source Routing header, the
              destination address used in the pseudo-header checksum is that
              of the final destination.

           o  The Payload Length used in the pseudo-header checksum is the
              length of the transport-layer packet, including the transport
              header.

           o  The Payload Type used in the pseudo-header checksum is the
              Payload Type from the header immediately preceding the
              transport header.

           o  When added to the pseudo-header checksum, the Payload Type is
              treated as the left octet of a 16-bit word, with zeros in the
              the right octet, when viewed in IP standard octet order.

    Deering & Hinden                Historic                       [Page 21]

    RFC 8507                     Simple IP (SIP)               December 2018

           o  If either of the two addresses used in the pseudo-header
              checksum has its high-order bit set to 1, only the low-order
              32-bits of that address shall be used in the sum.  The
              high-order bit is used to indicate that the addressed system
              is an IPv4 system, and that the low-order 32-bits of the
              address contain that system's IPv4 address [IPAE].

       The semantics of SIP service differ from IPv4 service in three ways
       that may affect some transport protocols:

         (1)  SIP does not enforce maximum packet lifetime.  Any transport
              protocol that relies on IPv4 to limit packet lifetime must
              take this change into account, for example, by providing its
              own mechanisms for detecting and discarding obsolete packets.

         (2)  SIP does not checksum its own header fields.  Any transport
              protocol that relies on IPv4 to assure the integrity of the
              source and destinations addresses, packet length, and
              transport protocol identifier must take this change into
              account.  In particular, when used with SIP, the UDP checksum
              is mandatory, and ICMP and IGMP are changed to use a
              pseudo-header checksum.

         (3)  SIP does not (except in special cases) fragment packets that
              exceed the MTU of their delivery paths.  Therefore, a
              transport protocol must not send packets longer than
              576 octets unless it implements Path MTU Discovery [RFC1191]
              and is capable of adapting its transmitted packet size in
              response to changes of the path MTU.

    9.4.  Changes to Link-Layer Protocols

       Link-layer media that have an MTU less than 576 must be enhanced
       with a link-specific fragmentation and reassembly mechanism, to
       support SIP.

       For links on which ARP is used by IPv4, the identical ARP protocol is
       used for SIP.  The low-order 32-bits of SIP addresses are used
       wherever IPv4 addresses would appear; since ARP is used only among
       systems on the same subnet, the high-order 32-bits of the SIP
       addresses may be inferred from the subnet prefix (assuming the subnet
       prefix is at least 32 bits long).  [This is subject to change -- see
       Appendix B.]

    10.  Security Considerations

       <to be done>

    Deering & Hinden                Historic                       [Page 22]

    RFC 8507                     Simple IP (SIP)               December 2018

    11.  Acknowledgments

       The author acknowledges the many helpful suggestions and the words of
       encouragement from Dave Clark, Dave Crocker, Deborah Estrin, Bob
       Hinden, Christian Huitema, Van Jacobson, Jeff Mogul, Dave Nichols,
       Erik Nordmark, Dave Oran, Craig Partridge, Scott Shenker, Paul
       Tsuchiya, Lixia Zhang, the members of End-to-End Research Group and
       the IPAE Working Group, and the participants in the big-internet and
       sip mailing lists.  He apologizes to those whose names he has not
       explicitly listed.  [If you want to be on the list in the next draft,
       just let him know!]

       Editor's note: Steve Deering was employed by the Xerox Palo Alto
       Research Center in Palo Alto, CA USA when this work was done.

    12.  Informative References

       [IPAE]     Crocker, D. and R. Hinden, "IP Address Encapsulation
                  (IPAE): A Mechanism for Introducing a New IP", Work in
                  Progress, draft-crocker-ip-encaps-01, November 1992.

       [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
                  DOI 10.17487/RFC0791, September 1981,
                  <https://www.rfc-editor.org/info/rfc791>.

       [RFC792]  Postel, J., "Internet Control Message Protocol", STD 5,
                  RFC 792, DOI 10.17487/RFC0792, September 1981,
                  <https://www.rfc-editor.org/info/rfc792>.

       [RFC950]  Mogul, J. and J. Postel, "Internet Standard Subnetting
                  Procedure", STD 5, RFC 950, DOI 10.17487/RFC0950,
                  August 1985, <https://www.rfc-editor.org/info/rfc950>.

       [RFC951]  Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951,
                  DOI 10.17487/RFC0951, September 1985,
                  <https://www.rfc-editor.org/info/rfc951>.

       [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
                  RFC 1112, DOI 10.17487/RFC1112, August 1989,
                  <https://www.rfc-editor.org/info/rfc1112>.

       [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
                  Communication Layers", STD 3, RFC 1122,
                  DOI 10.17487/RFC1122, October 1989,
                  <https://www.rfc-editor.org/info/rfc1122>.

    Deering & Hinden                Historic                       [Page 23]

    RFC 8507                     Simple IP (SIP)               December 2018

       [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
                  DOI 10.17487/RFC1191, November 1990,
                  <https://www.rfc-editor.org/info/rfc1191>.

       [RFC1256]  Deering, S., Ed., "ICMP Router Discovery Messages",
                  RFC 1256, DOI 10.17487/RFC1256, September 1991,
                  <https://www.rfc-editor.org/info/rfc1256>.

       [RFC1661]  Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
                  STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994,
                  <https://www.rfc-editor.org/info/rfc1661>.

       [RFC1710]  Hinden, R., "Simple Internet Protocol Plus White Paper",
                  RFC 1710, DOI 10.17487/RFC1710, October 1994,
                  <https://www.rfc-editor.org/info/rfc1710>.

       [RFC1752]  Bradner, S. and A. Mankin, "The Recommendation for the IP
                  Next Generation Protocol", RFC 1752, DOI 10.17487/RFC1752,
                  January 1995, <https://www.rfc-editor.org/info/rfc1752>.

       [RFC1883]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
                  (IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883,
                  December 1995, <https://www.rfc-editor.org/info/rfc1883>.

       [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
                  (IPv6) Specification", STD 86, RFC 8200,
                  DOI 10.17487/RFC8200, July 2017,
                  <https://www.rfc-editor.org/info/rfc8200>.

       [SIP-ADDR] Deering, S., "Simple Internet Protocol (SIP) Addressing
                  and Routing", Work in Progress, November 1992.

    Deering & Hinden                Historic                       [Page 24]

    RFC 8507                     Simple IP (SIP)               December 2018

    Appendix A.  SIP Design Rationale

       <this section still to be done>

       Fields present in IPv4, but absent in SIP:

         Header Length    Not needed; SIP header length is fixed.

         Precedence &
         Type of Service  Not used; transport-layer Port fields (or perhaps
                          a to-be-defined value in the Reserved field of the
                          SIP header) may be used for classifying packets at
                          a granularity finer than host-to-host, as required
                          for special handling.

         Header Checksum  Not used; transport pseudo-header checksum
                          protects destinations from accepting corrupted
                          packets.

       Need to justify:

         change of Total Length -> Payload Length, excluding header
         change of Protocol -> Payload Type
         change of Time to Live -> Hop Limit
         movement of fragmentation fields out of fixed header
         bigger minimum MTU, and reliance on PMTU Discovery

    Appendix B.  Future Directions

       SIP as specified above is a fully functional replacement for IPv4,
       with a number of improvements, particularly in the areas of
       scalability of routing and addressing, and performance.  Some
       additional improvements are still under consideration:

           o  ARP may be modified to carry full 64-bit addresses, and to use
              link-layer multicast addresses, rather than broadcast
              addresses.

           o  The 28-bit Reserved field in the SIP header may be defined as
              a "Flow ID", or partitioned into a Type of Service field and a
              Flow ID field, for classifying packets deserving of special
              handling, e.g., non-default quality of service or real-time
              service.  On the other hand, the transport-layer port fields
              may be adequate for performing any such classification.  (One
              possibility would be simply to remove the port fields from TCP
              & UDP and append them to the SIP header, as in XNS.)

    Deering & Hinden                Historic                       [Page 25]

    RFC 8507                     Simple IP (SIP)               December 2018

           o  A new ICMP "destination has moved" message may defined, for
              re-routing to mobile hosts or subnets, and to domains that
              have changed their address prefixes.

           o  An explicit Trace Route message or option may be defined; the
              current IPv4 traceroute scheme will work fine with SIP, but it
              does not work for multicast, for which it has become very
              apparent that management and debugging tools are needed.

           o  A new Host-to-Router protocol may be specified, encompassing
              the requirements of router discovery, black-hole detection,
              auto- configuration of subnet prefixes, "beaconing" for mobile
              hosts, and, possibly, address resolution.  The OSI End System
              To Intermediate System Protocol may serve as a good model for
              such a protocol.

           o  The requirement that SIP addresses be strictly bound to
              interfaces may be relaxed, so that, for example, a system
              might have fewer addresses than interfaces.  There is some
              experience with this approach in the current Internet, with
              the use of "unnumbered links" in routing protocols such as
              OSPF.

           o  Authentication and integrity-assurance mechanisms for all
              clients of SIP, including ICMP and IGMP, may be specified,
              possibly based on the Secure Data Network System (SNDS) SP-3
              or SP-4 protocol.

    Authors' Addresses

       Stephen E. Deering
       Retired
       Vancouver, British Columbia
       Canada

       Robert M. Hinden (editor)
       Check Point Software
       959 Skyway Road
       San Carlos, CA  94070
       USA

       Email: bob.hinden@gmail.com

    Deering & Hinden                Historic                       [Page 26]