IPng White Paper on Transition and Other Considerations
RFC 1671
Document | Type |
RFC - Informational
(August 1994; No errata)
Was draft-carpenter-ipng-whitepaper (individual)
|
|
---|---|---|---|
Author | Brian Carpenter | ||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 1671 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group B. Carpenter Request for Comments: 1671 CERN Category: Informational August 1994 IPng White Paper on Transition and Other Considerations 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. Abstract 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. Summary This white paper outlines some general requirements for IPng in selected areas. It identifies the following requirements for stepwise transition: A) Interworking at every stage and every layer. B) Header translation considered harmful C) Coexistence. D) IPv4 to IPng address mapping. E) Dual stack hosts. F) DNS. G) Smart dual-stack code. H) Smart management tools. Some remarks about phsysical and logical multicast follow, and it is suggested that a model of how IPng will run over ATM is needed. Finally, the paper suggests that the requirements for policy routing, accounting, and security firewalls will in turn require all IPng packets to carry a trace of the type of transaction involved as well as of their source and destination. Transition and deployment It is clear that the transition will take years and that every site will have to decide its own staged transition plan. Only the very smallest sites could envisage a single step ("flag day") transition, Carpenter [Page 1] RFC 1671 IPng White Paper on Transition, etc. August 1994 presumably under pressure from their Internet service providers. Furthermore, once the IPng decision is taken, the next decade (or more) of activity in the Internet and in all private networks using the Internet suite will be strongly affected by the process of IPng deployment. User sites will look at the decision whether to change from IPv4 in the same way as they have looked in the past at changes of programming language or operating system. It may not be a foregone conclusion that what they change to is IPng. Their main concern will be to minimise the cost of the change and the risk of lost production. This concern immediately defines strong constraints on the model for transition and deployment of IPng. Some of these constraints are listed below, with a short explanation of each one. Terminology: an "IPv4 host" is a host that runs exactly what it runs today, with no maintenance releases and no configuration changes. An "IPng host" is a host that has a new version of IP, and has been reconfigured. Similarly for routers. A) Interworking at every stage and every layer. This is the major constraint. Vendors of computer systems, routers, and applications software will certainly not coordinate their product release dates. Users will go on running their old equipment and software. Therefore, any combination of IPv4 and IPng hosts and routers must be able to interwork (i.e., participate in UDP and TCP sessions). An IPv4 packet must be able to find its way from any IPv4 host, to any other IPv4 or IPng host, or vice versa, through a mixture of IPv4 and IPng routers, with no (zero, null) modifications to the IPv4 hosts. IPv4 routers must need no modifications to interwork with IPng routers. Additionally, an application package which is "aware" of IPv4 but still "unaware" of IPng must be able to run on a computer system which is running IPv4, but communicating with an IPng host. For example an old PC in Europe should be able to access a NIC server in the USA, even if the NIC server is running IPng and the transatlantic routing mechanisms are only partly converted. Or a Class C network in one department of a company should retain full access to corporate servers which are running IPng, even though nothing whatever has been changed inside the Class C network. (This does NOT require an IPv4-only application to run on an IPng host; thus we accept that some hosts cannot be upgraded until all their applications are IPng-compatible. In other words we accept that the API may change to some extent. However, even this relaxation is debatable and some vendors may want to strictly preserve the IPv4 API on an IPng host.) Carpenter [Page 2] RFC 1671 IPng White Paper on Transition, etc. August 1994 B) Header translation considered harmful. This author believes that any transition scenario which REQUIRESShow full document text