As per Relevance of the word translation, we have this rfc below:
Network Working Group B.
Request for Comments: 1671
Category: Informational August 1994
IPng White Paper on Transition and Other
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This document was submitted to the IETF IPng area in response to
1550. Publication of this document does not imply acceptance by
IPng area of any ideas expressed within. Comments should
submitted to the big-internet@munnari.oz.au mailing list
This white paper outlines some general requirements for IPng
selected areas. It identifies the following requirements for
transition
A) Interworking at every stage and every layer
B) Header translation considered
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
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
packets to carry a trace of the type of transaction involved as
as of their source and destination
Transition and
It is clear that the transition will take years and that every
will have to decide its own staged transition plan. Only the
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 (
more) of activity in the Internet and in all private networks
the Internet suite will be strongly affected by the process of
deployment. User sites will look at the decision whether to
from IPv4 in the same way as they have looked in the past at
of programming language or operating system. It may not be a
conclusion that what they change to is IPng. Their main concern
be to minimise the cost of the change and the risk of
production
This concern immediately defines strong constraints on the model
transition and deployment of IPng. Some of these constraints
listed below, with a short explanation of each one
Terminology: an "IPv4 host" is a host that runs exactly what it
today, with no maintenance releases and no configuration changes.
"IPng host" is a host that has a new version of IP, and has
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
release dates. Users will go on running their old equipment
software. Therefore, any combination of IPv4 and IPng hosts
routers must be able to interwork (i.e., participate in UDP and
sessions). An IPv4 packet must be able to find its way from any IPv
host, to any other IPv4 or IPng host, or vice versa, through
mixture of IPv4 and IPng routers, with no (zero, null)
to the IPv4 hosts. IPv4 routers must need no modifications
interwork with IPng routers. Additionally, an application
which is "aware" of IPv4 but still "unaware" of IPng must be able
run on a computer system which is running IPv4, but
with an IPng host. For example an old PC in Europe should be able
access a NIC server in the USA, even if the NIC server is
IPng and the transatlantic routing mechanisms are only
converted. Or a Class C network in one department of a
should retain full access to corporate servers which are
IPng, even though nothing whatever has been changed inside the
C network
(This does NOT require an IPv4-only application to run on an
host; thus we accept that some hosts cannot be upgraded until
their applications are IPng-compatible. In other words we accept
the API may change to some extent. However, even this relaxation
debatable and some vendors may want to strictly preserve the IPv4
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
dynamic header translation between IPv4 and IPng packets will
almost insurmountable practical difficulties
B1) It is taken for granted for the purposes of this paper
IPng functionality will be a superset of IPv4 functionality
However, successful translation between protocols
that the functionalities of the two protocols which are to
translated are effectively identical. To achieve this
applications will need to know when they are interworking
via the IPng API and a translator somewhere in the network
with an IPv4 host, so as to use only IPv4 functionality.
is an unrealistic constraint
B2) Administration of translators will be quite impracticable
large sites, unless the translation mechanism is
blind and automatic. Specifically, any translation
that requires special tags to be maintained manually for
host in tables (such as DNS tables or router tables)
indicate the need for translation will be impossible
administer. On a site with thousands of hosts running
versions and releases of several operating systems,
move forwards and even backwards between software releases
such a way that continuously tracking the required state
such tags will be impossible. Multiplied across the
Internet, this will lead to chaos, complex failure modes,
difficult diagnosis. In particular, it will make
constraint of paragraph B1) impossible to respect
In practice, the knowledge that translation is needed
never leak out of the site concerned if chaos is to
avoided, and yet without such knowledge applications
limit themselves to IPv4 functionality when necessary
To avoid confusion, note that header translation, as discussed here
is not the same thing as address translation (NAT). This paper
not discuss NAT
This paper does not tackle performance issues in detail, but
another disadvantage of translation is the consequent overhead
C) Coexistence
The Internet infrastructure (whether global or private) must
coexistence of IPv4 and IPng in the same routers and on the
Carpenter [Page 3]
RFC 1671 IPng White Paper on Transition, etc. August 1994
physical paths
This is a necessity, in order that the network infrastructure can
updated to IPng without requiring hosts to be updated in lock
and without requiring translators
Note that this requirement does NOT impose a decision about a
or separate (ships-in-the-night) approach to routing. Nor does
exclude encapsulation as a coexistence mechanism
D) IPv4 to IPng address mapping
Human beings will have to understand what is happening
transition. Although auto-configuration of IPng addresses may be
desirable end point, management of the transition will be
simplified if there is an optional simple mapping, on a given site
between IPv4 and IPng addresses
Therefore, the IPng address space should include a mapping for IPv
addresses, such that (if a site or service provider wants to do this
the IPv4 address of a system can be transformed mechanically into
IPng address, most likely by adding a prefix. The prefix does
have to be the same for every site; it is likely to be at
service-provider specific
This does not imply that such address mapping will be used
dynamic translation (although it could be) or to embed IPv4
within IPng routing (although it could be). Its main purpose is
simplify transition planning for network operators
By the way, this requirement does not actually assume that IPv
addresses are globally unique
Neither does it help much in setting up the relationship, if any
between IPv4 and IPng routing domains and hierarchies. There is
reason to suppose these will be in 1:1 correspondence
E) Dual stack hosts
Stepwise transition without translation is hard to imagine unless
large proportion of hosts are simultaneously capable of running
and IPv4. If A needs to talk to B (an IPng host) and to C (an IPv
host) then either A or B must be able to run both IPv4 and IPng.
other words, all hosts running IPng must still be able to run IPv4.
IPng-only hosts are not allowed during transition
This requirement does not imply that IPng hosts really have
completely separate IP implementations (dual stacks and dual APIs),
Carpenter [Page 4]
RFC 1671 IPng White Paper on Transition, etc. August 1994
but just that they behave as if they did. It is compatible
encapsulation (i.e., one of the two stacks encapsulates packets
the other).
Obviously, management of dual stack hosts will be simplified by
address mapping just mentioned. Only the site prefix has to
configured (manually or dynamically) in addition to the IPv4 address
In a dual stack host the IPng API and the IPv4 API will be
distinguishable even if they are implemented as a single entity
Applications will know from the API whether they are using IPng
IPv4.
F) DNS
The dual stack requirement implies that DNS has to reply with both
IPv4 and IPng address for IPng hosts, or with a single reply
encodes both
If a host is attributed an IPng address in DNS, but is not
running IPng yet, it will appear as a black hole in IPng space -
the next point
G) Smart dual-stack code
The dual-stack code may get two addresses back from DNS; which
it use? During the many years of transition the Internet
contain black holes. For example, somewhere on the way from IPng
A to IPng host B there will sometimes (unpredictably) be IPv4-
routers which discard IPng packets. Also, the state of the DNS
not necessarily correspond to reality. A host for which DNS claims
know an IPng address may in fact not be running IPng at a
moment; thus an IPng packet to that host will be discarded
delivery. Knowing that a host has both IPv4 and IPng addresses
no information about black holes. A solution to this must be
and it must not depend on manually maintained information. (If
is not solved, the dual stack approach is no better than the
translation approach.)
H) Smart management tools
A whole set of management tools is going to be needed during
transition. Why is my IPng route different from my IPv4 route?
there is translation, where does it happen? Where are the
holes? (Cosmologists would like the same tool :-) Is that host
IPng-capable today?...
Carpenter [Page 5]
RFC 1671 IPng White Paper on Transition, etc. August 1994
Multicasts high and
It is taken for granted that multicast applications must be
by IPng. One obvious architectural rule is that no multicast
should ever travel twice over the same wire, whether it is a LAN
WAN wire. Failure to observe this would mean that the maximum
of simultaneous multicast transactions would be halved
A negative feature of IPv4 on LANs is the cavalier use of
broadcast packets by protcols such as ARP (and various non-
copycats). On large LANs this leads to a number of
consequences (often caused by poor products or poor users, not by
protcol design itself). The obvious architectural rule is
physical broadcast should be replaced by unicast (or at worst
multicast) whenever possible
The networking industry is investing heavily in ATM. No IPng
will be plausible (in the sense of gaining management approval
unless it is "ATM compatible", i.e., there is a clear model of how
will run over an ATM network. Although a fully detailed document
as RFC 1577 is not needed immediately, it must be shown that
basic model works
Similar remarks could be made about X.25, Frame Relay, SMDS etc.
ATM is the case with the highest management hype ratio today
Policy routing and
Unfortunately, this cannot be ignored, however much one would
to. Funding agencies want traffic to flow over the lines funded
carry it, and they want to know afterwards how much traffic
was. Accounting information can also be used for network
and for back-charging
It is therefore necessary that IPng and its routing procedures
traffic to be routed in a way that depends on its source
destination in detail. (As an example, traffic from the
department of MIT might be required to travel a different route
CERN than traffic from any other department.)
A simple approach to this requirement is to insist that IPng
support provider-based addressing and routing
Accounting of traffic is required at the same level of detail (
more, for example how much of the traffic is ftp and how much
www?).
Carpenter [Page 6]
RFC 1671 IPng White Paper on Transition, etc. August 1994
Both of these requirements will cost time or money and may
more than just the IP layer, but IPng should not duck them
Security
Corporate network operators, and campus network operators who
been hacked a few times, take this more seriously than many
experts. Indeed many corporate network operators would see
security as a more compelling argument for transition to IPng
anything else
Since IPng will presumably be a datagram protocol, limiting what
be done in terms of end-to-end security, IPng must allow
effective firewalls in routers than IPv4. In particular
traffic barring based on source and destination addresses and
of transaction is needed
It seems likely that the same features needed to allow policy
and detailed accounting would be needed for improved
security. It is outside the scope of this document to discuss
features in detail, but it seems unlikely that they are limited
implementation details in the border routers. Packets will have
carry some authenticated trace of the (source, destination
transaction) triplet in order to check for unwanted traffic, to
policy-based source routing, and/or to allow detailed accounting
Presumably any IPng will carry source and destination identifiers
some format in every packet, but identifying the type of transaction
or even the individual transaction, is an extra requirement
Disclaimer and
This is a personal view and does not necessarily represent that of
employer
CERN has been through three network transitions in recent years (IPv
renumbering managed by John Gamble, AppleTalk Phase I to Phase
transition managed by Mike Gerard, and DECnet Phase IV to DECnet/
routing transition managed by Denise Heagerty). I could not
written this document without having learnt from them. I have
benefitted greatly from discussions with or the writings of
people, especially various members of the IPng Directorate.
Directorate members gave comments that helped clarify this paper,
did Bruce L Hutfless of Boeing. However the opinions are mine
are not shared by all Directorate members
Carpenter [Page 7]
RFC 1671 IPng White Paper on Transition, etc. August 1994
Author's
Brian E.
Group Leader, Communications
Computing and Networks
European Laboratory for Particle
1211 Geneva 23,
Phone: +41 22 767-4967
Fax: +41 22 767-7155
Telex: 419000 cer
EMail: brian@dxcoms.cern.
Carpenter [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
