doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc6877.txt b/doc/rfc/rfc6877.txt
new file mode 100644
index 0000000..128efb1
--- /dev/null
+++ b/doc/rfc/rfc6877.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       M. Mawatari
+Request for Comments: 6877                       Japan Internet Exchange
+Category: Informational                                     M. Kawashima
+ISSN: 2070-1721                                 NEC AccessTechnica, Ltd.
+                                                                C. Byrne
+                                                            T-Mobile USA
+                                                              April 2013
+
+
+       464XLAT: Combination of Stateful and Stateless Translation
+
+Abstract
+
+   This document describes an architecture (464XLAT) for providing
+   limited IPv4 connectivity across an IPv6-only network by combining
+   existing and well-known stateful protocol translation (as described
+   in RFC 6146) in the core and stateless protocol translation (as
+   described in RFC 6145) at the edge. 464XLAT is a simple and scalable
+   technique to quickly deploy limited IPv4 access service to IPv6-only
+   edge networks without encapsulation.
+
+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/rfc6877.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mawatari, et al.              Informational                     [Page 1]
+
+RFC 6877                         464XLAT                      April 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  Motivation and Uniqueness of 464XLAT . . . . . . . . . . . . .  4
+   4.  Network Architecture . . . . . . . . . . . . . . . . . . . . .  4
+     4.1.  Wireline Network Architecture  . . . . . . . . . . . . . .  4
+     4.2.  Wireless 3GPP Network Architecture . . . . . . . . . . . .  5
+   5.  Applicability  . . . . . . . . . . . . . . . . . . . . . . . .  6
+     5.1.  Wireline Network Applicability . . . . . . . . . . . . . .  6
+     5.2.  Wireless 3GPP Network Applicability  . . . . . . . . . . .  7
+   6.  Implementation Considerations  . . . . . . . . . . . . . . . .  7
+     6.1.  IPv6 Address Format  . . . . . . . . . . . . . . . . . . .  7
+     6.2.  IPv4/IPv6 Address Translation Chart  . . . . . . . . . . .  7
+     6.3.  IPv6 Prefix Handling . . . . . . . . . . . . . . . . . . .  9
+     6.4.  DNS Proxy Implementation . . . . . . . . . . . . . . . . .  9
+     6.5.  CLAT in a Gateway  . . . . . . . . . . . . . . . . . . . .  9
+     6.6.  CLAT-to-CLAT Communications  . . . . . . . . . . . . . . . 10
+   7.  Deployment Considerations  . . . . . . . . . . . . . . . . . . 10
+     7.1.  Traffic Engineering  . . . . . . . . . . . . . . . . . . . 10
+     7.2.  Traffic Treatment Scenarios  . . . . . . . . . . . . . . . 10
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 12
+   Appendix A.  Examples of IPv4/IPv6 Address Translation . . . . . . 13
+
+
+
+
+
+
+
+
+
+Mawatari, et al.              Informational                     [Page 2]
+
+RFC 6877                         464XLAT                      April 2013
+
+
+1.  Introduction
+
+   With the exhaustion of the unallocated IPv4 address pools, it will be
+   difficult for many networks to assign IPv4 addresses to end users.
+
+   This document describes an IPv4-over-IPv6 solution as one of the
+   techniques for IPv4 service extension and encouragement of IPv6
+   deployment. 464XLAT is not a one-for-one replacement of full IPv4
+   functionality.  The 464XLAT architecture only supports IPv4 in the
+   client-server model, where the server has a global IPv4 address.
+   This means it is not fit for IPv4 peer-to-peer communication or
+   inbound IPv4 connections. 464XLAT builds on IPv6 transport and
+   includes full any-to-any IPv6 communication.
+
+   The 464XLAT architecture described in this document uses IPv4/IPv6
+   translation standardized in [RFC6145] and [RFC6146].  It does not
+   require DNS64 [RFC6147] since an IPv4 host may simply send IPv4
+   packets, including packets to an IPv4 DNS server, that will be
+   translated to IPv6 on the customer-side translator (CLAT) and back to
+   IPv4 on the provider-side translator (PLAT).  464XLAT networks may
+   use DNS64 [RFC6147] to enable single stateful translation [RFC6146]
+   instead of 464XLAT double translation where possible.  The 464XLAT
+   architecture encourages the IPv6 transition by making IPv4 services
+   reachable across IPv6-only networks and providing IPv6 and IPv4
+   connectivity to single-stack IPv4 or IPv6 servers and peers.
+
+2.  Terminology
+
+   PLAT:   PLAT is provider-side translator (XLAT) that complies with
+           [RFC6146].  It translates N:1 global IPv6 addresses to global
+           IPv4 addresses, and vice versa.
+
+   CLAT:   CLAT is customer-side translator (XLAT) that complies with
+           [RFC6145].  It algorithmically translates 1:1 private IPv4
+           addresses to global IPv6 addresses, and vice versa.  The CLAT
+           function is applicable to a router or an end-node such as a
+           mobile phone.  The CLAT should perform IP routing and
+           forwarding to facilitate packets forwarding through the
+           stateless translation even if it is an end-node.  The CLAT as
+           a common home router or wireless Third Generation Partnership
+           Project (3GPP) router is expected to perform gateway
+           functions such as being a DHCP server and DNS proxy for local
+           clients.  The CLAT uses different IPv6 prefixes for CLAT-side
+           and PLAT-side IPv4 addresses and therefore does not comply
+           with the sentence "Both IPv4-translatable IPv6 addresses and
+           IPv4-converted IPv6 addresses SHOULD use the same prefix." in
+
+
+
+
+
+Mawatari, et al.              Informational                     [Page 3]
+
+RFC 6877                         464XLAT                      April 2013
+
+
+           Section 3.3 of [RFC6052].  The CLAT does not facilitate
+           communications between a local IPv4-only node and an IPv6-
+           only node on the Internet.
+
+3.  Motivation and Uniqueness of 464XLAT
+
+   The list below describes the motivation for 464XLAT and its unique
+   characteristics.
+
+   o  464XLAT has minimal IPv4 resource requirements and maximum IPv4
+      efficiency through statistical multiplexing.
+
+   o  No new protocols are required; there is quick deployment.
+
+   o  IPv6-only networks are simpler and therefore less expensive to
+      operate than dual-stack networks.
+
+   o  464XLAT has consistent native IP-based monitoring and traffic
+      engineering.  Capacity-planning techniques can be applied without
+      the indirection or obfuscation of a tunnel.
+
+4.  Network Architecture
+
+   Examples of 464XLAT architectures are shown in the figures in the
+   following sections.
+
+   Wireline Network Architecture can be used in situations where there
+   are clients behind the CLAT, regardless of the type of access service
+   -- for example, fiber to the home (FTTH), Data Over Cable Service
+   Interface Specification (DOCSIS), or WiFi.
+
+   Wireless 3GPP Network Architecture can be used in situations where a
+   client terminates the wireless access network and possibly acts as a
+   router with tethered clients.
+
+4.1.  Wireline Network Architecture
+
+   The private IPv4 host in this diagram can reach global IPv4 hosts via
+   translation on both the CLAT and PLAT.  On the other hand, the IPv6
+   host can reach other IPv6 hosts on the Internet directly without
+   translation.  This means that the Customer Premises Equipment (CPE) /
+   CLAT can not only have the function of a CLAT but also the function
+   of an IPv6 native router for native IPv6 traffic.  In this diagram,
+   the v4p host behind the CLAT has [RFC1918] addresses.
+
+
+
+
+
+
+
+Mawatari, et al.              Informational                     [Page 4]
+
+RFC 6877                         464XLAT                      April 2013
+
+
+                                 +------+
+                                 |  v6  |
+                                 | host |
+                                 +--+---+
+                                    |
+                                .---+---.
+                               /         \
+                              /   IPv6    \
+                             |  Internet   |
+                              \           /
+                               `----+----'
+                                    |
+   +------+   |                 .---+---.                    .------.
+   |  v6  +---+   +------+     /         \     +------+     /        \
+   | host |   |   |      |    /   IPv6    \    |      |    /   IPv4   \
+   +------+   +---+ CLAT +---+   Network   +---+ PLAT +---+  Internet  |
+   +--------+ |   |      |    \           /    |      |    \           /
+   | v4p/v6 +-+   +------+     `---------'     +------+     `----+----'
+   |  host  | |                                                  |
+   +--------+ |                                               +--+---+
+   +------+   |                                               | v4g  |
+   | v4p  +---+                                               | host |
+   | host |   |                                               +------+
+   +------+   |
+
+          <- v4p -> XLAT <--------- v6 --------> XLAT <- v4g ->
+
+     v6  : Global IPv6
+     v4p : Private IPv4
+     v4g : Global IPv4
+
+                    Figure 1: Wireline Network Topology
+
+4.2.  Wireless 3GPP Network Architecture
+
+   The CLAT function on the User Equipment (UE) provides an [RFC1918]
+   address and IPv4 default route to the local node's network stack.
+   The applications on the UE can use the private IPv4 address for
+   reaching global IPv4 hosts via translation on both the CLAT and the
+   PLAT.  On the other hand, reaching IPv6 hosts (including hosts
+   presented via DNS64 [RFC6147]) does not require the CLAT function on
+   the UE.
+
+   Presenting a private IPv4 network for tethering via NAT44 and
+   stateless translation on the UE is also an application of the CLAT.
+
+
+
+
+
+
+Mawatari, et al.              Informational                     [Page 5]
+
+RFC 6877                         464XLAT                      April 2013
+
+
+                                  +------+
+                                  |  v6  |
+                                  | host |
+                                  +--+---+
+                                     |
+                                 .---+---.
+                                /         \
+                               /   IPv6    \
+                              |   Internet  |
+                               \           /
+      UE / Mobile Phone         `---------'
+   +----------------------+          |
+   | +----+    |          |      .---+---.                   .------.
+   | | v6 +----+   +------+     /         \     +------+    /        \
+   | +----+    |   |      |    / IPv6 PDP  \    |      |   /   IPv4   \
+   |           +---+ CLAT +---+ Mobile Core +---+ PLAT +--+  Internet  |
+   |           |   |      |    \    GGSN   /    |      |   \          /
+   |           |   +------+     \         '     +------+    `----+---'
+   | +-----+   |          |      `-------'                       |
+   | | v4p +---+          |                                   +--+---+
+   | +-----+   |          |                                   | v4g  |
+   +----------------------+                                   | host |
+                                                              +------+
+
+           <- v4p -> XLAT <--------- v6 --------> XLAT <- v4g ->
+
+     v6   : Global IPv6
+     v4p  : Private IPv4
+     v4g  : Global IPv4
+     PDP  : Packet Data Protocol
+     GGSN : Gateway GPRS Support Node
+
+                 Figure 2: Wireless 3GPP Network Topology
+
+5.  Applicability
+
+5.1.  Wireline Network Applicability
+
+   When an Internet Service Provider (ISP) has IPv6 access service and
+   provides 464XLAT, the ISP can provide outgoing IPv4 service to end
+   users across an IPv6 access network.  The result is that edge network
+   growth is no longer tightly coupled to the availability of scarce
+   IPv4 addresses.
+
+   If another ISP operates the PLAT, the edge ISP is only required to
+   deploy an IPv6 access network.  All ISPs do not need IPv4 access
+   networks.  They can migrate their access network to a simple and
+   highly scalable IPv6-only environment.
+
+
+
+Mawatari, et al.              Informational                     [Page 6]
+
+RFC 6877                         464XLAT                      April 2013
+
+
+5.2.  Wireless 3GPP Network Applicability
+
+   At the time of writing, in April 2013, the vast majority of mobile
+   networks are compliant to Pre-Release 9 3GPP standards.  In Pre-
+   Release 9 3GPP networks, Global System for Mobile Communications
+   (GSM) and Universal Mobile Telecommunications System (UMTS) networks
+   must signal and support both IPv4 and IPv6 Packet Data Protocol (PDP)
+   attachments to access IPv4 and IPv6 network destinations [RFC6459].
+   Since there are two PDPs required to support two address families,
+   this is double the number of PDPs required to support the status quo
+   of one address family, which is IPv4.
+
+   For the cases of connecting to an IPv4 literal or IPv4 socket that
+   require IPv4 connectivity, the CLAT function on the UE provides a
+   private IPv4 address and IPv4 default route on the host for the
+   applications to reference and bind to.  Connections sourced from the
+   IPv4 interface are immediately routed to the CLAT function and passed
+   to the IPv6-only mobile network, destined for the PLAT.  In summary,
+   the UE performs the CLAT function that does a stateless translation
+   [RFC6145], but only when required by an IPv4-only scenario such as
+   IPv4 literals or IPv4-only sockets.  The mobile network has a PLAT
+   that does stateful translation [RFC6146].
+
+   464XLAT works with today's existing systems as much as possible.
+   464XLAT is compatible with existing solutions for network-based deep
+   packet inspection like 3GPP standardized Policy and Charging Control
+   (PCC) [TS.23203].
+
+6.  Implementation Considerations
+
+6.1.  IPv6 Address Format
+
+   The IPv6 address format in 464XLAT is defined in Section 2.2 of
+   [RFC6052].
+
+6.2.  IPv4/IPv6 Address Translation Chart
+
+   This chart offers an explanation about address translation
+   architecture using a combination of stateful translation at the PLAT
+   and stateless translation at the CLAT.  The client on this chart is
+   delegated an IPv6 prefix from a prefix delegation mechanism such as
+   DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633]; therefore, it has a
+   dedicated IPv6 prefix for translation.
+
+
+
+
+
+
+
+
+Mawatari, et al.              Informational                     [Page 7]
+
+RFC 6877                         464XLAT                      April 2013
+
+
+                                           Destination IPv4 address
+                                          +----------------------------+
+                                          | Global IPv4 address        |
+                                          | assigned to IPv4 server    |
+                               +--------+ +----------------------------+
+                               |  IPv4  |  Source IPv4 address
+                               | server | +----------------------------+
+                               +--------+ | Global IPv4 address        |
+                                   ^      | assigned to IPv4 PLAT pool |
+                                   |      +----------------------------+
+                               +--------+
+                               |  PLAT  | Stateful XLATE(IPv4:IPv6=1:n)
+                               +--------+
+                                   ^
+                                   |
+                              (IPv6 cloud)
+         Destination IPv6 address
+        +--------------------------------------------------------------+
+        | IPv4-embedded IPv6 address                                   |
+        | defined in Section 2.2 of RFC 6052                           |
+        +--------------------------------------------------------------+
+         Source IPv6 address
+        +--------------------------------------------------------------+
+        | IPv4-embedded IPv6 address                                   |
+        | defined in Section 2.2 of RFC 6052                           |
+        +--------------------------------------------------------------+
+                              (IPv6 cloud)
+                                   ^
+                                   |
+                               +--------+
+                               |  CLAT  | Stateless XLATE(IPv4:IPv6=1:1)
+                               +--------+
+                                   ^       Destination IPv4 address
+                                   |      +----------------------------+
+                               +--------+ | Global IPv4 address        |
+                               |  IPv4  | | assigned to IPv4 server    |
+                               | client | +----------------------------+
+                               +--------+  Source IPv4 address
+                                          +----------------------------+
+                                          | Private IPv4 address       |
+                                          | assigned to IPv4 client    |
+                                          +----------------------------+
+
+          Figure 3: Case of Enabling Only Stateless XLATE on CLAT
+
+
+
+
+
+
+
+Mawatari, et al.              Informational                     [Page 8]
+
+RFC 6877                         464XLAT                      April 2013
+
+
+6.3.  IPv6 Prefix Handling
+
+   There are two relevant IPv6 prefixes that the CLAT must be aware of.
+
+   First, CLAT must know its own IPv6 prefixes.  The CLAT should acquire
+   a /64 for the uplink interface, a /64 for all downlink interfaces,
+   and a dedicated /64 prefix for the purpose of sending and receiving
+   statelessly translated packets.  When a dedicated /64 prefix is not
+   available for translation from DHCPv6-PD [RFC3633], the CLAT may
+   perform NAT44 for all IPv4 LAN packets so that all the LAN-originated
+   IPv4 packets appear from a single IPv4 address and are then
+   statelessly translated to one interface IPv6 address that is claimed
+   by the CLAT via the Neighbor Discovery Protocol (NDP) and defended
+   with Duplicate Address Detection (DAD).
+
+   Second, the CLAT must discover the PLAT-side translation IPv6 prefix
+   used as a destination of the PLAT.  The CLAT will use this prefix as
+   the destination of all translation packets that require stateful
+   translation to the IPv4 Internet.  It may discover the PLAT-side
+   translation prefix using [Discovery-Heuristic].  In the future, some
+   other mechanisms, such as a new DHCPv6 option, will possibly be
+   defined to communicate the PLAT-side translation prefix.
+
+6.4.  DNS Proxy Implementation
+
+   The CLAT should implement a DNS proxy as defined in [RFC5625].  The
+   case of an IPv4-only node behind the CLAT querying an IPv4 DNS server
+   is undesirable since it requires both stateful and stateless
+   translation for each DNS lookup.  The CLAT should set itself as the
+   DNS server via DHCP or other means and should proxy DNS queries for
+   IPv4 and IPv6 LAN clients.  Using the CLAT-enabled home router or UE
+   as a DNS proxy is a normal consumer gateway function and simplifies
+   the traffic flow so that only IPv6 native queries are made across the
+   access network.  DNS queries from the client that are not sent to the
+   DNS proxy on the CLAT must be allowed and are translated and
+   forwarded just like any other IP traffic.
+
+6.5.  CLAT in a Gateway
+
+   The CLAT feature can be implemented in a common home router or mobile
+   phone that has a tethering feature.  Routers with a CLAT feature
+   should also provide common router services such as DHCP of [RFC1918]
+   addresses, DHCPv6, NDP with Router Advertisement, and DNS service.
+
+
+
+
+
+
+
+
+Mawatari, et al.              Informational                     [Page 9]
+
+RFC 6877                         464XLAT                      April 2013
+
+
+6.6.  CLAT-to-CLAT Communications
+
+   464XLAT is a hub and spoke architecture focused on enabling IPv4-only
+   services over IPv6-only networks.  Interactive Connectivity
+   Establishment (ICE) [RFC5245] may be used to support peer-to-peer
+   communication within a 464XLAT network.
+
+7.  Deployment Considerations
+
+7.1.  Traffic Engineering
+
+   Even if the ISP for end users is different from the PLAT provider
+   (e.g., another ISP), it can implement traffic engineering
+   independently from the PLAT provider.  Detailed reasons are below:
+
+   1.  The ISP for end users can figure out the IPv4 destination address
+       from the translated IPv6 packet header, so it can implement
+       traffic engineering based on the IPv4 destination address (e.g.,
+       traffic monitoring for each IPv4 destination address, packet
+       filtering for each IPv4 destination address, etc.).  The
+       tunneling methods do not have such an advantage, without any deep
+       packet inspection for processing the inner IPv4 packet of the
+       tunnel packet.
+
+   2.  If the ISP for end users can assign an IPv6 prefix greater than
+       /64 to each subscriber, this 464XLAT architecture can separate
+       the IPv6 prefix for native IPv6 packets and the XLAT prefixes for
+       IPv4/IPv6 translation packets.  Accordingly, it can identify the
+       type of packets ("native IPv6 packets" and "IPv4/IPv6 translation
+       packets") and implement traffic engineering based on the IPv6
+       prefix.
+
+7.2.  Traffic Treatment Scenarios
+
+   The below table outlines how different permutations of connectivity
+   are treated in the 464XLAT architecture.
+
+   Note: 464XLAT double translation treatment will be stateless when a
+   dedicated /64 is available for translation on the CLAT.  Otherwise,
+   the CLAT will have both stateful and stateless since it requires
+   NAT44 from the LAN to a single IPv4 address and then stateless
+   translation to a single IPv6 address.
+
+
+
+
+
+
+
+
+
+Mawatari, et al.              Informational                    [Page 10]
+
+RFC 6877                         464XLAT                      April 2013
+
+
+        +--------+-------------+-----------------------+-------------+
+        | Server | Application |   Traffic Treatment   | Location of |
+        |        | and Host    |                       | Translation |
+        +--------+-------------+-----------------------+-------------+
+        |  IPv6  |    IPv6     |    End-to-End IPv6    |    None     |
+        +--------+-------------+-----------------------+-------------+
+        |  IPv4  |    IPv6     | Stateful Translation  |    PLAT     |
+        +--------+-------------+-----------------------+-------------+
+        |  IPv4  |    IPv4     |        464XLAT        |  PLAT/CLAT  |
+        +--------+-------------+-----------------------+-------------+
+
+                        Traffic Treatment Scenarios
+
+8.  Security Considerations
+
+   To implement a PLAT, see the security considerations presented in
+   Section 5 of [RFC6146].
+
+   To implement a CLAT, see the security considerations presented in
+   Section 7 of [RFC6145].  The CLAT may comply with [RFC6092].
+
+9.  Acknowledgements
+
+   The authors would like to thank JPIX NOC members, JPIX 464XLAT trial
+   service members, Seiichi Kawamura, Dan Drown, Brian Carpenter, Rajiv
+   Asati, Washam Fan, Behcet Sarikaya, Jan Zorz, Tatsuya Oishi, Lorenzo
+   Colitti, Erik Kline, Ole Troan, Maoke Chen, Gang Chen, Tom Petch,
+   Jouni Korhonen, Bjoern A. Zeeb, Hemant Singh, Vizdal Ales, Mark ZZZ
+   Smith, Mikael Abrahamsson, Tore Anderson, Teemu Savolainen, Alexandru
+   Petrescu, Gert Doering, Victor Kuarsingh, Ray Hunter, James Woodyatt,
+   Tom Taylor, and Remi Despres for their helpful comments.  We also
+   would like to thank Fred Baker and Joel Jaeggli for their support.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
+              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
+              October 2010.
+
+   [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.
+
+
+
+
+Mawatari, et al.              Informational                    [Page 11]
+
+RFC 6877                         464XLAT                      April 2013
+
+
+10.2.  Informative References
+
+   [Discovery-Heuristic]
+              Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
+              the IPv6 Prefix Used for IPv6 Address Synthesis", Work
+              in Progress, March 2013.
+
+   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
+              E. Lear, "Address Allocation for Private Internets",
+              BCP 5, RFC 1918, February 1996.
+
+   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
+              Host Configuration Protocol (DHCP) version 6", RFC 3633,
+              December 2003.
+
+   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
+              (ICE): A Protocol for Network Address Translator (NAT)
+              Traversal for Offer/Answer Protocols", RFC 5245,
+              April 2010.
+
+   [RFC5625]  Bellis, R., "DNS Proxy Implementation Guidelines",
+              BCP 152, RFC 5625, August 2009.
+
+   [RFC6092]  Woodyatt, J., "Recommended Simple Security Capabilities in
+              Customer Premises Equipment (CPE) for Providing
+              Residential IPv6 Internet Service", RFC 6092,
+              January 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.
+
+   [RFC6459]  Korhonen, J., Soininen, J., Patil, B., Savolainen, T.,
+              Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
+              Partnership Project (3GPP) Evolved Packet System (EPS)",
+              RFC 6459, January 2012.
+
+   [TS.23203] 3GPP, "Policy and charging control architecture", 3GPP
+              TS 23.203 10.7.0, June 2012.
+
+
+
+
+
+
+
+
+
+
+
+Mawatari, et al.              Informational                    [Page 12]
+
+RFC 6877                         464XLAT                      April 2013
+
+
+Appendix A.  Examples of IPv4/IPv6 Address Translation
+
+   The following is an example of IPv4/IPv6 address translation on the
+   464XLAT architecture.
+
+   In the case that an IPv6 prefix greater than /64 is assigned to an
+   end user by such as DHCPv6-PD [RFC3633], the CLAT can use a dedicated
+   /64 from the assigned IPv6 prefix.
+
+      Host & configuration value
+   +------------------------------+
+   |           IPv4 server        |
+   |         [198.51.100.1]       |            IP packet header
+   +------------------------------+   +--------------------------------+
+                   ^                  | Destination IP address         |
+                   |                  | [198.51.100.1]                 |
+                   |                  | Source IP address              |
+                   |                  | [192.0.2.1]                    |
+   +------------------------------+   +--------------------------------+
+   |              PLAT            |                   ^
+   | IPv4 pool address            |                   |
+   | [192.0.2.1 - 192.0.2.100]    |                   |
+   | PLAT-side XLATE IPv6 prefix  |                   |
+   | [2001:db8:1234::/96]         |                   |
+   +------------------------------+   +--------------------------------+
+                   ^                  | Destination IP address         |
+                   |                  | [2001:db8:1234::198.51.100.1]  |
+                   |                  | Source IP address              |
+                   |                  | [2001:db8:aaaa::192.168.1.2]   |
+   +------------------------------+   +--------------------------------+
+   |              CLAT            |                   ^
+   | PLAT-side XLATE IPv6 prefix  |                   |
+   | [2001:db8:1234::/96]         |                   |
+   | CLAT-side XLATE IPv6 prefix  |                   |
+   | [2001:db8:aaaa::/96]         |                   |
+   +------------------------------+   +--------------------------------+
+                   ^                  | Destination IP address         |
+                   |                  | [198.51.100.1]                 |
+                   |                  | Source IP address              |
+                   |                  | [192.168.1.2]                  |
+   +------------------------------+   +--------------------------------+
+   |          IPv4 client         |
+   |        [192.168.1.2/24]      |
+   +------------------------------+
+   Delegated IPv6 prefix for client: 2001:db8:aaaa::/56
+
+
+
+
+
+
+Mawatari, et al.              Informational                    [Page 13]
+
+RFC 6877                         464XLAT                      April 2013
+
+
+Authors' Addresses
+
+   Masataka Mawatari
+   Japan Internet Exchange Co., Ltd.
+   KDDI Otemachi Building 19F, 1-8-1 Otemachi,
+   Chiyoda-ku, Tokyo  100-0004
+   JAPAN
+
+   Phone: +81 3 3243 9579
+   EMail: mawatari@jpix.ad.jp
+
+
+   Masanobu Kawashima
+   NEC AccessTechnica, Ltd.
+   800, Shimomata
+   Kakegawa-shi, Shizuoka  436-8501
+   JAPAN
+
+   Phone: +81 537 22 8274
+   EMail: kawashimam@vx.jp.nec.com
+
+
+   Cameron Byrne
+   T-Mobile USA
+   Bellevue, Washington  98006
+   USA
+
+   EMail: cameron.byrne@t-mobile.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mawatari, et al.              Informational                    [Page 14]
+