[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: huitema-v6ops-teredo-01 comments
A long time ago, Pekka sent to the list a detailed review of the Teredo
draft. I have just submitted draft-huitema-v6ops-teredo-02.txt that
addresses these comments, and also fixes a typo found by Eiffel Wu in
the qualification procedure diagram. Thanks to both reviewers.
What follows is a detailed reply to Pekka's comments.
-- Christian Huitema
> substantial
> -----------
>
> 1) sect 5.2.1, qualification procedure seems to yield either cone NAT,
> restricted cone NAT or symmetric NAT. What about port-restricted cone
> NATs? Are these implicitly covered in some terminology here? They
> don't seem to be explicitly mentioned anywhere!
Yes, restricted and port restricted are treated the same way. I will
make that explicit in the revision.
> 2) security considerations should discuss that MD5 is not anymore
> considered "secure" due to better collision-resistance of SHA1.
> However, in this specific case, I don't think this is a huge problem.
I will rewrite the text to indicate that MD5 is just a convenient
default, but that client and servers can agree on a different algorithm.
The packet format already allows for variable length authentication
checks, and the key has to be provisioned explicitly in the client, so
we could conceivably provision both the key and the algorithm, and just
leave it a configuration option. But the main threat is a dictionary
attack, for which there is no difference between MD5 and SHA1.
> 3) I think this document seriously needs an "overview" section, around
> section 4, which could be e.g. 2-4 pages, trying to summarize the
> whole operation while leaving out the details with figures, etc. --
> whatever appropriate. The spec is rather compact and requires careful
> reading to understand its implications. Having such a section (as
> there was before, but it was removed, I think) would be very useful
> for those who want to get a good overview of how the mechanism works.
The problem with the previous version was that it introduced confusion
-- implementers were confused as to which part was normative, the
overview or the protocol specification.
> 4) what's the implementation status? to what degree do the
> implementation(s) reflect the current spec? I have a few thoughts for
> improvements if certain parts of the spec would not be implemented yet
> (e.g., the authentication encapsulation), but if they are, making such
> changes might not be feasible.
The specification tries to closely reflect the existing implementations.
> 5) an interesting deployment model could be deploying a
> Teredo-cognizant tunnel broker at the teredo anycast address,
> basically "hijacking" all the teredo users as your tunnel broker
> customers -- requiring no tunnel broker implementations at the client
> side. This would be a rather interesting way to leverage the existing
> implementations to provide tunnel broker service :-).
There is no Teredo anycast address, but I see the idea: have the client
automatically discover whether the Teredo server is willing to act as a
tunnel end-point. In that case, the client would go for a classic tunnel
mode.
> 6) this doc probably needs a bit more applicability etc. work but
> that's something that can be inserted a bit later on as well.
>
> semi-editorial/substatial
> -------------------------
>
> Abstract
>
> We propose here a service that enables nodes located behind one or
> several 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.
>
> ==> the last sentence is not accurate when you take also the "6to4
> universe" into account -- needs rewording somehow?
OK.
> 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 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 suffers a high
> cost. For these two reasons, we tend to prefer solutions that allow
> for "automatic tunneling", i.e. let the packets follow a direct
path
> to the destination.
>
> ==> I'd reword this to a bit softer, because tunnel brokers are
> actually useful in some contexts:
> ==> s/is not very good/may be limited/
> ==> s/we tend to prefer/it may be desirable to have/
OK.
> 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. The IPv4
> address may or may not be globally routable, as the client may be
> located behind one or several NAT.
>
> ==> ports are not attached to interfaces. They may be attached to
> addresses only. So, maybe rename "Teredo service port" to "Teredo
> service address/port" or whatever, and reword the text a bit?
I reworded to mention binding to a specific address.
> Experience shows that the implementers of NAT devices can adopt
> widely different treatments of UDP mappings:
>
> ==> if this has been analyzed at more length elsewhere, I'd refer to
> that work for additional information. Later in the document, RFC3489
> is cited as one source, at least.
OK, done that.
> 3) Instead of keeping just a list of authorized hosts, some NAT
> implementations keep a list of authorized host and port pairs. UDP
> packets coming from remote addresses are rejected if the internal
> host has not yet sent traffic to the outside host and port pair.
The
> NATs are often called "port-restricted cone NATs"
>
> ==> I've always had problems figuring out what this means. I suggest
> adding a new second-to-last sentence:
>
> That is, as long as the internal host has communicated with a (host,
> port) pair, the created NAT mapping (to some other host or port) can
> be used to inject incoming packets to the internal host.
Replaced by a pointer to STUN/RFC3489.
> 3.2.1 When to use Teredo?
>
> Teredo is designed to robustly enable IPv6 traffic through NATs,
and
> the price of robustness is a reasonable amount of overhead, due to
> UDP encapsulation and transmission of bubbles. Nodes that want to
> connect to the IPv6 Internet SHOULD only use 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 the local NAT, and they SHOULD prefer
> using the less onerous "6to4" encapsulation if they can use a
global
> IPv4 address.
>
> ==> this doesn't yet describe tunnel service (details TBD at the
> moment) at all -- it is also a preferable choice.
OK, added text.
> 4 Teredo Addresses
>
> ==> I'd consider separating this to two subsection, global and
> link-local addresses -- as these seem to have slightly different
> characteristics.
>
> - The bits indicated with "z" must be set to zero.
>
> ==> s/set to zero/sent as zero and ignored on receipt/ ?
OK.
> The Teredo relay advertises reachability of the Teredo service
> prefix over IPv6. It forwards Teredo IPv6 packets to the
appropriate
> IPv4 address and UDP port.
>
> ==> local relays don't do the first. This has been ignored in a few
> other places in the document as well.
OK.
> 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
> 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".
>
> ==> this obfuscation code has been described in two places -- maybe it
> would make sense to put it in a subsection or something, so it could
> be referred to more easily when it's used later on in the draft?
I find simpler to leave it as is.
> The third octet indicates the length of
> the client identifier; the fourth octet indicates the length of
> the authentication value.
>
> ==> is zero client ID OK as well? The same about authentication
> value? (these could be useful if you'd only want "return routability"
> like anonymous testing, where you'd only want to use nonces.
Yes.
> ==> these octets give the length in the units of bytes, correct? (make
> explicit)
OK.
> 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.
>
> ==> this seems quite long, and I don't see how RFC2461 relates here.
> Maybe e.g. T=2, N=1 would be sufficient?
We are performing an RS/RA exchange, so the value in RFC2641 apply. If 4
seconds is a proper value on an Ethernet, why should we pick a lower
value on a longer-delay network?
> 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
>
> ==> "global" --> remove that, could be local as well?
Uh, no. Unless we define a brand new /32 that has no global meaning.
> If the client has received an RA with the "Cone" bit 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.
>
> ==> there are multiple places where Cone bit can be set, so maybe
> reword like:
>
> If the client has received an RA with the "Cone" bit in the
> advertised prefix set to 1, it is behind a cone NAT and is fully
> qualified. If the RA is received with the Cone bit in the
> advertised prefix 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 in the link-local address remaining to the value zero.
>
> ....
I checked the text a bit.
> 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
>
> ==> s/to receive the RA/in the RA/ ? Or am I confused about cone bit
> in the prefix vs. link-local address?
It is in the address.
> 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],
>
> ==> you must spell out what exactly to check, as RFC2460 does not
> specify what is a "valid IPv6 packet". The same happens a lot later
> in the spec as well.
OK.
> if an origin indication is
> present, the client should perform the "direct IPv6 connectivity
> test" described in section 5.2.9.
>
> ==> should you use more uppercase keywords, e.g., in here, but in
> several other places as well?
Matter of taste, I guess...
> If the values match, the packet
> should be accepted; the date and time of the last reception from
the
> peer should be updated.
>
> ==> s/should be/is/ ?
OK.
>
> 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 of the reply matches the "nonce" stored in the peer entry,
> the packet should be accepted;
>
> ==> s/content/ICMPv6 data/
OK.
> any packet queued for this IPv6
> peer should be de-queued and forwarded to the newly learned IPv4
> address and UDP port.
>
> ==> add a pointer to 5.2.4 around queuing?
>
> 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 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.
>
> ==> and what if there is no such entry? do nothing?
Rearranged the order of paragraphs so the "what else" case is clearly
described in "6) In the other cases, ..."
> 5) If the IPv4 destination address through which the packet was
> received is the Teredo IPv4 Discovery Address, the source address
is
>
> ==> add a note here stating that this procedure is optional.
OK.
> 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. The packet will be de-queued and
>
> ==> s/5.2.8/5.2.9/
OK.
> 5.2.6 Sending Teredo Bubbles
>
> ==> this section should also discuss "indirect bubbles" (as introduced
> in 5.2.4) and how they're sent.
OK.
> 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.
>
> ==> umm.. why exactly are you setting the dates to 30 seconds in the
> history??
So we do not engage in futile immediate retransmission...
> 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 the maintenance
> procedure on this port and reset the date and time of the last
> interaction on the secondary port.
>
> ==> umm,, this would seem to hint at an implementation technique,
> where you'd be continously listening at the secondary port. I fail to
> see the need for that -- this is only done when you start up Teredo
> (if it's implemented that is). Rather, just specify that the port is
> closed when the procedure ends?
OK.
> A Teredo client who wishes to enable local discovery SHOULD wait
for
> discovery bubbles to be received on the Teredo IPv4 Discovery
> Address, and should send local discovery bubbles to the Teredo IPv4
> Discovery Address at random intervals
>
> ==> which -- wait _or_ send? Or both? Make it more explicit. Maybe
> just say that one should join the group.
OK.
> - IPv6 source: the Teredo IPv6 address of the sender
>
> ==> is this the global or link-local address?
Global.
> 5.3 Teredo Server specification
>
> ==> you should really add text here describing the forwarding of
> ICMPv6 probes, and bubbles between Teredo and non-Teredo nodes.
>
> ==> also, you should mention the requirement about the secondary
> address on the server.
Done.
> Upon reception 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.
>
> 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 IPv6 packet, the
packet
> MUST be silently discarded.
>
> ==> isn't the first paragraph unnecessary, compared to 1)?
> ==> you don't define well-formed?
OK.
> 2) If the UDP packet is not a bubble or an ICMPv6 message, it
should
> be discarded.
>
> ==> should probably add a pointer for the definition of a bubble.
Replaced by "Teredo bubble", which is defined in section 2.
> ==> should you use upper-case keywords in a place like this?
OK.
> 4) If the IPv6 source address is an IPv6 link-local address, the
> 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 be accepted; it
> MUST be discarded if the server requires secure qualification and
> the authentication encapsulation is absent or cannot be verified.
>
> ==> SHOULD be accepted? What's the alternative -- discard them?
> Shouldn't this be a mandatory part? (Same later in 5) and 6)
> ==> s/cannot be verified/verification fails/ ?
Ok.
> The Teredo server will then check the IPv6 destination address of
> the encapsulated IPv6 packet.
>
> ==> s/./:/
> ==> maybe the following paragraphs should be similarly separated to
> 1), 2) and 3) for clarity?
>
> If the IPv6 destination address is a valid Teredo IPv6 address, the
> Teredo Server MUST check that the IPv4 address derived from this
> IPv6 address is in the format of a global unicast address
>
> ==> a link-local address is also a valid Teredo address, right? But
> not applicable here? Maybe needs spelling out which specific address
> type?
OK, added reference to 2.13.
> 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.
>
> ==> how can the server know which addresses it's supposed to be
> servicing? Or are you really saying, "if received through the Teredo
> interface.." ?
If the client is served by this server, the server's IPv4 address is
copied in bits 32-63 of the client's Teredo IPv6 address.
> The IPv6 source address should
> be set to a Teredo link-local server address associated to the
local
> interface.
>
> ==> how exactly did you form the LL address on the server? What about
> the C-bit?
>
> However, Teredo relays do not have to
> perform the qualification procedure.
>
> [...]
> 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.
>
> ==> aren't these in conflict? The relay don't know which NAT it's
> behind unless it has run qualification procedure?
OK, I removed the "do not have" phrase.
> 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.
>
> ==> hmm.. could the list of peers information be stale, or is it
> purged often enough so that if the NAT mapping of a host changes,
> there won't be communication with it directly? Are there fallbacks?
If the NAT mapping of the host changes, its Teredo address also changes,
so the fallback occurs very naturally...
>
> Then, the Teredo relay examines whether the IPv6 source address is
a
> valid Teredo address, and if the mapped IPv4 address and mapped
port
> match the IPv4 source address and port number from which the packet
> is received. If this is not the case, the packet is silently
> discarded.
>
> ==> I've trouble figuring out how this would work -- maybe I'm
> confused. I mean, when the Teredo client sends toward different IPv4
> destination addresses, new mappings are created in the NAT for each --
> and this is by definition different from the one which is learned by
> the Teredo client from the Teredo Server?
No. If the NAT is cone or restricted cone, then the mappings are always
the same. They change if the NAT is symmetric, but we do not support
that.
> Finally, the relay examines the destination IPv6 address. If the
> destination is the "all nodes multicast address", the packet should
> be processed locally.
>
> ==> why this rule?
Humm. Unclear. Probably had to do with combining a relay and a client. I
removed it.
> 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.
>
> ==> this text is not clear enough on whether section 5.3 on Teredo
> servers already includes all the functionalitty required of Teredo
> servers + relays, or whether you need to combine 5.3+5.4 to get
> server+relay?
OK, added text.
>
> Most Teredo servers
> will not be expected to operate more than a few years, perhaps
until
> at most 2006.
>
> ==> umm, isn't this awfully optimistic? :)
Well, we have a time limit of 6/6/6 for the current prefix, don't we? We
could indeed make that 6/6/66 if you want...
> The very purpose of the Teredo service is to make a machine
> reachable through IPv6. By definition, the machine using the
> service
> will give up whatever "firewall" service was available in the NAT
> box; all services declared locally will become potential target of
> attacks from the entire IPv6 Internet. This may sound scary, but
> there are three mitigating factors.
>
> ==> "all services declared locally" is a bit short, maybe spell it
> out? Maybe also missing a word or two?
OK.
>
> The first mitigating factor is the possibility to restrict some
> services to only accept traffic from one of the limited address
> scopes defined in IPv6, e.g. link-local or site-local.
>
> ==> using link-locals w/ apps is IMHO pretty bad practice, and
> site-locals are gone. please update :)
Link local is actually used with some "home network" applications. I
have removed the reference to site-local.
> There is no
> support for such scopes in Teredo, which implies that limited-scope
> services will not be accessed through Teredo, and will be
> restricted
> to whatever other IPv6 connectivity may be available, e.g. direct
> traffic with neighbors on the local link, behind the NAT.
>
> ==> these also have teredo addresses, which go through the teredo
> server, etc. -- not from the same namespace, unless you configure them
> manually or using some other process..
>
> The third mitigating factor, already noted, is the 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
> with Teredo is a good policy, as it will protect the client from
> possible attacks in intermediate servers such as the NAT, the
> Teredo
> server, or the Teredo relay.
>
> ==> when you use these magic keywords, one must always ask, "OK, how
> do you do key distribution?" Not practical in many cases, I guess.
Well, it depends... But I can certainly use a phrase about key
distribution.
> Meta-issue here: opportunistic IPsec might leverage DNS records for
> storing the keys; I think Teredo doesn't support setting reverse DNS
> records at the moment. (Which maybe for the best, considering how
> often the addresses would probably change..)
Are you proposing using reverse DNS to get a certificate that can be
used for IPSEC? Well, I would much rather just say that we need to
distribute keys somehow...
> The goal of the Teredo service is to provide hosts located behind a
> NAT with a globally reachable IPv6 address. There is a possible
> class of attacks against this service in which an attacker somehow
> intercepts the router solicitation, responds with a spoofed router
> advertisement, and provides a Teredo client with an incorrect
> address.
>
> ==> actually, a more typical attack would be the attacker guessing the
> server address (simple if there are only a few of those), and the IPv4
> address/port of the destination. Then, by appropriate spoofing, a RA
> could be injected without getting hold of the RS's. Of course, this
> is practically impossible if the Authentication option (just using the
> nonces is enough) is included.
That's the point. Since we always have a nonce, the attacker needs to
intercept the traffic.
> The secure qualification procedure described in section 5.2.2
> enables a good protection against attacks in which a third party
> tries to spoof the server.
>
> ==> how would that secret (if you don't use just nonces) is
> distributed? Especially if the server is hosted by someone you don't
> have a direct relationship with, you could be in trouble..
The usual. Web services, for example.
> protect
> against this attack, the secret shared between client and server
> should be provisioned by an automatic procedure and contain
> sufficient entropy.
>
> ==> what are you referring to with "automatic procesdure"? 1)
> automatic distribution, or 2) automatic generation of secrets (trying
> ot ensure they have good enough entropy, e.g., are subject to e.g.,
> disctionary attacks) ?
>
> ==> I'd again want to note, that using null ID and null
> authentication, could still give you the 64bit protection using nonces
> -- which is not bad for a use case like this.
OK, I wrote text to that effect.
> ==> the authentication encapsulation does not provide replay
> protection, at least as specified, but some of this could be fixed I
> guess?
Actually it does, when combined with the nonce.
> 1) Client prepares router solicitation, including authentication
> header.
>
> ==> s/header/encapsulation/ (or something, to make sure this is not
> IPsec AH)
>
> 7.3.2 Denial of service by exceeding the number of peers
>
> A Teredo client manages a cache of recently-used peers, which makes
> it stateful.
>
> ==> this is a problem of Teredo relay as well, right?
Yes, although state can only be initiated from the IPv6 side.
> The ICMP Traceback (ITRACE) working group is considering systems
> for
> "tracing" the source of DOS attacks. According to the proposal,
> when
> forwarding packets, routers can, with a low probability, generate a
> Traceback message that is sent along to the destination; with
> enough
> Traceback messages from enough routers along the path, the traffic
> source and path can be determined. This set up assumes that the
> source and destination are both using the same version of IP. In
> the
> Teredo case, the ICMP Traceback packets will be sent to the Teredo
> server, not the final destination. It is conceivable to "map" the
> IPv4 traceback to an IPv6 traceback sent by the Teredo server; the
> details of the solution should be specified by the ITRACE working
> group.
>
> ==> unfortunately, the ITRACE WG was closed, and the spec is pretty
> much dead.. so I don't think we can count on this anymore. (The same
> issue later in the spec again)
>
> The exit strategy is facilitated by the nature of Teredo, which
> provides an IP level solution. IPv6 aware applications do not have
> to be updated to use or not use Teredo. The absence of impact on
> the
> applications makes it easier to migrate out of Teredo: network
> connectivity suffices.
>
> ==> The clients migrate out of Teredo, that's correct, but the actual
> problem is how do you retire (host-side, "local") relays? As long as
> there are Teredo hosts out there (10 years from now on?) having such a
> feature on the box would be useful (with some definition of useful).
> What's the exit strategy for these?
>
OK, added text.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> editorial
> ---------
>
> We propose here a service that enables nodes located behind one or
> several IPv4 NATs to obtain IPv6 connectivity by tunneling packets
>
> ==> s/one or several/one or more/ (isn't this the more common usage) ?
> (this is in very many places)
OK.
> several NATs; it also supposes that we can find a way to bypass the
> various "per destination protections" that many NATs implement. In
>
> ==> add a reference here to section 3.1?
Not needed.
> The specification is organized as follow. Section 2 contains the
>
> ==> s/follow/follows/
>
> 2.1 Teredo service
>
> ==> 16 subsections, none of which is longer than 1 paragraph, one for
> each term -- they explode the ToC. Maybe remove the subsections and
> put these in the body of section 2, otherwise identically?
>
> A node that has some access to the IPv4 Internet and that wants to
> gain access to the IPv6 Internet.
>
> ==> remove redundant "that" (the same in a few other examples as well)
> ?
>
> 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.
>
> ==> suggest rewording e.g. to be like:
>
> 2.10 Teredo mapped address and Teredo mapped port
>
> A global IPv4 address and a UDP port that result from the
> translation of the client's IPv4 address and Teredo service port by
> one or more NATs.
>
> ...
>
> of 30 seconds; a longer value may be determined by local tests,
> described in section 5.
>
> ==> s/described/as described/
>
> Relaying packets over TCP would be possible, but would result in a
> very poor quality of service; relaying over UDP is a better choice.
>
> ==> s/relaying/encapsulation/
>
> on the specified port for a "lifetime" period. The Teredo client
> that want to maintain a mapping open in the NAT will have to send
>
> ==> s/want/wants/
>
> when no traffic is observed is observed on the connection for a
>
> ==> remove extra "is observed"
>
> transition schemes designed by the NGTRANS working group. This
>
> ==> v6ops now?
>
> - Client IPv4: the obfuscated "mapped IPv4 address" of a client
>
> ==> s/a client/the client/
>
> There are thus two valid 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.
>
> ==> remove "valid" or even state like "two currently specified values"
> .. just to spell it out there might be more in the future.
>
> A third party sends IPv6 packets to a Teredo client by sending
these
> packets over UDP to the mapped IPv4 address and port 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 to first synchronize with the client, by sending an
> initial bubble through the server.
>
> ==> this seems to be mostly outside the scope of Teredo address
> specification, so one should either remove it or add references to the
> fuller specification later on in the draft.
>
> 5.1.1 Teredo IPv6 packets encapsulation
>
> ==> s/packets/packet/
>
> +--------+--------+--------+--------+
> | 0x00 | 0x01 | ID-len | AU-len |
> +--------+--------+--------+--------+
> | Client identifier (ID-len |
> +-----------------+-----------------+
> | octets) | Authentication |
> +-----------------+--------+--------+
> | value (AU-len octets) | Nonce |
> +--------------------------+--------+
> | value (8 octets |
> +--------------------------+--------+
> | | Conf. |
> +--------------------------+--------+
>
> ==> I'd really try to aim for using the typical "nice" figures such as
> the the ones used in RFC2461, RFC2463, etc.
>
> 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:
>
> ==> s/; t/. T/ ?
>
> +----+----+
> | Set C=1 |
> +----+----+
>
> ==> make more explicit that C means Cone bit?
>
> /---------\ Timer | ^
> |Starting |-------+ N attempts /----------\ Yes |
> \---------/------------------->| C == 1 ? |-----+
> | Response \----------/
>
> ==> does "N attempts" refer to moving from "Starting" to "Start", or
> to "C == 1?" state? Maybe reorganize the text a bit?
>
> /-----------------\
> | Restricted NAT |
> \-----------------/
>
> ==> restricted cone NAT you mean?
>
> 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;
>
> ==> maybe refer to sect 4?
>
> 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.
>
> ==> s/source address/IPv6 source address/ ?
>
> and local peer port parameters to reflect the IPv4 source address
> and UDP source port of the bubble the last reception date to the
>
> ==> s/bubble/bubble,/
>
> When it wants to send a packet to an IPv6 node on the IPv6
Internet,
> the client should check whether a valid peer entry already exists
>
> ==> swap "it" and "the client" here.
>
> destination. The ICMPv6 packet will then be sent encapsulated in a
> UDP packet bound to the local server IPv4 address, and to the
Teredo
> port. The rules of section 5.2.3 specify how the reception of this
> packet will be processed.
>
>
> ==> s/bound/destined/ ?
> ==> s/local server IPv4/Teredo server/ ?
> ==> s/reception of/reply to/ ?
>
> It is in many cases possible to work around the limitations of
> these
>
> ==> s/It is in many cases/In many cases, it is/ ?
>
> - The source IPv4 address is the server's IPv4 address.
>
> ==> s/server's IPv4/Teredo server/ (same in a couple of other places)
>
> 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.
>
> ==> this has some operationa requirements (i.e., the server having
> more than one address), which should be spelled out (already commented
> for section 5.3)
>
> Teredo relays are IPv6 routers that advertise reachability of the
> Teredo service IPv6 prefix through the IPv6 routing protocols.
>
> ==> or not, in the case of local relays..
>
> 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
>
> ==> split a new paragraph before "Before" ?
>
> It may be desirable in some cases to deploy stateful tunnel servers
> instead of the stateless Teredo servers. Tunnels servers generally
>
> ==> s/Tunnels/Tunnel/
>
> capacity. In summary, the attack is very hard to mount, and the
> gain
> for the attacker is minimal.
>
> ==> s/gain/additional gain/ ?
>
> its IPv6 traffic, using IPSEC. Even if the IPv4 and UDP headers are
> vulnerable, the use of IPSEC will effectively prevent spoofing and
>
> ==> s/IPSEC/IPsec/ (everywhere)
>
> 8.3.1 Denial of service by server spoofing
>
> In section 8.2, we discussed the use of spoofed router
>
> ==> s/8.3/7.3/, s/8.2/7.2/ ?
>
> non existing IPv4 address or to the IPv4 address of a third party.
>
> ==> s/non/non-/
>
> 7.4.1 Laundering DOS attacks from IPv4 to IPv4
>
> ==> s/DOS/DoS/
>
> on their treatment of UDP; the mappings need to be continuously
> refreshed, while the ; and addressing structure may cause some
> hosts
>
> ==> something missing around ";"
>
OK, done all that.