RFC 1670

RFC 1670: Input to IPng Engineering Considerations 💖

okay so this is RFC 1670 and it's giving "veteran who has been in the trenches" energy 🫶

• Number: RFC 1670
• Title: Input to IPng Engineering Considerations
• Author: D. Heagerty (Denise Heagerty), CERN 🎀
• Category: Informational
• Date: August 1994
• Obsoletes/Updates: the header doesn't list any RFCs it obsoletes or updates ✨

---

Status of this Memo 🌸

this memo is info for the Internet community, bestie 💅 it does not specify 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 accepted any of the ideas inside 🙈 comments should go to the big-internet@munnari.oz.au mailing list 💌

Summary 💅

this white paper shares some personal opinions on IPng engineering considerations, based on experience with the DECnet Phase V transition 🔥 the big idea is to break the IPng decisions and transition tasks into smaller parts, so the relevant experts can tackle them early 🧚

Timescales ⏰

so to let key decisions get made early, i really want to see IPng decisions and timescales broken down into smaller parts, like:

• address structure and allocation mechanism
• name service changes
• host software and programming interface changes
• routing protocol changes

these are all interrelated, but they don't all need to be defined by the same date 💖 figure out which decisions will be hard to change and which can be allowed to evolve. everything should be worked on in parallel, but the list above shows how urgent each decision is ✨ from my experience, administrative changes (like addressing changes) take the longest to implement, and routing protocol changes take the least time 🍓

i'd love an early decision on address structure, plus enough info for service managers to start planning their transition 🌈 some hosts will never be upgraded, so they'll need to be phased out or configured with reduced connectivity 💀 a lead time of 10 years (or more) helps with long term technical decisions and eases the financial and organisational constraints 👑

Transition and deployment 🦋

transition needs deep knowledge of the environment (financial, political, AND technical) 😭 the task needs to be split up so that service managers close to their clients can make decisions and make them happen 🫶

let the service managers adapt the solutions to their own environment by giving them a transition toolbox and scenarios based on real examples 🧰 clearly state the merits and limitations of each transition strategy 💜

provide for transition autonomy! let systems and sites transition at different times, whenever it's convenient for them 🌷

identify what software needs to be changed and keep an up-to-date list 📝

identify what's essential to have in place so service managers can transition at their own pace 🏃‍♀️

and allow for a feedback loop so software can improve based on experience 🔁✨

Configuration, Administration, Operation 🛠️

we run IP on a wide range of equipment and operating systems, so we need an easy way to (re-)configure all our IP capable systems 😩 the systems need to be sent their IP parameters (e.g., their address, address of their default router, address of their local name servers), and we need to get data back from the system (e.g., contact info for the owner, location and name of the system) 📬 we also need an easy way to update DNS 🌐

in our environment, systems get moved between buildings all the time, so the tight coupling of IP address to physical subnet feels way too restrictive 🙄 automatic configuration could help with that 🧚

we'd also love to efficiently load balance users of various IP based services (e.g., telnet, ftp, locally written applications) across a number of systems ⚖️

being able to break down addresses and routing into several levels of hierarchy matters a lot, because it lets network management be delegated into subdomains 🗂️ and as the network grows, so does the desire to add more levels of hierarchy 📈

Disclaimer and acknowledgments 🫶

this is a personal view and doesn't necessarily represent my employer's 💅 i've learned a ton from many transition discussions with my colleagues at CERN, other High Energy Physics DECnet managers, and Digital Equipment Corporation engineers 🙌

Security Considerations 🚨

⚠️ Security issues are not discussed in this memo. Not one word. 💀

Author's Address 📮

Denise Heagerty
Communications Systems Group
Computing and Networks Division
CERN
European Laboratory for Particle Physics
1211 Geneva 23, Switzerland

Phone:  +41 22 767-4975
Fax:    +41 22 767-7155
EMail: denise@dxcoms.cern.ch

that's the whole RFC, bestie 🌈✨💖