RFC 1676

RFC 1676: INFN Requirements for an IPng 🦋

okay bestie, title block tea ☕ this is an Informational doc from the Network Working Group, dated August 1994. It was written by A. Ghiselli, D. Salomoni, and C. Vistoli, all from INFN/CNAF 💅. The header doesn't list any obsoletes or updates, so there's no drama there ✨

Status of this Memo 🌸

this one's just info for the Internet community 💖 It is not an Internet standard, not even a little bit. And distribution is unlimited, so share away 🫶

Overview 🎀

So this doc was submitted to the IETF IPng area as a reply to RFC 1550 💌 Publishing it doesn't mean the IPng area agreed with any of the ideas inside 🙈 Comments should go to the big-internet@munnari.oz.au mailing list.

Abstract 🌈

This white paper comes from the INFN network team, the Italian National Institute for nuclear physics 🧪 Their network, INFNet, is a nationwide network set up to give access to existing national and international HEP laboratories and to help researchers talk to each other 🤝 With this paper they want to highlight the key points they would like to consider if they ever get put in charge of an IPng plan 👑 They don't really expect to add brand-new items to the selection, but they think sharing the opinions and ideas from their own network experience is useful ✨

1. General Requirements 💅

okay so the big problems IP internet has to solve are basically three:

1. address exhaustion
2. flat address space
3. routing efficiency, flexibility and capacity.

The goal of the IPng study should be a plan that fixes all of these together, not each one on its own 🧩 no piecemeal stuff, bestie 😤

The general requirements they really underline for this transition are:

• transparency to the final user: user applications should not be influenced. 🫧
• flexibility: it should be easy to fit new communication technology and topology changes, whether they come from new services or from different user needs 🦋

2. Application and Transport Level 🦋

Starting from the top of the OSI model, they think users' applications should not be influenced by the migration plan 💖 That means TCP (the transport layer) must keep the same interfaces and services for the upper layers. But it's also necessary to plan for using different transport services, and applications should be offered the option to use a different transport. So a transport selector field is needed 🎀

3. Network layer: service and address 🌐

They assume the network layer must keep providing the same datagram service IP does 🫶 CLNS could be a solid starting point for IPng. The big win is that it's been properly tested and is already available on lots of systems 🔥 It isn't deployed as widely as IPv4, of course, since it's newer tech. But it's widely configured and there's already operational experience 🧠

The matching address, the NSAP, is 20 bytes long. That's long enough to scale the future data network environment 📈 Its hierarchical format can be organized in a really flexible way, covering hierarchical routing and policy-based routing needs and making distributed administration and management way simpler 👑 Lots of work has already been done in most countries to define NSAP formats that satisfy both administrative delegation and routing performance needs 🌍

4. Routing protocols 🛣️

They don't think the choice of routing protocol for IPng is fundamental 🙃 Yes, it matters a lot for good performance, but routing protocols can be changed or improved at any time because they don't affect the End Systems configuration 💅 The relationships between NSAP aggregation, hierarchical topology and hierarchical routing algorithm must be taken into account in the IPng plan 🧩 These issues could improve administration and topological flexibility and solve the flat problem of IPv4 ✨

IPng routing protocols should include policy-based features 🔐 The IPv4 network topology is super complex and will keep growing during the transition 😭 Managing it without "policy" tools would be really difficult, or impossible. The multicast capability, plus any other new features that fit in a datagram network, should be supported 🌈

As for Source Routing, they think it seriously changes the aim and the "philosophy" of a connectionless network, and it adds heavy complexity to end node and router software. So they don't consider it a major issue 🙅‍♀️

5. Layer 2 or communication infrastructure media support. 📡

This is a wide-open, fast-changing field, so it must be left open to any evolution 🦋 What should be recommended is compatibility with the network layer above ✨

6. Transition and Deployment 🚀

They dealt with moving the DECNET global network to DECNET/OSI over CLNS 💜 That work is now on its final step, and from that experience they want to underline a few points that really mattered during the transition deployment 🙌

First up: transitions must be planned and developed in a distributed way 🧩 Every organization should be able to plan and start its own network migration without losing connectivity with the existing global internet 🌍 And compatibility with the IPv4 world must be maintained. A new-generation system must interwork with both IPv4 and IPng nodes, using the same applications 🫶

But it's also important to set a deadline for backward compatibility. Otherwise you get huge software maintenance in user systems and a "multi-topology" mess 😩 They think a dual stack approach could make the transition much simpler, while a translation mechanism would need wide and deep coordination to keep global connectivity during the transition period 🤓 Dual stack is simpler and easier to develop. Still, it's important to push toward pure IPng with global connectivity as soon as possible, which could happen once there are no more "IPv4 only" hosts 🏁

Here's the catch with dual stack, though 😬 You keep suffering from IPv4 address space exhaustion, and you must keep supporting IPv4 routing protocols and infrastructure. They don't think the tunnel solution for interconnecting IPv4 isles would give users good performance 📉 So it's important to keep IPv4 connectivity and dual stack software support in End System software for a set timeframe, or the transition will never end 💀

Security Considerations 🔐

Security issues are not discussed in this memo. 💀 Not one word. No security chapter at all.

Authors' Addresses 📮

• Davide Salomoni 💖
  • INFN-CNAF
  • National Institute of Nuclear Physics - National Networking Center
  • V.le Ercolani, 8
  • 40138 Bologna - Italy
  • Phone: +39 51 6098-260
  • Fax: +39 51 6098 135
  • EMail: Salomoni@infn.it
• Cristina Vistoli 🦋
  • INFN-CNAF
  • National Institute of Nuclear Physics - National Networking Center
  • V.le Ercolani, 8
  • 40138 Bologna - Italy
  • Phone: +39 51 6098-260
  • Fax: +39 51 6098 135
  • EMail: Vistoli@infn.it
• Antonia Ghiselli 🌸
  • INFN-CNAF
  • National Institute of Nuclear Physics - National Networking Center
  • V.le Ercolani, 8
  • 40138 Bologna - Italy
  • Phone: +39 51 6098-267
  • Fax: +39 51 6098 135
  • EMail: Ghiselli@infn.it