Movatterモバイル変換

Network Working Group                                        A. GhiselliRequest for Comments: 1676                                   D. SalomoniCategory: Informational                                       C. Vistoli                                                               INFN/CNAF                                                             August 1994INFN Requirements for an IPngStatus 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.Overview   This document was submitted to the IETF IPng area in response toRFC1550.  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.Abstract   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.1. General Requirements   The problems that are to be solved in IP internet are mainly three:      1. address exhaustion      2. flat address space      3. routing efficiency, flexibility and capacity.   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.   The general requirements that we underline for this transition are:Ghiselli, Salomoni & Vistoli                                    [Page 1]

RFC 1676             INFN Requirements for an IPng           August 1994      - transparency to the final user: user applications should not be        influenced.      - flexibility: Simplify the suitability to new communication        technology and to topology changes due to new services provided        or to different users needs.2. Application and Transport Level   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.3. Network layer: service and address   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.4. Routing protocols   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.  TheGhiselli, Salomoni & Vistoli                                    [Page 2]

RFC 1676             INFN Requirements for an IPng           August 1994   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.5. Layer 2 or communication infrastructure media support.   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.6. Transition and Deployment   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.   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.   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.Ghiselli, Salomoni & Vistoli                                    [Page 3]

RFC 1676             INFN Requirements for an IPng           August 1994Security Considerations   Security issues are not discussed in this memo.Authors' Addresses   Davide Salomoni   INFN-CNAF   National Institute of Nuclear Physics - National Networking Center   V.le Ercolani, 8   40138 Bologna - Italy   Phone:  +39 51 6098-260   Fax:    +39 51 6098 135   EMail: Salomoni@infn.it   Cristina Vistoli   INFN-CNAF   National Institute of Nuclear Physics - National Networking Center   V.le Ercolani, 8   40138 Bologna - Italy   Phone:  +39 51 6098-260   Fax:    +39 51 6098 135   EMail: Vistoli@infn.it   Antonia Ghiselli   INFN-CNAF   National Institute of Nuclear Physics - National Networking Center   V.le Ercolani, 8   40138 Bologna - Italy   Phone:  +39 51 6098-267   Fax:    +39 51 6098 135   EMail: Ghiselli@infn.itGhiselli, Salomoni & Vistoli                                    [Page 4]