> 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.
The network stack isn't the problem; the difficulty of handling SLs in applications, coupled with their lack of benefit, is the problem. > 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. No the result is not the same, because each time the debate crops up again there is less and less justification for SLs. The arguments for SL were always weak, by now when the burdens associated with SL are more apparent they're nearly indefensible. > 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. Clearly we don't have a consensus that SLs are technically sound or that there is a compelling use case for them. That should argue for our not burdening the network with them. > 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. You are right about the first part, someone mistaken about the second. RFC 1918 was indeed a response to the use of arbitrary IPv4 prefixes; and surely it was better to use a standard set of prefixes than arbitrary ones. But RFC 1918 has also repeatedly been cited to give license to hooking private networks to the public Internet via NAT despite careful wording in RFC 1918 to NOT license such use. > 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. Network admins can indeed screw with their networks and harm interoperability of the global network by doing so, and there's nothing that we can do to prevent them from doing that. But it's not IETF's purpose to tell network admins that it's okay to harm the network. Rather, it's IETF's purpose to tell them how the network was designed to be used and which practices for using the network make good sense. SLs do not make good sense. > 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. No, the burden on those who want to promote site-local is to figure out how to have SLs exist without limiting the ability of the network to support multiparty apps and without imposing a considerable burden on such apps. We need justification to keep complex and burdensome features, not to justify getting rid of them (or replacing them with simpler features). > The requirements that network adminstrators > would place on these addresses would probably be that there is no registration > required I think you're stating it a bit strongly. I would say that there needs to be a low barrier to obtaining addresses and that the process be easily and widely understood. But this doesn't by itself preclude some kind of registration. Sites don't seem to have major problems registering domain names, for instance. > 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. I've seen multiple proposals along these lines. I certainly agree that these are needed - as I've said on multiple occasions, they are needed to facilitate private interconnection between private networks. > 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. It seems to me that there's nowhere approaching a consensus to keep SLs except for isolated networks. > 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 I agree with the above. We *really* need to work on a complete story for renumbering. We *really* need a way for sites to get non-publically-routable (but routable between private networks), provider-independent address space. > and providing the great > IPv6 applications which their customers want but that break in the presence > of site-local addresses. this part makes no sense. applications that don't work under such conditions don't get deployed very far - and people never get to use them. Keith -------------------------------------------------------------------- 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] --------------------------------------------------------------------
