[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

comments on deprecate-site-local-00



Hi,

A couple of comments on deprecate-site-local draft.  In general, I think 
the doc is very good, but could use a bit boosting in a couple of areas 
(which -00 draft wouldn't.. :-)


substantial
-----------

Although the consensus was far
   from unanimous, the working group decided in its meeting in July
   2003 to document these issues and the consequent decision to
   deprecate IPv6 site-local unicast addresses.

==> was this really the case?  Didn't the WG decide on that already earlier,
not at Vienna??

2       Adverse effects of site local addresses

==> I showed this draft to a believer of site-local addressing, who had had
very little experience with IPv6.  He was not convinced of the arguments. 
This may be for one of the many reasons.  One fix is to also refer to some
documents which include more verbiage than this document, e.g. Margaret
Wasserman's SL impact document -- note that such would necessarily have to
be a normative reference then, requiring the publication of it as an
Informational doc.

2.2     Manager pain, leaks

==> regarding the previous comment, this section should probably 
focus a bit more on the non-trivial leaks (any leak w/ RFC1918 addresses in
the source/destination address is trivial), such as reverse DNS queries for
RFC1918 addresses, passing RFC1918 addresses in the application payloads in
general, etc. (pick non-NAT specific topics e.g. from Keith Moore's "What
NATs break" paper or "NAT architectural considerations" RFC).

5       Security Considerations
   
   The link-local unicast prefix allows for some blocking action in
   firewall rules and address selection rules, which are commonly
   viewed as a security feature since they prevent packets crossing
   administrative boundaries. However, such blocking rules can be
   configured for any prefix, including the expected future replacement
   for the site-local prefix. Thus the deprecation of the site-local
   prefix does not endanger security.

==> s/link/site/, obviously.

==> I think the security considerations considers only one, but important
aspect of the site-locals.  One should also discuss the effect of stability
to the availability (which is part of security), and the effect of explicit
scope  to the address selection -- e.g., the case with intra-domain
VPN's which route some traffic directly to the Internet but some to through
the VPN to the infrastructure: how to ensure that the traffic destined to
internal hosts over the VPN doesn't end up in the Internet by accident
(e.g. if the VPN is down).



editorial
---------

   example in DNS or trace-route requests, causing the request to fail,

==> s/trace-/trace/

   The leakage issue is largely unavoidable. While some applications
   are intrinsically scoped (eg. RA, ND), most applications have no

==> have to spell out RA & ND

   The current definition of scopes follows an idealized "concentric
   scope" model.

==> I don't understand the use of "concentric" in this context ?
perhaps reword?

  boundaries, QOS boundaries, administrative boundaries, funding
   boundaries, some other kinds of boundaries, or a combination. It is

==> s/combination/combination of these/ ?

   Having non ambiguous address solves a large part of the developers'

==> s/non ambiguous/non-ambiguous/ (everywhere) ?

  This document formally deprecates the IPv6 link-local unicast prefix
   defined in [RFC3513], i.e. 1111111011 binary or FEC0::/10. The
   special behavior of this prefix MUST no longer be supported in new 
   implementations.

==> if the uppercase keywords are used, one has to add the reference to the
definition of them up front in section 1 or thereabouts.

9       Acknowledgements

==> should probably be non-empty :-)

10      References

==> you're missing a ref to [Bradner, 1996].

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------