--On Friday, March 28, 2003 10:36 AM -0800 Tony Hain <[EMAIL PROTECTED]> wrote:
John C Klensin wrote:Tony,
I've been trying to get my mind around the various issues here, and I keep getting back to the same place, so I think I need to embarrass myself by making a proposal that I find frightening.
Let's assume, as I think you have suggested, that SL is all about local addresses and filtering, and not about some special prefix that applications need to recognize. I'm still not sure I believe that, but let's assume it is true and see where that takes us.
Let's also remember the long path that got us to CIDR and 1918. Our original position was that anyone using TCP/IP (v4) should have unique address space. I remember many discussions in which people were told "don't just grab an address on the theory that you would never connect. Our experience has been that, sooner or later, you might connect to the public network, or connect to someone else who has used 'private' (or 'squatter') space... unique addresses will save you, and everyone else, a lot of trouble". In that context, 1918 and its predecessors came out of two threads of developments:
* we were running short of addresses and wanted to discourage unconnected (or hidden) networks from using up public space and * we hoped that, by encouraging such isolated networks to use some specific address ranges, those ranges could be easily and effectively filtered at the boundaries.
We can debate how well either really worked, or what nasty side-effects they caused, but probably it makes little difference in the last analysis except to note that, no matter what we do, leaks happen.
Now one of the problems IPv6 was supposed to solve was "too little address space" or, more specifically, our having to make architecturally bad decisions on the basis of address space exhaustion. I hope we have solved it. If we haven't, i.e., if the address space is still too small, then the time to deal with that issue is right now (or sooner), before IPv6 is more broadly deployed (and it better be variable-length the next time, because, if we are conceptually running short of space already, it would be, IMO, conclusive proof that we have no idea how to specify X in "X addresses will be enough").
But suppose we really do have enough address space (independent of routing issues). In that context, is site local just a shortcut to avoid dealing with a more general problem? Should we have a address allocation policy that updates the policies of the 70s but ignores the intermediate "we are running out" steps? Should I be able to go to an RIR and ask for unique space for an isolated network, justify how much of it I need, and get it -- with no promises that the addresses can be routed (and, presumably, without pushing a wheelbarrow full of dollars/ euros/ yen/ won/ yuan/...)?
The problems with this theory are that a registry costs money to run, and it requires an organization to expose their business plan (never mind figuring out who is really qualified to judge the validity of any given justification). Even when the big bad US Gov. was picking up the tab, there were cost control measures that required someone to validate the request (I was one such sanity checker). If we create a space that requires registration, it will become a simple -biggest wallet gets the most space- arrangement, because it is in the financial interest of the registry to accept all requests. The only push back to that is to set the price per prefix high enough that the registry doesn't need more cash to run, but that, and the recurring nature of those costs, will cause people to avoid the registry and use random numbers. The other point in this is that you can't force people to register until there is a technical reason for it, like making routing work.
Of course, this takes us fairly far onto the path of having to think about multihomed hosts, not just multihomed LANs, but, as others have pointed out, the notion of multiple addresses (or multiple prefixes) for a given host (or interface) takes us rather far down that path anyway. Figuring out which address to use is a problem we need to solve, with or without SL, or the whole idea of multiple addresses on hosts, especially dumb hosts, is going to turn out to be a non-starter. And, as Louis, Noel, and others have pointed out, it is hard. But, if we can find a solution, even one that is just mostly locally-optimal and that fails occasionally, then it seems to me that your position ultimately gives no advantages to a reserved site-local form over unique, but non-routable, addresses. The advantages of the latter appear obvious, starting with being able to identify the sources of address leaks and the notion that routability is a separate negotiation with providers (and their peers and other customers) and not an RIR responsibility.
Leaks are a multifaceted problem. On one hand it might facilitate tracking the source of the leak, but on another it makes it impossible for everyone to know that this specific prefix is supposed to be filtered. While it might be nice to believe that defining a space as non-routable means it won't be routed, reality is that ISPs that want to survive will do what the paying customer says. The only defense against route-for-hire table bloat is the technical infeasibility created by ambiguity.
That would leave another topic which I consider separate: whether we ought to create some number of 1918-like addresses that organizations that are really isolated (not connected even with other prefixes) can use without needing to have a negotiation with an RIR. The answer, I think, is probably "yes", but it really is a policy question, not a technical one. And, on the above model, an ISP offering service (and prefixes) to an enterprise could be expected to insist that the enterprise not be using any of those isolated addresses in their local environment.
It is absolutely unreasonable for an ISP to tell their customer anything about running their network that is not directely related to the customer/provider interface. As long as the enterprise traffic over that interface is related to the capabilities they are paying for, it is none of the ISPs (or IETFs) business what they are doing elsewhere.
That said, I do have a draft that globally preallocates space in an unabmiguous way (http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-03.txt). This would allow use without the need to register, and if organizations merged there would be no collision. As a side effect, when those values were leaked into the global routing system, they can be proxy aggregated at least at the transcontinental level. The text is currently focused at the multi-homing problem, but it could easily be reworded.
I obviously don't understand all of the issues here well enough. But the traffic of the last few days has left me with the strong impression that SL may be an answer to the wrong question. If so, is the suggestion above closer to the right question?
And, unfortunately, since this approach involves a change in the advice the IETF gives the RIRs, it probably does belong on the IETF list and not that of a WG.
Eventually if policy needs to change, then yes. At this point though I believe the fundamental issue is really about people coming to grips with the concept that unlike IPv4,
- all IPv6 nodes will have multiple addresses per interface. -
Once that is understood, the noise about the cost of renumbering goes away because that is simply the act of adding a prefix to the nodes that care to use it. If one chooses to take the old one away at some point, that is fine. But that step is not mandatory, which significantly reduces the costs associated with flash cutovers. This also means that sites that want to filter can use different prefixes for global vs. local access and only those nodes needing global access would configure the global prefix. As you noted earlier, it really doesn't matter what the local use prefix is for this purpose, the only reasons for the ambiguous one is the lack of need to register it (pay and/or expose your business case), the ability to keep those values out of the global routing table, and for applications that care to look, a hint that there is a filter somewhere in the network.
Tony
_______________________________________________ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio.
------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: [EMAIL PROTECTED]
