summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6751.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6751.txt')
-rw-r--r--doc/rfc/rfc6751.txt1851
1 files changed, 1851 insertions, 0 deletions
diff --git a/doc/rfc/rfc6751.txt b/doc/rfc/rfc6751.txt
new file mode 100644
index 0000000..5626224
--- /dev/null
+++ b/doc/rfc/rfc6751.txt
@@ -0,0 +1,1851 @@
+
+
+
+
+
+
+Independent Submission R. Despres, Ed.
+Request for Comments: 6751 RD-IPtech
+Category: Experimental B. Carpenter
+ISSN: 2070-1721 Univ. of Auckland
+ D. Wing
+ Cisco
+ S. Jiang
+ Huawei Technologies Co., Ltd.
+ October 2012
+
+
+ Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)
+
+Abstract
+
+ In customer sites having IPv4-only Customer Premises Equipment (CPE),
+ Teredo (RFC 4380, RFC 5991, RFC 6081) provides last-resort IPv6
+ connectivity. However, because it is designed to work without the
+ involvement of Internet Service Providers, it has significant
+ limitations (connectivity between IPv6 native addresses and Teredo
+ addresses is uncertain; connectivity between Teredo addresses fails
+ for some combinations of NAT types). 6a44 is a complementary
+ solution that, being based on ISP cooperation, avoids these
+ limitations. At the beginning of 6a44 IPv6 addresses, it replaces
+ the Teredo well-known prefix, present at the beginning of Teredo IPv6
+ addresses, with network-specific /48 prefixes assigned by local ISPs
+ (an evolution similar to that from 6to4 to 6rd (IPv6 Rapid Deployment
+ on IPv4 Infrastructures)). The specification is expected to be
+ complete enough for running code to be independently written and the
+ solution to be incrementally deployed and used.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 1]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for examination, experimental implementation, and
+ evaluation.
+
+ This document defines an Experimental Protocol for the Internet
+ community. This is a contribution to the RFC Series, independently
+ of any other RFC stream. The RFC Editor has chosen to publish this
+ document at its discretion and makes no statement about its value for
+ implementation or deployment. Documents approved for publication by
+ the RFC Editor are not 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/rfc6751.
+
+Copyright Notice
+
+ Copyright (c) 2012 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 2]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Requirements Language ...........................................5
+ 3. Definitions .....................................................5
+ 4. Design Goals, Requirements, and Model of Operation ..............7
+ 4.1. Hypotheses about NAT Behavior ..............................7
+ 4.2. Native IPv6 Connectivity for Unmanaged Hosts behind
+ NAT44s .....................................................7
+ 4.3. Operational Requirements ...................................8
+ 4.4. Model of Operation .........................................9
+ 5. 6a44 Addresses .................................................12
+ 6. Specification of Clients and Relays ............................14
+ 6.1. Packet Formats ............................................14
+ 6.2. IPv6 Packet Encapsulations ................................14
+ 6.3. 6a44 Bubbles ..............................................14
+ 6.4. MTU Considerations ........................................16
+ 6.5. 6a44 Client Specification .................................16
+ 6.5.1. Tunnel Maintenance .................................16
+ 6.5.2. Client Transmission ................................19
+ 6.5.3. Client Reception ...................................20
+ 6.6. 6a44 Relay Specification ..................................23
+ 6.6.1. Relay Reception in IPv6 ............................23
+ 6.6.2. Relay Reception in IPv4 ............................24
+ 6.7. Implementation of Automatic Sunset ........................26
+ 7. Security Considerations ........................................26
+ 8. IANA Considerations ............................................30
+ 9. Acknowledgments ................................................30
+ 10. References ....................................................30
+ 10.1. Normative References .....................................30
+ 10.2. Informative References ...................................31
+
+1. Introduction
+
+ Although most Customer Premises Equipment (CPE) should soon be dual-
+ stack capable, a large installed base of IPv4-only CPEs is likely to
+ remain for several years. Their operation is based on IPv4-to-IPv4
+ NATs (NAT44s). Also, due to the IPv4 address shortage, more and more
+ Internet Service Providers (ISPs), and more and more mobile
+ operators, will assign private IPv4 addresses ([RFC1918]) to their
+ customers (the [NAT444] model). For rapid and extensive use of IPv6
+ [RFC2460], there is therefore a need for IPv6 connectivity behind
+ NAT44s, including those of the [NAT444] model.
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 3]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+ At the moment, there are two tunneling techniques specified for IPv6
+ connectivity behind NAT44s:
+
+ o Configured tunnels. These involve tunnel brokers with which users
+ must register [RFC3053]. Well-known examples include deployments
+ of the Hexago tool, and the SixXS collaboration, which are
+ suitable for IPv6 early trials. However, this approach is not
+ adequate for mass deployment: it imposes the restriction that even
+ if two hosts are in the same customer site, IPv6 packets between
+ them must transit via tunnel servers, which may be far away.
+
+ o Automatic Teredo tunnels [RFC4380] [RFC5991]. Teredo is specified
+ as a last-resort solution that, due to its objective to work
+ without local ISP involvement, has the following limitations:
+
+ * Connectivity between IPv6 native addresses and Teredo addresses
+ is uncertain. (As explained in [RFC4380] Section 8.3, this
+ connectivity depends on paths being available from all IPv6
+ native addresses to some Teredo relays. ISPs lack sufficient
+ motivations to ensure it.)
+
+ * Between two Teredo addresses, IPv6 connectivity fails for some
+ combinations of NAT44 types ([RFC6081] Section 3).
+
+ * According to [RFC4380] Section 5.2, each Teredo host has to be
+ configured with the IPv4 address of a Teredo server (a
+ constraint that can, however, be avoided in some
+ implementations).
+
+ 6a44 is designed to avoid Teredo limitations: with 6a44, ISPs can
+ participate in the solution. The approach for this is similar to the
+ approach that permitted 6rd [RFC5569] [RFC5969] to avoid the
+ limitations of 6to4 [RFC3056] [RFC3068]: at the beginning of IPv6
+ addresses, the Teredo well-known prefix is replaced by network-
+ specific prefixes assigned by local ISPs.
+
+ This document is organized as follows: terms used in the document are
+ defined in Section 3; design goals and model of operation are
+ presented in Section 4; Section 5 describes the format of 6a44 IPv6
+ addresses; Section 6 specifies in detail the behaviors of 6a44
+ clients and 6a44 relays; security and IANA considerations are covered
+ in Sections 7 and 8, respectively.
+
+ This specification is expected to be complete enough for running code
+ to be independently written and the solution to be incrementally
+ deployed and used. Its status is Experimental rather than Standards
+ Track, to reflect uncertainty as to which major Internet players may
+ be willing to support it.
+
+
+
+Despres, et al. Experimental [Page 4]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+2. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+3. Definitions
+
+ The following definitions are used in this document:
+
+ MAJOR NEW DEFINITIONS
+
+ 6a44 ISP network: An IPv4-capable ISP network that supports at least
+ one 6a44 relay. Additional conditions are that it assigns
+ individual IPv4 addresses to its customer sites (global or
+ private), that it supports ingress filtering [RFC2827], and that
+ its path MTUs are at least 1308 octets.
+
+ 6a44 relay: A node that supports the 6a44 relay function defined in
+ this document and that has interfaces to an IPv6-capable upstream
+ network and to an IPv4-capable downstream network.
+
+ 6a44 client: A host that supports the 6a44 client function defined
+ in this document and has no means other than 6a44 to have an IPv6
+ native address.
+
+ 6a44 tunnel: A tunnel established and maintained between a 6a44
+ client and 6a44 relays of its ISP network.
+
+ 6a44 bubble: A UDP/IPv4 packet sent from a 6a44 client to the
+ 6a44-relay address, or vice versa, and having a UDP payload that
+ cannot be confused with an IPv6 packet. In the client-to-relay
+ direction, it is a request for a response bubble. In the relay-
+ to-client direction, it conveys the up-to-date IPv6 prefix of the
+ client.
+
+ SECONDARY NEW DEFINITIONS
+
+ (This list is for reference and can be skipped by readers familiar
+ with the usual terminology.)
+
+ 6a44 service: The service offered by a 6a44 ISP network to its 6a44
+ clients.
+
+ 6a44-client IPv6 address: The IPv6 address of a 6a44 client. It is
+ composed of the client IPv6 prefix, received from a 6a44 relay,
+ followed by the client local IPv4 address.
+
+
+
+
+Despres, et al. Experimental [Page 5]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+ 6a44-client IPv6 prefix: For a 6a44 client, the IPv6 prefix (/96)
+ composed of the IPv6 prefix of the local 6a44 network (/48)
+ followed by the UDP/IPv4 mapped address of the client (32 +
+ 16 bits).
+
+ 6a44-client UDP/IPv4 mapped address: For a 6a44 client, the external
+ UDP/IPv4 address that, in the CPE NAT44 of the site, is that of
+ its 6a44 tunnel.
+
+ 6a44-client UDP/IPv4 local address: For a 6a44 client, the
+ combination of its local IPv4 address and the 6a44 port.
+
+ 6a44 port: UDP port 1027, reserved by IANA for 6a44 (see Section 8).
+
+ 6a44-relay UDP/IPv4 address: The UDP/IPv4 address composed of the
+ 6a44-relay anycast address and the 6a44 port.
+
+ 6a44-relay anycast address: IPv4 anycast address 192.88.99.2,
+ reserved by IANA for 6a44 (see Section 8).
+
+ 6a44-network IPv6 prefix: An IPv6 /48 prefix assigned by an ISP to a
+ 6a44 network.
+
+ USUAL DEFINITIONS
+
+ (This list is for reference and can be skipped by readers familiar
+ with the usual terminology.)
+
+ Upstream direction: For a network border node, the direction toward
+ the Internet core.
+
+ Downstream direction: For a network border node, the direction
+ toward end-user nodes (opposite to the upstream direction).
+
+ IPv4 private address: An address that starts with one of the three
+ [RFC1918] prefixes (10/8, 172.16/12, or 192.168/16).
+
+ IPv6 native address: An IPv6 global unicast address that starts with
+ an aggregatable prefix assigned to an ISP.
+
+ UDP/IPv4 address: The combination of an IPv4 address and a UDP port.
+
+ UDP/IPv4 packet: A UDP datagram contained in an IPv4 packet.
+
+ IPv6/UDP/IPv4 packet: An IPv6 packet contained in a UDP/IPv4 packet.
+
+
+
+
+
+
+Despres, et al. Experimental [Page 6]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+4. Design Goals, Requirements, and Model of Operation
+
+4.1. Hypotheses about NAT Behavior
+
+ 6a44 is designed to work with NAT44 behaviors identified in Section 3
+ of [RFC6081]. In particular, it has to work with endpoint-dependent
+ mappings as well as with endpoint-independent mappings, including
+ cases where there are dynamic changes from one mode to the other.
+
+ The only assumption is that, after a mapping has been established in
+ the NAT44, it is maintained as long as it is reused at least once, in
+ each direction, every 30 seconds.
+
+ NOTE: 30 seconds is the value used for the same mapping-maintenance
+ purpose in Teredo [RFC4380] and in SIP [RFC5626].
+
+4.2. Native IPv6 Connectivity for Unmanaged Hosts behind NAT44s
+
+ The objective remains that, as soon as possible, CPEs and ISPs
+ support IPv6 native prefixes. 6a44 is therefore designed only as a
+ temporary solution for hosts to obtain IPv6 native addresses in sites
+ whose CPEs are not IPv6 capable yet.
+
+ As noted in Section 1, IPv6 native addresses obtainable with
+ configured tunnels have important limitations. However, compared to
+ 6a44 addresses, they have the advantage of remaining unchanged in the
+ case of NAT44 reset. 6a44 therefore remains the last-resort solution
+ for IPv6 native addresses in unmanaged hosts of IPv4-only-CPE sites,
+ while configured tunnels may still be preferred for some managed
+ hosts if reported limitations of configured tunnels are judged to be
+ acceptable. As their scopes are different, the two solutions can
+ usefully coexist.
+
+ Note that Teredo remains a last-resort solution for hosts to have
+ IPv6 addresses where IPv6 native addresses cannot be made available
+ (and where Teredo limitations are judged to be acceptable).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 7]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+4.3. Operational Requirements
+
+ Operational requirements of 6a44 include the following:
+
+ Robust IPv6 connectivity: A node having a 6a44 address must have
+ paths across the Internet to and from all IPv6 native addresses
+ that are not subject to voluntary firewall filtering.
+
+ Intra-site path efficiency: Packets exchanged between 6a44 clients
+ that are behind the same CPE NAT44 must not have to traverse it.
+ If these clients have IPv4 connectivity using their private IPv4
+ addresses, they must also have IPv6 connectivity using their 6a44
+ addresses.
+
+ Plug-and-play operation of 6a44 clients: In order to obtain a 6a44
+ address from its local ISP, a 6a44 client must need no parameter
+ configuration.
+
+ Scalability of ISP functions: For the solution to be easily
+ scalable, ISP-supported functions have to be completely stateless.
+
+ Anti-spoofing protection: Where address anti-spoofing is ensured in
+ IPv4 with ingress filtering [RFC2827] [RFC3704], IPv6 addresses
+ must benefit from the same degree of anti-spoofing protection.
+
+ Overall operational simplicity: To paraphrase what Antoine de Saint-
+ Exupery said in [TheTool], "it seems that perfection is attained
+ not when there is nothing more to add, but when there is nothing
+ more to remove".
+
+ Incremental deployability: Hosts and ISP networks must be able to
+ become 6a44 capable independently of each other. IPv6 must be
+ operational where both are available, and there must be no
+ perceptible effect where they are not both available.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 8]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+4.4. Model of Operation
+
+ Operation of 6a44 involves two types of nodes: 6a44 clients and 6a44
+ relays. Figure 1 shows the two applicability scenarios:
+
+ o In the first one, IPv4 addresses assigned to customer sites are
+ global IPv4.
+
+ o In the second one, they are private IPv4 addresses (the [NAT444]
+ model, where ISPs operate one or several NAT44s, also called
+ Carrier-Grade NATs (CGNs)).
+
+ (A) GLOBAL IPv4 ISP NETWORK
+ +------------------+
+ 6a44 customer network(s) |GLOBAL IPv4 | Upstream
+ +-----------+ ---| MTU >= 1308 +--- IPv4 network
+ ---| Private | | ingress filtering| (<== no route
+ +----+ | IPv4 +-----+ | IPv6 optional | to 6a44 relays)
+ | |-----| |NAT44|----+ |
+ +----+ | +-----+ | +-------------+
+ 6a44 ---|MTU >= 1308| | --+6a44 relay(s)|--- Upstream
+ client(s) | no | ---| +-------------+ IPv6 network
+ |native IPv6| | |
+ +-----------+ +------------------+
+
+
+ (B) PRIVATE IPv4 ISP NETWORK
+ +------------------+
+ |PRIVATE IPv4 |
+ | as above |
+ ---| |
+ | +--------------+
+ | --+ ISP NAT44(s) |--- Upstream
+ as above ----+ +--------------+ IPv4 network
+ | |
+ | +--------------+
+ ---| --+6a44 relay(s) |--- Upstream
+ | +--------------+ IPv6 network
+ | |
+ +------------------+
+
+ Figure 1: 6a44 Applicability Scenarios
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 9]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+ In both configurations, the ISP network may also assign IPv6 prefixes
+ to customer sites:
+
+ o If customer sites are only assigned IPv4 addresses (IPv6 prefix
+ available neither natively nor with any tunnel), 6a44 applies not
+ only to sites whose CPEs are IPv4-only capable but also to those
+ whose CPEs are dual-stack capable.
+
+ o If customer sites are assigned both IPv4 addresses and IPv6
+ prefixes, 6a44 only applies to sites whose CPEs are IPv4-only
+ capable.
+
+ Figure 2 illustrates paths of IPv6 packets between a 6a44 client, A,
+ and various possible locations of remote hosts (E in the same site, F
+ in another 6a44 site of the same ISP, G in a non-6a44 IPv6 site of
+ the same ISP, D in an IPv6 site of another ISP). Between 6a44
+ clients of a same site, IPv6 packets are encapsulated in IPv4
+ packets. Those between 6a44 clients and 6a44 relays are encapsulated
+ in UDP/IPv4 packets.
+
+ 6a44 operates as follows (details in Section 6):
+
+ 1. A 6a44 client starts operation by sending a 6a44 bubble to the
+ 6a44-relay UDP/IPv4 address.
+
+ 2. When a 6a44 relay receives a bubble from one of its 6a44
+ clients, it returns to this client a bubble containing the IPv6
+ prefix of this client.
+
+ 3. When a 6a44 client receives a bubble from a 6a44 relay, it
+ updates (or confirms) its 6a44 address. It is an update if the
+ client has no IPv6 address yet or if, due to a CPE reset, this
+ address has changed. After receiving a bubble, a client is
+ ready to start, or to continue, IPv6 operation.
+
+ 4. When a 6a44 client having a 6a44 address has an IPv6 packet to
+ send whose destination IS in the same customer site, it
+ encapsulates it in an IPv4 packet whose destination is found in
+ the IPv6 destination address. It then sends the resulting IPv6/
+ IPv4 packet.
+
+ 5. When a 6a44 client receives a valid IPv6/IPv4 packet from a 6a44
+ client of the same site, it decapsulates the IPv6 packet and
+ submits it to further IPv6 processing.
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 10]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+ 6. When a 6a44 client having a 6a44 address has an IPv6 packet to
+ send whose destination IS NOT in the same customer site, it
+ encapsulates the packet in a UDP/IPv4 packet whose destination
+ is the 6a44-relay UDP/IPv4 address. It then sends the IPv6/UDP/
+ IPv4 packet.
+
+ 7. When a 6a44 relay receives via its IPv4 interface a valid IPv6/
+ UDP/IPv4 packet whose destination IS one of its 6a44 clients, it
+ forwards the contained IPv6 packet in a modified IPv6/UDP/IPv4
+ packet. The UDP/IPv4 destination of this packet is found in the
+ IPv6 destination address.
+
+ 8. When a 6a44 client receives a valid IPv6/UDP/IPv4 packet from a
+ 6a44 relay, it decapsulates the IPv6 packet and submits it to
+ further IPv6 processing.
+
+ 9. When a 6a44 relay receives via its IPv4 interface a valid IPv6/
+ UDP/IPv4 packet whose IPv6 destination IS NOT one of its 6a44
+ clients, it decapsulates the IPv6 packet and sends it via its
+ IPv6 interface.
+
+ 10. When a 6a44 relay receives via its IPv6 interface a valid IPv6
+ packet whose destination is one of its 6a44 clients, it
+ encapsulates the packet in a UDP/IPv4 packet whose destination
+ is the UDP/IPv4 address found in the IPv6 destination address.
+ It then sends the resulting IPv6/UDP/IPv4 packet via its IPv4
+ interface.
+
+ 11. To maintain the NAT44 mapping of its 6a44 tunnel, and to quickly
+ detect the need to change its 6a44 address in case of NAT44
+ reset, a 6a44 client from time to time sends a bubble to the
+ 6a44-relay address (see Section 6.5.1).
+
+ 12. When a 6a44 relay receives via its IPv4 interface an IPv6/UDP/
+ IPv4 packet whose IPv6 and UDP/IPv4 source addresses are not
+ consistent, it discards the invalid packet and returns a bubble
+ to the UDP/IPv4 source address. (This permits the 6a44 client
+ at this address to update its IPv6 address.)
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 11]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+ CUSTOMER +-------------------------+
+ SITES | ISP NETWORK |
+ +---------+ +----------------+ |
+ | | |6a44 ISP NETWORK| | GLOBAL
+ | | | | | INTERNET
+ HOSTS | IPv6/UDP/IPv4 +---------+ | HOST
+ +-+ | +-----+ | B| 6a44 |C/48| IPv6 +-+
+ |A|---|--.---|NAT44|----|----------.---------.----|--- - - - ---|D|
+ +-+ | \ +-----+ | /| relay(s)|\ | +-+
+ +-+ | / | | ' +---------+ ' |
+ |E|---|--' | | | | | |
+ +-+ IPv6/IPv4 | | | | | |
+ +---------+ | | | | |
+ | | | | |
+ +---------+ | | | | |
+ | IPv6/UDP/IPv4 . | | |
+ +-+ | +-----+ | / | | |
+ |F|---|------|NAT44|----|------' | | |
+ +-+ | +-----+ | | | |
+ | | +----------------+ | |
+ +---------+ | . |
+ +-+ | / |
+ |G|---- - - - - - - ----|--------------------' |
+ +-+ IPv6 | |
+ +-------------------------+
+
+ IPv6 PATHS A-D: D is IPv6 of another ISP
+ A-E: E is a 6a44 client in the same site
+ A-F: F is a 6a44 client in another site of the same ISP
+ A-G: G is IPv6 of the same ISP, other than 6a44
+
+ Figure 2: IPv6 Paths between 6a44 Hosts and Remote Hosts
+
+5. 6a44 Addresses
+
+ The 6a44 IPv6 address an ISP assigns to a host must contain all
+ pieces of information needed to reach it from other IPv6 addresses.
+ These pieces are described below and illustrated in Figure 3:
+
+ o the 6a44-network IPv6 prefix C (a /48 the ISP has assigned to its
+ 6a44 relays);
+
+ o the customer-site IPv4 address N (either global IPv4 or, if the
+ ISP uses a [NAT444] model, private IPv4);
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 12]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+ o the mapped port Z of the 6a44 tunnel (i.e., the external port
+ assigned by the NAT44 to the tunnel that the client maintains
+ between its UDP/IPv4 local address A:W and the 6a44-relay UDP/IPv4
+ address B:W);
+
+ o the client local IPv4 address A (i.e., the private IPv4 address
+ assigned to the client in its customer site; it is needed for
+ intra-site IPv6 connectivity).
+
+ Customer network ISP network
+ +--------------+ +------------------+
+ Client |IPv4 CPE |IPv4 |
+ +----+ | +-----+ | +----------+
+ | ^ |-----| |NAT44|----+ |6a44 relay|---- IPv6
+ +-|-^+ | +-----+ | +----------+^
+ | | | ^ | ^ | ^ | |
+ | | +----------|---+ | +---------|--------+ |
+ | | | ^ | | |
+ | | >0/0| | |N/32< | |
+ | | | | |
+ | | Mapping | |
+ | | <a:w>-<N:Z> (*) | |
+ | | | |
+ | |A:W< >B:W| |
+ | |
+ IPv6 |C.N.Z.A/128< |C/48<
+
+ (*) With NAT44(s) between client and CPE, a:w may differ from A:W
+
+
+ |0 47|48 79|80 95|96 127|
+ +-------+-------+-------+-------+-------+-------+-------+-------+
+ | 6a44-network | Customer-site |Tunnel | 6a44-client |
+ | IPv6 prefix | IPv4 address |mapped | local IPv4 |
+ | (C) | (N) |port(Z)| address (A) |
+ +-------+-------+-------+-------+-------+-------+-------+-------+
+ 6a44-client
+ <-- UDP/IPv4 address -->
+ <------------ 6a44-client IPv6 prefix --------->
+ <---------------- 6a44-client IPv6 address --------------------->
+
+ Figure 3: Host-Address Construction
+
+ NOTE: 6a44 addresses are not guaranteed to comply with the rule
+ listed in [RFC4291], according to which bits 64-127 of aggregatable
+ unicast addresses have to be in Modified-EUI-64 Interface Identifier
+ (IID) format. However, these bits within the 6a44 addresses are
+ interpreted only where 6a44 addresses are processed, i.e., in 6a44
+
+
+
+Despres, et al. Experimental [Page 13]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+ relays and clients. No operational problem is therefore foreseen.
+ Besides, because it is a purely transitional tool, it shouldn't
+ prevent any "development of future technology that can take advantage
+ of interface identifiers with universal scope" (the purpose of this
+ format, as expressed in [RFC4291].
+
+6. Specification of Clients and Relays
+
+6.1. Packet Formats
+
+6.2. IPv6 Packet Encapsulations
+
+ For NAT44 traversal, an IPv6 packet transmitted from a 6a44 client to
+ a 6a44 relay, or vice versa, is encapsulated in a UDP/IP packet whose
+ source and destination addresses are those of the two endpoints (A:W
+ and B:W in the notations of Figure 3). The IPv4 packet is that of a
+ complete datagram (its more-fragment bit is set to 0, its offset is
+ set to 0, and its datagram identification may be set to 0). The UDP
+ checksum is set to 0 (there is no need for an additional layer of
+ checksum protection). The length of the IPv6 packet SHOULD NOT
+ exceed 1280 octets (see Section 6.4).
+
+ Octets: |0 |20 |28 |68 |
+ +----------+---+-------------------+-------//-----+
+ | IPv4 |UDP| IPv6 header | IPv6 payload |
+ +----------+---+-------------------+-------//-----+
+
+ An IPv6 packet transmitted from a 6a44 client to another 6a44 client
+ of the same site is encapsulated in an IPv4 packet whose source and
+ destination addresses are the private IPv4 addresses of the two
+ hosts. The IPv4 packet is that of a complete datagram (its
+ more-fragment bit is set to 0, its offset is set to 0, and its
+ datagram identification may be set to 0). The size of the IPv6
+ packet SHOULD NOT exceed 1280 octets (see Section 6.4).
+
+ Octets: |0 |20 |60 |
+ +----------+-------------------+-------//-----+
+ | IPv4 | IPv6 header | IPv6 payload |
+ +----------+-------------------+-------//-----+
+
+6.3. 6a44 Bubbles
+
+ A "bubble" is a UDP/IPv4 packet whose UDP payload is comprised of a
+ "6a44-client IPv6 prefix" field and a "Bubble ID" field and whose UDP
+ checksum is set to 0. Having no UDP checksum protection in bubbles
+ is a simplification that is acceptable because bubble contents are
+
+
+
+
+
+Despres, et al. Experimental [Page 14]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+ regularly updated and non-critical (a client accepting a corrupted
+ IPv6 prefix never leads to any IPv6 packet being accepted by any
+ wrong destination).
+
+ "6a44-client IPv6 prefix" field
+ . from a 6a44 client = 0 (also denoted by ::/96)
+ . from a 6a44 relay = 6a44-client IPv6 prefix
+ |
+ Octets: |0 |20 |28| |40 |48
+ +----------+---+--|-+---+
+ | IPv4 |UDP| . | . |
+ +----------+---+----+-|-+
+ |
+ "Bubble ID" field
+ . from a 6a44 client: a client-selected value
+ . from a 6a44 relay:
+ - in a response bubble, copy of the received Bubble ID
+ - in an error-signaling bubble, 0
+
+ Figure 4: 6a44 Bubble Format
+
+ In a bubble from a 6a44 client to a 6a44 relay, the "6a44-client
+ IPv6 prefix" field is only reserved space for the response and is set
+ to 0. In a bubble from a 6a44 relay to a 6a44 client, this field
+ contains the IPv6 prefix of the client, left-justified.
+
+ In a bubble from a 6a44 client to a 6a44 relay, the "Bubble ID" field
+ contains a randomly chosen value, renewed under the circumstances
+ defined in Section 6.5.1. In a bubble from a 6a44 relay to a 6a44
+ client, if the bubble is a response to a bubble received from the
+ client, the field contains the value found in the received bubble; if
+ the bubble is a reaction to a received IPv6/UDP/IPv4 packet whose
+ IPv6 and UDP/IPv4 sources are inconsistent (i.e., not conforming to
+ R44-2 condition (3) in Section 6.6.2), the field is set to 0. The
+ purpose of this field is to protect against 6a44-relay spoofing
+ attacks (see Section 7).
+
+ In order to preserve forward compatibility with any extension of
+ bubble formats -- should one prove useful in the future -- 6a44
+ clients and 6a44 relays MUST be configured to receive bubbles whose
+ UDP payload lengths are longer than 20 octets (up to that of an IPv6-
+ packet header since, as detailed in Sections 6.5.3 and 6.6.2, bubbles
+ are recognized by the fact that their lengths are shorter than that
+ of tunneled IPv6 packets).
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 15]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+6.4. MTU Considerations
+
+ Reassembly of a fragmented IPv4 datagram necessitates that its
+ identifier be remembered from reception of the first fragment to
+ reception of the last one, and necessitates a timeout protection
+ against packet losses. If such stateful IP-layer processing would be
+ necessary for 6a44, it would make it more complex than needed, would
+ introduce a vulnerability to denial-of-service attacks, and would
+ impose the restriction that all fragments of a fragmented IPv4
+ datagram go to the same relay. This last point would be a constraint
+ on how load balancing may be performed between multiple 6a44 relays,
+ and would therefore be detrimental to scalability.
+
+ For 6a44 processing to remain completely stateless, IPv4 packets
+ containing encapsulated IPv6 packets must never be fragmented (DF
+ always set to 1). For this requirement to be met, the following
+ apply:
+
+ o In customer sites, 6a44 clients MUST have IPv4 link MTUs that
+ support encapsulated IPv6 packets of lengths up to 1280 octets,
+ i.e., for IPv6/UDP/IPv4 packets that traverse the CPE, link MTUs
+ of at least 1280+20+8=1308 octets. (This condition is in general
+ satisfied.)
+
+ o For the same reason, 6a44 ISP networks must have IPv4 path MTUs of
+ at least 1308 octets. (This condition is in general satisfied.)
+
+ o 6a44 clients SHOULD limit the size of IPv6 packets they transmit
+ to 1280 octets.
+
+ o 6a44 relays SHOULD set their IPv6 MTU to 1280. (If a relay
+ receives an IPv6 packet longer than this MTU via its IPv6 upstream
+ interface, it MUST return an ICMPv6 Packet Too Big error message.)
+ Typical ISP networks have path MTUs that would permit IPv6 MTUs of
+ 6a44 devices to be longer than 1280 octets, but accepting 1280
+ octets is a precaution that guarantees against problems with
+ customer sites that may have internal path MTUs smaller than those
+ supported by their ISP networks.
+
+6.5. 6a44 Client Specification
+
+6.5.1. Tunnel Maintenance
+
+ For a 6a44-client IPv6 address to remain valid, the port mapping of
+ the 6a44 tunnel MUST be maintained in the CPE NAT44.
+
+ For this, the 6a44 client SHOULD apply the equivalent of the
+ following TM-x rules, as illustrated in Figure 5.
+
+
+
+Despres, et al. Experimental [Page 16]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+ TM-1 At initialization, a timer value T1 is randomly chosen in the
+ recommended range of 1 to 1.5 seconds, and the "6a44 disabled"
+ state is entered. (Randomness of this value is a precaution to
+ avoid the following scenario: if many hosts happened to be
+ re-initialized at the same time, the bubble traffic resulting
+ from the following rules would be synchronized.)
+
+ TM-2 In the "6a44-disabled" state, if it appears that the interface
+ has no IPv6 native address BUT has a private IPv4 address, then
+ (1) the Attempt count (a local variable) is set to 1; (2) a new
+ Bubble ID (another local variable) is randomly chosen (it is
+ not critical how random this new value is, as explained in
+ Section 7); (3) a bubble is sent with this Bubble ID; (4) the
+ "Bubble sent" state is entered with the timer set to T1.
+
+ TM-3 In the "Bubble sent" state, if the timer expires AND the
+ Attempt count is less than 4, then (1) the Attempt count is
+ increased by 1; (2) a new bubble is sent with the current
+ Bubble ID; (3) the "Bubble sent" state is re-entered with the
+ timer reset to T1.
+
+ TM-4 In the "Bubble sent" state, if a bubble is received, then
+ (1) the 6a44-client IPv6 address is set to the received
+ 6a44-client IPv6 prefix followed by the host local IPv4
+ address; (2) the "Bubble received" state is entered with the
+ timer set to T2, whose recommended value is 30 seconds minus 4
+ times T1.
+
+ TM-5 In the "Bubble sent" state, if timer T1 expires AND the Attempt
+ count is equal to 4, then the "No 6a44 relay" state is entered
+ with the timer set to T3, whose recommended value is 30
+ minutes.
+
+ TM-6 In the "Bubble sent" state, OR the "Bubble received" state, OR
+ the "No 6a44 relay" state, if an IPv6 native address is
+ obtained by some other means, OR if the private IPv4 address of
+ the host is no longer valid, then (1) the timer is disarmed;
+ (2) the "6a44 disabled" state is entered.
+
+ TM-7 In the "Bubble received" state, if timer T2 expires, then
+ (1) the Attempt count is reset to 1; (2) a new Bubble ID is
+ randomly chosen; (3) a bubble is sent with this Bubble ID;
+ (4) the "Bubble sent" state is entered with the timer set
+ to T1.
+
+ TM-8 In the "Bubble received" state, if a bubble is received, then
+ the timer is reset to T2. (NOTE: Since a bubble is received by
+ a 6a44 client either in response to a bubble it has sent or in
+
+
+
+Despres, et al. Experimental [Page 17]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+ reaction to a packet it has sent with inconsistent IPv6 and
+ UDP/IPv4 source addresses, receiving a bubble is a sign that
+ the tunnel mapping reported in the received bubble prefix has
+ recently been used in BOTH directions, a condition required by
+ some NAT44s to maintain their mappings.)
+
+ TM-9 In the "No 6a44 relay" state, if the timer expires, then
+ (1) the Attempt count is reset to 1; (2) a new Bubble ID is
+ randomly chosen; (3) a bubble is sent with this Bubble ID;
+ (4) the "Bubble sent" state is entered with the timer set
+ to T1.
+
+ Initialization
+ ________v________
+ / \
+ | "6a44 disabled" |------------<-----------------+
+ \_________________/ ^
+ v no v6-add AND v4-add ^
+ +--------->--------------v ^
+ ^ +--------------v--------------+ ^
+ ^ | Reset the Attempt count | ^
+ ^ | Renew the Bubble ID | ^
+ ^ +--------------+--------------+ ^
+ ^ +----->-------------v ^
+ ^ ^ +--------------v--------------+ ^
+ ^ ^ | Send a bubble | ^
+ ^ ^ +--------------v--------------+ ^
+ ^ ^ ________v________ ^
+ ^ ^ Timer T1 / \ 4 attempts without answer ^
+ ^ +----<-----| "Bubble sent" |-------->----------------+ ^
+ ^ (1 to 1.5 s)\_________________/ v ^
+ ^ v \ v6-add OR no v4-add v ^
+ ^ Bubble received v +-----------------------------+
+ ^ v-----------------<-----------+ v ^
+ ^ _________v_________ ^ v ^
+ ^ Timer T2 / \Bubble received ^ v ^
+ +----------<---| "Bubble received" |-------->----------+ v ^
+ ^ (30 s - 4*T1)\___________________/ v ^
+ ^ \ v6-add OR no v4-add v ^
+ ^ +------->--------------------+
+ ^ v ^
+ ^ +----------------------------------+ ^
+ ^ _______v________ ^
+ ^ Timer T3 / \ v6-add OR no v4-add ^
+ +-----------<----| "No 6a44 relay" |----->-----------------------+
+ (30 min) \_________________/
+
+ Figure 5: Tunnel Maintenance Algorithm
+
+
+
+Despres, et al. Experimental [Page 18]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+6.5.2. Client Transmission
+
+ A 6a44 client transmits packets according to the following CT-x
+ rules. In figures that illustrate these rules, symbols used in
+ Section 5 are reused; packets are represented as a succession of
+ significant fields separated by commas, with sources preceding
+ destinations as usual; != means "different from".
+
+ CT-1 BUBBLE SENT BY A 6a44 CLIENT
+
+ (IPv4, A, B, UDP[W, W, ::/96, <current Bubble ID>])
+ |
+ +-------+--------+ |
+ | | 6a44 | |
+ | | client +------>---------- >B:W
+ | |function|A:W< UDP/IPv4
+ +-------+--------+
+ Host
+
+ Bubbles are transmitted from time to time. Conditions of their
+ transmission are specified in Section 6.5.1, and their format is
+ specified in Section 6.3.
+
+ CT-2 IPv6/IPv4 PACKET SENT TO A HOST OF THE SAME SITE
+
+ [IPv6, <C.N.Z.A>, <C.N..E>,...]
+ |
+ | (IPv4, A, A2, IP-in-IP[encapsulated packet])
+ | |
+ +----|--+--------+ |
+ | | | 6a44 | |
+ | -->--+ client +------>------ >A2
+ | IPv6 |function|<A IPv4
+ +-------+--------+
+ Host
+
+ If an IPv6 packet is submitted for transmission with ALL the
+ following conditions satisfied, the 6a44 client MUST encapsulate the
+ IPv6 packet in an IPv4 packet whose protocol is set to IP in IP
+ (protocol = 41) and whose IPv4 destination is copied from the last 32
+ bits of the IPv6 destination: (1) the IPv6 source address is the
+ 6a44-client IPv6 address; (2) the IPv6 destination is a 6a44 address
+ of the same site (it has the same 80 bits as the 6a44-client IPv6
+ address); (3) either the IPv6 packet does not exceed 1280 octets, or
+ it is longer but it does not exceed the IPv4 link MTU minus 20 octets
+ and the IPv4 destination address starts with the IPv4 link prefix.
+
+
+
+
+
+Despres, et al. Experimental [Page 19]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+ CT-3 IPv6/UDP/IPv4 PACKET TO A HOST OF ANOTHER SITE
+
+ [IPv6, <C.N.Z.A>, X != <C.N...>, ...]
+ |
+ | (IPv4, B, A, UDP(W, W, [encapsulated packet])
+ | |
+ +----|--+--------+ |
+ | | | 6a44 | |
+ | -->--+ client +------>---------- >B:W
+ | IPv6 |function|A:W< UDP/IPv4
+ +-------+--------+
+ Host
+
+ If an IPv6 packet is submitted for transmission and ALL the following
+ conditions are satisfied, the IPv6 packet MUST be encapsulated in a
+ UDP/IPv4 packet whose destination is the 6a44-relay anycast address
+ and whose source and destination ports are both the 6a44 port:
+ (1) the source address is the local 6a44-client IPv6 address; (2) the
+ destination is not a 6a44 address of the same site (its first 80 bits
+ differ from those of the 6a44-client IPv6 address); (3) the IPv6
+ packet does not exceed 1280 octets.
+
+ CT-4 IPv6 PACKET THAT DOESN'T CONCERN 6a44
+
+ If an IPv6 packet is submitted to the 6a44 client function for
+ transmission with an IPv6 source address that is not the
+ 6a44-client IPv6 address, the packet does not concern 6a44. It
+ MUST be left for any other IPv6 transmission function that may
+ apply (the source address can be a link-local address or a
+ Unique Local Address (ULA) [RFC4193]).
+
+6.5.3. Client Reception
+
+ Upon reception of an IPv4 packet, a 6a44 client applies the following
+ CR-x rules:
+
+ CR-1 BUBBLE RECEIVED FROM A 6a44 RELAY
+
+ (IPv4, B, A, UDP(W, W, [<C.N.Z>, <current Bubble ID>])
+ |
+ +-------+--------+ |
+ | | 6a44 | |
+ | | client +------<---------- <B:W
+ | | |A:W< UDP/IPv4
+ +-------+--------+
+ Host
+ (updates C.N.Z)
+
+
+
+
+Despres, et al. Experimental [Page 20]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+ If ALL the following conditions are satisfied (i.e., the packet is a
+ 6a44 bubble from a 6a44 relay), the 6a44-client IPv6 address MUST be
+ updated using the received IPv6 prefix C.N.Z: (1) the IPv4 packet
+ contains a complete UDP datagram (protocol = 17, offset = 0,
+ more-fragment bit = 0); (2) both ports of the UDP datagram are the
+ 6a44 port, and the payload length is enough to contain a 6a44-client
+ IPv6 prefix and a Bubble ID but shorter than an IPv6-packet header
+ (protocol = 17, UDP payload length = at least 20 octets and less than
+ 40 octets); (3) the received Bubble ID matches the current value of
+ the Bubble-ID local variable.
+
+ CR-2 IPv6/IPv4 PACKET FROM A HOST OF THE SAME SITE
+
+ (IPv4, E, A, IP-in-IP, [IPv6, <C.N..A2>, <C.N.Z.A>, ...])
+ |
+ [decapsulated packet] |
+ | |
+ +----|--+--------+ |
+ | | | 6a44 | |
+ | --<--+ client +------<------ <A2
+ | IPv6 | |A< IPv4
+ +-------+--------+
+ Host
+
+ If ALL the following conditions are satisfied (i.e., the packet comes
+ from a 6a44 client of the same site), the 6a44 client MUST
+ decapsulate the inner packet and treat it as a received IPv6 packet:
+ (1) the IPv4 packet contains a complete UDP datagram (protocol = 17,
+ offset = 0, more-fragment bit = 0); (2) both ports of the UDP
+ datagram are the 6a44 port, and the UDP payload is an IPv6 packet
+ (UDP length of at least 40 octets, version = 6); (3) the IPv6 source
+ address is one of the same site (the first 80 bits match those of the
+ 6a44-client IPv6 address; (4) its last 32 bits are equal to the IPv4
+ source address; (5) the IPv6 destination address is the 6a44-client
+ IPv6 address.
+
+ CR-3 IPv6/UDP/IPv4 PACKET FROM A HOST OF ANOTHER SITE
+
+ (IPv4, B, A, UDP(W, W, [IPv6, X, <C.N.Z.A>,...])
+ |
+ [decapsulated packet] |
+ | |
+ +----|--+--------+ |
+ | | | 6a44 | |
+ | --<--+ client +------<---------- <B:W
+ | IPv6 | |A:W< UDP/IPv4
+ +-------+--------+
+ Host
+
+
+
+Despres, et al. Experimental [Page 21]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+ If ALL the following conditions are satisfied (i.e., the packet has
+ been relayed by a 6a44 relay), the 6a44 client MUST decapsulate the
+ inner packet and treat it as a received IPv6 packet: (1) the IPv4
+ packet contains a complete UDP datagram (protocol = 17, offset = 0,
+ more-fragment bit = 0); (2) the UDP payload is an IPv6 packet (length
+ of at least 40 octets, version = 6); (3) the UDP/IPv4 source address
+ is the 6a44-relay UDP/IPv4 address; (4) the IPv6 destination address
+ is the 6a44-client IPv6 address.
+
+ CR-4 RECEIVED ICMPv4 ERROR MESSAGE CONCERNING A 6a44 PACKET
+
+ If the 6a44 client receives an IPv4 error message [RFC0792]
+ that concerns a discarded 6a44 packet (i.e., if the copied
+ header of the discarded packet is that of a transmitted packet
+ according to CT-2 or CT-3), it SHOULD translate it into an
+ ICMPv6 error message [RFC4443] and then treat it as a received
+ IPv6 packet. Translation of Type and Code conversions between
+ IPv4 and IPv6 is described in Section 4.2 of [RFC6145], under
+ "ICMPv4 error messages".
+
+ CR-5 RECEIVED IPv4 PACKET OTHER THAN 6a44
+
+ If ANY one or more of the following conditions are verified,
+ the received IPv4 packet does not concern 6a44 and MUST
+ therefore be left for any other IPv4 reception function that
+ may apply: (1) the IPv4 payload is neither UDP nor IPv6
+ (protocol = neither 17 nor 41, or protocol = 41 and IP version
+ in the payload is not = 6); (2) the IPv4 packet is an
+ IP-datagram fragment other than the first one (offset > 0);
+ (3) the IPv4 packet contains the first or unique fragment of a
+ UDP datagram (protocol = 17, offset = 0), with neither port
+ equal to the 6a44 port.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 22]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+6.6. 6a44 Relay Specification
+
+6.6.1. Relay Reception in IPv6
+
+ Upon reception of a packet via its IPv6 interface with a destination
+ address starting with the 6a44-network IPv6 prefix, a 6a44 relay MUST
+ apply the following RR6-x rules:
+
+ RR6-1 VALID IPv6 PACKET FROM OUTSIDE THE 6a44 ISP NETWORK
+
+ [IPv6, (X != <C...> AND != <Teredo(IPv4=B)>), <C.<N != B>.Z...>,...]
+ |
+ (IPv4, B, N, UDP(W, Z, |
+ [encapsulated packet])) |
+ | |
+ | +--------+ |
+ | >B:W | 6a44 |C/48< |
+ N:Z< ---<--------| relay |-------<---- C.N.Z...<
+ IPv4 | | IPv6
+ +--------+
+
+ If ALL the following conditions are satisfied, the IPv6 packet MUST
+ be encapsulated in a UDP/IPv4 packet whose UDP/IPv4 destination is
+ copied from bits 48 to 95 of the IPv6 destination address: (1) the
+ IPv6 source address is not that of a 6a44 client of the ISP (it does
+ not start with the 6a44-network IPv6 prefix); (2) the IPv6 source
+ address is not a Teredo address whose embedded UDP/IPv4 address is
+ the 6a44-relay anycast address; (3) the customer-site IPv4 address
+ embedded in the 6a44 destination address is not the 6a44-relay
+ anycast address; (4) the packet has at most 1280 octets.
+
+ RR6-2 INVALID IPv6 PACKET FROM OUTSIDE THE 6a44 ISP NETWORK
+
+ If ANY one or more of the following conditions are satisfied,
+ the IPv6 packet MUST be discarded: (1) the packet has more
+ than 1280 octets (in this case, an ICMPv6 Packet Too Big error
+ message MUST be returned to the source); (2) the customer-site
+ IPv4 address embedded in the IPv6 destination address is the
+ 6a44-relay anycast address; (3) the IPv6 source address is a
+ Teredo address whose embedded IPv4 address is the 6a44-relay
+ anycast address.
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 23]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+6.6.2. Relay Reception in IPv4
+
+ Upon reception via its IPv4 downstream interface of an IPv4 packet
+ that contains a complete IP datagram (fragment offset = 0 and
+ more-fragment bit = 0) and that contains a UDP datagram whose UDP/
+ IPv4 destination is the 6a44-relay UDP/IPv4 address, a 6a44 relay
+ MUST apply the following rules:
+
+ RR4-1 BUBBLE FROM 6a44 CLIENT
+
+ (IPv4, N, B, UDP(Z, W, [::/96, Bubble ID]))
+ |
+ IPv4 | +--------+
+ ------->----| |
+ >B:W| 6a44 |
+ | relay |
+ N:Z< -------<----| |
+ IPv4 | +--------+
+ |
+ |
+ (IPv4, B, N, UDP(W, Z, [<C.N.Z>, Bubble ID]))
+
+ If the following condition is satisfied, the 6a44 relay MUST return
+ to the source a bubble derived from the bubble it just received by
+ permuting its UDP/IPv4 source and destination, and by putting in its
+ 6a44-client-IPv6-prefix field the received UDP/IPv4 source address:
+ the UDP payload is a bubble, i.e., has at least 20 octets and less
+ than 40 octets.
+
+ RR4-2 IPv6 PACKET FROM A 6a44 CLIENT TO ANOTHER 6a44 CLIENT
+
+ (IPv4, N1, B, UDP(Z1, W, [IPv6, <C.N1.Z1...>, <C.N2.Z2...>, ...]))
+ |
+ IPv4 | +--------+
+ ------->----| |
+ >B:W| 6a44 |
+ | relay |
+ | |
+ N2.Z2< -------<----| |
+ IPv4 | +--------+
+ | 6a44 relay
+ |
+ (IPv4, B, N2, UDP(W, Z2, [encapsulated packet]))
+
+ If ALL the following conditions are satisfied, the 6a44 relay MUST
+ return back via its downstream IPv4 interface an IPv6/ UDP/IPv4
+ packet containing the same encapsulated packet, having its UDP/IPv4
+ destination set to the UDP/IPv4 address found in the 6a44 destination
+
+
+
+Despres, et al. Experimental [Page 24]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+ address, and having its UDP/IPv4 source set to the 6a44-relay
+ UDP/IPv4 address: (1) the IPv4 packet contains a complete UDP
+ datagram (protocol = 17, offset = 0, more-fragment bit = 0); (2) the
+ UDP payload is an IPv6 packet (length of at least 40 octets, version
+ = 6); (3) the IPv6 source address starts with the 6a44-network IPv6
+ prefix followed by the UDP/IPv4 source address of the received
+ packet; (4) the IPv6 destination address starts with the 6a44-network
+ IPv6 prefix.
+
+ RR4-3 IPv6 PACKET FROM A 6a44 CLIENT TO A NON-6a44 CLIENT
+
+ (IPv4, N, B, UDP(Z, W, [IPv6, <C.N.Z...>,
+ | (X != <C...> AND != <Teredo(IPv4=B)), ...]))
+ |
+ | [decapsulated packet]
+ | |
+ | +--------+ |
+ | B:W>| 6a44 | |
+ >B:W --->----------| relay |------->---- >
+ IPv4 | | IPv6
+ +--------+
+
+ If ALL the following conditions are satisfied, the 6a44 relay MUST
+ decapsulate the IPv6 packet and forward it via the IPv6 interface:
+ (1) the IPv4 packet contains a complete UDP datagram (protocol = 17,
+ offset = 0, more-fragment bit = 0); (2) the UDP payload is an IPv6
+ packet (length of at least 40 octets, version = 6); (3) the IPv6
+ source address starts with the 6a44-network IPv6 prefix followed by
+ the UDP/IPv4 source address of the received packet; (4) the IPv6
+ destination address does not start with the 6a44-network IPv6 prefix
+ and is not a Teredo address whose embedded IPv4 address is the
+ 6a44-relay anycast address.
+
+ RR4-4 RECEIVED ICMPv4 ERROR MESSAGE CONCERNING A 6a44 PACKET
+
+ If the 6a44 relay receives an IPv4 error message [RFC0792]
+ that concerns a discarded 6a44 packet (i.e., if the copied
+ header of the discarded packet is that of a transmitted packet
+ according to RR6-1 or RR4-2), it SHOULD translate it into an
+ ICMPv6 error message [RFC4443] and then treat it as a received
+ IPv6 packet. Translation of Type and Code conversions between
+ IPv4 and IPv6 is described in Section 4.2 of [RFC6145], under
+ "ICMPv4 error messages".
+
+ RR4-5 INVALID IPv6/UDP/IPv4 PACKET
+
+ For ANY other case, the 6a44 relay MUST discard the packet.
+
+
+
+
+Despres, et al. Experimental [Page 25]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+6.7. Implementation of Automatic Sunset
+
+ 6a44 is designed as an interim transition mechanism, not to be used
+ any longer than strictly necessary. Its sole purpose is to
+ accelerate availability of IPv6 native addresses where, for any
+ reason, CPEs cannot quickly be replaced, or where, for any reason,
+ ISP networks cannot quickly support dual-stack routing or 6rd.
+
+ A 6a44-capable ISP can first have an increase in its 6a44 traffic as
+ more and more hosts behind IPv4-only CPEs support the 6a44 client
+ function, but it should later have a decrease in this traffic as more
+ and more CPEs operate in dual stack.
+
+ When this traffic becomes sufficiently negligible, the ISP may, after
+ due prior notice, discontinue 6a44-relay operation. This terminates
+ its sunset procedure.
+
+ In a host that obtains an IPv6 native address by some means other
+ than 6a44, the effect of having the 6a44 function in its protocol
+ stack is inexistent. OS providers may therefore keep this function
+ in their code for many years. When it becomes clear that the number
+ of users of this function has become negligible, they can delete it
+ from later releases. This terminates their sunset procedure.
+
+7. Security Considerations
+
+ Incoming reachability:
+
+ Hosts that acquire 6a44 addresses become reachable from the
+ Internet in IPv6 while they remain unreachable in IPv4 at their
+ private IPv4 addresses.
+
+ For ordinary use, this should not introduce a perceptible new
+ security risk for two reasons: (1) hosts can, without IPv6, use
+ NAT44 hole-punching techniques such as Interactive Connectivity
+ Establishment (ICE) [RFC5245] to receive incoming connections;
+ (2) by default, modern operating systems that support IPv6 have
+ their own protections against incoming connections.
+
+ If 6a44 reachability across an ordinary NAT44 nevertheless has to
+ be barred, this can be done by configuring its port-forwarding
+ function with the 6a44 port bound to any internal address that is
+ not assigned to any host. Thus, no bubble from a 6a44 relay can
+ reach any 6a44-capable host, and this is sufficient to prevent
+ hosts from using 6a44.
+
+
+
+
+
+
+Despres, et al. Experimental [Page 26]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+ For more sophisticated uses with managed firewalls, default
+ configurations generally specify that packets that are not
+ explicitly authorized are discarded. Thus, 6a44 can be used only
+ if the 6a44 port is deliberately opened to incoming traffic.
+
+ Subscriber authentication:
+
+ Any authentication that applies to an IPv4 address extends its
+ effect to 6a44 addresses that are derived from it.
+
+ Host-address spoofing:
+
+ With ingress filtering required in 6a44 ISP networks, and with the
+ address checks specified in Section 6, no new IPv6 address-
+ spoofing vulnerability is introduced by 6a44.
+
+ Address-and-port scanning:
+
+ To mitigate the (limited) risk of a malicious user trying to scan
+ IPv4 address/port pairs to reach a host, Teredo addresses contain
+ 12 random bits [RFC5991]. 6a44 addresses have no random bits but
+ contain local IPv4 addresses of clients. Since possible values of
+ these addresses are not deterministically known from outside
+ customer sites and are in ranges that can be configured in typical
+ NAT44s, some protection against address and port scanning is thus
+ achieved. This protection may be less effective than that
+ achieved with random bits but is in any case better for 6a44 IPv6
+ addresses than for IPv4 addresses alone.
+
+ Denial of service:
+
+ Provided 6a44 relays are provisioned with enough processing power,
+ which is facilitated by their being completely stateless, 6a44
+ introduces no denial-of-service vulnerabilities of its own.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 27]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+ Routing loops:
+
+ A risk of routing-loop attacks has been identified in [RFC6324].
+ Without taking precautions, it applies to some combinations of
+ automatic-tunnel mechanisms such as 6to4, the Intra-Site Automatic
+ Tunnel Addressing Protocol (ISATAP), 6rd, and Teredo. This risk
+ does not exist with 6a44 for the following reasons:
+
+ 1. When a packet enters a 6a44 relay via its IPv6 interface, the
+ following apply:
+
+ + An IPv6/UDP/IPv4 packet cannot be sent to another 6a44
+ relay because its IPv4 destination would have to be a
+ 6a44-relay IPv4 address. This is prevented by rule RR6-1
+ of Section 6.6.1.
+
+ + If an IPv6/UDP/IPv4 packet is sent to the address of a 6to4
+ relay, 6rd relay, or ISATAP relay, it will be discarded
+ there because these relays don't accept UDP/IPv4 packets.
+
+ + If an IPv6/UDP/IPv4 packet is sent to a Teredo relay, it
+ will be discarded there because (1) Teredo relays check
+ that the IPv4 address that is embedded in the IPv6 source
+ address of a received IPv6/IPv4 packet matches the IPv4
+ source address of the encapsulating packet (Section 5.4.2
+ of [RFC4380]); (2) encapsulating packets sent by 6a44
+ relays have the 6a44-relay anycast address as the IPv4
+ source address; (3) a 6a44 relay forwards a received IPv6
+ packet as an IPv6/UDP/IPv4 packet only if its IPv6 source
+ address is not a Teredo address whose embedded IPv4 address
+ is the 6a44-relay IPv4 address.
+
+ 2. When a packet enters a 6a44 relay via its IPv4 interface, the
+ following apply:
+
+ + The received packet cannot come from another 6a44 relay (as
+ just explained, 6rd relays do not send IPv6/UDP/IPv4
+ packets to other 6a44 relays).
+
+ + If the IPv4 packet comes from a 6to4 relay, a 6rd relay, or
+ an ISATAP relay, its IPv6 encapsulated packet cannot be
+ forwarded (the received packet is IPv6/IPv4 instead of
+ being IPv6/UDP/IPv4, as required by rules RR4-2 and RR4-3
+ of Section 6.6.2).
+
+ + If the received packet is an IPv6/UDP/IPv4 packet coming
+ from a Teredo relay, this packet cannot have been sent to
+ the Teredo relay by a 6a44 relay: (1) in order to reach the
+
+
+
+Despres, et al. Experimental [Page 28]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+ 6a44 relay, the IPv6 destination of the IPv6 encapsulated
+ packet must be a Teredo address whose embedded IPv4 address
+ is the 6a44-relay anycast address (Section 5.4.1 of
+ [RFC4380]); (2) a 6a44 relay does not forward via its IPv6
+ interface an IPv6 packet whose destination is a Teredo
+ address whose embedded IPv4 address is the 6a44-relay
+ anycast address (rule RR4-3 of Section 6.6.2).
+
+ 6a44-relay spoofing:
+
+ In a 6a44 network, no node can spoof a 6a44 relay because ingress
+ filtering prevents any 6a44-relay anycast address from being
+ spoofed.
+
+ In a network that does not support ingress filtering (and
+ therefore is not a 6a44 network), the following apply:
+
+ * 6a44 packets sent by 6a44-capable hosts are discarded in the
+ IPv4 backbone because their IPv4 destination, the 6a44-relay
+ anycast address, does not start with any ISP-assigned prefix.
+
+ * If an attacker tries to send to a 6a44-capable host a fake
+ relay-to-client bubble, the probability that it would be
+ accepted by its destination is negligible. It would require
+ that all the following conditions be simultaneously satisfied:
+
+ + The UDP/IPv4 destination set by the attacker must reach a
+ NAT44 node in which it is the external mapping of a 6a44
+ tunnel established by a 6a44-capable host.
+
+ + This host must be in the "Bubble sent" state -- the only one
+ in which it listens to bubbles when its ISP is not 6a44
+ capable. This state is taken only for a few seconds every
+ 30 minutes (rule TM-5 of Section 6.5.1).
+
+ + This host accepts the bubble only if its Bubble ID has the
+ right value -- an extremely unlikely possibility with a
+ 64-bit randomly chosen Bubble ID (see Section 6.5.1).
+
+ * If a 6a44-capable host -- despite this scenario being very
+ unlikely -- accepts a fake bubble, the effect is that it
+ wrongly believes, for about 30 seconds, that it has an assigned
+ public IPv6 address. All IPv6 packets it then sends with this
+ address as the source cannot be accepted by any destination (no
+ relay will forward them, and no host of the same site will
+ accept them). The consequences of this scenario would
+ therefore not impair security.
+
+
+
+
+Despres, et al. Experimental [Page 29]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+8. IANA Considerations
+
+ IANA has assigned the following:
+
+ 1. IPv4 address 192.88.99.2 as the 6a44-relay anycast address (B in
+ this document).
+
+ 2. UDP port 1027 as the 6a44 port (W in this document).
+
+ The choice of 192.88.99.2 as the 6a44 IPv4 anycast address doesn't
+ conflict with any existing IETF specification because
+
+ o it starts with the 6to4 prefix 192.88.99.0/24 [RFC3068].
+
+ o it differs from the only currently assigned address that starts
+ with this prefix (the anycast address of 6to4 relays --
+ 192.88.99.1 [RFC3068].
+
+ This choice is made to permit implementations of 6a44 relays in
+ physical nodes that are independent from any 6to4 relay or, if found
+ to be more optimum, in nodes in which 6to4 relays and 6a44 relays are
+ collocated.
+
+9. Acknowledgments
+
+ This specification, whose origin is a convergence effort based on two
+ independent proposals -- [6rd+] and [SAMPLE] -- has benefited from
+ various suggestions. Comments have been received during this
+ process, in particular from Dave Thaler, Fred Templin, Ole Troan,
+ Olivier Vautrin, Pascal Thubert, Washam Fan, and Yu Lee. The authors
+ wish to thank them, and all others, for their useful contributions.
+ Special recognition is due to Dave Thaler and John Mann. Their
+ detailed reviews led to a few useful modifications and editorial
+ improvements.
+
+10. References
+
+10.1. Normative References
+
+ [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
+ RFC 792, September 1981.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 30]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 4291, February 2006.
+
+10.2. Informative References
+
+ [6rd+] Despres, R., "Rapid Deployment of Native IPv6 Behind IPv4
+ NATs (6rd+)", Work in Progress, July 2010.
+
+ [NAT444] Yamaguchi, J., Shirasaki, Y., Miyakawa, S., Nakagawa, A.,
+ and H. Ashida, "NAT444 addressing models", Work
+ in Progress, July 2012.
+
+ [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
+ and E. Lear, "Address Allocation for Private Internets",
+ BCP 5, RFC 1918, February 1996.
+
+ [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
+ Defeating Denial of Service Attacks which employ IP Source
+ Address Spoofing", BCP 38, RFC 2827, May 2000.
+
+ [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
+ Tunnel Broker", RFC 3053, January 2001.
+
+ [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
+ via IPv4 Clouds", RFC 3056, February 2001.
+
+ [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
+ RFC 3068, June 2001.
+
+ [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
+ Networks", BCP 84, RFC 3704, March 2004.
+
+ [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+ Addresses", RFC 4193, October 2005.
+
+ [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
+ Network Address Translations (NATs)", RFC 4380,
+ February 2006.
+
+ [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
+ Control Message Protocol (ICMPv6) for the Internet
+ Protocol Version 6 (IPv6) Specification", RFC 4443,
+ March 2006.
+
+
+
+
+
+Despres, et al. Experimental [Page 31]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+ [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
+ (ICE): A Protocol for Network Address Translator (NAT)
+ Traversal for Offer/Answer Protocols", RFC 5245,
+ April 2010.
+
+ [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
+ Infrastructures (6rd)", RFC 5569, January 2010.
+
+ [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed.,
+ "Managing Client-Initiated Connections in the Session
+ Initiation Protocol (SIP)", RFC 5626, October 2009.
+
+ [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
+ Infrastructures (6rd) -- Protocol Specification",
+ RFC 5969, August 2010.
+
+ [RFC5991] Thaler, D., Krishnan, S., and J. Hoagland, "Teredo
+ Security Updates", RFC 5991, September 2010.
+
+ [RFC6081] Thaler, D., "Teredo Extensions", RFC 6081, January 2011.
+
+ [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
+ Algorithm", RFC 6145, April 2011.
+
+ [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using
+ IPv6 Automatic Tunnels: Problem Statement and Proposed
+ Mitigations", RFC 6324, August 2011.
+
+ [SAMPLE] Carpenter, B. and S. Jiang, "Legacy NAT Traversal for
+ IPv6: Simple Address Mapping for Premises Legacy Equipment
+ (SAMPLE)", Work in Progress, June 2010.
+
+ [TheTool] de Saint-Exupery, A., "Wind, Sand and Stars", Chapter III
+ (The Tool), 1939.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 32]
+
+RFC 6751 Native IPv6 behind NAT44 CPEs (6a44) October 2012
+
+
+Authors' Addresses
+
+ Remi Despres (editor)
+ RD-IPtech
+ 3 rue du President Wilson
+ Levallois
+ France
+
+ EMail: despres.remi@laposte.net
+
+
+ Brian Carpenter
+ University of Auckland
+ Department of Computer Science
+ PB 92019
+ Auckland 1142
+ New Zealand
+
+ EMail: brian.e.carpenter@gmail.com
+
+
+ Dan Wing
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, California 95134
+ USA
+
+ EMail: dwing@cisco.com
+
+
+ Sheng Jiang
+ Huawei Technologies Co., Ltd.
+ Q14, Huawei Campus - No. 156 Beiqing Road
+ Hai-Dian District, Beijing 100095
+ P.R. China
+
+ EMail: jiangsheng@huawei.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 33]
+