Subject: comments on deprecate-site-local-00

From: Pekka Savola <[email-masked]>
Date: Wed, 17 Sep 2003 15:20:56 +0300 (EEST)

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
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 22 Sep 2003 12:14:07 +0200

Pekka,

Thanks for the review.

> (which -00 draft wouldn't.. :-)

It seems to me that the documentation decision was definitely not made 
in San Francisco. But we can fix this by s/decided/confirmed/

> be a normative reference then, requiring the publication of it as an

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?

> (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

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

---

From: Pekka Savola <[email-masked]>
Date: Tue, 23 Sep 2003 09:02:31 +0300 (EEST)

On Mon, 22 Sep 2003, Brian E Carpenter wrote:
> good use of our collective effort. 

True, but if we wish to remain relevant, something has to be written 
somewhere.  I fully agree that doing so in *this* document may not be 
worth it; it might be worth it in some other doc, e.g. sl-impact.

> Are there any specific weak points?

Trying to summarize:
 - 2.1: trying your own local addresses while visiting another site is a 
problem, but no news compared to RFC1918
 - 2.2: the "leaking" of addresses may not be clear enough.  The reader 
interpreted that as source/destination addresses (trivial!) and DNS.  The 
*difficult* problems are elsewhere..
 - 2.3: the reader didn't notice that the difficulty of routing lies with 
overlapping or adjacent sites.

I'll send the exact wording off-list..

> replacement (if any) of site locals, surely?

Well, I'm not sure if the document does need it; maybe not.  However, the 
security considerations as it is is a bit one-sided.  It should be either 
tailed down a bit or extended.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 23 Sep 2003 08:57:26 +0200

> worth it; it might be worth it in some other doc, e.g. sl-impact.

I agree with Pekka. HAving this in writing somewhere is important.

Best regards,

- - kurtis -

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 23 Sep 2003 16:41:16 -0400

>I agree with Pekka. HAving this in writing somewhere is important.

I'd be happy to dust off my sl-impact draft, and update it based
on the feedback I've received so far, if folks think that would be
useful...

Margaret

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Sep 2003 09:35:24 +0200

I definitely think so. I think it's better if the deprecation document,
which is a standards action, stays mean and lean so that it can be read
in 5 minutes, with the full details of the issues being Informational.

   Brian

---

From: Tim Chown <[email-masked]>
Date: Wed, 24 Sep 2003 10:40:59 +0100

> on the feedback I've received so far, if folks think that would be

Please.  It's excellent to have the issues in one place (other than 
embdedded in a few hundred mails in the list archive :).

Tim

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 25 Sep 2003 16:16:59 +0200

> on the feedback I've received so far, if folks think that would be

That could be a good base, but I think that what Pekka asked for and at 
least what I would hope for, would be broader.

Best regards,

- - kurtis -

---

From: Måns Nilsson <[email-masked]>
Date: Sat, 27 Sep 2003 14:22:29 +0200

> on the feedback I've received so far, if folks think that would be

Yes, please do. 

-- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC  MN1334-RIPE

We're sysadmins. To us, data is a protocol-overhead.