Request for Comments: 3964 CSC/FUNET
Category: Informational C. Patel
All Play, No Work
December 2004
Security Considerations for 6to4
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
The IPv6 interim mechanism 6to4 (RFC3056) uses automatic
IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The
architecture includes 6to4 routers and 6to4 relay routers, which
accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from
any node in the IPv4 internet. This characteristic enables a number
of security threats, mainly Denial of Service. It also makes it
easier for nodes to spoof IPv6 addresses. This document discusses
these issues in more detail and suggests enhancements to alleviate
the problems.
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 . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction
The IPv6 interim mechanism "6to4" [1] specifies automatic
IPv6-over-IPv4 tunneling to interconnect isolated IPv6 clouds by
embedding the tunnel IPv4 address in the IPv6 6to4 prefix.
Two characteristics of the 6to4 mechanism introduce most of the
security considerations:
1. All 6to4 routers must accept and decapsulate IPv4 packets from
every other 6to4 router, and from 6to4 relays.
2. 6to4 relay routers must accept traffic from any native IPv6 node.
As the 6to4 router must accept traffic from any other 6to4 router or
relay, a certain requirement for trust is implied, and there are no
strict constraints on what the IPv6 packet may contain. Thus,
addresses within the IPv4 and IPv6 headers may be spoofed, and this
leads to various types of threats, including different flavors of
Denial of Service attacks.
The 6to4 specification outlined a few security considerations and
rules but was ambiguous as to their exact requirement level.
Moreover, the description of the considerations was rather short, and
some of them have proven difficult to understand or impossible to
implement.
This document analyzes the 6to4 security issues in more detail and
outlines some enhancements and caveats.
Sections 2 and 3 are more or less introductory, rehashing how 6to4 is
used today based on the 6to4 specification, so that it is easier to
understand how security could be affected. Section 4 provides a
threat analysis for implementations that already implement most of
the security checks. Section 5 describes the optimal
decapsulation/encapsulation rules for 6to4 implementations, and
Section 6 provides further discussion on a few issues that have
proven difficult to implement. Appendix A outlines a few possible
trivial attack scenarios in which very little or no security has been
implemented.
For the sake of simplicity, in this document, the native Internet is
assumed to encompass IPv6 networks formed by using other transition
mechanisms (e.g., RFC 2893 [4]), as these mechanisms cannot 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 interpreted as described in BCP 14, RFC 2119 [2].
Throughout this memo, IPv4 addresses from blocks 7.0.0.0/24,
8.0.0.0/24, and 9.0.0.0/24 are used for demonstrative purposes, to
represent global IPv4 addresses that have no relation to each other.
This approach was chosen instead of just using addresses from
192.0.2.0/24 [5] for two reasons: to use addresses whose 6to4 mapping
is glaringly obvious, and to make it obvious that the IPv4 addresses
of different 6to4 gateways need not have any relation to each other.
2. Different 6to4 Forwarding Scenarios
Note that when one communicates between 6to4 and native domains, the
6to4 relays that will be used in the two directions are very likely
different; routing is highly asymmetric. Because of this, it is not
feasible to limit relays from which 6to4 routers may accept traffic.
The first three subsections introduce the most common forms of 6to4
operation. Other models are presented in the fourth subsection.
2.1. From 6to4 to 6to4
6to4 domains always exchange 6to4 traffic directly via IPv4
tunneling; the endpoint address V4ADDR is derived from 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).
2.2. From Native to 6to4
When native domains send traffic to 6to4 prefix 2002:V4ADDR::/48, it
will be routed to the topologically nearest advertising 6to4 relay
(advertising route to 2002::/16). The 6to4 relay will tunnel the
traffic over IPv4 to the corresponding IPv4 address V4ADDR.
Note that IPv4 address 9.0.0.1 here is just an example of a global
IPv4 address, and it is 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, or the closest one found by
using 6to4 IPv4 Anycast [3]. The relay will decapsulate the packet
and forward it to native IPv6 Internet, as would any other IPv6
packet.
Note that the destination IPv6 address in the packet is a non-6to4
address and is assumed to be 2001:db8::1 in the example.
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) will be considered.
2.4.1. BGP between 6to4 Routers and Relays
Section 5.2.2.2 in [1] presents a model where, instead of static
configuration, BGP [6] is used between 6to4 relay routers and 6to4
routers (for outgoing relay selection only).
Going further than [1], if the 6to4 router established a BGP session
between all the possible 6to4 relays and advertised its /48 prefix to
them, the traffic from non-6to4 sites would always come from a
"known" relay. Alternatively, the 6to4 relays might advertise the
more specific 6to4 routes between 6to4 relays.
Both of these approaches are obviously infeasible due to scalability
issues.
Neither of these models are known to be used at the time of writing;
this is probably because parties that need 6to4 are not able to run
BGP, and because setting up these sessions would be much more work
for relay operators.
2.4.2. 6to4 as an Optimization Method
Some sites seem to use 6to4 as an IPv6 connectivity "optimization
method"; that is, they also have non-6to4 addresses on their nodes
and border routers but also employ 6to4 to reach 6to4 sites.
This is typically done to be able to reach 6to4 destinations by
direct tunneling without using relays at all.
These sites also publish both 6to4 and non-6to4 addresses in DNS to
affect inbound connections. If the source host’s default address
selection [7] works properly, 6to4 sources will use 6to4 addresses to
reach the site and non-6to4 nodes use non-6to4 addresses. If this
behavior of foreign nodes can be assumed, the security threats to
such sites can be significantly simplified.
2.4.3. 6to4 as Tunnel End-Point Addressing Mechanism
6to4 addresses can also be used only as an IPv6-in-IPv4 tunnel
endpoint addressing and routing mechanism.
An example of this is interconnecting 10 branch offices where nodes
use non-6to4 addresses. Only the offices’ border routers need to be
aware of 6to4, and use 6to4 addresses solely for addressing the
tunnels between different branch offices. An example is provided in
the figure below.
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 4
In 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::1
And a branch office sets up two routes as well:
2001:db8:0:20::/60 -> 2002:0800:0002::1
default -> 2002:0700:0003::1
Thus, the IPv4 Internet is treated as an NBMA link-layer for
interconnecting 6to4-enabled sites; with explicit routes, 6to4
addressing need not be used in routers other than the 6to4 edge
routers. However, note that if a branch office sends a packet to any
6to4 destination, it will not go through the main office, as the 6to4
2002::/16 route overrides the default route.
This approach may make addressing and routing slightly easier in some
circumstances.
3. Functionalities of 6to4 Network Components
This section summarizes the main functionalities of the 6to4 network
components (6to4 routers, and 6to4 relays) and the security checks
they must do. The pseudo-code for the security checks is provided in
Section 5.
This section summarizes the main functions of the various components
of a 6to4 network: 6to4 relay routers and 6to4 routers. Refer to
Section 1.1 of RFC 3056 [1] for 6to4-related definitions.
3.1. 6to4 Routers
The 6to4 routers act as the border routers of a 6to4 domain. It does
not have a native global IPv6 address except in certain special
cases. Since the specification [1] uses the term "6to4 router", this
memo does the same; however, note that in this definition, we also
include a single host with a 6to4 pseudo-interface, which doesn’t
otherwise act as a router. The main functions of the 6to4 router are
as follows:
o Provide IPv6 connectivity to local clients and routers.
o Tunnel packets sent to foreign 6to4 addresses to the destination
6to4 router using IPv4.
o Forward packets sent to locally configured 6to4 addresses to the
6to4 network.
o Tunnel packets sent to non-6to4 addresses to the configured/
closest-by-anycast 6to4 relay router.
o Decapsulate directly received IPv4 packets from foreign 6to4
addresses.
o Decapsulate IPv4 packets received via the relay closest to the
native IPv6 sources. Note that it is not easily distinguishable
whether the packet was received from a 6to4 relay router or from a
spoofing third party.
The 6to4 router should also perform security checks on traffic that
it receives from other 6to4 relays, or 6to4 routers, or from within
the 6to4 site. These checks include the following:
o 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.
o 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.)
o 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.
o Disallow traffic transmission to other 6to4 domains through 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.)
o Discard traffic received from other 6to4 domains via a 6to4 relay
router.
o Discard traffic received for prefixes other than one’s own 6to4