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

Versions: 00 01

Behave                                                             X. Li
Internet-Draft                                                    C. Bao
Updates: 2765, 2766                    CERNET Center/Tsinghua University
(if approved)                                                   F. Baker
Intended status: Standards Track                                  K. Yin
Expires: March 20, 2009                                    Cisco Systems
                                                      September 16, 2008


                     IVI Update to SIIT and NAT-PT
                       draft-baker-behave-ivi-01

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 March 20, 2009.

Abstract

   This note proposes an address and service architecture designed to
   facilitate transition from an IPv4 Internet to an IPv6 Internet.
   This service contains three parts: A DNS Application Layer Gateway, a
   stateful Network Address Translator that enables IPv6 clients to
   initiate connections to IPv4 servers and peers, and a stateless
   Network Address Translator that enables IPv4 and IPv6 systems to
   interoperate freely.

   It is couched as an update to RFCs 2765 and 2766.  This is because



Li, et al.               Expires March 20, 2009                 [Page 1]


Internet-Draft        IVI Update to SIIT and NAT-PT       September 2008


   the stateless service is essentially the SIIT with a different
   address format, and because the DNS Application Layer Gateway and the
   stateful translator have significant similarities to NAT-PT.  There
   are, however, important differences from NAT-PT, responsive to the
   issues raised in RFC 4966.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The IVI model  . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  IVI Network Model and communication objectives . . . . . .  4
     2.2.  IVI Address Format . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Routing in IVI networks  . . . . . . . . . . . . . . . . .  6
     2.4.  DNS service in IVI networks  . . . . . . . . . . . . . . .  8
     2.5.  Host operation in IVI networks . . . . . . . . . . . . . .  9
       2.5.1.  Interaction of IVI Addresses with RFC3484 Address
               Selection  . . . . . . . . . . . . . . . . . . . . . .  9
       2.5.2.  Interaction of IPv4 and IVI addresses on the same
               host . . . . . . . . . . . . . . . . . . . . . . . . . 10
     2.6.  Operation of the IVI Gateway . . . . . . . . . . . . . . . 11
       2.6.1.  Stateless (1:1) Operation  . . . . . . . . . . . . . . 12
       2.6.2.  Stateful (1:n) Operation . . . . . . . . . . . . . . . 12
   3.  Transition plan  . . . . . . . . . . . . . . . . . . . . . . . 12
     3.1.  IPv4-only Network  . . . . . . . . . . . . . . . . . . . . 13
     3.2.  IPv4+IPv6 Dual Stack Network . . . . . . . . . . . . . . . 13
     3.3.  IPv6+IPv4-accessible Network . . . . . . . . . . . . . . . 13
     3.4.  IPv6 Network . . . . . . . . . . . . . . . . . . . . . . . 14
   4.  Future extensions of the IVI Model . . . . . . . . . . . . . . 14
   5.  Reflections on RFC 4966  . . . . . . . . . . . . . . . . . . . 14
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 19













Li, et al.               Expires March 20, 2009                 [Page 2]


Internet-Draft        IVI Update to SIIT and NAT-PT       September 2008


1.  Introduction

   This note documents the prototype being used for translation between
   the IPv4 CERNET and the IPv6 CNGI-CERNET2 networks.  This uses the
   algorithms of SIIT [RFC2765] with a modified address format, and a
   modified version of NAT-PT [RFC2766].  In general, we recommend the
   use of native communication and dual stack deployment.  However, in
   several scenarios, the temporary use of translation can simplify
   service deployment.  Hence, we describe a translation function.

   It should be understood that protocol translation in any form is not
   a viable long term solution for IPv6 deployment; it has value during
   a certain part of the adoption curve, but will become less relevant
   at later points in the adoption curve.  The objective of any
   transition strategy, of which IVI is an example, is to facilitate
   transition, not to enter a phase of heightened operational and
   capital expenditure running two networks in parallel only to stay
   there.  When IPv6 is widely deployed and economic conditions support
   the move, we expect service providers to withdraw IPv4 service.

   The objectives of the translation function are to enable systems that
   are unable to communicate with each other due to routing,
   implementation, or parameter differences to communicate.  Almost any
   translation function will connect IPv6 systems with IPv4 systems or
   systems in an IPv4 network.  The difficulty is that this gives no
   incentive to administrations to move their servers and peers from the
   IPv4 domain to the IPv6 domain.  Noting that dual stack
   implementations such as recommended in [RFC4213] are not being widely
   deployed by operators, the IVI model is designed to facilitate
   placing servers and peers in the IPv6 domain, achieving native IPv6
   connectivity without giving up IPv4 accessibility.

   More specifically, the objectives are several:

   o  As with any network, IPv4 systems connected by an IPv4 network can
      talk among themselves and IPv6 systems connected by an IPv6
      network can talk among themselves.  The first objective is to
      preserve this and its scaling characteristics.

   o  If one or both domains are IPv4+IPv6 but there exist systems with
      only one architecture, we presume that IPv4 and IPv6 routing
      crosses the gateway or a parallel router, and the systems are able
      to communicate directly.

   o  We want to enable systems that have no IPv6 address to access
      servers and peers with IPv4-derived IPv6 addresses (IVI addresses)
      in the IPv6 domain.  This requires translation similar to that
      described in SIIT [RFC2765].  This operation is stateless.



Li, et al.               Expires March 20, 2009                 [Page 3]


Internet-Draft        IVI Update to SIIT and NAT-PT       September 2008


   o  We want to enable systems that have no IPv4 address to access
      servers and peers in the IPv4 domain.  For systems with IPv4-
      derived IPv6 addresses (IVI addresses), this is solved by the SIIT
      extension described in this document, given the appropriate AAAA
      record by IVI DNS ALG.  This operation is also stateless.  Other
      systems with non-IVI IPv6 addresses require some form of stateful
      translation.  This has similarities to the mechanisms described in
      NAT-PT [RFC2766].  We wish to do this with a minimum of maintained
      state.

   Some have questioned the need for IPv4 access to IPv6-only servers
   and peers, noting that in the Internet of 2008 there is no market
   requirement for such access and any server or peer will require
   accessibility from an IPv4 network.  The issue is that this presumes
   a certain point in the adoption curve; at another point in the
   adoption curve, one hopes that there will be few takers for IPv4-only
   service.  In between, before IPv6 service for a server or peer
   becomes a requirement, IPv6-only service for a server or peer must be
   feasible (it must be conceivable that a server or peer with an IPv6
   address will be useful).  We argue that it is easier for IPv6 service
   for a server or peer to become feasible if it is possible to
   configure it with an IPv4-derived IPv6 address than if it must also
   have IPv4 service.  In the long term, we believe that translation is
   not a service that service providers will normally use, but is a
   helpful and perhaps necessary step in transitioning to an IPv6 world.


2.  The IVI model

   The Name "IVI" contracts "IV<->VI"; we are describing a translation
   connection between systems using IPv4 or IPv6 that cannot communicate
   using either IPv4 or IPv6.  In any normal case where native
   communication is possible between two systems, we argue that it is
   preferable.

2.1.  IVI Network Model and communication objectives

   An IVI Network, as shown in Figure 1, consists of two or more network
   domains connected by one or more IVI gateways.  One of those networks
   either routes IPv4 but not IPv6, or contains some hosts that only
   implement IPv4.  The other network either routes IPv6 but not IPv4,
   or contains some hosts that only implement IPv6.  Both networks
   contain clients, servers, and peers.  It would be advisable and
   preferable to implement a dual stack architecture in both domains,
   but either due to address scarcity or the process involved in IPv6
   turn-up, that is not practical at the moment.





Li, et al.               Expires March 20, 2009                 [Page 4]


Internet-Draft        IVI Update to SIIT and NAT-PT       September 2008


                   -----------                -----------
                ///   IPv4    \\\          ///   IPv6    \\\
              //     Network     \\      //     Network     \\
             /                     \    /              +-----+\
            |                       |  |               |IPv6 | |
           |                    +---------+            +-----+  |
           |                    |   IVI   |                     |
           |                    | Gateway |            +-----+  |
           |     +-----+        +---------+            |IPv6/|  |
            |    |IPv4 |            |  |               | IVI | |
             \   +-----+           /    \              +-----+/
              \\                 //      \\                 //
                \\\           ///          \\\           ///
                   -----------                -----------

                        Figure 1: IVI Network Model

   Clearly, there are issues in IP addressing, and routing, DNS, and the
   specifics of translation.

2.2.  IVI Address Format

   The IVI Address is an IPv4 address embedded in an IPv6 address and
   predictable by the gateway and systems on either side.  The selection
   of the LIR prefix, including its length and absolute value, is at the
   option of the network administration; it is not fixed.  Figure 2
   shows one possible model.  It enables the IPv6 domain to assign the
   equivalent of IPv4 /24 prefixes to IPv6 LANs (/64).

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

                   Figure 2: Example IVI Address Format

   In the IPv4 domain, this represents a prefix no longer than /24.  In
   the IPv6 domain, the "default route" advertising the entire IPv4
   address space is the LIR /40 prefix.  More specific prefixes up to
   /64 may be advertised as needed, or host (/128) routes.

   The objective here is to enable the network administration to be in
   control of the impact of the tradeoff on its routing.

   The need to change the address format used by SIIT bears repetition,
   although it has come up in other discussions.  [RFC4291] deprecated



Li, et al.               Expires March 20, 2009                 [Page 5]


Internet-Draft        IVI Update to SIIT and NAT-PT       September 2008


   the address format with the brusque comment that "current IPv6
   transition mechanisms no longer use these addresses."  The reason
   that they were not widely deployed was that they gave network
   operators little control in routing, or ways to ensure that route
   redistribution worked correctly.  A prefix that lets the LIR specify
   the upper bits gives the operator the flexibility to identify the IVI
   gateway advertising the prefix and better control the distribution of
   routes.

2.3.  Routing in IVI networks

   The IVI Gateway may be a general purpose router; in that mode, it
   operates like any other router.  However, it also advertises one or
   more prefixes into both the IPv4 and the IPv6 domain, and when a
   datagram is directed to an address within the translation prefix(es),
   it translates the datagram.

   As a Network Address Translator, the IVI Gateway offers one or both
   of two services: stateless translation of addresses conforming to
   Figure 2 to and from IPv4 addresses, and stateful translation between
   IPv6 addressing and a combination of an IPv4 address and transport
   source port as is done in normal NATs.

   In IPv4, the IVI gateway advertises the IPv4 prefix being used for
   stateless IVI address translation; for example, if an IPv4 /20 is
   being used as a set of /24 prefixes in the IPv6 domain, it would
   advertise a /20 into the IPv4 domain.  If the IVI gateway is offering
   stateful translation, it may also advertise the addresses or prefix
   being used for that service unless another router handles this.

   In IPv6, the IVI gateway advertises a "default route for global IPv4"
   - in the example given in Figure 2, it would normally advertise the
   /40 LIR prefix.  If that is inappropriate - there are multiple non-
   overlapping IPv4 domains or other concerns apply - it would advertise
   "more-specific" prefixes as appropriate.

   In the IPv6 domain, the routers or hosts that have been assigned IVI
   prefixes or addresses subsidiary to the IVI prefix for a service
   advertise the IVI /64s corresponding to those IPv4 /24s.

   Clearly, there may be multiple non-overlapping IPv4 domains, multiple
   non-overlapping IPv6 domains, and there may be multiple IVI gateways.
   These are handled in a manner consistent with normal routing practice
   in the Internet.

   As shown in Figure 3, routing is slightly more complex in an IVI
   service, but follows simple routing concepts.  In this example,




Li, et al.               Expires March 20, 2009                 [Page 6]


Internet-Draft        IVI Update to SIIT and NAT-PT       September 2008


   o  IPv4 interfaces can open a session to any IVI address (e.g. 4Host1
      -> IVI1),

   o  IPv4 interfaces cannot open sessions to non-IVI IPv6 addresses
      (e.g. 4Host1 X-> 6Host1),

   o  IPv6 IVI interfaces can open a session to any IPv4 interface,
      statelessly (e.g.  IVI1 -> 4Host1),

   o  Non-IVI IPv6 hosts can open sessions to IPv4 interfaces,
      statefully (e.g. 6Host1 -> 4Host1),

   o  Any two IPv4 hosts can open a session to either each other using
      native routing (e.g. 4Host1 -> 4Host2, 4Host2 -> 4Host1),

   o  Any two IPv6 hosts can open a session to either each other using
      native routing, even using the IVI addresses (e.g. 6Host1 -> IVI1,
      IVI1 -> 6Host1, 6Host1 -> 6Host2, IVI1 -> IVI2).

                    -------------           ------------
                   / IPv4 Domain \         / IPv6 Domain \
                  /               \       /               \
                 /        |        \     /        | +----+ \
                /+------+ |         \   /         |-|IVI1|  \
               / |4Host1|-| +--+ |   \ /   | +--+ | +----+   \
              /  +------+ |-|R1|-|    V    |-|R3|-| +------+  \
              |           | +--+ |    |    | +--+ |-|6Host1|  |
              |                  | +-----+ |      | +------+  |
              |                  |-|XLATE|-|                  |
              |                  | +-----+ |                  |
              |           | +--+ |    |    | +--+ | +------+  |
              |  +------+ |-|R2|-|    |    |-|R4|-|-|6Host2|  |
              \  |4Host2|-| +--+ |    A    | +--+ | +------+  /
               \ +------+ |          / \          | +----+   /
                \         |         /   \         |-|IVI2|  /
                 \                 /     \        | +----+ /
                  \               /       \               /
                   ---------------         ---------------
              Route Advertisements:
                    R1: its IPv4 LAN        R3: its IPv6 LAN
                    R2: its IPv4 LAN        R3: its IVI /64
                    XLATE: IPv4 IVI prefix  R4: its IPv6 LAN
                    possible IPv4 overlay   R4: its IVI /64
                                prefix      XLATE:  IVI /40

                    Figure 3: IVI Reachability example





Li, et al.               Expires March 20, 2009                 [Page 7]


Internet-Draft        IVI Update to SIIT and NAT-PT       September 2008


2.4.  DNS service in IVI networks

   Rather than using the DNS Application Layer Gateway described in
   [RFC2766] as specified, the IVI DNS ALG is a one-way translation of A
   and MX records to AAAA records with a predictable address.  The DNS
   server may be in the gateway or in a separate system related to it.

   As illustrated in Figure 4, in the IPv4 domain, the DNS server holds
   and advertises A records for systems with IPv4 addresses and for
   systems (servers or peers) that have IVI addresses.  These are
   generally pre-populated, if only via Dynamic DNS.  The IPv4 network
   cannot distinguish them from other A records or from other IPv4
   addresses, so this works without host changes.
                  IPv4 Domain                 IPv6 Domain
                             |               |
              A/MX Request\  |               |  / AAAA Request
                           \ |    DNS ALG    | /
                            \|    as         |/
                            /|    Standard   |\
                           / |    DNS        | \
             A/MX Response/  |    Service    |  \ AAAA Response
                             |               |
                             |               |

                       Figure 4: Normal DNS Service

   Also as illustrated in Figure 4, in the IPv6 domain, the DNS server
   holds and advertises AAAA records in the usual fashion for systems
   with general IPv6 addresses.

   As illustrated in Figure 5, in the IPv6 domain, when the DNS ALG
   receives a request for a AAAA record for which it has nothing to
   reply, or for which normal DNS processing receives a failure, it
   obtains an A or MX record from its own database or another server,
   manufactures a corresponding AAAA record using an IVI address, and
   returns that.  The IPv6 network cannot distinguish between these and
   other AAAA records, or between these and any other address.  Routing
   takes traffic through the gateway without host changes.













Li, et al.               Expires March 20, 2009                 [Page 8]


Internet-Draft        IVI Update to SIIT and NAT-PT       September 2008


                IPv4 Domain                      IPv6 Domain
                              |               |
                              |               |    AAAA Request
                              |               |<---------
                              |               |
            A/MX Request      |               |
                <-------------|   DNS ALG     |
                              |   as IPv4     |
                              |   to IPv6     |
                ------------->|  translator   |
           A/MX Response      |               |
                              |               |
                              |               |--------->
                              |               |    AAAA Response
                              |               |
                              |               |

                 Figure 5: DNS Record Translation Service

   To avoid conflicts, the DNS server should have access to all AAAA
   records advertised in the IPv6 domain.  Otherwise, it may not know
   when to create AAAA records from A or MX records.

   An issue arises with Dynamic DNS, in that the IVI host will only know
   to post its IPv6 addresses.  The DNS service should store the AAAA
   records as generated by the host, and also generate an A record for
   each IVI address posted.  Whether the IVI address itself is stored as
   a AAAA record as well as in an A record is at the implementer's
   option; if it is not stored it will be created from the A record if
   needed.

2.5.  Host operation in IVI networks

   Host behavior is unchanged by this specification.  However, the local
   administration might want to configure host [RFC3484] address
   selection tables to optimize session behavior.

2.5.1.  Interaction of IVI Addresses with RFC3484 Address Selection

   [RFC3484] could be summarized as saying that IPv6 systems should
   select source and destination addresses that are as similar as
   possible.  "Similarity" is defined in terms of prefix length.  Each
   remote address is compared to each local address, and the remote
   address is considered to be most similar to the local address with
   the longest string of equivalent prefix bits.  The specification
   recommends that sessions between the two systems should prefer the
   address pair with the longest "similar" prefix.




Li, et al.               Expires March 20, 2009                 [Page 9]


Internet-Draft        IVI Update to SIIT and NAT-PT       September 2008


   For example, if Alice has the addresses

   o  2001:db8:1234:1::A and

   o  2001:db8:5678::A,

   and Bob has the following addresses

   o  2001:db8:1234:2::B and

   o  2001:db8:5ABC:B,

   2001:db8:1234:1::A is more similar to 2001:db8:1234:2::B (the first
   48 bits are the same as opposed to only the first 33) and 2001:db8:
   5678::A is more similar to 2001:db8:5ABC:B (the first 36 bits are the
   same as opposed to the first 33).  When Alice and Bob communicate,
   the default address policy selects the address pair in 2001:db8:
   1234::/48 over 2001:db8:5000::/36 because it has a longer "similar"
   prefix.

   IPv4-only systems connect to IPv6 systems having IVI addresses
   through the gateway, and lack a means to initiate a connection to
   other IPv6 systems.  Since IPv4 addresses appear in the IPv6 domain
   as IVI addresses, [RFC3484] will guide IPv6-only systems with IVI
   addresses to connect from their IVI address when communicating with
   IPv4-only systems, as they are the "most similar" addresses to those
   of their IPv4 counterparts.  This is important, because it promotes
   stateless translation operation.

   IVI systems may also find the IVI address pair "most similar" when
   communicating with other systems with IVI addresses.  This is
   acceptable, as to the IPv6 domain they are simply IPv6 addresses and
   will communicate directly.

   In general, a system with both an IPv4 address and an IPv6 address
   can connect to a similar system using either technology.  There need
   be no preference order, and if one is chosen that is a local matter.

2.5.2.  Interaction of IPv4 and IVI addresses on the same host

   Systems that have both native IPv4 and translated IVI addresses
   require attention to the configuration of the address choice
   mechanism described in [RFC3484].  In such a case, the redundancy
   suggests different uses for those addresses and the possibility that
   IPv4 reachability has been fragmented.

   For example, consider a host with a private IPv4 address and an IVI
   address attempting to open a session with an IPv4 system with a



Li, et al.               Expires March 20, 2009                [Page 10]


Internet-Draft        IVI Update to SIIT and NAT-PT       September 2008


   public address.  Apart from actually successfully opening a session,
   the addresses give no clue to actual reachability; the remote host
   might be reachable via IPv4, or that might be a private network
   disconnected from the Internet.  If the remote host is reachable,
   there is likely to be a NAT between the host and that system, making
   the point moot.  Similarly, the remote host might be reachable via
   IVI, but it might not.  It might be reachable via both
   simultaneously, and it might not be reachable at all.

   In general, native operation should be preferred to translated
   operation, but the specifics of the environment may guide this choice
   otherwise.  As such, if an application is unable to open a session
   using one address, it should try another, and the local
   administration may consider configuring the [RFC3484] tables to
   manage the case.

2.6.  Operation of the IVI Gateway

   The IVI Gateway has two modes, depending on the address of the IPv6
   system using its services.  These are the Stateless Mode, used to
   connect between IPv6-only systems with IVI addresses and IPv4
   systems, and the Stateful Mode, used to connect other (non-IVI) IPv6-
   only systems with IPv4 systems.  IPv6 routing should not take traffic
   between IPv6 systems in the same IPv6 domain through the gateway, as
   it will follow more specific routes.

   In either mode, the gateway is subject to the usual ills of Network
   Address Translation.  Protocols that exchange IP addresses should in
   general not be exchanged across an IVI gateway, as the addresses are
   not necessarily translatable or meaningful after translation.  Also,
   IPsec AH is compromised, so end-to-end privacy and authentication
   issues should be dealt with in another way such as IPsec ESP.

   In general, native (IPv6<->IPv6 or IPv4<->IPv4) communications are
   preferable to any form of translation, and stateless translation is
   preferable to stateful translation.  In the first case, this derives
   from the End-to-End principle discussed in [Saltzer] - the utility of
   the network to the applications that use it is generally maximized by
   staying out of their way.  In the latter case, this is due to the
   Simplicity Principle discussed in [RFC3439]; given an easy and a hard
   way to do something, and given equivalence of outcome, the easy way
   is generally better for all concerned.  Stateful and Stateless
   operation both enable communication at the cost of a header exchange.
   Stateful operation requires supporting dynamically-created per-flow
   tables in the gateway while stateless operation transforms datagrams
   algorithmically without per-flow state.





Li, et al.               Expires March 20, 2009                [Page 11]


Internet-Draft        IVI Update to SIIT and NAT-PT       September 2008


2.6.1.  Stateless (1:1) Operation

   In the stateless mode, the IVI gateway translates datagrams exchanged
   between IPv4 systems and IPv6 systems that have an IVI address.  The
   translation is as described in SIIT [RFC2765], with the exception
   that the address format is as described in Section 2.2 rather than
   the IPv4 Compatible Address described in section 2.1 of that document
   and deprecated in [RFC4291].  This includes the necessary correction
   of transport layer checksums.

   This is referred to as 'stateless', because the transformation
   between IPv4 and IPv6 communication is entirely algorithmic and
   requires no long-term state in either the hosts or the gateway.

2.6.2.  Stateful (1:n) Operation

   In the stateful mode, the IVI gateway operates as a standard Network
   Address Translator, but between IPv4 and IPv6 domains.  This is
   similar in many respects to the translation carried out in NAT-PT
   [RFC2766].  This includes the necessary correction of transport layer
   checksums.

   IPv4 addresses and port numbers are mapped to IPv6 addresses in a
   stateful manner, much as is done in IPv4-IPv4 network address
   translation.  The difference is that it is unidirectional; while the
   source port in an IPv6-> IPv4 translation may have to be changed to
   provide adequate flow identification, there is no necessity to change
   the source port in the IPv4->IPv6 direction.


3.  Transition plan

   Merriam-Webster defines a "transition" as "passage from one state,
   stage, subject, or place to another".  Any transition plan that it
   doesn't describe how one can expect to transition from an IPv4 to an
   IPv6 network using it is incomplete.  Coexistence is a necessary
   part, and is likely to last for a period of time measured in the
   durations of contracts.  But if the increased operations and capital
   expenditures implied in a state of IPv4+IPv6 coexistence doesn't
   ultimately lead to the reduced expenditure state of a single network,
   it has not solved the problem it was intended to address.

   In the IVI model, the network is presumed to traverse four relatively
   stable states.  These are:

   o  IPv4-only Network





Li, et al.               Expires March 20, 2009                [Page 12]


Internet-Draft        IVI Update to SIIT and NAT-PT       September 2008


   o  IPv4+IPv6 Dual Stack Network

   o  IPv6+IPv4-accessible Network

   o  IPv6 Network

3.1.  IPv4-only Network

   The Internet, by and large, runs on IPv4 today.  There are
   experimental uses of IPv6 and infrastructure uses of supporting
   internetwork protocols like MPLS and ATM, but end-to-end the protocol
   is IPv4.

3.2.  IPv4+IPv6 Dual Stack Network

   [RFC4213] recommends the deployment of a dual stack architecture.
   The reason is straightforward: if while we can map IPv4 and IPv6
   addresses 1:1 we aggressively deploy IPv6, we have two opportunities.
   First, should there be a problem (and there are always problems),
   user connectivity can be supported using IPv4 while the IPv6 issues
   are sorted out.  Second, at the point where the availability of IPv4
   addresses becomes a serious issue, IPv6 connectivity will be
   widespread, meaning that one can progress to the next phase rather
   than scrambling for business continuity.

   We presume that service providers and enterprise networks can deploy
   IPv6 in parallel with IPv4, enabling current hosts (which are mostly
   if not all IPv4+IPv6 capable) to communicate with either
   architecture.

3.3.  IPv6+IPv4-accessible Network

   The problem with Section 3.2 is that, although people have had
   warning, they have chosen to not make use of it.  Hence, we are
   likely to see an interval in the near future during which large
   numbers of IPv4 addresses are not available to extend services and
   IPv6 is not readily available as a deployed and purchasable service.

   In such a case, a service provider has two main choices: obtain what
   IPv4 addresses can be obtained at whatever cost they may be available
   and extend his IPv4 service lifetime for a limited time period, or
   obtain those addresses and use them in a strategic manner to
   encourage movement to IPv6.

   The IVI model suggests that remaining available IPv4 addresses could
   be mapped to IPv6 addresses in such a manner than both IPv4 and IPv6
   systems can access servers and peers using them.  A subscriber might
   be given an IPv6 /56 or /48 prefix for native use and a smaller IPv4



Li, et al.               Expires March 20, 2009                [Page 13]


Internet-Draft        IVI Update to SIIT and NAT-PT       September 2008


   /30 or /24 prefix for translated use for servers and peers, giving
   him an IPv6-only network whose servers and peers are available using
   IPv4 via translation.  Since the vast majority of systems operate as
   clients or as peer-to-peer application peers, this would in fact
   work.

3.4.  IPv6 Network

   At some point, enough systems have IPv6 addresses that it no longer
   makes economic sense to support the two networks in parallel.  At
   this point, one can expect customers to no longer purchase IPv4 or
   IVI connectivity, IPv4 and IVI services to become economically
   uninteresting, and a global IPv6-only network to emerge.


4.  Future extensions of the IVI Model

   If the IPv6 hosts can be modified, the IVI model can have a stateless
   (1:n)operation, which can support both IPv6 initiated communication
   as well as IPv4 initiated communication.

   For the operation and management concerns, the IVI model has ICMP
   extension, which can be used in the traceroute or similar cases.

   The IVI model can also support the use of multicast between IPv4 and
   IPv6.

   These extensions will be addressed in other documents.


5.  Reflections on RFC 4966

   RFCs [RFC4291] and [RFC4966] commented on the SIIT and NAT-PT
   proposals, and called for an improved proposal.  This note is in
   response to that request.  It would be of value to summarize the
   responses to the issues.

   The DNS Application layer Gateway used by IVI, described in
   Section 2.4, is essentially that of DNS64 [I-D.bagnulo-behave-nat64]
   apart from the exact format of the address.  NAT-PT has a problem
   with its DNS Application Layer gateway in that the overlay
   relationship between IPv4 addresses and ports and IPv6 addresses is
   dynamic, created when the RR is requested.  There are complexities,
   scoping, and timing issues with that approach.  The DNS Application
   Layer Gateway used by IVI could be configured as a completely static
   mapping, although that would not scale.  The form of the relationship
   between A/MX and AAAA records is algorithmic and fixed, and the
   translation is done on the fly without saved state.  So the DNS



Li, et al.               Expires March 20, 2009                [Page 14]


Internet-Draft        IVI Update to SIIT and NAT-PT       September 2008


   Application Layer Gateway is simpler and more predictable.

   The stateless data plane translation algorithm, described in
   Section 2.6.1, is essentially that of SIIT [RFC2765] apart from the
   address format.  As noted, [RFC4291] deprecated the address format
   with the brusque comment that "current IPv6 transition mechanisms no
   longer use these addresses."  The reason that they were not widely
   deployed was that they gave network operators little control in
   routing, or ways to ensure that route redistribution worked
   correctly.  A prefix that lets the LIR specify the upper bits gives
   the operator the flexibility to identify the IVI gateway advertising
   the prefix and better control the distribution of routes.  In
   addition, moving the IPv4-mapped portion of the IVI address into the
   upper 64 bits of the address enables and encourages the network
   operator to permit IPv4-capable systems to be in various places
   topologically while retaining an address format familiar from other
   IPv6 addresses.  The stateless mode applies to every session
   initiated from the IPv4 side of the gateway, as IVI does not provide
   DNS reachability to non-IVI addresses.  It also applies to sessions
   initiated from IVI addresses on the IPv6 side of the gateway.

   The stateful data plane algorithm, described in Section 2.6.2, is
   similar to that performed in normal IPv4/IPv4 NATs.  Traffic from a
   non-IVI IPv6 address is overlaid on an IPv4 address and disambiguated
   by the source port number, and traffic to that IPv4 address using
   that port number as its destination is mapped back to the IPv6
   address and port.  This is essentially the "Address+Port" model
   proposed in [APNAT].

   These three algorithms have two years of operational experience
   behind them in the CERNET/CNGI-CERNET2 network.  In a world of "rough
   consensus and running code", these are running code.

   Many of the issues raised in [RFC4966] are in fact not specific to
   NAT-PT, but are true of NATs in general and in particular NATs that
   translate between Internet Protocols with different address formats.
   In that sense, the document is not so much a complaint about NAT-PT
   as it is a complaint about translation.  IVI's stateful mode suffers
   many of the same limitations, as would any translator.  IVI's
   stateless mode suffers from less of them due to its stateless nature,
   but is nonetheless a translation and therefore breaks some of the
   end-to-end semantics of the Internet.


6.  IANA Considerations

   This memo adds no new IANA considerations.




Li, et al.               Expires March 20, 2009                [Page 15]


Internet-Draft        IVI Update to SIIT and NAT-PT       September 2008


   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.


7.  Security Considerations

   Three error cases are apparent: DNS errors, IPsec issues, and
   application address errors.

   As noted in Figure 4, the errors that happen in NAT-PT
   implementations can happen in an IVI network as well.  These mostly
   relate to the propagation of DNS records outside their domain of
   applicability.

   As noted in Section 2.6, the side-effects of Network Address
   Translation between IPv4 and IPv4 apply when translating between IPv4
   and IPv6.  IPsec AH, whose checksum covers the IP header, fails when
   the header is changed.  IPsec ESP, either directly on IP or over UDP
   are usable across NATs and presumably across translators as long as
   the IPv4 address is not in the certificate.

   Protocols that exchange IP addresses should not normally be used
   across a translator, as the addresses are generally not applicable on
   the far side.  Such protocols should be filtered, or permitted but
   used with care.

   [APNAT] raises a variety of issues with Carrier Grade Network Address
   Translators; those issues apply to the stateful mode of IVI, and in
   fact to any NAT.  The stateless mode mitigates most of the issues
   raised there, however.  If anything, this is the reason that we
   recommend dual stack deployment of IPv4 and IPv6 where possible in
   the near term, and target general IPv6 deployment in the medium term,
   as opposed to remaining in a dual address space environment forever.


8.  Acknowledgements

   Dan Wing and Tony Hain helped with the review of the document.


9.  References






Li, et al.               Expires March 20, 2009                [Page 16]


Internet-Draft        IVI Update to SIIT and NAT-PT       September 2008


9.1.  Normative References

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

9.2.  Informative References

   [APNAT]    Maennel, O., Bush, R., Cittadini, L., and S. Bellovin, "A
              Better Approach than Carrier-Grade-NAT", Aug 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-00 (work in
              progress), June 2008.

   [RFC3439]  Bush, R. and D. Meyer, "Some Internet Architectural
              Guidelines and Philosophy", RFC 3439, December 2002.

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

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

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

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

   [Saltzer]  Saltzer, JH., Reed, DP., and DD. Clark, "End-to-end
              arguments in system design", ACM Transactions on Computer
              Systems (TOCS) v.2 n.4, p277-288, Nov 1984.












Li, et al.               Expires March 20, 2009                [Page 17]


Internet-Draft        IVI Update to SIIT and NAT-PT       September 2008


Authors' Addresses

   Xing Li
   CERNET Center/Tsinghua University
   Room 225, Main Building, Tsinghua University
   Beijing,   100084
   China

   Phone: +86 62785983
   Email: xing@cernet.edu.cn


   Congxiao Bao
   CERNET Center/Tsinghua University
   Room 225, Main Building, Tsinghua University
   Beijing,   100084
   China

   Phone: +86 62785983
   Email: congxiao@cernet.edu.cn


   Fred Baker
   Cisco Systems
   Santa Barbara, California  93117
   USA

   Phone: +1 408 526 4257
   Email: fred@cisco.com


   Kevin Yin
   Cisco Systems
   No. 2 Jianguomenwai Ave, Chaoyang District
   Beijing,   100022
   China

   Phone: +86 10 8515 5094
   Email: kyin@cisco.com












Li, et al.               Expires March 20, 2009                [Page 18]


Internet-Draft        IVI Update to SIIT and NAT-PT       September 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.











Li, et al.               Expires March 20, 2009                [Page 19]


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