summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6877.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6877.txt')
-rw-r--r--doc/rfc/rfc6877.txt787
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]
+