diff options
Diffstat (limited to 'doc/rfc/rfc8507.txt')
| -rw-r--r-- | doc/rfc/rfc8507.txt | 1459 |
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc8507.txt b/doc/rfc/rfc8507.txt new file mode 100644 index 0000000..ba02d26 --- /dev/null +++ b/doc/rfc/rfc8507.txt @@ -0,0 +1,1459 @@ + + + + + + +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] + |