RFC 8507
Simple Internet Protocol (SIP) Specification
RFC 8507: Simple Internet Protocol (SIP) Specification 🎀
Okay bestie, let's start with the header 💅 This one is an Independent Submission, so it came in through the independent stream and not the IETF one 🌸. The category is Historic, so it's basically a museum piece ✨. The status in the header is Retired 🦋.
S. Deering is listed as an author, and R. Hinden is the editor (Ed.) 💜. Hinden's affiliation is Check Point Software. The date is December 2018 📅. The ISSN is 2070-1721 🧚. The title block doesn't list anything this RFC obsoletes or updates 🙈.
Abstract ✨
This doc is published for the historical record 📜. The Simple Internet Protocol was one of the candidates for the IETF's Next Generation (IPng) work, which became IPv6 👑.
The original Internet-Draft was published on November 10, 1992 📅. It's presented here almost exactly as it was, and it's neither a complete document nor meant to be implementable 🙈.
Next up is the original draft's own abstract, in my words 💅.
The original draft specifies a new version of IP called SIP, the Simple Internet Protocol 🦋. It also covers the changes ICMP, IGMP, and transport protocols like TCP and UDP need so they can work with SIP 💖. The addressing and routing side lives in a companion document, [SIP-ADDR], which covers auto-configuration, host and subnet mobility, and multicast 🌈.
Status of This Memo 📝
This document isn't an Internet Standards Track specification. It's published for the historical record 🕰️.
It's a Historic Document for the Internet community. It's a contribution to the RFC Series, sitting independently of any other RFC stream 🌸. The RFC Editor picked to publish it at their discretion, and they say nothing about whether it's worth implementing or deploying 🙈. Documents the RFC Editor approves for publication aren't candidates for any level of Internet Standard (see Section 2 of RFC 7841) 💅.
For the current status, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc8507 🔗.
Copyright Notice ©️
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info), as they stood on the publication date. Please read them carefully, because they spell out your rights and restrictions for 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 ................................................261. Preface 🎀
Yep, this is for the historical record 📜.
Simple IP (SIP) was one of the IPng candidates. Check out "The Recommendation for the IP Next Generation Protocol" [RFC1752] 🧚. The 1992 Internet-Draft describing SIP is kept here as part of that work's record 📖.
SIP glowed up into SIP Plus [RFC1710] ✨. It got assessed as an IPng candidate [RFC1752] and eventually led to IPv6, first published as [RFC1883] 👑. The current IPv6 spec is [RFC8200] 💅.
Steve Deering wrote the original Internet-Draft, which was posted on November 10, 1992 💖. The content matches that draft except for a few things: clarifications in the Abstract, adding this Preface, updating the authors' info, refreshing the references, removing the IANA considerations, and some minor formatting tweaks 🌈.
Heads up: the original draft was never finished, and nobody's tried to finish it here 🙈. This document isn't meant to be implementable 🚫.
2. Introduction 🦋
SIP is a new version of IP 🦋. Its big differences from IP version 4 [RFC791] (aka "IPv4") are:
- expansion of addresses to 64 bits 💅
- simplification of the IP header by getting rid of some inessential fields 🧹
- relaxation of length restrictions on optional data, like source-routing information 🌸
SIP keeps the IP model of globally-unique addresses, which are hierarchically-structured for efficient routing 🗺️. Bumping the address size from 32 to 64 bits gives you more levels of hierarchy in the addresses. That's enough for efficient routing in an internet with tens of thousands of addressable devices in every office, every residence, and every vehicle in the world 🚗🏠🏢. Keeping addresses fixed-length and fairly compact makes high-performance router and host implementations easier, and it keeps the bandwidth overhead of SIP headers almost as low as IPv4's 💜.
Getting rid of inessential fields also helps with high-performance implementation, and it makes correct implementation more likely 🙌. Changing how optional data like source-routing information is encoded allows for more efficient forwarding and less strict limits on how long that data can be ✨.
Even with all this, SIP is still super similar to IPv4 👯. That makes SIP easy to understand if you already get IPv4. It also makes it possible to reuse a lot of the code and data structures from IPv4 in a SIP implementation (including almost all of ICMP and IGMP). And it makes translating between SIP packets and IPv4 packets straightforward for transition purposes [IPAE] 🔁.
The rest of this doc specifies SIP and its related protocols without spending much time on why the design choices were made. Appendix A has the rationale for the parts 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 talk at the link layer, meaning the layer right 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, the lowest-level (finest-grain) cluster of addresses, sharing a common address prefix (the high-order address bits). Usually, all interfaces attached to the same link have addresses in the same subnet. But sometimes a single link can support more than one subnet, or a single subnet can span more than one link 🧩link MTU: the maximum transmission unit, meaning the largest 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 smallest link MTU among all the links in a path between a source system and a destination system 🛣️packetization layer: any protocol layer above SIP that's responsible for packetizing data to fit inside outgoing SIP packets. Transport-layer protocols like TCP are typically packetization protocols, but there can also be higher-layer ones, like protocols built on top of UDP 🎁
4. SIP Header Format 🎀
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Payload Type | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the field breakdown 🍓
Version🔢: a 4-bit IP version number, equal to decimal 6.<to be confirmed>Reserved🫧: a 28-bit reserved field. It's set to zero when transmitting and ignored on reception.Payload Length📏: a 16-bit unsigned integer. It's the length of the payload, meaning the rest of the packet after the SIP header, in octets.Payload Type🎫: an 8-bit selector that identifies the type of payload, like TCP.Hop Limit🦘: an 8-bit unsigned integer. Each system that forwards the packet decrements it by 1. The packet gets discarded if Hop Limit is decremented to zero 💀.Source Address🏠: 64 bits. See the "Addresses" section below.Destination Address🎯: 64 bits. See the "Addresses" section below.
5. Addresses 🦋
(Addresses continues in part 2 🧚)
5.1. Text Representation of Addresses ✨
Okay so SIP addresses are 64 bits (8 octets) long, bestie 💖 The text version is 16 hexadecimal digits, with a colon between the 4th and 5th digits and optional colons between any other pair of digits. Leading zeros MUST NOT be dropped 🙅♀️ Here are some examples:
0123:4567:89AB:CDEF
0123:456789ABCDEF
0123:456789AB:CDE:FPrograms that read the text form MUST BE insensitive to whether those optional colons are there or not 🫶 Programs that write the text form SHOULD use the first format above (colons after the 4th, 8th, and 12th digits) if they don't know anything about the address's structure or preferred format, like the format it was originally read in. Iconic behaviour, honestly 💅
The presence of at least one colon in the text form makes SIP addresses super easy to tell apart from domain names and from the text form of IPv4 addresses 🦋
5.2. Unicast Addresses 🦋
A SIP unicast address is a globally-unique identifier for a single interface. So no two interfaces in a SIP internet MAY have the same unicast address 🙈 A single interface MAY, however, have more than one unicast address, which is giving main character energy ✨
A system thinks of its own unicast address(es) as having this structure, where different addresses can have different values for n:
| n bits | 64-n bits |
+----------------------------------------------------+------------+
| subnet prefix |interface ID|
+----------------------------------------------------+------------+To know how long the subnet prefix is, the system is REQUIRED to attach a 'subnet mask' of the following form to each of its addresses 🧚
| n bits | 64-n bits |
+----------------------------------------------------+------------+
|1111111111111111111111111111111111111111111111111111|000000000000|
+----------------------------------------------------+------------+A system MAY have a subnet mask of all-ones. That means the system belongs to a subnet containing exactly one system, which is itself 🌸
A system gets its subnet mask(s) at the same time, and by the same mechanism, as it gets its address(es). For example, that could be manual configuration or a dynamic configuration protocol such as BOOTP [RFC951] 🍓
Hosts are totally ignorant of any further structure in a unicast address 🙈 They just don't need to know.
Routers MAY acquire additional masks through manual configuration or the operation of routing protocols. These masks identify higher-level clusters in a hierarchical addressing plan. For example, the routers within a single site would typically have a 'site mask' like this:
| m bits | 64-m bits |
+-----------------------------------------+-----------------------+
|11111111111111111111111111111111111111111|00000000000000000000000|
+-----------------------------------------+-----------------------+With that, 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 of the knowledge SIP systems have about the structure of unicast addresses comes from having these masks. There is no "wired-in" knowledge of unicast address formats at all 👑
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 🌈
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 this format:
|1| 7 | 4 | 4 | 48 bits |
+-+-------+----+----+---------------------------------------------+
|C|1111111|flgs|scop| group ID |
+-+-------+----+----+---------------------------------------------+Here's what each part means:
- C = IPv4 compatibility flag; see [IPAE].
- 1111111 in the rest of the first octet identifies the address as being a multicast address.
The flgs field is a set of 4 flags:
+-+-+-+-+
|0|0|0|T|
+-+-+-+-+- The high-order 3 flags are reserved, and they 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.
The scop field 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)
D (unassigned)
E global scope
F reservedThe group ID identifies the multicast group, either permanent or transient, within the given scope.
The "meaning" of a permanently-assigned multicast address doesn't depend on the scope value 🧚 For example, if the "NTP servers group" gets 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 only mean something inside a given scope 🦋 For example, a group identified by the non-permanent, intra-site multicast address 7F15:000000000043 at one site has no relationship to a group using that same address at a different site. It also has no relationship to a non-permanent group using the same group ID with a different scope, or to a permanent group with the same group ID. Totally separate vibes 💀
5.4. Special Addresses 👑
There are a bunch 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 is 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 🪞
- Anyone Addresses:
<prefix><zero>
Addresses of this form MAY be used to send to the "nearest" system (according to the routing protocols' measure of distance) that "knows" it has a unicast address prefix of <prefix> ✨
Since hosts only know 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 one of its addresses has this 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 like this 🔥
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.
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, which means 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 together with the SIP source routing header. They cause a packet to be routed via one or more specified "transit domains" without needing to identify individual routers in those domains 🦋
The value zero is reserved at each level of every unicast address hierarchy, so it can 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. It SHALL NEVER be assigned to any multicast group 🙅♀️
- The All Systems Addresses:
7F01:0000:0000:0001and7F02: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:0002and7F02: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:0003and7F02: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 it belongs to 🫶
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 ✨
okay bestie, let's talk MTUs 🎀 SIP requires that every link in the internet has an MTU of 576 octets or greater. Any link that can't carry a 576-octet packet in one piece needs link-specific fragmentation and reassembly 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 a system is directly attached to, the system must be able to accept packets as large as that link's MTU. Links with a configurable MTU, like PPP links [RFC1661], should be configured with an MTU of 600 octets or greater 💜
SIP systems are expected to implement Path MTU Discovery [RFC1191] so they can find and use paths with an MTU bigger than 576 octets ✨ However, a minimal SIP implementation (for example, one living in a boot ROM) may simply stick to sending packets no larger than 576 octets and skip Path MTU Discovery entirely. No judgment, it's giving survival mode 💀
Path MTU Discovery needs support both in the SIP layer and in the packetization layers. A system that supports Path MTU Discovery at the SIP layer may still serve packetization layers that can't adapt to path MTU changes. Those packetization layers must limit themselves to sending packets no longer than 576 octets, even when they're sending to destinations on 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. 🦋
7. Source Routing Header
okay this header is so iconic 👑 A Payload Type of <TBD> in the immediately preceding header tells you the Source Routing header is there:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.The Source Routing header isn't looked at or processed until it reaches the system named in the Destination Address field of the SIP header. There, dispatching on the Payload Type of the SIP (or a later) header invokes the Source Routing module, which runs this algorithm 🔥
- If
Next Addr<Num Addrs, swap the SIP Destination Address andAddress[Next Addr], incrementNext Addrby one, and re-submit the packet to the SIP module for forwarding to the next destination. - If
Next Addr=Num Addrs, dispatch to the local protocol module identified by the Payload Type field in the Source Routing header. - If
Next Addr>Num Addrs, send an ICMP Parameter Problem message to the Source Address, pointing to theNum Addrsfield.
8. Fragmentation Header
the Fragmentation header is giving main character energy 🦋 A Payload Type of <TBD> in the immediately preceding header tells you it's present:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.Real talk: the Fragmentation header is not meant to support general, SIP-layer fragmentation 🙅♀️ SIP routers shall not fragment a SIP packet that's too big for the MTU of its next hop, except in the special cases below. Normally, a packet like that gets an ICMP Packet Too Big message sent back to its source, so the source's Path MTU Discovery algorithm can use it 🌈
The special cases where the Fragmentation header is meant to show up are:
- A SIP packet that is "tunneled", either by encapsulation within another SIP packet or by inserting a Source Routing header en-route, may exceed the MTU of the tunnel's path after the extra header fields are added. If the original packet is 576 octets or less in length, the tunnel entry system can't respond to the source with a Packet Too Big message, so it must insert a Fragmentation header and fragment the packet to fit within the tunnel's MTU.
- An IPv4 fragment that gets translated into a SIP packet, or an unfragmented IPv4 packet that gets translated into a SIP packet too long to fit in the remaining path MTU, must include the SIP Fragmentation header so it can be properly reassembled at the destination SIP system ✨
Every SIP system must support SIP fragmentation and reassembly 🫶 Any system may be configured to act as a tunnel entry or exit point, and any SIP system may be the destination of IPv4 fragments. All SIP systems must be able to reassemble, 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 don't examine or process the Fragmentation headers of packets they forward. Only the destination system acts on the Fragmentation header (meaning it does the reassembly), because that happens when it dispatches on the Payload Type of the preceding header 💅
Fragmentation and reassembly use the same algorithm as IPv4, with these exceptions:
- 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.
- 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.
The algorithm and field layout are so similar to IPv4's that existing IPv4 fragmentation and reassembly code and data structures can be reused with little modification. Literally so smart 🧠✨
9. Changes to Other Protocols
okay so upgrading IPv4 to SIP means changing the associated control protocols, ICMP and IGMP 🎀 It also touches the transport layer above and possibly the link layer below. This section is where those changes get identified 🍓
9.1. Changes to ICMP ✨
okay so SIP borrows a subset of ICMP [[RFC792], [RFC950], [RFC1122], [RFC1191], [RFC1256]] 💅 and tweaks it a little, with a few additions too. You can spot an ICMP header by its Payload Type, which is 1 🎀
One change applies to every ICMP message. When it's used with SIP, the ICMP checksum covers a pseudo-header, same as TCP and UDP do. That pseudo-header is made of the SIP Source Address, the Destination Address, the Payload Length, and the Payload Type (see section 8.3) 🧚
Error messages are a special group. For IPv4, each one carries the IPv4 header plus 64 bits or more of data from the packet that set it off. With SIP, it's bigger and better: the error carries the first 256 octets of the invoking SIP packet, or the whole packet if it's under 256 octets 🦋
Most ICMP message types keep the same format and meaning as they had in IPv4. The main difference is that some fields got new names so they match SIP terminology ✨
Here's the breakdown for each message type:
Destination Unreachable
Some Codes get brand-new names in 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")Other Codes keep their names 🌸
3 - port unreachable
5 - source route failed
8 - source host isolated
13 - communication administratively prohibitedAnd these Codes are not used with SIP at all 🙈
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 serviceFor "packet too big" messages (Code 4), the minimum legal value in the Next-Hop MTU field [RFC1191] is 576. Don't go lower than that, bestie 🍓
Time Exceeded
Code 0 gets a glow-up and is now called "hop limit exceeded in transit" ✨
Parameter Problem
The Pointer field grows to 16 bits and moves to the low-order end of the second 32-bit word. It looks like this 🧚
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| first 256 octets of the invoking packet |
| |Redirect
Only Code 1 is used with SIP, and it means "redirect packets for the destination address" 🦋
The Redirect header got a makeover too. It now fits the 64-bit address of the "preferred router" and still keeps 64-bit alignment ✨
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Preferred Router +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| first 256 octets of the invoking packet |
| |Router Advertisement
The Router Advertisement message has a new format 💖
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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. Every Reserved field gets set to zero by senders and gets ignored by receivers 🫶
Router Solicitation
No changes. Easy 💅
Echo and Echo Reply
No changes either 🌈
These 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]. An IGMP header shows up with a Payload Type of 2 🦋
Just like ICMP, the IGMP checksum covers a pseudo-header, same as TCP and UDP. It's made of the SIP Source Address, Destination Address, Payload Length, and Payload Type (see section 8.3) 💜
The IGMP Host Membership Query message now looks like this 🎀
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The IGMP Host Membership Report message is also updated 🌸
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+For both message types, the Version number stays at 1. Reserved fields are set to zero by senders and ignored by receivers 🍓
9.3. Changes to Transport Protocols ✨
Heads up, bestie: SIP's service interface is not the same as IPv4's 👀 Existing transport protocols that use IPv4 must be changed to operate over SIP's service interface. Here are the differences 💅
- Any addresses passed across the interface are 64 bits long, rather than 32 bits.
- The following IPv4 variables are not passed across the interface: Precedence, Type-of-Service, Identifier, Don't Fragment Flag.
- 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.)
- 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, like identifying connection state or going into a pseudo-header checksum, must be changed to use 64-bit SIP addresses for those jobs 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. There are some caveats, though 🧚
- If the packet contains a Source Routing header, the destination address used in the pseudo-header checksum is that of the final destination.
- The Payload Length used in the pseudo-header checksum is the length of the transport-layer packet, including the transport header.
- The Payload Type used in the pseudo-header checksum is the Payload Type from the header immediately preceding the transport header.
- 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 right octet, when viewed in IP standard octet order.
- 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 👑
- 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.
- 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.
- 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 ✨
Okay bestie, so any link-layer medium with an MTU under 576 must get its own link-specific fragmentation and reassembly mechanism so SIP can actually run over it 🫶
On links where IPv4 uses ARP, SIP just reuses the exact same ARP protocol 🔁 The low-order 32 bits of a SIP address get used anywhere an IPv4 address would show up. ARP only talks between systems on the same subnet, so the high-order 32 bits can be inferred from the subnet prefix, as long as that prefix is at least 32 bits long. [This is subject to change -- see Appendix B.] 🌸
10. Security Considerations 🔒
<to be done> 😭 Security is literally the next big thing on the list, and it's coming soon.
11. Acknowledgments 📣
The author gives a huge shoutout 💖 to all the people who offered helpful suggestions and tons of encouragement: 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 anyone whose name didn't make the list. [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>.
[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.Appendix A. SIP Design Rationale 🧠
<this section still to be done> 🫠 The rationale is still cooking, so stay tuned!
Here's the IPv4 stuff that SIP dropped 💅:
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.And these changes still need a proper justification 🤔:
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 DiscoveryAppendix B. Future Directions 🔮
SIP as specified above is a fully functional replacement for IPv4, with a bunch of upgrades, especially for routing and addressing scalability, and performance. ✨ A few more improvements are still under consideration:
- ARP may be modified to carry full 64-bit addresses, and to use link-layer multicast addresses, rather than broadcast addresses. 📡
- The 28-bit Reserved field in the SIP header may be defined as a "Flow ID", or split into a Type of Service field and a Flow ID field, for classifying packets that deserve 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 doing any of that classification. (One possibility would be simply to remove the port fields from TCP & UDP and append them to the SIP header, as in XNS.)
- 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. 🚚
- 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, and it has become super obvious that management and debugging tools are needed for that. 🔍
- A new Host-to-Router protocol may be specified, covering 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. 🗺️
- 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's some experience with this in the current Internet, through the use of "unnumbered links" in routing protocols such as OSPF. 🧩
- 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📦 where this page comes from
- ietf: rfc8507 2018-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms