home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1676.txt < prev    next >
Text File  |  1996-05-07  |  9KB  |  116 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        A. Ghiselli Request for Comments: 1676                                   D. Salomoni Category: Informational                                       C. Vistoli                                                                INFN/CNAF                                                              August 1994 
  8.  
  9.                       INFN Requirements for an IPng 
  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. Overview 
  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. Abstract 
  20.  
  21.    This white paper is sent by INFN network team, the Italian National    Institute for nuclear physics, whose network, named INFNet, is a    nationwide network founded to provide the access to existing national    and international HEP laboratory and to facilitate communications    between the researchers.  With this paper we would like to emphasize    the key points that we would to consider if charged with IPng plan.    We do not really expect to add original items to the selection, but    we think that it could be useful to submit the opinions and ideas    that come from our network experience. 
  22.  
  23. 1. General Requirements 
  24.  
  25.    The problems that are to be solved in IP internet are mainly three: 
  26.  
  27.       1. address exhaustion 
  28.  
  29.       2. flat address space 
  30.  
  31.       3. routing efficiency, flexibility and capacity. 
  32.  
  33.    The aim of IPng study should be to define a plan that solves all    these problems as a whole and not each of them separately. 
  34.  
  35.    The general requirements that we underline for this transition are: 
  36.  
  37.  
  38.  
  39. Ghiselli, Salomoni & Vistoli                                    [Page 1] 
  40.  RFC 1676             INFN Requirements for an IPng           August 1994 
  41.  
  42.        - transparency to the final user: user applications should not be         influenced. 
  43.  
  44.       - flexibility: Simplify the suitability to new communication         technology and to topology changes due to new services provided         or to different users needs. 
  45.  
  46. 2. Application and Transport Level 
  47.  
  48.    Starting from the top of the OSI model, we think that the users    applications should not be influenced by the migration plan.  It    means that the TCP (the transport layer) must maintain the same    interfaces and services to the upper layers.  Anyway, it is also    necessary to foresee the use of a different transport services. The    possibility to use different transport should be offered to the    applications.  Therefore a transport selector field is needed. 
  49.  
  50. 3. Network layer: service and address 
  51.  
  52.    We assume that the network layer must continue to provide the same    datagram service as IP does.  CLNS could be a solution and a reliable    starting point for the IPng.  The main advantage is that this    solution has been profitable tested and it is already available on    many systems.  It is not, of course, deployed as widely as IPv4 is,    since it is a newer technology, but it is widely configured and and    there is already operational experience.  The corresponding address,    the NSAP, is 20 bytes long.  It is long enough to scale the future    data network environment.  Its hierarchical format can be organized    in a really flexible way, satisfying hierarchical routing and policy    based routing needs and simplifying the distributed administration    and management.  A lot of work has been already done in the majority    of the countries in order to define NSAP formats satisfying both the    requirements of administrative delegation and routing performances. 
  53.  
  54. 4. Routing protocols 
  55.  
  56.    We don't consider the decision about the routing protocol to be    adopted for the IPng to be fundamental.  Even if this choice is very    important to obtain good performances, the routing protocols can be    changed or improved at any time, because there is no influence into    the End Systems configuration.  Relationships between NSAP    aggregation, hierarchical topology and hierarchical routing algorithm    must be taken into account in IPng plan.  These issues could improve    administration and topological flexibility of the IPng and solve the    flat problem of the IPv4.  The IPng routing protocols should include    policy-based features.  The IPv4 network topology is very complex and    it will continue to enlarge during the transition. It would be very    difficult or impossible to manage it without the "policy" tools.  The 
  57.  
  58.  
  59.  
  60. Ghiselli, Salomoni & Vistoli                                    [Page 2] 
  61.  RFC 1676             INFN Requirements for an IPng           August 1994 
  62.  
  63.     multicast capability as well as any other new features that fit in a    datagram network should be supported.  Regarding the Source Routing    feature, since we think that it deeply modifies the aim and the    "philosophy" of a connectionless network and it also introduces an    heavy complication in the end nodes and routers software, we don't    consider it a major issue. 
  64.  
  65. 5. Layer 2 or communication infrastructure media support. 
  66.  
  67.    This is an open field, rapidly changing, then it must be left open to    any evolution. What it should be recommended is to be compatible with    the above network layer. 
  68.  
  69. 6. Transition and Deployment 
  70.  
  71.    We faced the problem of the transition of the DECNET global network    to DECNET/OSI over CLNS. This activity is now proceeding to the last    step and based on this experience we would underline some points that    we found important during the transition deployment.  The transitions    must be planned and developed in a distributed way.  This means that    every organization should have the possibility to plan and start    their network migration without loosing connectivity with the    existing global internet.  Of course, the compatibility with the IPv4    world must be maintained, this mean that a new generation system must    interwork with both the IPv4 and IPng nodes, using the same    applications. 
  72.  
  73.    However, it is important to define a deadline for the backward    compatibility in order to avoid huge software maintenance in the user    systems and a "multi-topology" management.  We think that a dual    stack approach could simplify very much the transition, whereas a    translation mechanism would need a widely and deep coordination in    order to maintain the global connectivity during the transition    period.  The dual stack is simpler and could be easily developed, but    it is important to push in order to have pure IPng with global    connectivity as soon as possible; this could happen when there are no    more "IPv4 only" hosts. 
  74.  
  75.    Indeed, the drawback of the dual stack configuration is that you    continue to suffer for the IPv4 address space exhaustion and that you    must continue to support the IPv4 routing protocols and    infrastructure.  We don't think that the tunnel solution to    interconnect the IPv4 isle could give good performances to the users.    Then, it is important to maintain the IPv4 connectivity and the dual    stack software support in the End System software in a determined    timeframe, or the transition will never end. 
  76.  
  77.  
  78.  
  79.  
  80.  
  81. Ghiselli, Salomoni & Vistoli                                    [Page 3] 
  82.  RFC 1676             INFN Requirements for an IPng           August 1994 
  83.  
  84.  Security Considerations 
  85.  
  86.    Security issues are not discussed in this memo. 
  87.  
  88. Authors' Addresses 
  89.  
  90.    Davide Salomoni    INFN-CNAF    National Institute of Nuclear Physics - National Networking Center    V.le Ercolani, 8    40138 Bologna - Italy 
  91.  
  92.    Phone:  +39 51 6098-260    Fax:    +39 51 6098 135    EMail: Salomoni@infn.it 
  93.  
  94.     Cristina Vistoli    INFN-CNAF    National Institute of Nuclear Physics - National Networking Center    V.le Ercolani, 8    40138 Bologna - Italy 
  95.  
  96.    Phone:  +39 51 6098-260    Fax:    +39 51 6098 135    EMail: Vistoli@infn.it 
  97.  
  98.     Antonia Ghiselli    INFN-CNAF    National Institute of Nuclear Physics - National Networking Center    V.le Ercolani, 8    40138 Bologna - Italy 
  99.  
  100.    Phone:  +39 51 6098-267    Fax:    +39 51 6098 135    EMail: Ghiselli@infn.it 
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  Ghiselli, Salomoni & Vistoli                                    [Page 4] 
  115.  
  116.