the same as the one embedded in the source IPv6 address. Thus,
6to4 nodes will be forced to use the correct IPv6 prefix while
launching an attack, making it easy to close such attacks.
o Packets may pass through choke point(s), namely a 6to4 relay. In
addition to physical limitations, there could be some sort of
traffic rate limiting mechanisms that may be implemented, and
these could tone down the attack.
o For every packet sent, at most one reply packet is generated:
There is no amplification factor.
Some of the mitigation methods for such attacks are as follows:
1. Ingress filtering in the IPv4 Internet to prevent packets with a
spoofed IPv4 source from being transmitted. As the relay checks
that the 6to4 address embeds the IPv4 address, no spoofing can be
achieved unless IPv4 addresses can be spoofed. However, this
would probably be an unfeasible requirement.
2. 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
threat appears to be slightly more manageable. If the relays perform
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 that 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 initiated by one of
the following:
o 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.
o 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.
o 6to4 nodes. These nodes can perform 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 launched from a native IPv6 node, the traffic goes through 6to4
relays twice, both before and after the reflection; when launched
from a 6to4/IPv4 node, the traffic goes through a relay only after
the reflection.
EXTENSIONS
A distributed reflection DoS can be performed 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 such attacks are as follows:
1. Attacks from the native IPv6 nodes could be stopped by
implementing ingress filtering in the IPv6 Internet; hopefully
this will become commonplace, but past experience of IPv4 ingress
filtering deployment (or lack thereof) does not promise much.
2. Two measures are needed to stop or mitigate the attacks from IPv4
nodes: 1) Implementing ingress filtering in the IPv4 internet,
and 2) logging IPv4 source addresses in the 6to4 router.
3. Attacks from 6to4 nodes in other sites can be stopped if the 6to4
routers in those sites implement egress filtering. This could be
done by those sites, but the sites that are most likely to be
abused are typically also those most likely to neglect installing
appropriate filtering at their edges.
4. 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 though there are means to mitigate it, the attack is still
rather efficient, especially when used by native IPv6 nodes with
spoofed addresses. Using 6to4 relays and routers could easily take
down the 6to4 relay system and/or provide an easy means for traffic
laundering. However, if the attack is intended to DoS the victim,
this can be achieved more smoothly by doing it directly (as the
source address spoofing was available as well).
Therefore, the threat to the availability and stability of the 6to4
relay system itself seems to be higher than to the native IPv6
Internet.
4.2.4. Local IPv4 Broadcast Attack
This attack is similar to the ones employed against 6to4 routers, as
described in Section 4.1.4. There are slight differences with regard
to the source of the attacks. This attack can be initiated by:
o native IPv6 nodes that may send traffic to the relay’s subnet
broadcast address, and
o 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 it can be initiated by any IPv6 node (allowed to use the
relay); the approach is not limited to local users.
The second approach is trickier and not really useful. For it to
succeed, the relay would have to accept native source addresses over
the 6to4 pseudo-interface (we did not assume this check was
implemented), as if coming from another relay, triggering 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 is fixed by
tightening the 6to4 security checks.
COMPARISON TO SITUATION WITHOUT 6to4
This scenario is caused by 6to4, but fortunately the issue is not
serious.
4.2.5. Theft of Service
ATTACK DESCRIPTION
The 6to4 relay administrators would often want to use some policy to
limit the use of the relay to specific 6to4 sites and/or specific
IPv6 sites.
The policy control is usually enacted by applying restrictions to
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 be able to use the service regardless of these
controls, by
o configuring the address of the relay using its IPv4 address
instead of 192.88.99.1, or
o 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 the following ways:
1. IPv4 domains should prevent use of the actual IPv4 address of the
relay instead of 192.88.99.1.
2. Usage of 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.
3. The 6to4 relay should filter out arriving tunneled packets with
protocol 41 (IPv6) that do not have 192.88.99.1 as the
destination address.
The other threat, of using routing tricks in the IPv6 networks to
reach the 6to4 relay, has similar solutions:
1. Usage of access lists in the relay to limit access.
2. Filtering out the packets with a routing header (although this
may have other implications).
3. Monitoring the source addresses going through the relay to
detect, e.g., peers setting up static routes.
Routing Header is not 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].
As this threat does not have implications for anything other than the
organization providing 6to4 relay, it is not analyzed any further.
COMPARISON TO SITUATION WITHOUT 6to4
These threats are specific to 6to4 relays (or in general anycast
services) and do not exist in networks without 6to4.
4.2.6. Relay Operators Seen as Source of Abuse
ATTACK DESCRIPTION
Several attacks use 6to4 relays to anonymize the traffic; this often
results in packets being tunneled from the relay to a supposedly-6to4
site.
However, as was pointed out in Section 4.2, the IPv4 source address
used by the relay could, on a cursory look, be seen as the source of
these "protocol-41" attacks.
This could cause a number of concerns for the operators deploying
6to4 relay service, including the following:
o being contacted a lot (via email, phone, fax, or lawyers) on
suspected "abuse",
o having the whole IPv4 address range rejected as a source of abuse
or spam, causing outage to other operations as well, or
o causing the whole IPv4 address range to be blacklisted in some
"spammer databases", if the relay were used for those purposes.
This threat seems slightly similar to the outburst of SMTP abuse
caused by open relays but is more generic.
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:
o knowledge that this is a special IANA address block, with no real
contact person,
o knowledge that this is a special address block for RFC 3068, or
o 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:
o Section number. The section that describes the attack.
o Attack name.
o Initiator. The node that initiates the attack.
* I_4 - IPv4 node
* I_6 - native IPv6 node
* 6to4 - 6to4 node
* * - All of the above
o Victim. The victim node
* I_4 - IPv4 node
* I_6 - native IPv6 node
* 6to4 - 6to4 node
* Relay - 6to4 relay
* Router - 6to4 router
o ToA. Type of Attack
* D - DoS
* R - Reflection DoS
* T - Theft of Service
o 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:
1) 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
accept
5.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
accept
5.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
o 0.0.0.0/8 (the system has no address assigned yet)
o 10.0.0.0/8 (private)
o 127.0.0.0/8 (loopback)
o 172.16.0.0/12 (private)
o 192.168.0.0/16 (private)
o 169.254.0.0/16 (IANA Assigned DHCP link-local)
o 224.0.0.0/4 (multicast)
o 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
o receive and process encapsulated IPv4 packets arriving at its
broadcast addresses, or
o send encapsulated IPv4 packets to one of its broadcast addresses.
5.3.2. IPv6
IPv6 address MUST NOT be
o 0::/16 (compatible, mapped addresses, loopback, unspecified, ...)
o fe80::/10 (link-local)
o fec0::/10 (site-local)
o 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
The rule "dst_v4 SHOULD be assigned to the router" is not needed if
the 6to4 router implementation only accepts and processes
encapsulated IPv4 packets arriving to its unicast IPv4 addresses, and
when the destination address is known to be a local broadcast
address, it does not 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 implementable with system-level access lists, if one
would like to avoid placing too many restrictions in the 6to4
implementation itself. This depends on how many hooks are in place
for the access lists. In practice, it seems that this could not be
done effectively enough unless the access list mechanism is able to
parse the encapsulated packets.
6. Issues in 6to4 Implementation and Use
This section tries to give an overview of some of the problems 6to4
implementations face, and the kind of generic problems the 6to4 users
could come up with.
6.1. Implementation Considerations with Automatic Tunnels
There is a problem with multiple transition mechanisms if strict
security checks are implemented. This may vary a bit from
implementation to implementation.
Consider three mechanisms using 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, which has any two of these enabled, receives an IPv4
encapsulated IPv6 packet
src_v6 = 2001:db8::1
dst_v6 = 2002:1010:1010::2
src_v4 = 10.0.0.1
dst_v4 = 20.20.20.20
What can it do? How should it decide which transition mechanism this
belongs to; there is 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", as the mechanisms aren’t
differentiated but handled in "one big lump".
Configured tunneling [4] does not suffer from this, as it is
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 bears
some additional elaboration, as it was the only problem that cannot
be even partially solved using the current deployment model. There
are some mitigation methods.
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.
Consequently, anyone can spoof any non-6to4 IPv6 address by sending
traffic, encapsulated, directly to 6to4 routers.
It could be possible to turn the deployment assumptions of 6to4
around a bit to eliminate some threats caused by untrusted 6to4
relays:
o Every dual-stack site (or even ISP) would be required to have its