RFC 1676 (rfc1676) - Page 2 of 4
INFN Requirements for an IPng
Alternative Format: Original Text Document
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