RFC 6751
Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)
Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44) 🎀
okay bestie, title block time! 💅 This is RFC 6751, an Independent Submission and it's marked Experimental 🧪, so it's not a Standards Track thing. It was published in October 2012 and the ISSN is 2070-1721. The editor is R. Despres, Ed. from RD-IPtech, and the co-authors are B. Carpenter (Univ. of Auckland), D. Wing (Cisco), and S. Jiang (Huawei Technologies Co., Ltd.). The header doesn't have an Obsoletes or Updates line, so this doc doesn't replace or update any other RFC 🦋.
Abstract ✨
So in customer sites that have IPv4-only Customer Premises Equipment (CPE) 🏠, Teredo (RFC 4380, RFC 5991, RFC 6081) is the last-resort way to get IPv6 connectivity. Here's the tea though: Teredo was designed to work without ISPs being involved, so it has some real problems 😭. IPv6 native addresses and Teredo addresses might not connect, and Teredo addresses can fail to reach each other for some combos of NAT types 💀.
Enter 6a44 💖! It's a complementary solution that does rely on ISP cooperation, so it dodges those limitations. It takes the Teredo well-known prefix at the start of Teredo IPv6 addresses and swaps it for network-specific /48 prefixes that local ISPs assign. It's giving the same glow-up energy as going from 6to4 to 6rd (IPv6 Rapid Deployment on IPv4 Infrastructures) 🌈. The spec is meant to be complete enough that people can write running code independently, and that the solution can be rolled out and used bit by bit 🍓.
Status of This Memo ✨
This document is not an Internet Standards Track specification 🙈. It's published for examination, experimental implementation, and evaluation.
This document defines an Experimental Protocol for the Internet community. It's a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor chose to publish it at their discretion, and they make no statement about its value for implementation or deployment. Documents the RFC Editor approves for publication aren't candidates for any level of Internet Standard, so see Section 2 of RFC 5741 for the details 💅.
Information about the current status of this document, any errata, and how to give feedback on it can be found 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) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 📜.
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 ...................................311. Introduction 💫
Okay so most Customer Premises Equipment (CPE) should be dual-stack capable soon, but a big installed base of IPv4-only CPEs is going to hang around for several years 🕰️. Those CPEs run on IPv4-to-IPv4 NATs (NAT44s). Also, because IPv4 addresses are running low, more and more Internet Service Providers (ISPs) and mobile operators are giving their customers private IPv4 addresses ([RFC1918]) (the [NAT444] model) 😩. So if IPv6 [RFC2460] is going to be used widely and fast, we need IPv6 connectivity behind NAT44s, including the ones in the [NAT444] model ✨.
Right now there are two tunneling techniques specified for IPv6 connectivity behind NAT44s 🫶:
- Configured tunnels. These need tunnel brokers that users have to register with [RFC3053]. Hexago and the SixXS collaboration are well-known examples, and they're good for early IPv6 trials 🧪. But they're not adequate for mass deployment, because even if two hosts are in the same customer site, their IPv6 packets have to go through tunnel servers that might be far away 🌍.
- Automatic Teredo tunnels [RFC4380] [RFC5991]. Teredo is a last-resort solution, and since it's built to work without local ISP involvement, it has these 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 don't have enough motivation to make sure that happens.)
- 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 (although some implementations can avoid this constraint).
6a44 is designed to get around the Teredo limitations, because with 6a44, ISPs can join the party 🎉. The approach is similar to the one that let 6rd [RFC5569] [RFC5969] avoid the limitations of 6to4 [RFC3056] [RFC3068]: the Teredo well-known prefix at the start of IPv6 addresses gets replaced by network-specific prefixes that local ISPs assign 🦋.
Here's how this document is laid out 🗺️: Section 3 has the definitions for terms used in the doc, Section 4 covers design goals and the model of operation, and Section 5 describes the format of 6a44 IPv6 addresses. Section 6 gets into the detailed behaviors of 6a44 clients and 6a44 relays. Security and IANA considerations are in Sections 7 and 8 respectively 👑.
This spec is meant to be complete enough for people to write running code independently, and for the solution to be rolled out and used bit by bit. Its status is Experimental instead of Standards Track, since it's still unclear which major Internet players might be willing to support it 🤷♀️.
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 ✨
okay so bestie, here are the definitions we're working with 💅 the first batch is the MAJOR NEW DEFINITIONS (the stuff that's brand new, no cap) 🎀
MAJOR NEW DEFINITIONS 💖
6a44 ISP network: an IPv4-capable ISP network that supports at least one 6a44 relay. on top of that, it assigns individual IPv4 addresses to its customer sites (global or private), it supports ingress filtering [RFC2827], and its path MTUs are at least 1308 octets. very specific, very iconic 👑
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. the main character of this whole doc 🧚
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's a request for a response bubble. in the relay-to-client direction, it conveys the up-to-date IPv6 prefix of the client. the bubble is literally the vibe check 🫧✨
SECONDARY NEW DEFINITIONS 🍓
(this list is for reference and you can skip it if you already know the usual terminology, no judgment 🙈)
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's composed of the client IPv6 prefix, received from a 6a44 relay, followed by the client local IPv4 address. 🫶
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). the math is giving precision 🧮💅
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). it's giving reserved-seat energy 👑
6a44-network IPv6 prefix: an IPv6 /48 prefix assigned by an ISP to a 6a44 network. 🌸
USUAL DEFINITIONS 🧚
(this list is for reference and you can skip it if you already know 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. it's a packet inside a packet inside a packet, and I am obsessed 😭✨
4. Design Goals, Requirements, and Model of Operation 🎀
4.1. Hypotheses about NAT Behavior 🦋
okay so 6a44 is designed to work with the NAT44 behaviors identified in Section 3 of [RFC6081]. specifically, it has to work with endpoint-dependent mappings AND endpoint-independent mappings, including cases where things dynamically switch from one mode to the other. it really doesn't pick a favorite 💅
the only assumption is that, once a mapping has been established in the NAT44, it's maintained as long as it gets reused at least once, in each direction, every 30 seconds. that's the whole deal 🫶
NOTE: 30 seconds is the value used for the same mapping-maintenance purpose in Teredo [RFC4380] and in SIP [RFC5626]. the same number showing up in two other protocols is lowkey iconic 🔥
4.2. Native IPv6 Connectivity for Unmanaged Hosts behind NAT44s 🌸
the goal is still that, as soon as possible, CPEs and ISPs support IPv6 native prefixes. 6a44 is therefore designed only as a temporary solution for hosts to get IPv6 native addresses in sites whose CPEs aren't IPv6 capable yet. it's a bridge, not the destination 🌉💖
as noted in Section 1, IPv6 native addresses obtainable with configured tunnels have important limitations. BUT compared to 6a44 addresses, they have the advantage of staying unchanged when there's a NAT44 reset. so 6a44 stays the last-resort solution for IPv6 native addresses on unmanaged hosts of IPv4-only-CPE sites, while configured tunnels may still be preferred for some managed hosts if the reported limitations of configured tunnels are judged to be acceptable. since their scopes are different, the two solutions can usefully coexist. it's a team effort, bestie 🧚
note that Teredo remains a last-resort solution for hosts to have IPv6 addresses where IPv6 native addresses can't be made available (and where Teredo's limitations are judged to be acceptable). ⭐
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. the internet is supposed to be open to you, periodt 🌍✨
- 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. no unnecessary detours, the way that 🏠🦋
- 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. zero setup, maximum slay 🎀
- Scalability of ISP functions: for the solution to be easily scalable, ISP-supported functions have to be completely stateless. stateless is the move, iykyk 🧚💜
- 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. no one gets to sneak in as your address 🔒👑
- 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". minimalism is literally the aesthetic 🤍✨
- 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. they don't need each other to show up, and nobody gets left on read 🫶🌈
4.4. Model of Operation
okay so 6a44 has just two kinds of nodes 💖: 6a44 clients and 6a44 relays. Figure 1 shows the two applicability scenarios, and they're honestly so cute 🎀
- In the first one, the IPv4 addresses given to customer sites are global IPv4 🌍
- In the second one, they're private IPv4 addresses (the [NAT444] model, where ISPs run 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 ScenariosIn both setups, the ISP network might also hand out IPv6 prefixes to customer sites ✨
- If customer sites only get IPv4 addresses (IPv6 prefix available neither natively nor with any tunnel), 6a44 applies not just to sites whose CPEs are IPv4-only capable, but also to those whose CPEs are dual-stack capable 🦋
- If customer sites get both IPv4 addresses and IPv6 prefixes, 6a44 only applies to sites whose CPEs are IPv4-only capable 🌸
Figure 2 shows the paths IPv6 packets take between a 6a44 client, A, and different possible 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, and D in an IPv6 site of another ISP 👑. Between 6a44 clients in the same site, IPv6 packets get wrapped up in IPv4 packets. Packets between 6a44 clients and 6a44 relays get wrapped in UDP/IPv4 packets 🎁
Here's how 6a44 works, step by step (the details are in Section 6) 💅
- A 6a44 client gets things started by sending a 6a44 bubble to the 6a44-relay UDP/IPv4 address 🫧
- When a 6a44 relay gets a bubble from one of its 6a44 clients, it sends a bubble back to that client with the client's IPv6 prefix in it 💌
- When a 6a44 client gets a bubble from a 6a44 relay, it updates (or confirms) its 6a44 address. It's an update if the client doesn't have an IPv6 address yet, or if a CPE reset changed this address. Once a client receives a bubble, it's ready to start up, or keep going, with IPv6 🚀
- When a 6a44 client that has a 6a44 address has an IPv6 packet to send whose destination IS in the same customer site, it wraps the packet in an IPv4 packet. The destination of that IPv4 packet comes from the IPv6 destination address. Then it sends the IPv6/IPv4 packet off 🏠
- When a 6a44 client gets a valid IPv6/IPv4 packet from a 6a44 client in the same site, it unwraps the IPv6 packet and passes it along for more IPv6 processing 🎀
- When a 6a44 client that has a 6a44 address has an IPv6 packet to send whose destination IS NOT in the same customer site, it wraps the packet in a UDP/IPv4 packet. That packet's destination is the 6a44-relay UDP/IPv4 address. Then it sends the IPv6/UDP/IPv4 packet 📦
- When a 6a44 relay gets a valid IPv6/UDP/IPv4 packet on its IPv4 interface, and the destination IS one of its 6a44 clients, it forwards the IPv6 packet inside, wrapped in a modified IPv6/UDP/IPv4 packet. The UDP/IPv4 destination of this packet comes from the IPv6 destination address 💫
- When a 6a44 client gets a valid IPv6/UDP/IPv4 packet from a 6a44 relay, it unwraps the IPv6 packet and passes it along for IPv6 processing 🌈
- When a 6a44 relay gets a valid IPv6/UDP/IPv4 packet on its IPv4 interface, and the IPv6 destination IS NOT one of its 6a44 clients, it unwraps the IPv6 packet and sends it out on its IPv6 interface 🛫
- When a 6a44 relay gets a valid IPv6 packet on its IPv6 interface, and the destination is one of its 6a44 clients, it wraps the packet in a UDP/IPv4 packet. The destination of that UDP/IPv4 packet is the UDP/IPv4 address found in the IPv6 destination address. Then it sends the IPv6/UDP/IPv4 packet out on its IPv4 interface 🧚
- To keep the NAT44 mapping for its 6a44 tunnel alive, and to quickly notice when its 6a44 address needs to change because of a NAT44 reset, a 6a44 client sends a bubble to the 6a44-relay address now and then (see Section 6.5.1) ⏰
- When a 6a44 relay gets an IPv6/UDP/IPv4 packet on its IPv4 interface whose IPv6 and UDP/IPv4 source addresses don't match, it throws the invalid packet away and sends a bubble back to the UDP/IPv4 source address. (This lets the 6a44 client at that address update its IPv6 address.) 🙈
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 Hosts5. 6a44 Addresses
The 6a44 IPv6 address an ISP gives a host has to carry every piece of info needed to reach it from other IPv6 addresses 🗺️ Here are those pieces, which you can also see in Figure 3:
- the 6a44-network IPv6 prefix C (a /48 the ISP has assigned to its 6a44 relays) 🧁
- the customer-site IPv4 address N (either global IPv4 or, if the ISP uses a [NAT444] model, private IPv4) 🌷
- the mapped port Z of the 6a44 tunnel (that is, the external port the NAT44 assigns to the tunnel the client keeps up between its UDP/IPv4 local address A:W and the 6a44-relay UDP/IPv4 address B:W) 🔑
- the client local IPv4 address A (that is, the private IPv4 address given to the client in its customer site; it's 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 ConstructionNOTE: 6a44 addresses are NOT guaranteed to follow the rule in [RFC4291], which says bits 64-127 of aggregatable unicast addresses have to be in Modified-EUI-64 Interface Identifier (IID) format. But these bits in 6a44 addresses only get interpreted where 6a44 addresses are processed, that is, in 6a44 relays and clients. So no operational problem is foreseen 🫶 Plus, since this is purely a transitional tool, it shouldn't stop 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
okay bestie, so for NAT44 traversal ✨ an IPv6 packet going from a 6a44 client to a 6a44 relay (or the other way around) gets wrapped up inside a UDP/IP packet 🎀. The source and destination addresses of that outer packet are the two endpoints' addresses (A:W and B:W in the notations of Figure 3) 💖. The IPv4 packet is a complete datagram, so 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 because there's no need for an extra layer of checksum protection, it's already covered 💅. 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 |
+----------+---+-------------------+-------//-----+Now the case where an IPv6 packet goes from one 6a44 client to another 6a44 client of the same site 🏠. This one gets wrapped in an IPv4 packet whose source and destination addresses are the private IPv4 addresses of the two hosts 🧚. Same deal as before: the IPv4 packet is a complete datagram (more-fragment bit 0, offset 0, identification may be 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
okay so a "bubble" is a UDP/IPv4 packet whose UDP payload is made up of a "6a44-client IPv6 prefix" field and a "Bubble ID" field 🫧. Its UDP checksum is set to 0 🌈. Skipping UDP checksum protection in bubbles is a simplification that's totally acceptable, because bubble contents get updated all the time and aren't critical 💅. (A client that accepts a corrupted IPv6 prefix never ends up with an IPv6 packet being accepted by the wrong destination, so it's not that deep 🙈.)
"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 FormatLet's talk about what goes in each field 👀. 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 holds the IPv6 prefix of the client, left-justified 💌.
In a bubble from a 6a44 client to a 6a44 relay, the "Bubble ID" field holds a randomly chosen value, which gets renewed under the circumstances defined in Section 6.5.1 🎲. In a bubble from a 6a44 relay to a 6a44 client, things go like this 🔁:
- If the bubble is a response to a bubble the client sent, the field has 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 whole point of this field is to protect against 6a44-relay spoofing attacks (see Section 7) 🛡️. Iconic behaviour, honestly 👑.
Now for forward compatibility 🔮. In order to keep things compatible with any extension of bubble formats (in case one proves useful in the future), 6a44 clients and 6a44 relays MUST be configured to receive bubbles whose UDP payload lengths are longer than 20 octets. That upper limit is the size 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 🧁.
6.4. MTU Considerations
okay this section is giving "why we can't just fragment everything" 😭. Reassembling a fragmented IPv4 datagram means you have to remember its identifier from the first fragment all the way to the last one, and you need a timeout in case packets get lost 🕰️. If 6a44 needed that kind of stateful IP-layer processing, it would be way more complex than it needs to be, it would open up a vulnerability to denial-of-service attacks, and it would force all fragments of a fragmented IPv4 datagram to go to the same relay 🙅♀️. That last bit would limit how load balancing could work across multiple 6a44 relays, which is bad for scalability 📉.
So to keep 6a44 processing completely stateless ✨, IPv4 packets containing encapsulated IPv6 packets must never be fragmented (DF always set to 1). To make that happen, the following apply 💅:
- 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=1308octets. (This condition is in general satisfied 🌷.) - For the same reason, 6a44 ISP networks must have IPv4 path MTUs of at least
1308octets. (This condition is in general satisfied 🌈.) - 6a44 clients SHOULD limit the size of IPv6 packets they transmit to 1280 octets 🎀.
- 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 allow the IPv6 MTUs of 6a44 devices to be longer than 1280 octets, but accepting 1280 octets is a precaution. It guarantees you're safe from problems with customer sites whose internal path MTUs are smaller than what their ISP network supports 🫧.
6.5. 6a44 Client Specification
6.5.1. Tunnel Maintenance 🎀
Okay bestie, so for a 6a44-client IPv6 address to stay 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. 🦋
TM-1 At initialization, a timer value T1 gets randomly picked from the recommended range of 1 to 1.5 seconds, and the "6a44 disabled" state is entered. The randomness is a total precaution 🙈 because if a bunch of hosts got re-initialized at the same time, their bubble traffic from these rules would get synced up, and nobody wants that.
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 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 Algorithm6.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
+-------+--------+
HostBubbles 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
+-------+--------+
HostIf 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. 🌈
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
+-------+--------+
HostIf 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
okay bestie, this is where the 6a44 client sorts its inbox 💌✨ 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)okay so this one is giving bubble check 🥹 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
+-------+--------+
Hostthis is the same-site vibe check 🫶 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
+-------+--------+
Hostok so if the packet came from another site, it's gotta have been relayed by a 6a44 relay 🦋 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 🙈
ngl this one's about error messages getting a glow-up 💅 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.
6.6. 6a44 Relay Specification
the relay era has arrived 🌸 this is where the relays do their thing, bestie 🧚
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
+--------+so when a valid IPv6 packet shows up from outside the ISP network, the relay gets to wrap it up 🎁 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.
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]))for the bubble, the relay bounces back a bubble of its own 🫧 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]))client-to-client, the relay is the middle friend making the intro happen 🤝 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 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
+--------+when the friend is outside the 6a44 crew, the relay unwraps the packet and sends it on over 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. no exceptions, bestie 💅
6.7. Implementation of Automatic Sunset 🌅
okay so 6a44 is an interim transition mechanism, bestie 💅 It is not meant to stick around any longer than strictly necessary ✨ Its whole job is to speed up IPv6 native addresses for people whose CPEs can't quickly be replaced, or whose ISP networks can't quickly support dual-stack routing or 6rd. Think of it as a bridge, not a permanent home 🌉
A 6a44-capable ISP will first see its 6a44 traffic go up as more and more hosts behind IPv4-only CPEs turn on the 6a44 client function 📈 Later, though, that traffic should go down as more and more CPEs run in dual stack. The arc is literally the point 🦋
When this traffic gets sufficiently negligible, the ISP may, after due prior notice, switch off its 6a44-relay operation 🫶 That's the end of its sunset procedure, and it's giving closure.
Now for hosts. If a host gets an IPv6 native address by some means other than 6a44, then having the 6a44 function in its protocol stack has no effect at all 🙈 It's basically inexistent for that host. So OS providers can keep this function in their code for many years if they want 🧚 Once it's clear the number of users of this function has become negligible, they can delete it from later releases. That's the end of their sunset procedure too 🌸
7. Security Considerations 🛡️
Incoming reachability
Hosts that acquire 6a44 addresses become reachable from the Internet in IPv6, while they stay unreachable in IPv4 at their private IPv4 addresses 👀
For ordinary use, this should not introduce a perceptible new security risk, and there are two reasons why 💅 (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, you can do that by configuring its port-forwarding function with the 6a44 port bound to any internal address that is not assigned to any host 🚫 That way, no bubble from a 6a44 relay can reach any 6a44-capable host, and this is sufficient to prevent hosts from using 6a44. Iconic lockdown behavior 💀
For more sophisticated uses with managed firewalls, default configurations generally specify that packets that are not explicitly authorized are discarded 🗑️ So 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 🍓 So the same vibe carries over, no cap.
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 🙌 Ingress filtering and those checks are doing the heavy lifting here, periodt.
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 they do contain local IPv4 addresses of clients. Since the possible values of these addresses are not deterministically known from outside customer sites, and they sit in ranges that can be configured in typical NAT44s, some protection against address and port scanning is achieved anyway 🦋 This protection may be less effective than the one that comes from random bits, but it 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, and that's facilitated by them being completely stateless ✨, 6a44 introduces no denial-of-service vulnerabilities of its own 🌈 Stateless is so iconic.
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:
- 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 🔁
- 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 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 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 a fake relay-to-client bubble to a 6a44-capable host, 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, which is 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 🔒
8. IANA Considerations 📋
IANA has assigned the following:
- IPv4 address
192.88.99.2as the 6a44-relay anycast address (B in this document). 📍 - UDP port
1027as 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:
- it starts with the 6to4 prefix
192.88.99.0/24[RFC3068]. 🌷 - 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, whose 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.
[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 🦋
okay these are the bonus reads, the extra stuff the doc points to for context bestie 📚✨
[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. 💖[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. 🧚♀️
Authors' Addresses 💖
here's where you can find the authors, bestie, they're literally the brains behind all this 🧠👑
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.comthat's the whole thing, bestie! 🌈💅🫶
📦 where this page comes from
- ietf: rfc6751 2012-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms