From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1670.txt | 171 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 171 insertions(+) create mode 100644 doc/rfc/rfc1670.txt (limited to 'doc/rfc/rfc1670.txt') diff --git a/doc/rfc/rfc1670.txt b/doc/rfc/rfc1670.txt new file mode 100644 index 0000000..54bbe78 --- /dev/null +++ b/doc/rfc/rfc1670.txt @@ -0,0 +1,171 @@ + + + + + + +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. + + + + + +Heagerty [Page 1] + +RFC 1670 Input to IPng Engineering Considerations August 1994 + + + 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. + + + + +Heagerty [Page 2] + +RFC 1670 Input to IPng Engineering Considerations August 1994 + + + 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 + + + + + + + + + + + + + + + + + + + + + + + +Heagerty [Page 3] + -- cgit v1.2.3