RFC 1671 (rfc1671) - Page 2 of 8
IPng White Paper on Transition and Other Considerations
Alternative Format: Original Text Document
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