RFC 1454

Comparison of Proposals for Next Version of IP 🌈

Okay bestie, let's get this title block sorted first 🎀 It's a Network Working Group doc, Request for Comments 1454, written by T. Dixon from RARE, dated May 1993. It's informational ("provides information for the Internet community"), so it's not a standard 📚 Its header doesn't list anything it obsoletes or updates, so there's nothing to replace or patch here 💅

Status of this Memo ✨

This memo gives information to the Internet community 💖 It does not specify an Internet standard. Distribution of this memo is unlimited 🦋

Abstract 🫶

This is a slightly edited reprint of RARE Technical Report RTC(93)004 🌸

Okay so this is a quick summary of the three main proposals for replacing the current Internet Protocol 👑 It's not meant to be exhaustive or definitive (there's a brief bibliography at the end pointing to more info 📖). It's meant to be input for the European discussions on these proposals, coordinated by RARE and RIPE 🇪🇺

It should be recognised that the proposals are themselves "moving targets" 🎯 As far as this paper is accurate at all, it reflects the position at the 25th IETF meeting in Washington, DC. Comments from Ross Callon and Paul Tsuchiya on the original draft have been incorporated 🙌

Also, for a while the term "IPv7" was used to mean the eventual next version of IP, but it got too closely tied to one particular proposal 🙈 So now the term "IPng" is used to identify the eventual next generation of IP ✨

The paper starts with a "generic" discussion of the mechanisms for solving problems and reaching particular goals, and only then gets into the proposals individually 🧚

1. WHY IS THE CURRENT IP INADEQUATE? 💀

The problem was investigated and formulated by the ROAD group, but it basically boils down to this 😭

• Exhaustion of IP Class B Address Space.
• Exhaustion of IP Address Space in General.
• Non-hierarchical nature of address allocation leading to flat routing space.

Like, the IESG requirements for a new Internet Protocol go further than just routing and addressing 👀 But these are the issues that make extending the current protocol an impractical option 🚫 So most of the discussion and development of the proposed protocols has zeroed in on these specific problems 🎯

Near-term fixes for these problems include the CIDR proposals (which allow aggregation of Class C networks for routing purposes) and assignment policies that allocate Class C network numbers in a way CIDR can take advantage of 💅 The routing protocols that support CIDR are OSPF and BGP4. None of these are prerequisites for the new IP (IPng), but they're needed to prolong the life of the current Internet long enough to work on longer-term solutions 🫶 Ross Callon points out there are other options for prolonging the life of IP, and some ideas have been floated on the TUBA list 💌

Longer-term proposals are being sought that will ultimately allow for further growth of the Internet 🌱 The timeline for considering them looks like this:

• Dec 15 Issue selection criteria as RFC.
• Feb 12 Two interoperable implementations available.
• Feb 26 Second draft of proposal documents available.

The (ambitious) target is a decision at the 26th IETF (Columbus, Ohio, March 1993) on which proposals to pursue 🤞

The current likely candidates are:

• PIP ('P' Internet Protocol - an entirely new protocol).
• TUBA (TCP/UDP with Big Addresses - uses ISO CLNP).
• SIP (Simple IP - IP with larger addresses and fewer options).

There's also a further proposal from Robert Ullman, which I don't claim to know much about 🙈 Each candidate comes with transition plans. These are mostly independent of the protocol itself, and they include pieces that could be adopted separately, even with IP v4, to extend the life of current implementations and systems 🔥

2. WHAT THE PROPOSALS HAVE IN COMMON 🌸

2.1 Larger Addresses

All the proposals (obviously) make room for larger address fields 💖 That doesn't just mean more addressable systems. It also lets addresses be allocated hierarchically, which helps with route aggregation 🦋

2.2 Philosophy

The proposals all come from a "routing implementation" view of the world, which means they focus on the internals of routing inside the network 🌐 They don't mainly look at the network service that end users or applications actually see 😬 That's kind of unavoidable, especially with the tight deadlines for producing interoperable implementations. But the (few) representatives of real users at the 25th IETF, the people whose support is ultimately needed to deploy new host implementations, were pretty unhappy 😭

There's a built-in assumption that IPng is meant to be a universal protocol. In other words, the same network-layer protocol would be used between hosts on the same LAN, between hosts and routers, between routers in the same domain, and between routers in different domains 🔗 Defining separate "access" and "long-haul" protocols does have some advantages, and the requirements don't rule that out. But because there are so few chances for major change like that within the Internet, the need for speed and low risk has pushed the proposals toward incremental changes to well-proven existing technology rather than radical ones 🧱

There's also an unstated assumption that the architecture is aimed at the singly-connected host 🖥️ It's currently hard to design IPv4 networks where hosts with more than one interface can benefit from more bandwidth and reliability compared with singly-connected hosts. That's a consequence of the address belonging to the interface and not the host 🤔 It would be better if topological constraints like these were documented. It's been claimed that this isn't necessarily a constraint of either the PIP or TUBA proposals, but I believe it's an issue that hasn't come up so far in the comparative criteria 👀

2.3 Source Routing

IPv4 does have provision for source-specified routes, though they're barely used [would someone like to contradict me here?] 🙋 Partly that's because they need knowledge of the network's internal structure right down to the router level 😵 Users usually need source routes when there are policy requirements that make it preferable, or even imperative, for traffic between a source and destination to pass through particular administrative domains 🏢 Routers inside administrative domains can also use source routes to route through particular logical topologies 🗺️ Source-specified routing needs a few distinct pieces:

• a. The specification by the source of the policy by which the route should be selected.
• b. The selection of a route appropriate to the policy.
• c. Marking traffic with the identified route.
• d. Routing marked traffic accordingly.

These steps aren't totally independent 🔗 How routes are identified in step (c) may limit the kinds of route that can be selected in the earlier steps. The destination inevitably takes part in specifying source routes too, either by advertising the policies it's willing to accept or, possibly, through some kind of negotiation 🤝

All of the proposals mark source routes by adding a chain of (perhaps partially-specified) intermediate addresses to each packet 📦 None of them specifies how a host might acquire the information needed to specify those intermediate addresses [not entirely unreasonably at this stage, but further information is expected] 🙃 The negative consequences of these decisions are:

• Packet headers can become quite long, depending on the number of intermediate addresses that must be specified (although there are mechanisms which are currently specified, or which can be imagined, to specify only the significant portions of intermediate addresses).
• The source route may have to be re-specified periodically if particular intermediate addresses are no longer reachable.

The positive consequences are:

• Inter-domain routers don't have to understand policies. They just have to mechanically follow the source route 🤖
• Routers don't have to store context identifying routes, since the information is in each packet header 💁
• Route servers can be located anywhere in the network, as long as the hosts know how to find them 🗺️

2.4 Encapsulation

Encapsulation means enclosing a network-layer packet inside another one, so the actual packet can take a path it wouldn't otherwise take, to a router that can strip off the outermost packet and send the resulting packet on to its destination 🎁 Encapsulation needs:

• a. An indication in the packet that it contains another packet.
• b. A function in routers which, on receiving such a packet, removes the encapsulation and re-enters the forwarding process.

All the proposals support encapsulation ✅ And it's worth noting that you can get the effect of source routing through suitable encapsulation by the source 🧠

2.5 Multicast

Addresses can be specified to permit multicast with various scopes, and all the proposals can accommodate that 📡 Internet-wide multicast is, of course, for further study! 🔮

2.6 Fragmentation

All the proposals support fragmentation of packets by intermediate routers 🧩 There's been some recent discussion of removing this mechanism from some of the proposals and requiring an MTU-discovery process to avoid the need for fragmentation 👀 That would effectively rule out transport protocols that use message-count sequence numbering (like OSI Transport) over the network, because only protocols with byte-count acknowledgement (like TCP) can handle MTU reductions during the lifetime of a connection 😬 OSI Transport may not matter much to the IP community (though it might matter to commercial suppliers offering multiprotocol services), but the consequences for the types of services that can be supported over IPng should still be noted 📝

2.7 The End of Lifetime as We Know It

The old IPv4 "Time to Live" field has been recast in every case as a simple hop count, mostly because it's easier to implement 🙄 The old TTL was largely implemented that way anyway, but it did serve an architectural purpose: it put an upper bound on how long a packet could live in the network ⏳ If this field becomes a hop count, there has to be some other specification of the maximum lifetime of a packet in the network. That way a source host can make sure that network-layer fragment IDs and transport-layer sequence numbers never risk being reused while there's still a risk of confusion 😵‍💫 There are, in fact, three separate issues here:

1. Terminating routing loops (solved by hop count).
2. Bounding the lifetime of network-layer packets (a necessity, unspecified so far) to support assumptions made by the transport layer.
3. Letting the source place further restrictions on packet lifetime (for example, so that "old" real-time traffic can be discarded in favour of new traffic in the case of congestion (an optional feature, unspecified so far)).

3. WHAT THE PROPOSALS ONLY HINT AT 👀

Part 2 picks up right here, bestie 🫶

3.1 Resource Reservation ✨

okay bestie, apps like real-time video and audio literally need a certain bandwidth or transit delay or they're just not useful 😭. So they need a way to tell the network what they need and get those resources reserved 💅. It's kinda like picking a source route, lowkey, and it goes like this:

• a. The source spells out its requirements.
• b. The network confirms those requirements can be met.
• c. The traffic gets marked with the requirement.
• d. Routers send the marked traffic accordingly.

Traffic that's routed under the same set of resource requirements is called a "flow" 🦋. Identifying flows needs a setup process, and it's super tempting to think the same process could set up source routes too... but nah, there are some differences:

• All the routers on a path have to take part in resource reservation and agree to it.
• So it's pretty straightforward to keep context in each router, and the identification for flows can be short.
• The network can choose to reroute when something fails.

Each proposal could carry flow identification by various means, but honestly that's still "for future study" 🤓. No setup mechanisms are defined yet. Actually reserving the resources is a higher-order problem 🙃. The interaction between source routing and resource reservation needs more investigation. Even though the two are distinct and have different implementation constraints, having two separate mechanisms could make it hard to pick routes that hit both policy and performance goals 😭.

3.2 Address-Assignment Policies 🏠

In IPv4, addresses were bound to systems on a long-term basis, and in lots of cases you could swap them with DNS names 🙌. It's tacitly accepted that the link between an address and a particular system may be more volatile in IPng 👀. In fact, one of the proposals, PIP, separates the identification of a system (a fixed thing) from its address, and lets the binding change on the fly 🦋.

None of the proposals sets bounds on how long addresses live, and how addresses get assigned isn't necessarily tied to any one proposal. For example, within the bigger address space IPng would offer, you have to choose whether to assign the "higher order" part of the hierarchical address by geography or by service provider 🗺️. Geographic addresses can stay constant and are easy to assign, but they bring back the danger of sliding into "flat" addresses inside the region they're assigned in, unless certain topological restrictions are assumed. Provider-based assignment means you get a new address if you change providers, or multiple addresses if you use multiple providers. Mobile hosts (depending on the underlying technology) can cause problems in both geographic and provider-based schemes 📱.

Without firm proposals for address-assignment schemes and what they mean for likely address lifetimes, you can't just assume the existing DNS model (where name-to-address bindings can be discovered) still holds up 💀.

Note that there's an interaction between the mechanism for assignment of addresses and the way automatic configuration may be deployed 🤝.

3.3 Automatic Configuration 🤖

Among the biggest (user) bugbears of current IP services is the admin effort of maintaining basic configuration info, like assigning names and addresses to hosts, making sure they're reflected in the DNS, and keeping everything correct 😩. Some of this comes from poor implementation (or the blind belief that vi and awk are network management tools 💀). But a lot of the problems could be eased by making the process more automatic ✨. Some of the possibilities (some of them mutually exclusive) are:

• Assigning host addresses from some (relative) invariant, such as a LAN address.
• Defining a protocol for dynamic assignment of addresses within a subnetwork.
• Defining "generic addresses" that let hosts reach necessary local servers (DNS, route servers, etc.) without preconfiguration.
• Having hosts determine their name by DNS lookup.
• Having hosts update their name/address bindings when their configuration changes.

While a bunch of the proposals mention some of these possibilities, picking the right solution depends somewhat on address-assignment policies. Also, dynamic configuration brings up some tricky philosophical and practical questions: what exactly is the role of an address? In what sense is a host "the same host" when its address changes? How do you handle dynamic changes to DNS mappings, and how do you authenticate them? 🧐

The groups involved in the proposals would, I think, see most of these questions as outside their scope. It would seem to be a failure in the process of defining and selecting candidates for IPng that "systemness" issues like these will probably not be discussed much. The participants recognise this, and it's likely that even when a decision is made, some of these ideas will be revisited by a wider audience 🫶.

It is, however, unlikely that IP will make an impact on proprietary networking systems for the non-technical environment (e.g., Netware, Appletalk) unless automatic configuration is taken seriously, either in the architecture or by suppliers. I believe there are ideas in people's heads about how to address these issues. They just haven't made it onto paper yet 📝.

3.4 Application Interface/Application Protocol Changes 🔌

A number of common application protocols (FTP, RPC, etc.) have been identified as specifically transferring 32-bit IPv4 addresses, and there are doubtless others, both standard and proprietary 😬. There are also lots of applications that treat IPv4 addresses as simple 32-bit integers. Even applications that use BSD sockets and try to handle addresses opaquely won't know how to parse or print longer addresses (even if the socket structure is big enough to hold them) 🙈.

So each proposal needs to specify mechanisms that let existing applications and interfaces keep working in the new environment while conversion takes place 🔄. It would also be useful to have (one) specification of a reference programming interface for (TCP and) IPng, which would also work on IPv4, so developers can start changing applications now 💻. All the proposals specify transition mechanisms from which existing application compatibility can be inferred. There's still no sign of a new interface specification that's independent of the chosen protocol 🥲.

3.5 DNS Changes 🌐

It's obvious there has to be a name-to-address mapping service that supports the new, longer addresses 📖. All the proposals assume DNS will provide this, with some suitably defined new resource record. There's ongoing discussion about whether it's appropriate to return this info alongside "A" record info in response to certain enquiries, and which info should be requested first 🤔. There's a potential tradeoff between the number of queries needed to establish the right address to use, and the potential for breaking existing implementations by returning info they don't expect 💅.

There has been heat, but not light 🔥, generated by discussion of the use of DNS for auto-configuration and the scaling (or otherwise) of reverse translations for certain addressing schemes 🙃.

---

4. WHAT THE PROPOSALS DON'T REALLY MENTION 🙈

4.1 Congestion Avoidance 🚦

IPv4 offers "Source Quench" control messages, which routers may use to tell a source that it's congested and has or may shortly drop packets. TUBA/PIP have a "congestion encountered" bit that gives similar info to the destination. None of these specs offers detailed instructions on how to use these facilities. However, there's been a substantial body of analysis over recent years suggesting that such facilities can be used (by providing info to the transport protocol) not only to signal congestion, but also to minimise delay through the network layer 🧠. Each proposal can offer some form of congestion signalling, but none specifies a mechanism for its use (or an analysis of whether the mechanism is actually useful) 🫠.

As a user of a network service with a discard rate of around 30% and a round-trip time of up to 2 seconds for a distance of only 500 miles 😭, I would be most interested in proposals for a more graceful degradation of the network service under excess load 💜.

4.2 Mobile Hosts 📱

A characteristic of mobile hosts is that they (relatively) rapidly move their physical location and point of attachment to the network topology 🏃‍♀️. This obviously matters for addressing (whether geographical or topological) and for routing. There seems to be an understanding of the problem, but so far no detailed specification of a solution 🤷.

4.3 Accounting 💸

The IESG selection criteria only require that proposals don't prevent the collection of information that may be of interest for audit or billing purposes 🧾. So none of the proposals consider potential accounting mechanisms 😶.

4.4 Security 🔐

"Network Layer Security Issues are For Further Study". Or secret. 🤫

However, it would be useful to have it demonstrated that each candidate could be extended to provide a level of security, for example against address-spoofing 🛡️. This will be especially important if resource-allocation features let certain hosts claim large chunks of available bandwidth for specialised applications 🚨.

Note that providing some level of security means manually configuring security information within the network, and that has to be weighed against the auto-configuration goals 🔑.

5. WHAT MAKES THE PROPOSALS DIFFERENT? 🎀

Okay so each proposal is basically as different from the others as it is from IPv4 🤯. The differences are small in principle, but they can have big effects (making addresses bigger is only a small change in principle, lol). Here are the main vibes:

PIP: PIP has an innovative header format that facilitates hierarchical, policy and virtual-circuit routing. It also has "opaque" fields in the header whose semantics can be defined differently in different administrative domains, and whose use and translation can be negotiated across domain boundaries. No control protocol is specified yet 🧚

SIP: SIP is giving "minimalist" 💅. It removes all the little-used fields from the IPv4 header and extends addresses to (only) 64 bits. The control protocol is based on modifications to ICMP. This one has the advantages of processing efficiency and familiarity ✨

TUBA: TUBA is based on CLNP (ISO 8473) and the ES-IS (ISO 9542) control protocol. It provides for the operation of TCP transport and UDP over a CLNP network. The main arguments in favour of TUBA are that routers already exist which can handle the network-layer protocol, that the extensible addresses offer a wide margin of "future-proofing," and that there is an opportunity for convergence of standards and products 🌈

5.1 PIP 🦋

PIP packet headers contain a set of instructions for the router's forwarding processor, telling it to perform certain actions on the packet. In traditional protocols, the contents of certain fields imply certain actions. PIP gives the source the flexibility to write small "programs" that direct how packets get routed through the network 💜

PIP addresses have an effectively unlimited length. Each level in the topological hierarchy of the network contributes part of the address, and addresses change as the network topology changes. In a completely hierarchical network topology, the amount of routing information needed at each level could be very small. In practice, though, levels of hierarchy will be decided more by commercial and practical factors than by the constraints of any particular routing protocol. A bigger advantage is that higher-order parts of the address may be omitted in local exchanges, and lower-order parts may be omitted in source routes. That reduces how much topological information host systems have to know 🍓

There's an assumption that PIP addresses are liable to change, so a further quantity, the PIP ID, is assigned to systems for identification purposes. It isn't clear that this quantity serves any purpose that couldn't equally be handled by a DNS name [it is more compact, but equally it does not need to be carried in every packet and requires an additional lookup]. The problem does come up, though, of how two potentially-communicating host systems find the correct addresses to use 🤔

The most complex part of PIP is that the meaning of some header fields is determined by mutual agreement within a particular domain. The semantics of specific processing facilities (for example, queuing priority) are registered globally, but the actual use and encoding of requests for these facilities in the packet header can differ between domains. Border routers between two domains that use different encodings must map from one encoding to another. Routers may be adjacent to other domains not only physically, but also via "tunnels," so the number of different encoding rules a router may need to understand can get pretty large 😭. There is a saving in header space compared to the more familiar "options," but the cost of negotiating the use and encoding of these facilities, along with re-coding the packets at each domain border, is a real concern. Hosts might be able to "precompile" the encoding rules for their local domain, but there are many potential implementation difficulties 💀

Honestly, PIP offers the most flexibility of the three proposals. Still, more work needs to be done on "likely use" scenarios that make the potential advantages and disadvantages more concrete 🫶

5.2 SIP 🌸

SIP is basically IP with larger addresses and fewer options. Its main advantage is that it's even simpler than IPv4 to process. Its main disadvantages are:

• It is far from clear that, if 32 bits of address are insufficient, 64 will be enough for the foreseeable future 💀;
• although there are a few "reserved" bits in the header, extending SIP to support new features is not obvious 🙈.

There's really very little else to say! 💅

5.3 TUBA 🧚

The characteristics of ISO CLNS are reasonably well known. The protocol has a strong cultural resemblance to IPv4, though it uses 20-byte network-layer addressing. Apart from a spurious "Not Invented Here" prejudice, the main argument against TUBA is that it's rather too like IPv4, offering nothing other than larger, more flexible addresses. There is proof-by-example that routers can handle the (very) long addresses efficiently. There is much less evidence that the longer headers don't adversely impact network bandwidth 👀

There are a number of objections to the proposed control protocol (ISO 9542):

• Tim's early experience is that the process by which routers discover hosts is inefficient and resource-consuming for routers. It also requires quite fine timer resolution on hosts if large LANs are to be accommodated reasonably. Proponents of TUBA suggest that recent experience shows ARP is no better, but Tim thinks this issue needs examination 🔍.
• The "redirect" mechanism is based on (effectively) LAN addresses and not network addresses. That means local routers can only "hand off" complex routing decisions to other routers on the same LAN. Equally, redirection schemes (such as IPv4's) that redirect to network addresses can result in unnecessary extra hops. Which solution is better depends a lot on the scenarios that get constructed 🤷‍♀️.

To be fair, though, the part of the protocol that handles router discovery provides a mechanism, absent from the other proposals, by which hosts can locate nearby gateways and potentially configure their addresses automatically. That's a real slay 👑.

6. Transition Plans 🦋

It should be obvious that a transition which lets "old" hosts talk to "new" hosts requires:

Either:

• (a) IPng hosts can also use IPv4, or
• (b) there is translation by an intermediate system;

and either:

• (c) the infrastructure between systems is capable of carrying both IPng and IPv4, or
• (d) tunneling or translation is used to carry one protocol within another in parts of the network.

The transition plans espoused by the various proposals are simply different combinations of the above. Experience suggests that all of these things will actually happen, regardless of which protocol is chosen 🌈

One problem with the tunneling and translation process is that there is additional information (the extra address parts) that must be carried across IPv4 tunnels in the network. This can be carried either by adding an extra "header" to the data before encapsulation in the IPv4 packet, or by encoding the information as new IPv4 option types. With the former, it may be difficult to map error messages correctly, since the original packet is truncated before it's returned. With the latter, there's a danger of the packet being discarded, because IPv4 options are not self-describing and new ones may not pass through IPv4 routers 😱. So there's a real possibility of having to introduce a "new" version of IPv4 in order to support IPng tunneling.

The alternative, where IPng hosts have two stacks and the infrastructure may or may not support IPng or IPv4, of course requires a mechanism for working out which protocols to try 🍓.

7. Random Comments 💬

This is the first fundamental change in the Internet protocols since the Internet was manageable as an entity and its development was tied to US government contracts. It was perhaps inevitable that the IETF/IESG/IAB structure wouldn't have evolved to manage a change of this magnitude. Hopefully the new structures being proposed will be more successful at building a useful consensus 🙏. It's kind of interesting that many of the perceived problems of the OSI process (slow progress, factional infighting over trivia, convergence on the lowest-common-denominator solution, and lack of consideration for the end-user) are in danger of attaching themselves to IPng. It'll be interesting to see how much of this is an inevitable consequence of wide representation and participation in network design 🧐

It could be seen as either a sign of success or failure of the competitive process for selecting IPng that the three main proposals have so few really significant differences. In this respect, the result of the selection process isn't especially significant. The process itself, though, may be necessary to repair the social and technical cohesion of the Internet engineering process 🫶✨

8. Further Information 🔎

The main discussion lists for the proposals are:

     TUBA:           tuba@lanl.gov
     PIP:            pip@thumper.bellcore.com
     SIP:            sip@caldera.usc.edu
     General:        big-internet@munnari.oz.au

     (Requests to: <list name>-request@<host>)

Internet-Drafts and RFCs for the various proposals can be found in the usual places 📚.

Security Considerations 💀

Security issues are not discussed in this memo. Yes, you read that right. Nothing about security in here, bestie, so keep that in mind 🙈.

Author's Address 🖋️

Tim Dixon
RARE Secretariat
Singel 466-468
NL-1017AW Amsterdam
(Netherlands)

Phone: +31 20 639 1131 or + 44 91 232 0936
EMail: dixon@rare.nl or Tim.Dixon@newcastle.ac.uk