Browse Prior Art Database

IPng White Paper on Transition and Other Considerations (RFC1671)

IP.com Disclosure Number: IPCOM000002508D
Original Publication Date: 1994-Aug-01
Included in the Prior Art Database: 2000-Sep-12
Document File: 7 page(s) / 16K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

B. Carpenter: AUTHOR

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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 17% of the total text.

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,

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...