Pekka, Thanks for the review.
Pekka Savola wrote: > > 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?? It seems to me that the documentation decision was definitely not made in San Francisco. But we can fix this by s/decided/confirmed/ > > 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. People who don't understand the down side of RFC 1918 are hard to convince by more verbiage, in my experience. So I don't think this would be a good use of our collective effort. Are there any specific weak points? > > 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). I'm not disagreeing with your points, but does this document really need an extended security analysis? That belongs in the specification for the replacement (if any) of site locals, surely? Brian > > 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 > [EMAIL PROTECTED] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS <[EMAIL PROTECTED]> PLEASE UPDATE ADDRESS BOOK -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
