home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1670.txt < prev    next >
Text File  |  1996-05-07  |  6KB  |  107 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        D. Heagerty Request for Comments: 1670                                          CERN Category: Informational                                      August 1994 
  8.  
  9.                  Input to IPng Engineering Considerations 
  10.  
  11. Status of this Memo 
  12.  
  13.    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. 
  14.  
  15. Abstract 
  16.  
  17.    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. 
  18.  
  19. Summary 
  20.  
  21.    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. 
  22.  
  23. Timescales 
  24.  
  25.    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: 
  26.  
  27.     - address structure and allocation mechanism     - name service changes     - host software and programming interface changes     - routing protocol changes 
  28.  
  29.    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. 
  30.  
  31.  
  32.  
  33.  
  34.  
  35. Heagerty                                                        [Page 1] 
  36.  RFC 1670        Input to IPng Engineering Considerations     August 1994 
  37.  
  38.     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. 
  39.  
  40. Transition and deployment 
  41.  
  42.    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. 
  43.  
  44.    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. 
  45.  
  46.    Provide for transition autonomy. Let systems and sites transition at    different times, as convenient for them. 
  47.  
  48.    Identify what software needs to be changed and keep an up-to-date    list. 
  49.  
  50.    Identify what is essential to have in place so that service managers    can transition at their own pace. 
  51.  
  52.    Allow for a feedback loop to improve software based on experience. 
  53.  
  54. Configuration, Administration, Operation 
  55.  
  56.    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. 
  57.  
  58.    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. 
  59.  
  60.    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. 
  61.  
  62.  
  63.  
  64.  Heagerty                                                        [Page 2] 
  65.  RFC 1670        Input to IPng Engineering Considerations     August 1994 
  66.  
  67.     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. 
  68.  
  69. Disclaimer and acknowledgments 
  70.  
  71.    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. 
  72.  
  73. Security Considerations 
  74.  
  75.    Security issues are not discussed in this memo. 
  76.  
  77. Author's Address 
  78.  
  79.    Denise Heagerty    Communications Systems Group    Computing and Networks Division    CERN    European Laboratory for Particle Physics    1211 Geneva 23, Switzerland 
  80.  
  81.    Phone:  +41 22 767-4975    Fax:    +41 22 767-7155    EMail: denise@dxcoms.cern.ch 
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105. Heagerty                                                        [Page 3] 
  106.  
  107.