v6ops Working Group                                            P. Savola
Internet Draft
Internet-Draft                                                 CSC/FUNET
Expiration Date: April
Expires: August 10, 2004                                        C. Patel
                                                       All Play, No Work
                                                            Feb 10, 2004
                                                            October 2003

                    Security Considerations for 6to4

                 draft-ietf-v6ops-6to4-security-00.txt
                 draft-ietf-v6ops-6to4-security-01.txt

Status of this Memo

   This document is an Internet-Draft and is subject to in full conformance with
   all provisions of Section 10 of RFC2026.

   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.

   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.

   To view the http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories, see Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 10, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over-
   IPv4
   IPv6-over-IPv4 tunneling to interconnect IPv6 networks.  The
   architecture includes 6to4 Routers routers and Relay Routers, 6to4 relay routers, which
   accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from anywhere.  There
   aren't many constraints on
   any node in the embedded IPv6 packets, or where IPv4
   traffic will be automatically tunneled to.  These could internet. This characteristic enable one ones to go
   around access controls, controls and more likely, being able to perform
   proxy Denial of Service attacks using
   6to4 relays or routers as
   reflectors.  Anyone is 6to4 routers.  It also capable of spoofing traffic from non-6to4
   addresses, as if makes it was coming from a relay, easier for nodes to a 6to4 node.
   spoof IPv6 addresses. This document discusses these issues in more
   detail and tries to suggest suggests enhancements to alleviate the problems.

Table of Contents

   1.    Introduction  ...............................................   3 . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.    Different 6to4 Forwarding Scenarios  ........................   4
     2.1.  . . . . . . . . . . . .  5
   2.1   From 6to4 to 6to4  ......................................   4
     2.2.  . . . . . . . . . . . . . . . . . . . . .  5
   2.2   From Native to 6to4  ....................................  . . . . . . . . . . . . . . . . . . . .  5
     2.3.
   2.3   From 6to4 to Native  ....................................  . . . . . . . . . . . . . . . . . . . .  6
     2.4.
   2.4   Other Models  ........................................... . . . . . . . . . . . . . . . . . . . . . . . .  6
       2.4.1.
   2.4.1 BGP Between 6to4 Routers and Relays  ................   6
       2.4.2.  . . . . . . . . . . . .  7
   2.4.2 6to4 as an Optimization Method  ..................... . . . . . . . . . . . . . . .  7
       2.4.3.
   2.4.3 6to4 as Tunnel End-Point Addressing Mechanism  ......  . . . . . . .  7
   3.  Some    Functionalities of 6to4  ...............................   7
     3.1.  Functions of Different 6to4 Network Components  .........   7
     3.2.  Non-functions of Different 6to4 Network Components  ..... . . . . . . . . .  9
   4.  Special Processing of
   3.1   6to4 Packets  .........................   9
     4.1.  Encapsulating IPv6 Packets into IPv4  ................... Routers . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.2.  Decapsulating IPv4 Packets into IPv6  ...................  10
   5.  Threat Analysis  ............................................  10
     5.1.  Threats Related to Any 6to4 Node  .......................  10
     5.2.  Threats Related to
   3.2   6to4 Relay Routers  ........................ . . . . . . . . . . . . . . . . . . . . . 10
       5.2.1.
   4.    Threat Analysis  . . . . . . . . . . . . . . . . . . . . . . 11
   4.1   Attacks Against the on 6to4 Pseudo-Interface  ..........  11
         5.2.1.1.  Comparison Networks . . . . . . . . . . . . . . . . . . 12
   4.1.1 Attacks with ND Messages . . . . . . . . . . . . . . . . . . 13
   4.1.2 Spoofing Traffic to Situation without 6to4  ...........  11
       5.2.2.  Relay Spoofing, DoS against IPv6 Nodes  .............  11
         5.2.2.1.  Comparison to Situation without 6to4  ...........  12
     5.3.  Threats Related . . . . . . . . . . . . . . . 14
   4.1.3 Reflecting Traffic to 6to4 Relays  .........................  13
       5.3.1.  Attacks Against the 6to4 Pseudo-Interface  ..........  14
       5.3.2.  Spoofing, DoS against IPv6 Nodes  ...................  14
       5.3.3.  Participating in DoS attacks against . . . . . . . . . . . . . . 16
   4.1.4 Local IPv4  ..........  14
         5.3.3.1.  Comparison Broadcast Attack  . . . . . . . . . . . . . . . . 18
   4.2   Attacks on Native IPv6 Internet  . . . . . . . . . . . . . . 19
   4.2.1 Attacks with ND Messages . . . . . . . . . . . . . . . . . . 20
   4.2.2 Spoofing Traffic to Situation without 6to4  ...........  14
       5.3.4.  Using Any Native IPv6 Node for Reflection  .................  15
         5.3.4.1.  Comparison node . . . . . . . . . . . . 20
   4.2.3 Reflecting Traffic to Situation without 6to4  ...........  15
       5.3.5.  IPv4 Native IPv6 nodes  . . . . . . . . . . 22
   4.2.4 Local Directed IPv4 Broadcast Attacks  ..............  16
         5.3.5.1.  Comparison to Situation without 6to4  ...........  16
       5.3.6. Attack  . . . . . . . . . . . . . . . . 23
   4.2.5 Theft of Service  ...................................  16
       5.3.7. . . . . . . . . . . . . . . . . . . . . . . 24
   4.2.6 Relay Operators Seen as Source of Abuse  ............  17
     5.4.  Possible Threat Mitigation Methods  .....................  18
       5.4.1.  6to4 Decapsulation Cache  ...........................  18
       5.4.2.  Rate-limiting at 6to4 Routers/Relays  ...............  18
       5.4.3.  An Application of iTrace Model  .....................  18
     5.5.  Summary  ................................................  19
       5.5.1.  . . . . . . . . . . 25
   4.3   Attacks on IPv4 Internet . . . . . . . . . . . . . . . . . . 26
   4.4   Summary of the Threats  .............................  19
       5.5.2.  Generic Notes about Threats  ........................  20
   6. Attacks . . . . . . . . . . . . . . . . . . . 27
   5.    Implementing Proper Security Checks in 6to4  ................  21
     6.1.  Generic Approach  .......................................  21
       6.1.1.  . . . . . . . . 29
   5.1   Encapsulating IPv6 into IPv4  .......................  21
       6.1.2. . . . . . . . . . . . . . . . . 29
   5.2   Decapsulating IPv4 into IPv6  .......................  22
       6.1.3. . . . . . . . . . . . . . . . . 30
   5.3   IPv4 and IPv6 Sanity Checks  ........................  22
         6.1.3.1.  . . . . . . . . . . . . . . . . 30
   5.3.1 IPv4  ...........................................  22
         6.1.3.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
   5.3.2 IPv6  ...........................................  23
         6.1.3.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
   5.3.3 Optional Ingress Filtering  .....................  23
         6.1.3.4. . . . . . . . . . . . . . . . . . 32
   5.3.4 Notes About the Checks  .........................  23
     6.2.  Simplified Approach  ....................................  24
       6.2.1.  Encapsulating IPv6 into IPv4  .......................  24
       6.2.2.  Decapsulating IPv4 into IPv6  .......................  24
   7. . . . . . . . . . . . . . . . . . . . 32
   6.    Issues  .....................................................  25
     7.1. in 6to4 Implementation and Use  . . . . . . . . . . . 32
   6.1   Implementation Considerations with Automatic Tunnels  ...  25
     7.2.  Reduced Flexibility  ....................................  26
     7.3. . . . . 32
   6.2   Anyone Pretending to Be a 6to4 Relay Router  .................  26
       7.3.1. . . . . . . . . . . . . 33
   6.2.1 Limited Distribution of More Specific Routes  .......  27
       7.3.2. . . . . . . . . 34
   6.2.2 A Different Model for 6to4 Deployment  ..............  28
   8.  . . . . . . . . . . . 35
   7.    Security Considerations  ....................................  28
   9.  Acknowledgements  ...........................................  29
   10.  References  ................................................  30
     10.1.  . . . . . . . . . . . . . . . . . . 35
   8.    Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 36
         Normative References  ..................................  30
     10.2. . . . . . . . . . . . . . . . . . . . . 36
         Informative References  ................................  30
   Author's Address  ...............................................  31 . . . . . . . . . . . . . . . . . . . 37
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38
   A.    Some Trivial Attack Scenarios Outlined  .....................  31 . . . . . . . . . . . 38
   B.    Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 39
         Intellectual Property and Copyright Statements . . . . . . . 40

1. Introduction

   The IPv6 interim mechanism "6to4" [6TO4] [1] specifies automatic
   IPv6-over-IPv4 tunneling to interconnect isolated IPv6 clouds without
   explicit tunnels by
   embedding the tunnel IPv4 address in the IPv6 6to4 prefix.

   One challenge with this

   Two characteristics of the 6to4 mechanism is that all introduce most of the
   security considerations:

   1.  All 6to4 routers must accept and decapsulate IPv4 packets from
       every other 6to4 router; router, and 6to4 relays.

   2.  6to4 relay routers must accept traffic from any native IPv6 node.

   Since the 6to4 router must accept from traffic from any other 6to4
   router or relay, it implies a certain level of trust, and there are
   no strict constraints on what the IPv6 packet may contain,
   which implies a trust relationship.

   Another, bigger challenge is that to interconnect native IPv6
   networks contain.  Thus,
   addresses within the IPv4, and 6to4 clouds, relay routers are used as bridges between
   these two clouds.  Relay routers can be tricked by malicious parties
   to send IPv4 or IPv6 traffic anywhere the attacker wants.  With
   source address spoofing, this could be called traffic "laundering" or
   a "proxy" denial-of-service attack.  To some extent, these reflected
   attacks can also header may be launched off from any node at all.

   Even worse, anyone can send tunneled traffic, spoofed to come from
   non-6to4 addresses to any 6to4 router, spoofed, and the node does not have any
   means to ensure its correctness, but this
   property leads to assume it came from a
   legitimate Relay. various types of threats including DoS, and
   reflection DoS.

   The 6to4 specification outlined quite a few security considerations,
   but it has been shown that in practice some of these them have been
   difficult to get implemented due to their abstract nature.

   This draft analyses analyzes the 6to4 security issues in more detail and
   outlines some enhancements and caveats.

   Sections 2-4

   Section 2, and Section 3 are more or less introductory in nature,
   rehashing how 6to4 should be is used today based on the 6to4 specification, so
   that it is easier to understand how security could be affected.
   Section 5 4 provides a threat analysis for implementations that already
   implement most of the security checks.  Section 6 5 introduces some
   filtering rules for 6to4 implementations, and section 7 discusses some
   additional problems Section 6 provides
   further discussion on a few issues which still need some consideration. have proven to be difficult.
   Appendix A outlines a few possible trivial attack scenarios in the
   case that very little or no security has been implemented.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and

   For the sake of simplicity, in this document, native IPv6 Internet is
   assumed to encompass IPv6 networks formed using other transition
   mechanisms (e.g. RFC 2893 [4]), as these mechanisms cannot talk
   directly 6to4 network.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119]. RFC 2119 [2].

2. Different 6to4 Forwarding Scenarios

   It should be noted that when communicating between 6to4 and native
   domains, the 6to4 relays that will be used in the two directions are
   very likely different; routing is highly asymmetric.  Because of
   this, it is not feasible to limit relays you accept traffic from with e.g.
   access lists. which 6to4 routers may
   accept traffic.

   The first three subsections introduce the most common forms of 6to4
   operation.  Other models are presented in the fourth subsection.

2.1.

2.1 From 6to4 to 6to4

   6to4 domains always exchange 6to4 traffic directly via IPv4
   tunneling; the endpoint address V4ADDR is derived from 6to4 prefix
   2002:V4ADDR.
   2002:V4ADDR::/48 of the destination.

    .--------.           _----_          .--------.
    |  6to4  |         _( IPv4 )_        |  6to4  |
    | Router router | <====> ( Internet ) <===> | Router router |
    '--------'         (_      _)        '--------'
        ^                '----'              ^
        |      Direct tunneling over IPv4    |
        V                                    V
    .--------.                           .-------.
    |  6to4  |                           |  6to4  |
    | Client  host  |                           | Client  host  |
    '--------'                           '--------'

                                Figure 1

   It is required that every 6to4 router considers every other 6to4
   router it wants to talk to to be "on-link" (with IPv4 as the link-
   layer).  If this is restricted by increasing the prefix length from
   2002::/16, some traffic will be sent to the 6to4 Relay Router, which
   would forward it to other 6to4 Routers.  However, if the original
   destination does not have equally long prefix, the traffic it tries
   to send back will be tunneled directly, and will be dropped.

   Therefore, the restricted scenario with a longer prefix-length is not
   globally workable and will not be considered here.

2.2.
   link-layer).

2.2 From Native to 6to4

   When native domains send traffic to 6to4 address 2002:V4ADDR, prefix 2002:V4ADDR::/48, it
   will be routed to the topologically nearest, advertising (advertising
   route to 2002::/16) 6to4 Relay
   Router.  Relay router relay.  The 6to4 relay will tunnel the
   traffic over IPv4 to the corresponding IPv4 address V4ADDR.  (Note

   Note that IPv4 address 9.0.0.1 here is just an example of a global
   IPv4 address.)

              2002::/16 address, and it is assigned to the 6to4 router's
   pseudo-interface.

                                     Closest to 'Native Client'
                                 "Native IPv6 node"
    .--------.       _----_        .------------.            .--------.
    | Native |     _( IPv6 )_      | 6to4 Relay relay |  Tunneled  |  6to4  |
    | Client IPv6   | -> ( Internet ) --> | Router router     | =========> | Router router |
    | node   |
    '--------'     (_      _)      '------------'   9.0.0.1  '--------'
    '--------'       '----'    dst=2002:0900:0001::1  dst_v6=2002:0900:0001::1            |
                                                                 V
                                                             .-------.
                                                             |  6to4  |
                                                             | Client  host  |
                                                             '--------'

2.3.

                                Figure 2

2.3 From 6to4 to Native

   6to4 domains send traffic to native domains by tunneling it over IPv4
   to their configured 6to4 Relay Router, relay router, or the closest one found using
   6to4 IPv4 Anycast [6TO4ANY]. [3].  The relay will decapsulate the packet and
   forward it to native IPv6 Internet, the same way as any other IPv6
   packet.

                         Configured/found

   Note that destination IPv6 address in the packet is a non-6to4
   address, and is assumed to be 2001:db8::1 in the example.

                                     Configured
                                        -or-
                                 found by IPv4 Anycast
    .--------.       _----_        .------------.            .--------.
    | Native |     _( IPv6 )_      | 6to4 Relay relay |  Tunneled  |  6to4  |
    | Client | <- ( Internet ) <-- | Router router     | <========= | Router router |
    '--------'     (_      _)      '------------' 192.88.99.1'--------'
   2001:db8::1       '----'                     (or configured)   ^
                dst=3ffe:ffff::1
                                                                  |
                                                             .-------.
                                                             |  6to4  |
                                                             | Client client |
                                                             '--------'

2.4.

                                Figure 3

2.4 Other Models

   These are more or less special cases of 6to4 operation; in operations. In later
   chapters, unless otherwise stated, only the most generally-used
   models (above) will be considered.

2.4.1.

2.4.1 BGP Between 6to4 Routers and Relays

   [6TO4, 5.2.2.2]

   Section 5.2.2.2 in [1] presents a model where, instead of static
   configuration, BGP4+ BGP [5] is used between 6to4 Relay Routers relay routers and 6to4
   Routers.
   routers.

   If the 6to4 router established a BGP session between all the possible
   6to4 relays, and advertised its /48 prefix to them, the traffic from
   non-6to4 sites would always go through
   "home relay", and configuring "trusted relay" would not be come from a problem;
   an alternative would be to "known" relay.
   Alternatively, the 6to4 relays might advertise the more specific 6to4
   routes between 6to4 Relays, relays, as described later in Section 6.2.1 in this
   memo.

   This model is not

   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
   those that are not able to run BGP, and because setting up these
   sessions would be much more work for relay operators.

2.4.2.

2.4.2 6to4 as an Optimization Method

   Some sites seem to use 6to4 as an IPv6 connectivity "optimization
   method"; that is, they have also non-6to4 addresses on their nodes
   and border routers, but also employ 6to4 to reach 6to4 sites.

   This is typically done to be able to reach 6to4 destinations by
   direct tunneling and not having to use relays at all.

   Some

   These sites also publish both 6to4 and non-6to4 addresses in DNS to
   affect inbound connections; if the source host's default address
   selection
   [ADDRSEL] [6] works properly, 6to4 sources will use 6to4 addresses to
   reach the site and non-6to4 nodes use non-6to4 addresses. If this
   behaviour
   behavior of foreign nodes can be assumed, the security threats to
   such sites can be significantly simplified.

2.4.3.

2.4.3 6to4 as Tunnel End-Point Addressing Mechanism

   6to4 addresses can also be used only as an IPv6-in-IPv4 tunnel
   endpoint addressing and routing mechanism.

   An example of this is interconnecting 10 branch offices where nodes
   use non-6to4 addresses.  Only the offices' border routers need to be
   aware of 6to4, and use 6to4 addresses solely for addressing the
   tunnels between different branch offices.  This assumes that all
   outgoing traffic from the  An example is provided in
   the figure below.

    2001:db8:0:10::/60                   2001:db8:0:20::/60
       .--------.                           .--------.
      ( Branch 1 )                         ( Branch 2 )
       '--------'                           '--------'
           |                                     |
       .--------.           _----_          .--------.
       |  6to4  |         _( IPv4 )_        |  6to4  |
       | router | <====> ( Internet ) <===> | router |
       '--------'         (_      _)        '--------'
        9.0.0.1             '----'            8.0.0.2
                              ^^
                              ||
                              vv
                          .--------.
                          |  6to4  | 7.0.0.3
                          | router |
                          '--------'
                              |        2001:db8::/48
                        .-----------.
                       ( Main Office )
                        '-----------'
                              ^
                              |
                              v
                            _----_
                          _( IPv6 )_
                         ( Internet )
                          (_      _)
                            '----'

                                Figure 4

   In the figure, the main organization (but not between office sets up two routes:

      2001:db8:0:10::/60 -> 2002:0900:0001::1

      2001:db8:0:20::/60 -> 2002:0800:0002::1

   And a branch
   offices) uses one or more non-6to4 connections.

   This is similar to office sets up two routes as well:

      2001:db8:0:20::/60 -> 2002:0800:0002::1

      default -> 2002:0700:0003::1

   Thus, the optimization model above, and can IPv4 Internet is treated as NBMA link-layer for
   interconnecting 6to4-enabled sites; with explicit routes, 6to4
   addressing need not be used in other than the 6to4 edge routers.
   However, note that if a branch office sends a packet to
   make any 6to4
   destination, it will not go through the main office as the 6to4
   2002::/16 route overrides the default route.

   This approach may make addressing and routing easier. slightly easier in some
   circumstances.

3. Some Functionalities of 6to4

   In this section, some, relatively obvious features of different 6to4
   components are listed to better undestand what's the required
   behaviour.

3.1. Functions of Different 6to4 Network Components

     o Non-6to4 (Native) Node

            If native IPv6 nodes want to communicate with 6to4 nodes,
            they send

   This section summarizes the traffic along normally.  The traffic will
            reach main functionalities of the topologically closest, advertising 6to4 Relay
            Router, network
   components (6to4 routers, and will 6to4 relays), and the security checks
   that must be tunneled to done by them. The pseudo-code for the destination 6to4 Router,
            which will pass it to security checks is
   provided in Section 5.

   This section summarizes the 6to4 node via normal forwarding
            process.

     o 6to4 Host

            A host, usually autoconfigured, main functions of the various components
   that has an address from are part of a 6to4 prefix, but doesn't have a network - 6to4 pseudo-interface.  It
            doesn't need to know anything about 6to4, relay routers, and it acts like a
            normal IPv6 Host in every manner.  Note that 6to4 Hosts can
            also be
   routers.  Refer to Section 1.1 of RFC 3056 [1] for 6to4 Routers in some scenarios, but then related
   definitions.

3.1 6to4 Router
            functionalities, below, apply.

     o Routers

   The 6to4 Router

            Acts at routers acts as the border router of a 6to4 domain.  It does
   not have a native, global IPv6 address.  More specifically:

              - provide "native-like"  The main functions of the
   6to4 router are:

   o  Provide IPv6 connectivity to local clients and routers
              - if routers.

   o  Tunnel packets are sent to foreign 6to4 addresses, tunnel
                them addresses to the destination
      6to4 router using IPv4
              - if IPv4.

   o  Forward packets are sent to locally configured 6to4
                addresses, forward them normally
              - if addresses to the
      6to4 network.

   o  Tunnel packets are sent to non-6to4 addresses, tunnel them to the configured/closest-by-anycast configured/
      closest-by-anycast 6to4 Relay Router,
                which will pass them on
              - if packets are relay router.

   o  Decapsulate directly received from 6to4 addresses, decapsulate
                the IPv4 packets received from foreign 6to4 routers
              - if packets are received from non-6to4 addresses,
                decapsulate the
      addresses.

   o  Decapsulate IPv4 packets received from 6to4 Relay
                Router via the relay closest to the source (note:
      native IPv6 sources.  Note, it is not easily distinguishable that
      the packet was really received from a Relay 6to4 relay router, not from
      a spoofing third party.)

     o 6to4 Relay Router

            Acts as a relay between all

   The 6to4 domains and native IPv6;
            more specifically:

              - advertises the reachability of the 2002::/16 prefix to
                native IPv6 routing, thus receiving router will also perform security checks on traffic to all that it
   will receive from other 6to4
                addresses relays, or 6to4 routers, or from closest native IPv6 nodes
              - (if implements RFC3068) advertise within
   the reachability of
                IPv4 '6to4 Relay anycast prefix' (192.88.99.0/24) to 6to4 site.  These checks include:

   o  Disallow traffic that has private, broadcast or reserved IPv4 routing, thus receiving some tunneled
      addresses in tunnels, or the matching 6to4 prefixes.

   o  Disallow traffic to
                native IPv6 nodes from 6to4 Routers
              - if packets are received from routers where the IPv4 tunnel source
      address does not match the 6to4 addresses through
                tunneling, decapsulate them and forwards them on prefix.

   o  Disallow traffic where the destination IPv6 address is not a
      global address; in particular, e.g. link-local addresses, mapped
      addresses and such should not be used.

   o  Disallow traffic transmission to other 6to4 domains through 6to4
      relay router or via some third party 6to4 router.

   o  Discard traffic received from other 6to4 domains via a 6to4 relay
      router.

   o  Discard traffic received for prefixes other than self 6to4
      prefix(es).

3.2 6to4 Relay Routers

   The 6to4 relay router acts as a relay between all 6to4 domains and
   native IPv6 networks; more specifically:

   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
      IPv4 "6to4 relay anycast prefix" (192.88.99.0/24) to IPv4 routing,
      thus receiving some tunneled traffic to native IPv6 nodes from
      6to4 routers.

   o  Decapsulate, and forward packets received from 6to4 addresses
      through tunneling, using normal IPv6 routing
              - if routing.

   o  Tunnels packets are received through normal IPv6 routing from native
      addresses, and are destined for 2002::/16, tunnel
                them to the corresponding
      6to4 Router

3.2. Non-functions of Different router.

   The 6to4 Network Components

   What should not happen; this forms a basis for the relay will also perform security checks.
   The lists are not exhaustive.

     o checks on traffic that it
   will receive from 6to4 Router routers, or Relay
         - use from native IPv6 nodes.  These
   checks are:

   o  Disallow traffic that has private, broadcast or reserved IPv4
      addresses in tunnels, or the matching 6to4 prefixes
         - receive prefixes.

   o  Disallow traffic from 6to4 Routers routers where the IPv4 tunnel source
      address does not match the 6to4 prefix
         - receive prefix.

   o  Disallow traffic where the destination IPv6 address is not a
      global address; in particular, e.g. link-local addresses, mapped
      addresses and such should not be used
     o used. Note, this check might be
      incorrect if 6to4 Router
         - send traffic were to other 6to4 domains through 6to4 Relay Router
           or via some third party 6to4 Router
         - receive be used.

   o  Discard traffic received from other 6to4 domains via a 6to4 Relay
           Router
         - receive traffic to other than to your own 6to4 prefix(es)
     o routers with the destination as
      a 6to4 Relay Router
         - receive traffic from prefix.

4. Threat Analysis

   This section discusses attacks against the 6to4 to network or attacks
   that are caused by the 6to4

4. Special Processing network.  The threats are discussed in
   light of the 6to4 Packets

   One could summarize deployment models defined in the special processing Section 2.

   There are three general types of 6to4 as follows:

     o Relay Router threats:

   1. incoming from native, tunneled to 6to4  Denial-of-Service (DoS) attacks, in which a malicious node
       prevents communication between the node under attack and other
       nodes.

   2. tunneled from 6to4, going  Reflection Denial-of-Service (DoS) attacks, in which a malicious
       node reflects the traffic off unsuspecting nodes to native

     o Router
          1. tunneled from relay, source a particular
       node (node under attack) with the intent of preventing
       communication between the node under attack and other nodes.

   3.  Service theft, in which a malicious node/site/operator may make
       unauthorized use of service.

   6to4 also provides a means for a "meta-threat", traffic laundering,
   in which some other attack is native
          2. tunneled channeled through the third parties to relay, destination is native
          3. tunneled directly, destination
   make it more difficult to trace the real origin of the attack.  This
   is used in conjunction with other threats, whether specific to 6to4

4.1. Encapsulating IPv6 Packets into IPv4

   IPv6 packets
   or not.

   At this point it is important to reiterate that the attacks are encapsulated into IPv4 in three scenarios:
   possible because:

   1.  6to4 Router sends packets routers have to consider all 6to4 relays, and other 6to4 Routers (2002::/16
         destination)
       routers as "on-link".

   2.  6to4 Router sends packets relays have to its configured/nearest-by-anycast consider all 6to4 Relay Router (non-2002::/16 destination) routers as "on-link".

   3.  Partial implementation of the security checks in the 6to4 Relay Router sends packets from native IPv6 sources to
         6to4 Routers (2002::/16 destination)

4.2. Decapsulating IPv4 Packets into IPv6

   IPv6 packets are decapsulated from IPv4 in three scenarios:

      1. 6to4 Router receives packets from other 6to4 Routers (2002::/16
         source)
      2. 6to4 Router receives packets from
       implementation.  It has been discovered that at least a node, supposedly 6to4 Relay
         Router closest to the source (non-2002::/16 source)
      3. 6to4 Relay Router receives packets from 6to4 Routers, to be
         sent to native IPv6 destinations (2002::/16 source)

5. Threat Analysis

   The 6to4 threat analysis presented here focuses on 6to4 couple of
       major implementations which have implemented most if do not implement all security
   checks listed in [6TO4]; in particular, checks that always match
   2002:V4ADDR and V4ADDR must be implemented.  Many implementations are
   known to be problematic at least in some cases. the checks.

   The appendix lists some additional trivial threats which attacks descriptions are
   applicable if no or only little security is implemented.

   The classified based on the target of the
   attack:

   1.  Attacks on 6to4 networks.

   2.  Attacks on IPv6 networks.

   3.  Attacks on IPv4 networks.

   Note, the IPv4 address blocks 8.0.0.0/24 and 9.0.0.0/24 are only used
   for demonstrative purposes, representing and represent global IPv4 addresses.

5.1. Threats Related to Any 6to4 Node

   Any 6to4 node can be made to participate in a DoS attack

   Note, one of the mitigation methods listed in
   5.2.2 below, being used as "dst".  The threat for various attacks is
   based on the premise that 6to4 relays will a have a feature that may
   be discussed
   there.

5.2. Threats Related able to limit traffic to/from specific 6to4 Routers

   Note that in sites.  At the time of
   writing this memo, document, such a loose interpretation of "6to4 router" is
   used; it feature is used speculation, and more work
   needs to refer be done to those all nodes which have determine the 6to4
   pseudo-interface.

   There are two main classes logistics of threats; such a feature.

4.1 Attacks on 6to4 Networks

   This section describes attacks against the 6to4
   pseudo-interface and attacks relying on being able to abuse networks.  Attacks which
   legerate 6to4 networks, but where the fact
   that it ultimate victim is difficult for elsewhere
   (e.g., a native IPv6 user, an IPv4 user) are described later in the
   memo.

   6to4 relays and routers are IPv4 nodes, and there is no way for any
   6to4 router to tell confirm the identity of the IPv4 node from which it is
   receiving traffic -- whether packets it is a legitimate 6to4 relay or some
   other node.  A 6to4 router has to process traffic from
   non-6to4 all IPv4
   nodes.  Malicious IPv4 nodes come can exploit this property and attack
   nodes within the 6to4 network.

   It is possible to conduct a variety of attacks on the 6to4 nodes.
   These attacks are:

   1.  Attacks with Neighbor Discovery (ND) Messages

   2.  Spoofing traffic to 6to4 nodes

   3.  Reflecting traffic from legitimate relays.

5.2.1. 6to4 nodes

   4.  Local IPv4 broadcast attack

4.1.1 Attacks Against with ND Messages

   ATTACK DESCRIPTION

   Since the 6to4 Pseudo-Interface

   Unless router assumes all the other 6to4 pseudo-interface has been sufficiently protected,
   it's routers, and 6to4
   relays are "on-link" it is possible to remotely attack the pseudo-interface with tunneled 6to4 router using
   ND messages from any node in the IPv4 network, unless a prior trust
   relationship has been established.

   The attacks are targeting the 6to4 pseudo-interface.  As long as the
   6to4 addresses are not used in the source or destination address, the
   security checks specified by 6to4 take no stance on these packets.
   Typically these use link-local packets, addresses.

   These attacks are exacerbated in case the implementation supports
   more tunneling mechanisms than just as if 6to4 (or configured tunneling),
   because it were in a local network.  Threats is impossible to disambiguate such mechanisms, making it
   difficult to enable strict security checks (see Section 6.1).

   The Neighbor Discovery threats (Redirect DoS, or DoS) are listed described
   in [SEND].

   The potential effects of an attack can [7].  Note that all attacks may not be mitigated if applicable, as the interface 6to4
   pseudo-interface is insulated from assumed not to have a link-layer address (Section
   3.8 RFC 2893 [4]).  However, one should note that the other interfaces (e.g. 6to4 router can
   be either a separate neighbor
   cache).  In practise, this is not router or host from the case. Neighbor Discovery perspective.

   THREAT ANALYSIS AND MITIGATION METHODS

   The attack attacks can be eliminated mitigated by restricting using any of the use following methods:

   o  The usage of ND messages could be prohibited.  It implies that all
      packets using addresses of 6to4 pseudo-
   interface: if any packet with scope smaller than global is received,
   it must link-local will be silently
      discarded.  ("Local addresses", if specified,
   might be allowed in some restricted scenarios.)  This may conflict
   with  Section 3.1 of RFC 3056 [1] leaves scope for future
      uses of [6TO4, 3.1].

5.2.1.1. Comparison link-local address.  This method has its pitfalls - it
      would prohibit any sort of ND message, and thus close the doors on
      development, and use of other ND options.  Whether this is a
      significant problem is another thing.

   o  The 6to4 pseudo-interface could be insulated from the other
      interfaces (for example, using a separate neighbor cache).

   o  Either IPsec [4] or an extension of SEND could be used [8] to Situation without
      secure packet exchange using link-local address; vanilla SEND
      would not work as the link-layer does not have an address -- and
      IPsec would be rather complex.

   COMPARISON TO SITUATION WITHOUT 6to4

   Even though rather simply fixable, this attack is not new as such;
   the same is possible using automatic tunneling [MECH] [4] or configured
   tunneling (if one is able to spoof source IPv4 address to that of the
   tunnel end-point).

   However, as 6to4 provides open decapsulation, and automatic tunneling
   is being deprecated, the worst
   problem comes from 6to4; any open decapsulation is bad.

5.2.2. Relay Spoofing, DoS against IPv6 Nodes deprecated [9], 6to4 Routers receive packets from non-6to4 source addresses through
   Relay Routers, as described in section 2.2 and 4.2 point 2.

   In the general case, the provides an easy means which would not
   exist without 6to4.

4.1.2 Spoofing Traffic to 6to4 router cannot distinguish Relay routers
   from Nodes

   ATTACK DESCRIPTION

   The attacker - a malicious nodes sending IPv4-encapsulated IPv4 or IPv6 traffic directly
   to the 6to4 router.

   This makes two kinds of attacks possible:

     o unidirectional node - can send packets with
   spoofed source address spoofing, and
     o Denial-of-Service attack reflection against native to a 6to4 node to accomplish a DoS attack.

   The IPv6 nodes.

   In both scenarios, and IPv4 addresses of the attacker sends IPv4-encapsulated IPv6 packets
   to the 6to4 router with contents like:

        src will be similar to:

   src_v6 = 3ffe:1122:3344::1 (forged)
        dst 2001:db8::1       (forged address)
   dst_v6 = 2002:0900:0002::1 (valid address)
   src_v4 = 8.0.0.1           (valid or forged address)
   dst_v4 = 9.0.0.2 (matching dst)

   Now the 6to4 router receives these packets           (valid address, matches dst_v6)

   For attacks launched from 8.0.0.1, a native IPv6 node, the src_v4 will be the
   address of the relay through which the traffic will reach the 6to4
   node.  From IPv4 nodes, src_v4 can be either a spoofed or the real
   source address.

   The 6to4 router receives these packets from 8.0.0.1, decapsulates
   them, discarding discards the IPv4 header containing the source address 8.0.0.1
   and processes them as normal ("dst" (the attacker has been guessed or obtained
   "dst_v6" using one of a number of techniques).

   In the first scenario, it is assumed that "src" is somehow specially
   trusted (at least to some extent) more than some other packets.

   This
   kind of weak trust based on IP addresses is commonplace. a DoS attack on 6to4 nodes.

   This
   enables unidirectional (as attack is similar to ones shown in [10].

   EXTENSIONS

   Replies to the replies traffic will be lost) source address
   spoofing, but may be enough for e.g. exploiting some remote
   vulnerabilities in connectionless protocol server applications.

   In directed to the second scenario, if "dst" exists, src_v6 address,
   resulting in 6to4 nodes in participating in a reflection DoS. This
   attack is described in more detail in Section 4.2.3.  That is, the
   replies (e.g. (e.g., TCP SYN ACK, TCP RST, ICMP ICMPv6 Echo Reply, input sent to
   UDP echo service, ICMPv6 Destination Unreachable, etc.) are sent to
   the victim "src", (src_v6), above. All the traces from the original attacker src_v4
   (src_v4) have been discarded.  These return packets will go through a
   relay.

   These attacks are similar to ones shown in [RHHASEC].

5.2.2.1. Comparison to Situation without 6to4

   The unidirectional spoofing attack exists without

   Certain 6to4 too, but networks may have a trivial ACL (Access Control List)
   based firewall that allows traffic to pass through if it
   requires comes from
   particular source(s). Such a firewalling mechanism can be bypassed by
   address spoofing.  This attack can therefore be used for trivial ACL
   avoidance as well. These attacks might be hampered by the attacker is able to spoof IPv6 source addresses.  With
   6to4, one is able fact that
   the replies from the 6to4 node to launch this the spoofed address will be lost.

   THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS

   The Denial-of-Service attack without any based on traffic spoofing at all.
   A restriction is not new;
   the only twists come from the fact that traces of an attack are more
   easily lost, and that spoofing the source IPv6 address cannot be spoofed is possible even to belong
   those who are unable to the destination site as only non-6to4 do so in their current networks.  The 6to4
   router typically does not log IPv4 addresses can (as they would be spoofed
   (assuming correct implementations).  Blindly trusting
   treated as L2 addresses) and thus the source address of packets coming from the Internet without other precautions is very
   bad practise, though -- and this attack would typically be useful
   only for spoofing destination site -- which is not possible, and can
   be protected against with egress filtering.

   The Denial-of-Service attack is also not really new; the only twists
   come (if
   launched from the fact that traces of an attack are more easily lost and
   that attacker does not really have to even spoof his IPv4 address to
   be able node) is lost. Since traces to reasonably discreetly launch the attack.

   However, it src_v4
   address can easily be argued that this DoS attack is not critical
   because:

     o 6to4 as an enabling mechanism does not provide any possibility
       for packet multiplication, attacks are generally 1:1,
     o victim receives packets as replies from "dst": unless echo
       service (e.g. UDP port 7) is used, the attacker has reasonably
       little control on the content of packets; for example, pure "SYN"
       TCP packets often used for flooding cannot be sent,
     o attack packets pass through choke point(s), namely (one or more)
       6to4 relays; in addition to physical limitations, lost, these could
       implement some form 6to4-site-specific traffic limiting, and
     o one has to know a valid destination address (however, this is
       easily guessable or deducible with e.g. an ICMP echo request with
       a limited Hop Count).

   The attack attacks can also be be launched
   from hosts IPv4 nodes whose connection is ingress-
   filtered, too.  So, this enables a way to launch attacks which hide
   the source address even when it was supposed to be prevented (for
   IPv4). ingress-filtered.

   However, often this is not a real factor, as usually the attackers
   are just zombies and real attackers may not even care if the
   unspoofed source address is discovered.

   This is one of

   Malicious native IPv6 nodes could be caught easily if ingress
   filtering was enabled everywhere in the most serious threats.

5.3. Threats Related IPv6 Internet.

   These attacks are easy to 6to4 Relays

   6to4 Relays are also subject to attacks, perform, but usually in a different
   role than 6to4 Routers; usually Relays' function is the anonymization extent of the attack and losing trails, not reflection -- as properly
   implemented relays should be resistant to reflection.

   6to4 Relays have only harm is limited:

   o  For every packet sent, at most one significant security check they must
   perform for general safety: when decapsulating IPv4 packets, check
   that 2002:V4ADDR and V4ADDR match.  If this reply packet is not done, several
   threats become more serious; in the following, it's assumed that such
   checks are always done.

   Also, it generated:
      there is assumed here that the Relay checks that it will not relay
   packets between 6to4 addresses.  In particular, packets decapsulated no amplification factor.

   o  Attack packets, if initiated from an IPv6 node, will pass through
      choke point(s), namely a 6to4 routers cannot be encapsulated again towards 6to4 routers,
   as descibed in rules relay; in section 6.  It is not clear whether this kind addition to physical
      limitations, these could implement some form of check is typically implemented.

5.3.1. Attacks Against 6to4-site-specific
      traffic limiting.

   On the 6to4 Pseudo-Interface other hand, a variety of factors can make the attack serious:

   o  The threats are attacker may have the same as against 6to4 routers.

5.3.2. Spoofing, DoS against IPv6 Nodes

   If one cannot assume that IPv6 source addresses are ingress-filtered, ability to choose the same threats relay, and he
      might employ the ones best suited for the attacks. Also, some
      relays use 192.88.99.1 [3] as listed in 5.2.2 apply. the source address making tracing
      even more difficult.

   o  The difference here is that relay's IPv4 address may be used as a native IPv6 node spoofs the source IPv6
   addresses, and the relay router provides address for these
      attacks, potentially causing a layer lot of indirection and
   loses complaints or other actions
      as the trails.

5.3.3. Participating in DoS attacks against IPv4

   An attack specific to 6to4 Relays is similar relay might seem to 6to4 Routers, but
   against IPv4; be the attacker sends IPv6-native source of the attack (see
      Section 4.2.6 for more).

   Some of the mitigation methods for such attacks are:

   1.  Ingress filtering in the native IPv6 networks to prevent packets
       with an IPv4
   address he wants spoofed IPv6 source being transmitted.  It would, thus, make
       it easy to bomb as identify the 6to4 destination address, like:

        src = 3ffe:1122:3344::1 (spoofed or real attacker)
        dst = 2002:0900:0002::1 (victim)

   Now source of the attack.

   2.  Security checks in the 6to4 relay.  The 6to4 relay receives must drop
       traffic (from the IPv6 internet) that has 6to4 addresses as
       source address, see Section 5 for more.

   However, these packets, mitigation methods do not address the case of IPv4
   node sending encapsulated IPv6 packets.

   There exists no simple way to prevent such attacks, and encapsulates longer term
   solutions like ingress filtering [11] or itrace [12] have to be
   deployed in both IPv6 and IPv4
   packets that are sent towards 9.0.0.2; networks to help identify the destination may not have a
   faintest idea source
   of what IPv6 is, but is bombed with packets coming from the relay's attacks.

   COMPARISON TO SITUATION WITHOUT 6to4

   Traffic spoofing is not a new phenomenon in IPv4 address, including or IPv6. 6to4 just
   makes it easier: anyone can, regardless of ingress filtering, spoof a
   native IPv6 packets as the payload.

5.3.3.1. Comparison address to Situation without a 6to4

   Slightly different arguments apply; below are reasons why node, even if "maximal security" would
   be implemented and deployed.  Losing trails is also easier.

   Therefore, depending on how much one assumes ingress filtering is
   deployed for IPv4 and IPv6, this can could be considered not too to be a very
   serious an attack:

     o issue, or close to irrelevant compared to the IP spoofing
   capabilities without 6to4.

4.1.3 Reflecting Traffic to 6to4 as an enabling mechanism does not provide any possibility
       for packet multiplication, attacks are generally 1:1,
     o victim receives packets as sent by Nodes

   ATTACK DESCRIPTION

   Spoofed traffic (as described in the source; if Section 4.2.2) may be sent to
   native IPv6 nodes with the victim is
       an IPv4-only node, it just sees "protocol 41" packets which are
       not typically dangerous and easily filtered,
     o aim of performing a reflection attack
   against 6to4 relay's source IPv4 address is used in packets, and tracing nodes.

   The spoofed traffic is easier,
     o source sent to a native IPv6 address (spoofed node, either from an
   IPv4 node (through a 6to4 relay), or real) is in from a native IPv6 node (unless
   ingress filtering has been deployed).  With the former, the sent
   packets which may
       make manual tracing easier, and
     o would look like:

   src_v6 = 2002:1234:1234::1 (forged address of the target 6to4 node)
   dst_v6 = 2002:0900:0002::1 (valid address)
   src_v4 = 8.0.0.1           (valid or invalid address)
   dst_v4 = 9.0.0.2           (valid address, matches dst_v6)

   One should note that an attack packets pass through choke point(s), namely (one or more)
       6to4 relays; in addition to physical limitations, these could
       implement some form 6to4-site-specific traffic limiting.

   And as counter-arguments, some more serious aspects of it are:

     o victim receives packets as sent by the source; relay is prevented if the victim is
       6to4 node, IPv6 packet
   relay implements proper decapsulation security checks (see Section 5
   for details) unless the IPv4 node can include almost anything; however if
       IPv6 spoof the source addess is not spoofed, this attack is nothing new,
     o address to
   match src_v6.  Similarly, the relays attack from native IPv6 nodes could be
   prevented by global ingress filtering deployment.

   These attacks can be chosen initiated by the attacker, so native IPv6, IPv4, or 6to4 nodes.

   EXTENSIONS

   A distributed Reflection DoS can be performed if there are a large number of relays, he can pick ones that nodes
   are known best suited for involved in sending spoofed traffic with the same src_v6.

   Malicious 6to4 nodes can also (try to) initiate this attack (e.g. bad security policy, ones using 192.88.99.1 by
   bouncing traffic off 6to4 nodes in other 6to4 sites. However this
   attack may not be possible as
       source for more difficult tracing, etc.), and
     o the relay's IPv4 address is used as a source address for these
       attacks, potentially causing a lot of complaints or other actions
       as 6to4 router (in the relay seems to be site from which
   the source of this "attack".

5.3.4. Using Any IPv6 Node for Reflection

   Any IPv6 node attack is being launched) will respond to IPv6 filter packets destined to the node with forged source
   address belonging to 2002::/16.

   This (with security checks mentioned in Section 5), and thus the
   attack is applicable if:

     o will be prevented.

   THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS

   The reverse traffic in this case are replies to the relay chosen messages received
   by the attacker does not check that IPv4 source
       and 2002::/16 source address match, or
     o the attacker's IPv6 connection is not ingress-filtered (and it
       was really a non-6to4 source). 6to4 nodes.  The IPv6 source address being forged, attacker has less control on the node will participate as an
   unwilling intermediary to an attack through packet type
   in this case, and this would inhibit certain types of attacks.  For
   example, flooding a 6to4 relay against any
   IPv4 node (or 6to4 node), like:

        src = 2002:0900:0002::1 (forged, target of the attack)
        dst = 3ffe:1122:3344::1 (intermediary node)

   This is not new: similar attack with any other spoofed source address
   is TCP SYN packets will not be
   possible if (but e.g., a SYN-ACK or RST would be).

   These attacks may be countered in various ways:

   o  Implementation of ingress filtering is not enabled.  The only difference
   here is that when attacking IPv4 nodes, by the relay's IPv4 source
   address is seen as the immediate source service providers.
      It would prevent forging of the attack.  Closer
   inspection (after packet reflection) reveals src_v4 address, and would help in
      closing down on the IPv6 datagram with
   (possibly spoofed) 2002::/16 destination address.

5.3.4.1. Comparison culprit IPv4 nodes.  Note that, it will be
      difficult to Situation without 6to4

   This shut down the attack is if a reflected variation large number of IPv4 nodes
      are involved.

      These attacks may be also be stopped at the attack above; 6to4 sites if the
   implications are similar to those in section 5.2.2.1:

     o A non-compliant 6to4 implementation or IPv6 source
      culprit src_v4 address
       spoofing is required,
     o 6to4 as an enabling mechanism does not provide any possibility
       for packet multiplication, attacks are generally 1:1,
     o victim receives packets as replies from "dst": unless echo
       service (e.g. UDP port 7) identified, and if it is used, the attacker has reasonably
       little control on the content of packets; for example, pure "SYN"
       TCP packets often used for flooding cannot constant, by
      filtering traffic from this address. Note that it would be sent,
     o attack packets pass through choke point(s), namely (one or more)
       6to4 relays; in addition
      difficult to physical limitations, these could implement some form 6to4-site-specific traffic limiting, and
     o the relay's IPv4 address this method, if appropriate logging is used as a source address for these
       attacks, potentially causing not
      done by the 6to4 router, or if a lot large number of complaints 6to4 nodes, and/
      or other actions
       as the relay seems to be the source a large number of this "attack".

5.3.5. IPv4 Local Directed Broadcast Attacks

   This threat is applicable if the relay does not check whether nodes are participating in the
   IPv4 address it tries to send encapsulated attack.

   o  Implementation of ingress filtering by all IPv6 packets to is a local
   broadcast address.  This threat is mentioned in [6TO4].  The packet service providers
      would eliminate this attack, because src_v6 could not be sent as follows:

        src = 3ffe:ffff:5678::aaaa (may spoofed
      to be forged)
        dst = 2002:0900:00ff::bbbb

   9.0.0.255 is assumed the the relay's broadcast a 6to4 address.  After
   receiving the packet natively, if the relay doesn't check the
   destination address for subnet broadcast, it would send the
   encapsulated IP-IP packet  However, expecting this to 9.0.0.255.  This would happen may not
      be received by
   all nodes in practical.

   o  Proper implementation of security checks (see Section 5) both at
      the subnet, 6to4 relays and the responses routers would be directed to eliminate the
   relay.

5.3.5.1. Comparison to Situation without 6to4

   This is a special form of "directed broadcast" attack which cannot be
   protected against attack, when
      launched from an IPv4 node, except by when the mentioned check.  However, there is a
   significant difference: IPv4 source address
      was also spoofed -- but then the reply packets are sent back attacker would have been able to
      just attack the relay.
   Therefore only the non-compliant device can suffer from this; ultimate destination directly.

   o  Rate limiting traffic at the
   rest 6to4 relays.  In a scenario where
      most of the Internet cannot be affected.

5.3.6. Theft of Service

   The administrators of traffic is passing through few 6to4 Relay Routers often want to use some
   policy to limit relays, these
      relays can implement traffic rate-limiting features, and
      rate-limit the use of relay.

   The policy control is usually done traffic from 6to4 sites

   COMPARISON TO SITUATION WITHOUT 6to4

   This particular attack can be mitigated by applying some restrictions in proper implementation of
   security checks and ingress filtering; where the routing information for 2002::/16 and/or 192.88.99.0/24 (if
   [6TO4ANY] ingress filtering is used) will spread.

   Some users may be able not
   implemented, it's typically easier to use attack directly than through
   reflection -- unless "traffic laundering" is an explicit goal in the service regardless of these
   controls using:

     o configuring
   attack.  Therefore, this attack does not seem very serious.

4.1.4 Local IPv4 Broadcast Attack

   ATTACK DESCRIPTION

   This threat is applicable if the address of 6to4 router does not check whether
   the relay using its IPv4 address
       instead of 192.88.99.1, or
     o using Routing Header it tries to route send encapsulated IPv6 packets to reach some 6to4
       Relay (some other routing tricks like neighbors setting static
       routes are also possible).

   The former can be protected against using configured access lists in
   the relay; this a
   local broadcast address, or a multicast address.  This threat is only feasible if
   mentioned in the number specification [1].

   There practically two kinds of IP networks the
   relay is supposed attacks: where a local 6to4 user tries
   to serve is relatively low.  Another possible way send packets to mitigate this the address corresponding to the broadcast
   address, or when someone is able to filter out arriving tunneled packets with
   protocol 41 (IPv6) which do not have the that remotely.

   In the 192.88.99.1 as first option, assume that 9.0.0.255 is the
   destination 6to4 router's
   broadcast address.

   The latter has similar issues:  After receiving the IPv6 source packet with a destionation
   address could be
   checked so like "2002:0900:00ff::bbbb" from a local 6to4 node, if the packets to
   router doesn't check the relay only come from destination address for subnet broadcast, it
   would send the valid IPv6
   addresses which are able encapsulated protocol-41 packet to reach 9.0.0.255.   This
   would be received by all nodes in the relay anyway.  As Routing
   Header is not specific to 6to4, subnet, and the main things one could do here
   with it responses would
   be directed to select the relay; some generic threats about
   Routing Header use are described 6to4 router.

   Malicious sites may also embed forged 6to4 addresses in [RHHASEC].

   Of these, except the DNS, use
   of which by a 6to4 node will result in really restricted scenarios, only a local broadcast by the first may 6to4
   router.  One way to perform this attack would be to send an HTML mail
   containing a link to an invalid URL (for example, http://
   [2002:0900:00ff::bbbb]/index.html) to all users in a 6to4 technology
   based network.  Opening of some interest, and the mitigating mail simultaneously would result in a
   broadcast storm.

   The second kind of attack is more complex: the problem attack can be
   initiated by access list is
   rather straightforward.

   As this threat does IPv4 nodes not have implications on other than belonging to the
   organization providing Relay, it is not further analysed.

5.3.7. Relay Operators Seen local network as Source of Abuse

   There are several attacks which use long as
   they can send traffic with invalid (for example 2002:0900:00ff::bbbb)
   source address. The 6to4 Relays router has to anonymize the
   traffic; this often results in packets being tunneled from the relay respond to a supposedly-6to4 site.

   However, as was already pointed out in sections 5.3.3 and 5.3.4, the
   IPv4 source address used traffic by
   sending ICMPv6 packets back to the relay could, cursorily looking, source, for example Hop Limit
   Exceeded or Destination Unreachable. The packet would be
   seen as the source follows:

   src_v6 = 2002:0800:00ff::bbbb (broadcast address of these "protocol-41" attacks. the router)
   dst_v6 = 2002:0800:0001::0001 (valid non-existent address)

   This could cause is a number of concerns for DoS attack.

   EXTENSIONS

   The attacks could also be directed at non-local broadcast addresses,
   but these would be so-called "IPv4 directed broadcasts", which have
   been (luckily enough) already been extensively blocked in the operators deploying
   6to4 relay service, for example:

     o getting contacted a lot (via email, phone, fax or lawyers)
   Internet.

   THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS

   The attack is based on
       suspected "abuse",
     o getting the whole IPv4 address range rejected as a source of
       abuse or spam, causing outage to other operations as well, or
     o causing premise that the whole IPv4 address range 6to4 router has to be send a
   packet to be blacklisted in
       some "spammer databases", if the relay would be used for those
       purposes.

   This problem can be avoided (or really, "made someone else's
   problem") an IPv6 address that embeds an invalid IPv4 address.  Such
   an attack is easily thwarted by using ensuring that the 6to4 anycast address in 192.88.99.0/24 as the
   source address: blacklisting or rejecting that router does
   not transmit packets to invalid IPv4 addresses.  Specifically traffic
   should not cause
   problems be sent to the other operations. Further, when someone broadcast or multicast IPv4 addresses.

   COMPARISON TO SITUATION WITHOUT 6to4

   The first threat is filing
   complaints similar to the owner of 192.88.99.0/24, they notice multiple
   records and see what's already possible with IPv4, but
   IPv6 does not have broadcast addresses.

   The second, a pointer more complex threat, is similarly also available in
   IPv4.

   In consequence, the security does not seem to [6TO4ANY], be significantly worse
   than with IPv4, and may learn even that the 6to4
   relay is in fact innocent.  Of course, this could result in these
   reports going restricted to the closest anycast site(s) with 6to4 relay as well,
   implementations which haven't been secured as described in
   fact had nothing to do with the incident.

5.4. Possible Threat Mitigation Methods Section 5.

4.2 Attacks on Native IPv6 Internet

   This section gives a rough idea of mechanisms thought to mitigate the
   threats.

5.4.1. describes attacks against native IPv6 Internet which
   leverage 6to4 Decapsulation Cache architecture somehow.  Attacks against 6to4 decapsulators (routers, relays) could keep a least recently used
   (LRU) header cache of possibly a few hundred entries of recently seen
   packets for tracing purposes.

   The problem here is how that kind of data could nodes were
   described in the previous section.

   Native IPv6 nodes can be extracted -- accessed by
   third parties that need it -- 6to4 and IPv4 nodes through the
   6to4 relay routers. Thus the 6to4 relays play a crucial role in timely fashion.  Many
   implementations are, of course, already able to any
   attack on native IPv6 nodes by IPv4 nodes or 6to4 nodes.

   6to4 relays have only one significant security check they must
   perform something
   like for general safety: when decapsulating IPv4 packets, check
   that 2002:V4ADDR::/48 and V4ADDR match.  If this by e.g. manually set logging access lists.

5.4.2. Rate-limiting at is not done, several
   threats become more serious; in the following analysis, it is assumed
   that such checks are implemented.

   6to4 Routers/Relays

   TBD.

5.4.3. An Application of iTrace Model relay should not relay packets between 6to4 decapsulators (or some of them) could send out some specific addresses. In
   particular, packets probabilitically as a way ensure that reflectors cannot decapsulated from 6to4 routers should not be
   used to lose trails of an attack.  This could either be a
   simplification or an extension of e.g. [ITRACE] model, depending on
   how fast its specification goes.

   The most important place for this would be at
   encapsulated again towards 6to4 Routers, to
   counter the reflection attack descibed routers, as described in 5.2.2.  If so, the check
   could be placed at the decapsulation phase where rules in
   Section 5. Similarly, packets have a with 6to4 source and destination
   address but the source sent from IPv6 nodes should not be relayed.  It is non-6to4.

   The iTrace working group has been concluded due to decreased
   applicability not clear
   whether this kind of the work. check is typically implemented.  The documents may move forward attacks
   described below assume that such checks are not implemented.

4.2.1 Attacks with ND Messages

   These attacks are the same as
   individual submissions.

5.5. Summary

   It would be useful to try employed against 6to4 routers as
   described in Section 4.1.1.

4.2.2 Spoofing Traffic to characterize the different threats by
   comparing the severity of the threat to:

      1. Native IPv6 node

   ATTACK DESCRIPTION

   The attacker - a malicious IPv4 networks today, where in many cases (even most), or 6to4 node - can send packets with
   spoofed (or not spoofed) 6to4 source address spoofing is possible and there are no easy ways to
         trace attacks

      2. Hypothetical IPv4 networks -- the case if ingress filtering
         would be deployed everywhere

      3. Hypothetical a native IPv6 networks -- node to
   accomplish a DoS attack.

   The threat is similar as the case if ingress filtering
         would be deployed everywhere one involving 6to4 routers as described
   in current and future Section 4.1.2.

   The difference here is that the attack is initiated by IPv4 nodes, or
   6to4 nodes.  The source IPv6
         networks

   However, this would address may or may not be very difficult spoofed. Note,
   as it mentioned above, the relay is not easy to assign
   severity values assumed to all correlate source IPv4
   address with the features 6to4 adds and try to decide
   whether it's more serious or not.

5.5.1. Summary of the Threats

   Below is the summary of the threats discussed above.  Threat address embedded in 5.1
   was merged with 5.2.2 as the effects are source IPv6 address during
   decapsulation. A side effect is that all the same but from spoofed traffic will
   have a
   different perspective.

        +----+-----+--------------------+-------+-------+---+---+----+
        |Type| Sec | Characterization   | Using |Against|Fix|I-F|Comp|
        +----+-----+--------------------+-------+-------+---+---+----+
        |Othr|5.2.1|Pseudo-Interface    |Rtr/Rly|itself |yes|N/A| 3  |
        |Othr|5.3.5|Local Direct. Bcast |Rly    |itself |yes|N/A| 3  |
        |Othr|5.3.6|Theft of Service    |Rly    |itself |yes|N/A| -  |
        |Othr|5.3.7|Relay Seems to Abuse|Rly    |any v4 | ? | ? | -  |
        +----+-----+--------------------+-------+-------+---+---+----+
        |Spf |5.2.2|Relay Spoofing      |Rtr    |ownsite| y?| - |same|
        +----+-----+--------------------+-------+-------+---+---+----+
        |Dir |5.3.3|DoS against IPv4    |Rly    |any v4 | ? | 6 |1,2 |
        +----+-----+--------------------+-------+-------+---+---+----+
        |Refl|5.2.2|Refl. off any 6to4  |Rtr/Any|non6to4| ? | - | 2  |
        |Refl|5.3.2|Refl. off any 6to4  |R*/Any |non6to4| ? | 6 | 2  |
        |Refl|5.3.4|Refl. off any source address.

   EXTENSIONS

   Spoofed traffic may also be sent to native IPv6  |Rly/Any|any v4 |1/2|4+6|1,2 |
        +----+-----+--------------------+-------+-------+---+---+----+

   The table is sorted by threat type.  Possibilities are spoofing,
   direct attack, attack nodes by reflection (ie. final attack consists of
   some response packets) and other.

   Threats when realize (ab)use some IPv6 nodes: possibilities are either other
   native IPv6 nodes, or 6to4 Routers (Rtr), 6to4 Relays (Rly) nodes, or any malicious IPv4 nodes to conduct
   Reflection DoS on either native IPv6 nodes or any 6to4 nodes (Any).  "R*" means nodes.

   Certain native IPv6 networks may have a trivial ACL (Access Control
   List) based firewall that both Relays and Routers are used.

   The final target of the attack is descibed in "Against"; allows traffic to pass through if it comes
   from particular source(s). Such a firewalling mechanism can be
   node(s) or network itself,
   bypassed by address spoofing.  This attack can therefore be used for
   trivial ACL avoidance as well. These attacks might be hampered by the site itself which could prevent
   fact that the
   attack, any IPv4 node or any non-6to4 IPv6 node (non6to4).

   If a fix for replies from the problem is apparent, it is mentioned in 6to4 node to the Fix
   field.

   If it can spoofed address will
   be assumed that either complete Internet-wide IPv4 or IPv6
   ingress filtering would (more or less) fix or significantly alleviate lost.

   THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS

   The Denial-of-Service attack based on traffic spoofing is not new;
   the problem, only twist comes from the fixing version fact that traces of ingress filtering is noted in I-F
   column. an attack are more
   easily lost.  The notable case is 5.3.4 where both v4/v6 ingress filtering
   is needed -- but if 6to4 relay typically does not log IPv4 addresses
   (as they would be treated as L2 addresses) and thus the half source of the readily-available fix is done,
   IPv6 ingress filtering is enough.  The other notable case
   attack (if launched from an IPv4 node) is threat
   5.2.2, which cannot be disabled by ingress filtering.

   The last field "Comp" tries lost. Since traces to compare the threats to their IPv4
   equivalents, using:
      1. cannot control packets significantly, ie. a weak attack,
      2.
   src_v4 address can easily be mitigated significantly by adding some kind of tracing,
         or
      3. some new form of attack.

5.5.2. Generic Notes about Threats

   Note: TBD.

     o correct lost, these attacks can also be be
   launched from IPv4 nodes whose connection is ingress-filtered.

   These attacks might be not be very easy to perform, and fully-implemented base security features are a pre-
       requisite for reasonably safe operation, might be
   hampered because of:

   o being able to spoof IPv4 or IPv6 packets enables one  It might be difficult to launch
       similar or more powerful such attacks from 6to4 nodes
      because even currently,
     o some if the 6to4 attacks provide an additional layer routers allow spoofing of indirection,
       which may or may not be useful,
     o the source IPv6
      address, the 6to4 as an enabling mechanism does not provide any possibility
       for packet multiplication which relay would affect global Internet,
       attacks are generally 1:1,
     o typically the reflected packets have restricted content, limiting check if source V4ADDR is same as
      the usability one embedded in an attack,
     o attacks typically have either the source IPv6 address.  Thus, 6to4 relay router's address or some
       other information which could nodes
      will be used in manual tracing, forced to use the correct IPv6 prefix while lauching
      attack, and it is easy to close such attacks.

   o attack packets  Packets may pass through choke point(s), namely (one or more) a 6to4 relays; in addition relay.  In
      addition to physical limitations, these there could
       implement be some form 6to4-site-specific traffic limiting,
     o the relay's IPv4 address is often used as a source address for
       these attacks, potentially causing a lot sort of complaints or other
       actions as the relay seems to
      traffic rate limiting mechanisms which may be the source of this "attack", implemented, and
     o attacks it
      could in theory be traceable using an extension tone down the attack.

   o  For every packet sent, at most one reply packet is generated:
      there is no amplification factor.

   Some of
       [ITRACE] or [REVITRACE], but as those haven't been specified,
       much less used, the point seems rather academic yet.

   When considering motives mitigation methods for DoS such attacks and how are:

   1.  Ingress filtering in the IPv4 Internet to protect against
   them (and considering prevent packets with
       spoofed IPv4 source being transmitted.  As the cost, and whether relay checks that
       the protection actually
   buys you anything), 6to4 address embeds the following should not IPv4 address, no spoofing can be forgotten:

     o
       achieved done unless IPv4 and IPv6 ingress filtering are not likely to addresses can be commonplace
       for a long time; until it is, you cannot really depend on it,
     o spoofed.

   2.  Security checks in the real attacker (launching a DoS 6to4 relay.  The 6to4 relay must drop
       traffic (from 6to4 nodes, or DDoS) may IPv4 nodes) that has non-6to4
       addresses as source address, or where the source IPv4 address
       does not really even
       care whether some zombie nodes get found out,
     o techniques to trace DoS attacks are still match the address embebdded in infancy (or not even
       there) yet; due to time anything takes the source IPv6 address.

   COMPARISON TO SITUATION WITHOUT 6to4

   Compared to get deployed, it Section 4.1.2, which is not
       clear whether tracing mechanisms even for basic DoS attack
       mechanisms would get reasonably widely deployed before it was
       time to (more or less) retire 6to4, and
     o DoS attacks are something that, in practise, operational people
       have more serious, this threat appears
   to be able to deal with anyway.

6. Implementing Proper Security Checks in slightly more manageable.  If the relays perform proper
   decapsulation checks, the spoofing can only be achived, to a 6to4

   In this section, several ways
   source address, when IPv4 address is spoofable as well.

4.2.3 Reflecting Traffic to Native IPv6 nodes

   ATTACK DESCRIPTION

   These reflection attacks are similar to implement the security checks
   required one involving 6to4
   routers as described in Section 4.1.3.  Traffic may be reflected off
   native IPv6 nodes, or implied 6to4 nodes.  The attack can be initiated by [6TO4] or augmented
   either:

   o  Native IPv6 nodes.  These nodes can send invalid traffic with
      spoofed native IPv6 addresses to valid 6to4 nodes.  Replies from
      the 6to4 nodes are part of a reflection attack.

   o  IPv4 nodes.  These nodes can send traffic with native IPv6 source
      addresses (encapsulated by this specification the IPv4 node itself into a protocol-41
      packet) to 6to4 nodes. Replies from the 6to4 nodes are
   described. part of a
      reflection attack.

   o  6to4 nodes.  These do not, in general, protech against nodes can perform similar attacks to the majority ones
      by IPv4 nodes, but that would require spoofing of the threats listed above in source
      address at the threat analysis.  They're just
   prerequisites for 6to4 site before encapsulation; that is likely to
      be difficult.

   When launched from a relatively safe and simple native IPv6 node, the traffic goes through 6to4 implementation.

   Two different sets of rules are listed, "generic",
   relays twice, both after and "simplified".
   The former addresses before the required rules in reflection; when launched
   from a 6to4/IPv4 node, the generic form; traffic goes through a relay only after
   the
   latter simplifies them using reflection.

   EXTENSIONS

   A distributed Reflection DoS can be performed if a number large number of assumptions to
   increase the readability.

6.1. Generic Approach

6.1.1. Encapsulating
   native IPv6 into IPv4

    src and dst MUST pass ipv6-sanity checks, else drop (defined below)
    if src=2002
        src MUST match src_v4
            /* the scenario: 4.1. case 1. nodes or 2. */
        if dst=2002
            dst_v4 SHOULD NOT be assigned to IPv4/6to4 nodes are involved in sending spoofed
   traffic with the router (avoid misconfigurations)
                /* same source IPv6 address.

   THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS

   Some of the scenario: 4.1. case mitigation methods for such attacks are:

   1. */
        fi
    elif dst=2002
        dst_v4 MAY have to match one of ipv4 equiv. of 6to4 prefixes masked  Attacks from the native IPv6 nodes could be stopped by a
           user-specified prefix length (restricting who can use
       implementing ingress filtering in the relay)
            /* IPv6 Internet.

   2.  Two measures are needed to stop or mitigate the scenario: 4.1. case 3. */
    else
        drop
            /* attacks from IPv4
       nodes: 1) Implementing ingress filtering in the scenario: we somehow got a native-native ipv6 packet */
    fi
    accept

6.1.2. Decapsulating IPv4 into IPv6

    src_v4 and dst_v4 MUST pass ipv4-sanity checks, else drop (defined below)
    src internet,
       and dst MUST pass ipv6-sanity checks, else drop (defined below)
    if dst=2002
        dst MUST match dst_v4
            /* 2) logging IPv4 source address in the scenario: 4.2. case 1. or 2. */
            if src=2002
                src MUST match src_v4
                dst_v4 SHOULD 6to4 router.

   3.  Attacks from 6to4 nodes in other sites can be assigned to stopped if the 6to4
       router (see notes below)
                    /* in those sites implements egress filtering.

   4.  The traffic passes through one or two relays, and traffic rate
       limiting in the scenario: 4.2. case 1. */
            fi
    elif src=2002
        src MUST match src_v4
        dst_v4 SHOULD be assigned to 6to4 relays might help tone down the router (see notes below)
        src_v4 MAY have to match one of ipv4 equiv. of reflection
       attack.

   COMPARISON TO SITUATION WITHOUT 6to4 prefixes masked

   Even thought there are means to mitigate the attack, it is still
   rather efficient, especially when used by a
               user-specified prefix length (restricting who can use native IPv6 nodes with
   spoofed addresses.  Using 6to4 relays and routers could easily take
   down the relay)
            /* 6to4 relay system and/or provide an easy means for traffic
   laundering. However, if the scenario: 4.2. case 3. */
    else
        drop
            /* intent of the scenario: we somehow got a native-native ipv6 packet */
    fi
    accept

6.1.3. IPv4 attack is just to DoS the
   victim, it can be achieved more smoothly by doing it directly (as the
   source address spoofing was available as well).

   Therefore, the threat seems to be higher to the availability and
   stability of the 6to4 relay system itself than to native IPv6 Sanity Checks

6.1.3.1. IPv4
   Internet.

4.2.4 Local IPv4 address MUST be a global unicast address, as required by Broadcast Attack

   This attack is similar to the ones employed against 6to4 specification.  The disallowed addresses include those defined routers as
   described in [RFC1812], and others widely used and known not Section 4.1.4. There are slight differences with regard
   to the source of the attacks. This attack can be global.
   These are:

     o 0.0.0.0/8      (the system has no address assigned yet)
     o 10.0.0.0/8     (private)
     o 127.0.0.0/8    (loopback)
     o 172.16.0.0/12  (private)
     o 192.168.0.0/16 (private)
     o 169.254.0.0/16 (IANA Assigned DHCP link-local)
     o 224.0.0.0/4    (multicast) initiated by:

   o 255.0.0.0/8    (broadcast)

   In addition it MUST be checked  Native IPv6 nodes that may send traffic to the relay's subnet
      broadcast address.

   o  IPv4 nodes that may send traffic with spoofed source IP address is not any of
      (to be the
   system's relay's broadcast addresses.  This is especially important if address) to elicit replies (e.g.,
      ICMPv6 Hop Limit Exceeded messages) from the
   implementation 6to4 relay to its
      local nodes.

   The first is made so more dangerous than in Section 4.1.4 because it can be
   initiated by any IPv6 node (which is allowed to use the relay, that
   is), not limited to local users.

   The second is trickier and not really useful.  For it can:

     o receive to succeed, the
   relay would have to accept native source addresses over the 6to4
   pseudo-interface (but we did not assume this check was implemented),
   as if coming from another relay, and process encapsulated trigger an ICMPv6 message to the
   relay's local IPv4 packets arriving at its
       broadcast addresses, or
     o send encapsulated IPv4 packets subnet.  The former method is more lucrative.

   EXTENSIONS

   None.

   THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
   The threat is restricted to one the relay's local subnet, and is fixed by
   tightening the 6to4 security checks.

   COMPARISON TO SITUATION WITHOUT 6to4

   This scenario is caused by 6to4, but fortunately, the issue is not
   serious.

4.2.5 Theft of its broadcast addresses.

6.1.3.2. IPv6 Service

   ATTACK DESCRIPTION

   The 6to4 relay administrators would often want to use some policy to
   limit the use of the relay to specific 6to4 sites and/or specific
   IPv6 address MUST NOT be:
     o 0::/16    (compatible, mapped addresses, loopback, unspecified,
       ...)
     o fe80::/10 (link-local)
     o fec0::/10 (site-local)
     o ff02::/16 (link-local multicast)

   Other multicast could also be considered for filtering.

   In addition, it MUST be checked that equivalent 2002:V4ADDR checks,
   where V4ADDR sites.

   The policy control is any of usually done by applying restrictions to where
   the above IPv4 addresses, routing information for 2002::/16 and/or 192.188.99.0/24 (if the
   anycast address used [3]) will not spread.

   Some users may be passed.

6.1.3.3. Optional Ingress Filtering

   In addition, able to use the implementation may perform some form service regardless of ingress
   filtering (e.g. Unicast Reverse Path Forwarding checks).  For
   example, if these
   controls, by:

   o  Configuring the 6to4 Router has multiple interfaces, address of which some
   are "internal", receiving either the relay using its IPv4 address
      instead of 192.88.99.1, or

   o  Using the Routing header to route IPv6 packets with source
   address belonging to any of these internal networks from the Internet
   might reach specific
      6to4 relays.  (Some other routing tricks like using static routes
      may also be disallowed.

   If these checks are implemented, it is RECOMMENDED that they default used.)

   EXTENSIONS

   None.

   THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS

   Attempts to disabled.

6.1.3.4. Notes About use the Checks

   The rule 'dst_v4 SHOULD relay's IPv4 address instead of 192.88.99.1 can
   be assigned to mitigated in the router' is not needed if following ways:

   1.  IPv4 domains should prevent usage of the implementation is made actual IPv4 address of
       the relay instead of 192.88.99.1.

   2.  Usage of access lists in such a way that it the 6to4 relay to limit access.  This is
       only accepts and
   processes encapsulated IPv4 packets arriving on unicast IPv4
   addresses, and that feasible if destination address the number of IP networks the relay is known supposed
       to be a local
   broadcast address, serve is relatively low.

   3.  The 6to4 relay should filter out arriving tunneled packets with
       protocol 41 (IPv6) which do not try have the the 192.88.99.1 as the
       destination address.

   The other threat of using routing tricks in the IPv6 networks to encapsulate and send
   reach the 6to4 relay has similar solutions:

   1.  Usage of access lists in the relay to limit access.

   2.  Filtering out the packets with a routing header (may have other
       implications).

   3.  Monitoring the source addresses going through the relay, to it (see
   section 5.3.5 about this threat).

   Some checks, especially
       detect e.g. peers setting up static routes.

   Routing Header is not specific to 6to4, the IPv4/IPv6 Sanity Checks, main things one could be at
   least partially implementable do
   here with system-level access lists, if one it would like be to avoid placing too many restrictions in the 6to4
   implementation itself.  This depends on how many hooks for select the access
   lists relay; some generic threats about
   Routing Header use are described in place.  In practice it seems like [10].

   As this could threat does not be done
   effectively enough unless have implications on other than the access list mechanism
   organization providing 6to4 relay, it is able not analyzed any further.

   COMPARISON TO SITUATION WITHOUT 6to4

   These threats are specific to parse
   the encapsulated packets within IP-IP.

6.2. Simplified Approach 6to4 relays (or in general, anycast
   services), and do not exist in networks without 6to4.

4.2.6 Relay Operators Seen as Source of Abuse

   ATTACK DESCRIPTION

   There are several attacks which use 6to4 relays to anonymize the
   traffic; this often results in packets being tunneled from the relay
   to a supposedly-6to4 site.

   However, as was already pointed out in Section 4.2, the IPv4 source
   address used by the relay could, cursorily looking, be seen as the
   source of these "protocol-41" attacks.

   This could cause a number of concerns for the operators deploying
   6to4 relay service.  For example:

   o  Getting contacted a lot (via email, phone, fax, or lawyers) on
      suspected "abuse",

   o  Getting the whole IPv4 address range rejected as a source of abuse
      or spam, causing outage to other operations as well, or

   o  Causing the whole IPv4 address range to be to be blacklisted in
      some "spammer databases", if the relay would be used for those
      purposes.

   This threat seems slightly similar (but more generic) to the outburst
   of SMTP abuse caused by open relays.

   EXTENSIONS

   None.

   THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS

   This problem can be avoided (or really, "made someone else's
   problem") by using the 6to4 anycast address in 192.88.99.0/24 as the
   source address: blacklisting or rejecting that should not cause
   problems to the other operations.

   Further, when someone is filing complaints to the owner of
   192.88.99.0/24, they notice multiple WHOIS records and see a pointer
   to [3], and may learn that the 6to4 relay is in fact innocent.  Of
   course, this could result in these reports going to the closest
   anycast 6to4 relay as well, which in fact had nothing to do with the
   incident.

   However, the wide-spread usage of 192.88.99.1 as the source address
   may make it more difficult to disambiguate the relays, which might be
   a useful feature for debugging purposes.

   COMPARISON TO SITUATION WITHOUT 6to4

   This threat is caused by 6to4 deployment, but can be avoided, at
   least in the short-term, by using the use of 192.88.99.1 as the
   source address.

4.3 Attacks on IPv4 Internet

   There are two types of attacks on the IPv4 internet - spoofed
   traffic, and reflection. They can be initiated by native IPv6 nodes,
   6to4 nodes, and IPv4 nodes.

   Attacks initiated by IPv4 nodes that send spoofed traffic that will
   not utilize the 6to4 infrastructure are considered out of scope of
   this document. 6to4 infrastructure may be utilized in reflection
   attacks that are initiated by IPv4 nodes.

   It is difficult for these attacks to be effective as the traffic sent
   out will be IPv6-in-IPv4.  Such traffic will be rejected by most IPv4
   nodes unless they have implemented some sort of IPv6-in-IPv4
   tunneling.

   Such attacks can easily be thwarted by implementing protocol-41
   filtering in IPv4 nodes or sites that do not implement IPv6 over IPv4
   tunneling.  Such filters should not be made permanent, as they would
   act as a hurdle if IPv6 over IPv4 tunneling mechanisms were ever to
   be implemented by the IPv4 node or site.

   XXX: do these need to be spelled out, as in previous sections?

4.4 Summary of the Attacks

   Columns:

   o  Section number.  The section that describes the attack.

   o  Attack name.

   o  Initiator.  The node that initiates the attack.

      *  I_4 - IPv4 node

      *  I_6 - native IPv6 node

      *  6to4 - 6to4 node

      *  * - All of the above

   o  Victim.  The victim node

      *  I_4 - IPv4 node

      *  I_6 - native IPv6 node

      *  6to4 - 6to4 node

      *  Relay - 6to4 relay

      *  Router - 6to4 router

   o  ToA.  Type of Attack

      *  D - DoS

      *  R - Reflection DoS

      *  T - Theft of Service

   o  Fix.  Specified who is responsible for fixing the attack.

      *  6 - The 6to4 developer and/or operator can completely mitigate
         this attack.

      *  6* - The 6to4 developer and/or operator can partially mitigate
         this attack.

      *  E - This threat cannot be fixed by the 6to4 developer or the
         6to4 operator.

   Summary of attacks on a 6to4 network:

      +-------+----------------------+---------+----------+-----+-----+
      | Sec   | Attack name          |Initiator| Victim   | ToA | Fix |
      +-------+----------------------+---------+----------+-----+-----+
      | 4.1.1 | Attacks with ND      |  I_4    |  Router  |  D  |  6  |
      +-------+----------------------+---------+----------+-----+-----+
      | 4.1.2 | Spoofing Traffic     | I_4,I_6 |   6to4   |  D  |  E  |
      +-------+----------------------+---------+----------+-----+-----+
      | 4.1.3 | Reflection Attacks   |   *     |   6to4   |  R  |  6* |
      +-------+----------------------+---------+----------+-----+-----+
      | 4.1.4 | Local IPv4 Broadcast |   *     |  Router  |  D  |  6  |
      +-------+----------------------+---------+----------+-----+-----+

                                Figure 8

   Summary of attacks on the native IPv6 internet:

      +-------+----------------------+---------+----------+-----+-----+
      | Sec   | Attack name          |Initiator|  Victim  | ToA | Fix |
      +-------+----------------------+---------+----------+-----+-----+
      | 4.2.1 | Attacks with ND      |   I_4   |  Relay   |  D  |  6  |
      +-------+----------------------+---------+----------+-----+-----+
      | 4.2.2 | Spoofing Traffic     | I_4,6to4|    I_6   |  D  |  6* |
      +-------+----------------------+---------+----------+-----+-----+
      | 4.2.3 | Reflection Attacks   |    *    |    I_6   |  R  |  6* |
      +-------+----------------------+---------+----------+-----+-----+
      | 4.2.4 | Local IPv4 Broadcast |    *    |  Relay   |  D  |  6  |
      +-------+----------------------+---------+----------+-----+-----+
      | 4.2.5 | Theft of Service     |  6to4   |  Relay   |  T  |  6  |
      +-------+----------------------+---------+----------+-----+-----+
      | 4.2.6 | Relay Operators ...  |    -    |    -     |  D  |  1) |
      +-------+----------------------+---------+----------+-----+-----+

                                Figure 9

   Notes:

   1) This attack is a side-effect of the other attacks, and thus does
   not have any Initiator, Victim, and Fix. It is a Denial of Service
   attack not on the network but on the organization in-charge of the
   relay.

   Summary of attacks on IPv4 internet:

      +-------+----------------------+---------+----------+-----+-----+
      | Sec   | Attack name          |Initiator|  Victim  | ToA | Fix |
      +-------+----------------------+---------+----------+-----+-----+
      |  4.3  | Spoofing Traffic     |    *    |    I_4   |  D  |  6* |
      +-------+----------------------+---------+----------+-----+-----+
      |  4.3  | Reflection Attacks   |    *    |    I_4   |  R  |  6* |
      +-------+----------------------+---------+----------+-----+-----+

                               Figure 10

5. Implementing Proper Security Checks in 6to4

   In this section, several ways to implement the security checks
   required or implied by the specification [1] or augmented by this
   memo are described.  These do not, in general, protect against the
   majority of the threats listed above in the "Threat Analysis"
   section.  They're just prerequisites for a relatively safe and simple
   6to4 implementation.

   Note that in in general, the 6to4 router or relay does not know
   whether it is acting as a router or relay.  It would be possible to
   include a toggle to specify the behaviour, to be used e.g., when the
   interface is brought up, but at least in February 2004, no
   implementations were known to do that.  Due to that, the checks are
   described as one -- which works independent of whether the node is a
   router or relay.

5.1 Encapsulating IPv6 into IPv4

   The checks described in this section are to be performed when
   encapsulating IPv6 into IPv4.

    src_v6 and dst_v6 MUST pass ipv6-sanity checks (see below), else drop
    if prefix (src_v6) == 2002::/16
        ipv4 address embedded in src_v6 MUST match src_v4
        if prefix (dst_v6) == 2002::/16
            dst_v4 SHOULD NOT be assigned to the router
        fi
    else
        drop
            /* we somehow got a native-native ipv6 packet */
    fi
    accept

5.2 Decapsulating IPv4 into IPv6

   The checks described in this section are to be performed when
   decapsulating IPv4 into IPv6.  They will be performed in both the
   6to4 router and relay.

    src_v4 and dst_v4 MUST pass ipv4-sanity checks, else drop
    src_v6 and dst_v6 MUST pass ipv6-sanity checks, else drop
    if prefix (dst_v6) == 2002::/16
        ipv4 address embedded in dst_v6 MUST match dst_v4
            if prefix (src_v6) == 2002::/16
                ipv4 address embedded in src_v6 MUST match src_v4
                dst_v4 SHOULD be assigned to the router
            fi
    elif prefix (src_v6) == 2002::/16
        ipv4 address embedded in src_v6 MUST match src_v4
        dst_v4 SHOULD be assigned to the router (see notes below)
    else
        drop
            /* the we somehow got a native-native ipv6 packet */
    fi
    accept

5.3 IPv4 and IPv6 Sanity Checks

   The encapsulation and decapsulation checks included certain sanity
   checks for both IPv4 and IPv6.  These are described here in detail.

5.3.1 IPv4

   IPv4 address MUST be a global unicast address, as required by the
   6to4 specification.  The disallowed addresses include those defined
   in [13], and others widely used and known not to be global.  These
   are:

   o  0.0.0.0/8 (the system has no address assigned yet)

   o  10.0.0.0/8 (private)

   o  127.0.0.0/8 (loopback)

   o  172.16.0.0/12 (private)

   o  192.168.0.0/16 (private)

   o  169.254.0.0/16 (IANA Assigned DHCP link-local)

   o  224.0.0.0/4 (multicast)

   o  240.0.0.0/4 (reserved and broadcast)

   In addition, the address MUST NOT be any of the system's broadcast
   addresses.  This makes some assumptions about is especially important if the implementation is
   made so that it can:

   o  receive and process encapsulated IPv4 packets arriving at its
      broadcast addresses, or

   o  send encapsulated IPv4 packets to one of its broadcast addresses.

5.3.2 IPv6

   IPv6 address MUST NOT be:

   o  0::/16 (compatible, mapped addresses, loopback, unspecified, ...)

   o  fe80::/10 (link-local)

   o  fec0::/10 (site-local)

   o  ff00::/8 (any multicast)

   Note: only link-local multicast would be strictly required, but it is
   believed that multicast with 6to4 will not be feasible, so it has
   been disallowed as pointed above
   to simplify well.

   In addition, it MUST be checked that equivalent 2002:V4ADDR::/48
   checks, where V4ADDR is any of the above rules.

6.2.1. Encapsulating IPv6 into IPv4

    src and dst MUST pass ipv6-sanity checks, else drop addresses, will not be
   passed.

5.3.3 Optional Ingress Filtering

   In addition, the implementation in the 6to4 router may perform some
   form of ingress filtering (e.g. Unicast Reverse Path Forwarding
   checks).  For example, if src=2002
        src MUST match src_v4
    elif dst=2002
        (accept)
    else
        drop
    fi
    accept

6.2.2. Decapsulating the 6to4 router has multiple interfaces, of
   which some are "internal", receiving either IPv4 into or IPv6

    src_v4 packets with
   source address belonging to any of these internal networks from the
   Internet might be disallowed.

   If these checks are implemented, and dst_v4 MUST pass ipv4-sanity checks, else drop
    src are enabled by default, it's
   recommended that there is a toggle to disable them if needed.

5.3.4 Notes About the Checks

   The rule "dst_v4 SHOULD be assigned to the router" is not needed if
   the 6to4 router implementation only accepts and dst MUST pass ipv6-sanity processes
   encapsulated IPv4 packets arriving its unicast IPv4 addresses, and
   when destination address is known to be a local broadcast address, it
   does not try to encapsulate and send packets to it. (see Section
   4.1.4, and Section 4.2.4 about this threat).

   Some checks, else drop
    if dst=2002
        dst MUST match dst_v4 especially the IPv4/IPv6 Sanity Checks, could be at
   least partially implementable with system-level access lists, if src=2002
                src MUST match src_v4
            fi
    elif src=2002
        src MUST match src_v4
    else
        drop
    fi
    accept

7. one
   would like to avoid placing too many restrictions in the 6to4
   implementation itself.  This depends on how many hooks for the access
   lists are in place.  In practice it seems that this could not be done
   effectively enough unless the access list mechanism is able to parse
   the encapsulated packets.

6. Issues in 6to4 Implementation and Use

   This section tries to give an overview of some of the problems 6to4
   implementations are faced with, and which the kind of generic problems the
   6to4 users could come up with.

7.1.

6.1 Implementation Considerations with Automatic Tunnels

   There is a problem with multiple transition mechanisms if strict
   security checks are implemented.  This may vary a bit from
   implementation to implementation.

   Consider three mechanisms using automatic tunneling: 6to4, ISATAP
   [ISATAP]
   [14] and Automatic Tunneling using Compatible Addresses [MECH]. [4].  All of
   these use IP-IP (protocol 41) [IPIP] [15] IPv4 encapsulation with, more or
   less, a pseudo-interface.

   When a router, which has any two of these enabled, receives an IPv4
   encapsulated IPv6 packet:

   src_v6 = 2001:db8::1
   dst_v6 = 2002:1010:1010::2
   src_v4 = 10.0.0.1
   dst_v4 = 20.20.20.20
        src = 3ffe:ffff::1
        dst = 2002:1010:1010::2

   what

   What can it do?  How should it decide which transition mechanism this
   belongs to; there is no "transition mechanism number" in IPv6 or IPv4
   header to signify this.  (This can also be viewed as a flexibility
   benefit.)

   Without any kind of security checks (in any of implemented methods)
   these often just "work" as the mechanisms aren't differentiated but
   handled in "one big lump".

   Configured tunneling [MECH] [4] does not suffer from this as it is point-
   to-point,
   point-to-point, and based on src/dst src_v6/dst_v6 pairs of both IPv4 and
   IPv6 addresses it can be deduced which logical tunnel interface is in
   the question.

   Solutions for this include 1) not using more than one automatic
   tunneling mechanisms mechanism in the same system a node or 2) binding different mechanisms to
   different IPv4 addresses.

7.2. Reduced Flexibility

   There is a worry about too strict rules limiting the (future)
   flexibility of 6to4.  If later, for some reason, one would want to
   introduce new revolutionary ways to use 6to4, strict checking in all
   relevant nodes might prevent it, as new updated version would have to
   be deployed everywhere before the new method could be used.

   On the other hand, one could argue that 6to4 has always been intended
   as an intermediate mechanism, and that future flexibility should not
   be critical.  However, it is difficult to predict how long the
   intermediate period will be.

7.3.

6.2 Anyone Pretending to Be a 6to4 Relay Router

   Even though this was already discussed in Section 4.1.2, it bears
   some additional elaboration as it was the only problem which cannot
   be even partially solved.

   That is, 6to4 Routers routers receive traffic from non-6to4 ("native")
   sources via 6to4 Relays. relays.  6to4 Routers routers have no way of matching IPv4
   source address of the relay with non-6to4 IPv6 address of the source.  In
   consequence,
   Consequently, anyone can spoof any non-6to4 IPv6 address he wants by
   sending traffic, encapsulated, directly to 6to4 Routers.  This is
   analyzed in more detail in the Threat Analysis section, above.

   Of course, as the source IPv4 address may be logged, many may spoof
   their IPv4 source address, but the ability to do so is not be
   required: it is unlikely that source IPv4 (but rather, the spoofed
   IPv6 address) will be logged anywhere -- this would be equivalent to
   logging the MAC-address routers.

   Two different models of IP packets.

   Unfortunately, thinking have been proposed to fix this
   problem if it is very difficult considered to solve properly.
   There have been three rough ideas:

     o Every 6to4 Relay must configure and use "192.88.99.1" as the
       source address of packets that are encapsulated towards 6to4
       Routers. be important:

   o  Every 6to4 Relay relay must participate in an eBGP multi-hop peering
      mesh (which can be hierarchical): there hierarchical); it would be used to advertise
      more specific routes will
       be advertised. routes.

   o  The 6to4 usage model would be turned upside-down, and the
      deployment of 6to4 would be have to be borne by native IPv6 users.

   It should be noted that if IPv6 operators do not implement ingress
   filtering for IPv6, so that spoofing IPv6 is not

   These are described at a bit more difficult than
   spoofing IPv4, these problems have only little impact on the overall
   security of 6to4 nodes.

   The first has since then been rejected: the difference in the
   difficulty of spoofing an address and spoofing it to be 192.88.99.1
   does not seem to justify the mechanism.  A tentative analysis for the
   second and third is given length below.

7.3.1.

6.2.1 Limited Distribution of More Specific Routes

   If 6to4 prefixes more specific than 2002::/16 could be advertised,
   the traffic model between native<->6to4 native to 6to4 and 6to4<-> 6to4 to native could be
   changed so that only one Relay 6to4 relay would always be used, most often
   the one closest to the 6to4 Router. router.

   This model was rejected in the base specification, as IPv6 routing
   table was not to be polluted by 6to4 prefixes derived of IPv4
   prefixes.

   However, the problem could be avoided with some effort: creating a
   separate, possibly hierarchical based on IPv6 connections, peering
   mesh for 6to4 Relay relay routers.  This could be done by forming eBGP
   [BGP] [5]
   multi-hop peerings between Relays, 6to4 relays, and advertising more specific
   routes (e.g. (e.g., the same superblocks of IPv4 addresses one expects to
   service) to all the other Routers. routers.

   In that way, the global routing table would not be impacted at all.

   This seems to have at least three potential issues:

     o

   1.  Every Relay 6to4 relay should be part of this (if one wants to have
       some extra safety that the addresses haven't been spoofed),

     o

   2.  The route from a native source takes the path to the first Relay, 6to4
       relay, and there (possibly through other Relays) to the last Relay 6to4
       relay to tunnel the packet to the 6to4 Router; router; this adds at least
       some latency, and

     o

   3.  The mechanism of redistributing IPv4 6to4 client addresses to
       other relays as 6to4 prefixes needs work.

   Of these, only the last requires more discussion.  It could be argued
   that this advertising should either be manually configured once (ie.
   (i.e., relatively static prefixes, or generated from IPv4
   route-objects in RADB etc.) [16] or generated automatically (e.g. (e.g., when a
   6to4 Router router first sends a "triggering" packet through the Relay). 6to4
   relay).  Of course, this data could even be derived in some form from
   the IPv4 routing tables. Further analysis on this is TBD if
   necessary.

   This method seems

   Even if the traffic to be 6to4 routers is limited to few relays, other
   IPv4 nodes can still spoof both IPv4, and IPv6 address and perform
   the only one where spoofing attack.  Hence, a necessary step is to use strong
   cryptography-based mechanisms to be sure about ensure the 6to4 Router router - 6to4 Relay
   -relationship could be doable; otherwise, relay
   relationship.  Alternatively, some sort of infrastructure
   (e.g. (e.g.,
   small-scale PKI) would have to be established which would have to
   include all the possible 6to4 Relays relays in the Internet.

7.3.2.

6.2.2 A Different Model for 6to4 Deployment

   It could be possible to turn the deployment assumptions of 6to4
   around a bit to eliminate some threats caused by untrusted 6to4
   relays.  That is:

   o  Every dual-stack site (or even ISP) would be required to have
      their own 6to4 relay.  That is, there would not be third-party
      relays, and the 2002::/16 route would not need to be advertised
      globally, and

   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
      policies) -- this is something that the sites and ISPs ISP's should be
      familiar with already.

   However, this has a number of problems:

   This model would shift the majority of burden of supporting 6to4 to
   IPv6 sites which don't employ or use 6to4 at all, e.g. i.e., "those who
   deploy proper native dual-stack".  It could be argued that the
   deployment pain should be borne by 6to4 users, not the others.

   The main advantage of 6to4 is easy deployment and free relays.  This
   would require that everyone the 6to4 sites wish to communicate with
   implement these measures.

   The model would not fix the "relay spoofing problem", only restrict
   it a bit, unless
   everybody deployed also 6to4 addresses on the nodes (alongside with
   native addresses, if necessary), which in turn would change 6to4 to
   operate without relays completely.

   To summarize, it seems like 6to4 cannot be salvaged: the decision is
   either to embrace it or trash it.

8.

7. Security Considerations

   This draft discusses security considerations. considerations of 6to4.

   Even if proper checks are implemented, there are significant a large number of
   different kind of security
   threats ranging from DoS proxy attacks to spoofing and attacks
   against 6to4 pseudo-interface.  These threats; these threats are analyzed in section
   5.

   As can be seen, there
   Section 4.

   There are mainly three classes of potential problem sources:

     o

   1.  6to4 routers not being able to identify whether relays are
       legitimate
     o wrong identify whether relays are
       legitimate,

   2.  Wrong or impartially implemented 6to4 router or relay security
       checks,

   3.  6to4 architecture used to participate in DoS or reflected DoS
       attacks, or made to participate in "packet laundering", i.e.,
       making another attack harder to trace, or impartially implemented

   4.  6to4 Routers
     o relays performing packet laundering being subject to "administrative abuse", e.g., theft
       of service, or being seen as a source of abuse.

   The first is the toughest problem, still under research.  The second
   can be fixed by ensuring the correctness of implementations; this is
   important.  The third is also a difficult, but very difficult problem, and
   impossible to solve completely -- therefore it is important to be
   able to analyze whether this results in a fairly restricted significant increase of
   threats.   The fourth problem as relays are limited in number. seems to have feasible solutions.

   These are analyzed in detail in Threat Analysis section, above.

9. Acknowledgements Analysis, in Section 4.

8. Acknowledgments

   Some issues were first brought up by Itojun Hagino in [TRANSAB], [17], and Alain
   Durand introduced one specific problem at IETF51 in August 2001
   (though there was some discussion on the list prior to that); these
   gave the author the push to start looking into the details of
   securing 6to4.

   Alexey Kuznetsov brought up the implementation problem with IPv6
   martian checks.  Christian Huitema formulated the rules that rely on
   Relays
   6to4 relays using only anycast.  Keith Moore brought up the point
   about reduced flexibility.  Brian Carpenter, Tony Hain and Vladislav
   Yasevich are acknowledged for lengthy discussions.  Alain Durand
   reminded of relay spoofing problems.  Brian Carpenter reminded of the
   BGP-based 6to4 router model.  Christian Huitema gave a push to a more
   complete threat analysis.  Itojun Hagino spelled out the operators'
   fears about 6to4 relay abuse.  Rob Austein brought up the idea of a
   different 6to4 deployment model.

   In the latter phase, especially discussions with Christian Huitema,
   Brian Carpenter and Alain Durand were helpful when improving the
   document.

   David Malone and [your name could be here] gave feedback on the
   document.

10. References

10.1.

Normative References

   [6TO4]

   [1]  Carpenter, B. and Moore K., K. Moore, "Connection of IPv6 Domains via IPv4
        Clouds", RFC 3056, February 2001.

   [6TO4ANY]   Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
               RFC 3068, June 2001.

   [RFC1918]   Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.
               and E. Lear, "Address Allocation for Private Internets",
               BCP 5, RFC 1918, February 1996.

   [RFC2119]

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

10.2.

   [3]  Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC
        3068, June 2001.

Informative References

   [ADDRSEL]   Draves, R., "Default Address Selection

   [4]   Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6", IPv6
         Hosts and Routers", RFC 3484, February 2003.

   [BGP] 2893, August 2000.

   [5]   Rekhter, Y., Y. and T. Li, T., "A Border Gateway Protocol 4",
               RFC1771, March 1995.

   [IPIP]      Simpson, W., "IP in IP Tunneling", 4 (BGP-4)",
         RFC 1853, October 1771, March 1995.

   [ISATAP]    Templin, F. et al, "Intra-Site Automatic Tunnel
               Addressing

   [6]   Draves, R., "Default Address Selection for Internet Protocol (ISATAP)", draft-ietf-ngtrans-
               isatap-15.txt (work-in-progress), August
         version 6 (IPv6)", RFC 3484, February 2003.

   [ITRACE]    Bellovin, S., Leech, M., Taylor, T., "ICMP Traceback
               Messages", draft-ietf-itrace-04.txt

   [7]   Nikander, P., "IPv6 Neighbor Discovery trust models and
         threats", draft-ietf-send-psreq-04 (work in progress),
               February October
         2003.

   [MECH]      Gilligan, R., and

   [8]   Arkko, J., "SEcure Neighbor Discovery (SEND)",
         draft-ietf-send-ndopt-03 (work in progress), January 2004.

   [9]   Nordmark, E. "Transition and R. Gilligan, "Basic Transition Mechanisms for
         IPv6 Hosts and Routers", RFC 2893, August 2000.

   [REVITRACE] Barros, C., "A Proposal for ICMP Traceback Messages",
               http://www.research.att.com/lists/ietf-itrace/2000/09/
               msg00044.html.

   [RHHASEC] draft-ietf-v6ops-mech-v2-02 (work in
         progress), February 2004.

   [10]  Savola, P., "Security of IPv6 Routing Header and Home Address
         Options", draft-savola-ipv6-rh-ha-security-03.txt
               (work-in-progress), December draft-savola-ipv6-rh-ha-security-02 (work in
         progress), March 2002.

   [SEND]      Nikander,

   [11]  Ferguson, P. (Ed.), "IPv6 Neighbor Discovery trust
               models and threats",  draft-ietf-send-psreq-03.txt
               (work-in-progress), April D. Senie, "Network Ingress Filtering:
         Defeating Denial of Service Attacks which employ IP Source
         Address Spoofing", BCP 38, RFC 2827, May 2000.

   [12]  Bellovin, S., Leech, M. and T. Taylor, "ICMP Traceback
         Messages", draft-ietf-itrace-04 (work in progress), February
         2003.

   [TRANSAB]

   [13]  Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
         June 1995.

   [14]  Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site
         Automatic Tunnel Addressing Protocol (ISATAP)",
         draft-ietf-ngtrans-isatap-18 (work in progress), February 2004.

   [15]  Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.

   [16]  Merit Network Inc., "Routing Assets Database (http://
         www.radb.net)".

   [17]  Hagino, J., "Possible abuse against IPv6 transition
         technologies", draft-itojun-ipv6-transition-abuse-01.txt
         (expired, work-in-progress), work-in-progress) , July 2000.

Author's Address

   [18]  Barros, C., "Proposal for ICMP Traceback Messages", http://
         www.research.att.com/lists/ietf-itrace/2000/09/msg00044.html .

Authors' Addresses

   Pekka Savola
   CSC/FUNET
   Espoo,
   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

   Here, a few trivial attack scenarios are outlined -- ones that are
   prevented by implementing checks listed in [6TO4] [1] or in section 6.

   When two 6to4 Routers routers send traffic to each others' domains, packet
   sent by RA to RB is like (note: addresses from 8.0.0.0/24 are just
   examples of global IPv4 addresses):

        src

   src_v6 = 2002:0800:0001::aaaa
        dst
   dst_v6 = 2002:0800:0002::bbbb
   src_v4 = 8.0.0.1 (added when encapsulated to IPv4)
   dst_v4 = 8.0.0.2 (added when encapsulated to IPv4)

   When the packet is received by IPv4 stack on RB, it will be
   decapsulated so that only src src_v6 and dst dst_v6 remain, as originally
   sent by RA:

        src

   src_v6 = 2002:0800:0001::aaaa
        dst
   dst_v6 = 2002:0800:0002::bbbb

   As every other node is just one hop away (IPv6-wise) and the link-
   layer
   link-layer (IPv4) addresses are lost, this may open a lot of
   possibilities for misuse.

   As an example, unidirectional IPv6 spoofing is made trivial because
   nobody can check (without delving into IP-IP packets) whether the
   encapsulated IPv6 addresses were authentic (With native IPv6, this
   can be done by e.g. RPF-like mechanisms or access lists in upstream
   routers).

        src = 2002:1234:5678::aaaa (forged)
        dst = 2002:0800:0002::bbbb
        src_v4 = 8.0.0.1 (added when encapsulated done by e.g., RPF-like mechanisms or access lists in upstream
   routers).

   src_v6 = 2002:1234:5678::aaaa (forged)
   dst_v6 = 2002:0800:0002::bbbb
   src_v4 = 8.0.0.1 (added when encapsulated to IPv4)
   dst_v4 = 8.0.0.2 (added when encapsulated to IPv4)

   A similar attack with "src" being native address is possible even
   with the security checks, by having the sender node pretend to be a
   6to4 relay router.

   More worries come in to the picture if e.g.,

   src_v6 = ::ffff:[some trusted IPv4 in a private network]
   src_v6/dst_v6 = ::ffff:127.0.0.1
   src_v6/dst_v6 = ::1
   src_v6/dst_v6 = ...

   Some implementations might have been careful enough to have designed
   the stack to as to avoid the incoming (or reply) packets going to
   IPv4 packet processing through special addresses (e.g., IPv4-mapped
   addresses), but who can say for all ...

Appendix B. Change Log

   [[ RFC-EDITOR note: to be removed before publication ]]

   Changes from -00 to -01

   1.  Lots of editorial changes in other sections

   2.  Revamped the "Threat Analysis" section completely; ripple the
       effects elsewhere in the document as well.

   3.  Added Chirayu Patel as a co-author.

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any 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 such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to IPv4)
        dst_v4 = 8.0.0.2 (added when encapsulated bring to IPv4)

   A similar attack with "src" being native its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address is possible even
   with the security checks, by having information to the sender node pretend IETF Executive
   Director.

Full Copyright Statement

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be a
   6to4 Relay router.

   More worries come prepared, copied, published
   and distributed, in to whole or in part, without restriction of any
   kind, provided that the picture if e.g.

        src = ::ffff:[some trusted IPv4 above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in a private network]
        src/dst = ::ffff:127.0.0.1
        src/dst = ::1
        src/dst = ...

   Some implementations might have been careful enough to have designed any way, such as by removing
   the stack copyright notice or references to the Internet Society or other
   Internet organizations, except as to avoid needed for the incoming (or reply) packets going purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to
   IPv4 packet processing through special addresses (e.g. IPv4-mapped
   addresses), but who can say translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgment

   Funding for all ... the RFC Editor function is currently provided by the
   Internet Society.