summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1676.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc1676.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc1676.txt')
-rw-r--r--doc/rfc/rfc1676.txt227
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]
+