rfc1671.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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 [e-mail] 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 REQUIRES
   dynamic header translation between IPv4 and IPng packets will create
   almost insurmountable practical difficulties:


     B1) It is taken for granted for the purposes of this paper that
         IPng functionality will be a superset of IPv4 functionality.
         However, successful translation between protocols requires
         that the functionalities of the two protocols which are to be
         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. This
         is an unrealistic constraint.

     B2) Administration of translators will be quite impracticable for
         large sites, unless the translation mechanism is completely
         blind and automatic. Specifically, any translation mechanism
         that requires special tags to be maintained manually for each
         host in tables (such as DNS tables or router tables) to
         indicate the need for translation will be impossible to
         administer. On a site with thousands of hosts running many
         versions and releases of several operating systems, hosts
         move forwards and even backwards between software releases in
         such a way that continuously tracking the required state of
         such tags will be impossible. Multiplied across the whole
         Internet, this will lead to chaos, complex failure modes, and
         difficult diagnosis. In particular, it will make the
         constraint of paragraph B1) impossible to respect.

         In practice, the knowledge that translation is needed should
         never leak out of the site concerned if chaos is to be
         avoided, and yet without such knowledge applications cannot
         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 does
   not discuss NAT.

   This paper does not tackle performance issues in detail, but clearly
   another disadvantage of translation is the consequent overhead.

   C) Coexistence.

   The Internet infrastructure (whether global or private) must allow
   coexistence of IPv4 and IPng in the same routers and on the same



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 be
   updated to IPng without requiring hosts to be updated in lock step
   and without requiring translators.

   Note that this requirement does NOT impose a decision about a common
   or separate (ships-in-the-night) approach to routing.  Nor does it
   exclude encapsulation as a coexistence mechanism.

   D) IPv4 to IPng address mapping.

   Human beings will have to understand what is happening during
   transition. Although auto-configuration of IPng addresses may be a
   desirable end point, management of the transition will be greatly
   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 IPv4
   addresses, such that (if a site or service provider wants to do this)
   the IPv4 address of a system can be transformed mechanically into its
   IPng address, most likely by adding a prefix.  The prefix does not
   have to be the same for every site; it is likely to be at least
   service-provider specific.

   This does not imply that such address mapping will be used for
   dynamic translation (although it could be) or to embed IPv4 routing
   within IPng routing (although it could be). Its main purpose is to
   simplify transition planning for network operators.

   By the way, this requirement does not actually assume that IPv4
   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 no
   reason to suppose these will be in 1:1 correspondence.

   E) Dual stack hosts.

   Stepwise transition without translation is hard to imagine unless a
   large proportion of hosts are simultaneously capable of running IPng
   and IPv4.  If A needs to talk to B (an IPng host) and to C (an IPv4
   host) then either A or B must be able to run both IPv4 and IPng. In
   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 two
   completely separate IP implementations (dual stacks and dual APIs),



Carpenter                                                       [Page 4]