From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6877.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc6877.txt (limited to 'doc/rfc/rfc6877.txt') 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] + -- cgit v1.2.3