GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6343

Internet Engineering Task Force (IETF) B. Carpenter Request for Comments: 6343 Univ. of Auckland Category: Informational August 2011 ISSN: 2070-1721

              Advisory Guidelines for 6to4 Deployment

Abstract

 This document provides advice to network operators about deployment
 of the 6to4 technique for automatic tunneling of IPv6 over IPv4.  It
 is principally addressed to Internet Service Providers (ISPs),
 including those that do not yet support IPv6, and to Content
 Providers.  Some advice to implementers is also included.  The
 intention of the advice is to minimize both user dissatisfaction and
 help-desk calls.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6343.

Copyright Notice

 Copyright (c) 2011 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Carpenter Informational [Page 1] RFC 6343 6to4 Advisory August 2011

Table of Contents

 1. Introduction ....................................................2
 2. Principles of Operation .........................................3
    2.1. Router 6to4 ................................................3
    2.2. Anycast 6to4 ...............................................4
 3. Problems Observed ...............................................5
 4. Advisory Guidelines ............................................10
    4.1. Vendor Issues .............................................10
    4.2. Consumer ISPs, and Enterprise Networks, That Do
         Not Support IPv6 in Any Way ...............................11
         4.2.1. Anycast Address Availability .......................11
         4.2.2. Protocol 41 ........................................11
         4.2.3. IPv4 Prefix Issues .................................12
         4.2.4. DNS Issues .........................................12
         4.2.5. Rogue Router Advertisements ........................12
         4.2.6. Planning for IPv6 Deployment .......................13
    4.3. Consumer ISPs, and Enterprise Networks, That Do
         Support IPv6 ..............................................13
    4.4. Transit ISPs and Internet Exchange Points .................14
    4.5. Content Providers and Their ISPs ..........................15
 5. Tunnels Managed by ISPs ........................................17
 6. Security Considerations ........................................17
 7. Acknowledgements ...............................................18
 8. References .....................................................18
    8.1. Normative References ......................................18
    8.2. Informative References ....................................18

1. Introduction

 A technique for automatic tunneling of IPv6 over IPv4, intended for
 situations where a user may wish to access IPv6-based services via a
 network that does not support IPv6, was defined a number of years
 ago.  It is known as 6to4 [RFC3056] [RFC3068] and is quite widely
 deployed in end systems, especially desktop and laptop computers.
 Also, 6to4 is supported in a number of popular models of CPE routers,
 some of which have it enabled by default, leading to quite widespread
 unintentional deployment by end users.
 Unfortunately, experience shows that the method has some problems in
 current deployments that can lead to connectivity failures.  These
 failures cause either long retry delays or complete failures for
 users trying to connect to services.  In many cases, the user may be
 quite unaware that 6to4 is in use; when the user contacts a help
 desk, in all probability the help desk is unable to correctly
 diagnose the problem.  Anecdotally, many help desks simply advise
 users to disable IPv6, thus defeating the whole purpose of the
 mechanism, which was to encourage early adoption of IPv6.

Carpenter Informational [Page 2] RFC 6343 6to4 Advisory August 2011

 The main goal of the present document is to offer advice to network
 operators on how to deal with this situation more constructively than
 by disabling 6to4.  It briefly describes the principle of operation,
 then describes the problems observed, and finally offers specific
 advice on the available methods of avoiding the problems.  Note that
 some of this advice applies to ISPs that do not yet support IPv6,
 since their customers and help desks are significantly affected in
 any case.
 Other advice applies to content providers and implementers, but this
 document does not discuss aspects that are mainly outside the scope
 of network operators:
 1.  Operating system preferences between IPv4 and IPv6 when both
     appear to be available [RFC3484-REVISE].
 2.  Ensuring that application software deals gracefully with
     connectivity problems [EYEBALLS-IPV6].
 3.  Some content providers have chosen to avoid the problem by hiding
     their IPv6 address except from customers of pre-qualified
     networks [DNSWHITE].
 A companion document [HISTORIC] proposes to reclassify 6to4 as
 Historic.  However, this will not remove the millions of existing
 hosts and CPEs that implement 6to4.  Hence, the advice in this
 document remains necessary.

2. Principles of Operation

 There are two variants of 6to4 that are referred to here as "Router
 6to4" and "Anycast 6to4".  To understand Anycast 6to4, it is
 necessary first to understand Router 6to4.

2.1. Router 6to4

 Router 6to4 is the original version, documented in [RFC3056].  The
 model assumes that a user site operates native IPv6, but that its ISP
 provides no IPv6 service.  The site border router acts as a 6to4
 router.  If its external global 32-bit IPv4 address is V4ADDR, the
 site automatically inherits the IPv6 prefix 2002:V4ADDR::/48.  (The
 explanation in RFC 3056 is somewhat confusing, as it refers to the
 obsolete "Top Level Aggregator" terminology.)  The prefix 2002:
 V4ADDR::/48 will be used and delegated for IPv6 service within the
 user site.

Carpenter Informational [Page 3] RFC 6343 6to4 Advisory August 2011

 Consider two such site border routers, with global IPv4 addresses
 192.0.2.170 and 192.0.2.187, and that therefore inherit the IPv6
 prefixes 2002:c000:2aa::/48 and 2002:c000:2bb::/48, respectively.
 The routers can exchange IPv6 packets by encapsulating them in IPv4
 using protocol number 41, and sending them to each other at their
 respective IPv4 addresses.  In fact, any number of 6to4 routers
 connected to the IPv4 network can directly exchange IPv6 packets in
 this way.
 Some 6to4 routers are also configured as "relay routers".  They
 behave as just described, but, in addition, they obtain native IPv6
 connectivity with a normal IPv6 prefix.  They announce an IPv6 route
 to 2002::/16.  For example, assume that the 6to4 router at
 192.0.2.187 is a relay router, whose address on the 6to4 side is
 2002:c000:2bb::1.  Suppose that a host with the 6to4 address 2002:
 c000:2aa::123 sends an IPv6 packet to a native IPv6 destination such
 as 2001:db8:123:456::321.  Assume that the 6to4 router at 192.0.2.170
 has its IPv6 default route set to 2002:c000:2bb::1, i.e., the relay.
 The packet will be delivered to the relay, encapsulated in IPv4.  The
 relay will decapsulate the packet and forward it into native IPv6 for
 delivery.  When the remote host replies, the packet (source 2001:db8:
 123:456::321, destination 2002:c000:2aa::123) will find a route to
 2002::/16, and hence be delivered to a 6to4 relay.  The process will
 be reversed and the packet will be encapsulated and forwarded to the
 6to4 router at 192.0.2.170 for final delivery.
 Note that this process does not require the same relay to be used in
 both directions.  The outbound packet will go to whichever relay is
 configured as the default IPv6 router at the source router, and the
 return packet will go to whichever relay is announcing a route to
 2002::/16 in the vicinity of the remote IPv6 host.
 Of course, there are many further details in RFC 3056, most of which
 are irrelevant to current operational problems.

2.2. Anycast 6to4

 Router 6to4 assumes that 6to4 routers and relays will be managed and
 configured cooperatively.  In particular, 6to4 sites need to
 configure a relay router willing to carry their outbound traffic,
 which becomes their default IPv6 router (except for 2002::/16).  The
 objective of the anycast variant, defined in [RFC3068], is to avoid
 any need for such configuration.  The intention was to make the
 solution available for small or domestic users, even those with a
 single host or simple home gateway rather than a border router.  This
 is achieved quite simply, by defining 192.88.99.1 as the default IPv4
 address for a 6to4 relay, and therefore 2002:c058:6301:: as the
 default IPv6 router address for a 6to4 site.

Carpenter Informational [Page 4] RFC 6343 6to4 Advisory August 2011

 Since Anycast 6to4 implies a default configuration for the user site,
 it does not require any particular user action.  It does require an
 IPv4 anycast route to be in place to a relay at 192.88.99.1.  As with
 Router 6to4, there is no requirement that the return path goes
 through the same relay.

3. Problems Observed

 It should be noted that Router 6to4 was not designed to be an
 unmanaged solution.  Quite the contrary: RFC 3056 contains a number
 of operational recommendations intended to avoid routing issues.  In
 practice, there are few if any deployments of Router 6to4 following
 these recommendations.  Mostly, Anycast 6to4 has been deployed.  In
 this case, the user site (either a single host or a small broadband
 gateway) discovers that it doesn't have native IPv6 connectivity, but
 that it does have a global IPv4 address and can resolve AAAA queries.
 Therefore, it assumes that it can send 6to4 packets to 192.88.99.1.
 Empirically, 6to4 appears to suffer from a significant level of
 connection failure; see [Aben] and [Huston-a].  In experiments
 conducted on a number of dual-stack web servers, the TCP connection
 failure rate has been measured.  In these experiments, the client's
 connection attempt to a server was considered to have failed when the
 server received a TCP SYN packet and sent a SYN/ACK packet in
 response, but received no ACK packet to complete the initial TCP
 three-way handshake.  The experiment conducted by Aben recorded a
 failure rate of between 9% and 20% of all 6to4 connection attempts.
 The experiment conducted by Huston has recorded a failure rate of
 between 9% and 19% of all 6to4 clients.  In this latter experiment,
 it was further noted that between 65% to 80% of all 6to4 clients who
 failed to connect using 6to4 were able to make a successful
 connection using IPv4, while the remainder did not make any form of
 IPv4 connection attempt, successful or otherwise, using the mapped
 IPv4 address as a source address.  No connection attempts using
 embedded RFC 1918 IPv4 addresses were recorded by the server.
 There have been several possible reasons offered for this form of
 6to4 connection failure.  One is the use of private IPv4 addresses
 embedded in the 6to4 address, making the return path for the 6to4
 tunnel infeasible, and the second is the use of local filters and
 firewalls that drop incoming IP packets that use IP protocol 41.  If
 the former case were prevalent, it would be reasonable to expect that
 a significant proportion of failed 6to4 connections would use
 embedded IPv4 addresses that are either drawn from the private use
 (RFC 1918) address ranges, contrary to RFC 3056, or from addresses
 that are not announced in the Internet's IPv4 inter-domain routing
 table.  Neither case was observed to any significant volume in the
 experiments conducted by Huston.  Furthermore, the experimental

Carpenter Informational [Page 5] RFC 6343 6to4 Advisory August 2011

 conditions were varied to use a return 6to4 tunnel with either the
 native IPv4 source address of the dual-stack server or an IPv4 source
 address of 192.88.99.1.  No change in the 6to4 connection failure
 rate was observed between these two configurations; however, other
 operators have reported significant problems when replying from the
 native address, caused by stateful firewalls at the user site.  Given
 that the server used its own 6to4 relay for the return path, the only
 difference in the IP packet itself between the successful IPv4
 connections and the failed 6to4 connections was the IP protocol
 number, which was 6 (TCP) for the successful IPv4 connections and 41
 (IPv6 payload) for the failed 6to4 connections.  The inference from
 these experiments is that one likely reason for the high connection
 failure rate for 6to4 connections is the use of local filters close
 to the end user that block incoming packets with protocol 41, in some
 cases made worse by stateful firewalls if the source address is not
 192.88.99.1.
 In a dual-stack context, this connection failure rate was effectively
 masked by the ability of the client system to recover from the
 failure and make a successful connection using IPv4.  In this case,
 the only effect on the client system was a delay in making the
 connection of between 7 and 20 seconds as the client's system timed
 out on the 6to4 connection attempts (see [EYEBALLS-IPV6]).
 This experience, and further analysis, shows that specific
 operational problems with Anycast 6to4 include:
 1.  Outbound Black Hole: 192.88.99.1 does not generate 'destination
     unreachable' but in fact packets sent to that address are
     dropped.  This can happen due to routing or firewall
     configuration, or even because the relay that the packets happen
     to reach contains an ACL such that they are discarded.
     This class of problem arises because the user's ISP is accepting
     a route to 192.88.99.0/24 despite the fact that it doesn't go
     anywhere useful.  Either the user site or its ISP is dropping
     outbound protocol 41 traffic, or the upstream operator is
     unwilling to accept incoming 6to4 packets from the user's ISP.
     The latter is superficially compatible with the design of Router
     6to4 (referred to as "unwilling to relay" in RFC 3056).  However,
     the simple fact of announcing a route to 192.88.99.0/24 in IPv4,
     coupled with the behavior described in RFC 3068, amounts to
     announcing a default route for IPv6 to all 6to4 sites that
     receive the IPv4 route.  This violates the assumptions of RFC
     3056.

Carpenter Informational [Page 6] RFC 6343 6to4 Advisory August 2011

     The effect of this problem on users is that their IPv6 stack
     believes that it has 6to4 connectivity, but in fact all outgoing
     IPv6 packets are black-holed.  The prevalence of this problem is
     hard to measure, since the resulting IPv6 packets can never be
     observed from the outside.
 2.  Inbound Black Hole: In this case, 6to4 packets sent to
     192.88.99.1 are correctly delivered to a 6to4 relay, and reply
     packets are returned, but they are dropped by an inbound protocol
     41 filter.  As far as the user is concerned, the effect is the
     same as the previous case: IPv6 is a black hole.  Many enterprise
     networks are believed to be set up in this way.  Connection
     attempts due to this case can be observed by IPv6 server
     operators, in the form of SYN packets from addresses in 2002::/16
     followed by no response to the resulting SYN/ACK.  From the
     experiments cited above, this appears to be a significant problem
     in practice.
     This problem is complicated by three variables: the firewall
     applying the protocol 41 filter may be stateless or stateful; the
     relay may source its packets from its native IPv4 address or from
     192.88.99.1; packets from the relay may be subject to IPv4
     ingress filtering.  If the protocol 41 filter is stateless, 6to4
     will never succeed.  If it is stateful, the firewall will drop
     inbound packets from addresses that have not been seen in
     outbound traffic on the same port.  In this case, 6to4 will only
     succeed if the packets are sourced from 192.88.99.1.  If the
     relay is subject to ingress filtering, only packets from its
     native IPv4 address can be transmitted.  Therefore, there are
     only three combinations that can succeed:
     1.  No protocol 41 filter, with the relay using its native IPv4
         source address.
     2.  No protocol 41 filter, with the relay using the anycast IPv4
         source address and with no ingress filter.
     3.  A stateful protocol 41 firewall, with the relay using the
         anycast IPv4 source address and with no ingress filter.
 3.  No Return Relay: If the Outbound Black Hole problem does not
     occur, i.e., the outgoing packet does reach the intended native
     IPv6 destination, the target system will send a reply packet, to
     2002:c000:2aa::123 in our example above.  Then, 2002::/16 may or
     may not be successfully routed.  If it is not routed, the packet
     will be dropped (hopefully, with 'destination unreachable').
     According to RFC 3056, an unwilling relay "MUST NOT advertise any
     2002:: routing prefix into the native IPv6 domain"; therefore,

Carpenter Informational [Page 7] RFC 6343 6to4 Advisory August 2011

     conversely, if this prefix is advertised the relay must relay
     packets regardless of source and destination.  However, in
     practice, the problem arises that some relays reject packets that
     they should relay, based on their IPv6 source address.
     Whether the native IPv6 destination has no route to 2002::/16 or
     it turns out to have a route to an unwilling relay, the effect is
     the same: all return IPv6 packets are black-holed.  While there
     is no direct evidence of the prevalence of this problem, it
     certainly exists in practice.
 4.  Large RTT: In the event that none of the above three problems
     applies, and a two-way path does in fact exist between a 6to4
     host and a native host, the round-trip time may be quite large
     and variable since the paths to the two relays are unmanaged and
     may be complex.  Overloaded relays might also cause highly
     variable RTT.
 5.  PMTUD Failure: A common link MTU size observed on the Internet
     today is 1500 bytes.  However, when using 6to4, the path MTU is
     less than this due to the encapsulation header.  Thus, a 6to4
     client will normally see a link MTU that is less than 1500, but a
     native IPv6 server will see 1500.  It has been observed that Path
     MTU Discovery (PMTUD) does not always work, and this can lead to
     connectivity failures.  Even if a TCP SYN/ACK exchange works, TCP
     packets with full-size payloads may simply be lost.  This problem
     is apparently exacerbated in some cases by failure of the TCP
     Maximum Segment Size (MSS) negotiation mechanism [RFC2923].
     These failures are disconcerting even to an informed user, since
     a standard 'ping' from the client to the server will succeed,
     because it generates small packets, and the successful SYN/ACK
     exchange can be traced.  Also, the failure may occur on some
     paths but not others, so a user may be able to fetch web pages
     from one site, but only ping another.
     Additionally, there is a problem if 6to4 is enabled on a router
     and it advertises the resulting prefix on a LAN, but does not
     also advertise a smaller MTU; in this case, TCP MSS negotiation
     will definitely fail.
 6.  Reverse DNS Failure: Typically, a 6to4-addressed host will not
     have a reverse DNS delegation.  If reverse DNS is used as a
     pseudo-security check, it will fail.
 7.  Bogus Address Failure: By design, 6to4 does not work and will not
     activate itself if the available V4ADDR is a private address
     [RFC1918].  However, it will also not work if the available
     V4ADDR is a "bogon", i.e., a global address that is being used by

Carpenter Informational [Page 8] RFC 6343 6to4 Advisory August 2011

     the operator as a private address.  A common case of this is a
     legacy wireless network using 1.1.1.0/24 as if it was a private
     address.  In this case, 6to4 will assume it is connected to the
     global Internet, but there is certainly no working return path.
     This failure mode will also occur if an ISP is operating a
     Carrier Grade NAT [CGN] between its customers and the Internet,
     and is using global public address space as if it were private
     space to do so.
 8.  Faulty 6to4 Implementations: It has been reported that some 6to4
     implementations attempt to activate themselves even when the
     available IPv4 address is an RFC 1918 address.  This is in direct
     contradiction to RFC 3056, and will produce exactly the same
     failure mode as Bogus Address Failure.  It is of course outside
     the ISP's control.
 9.  Difficult Fault Diagnosis: The existence of all the above failure
     modes creates a problem of its own: very difficult fault
     diagnosis, especially if the only symptom reported by a user is
     slow access to web pages, caused by a long timeout before
     fallback to IPv4.  Tracking down anycast routing problems and
     PMTUD failures is particularly hard.
 The practical impact of the above problems, which are by no means
 universal as there is considerable successful use of Anycast 6to4,
 has been measured at a fraction of 1% loss of attempted connections
 to dual-stack content servers [Anderson].  This is because a small
 fraction of client hosts attempt to connect using 6to4, and up to 20%
 of these experience one of the above failure modes.  While this seems
 low, it amounts to a significant financial impact for content
 providers.  Also, end users frustrated by the poor response times
 caused by fallback to IPv4 connectivity [EYEBALLS-IPV6] are
 considered likely to generate help-desk calls with their attendant
 costs.
 A rather different operational problem caused incidentally by 6to4 is
 that, according to observations made at the University of Southampton
 by Tim Chown and James Morse, and at other sites, rogue Router
 Advertisements [RFC6104] often convey a 2002::/16 prefix.  This
 appears to be due to misbehavior by devices acting as local IPv6
 routers or connection-sharing devices but issuing Router
 Advertisement (RA) messages on the wrong interface.  Such a device,
 if it obtains IPv6 connectivity via an upstream link to the Internet,
 should only issue the corresponding RA messages on its downstream
 link to the nodes intended to share its Internet connection.  Issuing
 RA messages on the upstream link will perturb any other IPv6 hosts on

Carpenter Informational [Page 9] RFC 6343 6to4 Advisory August 2011

 that link.  If 6to4 routing is enabled by default on a device that
 exhibits this faulty behavior, the resulting rogue RA messages will
 indeed convey a 2002::/16 prefix.

4. Advisory Guidelines

 There are several types of operator involved, willingly or
 unwillingly, in the Anycast 6to4 scenario and they will all suffer if
 things work badly.  To avoid operational problems and customer
 dissatisfaction, there is a clear incentive for each of them to take
 appropriate action, as described below.
 This document avoids formal normative language, because it is highly
 unlikely that the guidelines apply universally.  Each operator will
 make its own decisions about which of the following guidelines are
 useful in its specific scenario.

4.1. Vendor Issues

 Although this document is aimed principally at operators, there are
 some steps that implementers and vendors of 6to4 should take.
 1.  Some vendors of routers, including customer premises equipment,
     have not only included support for 6to4 in their products, but
     have enabled it by default.  This is bad practice - it should
     always be a conscious decision by a user to enable 6to4.  Many of
     the above problems only occur due to unintentional deployment of
     6to4.
 2.  Similarly, host operating systems should not enable Anycast 6to4
     by default; it should always be left to the user to switch it on.
 3.  Any 6to4 implementation that attempts to activate itself when the
     available IPv4 address is an RFC 1918 address is faulty and needs
     to be updated.
 4.  6to4 implementations should adopt updated IETF recommendations on
     address selection [RFC3484-REVISE].
 5.  6to4 relay implementations must carefully follow Section 3.2 of
     [RFC4213] to ensure correct handling of MTU issues.
 6.  6to4 router or connection-sharing implementations must avoid
     issuing rogue RAs [RFC6104].  Additionally, where 6to4 is being
     enabled by a node for Internet-connection-sharing purposes, and
     the node supports [RFC4191], then it should set the Router
     Advertisement router preference bits to 11 (low preference).

Carpenter Informational [Page 10] RFC 6343 6to4 Advisory August 2011

4.2. Consumer ISPs, and Enterprise Networks, That Do Not Support IPv6

    in Any Way

4.2.1. Anycast Address Availability

 To reduce the negative impact of Anycast 6to4 deployed (probably
 unknowingly) by users, and consequent user dissatisfaction and help-
 desk calls, such ISPs should check in sequence:
 1.  Does the ISP have a route to 192.88.99.1?  (This means an
     explicit route, or knowledge that the default upstream provider
     has an explicit route.  A default route doesn't count!)
 2.  If so, is it functional and stable?
 3.  If so, is the ping time reasonably short?
 4.  If so, does the relay willingly accept 6to4 traffic from the
     ISP's IPv4 prefixes?  (Note that this is an administrative as
     well as a technical question -- is the relay's operator willing
     to accept the traffic?)
 Unless the answer to all these questions is 'yes', the operator
 should consider blocking the route to 192.88.99.1 and generating an
 IPv4 'destination unreachable' message.  This may cause some 6to4
 implementations to fall back to IPv4 more quickly.  There is little
 operational experience with this, however.
 Some implementations also perform some form of 6to4 relay
 qualification.  For example, one host implementation (Windows) tests
 the protocol 41 reachability by sending an ICMPv6 echo request with
 Hop Limit = 1 to the relay, expecting a response or Hop Limit
 exceeded error back.  Lack of any response indicates that the 6to4
 relay does not work so 6to4 is turned off [Savola].
 A more constructive approach for such an ISP is to seek out a transit
 provider who is indeed willing to offer outbound 6to4 relay service,
 so that the answer to each of the questions above is positive.

4.2.2. Protocol 41

 ISPs in this class should always allow protocol 41 through their
 network and firewalls.  Not only is this a necessary condition for
 6to4 to work, but it also allows users who want to use a configured
 IPv6 tunnel service to do so.

Carpenter Informational [Page 11] RFC 6343 6to4 Advisory August 2011

 Some operators, particularly enterprise networks, silently block
 protocol 41 on security grounds.  Doing this on its own is bad
 practice, since it contributes to the problem and harms any users who
 are knowingly or unknowingly attempting to run 6to4.  The strategic
 solution is to deploy native IPv6, making protocol 41 redundant.  In
 the short term, experimentation could be encouraged by allowing
 protocol 41 for certain users, while returning appropriate ICMP
 responses as mentioned above.  Unfortunately, if this is not done,
 the 6to4 problem cannot be solved.

4.2.3. IPv4 Prefix Issues

 Operators should never use "bogon" address space such as the example
 of 1.1.1.0/24 for customers, since IPv4 exhaustion means that all
 such addresses are likely to be in real use in the near future.
 (Also, see [RFC6269].)  An operator that is unable to immediately
 drop this practice should ensure that 192.88.99.1 generates IPv4
 'destination unreachable'.  It has been suggested that they could
 also run a dummy 6to4 relay at that address which always returns
 ICMPv6 'destination unreachable' as a 6to4 packet.  However, these
 techniques are not very effective, since most current end-user 6to4
 implementations will ignore them.
 If an operator is providing legitimate global addresses to customers
 (neither RFC 1918 nor bogon addresses), and also running Carrier
 Grade NAT (Large Scale NAT) between this address space and the global
 address space of the Internet, then 6to4 cannot work properly.  Such
 an operator should also take care to return 'destination unreachable'
 for 6to4 traffic.  Alternatively, they could offer untranslated
 address space to the customers concerned.

4.2.4. DNS Issues

 A customer who is intentionally using 6to4 may also need to create
 AAAA records, and the operator should be able to support this, even
 if the DNS service itself runs exclusively over IPv4.  However,
 customers should be advised to consider carefully whether their 6to4
 service is sufficiently reliable for this.
 Operators could, in principle, offer reverse DNS support for 6to4
 users [RFC5158], although this is not straightforward for domestic
 customers.

4.2.5. Rogue Router Advertisements

 Paradoxically, operators in this category should consider whether
 they need to defend themselves against rogue IPv6 RA messages
 [RFC6105], since such messages may appear from devices seeking to

Carpenter Informational [Page 12] RFC 6343 6to4 Advisory August 2011

 operate as 6to4 routers and confuse any user devices with IPv6
 enabled by default.  Eventually, the measures being designed by the
 IETF Source Address Validation Improvement (SAVI) working group will
 assist with this problem.  In the short term, IPv4-only operators may
 choose to filter out packets with the IPv6 Ethertype (0x86DD) in
 their access equipment; this will definitively remove rogue RA
 packets.

4.2.6. Planning for IPv6 Deployment

 Enterprise operators who have complete administrative control of all
 end systems may choose to disable 6to4 in those systems as an
 integral part of their plan to deploy IPv6.
 Some IPv4 operators have chosen to install a 6to4 relay, connected
 via an IPv6-in-IPv4 tunnel to an IPv6 operator, as a first step
 before native IPv6 deployment.  The routing guidelines in Section 4.4
 would apply.  However, offering genuine IPv6 service to interested
 customers, even if tunneled, would generally be a better first step.

4.3. Consumer ISPs, and Enterprise Networks, That Do Support IPv6

 Once an operator does support IPv6 service, whether experimentally or
 in production, it is almost certain that users will get better
 results using this service than by continuing to use 6to4.
 Therefore, these operators are encouraged to advise their users to
 disable 6to4 and they should not create DNS records for any 6to4
 addresses.
 Such an operator may automatically fall into one of the following two
 categories (transit provider or content provider), so the guidelines
 in Sections 4.4 or 4.5 will apply instead.
 Operators in this category should make sure that no routers are
 unintentionally or by default set up as active 6to4 relays.
 Unmanaged 6to4 relays will be a source of problems.
 Operators in this category should consider whether they need to
 defend themselves against rogue RA messages with an RA Guard solution
 [RFC6105].  If RA Guard is not available, it may help in some cases
 if at least one legitimate IPv6 router per LAN supports [RFC4191] and
 sets the Router Advertisement router preference bits to 01 (high
 preference).  Eventually, the measures being designed by the IETF
 Source Address Validation Improvement (SAVI) working group will
 assist with this problem.

Carpenter Informational [Page 13] RFC 6343 6to4 Advisory August 2011

4.4. Transit ISPs and Internet Exchange Points

 We assume that transit ISPs have IPv6 connectivity.  To reduce the
 negative impact of Anycast 6to4 on all their client networks, it is
 strongly recommended that they each run an Anycast 6to4 relay
 service.  This will have the additional advantage that they will
 terminate the 6to4 IPv4 packets and can then forward the decapsulated
 IPv6 traffic according to their own policy.  Otherwise, they will
 blindly forward all the encapsulated IPv6 traffic to a competitor who
 does run a relay.
 Although most modern Internet Exchange Points do not offer IP layer
 services, an Internet exchange point (IXP) could choose to operate an
 Anycast 6to4 relay service for the benefit of its customers.  If so,
 it should follow the recommendations in this section.
 It is of critical importance that routing to this service is
 carefully managed:
 1.  The IPv4 prefix 192.88.99.0/24 must be announced only towards
     client IPv4 networks whose outbound 6to4 packets will be
     accepted.
 2.  The IPv6 prefix 2002::/16 must be announced towards native IPv6.
     The relay must accept all traffic towards 2002::/16 that reaches
     it, so the scope reached by this announcement should be carefully
     planned.  It must reach all client IPv6 networks of the transit
     ISP.  If it reaches a wider scope, the relay will be offering a
     free ride to non-clients.
 3.  As discussed in item 2 of Section 3, the choice of IPv4 source
     address used when the relay sends 6to4 packets back towards a
     6to4 user is important.  The best choice is likely to be
     192.88.99.1, not the relay's unicast IPv4 address, unless ingress
     filtering is an issue.  This is to avoid failure if the user is
     behind a stateful firewall.
 4.  The relay should be capable of responding correctly to ICMPv6
     echo requests encapsulated in IPv4 protocol 41, typically with
     outer destination address 192.88.99.1 and inner destination
     address 2002:c058:6301::.  (As noted previously, some 6to4 hosts
     are known to send echo requests with Hop Limit = 1, which allows
     them to rapidly detect the presence or absence of a relay in any
     case, but operators cannot rely on this behavior.)
 5.  Protocol 41 must not be filtered in any IPv4 network or
     firewalls.

Carpenter Informational [Page 14] RFC 6343 6to4 Advisory August 2011

 6.  As a matter of general practice, which is essential for 6to4 to
     work well, IPv6 PMTUD must be possible, which means that ICMPv6
     must not be blocked anywhere [RFC4890].  This also requires that
     the relay has a sufficiently high ICMP error generation
     threshold.  For a busy relay, a typical default rate limit of 100
     packets per second is too slow.  On a busy relay, 1000 pps or
     more might be needed.  If ICMPv6 "Packet Too Big" error messages
     are rate limited, users will experience PMTUD failure.
 7.  The relay must have adequate performance, and since load
     prediction is extremely hard, it must be possible to scale it up
     or, perhaps better, to replicate it as needed.  Since the relay
     process is stateless, any reasonable method of load sharing
     between multiple relays will do.
 8.  Of course, the relay must be connected directly to global IPv4
     space, with no NAT.
 Operators in this category should make sure that no routers are
 unintentionally or by default set up as active 6to4 relays.
 Unmanaged 6to4 relays will be a source of problems.

4.5. Content Providers and Their ISPs

 We assume that content providers and their ISPs have IPv6
 connectivity, and that the servers are dual stacked.  The following
 applies to content servers as such, but equally to web hosting
 servers, servers that form part of a content distribution network,
 load balancers in front of a server farm, and HTTP caches.  There is
 a need to avoid the situation where a client host, configured with
 Anycast 6to4, succeeds in sending an IPv6 packet to the server, but
 the 6to4 return path fails as described above.  To avoid this, there
 must be a locally positioned 6to4 relay.  Large content providers are
 advised to operate their own relays, and ISPs should do so in any
 case.  There must be a 2002::/16 route from the content server to the
 relay.  As noted in the previous section, the corresponding route
 advertisement must be carefully scoped, since any traffic that
 arrives for 2002::/16 must be relayed.
 Such a relay may be dedicated entirely to return traffic, in which
 case, it need not respond to the 6to4 anycast address.
 Nevertheless, it seems wisest to ensure that when the relay sends
 6to4 packets back towards a 6to4 user, they should have 192.88.99.1
 as their IPv4 source address (not the relay's unicast IPv4 address).
 As noted above, this is to avoid problems if the user is behind a
 stateful firewall that drops UDP packets from addresses that have not

Carpenter Informational [Page 15] RFC 6343 6to4 Advisory August 2011

 been seen in outbound traffic.  However, it is also necessary that
 192.88.99.1 is not blocked by upstream ingress filtering -- this
 needs to be tested.
 Without careful engineering, there is nothing to make the return path
 as short as possible.  It is highly desirable to arrange the scope of
 advertisements for 2002::/16 such that content providers have a short
 path to the relay, and the relay should have a short path to the ISP
 border.  Care should be taken about shooting off advertisements for
 2002::/16 into BGP4; they will become traffic magnets.  If every ISP
 with content provider customers operates a relay, there will be no
 need for any of them to be advertised beyond each ISP's own
 customers.
 Protocol 41 must not be filtered in the ISP's IPv4 network or
 firewalls.  If the relays are placed outside the content provider's
 firewall, the latter may filter protocol 41 if desired.
 The relay must have adequate performance, and since load prediction
 is extremely hard, it must be possible to scale it up or, perhaps
 better, to replicate it as needed.  Since the relay process is
 stateless, any reasonable method of load sharing between multiple
 relays will do.
 The relay must of course be connected directly to global IPv4 space,
 with no NAT.
 An option is to embed the relay function directly in the content
 server or first hop router.  This is straightforward, since it can be
 achieved by enabling a local 6to4 interface, and using it to route
 2002::/16 for outbound packets.  (This might not allow use of
 192.88.99.1 as the source address.)  Further details are to be found
 at [Huston-b].  However, in this case protocol 41 must be allowed by
 the firewalls.
 Content providers who do embed the relay function in this way could,
 in theory, accept inbound 6to4 traffic as well.  This is highly
 unadvisable since, according to the rules of 6to4, they would then
 have to relay traffic for other IPv6 destinations, too.  So they
 should not be reachable via 192.88.99.1.  Also, they should certainly
 not create an AAAA record for their 6to4 address -- their inbound
 IPv6 access should be native, and advertising a 6to4 address might
 well lead to unicast reverse path forwarding (uRPF) [RFC3704] ingress
 filtering problems.
 To avoid the path MTU problem described above, content servers should
 also set their IPv6 MTU to a safe value.  From experience, 1280 bytes
 (the minimum allowed for IPv6) is recommended; again, see [Huston-b].

Carpenter Informational [Page 16] RFC 6343 6to4 Advisory August 2011

 Of course, ICMPv6 "Packet Too Big" must not be blocked or rate-
 limited anywhere [RFC4890].
 Reverse DNS delegations are highly unlikely to exist for 6to4
 clients, and are by no means universal for other IPv6 clients.
 Content providers (and, in fact, all service providers) should not
 rely on them as a pseudo-security check for IPv6 clients.
 Operators and content providers should make sure that no routers are
 unintentionally or by default set up as active 6to4 relays.
 Unmanaged 6to4 relays will be a source of problems.

5. Tunnels Managed by ISPs

 There are various ways, such as tunnel brokers [RFC3053], 6rd
 [RFC5969], and Layer 2 Tunneling Protocol version 2 (L2TPv2) hub-and-
 spoke [RFC5571], by which Internet Service Providers can provide
 tunneled IPv6 service to subscribers in a managed way, in which the
 subscriber will acquire an IPv6 prefix under a normal provider-based
 global IPv6 prefix.  Most of the issues described for 6to4 do not
 arise in these scenarios.  However, for IPv6-in-IPv4 tunnels used by
 clients behind a firewall, it is essential that IPv4 protocol 41 is
 not blocked.
 As a matter of general practice, IPv6 PMTUD must be possible, which
 means that ICMPv6 "Packet Too Big" must not be blocked or rate-
 limited anywhere [RFC4890].

6. Security Considerations

 There is a general discussion of security issues for IPv6-in-IPv4
 tunnels in [RFC6169], and [TUNNEL-LOOPS] discusses possible malicious
 loops.  [RFC3964] specifically discusses 6to4 security.  In summary,
 tunnels create a challenge for many common security mechanisms,
 simply because a potentially suspect packet is encapsulated inside a
 harmless outer packet.  All these considerations apply to the
 automatic mechanisms discussed in this document.  However, it should
 be noted that if an operator provides well-managed servers and relays
 for 6to4, non-encapsulated IPv6 packets will pass through well-
 defined points (the native IPv6 interfaces of those servers and
 relays) at which security mechanisms may be applied.
 A blanket recommendation to block protocol 41 is not compatible with
 mitigating the 6to4 problems described in this document.

Carpenter Informational [Page 17] RFC 6343 6to4 Advisory August 2011

7. Acknowledgements

 Useful comments and contributions were made by Emile Aben, Mikael
 Abrahamsson, Tore Anderson, Hermin Anggawijaya, Jack Bates, Cameron
 Byrne, Tim Chown, Remi Despres, Jason Fesler, Wes George, Philip
 Homburg, Ray Hunter, Geoff Huston, Eric Kline, Victor Kuarsingh,
 Martin Levy, David Malone, Alexey Melnikov, Martin Millnert, Keith
 Moore, Gabi Nakibly, Michael Newbery, Phil Pennock, Pekka Savola,
 Mark Smith, Nathan Ward, James Woodyatt, and others.

8. References

8.1. Normative References

 [RFC3056]         Carpenter, B. and K. Moore, "Connection of IPv6
                   Domains via IPv4 Clouds", RFC 3056, February 2001.
 [RFC3068]         Huitema, C., "An Anycast Prefix for 6to4 Relay
                   Routers", RFC 3068, June 2001.

8.2. Informative References

 [Aben]            Aben, E., "6to4 - How Bad is it Really?", 2010, <ht
                   tps://labs.ripe.net/Members/emileaben/
                   6to4-how-bad-is-it-really>.
 [Anderson]        Anderson, T., "IPv6 dual-stack client loss in
                   Norway", 2010, <http://www.fud.no/ipv6/>.
 [CGN]             Perreault, S., Yamagata, I., Miyakawa, S.,
                   Nakagawa, A., and H. Ashida, "Common requirements
                   for Carrier Grade NAT (CGN)", Work in Progress,
                   July 2011.
 [DNSWHITE]        Livingood, J., "IPv6 AAAA DNS Whitelisting
                   Implications", Work in Progress, June 2011.
 [EYEBALLS-IPV6]   Wing, D. and A. Yourtchenko, "Happy Eyeballs:
                   Trending Towards Success with Dual-Stack Hosts",
                   Work in Progress, October 2010.
 [HISTORIC]        Troan, O., "Request to move Connection of IPv6
                   Domains via IPv4 Clouds (6to4) to Historic status",
                   Work in Progress, June 2011.
 [Huston-a]        Huston, G., "Flailing IPv6", 2010, <http://
                   www.potaroo.net/ispcol/2010-12/6to4fail.html>.

Carpenter Informational [Page 18] RFC 6343 6to4 Advisory August 2011

 [Huston-b]        Huston, G., "Two Simple Hints for Dual Stack
                   Servers", 2010, <http://www.potaroo.net/ispcol/
                   2010-05/v6hints.html>.
 [RFC1918]         Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot,
                   G., and E. Lear, "Address Allocation for Private
                   Internets", BCP 5, RFC 1918, February 1996.
 [RFC2923]         Lahey, K., "TCP Problems with Path MTU Discovery",
                   RFC 2923, September 2000.
 [RFC3053]         Durand, A., Fasano, P., Guardini, I., and D. Lento,
                   "IPv6 Tunnel Broker", RFC 3053, January 2001.
 [RFC3484-REVISE]  Matsumoto, A., Kato, J., Fujisaki, T., and T.
                   Chown, "Update to RFC 3484 Default Address
                   Selection for IPv6", Work in Progress, July 2011.
 [RFC3704]         Baker, F. and P. Savola, "Ingress Filtering for
                   Multihomed Networks", BCP 84, RFC 3704, March 2004.
 [RFC3964]         Savola, P. and C. Patel, "Security Considerations
                   for 6to4", RFC 3964, December 2004.
 [RFC4191]         Draves, R. and D. Thaler, "Default Router
                   Preferences and More-Specific Routes", RFC 4191,
                   November 2005.
 [RFC4213]         Nordmark, E. and R. Gilligan, "Basic Transition
                   Mechanisms for IPv6 Hosts and Routers", RFC 4213,
                   October 2005.
 [RFC4890]         Davies, E. and J. Mohacsi, "Recommendations for
                   Filtering ICMPv6 Messages in Firewalls", RFC 4890,
                   May 2007.
 [RFC5158]         Huston, G., "6to4 Reverse DNS Delegation
                   Specification", RFC 5158, March 2008.
 [RFC5571]         Storer, B., Pignataro, C., Dos Santos, M., Stevant,
                   B., Toutain, L., and J. Tremblay, "Softwire Hub and
                   Spoke Deployment Framework with Layer Two Tunneling
                   Protocol Version 2 (L2TPv2)", RFC 5571, June 2009.
 [RFC5969]         Townsley, W. and O. Troan, "IPv6 Rapid Deployment
                   on IPv4 Infrastructures (6rd) -- Protocol
                   Specification", RFC 5969, August 2010.

Carpenter Informational [Page 19] RFC 6343 6to4 Advisory August 2011

 [RFC6104]         Chown, T. and S. Venaas, "Rogue IPv6 Router
                   Advertisement Problem Statement", RFC 6104,
                   February 2011.
 [RFC6105]         Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C.,
                   and J. Mohacsi, "IPv6 Router Advertisement Guard",
                   RFC 6105, February 2011.
 [RFC6169]         Krishnan, S., Thaler, D., and J. Hoagland,
                   "Security Concerns with IP Tunneling", RFC 6169,
                   April 2011.
 [RFC6269]         Ford, M., Boucadair, M., Durand, A., Levis, P., and
                   P. Roberts, "Issues with IP Address Sharing",
                   RFC 6269, June 2011.
 [Savola]          Savola, P., "Observations of IPv6 Traffic on a 6to4
                   Relay", ACM SIGCOMM CCR 35 (1) 23-28, 2006.
 [TUNNEL-LOOPS]    Nakibly, G. and F. Templin, "Routing Loop Attack
                   using IPv6 Automatic Tunnels: Problem Statement and
                   Proposed Mitigations", Work in Progress, May 2011.

Author's Address

 Brian Carpenter
 Department of Computer Science
 University of Auckland
 PB 92019
 Auckland, 1142
 New Zealand
 EMail: brian.e.carpenter@gmail.com

Carpenter Informational [Page 20]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6343.txt · Last modified: 2011/08/09 03:19 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki