1 files changed, 227 insertions, 0 deletions
diff --git a/doc/rfc/rfc1676.txt b/doc/rfc/rfc1676.txt
new file mode 100644
index 0000000..2bb61b9
--- /dev/null
+++ b/doc/rfc/rfc1676.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group                                        A. Ghiselli
+Request for Comments: 1676                                   D. Salomoni
+Category: Informational                                       C. Vistoli
+                                                               INFN/CNAF
+                                                             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.
+
+Overview
+
+   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.
+
+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.  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.
+
+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.it
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ghiselli, Salomoni & Vistoli                                    [Page 4]
+