Dan Lanciani wrote: > ... > The thing that bothers me about this discussion is that it is > starting to sound as if site-local addressing (and all the > endless debate about scope and address selection rules) was > just another sham like transparent renumbering. Until a few > days ago site-local addresses (along with the scope baggage they > entail) were a part of the IPv6 vision. Now suddenly they > are a minor wart to be eliminated, and all roads seem to lead > back to the situation where the stability (and cost) of your > internal network is directly dependent on your ISP. This in > turn will almost certainly result in the introduction of IPv6 > NAT and we will be right back where we started.
Please don't interpret the ranting of a few as representing anything close to consensus of a very large WG. Your comments are very valuable as they keep the real end use requirements in focus, and push the 'its too hard' wining to the background. I do have one question about your comment, do you believe transparent renumbering is a sham, or did I mis-read your intent? > > > Margaret Wasserman <[EMAIL PROTECTED]> wrote: > > |Seriously, we have an opportunity, with the introduction of IPv6, to > |advocate new ways of doing things on the new network. > | > |Just because people have been doing something one (bad) way > |in the past, doesn't mean that we should advocate that approach in > |IPv6. > > Wow. I think I used almost exactly those words a few years > back in a futile argument for global portable identifiers. > But you seem to be advocating constraining v6's addressing to > work just as v4's does. How is that new? > > One of the (IMHO, very few) benefits of the v6 addressing > architecture is that scoped site-local addresses allow some > of the desirable functionality of NAT and private addressing > to integrate smoothly. I'm not saying that this was a good > tradeoff. I would have preferred to see work on the routing > problem so that everybody could have their own stable > routable addresses. But that would have upset the status quo > a bit too much and we got scopes instead. The bottom line is > that by hand-waving arguments scoped addressing was declared > feasible while routing portable addresses was declared > impossible. The bed has been made and now we have to lie in it... There is an ongoing discussion on multi6 about how we might get a compromise version of stable global & routable identifiers, but it is not converging anytime soon. > > > "Bound, Jim" <[EMAIL PROTECTED]> wrote: > > |Dan, > | ... > > |So I am not clear your argument of long lived connections is an > |argument for SLs? > > That isn't my argument. My argument would be for portable > routable addresses or identifiers, but I lost. The arguments > for site-local addressing were made years ago. It isn't > clear why they have all been forgotten. Because those who made them thought it was essentially finished and moved on to real problems, while those who lost figure the lack of attention represents a good opportunity to revisit the discussion and win this time. > > |It is an argument for other work I believe to be important. > > Sure, implement my portable identifier protocol and all the > problems will go away. Or allow portable routable addresses. > The hardware has gotten a lot faster and memory has gotten a > lot cheaper. Or solve the renumbering and address allocation > problems without the former. But whatever you do, do it > FIRST and then come back so we can discuss removing the last > vestige of supported end-user-controlled address space. Your point is there will be end-user-controlled address space, the only option we have now is SL but we only need one mechanism that meets the requirement. > > > Keith Moore <[EMAIL PROTECTED]> wrote: > > |first, I don't buy that provider-based addresses are inherently that > |much > |of a burden. > > They seem to be enough of a burden to cause NAT to flourish, though. > > |and it's far easier to solve the renumbering problem > (particularly for > |special-purpose devices) than to solve the SL addressibility problem. > > So we are coming full circle? We have the renumbering > problem because the portable address/identifier problem was > declared by fiat to be too hard to even think about solving. > We are stuck with site-local addressing because the > renumbering problem turned out to be too difficult to solve > in practice. Please explain... I understand that renumbering and static configuration of things like filters can be a challenge, but those are solvable given a reasonable time period. Is this simply a matter of an app can't survive a reunmbering event? > > I've noticed an unfortunate trend towards the following kind > of argument: ``X is bad, unaesthetic, and hard. I don't > like x. The world will be much better if we eliminate x now > and replace its functionality with y at some point in the > future. Y is easier, cleaner, and more aesthetic. As soon > as someone manages to implement y everybody will see this. I > don't have an implementation of y right now, of course. But > it will happen.'' Site-locals are already at least a > third-order compromise. You aren't even proposing a new "y"... This is because there is a complete lack of appreciation for the fundemental requirement that a network manager have stable locally controlled address space. > > If you think that the renumbering problem is easy solve, can > I make a suggestion similar to the ones I received when I > proposed portable identifiers? Go make it work. Bring back > a few sample implementations that demonstrate transparent > renumbering. Write it up. Get the necessary changes made in > whatever standards are affected. With renumbering solved I > think you will see less resistance to elimination of > site-locals, though there is still the address cost issue. > Now in my opinion, renumbering is a very hard problem to > solve--much harder than either portable identifiers or scope > propagation. (At least, renumbering is hard to solve if you > don't introduce a level of indirection that is equivalent to > portable identifiers.) But I'd be happy to be proven wrong. As a slightly off topic question, do you agree with the business driver assertions in draft-hain-ipv6-pi-addr-use-03.txt ? We can disagree about the approach in the PI format, but the fundamental reasons should be consistent. > > |second, I don't buy that we're stuck with provider-based addresses > |anyway. > > Can you expand on this? If you know a way to get unstuck > from provider-based addresses I'd love to hear about it. > With a mechanism for end users to own portable routable > global addresses the need for site-locals would be greatly > reduced. But if you are just talking about a hypothetical > future utopia then it is unreasonable to use this as a reason > to deprecate site-locals. The ipv4 address aggregation hack > was supposed to be a temporary stopgap until the hardware > caught up. The hardware caught up a long time ago. You > still can't get portable v4 address space in any reasonable > way. I see no reason to believe that v6 addresses will fair > any better. > > If you are talking about non-routable global addresses then > this is a step in the right direction, but it isn't clear > that it removes the need to deal with scopes and DNS hacks. Non-routable global addresses are by definition local. The only thing they bring to the table over SL is ambiguity in the scope of routability. Keith continues to argue that he wants to remove ambiguity, but what he is really arguing is that it be moved outside the visibility of his multi-party app development window. Tony > > If you are talking about 6to4 space then you have found an > illusory solution. > > |third, I don't buy that every company wants to set up its own > |infrastructure to network to remote devices when they can > take bids from competing providers > |who already have infrastructure - or even use a mixture of > providers. > |(for instance, you can combine wired, wireless, satellite > depending on > |where your devices are) > > Do you buy that most companies want to set up their own > infrastructure to network to *local* devices without > depending on their ISP? Should access to my local network > printer really depend on an address assignment from my ISP? > Even for remote devices accessed via third-party > infrastructure the increased use of VPNs may well mean that > those remote devices will have addresses local to the the owner. > > |fourth, I don't buy that the existence of provider-based > addresses is a > |compelling reason to burden us with SLs. > > See #1. > > Dan Lanciani > ddl@danlan.*com > -------------------------------------------------------------------- > 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] --------------------------------------------------------------------
