doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc6127.txt b/doc/rfc/rfc6127.txt
new file mode 100644
index 0000000..2ccddd7
--- /dev/null
+++ b/doc/rfc/rfc6127.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          J. Arkko
+Request for Comments: 6127                                      Ericsson
+Category: Informational                                      M. Townsley
+ISSN: 2070-1721                                                    Cisco
+                                                                May 2011
+
+
+           IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios
+
+Abstract
+
+   When IPv6 was designed, it was expected that the transition from IPv4
+   to IPv6 would occur more smoothly and expeditiously than experience
+   has revealed.  The growth of the IPv4 Internet and predicted
+   depletion of the free pool of IPv4 address blocks on a foreseeable
+   horizon has highlighted an urgent need to revisit IPv6 deployment
+   models.  This document provides an overview of deployment scenarios
+   with the goal of helping to understand what types of additional tools
+   the industry needs to assist in IPv4 and IPv6 co-existence and
+   transition.
+
+   This document was originally created as input to the Montreal co-
+   existence interim meeting in October 2008, which led to the
+   rechartering of the Behave and Softwire working groups to take on new
+   IPv4 and IPv6 co-existence work.  This document is published as a
+   historical record of the thinking at the time, but hopefully will
+   also help readers understand the rationale behind current IETF tools
+   for co-existence and transition.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6127.
+
+
+
+
+
+
+
+Arkko & Townsley              Informational                     [Page 1]
+
+RFC 6127               IPv4 and IPv6 Co-Existence               May 2011
+
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Scenarios .......................................................4
+      2.1. Reaching the IPv4 Internet .................................4
+           2.1.1. NAT444 ..............................................5
+           2.1.2. Distributed NAT .....................................6
+           2.1.3. Recommendation ......................................8
+      2.2. Running Out of IPv4 Private Address Space ..................9
+      2.3. Enterprise IPv6-Only Networks .............................11
+      2.4. Reaching Private IPv4-Only Servers ........................13
+      2.5. Reaching IPv6-Only Servers ................................14
+   3. Security Considerations ........................................16
+   4. Conclusions ....................................................16
+   5. References .....................................................17
+      5.1. Normative References ......................................17
+      5.2. Informative References ....................................17
+   Appendix A. Acknowledgments .......................................20
+
+1.  Introduction
+
+   This document was originally created as input to the Montreal
+   co-existence interim meeting in October 2008, which led to the
+   rechartering of the Behave and Softwire working groups to take on new
+   IPv4 and IPv6 co-existence work.  This document is published as a
+   historical record of the thinking at the time, but hopefully will
+   also help readers understand the rationale behind current IETF tools
+   for co-existence and transition.
+
+
+
+
+
+
+
+
+Arkko & Townsley              Informational                     [Page 2]
+
+RFC 6127               IPv4 and IPv6 Co-Existence               May 2011
+
+
+   When IPv6 was designed, it was expected that IPv6 would be enabled,
+   in part or in whole, while continuing to run IPv4 side-by-side on the
+   same network nodes and hosts.  This method of transition is referred
+   to as "dual-stack" [RFC4213] and has been the prevailing method
+   driving the specifications and available tools for IPv6 to date.
+
+   Experience has shown that large-scale deployment of IPv6 takes time,
+   effort, and significant investment.  With IPv4 address pool depletion
+   on the foreseeable horizon [HUSTON-IPv4], network operators and
+   Internet Service Providers are being forced to consider network
+   designs that no longer assume the same level of access to unique
+   global IPv4 addresses.  IPv6 alone does not alleviate this concern
+   given the basic assumption that all hosts and nodes will be dual-
+   stack until the eventual sunsetting of IPv4-only equipment.  In
+   short, the time-frames for the growth of the IPv4 Internet, the
+   universal deployment of dual-stack IPv4 and IPv6, and the final
+   transition to an IPv6-dominant Internet are not in alignment with
+   what was originally expected.
+
+   While dual-stack remains the most well-understood approach to
+   deploying IPv6 today, current realities dictate a re-assessment of
+   the tools available for other deployment models that are likely to
+   emerge.  In particular, the implications of deploying multiple layers
+   of IPv4 address translation need to be considered, as well as those
+   associated with translation between IPv4 and IPv6, which led to the
+   deprecation of [RFC2766] as detailed in [RFC4966].  This document
+   outlines some of the scenarios where these address and protocol
+   translation mechanisms could be useful, in addition to methods where
+   carrying IPv4 over IPv6 may be used to assist in transition to IPv6
+   and co-existence with IPv4.  We purposefully avoid a description of
+   classic dual-stack methods, as well as IPv6-over-IPv4 tunneling.
+   Instead, this document focuses on scenarios that are driving tools we
+   have historically not been developing standard solutions around.
+
+   It should be understood that the scenarios in this document represent
+   new deployment models and are intended to complement, and not
+   replace, existing ones.  For instance, dual-stack continues to be the
+   most recommended deployment model.  Note that dual-stack is not
+   limited to situations where all hosts can acquire public IPv4
+   addresses.  A common deployment scenario is running dual-stack on the
+   IPv6 side with public addresses, and on the IPv4 side with just one
+   public address and a traditional IPv4 NAT.  Generally speaking,
+   offering native connectivity with both IP versions is preferred over
+   the use of translation or tunneling mechanisms when sufficient
+   address space is available.
+
+
+
+
+
+
+Arkko & Townsley              Informational                     [Page 3]
+
+RFC 6127               IPv4 and IPv6 Co-Existence               May 2011
+
+
+2.  Scenarios
+
+   This section identifies five deployment scenarios that we believe
+   have a significant level of near-to-medium-term demand somewhere on
+   the globe.  We will discuss these in the following sections, while
+   walking through a bit of the design space to get an understanding of
+   the types of tools that could be developed to solve each.  In
+   particular, we want the reader to consider for each scenario what
+   type of new equipment must be introduced in the network, and where;
+   which nodes must be changed in some way; and which nodes must work
+   together in an interoperable manner via a new or existing protocol.
+
+   The five scenarios are:
+
+   o  Reaching the IPv4 Internet with less than one global IPv4 address
+      per subscriber or subscriber household available (Section 2.1).
+
+   o  Running a large network needing more addresses than those
+      available in private RFC 1918 address space (Section 2.2).
+
+   o  Running an IPv6-only network for operational simplicity as
+      compared to dual-stack, while still needing access to the global
+      IPv4 Internet for some, but not all, connectivity (Section 2.3).
+
+   o  Reaching one or more privately addressed IPv4-only servers via
+      IPv6 (Section 2.4).
+
+   o  Accessing IPv6-only servers from IPv4-only clients (Section 2.5).
+
+2.1.  Reaching the IPv4 Internet
+
+                    +----+                       +---------------+
+   IPv4 host(s)-----+ GW +------IPv4-------------| IPv4 Internet |
+                    +----+                       +---------------+
+
+   <---private v4--->NAT<--------------public v4----------------->
+
+                Figure 1: Accessing the IPv4 Internet Today
+
+   Figure 1 shows a typical model for accessing the IPv4 Internet today,
+   with the gateway device implementing a Network Address and Port
+   Translation (NAPT, or more simply referred to in this document as
+   NAT).  The NAT function serves a number of purposes, one of which is
+   to allow more hosts behind the gateway (GW) than there are IPv4
+   addresses presented to the Internet.  This multiplexing of IP
+   addresses comes at great cost to the original end-to-end model of the
+   Internet, but nonetheless is the dominant method of access today,
+   particularly to residential subscribers.
+
+
+
+Arkko & Townsley              Informational                     [Page 4]
+
+RFC 6127               IPv4 and IPv6 Co-Existence               May 2011
+
+
+   Taking the typical residential subscriber as an example, each
+   subscriber line is allocated one global IPv4 address for it to use
+   with as many devices as the NAT GW and local network can handle.  As
+   IPv4 address space becomes more constrained and without substantial
+   movement to IPv6, it is expected that service providers will be
+   pressured to assign a single global IPv4 address to multiple
+   subscribers.  Indeed, in some deployments this is already the case.
+
+2.1.1.  NAT444
+
+   When there is less than one address per subscriber at a given time,
+   address multiplexing must be performed at a location where visibility
+   to more than one subscriber can be realized.  The most obvious place
+   for this is within the service provider network itself, requiring the
+   service provider to acquire and operate NAT equipment to allow
+   sharing of addresses across multiple subscribers.  For deployments
+   where the GW is owned and operated by the customer, however, this
+   becomes operational overhead for the Internet Service Provider (ISP),
+   for which the ISP will no longer be able to rely on the customer and
+   the seller of the GW device.
+
+   This new address translation node has been termed a "Carrier Grade
+   NAT", or CGN [NISHITANI-CGN].  The CGN's insertion into the ISP
+   network is shown in Figure 2.
+
+                    +----+                   +---+  +-------------+
+   IPv4 host(s)-----+ GW +------IPv4---------+CGN+--+IPv4 Internet|
+                    +----+                   +---+  +-------------+
+
+   <---private v4--->NAT<----private v4------>NAT<----public v4--->
+
+                Figure 2: Employing Two NAT Devices: NAT444
+
+   This approach is known as "NAT444" or "Double-NAT" and is discussed
+   further in [NAT-PT].
+
+   It is important to note that while multiplexing of IPv4 addresses is
+   occurring here at multiple levels, there is no aggregation of NAT
+   state between the GW and the CGN.  Every flow that is originated in
+   the subscriber home is represented as duplicate state in the GW and
+   the CGN.  For example, if there are 4 PCs in a subscriber home, each
+   with 25 open TCP sessions, both the GW and the CGN must track 100
+   sessions each for that subscriber line.
+
+   NAT444 has the enticing property that it seems, at first glance, that
+   the CGN can be deployed without any change to the GW device or other
+   node in the network.  While it is true that a GW that can accept a
+   lease for a global IPv4 address would very likely accept a translated
+
+
+
+Arkko & Townsley              Informational                     [Page 5]
+
+RFC 6127               IPv4 and IPv6 Co-Existence               May 2011
+
+
+   IPv4 address as well, the CGN is neither transparent to the GW nor to
+   the subscriber.  In short, it is a very different service model to
+   offer a translated IPv4 address versus a global IPv4 address to a
+   customer.  While many things may continue to work in both
+   environments, some end-host applications may break, and GW port-
+   mapping functionality will likely cease to work reliably.  Further,
+   if addresses between the subscriber network and service provider
+   network overlap [ISP-SHARED-ADDR], ambiguous routes in the GW could
+   lead to misdirected or black-holed traffic.  Resolving this overlap
+   through allocation of new private address space is difficult, as many
+   existing devices rely on knowing what address ranges represent
+   private addresses [IPv4-SPACE-ISSUES].
+
+   Network operations that had previously been tied to a single IPv4
+   address for a subscriber would need to be considered when deploying
+   NAT444 as well.  These may include troubleshooting, operations,
+   accounting, logging and legal intercept, Quality of Service (QoS)
+   functions, anti-spoofing and security, backoffice systems, etc.
+   Ironically, some of these considerations overlap with the kinds of
+   considerations one needs to perform when deploying IPv6.
+
+   Consequences aside, NAT444 service is already being deployed in some
+   networks for residential broadband service.  It is safe to assume
+   that this trend will likely continue in the face of tightening IPv4
+   address availability.  The operational considerations of NAT444 need
+   to be well-documented.
+
+   NAT444 assumes that the global IPv4 address offered to a residential
+   subscriber today will simply be replaced with a single translated
+   address.  In order to try and circumvent performing NAT twice, and
+   since the address being offered is no longer a global address, a
+   service provider could begin offering a subnet of translated IPv4
+   addresses in hopes that the subscriber would route IPv4 in the GW
+   rather than NAT.  The same would be true if the GW was known to be an
+   IP-unaware bridge.  This makes assumptions on whether the ISP can
+   enforce policies, or even identify specific capabilities, of the GW.
+   Once we start opening the door to making changes at the GW, we have
+   increased the potential design space considerably.  The next section
+   covers the same problem scenario of reaching the IPv4 Internet in the
+   face of IPv4 address depletion, but with the added wrinkle that the
+   GW can be updated or replaced along with the deployment of a CGN (or
+   CGN-like) node.
+
+2.1.2.  Distributed NAT
+
+   Increasingly, service providers offering "triple-play" services own
+   and manage a highly functional GW in the subscriber home.  These
+   managed GWs generally have rather tight integration with the service
+
+
+
+Arkko & Townsley              Informational                     [Page 6]
+
+RFC 6127               IPv4 and IPv6 Co-Existence               May 2011
+
+
+   provider network and applications.  In these types of deployments, we
+   can begin to consider what other possibilities exist besides NAT444
+   by assuming cooperative functionality between the CGN and the GW.
+
+   If the connection between the GW and the CGN is a point-to-point link
+   (a common configuration between the GW and the "IP edge" in a number
+   of access architectures), NAT-like functionality may be "split"
+   between the GW and the CGN rather than performing NAT444 as described
+   in the previous section.
+
+                 one frac addr            one public addr
+                    +----+                   +---+  +-------------+
+   IPv4 host(s)-----+ GW +-----p2p link------+CGN+--+IPv4 Internet|
+                    +----+                   +---+  +-------------+
+
+   <---private v4--->            NAT             <----public v4--->
+                             (distributed,
+                           over a p2p link)
+
+                     Figure 3: Distributed-NAT Service
+
+   In this approach, multiple GWs share a common public IPv4 address,
+   but with separate, non-overlapping port ranges.  Each such address/
+   port range pair is defined as a "fractional address".  Each home
+   gateway can use the address as if it were its own public address,
+   except that only a limited port range is available to the gateway.
+   The CGN is aware of the port ranges, which may be assigned in
+   different ways, for instance during DHCP lease acquisition or
+   dynamically when ports are needed [v6OPS-APBP].  The CGN directs
+   traffic to the fractional address towards that subscriber's GW
+   device.  This method has the advantage that the more complicated
+   aspects of the NAT function (Application Level Gateways (ALGs), port
+   mapping, etc.) remain in the GW, augmented only by the restricted
+   port range allocated to the fractional address for that GW.  The CGN
+   is then free to operate in a fairly stateless manner, forwarding
+   traffic based on IP address and port ranges and not tracking any
+   individual flows from within the subscriber network.  There are
+   obvious scaling benefits to this approach within the CGN node, with
+   the tradeoff of complexity in terms of the number of nodes and
+   protocols that must work together in an interoperable manner.
+   Further, the GW is still receiving a global IPv4 address, albeit only
+   a "portion" of one in terms of available port usage.  There are still
+   outstanding questions in terms of how to handle protocols that run
+   directly over IP and cannot use the divided port number ranges, and
+   how to handle fragmented packets, but the benefit is that we are no
+   longer burdened by two layers of NAT as in NAT444.
+
+
+
+
+
+Arkko & Townsley              Informational                     [Page 7]
+
+RFC 6127               IPv4 and IPv6 Co-Existence               May 2011
+
+
+   Not all access architectures provide a natural point-to-point link
+   between the GW and the CGN to tie into.  Further, the CGN may not be
+   incorporated into the IP edge device in networks that do have point-
+   to-point links.  For these cases, we can build our own point-to-point
+   link using a tunnel.  A tunnel is essentially a point-to-point link
+   that we create when needed [INTAREA-TUNNELS].  This is illustrated in
+   Figure 4.
+
+                 one frac addr            one public addr
+                    +----+                   +---+  +-------------+
+   IPv4 host(s)-----+ GW +======tunnel=======+CGN+--+IPv4 Internet|
+                    +----+                   +---+  +-------------+
+
+   <---private v4--->            NAT             <----public v4--->
+                            (distributed,
+                            over a tunnel)
+
+          Figure 4: Point-to-Point Link Created through a Tunnel
+
+   Figure 4 is essentially the same as Figure 3, except the data link is
+   created with a tunnel.  The tunnel could be created in any number of
+   ways, depending on the underlying network.
+
+   At this point, we have used a tunnel or point-to-point link with
+   coordinated operation between the GW and the CGN in order to keep
+   most of the NAT functionality in the GW.
+
+   Given the assumption of a point-to-point link between the GW and the
+   CGN, the CGN could perform the NAT function, allowing private,
+   overlapping space to all subscribers.  For example, each subscriber
+   GW may be assigned the same 10.0.0.0/8 address space (or all RFC 1918
+   [RFC1918] space for that matter).  The GW then becomes a simple
+   "tunneling router", and the CGN takes on the full NAT role.  One can
+   think of this design as effectively a layer-3 VPN, but with Virtual-
+   NAT tables rather than Virtual-Routing tables.
+
+2.1.3.  Recommendation
+
+   This section deals strictly with the problem of reaching the IPv4
+   Internet with limited public address space for each device in a
+   network.  We explored combining NAT functions and tunnels between the
+   GW and the CGN to obtain similar results with different design
+   tradeoffs.  The methods presented can be summarized as:
+
+   a. Double-NAT (NAT444)
+
+   b. Single-NAT at CGN with a subnet and routing at the GW
+
+
+
+
+Arkko & Townsley              Informational                     [Page 8]
+
+RFC 6127               IPv4 and IPv6 Co-Existence               May 2011
+
+
+   c. Tunnel/link + fractional IP (NAT at GW, port-routing at CGN)
+
+   d. Tunnel/link + Single-NAT with overlapping RFC 1918 ("Virtual NAT"
+      tables and routing at the GW)
+
+   In all of the methods above, the GW could be logically moved into a
+   single host, potentially eliminating one level of NAT by that action
+   alone.  As long as the hosts themselves need only a single IPv4
+   address, methods b and d obviously are of little interest.  This
+   leaves methods a and c as the more interesting methods in cases where
+   there is no analogous GW device (such as a campus network).
+
+   This document recommends the development of new guidelines and
+   specifications to address the above methods.  Cases where the home
+   gateway both can and cannot be modified should be addressed.
+
+2.2.  Running Out of IPv4 Private Address Space
+
+   In addition to public address space depletion, very large privately
+   addressed networks are reaching exhaustion of RFC 1918 space on local
+   networks as well.  Very large service provider networks are prime
+   candidates for this.  Private address space is used locally in ISPs
+   for a variety of things, including:
+
+   o  Control and management of service provider devices in subscriber
+      premises (cable modems, set-top boxes, and so on).
+
+   o  Addressing the subscriber's NAT devices in a Double-NAT
+      arrangement.
+
+   o  "Walled garden" data, voice, or video services.
+
+   Some providers deal with this problem by dividing their network into
+   parts, each on its own copy of the private space.  However, this
+   limits the way services can be deployed and what management systems
+   can reach what devices.  It is also operationally complicated in the
+   sense that the network operators have to understand which private
+   scope they are in.
+
+   Tunnels were used in the previous section to facilitate distribution
+   of a single global IPv4 address across multiple endpoints without
+   using NAT, or to allow overlapping address space to GWs or hosts
+   connected to a CGN.  The kind of tunnel or link was not specified.
+   If the tunnel used carries IPv4 over IPv6, the portion of the IPv6
+   network traversed naturally need not be IPv4-capable, and need not
+   utilize IPv4 addresses, private or public, for the tunnel traffic to
+   traverse the network.  This is shown in Figure 5.
+
+
+
+
+Arkko & Townsley              Informational                     [Page 9]
+
+RFC 6127               IPv4 and IPv6 Co-Existence               May 2011
+
+
+                            IPv6-only network
+                    +----+                     +---+  +-------------+
+   IPv4 host--------+ GW +=======tunnel========+CGN+--+IPv4 Internet|
+                    +----+                     +---+  +-------------+
+
+   <---private v4---->  <-----  v4 over v6 ----->  <---public v4---->
+
+             Figure 5: Running IPv4 over an IPv6-Only Network
+
+   Each of the four approaches (a, b, c, and d) from the Section 2.1
+   scenario could be applied here, and for brevity each iteration is not
+   specified in full here.  The models are essentially the same, just
+   that the tunnel is over an IPv6 network and carries IPv4 traffic.
+   Note that while there are numerous solutions for carrying IPv6 over
+   IPv4, this reverse mode is somewhat of an exception (one notable
+   exception being the Softwire working group, as seen in [RFC4925]).
+
+   Once we have IPv6 to the GW (or host, if we consider the GW embedded
+   in the host), enabling IPv6 and IPv4 over the IPv6 tunnel allows for
+   dual-stack operation at the host or network behind the GW device.
+   This is depicted in Figure 6:
+
+                   +----+                               +-------------+
+     IPv6 host-----+    |            +------------------+IPv6 Internet|
+                   |    +---IPv6-----+                  +-------------+
+   dual-stack host-+ GW |
+                   |    |                        +---+  +-------------+
+     IPv4 host-----+    +===v4-over-v6 tunnel====+CGN+--+IPv4 Internet|
+                   +----+                        +---+  +-------------+
+
+   <-----------private v4 (partially in tunnel)-->NAT<---public v4---->
+   <-----------------------------public v6---------------------------->
+
+      Figure 6: "Dual-Stack Lite" Operation over an IPv6-Only Network
+
+   In [DUAL-STACK-LITE], this is referred to as "dual-stack lite",
+   bowing to the fact that it is dual-stack at the gateway, but not at
+   the network.  As introduced in Section 2.1, if the CGN here is a full
+   functioning NAT, hosts behind a dual-stack lite gateway can support
+   IPv4-only and IPv6-enabled applications across an IPv6-only network
+   without provisioning a unique IPv4 address to each gateway.  In fact,
+   every gateway may have the same address.
+
+   While the high-level problem space in this scenario is how to
+   alleviate local usage of IPv4 addresses within a service provider
+   network, the solution direction identified with IPv6 has interesting
+   operational properties that should be pointed out.  By tunneling IPv4
+   over IPv6 across the service provider network, the separate problems
+
+
+
+Arkko & Townsley              Informational                    [Page 10]
+
+RFC 6127               IPv4 and IPv6 Co-Existence               May 2011
+
+
+   of transitioning the service provider network to IPv6, deploying IPv6
+   to subscribers, and continuing to provide IPv4 service can all be
+   decoupled.  The service provider could deploy IPv6 internally, turn
+   off IPv4 internally, and still carry IPv4 traffic across the IPv6
+   core for end users.  In the extreme case, all of that IPv4 traffic
+   need not be provisioned with different IPv4 addresses for each
+   endpoint, as there is not IPv4 routing or forwarding within the
+   network.  Thus, there are no issues with IPv4 renumbering, address
+   space allocation, etc. within the network itself.
+
+   It is recommended that the IETF develop tools to address this
+   scenario for both a host and the GW.  It is assumed that both
+   endpoints of the tunnel can be modified to support these new tools.
+
+2.3.  Enterprise IPv6-Only Networks
+
+   This scenario is about allowing an IPv6-only host or a host that has
+   no interfaces connected to an IPv4 network to reach servers on the
+   IPv4 Internet.  This is an important scenario for what we sometimes
+   call "greenfield" deployments.  One example is an enterprise network
+   that wishes to operate only IPv6 for operational simplicity, but
+   still wishes to reach the content in the IPv4 Internet.  For
+   instance, a new office building may be provisioned with IPv6 only.
+   This is shown in Figure 7.
+
+                             +----+                  +-------------+
+                             |    +------------------+IPv6 Internet+
+                             |    |                  +-------------+
+   IPv6 host-----------------+ GW |
+                             |    |                  +-------------+
+                             |    +------------------+IPv4 Internet+
+                             +----+                  +-------------+
+
+   <-------------------------public v6----------------------------->
+   <-------public v6--------->NAT<----------public v4-------------->
+
+                  Figure 7: Enterprise IPv6-Only Network
+
+   Other cases that have been mentioned include "greenfield" wireless
+   service provider networks and sensor networks.  This enterprise IPv6-
+   only scenario bears a striking resemblance to the Section 2.2
+   scenario as well, if one considers a particularly large enterprise
+   network that begins to resemble a service provider network.
+
+   In the Section 2.2 scenario, we dipped into design space enough to
+   illustrate that the service provider was able to implement an IPv6-
+   only network to ease their addressing problems via tunneling.  This
+   came at the cost of touching two devices on the edges of this
+
+
+
+Arkko & Townsley              Informational                    [Page 11]
+
+RFC 6127               IPv4 and IPv6 Co-Existence               May 2011
+
+
+   network; both the GW and the CGN have to support IPv6 and the
+   tunneling mechanism over IPv6.  The greenfield enterprise scenario is
+   different from that one in the sense that there is only one place
+   that the enterprise can easily modify: the border between its network
+   and the IPv4 Internet.  Obviously, the IPv4 Internet operates the way
+   it already does.  But in addition, the hosts in the enterprise
+   network are commercially available devices, personal computers with
+   existing operating systems.  While we consider in this scenario that
+   all of the devices on the network are "modern" dual-stack-capable
+   devices, we do not want to have to rely upon kernel-level
+   modifications to these operating systems.  This restriction drives us
+   to a "one box" type of solution, where IPv6 can be translated into
+   IPv4 to reach the public Internet.  This is one situation where new
+   or improved IETF specifications could have an effect on the user
+   experience in these networks.  In fairness, it should be noted that
+   even a network-based solution will take time and effort to deploy.
+   This is essentially, again, a tradeoff between one new piece of
+   equipment in the network, or a cooperation between two.
+
+   One approach to deal with this environment is to provide an
+   application-level proxy at the edge of the network (GW).  For
+   instance, if the only application that needs to reach the IPv4
+   Internet is the web, then an HTTP/HTTPS proxy can easily convert
+   traffic from IPv6 into IPv4 on the outside.
+
+   Another more generic approach is to employ an IPv6-to-IPv4 translator
+   device.  Different types of translation schemes are discussed in
+   [NAT-PT], [RFC6144], [RFC6145], and [RFC6052].  NAT64 is one example
+   of a translation scheme falling under this category [RFC6147]
+   [RFC6146].
+
+   Translation will in most cases have some negative consequences for
+   the end-to-end operation of Internet protocols.  For instance, the
+   issues with Network Address Translation - Protocol Translation
+   (NAT-PT) [RFC2766] have been described in [RFC4966].  It is important
+   to note that the choice of translation solution, and the assumptions
+   about the network in which it is used, impact the consequences.  A
+   translator for the general case has a number of issues that a
+   translator for a more specific situation may not have at all.
+
+   It is recommended that the IETF develop tools to address this
+   scenario.  These tools need to allow existing IPv6 hosts to operate
+   unchanged.
+
+
+
+
+
+
+
+
+Arkko & Townsley              Informational                    [Page 12]
+
+RFC 6127               IPv4 and IPv6 Co-Existence               May 2011
+
+
+2.4.  Reaching Private IPv4-Only Servers
+
+   This section discusses the specific problem of IPv4-only-capable
+   server farms that no longer can be allocated a sufficient number of
+   public addresses.  It is expected that for individual servers,
+   addresses are going to be available for a long time in a reasonably
+   easy manner.  However, a large server farm may require a large enough
+   block of addresses that it is either not feasible to allocate one or
+   it becomes economically desirable to use the addresses for other
+   purposes.
+
+   Another use case for this scenario involves a service provider that
+   is capable of acquiring a sufficient number of IPv4 addresses, and
+   has already done so.  However, the service provider also simply
+   wishes to start to offer an IPv6 service but without yet touching the
+   server farm (that is, without upgrading the server farm to IPv6).
+
+   One option available in such a situation is to move those servers and
+   their clients to IPv6.  However, moving to IPv6 involves not just the
+   cost of the IPv6 connectivity, but the cost of moving the application
+   itself from IPv4 to IPv6.  So, in this case, the server farm is IPv4-
+   only, there is an increasing cost for IPv4 connectivity, and there is
+   an expensive bill for moving server infrastructure to IPv6.  What can
+   be done?
+
+   If the clients are IPv4-only as well, the problem is a hard one.
+   This issue is dealt with in more depth in Section 2.5.  However,
+   there are important cases where large sets of clients are IPv6-
+   capable.  In these cases, it is possible to place the server farm in
+   private IPv4 space and arrange some of the gateway service from IPv6
+   to IPv4 to reach the servers.  This is shown in Figure 8.
+
+                                     +----+
+   IPv6 host(s)-------(Internet)-----+ GW +------Private IPv4 servers
+                                     +----+
+
+   <---------public v6--------------->NAT<------private v4---------->
+
+             Figure 8: Reaching Servers in Private IPv4 Space
+
+   One approach to implement this is to use NAT64 to translate IPv6 into
+   private IPv4 addresses.  The private IPv4 addresses are mapped into
+   IPv6 addresses within one or more known prefixes.  The GW at the edge
+   of the server farm is aware of the mapping, as is the Domain Name
+
+
+
+
+
+
+
+Arkko & Townsley              Informational                    [Page 13]
+
+RFC 6127               IPv4 and IPv6 Co-Existence               May 2011
+
+
+   System (DNS).  AAAA records for each server name are given an IPv6
+   address that corresponds to the mapped private IPv4 address.  Thus,
+   each privately addressed IPv4 server is given a public IPv6
+   presentation.  No Application Level Gateway for DNS (DNS-ALG) is
+   needed in this case, contrary to what NAT-PT would require, for
+   instance.
+
+   This is very similar to the Section 2.3 scenario where we typically
+   think of a small site with IPv6 needing to reach the public IPv4
+   Internet.  The difference here is that we assume not a small IPv6
+   site, but the whole of the IPv6 Internet needing to reach a small
+   IPv4 site.  This example was driven by the enterprise network with
+   IPv4 servers, but could be scaled down to the individual subscriber
+   home level as well.  Here, the same technique could be used to, say,
+   access an IPv4 webcam in the home from the IPv6 Internet.  All that
+   is needed is the ability to update AAAA records appropriately, an
+   IPv6 client (which could use Teredo [RFC4380] or some other method to
+   obtain IPv6 reachability), and the NAT64 mechanism.  In this sense,
+   this method looks much like a "NAT/firewall bypass" function.
+
+   An argument could be made that since the host is likely dual-stack,
+   existing port-mapping services or NAT traversal techniques could be
+   used to reach the private space instead of IPv6.  This would have to
+   be done anyway if the hosts are not all IPv6-capable or connected.
+   However, in cases where the hosts are all IPv6-capable, the
+   alternative techniques force additional limitations on the use of
+   port numbers.  In the case of IPv6-to-IPv4 translation, the full port
+   space would be available for each server, even in the private space.
+
+   It is recommended that the IETF develop tools to address this
+   scenario.  These tools need to allow existing IPv4 servers to operate
+   unchanged.
+
+2.5.  Reaching IPv6-Only Servers
+
+   This scenario is predicted to become increasingly important as IPv4
+   global connectivity sufficient for supporting server-oriented content
+   becomes significantly more difficult to obtain than global IPv6
+   connectivity.  Historically, the expectation has been that for
+   connectivity to IPv6-only devices, devices would either need to be
+   IPv6-connected, or dual-stack with the ability to set up an IPv6-
+   over-IPv4 tunnel in order to access the IPv6 Internet.  Many "modern"
+   device stacks have this capability, and for them this scenario does
+   not present a problem as long as a suitable gateway to terminate the
+   tunnel and route the IPv6 packets is available.  But, for the server
+   operator, it may be a difficult proposition to leave all IPv4-only
+   devices without reachability.  Thus, if a solution for IPv4-only
+   devices to reach IPv6-only servers were realizable, the benefits
+
+
+
+Arkko & Townsley              Informational                    [Page 14]
+
+RFC 6127               IPv4 and IPv6 Co-Existence               May 2011
+
+
+   would be clear.  Not only could servers move directly to IPv6 without
+   trudging through a difficult dual-stack period, but they could do so
+   without risk of losing connectivity with the IPv4-only Internet.
+
+   Unfortunately, realizing this goal is complicated by the fact that
+   IPv4 to IPv6 is considered "hard" since of course IPv6 has a much
+   larger address space than IPv4.  Thus, representing 128 bits in
+   32 bits is not possible, barring the use of techniques similar to
+   NAT64, which uses IPv6 addresses to represent IPv4 addresses as well.
+
+   The main questions regarding this scenario are about timing and
+   priority.  While the expectation that this scenario may be of
+   importance one day is readily acceptable, at the time of this
+   writing, there are few or no IPv6-only servers of importance (beyond
+   some contrived cases) that the authors are aware of.  The difficulty
+   of making a decision about this case is that, quite possibly, when
+   there is sufficient pressure on IPv4 such that we see IPv6-only
+   servers, the vast majority of hosts will either have IPv6
+   connectivity or the ability to tunnel IPv6 over IPv4 in one way or
+   another.
+
+   This discussion makes assumptions about what a "server" is as well.
+   For the majority of applications seen on the IPv4 Internet to date,
+   this distinction has been more or less clear.  This clarity is
+   perhaps in no small part due to the overhead today in creating a
+   truly end-to-end application in the face of the fragmented addressing
+   and reachability brought on by the various NATs and firewalls
+   employed today.  However, current notions of a "server" are beginning
+   to shift, as we see more and more pressure to connect people to one
+   another in an end-to-end fashion -- with peer-to-peer techniques, for
+   instance -- rather than simply content server to client.  Thus, if we
+   consider an "IPv6-only server" as what we classically consider an
+   "IPv4 server" today, there may not be a lot of demand for this in the
+   near future.  However, with a more distributed model of the Internet
+   in mind, there may be more opportunities to employ IPv6-only
+   "servers" that we would normally extrapolate from based on past
+   experience with applications.
+
+   It is recommended that the IETF address this scenario, though perhaps
+   with a slightly lower priority than the others.  In any case, when
+   new tools are developed to support this, it should be obvious that we
+   cannot assume any support for updating legacy IPv4 hosts in order to
+   reach the IPv6-only servers.
+
+
+
+
+
+
+
+
+Arkko & Townsley              Informational                    [Page 15]
+
+RFC 6127               IPv4 and IPv6 Co-Existence               May 2011
+
+
+3.  Security Considerations
+
+   Security aspects of the individual solutions are discussed in more
+   depth elsewhere, for instance in [DUAL-STACK-LITE], [RFC6144],
+   [RFC6147], [RFC6145], [RFC6146], [NAT-PT], and [RFC4966].  This
+   document highlights just three issues:
+
+   o  Any type of translation may have an impact on how certain
+      protocols can pass through.  For example, IPsec needs support for
+      NAT traversal, and the proliferation of NATs implies an even
+      higher reliance on these mechanisms.  It may also require
+      additional support for new types of translation.
+
+   o  Some solutions have a need to modify results obtained from DNS.
+      This may have an impact on DNS security, as discussed in
+      [RFC4966].  Minimization or even elimination of such problems is
+      essential, as discussed in [RFC6147].
+
+   o  Tunneling solutions have their own security issues, for instance
+      the need to secure tunnel endpoint discovery or to avoid opening
+      up denial-of-service or reflection vulnerabilities [RFC6169].
+
+4.  Conclusions
+
+   The authors believe that the scenarios outlined in this document are
+   among the top of the list of those that should be addressed by the
+   IETF community in short order.  For each scenario, there are clearly
+   different solution approaches with implementation, operations, and
+   deployment tradeoffs.  Further, some approaches rely on existing or
+   well-understood technology, while some require new protocols and
+   changes to established network architecture.  It is essential that
+   these tradeoffs be considered, understood by the community at large,
+   and in the end well-documented as part of the solution design.
+
+   After writing the initial version of this document, the Softwire
+   working group was rechartered to address the Section 2.2 scenario
+   with a combination of existing tools (tunneling, IPv4 NATs) and some
+   minor new ones (DHCP options) [DUAL-STACK-LITE].  Similarly, the
+   Behave working group was rechartered to address scenarios from
+   Sections 2.3, 2.4, and 2.5.  At the time this document is being
+   published, proposals to address scenarios from Section 2.1 are still
+   under consideration for new IETF work items.
+
+   This document set out to list scenarios that are important for the
+   Internet community.  While it introduces some design elements in
+   order to understand and discuss tradeoffs, it does not list detailed
+   requirements.  In large part, the authors believe that exhaustive and
+   detailed requirements would not be helpful at the expense of
+
+
+
+Arkko & Townsley              Informational                    [Page 16]
+
+RFC 6127               IPv4 and IPv6 Co-Existence               May 2011
+
+
+   embarking on solutions, given our current state of affairs.  We do
+   not expect any of the solutions to be perfect when measured from all
+   vantage points.  When looking for opportunities to deploy IPv6,
+   reaching too far for perfection could result in losing these
+   opportunities if we are not attentive.  Our goal with this document
+   is to support the development of tools to help minimize the tangible
+   problems that we are experiencing now, as well as those problems that
+   we can best anticipate down the road, in hopes of steering the
+   Internet on its best course from here.
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.,
+              and E. Lear, "Address Allocation for Private Internets",
+              BCP 5, RFC 1918, February 1996.
+
+   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
+              for IPv6 Hosts and Routers", RFC 4213, October 2005.
+
+5.2.  Informative References
+
+   [RFC2766]  Tsirtsis, G. and P. Srisuresh, "Network Address
+              Translation - Protocol Translation (NAT-PT)", RFC 2766,
+              February 2000.
+
+   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
+              Network Address Translations (NATs)", RFC 4380,
+              February 2006.
+
+   [RFC4925]  Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
+              Problem Statement", RFC 4925, July 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.
+
+   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
+              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
+              October 2010.
+
+   [NAT-PT]   Wing, D., Ward, D., and A. Durand, "A Comparison of
+              Proposals to Replace NAT-PT", Work in Progress,
+              September 2008.
+
+
+
+
+
+
+Arkko & Townsley              Informational                    [Page 17]
+
+RFC 6127               IPv4 and IPv6 Co-Existence               May 2011
+
+
+   [DUAL-STACK-LITE]
+              Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
+              Stack Lite Broadband Deployments Following IPv4
+              Exhaustion", Work in Progress, May 2011.
+
+   [RFC6144]  Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
+              IPv4/IPv6 Translation", RFC 6144, April 2011.
+
+   [RFC6145]  Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
+              Algorithm", RFC 6145, April 2011.
+
+   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
+              NAT64: Network Address and Protocol Translation from IPv6
+              Clients to IPv4 Servers", RFC 6146, April 2011.
+
+   [RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. van
+              Beijnum, "DNS64: DNS Extensions for Network Address
+              Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
+              April 2011.
+
+   [INTAREA-TUNNELS]
+              Touch, J. and M. Townsley, "Tunnels in the Internet
+              Architecture", Work in Progress, March 2010.
+
+   [v6OPS-APBP]
+              Despres, R., "A Scalable IPv4-IPv6 Transition Architecture
+              Need for an Address-Port-Borrowing-Protocol (APBP)", Work
+              in Progress, July 2008.
+
+   [HUSTON-IPv4]
+              Huston, G., "IPv4 Address Report", available
+              at http://www.potaroo.net, December 2010.
+
+   [NISHITANI-CGN]
+              Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
+              A., and H. Ashida, "Common Requirements for IP Address
+              Sharing Schemes", Work in Progress, March 2011.
+
+   [ISP-SHARED-ADDR]
+              Yamagata, I., Miyakawa, S., Nakagawa, A., Yamaguchi, J.,
+              and H. Ashida, "ISP Shared Address", Work in Progress,
+              September 2010.
+
+
+
+
+
+
+
+
+
+Arkko & Townsley              Informational                    [Page 18]
+
+RFC 6127               IPv4 and IPv6 Co-Existence               May 2011
+
+
+   [IPv4-SPACE-ISSUES]
+              Azinger, M. and L. Vegoda, "Issues Associated with
+              Designating Additional Private IPv4 Address Space", Work
+              in Progress, January 2011.
+
+   [RFC6169]  Krishnan, S., Thaler, D., and J. Hoagland, "Security
+              Concerns with IP Tunneling", RFC 6169, April 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arkko & Townsley              Informational                    [Page 19]
+
+RFC 6127               IPv4 and IPv6 Co-Existence               May 2011
+
+
+Appendix A.  Acknowledgments
+
+   Discussions with a number of people including Dave Thaler, Thomas
+   Narten, Marcelo Bagnulo, Fred Baker, Remi Despres, Lorenzo Colitti,
+   Dan Wing, and Brian Carpenter, and feedback during the Internet Area
+   open meeting at IETF 72, were essential to the creation of the
+   content in this document.
+
+Authors' Addresses
+
+   Jari Arkko
+   Ericsson
+   Jorvas  02420
+   Finland
+
+   EMail: jari.arkko@piuha.net
+
+
+   Mark Townsley
+   Cisco
+   Paris  75006
+   France
+
+   EMail: townsley@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arkko & Townsley              Informational                    [Page 20]
+