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 > -----Original Message----- > From: Bound, Jim [mailto:Jim.Bound@;hp.com] > Sent: Wednesday, October 30, 2002 3:17 PM > To: [EMAIL PROTECTED]; Tim Hartrick; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: Limiting the Use of Site-Local > > > 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:alh-ietf@;tndh.net] > > Sent: Wednesday, October 30, 2002 4:01 PM > > To: 'Tim Hartrick'; [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: RE: Limiting the Use of Site-Local > > > > > > Thank you! > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:owner-ipng@;sunroof.eng.sun.com] On Behalf Of Tim Hartrick > > > Sent: Tuesday, October 29, 2002 4:41 PM > > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > > 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 PROTECTED] > > > > -------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------- > > 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 PROTECTED] > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- 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 PROTECTED] --------------------------------------------------------------------
