Subject: RE: IPv6 w.g. Last Call on "Deprecating Site Local Addresses"

From: "Christian Huitema" <[email-masked]>
Date: Wed, 5 Nov 2003 12:11:16 -0800

> From: Erik Nordmark, October 22, 2003 1:34 PM
> To: Brian Haberman
> Cc: [email-masked]
> Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses"
> 
> 
> Overall I support this document, but there are two things that have
> me concerned.
> 
> 1. The document talks about a replacement in section 2 and section 5.
> While finding replacement for what folks perceived as being benefit
> with site local addresses is useful (and perhaps even required),
> the text in this draft seems to lock us down into replacement that
> consist of defining some new address format.
> I find this odd since the the WG has discussed partial replacement
> solutions
> (for instance, draft-zill-ipv6wg-zone-prefixlen-00.txt) which do not
> involve
> defining a new address format.
> 
> Does this document indeed intend to prevent the WG from working
> on replacement solutions which do not define a new addressing format?
> That would seem silly thus I suggest the text be reworked a bit to
> make this more clear.

The 'prefix length' draft is indeed independent of address formats, and
provides an alternative to the use of site local addresses for security.
I would agree to add a short paragraph describing how a prefix length
option can be a helpful part of the solution. However, this option alone
does not solve the other requirements, e.g. stable addresses that don't
depend on out-of-site events. 

> 2. Section 2 talks of only two categories of issues but I
> think there is a 3rd one: "moving the problem to the application
space".
> 
> The text in section 2.1 talks of only one aspect of this (having to
deal
> with scope ids in the application).
> draft-wasserman-ipv6-sl-impact-02.txt in section 3.7 has additional
> issues relating to:
>          - Two-party client/server applications that exchange IP
>             addresses at the application layer.
>          - Multi-party applications that exchange IP addresses at the
>             application layer.
> Thus in particular the last two paragraphs in section 3.7 in
> draft-wasserman-ipv6-sl-impact-02.txt seems to be missing from this
draft
> and I think they need to be included to make sure important aspects of
> the issues are not forgotten as we move forward.

OK. I think we can easily add a section with these two paragraphs and
capture the idea.

-- Christian Huitema

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 6 Nov 2003 09:20:32 -0800

Actually, the 01 draft includes two changes to address Pekka's feedback:
add some explanatory text in section 2.2, address leak, and section 2.3,
routing pain; and in section 5, qualify that the replacement of site
local is only as secure if blocking rules are actually implemented at
site boundaries. But it is clear that we want to keep the document short
and concise, and thus chose to not widely expand the text in section 2
and 5.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian
> E Carpenter
> Sent: Thursday, November 06, 2003 7:59 AM
> To: Pekka Savola
> Cc: Brian Haberman; [email-masked]
> Pekka, it's been a while, but my recollection is that we (the authors)
> didn't agree and didn't see any support for your comments on the list.
> 
> I could be wrong.
> 
>    Brian
> 
> Pekka Savola wrote:
> >
> > On Wed, 5 Nov 2003, Brian Haberman wrote:
> > > This is a reminder that the last call on the deprecation document
> > > ends today.  In particular, the chairs would like to ensure that
> > > the WG agrees on the actual deprecation text in Sections 4 & 6.
> > > There has been few comments on this draft and it cannot proceed
> > > unless the chairs can be sure that it has been thoroughly reviewed
> > > and agreed upon.
> >
> > I do not believe the -01 version addresses the comments I made to
the -
> 00
> > version.
> >
> > --
> > Pekka Savola                 "You each name yourselves king, yet the
> > Netcore Oy                    kingdom bleeds."
> > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> >
> --
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Brian E Carpenter
> Distinguished Engineer, Internet Standards & Technology, IBM
> 
> NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK
>

---

From: "Elwyn Davies" <[email-masked]>
Date: Mon, 10 Nov 2003 05:40:17 -0000

I am generally happy with the document after reviewing it.  I found a number
of fairly trivial nits, plus one wording query:

Section  2.3, first para - also an editorial nit in same para:
In the first para the draft says:
   The ambiguity of site local addresses also creates problems for the
   routers. In theory, site local addresses are only used within a
   contiguous site, and all routers in that site can treat them as if
   they were not ambiguous. In practice, problem occurs when sites are
                                         -------
                                         the problem   
   disjoint, or when routers have to handle several sites

I am not sure that the word 'disjoint' is right here.  When I read it I
wasn't sure whether the intention was to callout situations where 'sites'
overlapped and the word 'not' was missing.  The next sentence clarifies that
we a dealing with sites which are partitioned but the components are not
directly connected.   I think partitioned might be a better description.

Editorial nits:

Section 1: It might be desirable to add 'unicast' to site local on the first
occurrence (as this what the discussion has been about) and would be
desirable for the second occurrence.

Section 2.2, para 3:
   The experience with RFC1918 addresses also shows some non trivial
   leaks, besides pacing these addresses in IP headers. Private
                  ------ s/b
                  placing

Section 2.2, last para:
The second sentence may be a little too colloquial.

Section 2.3, 4th para:
 In multi-homed routers, such as for example site border routers, the
   routing process should be complemented by a filtering process, to
   guarantee that packets sourced with a site local address never leave
   the site. This filtering process will in turn interact with the
   routing of packets, as it may cause the drop of packets sent to a
                                           ----
                                           dropping

Section 2.5: Spurious blank line in 1st para.

Section3:
Non-ambiguous should be hypenated throughout - currently there is a mixture
of hyphenated and non hyphenated(sic).

Section3, last para:
   One question remains, anycast addressing. Anycast addresses are
   ambiguous by construction, since they refer by definition to any
   host that has been assigned a given anycast address. Link-local or
   global anycast addresses can be"baked in the code". 
                                 ---- missing space

Regards,
Elwyn Davies
> From: Brian Haberman [mailto:[email-masked]] 
> Sent: 05 November 2003 18:27
> To: [email-masked]
> If you have reviewed the document, have no issues with it, and agree
> on its content, please let the chairs and/or the working group know.
> 
> Thanks,
> Brian & Bob
> IPv6 WG Chairs
> 
> Brian Haberman wrote:
> 
> > This is a IPv6 working group last call for comments on advancing the
> > following document as an Proposed Standard:
> > 
> >     Title        : Deprecating Site Local Addresses
> >     Author(s)    : C. Huitema, B. Carpenter
> >     Filename    : draft-ietf-ipv6-deprecate-site-local-01.txt
> >     Pages        : 10
> >     Date        : 2003-10-13
> > 
> > Please send substantive comments to the ipv6 mailing list, and minor
> > editorial comments to the authors.  This last call period 
> will end on 5
> > November 2003.
> > 
> > Brian Haberman / Bob Hinden
> > IPv6 W.G. Chairs
> 
>