RFC 1671

IPng White Paper on Transition and Other Considerations 💖

okay bestie, this is RFC 1671 📜 (part 1 of 2!) and it's giving serious networking energy 🎀. It came from the Network Working Group and was written by B. Carpenter at CERN 🌸. It's marked as Informational and dated August 1994 ✨. The header doesn't list any RFCs that it obsoletes or updates, so nothing gets replaced or changed by it 🫶.

---

Status of this Memo 📜

so this memo is here to give information to the Internet community 💅. It is not specifying an Internet standard of any kind. 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 has accepted any of the ideas in it 🙈. Comments should go to the big-internet@munnari.oz.au mailing list 💌.

Summary ✨

okay so this white paper lays out some general requirements for IPng in selected areas 💜. It names these requirements for stepwise transition:

• A) Interworking at every stage and every layer.
• B) Header translation considered harmful
• C) Coexistence.
• D) IPv4 to IPng address mapping.
• E) Dual stack hosts.
• F) DNS.
• G) Smart dual-stack code.
• H) Smart management tools.

It also has some remarks about physical and logical multicast 🦋, and it suggests that a model of how IPng will run over ATM is needed.

Finally, the paper suggests that the requirements for policy routing, accounting, and security firewalls will in turn require all IPng packets to carry a trace of the type of transaction involved, as well as of their source and destination 🔥.

Transition and deployment 🌸

it is so clear that the transition will take years, and every site will have to decide on its own staged transition plan 😭. Only the very smallest sites could even picture a single-step "flag day" transition, presumably because their Internet service providers are pressuring them.

once the IPng decision is made, the next decade (or more) of activity on the Internet and in every private network using the Internet suite will be strongly affected by how IPng gets deployed 🌈. Sites will look at whether to move off IPv4 the same way they've looked at changing programming languages or operating systems 💀. It may not be a foregone conclusion that what they switch to is IPng. Their main concern will be minimising the cost of the change and the risk of lost production 💖.

This concern immediately sets strong constraints on the model for transition and deployment of IPng. Some of these constraints are listed below, each with a short explanation 🫶.

Terminology: an "IPv4 host" is a host that runs exactly what it runs today, with no maintenance releases and no configuration changes. An "IPng host" is a host that has a new version of IP and has been reconfigured. Routers work the same way 🎀.

A) Interworking at every stage and every layer. 🔥

this is the major constraint 😤. Vendors of computer systems, routers, and applications software will certainly not coordinate their product release dates, and users will keep running their old equipment and software 💀. So any combination of IPv4 and IPng hosts and routers must be able to interwork (i.e., take part in UDP and TCP sessions). An IPv4 packet must be able to find its way from any IPv4 host, to any other IPv4 or IPng host, or vice versa, through a mixture of IPv4 and IPng routers, with no (zero, null) modifications to the IPv4 hosts. IPv4 routers must need no modifications to interwork with IPng routers.

there's also an application package that's "aware" of IPv4 but still "unaware" of IPng. It must be able to run on a computer system that's running IPv4 while it talks to an IPng host 👑. For example, an old PC in Europe should be able to access a NIC server in the USA, even if that NIC server is running IPng and the transatlantic routing mechanisms are only partly converted. Or a Class C network in one department of a company should keep full access to corporate servers running IPng, even though nothing whatever has been changed inside that Class C network 🧚.

(This does not require an IPv4-only application to run on an IPng host. So we accept that some hosts can't be upgraded until all their applications are IPng-compatible. In other words, we accept that the API may change to some extent. However, even this relaxation is debatable, and some vendors may want to strictly preserve the IPv4 API on an IPng host 🙈.)

B) Header translation considered harmful. 💀

This author believes that any transition scenario which requires dynamic header translation between IPv4 and IPng packets will create almost insurmountable practical difficulties:

B1) It's taken for granted for the purposes of this paper that IPng functionality will be a superset of IPv4 functionality. But successful translation between protocols requires that the functionalities of the two protocols being translated are effectively identical. To get there, applications would need to know when they're interworking (via the IPng API and a translator somewhere in the network) with an IPv4 host, so they only use IPv4 functionality. That is an unrealistic constraint 😩.

B2) Administering translators will be quite impracticable for large sites, unless the translation mechanism is completely blind and automatic. Specifically, any translation mechanism that requires special tags to be maintained manually for each host in tables (such as DNS tables or router tables) to indicate the need for translation will be impossible to administer. On a site with thousands of hosts running many versions and releases of several operating systems, hosts move forwards and even backwards between software releases, so continuously tracking the required state of those tags will be impossible. Multiply that across the whole Internet and you get chaos, complex failure modes, and difficult diagnosis. In particular, it will make the constraint of paragraph B1) impossible to respect 💔.

In practice, the knowledge that translation is needed should never leak out of the site concerned if chaos is to be avoided. Yet without that knowledge, applications can't limit themselves to IPv4 functionality when necessary 😭.

To avoid confusion, note that header translation, as discussed here, is not the same thing as address translation (NAT). This paper does not discuss NAT 🙅‍♀️.

This paper doesn't tackle performance issues in detail, but clearly another disadvantage of translation is the overhead that comes with it 🐢.

C) Coexistence. 🌈

The Internet infrastructure (whether global or private) must allow IPv4 and IPng to coexist in the same routers and on the same physical paths 🫶.

This is a necessity, so the network infrastructure can be updated to IPng without requiring hosts to be updated in lock step, and without requiring translators 🔧.

Note that this requirement does not decide between a common or separate (ships-in-the-night) approach to routing. It also doesn't rule out encapsulation as a coexistence mechanism 🦋.

D) IPv4 to IPng address mapping. 🧚

Human beings will have to understand what's happening during the transition 🧠. Auto-configuration of IPng addresses may be a desirable end point, but managing the transition will be way simpler if there's an optional, simple mapping on a given site between IPv4 and IPng addresses ✨.

So the IPng address space should include a mapping for IPv4 addresses. If a site or service provider wants to do this, the IPv4 address of a system can be transformed mechanically into its IPng address, most likely by adding a prefix. The prefix doesn't have to be the same for every site. It's likely to be at least service-provider specific 💜.

This doesn't mean such address mapping will be used for dynamic translation (although it could be), or to embed IPv4 routing within IPng routing (although it could be). Its main purpose is to simplify transition planning for network operators 📋.

By the way, this requirement doesn't actually assume that IPv4 addresses are globally unique 👀.

It also doesn't help much in setting up the relationship, if any, between IPv4 and IPng routing domains and hierarchies. There's no reason to suppose those will be in 1:1 correspondence 🙃.

E) Dual stack hosts. 👑

Stepwise transition without translation is hard to imagine unless a large proportion of hosts can run IPng and IPv4 at the same time 😵‍💫. If A needs to talk to B (an IPng host) and to C (an IPv4 host), then either A or B must be able to run both IPv4 and IPng. In other words, all hosts running IPng must still be able to run IPv4. IPng-only hosts are not allowed during transition 🚫.

This requirement doesn't mean IPng hosts really have two completely separate IP implementations (dual stacks and dual APIs). It just means they behave as if they did. It's compatible with encapsulation, meaning one of the two stacks encapsulates packets for the other 🎁.

Obviously, managing dual stack hosts gets simpler with the address mapping we just talked about. Only the site prefix has to be configured (manually or dynamically) in addition to the IPv4 address 🙌.

In a dual stack host, the IPng API and the IPv4 API will be logically distinguishable, even if they're implemented as a single entity. Applications will know from the API whether they're using IPng or IPv4 🍓.

F) DNS. 🍓

The dual stack requirement means DNS has to reply with both an IPv4 and an IPng address for IPng hosts, or with a single reply that encodes both 📡.

If a host is given an IPng address in DNS but isn't actually running IPng yet, it'll show up as a black hole in IPng space. See the next point 🕳️.

G) Smart dual-stack code. 💅

The dual-stack code may get two addresses back from DNS. Which one does it use? 🤔 During the many years of transition, the Internet will contain black holes. For example, somewhere on the way from IPng host A to IPng host B there will sometimes (unpredictably) be IPv4-only routers that discard IPng packets. Also, the state of the DNS doesn't necessarily match reality. A host that DNS says has an IPng address may not actually be running IPng at a particular moment, so an IPng packet to that host gets discarded on delivery 😬.

Knowing that a host has both IPv4 and IPng addresses tells you nothing about black holes. A solution to this must be proposed, and it must not depend on manually maintained information. (If this isn't solved, the dual stack approach is no better than the packet translation approach 💀.)

H) Smart management tools. 🔍

A whole set of management tools is going to be needed during the transition 🛠️. Why is my IPng route different from my IPv4 route? If there's translation, where does it happen? Where are the black holes? (Cosmologists would like the same tool :-) Is that host really IPng-capable today?... 🌌😭

that's the end of part 1 🦋 part 2 is coming up next, so stay tuned 💖

Multicasts high and low ✨

okay bestie, it's taken for granted that multicast apps MUST be supported by IPng. non-negotiable 💅 one obvious architectural rule is that no multicast packet SHOULD ever travel twice over the same wire, whether it's a LAN or a WAN wire. if that happened, the max number of simultaneous multicast transactions would literally get halved 😭 not it.

a negative feature of IPv4 on LANs is how casually physical broadcast packets get used by protocols like ARP (and various non-IETF copycats) 🙄 on big LANs this causes a bunch of undesirable consequences. honestly those are usually caused by poor products or poor users, not the protocol design itself 🙈 the obvious architectural rule is that physical broadcast SHOULD be replaced by unicast (or at worst, multicast) whenever possible 🌸

ATM 🦋

the networking industry is investing heavily in ATM, so no IPng proposal is going to be plausible (meaning, gaining management approval) unless it is "ATM compatible". that means there's a clear model of how it will run over an ATM network 👀 a fully detailed document like RFC 1577 isn't needed right away, but it MUST be shown that the basic model works 💖

similar vibes could be said about X.25, Frame Relay, SMDS etc., but ATM has the highest management hype ratio today 💀

Policy routing and accounting 💸

unfortunately this cannot be ignored, no matter how much we'd like to 😩 funding agencies want traffic to flow over the lines they funded to carry it, and they want to know afterwards how much traffic there was. accounting info can also be used for network planning and for back-charging 📊

so it's necessary that IPng and its routing procedures let traffic be routed in a way that depends on its source and destination in detail. (for example, traffic from the Physics department of MIT might be REQUIRED to travel a different route to CERN than traffic from any other department 🧚)

a simple way to handle this is to insist that IPng MUST support provider-based addressing and routing 🎀

accounting of traffic is REQUIRED at the same level of detail (or even more, like how much of the traffic is ftp and how much is www? 👑)

both of these requirements will cost time or money and MAY impact more than just the IP layer, but IPng SHOULD NOT duck them 💅✨

---

Security Considerations 🔐

corporate network operators, and campus network operators who have been hacked a few times, take this way more seriously than a lot of protocol experts do. honestly, many corporate network operators would see improved security as a more compelling reason to transition to IPng than anything else 😭🚨

since IPng will presumably be a datagram protocol, which limits what can be done in terms of end-to-end security, IPng MUST allow more effective firewalls in routers than IPv4 🔥 in particular, efficient traffic barring based on source and destination addresses and types of transaction is needed.

the same features needed for policy routing and detailed accounting would probably also be needed for better firewall security 🛡️ it's outside the scope of this document to get into these features in detail, but it seems unlikely they're limited to implementation details in the border routers. packets will have to carry some authenticated trace of the (source, destination, transaction) triplet so routers can check for unwanted traffic, allow policy-based source routing, and/or allow detailed accounting 🧾 presumably any IPng will carry source and destination identifiers in some format in every packet, but identifying the type of transaction, or even the individual transaction, is an extra requirement 💜

---

Disclaimer and Acknowledgements 🫶

this is a personal view and does not necessarily represent that of my employer 🌈

CERN has been through three network transitions in recent years 🙌 there was IPv4 renumbering (managed by John Gamble), the AppleTalk Phase I to Phase II transition (managed by Mike Gerard), and the DECnet Phase IV to DECnet/OSI routing transition (managed by Denise Heagerty). I could not have written this document without having learnt from them. I've also benefitted hugely from discussions with, or the writings of, many people, especially various members of the IPng Directorate 💖 several Directorate members gave comments that helped clarify this paper, and so did Bruce L Hutfless of Boeing. however, the opinions are mine and are not shared by all Directorate members 💅

---

Author's Address 💌

Brian E. Carpenter
Group Leader, Communications Systems
Computing and Networks Division
CERN
European Laboratory for Particle Physics
1211 Geneva 23, Switzerland

Phone:  +41 22 767-4967
Fax:    +41 22 767-7155
Telex:  419000 cer ch
EMail: brian@dxcoms.cern.ch