INFN Requirements for an IPng
RFC 1676

Document Type RFC - Informational (August 1994; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1676 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        A. Ghiselli
Request for Comments: 1676                                   D. Salomoni
Category: Informational                                       C. Vistoli
                                                             August 1994

                     INFN Requirements for an IPng

Status 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.


   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 mailing list.


   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

      - 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
Show full document text