Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)
draft-huitema-v6ops-teredo-05

[Ballot discuss]
From: Thomas Narten
To: Margaret Wasserman
cc: "Christian Huitema"
Date: Tue, 15 Feb 2005 10:03:30 -0500
Subject: Re: draft-huitema-v6ops-teredo-04.txt

> Thomas had raised on issues with this document a while back, and he
> still isn't showing any position in the tracker.  I've been waiting
> to hear from him about whether he wants those issue to be resolved
> before the document is published.

yep, I've been rather delinquent. Looking through my notes, my
comments are mostly editorial.

But there are two substantative issues.

I wonder if it would be worth adding the overview I put together. If
one existed in the past, it's a shame it got removed. All protocol
documents really benefit from a summary/overview section at the
start. This document is hard to read without an overview (other IESG
reviewers said the same).

It would be good to make it _very_ explicit exactly what packets a
toredo server is supposed to relay, and which it is not. That is, for
security purposes, servers should drop all packets other than those
that are explicitely allowed. The document is not clear at all clear
about this. A single paragraph/table would be sufficient to make this
point clear.

ICMP echo requests. I worry that using ICMP echo requests/replies for
signalling will lead to problems. I.e., using echos for a purpose
other than originally intended. The main problem I see is that there
are sites that filter all ICMP for (arguably) bogus security
reasons. Or, they filter ICMP echos when dealing with DDOS attacks and
such. I'm aware of two such instances today. It appears that my
employer filters ICMP echo requests/replies at its border. This didn't
used to be the case, but has been in effect for many months now. Also,
I regularly use accounts within cs.duke.edu. But they do funny things
with ICMP. Some of the internal hosts do not appear to respond to ICMP
echos from outside the site. E.g., try cassatt.cs.duke.edu. You can
ssh into that machine, so it is connected.

Since teredo relies in ICMP for setup, this would seem to be a
problem. Not sure how easy to fix this or if it is fixable. Would it
make sense to not use ICMP echos, but to allocate an alternative Type
value? This at least would make it possible for firewalls to filter
teredo setup messages separately from ICMP (the concern is folks
filtering ICMP echo without having a clue on the impact that will have
on teredo). Another possibility is to use a different code value for
teredo echos, so that firewalls can filter them differntly, but I
suspect that won't be sufficient and I am not sure whether firewalls
understand this degree of granualarity.

Specific comments:

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

s/user/Teredo client/ (users surely don't select servers...)


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

what does "joined" mean? Do you just mean "reached"?

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

Source port on the client? dest port? Both?

>    Packet transmission only takes places after an exchange of "bubbles"
>    between the parties. This exchange would often fail for clients
>    behind symmetric NAT, because their peer cannot predict the UDP port
>    number that the NAT expect.

what kind of packet transmission? You mean arbitrary IPv6 to IPv6
communication between the client and some random IPv6 host?

>    address. We had to include an "obfuscation" procedure in TCP to
>    avoid this behavior.

Who is "we" and what does this document recommend implementors do? If
there is no action, remove sentence...

>    During the peak of the transition, there will be a requirement to
>    deploy a large number of servers throughout the Internet. Minimizing

what kind of servers? I assume teredo servers. Might be good to go
through the document and s/server/teredo server/ throughout for
clarity.

> 3.3.2 Minimal support cost
>   
>    The service requires the support of servers and relays. In order to
>    facilitate the deployment of these servers, the Teredo procedures
>    are designed to minimize the fraction of traffic that has to be
>    routed through the servers.

"routed through the servers"? earlier I thought it was a requirement
that:

  necessary. To achieve this objective, we require only that servers
  enable the packet exchange between clients, but we don't require
  servers to carry the actual data packets: these packets will have to
  be exchanged directly between the Teredo clients, or through a
  destination-selected relay for exchanges between Teredo clients and
  other IPv6 clients.
 
>    Teredo clients have to discover the relay that is closest to each
>    native IPv6 peer. In order to prevent spoofing, the Teredo clients
>    perform a relay discovery procedure by sending an ICMP echo request
>    to the native host, through the Teredo server. The payload of the
>    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 to discover this relay. In order to prevent
>    spoofing, the Teredo client verifies that the payload of the echo
>    reply contains the proper random number.

To be sure I understand (and to clarify):

The above needs to be done whenever one initiates communication with a
new destination? (please say so).

What does "through the teredo server"  mean? What exactly does the
server send to the client (i.e, what addresses are used...)

>    The echo reply is
>    forwarded by the relay closest to the native or 6to4 peer, enabling
>    the Teredo client to discover this relay.

How does it discover the relay? what info is in the forwarded echo
reply that allows it to do so?

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

why? what purpose does this server?

>    - Flags: a set of 16 bits that document type of address and NAT.

I wonder about this. Whether one is behind a certain type  of NAT is a
relative term. What this bit says is what type of nat is between the
client and server. The type of nat between the client and some random
desitination may be different (when multiple nats  are present). Is
this an issue? I.e., is this flag really to indicate the type of nat
relative to the server, or is this supposed to be a global statement
that random destinations take advantage of?

>    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
>    address and UDP port.

for the last sentence, can you say specifically what kind of IPv6
packet a server forwards, since you repeatedly say that data packets
are not?

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

here is that generic "relaying" text again...

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

Huh? servers are "routers?

>    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:

Huh? server relays RAs? ???

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

Are you really saying "should not perform PMTU discovery"? If so,
better to just say that.

>    A Teredo client expects to exchange IPv6 packets through an UDP

s/an UDP/a UDP/ (occurs more in at least one other place)

>    A Teredo client expects to exchange IPv6 packets through an UDP
>    port, the Teredo service port. To avoid problems when operating
>    behind a "port conserving" NAT, different clients operating behind
>    the same NAT should use different service port numbers. This can be

say "different service source port numbers"?

>    When the client wants to send a packet to an IPv6 node on the IPv6
>    Internet, 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

Isn't the above only if the destination is teredo?

>    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. Operators may however decide to combine the functions of

All types of ICMP messages?

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

This seems like asking for trouble. The teredo server should not be
receiving such packets. Why forward them? By doing so, one increases
server load and prevents broken clients from getting fixed.

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

shouldn't one also verify that the packet is a valid bubble (i.e.,
icmpv6 echo?), and nothing else?

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

should? Seems like a must, since relays may send packets to arbitrary
servers.

>    bubble, up to three times. If there relay fails to receive a bubble

s/there/the/ ?

>    In cases 2 and 3, the Teredo relay should create a peer entry for
>    the IPv6 address; the entry status is marked as trusted in case 2
>    (cone NAT), not trusted 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 of
>    the Teredo destination; this will "open the path" for the return
>    bubble from the Teredo client.

I don't believe the above is true. see previous comments about
relative view of type of nat.

NOt accurate to call teredo servers "stateless".


Section 5.2:

read up to security considerations

>    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,
>    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 use
>    the "list of recent peers". For each peer, the list contains:

is this just for Teredo destinations, or for all destination?


>    - The status of the mapped address, i.e. trusted or not,

trusted? isn't "verified" or "current" more accurate?

>    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 detects a port-restricted or restricted cone
>    NAT: the client is qualified to use the service. (Teredo operates

Where does this secondary address come from? Is this just the
secondary port? Also, later, this is described as an optional
procedure. Is it optional for the client? Is it optional (to
implement?) for the server?

Section 5.3: be more specific about what a server forwards and does
not. There should be explicit tests to prevent forwarding of traffic
that is not appropriate. E.g., what about echo responses?

[Ballot discuss]
draft-huiteme-v6ops-teredo-04 was posted, and it resolves the vast bulk of
  my concerns were addressed.  One remains.

  Section 7.2.1 says:
  >
  > Another way to defeat the protection afforded by the signature
  > procedure is to mount a complex attack, as follows:
  >
  Elsewhere this is discussed as authentication.  Please do not use
  "signature."  This is not a signature scheme.

[Ballot discuss]
How important is queueing of packets by the relays before the first buble
goes through? I'm concerned about scaling aspects and possible DoS exploits.
If the mechanisms will still work when the first pkt is dropped, I'd suggest
changing the doc say that relays MAY queue packets and if they do, they SHOULD
limit the number of queued packets per client.

[Ballot comment]
Reviewed by John Loughney, Gen-ART

I am casting a no-obj here because I do not agree that there is value to the IETF in pushing this to Info or Experimental instead of standards-track.

His review:

Basically, I think that this document should be published as an
informational RFC.  Its documenting what is currently being deployed,
it has gone through PROTO evaluation, it has met the UNSAF criteria
and survived review by Pekka Savola.

There's a lot that could be nit-picked in the draft, but I don't have
the time or energy to do this.  I think I would have probably liked
a more concise statement of applicability of this mechanism, but
I think having to cover the UNSAF criteria diluted any general statement
concerning applicability.

I also had some security-related concerns, but see that the Security
ADs have given the document a good review, so I'll defer to their comments.

[Ballot discuss]
At several points the specification talks about confirming that an
IPV4 address is a global unicast address.  The security considerations
section point out that this prevents sending to an IPV4 broadcast
address.  How do you check to see that some address is not an IPV4
broadcast address?  Doesn't that depend on the netmask of the network
in question?  Also, is global really appropriate?  Why should private
use addresses be excluded?  Please include specific details of what
address checks are actually intended.


Section 5.2.2 does not provide sufficient detail of the authentication
algorithm to produce interoperable implementations.  You need to
specify the specific fields that are checksummed, their order, any
padding.  In general you want to provide test vectors for your
authentication algorithm; doing so makes sure that you actually
specify things in enough detail.

The document implies that there is algorithm agility; it implies that
new authentication algorithms can be defined.  If so, how do the
client and server know what algorithm to use?


Section 6 appears to be stating normative requirements for a tunnel
mode.  However requirement levels are not stated; is it a MAY, SHOULD
or MUST for servers to implement this facility?  Section 6 conflicts
with section 5.2; section 5.2 requires clients to confirm that they
receive a Taredo address.  However section 6 allows a server to hand
out other such addresses.  I think this will break clients that are
not expecting the tunnel facility.


Section 7 assumes at several points that IPsec cannot be used from
behind a NAT.  This is no longer true.

Section 7.1 assumes that NATs improve security/create a security
barrier.  Please see section 9 of RFC 2993.  It might be reasonable to
reword section 7.1 in terms of getting around a firewall function
included along side a NAT product.


Section 7.2  misses a significant spoofing consideration.  When a
Taredo client receives a packet from a non-Taredo IPV6 address it has
to determine whether to trust the relay and whether to accept the
packet.  Operational guidelines are provided in section 5 but a
security discussion should be placed in section 7.


Section 7.4 proposes to assign a work item to the ITRACE working
group.  They're gone, right?

Section 8 seems to consider Teredo in its normal mode, not the tunnel
mode described in section 6.  I think the load implication of section
6 on servers should be discussed in 8.3 I believe that section 8.4
should also consider section 6.

[Ballot comment]
Section 5.3.2 says:
  >
  > 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.
  >
  s/must/MUST/
  s/should/SHOULD/ (two places; consider making the first one MUST)

  Section 7.2 says:
  >
  > ... the one way function used to compute ...
  >
  s/one way function/one-way function/

[Ballot discuss]
Section 5.2.2 says:
  >
  > - the hash function shall be the MD5 function [RFC1321].
  >
  and, Section 7.2 says:
  >
  > This specification suggests a default algorithm combining HMAC
  > and MD5. If the protection afforded by MD5 was not deemed
  > sufficient, clients and servers can be agree to use a different
  > algorithm, e.g. SHA1.
  >
  I have two concerns.  First, the protocol ought to be authentication
  mechanism independent.  As written, the document requires an HMAC-
  based mechanism.  Mechanisms like AES-XCBC-MAC-96 (see RFC 3566)
  ought to be accommodated too.  Second, while no problems have been
  found with HMAC-MD5, problems have been found with MD5.  Is there
  any reason why we cannot use HMAC-SHA-1 as the default here?  Even
  if the output is truncated to 128 bits (sometimes called
  HMAC-SHA-1-128), I would feel more comfortable than continuing to
  promote the use of MD5.

  Section 7 says:
  >
  > ... use IP security services such as IKE, AH or ESP.
  >
  Please provide references for these.
  Also: s/IP security/IP security (IPsec)/

  Section 7.2 says:
  >
  > Another way to defeat the protection afforded by the signature
  > procedure is to mount a complex attack, as follows:
  >
  and, later it says:
  >
  > It is very hard to devise an effective signature scheme, since
  > the attacker does not do anything else than what the NAT legally
  > does!
  >
  Elsewhere this is discussed as authentication.  Please do not use
  "signature" here.  This is not a signature scheme.

Follow-up message sent to folks with LC comments:

To: ericlklein@softhome.net, henrik@levkowetz.com, karen.e.nielsen@ericsson.com, Francis.Dupont@enst-bretagne.fr, Markku.Ala-Vannesluoma@nokia.com, Jonathan Rosenberg
From: Margaret Wasserman
Subject: draft-huitema-v6ops-teredo-03.txt
Cc: v6ops@ops.ietf.org
Bcc:
X-Attachments:


Hi Eric, Henrik, Karen, Francis, Markku and Jonathan,

There is a new version of the Teredo draft available at:

http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-03.txt

Could you check whether this version addresses the issues that you raised during IETF LC?  It would be best if you could review this document and return any feedback by this Thursday, 9-Dec-04.

If there are no further objections, I will place this draft on the IESG agenda for consideration on our 16-Dec-04 telechat.

Thanks!

Margaret

List of Last Call comments received (for later reference):

- Eric Klein [ericlklein@softhome.net] (with retort from Jeroen Massar,
Pekka Savola and Jonne Soininen]
- Karen Nielsen
- Francis Dupont [addition by Paul Hoffman, Jeroen Massar, Joe Abley]
- Markku Ala-Vannesluoma
- Henrik Levkowetz [henrik@levkowetz.com]
- Jonathan Rosenberg

IAB Review:

From: Jonathan Rosenberg
To: The IESG , Christian Huitema
Cc: IAB
Subject: IAB comments on IAB considerations section of teredo

IESG, Christian,

The IAB has reviewed the IAB considerations section of draft-huitema-v6ops-teredo, and has the following comments:

> The specific problems being solved by Teredo is the provision of
>    IPv6 connectivity for a host that cannot obtain IPv6 connectivity
>    either natively or by other means, such as 6to4.

s/problems/problem

The scope of teredo is a little more focused that that; it concentrates on IPv4 hosts that cannot make use of 6to4 because of the presence of a NAT between them and the relay.

> Teredo comes with its own built in exit strategy: as soon as IPv6
>    connectivity is obtained by other means, Teredo will cease to be
>    used.

This is true for any particular client, not for the service overall. Suggest rewording to: "Teredo comes with its own built in exit strategy: as soon as a client obtains IPv6 connectivity by other means, either 6to4 or native IPv6, it can cease using the Teredo service."

This fact really represents the essence of the reason why teredo would be short lived. However, this fact requires some justification. There would appear to be reasons why a teredo implementation might decide to continue usage of the teredo service:

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

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

These are just examples. I suggest that this part of the IAB considerations section present a stronger justification for why this sunset is likely to occur, or if there are reasons where it may not happen, that these be documented. This does not mean that the document needs to discuss the above two issues in particular; it should only do so if the authors of teredo believe that these are valid reasons why such a transition may not occur. In cases where such considerations are documented in other specifications (for example, RFC 3904), it is acceptable to merely reference the appropriate section of that specification.

> Teredo introduces brittleness into the system in several ways: the
>    discovery process assumes a certain classification of devices based
...snip...
>... unreachable from each other. (There are
>    many similarities between these points and those introduced by STUN
>    [RFC3489].)

s/beyond/behind

I believe that teredo is actually less brittle than STUN in its discovery procedures. The reason is that all teredo packets are sent from the local IPv4 teredo service port, including discovery, bubbles and actual encapsulated packets. This is different from STUN, where NAT type detection and binding allocation use different local ports (ephemeral, in both cases). One of the difficulties found in real NATs is that their behavior depends on whether or not the source port on the private side has already been allocated. In some NATs, the behavior can vary between full cone and port restricted depending on this. In regular STUN, this means that the NAT type detection may reveal full cone, but actual binding allocations may see port restricted behavior. This is not so with teredo since only a single mapping is used in the NAT for all functions. This difference is worth pointing out.

> The use of the Teredo server as an additional network element
>    introduces another point of potential security attack. These
>
...snip...
>    Teredo server, or if the server should be unavailable due to
>    failure, the Teredo client will not be able to obtain IPv6
>    connectivity.

Teredo introduces two elements - the relay and the server, not just one.


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

* Teredo service will not work through NATs of the symmetric variety

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

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

>  Teredo imposes some restrictions on the network topologies for
>    proper operation. In particular, if the same NAT is on the path
...snip...
>... are connected to the same link, or
>    if the common NAT is capable of "looping" packets sent by one client
>    to another.

This is referred to as "hairpinning" in http://www.ietf.org/internet-drafts/draft-audet-nat-behave-00.txt; I'd suggest usage of that terminology.


Thanks,
Jonathan Rosenberg for IAB

Follow-up IANA Last CALL COMMENTS:
From: Christian Huitema
The required prefix length is /32.
The current deployments use a prefix in the temporary range (3ffe).
I don't think that writing the prefix in the "INTERNET PROTOCOL VERSION
6 ADDRESS SPACE" table is appropriate.
I would suggest a mechanism similar to the allocation of prefixes to
special networks.

Last call comments received from Henrik Levkowetz (attached).  Also, the IANA considerations section needs further detail/clarification.

From: Henrik Levkowetz
To: iesg@ietf.org
Cc: huitema@microsoft.com
Subject: Re: Last Call: 'Teredo: Tunneling IPv6 over UDP through NATs' to
Proposed Standard

Hi,

I've read through this draft; my full comments, including
editorials, are given below, and also inline in the draft, here:

http://ietf.levkowetz.com/tools/rfcmarkup/rfcmarkup.cgi?url=../../reviews/review-huitema-v6ops-teredo-02.txt&comments=HENRIK

Major comments:

1. The role, or architectural function if you will, of a teredo
relay is not sufficiently well defined early on in the text.
I find myself guessing and wondering about this throughout
the text, all the way to the section that goes into detail
about the relays.  I think this should be clarified early,
possibly with more text than just an expansion of the
definition.  A diagram would be excellent for this.

2. There is no explanation or justification given for the
bit-by-bit inversion ("obfuscation") of IPv4 addresses which are
embedded in teredo bubbles and addresses.  I'm not sure if the
inversion makes sense, I suspect the reason is to prevent
busybody NATs from translating the addresses, but however this
is, there should be an explanation and justification of the
practice.

3. Section 5.5 specifies that teredo servers should announce a
date at which they will stop providing the service, but there is
no mechanism specified for this.  A notice in the local
newspaper?  A note on the providers web page?  A router
advertisement giving the stop date?

Minor Comments (marked HENRIK):

Section 3.1, para. 2:

    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.
HENRIK: s/ these three types NATs.//


Section 3.4, para. 3:

    The Teredo address embeds the "mapped address and port" through
    which the client can receive IPv4/UDP packets encapsulating IPv6
    packets. If the client is not located behind a cone NAT, packet
    transmission must be preceded by an exchange of "bubbles" that will
    install a mapping in the NAT. This document specifies how the
    bubbles can be exchanged between Teredo clients in order to enable
    transmission along a direct path.
HENRIK: suggest changing 1st sentence to "The Teredo address has
embedded in the IPv6 address the "mapped address and port" through
which the client can receive IPv4 UDP packets encapsulating IPv6
packets."


Section 3.4, para. 4:

    Teredo clients can exchange IPv6 packets with plain IPv6 nodes (e.g.
    native nodes or 6to4 nodes) through Teredo relays. Teredo relays
    advertise reachability of the Teredo prefix to a certain subset of
    the IPv6 Internet: a relay set up by an ISP will typically serve
    only the IPv6 customers of this ISP; a relay set-up for a site will
    only serve the IPv6 hosts of this site. Dual-stack hosts may
    implement a "local relay", allowing them to communicate directly
    with Teredo hosts by sending IPv6 packets over UDP and IPv4.
HENRIK: The last sentence is hard to digest because there is no
indication of why this is needed, how this is different from
a regular Teredo client.

HENRIK: It is not immediately clear to me what the difference is
between a Teredo relay and a 6to4 router - or rather, why
one would use a Teredo relay instead of a 6to4 router.
Maybe clarify this?


Section 3.4, para. 5:

    In order to prevent spoofing, the Teredo clients perform a relay
    discovery procedure by sending an ICMP echo request to the native
    host, through the Teredo server. The payload of the 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
    to discover this relay. In order to prevent spoofing, the Teredo
    client verifies that the payload of the echo reply contains the
    proper random number.
HENRIK: Hard to parse this paragraph.  A diagram would help, I think;
or it may be a problem with the assumptions.
HENRIK: From the previous paragraph, I got the impression that relays
were deployed close to the client - now I think close to the
contacted host?  Clarify


Section 4, para. 4:

    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.
HENRIK: A rationale for this inversion (obfuscation is to strong a word,
I think) is sorely needed here.


Section 4, para. 8:

    - 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
    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 sent as zero and
    ignored on receipt.
HENRIK: Reading this, I get the impression that the zeroes are
necessary to have a valid Modified EUI-64 ID.


Section 4, para. 9:

    There are thus two 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. (Further versions of this specification may
    assign new values to the reserved bits.)
HENRIK: Now I suddenly get the impression that the zeroes are not forced,
but are rather reserved bits.  So maybe the bits which are in
fact reserved bits should be indicated by 'r' rather than 'z'
and called reserved, rather than zero bits.


Section 5.4.1, para. 1:

    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.
HENRIK: s/Teredo Server/Teredo relay/


Section 5.4.2, para. 1:

    The Teredo relay may receive packets from Teredo clients; the
    packets should normally only be sent by clients to which the relay
    previously transmitted packets, i.e. clients whose IPv6 address is
    present in the list of peers. Relays, like clients, use the packet
    reception procedure 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 relay checks that it contains a valid IPv6 packet as
    specified in [RFC2460]. If this is not the case, the packet is
    silently discarded.
HENRIK: s/received over/received on/


Section 5.4.2, para. 3:

    The Teredo relay then examines whether there is an entry for the
    IPv6 source address in the list of recent peers. If this is not the
    case, the packet may be silently discarded. If this is the case, the
    entry status is set to "trusted"; the relay updates the "date and
    time of the last interaction" to the current date and time.
HENRIK: s/may be silently/MAY be silently/ ?


Section 5.4.3, para. 2:

    The dual-role of server and relays implies an additional complexity
    for the programming of servers: the processing of incoming packets
    should be a combination of the server processing rules defined in
    5.3.1, and the 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.)
HENRIK: Maybe point out this already at the beginning of Section 5.3 ?


Section 5.5, para. 2:

    The Teredo-capable nodes MUST NOT behave as Teredo clients if they
    already have IPv6 connectivity through any other means, such as
    native IPv6 connectivity; in particular, nodes that have a global
    IPv4 address SHOULD obtain connectivity through the 6to4 service
    rather than through the Teredo service. The classic reason why a
    node that 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 has IPv4
    connectivity and that has obtained IPv6 connectivity outside the
    Teredo service MAY decide to behave as a Teredo relay, and still
    obtain good performance when interacting with Teredo clients.
HENRIK: (Why? Explain rationale and tradeoffs?)


Section 5.5, para. 3:

    The Teredo servers are expected to participate in the sunset
    procedure by announcing a date at which they will stop providing the
    service. This date depends on the availability of alternative
    solutions to their clients, such as "dual-mode" gateways that behave
    simultaneously as IPv4 NATs and IPv6 routers. Most Teredo servers
    will not be expected to operate more than a few years, perhaps until
    at most 2006.
HENRIK: Announce a date - how?  Surely the mechanism must be explicitly
indicated if this is to work...


Section 8.3.1, para. 0:

8.3.1 Denial of service by server spoofing
HENRIK: Out of sequence section numbering. This also affects the later
7.3.x sections.


Section 7.3.4, para. 1:

    It is possible to mount a brute force denial of service attack
    against the Teredo servers by sending them a very large number of
    packets. This attack will have to be "brute force", since the
    servers are stateless, and can be designed to process all the
    packets that are sent on their access line.
HENRIK: s/against the/against/
    The brute force attack against the Teredo servers is mitigated if
    clients are ready to "failover" to another server. Bringing down the
    servers will however force the clients that change servers to
    renumber their Teredo address.
HENRIK: maybe s/servers/server/g


Section 7.3.4, para. 2:

    It is also possible to mount a brute force attack against a Teredo
    relay. This attack is mitigated if the relay under attack stops
    announcing the reachability of the Teredo service prefix to the IPv6
    network: the traffic will be picked up by the next relay.
HENRIK: This is a bit brief... I think there are some unstated
assumptions here.


Section 7.4, para. 1:

    There is a widely expressed concern that transition mechanisms such
    as Teredo can be used to mount denial of service attacks, by
    injecting traffic at locations where it is not expected. These
    attacks fall in three categories: using the Teredo servers as a
    reflector in a denial of service attack, using the Teredo server to
    carry a denial of service attack against IPv6 nodes, and using the
    Teredo relays to carry a denial of service attack against IPv4
    nodes. The analysis of these attacks follows. A common mitigating
    factor in all cases is the "regularity" of the Teredo traffic, which
    contains highly specific patterns such as the Teredo UDP port, or
    the Teredo IPv6 prefix. In case of attacks, these patterns can be
    used to quickly install filters and remove the offending traffic.
HENRIK: In all three discussions below, there is no discussion of
amplification.  Would that be appropriate?  (It seems to me that
none of the listed possibilities offer any noticeable
amplification ...)


Section 9, para. 1:

    This memo documents a request to IANA to allocate a Teredo IPv6
    service prefix, and a Teredo IPv4 multicast address.
HENRIK: This doesn't tell IANA the length of the proposed prefix.
That detail should probably be repeated here, with a reference
to the relevant section.

IANA LAST CALL COMMENTS:
The IANA Considerations section says the following:

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

It would be helpful if there was some guidance on the size
of the prefix.  Will this allocation be made in the following registry?