AD review of draft-krishnan-v6ops-teredo-update

[Jari Arkko <[e-mail]>]

I have reviewed this draft and have the following comments. In general, the draft is in good shape and can move forward. I have two small technical issues and a few minor editorial ones. Nevertheless, I have decided to initiate last call, but I would appreciate a quick document update in the next few days to correct these issues.

Technical:

Teredo Client: A node that has access to the IPv4 Internet and wants
to gain access to the IPv6 Internet.
  

There are lots of such nodes, but not all of them are Teredo clients, i.e., implement the Teredo protocol... please correct the definition.

Opening a hole in an enterprise firewall
[http://tools.ietf.org/html/draft-krishnan-v6ops-teredo-update-06#ref-I-D.ietf-v6ops-tunnel-security-concerns" title='"Security Concerns With IP Tunneling"' rel="nofollow">I-D.ietf-v6ops-tunnel-security-concerns]: Teredo is NOT RECOMMENDED
as a solution for managed networks.  Administrators of such networks
may wish to filter all Teredo traffic at the boundaries of their
networks.
  

I'm not sure the term "managed networks" is a correct one here. There are many types of managed networks, some care about blocking Teredo and some would not. Suggested rewrite:

"Opening a hole in an enterprise firewall [I-D.ietf-v6ops-tunnel-security-concerns]: Teredo is NOT RECOMMENDED as a solution for networks that wish to implement strict controls for what traffic passes to and from the Internet.  Administrators of such networks may wish to filter all Teredo traffic at the boundaries of their networks."

(Also, speaking personally, I may not completely agree with the conclusions from draft-ietf-v6ops-tunnel-security-concerns that inspection of tunneled traffic is always hard and inefficient. I think there is some room to allow firewalls to inspect tunneling traffic on top of well-known and established tunneling protocols such as Teredo.)

Editorial:

Teredo IPv6 Address: An IPv6 address that starts with the prefix
2001:0000:/32 and is formed as specified in http://tools.ietf.org/html/rfc4380#section-2.14" rel="nofollow">[RFC4380] section 2.14.
  

Wouldn't Section 4 be a better reference here?

Teredo addresses are structured and some of the fields contained in
them are fairly predictable.  This can be used to better predict the
address.
  

I would rewrite the second sentence (which currently doesn't say much) as follows: "This makes it easier to predict an address, opening a (small) vulnerability."

   open on a IPv4 address, prior to trying to form a Teredo address for

s/on a/on an/

4. Acknowledgments
....
5. Security Considerations

I think it would be better if all the technical parts of the document were explained first, followed by the acknowledgment section. That is, I think Section 5 would come more naturally before Section 4.

Jari