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