[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

IPv6 Operations Working Group                                    N. Ward
Internet-Draft                                           Braintrust Ltd.
Intended status: Standards Track                           June 30, 2007
Expires: January 1, 2008

                        Teredo Server Selection

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 1, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).


   This document describes performance, reliability and privacy problems
   inherent when using a remotely situated vendor-provided Teredo
   server, which is a common default in current implementations, and
   then discussed why configuring servers manually is bad and difficult.
   It recommends two partial solutions, and gives a final recommendation
   combining both solutions using anycast IPv4 and a well known DNS

Ward                     Expires January 1, 2008                [Page 1]

Internet-Draft           Teredo Server Selection               June 2007

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Motivation for Local Teredo Servers  . . . . . . . . . . . . .  3
     2.1.  Performance and Reliability  . . . . . . . . . . . . . . .  4
     2.2.  Blocking Peers . . . . . . . . . . . . . . . . . . . . . .  4
     2.3.  Hijacking Peers  . . . . . . . . . . . . . . . . . . . . .  4
   3.  Static Configuration of Teredo Server Names in Clients . . . .  5
     3.1.  Hosts Moving Networks  . . . . . . . . . . . . . . . . . .  5
     3.2.  Reconfiguration Logistics  . . . . . . . . . . . . . . . .  6
   4.  Recommendations  . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Overloading A Well Known DNS Name  . . . . . . . . . . . .  6
       4.1.1.  Problems . . . . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Anycast IPv4 . . . . . . . . . . . . . . . . . . . . . . .  7
       4.2.1.  Problems . . . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  Combined IPv4 Anycast and DNS Overloading  . . . . . . . .  7
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  Incomplete Work  . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 11

Ward                     Expires January 1, 2008                [Page 2]

Internet-Draft           Teredo Server Selection               June 2007

1.  Introduction

   Current Teredo RFC 4380 [RFC4380] implementations do not select the
   best Teredo servers for the client's current network location,
   instead relying on a single server name.

   This document explores why an access network provider would wish to
   provide its own Teredo servers, for reasons of reliability,
   performance, and data security and privacy.

   While the server name is configurable in all existing Teredo
   implementations, a network wishing to advise its users to use its own
   Teredo services would currently be required to contact all those
   uesrs and guide them through the re-configuration process.  This
   document describes several reason why this is in-feasible.

   Alternatively, a network may force customers to use its Teredo
   servers by `spoofing' DNS names or IPv4 addresses.  Spoofing of this
   nature is generally considered a bad practice by the Internet
   community, and as such the author advises against doing so.

   As a solution to these problems, this document recommends two things;
   a default configuration setting for Teredo implementations, and an
   IPv4 anycast network for public and internal Teredo server
   distribution.  This default configuration setting can be utilised by
   a network to direct end users to either their own Teredo servers, or
   to publicly available Teredo servers.

   The section entitled "Incomplete Work" at the end of this document
   outlines work required before this document is complete.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Motivation for Local Teredo Servers

   This section describes several reasons why a network may wish to
   provide its own Teredo servers, as opposed to requiring or allowing
   end hosts to rely on those of a third party.

   The Teredo specification documents a relay discovery procedure by
   which a client must find an appropriate Teredo relay for the IPv6
   peer it wishes to exchange IPv6 traffic with.  At a high level, this
   is done by transmitting ICMPv6 Echo-Request messages to the peer via

Ward                     Expires January 1, 2008                [Page 3]

Internet-Draft           Teredo Server Selection               June 2007

   the Teredo server and examining responses.  The path that these
   responses take depends on the NAPT type detected during the Teredo
   Qualification Procedure.

   A Teredo client wishing to access another Teredo client may need to
   use a Teredo server to help establish NAPT translation rules.  This
   is susceptible to the problems below, however two Teredo clients that
   are able to initiate direct communication without assistance from a
   Teredo server are not impacted - i.e. two clients behind two
   different 'cone' NAPTs, or on the same local broadcast network.

2.1.  Performance and Reliability

   Teredo servers and their clients are likely to be located in vastly
   different geographical locations, and as such the Qualification
   Procedure and relay detection mechanisms may not perform optimally.
   While these are small performance hits, hosts at the end of high
   delay networks are likely to be severely impacted.

2.2.  Blocking Peers

   A maliciously configured Teredo server or attached IPv6 network could
   prevent ICMPv6 Echo-Request messages from reaching certain peer nodes
   by simply dropping the packet as part of a firewall filter.  Teredo
   client hosts attempting to reach these nodes will wait for a timeout,
   and optionally fall back to attempting to reach the peer directly via
   IPv4, if available.

    +-------------+          +-------------+           +---------+
    |Teredo Client|--------->|Teredo Server|D.........>|IPv6 Peer|
    +-------------+          +-------------+           +---------+

   D = Dropped packet
   . = Intended relay discovery path
   - = Actual relay discovery path

2.3.  Hijacking Peers

   A maliciously configured Teredo server or attached IPv6 network could
   redirect relay discovery messages intended for certain peer nodes to
   a malicious server.  The malicious server can respond to the Echo-
   Request message via its relay, causing the client's Teredo software
   to select this relay as the best relay for this IPv6 peer.  Now the
   client believes itself to be exchanging traffic with the correct IPv6
   peer, but it is in-fact communicating with an impostor.

   Using this method, a malicious party could either provide services to
   the client, or proxy requests while performing logging or translation

Ward                     Expires January 1, 2008                [Page 4]

Internet-Draft           Teredo Server Selection               June 2007

   of content.  This attack is undetectable to applications, as the
   peer's IPv6 address is unchanged, and the Teredo stack internals does
   not interact with applications.  This attack is undetectable to the
   intended peers, as no traffic will reach it from this client.

   In addition, if this malicious party is or otherwise has access to a
   root certificate authority that is trusted by the client's
   application, a transparent attack on SSL-secured applications - such
   as HTTPS secured banking applications - could easily be performed.

                      +-------------+       +---------+
                      |Actual       |       |Actual   |
          ++=========>|Teredo Relay |<=====>|IPv6 Host|
          ||          +-------------+       +---------+
          ||                                    ^
          \/                                    |        +---------+
    +-------------+           +-------------+   |        |Intended |
    |Teredo Client|---------->|Teredo Server|-->R.......>|IPv6 Host|
    +-------------+           +-------------+            +---------+
           ^                                                 .
           .                                                 .
           .                  +------------+                 .
           .                  |Intended    |                 .
           ...................|Teredo Relay|<.................

   R = Redirected packet
   . = Intended relay discovery path
   - = Actual relay discovery path
   = = Actual data path

3.  Static Configuration of Teredo Server Names in Clients

   A network wishing to provide local Teredo servers is currently only
   able to do so by re-configuring all its client hosts' Teredo
   implementations.  This is difficult and problematic for the reasons
   discussed below.

3.1.  Hosts Moving Networks

   If a host with a statically configured Teredo server specific to one
   network wishes to move to another network, it may cause performance
   problems (see section 2.1), or reachability problems if the
   configured Teredo server is configured to only provide access to
   hosts connected to a particular network, or the Teredo server's
   hostname is not available for querying outside a particular network.
   These can be mitigated through changes in client configuration during

Ward                     Expires January 1, 2008                [Page 5]

Internet-Draft           Teredo Server Selection               June 2007

   network moves, however this is unlikely to be something most end
   users will wish to do.

3.2.  Reconfiguration Logistics

   A service provider with many customers is unlikely to want to spend
   its call centre's resources on contacting these customers, convincing
   them that reconfiguration is important, and guiding them through the
   process for each of their end hosts.

   It has been suggested that a service provider may wish to simply wait
   until a customer has problems and calls the call centre, however this
   has potential to be seen as a problem with the service by the
   customer, and a problem with the IPv6 protocol by the server
   provider's management.

4.  Recommendations

4.1.  Overloading A Well Known DNS Name

   One possible solution is to create a well known DNS name which is
   configured in Teredo clients as the default Teredo server.

   Networks wishing to implement Teredo servers for local use do so by
   creating A records for the well known hostname in their recursive
   resolvers, pointing at one or more Teredo servers that are available
   to their users.

   In programming terms, this is similar to overloading so this
   technique is referred to as DNS overloading for the purposes of this
   document.  This does not reflect any particular network performance
   or loading.

4.1.1.  Problems

   This solution does not provide a good mechanism for a 'fallback' to a
   public or vendor provided set of Teredo servers in the event of a
   failure of the network provided servers, or if a network does not
   provide servers at all.  A possible solution to this would be to have
   the DNS name hosted by the root servers (or some other independent
   party), and have A records pointing to Teredo servers hosted by
   organisations who wish to volunteer their servers for public use.
   However this would require additional administrative overhead to
   maintain a list of working public Teredo servers, in addition either
   all servers would have to have roughly the same load requirements, or
   some weighting would have to occur by duplicating records in the DNS.

Ward                     Expires January 1, 2008                [Page 6]

Internet-Draft           Teredo Server Selection               June 2007

4.2.  Anycast IPv4

   Another solution is to allocate a new 24-bit IPv4 prefix for
   anycasting Teredo servers.  Teredo client software vendors who
   provide Teredo servers for public use should change the A records of
   their current default Teredo server hostnames to point to the first
   IPv4 host address in this prefix.

   Networks wishing to implement Teredo servers for local use do so by
   directing the prefix to one or more local Teredo servers.

   This differs slightly from the IPv4 anycast prefix assigned to 6to4
   servers in RFC 3068 [RFC3068] in that the traffic to this prefix is
   only relay discovery and qualification traffic.  As such, it is
   anticipated that some providers and vendors may make their Teredo
   servers available for use by the public Internet as is done today.
   This can be done by advertising the Teredo anycast IPv4 prefix to
   their peers.

4.2.1.  Problems

   This does not provide a way to distribute load across several servers
   other than to distribute them throughout a network and anycast them
   at each location.  This problem is also apparent in hosts wishing to
   provide public Teredo servers for the use of the general Internet.

   In addition, third party hostnames are still required, and could
   still be changed to point to malicious Teredo servers.

4.3.  Combined IPv4 Anycast and DNS Overloading

   A third approach is to combine the two above solutions, where both a
   well known DNS name is used, and an IPv4 anycast prefix is allocated.
   The root servers (or some other independent party) would host the DNS
   name, with an A record for the first host address in the anycast
   prefix.  This removes the reliance on any vendor provided hostnames,
   and gives the ability for a network to use DNS to distribute load
   across local Teredo servers.

   A network wishing for its users to use Teredo services has several
   non-exclusive deployment options, depending on its requirements:

   1.  The simplest implementation is to direct the anycast prefix to
       one or more local Teredo servers.  The DNS name does not need to
       be overloaded, as the publicly returned A records are accurate
       for the local network.

Ward                     Expires January 1, 2008                [Page 7]

Internet-Draft           Teredo Server Selection               June 2007

   2.  A network wishing to provide Teredo servers on its own IPv4 space
       can do so by overloading the DNS name.  This is useful in larger
       networks to distribute load across several Teredo servers, for
       example.  Note that these servers will only be used by hosts
       configured to use the DNS servers that this name is overloaded

   3.  A network overloading the DNS name may also wish to provide local
       Teredo services for users using third party DNS servers.  Many of
       these hosts can be captured by directing the anycast IPv4 prefix
       at one or more local Teredo servers.

   4.  A network may make its Teredo servers, which are using the IPv4
       anycast addresses, available for the use of the public Internet
       by advertising the IPv4 anycast prefix to its peers, as in
       section 4.2.

   5.  A network not wishing to deploy any Teredo services can do so by
       simply not overloading the well known hostname, and not
       originating the IPv4 anycast prefix - typically, this will mean
       taking no action, so networks with no Teredo knowledge will
       likely function like this already, and their end users will use
       third party Teredo servers selected by the network to be the
       closest IPv4 path.

   6.  Hosts often use statically configured DNS servers, and sometimes
       move to remote networks.  It is not unreasonable to expect
       services like Teredo to continue to function optimally in this
       case.  A network overloading the DNS name may wish to use DNS
       'views' to provide A record(s) pointing to local Teredo server
       addresses when requested by local hosts, and to the public
       anycast Teredo server address when requested by non-local hosts.

   Locally overloaded instances of the DNS name MUST NOT return records
   pointing to any addresses in the public anycast prefix other than the
   first host address.  To do so would cause a problem when hosts that
   either cache results, or remotely query local DNS servers due to
   static configuration, prefer a different anycasted Teredo server

5.  Acknowledgements

   The problems described in this document were arrived at during
   conversations with Shane Connolly and Robin Hartley.

Ward                     Expires January 1, 2008                [Page 8]

Internet-Draft           Teredo Server Selection               June 2007

6.  IANA Considerations

   This memo includes no request to IANA at this time.

7.  Security Considerations

   This document highlights several security concerns with current
   Teredo implementations.

   Fake advertisements of the anycast IPv4 prefix, or fake responses to
   the well known DNS name are not new attack vectors for hijacking
   servers that are introduced by this document - these vectors are
   available in an existing Teredo implementation using vendor provided
   server names and server IPv4 addresses.

   This document assumes that the end user's ISP is a trusted party for
   the purposes of providing a Teredo server.  A Teredo server gives an
   ISP no more control over users' traffic than it has already when
   providing native IPv4 or IPv6 connectivity.

8.  Incomplete Work

   This document is incomplete.  It does not investigate alternative
   service discovery mechanisms, such as SRV records RFC 2782 [RFC2782].
   It does not recommend which of the three solutions to use.  It
   probably needs a bit of re-organisation to make things clearer.

9.  References

9.1.  Normative References

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

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
              Network Address Translations (NATs)", RFC 4380,
              February 2006.

Ward                     Expires January 1, 2008                [Page 9]

Internet-Draft           Teredo Server Selection               June 2007

9.2.  Informative References

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

Author's Address

   Nathan Ward
   Braintrust Ltd.

   Phone: +64 21 431 675
   Email: nward@braintrust.co.nz

Ward                     Expires January 1, 2008               [Page 10]

Internet-Draft           Teredo Server Selection               June 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Ward                     Expires January 1, 2008               [Page 11]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/