The RFC Archive
 The RFC Archive   RFC 1670   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 1670

Input to IPng Engineering Considerations

Last modified on Friday, August 5th, 1994

Permanent link to RFC 1670
Search GitHub Wiki for RFC 1670
Show other RFCs mentioning RFC 1670







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 top


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 top

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 top

Input to IPng Engineering Considerations RFC TOTAL SIZE: 5350 bytes PUBLICATION DATE: Friday, August 5th, 1994 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 1670: The IETF Trust, Friday, August 5th, 1994
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement