RFCs in HTML Format


RFC 1676

                     INFN Requirements for an IPng


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. The Ghiselli, 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 1994 Security Considerations Security issues are not discussed in this memo.



Back to RFC index

 

Associates:

 



Sponsered-Sites:

Register domain name and transfer | Cheap webhosting service | Domain name registration

 

 

""