RFC 3964
Security Considerations for 6to4
Security Considerations for 6to4 🎀
RFC 3964, Security Considerations for 6to4, is by P. Savola (CSC/FUNET) and C. Patel (All Play, No Work). It's Informational, dated December 2004, and the header doesn't list any RFCs it obsoletes or updates. Okay, the boring facts are out of the way, now let's get into it 💅
Status of This Memo 📜
This memo is just info for the Internet community. It is not an Internet standard of any kind. Anyone can distribute it as much as they want 🫶
Copyright Notice ©️
Copyright (C) The Internet Society (2004).
Abstract ✨
Okay, so 6to4 (RFC3056) is this IPv6 interim mechanism that does automatic IPv6-over-IPv4 tunneling to connect IPv6 networks together 🦋 The setup has 6to4 routers and 6to4 relay routers, and both of them accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from literally any node on the IPv4 internet 😭 That openness makes a bunch of threats possible, mainly Denial of Service, and it also makes it way easier for nodes to spoof IPv6 addresses 💀 This document digs into all of that and suggests some enhancements to help fix it.
Table of Contents 📑
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Different 6to4 Forwarding Scenarios . . . . . . . . . . . . . 4
2.1. From 6to4 to 6to4 . . . . . . . . . . . . . . . . . . . 4
2.2. From Native to 6to4 . . . . . . . . . . . . . . . . . . 5
2.3. From 6to4 to Native . . . . . . . . . . . . . . . . . . 5
2.4. Other Models . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1. BGP between 6to4 Routers and Relays . . . . . . 6
2.4.2. 6to4 as an Optimization Method . . . . . . . . . 7
2.4.3. 6to4 as Tunnel End-Point Addressing Mechanism . . 8
3. Functionalities of 6to4 Network Components . . . . . . . . . . 9
3.1. 6to4 Routers . . . . . . . . . . . . . . . . . . . . . . 9
3.2. 6to4 Relay Routers . . . . . . . . . . . . . . . . . . . 10
4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Attacks on 6to4 Networks . . . . . . . . . . . . . . . . 12
4.1.1. Attacks with ND Messages . . . . . . . . . . . . 13
4.1.2. Spoofing Traffic to 6to4 Nodes . . . . . . . . . 14
4.1.3. Reflecting Traffic to 6to4 Nodes . . . . . . . . 17
4.1.4. Local IPv4 Broadcast Attack . . . . . . . . . . 19
4.2. Attacks on Native IPv6 Internet . . . . . . . . . . . . 20
4.2.1. Attacks with ND Messages . . . . . . . . . . . . 21
4.2.2. Spoofing Traffic to Native IPv6 Nodes. . . . . . 21
4.2.3. Reflecting Traffic to Native IPv6 Nodes . . . . 23
4.2.4. Local IPv4 Broadcast Attack . . . . . . . . . . 24
4.2.5. Theft of Service . . . . . . . . . . . . . . . . 25
4.2.6. Relay Operators Seen as Source of Abuse . . . . 26
4.3. Attacks on IPv4 Internet . . . . . . . . . . . . . . . . 28
4.4. Summary of the Attacks . . . . . . . . . . . . . . . . . 28
5. Implementing Proper Security Checks in 6to4 . . . . . . . . . 30
5.1. Encapsulating IPv6 into IPv4 . . . . . . . . . . . . . . 31
5.2. Decapsulating IPv4 into IPv6 . . . . . . . . . . . . . . 31
5.3. IPv4 and IPv6 Sanity Checks . . . . . . . . . . . . . . 32
5.3.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . 32
5.3.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . 33
5.3.3. Optional Ingress Filtering . . . . . . . . . . . 33
5.3.4. Notes about the Checks . . . . . . . . . . . . . 33
6. Issues in 6to4 Implementation and Use . . . . . . . . . . . . 34
6.1. Implementation Considerations with Automatic Tunnels . . 34
6.2. A Different Model for 6to4 Deployment . . . . . . . . . 35
7. Security Considerations . . . . . . . . . . . . . . . . . . . 36
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A. Some Trivial Attack Scenarios Outlined . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 411. Introduction 🌸
The IPv6 interim mechanism "6to4" [1] is all about automatic IPv6-over-IPv4 tunneling. It connects isolated IPv6 clouds by embedding the tunnel IPv4 address inside the IPv6 6to4 prefix 🧚
Two things about 6to4 cause most of the security drama:
- All 6to4 routers must accept and decapsulate IPv4 packets from every other 6to4 router, and from 6to4 relays.
- 6to4 relay routers must accept traffic from any native IPv6 node.
Since a 6to4 router has to accept traffic from any other 6to4 router or relay, you need a lot of trust, and there are no strict rules on what the IPv6 packet can contain 🙈 So addresses in the IPv4 and IPv6 headers can be spoofed, and that opens the door to all kinds of threats, including different flavors of Denial of Service attacks. Not it. 🫠
The 6to4 spec laid out a few security considerations and rules, but it was vague about how strictly they had to be followed. The explanations were pretty short too, and some of them turned out to be hard to understand or impossible to implement.
This document takes a deeper look at 6to4 security issues and outlines some enhancements and caveats 🔥
Here's the roadmap: Sections 2 and 3 are more or less intro stuff, basically how 6to4 is used today according to the 6to4 spec, so you can see how security could get affected. Section 4 is the threat analysis for implementations that already do most of the security checks. Section 5 describes the best decapsulation/encapsulation rules for 6to4 implementations, and Section 6 talks about a few issues that have been tricky to implement. Appendix A covers some trivial attack scenarios where very little or no security has been implemented 👑
For simplicity, this document treats the native Internet as including IPv6 networks built with other transition mechanisms (e.g., RFC 2893 [4]). That's because those mechanisms can't talk directly to the 6to4 network 🦋
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in BCP 14, RFC 2119 [2]. Those are the only ones that carry requirement weight, so watch for them 🎀
Throughout this memo, IPv4 addresses from the blocks 7.0.0.0/24, 8.0.0.0/24, and 9.0.0.0/24 are used as examples. They stand in for global IPv4 addresses that have nothing to do with each other. The authors didn't use addresses from 192.0.2.0/24 [5] for two reasons: they wanted addresses whose 6to4 mapping is super obvious, and they wanted it to be clear that the IPv4 addresses of different 6to4 gateways don't need any relation to each other 🍓
2. Different 6to4 Forwarding Scenarios 🗺️
Heads up: when you communicate between 6to4 and native domains, the 6to4 relays used in each direction are very likely different. Routing is highly asymmetric 🙃 Because of that, it isn't feasible to limit which relays a 6to4 router accepts traffic from.
The first three subsections cover the most common forms of 6to4 operation. The fourth subsection covers the other models 💜
2.1. From 6to4 to 6to4 🦋
6to4 domains always swap 6to4 traffic directly over IPv4 tunneling. The endpoint address V4ADDR comes from the 6to4 prefix 2002:V4ADDR::/48 of the destination.
.--------. _----_ .--------.
| 6to4 | _( IPv4 )_ | 6to4 |
| router | <====> ( Internet ) <===> | router |
'--------' (_ _) '--------'
^ '----' ^
| Direct tunneling over IPv4 |
V V
.--------. .-------.
| 6to4 | | 6to4 |
| host | | host |
'--------' '--------'Figure 1
It is required that every 6to4 router consider every other 6to4 router it wants to talk to be "on-link" (with IPv4 as the link-layer). Yes, IPv4 is acting as the link layer here, which is so cool 🤯
2.2. From Native to 6to4 🌈
When native domains send traffic to the 6to4 prefix 2002:V4ADDR::/48, it gets routed to the topologically nearest advertising 6to4 relay, which is the one advertising the route 2002::/16. The 6to4 relay then tunnels the traffic over IPv4 to the matching IPv4 address V4ADDR.
Note that IPv4 address 9.0.0.1 here is just an example of a global IPv4 address, and it's assigned to the 6to4 router's pseudo-interface.
Closest to
"Native IPv6 node"
.--------. _----_ .------------. .--------.
| Native | _( IPv6 )_ | 6to4 relay | Tunneled | 6to4 |
| IPv6 | -> ( Internet ) --> | router | =========> | router |
| node | (_ _) '------------' 9.0.0.1 '--------'
'--------' '----' dst_v6=2002:0900:0001::1 |
V
.-------.
| 6to4 |
| host |
'--------'Figure 2
2.3. From 6to4 to Native 🚀
6to4 domains send traffic to native domains by tunneling it over IPv4 to their configured 6to4 relay router. They can also use the closest one they find through 6to4 IPv4 Anycast [3]. The relay decapsulates the packet and forwards it to the native IPv6 Internet, just like it would for any other IPv6 packet ⭐
Note that the destination IPv6 address in the packet is a non-6to4 address, and in the example it's assumed to be 2001:db8::1.
Configured
-or-
found by IPv4 Anycast
.--------. _----_ .------------. .--------.
| Native | _( IPv6 )_ | 6to4 relay | Tunneled | 6to4 |
| Client | <- ( Internet ) <-- | router | <========= | router |
'--------' (_ _) '------------' 192.88.99.1'--------'
2001:db8::1 '----' (or configured) ^
|
.-------.
| 6to4 |
| client |
'--------'Figure 3
2.4. Other Models 🧚♀️
These are more or less special cases of 6to4 operations. In later chapters, unless otherwise stated, only the most generally used models (above) get considered 💖
2.4.1. BGP between 6to4 Routers and Relays
okay so Section 5.2.2.2 in [1] lays out a setup where, instead of static config, BGP [6] runs between 6to4 relay routers and 6to4 routers, but only for picking which outgoing relay to use. 🛣️✨
now here's where it gets spicy. going beyond [1], if a 6to4 router set up a BGP session with every possible 6to4 relay and advertised its /48 prefix to them, then traffic from non-6to4 sites would always come from a "known" relay 👀. or the 6to4 relays could advertise the more specific 6to4 routes between each other. 🔄
but bestie, both of these are obviously a no-go because of scalability issues 💀. literally cannot scale.
neither of these models is known to be in use at the time of writing 🙈. probably because the people who need 6to4 can't run BGP, and setting these sessions up would be a whole lot more work for relay operators. not it. 🫠
2.4.2. 6to4 as an Optimization Method
some sites are giving "optimization method" energy with 6to4 🧚. they've got non-6to4 addresses on their nodes and border routers, but they also use 6to4 to reach 6to4 sites.
this is typically done so they can reach 6to4 destinations through direct tunneling without using relays at all. no middleman, very efficient, very iconic 💅.
these sites also publish both 6to4 and non-6to4 addresses in DNS to influence inbound connections 🌸. if the source host's default address selection [7] works properly, 6to4 sources will use the 6to4 addresses to reach the site, and non-6to4 nodes will use the non-6to4 addresses. if you can assume that foreign nodes behave this way, the security threats to these sites can be significantly simplified. 🔐✨
2.4.3. 6to4 as Tunnel End-Point Addressing Mechanism
okay this one is lowkey my favorite 🦋. 6to4 addresses can also be used purely as an addressing and routing mechanism for IPv6-in-IPv4 tunnel endpoints.
the example is interconnecting 10 branch offices where the nodes use non-6to4 addresses. only the offices' border routers need to know about 6to4, and they use 6to4 addresses solely for addressing the tunnels between the different branch offices. here's the figure 👇
2001:db8:0:10::/60 2001:db8:0:20::/60
.--------. .--------.
( Branch 1 ) ( Branch 2 )
'--------' '--------'
| |
.--------. _----_ .--------.
| 6to4 | _( IPv4 )_ | 6to4 |
| router | <====> ( Internet ) <===> | router |
'--------' (_ _) '--------'
9.0.0.1 '----' 8.0.0.2
^^
||
vv
.--------.
| 6to4 | 7.0.0.3
| router |
'--------'
| 2001:db8::/48
.-----------.
( Main Office )
'-----------'
^
|
v
_----_
_( IPv6 )_
( Internet )
(_ _)
'----'
Figure 4in the figure, the main office sets up two routes:
2001:db8:0:10::/60 -> 2002:0900:0001::1
2001:db8:0:20::/60 -> 2002:0800:0002::1and a branch office sets up two routes as well:
2001:db8:0:20::/60 -> 2002:0800:0002::1
default -> 2002:0700:0003::1so the IPv4 Internet gets treated as an NBMA link-layer for interconnecting 6to4-enabled sites 🌐. with explicit routes, 6to4 addressing doesn't need to be used in routers other than the 6to4 edge routers 💖.
⚠️ heads up: if a branch office sends a packet to any 6to4 destination, it will NOT go through the main office, because the 6to4 2002::/16 route overrides the default route. 🙃
this approach may make addressing and routing slightly easier in some situations 🎀.
3. Functionalities of 6to4 Network Components ✨
this section sums up the main functionalities of the 6to4 network components (6to4 routers and 6to4 relays) and the security checks they must do 🛡️. the pseudo-code for those security checks shows up in Section 5.
so basically this section breaks down the main jobs of the components in a 6to4 network: 6to4 relay routers and 6to4 routers. for 6to4 definitions, check out Section 1.1 of RFC 3056 [1] 📚.
3.1. 6to4 Routers
6to4 routers are the border routers of a 6to4 domain 🏰. they don't have a native global IPv6 address, except in certain special cases. since the specification [1] uses the term "6to4 router", this memo does too. just know that this definition also includes a single host with a 6to4 pseudo-interface, even though that host doesn't otherwise act as a router 🧚♀️. the main functions of a 6to4 router are:
- Provide IPv6 connectivity to local clients and routers. 🌈
- Tunnel packets sent to foreign 6to4 addresses to the destination 6to4 router using IPv4.
- Forward packets sent to locally configured 6to4 addresses to the 6to4 network.
- Tunnel packets sent to non-6to4 addresses to the configured/closest-by-anycast 6to4 relay router.
- Decapsulate directly received IPv4 packets from foreign 6to4 addresses.
- Decapsulate IPv4 packets received via the relay closest to the native IPv6 sources. note that it's not easily distinguishable whether the packet came from a 6to4 relay router or from a spoofing third party 👀.
the 6to4 router should also do security checks on traffic it receives from other 6to4 relays, other 6to4 routers, or from within the 6to4 site 🔍. these checks include the following:
- Disallow traffic that has private, broadcast or certain specific reserved IPv4 addresses (see Section 5.3.1 for details) in tunnels, or the matching 6to4 prefixes. 🚫
- Disallow traffic from 6to4 routers in which the IPv4 tunnel source address does not match the 6to4 prefix. (note that the pseudo-interface must pick the IPv4 address corresponding to the prefix when encapsulating, or problems may ensue, e.g., on multi-interface routers 😬.)
- Disallow traffic in which the destination IPv6 address is not a global address; in particular, link-local addresses, mapped addresses, and such should not be used. 🙅♀️
- Disallow traffic transmission to other 6to4 domains through a 6to4 relay router or via some third party 6to4 router. (to avoid transmission to the relay router, the pseudo-interface prefix length must be configured correctly to /16. further, to avoid the traffic being discarded, 6to4 source addresses must always correspond to the IPv4 address encapsulating the traffic 🧠.)
- Discard traffic received from other 6to4 domains via a 6to4 relay router. 🗑️
- Discard traffic received for prefixes other than one's own 6to4 prefix(es). 💅
3.2. 6to4 Relay Routers
the 6to4 relay router is the middle-person between all 6to4 domains and native IPv6 networks 🤝. more specifically, it:
- advertises the reachability of the 2002::/16 prefix to native IPv6 routing, so it receives traffic to all 6to4 addresses from the closest native IPv6 nodes 📡.
- advertises (if RFC 3068 [3] is implemented) the reachability of the IPv4 "6to4 relay anycast prefix" (192.88.99.0/24) to IPv4 routing, so it receives some tunneled traffic to native IPv6 nodes from 6to4 routers 🌊.
- decapsulates and forwards packets received from 6to4 addresses through tunneling, using normal IPv6 routing, and
- tunnels packets received through normal IPv6 routing from native addresses that are destined for 2002::/16 to the corresponding 6to4 router 🎁.
the 6to4 relay should also do security checks on traffic it receives from 6to4 routers or from native IPv6 nodes 🔒. these checks are as follows:
- Disallow traffic that has private, broadcast, or certain specific reserved IPv4 addresses in tunnels, or in the matching 6to4 prefixes. 🚫
- Disallow traffic from 6to4 routers in which the IPv4 tunnel source address does not match the 6to4 prefix. (note that the pseudo-interface must pick the IPv4 address corresponding to the prefix when encapsulating, or problems may ensue, e.g., on multi-interface routers 😬.)
- Disallow traffic in which the destination IPv6 address is not a global address; in particular, link-local addresses, mapped addresses, and such should not be used. 🙅♀️
- Discard traffic received from 6to4 routers with the destination as a 6to4 prefix. 🗑️
4. Threat Analysis 🚨
okay bestie, this section is all about attacks against the 6to4 network, or attacks caused by the 6to4 network 😱. the threats are discussed in light of the 6to4 deployment models defined in Section 2.
there are three general types of threats:
- Denial-of-Service (DoS) attacks, in which a malicious node prevents communication between the node under attack and other nodes. 💀
- Reflection Denial-of-Service (DoS) attacks, in which a malicious node reflects the traffic off unsuspecting nodes to a particular node (the node under attack) in order to prevent communication between the node under attack and other nodes. 🪞
- Service theft, in which a malicious node/site/operator may make unauthorized use of the service. 🫣
6to4 also gives us a "meta-threat", traffic laundering 🧺, in which some other attack gets channeled through third parties to make tracing the real origin of the attack harder. this gets used together with other threats, whether they're specific to 6to4 or not.
🚩 super important: the attacks are possible because: 1. 6to4 routers have to consider all 6to4 relays, and other 6to4 routers, as "on-link", 2. 6to4 relays have to consider all 6to4 routers as "on-link", and 3. it has been discovered that at least a couple of major 6to4 implementations do not implement all the security checks.
the attack descriptions are sorted by their target:
- Attacks on 6to4 networks.
- Attacks on IPv6 networks.
- Attacks on IPv4 networks.
also, one of the mitigation methods listed for various attacks is based on the premise that 6to4 relays could have a feature limiting traffic to and from specific 6to4 sites. as of this writing, that feature is speculative, and more work needs to be done to figure out the logistics 🤔.
4.1. Attacks on 6to4 Networks
this section covers attacks against 6to4 networks. attacks that leverage 6to4 networks, but where the ultimate victim is somewhere else (e.g., a native IPv6 user, or an IPv4 user), are described later in the memo 👀.
6to4 relays and routers are IPv4 nodes, and there's no way for any 6to4 router to confirm the identity of the IPv4 node it receives traffic from, whether that's a legit 6to4 relay or some other node 🫥. a 6to4 router has to process traffic from all IPv4 nodes. malicious IPv4 nodes can exploit this and attack nodes inside the 6to4 network 😤.
there are a bunch of attacks possible on the 6to4 nodes. they are:
- Attacks with Neighbor Discovery (ND) Messages
- Spoofing traffic to 6to4 nodes
- Reflecting traffic from 6to4 nodes
- Local IPv4 broadcast attack
4.1.1. Attacks with ND Messages ✨
ATTACK DESCRIPTION
Okay so, the 6to4 router assumes that all the other 6to4 routers and 6to4 relays are "on-link" 😭. That means anyone in the IPv4 network can attack the 6to4 router with ND messages, unless a prior trust relationship has been established. 💀
The attacks target the 6to4 pseudo-interface. As long as the 6to4 addresses aren't used in the source or destination address, the security checks specified by 6to4 take no stance on these packets. Typically they use link-local addresses. 🦋
For example, an attack could be a Route Advertisement or Neighbor Advertisement message crafted specifically to cause havoc 🔥. The addresses in such a packet could resemble the following:
src_v6 = fe80::2 (forged address)
dst_v6 = fe80::1 (valid or invalid address)
src_v4 = 8.0.0.1 (valid or forged address)
dst_v4 = 9.0.0.2 (valid address, matches dst_v6)These attacks are exacerbated if the implementation supports more tunneling mechanisms than 6to4 (or configured tunneling), because it is impossible to disambiguate such mechanisms. That makes it difficult to enable strict security checks (see Section 6.1). 🙈
The Neighbor Discovery threats (Redirect DoS, or DoS) are described in [8]. Note that all attacks may not be applicable, as the 6to4 pseudo-interface is assumed not to have a link-layer address (Section 3.8 RFC 2893 [4]). However, note that the 6to4 router can be either a router or host from the Neighbor Discovery perspective. 🧚
THREAT ANALYSIS AND MITIGATION METHODS
The attacks can be mitigated by using any of the following methods:
- The usage of ND messages could be prohibited. This implies that all packets using addresses of scope link-local will be silently discarded. Section 3.1 of RFC 3056 [1] leaves scope for future uses of link-local address. This method has its pitfalls: it would prohibit any sort of ND message and thus close the doors on development and use of other ND options. Whether this is a significant problem is another thing. 🚫
- The 6to4 pseudo-interface could be insulated from the other interfaces, particularly the other tunnel interfaces (if any), for example by using a separate neighbor cache. 🧱
- If ND messages are needed, either IPsec [4] or an extension of SEND could be used [9] to secure packet exchange using the link-local address. Vanilla SEND would not work, as the link-layer does not have an address, and IPsec would be rather complex. 🔐
COMPARISON TO SITUATION WITHOUT 6to4
Even though rather simply fixed, this attack is not new as such. The same is possible by using automatic tunneling [4] or configured tunneling (if one is able to spoof source IPv4 address to that of the tunnel end-point). 🤷♀️
However, as 6to4 provides open decapsulation, and automatic tunneling is being deprecated [10], 6to4 provides an easy means, which would not exist without it. Lowkey a big deal 💅
4.1.2. Spoofing Traffic to 6to4 Nodes 🎀
ATTACK DESCRIPTION
The attacker, a malicious IPv4 or IPv6 node, can send packets that are difficult to trace (e.g., due to spoofing or going through a relay) to a 6to4 node. This can be used e.g., to accomplish a DoS attack. 🕵️♀️
The IPv6 and IPv4 addresses of the packets will be similar to the following:
src_v6 = 2001:db8::1 (forged address)
dst_v6 = 2002:0900:0002::1 (valid address)
src_v4 = 8.0.0.1 (valid or forged address)
dst_v4 = 9.0.0.2 (valid address, matches dst_v6)For attacks launched from a native IPv6 node, the src_v4 will be the address of the relay through which the traffic will reach the 6to4 node. From IPv4 nodes, src_v4 can be either a spoofed source address or the real one. 🌸
The 6to4 router receives these packets from 8.0.0.1, decapsulates them, discards the IPv4 header containing the source address 8.0.0.1, and processes them as normal. The attacker has guessed or obtained "dst_v6" by using one of a number of techniques. 👀
This is a DoS attack on 6to4 nodes. 😤
This attack is similar to those shown in [11].
EXTENSIONS
Replies to the traffic will be directed to the src_v6 address, resulting in 6to4 nodes participating in a reflection DoS. This attack is described in more detail in Section 4.2.3. The replies (e.g., TCP SYN ACK, TCP RST, ICMPv6 Echo Reply, input sent to UDP echo service, ICMPv6 Destination Unreachable) are sent to the victim (src_v6), above. All the traces from the original attacker (src_v4) have been discarded. These return packets will go through a relay. 🔄
Certain 6to4 networks may have a trivial ACL (Access Control List) based firewall that allows traffic to pass through if it comes from particular source(s). Such a firewalling mechanism can be bypassed by address spoofing. This attack can therefore be used for trivial ACL avoidance as well. These attacks might be hampered because the replies from the 6to4 node to the spoofed address will be lost. 🧐
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
The Denial-of-Service attack based on traffic spoofing is not new. The only twists come from the fact that traces of an attack are more easily lost, and that spoofing the IPv6 address is possible even to those who are unable to do so in their current networks. 🥲
The 6to4 router typically does not log IPv4 addresses (as they would be treated as L2 addresses), and thus the source of the attack (if launched from an IPv4 node) is lost. Because traces to the src_v4 address are easily lost, these attacks can also be launched from IPv4 nodes whose connections are ingress-filtered. 🫠
However, often this is not a real factor, as usually the attackers are just zombies, and real attackers may not even care whether the unspoofed source address is discovered. 🧟♀️
Malicious native IPv6 nodes could be caught easily if ingress filtering was enabled everywhere in the IPv6 Internet. 🪤
These attacks are easy to perform, but the extent of harm is limited:
- For every packet sent, at most one reply packet is generated: there is no amplification factor. ✅
- Attack packets, if initiated from an IPv6 node, will pass through choke point(s), namely a 6to4 relay. In addition to physical limitations, these could implement some form of 6to4-site-specific traffic limiting. 🚧
On the other hand, a variety of factors can make the attacks serious:
- The attacker may have the ability to choose the relay, and he might employ the ones best suited for the attacks. Also, many relays use 192.88.99.1 [3] as the source address, making tracing even more difficult (also see Section 4.2.6). 😬
- The relay's IPv4 address may be used as a source address for these attacks, potentially causing a lot of complaints or other actions, as the relay might seem to be the source of the attack (see Section 4.2.6 for more). 📣
Some of the mitigation methods for such attacks are as follows:
- Ingress filtering in the native IPv6 networks to prevent packets with spoofed IPv6 sources from being transmitted. This would, thus, make it easy to identify the source of the attack. Unfortunately, it would depend on significant (or even complete) ingress filtering everywhere in other networks. While this is highly desirable, it may not be feasible. 🛡️
- Security checks in the 6to4 relay. The 6to4 relay must drop traffic (from the IPv6 Internet) that has 6to4 addresses as source address; see Section 5 for more detail. This has very little cost. 💖
However, these mitigation methods do not address the case of an IPv4 node sending encapsulated IPv6 packets. 😮💨
No simple way to prevent such attacks exists. Longer-term solutions, such as ingress filtering [12] or itrace [13], would have to be deployed in both IPv6 and IPv4 networks to help identify the source of the attacks. A total penetration is likely impossible. (Note that itrace work has been discontinued, as of this writing in July 2004.) 🥀
COMPARISON TO SITUATION WITHOUT 6to4
Traffic spoofing is not a new phenomenon in IPv4 or IPv6. 6to4 just makes it easier: anyone can, regardless of ingress filtering, spoof a native IPv6 address to a 6to4 node, even if "maximal security" would be implemented and deployed. Losing trails is also easier. 🕳️
Therefore, depending on how much one assumes ingress filtering is deployed for IPv4 and IPv6, this could be considered either a very serious issue or close to irrelevant compared to the IP spoofing capabilities without 6to4. It's giving "it depends" energy, bestie 🌈
4.1.3. Reflecting Traffic to 6to4 Nodes 🪞
ATTACK DESCRIPTION 💅
Okay so, spoofed traffic (the kind from Section 4.2.2) can be sent to native IPv6 nodes to pull off a reflection attack against 6to4 nodes. It's giving bounce-off-a-wall energy 🎾
The spoofed traffic reaches a native IPv6 node either from an IPv4 node (through a 6to4 relay) or from a native IPv6 node (unless ingress filtering has been deployed). In the first case, the packets would look something like this:
src_v6 = 2002:1234:1234::1 (forged address of the target 6to4 node)
dst_v6 = 2002:0900:0002::1 (valid address)
src_v4 = 8.0.0.1 (valid or invalid address)
dst_v4 = 9.0.0.2 (valid address, matches dst_v6)Plot twist 🫶 an attack through the relay is blocked if the relay runs proper decapsulation security checks (see Section 5 for details), unless the IPv4 node can spoof the source address to match src_v6. Similarly, the attack from native IPv6 nodes could be stopped by global ingress filtering deployment. ✨
These attacks can be launched by native IPv6, IPv4, or 6to4 nodes. 🧚
EXTENSIONS 🌸
A distributed Reflection DoS can happen if a large number of nodes send spoofed traffic with the same src_v6. Literally a whole crowd, bestie 😭
Malicious 6to4 nodes can also (try to) run this attack by bouncing traffic off 6to4 nodes in other 6to4 sites. However, this may not be possible, because the 6to4 router (in the site the attack is launched from) will filter packets with forged source addresses (using the security checks mentioned in Section 5). 🛡️
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS 🔥
Here the reverse traffic is made up of replies to the messages received by the 6to4 nodes. The attacker has less control over the packet type, which inhibits certain kinds of attacks. For example, flooding a 6to4 node with TCP SYN packets won't be possible, but a SYN-ACK or RST would be. 🙈
These attacks may be mitigated in various ways:
- Implementation of ingress filtering by the IPv4 service providers. This would prevent forging of the src_v4 address and help close down on the culprit IPv4 nodes. Note that it will be difficult to shut down the attack if a large number of IPv4 nodes are involved.
These attacks may also be stopped at the 6to4 sites if the culprit src_v4 address is identified and, if it is constant, by filtering traffic from that address. Note that this would be difficult to implement if appropriate logging were not done by the 6to4 router, or if a large number of 6to4 nodes and/or a large number of IPv4 nodes were participating in the attack.
Unfortunately, because many IPv4 service providers don't implement ingress filtering, for whatever reasons, this may not be a satisfactory solution. 😤
- Implementation of ingress filtering by all IPv6 service providers would eliminate this attack, because src_v6 could not be spoofed as a 6to4 address. However, expecting this to happen may not be practical. 🥲
- Proper implementation of security checks (see Section 5) at both the 6to4 relays and routers would eliminate an attack launched from an IPv4 node, except when the IPv4 source address was also spoofed. But then the attacker could have attacked the ultimate destination directly anyway. 💀
- Rate limiting traffic at the 6to4 relays. In a scenario where most of the traffic passes through a few 6to4 relays, these relays can use traffic rate-limiting features to rate-limit the traffic from 6to4 sites. 🚦
COMPARISON TO SITUATION WITHOUT 6to4 👑
This particular attack can be mitigated by proper implementation of security checks (which is quite straightforward) and by ingress filtering. When ingress filtering is not implemented, it's typically easier to attack directly than through reflection, unless "traffic laundering" is an explicit goal of the attack. So, honestly, this attack doesn't seem very serious. 🫠
4.1.4. Local IPv4 Broadcast Attack 📡
ATTACK DESCRIPTION 🎀
This threat applies if the 6to4 router doesn't check whether the IPv4 address it tries to send encapsulated IPv6 packets to is a local broadcast address or a multicast address.
This threat is described in the specification [1], and implementing those checks eliminates it. However, since the checks haven't been widely implemented, the threat is included here for completeness. 📚
There are practically two kinds of attacks: one where a local 6to4 user tries to send packets to the address corresponding to the broadcast address, and one where someone is able to do so remotely. 🫣
For the first kind, assume that 9.0.0.255 is the 6to4 router's broadcast address. After receiving a packet with a destination address like 2002:0900:00ff::bbbb from a local 6to4 node, the router, if it doesn't check the destination address for subnet broadcast, would send the encapsulated protocol-41 packet to 9.0.0.255. Every node in the subnet would receive it, and the responses would be directed to the 6to4 router. Chaos, but make it networking 🌪️
Malicious sites may also embed forged 6to4 addresses in the DNS. If a 6to4 node uses one of those, the 6to4 router would end up doing a local broadcast. One way to pull this off would be to send an HTML mail containing a link to an invalid URL (for example, http://[2002:0900:00ff::bbbb]/index.html) to all users in a 6to4-based network. If everyone opened the mail at the same time, it would result in a broadcast storm. 😱
The second kind is more complex. The attack can be started by IPv4 nodes that don't belong to the local network, as long as they can send traffic with an invalid source address (for example, 2002:0900:00ff::bbbb). The 6to4 router has to respond to that traffic by sending ICMPv6 packets back to the source (e.g., Hop Limit Exceeded or Destination Unreachable). The packet would look like this:
src_v6 = 2002:0800:00ff::bbbb (broadcast address of the router)
dst_v6 = 2002:0800:0001::0001 (valid non-existent address)This is a DoS attack. 🚨
EXTENSIONS 🧩
The attacks could also be aimed at non-local broadcast addresses, but these would be so-called "IPv4 directed broadcasts", which have (luckily enough) already been extensively blocked across the Internet. Phew 🙏
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS 🛠️
The attack relies on the premise that the 6to4 router has to send a packet that embeds an invalid IPv4 address into an IPv6 address. It's easily thwarted by making sure the 6to4 router doesn't transmit packets to invalid IPv4 addresses. Specifically, traffic should not be sent to broadcast or multicast IPv4 addresses. ✅
COMPARISON TO SITUATION WITHOUT 6to4 🦋
The first threat is similar to what's already possible with IPv4, but IPv6 doesn't have broadcast addresses. 🤔
The second, more complex threat is, similarly, also available in IPv4.
So in consequence, the security doesn't seem to be significantly worse than with IPv4. And even that is restricted to the sites with 6to4 implementations that haven't been secured as described in Section 5. 💖
4.2. Attacks on Native IPv6 Internet 🌐
This section describes attacks against the native IPv6 Internet that somehow leverage the 6to4 architecture. Attacks against 6to4 nodes were described in the previous section. 🫶
6to4 and IPv4 nodes can access native IPv6 nodes through the 6to4 relay routers. So the 6to4 relays play a crucial role in any attack on native IPv6 nodes by IPv4 nodes or 6to4 nodes. Main character energy, but make it infrastructure 👑
6to4 relays have only one significant security check they must perform for general safety. When decapsulating IPv4 packets, they check that 2002:V4ADDR::/48 and V4ADDR match in the source address. If this isn't done, several threats become way more serious. In the following analysis, it's assumed that such checks are implemented. 🔒
A 6to4 relay should not relay packets between 6to4 addresses. In particular, packets decapsulated from 6to4 routers should not be encapsulated toward 6to4 routers, as described in Section 5. Similarly, packets with 6to4 source and destination addresses sent from IPv6 nodes should not be relayed. It's not clear whether this kind of check is typically implemented, so the attacks described below assume that such checks are not implemented. 🙃
4.2.1. Attacks with ND Messages 📨
These attacks are the same as the ones employed against 6to4 routers, as described in Section 4.1.1. ✨
4.2.2. Spoofing Traffic to Native IPv6 Node ✨
ATTACK DESCRIPTION 💥
Okay bestie, so the attacker is a sneaky malicious IPv4 or 6to4 node 😈. They can send packets with a spoofed (or not spoofed) 6to4 source address to a native IPv6 node, and the goal is a DoS attack. Total villain arc 💀.
This is basically the same drama as the one with 6to4 routers from Section 4.1.2, just with a different cast. The difference is that the attack starts from IPv4 or 6to4 nodes. The source IPv6 address may or may not be spoofed. Also, as mentioned above, the relay is assumed to match the source IPv4 address against the address embedded in the source IPv6 address during decapsulation. So the side effect is that all spoofed traffic ends up with a 6to4 source address 🎀.
EXTENSIONS 🌈
Spoofed traffic can also be sent to native IPv6 nodes by other native IPv6 nodes, by 6to4 nodes, or by malicious IPv4 nodes. That lets them run Reflection DoS against native IPv6 nodes or 6to4 nodes 🫠.
Some native IPv6 networks have a trivial ACL (Access Control List) based firewall that lets traffic through if it comes from particular source(s). Spoofing the address can get around that, so this attack can also be used for trivial ACL avoidance 🙈. These attacks might get hampered by lost replies from the 6to4 node to the spoofed address 🧚.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS 🔍
The Denial-of-Service attack based on traffic spoofing isn't new 🥱. The only twist is that the traces of an attack are way easier to lose 👻. The 6to4 relay typically does not log IPv4 addresses (since they would be treated as L2 addresses), so if the attack comes from an IPv4 node, the source is lost 😭. Because traces to the src_v4 address are easily lost, these attacks can also be launched from IPv4 nodes whose connections are ingress-filtered 🕵️♀️.
These attacks might not be easy to pull off, though, and they might get hampered for these reasons:
- It might be difficult to launch such attacks from 6to4 nodes. Even if the 6to4 routers allow spoofing of the source IPv6 address, the 6to4 relay checks whether the source V4ADDR is the same as the one embedded in the source IPv6 address. So 6to4 nodes will be forced to use the correct IPv6 prefix while launching an attack, which makes these attacks easy to shut down 🔒.
- Packets may pass through choke point(s), namely a 6to4 relay. Besides physical limitations, there could be some sort of traffic rate limiting mechanisms in place, and those could tone down the attack 🐢.
- For every packet sent, at most one reply packet is generated. There is no amplification factor 🙅♀️.
Some of the mitigation methods for these attacks are:
- Ingress filtering in the IPv4 Internet to prevent packets with a spoofed IPv4 source from being transmitted. The relay checks that the 6to4 address embeds the IPv4 address, so no spoofing can be achieved unless IPv4 addresses can be spoofed. However, this would probably be an unfeasible requirement 😩.
- Security checks in the 6to4 relay. The 6to4 relay must drop traffic (from 6to4 nodes, or IPv4 nodes) with non-6to4 addresses as the source address, or for which the source IPv4 address does not match the address embedded in the source IPv6 address 🛑.
COMPARISON TO SITUATION WITHOUT 6to4 🆚
Compared to Section 4.1.2, which describes more serious threats, this one seems a little more manageable 💅. If the relays do proper decapsulation checks, the spoofing can only be achieved, to a 6to4 source address, when the IPv4 address is spoofable as well 🫶.
4.2.3. Reflecting Traffic to Native IPv6 Nodes 🪞
ATTACK DESCRIPTION 💥
These reflection attacks are similar to the one involving 6to4 routers, as described in Section 4.1.3 🔁. Traffic may be reflected off native IPv6 nodes, or off 6to4 nodes. The attack can be started by any of the following:
- Native IPv6 nodes. These nodes can send invalid traffic with spoofed native IPv6 addresses to valid 6to4 nodes. Replies from the 6to4 nodes are part of a reflection attack 😤.
- IPv4 nodes. These nodes can send traffic with native IPv6 source addresses (encapsulated by the IPv4 node itself into a protocol-41 packet) to 6to4 nodes. Replies from the 6to4 nodes are part of a reflection attack 🙃.
- 6to4 nodes. These nodes can do attacks similar to those by IPv4 nodes, but this would require spoofing of the source address at the 6to4 site before encapsulation, which is likely to be difficult 🧐.
When it's launched from a native IPv6 node, the traffic goes through 6to4 relays twice, both before and after the reflection. When it's launched from a 6to4/IPv4 node, the traffic only goes through a relay after the reflection 🌀.
EXTENSIONS 🌸
A distributed reflection DoS can happen if a large number of native IPv6 nodes or IPv4/6to4 nodes are involved in sending spoofed traffic with the same source IPv6 address 📣.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS 🔍
Some of the mitigation methods for these attacks are:
- Attacks from native IPv6 nodes could be stopped by implementing ingress filtering in the IPv6 Internet. Hopefully this becomes commonplace, but past experience with IPv4 ingress filtering deployment (or lack thereof) does not promise much 😬.
- Two measures are needed to stop or mitigate attacks from IPv4 nodes: 1) implementing ingress filtering in the IPv4 internet, and 2) logging IPv4 source addresses in the 6to4 router 📝.
- Attacks from 6to4 nodes in other sites can be stopped if the 6to4 routers in those sites implement egress filtering. Those sites could do this themselves, but the sites most likely to be abused are typically also the ones most likely to neglect installing appropriate filtering at their edges 🥀.
- The traffic passes through one or two relays, and traffic rate limiting in the 6to4 relays might help tone down the reflection attack 🐢.
COMPARISON TO SITUATION WITHOUT 6to4 🆚
Even with ways to mitigate it, the attack is still pretty efficient, especially when native IPv6 nodes use spoofed addresses 😵. Using 6to4 relays and routers could easily take down the 6to4 relay system, and/or give an easy means for traffic laundering 🧺. However, if the goal is to DoS the victim, that can be done more smoothly by attacking directly, since source address spoofing was available as well 🎯.
So the threat to the availability and stability of the 6to4 relay system itself seems to be higher than the threat to the native IPv6 Internet 💜.
4.2.4. Local IPv4 Broadcast Attack 📡
This attack is similar to the ones used against 6to4 routers, as described in Section 4.1.4 🙌. There are slight differences in where the attacks come from. This attack can be started by:
- native IPv6 nodes that may send traffic to the relay's subnet broadcast address, and
- IPv4 nodes that may send traffic with a spoofed source IP address (to be the relay's broadcast address) to elicit replies (e.g., ICMPv6 Hop Limit Exceeded) from the 6to4 relay to its local nodes 🫣.
The first approach is more dangerous than those in Section 4.1.4, because any IPv6 node (allowed to use the relay) can start it. It isn't limited to local users 🚨.
The second approach is trickier and not really useful 🙄. For it to work, the relay would have to accept native source addresses over the 6to4 pseudo-interface (we did not assume this check was implemented), as if they came from another relay, which would trigger an ICMPv6 message to the relay's local IPv4 subnet. The former method is more lucrative 💰.
EXTENSIONS 🌸
None.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS 🔍
The threat is restricted to the relay's local subnet, and it's fixed by tightening the 6to4 security checks 🔧.
COMPARISON TO SITUATION WITHOUT 6to4 🆚
This scenario is caused by 6to4, but thankfully the issue isn't serious 🥰.
4.2.5. Theft of Service 🎟️
ATTACK DESCRIPTION 💥
6to4 relay administrators would often want some policy to limit use of the relay to specific 6to4 sites and/or specific IPv6 sites 📋.
That policy control is usually enacted by applying restrictions on where the routing information for 2002::/16 and/or 192.188.99.0/24 (if the anycast address used [3]) will spread 🗺️.
Some users may still be able to use the service regardless of these controls, by:
- configuring the address of the relay using its IPv4 address instead of
192.88.99.1, or - using the routing header to route IPv6 packets to reach specific 6to4 relays. (Other routing tricks, such as using static routes, may also be used.) 🛣️
EXTENSIONS 🌸
None.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS 🔍
Attempts to use the relay's IPv4 address instead of 192.88.99.1 can be mitigated in these ways:
- IPv4 domains should prevent use of the actual IPv4 address of the relay instead of
192.88.99.1🚫. - Use access lists in the 6to4 relay to limit access. This is only feasible if the number of IP networks the relay is supposed to serve is relatively low 📑.
- The 6to4 relay should filter out arriving tunneled packets with protocol 41 (IPv6) that do not have
192.88.99.1as the destination address 🧹.
The other threat, using routing tricks in the IPv6 networks to reach the 6to4 relay, has similar solutions:
- Use access lists in the relay to limit access.
- Filter out the packets with a routing header (although this may have other implications) 🙈.
- Monitor the source addresses going through the relay to detect, e.g., peers setting up static routes 👀.
Routing Header isn't specific to 6to4. The main thing one could do with it here would be to select the relay. Some generic threats about routing header use are described in [11] 📚.
Since this threat doesn't have implications for anything other than the organization providing the 6to4 relay, it isn't analyzed any further 🤷♀️.
COMPARISON TO SITUATION WITHOUT 6to4 🆚
These threats are specific to 6to4 relays (or anycast services in general) and don't exist in networks without 6to4 🌷.
4.2.6. Relay Operators Seen as Source of Abuse 🎀
ATTACK DESCRIPTION
Okay so a bunch of attacks bounce their traffic through 6to4 relays to hide who's really sending it 🫥. This usually means packets get tunneled from the relay to a supposedly-6to4 site 📦.
BUT 🙃 like we said in Section 4.2, the relay's IPv4 source address could look (at a quick glance) like it's the one behind these "protocol-41" attacks 😬.
This could cause a bunch of drama for the operators running 6to4 relay service, including:
- getting blown up 📞 with contact attempts (email, phone, fax, or even lawyers) about suspected "abuse",
- having the whole IPv4 address range rejected as a source of abuse or spam, which causes outages for other operations too, or
- getting the whole IPv4 address range blacklisted in some "spammer databases", if the relay were used for those purposes 💀.
ngl this is kinda like the SMTP abuse mess caused by open relays, but way more general 🌈.
EXTENSIONS
None 🙅.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
This problem can be avoided (or, really, "made someone else's problem") by using the 6to4 anycast address in 192.88.99.0/24 as the source address ✨. Blacklisting or rejecting this should not cause problems to the other operations.
Further, when someone files complaints to the owner of 192.88.99.0/24, depending on which registry they are querying, they might get, for example:
- knowledge that this is a special IANA address block, with no real contact person,
- knowledge that this is a special address block for RFC 3068, or
- knowledge that this is a special address block for RFC 3068, and that there are multiple entries by relay operators in the database.
Any of these, at least when processed by a human, should show that the 6to4 relay is in fact innocent 🫶. Of course, this could result in reports going to the closest anycast 6to4 relay as well, which had nothing to do with the incident 😭.
However, the widespread usage of 192.88.99.1 as the source address may make it more difficult to disambiguate the relays, which might be a useful feature for debugging purposes 🔍.
COMPARISON TO SITUATION WITHOUT 6to4
This threat is caused by 6to4 deployment but can be avoided, at least in the short-term, by using 192.88.99.1 as the source address 💖.
4.3. Attacks on IPv4 Internet 🌸
There are two types of attacks on the IPv4 internet: spoofed traffic, and reflection. These can be initiated by native IPv6 nodes, 6to4 nodes, and IPv4 nodes 🦋.
Attacks initiated by IPv4 nodes that send spoofed traffic, which would not use the 6to4 infrastructure, are considered out of the scope of this document. 6to4 infrastructure may be used in reflection attacks initiated by IPv4 nodes.
It is difficult for these attacks to be effective, as the traffic sent out will be IPv6-in-IPv4. Such traffic will be rejected by most IPv4 nodes unless they have implemented some sort of IPv6-in-IPv4 tunneling 🙈.
4.4. Summary of the Attacks 📊
Columns:
- Section number. The section that describes the attack.
- Attack name.
- Initiator. The node that initiates the attack.
I_4- IPv4 nodeI_6- native IPv6 node6to4- 6to4 node*- All of the above
- Victim. The victim node
I_4- IPv4 nodeI_6- native IPv6 node6to4- 6to4 nodeRelay- 6to4 relayRouter- 6to4 router
- ToA. Type of Attack
D- DoSR- Reflection DoST- Theft of Service
- Fix. Specified who is responsible for fixing the attack.
6- The 6to4 developer and/or operator can completely mitigate this attack.6*- The 6to4 developer and/or operator can partially mitigate this attack.E- This threat cannot be fixed by the 6to4 developer or the 6to4 operator.
Summary of attacks on a 6to4 network:
+-------+----------------------+---------+----------+-----+-----+
| Sec | Attack name |Initiator| Victim | ToA | Fix |
+-------+----------------------+---------+----------+-----+-----+
| 4.1.1 | Attacks with ND | I_4 | Router | D | 6 |
+-------+----------------------+---------+----------+-----+-----+
| 4.1.2 | Spoofing Traffic | I_4,I_6 | 6to4 | D | E |
+-------+----------------------+---------+----------+-----+-----+
| 4.1.3 | Reflection Attacks | * | 6to4 | R | 6* |
+-------+----------------------+---------+----------+-----+-----+
| 4.1.4 | Local IPv4 Broadcast | * | Router | D | 6 |
+-------+----------------------+---------+----------+-----+-----+Figure 9 🍓
Summary of attacks on the native IPv6 internet:
+-------+----------------------+---------+----------+-----+-----+
| Sec | Attack name |Initiator| Victim | ToA | Fix |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.1 | Attacks with ND | I_4 | Relay | D | 6 |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.2 | Spoofing Traffic | I_4,6to4| I_6 | D | 6* |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.3 | Reflection Attacks | * | I_6 | R | 6* |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.4 | Local IPv4 Broadcast | * | Relay | D | 6 |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.5 | Theft of Service | 6to4 | Relay | T | 6 |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.6 | Relay Operators ... | - | - | D | 1) |
+-------+----------------------+---------+----------+-----+-----+Figure 10 💜
Notes:
- This attack is a side-effect of the other attacks and thus does not have any Initiator, Victim, and Fix. It is a Denial of Service attack not on the network but on the organization in-charge of the relay 📣.
Summary of attacks on IPv4 internet:
+-------+----------------------+---------+----------+-----+-----+
| Sec | Attack name |Initiator| Victim | ToA | Fix |
+-------+----------------------+---------+----------+-----+-----+
| 4.3 | Spoofing Traffic | * | I_4 | D | 6* |
+-------+----------------------+---------+----------+-----+-----+
| 4.3 | Reflection Attacks | * | I_4 | R | 6* |
+-------+----------------------+---------+----------+-----+-----+Figure 11 🌈
5. Implementing Proper Security Checks in 6to4 🔐
This section describes several ways to implement the security checks required or implied by the specification [1] or augmented by this memo. These do not, in general, protect against most of the threats listed above in the "Threat Analysis" section. They are only prerequisites for a relatively safe and simple 6to4 implementation ✨.
Note that, in general, the 6to4 router or relay does not know whether it is acting as a router or relay. It would be possible to include a toggle to specify the behaviour, to be used when, e.g., the interface is brought up, but as of February 2004, no implementations were known to do that. Therefore, the checks are described as that which works independently of whether the node is a router or relay 🤷♀️.
5.1. Encapsulating IPv6 into IPv4 🎀
The checks described in this section are to be performed when encapsulating IPv6 into IPv4.
The encapsulation rules are mainly designed to keep implementors from "shooting themselves in the foot" 🦶💀. For example, the source address check would verify that the packet will be acceptable to the decapsulator, or the sanity checks would ensure that addresses derived from private addresses are not used (which would be equally unacceptable).
src_v6 and dst_v6 MUST pass ipv6-sanity checks (see below) else drop
if prefix (src_v6) == 2002::/16
ipv4 address embedded in src_v6 MUST match src_v4
else if prefix (dst_v6) == 2002::/16
dst_v4 SHOULD NOT be assigned to the router
else
drop
/* we somehow got a native-native ipv6 packet */
fi
accept5.2. Decapsulating IPv4 into IPv6 🦋
The checks described in this section are to be performed when decapsulating IPv4 into IPv6. They will be performed in both the 6to4 router and relay.
src_v4 and dst_v4 MUST pass ipv4-sanity checks, else drop
src_v6 and dst_v6 MUST pass ipv6-sanity checks, else drop
if prefix (dst_v6) == 2002::/16
ipv4 address embedded in dst_v6 MUST match dst_v4
if prefix (src_v6) == 2002::/16
ipv4 address embedded in src_v6 MUST match src_v4
dst_v4 SHOULD be assigned to the router
fi
elif prefix (src_v6) == 2002::/16
ipv4 address embedded in src_v6 MUST match src_v4
dst_v4 SHOULD be assigned to the router (see notes below)
else
drop
/* the we somehow got a native-native ipv6 packet */
fi
accept5.3. IPv4 and IPv6 Sanity Checks 🧼
The encapsulation and decapsulation checks include certain sanity checks for both IPv4 and IPv6. These are described here in detail.
5.3.1. IPv4 🌐
IPv4 address MUST be a global unicast address, as required by the 6to4 specification. The disallowed addresses include those defined in [14], and others widely used and known not to be global. These are:
0.0.0.0/8(the system has no address assigned yet)10.0.0.0/8(private)127.0.0.0/8(loopback)172.16.0.0/12(private)192.168.0.0/16(private)169.254.0.0/16(IANA Assigned DHCP link-local)224.0.0.0/4(multicast)240.0.0.0/4(reserved and broadcast)
In addition, the address MUST NOT be any of the system's broadcast addresses. This is especially important if the implementation is made so that it can:
- receive and process encapsulated IPv4 packets arriving at its broadcast addresses, or
- send encapsulated IPv4 packets to one of its broadcast addresses.
5.3.2. IPv6 💜
IPv6 address MUST NOT be:
0::/16(compatible, mapped addresses, loopback, unspecified, ...)fe80::/10(link-local)fec0::/10(site-local)ff00::/8(any multicast)
Note: Only link-local multicast would be strictly required, but it is believed that multicast with 6to4 will not be feasible, so it has been disallowed as well.
In addition, it MUST be checked that equivalent 2002:V4ADDR::/48 checks, where V4ADDR is any of the above IPv4 addresses, will not be passed.
5.3.3. Optional Ingress Filtering 🚧
In addition, the implementation in the 6to4 router may perform some form of ingress filtering (e.g., Unicast Reverse Path Forwarding checks). For example, if the 6to4 router has multiple interfaces, of which some are "internal", receiving either IPv4 or IPv6 packets with source address belonging to any of these internal networks from the Internet might be disallowed.
If these checks are implemented and enabled by default, it's recommended that there be a toggle to disable them if needed 🫶.
5.3.4. Notes about the Checks ✨
okay so the rule "dst_v4 SHOULD be assigned to the router" is not needed if the 6to4 router only accepts and processes encapsulated IPv4 packets that arrive at its unicast IPv4 addresses. it's also not needed when the destination is known to be a local broadcast address, as long as the router doesn't try to encapsulate and send packets to it 💅 (see Sections 4.1.4 and 4.2.4 about this threat)
some checks, especially the IPv4/IPv6 Sanity Checks, could be at least partially done with system-level access lists, if you want to avoid putting too many restrictions in the 6to4 implementation itself 🎀 whether that works depends on how many hooks the access lists have. in practice, it seems like it couldn't be done effectively enough unless the access list mechanism can parse the encapsulated packets 🙈
6. Issues in 6to4 Implementation and Use 🧚
this section gives an overview of some of the problems 6to4 implementations run into, plus the kinds of generic problems 6to4 users could come up with 💖
6.1. Implementation Considerations with Automatic Tunnels
there's a problem with multiple transition mechanisms if strict security checks are implemented 😭 this may vary a bit from implementation to implementation.
consider three mechanisms that use automatic tunneling: 6to4, ISATAP [15], and Automatic Tunneling using Compatible Addresses [4] (currently removed [10] but typically still supported). all of these use IP-IP (protocol 41) [16] IPv4 encapsulation with, more or less, a pseudo-interface 🦋
when a router that has any two of these enabled receives an IPv4 encapsulated IPv6 packet like this:
src_v6 = 2001:db8::1
dst_v6 = 2002:1010:1010::2
src_v4 = 10.0.0.1
dst_v4 = 20.20.20.20what can it do? how should it decide which transition mechanism this belongs to? there's no "transition mechanism number" in the IPv6 or IPv4 header to signify this 🤔 (this can also be viewed as a flexibility benefit 🌈)
without any kind of security checks (in any of the implemented methods), these often just "work", because the mechanisms aren't differentiated and get handled in "one big lump" 🍓
configured tunneling [4] doesn't suffer from this. it's point-to-point and based on src_v6/dst_v6 pairs of both IPv4 and IPv6 addresses, so the tunnel interface can be logically deduced 👑
solutions for this include 1) not using more than one automatic tunneling mechanism in a node and 2) binding different mechanisms to different IPv4 addresses ✨
6.2. A Different Model for 6to4 Deployment
even though this was already discussed in Section 4.1.2, it deserves some extra elaboration, because it was the only problem that can't even be partially solved using the current deployment model 😤 there are some mitigation methods, though.
6to4 routers receive traffic from non-6to4 ("native") sources via 6to4 relays. 6to4 routers have no way of matching the IPv4 source address of the relay with the non-6to4 IPv6 address of the source. so, anyone can spoof any non-6to4 IPv6 address by sending encapsulated traffic directly to 6to4 routers 🙈 this is the "relay spoofing" chaos we're dealing with.
it could be possible to flip the deployment assumptions around a bit to get rid of some threats caused by untrusted 6to4 relays:
- every dual-stack site (or even ISP) would be required to have its own 6to4 relay. (this assumes that IPv6-only is so far away that 6to4 would be retired by that point.) that is, there would not be third-party relays, and 2002::/16 and 192.88.99.0/24 routes would not need to be advertised globally.
- the security implications of 6to4 use could be pushed back to the level of trust inside the site or ISP (or their acceptable use policies). this is something the sites and ISPs should already be familiar with 🫶
however, this presents a number of problems 😬
this model would shift most of the burden of supporting 6to4 onto IPv6 sites that don't employ or use 6to4 at all, i.e., "those who deploy proper native dual-stack." it could be argued that the deployment pain should be borne by 6to4 users, not by the others 💅
the main advantage of 6to4 is easy deployment and free relays. this would require that everyone the 6to4 sites wish to communicate with implements these measures 💀
the model would not fix the "relay spoofing problem", unless everybody also deployed 6to4 addresses on the nodes (alongside native addresses, if necessary), which would in turn change 6to4 to operate without relays completely 🌸
7. Security Considerations 🔥
this document discusses security considerations of 6to4. please take these seriously, bestie 😭
even if proper checks are implemented, there are a large number of different security threats 💀 these threats are analyzed in Section 4.
there are mainly four classes of potential problem sources:
- 6to4 routers not being able to identify whether relays are legitimate
- wrong or impartially implemented 6to4 router or relay security checks
- 6to4 architecture used to participate in DoS or reflected DoS attacks, or made to participate in "packet laundering", i.e., making another attack harder to trace
- 6to4 relays being subject to "administrative abuse", e.g., theft of service or being seen as a source of abuse
the first is the toughest problem, and it's still under research 🧠 the second can be fixed by ensuring the correctness of implementations, and this is important ✅ the third is also a very difficult problem, impossible to solve completely, so it's important to be able to analyze whether this results in a significant increase of threats 👀 the fourth problem seems to have feasible solutions 🎀
these are analyzed in detail in "Threat Analysis", in Section 4.
8. Acknowledgments 💜
some issues were first brought up by Itojun Hagino in [17], and Alain Durand introduced one specific problem at IETF51 in August 2001 (though there was some discussion on the list before that). these two gave the authors the push to start looking into the details of securing 6to4 🫶
Alexey Kuznetsov brought up the implementation problem with IPv6 martian checks. Christian Huitema formulated the rules that rely on 6to4 relays using only anycast. Keith Moore brought up the point about reduced flexibility. Brian Carpenter, Tony Hain, and Vladislav Yasevich are acknowledged for lengthy discussions. Alain Durand reminded the authors about relay spoofing problems. Brian Carpenter reminded the authors about the BGP-based 6to4 router model. Christian Huitema gave a push for a more complete threat analysis. Itojun Hagino spelled out the operators' fears about 6to4 relay abuse. Rob Austein brought up the idea of a different 6to4 deployment model 👑
in the latter phase, discussions with Christian Huitema, Brian Carpenter, and Alain Durand were helpful when improving the document 🌈
David Malone, Iljitsch van Beijnum, and Tim Chown gave feedback on the document 🧚
9. References 📚
9.1. Normative References
[1] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
9.2. Informative References
[4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
[5] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[6] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[7] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[8] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[9] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", Work in Progress, July 2004.
[10] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", Work in Progress, September 2004.
[11] Savola, P., "Security of IPv6 Routing Header and Home Address Options", Work in Progress, March 2002.
[12] 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.
[13] Bellovin, S., Leech, M. and T. Taylor, "ICMP Traceback Messages", Work in Progress, February 2003.
[14] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[15] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", Work in Progress, May 2004.
[16] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[17] Hagino, J., "Possible abuse against IPv6 transition technologies", Work in Progress, July 2000.
Appendix A. Some Trivial Attack Scenarios Outlined 🕵️♀️
here, a few trivial attack scenarios are outlined, ones that are prevented by implementing the checks listed in [1] or in Section 6 💅
when two 6to4 routers send traffic to each other's domains, the packet sent by RA to RB looks like this:
src_v6 = 2002:0800:0001::aaaa
dst_v6 = 2002:0800:0002::bbbb
src_v4 = 8.0.0.1 (added when encapsulated to IPv4)
dst_v4 = 8.0.0.2 (added when encapsulated to IPv4)when the packet is received by the IPv4 stack on RB, it gets decapsulated so that only src_v6 and dst_v6 remain, as originally sent by RA:
src_v6 = 2002:0800:0001::aaaa
dst_v6 = 2002:0800:0002::bbbbas every other node is just one hop away (IPv6-wise) and the link-layer (IPv4) addresses are lost, this may open many possibilities for misuse 😱
as an example, unidirectional IPv6 spoofing is made trivial, because nobody can check (without delving into IP-IP packets) whether the encapsulated IPv6 addresses were authentic. (with native IPv6, this can be done by, e.g., RPF-like mechanisms or access lists in upstream routers.)
src_v6 = 2002:1234:5678::aaaa (forged)
dst_v6 = 2002:0800:0002::bbbb
src_v4 = 8.0.0.1 (added when encapsulated to IPv4)
dst_v4 = 8.0.0.2 (added when encapsulated to IPv4)a similar attack with "src" being the native address is made possible, even with the security checks, by having the sender node pretend to be a 6to4 relay router 🥸
more worries come into the picture if, e.g.,
src_v6 = ::ffff:[some trusted IPv4 in a private network]
src_v6/dst_v6 = ::ffff:127.0.0.1
src_v6/dst_v6 = ::1
src_v6/dst_v6 = ...some implementations might have been careful enough to design the stack so that incoming (or reply) packets don't go into IPv4 packet processing through special addresses (e.g., IPv4-mapped addresses), but who can say for all ... 🫣
Authors' Addresses 💌
Pekka Savola
CSC/FUNET
Espoo
Finland
EMail: psavola@funet.fi
Chirayu Patel
All Play, No Work
185, Defence Colony
Bangalore, Karnataka 560038
India
Phone: +91-98452-88078
EMail: chirayu@chirayu.org
URI: http://www.chirayu.orgFull Copyright Statement 💅
Okay bestie, the legal bit at the end 🙈 Copyright is The Internet Society (2004) 🎀
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. ✨
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🦋
Intellectual Property 🧚
The IETF takes no position on whether any Intellectual Property Rights or other rights might be claimed to apply to the implementation or use of the technology in this document, or on how far any license under those rights might or might not be available. It also doesn't claim to have done any independent digging to find such rights. 🌸 If you want the IETF's rules on rights in IETF Documents, check out BCP 78 and BCP 79. 📚
Copies of IPR disclosures made to the IETF Secretariat, plus any assurances of licenses that are meant to be available, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr. The same goes for the result of any attempt to get a general license or permission to use these proprietary rights, which implementers or users of this specification might have made. 💜
The IETF invites anyone who's interested to bring any copyrights, patents, patent applications, or other proprietary rights to its attention, especially if they might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 💌
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. 👑
📦 where this page comes from
- ietf: rfc3964 2004-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms