draft-ietf-v6ops-6to4-security-04.txt   rfc3964.txt 
v6ops Working Group P. Savola Network Working Group P. Savola
Internet-Draft CSC/FUNET Request for Comments: 3964 CSC/FUNET
Expires: January 16, 2005 C. Patel Category: Informational C. Patel
All Play, No Work All Play, No Work
July 18, 2004 December 2004
Security Considerations for 6to4 Security Considerations for 6to4
draft-ietf-v6ops-6to4-security-04.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This memo provides information for the Internet community. It does
of section 3 of RFC 3667. By submitting this Internet-Draft, each not specify an Internet standard of any kind. Distribution of this
author represents that any applicable patent or other IPR claims of memo is unlimited.
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 16, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
The IPv6 interim mechanism 6to4 (RFC3056) uses automatic The IPv6 interim mechanism 6to4 (RFC3056) uses automatic
IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The
architecture includes 6to4 routers and 6to4 relay routers, which architecture includes 6to4 routers and 6to4 relay routers, which
accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from
any node in the IPv4 internet. This characteristic enables a number any node in the IPv4 internet. This characteristic enables a number
of security threats, mainly Denial of Service. It also makes it of security threats, mainly Denial of Service. It also makes it
easier for nodes to spoof IPv6 addresses. This document discusses easier for nodes to spoof IPv6 addresses. This document discusses
these issues in more detail and suggests enhancements to alleviate these issues in more detail and suggests enhancements to alleviate
the problems. the problems.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Different 6to4 Forwarding Scenarios . . . . . . . . . . . . . 5 2. Different 6to4 Forwarding Scenarios . . . . . . . . . . . . . 4
2.1 From 6to4 to 6to4 . . . . . . . . . . . . . . . . . . . . 5 2.1. From 6to4 to 6to4 . . . . . . . . . . . . . . . . . . . 4
2.2 From Native to 6to4 . . . . . . . . . . . . . . . . . . . 6 2.2. From Native to 6to4 . . . . . . . . . . . . . . . . . . 5
2.3 From 6to4 to Native . . . . . . . . . . . . . . . . . . . 6 2.3. From 6to4 to Native . . . . . . . . . . . . . . . . . . 5
2.4 Other Models . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Other Models . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1 BGP Between 6to4 Routers and Relays . . . . . . . . . 7 2.4.1. BGP between 6to4 Routers and Relays . . . . . . 6
2.4.2 6to4 as an Optimization Method . . . . . . . . . . . . 7 2.4.2. 6to4 as an Optimization Method . . . . . . . . . 7
2.4.3 6to4 as Tunnel End-Point Addressing Mechanism . . . . 8 2.4.3. 6to4 as Tunnel End-Point Addressing Mechanism . . 8
3. Functionalities of 6to4 Network Components . . . . . . . . . . 9 3. Functionalities of 6to4 Network Components . . . . . . . . . . 9
3.1 6to4 Routers . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. 6to4 Routers . . . . . . . . . . . . . . . . . . . . . . 9
3.2 6to4 Relay Routers . . . . . . . . . . . . . . . . . . . . 11 3.2. 6to4 Relay Routers . . . . . . . . . . . . . . . . . . . 10
4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 12 4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 11
4.1 Attacks on 6to4 Networks . . . . . . . . . . . . . . . . . 13 4.1. Attacks on 6to4 Networks . . . . . . . . . . . . . . . . 12
4.1.1 Attacks with ND Messages . . . . . . . . . . . . . . . 13 4.1.1. Attacks with ND Messages . . . . . . . . . . . . 13
4.1.2 Spoofing Traffic to 6to4 Nodes . . . . . . . . . . . . 15 4.1.2. Spoofing Traffic to 6to4 Nodes . . . . . . . . . 14
4.1.3 Reflecting Traffic to 6to4 Nodes . . . . . . . . . . . 17 4.1.3. Reflecting Traffic to 6to4 Nodes . . . . . . . . 17
4.1.4 Local IPv4 Broadcast Attack . . . . . . . . . . . . . 19 4.1.4. Local IPv4 Broadcast Attack . . . . . . . . . . 19
4.2 Attacks on Native IPv6 Internet . . . . . . . . . . . . . 21 4.2. Attacks on Native IPv6 Internet . . . . . . . . . . . . 20
4.2.1 Attacks with ND Messages . . . . . . . . . . . . . . . 21 4.2.1. Attacks with ND Messages . . . . . . . . . . . . 21
4.2.2 Spoofing Traffic to Native IPv6 node . . . . . . . . . 21 4.2.2. Spoofing Traffic to Native IPv6 Nodes. . . . . . 21
4.2.3 Reflecting Traffic to Native IPv6 nodes . . . . . . . 23 4.2.3. Reflecting Traffic to Native IPv6 Nodes . . . . 23
4.2.4 Local IPv4 Broadcast Attack . . . . . . . . . . . . . 24 4.2.4. Local IPv4 Broadcast Attack . . . . . . . . . . 24
4.2.5 Theft of Service . . . . . . . . . . . . . . . . . . . 25 4.2.5. Theft of Service . . . . . . . . . . . . . . . . 25
4.2.6 Relay Operators Seen as Source of Abuse . . . . . . . 26 4.2.6. Relay Operators Seen as Source of Abuse . . . . 26
4.3 Attacks on IPv4 Internet . . . . . . . . . . . . . . . . . 28 4.3. Attacks on IPv4 Internet . . . . . . . . . . . . . . . . 28
4.4 Summary of the Attacks . . . . . . . . . . . . . . . . . . 28 4.4. Summary of the Attacks . . . . . . . . . . . . . . . . . 28
5. Implementing Proper Security Checks in 6to4 . . . . . . . . . 30 5. Implementing Proper Security Checks in 6to4 . . . . . . . . . 30
5.1 Encapsulating IPv6 into IPv4 . . . . . . . . . . . . . . . 31 5.1. Encapsulating IPv6 into IPv4 . . . . . . . . . . . . . . 31
5.2 Decapsulating IPv4 into IPv6 . . . . . . . . . . . . . . . 31 5.2. Decapsulating IPv4 into IPv6 . . . . . . . . . . . . . . 31
5.3 IPv4 and IPv6 Sanity Checks . . . . . . . . . . . . . . . 32 5.3. IPv4 and IPv6 Sanity Checks . . . . . . . . . . . . . . 32
5.3.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.3.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . 32
5.3.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.3.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . 33
5.3.3 Optional Ingress Filtering . . . . . . . . . . . . . . 33 5.3.3. Optional Ingress Filtering . . . . . . . . . . . 33
5.3.4 Notes About the Checks . . . . . . . . . . . . . . . . 33 5.3.4. Notes about the Checks . . . . . . . . . . . . . 33
6. Issues in 6to4 Implementation and Use . . . . . . . . . . . . 34 6. Issues in 6to4 Implementation and Use . . . . . . . . . . . . 34
6.1 Implementation Considerations with Automatic Tunnels . . . 34 6.1. Implementation Considerations with Automatic Tunnels . . 34
6.2 A Different Model for 6to4 Deployment . . . . . . . . . . 35 6.2. A Different Model for 6to4 Deployment . . . . . . . . . 35
7. Security Considerations . . . . . . . . . . . . . . . . . . . 36 7. Security Considerations . . . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 37
10.2 Informative References . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 38
A. Some Trivial Attack Scenarios Outlined . . . . . . . . . . . . 39 A. Some Trivial Attack Scenarios Outlined . . . . . . . . . . . . 39
B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . . 41 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
The IPv6 interim mechanism "6to4" [1] specifies automatic The IPv6 interim mechanism "6to4" [1] specifies automatic
IPv6-over-IPv4 tunneling to interconnect isolated IPv6 clouds by IPv6-over-IPv4 tunneling to interconnect isolated IPv6 clouds by
embedding the tunnel IPv4 address in the IPv6 6to4 prefix. embedding the tunnel IPv4 address in the IPv6 6to4 prefix.
Two characteristics of the 6to4 mechanism introduce most of the Two characteristics of the 6to4 mechanism introduce most of the
security considerations: security considerations:
1. All 6to4 routers must accept and decapsulate IPv4 packets from 1. All 6to4 routers must accept and decapsulate IPv4 packets from
every other 6to4 router, and 6to4 relays. every other 6to4 router, and from 6to4 relays.
2. 6to4 relay routers must accept traffic from any native IPv6 node. 2. 6to4 relay routers must accept traffic from any native IPv6 node.
Since the 6to4 router must accept traffic from any other 6to4 router As the 6to4 router must accept traffic from any other 6to4 router or
or relay, a certain requirement for trust is implied, and there are relay, a certain requirement for trust is implied, and there are no
no strict constraints on what the IPv6 packet may contain. Thus, strict constraints on what the IPv6 packet may contain. Thus,
addresses within the IPv4, and IPv6 header may be spoofed, and this addresses within the IPv4 and IPv6 headers may be spoofed, and this
property leads to various types of threats including different leads to various types of threats, including different flavors of
flavors of Denial of Service -attacks. Denial of Service attacks.
The 6to4 specification outlined a few security considerations and The 6to4 specification outlined a few security considerations and
rules, but was very ambiguous on their exact requirement level. rules but was ambiguous as to their exact requirement level.
Further, the description of the considerations was rather short, and Moreover, the description of the considerations was rather short, and
in fact, some of them have been proven to be difficult to understand some of them have proven difficult to understand or impossible to
or impossible to implement. implement.
This draft analyzes the 6to4 security issues in more detail and This document analyzes the 6to4 security issues in more detail and
outlines some enhancements and caveats. outlines some enhancements and caveats.
Section 2, and Section 3 are more or less introductory in nature, Sections 2 and 3 are more or less introductory, rehashing how 6to4 is
rehashing how 6to4 is used today based on the 6to4 specification, so used today based on the 6to4 specification, so that it is easier to
that it is easier to understand how security could be affected. understand how security could be affected. Section 4 provides a
Section 4 provides a threat analysis for implementations that already threat analysis for implementations that already implement most of
implement most of the security checks. Section 5 describes the the security checks. Section 5 describes the optimal
optimal decapsulation/encapsulation rules for 6to4 implementations, decapsulation/encapsulation rules for 6to4 implementations, and
and Section 6 provides further discussion on a few issues which have Section 6 provides further discussion on a few issues that have
proven to be difficult to implement. Appendix A outlines a few proven difficult to implement. Appendix A outlines a few possible
possible trivial attack scenarios in the case that very little or no trivial attack scenarios in which very little or no security has been
security has been implemented. implemented.
For the sake of simplicity, in this document, the native Internet is For the sake of simplicity, in this document, the native Internet is
assumed to encompass IPv6 networks formed using other transition assumed to encompass IPv6 networks formed by using other transition
mechanisms (e.g. RFC 2893 [4]), as these mechanisms cannot talk mechanisms (e.g., RFC 2893 [4]), as these mechanisms cannot talk
directly to the 6to4 network. directly to the 6to4 network.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2]. 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/ Throughout this memo, IPv4 addresses from blocks 7.0.0.0/24,
24 and 9.0.0.0/24 are used for demonstrative purposes, to represent 8.0.0.0/24, and 9.0.0.0/24 are used for demonstrative purposes, to
global IPv4 addresses which have no relation to each other. This represent global IPv4 addresses that have no relation to each other.
approach was chosen instead of just using addresses from 192.0.2.0/24 This approach was chosen instead of just using addresses from
[5] for two reasons: to use addresses whose 6to4 mapping is 192.0.2.0/24 [5] for two reasons: to use addresses whose 6to4 mapping
blindingly obvious, and to make it obvious that the IPv4 addresses of is glaringly obvious, and to make it obvious that the IPv4 addresses
different 6to4 gateways do not have to have any relation to each of different 6to4 gateways need not have any relation to each other.
other.
2. Different 6to4 Forwarding Scenarios 2. Different 6to4 Forwarding Scenarios
It should be noted that when communicating between 6to4 and native Note that when one communicates between 6to4 and native domains, the
domains, the 6to4 relays that will be used in the two directions are 6to4 relays that will be used in the two directions are very likely
very likely different; routing is highly asymmetric. Because of different; routing is highly asymmetric. Because of this, it is not
this, it is not feasible to limit relays from which 6to4 routers may feasible to limit relays from which 6to4 routers may accept traffic.
accept traffic.
The first three subsections introduce the most common forms of 6to4 The first three subsections introduce the most common forms of 6to4
operation. Other models are presented in the fourth subsection. operation. Other models are presented in the fourth subsection.
2.1 From 6to4 to 6to4 2.1. From 6to4 to 6to4
6to4 domains always exchange 6to4 traffic directly via IPv4 6to4 domains always exchange 6to4 traffic directly via IPv4
tunneling; the endpoint address V4ADDR is derived from 6to4 prefix tunneling; the endpoint address V4ADDR is derived from 6to4 prefix
2002:V4ADDR::/48 of the destination. 2002:V4ADDR::/48 of the destination.
.--------. _----_ .--------. .--------. _----_ .--------.
| 6to4 | _( IPv4 )_ | 6to4 | | 6to4 | _( IPv4 )_ | 6to4 |
| router | <====> ( Internet ) <===> | router | | router | <====> ( Internet ) <===> | router |
'--------' (_ _) '--------' '--------' (_ _) '--------'
^ '----' ^ ^ '----' ^
| Direct tunneling over IPv4 | | Direct tunneling over IPv4 |
V V V V
.--------. .-------. .--------. .-------.
| 6to4 | | 6to4 | | 6to4 | | 6to4 |
| host | | host | | host | | host |
'--------' '--------' '--------' '--------'
Figure 1 Figure 1
It is required that every 6to4 router considers every other 6to4 It is required that every 6to4 router consider every other 6to4
router it wants to talk to to be "on-link" (with IPv4 as the router it wants to talk to be "on-link" (with IPv4 as the
link-layer). link-layer).
2.2 From Native to 6to4 2.2. From Native to 6to4
When native domains send traffic to 6to4 prefix 2002:V4ADDR::/48, it When native domains send traffic to 6to4 prefix 2002:V4ADDR::/48, it
will be routed to the topologically nearest, advertising (advertising will be routed to the topologically nearest advertising 6to4 relay
route to 2002::/16) 6to4 relay. The 6to4 relay will tunnel the (advertising route to 2002::/16). The 6to4 relay will tunnel the
traffic over IPv4 to the corresponding IPv4 address V4ADDR. 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 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 IPv4 address, and it is assigned to the 6to4 router's
pseudo-interface. pseudo-interface.
Closest to Closest to
"Native IPv6 node" "Native IPv6 node"
.--------. _----_ .------------. .--------. .--------. _----_ .------------. .--------.
| Native | _( IPv6 )_ | 6to4 relay | Tunneled | 6to4 | | Native | _( IPv6 )_ | 6to4 relay | Tunneled | 6to4 |
skipping to change at page 6, line 31 skipping to change at page 5, line 31
| node | (_ _) '------------' 9.0.0.1 '--------' | node | (_ _) '------------' 9.0.0.1 '--------'
'--------' '----' dst_v6=2002:0900:0001::1 | '--------' '----' dst_v6=2002:0900:0001::1 |
V V
.-------. .-------.
| 6to4 | | 6to4 |
| host | | host |
'--------' '--------'
Figure 2 Figure 2
2.3 From 6to4 to Native 2.3. From 6to4 to Native
6to4 domains send traffic to native domains by tunneling it over IPv4 6to4 domains send traffic to native domains by tunneling it over IPv4
to their configured 6to4 relay router, or the closest one found using to their configured 6to4 relay router, or the closest one found by
6to4 IPv4 Anycast [3]. The relay will decapsulate the packet and using 6to4 IPv4 Anycast [3]. The relay will decapsulate the packet
forward it to native IPv6 Internet, the same way as any other IPv6 and forward it to native IPv6 Internet, as would any other IPv6
packet. packet.
Note that destination IPv6 address in the packet is a non-6to4 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. address and is assumed to be 2001:db8::1 in the example.
Configured Configured
-or- -or-
found by IPv4 Anycast found by IPv4 Anycast
.--------. _----_ .------------. .--------. .--------. _----_ .------------. .--------.
| Native | _( IPv6 )_ | 6to4 relay | Tunneled | 6to4 | | Native | _( IPv6 )_ | 6to4 relay | Tunneled | 6to4 |
| Client | <- ( Internet ) <-- | router | <========= | router | | Client | <- ( Internet ) <-- | router | <========= | router |
'--------' (_ _) '------------' 192.88.99.1'--------' '--------' (_ _) '------------' 192.88.99.1'--------'
2001:db8::1 '----' (or configured) ^ 2001:db8::1 '----' (or configured) ^
| |
.-------. .-------.
| 6to4 | | 6to4 |
| client | | client |
'--------' '--------'
Figure 3 Figure 3
2.4 Other Models 2.4. Other Models
These are more or less special cases of 6to4 operations. In later These are more or less special cases of 6to4 operations. In later
chapters, unless otherwise stated, only the most generally-used chapters, unless otherwise stated, only the most generally used
models (above) will be considered. models (above) will be considered.
2.4.1 BGP Between 6to4 Routers and Relays 2.4.1. BGP between 6to4 Routers and Relays
Section 5.2.2.2 in [1] presents a model where, instead of static 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 configuration, BGP [6] is used between 6to4 relay routers and 6to4
routers (for outgoing relay selection only). routers (for outgoing relay selection only).
Going further than [1], if the 6to4 router established a BGP session Going further than [1], if the 6to4 router established a BGP session
between all the possible 6to4 relays, and advertised its /48 prefix between all the possible 6to4 relays and advertised its /48 prefix to
to them, the traffic from non-6to4 sites would always come from a them, the traffic from non-6to4 sites would always come from a
"known" relay. Alternatively, the 6to4 relays might advertise the "known" relay. Alternatively, the 6to4 relays might advertise the
more specific 6to4 routes between 6to4 relays. more specific 6to4 routes between 6to4 relays.
Both of these approaches are more or less obviously infeasible due to Both of these approaches are obviously infeasible due to scalability
scalability issues. issues.
Neither of these models are known to be used at the time of writing; Neither of these models are known to be used at the time of writing;
this is probably caused by the fact that parties that need 6to4 are this is probably because parties that need 6to4 are not able to run
those that are not able to run BGP, and because setting up these BGP, and because setting up these sessions would be much more work
sessions would be much more work for relay operators. for relay operators.
2.4.2 6to4 as an Optimization Method 2.4.2. 6to4 as an Optimization Method
Some sites seem to use 6to4 as an IPv6 connectivity "optimization Some sites seem to use 6to4 as an IPv6 connectivity "optimization
method"; that is, they have also non-6to4 addresses on their nodes method"; that is, they also have non-6to4 addresses on their nodes
and border routers, but also employ 6to4 to reach 6to4 sites. and border routers but also employ 6to4 to reach 6to4 sites.
This is typically done to be able to reach 6to4 destinations by This is typically done to be able to reach 6to4 destinations by
direct tunneling and not having to use relays at all. direct tunneling without using relays at all.
These sites also publish both 6to4 and non-6to4 addresses in DNS to These sites also publish both 6to4 and non-6to4 addresses in DNS to
affect inbound connections; if the source host's default address affect inbound connections. If the source host's default address
selection [7] works properly, 6to4 sources will use 6to4 addresses to selection [7] works properly, 6to4 sources will use 6to4 addresses to
reach the site and non-6to4 nodes use non-6to4 addresses. If this reach the site and non-6to4 nodes use non-6to4 addresses. If this
behavior of foreign nodes can be assumed, the security threats to behavior of foreign nodes can be assumed, the security threats to
such sites can be significantly simplified. such sites can be significantly simplified.
2.4.3 6to4 as Tunnel End-Point Addressing Mechanism 2.4.3. 6to4 as Tunnel End-Point Addressing Mechanism
6to4 addresses can also be used only as an IPv6-in-IPv4 tunnel 6to4 addresses can also be used only as an IPv6-in-IPv4 tunnel
endpoint addressing and routing mechanism. endpoint addressing and routing mechanism.
An example of this is interconnecting 10 branch offices where nodes An example of this is interconnecting 10 branch offices where nodes
use non-6to4 addresses. Only the offices' border routers need to be use non-6to4 addresses. Only the offices' border routers need to be
aware of 6to4, and use 6to4 addresses solely for addressing the aware of 6to4, and use 6to4 addresses solely for addressing the
tunnels between different branch offices. An example is provided in tunnels between different branch offices. An example is provided in
the figure below. the figure below.
skipping to change at page 9, line 15 skipping to change at page 9, line 4
(_ _) (_ _)
'----' '----'
Figure 4 Figure 4
In the figure, the main office sets up two routes: In the figure, the main office sets up two routes:
2001:db8:0:10::/60 -> 2002:0900:0001::1 2001:db8:0:10::/60 -> 2002:0900:0001::1
2001:db8:0:20::/60 -> 2002:0800:0002::1 2001:db8:0:20::/60 -> 2002:0800:0002::1
And a branch office sets up two routes as well: And a branch office sets up two routes as well:
2001:db8:0:20::/60 -> 2002:0800:0002::1 2001:db8:0:20::/60 -> 2002:0800:0002::1
default -> 2002:0700:0003::1 default -> 2002:0700:0003::1
Thus, the IPv4 Internet is treated as NBMA link-layer for Thus, the IPv4 Internet is treated as an NBMA link-layer for
interconnecting 6to4-enabled sites; with explicit routes, 6to4 interconnecting 6to4-enabled sites; with explicit routes, 6to4
addressing need not be used in other than the 6to4 edge routers. addressing need not be used in routers other than the 6to4 edge
However, note that if a branch office sends a packet to any 6to4 routers. However, note that if a branch office sends a packet to any
destination, it will not go through the main office as the 6to4 6to4 destination, it will not go through the main office, as the 6to4
2002::/16 route overrides the default route. 2002::/16 route overrides the default route.
This approach may make addressing and routing slightly easier in some This approach may make addressing and routing slightly easier in some
circumstances. circumstances.
3. Functionalities of 6to4 Network Components 3. Functionalities of 6to4 Network Components
This section summarizes the main functionalities of the 6to4 network This section summarizes the main functionalities of the 6to4 network
components (6to4 routers, and 6to4 relays), and the security checks components (6to4 routers, and 6to4 relays) and the security checks
that must be done by them. The pseudo-code for the security checks they must do. The pseudo-code for the security checks is provided in
is provided in Section 5. Section 5.
This section summarizes the main functions of the various components This section summarizes the main functions of the various components
that are part of a 6to4 network - 6to4 relay routers, and 6to4 of a 6to4 network: 6to4 relay routers and 6to4 routers. Refer to
routers. Refer to Section 1.1 of RFC 3056 [1] for 6to4 related Section 1.1 of RFC 3056 [1] for 6to4-related definitions.
definitions.
3.1 6to4 Routers 3.1. 6to4 Routers
The 6to4 routers acts as the border router of a 6to4 domain. It does 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 not have a native global IPv6 address except in certain special
cases. Since the specification [1] uses the term "6to4 router", this cases. Since the specification [1] uses the term "6to4 router", this
memo does the same; however, note that we also include a single host memo does the same; however, note that in this definition, we also
with a 6to4 pseudo-interface, which doesn't otherwise act as a include a single host with a 6to4 pseudo-interface, which doesn't
router, in this definition. The main functions of the 6to4 router otherwise act as a router. The main functions of the 6to4 router are
are: as follows:
o Provide IPv6 connectivity to local clients and routers. o Provide IPv6 connectivity to local clients and routers.
o Tunnel packets sent to foreign 6to4 addresses to the destination o Tunnel packets sent to foreign 6to4 addresses to the destination
6to4 router using IPv4. 6to4 router using IPv4.
o Forward packets sent to locally configured 6to4 addresses to the o Forward packets sent to locally configured 6to4 addresses to the
6to4 network. 6to4 network.
o Tunnel packets sent to non-6to4 addresses, to the configured/ o Tunnel packets sent to non-6to4 addresses to the configured/
closest-by-anycast 6to4 relay router. closest-by-anycast 6to4 relay router.
o Decapsulate directly received IPv4 packets from foreign 6to4 o Decapsulate directly received IPv4 packets from foreign 6to4
addresses. addresses.
o Decapsulate IPv4 packets received via the relay closest to the o Decapsulate IPv4 packets received via the relay closest to the
native IPv6 sources. Note, it is not easily distinguishable that native IPv6 sources. Note that it is not easily distinguishable
the packet was really received from a 6to4 relay router, not from whether the packet was received from a 6to4 relay router or from a
a spoofing third party. spoofing third party.
The 6to4 router should also perform security checks on traffic that The 6to4 router should also perform security checks on traffic that
it will receive from other 6to4 relays, or 6to4 routers, or from it receives from other 6to4 relays, or 6to4 routers, or from within
within the 6to4 site. These checks include: the 6to4 site. These checks include the following:
o Disallow traffic that has private, broadcast or certain specific o Disallow traffic that has private, broadcast or certain specific
reserved IPv4 addresses (see Section 5.3.1 for details) in reserved IPv4 addresses (see Section 5.3.1 for details) in
tunnels, or the matching 6to4 prefixes. tunnels, or the matching 6to4 prefixes.
o Disallow traffic from 6to4 routers where the IPv4 tunnel source o Disallow traffic from 6to4 routers in which the IPv4 tunnel source
address does not match the 6to4 prefix. (Note that the address does not match the 6to4 prefix. (Note that the
pseudo-interface must pick the IPv4 address corresponding to the pseudo-interface must pick the IPv4 address corresponding to the
prefix when encapsulating, or else problems may ensue on e.g., prefix when encapsulating, or problems may ensue, e.g., on
multi-interface routers.) multi-interface routers.)
o Disallow traffic where the destination IPv6 address is not a o Disallow traffic in which the destination IPv6 address is not a
global address; in particular, e.g. link-local addresses, mapped global address; in particular, link-local addresses, mapped
addresses and such should not be used. addresses, and such should not be used.
o Disallow traffic transmission to other 6to4 domains through 6to4 o Disallow traffic transmission to other 6to4 domains through 6to4
relay router or via some third party 6to4 router. (To avoid relay router or via some third party 6to4 router. (To avoid
transmission to the relay router, the pseudo-interface prefix transmission to the relay router, the pseudo-interface prefix
length must be configured correctly to be /16. Further, to avoid length must be configured correctly to /16. Further, to avoid the
the traffic being discarded, 6to4 source addresses must always traffic being discarded, 6to4 source addresses must always
correspond to the IPv4 address encapsulating the traffic.) correspond to the IPv4 address encapsulating the traffic.)
o Discard traffic received from other 6to4 domains via a 6to4 relay o Discard traffic received from other 6to4 domains via a 6to4 relay
router. router.
o Discard traffic received for prefixes other than your own 6to4 o Discard traffic received for prefixes other than one's own 6to4
prefix(es). prefix(es).
3.2 6to4 Relay Routers 3.2. 6to4 Relay Routers
The 6to4 relay router acts as a relay between all 6to4 domains and The 6to4 relay router acts as a relay between all 6to4 domains and
native IPv6 networks; more specifically: native IPv6 networks; more specifically, it
o It advertises the reachability of the 2002::/16 prefix to native
IPv6 routing, thus receiving traffic to all 6to4 addresses from
closest native IPv6 nodes.
o Advertise (if RFC 3068 [3] is implemented) the reachability of o advertises the reachability of the 2002::/16 prefix to native IPv6
routing, thus receiving traffic to all 6to4 addresses from the
closest native IPv6 nodes,
o advertises (if RFC 3068 [3] is implemented) the reachability of
IPv4 "6to4 relay anycast prefix" (192.88.99.0/24) to IPv4 routing, IPv4 "6to4 relay anycast prefix" (192.88.99.0/24) to IPv4 routing,
thus receiving some tunneled traffic to native IPv6 nodes from thus receiving some tunneled traffic to native IPv6 nodes from
6to4 routers. 6to4 routers.
o Decapsulate, and forward packets received from 6to4 addresses o decapsulates and forwards packets received from 6to4 addresses
through tunneling, using normal IPv6 routing. through tunneling, by using normal IPv6 routing, and
o Tunnels packets received through normal IPv6 routing from native o tunnels packets received through normal IPv6 routing from native
addresses, and are destined for 2002::/16, to the corresponding addresses that are destined for 2002::/16 to the corresponding
6to4 router. 6to4 router.
The 6to4 relay should also perform security checks on traffic that it The 6to4 relay should also perform security checks on traffic that it
will receive from 6to4 routers, or from native IPv6 nodes. These receives from 6to4 routers, or from native IPv6 nodes. These checks
checks are: are as follows:
o Disallow traffic that has private, broadcast or certain specific o Disallow traffic that has private, broadcast, or certain specific
reserved IPv4 addresses in tunnels, or the matching 6to4 prefixes. reserved IPv4 addresses in tunnels, or in the matching 6to4
prefixes.
o Disallow traffic from 6to4 routers where the IPv4 tunnel source o Disallow traffic from 6to4 routers in which the IPv4 tunnel source
address does not match the 6to4 prefix. (Note that the address does not match the 6to4 prefix. (Note that the
pseudo-interface must pick the IPv4 address corresponding to the pseudo-interface must pick the IPv4 address corresponding to the
prefix when encapsulating, or else problems may ensue on e.g., prefix when encapsulating, or problems may ensue, e.g., on
multi-interface routers.) multi-interface routers.)
o Disallow traffic where the destination IPv6 address is not a o Disallow traffic in which the destination IPv6 address is not a
global address; in particular, e.g. link-local addresses, mapped global address; in particular, link-local addresses, mapped
addresses and such should not be used. addresses, and such should not be used.
o Discard traffic received from 6to4 routers with the destination as o Discard traffic received from 6to4 routers with the destination as
a 6to4 prefix. a 6to4 prefix.
4. Threat Analysis 4. Threat Analysis
This section discusses attacks against the 6to4 network or attacks This section discusses attacks against the 6to4 network or attacks
that are caused by the 6to4 network. The threats are discussed in caused by the 6to4 network. The threats are discussed in light of
light of the 6to4 deployment models defined in Section 2. the 6to4 deployment models defined in Section 2.
There are three general types of threats: There are three general types of threats:
1. Denial-of-Service (DoS) attacks, in which a malicious node 1. Denial-of-Service (DoS) attacks, in which a malicious node
prevents communication between the node under attack and other prevents communication between the node under attack and other
nodes. nodes.
2. Reflection Denial-of-Service (DoS) attacks, in which a malicious 2. Reflection Denial-of-Service (DoS) attacks, in which a malicious
node reflects the traffic off unsuspecting nodes to a particular node reflects the traffic off unsuspecting nodes to a particular
node (node under attack) with the intent of preventing node (node under attack) in order to prevent communication
communication between the node under attack and other nodes. between the node under attack and other nodes.
3. Service theft, in which a malicious node/site/operator may make 3. Service theft, in which a malicious node/site/operator may make
unauthorized use of service. unauthorized use of service.
6to4 also provides a means for a "meta-threat", traffic laundering, 6to4 also provides a means for a "meta-threat", traffic laundering,
in which some other attack is channeled through the third parties to in which some other attack is channeled through the third parties to
make it more difficult to trace the real origin of the attack. This make tracing the real origin of the attack more difficult. This is
is used in conjunction with other threats, whether specific to 6to4 used in conjunction with other threats, whether specific to 6to4 or
or not. not.
At this point it is important to reiterate that the attacks are At this point it is important to reiterate that the attacks are
possible because: possible because
1. 6to4 routers have to consider all 6to4 relays, and other 6to4 1. 6to4 routers have to consider all 6to4 relays, and other 6to4
routers as "on-link". routers, as "on-link",
2. 6to4 relays have to consider all 6to4 routers as "on-link". 2. 6to4 relays have to consider all 6to4 routers as "on-link", and
3. Partial implementation of the security checks in the 6to4 3. it has been discovered that at least a couple of major 6to4
implementation. It has been discovered that at least a couple of implementations do not implement all the security checks.
major implementations do not implement all the checks.
The attacks descriptions are classified based on the target of the The attacks' descriptions are classified based on the target of the
attack: attack:
1. Attacks on 6to4 networks. 1. Attacks on 6to4 networks.
2. Attacks on IPv6 networks. 2. Attacks on IPv6 networks.
3. Attacks on IPv4 networks. 3. Attacks on IPv4 networks.
Note, one of the mitigation methods listed for various attacks is Note that one of the mitigation methods listed for various attacks is
based on the premise that 6to4 relays could have a feature that may based on the premise that 6to4 relays could have a feature limiting
be able to limit traffic to/from specific 6to4 sites. At the time of traffic to/from specific 6to4 sites. At the time of this writing,
writing this document, such a feature is speculation, and more work this feature is speculative, and more work needs to be done to
needs to be done to determine the logistics of such a feature. determine the logistics.
4.1 Attacks on 6to4 Networks 4.1. Attacks on 6to4 Networks
This section describes attacks against 6to4 networks. Attacks which This section describes attacks against 6to4 networks. Attacks that
leverage 6to4 networks, but where the ultimate victim is elsewhere leverage 6to4 networks, but for which the ultimate victim is
(e.g., a native IPv6 user, an IPv4 user) are described later in the elsewhere (e.g., a native IPv6 user, an IPv4 user), are described
memo. later in the memo.
6to4 relays and routers are IPv4 nodes, and there is no way for any 6to4 relays and routers are IPv4 nodes, and there is no way for any
6to4 router to confirm the identity of the IPv4 node from which it is 6to4 router to confirm the identity of the IPv4 node from which it
receiving traffic -- whether it is a legitimate 6to4 relay or some receives traffic -- whether from a legitimate 6to4 relay or some
other node. A 6to4 router has to process traffic from all IPv4 other node. A 6to4 router has to process traffic from all IPv4
nodes. Malicious IPv4 nodes can exploit this property and attack nodes. Malicious IPv4 nodes can exploit this property and attack
nodes within the 6to4 network. nodes within the 6to4 network.
It is possible to conduct a variety of attacks on the 6to4 nodes. It is possible to conduct a variety of attacks on the 6to4 nodes.
These attacks are: These attacks are as follows:
1. Attacks with Neighbor Discovery (ND) Messages 1. Attacks with Neighbor Discovery (ND) Messages
2. Spoofing traffic to 6to4 nodes 2. Spoofing traffic to 6to4 nodes
3. Reflecting traffic from 6to4 nodes 3. Reflecting traffic from 6to4 nodes
4. Local IPv4 broadcast attack 4. Local IPv4 broadcast attack
4.1.1 Attacks with ND Messages 4.1.1. Attacks with ND Messages
ATTACK DESCRIPTION ATTACK DESCRIPTION
Since the 6to4 router assumes all the other 6to4 routers, and 6to4 Since the 6to4 router assumes that all the other 6to4 routers and
relays are "on-link" it is possible to attack the 6to4 router using 6to4 relays are "on-link", it is possible to attack the 6to4 router
ND messages from any node in the IPv4 network, unless a prior trust by using ND messages from any node in the IPv4 network, unless a
relationship has been established. prior trust relationship has been established.
The attacks are targeting the 6to4 pseudo-interface. As long as the The attacks target the 6to4 pseudo-interface. As long as the 6to4
6to4 addresses are not used in the source or destination address, the addresses are not used in the source or destination address, the
security checks specified by 6to4 take no stance on these packets. security checks specified by 6to4 take no stance on these packets.
Typically these use link-local addresses. Typically they use link-local addresses.
For example, a possible attack could be a Route Advertisement or For example, an attack could be a Route Advertisement or Neighbor
Neighor Advertisement message, crafted specifically to cause havoc; Advertisement message crafted specifically to cause havoc; the
the addresses in such a packet could be like: addresses in such a packet could resemble to the following:
src_v6 = fe80::2 (forged address) src_v6 = fe80::2 (forged address)
dst_v6 = fe80::1 (valid or invalid address) dst_v6 = fe80::1 (valid or invalid address)
src_v4 = 8.0.0.1 (valid or forged address) src_v4 = 8.0.0.1 (valid or forged address)
dst_v4 = 9.0.0.2 (valid address, matches dst_v6) dst_v4 = 9.0.0.2 (valid address, matches dst_v6)
These attacks are exacerbated in case the implementation supports These attacks are exacerbated if the implementation supports more
more tunneling mechanisms than just 6to4 (or configured tunneling), tunneling mechanisms than 6to4 (or configured tunneling) because it
because it is impossible to disambiguate such mechanisms, making it is impossible to disambiguate such mechanisms, making it difficult to
difficult to enable strict security checks (see Section 6.1). enable strict security checks (see Section 6.1).
The Neighbor Discovery threats (Redirect DoS, or DoS) are described The Neighbor Discovery threats (Redirect DoS, or DoS) are described
in [8]. Note that all attacks may not be applicable, as the 6to4 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 pseudo-interface is assumed not to have a link-layer address (Section
3.8 RFC 2893 [4]). However, one should note that the 6to4 router can 3.8 RFC 2893 [4]). However, note that the 6to4 router can be either
be either a router or host from the Neighbor Discovery perspective. a router or host from the Neighbor Discovery perspective.
THREAT ANALYSIS AND MITIGATION METHODS THREAT ANALYSIS AND MITIGATION METHODS
The attacks can be mitigated by using any of the following methods: The attacks can be mitigated by using any of the following methods:
o The usage of ND messages could be prohibited. It implies that all o The usage of ND messages could be prohibited. This implies that
packets using addresses of scope link-local will be silently all packets using addresses of scope link-local will be silently
discarded. Section 3.1 of RFC 3056 [1] leaves scope for future discarded. Section 3.1 of RFC 3056 [1] leaves scope for future
uses of link-local address. This method has its pitfalls - it uses of link-local address. This method has its pitfalls: It
would prohibit any sort of ND message, and thus close the doors on would prohibit any sort of ND message and thus close the doors on
development, and use of other ND options. Whether this is a development and use of other ND options. Whether this is a
significant problem is another thing. significant problem is another thing.
o The 6to4 pseudo-interface could be insulated from the other o The 6to4 pseudo-interface could be insulated from the other
interfaces, particularly the other tunnel interfaces (if any), for interfaces, particularly the other tunnel interfaces (if any), for
example using a separate neighbor cache. example by using a separate neighbor cache.
o If ND messages are needed, either IPsec [4] or an extension of o If ND messages are needed, either IPsec [4] or an extension of
SEND could be used [9] to secure packet exchange using link-local SEND could be used [9] to secure packet exchange using the
address; vanilla SEND would not work as the link-layer does not link-local address; vanilla SEND would not work, as the link-layer
have an address -- and IPsec would be rather complex. does not have an address -- and IPsec would be rather complex.
COMPARISON TO SITUATION WITHOUT 6to4 COMPARISON TO SITUATION WITHOUT 6to4
Even though rather simply fixable, this attack is not new as such; Even though rather simply fixed, this attack is not new as such; the
the same is possible using automatic tunneling [4] or configured same is possible by using automatic tunneling [4] or configured
tunneling (if one is able to spoof source IPv4 address to that of the tunneling (if one is able to spoof source IPv4 address to that of the
tunnel end-point). tunnel end-point).
However, as 6to4 provides open decapsulation, and automatic tunneling However, as 6to4 provides open decapsulation, and automatic tunneling
is being deprecated [10], 6to4 provides an easy means which would not is being deprecated [10], 6to4 provides an easy means, which would
exist without 6to4. not exist without it.
4.1.2 Spoofing Traffic to 6to4 Nodes 4.1.2. Spoofing Traffic to 6to4 Nodes
ATTACK DESCRIPTION ATTACK DESCRIPTION
The attacker - a malicious IPv4 or IPv6 node - can send packets which 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 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 relay) to a 6to4 node. This can be used e.g., to accomplish a DoS
attack. attack.
The IPv6 and IPv4 addresses of the packets will be similar to: The IPv6 and IPv4 addresses of the packets will be similar to the
following:
src_v6 = 2001:db8::1 (forged address) src_v6 = 2001:db8::1 (forged address)
dst_v6 = 2002:0900:0002::1 (valid address) dst_v6 = 2002:0900:0002::1 (valid address)
src_v4 = 8.0.0.1 (valid or forged address) src_v4 = 8.0.0.1 (valid or forged address)
dst_v4 = 9.0.0.2 (valid address, matches dst_v6) 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 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 address of the relay through which the traffic will reach the 6to4
node. From IPv4 nodes, src_v4 can be either a spoofed or the real node. From IPv4 nodes, src_v4 can be either a spoofed source address
source address. or the real one.
The 6to4 router receives these packets from 8.0.0.1, decapsulates 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 them, discards the IPv4 header containing the source address 8.0.0.1,
and processes them as normal (the attacker has guessed or obtained and processes them as normal (the attacker has guessed or obtained
"dst_v6" using one of a number of techniques). "dst_v6" by using one of a number of techniques).
This is a DoS attack on 6to4 nodes. This is a DoS attack on 6to4 nodes.
This attack is similar to ones shown in [11]. This attack is similar to those shown in [11].
EXTENSIONS EXTENSIONS
Replies to the traffic will be directed to the src_v6 address, Replies to the traffic will be directed to the src_v6 address,
resulting in 6to4 nodes in participating in a reflection DoS. This resulting in 6to4 nodes participating in a reflection DoS. This
attack is described in more detail in Section 4.2.3. That is, the attack is described in more detail in Section 4.2.3. The replies
replies (e.g., TCP SYN ACK, TCP RST, ICMPv6 Echo Reply, input sent to (e.g., TCP SYN ACK, TCP RST, ICMPv6 Echo Reply, input sent to UDP
UDP echo service, ICMPv6 Destination Unreachable, etc.) are sent to echo service, ICMPv6 Destination Unreachable) are sent to the victim
the victim (src_v6), above. All the traces from the original (src_v6), above. All the traces from the original attacker (src_v4)
attacker (src_v4) have been discarded. These return packets will go have been discarded. These return packets will go through a relay.
through a relay.
Certain 6to4 networks may have a trivial ACL (Access Control List) Certain 6to4 networks may have a trivial ACL (Access Control List)
based firewall that allows traffic to pass through if it comes from based firewall that allows traffic to pass through if it comes from
particular source(s). Such a firewalling mechanism can be bypassed particular source(s). Such a firewalling mechanism can be bypassed
by address spoofing. This attack can therefore be used for trivial by address spoofing. This attack can therefore be used for trivial
ACL avoidance as well. These attacks might be hampered by the fact ACL avoidance as well. These attacks might be hampered because the
that the replies from the 6to4 node to the spoofed address will be replies from the 6to4 node to the spoofed address will be lost.
lost.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
The Denial-of-Service attack based on traffic spoofing is not new; 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 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 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 those who are unable to do so in their current networks. The 6to4
router typically does not log IPv4 addresses (as they would be router typically does not log IPv4 addresses (as they would be
treated as L2 addresses) and thus the source of the attack (if treated as L2 addresses), and thus the source of the attack (if
launched from an IPv4 node) is lost. Since traces to the src_v4 launched from an IPv4 node) is lost. Because traces to the src_v4
address can easily be lost, these attacks can also be be launched address are easily lost, these attacks can also be launched from IPv4
from IPv4 nodes whose connection is ingress-filtered. nodes whose connections are ingress-filtered.
However, often this is not a real factor, as usually the attackers However, often this is not a real factor, as usually the attackers
are just zombies and real attackers may not even care if the are just zombies and real attackers may not even care whether the
unspoofed source address is discovered. unspoofed source address is discovered.
Malicious native IPv6 nodes could be caught easily if ingress Malicious native IPv6 nodes could be caught easily if ingress
filtering was enabled everywhere in the IPv6 Internet. filtering was enabled everywhere in the IPv6 Internet.
These attacks are easy to perform, but the extent of harm is limited: These attacks are easy to perform, but the extent of harm is limited:
o For every packet sent, at most one reply packet is generated: o For every packet sent, at most one reply packet is generated:
there is no amplification factor. there is no amplification factor.
o Attack packets, if initiated from an IPv6 node, will pass through o Attack packets, if initiated from an IPv6 node, will pass through
choke point(s), namely a 6to4 relay; in addition to physical choke point(s), namely a 6to4 relay; in addition to physical
limitations, these could implement some form of 6to4-site-specific limitations, these could implement some form of 6to4-site-specific
traffic limiting. traffic limiting.
On the other hand, a variety of factors can make the attack serious: On the other hand, a variety of factors can make the attacks serious:
o The attacker may have the ability to choose the relay, and he o The attacker may have the ability to choose the relay, and he
might employ the ones best suited for the attacks. Also, many might employ the ones best suited for the attacks. Also, many
relays use 192.88.99.1 [3] as the source address making tracing relays use 192.88.99.1 [3] as the source address, making tracing
even more difficult (also see Section 4.2.6). even more difficult (also see Section 4.2.6).
o The relay's IPv4 address may be used as a source address for these o The relay's IPv4 address may be used as a source address for these
attacks, potentially causing a lot of complaints or other actions attacks, potentially causing a lot of complaints or other actions,
as the relay might seem to be the source of the attack (see as the relay might seem to be the source of the attack (see
Section 4.2.6 for more). Section 4.2.6 for more).
Some of the mitigation methods for such attacks are: Some of the mitigation methods for such attacks are as follows:
1. Ingress filtering in the native IPv6 networks to prevent packets 1. Ingress filtering in the native IPv6 networks to prevent packets
with spoofed IPv6 source being transmitted. It would, thus, make with spoofed IPv6 sources from being transmitted. This would,
it easy to identify the source of the attack. Unfortunately, thus, make it easy to identify the source of the attack.
this would depend on significant (or even complete) ingress Unfortunately, it would depend on significant (or even complete)
filtering everywhere in other networks; while this is highly ingress filtering everywhere in other networks; while this is
desirable, it may also be practically unfeasible. highly desirable, it may not be feasible.
2. Security checks in the 6to4 relay. The 6to4 relay must drop 2. Security checks in the 6to4 relay. The 6to4 relay must drop
traffic (from the IPv6 Internet) that has 6to4 addresses as traffic (from the IPv6 Internet) that has 6to4 addresses as
source address, see Section 5 for more. This has very little source address; see Section 5 for more detail. This has very
cost. little cost.
However, these mitigation methods do not address the case of IPv4 However, these mitigation methods do not address the case of an IPv4
node sending encapsulated IPv6 packets. node sending encapsulated IPv6 packets.
There exists no simple way to prevent such attacks, and longer term No simple way to prevent such attacks exists, and longer-term
solutions like ingress filtering [12] or itrace [13] would have to be solutions, such as ingress filtering [12] or itrace [13], would have
deployed in both IPv6 and IPv4 networks to help identify the source to be deployed in both IPv6 and IPv4 networks to help identify the
of the attacks. A total penetration is likely impossible to achieve. source of the attacks. A total penetration is likely impossible.
(Note that itrace work has been discontinued, as of this writing in (Note that itrace work has been discontinued, as of this writing in
July 2004.) July 2004.)
COMPARISON TO SITUATION WITHOUT 6to4 COMPARISON TO SITUATION WITHOUT 6to4
Traffic spoofing is not a new phenomenon in IPv4 or IPv6. 6to4 just Traffic spoofing is not a new phenomenon in IPv4 or IPv6. 6to4 just
makes it easier: anyone can, regardless of ingress filtering, spoof a makes it easier: Anyone can, regardless of ingress filtering, spoof a
native IPv6 address to a 6to4 node, even if "maximal security" would native IPv6 address to a 6to4 node, even if "maximal security" would
be implemented and deployed. Losing trails is also easier. be implemented and deployed. Losing trails is also easier.
Therefore, depending on how much one assumes ingress filtering is Therefore, depending on how much one assumes ingress filtering is
deployed for IPv4 and IPv6, this could be considered to be a very deployed for IPv4 and IPv6, this could be considered either a very
serious issue, or close to irrelevant compared to the IP spoofing serious issue or close to irrelevant compared to the IP spoofing
capabilities without 6to4. capabilities without 6to4.
4.1.3 Reflecting Traffic to 6to4 Nodes 4.1.3. Reflecting Traffic to 6to4 Nodes
ATTACK DESCRIPTION ATTACK DESCRIPTION
Spoofed traffic (as described in Section 4.2.2) may be sent to native Spoofed traffic (as described in Section 4.2.2) may be sent to native
IPv6 nodes with the aim of performing a reflection attack against IPv6 nodes to perform a reflection attack against 6to4 nodes.
6to4 nodes.
The spoofed traffic is sent to a native IPv6 node, either from an The spoofed traffic is sent to a native IPv6 node, either from an
IPv4 node (through a 6to4 relay), or from a native IPv6 node (unless IPv4 node (through a 6to4 relay) or from a native IPv6 node (unless
ingress filtering has been deployed). With the former, the sent ingress filtering has been deployed). With the former, the sent
packets would look like: packets would resemble the following:
src_v6 = 2002:1234:1234::1 (forged address of the target 6to4 node) src_v6 = 2002:1234:1234::1 (forged address of the target 6to4 node)
dst_v6 = 2002:0900:0002::1 (valid address) dst_v6 = 2002:0900:0002::1 (valid address)
src_v4 = 8.0.0.1 (valid or invalid address) src_v4 = 8.0.0.1 (valid or invalid address)
dst_v4 = 9.0.0.2 (valid address, matches dst_v6) dst_v4 = 9.0.0.2 (valid address, matches dst_v6)
One should note that an attack through the relay is prevented if the Note that an attack through the relay is prevented if the relay
relay implements proper decapsulation security checks (see Section 5 implements proper decapsulation security checks (see Section 5 for
for details) unless the IPv4 node can spoof the source address to details) unless the IPv4 node can spoof the source address to match
match src_v6. Similarly, the attack from native IPv6 nodes could be src_v6. Similarly, the attack from native IPv6 nodes could be
prevented by global ingress filtering deployment. prevented by global ingress filtering deployment.
These attacks can be initiated by native IPv6, IPv4, or 6to4 nodes. These attacks can be initiated by native IPv6, IPv4, or 6to4 nodes.
EXTENSIONS EXTENSIONS
A distributed Reflection DoS can be performed if a large number nodes A distributed Reflection DoS can be performed if a large number of
are involved in sending spoofed traffic with the same src_v6. nodes are involved in sending spoofed traffic with the same src_v6.
Malicious 6to4 nodes can also (try to) initiate this attack by Malicious 6to4 nodes can also (try to) initiate this attack by
bouncing traffic off 6to4 nodes in other 6to4 sites. However this bouncing traffic off 6to4 nodes in other 6to4 sites. However, this
attack may not be possible as the 6to4 router (in the site from which attack may not be possible, as the 6to4 router (in the site from
the attack is being launched) will filter packets with forged source which the attack is launched) will filter packets with forged source
address (with security checks mentioned in Section 5), and thus the addresses (with security checks mentioned in Section 5).
attack will be prevented.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
The reverse traffic in this case are replies to the messages received In this case, the reverse traffic comprises replies to the messages
by the 6to4 nodes. The attacker has less control on the packet type received by the 6to4 nodes. The attacker has less control on the
in this case, and this would inhibit certain types of attacks. For packet type, and this would inhibit certain types of attacks. For
example, flooding a 6to4 node with TCP SYN packets will not be example, flooding a 6to4 node with TCP SYN packets will not be
possible (but e.g., a SYN-ACK or RST would be). possible (but e.g., a SYN-ACK or RST would be).
These attacks may be mitigated in various ways: These attacks may be mitigated in various ways:
o Implementation of ingress filtering by the IPv4 service providers. o Implementation of ingress filtering by the IPv4 service providers.
It would prevent forging of the src_v4 address, and would help in This would prevent forging of the src_v4 address and help in
closing down on the culprit IPv4 nodes. Note that, it will be closing down on the culprit IPv4 nodes. Note that it will be
difficult to shut down the attack if a large number of IPv4 nodes difficult to shut down the attack if a large number of IPv4 nodes
are involved. are involved.
These attacks may be also be stopped at the 6to4 sites if the These attacks may be also be stopped at the 6to4 sites if the
culprit src_v4 address is identified, and if it is constant, by culprit src_v4 address is identified, and if it is constant, by
filtering traffic from this address. Note that it would be filtering traffic from this address. Note that it would be
difficult to implement this method, if appropriate logging is not difficult to implement this method if appropriate logging were not
done by the 6to4 router, or if a large number of 6to4 nodes, and/ done by the 6to4 router or if a large number of 6to4 nodes, and/or
or a large number of IPv4 nodes are participating in the attack. a large number of IPv4 nodes were participating in the attack.
Unfortunately, as many IPv4 service providers don't implement Unfortunately, because many IPv4 service providers don't implement
ingress filtering, for whatever reasons, this may not be a ingress filtering, for whatever reasons, this may not be a
satisfactory resolution. satisfactory solution.
o Implementation of ingress filtering by all IPv6 service providers o Implementation of ingress filtering by all IPv6 service providers
would eliminate this attack, because src_v6 could not be spoofed would eliminate this attack, because src_v6 could not be spoofed
to be a 6to4 address. However, expecting this to happen may not as a 6to4 address. However, expecting this to happen may not be
be practical. practical.
o Proper implementation of security checks (see Section 5) both at o Proper implementation of security checks (see Section 5) both at
the 6to4 relays and routers would eliminate the attack, when the 6to4 relays and routers would eliminate an attack launched
launched from an IPv4 node, except when the IPv4 source address from an IPv4 node, except when the IPv4 source address was also
was also spoofed -- but then the attacker would have been able to spoofed -- but then the attacker would have been able to attack
just attack the ultimate destination directly. the ultimate destination directly.
o Rate limiting traffic at the 6to4 relays. In a scenario where o Rate limiting traffic at the 6to4 relays. In a scenario where
most of the traffic is passing through few 6to4 relays, these most of the traffic is passing through few 6to4 relays, these
relays can implement traffic rate-limiting features, and relays can implement traffic rate-limiting features and rate-limit
rate-limit the traffic from 6to4 sites. the traffic from 6to4 sites.
COMPARISON TO SITUATION WITHOUT 6to4 COMPARISON TO SITUATION WITHOUT 6to4
This particular attack can be mitigated by proper implementation of This particular attack can be mitigated by proper implementation of
security checks (which is quite straightforward) and ingress security checks (which is quite straightforward) and ingress
filtering; where ingress filtering is not implemented, it's typically filtering; when ingress filtering is not implemented, it is typically
easier to attack directly than through reflection -- unless "traffic easier to attack directly than through reflection -- unless "traffic
laundering" is an explicit goal in the attack. Therefore, this laundering" is an explicit goal of the attack. Therefore, this
attack does not seem very serious. attack does not seem very serious.
4.1.4 Local IPv4 Broadcast Attack 4.1.4. Local IPv4 Broadcast Attack
ATTACK DESCRIPTION ATTACK DESCRIPTION
This threat is applicable if the 6to4 router does not check whether This threat is applicable if the 6to4 router does not check whether
the IPv4 address it tries to send encapsulated IPv6 packets to a the IPv4 address to which it tries to send encapsulated IPv6 packets
local broadcast address, or a multicast address. is a local broadcast address or a multicast address.
This threat is described in the specification [1], and implementing This threat is described in the specification [1], and implementing
the checks eliminates this threat. However, as this has not been the checks eliminates this threat. However, as checks have not been
widely implemented, it is included here regardless for completeness. widely implemented, the threat is included here for completeness.
There practically two kinds of attacks: where a local 6to4 user tries There practically two kinds of attacks: when a local 6to4 user tries
to send packets to the address corresponding to the broadcast to send packets to the address corresponding to the broadcast
address, or when someone is able to do that remotely. address, and when someone is able to do so remotely.
In the first option, assume that 9.0.0.255 is the 6to4 router's In the first option, assume that 9.0.0.255 is the 6to4 router's
broadcast address. After receiving the packet with a destionation broadcast address. After receiving the packet with a destination
address like "2002:0900:00ff::bbbb" from a local 6to4 node, if the address like "2002:0900:00ff::bbbb" from a local 6to4 node, if the
router doesn't check the destination address for subnet broadcast, it router doesn't check the destination address for subnet broadcast, it
would send the encapsulated protocol-41 packet to 9.0.0.255. This would send the encapsulated protocol-41 packet to 9.0.0.255. This
would be received by all nodes in the subnet, and the responses would would be received by all nodes in the subnet, and the responses would
be directed to the 6to4 router. be directed to the 6to4 router.
Malicious sites may also embed forged 6to4 addresses in the DNS, use Malicious sites may also embed forged 6to4 addresses in the DNS, use
of which by a 6to4 node will result in a local broadcast by the 6to4 of which by a 6to4 node would result in a local broadcast by the 6to4
router. One way to perform this attack would be to send an HTML mail router. One way to perform this attack would be to send an HTML mail
containing a link to an invalid URL (for example, http:// containing a link to an invalid URL (for example,
[2002:0900:00ff::bbbb]/index.html) to all users in a 6to4 technology http://[2002:0900:00ff::bbbb]/index.html) to all users in a 6to4
based network. Opening of the mail simultaneously would result in a technology based network. Opening of the mail simultaneously would
broadcast storm. result in a broadcast storm.
The second kind of attack is more complex: the attack can be The second kind of attack is more complex: The attack can be
initiated by IPv4 nodes not belonging to the local network as long as initiated by IPv4 nodes not belonging to the local network as long as
they can send traffic with invalid (for example 2002:0900:00ff::bbbb) they can send traffic with invalid (for example 2002:0900:00ff::bbbb)
source address. The 6to4 router has to respond to the traffic by source address. The 6to4 router has to respond to the traffic by
sending ICMPv6 packets back to the source, for example Hop Limit sending ICMPv6 packets back to the source, (e.g., Hop Limit Exceeded
Exceeded or Destination Unreachable. The packet would be as follows: or Destination Unreachable). The packet would be as follows:
src_v6 = 2002:0800:00ff::bbbb (broadcast address of the router) src_v6 = 2002:0800:00ff::bbbb (broadcast address of the router)
dst_v6 = 2002:0800:0001::0001 (valid non-existent address) dst_v6 = 2002:0800:0001::0001 (valid non-existent address)
This is a DoS attack. This is a DoS attack.
EXTENSIONS EXTENSIONS
The attacks could also be directed at non-local broadcast addresses, The attacks could also be directed at non-local broadcast addresses,
but these would be so-called "IPv4 directed broadcasts", which have but these would be so-called "IPv4 directed broadcasts", which have
been (luckily enough) already been extensively blocked in the (luckily enough) already been extensively blocked in the Internet.
Internet.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
The attack is based on the premise that the 6to4 router has to send a The attack is based on the premise that the 6to4 router has to send a
packet to an IPv6 address that embeds an invalid IPv4 address. Such packet that embeds an invalid IPv4 address to an IPv6 address. Such
an attack is easily thwarted by ensuring that the 6to4 router does an attack is easily thwarted by ensuring that the 6to4 router does
not transmit packets to invalid IPv4 addresses. Specifically traffic not transmit packets to invalid IPv4 addresses. Specifically,
should not be sent to broadcast or multicast IPv4 addresses. traffic should not be sent to broadcast or multicast IPv4 addresses.
COMPARISON TO SITUATION WITHOUT 6to4 COMPARISON TO SITUATION WITHOUT 6to4
The first threat is similar to what's already possible with IPv4, but The first threat is similar to what is already possible with IPv4,
IPv6 does not have broadcast addresses. but IPv6 does not have broadcast addresses.
The second, a more complex threat, is similarly also available in The second, a more complex threat, is, similarly, also available in
IPv4. IPv4.
In consequence, the security does not seem to be significantly worse In consequence, the security does not seem to be significantly worse
than with IPv4, and even that is restricted to the site(s) with 6to4 than with IPv4, and even that is restricted to the site(s) with 6to4
implementations which haven't been secured as described in Section 5. implementations that haven't been secured as described in Section 5.
4.2 Attacks on Native IPv6 Internet 4.2. Attacks on Native IPv6 Internet
This section describes attacks against native IPv6 Internet which This section describes attacks against native IPv6 Internet that
leverage 6to4 architecture somehow. Attacks against 6to4 nodes were somehow leverage 6to4 architecture. Attacks against 6to4 nodes were
described in the previous section. described in the previous section.
Native IPv6 nodes can be accessed by 6to4 and IPv4 nodes through the 6to4 and IPv4 nodes can access native IPv6 nodes through the 6to4
6to4 relay routers. Thus the 6to4 relays play a crucial role in any relay routers. Thus, the 6to4 relays play a crucial role in any
attack on native IPv6 nodes by IPv4 nodes or 6to4 nodes. attack on native IPv6 nodes by IPv4 nodes or 6to4 nodes.
6to4 relays have only one significant security check they must 6to4 relays have only one significant security check they must
perform for general safety: when decapsulating IPv4 packets, check perform for general safety: When decapsulating IPv4 packets, they
that 2002:V4ADDR::/48 and V4ADDR match in the source address. If check that 2002:V4ADDR::/48 and V4ADDR match in the source address.
this is not done, several threats become more serious; in the If this is not done, several threats become more serious; in the
following analysis, it is assumed that such checks are implemented. following analysis, it is assumed that such checks are implemented.
6to4 relay should not relay packets between 6to4 addresses. In 6to4 relay should not relay packets between 6to4 addresses. In
particular, packets decapsulated from 6to4 routers should not be particular, packets decapsulated from 6to4 routers should not be
encapsulated again towards 6to4 routers, as described in rules in encapsulated toward 6to4 routers, as described in Section 5.
Section 5. Similarly, packets with 6to4 source and destination Similarly, packets with 6to4 source and destination addresses sent
address sent from IPv6 nodes should not be relayed. It is not clear from IPv6 nodes should not be relayed. It is not clear whether this
whether this kind of check is typically implemented. The attacks kind of check is typically implemented. The attacks described below
described below assume that such checks are not implemented. assume that such checks are not implemented.
4.2.1 Attacks with ND Messages 4.2.1. Attacks with ND Messages
These attacks are the same as employed against 6to4 routers as These attacks are the same as those employed against 6to4 routers, as
described in Section 4.1.1. described in Section 4.1.1.
4.2.2 Spoofing Traffic to Native IPv6 node 4.2.2. Spoofing Traffic to Native IPv6 Node
ATTACK DESCRIPTION ATTACK DESCRIPTION
The attacker - a malicious IPv4 or 6to4 node - can send packets with The attacker - a malicious IPv4 or 6to4 node - can send packets with
spoofed (or not spoofed) 6to4 source address to a native IPv6 node to a spoofed (or not spoofed) 6to4 source address to a native IPv6 node
accomplish a DoS attack. to accomplish a DoS attack.
The threat is similar as the one involving 6to4 routers as described The threat is similar to that involving 6to4 routers, as described in
in Section 4.1.2. Section 4.1.2.
The difference here is that the attack is initiated by IPv4 nodes, or The difference here is that the attack is initiated by IPv4 or 6to4
6to4 nodes. The source IPv6 address may or may not be spoofed. nodes. The source IPv6 address may or may not be spoofed. Note
Note, as mentioned above, the relay is assumed to correlate source that, as mentioned above, the relay is assumed to correlate the
IPv4 address with the address embedded in the source IPv6 address source IPv4 address with the address embedded in the source IPv6
during decapsulation. A side effect is that all the spoofed traffic address during decapsulation. A side effect is that all spoofed
will have a 6to4 source address. traffic will have a 6to4 source address.
EXTENSIONS EXTENSIONS
Spoofed traffic may also be sent to native IPv6 nodes by either other
native IPv6 nodes, or 6to4 nodes, or malicious IPv4 nodes to conduct Spoofed traffic may also be sent to native IPv6 nodes either by other
Reflection DoS on either native IPv6 nodes or 6to4 nodes. native IPv6 nodes, by 6to4 nodes, or by malicious IPv4 nodes to
conduct Reflection DoS on either native IPv6 nodes or 6to4 nodes.
Certain native IPv6 networks may have a trivial ACL (Access Control Certain native IPv6 networks may have a trivial ACL (Access Control
List) based firewall that allows traffic to pass through if it comes List) based firewall that allows traffic to pass through if it comes
from particular source(s). Such a firewalling mechanism can be from particular source(s). Such a firewalling mechanism can be
bypassed by address spoofing. This attack can therefore be used for bypassed by address spoofing. This attack can therefore be used for
trivial ACL avoidance as well. These attacks might be hampered by trivial ACL avoidance as well. These attacks might be hampered by
the fact that the replies from the 6to4 node to the spoofed address lost replies from the 6to4 node to the spoofed address.
will be lost.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
The Denial-of-Service attack based on traffic spoofing is not new; The Denial-of-Service attack based on traffic spoofing is not new;
the only twist comes from the fact that traces of an attack are more the only twist is that traces of an attack are more easily lost. The
easily lost. The 6to4 relay typically does not log IPv4 addresses 6to4 relay typically does not log IPv4 addresses (as they would be
(as they would be treated as L2 addresses) and thus the source of the treated as L2 addresses), and thus the source of the attack (if
attack (if launched from an IPv4 node) is lost. Since traces to the launched from an IPv4 node) is lost. Because traces to the src_v4
src_v4 address can easily be lost, these attacks can also be be address are easily lost, these attacks can also be launched from IPv4
launched from IPv4 nodes whose connection is ingress-filtered. nodes whose connections are ingress-filtered.
These attacks might be not be very easy to perform, and might be These attacks might not be easy to perform and might be hampered
hampered because of: because of the following:
o It might be difficult to launch such attacks from 6to4 nodes o It might be difficult to launch such attacks from 6to4 nodes
because even if the 6to4 routers allow spoofing of the source IPv6 because even if the 6to4 routers allow spoofing of the source IPv6
address, the 6to4 relay would check if source V4ADDR is same as address, the 6to4 relay would check whether the source V4ADDR is
the one embedded in the source IPv6 address. Thus, 6to4 nodes the same as the one embedded in the source IPv6 address. Thus,
will be forced to use the correct IPv6 prefix while lauching 6to4 nodes will be forced to use the correct IPv6 prefix while
attack, and it is easy to close such attacks. launching an attack, making it easy to close such attacks.
o Packets may pass through choke point(s), namely a 6to4 relay. In o Packets may pass through choke point(s), namely a 6to4 relay. In
addition to physical limitations, there could be some sort of addition to physical limitations, there could be some sort of
traffic rate limiting mechanisms which may be implemented, and it traffic rate limiting mechanisms that may be implemented, and
could tone down the attack. these could tone down the attack.
o For every packet sent, at most one reply packet is generated: o For every packet sent, at most one reply packet is generated:
there is no amplification factor. There is no amplification factor.
Some of the mitigation methods for such attacks are: Some of the mitigation methods for such attacks are as follows:
1. Ingress filtering in the IPv4 Internet to prevent packets with 1. Ingress filtering in the IPv4 Internet to prevent packets with a
spoofed IPv4 source being transmitted. As the relay checks that spoofed IPv4 source from being transmitted. As the relay checks
the 6to4 address embeds the IPv4 address, no spoofing can be that the 6to4 address embeds the IPv4 address, no spoofing can be
achieved done unless IPv4 addresses can be spoofed. However, achieved unless IPv4 addresses can be spoofed. However, this
this would probably be an unfeasible requirement. would probably be an unfeasible requirement.
2. Security checks in the 6to4 relay. The 6to4 relay must drop 2. Security checks in the 6to4 relay. The 6to4 relay must drop
traffic (from 6to4 nodes, or IPv4 nodes) that has non-6to4 traffic (from 6to4 nodes, or IPv4 nodes) with non-6to4 addresses
addresses as source address, or where the source IPv4 address as the source address, or for which the source IPv4 address does
does not match the address embebdded in the source IPv6 address. not match the address embedded in the source IPv6 address.
COMPARISON TO SITUATION WITHOUT 6to4 COMPARISON TO SITUATION WITHOUT 6to4
Compared to Section 4.1.2, which is more serious, this threat appears Compared to Section 4.1.2, which describes more serious threats, this
to be slightly more manageable. If the relays perform proper threat appears to be slightly more manageable. If the relays perform
decapsulation checks, the spoofing can only be achived, to a 6to4 proper decapsulation checks, the spoofing can only be achieved, to a
source address, when IPv4 address is spoofable as well. 6to4 source address, when the IPv4 address is spoofable as well.
4.2.3 Reflecting Traffic to Native IPv6 nodes 4.2.3. Reflecting Traffic to Native IPv6 Nodes
ATTACK DESCRIPTION ATTACK DESCRIPTION
These reflection attacks are similar to the one involving 6to4 These reflection attacks are similar to that involving 6to4 routers,
routers as described in Section 4.1.3. Traffic may be reflected off as described in Section 4.1.3. Traffic may be reflected off native
native IPv6 nodes, or 6to4 nodes. The attack can be initiated by IPv6 nodes, or off 6to4 nodes. The attack can be initiated by one of
either: the following:
o Native IPv6 nodes. These nodes can send invalid traffic with o Native IPv6 nodes. These nodes can send invalid traffic with
spoofed native IPv6 addresses to valid 6to4 nodes. Replies from spoofed native IPv6 addresses to valid 6to4 nodes. Replies from
the 6to4 nodes are part of a reflection attack. the 6to4 nodes are part of a reflection attack.
o IPv4 nodes. These nodes can send traffic with native IPv6 source o IPv4 nodes. These nodes can send traffic with native IPv6 source
addresses (encapsulated by the IPv4 node itself into a protocol-41 addresses (encapsulated by the IPv4 node itself into a protocol-41
packet) to 6to4 nodes. Replies from the 6to4 nodes are part of a packet) to 6to4 nodes. Replies from the 6to4 nodes are part of a
reflection attack. reflection attack.
o 6to4 nodes. These nodes can perform similar attacks to the ones o 6to4 nodes. These nodes can perform attacks similar to those by
by IPv4 nodes, but that would require spoofing of the source IPv4 nodes, but this would require spoofing of the source address
address at the 6to4 site before encapsulation; that is likely to at the 6to4 site before encapsulation, which is likely to be
be difficult. difficult.
When launched from a native IPv6 node, the traffic goes through 6to4 When launched from a native IPv6 node, the traffic goes through 6to4
relays twice, both after and before the reflection; when launched relays twice, both before and after the reflection; when launched
from a 6to4/IPv4 node, the traffic goes through a relay only after from a 6to4/IPv4 node, the traffic goes through a relay only after
the reflection. the reflection.
EXTENSIONS EXTENSIONS
A distributed Reflection DoS can be performed if a large number of A distributed reflection DoS can be performed if a large number of
native IPv6 nodes or IPv4/6to4 nodes are involved in sending spoofed native IPv6 nodes or IPv4/6to4 nodes are involved in sending spoofed
traffic with the same source IPv6 address. traffic with the same source IPv6 address.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
Some of the mitigation methods for such attacks are:
Some of the mitigation methods for such attacks are as follows:
1. Attacks from the native IPv6 nodes could be stopped by 1. Attacks from the native IPv6 nodes could be stopped by
implementing ingress filtering in the IPv6 Internet; hopefully implementing ingress filtering in the IPv6 Internet; hopefully
this will become commonplace, but past experience of IPv4 ingress this will become commonplace, but past experience of IPv4 ingress
filtering deployment (or lack thereof) does not promise much. filtering deployment (or lack thereof) does not promise much.
2. Two measures are needed to stop or mitigate the attacks from IPv4 2. Two measures are needed to stop or mitigate the attacks from IPv4
nodes: 1) Implementing ingress filtering in the IPv4 internet, nodes: 1) Implementing ingress filtering in the IPv4 internet,
and 2) logging IPv4 source address in the 6to4 router. and 2) logging IPv4 source addresses in the 6to4 router.
3. Attacks from 6to4 nodes in other sites can be stopped if the 6to4 3. Attacks from 6to4 nodes in other sites can be stopped if the 6to4
router in those sites implements egress filtering. This could be routers in those sites implement egress filtering. This could be
done by those sites, but the sites who are most likely to be done by those sites, but the sites that are most likely to be
abused are typically also most likely to be neglecting to abused are typically also those most likely to neglect installing
installing appropriate filtering at their edges. appropriate filtering at their edges.
4. The traffic passes through one or two relays, and traffic rate 4. The traffic passes through one or two relays, and traffic rate
limiting in the 6to4 relays might help tone down the reflection limiting in the 6to4 relays might help tone down the reflection
attack. attack.
COMPARISON TO SITUATION WITHOUT 6to4 COMPARISON TO SITUATION WITHOUT 6to4
Even thought there are means to mitigate the attack, it is still Even though there are means to mitigate it, the attack is still
rather efficient, especially when used by native IPv6 nodes with rather efficient, especially when used by native IPv6 nodes with
spoofed addresses. Using 6to4 relays and routers could easily take spoofed addresses. Using 6to4 relays and routers could easily take
down the 6to4 relay system and/or provide an easy means for traffic down the 6to4 relay system and/or provide an easy means for traffic
laundering. However, if the intent of the attack is just to DoS the laundering. However, if the attack is intended to DoS the victim,
victim, it can be achieved more smoothly by doing it directly (as the this can be achieved more smoothly by doing it directly (as the
source address spoofing was available as well). source address spoofing was available as well).
Therefore, the threat seems to be higher to the availability and Therefore, the threat to the availability and stability of the 6to4
stability of the 6to4 relay system itself than to native IPv6 relay system itself seems to be higher than to the native IPv6
Internet. Internet.
4.2.4 Local IPv4 Broadcast Attack 4.2.4. Local IPv4 Broadcast Attack
This attack is similar to the ones employed against 6to4 routers as This attack is similar to the ones employed against 6to4 routers, as
described in Section 4.1.4. There are slight differences with regard described in Section 4.1.4. There are slight differences with regard
to the source of the attacks. This attack can be initiated by: 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 o native IPv6 nodes that may send traffic to the relay's subnet
broadcast address. broadcast address, and
o IPv4 nodes that may send traffic with spoofed source IP address 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., (to be the relay's broadcast address) to elicit replies (e.g.,
ICMPv6 Hop Limit Exceeded messages) from the 6to4 relay to its ICMPv6 Hop Limit Exceeded) from the 6to4 relay to its local nodes.
local nodes.
The first is more dangerous than in Section 4.1.4 because it can be The first approach is more dangerous than those in Section 4.1.4
initiated by any IPv6 node (which is allowed to use the relay, that because it can be initiated by any IPv6 node (allowed to use the
is), not limited to local users. relay); the approach is not limited to local users.
The second is trickier and not really useful. For it to succeed, the The second approach is trickier and not really useful. For it to
relay would have to accept native source addresses over the 6to4 succeed, the relay would have to accept native source addresses over
pseudo-interface (but we did not assume this check was implemented), the 6to4 pseudo-interface (we did not assume this check was
as if coming from another relay, and trigger an ICMPv6 message to the implemented), as if coming from another relay, triggering an ICMPv6
relay's local IPv4 subnet. The former method is more lucrative. message to the relay's local IPv4 subnet. The former method is more
lucrative.
EXTENSIONS EXTENSIONS
None. None.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
The threat is restricted to the relay's local subnet, and is fixed by The threat is restricted to the relay's local subnet and is fixed by
tightening the 6to4 security checks. tightening the 6to4 security checks.
COMPARISON TO SITUATION WITHOUT 6to4 COMPARISON TO SITUATION WITHOUT 6to4
This scenario is caused by 6to4, but fortunately, the issue is not This scenario is caused by 6to4, but fortunately the issue is not
serious. serious.
4.2.5 Theft of Service 4.2.5. Theft of Service
ATTACK DESCRIPTION ATTACK DESCRIPTION
The 6to4 relay administrators would often want to use some policy to 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 limit the use of the relay to specific 6to4 sites and/or specific
IPv6 sites. IPv6 sites.
The policy control is usually done by applying restrictions to where The policy control is usually enacted by applying restrictions to
the routing information for 2002::/16 and/or 192.188.99.0/24 (if the where the routing information for 2002::/16 and/or 192.188.99.0/24
anycast address used [3]) will spread. (if the anycast address used [3]) will spread.
Some users may be able to use the service regardless of these Some users may be able to use the service regardless of these
controls, by: controls, by
o Configuring the address of the relay using its IPv4 address o configuring the address of the relay using its IPv4 address
instead of 192.88.99.1, or instead of 192.88.99.1, or
o Using the Routing header to route IPv6 packets to reach specific o using the routing header to route IPv6 packets to reach specific
6to4 relays. (Some other routing tricks like using static routes 6to4 relays. (Other routing tricks, such as using static routes,
may also be used.) may also be used.)
EXTENSIONS EXTENSIONS
None. None.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
Attempts to use the relay's IPv4 address instead of 192.88.99.1 can Attempts to use the relay's IPv4 address instead of 192.88.99.1 can
be mitigated in the following ways: be mitigated in the following ways:
1. IPv4 domains should prevent usage of the actual IPv4 address of 1. IPv4 domains should prevent use of the actual IPv4 address of the
the relay instead of 192.88.99.1. relay instead of 192.88.99.1.
2. Usage of access lists in the 6to4 relay to limit access. This is 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 only feasible if the number of IP networks the relay is supposed
to serve is relatively low. to serve is relatively low.
3. The 6to4 relay should filter out arriving tunneled packets with 3. The 6to4 relay should filter out arriving tunneled packets with
protocol 41 (IPv6) which do not have the the 192.88.99.1 as the protocol 41 (IPv6) that do not have 192.88.99.1 as the
destination address. destination address.
The other threat of using routing tricks in the IPv6 networks to The other threat, of using routing tricks in the IPv6 networks to
reach the 6to4 relay has similar solutions: reach the 6to4 relay, has similar solutions:
1. Usage of access lists in the relay to limit access. 1. Usage of access lists in the relay to limit access.
2. Filtering out the packets with a routing header (may have other 2. Filtering out the packets with a routing header (although this
implications). may have other implications).
3. Monitoring the source addresses going through the relay, to 3. Monitoring the source addresses going through the relay to
detect e.g. peers setting up static routes. detect, e.g., peers setting up static routes.
Routing Header is not specific to 6to4, the main things one could do Routing Header is not specific to 6to4. The main thing one could do
here with it would be to select the relay; some generic threats about with it here would be to select the relay. Some generic threats
Routing Header use are described in [11]. about routing header use are described in [11].
As this threat does not have implications on other than the As this threat does not have implications for anything other than the
organization providing 6to4 relay, it is not analyzed any further. organization providing 6to4 relay, it is not analyzed any further.
COMPARISON TO SITUATION WITHOUT 6to4 COMPARISON TO SITUATION WITHOUT 6to4
These threats are specific to 6to4 relays (or in general, anycast These threats are specific to 6to4 relays (or in general anycast
services), and do not exist in networks without 6to4. services) and do not exist in networks without 6to4.
4.2.6 Relay Operators Seen as Source of Abuse 4.2.6. Relay Operators Seen as Source of Abuse
ATTACK DESCRIPTION ATTACK DESCRIPTION
There are several attacks which use 6to4 relays to anonymize the Several attacks use 6to4 relays to anonymize the traffic; this often
traffic; this often results in packets being tunneled from the relay results in packets being tunneled from the relay to a supposedly-6to4
to a supposedly-6to4 site. site.
However, as was already pointed out in Section 4.2, the IPv4 source However, as was pointed out in Section 4.2, the IPv4 source address
address used by the relay could, cursorily looking, be seen as the used by the relay could, on a cursory look, be seen as the source of
source of these "protocol-41" attacks. these "protocol-41" attacks.
This could cause a number of concerns for the operators deploying This could cause a number of concerns for the operators deploying
6to4 relay service. For example: 6to4 relay service, including the following:
o Getting contacted a lot (via email, phone, fax, or lawyers) on o being contacted a lot (via email, phone, fax, or lawyers) on
suspected "abuse", suspected "abuse",
o having the whole IPv4 address range rejected as a source of abuse
o Getting the whole IPv4 address range rejected as a source of abuse
or spam, causing outage to other operations as well, or or spam, causing outage to other operations as well, or
o Causing the whole IPv4 address range to be to be blacklisted in o causing the whole IPv4 address range to be blacklisted in some
some "spammer databases", if the relay would be used for those "spammer databases", if the relay were used for those purposes.
purposes.
This threat seems slightly similar (but more generic) to the outburst This threat seems slightly similar to the outburst of SMTP abuse
of SMTP abuse caused by open relays. caused by open relays but is more generic.
EXTENSIONS EXTENSIONS
None. None.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
This problem can be avoided (or really, "made someone else's 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 problem") by using the 6to4 anycast address in 192.88.99.0/24 as the
source address: blacklisting or rejecting that should not cause source address. Blacklisting or rejecting this should not cause
problems to the other operations. problems to the other operations.
Further, when someone is filing complaints to the owner of Further, when someone files complaints to the owner of
192.88.99.0/24, depending on which registry they are querying, they 192.88.99.0/24, depending on which registry they are querying, they
might get, for example: might get, for example:
o Knowledge that this is a special IANA address block, with no real o knowledge that this is a special IANA address block, with no real
contact person, 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, or
o Knowledge that this is a special address block for RFC 3068, and o knowledge that this is a special address block for RFC 3068, and
that there are multiple entries in the database by relay that there are multiple entries by relay operators in the
operators. database.
Any of these, at least when processed by a human, should make one Any of these, at least when processed by a human, should show that
learn that the 6to4 relay is in fact innocent. Of course, this could the 6to4 relay is in fact innocent. Of course, this could result in
result in these reports going to the closest anycast 6to4 relay as reports going to the closest anycast 6to4 relay as well, which had
well, which in fact had nothing to do with the incident. nothing to do with the incident.
However, the wide-spread usage of 192.88.99.1 as the source address 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 may make it more difficult to disambiguate the relays, which might be
a useful feature for debugging purposes. a useful feature for debugging purposes.
COMPARISON TO SITUATION WITHOUT 6to4 COMPARISON TO SITUATION WITHOUT 6to4
This threat is caused by 6to4 deployment, but can be avoided, at This threat is caused by 6to4 deployment but can be avoided, at least
least in the short-term, by using the use of 192.88.99.1 as the in the short-term, by using 192.88.99.1 as the source address.
source address.
4.3 Attacks on IPv4 Internet 4.3. Attacks on IPv4 Internet
There are two types of attacks on the IPv4 internet - spoofed There are two types of attacks on the IPv4 internet - spoofed
traffic, and reflection. They can be initiated by native IPv6 nodes, traffic, and reflection. These can be initiated by native IPv6
6to4 nodes, and IPv4 nodes. nodes, 6to4 nodes, and IPv4 nodes.
Attacks initiated by IPv4 nodes that send spoofed traffic that will Attacks initiated by IPv4 nodes that send spoofed traffic, which
not utilize the 6to4 infrastructure are considered out of scope of would not use the 6to4 infrastructure, are considered out of the
this document. 6to4 infrastructure may be utilized in reflection scope of this document. 6to4 infrastructure may be used in
attacks that are initiated by IPv4 nodes. reflection attacks initiated by IPv4 nodes.
It is difficult for these attacks to be effective as the traffic sent It is difficult for these attacks to be effective, as the traffic
out will be IPv6-in-IPv4. Such traffic will be rejected by most IPv4 sent out will be IPv6-in-IPv4. Such traffic will be rejected by most
nodes unless they have implemented some sort of IPv6-in-IPv4 IPv4 nodes unless they have implemented some sort of IPv6-in-IPv4
tunneling. tunneling.
4.4 Summary of the Attacks 4.4. Summary of the Attacks
Columns: Columns:
o Section number. The section that describes the attack. o Section number. The section that describes the attack.
o Attack name. o Attack name.
o Initiator. The node that initiates the attack. o Initiator. The node that initiates the attack.
* I_4 - IPv4 node * I_4 - IPv4 node
skipping to change at page 30, line 26 skipping to change at page 30, line 26
+-------+----------------------+---------+----------+-----+-----+ +-------+----------------------+---------+----------+-----+-----+
| 4.2.5 | Theft of Service | 6to4 | Relay | T | 6 | | 4.2.5 | Theft of Service | 6to4 | Relay | T | 6 |
+-------+----------------------+---------+----------+-----+-----+ +-------+----------------------+---------+----------+-----+-----+
| 4.2.6 | Relay Operators ... | - | - | D | 1) | | 4.2.6 | Relay Operators ... | - | - | D | 1) |
+-------+----------------------+---------+----------+-----+-----+ +-------+----------------------+---------+----------+-----+-----+
Figure 10 Figure 10
Notes: Notes:
1) This attack is a side-effect of the other attacks, and thus does 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 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 attack not on the network but on the organization in-charge of the
relay. relay.
Summary of attacks on IPv4 internet: Summary of attacks on IPv4 internet:
+-------+----------------------+---------+----------+-----+-----+ +-------+----------------------+---------+----------+-----+-----+
| Sec | Attack name |Initiator| Victim | ToA | Fix | | Sec | Attack name |Initiator| Victim | ToA | Fix |
+-------+----------------------+---------+----------+-----+-----+ +-------+----------------------+---------+----------+-----+-----+
| 4.3 | Spoofing Traffic | * | I_4 | D | 6* | | 4.3 | Spoofing Traffic | * | I_4 | D | 6* |
+-------+----------------------+---------+----------+-----+-----+ +-------+----------------------+---------+----------+-----+-----+
| 4.3 | Reflection Attacks | * | I_4 | R | 6* | | 4.3 | Reflection Attacks | * | I_4 | R | 6* |
+-------+----------------------+---------+----------+-----+-----+ +-------+----------------------+---------+----------+-----+-----+
Figure 11 Figure 11
5. Implementing Proper Security Checks in 6to4 5. Implementing Proper Security Checks in 6to4
In this section, several ways to implement the security checks This section describes several ways to implement the security checks
required or implied by the specification [1] or augmented by this required or implied by the specification [1] or augmented by this
memo are described. These do not, in general, protect against the memo. These do not, in general, protect against most of the threats
majority of the threats listed above in the "Threat Analysis" listed above in the "Threat Analysis" section. They are only
section. They're just prerequisites for a relatively safe and simple prerequisites for a relatively safe and simple 6to4 implementation.
6to4 implementation.
Note that in in general, the 6to4 router or relay does not know Note that, in general, the 6to4 router or relay does not know whether
whether it is acting as a router or relay. It would be possible to it is acting as a router or relay. It would be possible to include a
include a toggle to specify the behaviour, to be used e.g., when the toggle to specify the behaviour, to be used when, e.g., the interface
interface is brought up, but at least in February 2004, no is brought up, but as of February 2004, no implementations were known
implementations were known to do that. Due to that, the checks are to do that. Therefore, the checks are described as that which works
described as one -- which works independent of whether the node is a independently of whether the node is a router or relay.
router or relay.
5.1 Encapsulating IPv6 into IPv4 5.1. Encapsulating IPv6 into IPv4
The checks described in this section are to be performed when The checks described in this section are to be performed when
encapsulating IPv6 into IPv4. encapsulating IPv6 into IPv4.
The encapsulation rules are mainly designed to keep one from The encapsulation rules are mainly designed to keep implementors from
"shooting yourself on the foot" -- for example, the source address "shooting themselves in the foot." For example, the source address
check verifies that the packet will be acceptable to the check would verify that the packet will be acceptable to the
decapsulator, or the sanity checks ensure that addresses derived from decapsulator, or the sanity checks would ensure that addresses
private addresses are not used (which would be equally unacceptable). 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 src_v6 and dst_v6 MUST pass ipv6-sanity checks (see below) else drop
if prefix (src_v6) == 2002::/16 if prefix (src_v6) == 2002::/16
ipv4 address embedded in src_v6 MUST match src_v4 ipv4 address embedded in src_v6 MUST match src_v4
else if prefix (dst_v6) == 2002::/16 else if prefix (dst_v6) == 2002::/16
dst_v4 SHOULD NOT be assigned to the router dst_v4 SHOULD NOT be assigned to the router
else else
drop drop
/* we somehow got a native-native ipv6 packet */ /* we somehow got a native-native ipv6 packet */
fi fi
accept accept
5.2 Decapsulating IPv4 into IPv6 5.2. Decapsulating IPv4 into IPv6
The checks described in this section are to be performed when The checks described in this section are to be performed when
decapsulating IPv4 into IPv6. They will be performed in both the decapsulating IPv4 into IPv6. They will be performed in both the
6to4 router and relay. 6to4 router and relay.
src_v4 and dst_v4 MUST pass ipv4-sanity checks, else drop src_v4 and dst_v4 MUST pass ipv4-sanity checks, else drop
src_v6 and dst_v6 MUST pass ipv6-sanity checks, else drop src_v6 and dst_v6 MUST pass ipv6-sanity checks, else drop
if prefix (dst_v6) == 2002::/16 if prefix (dst_v6) == 2002::/16
ipv4 address embedded in dst_v6 MUST match dst_v4 ipv4 address embedded in dst_v6 MUST match dst_v4
if prefix (src_v6) == 2002::/16 if prefix (src_v6) == 2002::/16
skipping to change at page 32, line 22 skipping to change at page 32, line 10
fi fi
elif prefix (src_v6) == 2002::/16 elif prefix (src_v6) == 2002::/16
ipv4 address embedded in src_v6 MUST match src_v4 ipv4 address embedded in src_v6 MUST match src_v4
dst_v4 SHOULD be assigned to the router (see notes below) dst_v4 SHOULD be assigned to the router (see notes below)
else else
drop drop
/* the we somehow got a native-native ipv6 packet */ /* the we somehow got a native-native ipv6 packet */
fi fi
accept accept
5.3 IPv4 and IPv6 Sanity Checks 5.3. IPv4 and IPv6 Sanity Checks
The encapsulation and decapsulation checks included certain sanity The encapsulation and decapsulation checks include certain sanity
checks for both IPv4 and IPv6. These are described here in detail. checks for both IPv4 and IPv6. These are described here in detail.
5.3.1 IPv4 5.3.1. IPv4
IPv4 address MUST be a global unicast address, as required by the IPv4 address MUST be a global unicast address, as required by the
6to4 specification. The disallowed addresses include those defined 6to4 specification. The disallowed addresses include those defined
in [14], and others widely used and known not to be global. These in [14], and others widely used and known not to be global. These
are: are
o 0.0.0.0/8 (the system has no address assigned yet) o 0.0.0.0/8 (the system has no address assigned yet)
o 10.0.0.0/8 (private) o 10.0.0.0/8 (private)
o 127.0.0.0/8 (loopback) o 127.0.0.0/8 (loopback)
o 172.16.0.0/12 (private) o 172.16.0.0/12 (private)
o 192.168.0.0/16 (private) o 192.168.0.0/16 (private)
o 169.254.0.0/16 (IANA Assigned DHCP link-local) o 169.254.0.0/16 (IANA Assigned DHCP link-local)
o 224.0.0.0/4 (multicast) o 224.0.0.0/4 (multicast)
o 240.0.0.0/4 (reserved and broadcast) o 240.0.0.0/4 (reserved and broadcast)
In addition, the address MUST NOT be any of the system's broadcast In addition, the address MUST NOT be any of the system's broadcast
addresses. This is especially important if the implementation is addresses. This is especially important if the implementation is
made so that it can: made so that it can
o receive and process encapsulated IPv4 packets arriving at its o receive and process encapsulated IPv4 packets arriving at its
broadcast addresses, or broadcast addresses, or
o send encapsulated IPv4 packets to one of its broadcast addresses. o send encapsulated IPv4 packets to one of its broadcast addresses.
5.3.2 IPv6 5.3.2. IPv6
IPv6 address MUST NOT be: IPv6 address MUST NOT be
o 0::/16 (compatible, mapped addresses, loopback, unspecified, ...) o 0::/16 (compatible, mapped addresses, loopback, unspecified, ...)
o fe80::/10 (link-local) o fe80::/10 (link-local)
o fec0::/10 (site-local) o fec0::/10 (site-local)
o ff00::/8 (any multicast) o ff00::/8 (any multicast)
Note: only link-local multicast would be strictly required, but it is Note: Only link-local multicast would be strictly required, but it is
believed that multicast with 6to4 will not be feasible, so it has believed that multicast with 6to4 will not be feasible, so it has
been disallowed as well. been disallowed as well.
In addition, it MUST be checked that equivalent 2002:V4ADDR::/48 In addition, it MUST be checked that equivalent 2002:V4ADDR::/48
checks, where V4ADDR is any of the above IPv4 addresses, will not be checks, where V4ADDR is any of the above IPv4 addresses, will not be
passed. passed.
5.3.3 Optional Ingress Filtering 5.3.3. Optional Ingress Filtering
In addition, the implementation in the 6to4 router may perform some In addition, the implementation in the 6to4 router may perform some
form of ingress filtering (e.g. Unicast Reverse Path Forwarding form of ingress filtering (e.g., Unicast Reverse Path Forwarding
checks). For example, if the 6to4 router has multiple interfaces, of checks). For example, if the 6to4 router has multiple interfaces, of
which some are "internal", receiving either IPv4 or IPv6 packets with which some are "internal", receiving either IPv4 or IPv6 packets with
source address belonging to any of these internal networks from the source address belonging to any of these internal networks from the
Internet might be disallowed. Internet might be disallowed.
If these checks are implemented, and are enabled by default, it's If these checks are implemented and enabled by default, it's
recommended that there is a toggle to disable them if needed. recommended that there be a toggle to disable them if needed.
5.3.4 Notes About the Checks 5.3.4. Notes about the Checks
The rule "dst_v4 SHOULD be assigned to the router" is not needed if The rule "dst_v4 SHOULD be assigned to the router" is not needed if
the 6to4 router implementation only accepts and processes the 6to4 router implementation only accepts and processes
encapsulated IPv4 packets arriving its unicast IPv4 addresses, and encapsulated IPv4 packets arriving to its unicast IPv4 addresses, and
when destination address is known to be a local broadcast address, it when the destination address is known to be a local broadcast
does not try to encapsulate and send packets to it. (see Section address, it does not try to encapsulate and send packets to it. (See
4.1.4, and Section 4.2.4 about this threat). Sections 4.1.4 and 4.2.4 about this threat.)
Some checks, especially the IPv4/IPv6 Sanity Checks, could be at Some checks, especially the IPv4/IPv6 Sanity Checks, could be at
least partially implementable with system-level access lists, if one least partially implementable with system-level access lists, if one
would like to avoid placing too many restrictions in the 6to4 would like to avoid placing too many restrictions in the 6to4
implementation itself. This depends on how many hooks for the access implementation itself. This depends on how many hooks are in place
lists are in place. In practice it seems that this could not be done for the access lists. In practice, it seems that this could not be
effectively enough unless the access list mechanism is able to parse done effectively enough unless the access list mechanism is able to
the encapsulated packets. parse the encapsulated packets.
6. Issues in 6to4 Implementation and Use 6. Issues in 6to4 Implementation and Use
This section tries to give an overview of some of the problems 6to4 This section tries to give an overview of some of the problems 6to4
implementations are faced with, and the kind of generic problems the implementations face, and the kind of generic problems the 6to4 users
6to4 users could come up with. could come up with.
6.1 Implementation Considerations with Automatic Tunnels 6.1. Implementation Considerations with Automatic Tunnels
There is a problem with multiple transition mechanisms if strict There is a problem with multiple transition mechanisms if strict
security checks are implemented. This may vary a bit from security checks are implemented. This may vary a bit from
implementation to implementation. implementation to implementation.
Consider three mechanisms using automatic tunneling: 6to4, ISATAP Consider three mechanisms using automatic tunneling: 6to4, ISATAP
[15] and Automatic Tunneling using Compatible Addresses [4] [15], and Automatic Tunneling using Compatible Addresses [4]
(currently removed [10] but typically still supported). All of these (currently removed [10] but typically still supported). All of these
use IP-IP (protocol 41) [16] IPv4 encapsulation with, more or less, a use IP-IP (protocol 41) [16] IPv4 encapsulation with, more or less, a
pseudo-interface. pseudo-interface.
When a router, which has any two of these enabled, receives an IPv4 When a router, which has any two of these enabled, receives an IPv4
encapsulated IPv6 packet: encapsulated IPv6 packet
src_v6 = 2001:db8::1 src_v6 = 2001:db8::1
dst_v6 = 2002:1010:1010::2 dst_v6 = 2002:1010:1010::2
src_v4 = 10.0.0.1 src_v4 = 10.0.0.1
dst_v4 = 20.20.20.20 dst_v4 = 20.20.20.20
What can it do? How should it decide which transition mechanism this What can it do? How should it decide which transition mechanism this
belongs to; there is no "transition mechanism number" in IPv6 or IPv4 belongs to; there is no "transition mechanism number" in the IPv6 or
header to signify this. (This can also be viewed as a flexibility IPv4 header to signify this. (This can also be viewed as a
benefit.) flexibility benefit.)
Without any kind of security checks (in any of implemented methods) Without any kind of security checks (in any of the implemented
these often just "work" as the mechanisms aren't differentiated but methods), these often just "work", as the mechanisms aren't
handled in "one big lump". differentiated but handled in "one big lump".
Configured tunneling [4] does not suffer from this as it is 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 point-to-point and based on src_v6/dst_v6 pairs of both IPv4 and IPv6
IPv6 addresses it can be deduced which logical tunnel interface is in addresses, so the tunnel interface can be logically deduced.
the question.
Solutions for this include 1) not using more than one automatic Solutions for this include 1) not using more than one automatic
tunneling mechanism in a node or 2) binding different mechanisms to tunneling mechanism in a node and 2) binding different mechanisms to
different IPv4 addresses. different IPv4 addresses.
6.2 A Different Model for 6to4 Deployment 6.2. A Different Model for 6to4 Deployment
Even though this was already discussed in Section 4.1.2, it bears Even though this was already discussed in Section 4.1.2, it bears
some additional elaboration as it was the only problem which cannot some additional elaboration, as it was the only problem that cannot
be even partially solved using the current deployment model -- but be even partially solved using the current deployment model. There
there are some mitigation methods. are some mitigation methods.
That is, 6to4 routers receive traffic from non-6to4 ("native") 6to4 routers receive traffic from non-6to4 ("native") sources via
sources via 6to4 relays. 6to4 routers have no way of matching IPv4 6to4 relays. 6to4 routers have no way of matching the IPv4 source
source address of the relay with non-6to4 IPv6 address of the source. address of the relay with the non-6to4 IPv6 address of the source.
Consequently, anyone can spoof any non-6to4 IPv6 address he wants by Consequently, anyone can spoof any non-6to4 IPv6 address by sending
sending traffic, encapsulated, directly to 6to4 routers. traffic, encapsulated, directly to 6to4 routers.
It could be possible to turn the deployment assumptions of 6to4 It could be possible to turn the deployment assumptions of 6to4
around a bit to eliminate some threats caused by untrusted 6to4 around a bit to eliminate some threats caused by untrusted 6to4
relays. That is: relays:
o Every dual-stack site (or even ISP) would be required to have o Every dual-stack site (or even ISP) would be required to have its
their own 6to4 relay. (This assumes that IPv6-only is so long own 6to4 relay. (This assumes that IPv6-only is so far away that
away that 6to4 would be hopefully retired at that point.) That 6to4 would be retired by that point.) That is, there would not be
is, there would not be third-party relays, and 2002::/16 and third-party relays, and 2002::/16 and 192.88.99.0/24 routes would
192.88.99.0/24 routes would not need to be advertised globally, not need to be advertised globally.
and
o The security implications of 6to4 use could be pushed back to the o The security implications of 6to4 use could be pushed back to the
level of trust inside the site or ISP (or their acceptable use level of trust inside the site or ISP (or their acceptable use
policies) -- this is something that the sites and ISP's should be policies). This is something that the sites and ISPs should
familiar with already. already be familiar with already.
However, this has a number of problems: However, this presents a number of problems:
This model would shift the majority of burden of supporting 6to4 to This model would shift most of the burden of supporting 6to4 to IPv6
IPv6 sites which don't employ or use 6to4 at all, i.e., "those who sites that don't employ or use 6to4 at all, i.e., "those who deploy
deploy proper native dual-stack". It could be argued that the proper native dual-stack." It could be argued that the deployment
deployment pain should be borne by 6to4 users, not the others. pain should be borne by 6to4 users, not by the others.
The main advantage of 6to4 is easy deployment and free relays. This The main advantage of 6to4 is easy deployment and free relays. This
would require that everyone the 6to4 sites wish to communicate with would require that everyone the 6to4 sites wish to communicate with
implement these measures. implement these measures.
The model would not fix the "relay spoofing problem", unless The model would not fix the "relay spoofing problem", unless
everybody deployed also 6to4 addresses on the nodes (alongside with everybody also deployed 6to4 addresses on the nodes (alongside with
native addresses, if necessary), which in turn would change 6to4 to native addresses, if necessary), which would in turn change 6to4 to
operate without relays completely. operate without relays completely.
7. Security Considerations 7. Security Considerations
This draft discusses security considerations of 6to4. This document discusses security considerations of 6to4.
Even if proper checks are implemented, there are a large number of Even if proper checks are implemented, there are a large number of
different kind of security threats; these threats are analyzed in different security threats; these threats are analyzed in Section 4.
Section 4.
There are mainly three classes of potential problem sources: There are mainly four classes of potential problem sources:
1. 6to4 routers not being able to identify whether relays are 1. 6to4 routers not being able to identify whether relays are
legitimate, legitimate
2. Wrong or impartially implemented 6to4 router or relay security 2. Wrong or impartially implemented 6to4 router or relay security
checks, checks
3. 6to4 architecture used to participate in DoS or reflected DoS 3. 6to4 architecture used to participate in DoS or reflected DoS
attacks, or made to participate in "packet laundering", i.e., attacks or made to participate in "packet laundering", i.e.,
making another attack harder to trace, or making another attack harder to trace
4. 6to4 relays being subject to "administrative abuse", e.g., theft 4. 6to4 relays being subject to "administrative abuse" e.g., theft
of service, or being seen as a source of abuse. of service or being seen as a source of abuse.
The first is the toughest problem, still under research. The second The first is the toughest problem, still under research. The second
can be fixed by ensuring the correctness of implementations; this is can be fixed by ensuring the correctness of implementations; this is
important. The third is also a very difficult problem, and important. The third is also a very difficult problem, impossible to
impossible to solve completely -- therefore it is important to be solve completely; therefore it is important to be able to analyze
able to analyze whether this results in a significant increase of whether this results in a significant increase of threats. The
threats. The fourth problem seems to have feasible solutions. fourth problem seems to have feasible solutions.
These are analyzed in detail in Threat Analysis, in Section 4.
8. IANA Considerations
This memo makes no requet to IANA. (RFC-editor note: please remove These are analyzed in detail in "Threat Analysis", in Section 4.
this section on publication.)
9. Acknowledgments 8. Acknowledgments
Some issues were first brought up by Itojun Hagino in [17], and Alain Some issues were first brought up by Itojun Hagino in [17], and Alain
Durand introduced one specific problem at IETF51 in August 2001 Durand introduced one specific problem at IETF51 in August 2001
(though there was some discussion on the list prior to that); these (though there was some discussion on the list prior to that); these
gave the author the push to start looking into the details of two gave the authors the push to start looking into the details of
securing 6to4. securing 6to4.
Alexey Kuznetsov brought up the implementation problem with IPv6 Alexey Kuznetsov brought up the implementation problem with IPv6
martian checks. Christian Huitema formulated the rules that rely on martian checks. Christian Huitema formulated the rules that rely on
6to4 relays using only anycast. Keith Moore brought up the point 6to4 relays using only anycast. Keith Moore brought up the point
about reduced flexibility. Brian Carpenter, Tony Hain and Vladislav about reduced flexibility. Brian Carpenter, Tony Hain, and Vladislav
Yasevich are acknowledged for lengthy discussions. Alain Durand Yasevich are acknowledged for lengthy discussions. Alain Durand
reminded of relay spoofing problems. Brian Carpenter reminded of the reminded the authors about relay spoofing problems. Brian Carpenter
BGP-based 6to4 router model. Christian Huitema gave a push to a more reminded the authors about the BGP-based 6to4 router model.
complete threat analysis. Itojun Hagino spelled out the operators' Christian Huitema gave a push for a more complete threat analysis.
fears about 6to4 relay abuse. Rob Austein brought up the idea of a Itojun Hagino spelled out the operators' fears about 6to4 relay
different 6to4 deployment model. abuse. Rob Austein brought up the idea of a different 6to4
deployment model.
In the latter phase, especially discussions with Christian Huitema, In the latter phase, discussions with Christian Huitema, Brian
Brian Carpenter and Alain Durand were helpful when improving the Carpenter, and Alain Durand were helpful when improving the document.
document.
David Malone, Iljitsch van Beijnum, and Tim Chown gave feedback on David Malone, Iljitsch van Beijnum, and Tim Chown gave feedback on
the document. the document.
10. References 9. References
10.1 Normative References 9.1. Normative References
[1] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 [1] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4
Clouds", RFC 3056, February 2001. Clouds", RFC 3056, February 2001.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC [3] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC
3068, June 2001. 3068, June 2001.
10.2 Informative References 9.2. Informative References
[4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 [4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
Hosts and Routers", RFC 2893, August 2000. Hosts and Routers", RFC 2893, August 2000.
[5] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. [5] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[6] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", [6] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995. RFC 1771, March 1995.
[7] Draves, R., "Default Address Selection for Internet Protocol [7] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003. version 6 (IPv6)", RFC 3484, February 2003.
[8] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor [8] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[9] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, [9] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05 "SEcure Neighbor Discovery (SEND)", Work in Progress, July 2004.
(work in progress), April 2004.
[10] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for [10] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-03 (work in IPv6 Hosts and Routers", Work in Progress, September 2004.
progress), June 2004.
[11] Savola, P., "Security of IPv6 Routing Header and Home Address [11] Savola, P., "Security of IPv6 Routing Header and Home Address
Options", draft-savola-ipv6-rh-ha-security-02 (work in Options", Work in Progress, March 2002.
progress), March 2002.
[12] Ferguson, P. and D. Senie, "Network Ingress Filtering: [12] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating
Defeating Denial of Service Attacks which employ IP Source Denial of Service Attacks which employ IP Source Address
Address Spoofing", BCP 38, RFC 2827, May 2000. Spoofing", BCP 38, RFC 2827, May 2000.
[13] Bellovin, S., Leech, M. and T. Taylor, "ICMP Traceback [13] Bellovin, S., Leech, M. and T. Taylor, "ICMP Traceback
Messages", draft-ietf-itrace-04 (work in progress), February Messages", Work in Progress, February 2003.
2003.
[14] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, [14] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995. June 1995.
[15] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site [15] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", Automatic Tunnel Addressing Protocol (ISATAP)", Work in
draft-ietf-ngtrans-isatap-22 (work in progress), May 2004. Progress, May 2004.
[16] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. [16] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[17] Hagino, J., "Possible abuse against IPv6 transition [17] Hagino, J., "Possible abuse against IPv6 transition
technologies", draft-itojun-ipv6-transition-abuse-01.txt technologies", Work in Progress, July 2000.
(expired, work-in-progress) , July 2000.
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.org
Appendix A. Some Trivial Attack Scenarios Outlined Appendix A. Some Trivial Attack Scenarios Outlined
Here, a few trivial attack scenarios are outlined -- ones that are Here, a few trivial attack scenarios are outlined -- ones that are
prevented by implementing checks listed in [1] or in section 6. prevented by implementing checks listed in [1] or in section 6.
When two 6to4 routers send traffic to each others' domains, packet When two 6to4 routers send traffic to each others' domains, the
sent by RA to RB is like: packet sent by RA to RB resembles the following:
src_v6 = 2002:0800:0001::aaaa src_v6 = 2002:0800:0001::aaaa
dst_v6 = 2002:0800:0002::bbbb dst_v6 = 2002:0800:0002::bbbb
src_v4 = 8.0.0.1 (added when encapsulated to IPv4) src_v4 = 8.0.0.1 (added when encapsulated to IPv4)
dst_v4 = 8.0.0.2 (added when encapsulated to IPv4) dst_v4 = 8.0.0.2 (added when encapsulated to IPv4)
When the packet is received by IPv4 stack on RB, it will be When the packet is received by IPv4 stack on RB, it will be
decapsulated so that only src_v6 and dst_v6 remain, as originally decapsulated so that only src_v6 and dst_v6 remain, as originally
sent by RA: sent by RA:
src_v6 = 2002:0800:0001::aaaa src_v6 = 2002:0800:0001::aaaa
dst_v6 = 2002:0800:0002::bbbb dst_v6 = 2002:0800:0002::bbbb
As every other node is just one hop away (IPv6-wise) and the As every other node is just one hop away (IPv6-wise) and the
link-layer (IPv4) addresses are lost, this may open a lot of link-layer (IPv4) addresses are lost, this may open many
possibilities for misuse. possibilities for misuse.
As an example, unidirectional IPv6 spoofing is made trivial because As an example, unidirectional IPv6 spoofing is made trivial because
nobody can check (without delving into IP-IP packets) whether the nobody can check (without delving into IP-IP packets) whether the
encapsulated IPv6 addresses were authentic (With native IPv6, this encapsulated IPv6 addresses were authentic. (With native IPv6, this
can be done by e.g., RPF-like mechanisms or access lists in upstream can be done by, e.g., RPF-like mechanisms or access lists in upstream
routers). routers.)
src_v6 = 2002:1234:5678::aaaa (forged) src_v6 = 2002:1234:5678::aaaa (forged)
dst_v6 = 2002:0800:0002::bbbb dst_v6 = 2002:0800:0002::bbbb
src_v4 = 8.0.0.1 (added when encapsulated to IPv4) src_v4 = 8.0.0.1 (added when encapsulated to IPv4)
dst_v4 = 8.0.0.2 (added when encapsulated to IPv4) dst_v4 = 8.0.0.2 (added when encapsulated to IPv4)
A similar attack with "src" being native address is possible even A similar attack with "src" being the native address is made
with the security checks, by having the sender node pretend to be a possible, even with the security checks, by having the sender node
6to4 relay router. pretend to be a 6to4 relay router.
More worries come in to the picture if e.g., More worries come into the picture if, e.g.,
src_v6 = ::ffff:[some trusted IPv4 in a private network] src_v6 = ::ffff:[some trusted IPv4 in a private network]
src_v6/dst_v6 = ::ffff:127.0.0.1 src_v6/dst_v6 = ::ffff:127.0.0.1
src_v6/dst_v6 = ::1 src_v6/dst_v6 = ::1
src_v6/dst_v6 = ... src_v6/dst_v6 = ...
Some implementations might have been careful enough to have designed Some implementations might have been careful enough to design the
the stack to as to avoid the incoming (or reply) packets going to stack so as to avoid the incoming (or reply) packets going to IPv4
IPv4 packet processing through special addresses (e.g., IPv4-mapped packet processing through special addresses (e.g., IPv4-mapped
addresses), but who can say for all ... addresses), but who can say for all ...
Appendix B. Change Log Authors' Addresses
[[ RFC-EDITOR note: to be removed before publication ]]
Changes from -03 to -04
1. Some editorial fixes; resolve IESG evaluation comments.
Changes from -02 to -03
1. Only rather minor editorial changes.
Changes from -01 to -02 Pekka Savola
CSC/FUNET
Espoo
Finland
1. Incorporate Iljitsch's feedback EMail: psavola@funet.fi
2. Clean up section 6.2 Chirayu Patel
All Play, No Work
185, Defence Colony
Bangalore, Karnataka 560038
India
3. Fix encapsulation code (had been munged in -01) Phone: +91-98452-88078
EMail: chirayu@chirayu.org
URI: http://www.chirayu.org
Changes from -00 to -01 Full Copyright Statement
1. Lots of editorial changes in other sections Copyright (C) The Internet Society (2004).
2. Revamped the "Threat Analysis" section completely; ripple the This document is subject to the rights, licenses and restrictions
effects elsewhere in the document as well. contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
3. Added Chirayu Patel as a co-author. 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 Statement Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the IETF's procedures with respect to rights in IETF Documents can
found in BCP 78 and BCP 79. be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at ietf-
ietf-ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) 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.
Acknowledgment Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/