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