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
[I-D.ietf-v6ops-tunnel-security-concerns <http://tools.ietf.org/html/draft-krishnan-v6ops-teredo-update-06#ref-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 [RFC4380] section 2.14 <http://tools.ietf.org/html/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