INFN Requirements for an IPng (RFC1676)
Original Publication Date: 1994-Aug-01
Included in the Prior Art Database: 2019-Feb-12
Internet Society Requests For Comment (RFCs)
A. Ghiselli: AUTHOR [+2]
With this paper we would like to emphasize the key points that we would to consider if charged with IPng plan. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
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.
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 email@example.com 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 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 c...