John C Klensin wrote: > I want to leave most of that discussion for some ARIN-related > list, as David Conrad suggested. I was certainly not trying to pick on ARIN, because there is wide perception that they are fairly liberal in their IPv4 policy. I agree that allocation policy discussions belong elsewhere. > But, for the record, I was > trying to dodge the question of whether address space > exhaustion, by itself, was "strong enough" or "sufficient" > reason to get IPv6 deployed and, especially, to avoid the > rathole-populating discussion about alternatives. Since I am on > record as believing that, by some reasonable measures, we have > already run out of address space and IPv6 is not yet widely > deployed, I would suggest that we have a solid example that it > has not [yet?] proven to be sufficient. Yes it is not widely deployed yet, but that does not mean lack of IPv4 space is not a sufficient reason. In several active deployment cases I am aware of, going as fast as they can, it takes 3-5 years to get to the point of delivering a stable commercial grade service. It should not be surprising that we don't see wide scale deployment yet, since the realization that we are effectively out of IPv4 space has only hit home recently. > ... > I strongly suspect that we are using words in ways that results > in miscommunication, because I think there is a third > alternative. That alternative may fall into the category you > describe as "passing around name objects", or maybe it doesn't. > >From my perspective --which is definitely the applications end > of the stack looking down-- the problem is all about data > abstraction. I'm going to try to switch terminology here in the > hope that it will help clarify things. Suppose the application > gets a well-constructed handle, and passes that handle "around" > --either to other applications or to different interfaces to the > stack/network. I don't see the application as dealing in > topology information by doing that, even if the handle > ultimately identifies information that is deeply > topology-sensitive and/or if the process that produces the > handle uses topological information, or probes the network to > develop such information. The important thing from that > perspective is that the application is dealing with the handle > as an opaque object, without trying to open it up and evaluate > its meaning or semantics (with regard to the network or > otherwise). In general I agree, but the difference of perspective is that ignoring the fact that the well constructed handle is actually derived from topology information does not make the issue go away. The only way you can get the handle you are looking for is to have something below you sort out the topological reality. I agree the current name service is not up to the task, and I believe that we need to get that fixed. Unfortunately it looks like it will take some very crisp architectural guidance to get the IESG to refocus the DNS related WGs to even discuss the issues. The sad part is that many of the participants there already ship or run variants that help address this problem, but they have agreed not to work on standardizing it. > > >From that point of view, having an application go to the stack > and say "given these criteria, give me a handle on the interface > or address I should use" or "given this DNS name, and these > criteria, give me a handle on the address I should use" does not > involve the application being topology-aware, nor does it imply > the application doing something evil because it picks an address > (or virtual interface, or...) without understanding the > topology. The handle is opaque and and an abstraction -- as far > as the application is concerned, it doesn't have any semantics, > regardless of whether lower layers of the stack can derive > semantics from it or from whatever they (but not the > application) can figure out it is bound to. This points out that I have been imprecise by claiming that passing names are sufficient, all the criteria you would use for local communication with the stack are the 'name' in the context of my previous mail. As long as the handle stays contained within the machine you are fine. The problem arises when the app passes that handle to another node, believing that the topology specific information is already there. If the blob passed were the same as what the app used to acquire the local handle, the other nodes would acquire appropriate local handles. > > If the application is calling on, e.g., TCP, then it might pass > some criteria to TCP, or might not, and TCP might either pass > enhanced criteria to the handle-generating layer or generate the > handle itself. Again, the application doesn't care -- it just > needs to deal with an abstraction of the criteria in application > terms. I think that, from the application standpoint, it makes > little difference whether the criteria involve routing, speed, > reliability, or any of several potential QoS or security issues. I agree as long as the app keeps the handle for local use. It can't assume that handle will have an equivalent meaning somewhere else in the network. If it wants to pass a handle that it believes has sufficient topology information for the receiver to directly access the same point, it needs to understand the topology enough to know that the meaning will be consistent. Otherwise it needs to pass the original parameters. > > I'll also be the first to admit that we have handled the set of > issues this implies rather badly with IPv4 (and they certainly > are not new issues). We have gotten away with it because the > number of _hosts_ that need to understand, and choose between, > multiple addresses for themselves has been extremely small, at > least since routers were introduced into the network > architecture. Because it could mostly be seen as a router > problem, applications in IPv4 mostly punted (for better or > worse). Also, since CIDR went in, we basically haven't given a > damn when users who can't qualify for PI space can't multihome > (at least without resort to complex kludges). IPv6, with its > multiple-address-per-host architecture, turns the problem from > "mostly theoretical" to an acute one. It does so with or > without SL addresses being one of those on a host that has > public (global or otherwise) addresses as well. I agree that SL simply exposed the issue. The problems arise from the mismatched interpretation by the apps, that all 'handles' will be treated equally by the network, and the reality that the network has more than a single policy. As you noted earlier, this is not just about scoping of address reachability, it also applies to QoS and any other policy related variance in the topology. > > Finally, from the standpoint of that hypothetical application, > the syntax and construction of that opaque handle are > irrelevant. In particular, it makes zero difference if it is a > name-string that lower layers look up in a dictionary or a > symbol table, or [the name of] some sort of class object, or > whether it is, e.g., an IP address. The only properties the > application cares about is that it is a handle that it got from > somewhere that satisfies criteria it specified or that were > specified for it. I understand that is what the app wants to see. I am suggesting that in the absence of a central policy entity that can sort out all possible topology differences, multi-party apps will need to pass the original parameter set, and maintain local mappings to the stack handle at each participant node. Not pretty, but closer to a working solution than continuing to ignore the reality that the topology is inconsistent. > ... > See above. Applications have gotten away with ignoring that > reality because the occurrences have been infrequent -- with one > important class of exceptions, we have had few machines with > multiple addresses (and multiple interfaces) since routers > became common in the network. The exceptions have been larger > web hosts which support pre-1.1 versions of HTTP and hence use > one address per DNS name. But, for them, hosts opening > connections to them use the address that matches the DNS name > (hence no need to make choices or understand topological > information) and the servers either use "address matching the > one on which the connection was opened" or an arbitrary address > on the interface --since the interface is the same, and its > connectivity is the same, it really makes no difference. If the > reason for multiple addresses per host (or interface) in IPv6 is > to support different scopes (or connectivity, or multihoming > arrangements), then it does make a difference, and will make a > difference for a significant number of hosts. And _that_ > implies a new requirement. We could debate 'new' forever, since as you noted earlier this requirement existed before routers, but the point is that apps can't ignore it any longer. > Tony, there is a difference in perspective here. I'm going to > try to identify and explain it, with the understanding that it > has little to do with any of the discussion above, which I think > is far more important. From your point of view, as I understand > it, this feature has been in IPv6 for a long time, no one > questioned it, or the problem(s) it apparently solved, for > equally long, some implementations were designed to take > advantage of it, and now people are coming along and proposing > to remove it without a clearly-better solution to address those > solved problems. Yes. > From the viewpoint of many or most of the > applications-oriented folks on this list, and maybe some others, > the applications implications of the SL idea (and maybe the > "multiple addresses" idea more generally) are just now becoming > clear. What is becoming clear with them is that the costs in > complexity, in data abstraction failures, and in damage to the > applications view of the hourglass, are very severe and, indeed > that, from the standpoint of how applications are constructed, > SL would never have worked.. From that perspective, when you > argue that applications are already doing bad things, the > applications folks respond by saying "but IPv6 should make it > better, or at least not make it worse". It is inconsistent to claim that SL would never have worked while admitting that there are implementations that take advantage of it. But that aside, SL is not the issue, the issue is that apps have come to believe that the topology is flat so they can pass around handles constructed of topology specific information. The reality all along has been that some addresses were not reachable outside an administrative scope of relevance. Writing those cases off in a client/server world was mostly possible, but in the peer-to-peer world of IPv6 that is no longer possible. > > Those differences lead to discussions about religion and > ideology, which get us nowhere (although they generate a lot of > list traffic). It is clear to me (from my particular narrow > perspective) that our getting to this point at this time > indicates a failure on the part of several generations of IESG > members (probably including me). It also identifies a series of > issues in how we review things cross-area (or don't do that > successfully) and reinforces my perception that shifting the > responsibility for defining standards away from a > multiple-perspective IESG and onto WGs with much narrower > perspectives would be a really bad idea. I agree, and even restricting the cross-area review to the IESG is a bad idea because there aren't enough cycles in that small group. > > But, unfortunate though it may be, we have gotten here. We > differentiate between Proposed and Draft standards precisely to > make it easier to take something out that doesn't work, or > --more to the point in this case-- doesn't appear to do the job > it was designed to do at a pain level no worse than what was > anticipated. I don't think essentially procedural arguments > about how much proof is required to take something out get us > anywhere at this stage. Instead, we should be concentrating on > the real character of the problem we are trying to solve and > ways in which it can be solved without doing violence to > whatever architectural principles we can agree upon. I agree to a point. My button is pushed by those that claim a technology 'creates more problems than it solves', when they simultaneously admit they don't have a clue what problems need solving. To that end I started a draft on what problems need solving, so we can sort out the cases that the current technology does solve, as well as begin to identify alternatives. IF we get to a point were there are alternatives for all the cases people care about, we should drop the unused technology. Tony