Input to IPng Engineering Considerations
Breaking IPng decisions into manageable parts, informed by DECnet transition experience.
Heagerty, D., "Input to IPng Engineering Considerations", RFC 1670, DOI 10.17487/RFC1670, August 1994, <https://www.rfc-editor.org/info/rfc1670>.
@misc{rfc1670,
series = {Request for Comments},
number = 1670,
howpublished = {RFC 1670},
publisher = {RFC Editor},
doi = {10.17487/RFC1670},
url = {https://www.rfc-editor.org/info/rfc1670},
author = {D. Heagerty},
title = {{Input to IPng Engineering Considerations}},
pagetotal = 3,
year = 1994,
month = aug,
} RFC text
Contents
Network Working Group D. Heagerty
Request for Comments: 1670 CERN
Category: Informational August 1994
Input to IPng Engineering Considerations
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be
submitted to the big-internet@munnari.oz.au mailing list.
Summary
This white paper expresses some personal opinions on IPng engineering
considerations, based on experience with DECnet Phase V transition.
It suggests breaking down the IPng decisions and transition tasks
into smaller parts so they can be tackled early by the relevant
experts.
Timescales
In order to allow key decisions to be taken early, I would like to
see IPng decisions and timescales broken down into into smaller
parts, for example:
- address structure and allocation mechanism
- name service changes
- host software and programming interface changes
- routing protocol changes
Although interrelated, not all details need to be defined by the same
date. Identify which decisions will be hard to change and which can
be allowed to evolve. All changes should be worked on in parallel,
but the above list indicates a feeling for urgency of a decision.
Our experience has been that administrative changes (as may be
required for addressing changes) need the greatest elapse time for
implementation, whereas routing protocol changes need the least.
I would like to see an early decision on address structure and enough
information for service managers to start planning their transition.
Some hosts will never be upgraded and will need to be phased out or
configured with reduced connectivity. A lead time of 10 years (or
more) will help to take good long term technical decisions and ease
financial and organisational constraints.
Transition and deployment
Transition requires intimate knowledge of the environment (financial,
political as well as technical). The task needs to be broken down so
that service managers close to their clients can take decisions and
make them happen.
Let the service managers adapt the solutions for their environment by
providing them with a transition toolbox and scenarios of their uses
based on real examples. Clearly state the merits and limitations of
different transition strategies.
Provide for transition autonomy. Let systems and sites transition at
different times, as convenient for them.
Identify what software needs to be changed and keep an up-to-date
list.
Identify what is essential to have in place so that service managers
can transition at their own pace.
Allow for a feedback loop to improve software based on experience.
Configuration, Administration, Operation
We run IP on a wide range of equipment and operating systems. 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 obtain data from the system (e.g., contact information
for owner, location and name of system). We also need an easy way to
update DNS.
In our environment systems are regularly moved between buildings and
we therefore find the tight coupling of IP address to physical subnet
over restrictive. Automatic configuration could help overcome this.
We would like to efficiently load balance users of various IP based
services (e.g., telnet, ftp, locally written applications) across a
number of systems.
The ability to break down addresses and routing into several levels
of hierarchy is important to allow the delegation of network
management into subdomains. As the network grows so does the desire
to increase the number of levels of hierarchy.
Disclaimer and acknowledgments
This is a personal view and does not necessarily represent that of my
employer. I have benefited 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.
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
AI ELI5
On this page
§1Breaking Down the Challenge
RFC 1670 is a white paper from Denise Heagerty at CERN, written in response to the IPng solicitation. Heagerty draws on experience managing the transition from DECnet Phase IV to Phase V across a large physics research network. The core argument is simple: treat IPng not as one massive decision, but as a collection of related but separable choices.
The RFC identifies four key areas that need decisions: address structure and allocation, name service changes, host software and programming interfaces, and routing protocol changes. While all are interconnected, they do not need the same deadline.
Heagerty says instead of making one big decision about the Internet, split it into four smaller decisions: addresses, naming, software on computers, and routing.
§2Timescales and Dependencies
The RFC argues that administrative decisions, especially those affecting address assignment, need the most time. Organizations must plan, budgeted changes, deploy new systems, and retire old ones. Ten years or more of lead time is realistic. Routing protocol changes, by contrast, can happen quickly because routers update without affecting the hosts they serve.
The RFC recommends early commitment on address structure and enough detail for service managers to start planning. Hosts that cannot be upgraded should be phased out or configured with reduced connectivity, a plan that takes years.
Changing how addresses work takes the longest because so many physical things have to change. Routing is faster because it just means updating routers.
§3Transition and Local Control
The RFC stresses that transition must respect local autonomy. Service managers close to their users understand the constraints (financial, political and technical) in their own environments. Provide them with a transition toolbox, scenarios and examples so they can adapt solutions locally.
Systems and sites should be able to transition at different times. A feedback loop based on real-world experience will improve software. Identify what software must change and keep the list current.
Let each organization change to the new Internet on their own schedule, with tools and examples to help them decide what to do.
§4Administration and Configuration
CERN runs IP on diverse equipment and operating systems. The RFC notes needs for efficient configuration: a way to send each system its IP parameters (address, default router, name servers) and to collect data from systems (contact, location, name). Automatic configuration would ease the tight coupling of addresses to physical subnets.
As the network grows, hierarchical address and routing delegation becomes critical. Breaking addresses into multiple hierarchy levels lets management devolve into subdomains.
Networks need easy ways to tell a computer its address and find out where it is, and a way to split management into smaller regions.