RFC 1710
Simple Internet Protocol Plus White Paper
Simple Internet Protocol Plus White Paper 🦋
okay bestie, this is RFC 1710 and the header is giving everything 💅 It's by R. Hinden at Sun Microsystems, dated October 1994, and it comes from the Network Working Group. The category is Informational, so it's an info doc, not a standard. The header doesn't list any RFCs it obsoletes or updates, so there's nothing to replace or patch here 🎀
Status of this Memo 📜
This memo provides information for the Internet community. ✨ It does not specify an Internet standard of any kind, so please don't treat it like one 🙈 Distribution of this memo is unlimited 🌈
Abstract 💜
This doc was submitted to the IETF IPng area in response to RFC 1550 🫶 Publishing it does not mean the IPng area accepted any of the ideas inside, so the vibes are "here's our take, not a verdict." Comments should be submitted to the author and/or the sipp@sunroof.eng.sun.com mailing list 💌
1. Introduction ✨
This white paper gives you an overview of the Simple Internet Protocol plus (SIPP) 🦋 It's one of the candidates the Internet Engineering Task Force (IETF) is looking at for the next version of the Internet Protocol. The current version is usually called IPv4. 🌸
It's not a deep dive into every feature and all the motivation behind SIPP. It's just meant to give you the overview of the proposal. It's also not meant to be an implementation spec 🙈 But the central core of SIPP is so simple that someone who already knows IPv4 could probably build a basic working SIPP implementation just from reading this overview. Iconic, honestly 🧚
SIPP is a new version of IP, designed as an evolutionary step from IPv4. It's a natural increment on top of it 💅 It can be installed as a normal software upgrade in internet devices, and it's interoperable with the current IPv4. The deployment strategy was designed to not have any "flag" days 🚩 SIPP is also designed to run well on high performance networks (e.g., ATM) and still be efficient on low bandwidth networks (e.g., wireless). On top of all that, it provides a platform for new internet functionality that will be required in the near future 🔥
This white paper describes the work of the IETF SIPP working group. Several individuals deserve specific recognition 👑 They are Steve Deering, Paul Francis, Dave Crocker, Bob Gilligan, Bill Simpson, Ran Atkinson, Bill Fink, Erik Nordmark, Christian Huitema, Sue Thompson, and Ramesh Govindan. Absolutely legends 💖
2. Key Issues for the Next Generation of IP 🔥
There are several key issues that should be used when evaluating any next generation internet protocol 📝 Some are very straightforward. For example, the new protocol must be able to support large global internetworks. Others are less obvious, and this is where it gets spicy 🌶️ There must be a clear way to transition the current installed base of IP systems. It doesn't matter how good a new protocol is if there isn't a practical way to move the current operational systems running IPv4 over to it 😭
2.1 Growth 💖
Growth is the whole reason we need a next generation IP 📈 If we've learned anything from our experience with IPv4, it's that addressing and routing must be able to handle reasonable scenarios of future growth. It's important that we understand the past growth and where the future growth is going to come from 🧚
Right now IPv4 serves what could be called the computer market 💻 The computer market has been the driver of Internet growth. It includes the current Internet and countless other smaller internets that aren't connected to the Internet. Its focus is connecting computers together in the big business, government, and university education markets. This market has been growing at an exponential rate, and one way to see it is that the number of networks in the current Internet (23,494 as of 1/28/94) is doubling about every 12 months 🤯 The computers at the endpoints range from PC's all the way up to Supercomputers. Most are attached to Local Area Networks (LANs), and the vast majority are not mobile 🌸
The next phase of growth probably won't be driven by the computer market. The computer market will keep growing at significant rates as it expands into other areas, like schools (elementary through high school) and small businesses 🎒 But it's doubtful it will keep growing at an exponential rate. What's likely is that other kinds of markets will develop. These markets fall into several areas, and they all share one trait: they're extremely large 😳 They also bring a new set of requirements that weren't as obvious in the early days of IPv4 deployment. These new markets will also happen in parallel with other ones. Maybe we'll look back on the last ten years of Internet growth as the time when the Internet was small and only doubling every year 🦋 The challenge for an IPng is to solve today's problems while also being attractive in these emerging markets.
Nomadic personal computing devices seem certain to become ubiquitous as their prices drop and their capabilities go up 📱 The key capability is that they'll be networked. Unlike most of today's networked computers, they'll support a variety of network attachments. When they're disconnected, they'll use RF wireless networks. In networked facilities, they'll use infrared attachment. When docked, they'll use physical wires 🔌 That makes them an ideal candidate for internetworking technology, since they need a common protocol that can work over a variety of physical networks. These devices will become consumer devices and will replace the current generation of cellular phones, pagers, and personal digital assistants 💅 Beyond the obvious need for an internet protocol that supports large scale routing and addressing, they'll also need one that imposes low overhead and supports auto configuration and mobility as a basic element. Nomadic computing also requires an internet protocol with built-in authentication and confidentiality 🔐 And of course these devices will need to talk to the current generation of computers. The need for low overhead comes from the wireless media. LANs will be very high speed, but the wireless media will be several orders of magnitude slower because of constraints on available frequencies, spectrum allocation, and power consumption 🪫
Another market is networked entertainment 📺 The first signs of it are the proposals being discussed for 500 channels of television, video on demand, and so on. This is clearly a consumer market, and it's possible that every television set will become an Internet host. As digital high definition television approaches, the differences between a computer and a television will shrink 🍿 Like the previous market, this one will need an Internet protocol that supports large scale routing and addressing, plus auto configuration. It also needs a protocol suite that imposes the minimum overhead to get the job done. Cost will be the major factor in choosing a technology 💸
Another market that could use the next generation IP is device control 💡 This covers everyday devices like lighting equipment, heating and cooling equipment, motors, and other equipment that's currently controlled by analog switches and that, in total, consumes a lot of power. The size of this market is enormous, and it needs solutions that are simple, robust, easy to use, and very low cost 🌈
The challenge for the IETF in picking an IPng is to choose a protocol that meets today's requirements and also matches the requirements of these emerging markets 🎯 These markets will happen with or without an IETF IPng. If the IETF IPng is a good match for them, it's likely to be used. If not, these markets will develop something else, and they won't wait around for an IETF solution 😤 If that happens, the IETF protocol would probably get supplanted, because of how huge and fast these new markets are. If the IETF IPng isn't appropriate for these markets, it's also probable that each one will develop its own protocols, perhaps proprietary. Those new protocols wouldn't interoperate with each other 💔 The opportunity for the IETF is to pick an IPng that has a reasonable chance of being used in these emerging markets. That would have the very desirable outcome of creating an immense, interoperable, world-wide information infrastructure built on open protocols 🌍✨ The alternative is a world of disjoint networks with protocols controlled by individual vendors, and nobody wants that era, periodt 💅
2.2. Transition ✨
okay so at some point in the next three to seven years the Internet is going to need a new version of the Internet protocol deployed, and it's giving "we needed this yesterday" 😭 Two things are pushing it: routing and addressing 🦋 Global internet routing based on the 32-bit addresses of IPv4 is getting seriously strained, ngl. IPv4 addresses just don't give you enough flexibility to build efficient hierarchies that can be aggregated. Classless Inter-Domain Routing [CIDR] is extending the lifetime of IPv4 routing by a number of years, but the effort to manage the routing keeps going up. And even if IPv4 routing could be scaled to support a full IPv4 Internet, the Internet would eventually run out of network numbers 💀 There's no question that an IPng is needed, just a question of when.
The challenge for an IPng is making sure its transition is complete before IPv4 routing and addressing break 😤 The transition will be way easier if IPv4 addresses are still globally unique. The two transition requirements that matter most are flexibility of deployment and the ability for IPv4 hosts to communicate with IPng hosts 🫶 There will be IPng-only hosts, just like there will be IPv4-only hosts. The capability must exist for IPng-only hosts to communicate with IPv4-only hosts globally while IPv4 addresses are globally unique.
The deployment strategy for an IPng must be as flexible as possible. The Internet is too large for any kind of controlled rollout to succeed 🌍 The importance of flexibility, and the need for interoperability between IPv4 and IPng, was said perfectly by Bill Fink, who is responsible for a portion of NASA's operational internet 👑 In a message to the sipp mailing list, he said:
"Being a network manager and thereby representing the interests of a significant number of users, from my perspective it's safe to say that the transition and interoperation aspects of any IPng is the key first element, without which any other significant advantages won't be able to be integrated into the user's network environment. I also don't think it wise to think of the transition as just a painful phase we'll have to endure en route to a pure IPng environment, since the transition/coexistence period undoubtedly will last at least a decade and may very well continue for the entire lifetime of IPng, until it's replaced with IPngng and a new transition. I might wish it was otherwise but I fear they are facts of life given the immense installed base.
"Given this situation, and the reality that it won't be feasible to coordinate all the infrastructure changes even at the national and regional levels, it is imperative that the transition capabilities support the ability to deploy the IPng in the piecemeal fashion... with no requirement to need to coordinate local changes with other changes elsewhere in the Internet...
"I realize that support for the transition and coexistence capabilities may be a major part of the IPng effort and may cause some headaches for the designers and developers, but I think it is a duty that can't be shirked and the necessary price that must be paid to provide as seamless an environment as possible to the end user and his basic network services such as e-mail, ftp, gopher, X-Window clients, etc...
"The bottom line for me is that we must have interoperability during the extended transition period for the base IPv4 functionality..."
Another way to think about the requirement for compatibility with IPv4 is to look at other product areas. In the product world, backwards compatibility is very important. Vendors who don't provide it for their customers usually find they don't have many customers left 🙈 For example, chip makers put considerable effort into making sure that new versions of their processors always run all of the software that ran on the previous model. It's unlikely that Intel would develop a new processor in the X86 family that didn't run DOS and the tens of thousands of applications which run on the current versions of X86's 💅
Operating system vendors go to great lengths to make sure new versions of their operating systems are binary compatible with their old versions. For example, the labels on most PC or MAC software usually indicate that they require OS version XX or greater. It would be foolish for Microsoft to come out with a new version of Windows that didn't run the applications which ran on the previous version. Microsoft even provides the ability for Windows applications to run on their new OS NT. This is an important feature 🧚 They understand that it was very important to make sure the applications which run on Windows also run on NT.
The same requirement is also true for IPng. The Internet has a large installed base. Features need to be designed into an IPng to make the transition as easy as possible. As with processors and operating systems, it must be backwards compatible with IPv4. Other protocols have tried to replace TCP/IP, for example XTP and OSI, and one element in their failure to reach widespread acceptance was that neither had any transition strategy other than running in parallel (sometimes called dual stack). New features alone aren't enough to motivate users to deploy new protocols 😭 IPng must have a great transition strategy and new features.
3. History of the SIPP Effort 🦋
The SIPP working group represents the evolution of three different IETF working groups focused on developing an IPng. The first was called IP Address Encapsulation (IPAE) and was chaired by Dave Crocker and Robert Hinden. It proposed extensions to IPv4 which would carry larger addresses. Much of its work focused on developing transition mechanisms 🌸
Somewhat later, Steve Deering proposed a new protocol evolved from IPv4 called the Simple Internet Protocol (SIP). A working group was formed to work on this proposal, chaired by Steve Deering and Christian Huitema. SIP had 64-bit addresses, a simplified header, and options in separate extension headers. After lengthy interaction between the two working groups, and the realization that IPAE and SIP had a number of common elements and that the transition mechanisms developed for IPAE would apply to SIP, the groups decided to merge and concentrate their efforts. The chairs of the new SIP working group were Steve Deering and Robert Hinden 💜
In parallel to SIP, Paul Francis (formerly Paul Tsuchiya) had founded a working group to develop the "P" Internet Protocol (Pip). Pip was a new internet protocol based on a new architecture. The motivation behind Pip was that the opportunity for introducing a new internet protocol doesn't come very often, so given that opportunity, important new features should be introduced. Pip supported variable length addressing in 16-bit units, separation of addresses from identifiers, support for provider selection, mobility, and efficient forwarding. It included a transition scheme similar to IPAE's ✨
After considerable discussion among the leaders of the Pip and SIP working groups, they realized that the advanced features in Pip could be accomplished in SIP without changing the base SIP protocol, while also keeping the IPAE transition mechanisms. In essence, it was possible to keep the best features of each protocol 🎀 Based on this, the groups decided to merge their efforts. The new protocol was called Simple Internet Protocol Plus (SIPP). The chairs of the merged working group are Steve Deering, Paul Francis, and Robert Hinden 👑
4. SIPP Overview 💖
SIPP is a new version of the Internet Protocol, designed as a successor to IP version 4 [IPV4]. SIPP is assigned IP version number 6 🌈
SIPP was designed to take an evolutionary step from IPv4. It was not a design goal to take a radical step away from IPv4. Functions which work in IPv4 were kept in SIPP, and functions which didn't work were removed. The changes from IPv4 to SIPP fall primarily into the following categories:
- Expanded Routing and Addressing Capabilities 🌸
SIPP increases the IP address size from 32 bits to 64 bits, to support more levels of addressing hierarchy and a much greater number of addressable nodes. SIPP addressing can be further extended, in units of 64 bits, by a facility equivalent to IPv4's Loose Source and Record Route option, in combination with a new address type called "cluster addresses" which identify topological regions rather than individual nodes. The scalability of multicast routing is improved by adding a "scope" field to multicast addresses.
- Header Format Simplification 💅
Some IPv4 header fields have been dropped or made optional, to reduce the common-case processing cost of packet handling and to keep the bandwidth cost of the SIPP header almost as low as that of IPv4, despite the increased size of the addresses. The basic SIPP header is only four bytes longer than IPv4.
- Improved Support for Options ⭐
Changes in the way IP header options are encoded allow for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future.
- Quality-of-Service Capabilities 🔥
A new capability is added to enable the labeling of packets belonging to particular traffic "flows" for which the sender requests special handling, such as non-default quality of service or "real-time" service.
- Authentication and Privacy Capabilities 🫶
SIPP includes the definition of extensions which provide support for authentication, data integrity, and confidentiality. This is included as a basic element of SIPP.
The SIPP protocol consists of two parts, the basic SIPP header and SIPP Options 🦋
4.1 SIPP Header Format ✨
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Payload Type | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+okay bestie, the SIPP header is the very first thing you see on every packet, and it's giving minimalist 💅 Here's the rundown of each field:
Versionis a 4-bit Internet Protocol version number, and it's= 6💖Flow Labelis a 28-bit field. Check out the SIPP Quality of Service section for the deets 🎀Payload Lengthis a 16-bit unsigned integer that tells you the length of the payload, i.e., the rest of the packet following the SIPP header, in octets ✨Payload Typeis an 8-bit selector that identifies the type of header immediately following the SIPP header. It uses the same values as the IPv4 Protocol field [STD 2, RFC 1700] 🧚Hop Limitis an 8-bit unsigned integer that gets decremented by 1 by each node that forwards the packet. The packet is discarded if Hop Limit is decremented to zero 💀Source Addressis 64 bits and is an address of the initial sender of the packet. See [ROUT] for details 🫶Destination Addressis 64 bits and is an address of the intended recipient of the packet. That might not be the ultimate recipient if an optional Routing Header is present 👑
4.2 SIPP Options 🎀
okay so SIPP has an improved option mechanism compared to IPv4, and it's honestly iconic 🔥 SIPP options live in their own separate headers, sitting between the SIPP header and the transport-layer header in a packet.
Here's the main glow-up: most SIPP option headers aren't examined or processed by any router along a packet's delivery path until it arrives at its final destination. That's a major win for router performance on packets that carry options. In IPv4, the presence of any options means the router has to examine all of them, so it's not giving the same vibes 😭
The other upgrade is that, unlike IPv4, SIPP options can be of arbitrary length, and the total amount of options carried in a packet isn't limited to 40 bytes. Put that together with the way they're processed, and SIPP options can be used for functions that weren't practical in IPv4. A perfect example is the SIPP Authentication and Security Encapsulation options 🦋
To keep handling of subsequent option headers and the transport protocol that follows fast, SIPP options are always an integer multiple of 8 octets long, so the alignment sticks around for the headers after them 🌸
The SIPP option headers that are currently defined are:
Option Function
--------------- ---------------------------------------
Routing Extended Routing (like IPv4 loose source
route)
Fragmentation Fragmentation and Reassembly
Authentication Integrity and Authentication
Security Encapsulation Confidentiality
Hop-by-Hop Option Special options which require hop by hop
processing4.3 SIPP Addressing 🌈
SIPP addresses are 64-bits long, and they're identifiers for individual nodes and for sets of nodes. There are three types: unicast, cluster, and multicast 💜
- Unicast addresses identify a single node.
- Cluster addresses identify a group of nodes that share a common address prefix, so that a packet sent to a cluster address gets delivered to one member of the group.
- Multicast addresses identify a group of nodes, so that a packet sent to a multicast address gets delivered to all of the nodes in the group.
Now for the big flex 💅 SIPP supports addresses that are twice the number of bits as IPv4 addresses. That gives an address space that's 2^^32 times the size of IPv4 addresses (also 2^^32). Another way to say it is that SIPP supports four billion internets, each the size of the maximum IPv4 internet. That's enough for every person on the planet to have their own internet! Even with several layers of hierarchy (with assignment utilization similar to IPv4), each person could have their own internet holding several thousand hosts 🌍✨
SIPP also supports extended addresses using the routing option. This lets the address space grow to 128-bits, 192-bits (or even larger) while the address units stay in manageable 64-bit units. The addresses can keep growing while the routing algorithms stay efficient, because they keep operating on 64-bit units 🧚
4.3.1 Unicast Addresses
There are several forms of unicast address assignment in SIPP: global hierarchical unicast addresses, local-use addresses, and IPv4-only host addresses. The assignment plan for unicast addresses is described in [ADDR] 🎀
4.3.1.1 Global Unicast Addresses
Global unicast addresses are used for global communication. They're the most common SIPP address and they're similar in function to IPv4 addresses. Their format is:
|1| n bits | m bits | p bits | 63-n-m-p|
+-+-------------------+---------------------+-----------+---------+
|C| PROVIDER ID | SUBSCRIBER ID | SUBNET ID | NODE ID |
+-+-------------------+---------------------+-----------+---------+The first bit is the IPv4 compatibility bit, or C-bit. It indicates whether the node represented by the address is IPv4 or SIPP. SIPP addresses are provider-oriented, which means the high-order part of the address goes to internet service providers, and they then assign portions of the address space to subscribers, and so on. It's similar to how IP addresses get assigned under CIDR 💅
The SUBSCRIBER ID tells apart multiple subscribers attached to the provider identified by the PROVIDER ID. The SUBNET ID identifies a topologically connected group of nodes within the subscriber network identified by the subscriber prefix. The NODE ID identifies a single node among the group of nodes identified by the subnet prefix 🫶
4.3.1.2 Local-Use Address
A local-use address is a unicast address with only local routability scope (within the subnet or within a subscriber network). It may have local or global uniqueness scope. These are meant for use inside of a site for "plug and play" local communication, for bootstrapping up to a single global address, and as part of an address sequence for global communication. Their format is:
| 4 |
|bits| 12 bits | 48 bits |
+----+---------------+--------------------------------------------+
|0110| SUBNET ID | NODE ID |
+----+---------------+--------------------------------------------+The NODE ID is an identifier that has to be unique in the domain where it's being used. In most cases these use a node's IEEE-802 48bit address. The SUBNET ID identifies a specific subnet in a site. Combining the SUBNET ID and the NODE ID to form a local-use address lets you build a large private internet without any other address allocation 🌸
Local-use addresses have two main perks. First, for sites or organizations that aren't (yet) connected to the global Internet, there's no need to request an address prefix from the global Internet address space. They can use local-use addresses instead. If the organization later connects to the global Internet, it can use its local-use addresses to talk to a server (for example, using the Dynamic Host Configuration Protocol [DHCP]) to get a global address automatically assigned 🌈
The second perk is that local-use addresses can hold much larger NODE IDs, which makes a super simple form of address auto-configuration possible. In particular, a node may discover a SUBNET ID by listening to Router Advertisement messages on its attached link(s), and then fabricate a SIPP address for itself by using its link-level address as the NODE ID on that subnet 🧚
An auto-configured local-use address can be used by a node as its own identification for communication within the local domain, possibly including communication with a local address server to obtain a global SIPP address. The details of host auto-configuration are described in [DHCP] 💖
4.3.1.3 IPv4-Only Addresses
SIPP unicast addresses are assigned to IPv4-only hosts as part of the IPAE scheme for transitioning from IPv4 to SIPP. These addresses have the following form:
|1| 31 bits | 32 bits |
+-+------------------------------+--------------------------------+
|1| HIGHER-ORDER SIPP PREFIX | IPv4 ADDRESS |
+-+------------------------------+--------------------------------+The highest-order bit of a SIPP address is called the IPv4 compatibility bit, or C bit. A C bit value of 1 identifies an address as belonging to an IPv4-only node 🙈
The IPv4 node's 32-bit IPv4 address is carried in the low-order 32 bits of the SIPP address. The remaining 31 bits carry the HIGHER-ORDER SIPP PREFIX, such as a service-provider ID 👑
4.3.2 Cluster Addresses
Cluster addresses are unicast addresses used to reach the "nearest" one (according to unicast routing's notion of nearest) of the set of boundary routers of a cluster of nodes that share a common prefix in the SIPP unicast routing hierarchy. They're used to identify a set of nodes. When used as part of an address sequence, a cluster address lets a node pick which of several providers it wants to carry its traffic 🦋
A cluster address can only be used as a destination address. In this example there would be a cluster address for each provider. This capability is sometimes called "source selected policies" 🍓 Cluster addresses have the general form:
| n bits | 64-n bits |
+---------------------------------+-------------------------------+
| CLUSTER PREFIX |0000000000000000000000000000000|
+---------------------------------+-------------------------------+4.3.3. Multicast Addresses 🌸
okay so a SIPP multicast address is basically an ID for a whole group of nodes 🫶 and a node can be in as many multicast groups as it wants. the layout goes like this:
|1| 7 | 4 | 4 | 48 bits |
+-+-------+----+----+---------------------------------------------+
|C|1111111|FLGS|SCOP| GROUP ID |
+-+-------+----+----+---------------------------------------------+here's the breakdown 💅
Cis the IPv4 compatibility bit.1111111in the rest of the first octet is what tells you it's a multicast address. 💜
the FLGS field is a set of 4 flags:
+-+-+-+-+
FLGS is a set of 4 flags: |0|0|0|T|
+-+-+-+-+the three high-order flags are reserved and MUST be initialized to 0. no skipping that one bestie 🙈
the last flag, T, is the important one:
T = 0means it's a permanently-assigned ("well-known") multicast address, handed out by the global internet numbering authority. very official 👑T = 1means it's a non-permanently-assigned ("transient") multicast address. more of a temporary vibe ✨
next up is SCOP, a 4-bit multicast scope value that limits how far the multicast group can reach. the values are:
0 reserved 8 intra-organization scope
1 intra-node scope 9 (unassigned)
2 intra-link scope 10 (unassigned)
3 (unassigned) 11 intra-community scope
4 (unassigned) 12 (unassigned)
5 intra-site scope 13 (unassigned)
6 (unassigned) 14 global scope
7 (unassigned) 15 reservedand finally GROUP ID identifies the multicast group, whether it's permanent or transient, within the given scope. the group ID is the main character of the whole address 🎀
4.4. SIPP Routing 🦋
okay routing in SIPP is giving familiar ngl 💖 it's almost identical to IPv4 routing under CIDR, the only real difference is that the addresses are 64-bit SIPP addresses instead of 32-bit IPv4 addresses. and this is still true when extended addresses are in use. with very straightforward extensions, all of IPv4's routing algorithms (OSPF, BGP, RIP, IDRP, etc.) can be used to route SIPP [OSPF] [RIP2] [IDRP]. so you don't have to start from zero, which is iconic of SIPP honestly 🧚
but SIPP also comes with simple routing extensions that unlock some seriously powerful new routing moves. the capabilities include:
- Provider Selection (based on policy, performance, cost, etc.)
- Host Mobility (route to current location)
- Auto-Readdressing (route to new address)
- Extended Addressing (route to "sub-cloud")
the new routing magic happens by building sequences of SIPP addresses with the SIPP Routing option. 💅 the routing option is used by a SIPP source to list one or more intermediate nodes (or topological clusters) that the packet should "visit" on its way to the destination. this is super similar to IPv4's Loose Source and Record Route option, so it's very familiar energy 🌈 and a node would publish its address sequence in the Domain Name System [DNS].
now here's the cute part. a specific transport connection is identified by only using the first (source) and last (destination) address in the sequence. those identifying addresses (the first and last addresses of a route sequence) are REQUIRED to be unique within the scope over which they are used. this is what lets the middle addresses change (for mobility, provider changes, site readdressing, etc.) without wrecking the transport connection. that's a whole glow-up without the drama 🦋
to make address sequences a general function, SIPP hosts are REQUIRED to reverse routes in a packet it receives that contains address sequences, so the packet can get back to its originator. this is done on purpose so SIPP host implementations support the handling and reversal of source routes from the start. it's the key that lets them work with hosts implementing new features like provider selection or extended addresses. main character behavior, fr 👑
three examples show how extended addressing can be used. in these examples, address sequences are written as a list of individual addresses separated by commas, like this:
SRC, I1, I2, I3, DSTthe first address is the source address, the last address is the destination address, and the middle addresses are intermediate addresses. 🫶
for these examples, assume two hosts, H1 and H2, want to communicate. assume H1 and H2's sites are both connected to providers P1 and P2, and a third wireless provider, PR, is connected to both P1 and P2. picture it like this:
----- P1 ------
/ | \
/ | \
H1 PR H2
\ | /
\ | /
----- P2 ------example 1: the simplest case 🍓 no address sequences at all. H1 wants to send a packet to H2 containing these addresses:
H1, H2when H2 replies, it reverses the addresses and builds a packet containing:
H2, H1in this example either provider could be used, and H1 and H2 would not be able to pick which provider the traffic goes out and comes in through. not very in control, bestie 💀
example 2: enforcing a policy 💜 if H1 wants to enforce a policy that all communication to and from H2 can only use provider P1, it builds a packet containing:
H1, P1, H2this makes sure that when H2 replies to H1, the route gets reversed and the reply also travels over P1. so H2's reply looks like:
H2, P1, H1example 3: H1 gets mobile 🦋 if H1 moves over to provider PR, it can keep talking to H2 without breaking any transport connections by sending packets with this address sequence:
H1, PR, P1, H2that makes sure that when H2 replies, it still enforces H1's exclusive use of provider P1, and sends the packet to H1's new location on provider PR. the reversed address sequence is:
H2, P1, PR, H1the address extension facility of SIPP can be used for provider selection, mobility, readdressing, and extended addressing. it's a simple but powerful capability, and honestly that's so iconic 🧚✨
4.5. SIPP Quality-of-Service Capabilities 💅
so the Flow Label field in the SIPP header MAY be used by a host to label the packets it wants special handling for from SIPP routers, like non-default quality of service or "real-time" service. this labeling matters for apps that need some degree of consistent throughput, delay, and/or jitter. think video calls where lag is a total no 😭 the Flow Label is a 28-bit field, and it's internally structured into three subfields:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| DP | Flow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+here's what each subfield does:
R (Reserved) 1-bit subfield. Initialized to zero for
transmission; Ignored on reception.
DP (Drop Priority) 3-bit unsigned integer. Specifies the
priority of the packet, relative to other
packets from the same source, for being
discarded by a router under conditions of
congestion. Larger values indicates a
greater willingness by the sender to allow
the packet to be discarded.
Flow ID 24-bit subfield used to identify a
specific flow.a flow is a sequence of packets sent from a particular source to a particular (unicast or multicast) destination, where the source wants the routers in between to handle them specially. there MAY be multiple active flows from a source to a destination, plus traffic that isn't part of any flow at all. a flow is identified by the combo of a Source Address and a non-zero Flow ID. packets that don't belong to a flow carry a Flow ID of zero. simple, but it works 💖
the Flow ID gets assigned to a flow by the flow's source node. new Flow IDs MUST be chosen (pseudo-)randomly and uniformly from the range 1 to FFFFFF hex. the random allocation is the secret sauce here: it makes any set of bits in the Flow ID usable as a hash key by the routers, so they can look up the special-handling state linked to that flow. ngl that's genius 🧠 and a Flow ID MUST NOT be re-used by a source for a new flow while any state from the previous usage still exists in any router. no recycling old IDs, periodt 🚫
the Drop Priority subfield gives you a way, separate from the Flow ID, to tell apart packets from the same source. it lets a source say which of its packets should be dropped first when a router can't forward them all. this is especially useful for stuff like video, where it's way better to drop the packets with screen updates than the ones carrying the video synchronization information 🎬
4.6. SIPP Security 🔥
okay real talk, the current Internet has a bunch of security problems, and it lacks effective privacy and authentication mechanisms below the application layer. yikes. SIPP fixes this with two integrated options that provide security services. they can be used singly or together to give different levels of security to different users, which is so important because different user communities have really different security needs 🫶
the first one is the "SIPP Authentication Header" 🛡️ it's an option that provides authentication and integrity (but NO confidentiality) to SIPP datagrams. the option is algorithm-independent and will support lots of different authentication techniques, but keyed MD5 is proposed to help ensure interoperability across the worldwide Internet. this can wipe out a big class of network attacks, including host masquerading attacks. it's especially important when source routing is used with SIPP, because of the known risks in IP source routing. since it sits at the internet layer, it can also help give host origin authentication to upper layer protocols and services that currently lack meaningful protections. this mechanism SHOULD be exportable by vendors in the United States and other countries with similar export restrictions, because it only provides authentication and integrity and specifically does NOT provide confidentiality. that exportability is what encourages it to be implemented and used widely. slay 💅
wait, the exportability part is literally why it can spread everywhere 🌍 the second security option is the "SIPP Encapsulating Security Header." this one provides integrity AND confidentiality to SIPP datagrams. it's simpler than some similar security protocols (e.g., SP3D, ISO NLSP) but still flexible and algorithm-independent 🧚 to get interoperability across the global Internet, the use of DES CBC is proposed as the standard algorithm for the SIPP Encapsulating Security Header.
the vibes are immaculate and the security options are literally the glow-up we needed 🌈💖
5. SIPP Transition Mechanisms 🦋
okay so the two big goals of the SIPP transition are giving direct interoperability between IPv4 and SIPP hosts 🫶 and letting the user population adopt SIPP in a super diffuse, spread-out way 💅. the transition has to be incremental with few or no critical interdependencies or it's not gonna work 😭. users can upgrade their hosts to SIPP and network operators can deploy SIPP in routers, with very little coordination between the two. it's giving low-drama 🌸
The mechanisms and policies of the SIPP transition are called "IPAE" ✨. Having its own name helps highlight the features designed specifically for transition. IPAE was once an acronym for an encapsulation technique that helped with transition, but now the term is mostly historical 📜.
The IPAE transition is based on five key elements 👑:
- A 64-bit SIPP addressing plan that encompasses the existing 32-bit IPv4 addressing plan 💖. The 64-bit plan will be used to assign addresses for both SIPP and IPv4 nodes at the beginning of the transition. Existing IPv4 nodes won't need to change their addresses, and IPv4 hosts being upgraded to SIPP keep their existing IPv4 addresses as the low-order 32 bits of their SIPP addresses. Since the SIPP addressing plan is a superset of the existing IPv4 plan, SIPP hosts are assigned only a single 64-bit address, which can be used to communicate with both SIPP and IPv4 hosts 🧚.
- A mechanism for encapsulating SIPP traffic within IPv4 packets so that the IPv4 infrastructure can be leveraged early in the transition 🌈. Most of the "SIPP within IPv4 tunnels" can be automatically configured ⭐.
- Algorithms in SIPP hosts that allow them to directly interoperate with IPv4 hosts located on the same subnet and elsewhere in the Internet 🫶.
- A mechanism for translating between IPv4 and SIPP headers to allow SIPP-only hosts to communicate with IPv4-only hosts, and to facilitate IPv4 hosts communicating over a SIPP-only backbone 🍓.
- An optional mechanism for mapping IPv4 addresses to SIPP addresses to allow improved scaling of IPv4 routing 🎀. At the present time, given the success of CIDR, this doesn't look like it will be needed in a transition to SIPP. If Internet growth continues beyond what CIDR can handle, it's available as an optional mechanism 🙈.
IPAE makes sure SIPP hosts can interoperate with IPv4 hosts anywhere in the Internet up until IPv4 addresses run out, and afterward lets SIPP and IPv4 hosts within a limited scope interoperate indefinitely 🥹. This protects, for a very long time, the huge investment users have made in IPv4 💜. Hosts that only need a limited connectivity range (think printers 🖨️) never need to be upgraded to SIPP. This also lets SIPP-only hosts interoperate with IPv4-only hosts ✨.
The incremental upgrade features of IPAE let host and router vendors fold SIPP into their product lines at their own pace, and let end users and network operators deploy SIPP on their own schedules 🌸.
The interoperability between SIPP and IPv4 that IPAE provides also extends the lifetime of IPv4 hosts 💅. With the huge installed base of IPv4, changing IPv4 in hosts is nearly impossible 😭. Once an IPng is chosen, most of the new feature development will happen on IPng, and new features in IPng will raise the incentive to adopt and deploy it 🔥.
6. Why SIPP? 🦋
okay, so there are a bunch of reasons why SIPP should be picked as the IETF's IPng 👑. It solves the Internet scaling problem, offers a flexible transition mechanism for the current Internet, and was designed to meet the needs of new markets like nomadic personal computing devices, networked entertainment, and device control 🧚. It does all this in an evolutionary way, which lowers the risk of architectural problems 🫶.
Ease of transition is a key point in SIPP's design. It's not something that got bolted on at the end 💖. SIPP is designed to interoperate with IPv4. Specific mechanisms (the C-bit, embedded IPv4 addresses, etc.) were built into SIPP to support transition and compatibility with IPv4 🌈. It was designed to allow gradual, piecemeal deployment without any dependencies, which is so iconic 💅.
SIPP supports large hierarchical addresses, which will let the Internet keep growing and provide new routing capabilities that IPv4 never had built in 🦋. It has cluster addresses that can be used for policy route selection ⭐, and scoped multicast addresses that give improved scalability over IPv4 multicast 🍓. It also has local-use addresses that enable "plug and play" installation 🎀.
SIPP is designed to have better performance than IPv4 and to work well in low-bandwidth applications like wireless 📶. Its headers are less expensive to process than IPv4's, and its 64-bit addresses were chosen to match the new generation of 64-bit processors 🔥. The compact header minimizes bandwidth overhead, which makes it ideal for wireless use 🌸.
SIPP provides a platform for new Internet functionality 👑. That includes support for real-time flows, provider selection, host mobility, end-to-end security, auto-configuration, and auto-reconfiguration 🧚.
In summary, SIPP is a new version of IP, and it can be installed as a normal software upgrade in Internet devices. It's interoperable with the current IPv4, and its deployment strategy was designed to avoid any "flag" days 🚩. SIPP is designed to run well on high-performance networks (e.g., ATM) and is still efficient for low-bandwidth networks (e.g., wireless) 💖. On top of that, it provides a platform for new Internet functionality that will be required in the near future 🌈.
7. Status of SIPP Effort 💅
There are lots of active participants in the SIPP working group 🫶. The groups making active contributions include:
Group Activity
--------------------- ----------------------------------------
Beame & Whiteside Implementation (PC)
Bellcore Implementation (SunOS), DNS and ICMP specs.
Digital Equipment Corp. Implementation (Alpha/OSF, Open VMS)
INRIA Implementation (BSD, BIND), DNS & OSPF specs.
INESC Implementation (BSD/Mach/x-kernel)
Intercon Implementation (MAC)
MCI Phone Conferences
Merit IDRP for SIPP Specification
Naval Research Lab. Implementation (BSD) Security Design
Network General Implementation (Sniffer)
SGI Implementation (IRIX, NetVisulizer)
Sun Implementation (Solaris 2.x, Snoop)
TGV Implementation (Open VMS)
Xerox PARC Protocol Design
Bill Simpson Implementation (KA9Q)As of when this paper was written, there were a bunch of SIPP and IPAE implementations 🎀. These include:
Implementation Status
-------------- ------------------------------------
BSD/Mach Completed (telnet, NFS, AFS, UDP)
BSD/Net/2 In Progress
Bind Code done
DOS &Windows Completed (telnet, ftp, tftp, ping)
IRIX In progress (ping)
KA9Q In progress (ping, TCP)
Mac OS Completed (telnet, ftp, finger, ping)
NetVisualizer Completed (SIP & IPAE)
Open VMS Completed (telnet, ftp), In Progress
OSF/1 In Progress (ping, ICMP)
Sniffer Completed (SIP & IPAE)
Snoop Completed (SIP & IPAE)
Solaris Completed (telnet, ftp, tftp, ping)
Sun OS In Progress8. Where to Get Additional Information 🧚
The documentation listed in the reference sections can be found in one of the IETF internet draft directories, or in the archive site for the SIPP working group 📂. The archive is located at:
ftp.parc.xerox.com in the /pub/sipp directory.Other SIPP material (like postscript versions of presentations on SIPP) can also be found in the SIPP working group archive 📑.
To join the SIPP working group, send electronic mail to:
sipp-request@sunroof.eng.sun.comAn archive of mail sent to this mailing list can be found in the IETF directories at:
cnri.reston.va.us9. Security Considerations 🔒
Okay, bestie, this one is SERIOUS 😱. Security issues are discussed in section 4.6, so go back and read that section carefully before you do anything else 💀. Trust me, you do not want to skip it 🙈.
10. Author's Address 🎀
Robert M. Hinden
Manager, Internet Engineering
Sun Microsystems, Inc.
MS MTV5-44
2550 Garcia Ave.
Mt. View, CA 94303
Phone: (415) 336-2082
Fax: (415) 336-6016
EMail: hinden@eng.sun.com11. References 📚
[ADDR]Francis, P., "Simple Internet Protocol Plus (SIPP): Unicast Hierarchical Address Assignment", Work in Progress, January 1994.[AUTH]Atkinson, R., "SIPP Authentication Payload", Work in Progress, January, 1994.[CIDR]Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an Address Assignment and Aggregation Strategy", RFC 1338, BARRNet, cisco, Merit, OARnet, June 1992.[DISC]Simpson, W., "SIPP Neighbor Discovery", Work in Progress, March 1994.[DIS2]Simpson, W., "SIPP Neighbor Discovery -- ICMP Message Formats", Work in Progress, March 1994.[DHCP]Thomson, S., "Simple Internet Protocol Plus (SIPP): Automatic Host Address Assignment", Work in Progress, March 1994.[DNS]Thomson, S., and C. Huitema, "DNS Extensions to Support Simple Internet Protocol Plus (SIPP)", Work in Progress, March 1994.[ICMP]Govindan, R., and S. Deering, "ICMP and IGMP for the Simple Internet Protocol Plus (SIPP)", Work in Progress, March 1994.[IDRP]Hares, S., "IDRP for SIP", Work in Progress, November 1993.[IPAE]Gilligan, R., et al, "IPAE: The SIPP Interoperability and Transition Mechanism", Work in Progress, March 1994.[IPV4]Postel, J., "Internet Protocol- DARPA Internet Program Protocol Specification", STD 5, RFC 791, DARPA, September 1981.[OSPF]Francis, P., "OSPF for SIPP", Work in Progress, February 1994.[RIP2]Malkin, G., and C. Huitema, "SIP-RIP", Work in Progress, March 1993.[ROUT]Deering, S., et al, "Simple Internet Protocol Plus (SIPP): Routing and Addressing", Work in Progress, February 1994.[SARC]Atkinson, R., "SIPP Security Architecture", Work in Progress, January 1994.[SECR]Atkinson, R., "SIPP Encapsulating Security Payload (ESP)", Work in Progress, January 1994.[SIPP]Deering, S., "Simple Internet Protocol Plus (SIPP) Specification", Work in Progress, February 1994.
📦 where this page comes from
- ietf: rfc1710 1994-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms