WDIFF

draft-huitema-v6ops-teredo-01.txt --> draft-huitema-v6ops-teredo-02.txt

INTERNET DRAFT C. Huitema
<draft-huitema-v6ops-teredo-01.txt>
<draft-huitema-v6ops-teredo-02.txt> Microsoft
Expires August 5, December 9, 2004 February 5, March 8, 2004

Teredo: Tunneling IPv6 over UDP through NATs

Status of this memo

This document is an Internet-Draft

By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and is any of which I become aware will be disclosed, in full conformance accordance
with
all provisions of Section 10 of RFC2026.

This document is an Internet-Draft. RFC 3668.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts. Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

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

Abstract

We propose here a service that enables nodes located behind one or
several
more IPv4 NATs to obtain IPv6 connectivity by tunneling packets over
UDP; we call this the Teredo service. Running the service requires
the help of "Teredo servers" and "Teredo relays"; the Teredo servers
are stateless, and only have to manage a small fraction of the
traffic between Teredo clients; the Teredo relays act as IPv6
routers between the Teredo service and the "native" IPv6
Internet.

1 Introduction

Classic tunneling methods envisaged for IPv6 transition operate by
sending IPv6 packets as payload of IPv4 packets; the 6to4 proposal
[RFC3056] proposes automatic discovery in this context. A problem
with these methods is that they don't work when the IPv6 candidate
node is isolated behind a Network Address Translator (NAT) device:
NATs are typically not programmed to allow the transmission of
arbitrary payload types; even when they are, the local address
cannot be used in a 6to4 scheme. 6to4 will work with a NAT if the
NAT and 6to4 router functions are in the same box; we want to cover
the relatively frequent case when Internet;
the NAT cannot be readily upgraded
to relays can also provide a 6to4 router function.

A possible way to solve the problem is to rely on a set of "tunnel
brokers." There are however limits to any solution that is based on interoperability with hosts using other
transition mechanisms such as "6to4".

Huitema [Page 1]

INTERNET DRAFT Teredo February 5, June 9, 2004

such brokers: the quality

Table of Contents:

1 Introduction .................................................... 4
2 Definitions ..................................................... 4
2.1 Teredo service is not very good, since the
traffic follows a "dog leg" route from the source to the broker and
then the destination; the broker has to provide sufficient
transmission capacity to relay all packets and thus ................................................ 5
2.2 Teredo Client ................................................. 5
2.3 Teredo Server ................................................. 5
2.4 Teredo Relay .................................................. 5
2.5 Teredo IPv6 service prefix .................................... 5
2.5.1 Global Teredo IPv6 service prefix ........................... 5
2.6 Teredo UDP port ............................................... 5
2.7 Teredo bubble ................................................. 5
2.8 Teredo service port ........................................... 5
2.9 Teredo server address ......................................... 6
2.10 Teredo mapped address and Teredo mapped port ................. 6
2.11 Teredo IPv6 client prefix .................................... 6
2.12 Teredo node identifier ....................................... 6
2.13 Teredo IPv6 address .......................................... 6
2.14 Teredo Refresh Interval ...................................... 6
2.15 Teredo secondary port ........................................ 6
2.16 Teredo IPv4 Discovery Address ................................ 6
3 Design goals, requirements, and model of operation .............. 6
3.1 Hypotheses about NAT behavior ................................. 7
3.2 IPv6 provider of last resort .................................. 8
3.2.1 When to use Teredo? ......................................... 8
3.2.2 Autonomous deployment ....................................... 8
3.2.3 Minimal load on servers ..................................... 8
3.2.4 Automatic sunset ............................................ 9
3.3 Operational Requirements ...................................... 9
3.3.1 Robustness requirement ...................................... 9
3.3.2 Minimal support cost ........................................ 9
3.3.3 Protection against denial of service attacks ................ 9
3.3.4 Protection against distributed denial of service attacks .... 9
3.3.5 Compatibility with ingress filtering ........................ 10
3.4 Model of operation ............................................ 10
4 Teredo Addresses ................................................ 11
5 Specification of clients, servers and relays .................... 12
5.1 Message formats ............................................... 12
5.1.1 Teredo IPv6 packet encapsulation ............................ 12
5.1.2 Maximum Transmission Unit ................................... 14
5.2 Teredo Client specification ................................... 15
5.2.1 Qualification procedure ..................................... 16
5.2.2 Secure qualification ........................................ 19
5.2.3 Packet reception ............................................ 20
5.2.4 Packet transmission ......................................... 22
5.2.5 Maintenance ................................................. 23
5.2.6 Sending Teredo Bubbles ...................................... 23
5.2.7 Optional Refresh Interval Determination Procedure ........... 24
5.2.8 Optional local client discovery procedure ................... 25
5.2.9 Direct IPv6 connectivity test ............................... 26
5.2.10 Working around symmetric NAT ............................... 27

Huitema [Page 2]

INTERNET DRAFT Teredo June 9, 2004

5.3 Teredo Server specification ................................... 28
5.3.1 Processing of Teredo IPv6 packets ........................... 28
5.3.2 Processing of router solicitations .......................... 29
5.4 Teredo Relay specification .................................... 30
5.4.1 Transmission by relays to Teredo clients .................... 30
5.4.2 Reception from Teredo clients ............................... 31
5.4.3 Difference between Teredo Relays and Teredo Servers ......... 32
5.5 Implementation of automatic sunset ............................ 32
6 Use of Teredo to implement a tunnel service ..................... 33
7 Security Considerations ......................................... 34
7.1 Opening a hole in the NAT ..................................... 34
7.2 Using the Teredo service for a man-in-the-middle attack ....... 35
7.2.1 End-to-end security ......................................... 36
7.3 Denial of the Teredo service .................................. 36
7.3.1 Denial of service by a rogue relay .......................... 37
8.3.1 Denial of service by server spoofing ........................ 37
7.3.2 Denial of service by exceeding the number of peers .......... 37
7.3.3 Attacks against the local discovery procedure ............... 37
7.3.4 Attacking the Teredo servers and relays ..................... 37
7.4 Denial of service against non-Teredo nodes .................... 38
7.4.1 Laundering DoS attacks from IPv4 to IPv4 .................... 38
7.4.2 DOS attacks from IPv4 to IPv6 ............................... 39
7.4.3 DOS attacks from IPv6 to IPv4 ............................... 39
8 IAB considerations .............................................. 40
8.1 Problem Definition ............................................ 40
8.2 Exit Strategy ................................................. 40
8.3 Brittleness Introduced by Teredo .............................. 41
8.4 Requirements for a Long Term Solution ......................... 42
9 IANA Considerations ............................................. 42
10 Acknowledgements ............................................... 42
11 References ..................................................... 42
12 Authors' Addresses ............................................. 43
13 Intellectual Property Statement ................................ 44
14 Copyright ...................................................... 44

Huitema [Page 3]

INTERNET DRAFT Teredo June 9, 2004

1 Introduction

Classic tunneling methods envisaged for IPv6 transition operate by
sending IPv6 packets as payload of IPv4 packets; the 6to4 proposal
[RFC3056] proposes automatic discovery in this context. A problem
with these methods is that they don't work when the IPv6 candidate
node is isolated behind a Network Address Translator (NAT) device:
NATs are typically not programmed to allow the transmission of
arbitrary payload types; even when they are, the local address
cannot be used in a 6to4 scheme. 6to4 will work with a NAT if the
NAT and 6to4 router functions are in the same box; we want to cover
the relatively frequent case when the NAT cannot be readily upgraded
to provide a 6to4 router function.

A possible way to solve the problem is to rely on a set of "tunnel
brokers." There are however limits to any solution that is based on
such brokers: the quality of service may be limited, since the
traffic follows a "dog leg" route from the source to the broker and
then the destination; the broker has to provide sufficient
transmission capacity to relay all packets and thus suffers a high
cost. For these two reasons, we tend it may be desirable to prefer have solutions
that allow for "automatic tunneling", i.e. let the packets follow a
direct path to the destination.

The automatic tunneling requirement is indeed at odds with some of
the specificities of NATs. Establishing a direct path supposes that
the IPv6 candidate node can retrieve a "globally routable" address
that results from the translation of its local address by one or
several
more NATs; it also supposes that we can find a way to bypass the
various "per destination protections" that many NATs implement. In
this memo, we will explain how IPv6 candidates located behind NATs
can enlist the help of "Teredo servers" and "Teredo relays" to learn
their "global address" and to obtain connectivity, and how clients,
servers and relays can be organized in Teredo networks.

The specification is organized as follow. follows. Section 2 contains the
definition of the terms used in the memo. Section 3 presents the
hypotheses on NAT behavior used in the design, as well as the
operational requirements that the design should meet. Section 4
presents the IPv6 address format used by Teredo. Section 5 contains
the format of the messages and the specification of the protocol.
Section 6 presents the guideline for some further work that would be
complementary to the current approach. Section 7 contains a security
discussion, section 8 a discussion of the so called "UNSAF" issues,
and section 9 contains IANA considerations.

2 Definitions

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

Huitema [Page 4]

INTERNET DRAFT Teredo June 9, 2004

This specification uses the following definitions:

2.1 Teredo service

The transmission of IPv6 packets over UDP, as defined in this memo.

2.2 Teredo Client

A node that has some access to the IPv4 Internet and that wants to gain
access to the IPv6 Internet.

2.3 Teredo Server

A node that has access to the IPv4 Internet through a globally
routable address, and that is used as a helper to provide IPv6
connectivity to Teredo clients.

Huitema [Page 2]

INTERNET DRAFT Teredo February 5, 2004

2.4 Teredo Relay

An IPv6 router that can receive traffic destined to Teredo clients
and forward it using the Teredo service.

2.5 Teredo IPv6 service prefix

An IPv6 addressing prefix which is used to construct the IPv6
address of Teredo clients.

2.5.1 Global Teredo IPv6 service prefix

An IPv6 addressing prefix whose value is XXXX:XXXX:/32.
(TBD IANA; experiments use the value 3FFE:831F::/32, taken from a
range of experimental IPv6 prefixes assigned to Microsoft.)

2.6 Teredo UDP port

The UDP port number at which Teredo Servers are waiting for packets.
The value of this port is 3544.

2.7 Teredo bubble

A Teredo bubble is a minimal IPv6 packet, made of an IPv6 header and
a null payload - the payload type is set to 59, No Next Header, as
per [RFC2460]. The Teredo clients and relays may send bubbles in
order to create a mapping in a NAT.

2.8 Teredo service port

The port through which the Teredo client sends Teredo packets. This
port is attached to one of the client's IPv4 interfaces. addresses. The IPv4
address may or may not be globally routable, as the client may be
located behind one or several more NAT.

Huitema [Page 5]

INTERNET DRAFT Teredo June 9, 2004

2.9 Teredo server address

The IPv4 address of the Teredo server selected by a particular user.

2.10 Teredo mapped address and Teredo mapped port

A global IPv4 address and a UDP port that results from the
translation by one or several NATs of the IPv4 address and UDP port of a client's Teredo
service port. port by one or more NATs. The client learns these values
through the Teredo protocol described in this memo.

2.11 Teredo IPv6 client prefix

A global scope IPv6 prefix composed of the Teredo IPv6 service
prefix and the Teredo server address.

Huitema [Page 3]

INTERNET DRAFT Teredo February 5, 2004

2.12 Teredo node identifier

A 64 bit identifier that contains the UDP port and IPv4 address at
which a client can be joined through the Teredo service, as well as
a flag indicating the type of NAT through which the client accesses
the IPv4 Internet.

2.13 Teredo IPv6 address

A Teredo IPv6 address obtained by combining a Teredo IPv6 client
prefix and a Teredo node identifier.

2.14 Teredo Refresh Interval

The interval during which a Teredo IPv6 Address is expected to
remain valid in the absence of "refresh" traffic. For a client
located behind a NAT, the interval depends on configuration
parameters of the local NAT, or the combination of NATs in the path
to the Teredo server. By default, clients assume an interval value
of 30 seconds; a longer value may be determined by local tests, as
described in section 5.

2.15 Teredo secondary port

A UDP port used to determine the appropriate value of the refresh
interval, but not used to carry any Teredo traffic.

2.16 Teredo IPv4 Discovery Address

An IPv4 multicast address used to discover other Teredo clients on
the same IPv4 subnet. The value of this address is X.X.X.X.
(TBD IANA; experiments use the value 224.0.0.252.)

3 Design goals, requirements, and model of operation

Huitema [Page 6]

INTERNET DRAFT Teredo June 9, 2004

The proposed solution transports IPv6 packets as the payload of UDP
packets. This is based on the observation that TCP and UDP are the
only protocols guaranteed to cross the majority of NAT devices.
Relaying
Tunneling packets over TCP would be possible, but would result in a
very
poor quality of service; relaying encapsulation over UDP is a better choice.

The design of our solution is based on a set of hypotheses and
observations on the behavior of NATs, our desire to provide an "IPv6
provider of last resort", and a list of operational requirements. It
results in a model of operation in which the Teredo service is
enabled by a set of servers and relays.

3.1 Hypotheses about NAT behavior

NAT devices typically incorporate some support for UDP, in order to
enable users in
enable users in the natted domain to use UDP based applications. The
NAT will typically allocate a "mapping" when it sees an UDP packet
coming through for which there is not yet an existing mapping. The
handling of UDP "sessions" by NAT devices differs by two important
parameters, the type and the duration of the mappings.

The type of mappings is analyzed in [RFC3489], which distinguishes
between "Cone NAT", "restricted cone NAT", "port restricted cone
NAT" and "symmetric NAT". The Teredo solution ensures connectivity
for clients located behind cone NATs, retricted cone NATs or port-
restricted cone NATs. these three types NATs.

Clients located behind a symmetric NAT will only be able to use
Teredo if they can somehow program the NAT and reserve a Teredo
service port for each client, for example using the DMZ functions of
the NAT. This is obviously an onerous requirement, at odds with the
design goal of an automatic solution. However, measurement campaigns
and studies of documentations have shown that, at least in simple
"unmanaged" networks, symmetric NATs are a small minority; moreover,
it seems that new NAT models or firmware upgrades avoid the
"symmetric" design.

Regardless of their types, UDP mappings are not kept forever. The
typical algorithm is to remove the natted domain to use UDP based applications. mapping if no traffic is observed
on the specified port for a "lifetime" period. The

Huitema [Page 4]

INTERNET DRAFT Teredo February 5, 2004 client
that wants to maintain a mapping open in the NAT will typically allocate a "mapping" when have to send
some "keep alive" traffic before the lifetime expires. For that, it sees an UDP packet
coming through for which there is not yet
needs an existing mapping. The
handling estimate of UDP "sessions" by NAT devices differs by two important
parameters, the type and the duration of "lifetime" parameter used in the mappings.

3.1.1 Types of UDP mappings

Experience shows NAT. We
observed that the implementers implementation of NAT devices lifetime control can adopt
widely different treatments of UDP mappings:

1) Some vary in
several ways.

Most NATs implement the simplest solution, a "minimum lifetime" which is to map an internal
UDP port, defined by an internal address and a port number on the
corresponding host, to an external port, defined by set as a global address
managed by parameter
of the NAT implementation. Our observations of various boxes showed that
this parameter can vary between about 45 seconds and a port number valid several
minutes.

In many NATs, mappings can be kept for a duration that address. In exceeds this
simple case,

Huitema [Page 7]

INTERNET DRAFT Teredo June 9, 2004

minimum, even in the mapping is retained as long as absence of traffic. We suspect that many
implementation perform "garbage collection" of unused mappings on
special events, e.g. when the overall number of mappings exceeds
some limit.

In some cases, e.g. NATs that manage ISDN or dial-up connections,
the port is active,
and is removed after an inactivity timer. As long as mappings will be released when the mapping connection is
retained, any packet received by the NAT for the external port released, i.e.
when no traffic is
relayed to the internal address and port. These NATs are usually
called "cone NATs".

2) Some implement a more complex solution, in which observed on the NAT not only
establishes a mapping connection for the UDP port, but also maintains a list period of
external hosts to which traffic has been sent from that port. The
packets originating from third party hosts a few
minutes.

Any algorithm used to which estimate the local host
has not yet sent traffic are rejected. These NATs are usually called
"restricted cone NATs".

3) Instead lifetime of keeping just a list mapping will have to
be robust against these variations.

3.2 IPv6 provider of authorized hosts, some NAT
implementations keep a list last resort

Teredo is designed to provide an "IPv6 access of last resort" to
nodes that need IPv6 connectivity but cannot use any of authorized host and port pairs. UDP
packets coming from remote addresses are rejected if the internal
host other
IPv6 transition schemes. This design objective has not yet sent traffic several
consequences on when to the outside host use Teredo, how to program clients, and port pair. The
NATs are often called "port-restricted cone NATs"

4) Finally, some NATs map what
to expect of servers. Another consequence is that we expect to see a
point in time at which the same internal address and port pair Teredo technology ceases to
different external address be used.

3.2.1 When to use Teredo?

Teredo is designed to robustly enable IPv6 traffic through NATs, and port pairs, depending on
the address price of robustness is a reasonable amount of the remote host. These NATs are usually called "symmetric NATs".

Measurement campaigns overhead, due to
UDP encapsulation and studies transmission of documentations have shown bubbles. Nodes that
most NATs implement either option 1 or option 2, i.e. cone NATs or
restricted cone NATs. The want to
connect to the IPv6 Internet SHOULD only use the Teredo solution ensures service as a
"last resort" option: they SHOULD prefer using direct IPv6
connectivity for
clients located behind cone NATs, restricted cone NATs, or port-
restricted cone NATs; if it contains optimizations for clients located
behind a cone NAT; is locally available, if it does not provide connectivity for clients
located behind a symmetric NAT.

3.1.2 Lifetime of UDP mappings

Regardless of their types, UDP mappings are not kept forever. The
typical algorithm is to remove provided by a 6to4
router co-located with the mapping local NAT, or if no traffic it is observed
on provided by a
configured tunnel service; and they SHOULD prefer using the specified port for less
onerous "6to4" encapsulation if they can use a "lifetime" period. The global IPv4 address.

3.2.2 Autonomous deployment

In an IPv6-enabled network, the IPv6 service is configured
automatically, by using mechanisms such as IPv6 Stateless Address
Autoconfiguration [RFC2462] and Neighbor Discovery [RFC2461]. A
design objective is to configure the Teredo service as automatically
as possible. In practice, it is however required that the client
learn the IPv4 address of a server that want is willing to maintain serve them;
some servers may also require some form of access control.

3.2.3 Minimal load on servers

During the peak of the transition, there will be a mapping open in requirement to
deploy a large number of servers throughout the NAT will have Internet. Minimizing
the load on the server is a good way to send
some "keep alive" facilitate this deployment.
To achieve this goal, servers should be as stateless as possible,
and they should also not be required to carry any more traffic before the lifetime expires. For that, it than

Huitema [Page 5] 8]

INTERNET DRAFT Teredo February 5, June 9, 2004

needs an estimate of

necessary. To achieve this objective, we require only that servers
enable the "lifetime" parameter used in packet exchange between clients, but we don't require
servers to carry the NAT. We
observed that actual data packets: these packets will have to
be exchanged directly between the implementation of lifetime control can vary in
several ways.

Most NATs implement Teredo clients, or through a "minimum lifetime" which
destination-selected relay for exchanges between Teredo clients and
other IPv6 clients.

3.2.4 Automatic sunset

Teredo is set meant as a parameter
of short-term solution to the implementation. Our observations specific problem of various boxes showed that
this parameter can vary between about 45 seconds and several
minutes.

In many NATs, mappings
providing IPv6 service to nodes located behind a NAT. The problem is
expected to be resolved over time by transforming the "IPv4 NAT"
into an "IPv6 router". This can be kept for a duration that exceeds this
minimum, even done in the absence of traffic. We suspect that many
implementation perform "garbage collection" one of unused mappings on
special events, e.g. when two ways:
upgrading the overall number of mappings exceeds
some limit.

In some cases, e.g. NATs that manage ISDN NAT to provide 6to4 functions, or dial-up connections,
the mappings will be released when upgrading the
Internet connection is released, i.e.
when no traffic is observed is observed on used by the connection for a
period of NAT to a few minutes.

Any algorithm used native IPv6 service, and
then adding IPv6 router functionality in the NAT. In either case,
the former NAT can present itself as an IPv6 router to estimate the lifetime of mapping systems
behind it. These systems will start receiving the "router
advertisements"; they will notice that they have to
be robust against these variations.

3.2 IPv6 provider of last resort connectivity,
and will stop using Teredo.

3.3 Operational Requirements

3.3.1 Robustness requirement

The Teredo service is designed primarily for robustness: packets are
carried over UDP in order to provide an "IPv6 access of last resort" to
nodes that need IPv6 connectivity but cannot use any of the other
transition schemes cross as many NAT implementations as
possible. The servers are designed by the NGTRANS working group. This
design objective has several consequences on when to use Teredo, how
to program clients, and what to expect of servers. Another
consequence is be stateless, which means that we
they can easily be replicated. We expect indeed to see a point in time find many such
servers replicated at which multiple Internet locations.

3.3.2 Minimal support cost

The service requires the
Teredo technology ceases to be used.

3.2.1 When support of servers and relays. In order to use Teredo?
facilitate the deployment of these servers, the Teredo is procedures
are designed to robustly enable IPv6 traffic through NATs, and minimize the price of robustness is a reasonable amount of overhead, due to
UDP encapsulation and transmission fraction of bubbles. Nodes traffic that want to
connect has to be
routed through the IPv6 Internet SHOULD only use servers.

Meeting this objective implies that the Teredo service as a
"last resort" option: they SHOULD prefer using direct IPv6
connectivity if it is locally available or if it is provided by a
6to4 router co-located with addresses will
incorporate the local NAT, IPv4 address and they SHOULD prefer
using UDP port through which a Teredo
client can be reached. This creates an implicit limit on the less onerous "6to4" encapsulation if they
stability of the Teredo addresses, which can use a global only remain valid as
long as the underlying IPv4 address.

3.2.2 Autonomous deployment

In an IPv6-enabled network, address and UDP port remains valid.

3.3.3 Protection against denial of service attacks

The Teredo clients obtain mapped addresses and ports from the IPv6 Teredo
servers. The service is configured
automatically, by using mechanisms such as IPv6 Stateless Address
Autoconfiguration [RFC2462] must be protected against denial of service
attacks in which a third party spoofs a Teredo server and Neighbor Discovery [RFC2461]. A
design objective is sends
improper information to configure the Teredo client.

3.3.4 Protection against distributed denial of service as automatically attacks

Huitema [Page 6] 9]

INTERNET DRAFT Teredo February 5, June 9, 2004

Teredo servers will act as possible. In practice, it is however required that the client
learn the IPv4 address of a server that is willing to serve them;
some servers may also require some form relay for IPv6 packets. Improperly
designed packet relays can be used by denial of access control.

3.2.3 Minimal load on servers

During service attackers to
hide their address, making the attack untraceable. The Teredo
service must include adequate protection against such misuse.

3.3.5 Compatibility with ingress filtering

Routers may perform ingress filtering by checking that the peak source
address of the transition, there will be packets received on a requirement given interface is
"legitimate", i.e. belongs to
deploy network prefixes from which traffic is
expected at a large number of servers throughout the Internet. Minimizing
the load on the server network interface. Ingress filtering is a good way to facilitate this deployment.
To achieve this goal, servers should be as stateless recommended
practice, as possible,
and they should also not be required to carry any more traffic than
necessary. To achieve this objective, we require only that servers
enable it thwarts the packet exchange between clients, but we don't require
servers use of forged source IP addresses by
malfeasant hackers, notably to carry the actual data packets: these packets will have cover their tracks during denial of
service attacks. The Teredo specification must not force networks to
be exchanged directly between the
disable ingress filtering.

3.4 Model of operation

The operation of Teredo involves four types of nodes: Teredo
clients, or through a
destination-selected relay for exchanges between Teredo clients servers, Teredo relays, and
other "plain" IPv6 clients.

3.2.4 Automatic sunset nodes.

Teredo clients start operation by interacting with a Teredo server,
performing a "qualification procedure". During this procedure, the
client will discover whether it is meant as behind a short-term solution to cone, restricted cone or
symmetric NAT. If the specific problem of
providing client is not located behind a symmetric NAT,
the procedure will be successful and the client will configure a
"Teredo address".

The Teredo address embeds the "mapped address and port" through
which the client can receive IPv4/UDP packets encapsulating IPv6 service to nodes
packets. If the client is not located behind a NAT. The problem is
expected to cone NAT, packet
transmission must be resolved over time preceded by transforming the "IPv4 NAT"
into an "IPv6 router". exchange of "bubbles" that will
install a mapping in the NAT. This document specifies how the
bubbles can be done exchanged between Teredo clients in one of two ways:
upgrading the NAT to provide 6to4 functions, or upgrading the
Internet connection used by the NAT order to enable
transmission along a native direct path.

Teredo clients can exchange IPv6 service, and
then adding packets with plain IPv6 router functionality in the NAT. In either case, nodes (e.g.
native nodes or 6to4 nodes) through Teredo relays. Teredo relays
advertise reachability of the former NAT can present itself as an IPv6 router Teredo prefix to a certain subset of
the systems
behind it. These systems IPv6 Internet: a relay set up by an ISP will start receiving typically serve
only the "router
advertisements"; they will notice that they have IPv6 connectivity,
and customers of this ISP; a relay set-up for a site will stop using Teredo.

3.3 Operational Requirements

3.3.1 Robustness requirement

The
only serve the IPv6 hosts of this site. Dual-stack hosts may
implement a "local relay", allowing them to communicate directly
with Teredo service is designed primarily for robustness: hosts by sending IPv6 packets are
carried over UDP in order to cross as many NAT implementations as
possible. The servers are designed to be stateless, which means that
they can easily be replicated. We expect indeed to find many such
servers replicated at multiple Internet locations.

3.3.2 Minimal support cost

The service requires the support of servers and relays. IPv4.

In order to
facilitate the deployment of these servers, prevent spoofing, the Teredo procedures
are designed clients perform a relay
discovery procedure by sending an ICMP echo request to minimize the fraction of traffic that has to be
routed native
host, through the servers.

Meeting this objective implies that the Teredo addresses will
incorporate server. The payload of the IPv4 address and UDP port through which echo request
contains a large random number. The echo reply is forwarded by the
relay closest to the native or 6to4 peer, enabling the Teredo client can be reached. This creates an implicit limit on
to discover this relay. In order to prevent spoofing, the Teredo

Huitema [Page 7] 10]

INTERNET DRAFT Teredo February 5, June 9, 2004

stability of the Teredo addresses, which can only remain valid as
long as the underlying IPv4 address and UDP port remains valid.

3.3.3 Protection against denial of service attacks

The Teredo clients obtain mapped addresses and ports from

client verifies that the Teredo
servers. The service must be protected against denial payload of service
attacks in which a third party spoofs a Teredo server and sends
improper information to the client.

3.3.4 Protection against distributed denial of service attacks

Teredo servers will act as a relay for IPv6 packets. Improperly
designed packet relays can be used by denial of service attackers to
hide their address, making echo reply contains the attack untraceable.
proper random number.

The Teredo
service must include adequate protection against such misuse.

3.3.5 Compatibility with ingress filtering

Routers may perform ingress filtering by checking procedures are designed so that the source
address of Teredo server only
participates in the packets received on a given interface is
"legitimate", i.e. belongs to network prefixes from which traffic is
expected at a network interface. Ingress filtering is a recommended
practice, as it thwarts qualification procedure and in the use of forged source IP addresses by
malfeasant hackers, notably to cover their tracks during denial exchange of
service attacks.
bubbles and ICMP echo requests. The Teredo specification must not force networks server never carries
actual data traffic. There are two rationales for this design:
reduce the load on the server in order to
disable ingress filtering. enable scaling; and avoid
privacy issues that could occur if a Teredo server kept copies of
the client's data packets.

4 Teredo Addresses

The Teredo addresses are composed of 5 components:

- Prefix: the 32 bit Teredo service prefix.
- Server IPv4: the IPv4 address of a Teredo server.
- Flags: a set of 16 bits that document type of address and NAT.
- Port: the obfuscated "mapped UDP port" of the Teredo service at
the client
- Client IPv4: the obfuscated "mapped IPv4 address" of a the client

In this format, both the "mapped UDP port" and "mapped IPv4 address"
of the client are obfuscated. Each bit in the address and port
number is reversed; this can be done by an exclusive OR of the 16-
bit port number with the hexadecimal value 0xFFFF, and an exclusive
OR of the 32-bit address with the hexadecimal value 0xFFFFFFFF.

The IPv6 addressing rules specify that "for all unicast addresses,
except those that start with binary value 000, Interface IDs are
required to be 64 bits long and to be constructed in Modified EUI-64

Huitema [Page 8]

INTERNET DRAFT Teredo February 5, 2004
format." This dictates the encoding of the flags, 16 intermediate
bits which should correspond to valid values of the most significant
16 bits of a Modified EUI-64 ID:

0 0 0 1
|0 7 8 5
+----+----+----+----+
|Czzz|zzUG|zzzz|zzzz|
+----+----+----+----+

In this format:

- The bits "UG" should be set to the value "00", indicating a non-
global unicast identifier;
- The bit "C" (cone) should be set to 1 if the client believes it is
behind a cone NAT, to 0 otherwise; these values determine

Huitema [Page 11]

INTERNET DRAFT Teredo June 9, 2004

different server behavior during the qualification procedure, as
specified in section 5.2.1, as well as different bubble processing
by clients and relays.
- The bits indicated with "z" must be set to zero. sent as zero and
ignored on receipt.

There are thus two valid currently specified values of the Flags field:
"0x0000" (all null) if the cone bit is set to 0, and "0x8000" if the
cone bit is set to 1.

A third party sends IPv6 packets to a Teredo client by sending these
packets over UDP to the mapped IPv4 address and port (Further versions of the client
if the cone bit is set, or if the third party has recently received
direct traffic from the client. In the other cases, the third party
will have this specification may
assign new values to first synchronize with the client, by sending an
initial bubble through the server. reserved bits.)

In some cases, Teredo nodes use link-local addresses. These
addresses contain a link local prefix (FE80::/64) and a 64 bit
identifier, constructed using the same format as presented above. A
difference between link-local addresses and global addresses is that
the identifiers used in global addresses MUST include a global scope
unicast IPv4 address, while the identifiers used in link-local
addresses MAY include a private IPv4 address.

5 Specification of clients, servers and relays

The Teredo service is realized by having clients interact with
Teredo servers through the Teredo service protocol. The clients will
also receive IPv6 packets through Teredo relays.

The Teredo server is designed to be stateless. It waits for Teredo
requests and for IPv6 packets on the Teredo UDP port; it processes
the requests by sending a response to the appropriate address and
port; it forwards Teredo IPv6 packets to the appropriate IPv4

Huitema [Page 9]

INTERNET DRAFT Teredo February 5, 2004
address and UDP port.

The Teredo relay advertises reachability of the Teredo service
prefix over IPv6. It The scope of advertisement may be the entire
Internet, or a smaller subset such as an ISP network or an IPv6
site; it may even be as small as a single host in the case of "local
relays". The relay forwards Teredo IPv6 packets to the appropriate
IPv4 address and UDP port.

Teredo clients, servers and relays must implement the sunset
procedure defined in section 5.5.

5.1 Message formats

5.1.1 Teredo IPv6 packets packet encapsulation

Teredo IPv6 packets are transmitted as UDP packets [RFC768] within
IPv4 [RFC791]. The source and destination IP addresses and UDP
ports take values that are specified in this section. Packets can
come in one of two formats, simple encapsulation and encapsulation
with origin indication.

Huitema [Page 12]

INTERNET DRAFT Teredo June 9, 2004

When simple encapsulation is used, the packet will have a simple
format, in which the IPv6 packet is carried as the payload of a UDP
datagram:

+------+-----+-------------+
| IPv4 | UDP | IPv6 packet |
+------+-----+-------------+

When relaying packets received from third parties, the server may
insert an origin indication in the first bytes of the UDP payload:

+------+-----+-------------------+-------------+
| IPv4 | UDP | Origin indication | IPv6 packet |
+------+-----+-------------------+-------------+

The origin indication encapsulation is an 8-octet element, with the
following content:

+--------+--------+-----------------+
| 0x00 | 0x00 | Origin port # |
+--------+--------+-----------------+
| Origin IPv4 address |
+-----------------------------------+

The first two octets of the origin indication are set to a null
value; this is used to discriminate between the simple
encapsulation, in which the first 4 bits of the packet contain the
indication of the IPv6 protocol, and the origin indication.

The following 16 bits contain the obfuscated value of the port
number from which the packet was received, in network byte order.
The next 32 bits contain the obfuscated IPv4 address from which the
packet was received, in network byte order. In this format, both the

Huitema [Page 10]

INTERNET DRAFT Teredo February 5, 2004
original "IPv4 address" and "UDP port" of the client are obfuscated.
Each bit in the address and port number is reversed; this can be
done by an exclusive OR of the 16-bit port number with the
hexadecimal value 0xFFFF, and an exclusive OR of the 32-bit address
with the hexadecimal value 0xFFFFFFFF.

For example, if the original UDP port number was 337 (hexadecimal
0151) and original IPv4 address was 1.2.3.4 (hexadecimal: 01020304),
the origin indication would contain the value "0000FEAEFEFDFCFB".

When exchanging Router Solicitation and Router Advertisement
messages between a client and its server, the packets may include an
authentication parameter:

+------+-----+----------------+-------------+
| IPv4 | UDP | Authentication | IPv6 packet |
+------+-----+----------------+-------------+

The authentication encapsulation is a variable length-element,

Huitema [Page 13]

INTERNET DRAFT Teredo June 9, 2004

containing a client identifier, an authentication value, a nonce
value, and a confirmation byte.

+--------+--------+--------+--------+
| 0x00 | 0x01 | ID-len | AU-len |
+--------+--------+--------+--------+
| Client identifier (ID-len |
+-----------------+-----------------+
| octets) | Authentication |
+-----------------+--------+--------+
| value (AU-len octets) | Nonce |
+--------------------------+--------+
| value (8 octets |
+--------------------------+--------+
| | Conf. |
+--------------------------+--------+

The first octet of the authentication encapsulation is set to a null
value, and the second octet is set to the value 1; this enables
differentiation from IPv6 packets and from origin information
indication encapsulation. The third octet indicates the length in
bytes of the client identifier; the fourth octet indicates the
length in bytes of the authentication value. The computation of the
authentication value is specified in section 5.2.2. The
authentication value is followed by an 8-octet nonce, and by a confirmation byte. 8-octet nonce, and by a
confirmation byte.

Both ID-len and AU-len can be set to null values if the server does
not require an explicit authentication of the client.

Authentication and origin indication encapsulations may sometimes be
combined, for example in the RA responses sent by the server. In
this case, the authentication encapsulation MUST be the first
element in the UDP payload:

Huitema [Page 11]

INTERNET DRAFT Teredo February 5, 2004

+------+-----+----------------+--------+-------------+
| IPv4 | UDP | Authentication | Origin | IPv6 packet |
+------+-----+----------------+--------+-------------+

5.1.2 Maximum Transmission Unit

Since Teredo uses UDP as an underlying transport, a Teredo
Maximum Transmission Unit (MTU) could potentially be as large as the
payload of the largest valid UDP datagram (65507 bytes). However,
since Teredo packets can travel on unpredictable paths over the
Internet, it is best to contain this MTU to a small size, in order
to minimize the effect of IPv4 packet fragmentation and reassembly.
The default link MTU assumed by a host, and the link MTU supplied by
a Teredo server during router advertisement SHOULD normally be set
to the minimum IPv6 MTU size of 1280 bytes [RFC2460].

Huitema [Page 14]

INTERNET DRAFT Teredo June 9, 2004

Teredo implementations SHOULD NOT set the Don't Fragment (DF) bit of
the encapsulating IPv4 header.

5.2 Teredo Client specification

Before using the Teredo service, the client must be configured with:

- the IPv4 address of a server.

If secure discovery is required, the client must also be configured
with:

- a client identifier,
- a secret value, shared with the server,
- an authentication algorithm, shared with the server.

A Teredo client expects to exchange IPv6 packets through an UDP
port, the Teredo service port. The client will maintain the
following variables that reflect the state of the Teredo service:

- Teredo connectivity status,
- Mapped address and port number associated with the Teredo service
port,
- Teredo IPv6 prefix associated with the Teredo service port,
- Teredo IPv6 address or addresses derived from the prefix,
- Link local address,
- Date and time of the last interaction with the Teredo server,
- Teredo Refresh Interval,
- Randomized Refresh Interval,
- List of recent Teredo peers.

Before sending any packets, the client must perform the Teredo
qualification procedure, which determines the Teredo connectivity
status, the mapped address and port number, and the Teredo IPv6
prefix; it should then perform the cone NAT determination procedure,

Huitema [Page 12]

INTERNET DRAFT Teredo February 5, 2004
which determines the cone NAT status and may alter the value of the
prefix. If the qualification is successful, the client may use the
Teredo service port to transmit and receive IPv6 packets, according
to the transmission and reception procedures; these procedures. These procedures use
the "list of recent peers". For each peer, the list contains:

- The IPv6 address of the peer,
- The mapped IPv4 address and mapped UDP port of the peer,
- The status of the mapped address, i.e. trusted or not,
- The value of the last "nonce" sent to the peer,
- The date and time of the last reception from the peer,
- The date and time of the last transmission to the peer,
- The number of bubbles transmitted to the peer.

The list of peers is used to enable the transmission of IPv6 packets
by using a "direct path" for the IPv6 packets. The list of peers
could grow over time. Clients should implement a list management

Huitema [Page 15]

INTERNET DRAFT Teredo June 9, 2004

strategy, for example deleting the least recently used entries.
Clients should make sure that the list has a sufficient size, to
avoid unnecessary exchanges of bubbles.

The client must regularly perform the maintenance procedure in order
to guarantee that the Teredo service port remains usable; the need
to use this procedure or not depends on the delay since the last
interaction with the Teredo server. The refresh procedure takes as a
parameter the "Teredo refresh interval". This parameter is initially
set to 30 seconds; it can be updated as a result of the optional
"interval determination procedure." The randomized refresh interval
is set to a value randomly chosen between 75% and 100% of the
refresh interval.

In order to avoid triangle routing for stations that are located
behind the same NAT, the Teredo clients MAY use the optional local
client discovery procedure defined in section 5.2.8.

5.2.1 Qualification procedure

The purpose of the qualification procedure is to establish the
status of the local IPv4 connection, and to determine the Teredo
IPv6 client prefix of the local Teredo interface. The procedure
starts when the service is in the "initial" state, and results in a
"qualified" state if successful, and in an "off-line" state if
unsuccessful.

Huitema [Page 13] 16]

INTERNET DRAFT Teredo February 5, June 9, 2004

/---------\
| Initial |
\---------/
|
+----+----+
+----+----------+
| Set C=1 ConeBit=1 |
+----+----+
+----+----------+
|
+<-----------------------------------------+
+<-------------------------------------------+
| |
+----+----+ |
| Start |<------+ |
+----+----+ | +----+----+ +----------+----+
| | | Set C=0 ConeBit=0 |
v | +----+----+ +----------+----+
/---------\ Timer | N ^
|Starting |-------+ N attempts /----------\ Yes |
\---------/------------------->| C /----------------\Yes|
\---------/----------------->| ConeBit == 1 ? |-----+ |---+
| Response \----------/ \----------------/
| | No
V V
/---------\
/---------------\ Yes /----------\
| C ConeBit == 0? 1? |---------+ | Off line |
\---------/
\---------------/ | \----------/
No | v
| /----------\
| | Cone NAT |
+-----+-----+ \----------/
| New Server|
+-----+-----+
|
+----+----+
| Start |<------+
+----+----+ |
| |
v |
/---------\ Timer |
|Starting |-------+ N attempts /----------\
\---------/------------------->| Off line |
| Response \----------/
|
V
/------------\ No /---------------\
| Same port? |-------->| Symmetric NAT |
\------------/ \---------------/
| Yes
V
/-----------------\
/----------------------\
| Restricted Cone NAT |
\-----------------/
\----------------------/

Huitema [Page 14] 17]

INTERNET DRAFT Teredo February 5, June 9, 2004

Initially, the Teredo connectivity status is set to "Initial".

When the interface is initialized, the system first performs the
"start action" by sending a Router Solicitation message, as defined
in [RFC2461]. The client picks a link-local address and uses it as
the IPv6 source of the message; the "cone" bit in the address is set
to 1; 1 (see section 4 for the address format); the IPv6 destination of
the RS is the all-routers multicast address; the packet will be sent
over UDP from the service port to the Teredo server's IPv4 address
and Teredo UDP port. The connectivity status moves then to
"Starting".

In the starting state, the client waits for a router advertisement
from the Teredo server. If no response comes within a time-out T,
the client should repeat the start action, by resending the Router
Solicitation message. If no response has arrived after N
repetitions, the client concludes that it is not behind a cone NAT.
It sets the "cone" bit to 0, and repeats the procedure. If after N
other timer expirations and retransmissions there is still no
response, the client concludes that it cannot use UDP, and that the
Teredo service is not available; the status is set to "Off-line." In
accordance with [RFC2461], the default time-out value is set to T=4
seconds, and the maximum number of repetitions is set to N=3.

If a response arrives, the client checks that the response contains
an origin indication and a valid router advertisement as defined in
[RFC2461], that the IPv6 destination address is equal to the link-
local address used in the router solicitation, and that the router
advertisement contains exactly one advertised Prefix Information
option. This prefix should be a valid Teredo IPv6 server prefix: the
first 32 bits should contain the global Teredo IPv6 service prefix,
and the next 32 bits should contain the server's IPv4 address. If
this is the case, the client learns the Teredo mapped address and
Teredo mapped port from the origin indication. The IPv6 source
address of the Router Advertisement is a link-local server address
of the Teredo server. (Responses that are not valid advertisements
are simply discarded.)

If the client has received an RA with the "Cone" bit in the IPv6
destination address set to 1, it is behind a cone NAT and is fully
qualified. If the RA is received with the Cone bit set to 0, the
client does not know whether the local NAT is restricted or
symmetric. The client selects a secondary IPv4 server address, and
repeats the procedure, the cone bit remaining to the value zero. If
the client does not receive a response, it detects that the service
is not usable. If the client receives a response, it compares the
mapped address and mapped port in this second response to the first
received values. If the values are different, the client detects a
symmetric NAT: it cannot use the Teredo service. If the values are
the same, the client is detects a port-restricted or restricted cone
NAT: the client is qualified to use the service. (Teredo operates

Huitema [Page 18]

INTERNET DRAFT Teredo June 9, 2004

the same way for restricted and port-restricted NAT.)

If the client is qualified, it builds a Teredo IPv6 address using

Huitema [Page 15]

INTERNET DRAFT Teredo February 5, 2004
the Teredo IPv6 server prefix learned from the RA and the obfuscated
values of the UDP port and IPv4 address learned from the origin
indication. The cone bit should be set to the value used to receive
the RA, i.e. 1 if the client is behind a cone NAT, 0 otherwise. The
client can start using the Teredo service.

5.2.2 Secure qualification

The client may be required to perform secured qualification. The
client will perform exactly the algorithm described in 5.2.1, but it
will incorporate an authentication encapsulation in the UDP packet
carrying the router solicitation message, and it will verify the
presence of a valid authentication parameter in the UDP message that
carries the router advertisement provided by the sender.

In these packets, the nonce value is chosen by the client, and is
repeated in the response from the server; the client identifier is a
value with which the client was configured.

A first level of protection is provided by just checking that the
value of the nonce in the response matches the value initially sent
by the client. If no other protection is used, the authentication
payload does not contain any identifier or authentication field; the
ID-len and AU-len fields are set to a null value. When stronger
protection is required, the authentication payload contains the
identifier and location fields, as explained in the following
paragraphs.

The confirmation byte is set to 0 by the client. A null value
returned by the server indicates that the client's key is still
valid; a non-null value indicates that the client should obtain a
new key.

The authentication value is computed according to an algorithm
agreed upon by client and server. To maximize interoperability, this
specification defines a default algorithm in which the
authentication value is computed according the HMAC specification
[RFC2104] using the following specifications:

- the hash function shall be the MD5 function [RFC1321].
- the secret value shall be the shared secret with which the client
was configured

The clear text to be protected includes:

- the nonce value,
- the confirmation byte,
- the origin indication encapsulation, if it is present,
- the IPv6 packet.

Huitema [Page 19]

INTERNET DRAFT Teredo June 9, 2004

If the HMAC verification fails, the packet is silently discarded.

5.2.3 Packet reception

The Teredo client receives packets over the Teredo interface. The
role of the packet reception procedure, besides receiving packets,
is to maintain the date and time of the last interaction with the
Teredo server, and the "list of recent peers."

When a UDP packet is received over the Teredo service port, the
Teredo client checks that it is encoded according to the packet
encoding rules defined in 5.1.1, and that it contains either a valid
IPv6 packet as specified in [RFC2460], packet, or the combination of a valid origin indication
encapsulation and a valid IPv6 packet, possibly protected by a valid
authentication encapsulation. If this is not the case, case, the packet is
silently discarded.

An IPv6 packet is deemed valid if it conforms to [RFC2460]: the
protocol identifier should indicate an IPv6 packet and the payload
length should be consistent with the length of the UDP datagram in
which the packet is silently discarded.

Huitema [Page 16]

INTERNET DRAFT encapsulated. In addition, the client should
check that the IPv6 destination address correspond to its own Teredo February 5, 2004
address.

Then, the Teredo client examines the IPv4 source address and UDP
port number from which the packet is received. If these values match
the IPv4 address of the server and the Teredo port, the client
updates the "date and time of the last interaction with the Teredo
server" to the current date and time; if an origin indication is
present, the client should perform the "direct IPv6 connectivity
test" described in section 5.2.9.

If the values are different, the client examines the IPv6 source
address of the packet:

1) If there is an entry for the source IPv6 address in the list of
peers whose status is trusted, the client compares the mapped IPv4
address and mapped port in the entry with the source IPv4 address
and source port of the packet. If the values match, the packet
should be is
accepted; the date and time of the last reception from the peer should be is
updated.

2) If there is an entry for the source IPv6 address in the list of
peers whose status is not trusted, the client checks whether the
packet is an ICMPv6 echo reply. If this is the case, and if the
content
ICMPv6 data of the reply matches the "nonce" stored in the peer
entry, the packet should be accepted; the status of the entry should
be changed to "trusted", the mapped IPv4 and mapped port in the
entry should be set to the source IPv4 address and source port from
which the packet was received, and the date and time of the last
reception from the peer should be updated; any packet queued for

Huitema [Page 20]

INTERNET DRAFT Teredo June 9, 2004

this IPv6 peer (as specified in 5.2.4) should be de-queued and
forwarded to the newly learned IPv4 address and UDP port.

3) If the source IPv6 address is a Teredo address, the client
compares the mapped IPv4 address and mapped port in the source
address with the source IPv4 address and source port of the packet.
If the values match, the client MUST create a peer entry for the
IPv6 source address in the list of peers; it should update the entry
if one already existed; the mapped IPv4 address and mapped port in
the entry should be set to the value from which the packet was
received, and the status should be set to "trusted". If a new entry
is created, the last transmission date is set to 30 seconds before
the current date, and the number of bubbles to zero. If the packet
is a bubble, it should be discarded after this processing;
otherwise, the packet should be accepted. In all cases, the client
must de-queue and forward any packet queued for that destination.

4) If the source IPv6 address is a Teredo address, and the mapped
IPv4 address and mapped port in the source address do not match the
source IPv4 address and source port of the packet, the client checks
whether the is an existing "local" entry for that IPv6 address. If
there is such an entry, and if the local client
compares the mapped IPv4 address and local mapped port
indicated in that entry match the source
address with the source IPv4 address and source port of the packet, packet.
If the values match, the client updates MUST create a peer entry for the
IPv6 source address in the list of peers; it should update the entry
if one already existed; the mapped IPv4 address and mapped port in
the entry should be set to the value from which the packet was
received, and the "local" entry, whose

Huitema [Page 17]

INTERNET DRAFT Teredo February 5, 2004 status should be set to "trusted". If a new entry
is created, the last transmission date is set to 30 seconds before
the current date, and the number of bubbles to zero. If the packet
is a bubble, it should be discarded after this processing;
otherwise, the packet should be accepted. In all cases, the client
must de-queue and forward any packet queued for that destination.

4) If the IPv4 destination address through which the packet was
received is the Teredo IPv4 Discovery Address, the source address is
a valid Teredo address, and the destination address is the "all
nodes on link" multicast address, the packet should be treated as a
local discovery bubble. If no local entry already existed for the
source address, a new one is created, but its status is set to "not
trusted". The client SHOULD reply with a unicast Teredo bubble, sent
to the source IPv4 address and source port of the local discovery
bubble; the IPv6 source address of the bubble will be set to local
Teredo IPv6 address; the IPv6 destination address of the bubble
should be set to the IPv6 source address of the local discovery
bubble. (Clients that do not implement the optional local discovery
procedure will not process local discovery bubbles.)

5) If the source IPv6 address is a Teredo address, and the mapped
IPv4 address and mapped port in the source address do not match the
source IPv4 address and source port of the packet, the client checks
whether there is an existing "local" entry for that IPv6 address. If
there is such an entry, and if the local IPv4 address and local port
indicated in that entry match the source IPv4 address and source
port of the packet, the client updates the "local" entry, whose
status should be set to "trusted". If the packet is a bubble, it
should be discarded after this processing; otherwise, the packet
should be accepted. In all cases, the client must de-queue and
forward any packet queued for that destination.

6) In the other cases, the packet may be accepted, but the client
should be conscious that the source address may be spoofed; before
processing the packet, the client should perform the "direct IPv6
connectivity test" described in section 5.2.9.

Whatever the IPv4 source address and UDP source port, the client
that receives an IPv6 packet MAY send a Teredo bubble towards that
target, as specified in section 5.2.6.

Huitema [Page 21]

INTERNET DRAFT Teredo June 9, 2004

5.2.4 Packet transmission

When a Teredo client has to transmit a packet over a Teredo
interface, it examines the destination IPv6 address. The client
checks first if there is an entry for this IPv6 address in the list
of recent Teredo peers, and if the entry is still valid: an entry
associated with a local peer is valid if the last reception date and
time associated with that list entry is less that 30 seconds from
the current time; an entry associated with a non-local peer is valid
if the last reception date and time associated with that list entry
is less that 30 seconds from the current time. (Local peer entries
can only be present if the client uses the local discovery procedure
discussed in section 5.2.8.)

The client then performs the following:

1) If there is an entry for that IPv6 address in the list of peers,
and if the status of the entry is set to "trusted", the IPv6 packet
should be sent over UDP to the IPv4 address and UDP port specified
in the entry. The client updates the date of last transmission in
the peer entry.

2) If the destination is not a Teredo IPv6 address, the packet is
queued, and the client performs the "direct IPv6 connectivity test"
described in section 5.2.8. 5.2.9. The packet will be de-queued and

Huitema [Page 18]

INTERNET DRAFT Teredo February 5, 2004
forwarded if this procedure completes successfully. If the direct
IPv6 connectivity test fails to complete within a 2 second time-out,
it should be repeated up to 3 times.

3) If the destination is the Teredo IPv6 address of a local peer
(i.e. a Teredo address from which a local discovery bubble has been
received in the last 600 seconds), the packet is queued. The client
sends a unicast Teredo bubble to the local IPv4 address and local
port specified in the entry, and a local Teredo bubble to the Teredo
IPv4 discovery address.

4) If the destination is a Teredo IPv6 address in which the cone bit
is set to 1, the packet is sent over UDP to the mapped IPv4 address
and mapped UDP port extracted from that IPv6 address.

5) If the destination is a Teredo IPv6 address in which the cone bit
is set to 0, the packet is queued. If the client is not located
behind a cone NAT, it sends a direct bubble to the Teredo
destination, i.e. to the mapped IP address and mapped port of the
destination. In all cases, the client sends an indirect bubble to
the Teredo destination, sending it over UDP to the server address
and to the Teredo port. The packet will be de-queued and forwarded
when the client receives a bubble or another packet directly from
this Teredo peer. If no bubble is received within a 2 second time-
out, the bubble transmission should be repeated up to 3 times.

In cases 4 and 5, before sending a packet over UDP, the client MUST

Huitema [Page 22]

INTERNET DRAFT Teredo June 9, 2004

check that the IPv4 destination address is in the format of a global
unicast address; if this is not the case, the packet MUST be
silently discarded. (Note that a packet can legitimately be sent to
a non-global unicast address in case 1, as a result of the local
discovery procedure.)

5.2.5 Maintenance

The Teredo client must ensure that the mappings that it uses remain
valid. It does so by checking that packets are regularly received
from the Teredo server.

At regular intervals, the client MUST check the "date and time of
the last interaction with the Teredo server", to ensure that at
least one packet has been received in the last Randomized Teredo
Refresh Interval. If this is not the case, the client SHOULD send a
router solicitation message to the server, as specified in 5.2.1;
the client should use the same value of the "cone" bit that resulted
in the reception of an RA during the qualification procedure.

When the router advertisement is received, the client SHOULD check
its validity as specified in 5.2.1; invalid advertisements are
silently discarded. If the advertisement is valid, the client MUST
check that the mapped address and port correspond to the current
Teredo address. If this is not the case, the mapping has changed;

Huitema [Page 19]

INTERNET DRAFT Teredo February 5, 2004
the client must mark the old address as invalid, and start using the
new address.

5.2.6 Sending Teredo Bubbles

The Teredo client may have to send a bubble towards another Teredo
client, either after a packet reception or after a transmission
attempt, as explained in sections 5.2.3 and 5.2.4. There are two
kinds of bubbles: direct bubbles, that are sent directly to the
mapped IPv4 address and mapped UDP port of the peer, and indirect
bubbles that are sent through the Teredo server of the peer.

When a Teredo client attempts to send a direct bubble, it extracts
the mapped IPv4 address and mapped UDP port from the Teredo IPv6
address of the target. It then checks whether there is already an
entry for this IPv6 address in the current list of peers. If there
is no entry, the client MUST create a new list entry for the
address, setting the last reception date and the last transmission
date to 30 seconds before the current date, and the number of
bubbles to zero.

When a Teredo client attempts to send an indirect bubble, it
extracts the Teredo server IPv4 address from the Teredo prefix of
the IPv6 address of the target (different clients may be using
different servers); the bubble will be sent to that IPv4 address and
the Teredo UDP port.

Huitema [Page 23]

INTERNET DRAFT Teredo June 9, 2004

Bubbles may be lost in transit, and it is reasonable to enhance the
reliability of the Teredo service by allowing multiple
transmissions; however, bubbles will also be lost systematically in
certain NAT configurations. In order to strike a balance between
reliability and unnecessary retransmissions, we specify the
following:

- The client MUST NOT send a bubble if the last transmission date
and time is less than 2 seconds before the current date and time;

- The client MUST NOT send a bubble if it has already sent 4 bubbles
to the peer in the last 300 seconds without receiving a direct
response.

In the other cases, the client MAY proceed with the transmission of
the bubble. When transmitting the bubble, the client MUST update the
last transmission date and time to that peer, and must also
increment the number of transmitted bubbles.

5.2.7 Optional Refresh Interval Determination Procedure

In addition to the regular client resources described in the
beginning of this section, the refresh interval determination
procedure uses an additional UDP port, the Teredo secondary port,
and the following variables:

- Teredo secondary connectivity status,
- Mapped address and port number of the Teredo secondary port,
- Teredo secondary IPv6 prefix associated with the secondary port,
- Teredo secondary IPv6 address derived from this prefix,
- Date and time of the last interaction on the secondary port,
- Maximum Teredo Refresh Interval.
- Candidate Teredo Refresh Interval.

The secondary connectivity status, mapped address and prefix are

Huitema [Page 20]

INTERNET DRAFT Teredo February 5, 2004
determined by running the qualification procedure on the secondary
port. When the client uses the interval determination procedure, the
qualification procedure MUST be run for the secondary port
immediately after running it on the service port. If the secondary
qualification fails, the interval determination procedure will not be
used, and the interval value will remain to the default value, 30
seconds. If the secondary qualification succeeds, the maximum refresh
interval is set to 120 seconds, and the candidate Teredo refresh
interval is set to 60 seconds, i.e. twice the Teredo refresh
interval. The procedure is then performed at regular intervals, until
it concludes:

1) wait until the candidate refresh interval is elapsed after the
last interaction on the secondary port;

2) send a Teredo bubble to the Teredo secondary IPv6 address, through
the service port.

Huitema [Page 24]

INTERNET DRAFT Teredo June 9, 2004

3) wait for reception of the bubble on the secondary port. If a timer
of 2 seconds elapses without reception, repeat step 2 at most three
times. If there is still no reception, the candidate has failed; if
there is a reception, the candidate has succeeded.

4) if the candidate has succeeded, set the Teredo refresh interval to
the candidate value, and set a new candidate value to the minimum of
twice the new refresh interval, or the average of the refresh
interval and the maximum refresh interval.

5) if the candidate has failed, set the maximum refresh interval to
the candidate value. If the current refresh interval is larger than
or equal to 75% of the maximum, the determination procedure has
concluded; otherwise, set a new candidate value to the average of the
refresh interval and the maximum refresh interval.

6) if the procedure has not concluded, perform the maintenance
procedure on the secondary port, which will reset the date and time
of the last interaction on the secondary port, and may result in the
allocation of a new Teredo secondary IPv6 address; this would not
affect the values of the refresh interval, candidate interval or
maximum refresh interval.

The secondary port MUST NOT be used for any other purpose than the
interval determination procedure. If a spurious packet is received on
the secondary port, the client SHOULD repeat It should be closed when the maintenance
procedure on this port and reset the date and time of the last
interaction on the secondary port. ends.

5.2.8 Optional local client discovery procedure

It is desirable to enable direct communication between Teredo
clients that are located behind the same NAT, without forcing a
systematic relay through a Teredo server. It is hard to design a

Huitema [Page 21]

INTERNET DRAFT Teredo February 5, 2004
general solution to this problem, but we can design a partial
solution when the Teredo clients are connected through IPv4 to the
same link.

A Teredo client who wishes to enable local discovery SHOULD join the
IPv4 multicast group identified by Teredo IPv4 Discovery Address.
The client SHOULD wait for discovery bubbles to be received on the
Teredo IPv4 Discovery
Address, and should Address. The client SHOULD send local
discovery bubbles to the Teredo IPv4 Discovery Address at random
intervals, uniformly distributed between 200 and 300 seconds. A
local Teredo bubble has the following characteristics:

- IPv4 source address: the IPv4 address of the sender

- IPv4 destination address: the Teredo IPv4 Discovery Address

- IPv4 ttl: 1

- UDP source port: the Teredo service port of the sender

Huitema [Page 25]

INTERNET DRAFT Teredo June 9, 2004

- UDP destination port: the Teredo UDP port

- UDP payload: a minimal IPv6 packet, as follows

- IPv6 source: the global Teredo IPv6 address of the sender

- IPv6 destination: the all-nodes on-link multicast address

- IPv6 payload type: 59 (No Next Header, as per [RFC2460])

- IPv6 payload length: 0

- IPv6 hop limit: 1

The local discovery procedure carries a denial of service risk, as
malevolent nodes could send fake bubbles to unsuspecting parties,
and thus capture the traffic originating from these parties. The
risk is mitigated by the filtering rules described in section 5.2.5,
and also by "link only" multicast scope of the Teredo IPv4 Discovery
Address, which implies that packets sent to this address will not be
forwarded across routers.

To benefit from the "link only multicast" protection, the clients
should silently discard all local discovery bubbles that are
received over a unicast address. To further mitigate the denial of
service risk, the client MUST silently discard all local discovery
bubbles whose IPv6 source address is not a well-formed Teredo IPv6
address, or whose IPv4 source address does not belong to the local
IPv4 subnet; the client MAY decide to silently discard all local
discovery bubbles whose Teredo IPv6 address do not include the same
mapped IPv4 address as its own.

If the bubble is accepted, the client checks whether there is an

Huitema [Page 22]

INTERNET DRAFT Teredo February 5, 2004
entry in the list of recent peers that correspond to the mapped IPv4
address and mapped UDP port associated with the source IPv6 address
of the bubble. If there is such an entry, the client MUST update the
local peer address and local peer port parameters to reflect the
IPv4 source address and UDP source port of the bubble. If there is
no entry, the client MUST create one, setting the local peer address
and local peer port parameters to reflect the IPv4 source address
and UDP source port of the bubble bubble, the last reception date to the
current date and time, the last transmission date to 30 seconds
before the current date, and the number of bubbles to zero; the
state of the entry is set to "not trusted".

Upon reception of a discovery bubble, clients reply with a unicast
bubble as specified in section 5.2.3.

5.2.9 Direct IPv6 connectivity test

The Teredo procedures are designed to enable direct connections

Huitema [Page 26]

INTERNET DRAFT Teredo June 9, 2004

between a Teredo host and a Teredo relay. Teredo hosts located
behind a cone NAT will receive packets directly from relays; other
Teredo hosts will learn the original addresses and UDP ports of
third parties through the local Teredo server. In all of these
cases, there is a risk that the IPv6 address of the source be
spoofed by a malevolent party. Teredo hosts must make two decisions,
whether to accept the packet for local processing, and whether to
transmit further packets to the IPv6 address through the newly
learned IPv4 address and UDP port. The basic rule is that the hosts
should be generous in what they accept, and careful in what they
send. Refusing to accept packets due to spoofing concerns would
compromise connectivity, and should only be done when there is a
near certainty that the source address is spoofed; on the other
hand, sending packets to the wrong address should be avoided.

When it the client wants to send a packet to an IPv6 node on the IPv6
Internet,
the client it should check whether a valid peer entry already exists
for the IPv6 address of the destination. If this is not the case,
the client will pick a random number (a nonce) and format an ICMPv6
Echo Request message whose source is the local Teredo address, whose
destination is the address of the IPv6 node, and whose Data field is
set to the nonce. The nonce value and the date at which the packet
was sent will be documented in a provisional peer entry for the IPV6
destination. The ICMPv6 packet will then be sent encapsulated in a
UDP packet bound destined to the local Teredo server IPv4 address, and to the
Teredo port. The rules of section 5.2.3 specify how the reception of reply to
this packet will be processed.

5.2.10 Working around symmetric NAT

The client procedures are designed to enable IPv6 connectivity
through the most common types of NAT, which are commonly called
"Cone NAT" and "restricted cone NAT" [RFC3489]. Some NAT employ a
different designs; design; they are often called "symmetric NAT". The

Huitema [Page 23]

INTERNET DRAFT Teredo February 5, 2004
qualification algorithm in section 5.2.1 will not succeed when the
local NAT is a symmetric NAT.

It is in

In many cases cases, it is possible to work around the limitations of
these NAT by explicitly reserving a UDP port for Teredo service on a
client, using a function often called "DMZ" in the NAT's manual.
This port will become the "service port" used by the Teredo hosts.
The implementers of Teredo functions in hosts must make sure that
the value of the service port can be explicitly provisioned, so that
user can provision the same value in the host and in the NAT.

The reservation procedure guarantees that the port mapping will
remain the same for all destinations. After the explicit
reservation, the qualification algorithm in section 5.2.1 will
succeed, and the Teredo client will behave as if behind a "cone
NAT".

When different clients use Teredo behind a single symmetric NAT,

Huitema [Page 27]

INTERNET DRAFT Teredo June 9, 2004

each of these clients must reserve and use a different service port.

5.3 Teredo Server specification

The Teredo server is designed to be stateless. The Teredo server
waits for incoming UDP packets at the Teredo Port, using the IPv4
address that has been selected for the service. In addition, the
server is able to receive and transmit some packets using a
different IPv4 address and a different port number.

The Teredo server acts as an IPv6 router. As such, it will receive
Router Solicitation messages, to which it will respond with Router
Advertisement messages as explained in section 5.3.2; it may also
receive other packets, for example ICMPv6 messages, messages and Teredo
bubbles, which are processed according to the IPv6 specification.

5.3.1 Processing

By default, the routing functions of the Teredo server are limited.
Teredo servers are expected to relay Teredo bubbles and ICMPv6
messages, but they are not expected to relay other types of IPv6 packets

Upon reception
packets. Operators may however decide to combine

5.3.1 Processing of a packet on the Teredo port, the Teredo server
will first check that the UDP payload contains a valid IPv6 packet;
if this is not the case, the packet will be silently discarded. packets

Before processing the packet, the Teredo server MUST check the
validity of the encapsulated IPv6 source address, the IPv4 source
address and the UDP source port:

1) If the UDP content is not a well formed Teredo IPv6 packet, as
defined in section 5.1.1, the packet MUST be silently discarded.

2) If the UDP packet is not a Teredo bubble or an ICMPv6 message, it should
SHOULD be discarded. (The packet may be processed if the Teredo
server also operates as a Teredo relay, as explained in section
5.4.)

3) If the IPv4 source address is not in the format of a global
unicast address, the packet MUST be silently discarded.

4) If the IPv6 source address is an IPv6 link-local address, the

Huitema [Page 24]

INTERNET DRAFT Teredo February 5, 2004
IPv6 destination address is the link-local scope all routers
multicast address (FF02::2), and the packet contains an ICMPv6
Router Solicitation message, the packet SHOULD MUST be accepted; it MUST
be discarded if the server requires secure qualification and the
authentication encapsulation is absent or cannot be verified. verification fails.

5) If the IPv6 source address is a Teredo IPv6 address, and if the
IPv4 address and UDP port embedded in that address match the IPv4
source address and UDP source port, the packet SHOULD be
accepted.

6) If the IPv6 source address is not a Teredo IPv6 address, and if
the IPv6 destination address is a Teredo address allocated

Huitema [Page 28]

INTERNET DRAFT Teredo June 9, 2004

through this server, the packet SHOULD be accepted.

7) In all other cases, the packet MUST be silently discarded.

The Teredo server will then check the IPv6 destination address of
the encapsulated IPv6 packet. packet:

If the IPv6 destination address is the link-local scope all routers
multicast address (FF02::2), or the link-local address of the
server, the Teredo server processes the packet; it may have to
process Router Solicitation messages and ICMPv6 Echo Request
messages.

If the destination IPv6 address is not a global scope IPv6 address,
the packet MUST NOT be forwarded.

If the destination address is not a Teredo IPv6 address, address the packet
should be relayed to the IPv6 Internet using regular IPv6 routing.

If the IPv6 destination address is a valid Teredo IPv6 address, address as
defined in 2.13, the Teredo Server MUST check that the IPv4 address
derived from this IPv6 address is in the format of a global unicast
address; if this is not the case, the packet MUST be silently
discarded.

If the address is valid, the Teredo server encapsulates the IPv6
packet in a new UDP datagram, in which the following parameters are
set:

- The destination IPv4 address is derived from the IPv6 destination.

- The source IPv4 address is the server's Teredo server IPv4 address.

- The destination UDP port is derived from the IPv6 destination.

- The source UDP port is set to the Teredo UDP Port.

If the destination IPv6 address is a Teredo client whose address is
serviced by this specific server, the server should insert an origin
indication in the first bytes of the UDP payload, as specified in
section 5.1.1.

Huitema [Page 25]

INTERNET DRAFT (To verify that the client is served by this server,
the server compares bits 32-63 of the client's Teredo February 5, 2004 IPv6 address
to the server's IPv4 address.)

5.3.2 Processing of router solicitations

When the Teredo server receives a Router Solicitation message (RS,
[RFC2641]), it retains the IPv4 address and UDP port from which the
solicitation was received; these become the Teredo mapped address
and Teredo mapped port of the client. The router uses these values
to compose the origin indication encapsulation that will be sent
with the response to the solicitation.

Huitema [Page 29]

INTERNET DRAFT Teredo June 9, 2004

The Teredo server responds to the router solicitation by sending a
Router Advertisement message [RFC2641]. The router advertisement
MUST advertise the Teredo IPv6 prefix composed from the service
prefix and the server's IPv4 address. The IPv6 source address should
be set to a Teredo link-local server address associated to the local
interface.
interface; this address is derived from the IPv4 address of the
server and from the Teredo port, as specified in section 4; the C
bit is set to 1. The IPv6 destination address is set to the IPv6
source address of the RS. The Router Advertisement message must be
sent over UDP to the Teredo mapped address and Teredo mapped port of
the client; the IPv4 source address and UDP source port should be
set to the server's IPv4 address and Teredo Port. If the cone bit of
the client's IPv6 address is set to 1, the RA must be sent from a
different IPv4 source address than the server address over which the
RS was received; if the cone bit is set to zero, the response must
be sent back from the same address.

Before sending the packet, the Teredo server MUST check that the
IPv4 destination address is in the format of a global unicast
address; if this is not the case, the packet MUST be silently
discarded.

If secure qualification is required, the server must insert a valid
authentication parameter in the UDP packet carrying the router
advertisement. The client identifier and the nonce value used in the
authentication parameter must be the same identifier as received in
the router solicitation; the confirmation byte should be set to zero
if the client identifier is still valid, and a non-null value
otherwise; the authentication value should be computed using the
secret that corresponds to the client identifier.

5.4 Teredo Relay specification

Teredo relays are IPv6 routers that advertise reachability of reachability of the
Teredo service IPv6 prefix through the IPv6 routing protocols. (A
minimal Teredo relay may serve just a local host, and would not
advertise the
Teredo service IPv6 prefix through the IPv6 routing protocols. beyond this host.) Teredo relays will receive
IPv6 packets bound to Teredo clients. Teredo relays should be able
to receive packets sent over IPv4 and UDP by Teredo clients; they
may apply filtering rules, e.g. only accept packets from Teredo
clients if they have previously sent traffic to these Teredo
clients.

The receiving and sending rules used by Teredo relays are very
similar to those of Teredo clients. Teredo relays must use a Teredo
service port to transmit packets to Teredo clients; they must
maintain a "list of peers", identical to the list of peers

Huitema [Page 26]

INTERNET DRAFT Teredo February 5, 2004
maintained by Teredo clients. However, Teredo relays do not have to
perform the qualification procedure.

5.4.1 Transmission by relays to Teredo clients

Huitema [Page 30]

INTERNET DRAFT Teredo June 9, 2004

When a Teredo relay has to transmit a packet to a Teredo client, it
examines the destination IPv6 address. By definition, the Teredo
relays will only send over UDP IPv6 packets whose IPv6 destination
address is a valid Teredo IPv6 address. Before processing these
packets, the Teredo Server MUST check that the IPv4 destination
address embedded in the Teredo IPv6 address is in the format of a
global unicast address; if this is not the case, the packet MUST be
silently discarded.

The relay then checks if there is an entry for this IPv6 address in
the list of recent Teredo peers, and if the entry is still valid.
The relay then performs the following:

1) If there is an entry for that IPv6 address in the list of peers,
and if the status of the entry is set to "trusted", the IPv6 packet
should be sent over UDP to the mapped IPv4 address and mapped UDP
port of the entry. The client updates the date of last transmission
in the peer entry.

2) If the destination is a Teredo IPv6 address in which the cone bit
is set to 1, the packet is sent over UDP to the mapped IPv4 address
and mapped UDP port extracted from that IPv6 address.

3) If the destination is a Teredo IPv6 address in which the cone bit
is set to 0, destination IPv6 address. By definition, the packet is queued. The Teredo relay creates a bubble
relays will only send over UDP IPv6 packets whose source IPv6 destination
address is set to a local valid Teredo IPv6 address, and whose address.

Before processing these packets, the Teredo Server MUST check that
the IPv4 destination address is set to embedded in the Teredo IPv6 address of the
packet's destination. The bubble is sent to the non-null server
address corresponding to
in the Teredo destination. The packet will be
de-queued and forwarded when format of a bubble or another packet will be
received from this IPv6 global unicast address; if no such packet this is received
before a time-out of 2 seconds, the Teredo relay may repeat not the
bubble, up to three times.

In cases 2 and 3, case,
the Teredo packet MUST be silently discarded.

The relay should create a peer then checks if there is an entry for
the this IPv6 address; the entry status is marked as trusted in case 2
(cone NAT), not trusted address in case 3. In case 3, if the Teredo relay
happens to be located behind a non-cone NAT, it should also send a
bubble directly to
the mapped IPv4 address and mapped port number list of
the recent Teredo destination; this will "open the path" for the return
bubble from peers, and if the Teredo client.

5.4.2 Reception from Teredo clients entry is still valid.
The Teredo relay may receive packets from Teredo clients; the
packets should normally only be sent by clients to which then performs the relay
previously transmitted packets, i.e. clients whose IPv6 address following:

1) If there is

Huitema [Page 27]

INTERNET DRAFT Teredo February 5, 2004

present an entry for that IPv6 address in the list of peers. Relays, like clients, use peers,
and if the status of the entry is set to "trusted", the IPv6 packet
reception procedure
should be sent over UDP to maintain the date mapped IPv4 address and time mapped UDP
port of the last
interaction with the Teredo server, and entry. The client updates the "list date of recent peers."

When a UDP packet is received over last transmission
in the Teredo service port, peer entry.

2) If the
Teredo relay checks that it contains destination is a valid Teredo IPv6 packet as
specified address in [RFC2460]. If this is not the case, which the packet cone bit
is
silently discarded.

Then, the Teredo relay examines whether set to 1, the IPv6 source address packet is a
valid Teredo address, and if sent over UDP to the mapped IPv4 address
and mapped UDP port
match extracted from that IPv6 address.

3) If the IPv4 source destination is a Teredo IPv6 address and port number from in which the packet
is received. If this cone bit
is not the case, set to 0, the packet is silently
discarded. queued. The Teredo relay then examines whether there creates a bubble
whose source address is an entry for the set to a local IPv6 source address, and whose
destination address in is set to the list Teredo IPv6 address of recent peers. If this the
packet's destination. The bubble is not sent to the
case, non-null server
address corresponding to the Teredo destination. The packet may will be silently discarded. If
de-queued and forwarded when a bubble or another packet will be
received from this IPv6 address; if no such packet is the case, the
entry status is set to "trusted"; the relay updates the "date and
time received
before a time-out of 2 seconds, the last interaction" to Teredo relay may repeat the current date
bubble, up to three times.

In cases 2 and time.

Finally, 3, the Teredo relay examines should create a peer entry for
the destination IPv6 address. If address; the
destination entry status is marked as trusted in case 2
(cone NAT), not trusted in case 3. In case 3, if the "all nodes multicast address", the packet should
be processed locally. If the destination belongs Teredo relay
happens to be located behind a range of IPv6
addresses served by the relay, non-cone NAT, it should also send a
bubble directly to the packet SHOULD be accepted, mapped IPv4 address and
forwarded to mapped port number of
the destination. In Teredo destination; this will "open the other cases, path" for the return
bubble from the packet SHOULD
be silently discarded.

5.4.3 Difference between Teredo Relays and client.

5.4.2 Reception from Teredo Servers

Because clients

The Teredo servers can relay Teredo may receive packets over IPv6, all
Teredo servers must be capable of behaving as Teredo relays. There
is however no requirement that Teredo relays behave as from Teredo
servers.

The dual-role of server and relays implies an additional complexity
for the programming of servers: clients; the processing of incoming
packets should normally only be a combination of the server processing rules defined in
5.3.1, and the relay processing rules defined in 5.4.2.

5.5 Implementation of automatic sunset

Teredo is designed as an interim transition mechanism, and it is
important that it should not be used any longer than necessary. The
"sunset" procedure will be implemented sent by Teredo clients, servers
and relays, as specified in this section.

The Teredo-capable nodes MUST NOT behave as Teredo clients if they
already have IPv6 connectivity through any other means, such as
native to which the relay
previously transmitted packets, i.e. clients whose IPv6 connectivity; in particular, nodes that have a global
IPv4 address SHOULD obtain connectivity through is
present in the 6to4 service
rather than through list of peers. Relays, like clients, use the packet
reception procedure to maintain the date and time of the last
interaction with the Teredo service. The classic reason why a server, and the "list of recent peers."

Huitema [Page 28] 31]

INTERNET DRAFT Teredo February 5, June 9, 2004

node that does not need connectivity would still enable

When a UDP packet is received over the Teredo service is to guarantee good performance when interacting with port, the
Teredo clients; however, a Teredo-capable node that has IPv4
connectivity and relay checks that has obtained it contains a valid IPv6 connectivity outside packet as
specified in [RFC2460]. If this is not the case, the packet is
silently discarded.

Then, the Teredo service MAY decide to behave as relay examines whether the IPv6 source address is a
valid Teredo relay, address, and still
obtain good performance when interacting with Teredo clients.

The Teredo servers are expected to participate in the sunset
procedure by announcing a date at which they will stop providing if the
service. This date depends on mapped IPv4 address and mapped port
match the availability of alternative
solutions to their clients, such as "dual-mode" gateways that behave
simultaneously as IPv4 NATs source address and IPv6 routers. Most Teredo servers
will not be expected to operate more than a few years, perhaps until
at most 2006.

Teredo relays are expected to have port number from which the packet
is received. If this is not the same life span as case, the packet is silently
discarded.

The Teredo
servers.

6 Use relay then examines whether there is an entry for the
IPv6 source address in the list of Teredo to implement a tunnel service

It recent peers. If this is not the
case, the packet may be desirable in some cases silently discarded. If this is the case, the
entry status is set to deploy stateful tunnel servers
instead "trusted"; the relay updates the "date and
time of the stateless Teredo servers. Tunnels servers generally
require more resources, but an advantage is that they can
potentially provide last interaction" to the users with "permanent" current date and time.

Finally, the relay examines the destination IPv6 addresses.

It is possible address. If the
destination belongs to design a tunnel server protocol that is compatible
with Teredo, in range of IPv6 addresses served by the sense that
relay, the same client could packet SHOULD be used either
in accepted and forwarded to the Teredo service or with a tunnel service.
destination. In fact, this can be
done by configuring the client with:

- The IPv4 address of a other cases, the packet SHOULD be silently
discarded.

5.4.3 Difference between Teredo server that acts as a tunnel broker
- A client identifier
- A shared secret with that server.

The Relays and Teredo client will use the secure qualification procedure, as
specified in section 5.2.2. Instead of returning a Servers

Because Teredo prefix in
the router advertisement, the server will return a globally routable
IPv6 prefix; this prefix may servers can relay Teredo packets over IPv6, all
Teredo servers must be permanently assigned to the client,
which would provide the client with a stable address. capable of behaving as Teredo relays. There
is however no requirement that Teredo relays behave as Teredo
servers.

The dual-role of server
will have to keep state, i.e. memorize the association between the
prefix assigned to the client and relays implies an additional complexity
for the mapped IPv4 address and mapped
UDP port programming of servers: the client.

The Teredo server will advertise reachability processing of incoming packets
should be a combination of the client prefix
to server processing rules defined in
5.3.1, and the IPv6 Internet. Any packet bound to relay processing rules defined in 5.4.2. (Section 5.3
only specifies the rules implemented by a pure server, not a
combination relay+server.)

5.5 Implementation of automatic sunset

Teredo is designed as an interim transition mechanism, and it is
important that prefix it should not be used any longer than necessary. The
"sunset" procedure will be
transmitted to the mapped IPv4 address implemented by Teredo clients, servers
and mapped UDP port of the
client. relays, as specified in this section.

The Teredo-capable nodes MUST NOT behave as Teredo client, when it receives the prefix, will notice clients if they
already have IPv6 connectivity through any other means, such as
native IPv6 connectivity; in particular, nodes that
this prefix is have a global IPv6 prefix, not in
IPv4 address SHOULD obtain connectivity through the 6to4 service
rather than through the form of a Teredo
prefix. service. The client will at that point recognize classic reason why a
node that it should
operate in tunnel mode. A client does not need connectivity would still enable the Teredo
service is to guarantee good performance when interacting with
Teredo clients; however, a Teredo-capable node that operates in tunnel mode will has IPv4

Huitema [Page 29] 32]

INTERNET DRAFT Teredo February 5, June 9, 2004

execute a much simpler transmission procedure: it will forward any
packet sent to

connectivity and that has obtained IPv6 connectivity outside the
Teredo interface service MAY decide to the IPv4 address behave as a Teredo relay, and still
obtain good performance when interacting with Teredo
UDP port of the server. clients.

The Teredo client will have servers are expected to perform participate in the maintenance sunset
procedure
described in section 5.2.5. The server by announcing a date at which they will receive stop providing the router
solicitation, and may notice a possible change of mapped IPv4
address and mapped UDP port that could result from
service. This date depends on the
reconfiguration availability of the mappings inside the NAT. The server should
continue advertising the same IPv6 prefix alternative
solutions to the client, and should
update the mapped their clients, such as "dual-mode" gateways that behave
simultaneously as IPv4 address NATs and mapped UDP port associated to
this prefix, if necessary.

7 Security Considerations

The main objective of IPv6 routers. Most Teredo is servers
will not be expected to provide nodes located behind a
NAT with operate more than a globally routable IPv6 address. This enables such nodes few years, perhaps until
at most 2006.

Teredo relays are expected to use IP security services such as IKE, AH or ESP. As such, we can
argue that the service has a positive effect on network security.
However, the security analysis must also envisage have the negative
effects same life span as Teredo
servers.

6 Use of the Teredo services, which we can group in four
categories: security risks of directly connecting to implement a node tunnel service

It may be desirable in some cases to the IPv6
Internet, spoofing deploy stateful tunnel servers
instead of the stateless Teredo servers. Tunnel servers generally
require more resources, but an advantage is that they can
potentially provide the users with "permanent" IPv6 addresses.

It is possible to enable design a man-in-the-middle
attack, potential attacks aimed at denying tunnel server protocol that is compatible
with Teredo, in the sense that the same client could be used either
in the Teredo service to or with a
Teredo client, and denial of service attacks against non-Teredo
participating nodes that would tunnel service. In fact, this can be enabled
done by configuring the client with:

- The IPv4 address of a Teredo service.

In server that acts as a tunnel broker
- A client identifier
- A shared secret with that server.

The Teredo client will use the following, we review secure qualification procedure, as
specified in detail these four types of issues,
and we present mitigating strategies for each section 5.2.2. Instead of them.

7.1 Opening returning a hole Teredo prefix in
the NAT

The very purpose of router advertisement, the Teredo service is to make server will return a machine
reachable through IPv6. By definition, globally routable
IPv6 prefix; this prefix may be permanently assigned to the machine using client,
which would provide the service client with a stable address. The server
will give up whatever "firewall" service was available in 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 NAT
box; all services declared locally client.

The Teredo server will become potential target advertise reachability of
attacks from the entire client prefix
to the IPv6 Internet. This may sound scary, but
there are three mitigating factors.

The first mitigating factor is the possibility to restrict some
services Any packet bound to only accept traffic from one of the limited address
scopes defined in IPv6, e.g. link-local or site-local. There is no
support for such scopes in Teredo, which implies that limited-scope
services will not be accessed through Teredo, and prefix will be restricted
transmitted to whatever other IPv6 connectivity may be available, e.g. direct
traffic with neighbors on the local link, behind mapped IPv4 address and mapped UDP port of the NAT.
client.

The second mitigating factor Teredo client, when it receives the prefix, will notice that
this prefix is a global IPv6 prefix, not in the possible use form of a "local
firewall" solution, i.e. a piece of software Teredo
prefix. The client will at that performs locally
the kind of inspection and filtering point recognize that is otherwise performed it should
operate in tunnel mode. A client that operates in tunnel mode will
execute a perimeter firewall. Using such software is recommended. much simpler transmission procedure: it will forward any
packet sent to the Teredo interface to the IPv4 address and Teredo
UDP port of the server.

Huitema [Page 30] 33]

INTERNET DRAFT Teredo February 5, June 9, 2004

The third mitigating factor, already noted, is Teredo client will have to perform the availability of
end-to-end connectivity, which allows for deployment of IP security
services such as IKE, AH or ESP. Using these services maintenance procedure
described in conjunction
with Teredo is a good policy, as it section 5.2.5. The server will protect receive the client from router
solicitation, and may notice a possible attacks in intermediate servers such as change of mapped IPv4
address and mapped UDP port that could result from the NAT,
reconfiguration of the Teredo
server, or mappings inside the Teredo relay.

7.2 Using NAT. The server should
continue advertising the Teredo service for a man-in-the-middle attack same IPv6 prefix to the client, and should
update the mapped IPv4 address and mapped UDP port associated to
this prefix, if necessary.

7 Security Considerations

The goal main objective of the Teredo service is to provide hosts nodes located behind a
NAT with a globally reachable routable 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.

The secure qualification procedure described in section 5.2.2 This enables a good protection against attacks in which a third party
tries such nodes
to spoof the server. To defeat this protection, use IP security services such as IKE, AH or ESP. As such, we can
argue that the attacker
could try to obtain service has a copy of positive effect on network security.
However, the secret shared between client and
server. The most likely way to obtain security analysis must also envisage the negative
effects of the shared secret is to listen Teredo services, which we can group in four
categories: security risks of directly connecting a node to the traffic and mount an offline dictionary attack; IPv6
Internet, spoofing of Teredo servers to protect
against this enable a man-in-the-middle
attack, potential attacks aimed at denying the secret shared between client Teredo service to a
Teredo client, and server
should denial of service attacks against non-Teredo
participating nodes that would be provisioned enabled by an automatic procedure the Teredo service.

In the following, we review in detail these four types of issues,
and contain
sufficient entropy.

Another way to defeat we present mitigating strategies for each of them.

7.1 Opening a hole in the protection afforded by NAT

The very purpose of the signature
procedure Teredo service is to mount make a complex attack, as follows:

1) Client prepares router solicitation, including authentication
header.

2) Attacker intercepts machine
reachable through IPv6. By definition, the solicitation, and somehow manages to
prevent it from reaching machine using the server, for example by mounting a short
duration DoS attack against service
will give up whatever "firewall" service was available in the server.

3) Attacker replaces NAT
box. The services that listen to the source IPv4 Teredo IPv6 address and source UDP port will become
potential target of attacks from the request by one of its own addresses and port, 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 forwards the
modified request will be restricted to whatever other
IPv6 connectivity may be available, e.g. direct traffic with
neighbors on the server.

4) Server dutifully notes the IPv4 address from which local link, behind the packet NAT.

The second mitigating factor is
received, verifies that the Authentication encapsulation is correct,
prepares possible use of a router advertisement, signs it, and sends it back to the
incoming address, "local
firewall" solution, i.e. the attacker.

5) Attacker receives the advertisement, takes note a piece of software that performs locally
the mapping,
replaces the IPv4 address kind of inspection and UDP port by the original values filtering that is otherwise performed in
a perimeter firewall. Using such software is recommended.

The third mitigating factor, already noted, is the
intercepted message, and sends the response to the client. availability of
end-to-end connectivity, which allows for deployment of IP security
services such as IKE, AH or ESP. Using these services in conjunction

Huitema [Page 31] 34]

INTERNET DRAFT Teredo February 5, June 9, 2004

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

with Teredo 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
signature scheme, since good policy, as it will protect the attacker does not do anything else than
what client from
possible attacks in intermediate servers such as the NAT legally does!

There are NAT, the Teredo
server, or the Teredo relay. (These services can however several mitigating factors that lead us to avoid
worrying too much about this attack. In practice, only be
used if the gain from parties in the
attack communication can negotiate a key, which
requires agreeing on some credentials; this is known to either deny be a hard
problem.)

7.2 Using the Teredo service to for a man-in-the-middle attack

The goal of the client, or obtain Teredo service is to provide hosts located behind a "man-in-
the-middle" position; however,
NAT with a globally reachable IPv6 address. There is a possible
class of attacks against this service in order to mount the attack, the which an attacker must be able to suppress traffic originating from somehow
intercepts the
client, i.e. router solicitation, responds with a spoofed router
advertisement, and provides a Teredo client with an incorrect
address. The attacker may have denial one of two objectives: it may try to
deny service capability; the attacker must
also be able to observe the traffic exchanged between Teredo client and
inject its own traffic 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.

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 mix, i.e. have man-in-the-middle
capacity. server. In summary, practice, the attack nonce
procedure can only be defeated if the attacker is very hard to mount, "on path".

If client and server share a secret, the gain
for secure qualification
procedure described in section 5.2.2 provides further protection. To
defeat this protection, the attacker is minimal.

7.2.1 End-to-end security

The most effective line of defense of a Teredo client is probably
not to could try to secure the Teredo service itself: even if obtain a copy of
the mapping
can be securely obtained, secret shared between client and server. The most likely way to
obtain the attacker would still be able shared secret is to listen to the traffic and send spoofed packets. Rather, mount an
offline dictionary attack; to protect against this attack, the Teredo
secret shared between client and server should realize that, because it is located behind a NAT, it is in a
situation of vulnerability; it should systematically try contain sufficient
entropy. (This probably requires some automated procedure for
provisioning the shared secret.)

If the shared secret contains sufficient entropy, the attacker would
have to encrypt
its IPv6 traffic, using IPSEC. Even if defeat the IPv4 and UDP headers are
vulnerable, one way function used to compute the use of IPSEC will effectively prevent spoofing
authentication value. This specification suggests a default
algorithm combining HMAC and
listening of MD5. If the IPv6 packets protection afforded by third parties. By providing each
client with a global IPv6 address, Teredo enables the use of IPSEC MD5
was not deemed sufficient, clients and ultimately enhances the security of these clients.

7.3 Denial of the Teredo service

Our analysis outlines five ways servers can be agree to attack use a
different algorithm, e.g. SHA1.

Another way to defeat the Teredo service. There
are counter-measures for each of these attacks.

7.3.1 Denial of service protection afforded by a rogue relay

An attack can be mounted on the IPv6 side of signature
procedure is to mount a complex attack, as follows:

1) Client prepares router solicitation, including authentication
encapsulation.

2) Attacker intercepts the service by setting
up a rogue relay, solicitation, and letting that relay advertise a route somehow manages to
prevent it from reaching the
Teredo IPv6 prefix. This is an server, for example by mounting a short
duration DoS 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 a "host local" Teredo relays are impervious to this
attack. server.

Huitema [Page 32] 35]

INTERNET DRAFT Teredo February 5, June 9, 2004

8.3.1 Denial

3) Attacker replaces the source IPv4 address and source UDP port of service by server spoofing

In section 8.2, we discussed
the use request by one of spoofed router
advertisements its own addresses and port, and forwards the
modified request to insert an attacker in the middle of server.

4) Server dutifully notes the IPv4 address from which the packet is
received, verifies that the Authentication encapsulation is correct,
prepares a Teredo
conversation. The spoofed router advertisements can also be used advertisement, signs it, and sends it back to
provision a client with an incorrect the
incoming address, pointing to either a
non existing IPv4 address or to i.e. the attacker.

5) Attacker receives the advertisement, takes note of the mapping,
replaces the IPv4 address of a third party.

The Teredo client will detect and UDP port by the attack when it fails original values in the
intercepted message, and sends the response to receive
traffic through the newly acquired IPv6 address. The attack can be
mitigated by using client.

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

7.3.2 Denial

The root cause of service by exceeding the number of peers

A Teredo client manages problem is that the NAT is, in itself, a cache of recently-used peers, which makes
it stateful. 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 possible very hard to mount devise an attack against effective
signature scheme, since the client by
provoking it to respond to packets attacker does not do anything else than
what the NAT legally does!

There are however several mitigating factors that appear lead us to come from a large
number of Teredo peers, thus trashing the cache and effectively
denying avoid
worrying too much about this attack. In practice, the use of direct communication between peers. The effect
will only last as long as gain from the
attack is sustained.

7.3.3 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 either deny service to disable the local
discovery procedure; however, if local discovery is disabled,
traffic between local nodes will end up being relayed through client, or obtain a
server external "man-in-
the-middle" position; however, in order to mount the local network, which has questionable
security implications.

7.3.4 Attacking attack, the Teredo servers and relays

It is possible
attacker must be able to mount a brute force suppress traffic originating from the
client, i.e. have denial of service attack
against capability; the Teredo servers by sending them a very large number of
packets. This attack will have to attacker must
also be "brute force", since able to observe the
servers are stateless, traffic exchanged between client and can be designed to process all
inject its own traffic in the mix, i.e. have man-in-the-middle
capacity. In summary, the
packets that are sent on their access line.

The brute force attack against is very hard to mount, and the gain
for the attacker is minimal.

7.2.1 End-to-end security

The most effective line of defense of a Teredo servers client is mitigated if
clients are ready probably
not to "failover" try to another server. Bringing down secure the
servers will however force Teredo service itself: even if the clients that change servers mapping
can be securely obtained, the attacker would still be able to
renumber their listen
to the traffic and send spoofed packets. Rather, the Teredo address.

It client
should realize that, because it is also possible to mount a brute force attack against located behind a Teredo
relay. This attack NAT, it is mitigated in a
situation of vulnerability; it should systematically try to encrypt
its IPv6 traffic, using IPSEC. Even if the relay under attack stops
announcing IPv4 and UDP headers are
vulnerable, the reachability use of IPSEC will effectively prevent spoofing and
listening of the Teredo service prefix to the IPv6
network: the traffic will be picked up packets by third parties. By providing each
client with a global IPv6 address, Teredo enables the next relay.

7.4 use of IPSEC
and ultimately enhances the security of these clients.

7.3 Denial of the Teredo service against non-Teredo nodes

Our analysis outlines five ways to attack the Teredo service. There

Huitema [Page 33] 36]

INTERNET DRAFT Teredo February 5, June 9, 2004

There is

are counter-measures for each of these attacks.

7.3.1 Denial of service by a widely expressed concern that transition mechanisms such
as Teredo rogue relay

An attack can be used to mount denial mounted on the IPv6 side of the service attacks, by
injecting traffic at locations where it is not expected. These
attacks fall in three categories: using the Teredo servers as setting
up a
reflector in rogue relay, and letting that relay advertise a denial of service attack, using route to the
Teredo server to
carry a denial of service IPv6 prefix. This is an attack against IPv6 nodes, and using routing, which
can also be mitigated by the same kind of procedures used to
eliminate spurious route advertisements. Dual stack nodes that
implement a "host local" Teredo relays are impervious to carry a denial this
attack.

8.3.1 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. by server spoofing

In case of attacks, these patterns can be
used to quickly install filters and remove section 7.2, we discussed the offending traffic.

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 spoofed router
advertisements to insert an IPv4 target. The attacker can do this in
one the middle of two ways. a Teredo
conversation. The first way is spoofed router advertisements can also be used to construct
provision a Router Solicitation
message and post it client with an incorrect address, pointing to either a Teredo server, using as
non-existing IPv4 source address or to the spoofed IPv4 address of the target; the Teredo server will then send a Router advertisement message to the target. third party.

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 client will detect the selected
Teredo server.

Reflector attacks are discussed in [REFLECT], which outlines various
mitigating techniques against such attacks. One of these mitigations
is attack when it fails to observe that 'the receive
traffic generated by through the reflectors [has]
sufficient regularity and semantics that it newly acquired IPv6 address. The attack can be filtered out near
the victim without
mitigated by using the filtering itself constituting a denial-of- authentication encapsulation.

7.3.2 Denial of service to the victim ("collateral damage").' The traffic reflected by exceeding the number of peers

A Teredo servers meets this condition: client manages a cache of recently-used peers, which makes
it stateful. It is clearly
recognizable, since it originates from possible to mount an attack against the Teredo UDP port; client by
provoking it can
be filtered out safely if the target itself is not to respond to packets that appear to come from a large
number of Teredo user. In
addition, peers, thus trashing the packets relayed by servers will carry an Origin
indication encapsulation, which will help determining cache and effectively
denying the source use of direct communication between peers. The effect
will only last as long as the attack.

7.4.2 DOS attacks from IPv4 to IPv6

An attacker may use attack is sustained.

7.3.3 Attacks against the Teredo servers to launch local discovery procedure

There is a possible denial of service attack against an arbitrary IPv6 destination. The attacker will
build an IPv6 packet bound for the target, and will local peer
discovery procedure, if attackers can manage to send that packet spoofed local
discovery bubbles to the IPv4 address and UDP port of a Teredo server, to be relayed
from there to the target over IPv6. client. The address checks specified described in
section 5.3.1 provide some
protection against 5.2.8 mitigate this attack, as they ensure that the IPv6 source
address will be consistent with the IPv4 source address and UDP
source port used by attack. Clients who are more interested
in security than in performance could decide to disable the attacker: local
discovery procedure; however, if the attacker cannot spoof the

Huitema [Page 34]

INTERNET DRAFT Teredo February 5, 2004

IPv4 source address, the target local discovery is disabled,
traffic between local nodes will be able end up being relayed through a
server external to determine the origin
of the attack.

The address checks ensure that the IPv6 source address of packets
forwarded by servers will start with local network, which has questionable
security implications.

7.3.4 Attacking the IPv6 Teredo prefix. This servers and relays

It is
a mitigating factor, as sites under attack could use this possible to filter
out all packets sourced from that prefix during an attack. This will
result in mount a partial loss brute force denial of service, as service attack
against the target Teredo servers by sending them a very large number of
packets. This attack will not have to be able "brute force", since the
servers are stateless, and can be designed to communicate with legitimate Teredo hosts process all the
packets that use are sent on their access line.

Huitema [Page 37]

INTERNET DRAFT Teredo June 9, 2004

The brute force attack against the same
prefix; however, Teredo servers is mitigated if
clients are ready to "failover" to another server. Bringing down the communication with other IPv6 hosts
servers will remain
unaffected, and however force the communication with clients that change servers to
renumber their Teredo hosts will be able address.

It is also possible to
resume when the mount a brute force attack against a Teredo
relay. This attack has ceased.

The ICMP Traceback (ITRACE) working group is considering systems for
"tracing" mitigated if the source relay under attack stops
announcing the reachability of DOS attacks. According to the proposal, when
forwarding packets, routers can, with a low probability, generate a
Traceback message that is sent along Teredo service prefix to the destination; with enough
Traceback messages from enough routers along the path, IPv6
network: the traffic
source and path can will be determined. This set picked up assumes that the
source and destination are both using by the same version next relay.

An attack similar to 7.3.2 can be mounted against a relay. An IPv6
host can send IPv6 packets to a large number of IP. In the Teredo case, destinations,
forcing the ICMP Traceback packets will be sent relay to the establish state for each of these destinations.
Teredo
server, not relays can obtain some protection by limiting the final destination. It is conceivable to "map" range of
IPv6 clients that they serve, and by limiting the
IPv4 traceback 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 an IPv6 traceback sent mount denial of service attacks, by
injecting traffic at locations where it is not expected. These
attacks fall in three categories: using the Teredo server; the
details servers as a
reflector in a denial of service attack, using the solution should be specified by the ITRACE working
group.

7.4.3 DOS attacks from IPv6 Teredo server to IPv4

An attacker with
carry a denial of service attack against IPv6 connectivity may use nodes, and using the
Teredo relays to
launch carry a denial of service attack against an arbitrary IPv4
destination.
nodes. The attacker will compose a Teredo IPv6 address using
the Teredo prefix, a null server address, analysis of these attacks follows. A common mitigating
factor in all cases is the IPv4 address "regularity" of the
target, an arbitrary Teredo traffic, which
contains highly specific patterns such as the Teredo UDP port, and an arbitrary node identifier. The
attacker will send IPv6 packets to that address; or
the packets will Teredo IPv6 prefix. In case of attacks, these patterns can be
routed
used to the nearest Teredo relay, quickly install filters and forwarded remove the offending traffic.

7.4.1 Laundering DoS attacks from there IPv4 to IPv4

An attacker can use the
target.

The address checks specified Teredo servers as reflectors in 5.4 are limited to verifying that
packets are only relayed to a global IPv4 address. This rules out a
class denial of
service attack aimed at an IPv4 target. The attacker can do this in which the packets are bound
one of two ways. The first way is to construct a broadcast or
multicast address. It also rules out another class of attack in
which the packets are bound for Router Solicitation
message and post it to a private Teredo server, using as IPv4 source address that would be
reachable by the relay.

The attack can be targeted at arbitrary UDP ports, such as for
example
the DNS port spoofed address of the target; the Teredo server will then send
a server. Router advertisement message to the target. The UDP payload must be a well-
formed IPv6 packet, and second way is thus unlikely to be accepted by any well-
written UDP service; in most case,
construct a Teredo IPv6 address using the only effect Teredo prefix, the address
of a selected server, the attack
will be to overload IPv4 of the target with random traffic.

A special case occurs if target, and an arbitrary UDP
port, and to then send packets bound to that address to the attack selected
Teredo server.

Reflector attacks are discussed in [REFLECT], which outlines various
mitigating techniques against such attacks. One of these mitigations
is directed to an echo service.
The service will echo observe that 'the traffic generated by the packets. Since reflectors [has]
sufficient regularity and semantics that it can be filtered out near
the echo victim without the filtering itself constituting a denial-of-
service sees to the victim ("collateral damage").' The traffic reflected

Huitema [Page 35] 38]

INTERNET DRAFT Teredo February 5, June 9, 2004

request coming from the IPv4 address of

by the relay, Teredo servers meets this condition: it is clearly
recognizable, since it originates from the echo replies
will Teredo UDP port; it can
be sent back to filtered out safely if the same relay. According to target itself is not a Teredo user. In
addition, the rules
specified in 5.4, these packets relayed by servers will carry an Origin
indication encapsulation, which will be discarded by help determining the source of
the attack.

7.4.2 DOS attacks from IPv4 to IPv6

An attacker may use the Teredo
relay. This is not servers to launch a very efficient denial of service
attack against the Teredo relays
- establishing a legitimate session with an actual Teredo host would
create more traffic. arbitrary IPv6 destination. The attacker will
build an IPv6 packets sent to packet bound for the target contain target, and will send that packet
to the IPv6 IPv4 address used by and UDP port of a Teredo server, to be relayed
from there to the attacker. If ingress filtering is used target over IPv6.

The address checks specified in section 5.3.1 provide some
protection against this attack, as they ensure that the IPv6 network, this source
address will be hard to spoof. If ingress filtering is not used, the
attacker can be traced if consistent with the IPv6 routers use a mechanism similar
to ICMP Traceback. The ICMP messages will normally be collected IPv4 source address and UDP
source port used by the same relays that forward attacker: if the traffic from attacker cannot spoof the attacker;
IPv4 source address, the
relays can use these messages target will be able to identify determine the source of an ongoing
attack. The details origin
of this solution should be specified by the
ITRACE working group.

8 IAB considerations attack.

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 checks ensure that the other side IPv6 source address of a NAT
through a collaborative protocol reflection mechanism [RFC3424]. packets
forwarded by servers will start with the IPv6 Teredo prefix. This is an example of
a protocol that performs mitigating factor, as sites under attack could use this type of
function. The IAB has mandated to filter
out all packets sourced from that any protocols developed for this
purpose document a specific set of considerations. prefix during an attack. This section
meets those requirements.

8.1 Problem Definition

From [RFC3424], any UNSAF proposal must provide will
result in a precise definition partial loss of a specific, limited-scope problem that is to be solved with service, as the
UNSAF proposal. A short term fix should target will not be generalized able
to solve communicate with legitimate Teredo hosts that use the same
prefix; however, the communication with other problems; this is why "short term fixes usually aren't".

The specific problems being solved by IPv6 hosts will remain
unaffected, and the communication with Teredo is hosts will be able to
resume when the provision of attack has ceased.

7.4.3 DOS attacks from IPv6 connectivity for a host that cannot obtain to IPv4

An attacker with IPv6 connectivity
either natively or by other means, such as 6to4.

8.2 Exit Strategy

From [RFC3424], any UNSAF proposal must provide may use the description Teredo relays to
launch a denial of service attack against an exit strategy/transition plan. arbitrary IPv4
destination. The better short term fixes are
the ones that attacker will naturally see less and less use as the
appropriate technology is deployed. compose a Teredo comes with its own built in exit strategy: as soon as IPv6
connectivity is obtained by other means, address using
the Teredo prefix, a null server address, the IPv4 address of the
target, an arbitrary UDP port, and an arbitrary node identifier. The
attacker will cease send IPv6 packets to be
used. In particular, we expect that address; the next generation of home
routers packets will provide an IPv6 service in complement be
routed to the current
IPv4 NAT service, e.g. by relaying connectivity obtained nearest Teredo relay, and forwarded from there to the
ISP,
target.

The address checks specified in 5.4 are limited to verifying that
packets are only relayed to a global IPv4 address. This rules out a
class of attack in which the packets are bound to a broadcast or
multicast address. It also rules out another class of attack in
which the packets are bound for a private IPv4 address that would be
reachable by using the relay.

The attack can be targeted at arbitrary UDP ports, such as for
example the DNS port of a configured or automatic tunnel service. server. The UDP payload must be a well-

Huitema [Page 36] 39]

INTERNET DRAFT Teredo February 5, June 9, 2004

The exit strategy is facilitated by the nature of Teredo, which
provides an IP level solution.

formed IPv6 aware applications do not have packet, and is thus unlikely 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.

8.3 Brittleness Introduced accepted by Teredo

From [RFC3424], any UNSAF proposal must provide a discussion well-
written UDP service; in most case, the only effect 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 the attack
will be to transition.

Teredo introduces brittleness into overload the system in several ways: target with random traffic.

A special case occurs if the
discovery process assumes a certain classification of devices based
on their treatment 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 UDP; the mappings need to relay, the echo replies
will be continuously
refreshed, while sent back to the ; and addressing structure may cause some hosts
located beyond a common NAT same relay. According to be unreachable from each other.
(There are many similarities between the rules
specified in 5.4, these points and those
introduced packets will be discarded by STUN [RFC3489].) the Teredo assumes
relay. This is not a certain classification of devices based on their
treatment of UDP, e.g. cone, protected cone and symmetric. There
could be devices that 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 fit into one of these molds, and
hence would used, the
attacker can be improperly classified by Teredo.

The bindings allocated from traced if the NAT need IPv6 routers use a mechanism similar
to ICMP Traceback. The ICMP messages will normally be continuously
refreshed. Since collected by
the timeouts for these bindings is very
implementation specific, same relays that forward the refresh interval cannot easily be
determined. When traffic from the binding is not being actively used to
receive traffic, but to wait for an incoming message, attacker; the binding
refresh will needlessly consume network bandwidth.

The
relays can use of these messages to identify the Teredo server as an additional network element
introduces another point source of potential security an ongoing
attack. These
attacks are largely prevented The details of this solution should be specified by the security measures provided by
Teredo, but not entirely.
ITRACE working group.

8 IAB considerations

The use of IAB has studied the Teredo server as an additional network element
introduces another point problem of failure. If "Unilateral Self Address Fixing"
(UNSAF), which is the client cannot locate general process by which a
Teredo server, or if the server should be unavailable due to
failure, the Teredo client will not be able attempts to obtain IPv6
connectivity.

Teredo imposes some restrictions
determine its address in another realm on the network topologies for
proper operation. In particular, if the same other side of a NAT is on the path
between two clients and the
through a collaborative protocol reflection mechanism [RFC3424].
Teredo server, these clients will only
be able to interoperate if they are connected 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 same link, or
if the common NAT
UNSAF proposal. A short term fix should not be generalized to solve
other problems; this is capable of "looping" packets sent why "short term fixes usually aren't".

The specific problems being solved by one client
to another.

Huitema [Page 37]

INTERNET DRAFT Teredo February 5, 2004

8.4 Requirements is the provision of
IPv6 connectivity for a Long Term Solution host that cannot obtain IPv6 connectivity
either natively or by other means, such as 6to4.

8.2 Exit Strategy

From [RFC3424], any UNSAF proposal must identify requirements for
longer term, sound technical solutions -- contribute to provide the process description of finding the right longer
an exit strategy/transition plan. The better short term solution.

Our experience fixes are
the ones that will naturally see less and less use as the
appropriate technology is deployed.

Huitema [Page 40]

INTERNET DRAFT Teredo June 9, 2004

Teredo comes with its own built in exit strategy: as soon as IPv6
connectivity is obtained by other means, Teredo has led will cease to be
used. In particular, we expect that the following requirements for
a long term solution next generation of home
routers will provide an IPv6 service in complement to the NAT problem: the devices that implement
the current
IPv4 NAT services should in service, e.g. by relaying connectivity obtained from the future also become IPv6 routers.

9 IANA Considerations

This memo documents
ISP, or by using a request to IANA to allocate 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
service prefix, and hosts. As Teredo usage declines, the traffic load on the
relays will decline. Over time, managers will observe a reduce
traffic load on their relays and will turn them off, effectively
increasing the pressure on the remaining Teredo IPv4 multicast address.

10 Copyright hosts to upgrade to
another form of connectivity.

The following copyright notice exit strategy is copied from RFC 2026 [Bradner,
1996], Section 10.4, and describes facilitated by the applicable copyright for this
document.

This document and translations nature of it may Teredo, which
provides an IP level solution. IPv6 aware applications do not have
to be copied and furnished updated to
others, and derivative works that comment on use or otherwise explain not use Teredo. The absence of impact on the
applications makes it
or assist in its implementation easier to migrate out of Teredo: network
connectivity suffices.

8.3 Brittleness Introduced by Teredo

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

Teredo introduces brittleness into the system in part, without restriction several ways: the
discovery process assumes a certain classification of any
kind, provided that devices based
on their treatment of UDP; the above copyright notice mappings need to be continuously
refreshed; and this paragraph addressing structure may cause some hosts located
beyond a common NAT to be unreachable from each other. (There are included
many similarities between these points and those introduced by STUN
[RFC3489].)

Teredo assumes a certain classification of devices based on all such copies their
treatment of UDP, e.g. cone, protected cone and derivative works. However, this
document itself may symmetric. There
could be devices that would not fit into one of these molds, and
hence would be modified in any way, such as improperly classified by removing Teredo.

The bindings allocated from the copyright notice or references NAT need to be continuously
refreshed. Since the Internet Society or other
Internet organizations, except as needed timeouts for these bindings is very
implementation specific, the purpose of
developing Internet standards in which case refresh interval cannot easily be
determined. When the procedures binding is not being actively used to
receive traffic, but to wait for
copyrights defined in an incoming message, the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

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

This document and needlessly consume network bandwidth.

The use of the information contained herein is provided on Teredo server as an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

11 Intellectual Property

The following notice is copied from RFC 2026 [Bradner, 1996], additional network element
introduces another point of potential security attack. These

Huitema [Page 38] 41]

INTERNET DRAFT Teredo February 5, June 9, 2004

Section 10.4, and describes the position of

attacks are largely prevented by the IETF concerning
intellectual property claims made against this document. security measures provided by
Teredo, but not entirely.

The IETF takes no position regarding use of the validity or scope Teredo server as an additional network element
introduces another point of any
intellectual property or other rights that might be claimed to
pertain to failure. If the implementation or use other technology described in
this document client cannot locate a
Teredo server, or if the extent to which any license under such rights
might or might server should be unavailable due to
failure, the Teredo client will not be available; neither does it represent that it
has made any effort able to identify any such rights. Information obtain IPv6
connectivity.

Teredo imposes some restrictions on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available network topologies for publication
proper operation. In particular, if the same NAT is on the path
between two clients and any assurances
of licenses to the Teredo server, these clients will only
be made available, able to interoperate if they are connected to the same link, or
if the result common NAT is capable of an attempt made "looping" packets sent by one client
to obtain another.

8.4 Requirements for a general license or permission Long Term Solution

From [RFC3424], any UNSAF proposal must identify requirements for
longer term, sound technical solutions -- contribute to the use of such
proprietary rights by implementers or users process
of this specification
can be obtained from finding the IETF Secretariat.

The IETF invites any interested party right longer term solution.

Our experience with Teredo has led to bring the following requirements for
a long term solution to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology the NAT problem: the devices that may be required to practice
this standard. Please address implement
the information to IPv4 NAT services should in the IETF Executive
Director.

12 future also become IPv6 routers.

9 IANA Considerations

This memo documents a request to IANA to allocate a Teredo IPv6
service prefix, and a Teredo IPv4 multicast address.

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 group; groups,
including Brian Carpenter, Cyndi Jung, Keith Moore, Thomas Narten,
Anssi Porttikivi, Pekka Savola, and Eng Soo Guan.

13 Guan, and Eiffel Wu.

11 References

Normative references

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

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

Huitema [Page 42]

INTERNET DRAFT Teredo June 9, 2004

[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.

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

[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate

Huitema [Page 39]

INTERNET DRAFT Teredo February 5, 2004
Requirement Levels", RFC 2119, March 1997.

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

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

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

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

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

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

Informative references

[RFC1750] D. Eastlake, S. Crocker, J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.

[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.

[SYNCHRO] S. Floyd, V. Jacobson, "The synchronization of periodic
routing messages", ACM SIGCOMM'93 Symposium, September 1993.

[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.

14 Authors' Addresses

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

Email: huitema@microsoft.com

Huitema [Page 40]

INTERNET DRAFT Teredo February 5, 2004

Huitema [Page 41]

INTERNET DRAFT Teredo February 5, 2004

Table of Contents:

1 Introduction .................................................... 1
2 Definitions ..................................................... 2
2.1 Teredo service ................................................ 2
2.2 Teredo Client ................................................. 2
2.3 Teredo Server ................................................. 2
2.4 Teredo Relay .................................................. 3
2.5 Teredo IPv6 service prefix .................................... 3
2.5.1 Global Teredo IPv6 service prefix ........................... 3
2.6 Teredo UDP port ............................................... 3
2.7 Teredo bubble ................................................. 3
2.8 Teredo service port ........................................... 3
2.9 Teredo server address ......................................... 3
2.10 Teredo mapped address and Teredo mapped port ................. 3
2.11 Teredo IPv6 client prefix .................................... 3
2.12 Teredo node identifier ....................................... 4
2.13 Teredo IPv6 address .......................................... 4
2.14 Teredo Refresh Interval ...................................... 4
2.15 Teredo secondary port ........................................ 4
2.16 Teredo IPv4 Discovery Address ................................ 4
3 Design goals, requirements,

Informative references

[RFC1750] D. Eastlake, S. Crocker, J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.

[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and model of operation .............. 4
3.1 Hypotheses about NAT behavior ................................. 4
3.1.1 Types of UDP mappings ....................................... 5
3.1.2 Lifetime R. Mahy.
"STUN - Simple Traversal of UDP mappings .................................... 5
3.2 IPv6 provider User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003.

[SYNCHRO] S. Floyd, V. Jacobson, "The synchronization of last resort .................................. 6
3.2.1 When to use Teredo? ......................................... 6
3.2.2 Autonomous deployment ....................................... 6
3.2.3 Minimal load on servers ..................................... 7
3.2.4 Automatic sunset ............................................ 7
3.3 Operational Requirements ...................................... 7
3.3.1 Robustness requirement ...................................... 7
3.3.2 Minimal support cost ........................................ 7
3.3.3 Protection against denial periodic
routing messages", ACM SIGCOMM'93 Symposium, September 1993.

[REFLECT] V. Paxson, "An analysis of service attacks ................ 8
3.3.4 Protection against using reflectors for
distributed denial of service attacks .... 8
3.3.5 Compatibility with ingress filtering ........................ 8
4 Teredo Addresses ................................................ 8
5 Specification of clients, servers and relays .................... 9
5.1 Message formats ............................................... 10
5.1.1 Teredo IPv6 packets encapsulation ........................... 10
5.1.2 Maximum Transmission Unit ................................... 12
5.2 Teredo Client specification ................................... 12
5.2.1 Qualification procedure ..................................... 13
5.2.2 Secure qualification ........................................ 16
5.2.3 Packet reception ............................................ 16
5.2.4 Packet transmission ......................................... 18
5.2.5 Maintenance ................................................. 19
5.2.6 Sending Teredo Bubbles ...................................... 20
5.2.7 Optional Refresh Interval Determination Procedure ........... 20
5.2.8 Optional local client discovery procedure ................... 21
5.2.9 Direct IPv6 connectivity test ............................... 23 attacks." Computer Communication
Review, ACM SIGCOMM, Volume 31, Number 3, July 2001, pp 38-47.

12 Authors' Addresses

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

Huitema [Page 42] 43]

INTERNET DRAFT Teredo February 5, June 9, 2004

5.2.10 Working around symmetric NAT ............................... 23
5.3 Teredo Server specification ................................... 24
5.3.1 Processing

Email: huitema@microsoft.com

13 Intellectual Property Statement

The IETF takes no position regarding the validity or scope of Teredo IPv6 packets ........................... 24
5.3.2 Processing any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of router solicitations .......................... 26
5.4 Teredo Relay specification .................................... 26
5.4.1 Transmission by relays the technology described
in this document or the extent to Teredo clients .................... 27
5.4.2 Reception from Teredo clients ............................... 27
5.4.3 Difference between Teredo Relays 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 Teredo Servers ......... 28
5.5 Implementation of automatic sunset ............................ 28
6 Use BCP 79.

Copies of Teredo IPR disclosures made to implement a tunnel service ..................... 29
7 Security Considerations ......................................... 30
7.1 Opening a hole in the NAT ..................................... 30
7.2 Using the Teredo service for a man-in-the-middle attack ....... 31
7.2.1 End-to-end security ......................................... 32
7.3 Denial IETF Secretariat and any
assurances of licenses to be made available, or the Teredo service .................................. 32
7.3.1 Denial result of service by an
attempt made to obtain a rogue relay .......................... 32
8.3.1 Denial of service by server spoofing ........................ 33
7.3.2 Denial of service by exceeding general license or permission for the number use
of peers .......... 33
7.3.3 Attacks against the local discovery procedure ............... 33
7.3.4 Attacking the Teredo servers and relays ..................... 33
7.4 Denial such proprietary rights by implementers or users of service against non-Teredo nodes .................... 33
7.4.1 Laundering DOS attacks this
specification can be obtained from IPv4 the IETF on-line IPR repository
at http://www.ietf.org/ipr.

The IETF invites any interested party to IPv4 .................... 34
7.4.2 DOS attacks from IPv4 bring to IPv6 ............................... 34
7.4.3 DOS attacks from IPv6 its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to IPv4 ............................... 35
8 IAB considerations .............................................. 36
8.1 Problem Definition ............................................ 36
8.2 Exit Strategy ................................................. 36
8.3 Brittleness Introduced by Teredo .............................. 37
8.4 Requirements implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.

14 Copyright

The following copyright notice is copied from [RFC3667], Section
5.4. It describes the applicable copyright for a Long Term Solution ......................... 38
9 IANA Considerations ............................................. 38
10 this document.

Copyright ...................................................... 38
11 Intellectual Property .......................................... 38
12 Acknowledgements ............................................... 39
13 References ..................................................... 39
14 Authors' Addresses ............................................. 40 (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.

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

Huitema [Page 43] 44]

----