[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 draft-ietf-behave-v6v4-framework

behave                                                     F. Baker, Ed.
Internet-Draft                                             Cisco Systems
Intended status: Informational                          October 26, 2008
Expires: April 29, 2009


                  Framework for IPv4/IPv6 Translation
                  draft-baker-behave-v4v6-framework-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 29, 2009.

Abstract

   This note describes a framework for IPv4/IPv6 translation.  This is
   in the context of replacing NAT-PT, which was deprecated by RFC 4966,
   and to enable networks to have IPv4 and IPv6 coexist in a somewhat
   rational manner while transitioning to an IPv6 network.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].





Baker                    Expires April 29, 2009                 [Page 1]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Why translation? . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Translation objectives . . . . . . . . . . . . . . . . . .  6
     1.4.  Transition Plan  . . . . . . . . . . . . . . . . . . . . .  8
     1.5.  Expected uses of translation . . . . . . . . . . . . . . . 10
       1.5.1.  Connection of IPv4-only islands to an IPv6-only
               network  . . . . . . . . . . . . . . . . . . . . . . . 10
       1.5.2.  Connection of IPv6-only islands to an IPv4-only
               network  . . . . . . . . . . . . . . . . . . . . . . . 12
       1.5.3.  Connecting IPv4-only devices with IPv6-only devices  . 12
       1.5.4.  ISP-supported connections between IPv4-only
               networks and IPv6-only networks  . . . . . . . . . . . 12
   2.  Framework  . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     2.1.  Mapped Address Format  . . . . . . . . . . . . . . . . . . 14
     2.2.  Translation components . . . . . . . . . . . . . . . . . . 15
       2.2.1.  DNS Application Layer Gateway  . . . . . . . . . . . . 15
       2.2.2.  Stateless Translation - mapped addresses . . . . . . . 16
       2.2.3.  Stateful translation - unmapped IPv6 address . . . . . 16
       2.2.4.  Translation gateway technologies . . . . . . . . . . . 17
     2.3.  Translation in operation . . . . . . . . . . . . . . . . . 17
     2.4.  Unsolved problems  . . . . . . . . . . . . . . . . . . . . 17
   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 18
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 19
   Appendix A.  Address proposals . . . . . . . . . . . . . . . . . . 20
     A.1.  Well-known address formats . . . . . . . . . . . . . . . . 21
       A.1.1.  Benefits of a well-known address . . . . . . . . . . . 21
       A.1.2.  Issues in using a well-known address . . . . . . . . . 22
       A.1.3.  Configuration of a well-known address  . . . . . . . . 22
       A.1.4.  Applicability of a well-known address  . . . . . . . . 23
     A.2.  Network operator specified prefixes  . . . . . . . . . . . 24
       A.2.1.  The IVI prefix . . . . . . . . . . . . . . . . . . . . 24
       A.2.2.  Network operator specified /96 prefixes  . . . . . . . 27
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31
   Intellectual Property and Copyright Statements . . . . . . . . . . 33










Baker                    Expires April 29, 2009                 [Page 2]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


1.  Introduction

   This note describes a framework for IPv4/IPv6 translation.  This is
   in the context of replacing NAT-PT [RFC2766], which was deprecated by
   [RFC4966], and to enable networks to have IPv4 and IPv6 coexist in a
   somewhat rational manner while transitioning to an IPv6-only network.

   Deprecation of NAT-PT wasn't intended to say that NAT-PT was "bad",
   nor did the IETF think that deprecating the technology would stop
   people from using it.  As with the 1993 deprecation of the RIP
   routing protocol at the time the Internet was converting to CIDR, the
   point was to inform the community that NAT-PT had operational issues
   and was not considered a viable medium or long term strategy for
   either coexistence or transition.  The point was to encourage network
   operators to actually move in the direction of transition.

   [RFC4213] describes the IETF's view of the most sensible transition
   model.  The IETF recommends, in short, that network operators
   (transit providers, service providers, enterprise networks, small and
   medium business, SOHO and residential customers, and any other kind
   of network that may currently be using IPv4) obtain an IPv6 prefix,
   turn on IPv6 routing within their networks and between themselves and
   any peer, upstream, or downstream neighbors, enable it on their
   computers, and use it in normal processing.  This should be done
   while leaving IPv4 stable, until a point is reached that any
   communication that can be carried out could use either protocol
   equally well.  At that point, the economic justification for running
   both becomes debatable, and network operators can justifiably turn
   IPv4 off.  This process is comparable to that of [RFC4192], which
   describes how to renumber a network using the same address family
   without a flag day.  While running stably with the older system,
   deploy the new.  Use the coexistence period to work out such kinks as
   arise.  When the new is also running stably, shift production to it.
   When network and economic conditions warrant, remove the old, which
   is now no longer necessary.

   The question arises: what if that is infeasible due to the time
   available to deploy or other considerations?  What if the process of
   moving a network and its components or customers is starting too late
   for contract cycles to effect IPv6 turn-up on important parts at a
   point where it becomes uneconomical to deploy global IPv4 addresses
   in new services?  How does one continue to deploy new services
   without balkanizing the network?

   This set of documents describes translation as one of the tools
   networks might use to facilitate coexistence and ultimate transition.





Baker                    Expires April 29, 2009                 [Page 3]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


1.1.  Why translation?

   Besides dual stack deployment, there are two fundamental approaches
   one could take to interworking between IPv4 and IPv6: tunneling and
   translation.  One could - and in the 6NET we did - build an overlay
   network using the new protocol inside tunnels.  Various proposals
   take that model, including 6to4 [RFC3056], Teredo [RFC4380], ISATAP
   [RFC5214],and DS-Lite [I-D.durand-softwire-dual-stack-lite].  The
   advantage of doing so is that the new is enabled to work without
   disturbing the old protocol, providing connectivity between users of
   the new protocol.  There are two disadvantages to tunneling:

   o  operators of those networks are unable to offer services to users
      of the new architecture, and those users are unable to use the
      services of the underlying infrastructure - it is just bandwidth,
      and

   o  it doesn't enable new protocol users to communicate with old
      protocol users.

   As noted, in this work, we look at Internet Protocol translation as a
   transition strategy.  [RFC4864] forcefully makes the point that many
   of the reasons people use Network Address Translators are met as well
   by routing or protocol mechanisms that preserve the end to end
   addressability of the Internet.  What it did not consider is the case
   in which there is an ongoing requirement to communicate with IPv4
   systems, but configuring IPv4 routing is not in the network
   operator's view the most desirable strategy, or is infeasible due to
   a shortage of global address space.  Translation enables the client
   of a network, whether a transit network, an access network, or an
   edge network, to access the services of the network and communicate
   with other network users regardless of their protocol usage - within
   limits.  Like NAT-PT, IPv4/IPv6 translation under this rubric is not
   a long term support strategy, but it is a medium term coexistence
   strategy that can be used to facilitate a long term program of
   transition.

1.2.  Terminology

   The following terminology is used in this document and other
   documents related to it.

   Advertised IPv4 Prefix:  The IPv4 prefix, if any, subdivided into
      Mapped IPv4 Prefixes in the IPv6-only domain.  This is advertised
      in routing in the IPv4 domain to attract traffic intended for
      mapped IPv4 addresses in the IPv6-only domain.





Baker                    Expires April 29, 2009                 [Page 4]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


   Dual Stack impementation:  A Dual Stack implementation, in this
      context, comprises an enabled end system stack plus routing in the
      network.  It implies that two application instances are capable of
      communicating using either IPv4 or IPv6 - they have stacks, they
      have addresses, and they have any necessary network support
      including routing.

   IPv4-only:  An IPv4-only implementation, in this context, comprises
      an enabled end system stack plus routing in the network.  It
      implies that two application instances are capable of
      communicating using either IPv4 but not IPv6 - they have an IPv4
      stack, addresses, and network support including IPv4 routing and
      potentially IPv4/IPv4 translation, but some element is missing
      that prevents communication using IPv6.

   IPv6-only:  An IPv6-only implementation, in this context, comprises
      an enabled end system stack plus routing in the network.  It
      implies that two application instances are capable of
      communicating using either IPv6 but not IPv4 - they have an IPv6
      stack, addresses, and network support including routing in IPv6,
      but some element is missing that prevents communication using
      IPv4.

   LIR Prefix:  The IPv6 prefix assigned by the network operator for
      direct mapping of IPv6 addresses to IPv4.

   LIR:  See Local Internet Registry.

   Local Internet Registry:  A Local Internet Registry (LIR) is an
      organization which has received an IP address allocation from a
      Regional Internet Registry (RIR), and which may assign parts of
      this allocation to its own internal network or those of its
      customers.  An LIR is thus typically an Internet service provider
      or an enterprise network.

   Mapped IPv4 Address:  An IPv6 address within a Mapped IPv4 Prefix.

   Mapped IPv4 Prefix:  An IPv6 prefix constructed from an LIR prefix
      and an IPv4 prefix.

   Overlay IPv4 Prefix:  Zero or more IPv4 addresses used in stateful
      translation.

   State:  "State" refers to dynamic information that is stored in a
      network element.  For example, if two systems are connected by a
      TCP connection, each stores information about the connection,
      which is called "connection state".  In this context, the term
      refers to correlations between IP addresses on either side of a



Baker                    Expires April 29, 2009                 [Page 5]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


      translator, or {IP Address, Transport type, transport port number}
      tuples on either side of the translator.  Of stateful algorithms,
      there are at least two major flavors depending on the kind of
      state they maintain:

      Hidden state:  the existence of this state is unknown outside the
         network element that contains it.

      Known state:  the existence of this state is known by other
         network elements.

   Stateful Translation:  A translation algorithm may be said to
      "require state in a network element" or be "stateful" if the
      transmission or reception of a packet creates or modifies a data
      structure in the relevant network element.

   Stateless Translation:  A translation algorithm that is not
      "stateful" is "stateless".  It may require configuration of a
      translation table, or may derive its needed information
      algorithmically from the messages it is translating.

1.3.  Translation objectives

   In any translation model, there is a question of objectives.
   Ideally, one would like to make any system and any application
   running on it able to "talk with" - exchange datagrams supporting
   applications - with any other system running the same application
   regardless of whether they have an IPv4 stack and connectivity or
   IPv6 stack and connectivity.  That was the model NAT-PT, and the
   things it necessitated led to scaling and operational difficulties.

   So the question comes back to what different kinds of connectivity
   can be easily supported and what are harder, and what technologies
   are needed to at least pick the low-hanging fruit.  We observe that
   applications today fall into three main categories:

   Client/Server Application:  Per whatis.com, "'Client/server'
      describes the relationship between two computer programs in which
      one program, the client, makes a service request from another
      program, the server, which fulfills the request."  In networking,
      the behavior of the applications is that connections are initiated
      from client software and systems to server software and systems.
      Examples include mail handling between an end user and his mail
      system (POP3, IMAP, and MUA->MTA SMTP), FTP, the web, and DNS name
      translation.






Baker                    Expires April 29, 2009                 [Page 6]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


   Peer to Peer Application:  Peer to peer applications are those that
      transfer information directly, rather than through the use of an
      intermediate repository such as a bulletin board or database.  In
      networking, any system (peer) might initiate a session with any
      other system (peer) at any time.  These in turn fall broadly into
      two categories:

      Peer to peer inrastructure applications:  Examples of
         "infrastructure applications" include SMTP between MTAs,
         Network News, and SIP.  Any MTA might open an SMTP session with
         any other at any time; any SIP Proxy might similarly connect
         with any other SIP Proxy.  An important characteristic of these
         applications is that they use ephemeral sessions - they open
         sessions when they are needed and close them when they are
         done.

      Peer to peer file exchange applications:  Examples of these
         include Limewire, BitTorrent, and UTorrent.  These are
         applications that open some sessions between systems and leave
         them open for long periods of time, and where ephemeral
         sessions are important, are able to learn about the reliability
         of peers from history or by reputation.  They use the long term
         sessions to map content availability.  Short term sessions are
         used to exchange content.  They tend to prefer to ask for
         content from servers that they find reliable and available.

   NAT-PT is an example of a facility with known state - at least two
   software components (the data plane translator and the DNS
   Application Layer Gateway, which may be implemented in the same or
   different systems) share and must coordinate translation state.  A
   typical IPv4/IPv4 NAT implements an algorithm with hidden state.
   Obviously, stateless translation requires less computational overhead
   than stateful translation, and less memory to maintain the state,
   because the translation tables and their associated methods and
   processes exist in a stateful algorithm and don't exist in a
   stateless one.

   If the key questions are the ability to open connections between
   systems, then one must ask who opens connections.

   o  We need a technology that will enable systems that act as clients
      to be able to open sessions with other systems that act as
      servers, whether in the IPv6->IPv4 direction or the IPv4->IPv6
      direction.  Ideally, this is stateless; especially in a carrier
      infrastructure, the preponderance of accesses will be to servers,
      and this optimizes access to them.  However, a stateful algorithm
      is acceptable if the complexity is minimized and a stateless
      algorithm cannot be constructed.



Baker                    Expires April 29, 2009                 [Page 7]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


   o  We also need a technology that will allow peers to connect with
      each other, whether in the IPv6->IPv4 direction or the IPv4->IPv6
      direction.  Again, it would be ideal if this was stateless, but a
      stateful algorithm is acceptable if the complexity is minimized
      and a stateless algorithm cannot be constructed.  In the case of
      infrastructure applications, which know nothing of choosing among
      peers by reputation, the IPv4->IPv6 direction is a stronger
      requirement.  Peer to peer file exchange applications, however,
      may be more forgiving - it may well be adequate to make a subset
      of IPv4->IPv6 connections work instead of all.  (EDITOR'S NOTE: I
      would be very interested in comments on this assertion)

   o  We do not need an algorithm that enables clients to connect to
      clients, because they don't connect.

   The complexity arguments bring us in the direction of hidden state:
   if state must be shared between the application and the translator or
   between translation components, complexity and deployment issues are
   greatly magnified.  We would very much prefer that any software
   changes be confined to the translator.

1.4.  Transition Plan

   While IPv6 was "by design" incompatible with IPv4, the designers
   intended that it would coexist with IPv4 during a period of
   transition.  The primary mode of coexistence was dual-stack operation
   - routers would be dual-stacked so that the network could carry both
   address families, and IPv6-capable hosts could be dual-stack to
   maintain access to IPv4-only partners.  The goal was that the
   preponderance of hosts and routers in the Internet would be IPv6-
   capable long before IPv4 address space allocation was completed.  At
   this time, it appears the exhaustion of IPv4 address space will occur
   before significant IPv6 adoption.

   Curran's "A Transition Plan for IPv6" [RFC5211] proposes a three-
   phase progression:

   Preparation Phase (current):  characterized by pilot use of IPv6,
      primarily through transition mechanisms defined in RFC 4213, and
      planning activities.

   Transition Phase (2010 through 2011):  characterized by general
      availability of IPv6 in provider networks which SHOULD be native
      IPv6; organizations SHOULD provide IPv6 connectivity for their
      Internet-facing servers, but SHOULD still provide IPv4-based
      services via a separate service name.





Baker                    Expires April 29, 2009                 [Page 8]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


   Post-Transition Phase (2012 and beyond):  characterized by a
      preponderance of IPv6-based services and diminishing support for
      IPv4-based services.

   In each of these phases, the coexistence problem and solution space
   has a different focus:

   Preparation Phase:  Coexistence tools are needed to facilitate early
      adopters by removing impediments to IPv6 deployment, and to assure
      that nothing is lost by adopting IPv6, in particular that the IPv6
      adopter has unfettered access to the global IPv4 Internet
      regardless of whether they have a global IPv4 address (or any IPv4
      address or stack at all.)  While it might appear reasonable for
      the cost and operational burden to be borne by the early adopter,
      the shared goal of promoting IPv6 adoption would argue against
      that model.  Additionally, current IPv4 users should not be forced
      to retire or upgrade their equipment and the burden remains on
      service providers to carry and route native IPv4.

   Transition Phase:  While IPv6 adoption can be expected to accelerate,
      there will still be a significant portion of the Internet
      operating in IPv4-only or preferring IPv4.  During this phase the
      norm shifts from IPv4 to IPv6, and coexistence tools evolve to
      ensure interoperability between domains that may be restricted to
      IPv4 or IPv6.

   Post-Transition Phase:  In this phase, IPv6 is ubiquitous and the
      burden of maintaining interoperability shifts to those who choose
      to maintain IPv4-only systems.  While these systems should be
      allowed to live out their economic life cycles, the IPv4-only
      legacy users at the edges should bear the cost of coexistence
      tools, and at some point service provider networks should not be
      expected to carry and route native IPv4 traffic.

   The choice between the terms "transition" versus "coexistence" has
   engendered long philosophical debate.  "Transition" carries the sense
   that we are going somewhere, while "coexistence" seems more like we
   are sitting somewhere.  Historically with IETF, "transition" has been
   the term of choice [RFC4213][RFC5211], and the tools for
   interoperability have been called "transition mechanisms".  There is
   some perception or conventional wisdom that adoption of IPv6 is being
   impeded by the deficiency of tools to facilitate interoperability of
   nodes or networks that are constrained (in some way, fully or
   partially) from full operation in one of the address families.  In
   addition, it is apparent that transition will involve a period of
   coexistence; the only real question is how long that will last.

   Thus, coexistence is an integral part of the transition plan, not in



Baker                    Expires April 29, 2009                 [Page 9]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


   conflict with it, but there will be a balancing act.  It starts out
   being a way for early adopters to easily exploit the bigger IPv4
   Internet, and ends up being a way for late/never adopters to hang on
   with IPv4 (at their own expense, with minimal impact or visibility to
   the Internet).  One way to look at solutions is that cost incentives
   (both monetary cost and the operational overhead for the end user)
   should encourage IPv6 and discourage IPv4.  That way natural market
   forces will keep the transition moving - especially as the legacy
   IPv4-only stuff ages out of use.  There will come a time to set a
   date after which no one is obligated to carry native IPv4 but it
   would be premature to attempt to do so yet.  The end goal should not
   be to eliminate IPv4 by fiat, but rather render it redundant through
   ubiquitous IPv6 deployment.  IPv4 may never go away completely, but
   rational plans should move the costs of maintaining IPv4 to those who
   insist on using it after wide adoption of IPv6.

1.5.  Expected uses of translation

   There are several potential uses of translation.  They are all easily
   described in terms of "interoperation between a set of systems that
   only communicate using IPv4 and a set of systems that only
   communicate using IPv6", but the differences at a detail level make
   them interesting.  At minimum, these include:

   o  Connection of IPv4-only islands to an IPv6-only network

   o  Connection of IPv6-only islands to an IPv4-only network

   o  Connecting IPv4-only devices with IPv6-only devices regardless of
      network type

   o  Connections between IPv4-only networks and IPv6-only networks,
      especially as a service within a large network such as an
      enterprise or ISP network or between peer networks.

1.5.1.  Connection of IPv4-only islands to an IPv6-only network

   While the basic issue is the same, there are at least two interesting
   special cases of this: connecting a small pool of legacy equipment
   with a view to eventual obsolescence, and connecting a legacy network
   with a view to eventual transition.










Baker                    Expires April 29, 2009                [Page 10]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


                  +----+ +----+ +----+              +----+
                  |IPv6| |IPv6| |IPv6| +----------+ |IPv4|
                  |Host| |Host| |Host| |Translator| |Host|
                  +--+-+ +--+-+ +--+-+ +-+------+-+ +--+-+
                     |      |      |     |      |      |
                  ---+------+------+-----+-    -+------+--

             Figure 1: Printer pool or other legacy equipment

   In the first case, Figure 1, one might have a pool of equipment
   (printers, perhaps) that is IPv4-capable, but either the network it
   serves or some equipment in that network is IPv6-only.  One pools the
   IPv4-only devices behind a translator, which enables IPv6-only
   systems to connect to the IPv4-only equipment.  If the network is
   dual stack and only some of the equipment is IPv6-only, the
   translator should be a function of a router, and the router should
   provide normal IPv4 routing services as well as IPv6->IPv4
   translation.

                   ----------
                ///          \\\
               //    IPv6      \\              192.168.1.0/24
             //      ISP         \\    +------+2001:db8:0:1::0/64
            |/                    \|   |      +---------------
            |  Allocates           |   |      |
           |   2001:db8::/60 to     |  |CPE   |192.168.2.0/24
           |   Customer             |  |Router|2001:db8:0:2::0/64
           |                        +--+      +---------------
           |   Doesn't know it,     |  |      |
            |  but sees customer   |   |      |192.168.3.0/24
            |\ IPv4 as            /|   |      |2001:db8:0:3::0/64
             \\2001:db8::a.b.c.d //    |      +---------------
               \\              //      +------+
                \\\          ///
                   ----------     LIR prefix is 2001:db8::0/96

                   Figure 2: Customer dual stack network

   Figure 2 creates transition options to a customer network connected
   to an IPv6-only ISP, or some equivalent relationship.  The customer
   might internally be using traditional IPv4 with NAT services, and the
   ISP might change its connection to an IPv6-only network and encourage
   it to transition.  If the ISP assigns a /60 prefix to a SOHO, for
   example, the CPE router in the SOHO could distribute several dual
   stack subnets internally, one for wireless and one for each of
   several fixed LANs (the entertainment system, his office, her office,
   etc).  One of the /64 prefixes would be dedicated to representing the
   SOHO's IPv4 addresses in the ISP or the IPv4 network beyond it, and



Baker                    Expires April 29, 2009                [Page 11]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


   the other prefixes for the various internal subnets.  Internally, the
   subnets might carry prefix pairs 192.168.n.0/24 and 2001:db8:0.n::/64
   for n in 1..15 (1..0xF), and externally might appear as 2001:db8:0:
   n::/64 for the IPv6 subnets and 2001:db8::192.168.n.0/120 for the
   IPv4 devices.  Note that to connect to an IPv4-only network beyond,
   RFC 1918 addresses would have to be statefully mapped using
   traditional IPv4 mechanisms somewhere; if this is done by the ISP,
   collusion on address mapping is required, and the case in
   Section 1.5.4 is probably a better choice.

   In this environment, the key issue is that one wants a prefix that
   enables the entire [RFC1918] address space to be embedded in a single
   /64 prefix, with the assumption that any routing structure behind the
   translator is managed by IPv4 routing.

1.5.2.  Connection of IPv6-only islands to an IPv4-only network

   To be completed

1.5.3.  Connecting IPv4-only devices with IPv6-only devices

   To be completed

1.5.4.  ISP-supported connections between IPv4-only networks and IPv6-
        only networks

   In this case (see Figure 3) we presume that a service provider or
   equivalent is offering a service in a network in which IPv4 routing
   is not supported, but customers are allocated relatively large pools
   of general IPv6 addresses, suitable for clients of IPv4 or IPv6
   hosts, and relatively small pools of addresses mapped to global IPv4
   addresses that are intended to be accessible to IPv4 peers and
   clients through translation.  Presumably, there are a number of such
   customers, and the administration wishes to use normal routing to
   manage the issues.  As a carrier offering, there is also a need for
   stateless translation.















Baker                    Expires April 29, 2009                [Page 12]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


                --------          --------
              //  IPv4  \\      //  IPv6  \\
             /   Domain   \    /   Domain   \
            /             +----+      +--+   \
           |              |XLAT|      |S3|    |  Sn: Servers
           | +--+         +----+      +--+    |  Hn: Clients
           | |S1|         +----+              |
           | +--+         |DNS |      +--+    |  XLAT: translator
            \     +--+    +----+      |H3|   /   DNS:  DNS Server
             \    |H1|    /    \      +--+  /
              \   +--+   /      \          /
             /            \    /            \
            /             +----+             \
           | +--+         |XLAT|     +--+     |
           | |S2|         +----+     |S4|     |
           | +--+         +----+     +--+     |
           |      +--+    |DNS |       +--+   |
            \     |H2|    +----+       |H4|  /
             \    +--+    /    \       +--+ /
              \\        //      \\        //
                --------          --------

     Figure 3: Service provider translation with multiple interchange
                                  points

   Since [RFC4291] specifies that IPv6 prefixes are 64 bits or shorter
   apart from host routes, one wishes to allocate each customer a /64
   mapped to a few IPv4 addresses and a shorter prefix for his general
   use.  The customer's CPE advertises the two prefixes into the IPv6
   routing domain to attract relevant traffic.  The translator
   advertises the mapped equivalent of an IPv4 default route into the
   IPv6 domain to attract all other traffic to it, for translation into
   the IPv4 routing domain.  It also advertises an appropriate IPv4
   prefix aggregating the mapped prefixes into the IPv4 domain to
   attract traffic intended for these customers.

   In this case, the LIR prefix MUST be within /32../63; a /64 puts the
   entire IPv4 address space into the host part, which is equivalent to
   the case in Section 1.5.1, and a prefix shorter than /32 wastes space
   with no redeeming argument.  In general, the LIR prefix should be 64
   bits less the length of IPv4 prefixes it allocates to its IPv4-mapped
   customers.  For example, if it is allocating a mapped IPv4 /24 to
   each customer, the LIR prefix used for mapping between IPv4 and IPv6
   addresses should be a /40, and the least significant bits in the IPv4
   address form the host part of the address.






Baker                    Expires April 29, 2009                [Page 13]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


2.  Framework

   Having laid out the preferred transition model and the options for
   implementing it (Section 1.1), defined terms(), considered the
   requirements (Section 1.3), considered the transition model
   (Section 1.4), and considered the kinds of networks the facility
   would support (Section 1.5), we now turn to a framework for IPv4/IPv6
   translation.  This framework has three main parts:

   o  The recommended address format

   o  The functional components of a translation solution, which include

      *  A DNS Application Layer Gateway,

      *  An optional stateless translator, and

      *  An optional stateful translator.

   o  The operational characteristics of the solution.

2.1.  Mapped Address Format

             0  8  16 24 32 40 48 56 64                    127
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |  LIR Prefix  | IPv4 addr |  entirely 0        |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |<-----prefix part ---->|<---   host part   --->|

                      Figure 4: Mapped Address Format

   As shown in Figure 4, the mapped address format has three components:

   bits 0..n-1:  An LIR-specified prefix, either 32..63 bits long or 96
      bits long,

   bits n..n+31  An embedded IPv4 address.  Except in the case of a 96
      bit prefix, this address intentionally straddles the boundary
      between [RFC4291]'s 64 bit "subnet" locator and its 64 bit host
      identifier.  The intention is that the /64 be used in routing and
      the bits in the host part be used for host identification as
      described in the address architecture.

   bits n+32..127:  Entirely zero; note that if n=96, this is null.

   The length of the LIR-specified prefix is itself specified by the LIR
   to achieve its objectives.  There are some obvious values that might
   be popular, including /40, /44, and /96, but there is no requirement



Baker                    Expires April 29, 2009                [Page 14]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


   than any of them be used; this is left to the operator's discretion.

2.2.  Translation components

   As noted in Section 1.5,translation involves several components.  An
   IPv4 client or peer must be able to determine the address of its
   server by obtaining an A record from DNS even if the server is IPv6-
   only - only has an IPv6 stack, or is in an IPv6-only network.
   Similarly, an IPv6 client or peer must be able to determine the
   address of its server by obtaining an AAAA record from DNS even if
   the server is IPv4-only - only has an IPv4 stack, or is in an IPv4-
   only network.  Given the address, the client/peer must be able to
   initiate a connection to the server/peer, and the server/peer must be
   able to reply.  It would be very nice if this scaled to the size of
   regional networks with straightforward operational practice.

   To that end, we describe four subsystems:

   o  A Domain Name System Translator

   o  A stateless IPv4/IPv6 translator

   o  A stateful IPv4/IPv6 translator

   o  Application Layer Gateways for some applications

2.2.1.  DNS Application Layer Gateway

   [DNS] describes the mechanisms by which a DNS Translator is intended
   to operate.  It is designed to operate on the basis of known but
   fixed state: the resource records, and therefore the names and
   addresses, that it translates are known to the network outside of the
   translator, but the process of serving them to applications does not
   interact with the translator in any way.

   There are at least three possible implementations of a DNS
   Translator:

   Static records:  One could literally program DNS with corresponding A
      and AAAA records.  This is most appropriate for stub services such
      as access to a legacy printer pool.

   Dynamic Translation of static records:  In more general operation,
      the expected behavior is for the application to request both A and
      AAAA records, and for an A record to be (retrieved and) translated
      by the DNS translator if and only if no reachable AAAA record
      exists.  This has ephemeral issues with cached translations, which
      can be dealt with by caching only the source record and forcing it



Baker                    Expires April 29, 2009                [Page 15]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


      to be translated whenever accessed.

   Static or Dynamic Translation of Dynamic DNS records:  In Dynamic DNS
      usage, a system could potentially report the translation of a name
      using a Mapped IPv4 Address, or using both a Mapped IPv4 Address
      and some other address.  The DNS translator has several options;
      it could store a AAAA record for the Mapped IPv4 Address and
      depend on translation of that for A records inline, it could store
      both an A and a AAAA record, or (when there is another IPv6
      address as well which is stored as the AAAA record) it could store
      only the A record.

2.2.2.  Stateless Translation - mapped addresses

   [XLAT] describes and defines the behavior of a stateless translator.
   This is an optional facility; one could implement or deploy only the
   stateful mode described in Section 2.2.3.  Stateless translation
   enables IPv4-only clients and peers to initiate connections to IPv6-
   only servers or peers equipped with Mapped IPv4 Addresses, as
   described in Figure 3.  It also enables scalable coordination of
   IPv4-only stubs of larger enterprise or ISP IPv6-only networks as
   described in Figure 2.

   In addition, since [RFC3484]address selection would select a Mapped
   IPv4 Address when it is available, stateless translation enables IPv6
   clients and peers with Mapped IPv4 Addresses to open connections with
   IPv4 servers and peers in a scalable fashion, supporting aysnchronous
   routes.

2.2.3.  Stateful translation - unmapped IPv6 address

   [XLAT] also describes and defines the behavior of the data plane
   component of a stateful translator.  [I-D.bagnulo-behave-nat64]
   describes the management of the state tables necessitated by stateful
   translation.  Like stateful translation, this is an optional
   facility; one could implement or deploy only the stateful mode
   described in Section 2.2.2.  Stateful translation is defined to
   enable IPv6 clients and peers without Mapped IPv4 Addresses to
   connect to IPv4-only servers and peers.

   Stateful translation could be defined to enable IPv4 clients and
   peers to connect to IPv6-only servers and peers without Mapped IPv4
   Addresses.  This is far more complex, however, and is out of scope in
   the present work.







Baker                    Expires April 29, 2009                [Page 16]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


2.2.4.  Translation gateway technologies

   In addition, some applications require special support.  An example
   is FTP.  FTP's active mode doesn't work well across NATs without
   extra support such as SOCKS.  Across NATs, it generally uses passive
   mode.  However, the designers of FTP inexplicably wrote different and
   incompatible passive mode implementations for IPv4 and IPv6 networks.
   Hence, either they need to fix FTP, or a translator must be written
   for the application.

   Other applications may be similarly broken.

2.3.  Translation in operation

2.4.  Unsolved problems

   Just say "multicast"; this framework could support multicast, but at
   this point does not.  This is a place for future work.

   As noted, IPv4 client/peer access to IPv6 servers and peers lacking
   Mapped IPv4 Addresses is not solved.

   Interoperation between IPv4-only clients and IPv6-only clients is not
   supported, and is not believed to be needed.


3.  IANA Considerations

   This memo requires no parameter assignment by the IANA.

   Note to RFC Editor: This section will have served its purpose if it
   correctly tells IANA that no new assignments or registries are
   required, or if those assignments or registries are created during
   the RFC publication process.  From the author's perspective, it may
   therefore be removed upon publication as an RFC at the RFC Editor's
   discretion.


4.  Security Considerations

   One "security" issue has been raised, with an address format that was
   considered and rejected for that reason.  At this point, the editor
   knows of no other security issues raised by the address format that
   are not already applicable to the addressing architecture in general.







Baker                    Expires April 29, 2009                [Page 17]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


5.  Acknowledgements

   This is under development by a large group of people.  Those who have
   posted to the list during the discussion include Andrew Sullivan,
   Andrew Yourtchenko, Brian Carpenter, Dan Wing, Ed Jankiewicz, Fred
   Baker, Hiroshi Miyata, Iljitsch van Beijnum, John Schnizlein, Kevin
   Yin, Magnus Westerlund, Marcelo Bagnulo Braun, Margaret Wasserman,
   Masahito Endo, Phil Roberts, Philip Matthews, Remi Denis-Courmont,
   Remi Despres, and Xing Li.

   The appendix is largely derived from Hiroshi Miyata's analysis, which
   is in turn based on documents by many of those just named.

   Ed Jankiewicz described the transition plan.

   The definition of a "Local Internet Registry" came from the
   Wikipedia, and was slightly expanded to cover the present case.
   (EDITOR'S QUESTION: Would it be better to describe this as an
   "operator-defined prefix"?)


6.  References

6.1.  Normative References

   [DNS]      Bagnulo, M., Ed., "Domain Name System Translator -
              draft-bagnulo-behave-dns64", October 2008.

   [I-D.bagnulo-behave-nat64]
              Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64/DNS64:
              Network Address and Protocol Translation from IPv6 Clients
              to  IPv4 Servers", draft-bagnulo-behave-nat64-01 (work in
              progress), September 2008.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [XLAT]     Li, X., Ed., Bao, C., Ed., and F. Baker, Ed., "IP/ICMP
              Translation Algorithm -
              draft-baker-behave-v4v6-translation", October 2008.





Baker                    Expires April 29, 2009                [Page 18]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


6.2.  Informative References

   [I-D.baker-behave-ivi]
              Li, X., Bao, C., Baker, F., and K. Yin, "IVI Update to
              SIIT and NAT-PT", draft-baker-behave-ivi-01 (work in
              progress), September 2008.

   [I-D.durand-softwire-dual-stack-lite]
              Durand, A., Droms, R., Haberman, B., and J. Woodyatt,
              "Dual-stack lite broadband deployments post IPv4
              exhaustion", draft-durand-softwire-dual-stack-lite-00
              (work in progress), September 2008.

   [I-D.ietf-v6ops-addcon]
              Velde, G., Popoviciu, C., Chown, T., Bonness, O., and C.
              Hahn, "IPv6 Unicast Address Assignment Considerations",
              draft-ietf-v6ops-addcon-10 (work in progress),
              September 2008.

   [I-D.miyata-v6ops-snatpt]
              Miyata, H. and M. Endo, "sNAT-PT: Simplified Network
              Address Translation - Protocol Translation",
              draft-miyata-v6ops-snatpt-02 (work in progress),
              September 2008.

   [I-D.xli-behave-ivi]
              Li, X., Chen, M., Bao, C., Zhang, H., and J. Wu, "Prefix-
              specific and Stateless Address Mapping (IVI) for IPv4/IPv6
              Coexistence and Transition", draft-xli-behave-ivi-00 (work
              in progress), July 2008.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC2765]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm
              (SIIT)", RFC 2765, February 2000.

   [RFC2766]  Tsirtsis, G. and P. Srisuresh, "Network Address
              Translation - Protocol Translation (NAT-PT)", RFC 2766,
              February 2000.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3142]  Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transport
              Relay Translator", RFC 3142, June 2001.




Baker                    Expires April 29, 2009                [Page 19]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 2003.

   [RFC3879]  Huitema, C. and B. Carpenter, "Deprecating Site Local
              Addresses", RFC 3879, September 2004.

   [RFC4192]  Baker, F., Lear, E., and R. Droms, "Procedures for
              Renumbering an IPv6 Network without a Flag Day", RFC 4192,
              September 2005.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
              for IPv6 Hosts and Routers", RFC 4213, October 2005.

   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
              Network Address Translations (NATs)", RFC 4380,
              February 2006.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC4864]  Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
              E. Klein, "Local Network Protection for IPv6", RFC 4864,
              May 2007.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, September 2007.

   [RFC4966]  Aoun, C. and E. Davies, "Reasons to Move the Network
              Address Translator - Protocol Translator (NAT-PT) to
              Historic Status", RFC 4966, July 2007.

   [RFC5211]  Curran, J., "An Internet Transition Plan", RFC 5211,
              July 2008.

   [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
              March 2008.


Appendix A.  Address proposals

   This appendix summarizes and analyzes the several proposals that have
   been made for a mapped IPv4 address.  These prefixes fall into two
   broad categories: those that embed the IPv4 address into a well-known



Baker                    Expires April 29, 2009                [Page 20]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


   prefix, and those that embed it into a prefix defined by the network
   operator.  [RFC4291] and [RFC2765] define different well-known
   prefixes, and [I-D.bagnulo-behave-nat64] and [I-D.baker-behave-ivi]
   define different forms of operator-defined prefixes.

A.1.  Well-known address formats

   [RFC2765] and [RFC4291] define two slightly different formats of
   address that map between IPv4 and IPv6.  In both cases, there is a
   defined 96 bit prefix, and the IPv4 address is inserted into bits
   96..127 of the IPv6 address.

   [RFC2765]'s address formats are as follows:

   IPv4-mapped:  An address of the form 0::ffff:a.b.c.d which refers to
      a node that is not IPv6-capable.  In addition to its use in the
      API this protocol uses IPv4-mapped addresses in IPv6 packets to
      refer to an IPv4 node.

   IPv4-compatible:  An address of the form 0::0:a.b.c.d which refers to
      an IPv6/IPv4 node that supports automatic tunneling.  Such
      addresses are not used in this protocol.

   IPv4-translated:  An address of the form 0::ffff:0:a.b.c.d which
      refers to an IPv6-enabled node.  Note that the prefix 0::ffff:0:0:
      0/96 is chosen to checksum to zero to avoid any changes to the
      transport protocol's pseudo header checksum.


    |                80 bits               | 16 |      32 bits        |
    +--------------------------------------+--------------------------+
    |0000..............................0000|0000|    IPv4 address     |
    +--------------------------------------+----+---------------------+
                        IPv4-Compatible IPv6 address
    |                80 bits               | 16 |      32 bits        |
    +--------------------------------------+--------------------------+
    |0000..............................0000|FFFF|    IPv4 address     |
    +--------------------------------------+----+---------------------+
                         IPv4-mapped IPv6 address

         Figure 5: RFC 4291 Deprecated IPv4-mapped address formats

A.1.1.  Benefits of a well-known address








Baker                    Expires April 29, 2009                [Page 21]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


   Address Mapping:  The Well-Known Prefix allows automatic IPv6 address
      mapping to IPv4.  One Well-Known Prefix can represent entire IPv4
      network address.

   Address Selection:  It is straightforward to ensure that an
      application prefers native addressing to mapped addressing in
      selecting an address for its peer or server, as the [RFC3484]
      tables can come configured that way from the manufacturer.

      It will choose its source address by [RFC3484] rules, which prefer
      the most similar prefix first.  Hence, a system with a mapped
      address communicating through a translator will prefer its own
      mapped address as a source.

   Synthetic Address Detection:  If the application wants to know
      whether the address has been synthesized, this is straightforward.

A.1.2.  Issues in using a well-known address

   Routing  In interdomain routing, there can be problems similar to
      those considered in [RFC3879].  For example, consider two routing
      administrations that interconnect using IPv6 and each offer
      independent [RFC1918] IPv4 domains.  If an IPv4 client of one
      administration accesses an IPv6 server in the other network, the
      replies will be routed to the other network's [RFC1918] domain.

   Scability of discontiguous IPv4 domains:  Using a standard prefix for
      all IPv4 space means that all IPv4 access is through that system
      or through the topologically nearest instance of them.  If the
      IPv4 address space is fragmented, and especially if it is
      duplicated as is done with [RFC1918] space, it is impossible to
      distinguish the access points in the IPv6 network.

   Control:  Even in intradomain routing, control issues can arise in
      routing if there is more than one translator.

A.1.3.  Configuration of a well-known address

   Host:  To use DNS re-writing function, the IPv6 node should be
      configured to send DNS query to appropriate DNS server somehow.
      But it is same as ordinary DNS configuration.  Therefore, no
      special configuration is required for both IPv6 and IPv4 hosts.

   Router:  No special configuration is required of routers.







Baker                    Expires April 29, 2009                [Page 22]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


   Gateway:  Each gateway needs to know the Well-Known Prefix, whether
      that means configuration of the prefix or simply configuration of
      the translation function.  The Gateway must also be configured to
      advertise the Well-Known Prefix in the IPv6 network and the
      relevant prefix(es) in the IPv4 network.  This must be performed
      once for each gateway.  If the addresses are mapped in statically,
      each mapping must be configured in the appropriate gateway.  This
      configuration must be performed [number of mapped prefixes] *
      [number of sharing gateway] times.

   DNS  The DNS re-writing function must be configured with the Well-
      Known Prefix to synthesize AAAA records from A records for IPv6
      clients, but it may be configured by default.  This configuration
      must be performed [number of Local Prefix] times.

A.1.4.  Applicability of a well-known address

   o  Small scale translation (Home Network).

   o  Less redundant translation service (no load balancing).

   o  Stub IPv6 network.

   Sample configurations include:

      To provide the access from IPv6 client in stub IPv6 network to
      global IPv4 server, place the gateway at the edge of IPv6 stub
      site.


    (IPv6 stub network)                          (IPv4 global network)
    [IPv6 Client]---->---[Gateway]----->----+------------[IPv4 Server]
                                            |
                                            +------------[IPv4 Server]]]

            Figure 6: IPv6 to global IPv4 (Client Side Gateway)

      To provide the access from IPv6 client in stub IPv6 network to
      private/global IPv4 server (IPv6 stub network attached to a
      private IPv4 network), place the gateway at the edge of IPv6 stub
      network.










Baker                    Expires April 29, 2009                [Page 23]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


    (IPv6 stub network)                          (IPv4 private network)
    [IPv6 Client]---->---[Gateway]----->----+------------[IPv4 Server]
                                            |
                                          [NAT]
                                            |
                                            +------------[IPv4 Server]

            Figure 7: IPv6 to global IPv4 (Client Side Gateway)

A.2.  Network operator specified prefixes

   Two forms of network operator specified addresses have been proposed,
   one of them in several minor variations.  In short, both have the
   network operator specify a prefix into which an IPv4 address is
   embedded, either in bits 96..127 or following a shorter prefix.

   Since one is a special case of the other (the LIR prefix is 96 bits
   as opposed to being variable), it would be tempting to comment on the
   two together.  The operational similarities will be great, and the
   differences will revolve around the economics of the prefix that the
   IPv4 address is embedded into But to make them clear, we will review
   them separately.

A.2.1.  The IVI prefix

   The IVI Address [I-D.xli-behave-ivi] [I-D.baker-behave-ivi], shown in
   Figure 8, has a variable length prefix specified by the operator
   followed by the IPv4 address, and the remainder filled with zero.
   Observing [RFC4291]'s requirement that an operator-specified prefix
   should have 64 bits of subnet locator and 64 bits of host interface
   identifier, IVI suggests that the operator divide the mapped IPv4
   prefix into a subnet part and a host part, and assign a prefix from
   its allocation that with the subnet part fills 64 bits.

             0  8  16 24 32 40 48 56 64                    127
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |  LIR Prefix  | IPv4 addr |  entirely 0        |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |<-----prefix part ---->|<---   host part   --->|

                       Figure 8: IVI Address Format

   The impact of the variability of the LIR Prefix has to do with
   service offerings.  If a network operator wishes to offer customers a
   general IPv6 prefix such as a /48 plus a smaller IPv4-mapped set of
   addresses for IPv4-accessible servers, such as an IPv4 /24, he might
   literally design a service in which each customer gets a general /48
   prefix and an IPv4-mapped /64 prefix.  To accomplish this, the



Baker                    Expires April 29, 2009                [Page 24]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


   operator would allocate a /40 for the LIR prefix and embed the IPv4
   address space into it.  His Advertised IPv4 Prefix would aggregate
   the Mapped IPv4 Prefixes that he in turn assigns to his customers.
   If, however, he wanted to assign smaller units, such as /28s to each
   customer, he would allocate a shorter prefix such as a /36 as the LIR
   Prefix.

   There are clear trade-offs here; the point is to enable the network
   operator to optimize them for the service he wants to offer.

A.2.1.1.  Benefits of an operator-specified /32../64 prefix

   Address Mapping:  A Mapped IPv4 Address format allows a stateless
      IPv6 address mapping between an IPv4 address and its mapped IPv6
      counterpart.  One such prefix can represent the entire IPv4
      address space, and if desired multiple prefixes can represent
      multiple instances of it or accesses to it.

   Address Selection:  [RFC3484] selection rules select the source
      address most similar to the destination address in question, which
      is to say matching the longest prefix.  In general, one would
      expect a system with an address of this type to prefer IPv6 source
      addresses derived from IPv4 addresses when they are available.

   Synthetic Address Detection:  If the [RFC3484] tables in a host are
      configured with the administration's translation prefix, a policy
      can be made to prefer native IPv4 to translation, or to prefer any
      other IPv6 address to a translated address.

   Managing Multiple Gateways:  The administration has the option of
      using the same prefix on multiple gateways, or of using different
      prefixes.  Differing administrations will almost assuredly use
      different prefixes.  This enables the administration to
      distinguish between distinct address spaces such as separate
      instances of the [RFC1918] address space.  It also enables
      multiple gateways to be used to interconnect between public IPv4
      and IPv6 networks without having to manage the state maintained by
      such translation gateways.

   Scalability:  Due to the ability to support multiple gateways between
      the same two domains statelessly and the ability to identify
      multiple instances of the same IPv4 address space when
      appropriate, a network operator specified prefix is scalable
      through normal routing structures.







Baker                    Expires April 29, 2009                [Page 25]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


   Flexibility  Since the prefix choice is under the network's control,
      routing is managed relatively easily.

   TCP/UDP Checksums:  These prefixes were chosen to make it unnecessary
      to adjust TCP/UDP checksums.

A.2.1.2.  Issues in using an operator-specified /32../64 prefix

   Synthetic Address Detection:  By default, hosts are unlikely to come
      configured with the administration's translation prefix in their
      [RFC3484] tables, and so are unlikely to be able to distinguish
      such addresses from other IPv6 addresses.

   Private address spaces  Multiple small (and perhaps overlapping)
      address spaces are readily supported in what might be called a
      network model.  However, these consume much larger blocks of IPv6
      address space than the appliance model of a Local Prefix
      (Appendix A.2.2) does.

   IPv4 Address Efficiency:  As noted above, IVI is less efficient than
      the NAT64 model in enumerating small IPv4 islands, and having a
      prefix per network operator is less efficient on a global basis
      than having a single well-known prefix.

   Routing:  If one uses both stateless and stateful translation in the
      same network, assigning a normal IPv6 prefix to all systems and
      additionally mapped addresses to servers, then one needs two
      routes, one for each prefix.  Reducing this burden requires either
      the total use of stateful translation, disabling IPv4 clients
      access to IPv6 servers, or total use of stateless translation,
      meaning that one effectively assigns an IPv4 address to every
      host.

   Service model:  One would generally expect an IVI address to be used
      in an ISP service, as it requires a 40 bit prefix assigned by the
      operator in most cases.  It could be used with a ULA [RFC4193] in
      an edge network at the cost of losing global routability.

   TCP/UDP checksums  Using an operator-specified prefix requires the
      translator to adjust TCP and UDP checksums.

A.2.1.3.  Configuration of an operator-specified /32../64 prefix

   Host assignment:  In general, one would expect a mapped IPv4 address
      to be assigned in the same way that IPv4 addresses are assigned;
      this would call for the use of DHCPv6 or manual configuration.





Baker                    Expires April 29, 2009                [Page 26]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


   Router:  If one or more hosts on a LAN are assigned mapped IPv4
      addresses, one or more routers on the LAN needs configuration of
      the corresponding Mapped IPv4 Prefix, and to have that advertised
      as a route in the IPv6 domain.

   Gateway:  The gateway needs to advertise three prefixes:

      *  The Advertised IPv4 Prefix is advertised into the IPv4 domain
         to attract traffic that needs translation to IPv6.

      *  The Overlay IPv4 Prefix, if stateful translation is in use, is
         advertised into the IPv4 domain to attract traffic using that
         translation facility.

      *  The LIR Prefix is advertised into the IPv6 domain to attract
         traffic that needs translation to IPv4.

   DNS:  The DNS re-writing function must be configured with the LIR
      Prefix to synthesize the AAAA records for IPv6 nodes when
      appropriate.

      The DNS server needs to be configured with the information to
      develop A records when appropriate.  This may be accomplished
      using Dynamic DNS or manual configuration.  This may mean
      configuration of IPv4 A records that get translated to AAAA
      records, or configuration of IPv6 AAAA records that are recognized
      by the DNS server.

A.2.1.4.  Applicability of an operator-specified /32../64 prefix

   o  The IVI address is appropriate to large scale, ISP grade,
      translation, while the NAT64 address is more flexible.

   o  Highly redundant translation service.

   o  Places where IPv4 clients need to access IPv6 servers.

   o  Places where IPv6 clients and peers need to access IPv4 servers
      and peers.

A.2.2.  Network operator specified /96 prefixes

   NAT64 [I-D.bagnulo-behave-nat64] and SNATPT [I-D.miyata-v6ops-snatpt]
   each specify an address that, like the well-known addresses of
   Appendix A.1 and the "Dummy Address" of [RFC2766] and [RFC3142], has
   96 bits of operator-specified prefix and the IPv4 address in bits
   96..127.  This is shown in Figure 9.  In some proposals, the "IDENT"
   field is always zero, and in others it enumerates different instances



Baker                    Expires April 29, 2009                [Page 27]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


   of the IPv4 address space.

                                               1             1
               1         2       6         7   9             2
     0123456789012345678901234...01234567890...01234567890...012345678
     +------------------------//-----+------//-------+----//---------+
     |            IPv6 Prefix        |     IDENT     | IPv4 Address  |
     |               64 bit          |     32 bit    |     32 bit    |
     +------------------------//-----+------//-------+----//---------+
     |                               |               |
     |<-----------PREFIX64---------->|<-identifier-->|

                      Figure 9: NAT64 Address Format

   A similar address format, with an "IDENT" based on the IANA OUI, is
   used by ISATAP [RFC5214]; if a globally-unique "IDENT" field is
   selected, it needs to differ from that value.

A.2.2.1.  Benefits of an operator-specified /96 prefix

   Address Mapping:  A Mapped IPv4 Address format allows a stateless
      IPv6 address mapping between an IPv4 address and its mapped IPv6
      counterpart.  One such prefix can represent the entire IPv4
      address space, and if desired multiple prefixes can represent
      multiple instances of it or accesses to it.

   Address Selection:  [RFC3484] selection rules select the source
      address most similar to the destination address in question, which
      is to say matching the longest prefix.  In general, one would
      expect a system with an address of this type to prefer IPv6 source
      addresses derived from IPv4 addresses when they are available.

   Synthetic Address Detection:  If the [RFC3484] tables in a host are
      configured with the administration's translation prefix, a policy
      can be made to prefer native IPv4 to translation, or to prefer any
      other IPv6 address to a translated address.

   Private address spaces  Multiple small (and perhaps overlapping)
      address spaces are readily supported in what might be called an
      appliance model; for example, if SOHOs are using IPv4 internally,
      the IPv6 ISP can give a /64 to each and manage them easily.

   Managing Multiple Gateways:  The administration has the option of
      using the same prefix on multiple gateways, or of using different
      prefixes.  This approach enables multiple gateways to be used to
      interconnect between IPv4 and IPv6 networks without having to
      manage the state maintained by such translation gateways.




Baker                    Expires April 29, 2009                [Page 28]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


   Scalability:  Due to the ability to support multiple gateways between
      the same two domains statelessly and the ability to identify
      multiple instances of the same IPv4 address space when
      appropriate, a network operator specified prefix is scalable
      through normal routing structures.

   Flexibility  Since the prefix choice is under the network's control,
      routing is managed relatively easily.

A.2.2.2.  Issues in using an operator-specified /96 prefix

   Synthetic Address Detection:  By default, hosts are unlikely to come
      configured with the administration's translation prefix in their
      [RFC3484] tables, and so are unlikely to be able to distinguish
      such addresses from other IPv6 addresses.

   Routing:  If one uses both stateless and stateful translation in the
      same network, assigning a normal IPv6 prefix to all systems and
      additionally mapped addresses to servers, then one needs two
      routes, one for each prefix.  Reducing this burden requires either
      the total use of stateful translation, disabling IPv4 clients
      access to IPv6 servers, or total use of stateless translation,
      meaning that one effectively assigns an IPv4 address to every
      host.

   Service model:  One would generally expect an IVI address to be used
      in an ISP service, as it requires a 40 bit prefix assigned by the
      operator in most cases.  It could be used with a ULA [RFC4193] in
      an edge network at the cost of losing global routability.  The
      NAT64 address, on the other hand, has no such issue.

   Synthetic Address Detection:  It is difficult to identify a mapped
      IPv4 address without knowledge that the mapping algorithm is used
      with a specific prefix.

   Address Configuration:  Since IPv4 addresses are allocated by DHCP
      servers or manually, it is inappropriate to mix Local Prefix IPv4-
      mapped addresses with Address Autoconfiguration [RFC4862]
      [RFC4941] in the same prefix.  This may not be obvious to a
      provider that thinks of itself as simply assigning a /64 IPv6
      prefix to the SOHO (regarding which see [I-D.ietf-v6ops-addcon]).

   Routing  Routing is readily handled in the IPv4 network.  However, if
      routing of IPv4-mapped prefixes is desired in the IPv6 network, we
      are forced to use prefixes in the neighborhood of /96../128.
      Apart from routing host addresses, [RFC4291] frowns on this,
      preferring routing prefixes to be 64 bits or shorter and leaving a
      64 bit host ID.



Baker                    Expires April 29, 2009                [Page 29]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


   TCP/UDP Checksums:  Using an operator-specified prefix requires the
      translator to adjust TCP and UDP checksums.

A.2.2.3.  Configuration of an operator-specified /96 prefix

   Host assignment:  In general, one would expect a mapped IPv4 address
      to be assigned in the same way that IPv4 addresses are assigned;
      this would call for the use of DHCPv6 or manual configuration.

   Router:  If one or more hosts on a LAN are assigned mapped IPv4
      addresses, one or more routers on the LAN needs configuration of
      the corresponding Mapped IPv4 Prefix, and to have that advertised
      as a route in the IPv6 domain.

   Gateway:  The gateway needs to advertise two prefixes:

      *  The Advertised IPv4 Prefix is advertised into the IPv4 domain
         to attract traffic that needs translation to IPv6.

      *  The LIR Prefix is advertised into the IPv6 domain to attract
         traffic that needs translation to IPv4.

   DNS:  The DNS re-writing function must be configured with the LIR
      Prefix to synthesize the AAAA records for IPv6 nodes when
      appropriate.

      The DNS server needs to be configured with the information to
      develop A records when appropriate.  This may be accomplished
      using Dynamic DNS or manual configuration.  This may mean
      configuration of IPv4 A records that get translated to AAAA
      records, or configuration of IPv6 AAAA records that are recognized
      by the DNS server.

A.2.2.4.  Applicability of an operator-specified /96 prefix

   o  Local Prefixes are appropriate to small networks that have little
      internal IPv6 structure, such as server pools or SOHO clients.
      The structure in the IPv4 network is as with any IPv4 network,
      making this appropriate to medium sized IPv4 domains.

   o  Highly redundant translation service.

   o  Places where IPv4 clients need to access IPv6 servers.

   o  Places where IPv6 clients and peers need to access IPv4 servers
      and peers.

   Sample configurations include:



Baker                    Expires April 29, 2009                [Page 30]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


      Place the gateway at the edge of IPv6 stub site.


     (IPv6 stub network)                          (IPv4 global network)
     [IPv6 Client]---->---[Gateway]----->----+------------[IPv4 Server]
                                             |
                                             +------------[IPv4 Server]

           Figure 10: IPv6 to global IPv4 (Client Side Gateway)

      Place the gateway in front of IPv4 server.


     (IPv6 global network)                        (IPv4 global network)
     [IPv6 Client]---------+------>------[Gateway]---->---[IPv4 Server]
                           |
     [IPv6 Client]---------+

           Figure 11: IPv6 to global IPv4 (Server Side Gateway)

      to provide the access from IPv6 client to private IPv4 server,
      place the gateway in front of IPv4 private network.


     (IPv6 global network)                       (IPv4 private network)
     [IPv6 Client]---------+------>------[Gateway]---->---[IPv4 Server]
                           |
     [IPv6 Client]---------+

           Figure 12: IPv6 to private IPv4 (Server Side Gateway)

      To provide the access from IPv4 client to IPv6 server by static
      1:1 mapping, place the gateway at the edge of IPv4 stub site.


     (IPv6 global network)                       (IPv4 private network)
     [IPv6 Server]---------+------<------[Gateway]---<----[IPv4 Client]
                           |
     [IPv6 Server]---------+

           Figure 13: Private IPv4 to IPv6 (Client Side Gateway)










Baker                    Expires April 29, 2009                [Page 31]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


Author's Address

   Fred Baker (editor)
   Cisco Systems
   Santa Barbara, California  93117
   USA

   Phone: +1-408-526-4257
   Fax:   +1-413-473-2403
   Email: fred@cisco.com









































Baker                    Expires April 29, 2009                [Page 32]


Internet-Draft     Framework for IPv4/IPv6 Translation      October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Baker                    Expires April 29, 2009                [Page 33]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/