6.  Further Study, Use of Teredo to Implement a Tunnel Service

   Teredo defines a NAT traversal solution that can be provided using
   very little resource at the server.  Ongoing IETF discussions have
   outlined the need for both a solution like Teredo and a more
   controlled NAT traversal solution, using configured tunnels to a
   service provider [RFC3904].  This section provides a tentative
   analysis of how Teredo could be extended to also support a configured
   tunnel service.

   It may be possible to design a tunnel server protocol that is
   compatible with Teredo, in the sense that the same client could be
   used either in the Teredo service or with a tunnel service.  In fact,
   this could be done by configuring the client with:

   - The IPv4 address of a Teredo server that acts as a tunnel broker
   - A client identifier
   - A shared secret with that server
   - An agreed-upon authentication algorithm.

   The Teredo client would use the secure qualification procedure, as
   specified in Section 5.2.2. Instead of returning a Teredo prefix in
   the router advertisement, the server would return a globally routable
   IPv6 prefix; this prefix could be permanently assigned to the client,
   which would provide the client with a stable address.  The server
   would have to keep state, i.e., memorize the association between the
   prefix assigned to the client and the mapped IPv4 address and mapped
   UDP port of the client.

   The Teredo server would advertise reachability of the client prefix
   to the IPv6 Internet.  Any packet bound to that prefix would be
   transmitted to the mapped IPv4 address and mapped UDP port of the
   client.

   The Teredo client, when it receives the prefix, would notice that
   this prefix is a global IPv6 prefix, not in the form of a Teredo
   prefix.  The client would at that point recognize that it should
   operate in tunnel mode.  A client that operates in tunnel mode would
   execute a much simpler transmission procedure: it would forward any
   packet sent to the Teredo interface to the IPv4 address and Teredo
   UDP port of the server.

   The Teredo client would have to perform the maintenance procedure
   described in Section 5.2.5. The server would receive the router
   solicitation, and could notice a possible change of mapped IPv4
   address and mapped UDP port that could result from the
   reconfiguration of the mappings inside the NAT.  The server should
   continue advertising the same IPv6 prefix to the client, and should

   update the mapped IPv4 address and mapped UDP port associated to this
   prefix, if necessary.

   There is as yet no consensus that a tunnel-mode extension to Teredo
   should be developed.  This section is only intended to provide
   suggestions to the future developers of such services.  Many details
   would probably have to be worked out before a tunnel-mode extension
   would be agreed upon.

7.  Security Considerations

   The main objective of Teredo is to provide nodes located behind a NAT
   with a globally routable IPv6 address.  The Teredo nodes can use IP
   security (IPsec) services such as Internet Key Exchange (IKE),
   Authentication Header (AH), or Encapsulation Security Payload (ESP)
   [RFC4306, RFC4302, RFC4303], without the configuration restrictions
   still present in "Negotiation of NAT-Traversal in the IKE" [RFC3947].
   As such, we can argue that the service has a positive effect on
   network security.  However, the security analysis must also envisage
   the negative effects of the Teredo services, which we can group in
   four categories: security risks of directly connecting a node to the
   IPv6 Internet, spoofing of Teredo servers to enable a man-in-the-
   middle attack, potential attacks aimed at denying the Teredo service
   to a Teredo client, and denial of service attacks against non-Teredo
   participating nodes that would be enabled by the Teredo service.

   In the following, we review in detail these four types of issues, and
   we present mitigating strategies for each of them.

7.1.  Opening a Hole in the NAT

   The very purpose of the Teredo service is to make a machine reachable
   through IPv6.  By definition, the machine using the service will give
   up whatever firewall service was available in the NAT box, however
   limited this service may be [RFC2993].  The services that listen to
   the Teredo IPv6 address will become the potential target of attacks
   from the entire IPv6 Internet.  This may sound scary, but there are
   three mitigating factors.

   The first mitigating factor is the possibility to restrict some
   services to only accept traffic from local neighbors, e.g., using
   link-local addresses.  Teredo does not support communication using
   link-local addresses.  This implies that link-local services will not
   be accessed through Teredo, and will be restricted to whatever other
   IPv6 connectivity may be available, e.g., direct traffic with
   neighbors on the local link, behind the NAT.

   The second mitigating factor is the possible use of a "local
   firewall" solution, i.e., a piece of software that performs locally
   the kind of inspection and filtering that is otherwise performed in a
   perimeter firewall.  Using such software is recommended.

   The third mitigating factor is the availability of IP security
   (IPsec) services such as IKE, AH, or ESP [RFC4306, RFC4302, RFC4303].
   Using these services in conjunction with Teredo is a good policy, as
   it will protect the client from possible attacks in intermediate
   servers such as the NAT, the Teredo server, or the Teredo relay.
   (However, these services can be used only if the parties in the
   communication can negotiate a key, which requires agreeing on some
   credentials; this is known to be a hard problem.)

7.2.  Using the Teredo Service for a Man-in-the-Middle Attack

   The goal of the Teredo service is to provide hosts located behind a
   NAT with a globally reachable IPv6 address.  There is a possible
   class of attacks against this service in which an attacker somehow
   intercepts the router solicitation, responds with a spoofed router
   advertisement, and provides a Teredo client with an incorrect
   address.  The attacker may have one of two objectives: it may try to
   deny service to the Teredo client by providing it with an address
   that is in fact unreachable, or it may try to insert itself as a
   relay for all client communications, effectively enabling a variety
   of "man-in-the-middle" attack.

7.2.1.  Attacker Spoofing the Teredo Server

   The simple nonce verification procedure described in Section 5.2.2
   provides a first level of protection against attacks in which a third
   party tries to spoof the server.  In practice, the nonce procedure
   can be defeated only if the attacker is "on path".

   If client and server share a secret and agree on an authentication
   algorithm, the secure qualification procedure described in Section
   5.2.2 provides further protection.  To defeat this protection, the
   attacker could try to obtain a copy of the secret shared between
   client and server.  The most likely way to obtain the shared secret
   is to listen to the traffic and mount an offline dictionary attack;
   to protect against this attack, the secret shared between client and
   server should contain sufficient entropy.  (This probably requires
   some automated procedure for provisioning the shared secret and the
   algorithm.)

   If the shared secret contains sufficient entropy, the attacker would
   have to defeat the one-way function used to compute the
   authentication value.  This specification suggests a default

   algorithm combining HMAC and MD5.  If the protection afforded by MD5
   was not deemed sufficient, clients and servers can agree to use a
   different algorithm, e.g., SHA1.

   Another way to defeat the protection afforded by the authentication
   procedure is to mount a complex attack, as follows:

   1) Client prepares router solicitation, including authentication
   encapsulation.

   2) Attacker intercepts the solicitation, and somehow manages to
   prevent it from reaching the server, for example, by mounting a
   short-duration DoS attack against the server.

   3) Attacker replaces the source IPv4 address and source UDP port of
   the request by one of its own addresses and port, and forwards the
   modified request to the server.

   4) Server dutifully notes the IPv4 address from which the packet is
   received, verifies that the Authentication encapsulation is correct,
   prepares a router advertisement, signs it, and sends it back to the
   incoming address, i.e., the attacker.

   5) Attacker receives the advertisement, takes note of the mapping,
   replaces the IPv4 address and UDP port by the original values in the
   intercepted message, and sends the response to the client.

   6) Client receives the advertisement, notes that the authentication
   header is present and is correct, and uses the proposed prefix and
   the mapped addresses in the origin indication encapsulation.

   The root cause of the problem is that the NAT is, in itself, a man-
   in-the-middle attack.  The Authentication encapsulation covers the
   encapsulated IPv6 packet, but does not cover the encapsulating IPv4
   header and UDP header.  It is very hard to devise an effective
   authentication scheme, since the attacker does not do anything else
   than what the NAT legally does!

   However, there are several mitigating factors that lead us to avoid
   worrying too much about this attack.  In practice, the gain from the
   attack is either to deny service to the client or to obtain a "man-
   in-the-middle" position.  However, in order to mount the attack, the
   attacker must be able to suppress traffic originating from the
   client, i.e., have denial of service capability; the attacker must
   also be able to observe the traffic exchanged between client and
   inject its own traffic in the mix, i.e., have man-in-the-middle
   capacity.  In summary, the attack is very hard to mount, and the gain
   for the attacker in terms of "elevation of privilege" is minimal.

   A similar attack is described in detail in the security section of
   [RFC3489].

7.2.2.  Attacker Spoofing a Teredo Relay

   An attacker may try to use Teredo either to pass itself for another
   IPv6 host or to place itself as a man-in-the-middle between a Teredo
   host and a native IPv6 host.  The attacker will mount such attacks by
   spoofing a Teredo relay, i.e., by convincing the Teredo host that
   packets bound to the native IPv6 host should be relayed to the IPv4
   address of the attacker.

   The possibility of the attack derives from the lack of any
   algorithmic relation between the IPv4 address of a relay and the
   native IPv6 addresses served by these relay.  A Teredo host cannot
   decide just by looking at the encapsulating IPv4 and UDP header
   whether or not a relay is legitimate.  If a Teredo host decided to
   simply trust the incoming traffic, it would easily fall prey to a
   relay-spoofing attack.

   The attack is mitigated by the "direct IPv6 connectivity test"
   specified in Section 5.2.9. The test specifies a relay discovery
   procedure secured by a nonce.  The nonce is transmitted from the
   Teredo host to the destination through Teredo server, which the
   client normally trusts.  The response arrives through the "natural"
   relay, i.e., the relay closest to the IPv6 destination.  Sending
   traffic to this relay will place it out of reach of attackers that
   are not on the direct path between the Teredo host and its IPv6 peer.

   End-to-end security protections are required to defend against
   spoofing attacks if the attacker is on the direct path between the
   Teredo host and its peer.

7.2.3.  End-to-End Security

   The most effective line of defense of a Teredo client is probably not
   to try to secure the Teredo service itself: even if the mapping can
   be securely obtained, the attacker would still be able to listen to
   the traffic and send spoofed packets.  Rather, the Teredo client
   should realize that, because it is located behind a NAT, it is in a

   situation of vulnerability; it should systematically try to encrypt
   its IPv6 traffic, using IPsec.  Even if the IPv4 and UDP headers are
   vulnerable, the use of IPsec will effectively prevent spoofing and
   listening of the IPv6 packets by third parties.  By providing each
   client with a global IPv6 address, Teredo enables the use of IPsec

   without the configuration restrictions still present in "Negotiation
   of NAT-Traversal in the IKE" [RFC3947] and ultimately enhances the
   security of these clients.

7.3.  Denial of the Teredo service

   Our analysis outlines five ways to attack the Teredo service.  There
   are countermeasures for each of these attacks.

7.3.1.  Denial of Service by a Rogue Relay

   An attack can be mounted on the IPv6 side of the service by setting
   up a rogue relay and letting that relay advertise a route to the
   Teredo IPv6 prefix.  This is an attack against IPv6 routing, which
   can also be mitigated by the same kind of procedures used to
   eliminate spurious route advertisements.  Dual-stack nodes that
   implement "host local" Teredo relays are impervious to this attack.

7.3.2.  Denial of Service by Server Spoofing

   In Section 7.2, we discussed the use of spoofed router advertisements
   to insert an attacker in the middle of a Teredo conversation.  The
   spoofed router advertisements can also be used to provision a client
   with an incorrect address, pointing to either a non-existing IPv4
   address or the IPv4 address of a third party.

   The Teredo client will detect the attack when it fails to receive
   traffic through the newly acquired IPv6 address.  The attack can be
   mitigated by using the authentication encapsulation.

7.3.3.  Denial of Service by Exceeding the Number of Peers

   A Teredo client manages a cache of recently used peers, which makes
   it stateful.  It is possible to mount an attack against the client by
   provoking it to respond to packets that appear to come from a large
   number of Teredo peers, thus trashing the cache and effectively
   denying the use of direct communication between peers.  The effect
   will last only as long as the attack is sustained.

7.3.4.  Attacks against the Local Discovery Procedure

   There is a possible denial of service attack against the local peer
   discovery procedure, if attackers can manage to send spoofed local
   discovery bubbles to a Teredo client.  The checks described in
   Section 5.2.8 mitigate this attack.  Clients who are more interested
   in security than in performance could decide to disable the local
   discovery procedure; however, if local discovery is disabled, traffic
   between local nodes will end up being relayed through a server

   external to the local network, which has questionable security
   implications.

7.3.5.  Attacking the Teredo Servers and Relays

   It is possible to mount a brute force denial of service attack
   against the Teredo servers by sending them a very large number of
   packets.  This attack will have to be brute force, since the servers
   are stateless, and can be designed to process all the packets that
   are sent on their access line.

   The brute force attack against the Teredo servers is mitigated if
   clients are ready to "failover" to another server.  Bringing down the
   servers will, however, force the clients that change servers to
   renumber their Teredo address.

   It is also possible to mount a brute force attack against a Teredo
   relay.  This attack is mitigated if the relay under attack stops
   announcing the reachability of the Teredo service prefix to the IPv6
   network: the traffic will be picked up by the next relay.

   An attack similar to that described in Section 7.3.2 can be mounted
   against a relay.  An IPv6 host can send IPv6 packets to a large
   number of Teredo destinations, forcing the relay to establish state
   for each of these destinations.  Teredo relays can obtain some
   protection by limiting the range of IPv6 clients that they serve, and
   by limiting the amount of state used for "new" peers.

7.4.  Denial of Service against Non-Teredo Nodes

   There is a widely expressed concern that transition mechanisms such
   as Teredo can be used to mount denial of service attacks, by
   injecting traffic at locations where it is not expected.  These
   attacks fall in three categories: using the Teredo servers as a
   reflector in a denial of service attack, using the Teredo server to
   carry a denial of service attack against IPv6 nodes, and using the
   Teredo relays to carry a denial of service attack against IPv4 nodes.
   The analysis of these attacks follows.  A common mitigating factor in
   all cases is the "regularity" of the Teredo traffic, which contains
   highly specific patterns such as the Teredo UDP port, or the Teredo
   IPv6 prefix.  In case of attacks, these patterns can be used to
   quickly install filters and remove the offending traffic.

   We should also note that none of the listed possibilities offer any
   noticeable amplification.

7.4.1.  Laundering DoS attacks from IPv4 to IPv4

   An attacker can use the Teredo servers as reflectors in a denial of
   service attack aimed at an IPv4 target.  The attacker can do this in
   one of two ways.  The first way is to construct a Router Solicitation

   message and post it to a Teredo server, using as IPv4 source address
   the spoofed address of the target; the Teredo server will then send a
   Router advertisement message to the target.  The second way is to
   construct a Teredo IPv6 address using the Teredo prefix, the address
   of a selected server, the IPv4 of the target, and an arbitrary UDP
   port, and to then send packets bound to that address to the selected
   Teredo server.

   Reflector attacks are discussed in [REFLECT], which outlines various
   mitigating techniques against such attacks.  One of these mitigations
   is to observe that "the traffic generated by the reflectors [has]
   sufficient regularity and semantics that it can be filtered out near
   the victim without the filtering itself constituting a denial-of-
   service to the victim ('collateral damage')".  The traffic reflected
   by the Teredo servers meets this condition: it is clearly
   recognizable, since it originates from the Teredo UDP port; it can be
   filtered out safely if the target itself is not a Teredo user.  In
   addition, the packets relayed by servers will carry an Origin
   indication encapsulation, which will help determine the source of the
   attack.

7.4.2.  DoS Attacks from IPv4 to IPv6

   An attacker may use the Teredo servers to launch a denial of service
   attack against an arbitrary IPv6 destination.  The attacker will
   build an IPv6 packet bound for the target and will send that packet
   to the IPv4 address and UDP port of a Teredo server, to be relayed
   from there to the target over IPv6.

   The address checks specified in Section 5.3.1 provide some protection
   against this attack, as they ensure that the IPv6 source address will
   be consistent with the IPv4 source address and UDP source port used
   by the attacker: if the attacker cannot spoof the IPv4 source
   address, the target will be able to determine the origin of the
   attack.

   The address checks ensure that the IPv6 source address of packets
   forwarded by servers will start with the IPv6 Teredo prefix.  This is
   a mitigating factor, as sites under attack could use this to filter
   out all packets sourced from that prefix during an attack.  This will
   result in a partial loss of service, as the target will not be able
   to communicate with legitimate Teredo hosts that use the same prefix.

   However, the communication with other IPv6 hosts will remain
   unaffected, and the communication with Teredo hosts will be able to
   resume when the attack has ceased.

7.4.3.  DoS Attacks from IPv6 to IPv4

   An attacker with IPv6 connectivity may use the Teredo relays to
   launch a denial of service attack against an arbitrary IPv4
   destination.  The attacker will compose a Teredo IPv6 address using
   the Teredo prefix, a "cone" flag set to 1, the IPv4 address of the
   target, and an arbitrary UDP port.

   In the simplest variation of this attack, the attacker sends IPv6
   packets to the Teredo destination using regular IPv6 routing.  The
   packets are picked by the nearest relay, which will forward them to
   the IPv4 address of the target.  In a more elaborate variant, the
   attacker tricks a Teredo into sending packets to the target, either
   by sending a first packet with a spoofed IPv6 address and letting the
   Teredo host reply or by publishing a spoofed IPv6 address in a name
   service.

   There are three types of IPv4 addresses that an attacker may embed in
   the spoofed Teredo address.  It may embed a multicast or broadcast
   address, an local unicast address, or a global unicast address.

   With multicast or broadcast addresses, the attacker can use the
   multiplying effect of multicast routing.  By sending a single packet,
   it can affect a large number of hosts, in a way reminiscent of the
   "smurf" attack.

   By using local addresses, the attacker can reach hosts that are not
   normally reachable from the Internet, for example, hosts connected to
   the a Teredo relay by a private subnet.  This creates an exposure
   for, at a minimum, a denial of service attack against these otherwise
   protected hosts.  This is similar to attack variants using source
   routing to breach a perimeter.

   The address checks specified in Section 5.2.4, 5.3.1, and 5.4.1
   verify that packets are relayed only to a global IPv4 address.  They
   are designed to eliminate the possibility of using broadcast,
   multicast or local addresses in denial of service or other attacks.
   In what follows, we will only consider attacks targeting globally
   reachable unicast addresses.

   The attacks can be targeted at arbitrary UDP ports, such as, for
   example, the DNS port of a server.  The UDP payload must be a well-
   formed IPv6 packet, and is thus unlikely to be accepted by any well-
   written UDP service; in most case, the only effect of the attack will
   be to overload the target with random traffic.

   A special case occurs if the attack is directed to an echo service.
   The service will echo the packets.  Since the echo service sees the
   request coming from the IPv4 address of the relay, the echo replies
   will be sent back to the same relay.  According to the rules
   specified in Section 5.4, these packets will be discarded by the
   Teredo relay.  This is not a very efficient attack against the Teredo
   relays -- establishing a legitimate session with an actual Teredo
   host would create more traffic.

   The IPv6 packets sent to the target contain the IPv6 address used by
   the attacker.  If ingress filtering is used in the IPv6 network, this

   address will be hard to spoof.  If ingress filtering is not used, the
   attacker can be traced if the IPv6 routers use a mechanism similar to
   ICMP Traceback.  The ICMP messages will normally be collected by the
   same relays that forward the traffic from the attacker; the relays
   can use these messages to identify the source of an ongoing attack.
   The details of this solution will have to be developed in further
   research.

8.  IAB Considerations

   The IAB has studied the problem of "Unilateral Self Address Fixing"
   (UNSAF), which is the general process by which a client attempts to
   determine its address in another realm on the other side of a NAT
   through a collaborative protocol reflection mechanism [RFC3424].
   Teredo is an example of a protocol that performs this type of
   function.  The IAB has mandated that any protocols developed for this
   purpose document a specific set of considerations.  This section
   meets those requirements.

8.1.  Problem Definition

   From [RFC3424], any UNSAF proposal must provide a precise definition
   of a specific, limited-scope problem that is to be solved with the
   UNSAF proposal.  A short-term fix should not be generalized to solve
   other problems; this is why "short term fixes usually aren't".

   The specific problem being solved by Teredo is the provision of IPv6
   connectivity for hosts that cannot obtain IPv6 connectivity natively
   and cannot make use of 6to4 because of the presence of a NAT between
   them and the 6to4 relays.

8.2.  Exit Strategy

   From [RFC3424], any UNSAF proposal must provide the description of an
   exit strategy/transition plan.  The better short term fixes are the
   ones that will naturally see less and less use as the appropriate
   technology is deployed.

   Teredo comes with its own built-in exit strategy: as soon as a client
   obtains IPv6 connectivity by other means, either 6to4 or native IPv6,
   it can cease using the Teredo service.  In particular, we expect that
   the next generation of home routers will provide an IPv6 service in
   complement to the current IPv4 NAT service, e.g., by relaying
   connectivity obtained from the ISP, or by using a configured or
   automatic tunnel service.

   As long as Teredo is used, there will be a need to support Teredo
   relays so that the remaining Teredo hosts can communicate with native
   IPv6 hosts.  As Teredo usage declines, the traffic load on the relays
   will decline.  Over time, managers will observe a reduced traffic
   load on their relays and will turn them off, effectively increasing
   the pressure on the remaining Teredo hosts to upgrade to another form
   of connectivity.

   The exit strategy is facilitated by the nature of Teredo, which
   provides an IP-level solution.  IPv6-aware applications do not have
   to be updated to use or not use Teredo.  The absence of impact on the
   applications makes it easier to migrate out of Teredo: network
   connectivity suffices.

   There would appear to be reasons why a Teredo implementation might
   decide to continue usage of the Teredo service even if it already has
   obtained connectivity by some other means, for example:

   1. When a client is dual homed, and it wishes to improve the service
   when communicating with other Teredo hosts that are "nearby" on the
   IPv4 network.  If the client only used its native IPv6 service, the
   Teredo hosts would be reached only through the relay.  By maintaining
   Teredo, the Teredo hosts can be reached by direct transmission over
   IPv4.

   2. If, for some reason, the Teredo link is providing the client with
   better service than the native IPv6 link, in terms of bandwidth,
   packet loss, etc.

   The design of Teredo mitigates the dual-homing reason.  A host that
   wishes to communicate with Teredo peers can implement a "host-based
   relay", which is effectively an unnumbered Teredo interface.  As
   such, the dual-homed host will obtain Teredo connectivity with those

   hosts that must use Teredo, but will not inadvertently encourage
   other dual-homed hosts to keep using the Teredo service.

   The bubbles and the UDP encapsulation used by Teredo introduce a
   significant overhead.  It would take exceptional circumstances for
   native technologies to provide a lesser service than Teredo.  These
   exceptional circumstances, or other unforeseen reasons, may induce
   hosts to keep using the Teredo service despite the availability of
   native IPv6 connectivity.  However, these circumstances are likely to
   be rare and transient.  Moreover, if the primary reason to use Teredo
   fades away, one can expect that Teredo relays will be progressively
   turned off and that the quality of the Teredo service will
   progressively degrade, reducing the motivation to use the Teredo
   service.

8.3.  Brittleness Introduced by Teredo

   From [RFC3424], any UNSAF proposal must provide a discussion of
   specific issues that may render systems more "brittle".  For example,
   approaches that involve using data at multiple network layers create
   more dependencies, increase debugging challenges, and make it harder
   to transition.

   Teredo introduces brittleness into the system in several ways: the
   discovery process assumes a certain classification of devices based
   on their treatment of UDP; the mappings need to be continuously
   refreshed; and addressing structure may cause some hosts located
   behind a common NAT to be unreachable from each other.

   There are many similarities between these points and those introduced
   by Simple Traversal of the UDP Protocol through NAT (STUN) [RFC3489];
   however, Teredo is probably somewhat less brittle than STUN.  The
   reason is that all Teredo packets are sent from the local IPv4 Teredo
   service port, including discovery, bubbles, and actual encapsulated
   packets.  This is different from STUN, where NAT type detection and
   binding allocation use different local ports (ephemeral, in both
   cases).

   Teredo assumes a certain classification of devices based on their
   treatment of UDP (e.g., cone, protected cone and symmetric).  There
   could be devices that would not fit into one of these molds, and
   hence would be improperly classified by Teredo.

   The bindings allocated from the NAT need to be continuously
   refreshed.  Since the timeouts for these bindings are very
   implementation specific, the refresh interval cannot easily be

   determined.  When the binding is not being actively used to receive
   traffic, but to wait for an incoming message, the binding refresh
   will needlessly consume network bandwidth.

   The use of the Teredo server as an additional network element
   introduces another point of potential security attack.  These attacks
   are largely prevented by the security measures provided by Teredo,
   but not entirely.

   The use of the Teredo server as an additional network element
   introduces another point of failure.  If the client cannot locate a
   Teredo server, or if the server should be unavailable due to failure,
   the Teredo client will not be able to obtain IPv6 connectivity.

   The communication with non-Teredo hosts relies on the availability of
   Teredo relays.  The Teredo design assumes that there are multiple
   Teredo relays; the Teredo service will discover the relay closest to
   the non-Teredo peer.  If that relay becomes unavailable, or is
   misbehaving, communication between the Teredo hosts and the peers
   close to that relay will fail.  This reliability issue is somewhat
   mitigated by the possibility to deploy many relays, arbitrarily close
   from the native IPv6 hosts that require connectivity with Teredo
   peers.

   Teredo imposes some restrictions on the network topologies for proper
   operation.  In particular, if the same NAT is on the path between two
   clients and the Teredo server, these clients will only be able to
   interoperate if they are connected to the same link, or if the common
   NAT is capable of "hairpinning", i.e., "looping" packets sent by one
   client to another.

   There are also additional points of brittleness that are worth
   mentioning:

   - Teredo service will not work through NATs of the symmetric variety.

   - Teredo service depends on the Teredo server running on a network
     that is a common ancestor to all Teredo clients; typically, this is
     the public Internet.  If the Teredo server is itself behind a NAT,
     Teredo service will not work to certain peers.

   - Teredo introduces jitter into the IPv6 service it provides, due to
     the queuing of packets while bubble exchanges take place.  This
     jitter can negatively impact applications, particularly latency
     sensitive ones, such as Voice over IP (VoIP).

8.4.  Requirements for a Long-Term Solution

   From [RFC3424], any UNSAF proposal must identify requirements for
   longer-term, sound technical solutions -- contribute to the process
   of finding the right longer-term solution.

   Our experience with Teredo has led to the following requirements for
   a long-term solution to the NAT problem: the devices that implement
   the IPv4 NAT services should in the future also become IPv6 routers.

9.  IANA Considerations

   This memo documents a request to IANA to allocate a 32-bit Teredo
   IPv6 service prefix, as specified in Section 2.6, and a Teredo IPv4
   multicast address, as specified in Section 2.17.

10.  Acknowledgements

   Many of the ideas in this memo are the result of discussions between
   the author and Microsoft colleagues, notably Brian Zill, John Miller,
   Mohit Talwar, Joseph Davies, and Rick Rashid.  Several encapsulation
   details are inspired from earlier work by Keith Moore.  The example
   in Section 5.1 and a number of security precautions were suggested by
   Pekka Savola.  The local discovery procedure was suggested by Richard
   Draves and Dave Thaler.  The document was reviewed by members of the
   NGTRANS and V6OPS working groups, including Brian Carpenter, Cyndi
   Jung, Keith Moore, Thomas Narten, Anssi Porttikivi, Pekka Savola, Eng
   Soo Guan, and Eiffel Wu.  Eric Klein, Karen Nielsen, Francis Dupont,
   Markku Ala-Vannesluoma, Henrik Levkowetz, and Jonathan Rosenberg
   provided detailed reviews during the IETF last call.

11.  References

11.1.  Normative References

   [RFC768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

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

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104, February
              1997.

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

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461, December
              1998.

   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.

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

   [RFC3424]  Daigle, L. and IAB, "IAB Considerations for UNilateral
              Self-Address Fixing (UNSAF) Across Network Address
              Translation", RFC 3424, November 2002.

   [RFC3566]  Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm
              and Its Use With IPsec", RFC 3566, September 2003.

   [FIPS-180] "Secure Hash Standard", Computer Systems Laboratory,
              National Institute of Standards and Technology, U.S.
              Department Of Commerce, May 1993.

11.2.  Informative References

   [RFC2993]  Hain, T., "Architectural Implications of NAT", RFC 2993,
              November 2000.

   [RFC3330]  IANA, "Special-Use IPv4 Addresses", RFC 3330, September
              2002.

   [RFC3489]  Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy.
              "STUN - Simple Traversal of User Datagram Protocol (UDP)
              Through Network Address Translators (NATs)", RFC 3489,
              March 2003.

   [RFC3904]  Huitema, C., Austein, R., Satapati, S., and R. van der
              Pol, "Evaluation of IPv6 Transition Mechanisms for
              Unmanaged Networks", RFC 3904, September 2004.

   [RFC3947]  Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
              "Negotiation of NAT-Traversal in the IKE", RFC 3947,
              January 2005.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302, December
              2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
              4303, December 2005.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
              4306, December 2005.

   [REFLECT]  V. Paxson, "An analysis of using reflectors for
              distributed denial of service attacks", Computer
              Communication Review, ACM SIGCOMM, Volume 31, Number 3,
              July 2001, pp 38-47.

Author's Address

   Christian Huitema
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052-6399

   EMail: huitema@microsoft.com

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   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
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   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
   http://www.ietf.org/ipr.

   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
   ietf-ipr@ietf.org.

Acknowledgement

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