From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1676.txt | 227 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 227 insertions(+) create mode 100644 doc/rfc/rfc1676.txt (limited to 'doc/rfc/rfc1676.txt') 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] + -- cgit v1.2.3