Subject: RE: Limiting the Use of Site-Local

From: "Bound, Jim" <[email-masked]>
Date: Wed, 30 Oct 2002 18:16:42 -0500

Tony and Tim,

I agree with Tim about the flow.  But I strongly support Margarets idea
to limit them today to not be part of domain where global addresses
exist as Margaret has clearly articulated.
Support for that is not a minority and not rehash but putting some
controls on an architectural part of IPv6 that is not understood, widely
implemented, or deployed as product with express warranty that it can be
used in production networks.

So keep it in the architecture and lets put a control on it right now
and move on.

I am personally not going to participate any further I have nothing else
to say.

P.S. Tim I emphatically do not agree with your views on 1918 and I was
here as you when it was developed.  But I see no point in kicking that
dead horse either.   We simply do not agree.  It is moot point though I
do agree.

P.S. Margaret if we can get folks to do this correct engineering change
order I will help with the draft if you require that. But for now I am
DELETING all this mail on killing SLs entirely it will not happen.
Though they should die and all should use globals the next best thing is
to put controls on this mess until we understand how to do it.  

/jim
[In matters of style, swim with the currents....in matters of principle,
stand like a rock.  - Thomas Jefferson]

> -----Original Message-----
> From: Tony Hain [mailto:[email-masked]] 
> Sent: Wednesday, October 30, 2002 4:01 PM
> To: 'Tim Hartrick'; [email-masked]; [email-masked]
> Subject: RE: Limiting the Use of Site-Local
> 
> 
> Thank you!
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Tim Hartrick
> > Sent: Tuesday, October 29, 2002 4:41 PM
> > To: [email-masked]; [email-masked]
> > Subject: RE: Limiting the Use of Site-Local
> > 
> > 
> > 
> > 
> > All,
> > 
> > I generally agree with all the points that Richard Draves has
> > made.  I am not as sanguine about the ease of implementation 
> > in the network stack but there is nothing in the details 
> > which is unimaginably difficult. We very much need to move 
> > on.  By my count this is the forth or fifth time this topic 
> > has been debated and redebated.  Each time the result has 
> > been the same.  If every decision taken by this working group 
> > can be opened repeatedly by a noisy minority then forward 
> > progress of any sort will not be possible.  Consensus does 
> > not require unanimity.  No matter how noisy and persistent 
> > the minority happens to be, it is possible to move on.
> > 
> > There are a couple of other points I would like to make.
> > 
> > Some folks seem to be operating under a misconception about
> > RFC 1918. RFC 1918 was a response to the rampant use of 
> > arbitrary IPv4 prefixes as private address space.  The use of 
> > private address space was not a response to the publishing of 
> > RFC 1918.  Network administrators will use "private" IPv6 
> > address space whether we excise all mention of site-local 
> > addresses from the specifications or not.  The network 
> > administrators that use private address space may be stupid, 
> > misinformed or have any number of socially unacceptable 
> > habits but they still run their networks and will run their 
> > networks the way they see fit. Removing site-local addresses 
> > from the architecture or attempting to restrict their use in 
> > a way that is equivalent to removing them is an exercise in 
> > futility absent better alternatives to site-local addresses.
> > 
> > The burden on those that want to remove site-local addresses
> > is to provide network administrators with an alternative 
> > which meets their needs but doesn't possess the negative 
> > aspects of site-local addresses that are being railed 
> > against.  The requirements that network adminstrators would 
> > place on these addresses would probably be that there is no 
> > registration required and that the addresses are not globally 
> > routable.  If such a proposal has been made and it has made 
> > it through last call of this working group, I must have 
> > missed it.  Contrary to what has been said by some in the 
> > anti-site-local camp, the burden should be on them to come up 
> > with alternatives to site-local addresses.  Until those 
> > alternatives have been thoroughly vetted by this working 
> > group the previous consensus should hold.
> > 
> > Counter to what one might believe from reading my comments
> > above, I don't like the architectural mess that has occured 
> > as a consequence of the use private addresses in IPv4.  The 
> > difference between me and the anti-site- local camp is that I 
> > don't anticipate that network administrators will stop using 
> > private address (IPv6 or IPv4) unless they are provided with 
> > good reasons not to use them.  That means solving 
> > renumbering, solving address shortage, artificial or 
> > otherwise, providing the an alternative "private" address 
> > scheme of the sort cited above and providing the great IPv6 
> > applications which their customers want but that break in the 
> > presence of site-local addresses.  If these things are done, 
> > it won't be necessary to add a bunch of MUST NOTs into the 
> > verbiage in various specifications. Site-local addresses and 
> > all the associated problems will fall into the dustbin of 
> > obsolescence.  Absent these things, all the MUST NOTs in the 
> > world won't prevent the use of site-local addresses or some 
> > other form of IPv6 "private" address.
> > 
> > Network administrators don't read RFCs for the MUST NOTs.
> > They read them for the solutions they provide.  If the MUST 
> > NOTs get in the way of the solution then they get ignored.
> > 
> > 
> > Tim Hartrick
> > Mentat Inc.
> > 
> > --------------------------------------------------------------------
> > IETF IPng Working Group Mailing List
> > IPng Home Page:                      http://playground.sun.com/ipng
> > FTP archive:                      ftp://playground.sun.com/pub/ipng
> > Direct all administrative requests to [email-masked]
> > --------------------------------------------------------------------
> > 
> 
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 30 Oct 2002 15:56:11 -0800

Jim,

The fundamental difference is the assumption about what is a reasonable
network topology. It is absolutely wrong to turn off SL just because a
global exists, because neighboring nodes on a single wire may have local
policy to be globally visible or not. Insisting that SL gets turned off
because one node on the wire needs a global creates a very unreasonable
burden to manage access lists, particularly if that node moves around
between segments that would otherwise have no global nodes. 

Again, I am sympathetic to the point that multi-party apps should refuse
to refer a SL if any of the members has a global, but that is at best a
BCP targeted at app developers. 

Tony

> From: Bound, Jim [mailto:[email-masked]] 
> Sent: Wednesday, October 30, 2002 3:17 PM
> To: [email-masked]; Tim Hartrick; 
> [email-masked]; [email-masked]
> I agree with Tim about the flow.  But I strongly support 
> Margarets idea to limit them today to not be part of domain 
> where global addresses exist as Margaret has clearly 
> articulated. Support for that is not a minority and not 
> rehash but putting some controls on an architectural part of 
> IPv6 that is not understood, widely implemented, or deployed 
> as product with express warranty that it can be used in 
> production networks.
> 
> So keep it in the architecture and lets put a control on it 
> right now and move on.
> 
> I am personally not going to participate any further I have 
> nothing else to say.
> 
> P.S. Tim I emphatically do not agree with your views on 1918 
> and I was here as you when it was developed.  But I see no 
> point in kicking that
> P.S. Margaret if we can get folks to do this correct 
> engineering change order I will help with the draft if you 
> require that. But for now I am DELETING all this mail on 
> killing SLs entirely it will not happen. Though they should 
> die and all should use globals the next best thing is to put 
> controls on this mess until we understand how to do it.  
> 
> /jim
> [In matters of style, swim with the currents....in matters of 
> principle, stand like a rock.  - Thomas Jefferson]
> 
> 
> > > I generally agree with all the points that Richard Draves 
> has made.  
> > > I am not as sanguine about the ease of implementation in 
> the network 
> > > stack but there is nothing in the details which is unimaginably 
> > > difficult. We very much need to move on.  By my count this is the 
> > > forth or fifth time this topic has been debated and 
> redebated.  Each 
> > > time the result has been the same.  If every decision 
> taken by this 
> > > working group can be opened repeatedly by a noisy minority then 
> > > forward progress of any sort will not be possible.  Consensus does
> > > Some folks seem to be operating under a misconception about RFC 
> > > 1918. RFC 1918 was a response to the rampant use of 
> arbitrary IPv4 
> > > prefixes as private address space.  The use of private 
> address space 
> > > was not a response to the publishing of RFC 1918.  Network 
> > > administrators will use "private" IPv6 address space whether we 
> > > excise all mention of site-local addresses from the 
> specifications 
> > > or not.  The network administrators that use private 
> address space 
> > > may be stupid, misinformed or have any number of socially 
> > > unacceptable habits but they still run their networks and 
> will run 
> > > their networks the way they see fit. Removing site-local addresses
> > > The burden on those that want to remove site-local 
> addresses is to 
> > > provide network administrators with an alternative which 
> meets their 
> > > needs but doesn't possess the negative aspects of site-local 
> > > addresses that are being railed against.  The requirements that 
> > > network adminstrators would place on these addresses 
> would probably 
> > > be that there is no registration required and that the 
> addresses are 
> > > not globally routable.  If such a proposal has been made 
> and it has 
> > > made it through last call of this working group, I must have
> > > Counter to what one might believe from reading my 
> comments above, I 
> > > don't like the architectural mess that has occured as a 
> consequence 
> > > of the use private addresses in IPv4.  The difference 
> between me and 
> > > the anti-site- local camp is that I don't anticipate that network 
> > > administrators will stop using private address (IPv6 or 
> IPv4) unless 
> > > they are provided with good reasons not to use them.  That means 
> > > solving renumbering, solving address shortage, artificial or
> They read 
> > > them for the solutions they provide.  If the MUST NOTs get in the 
> > > way of the solution then they get ignored.
> > > 
> > > 
> > > Tim Hartrick
> > > Mentat Inc.
> > > 
> > >

---

From: Keith Moore <[email-masked]>
Date: Wed, 30 Oct 2002 20:29:43 -0500

> policy to be globally visible or not. 

it is absolutely wrong to expect apps to deal with a mixture of SLs and
globals, because that forces those apps to develop their own addressing 
and routing schemes, essentially making any notion of SL to indicate
'policy' irrelevant.

> Insisting that SL gets turned off

well, I'd probably agree with that, because it provides an easy way to
attack an isolated network that was legitimately using SLs.  still,
a network that is using globals shouldn't be using SLs.

> BCP targeted at app developers.

it would never get published as a BCP because it's not a good practice 
to recommend - first because the app has no way of knowing in advance
whether any of its (current or future) members has a global, and second
because this prevents referrals between hosts in the same scope from 
going through an intermediary that doesn't share the same scope.
in other words, it forces apps to know about topology. 

and for similar reasons that it's not okay for SLs on the net to fail 
when they happen to see a global, neither is it okay for apps to start 
refusing to refer SLs when they see a global.

Keith

---

From: [email-masked]
Date: Thu, 31 Oct 2002 13:46:17 +1100

> and routing schemes, essentially making any notion of SL to indicate

	99.9% of applications just want a address to connect to.  They
	don't care if it is a SL, LL or GA.

	For the other 0.1% being able see the scoped the hosts are in
	allows them to make sensible decisions.  If you can't see the
	scopes you can't make the decisions.  AAAA doesn't give you the
	information you need.  SA6 will give you the information you
	need.

> a network that is using globals shouldn't be using SLs.

	Well don't configure *your* network to do this.  Stop trying
	to preventing those that do from doing so.
 
> in other words, it forces apps to know about topology. 

	Tunnel vision.

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Keith Moore <[email-masked]>
Date: Wed, 30 Oct 2002 22:37:06 -0500

> 	to preventing those that do from doing so.

and *you* stop trying to impair the Internet in such a way that 
the only applications it can support are client-server or those
organized into a strict hierarchy that reflects physical topology,
and stop trying to saddle such applications with useless complexity
and performance impairment.

and you accuse *me* of tunnel vision.

Keith