John C Klensin wrote: > ... Maybe that to get there > means that we need to revisit, not just ICMP as Daniel suggests, > but the "no TCPng" decision... I don't know. Maybe that is the path out. > But, if we can > figure out a way to clean this up and make it work well, we > could easily end up with a stronger justification for deploying > IPv6 than anything (at least anything real) we have had to date. Depends on where you are in the world, and how much IPv4 address space you are sitting on. I am aware of organizations in the US today that can't get enough IPv4 address space fast enough by current ARIN policy to meet a viable business plan for ramp up rate. > ... I'm just committed to a network and implementation > model in which they are kept below me in the stack. > Consequently, the only thing I want to need to know about an IP > address is how to pick it up from one source, carry it around > opaquely, and ultimately pass it to something else or use it in > an opaque way in a protocol transaction. But you just said you wanted to keep it below you in the stack. You can't have it both ways... You either get to keep it below you by passing around name objects, or you are taking on the responsibility of getting it right because you are passing around topology information. > The challenge to those > of you who are for, or against, SL at the IP level is to justify > it in a context in which applications really don't need to know > anything about them, or other address scope/ reachability/ > routability issues except through the addressing-independent > abstractions that we can agree on. I don't care if it is TCP-ng, or something else between IP & the app that takes care of figuring out the topology difference, but signaling by itself won't solve the problem of literal referrals. If the app is going to insist on passing around topology information, it has to make sure that matches the topology being used. > If the applications don't > need to know, and can function in a multiple-address-per-host > environment without --in the application-- having to determine > which one to use by some type of iteration process, then you > need to justify specialized addresses only in terms of their > requires lower in the stack. If the applications do need to > know, then the complexity costs appear to be high enough to > present an insurmountable barrier. The current IPv4 network already requires this of applications, the developers simply choose to ignore reality. There is nothing different in a unique prefix for local use, other than the ability for the app (stack) that chooses to look to figure out that some pairings won't work. If the app does as it currently will and passes an out-of-scope address, the application will fail. This is not a new requirement, it is simply exposing the fact that applications have been ignoring reality for a long time now. If there are other ways to mitigate the issue, I am all for developing them. My primary issue is that there are a variety of things people want to use SL for and removing an existing mechanism without appropriate replacements for all of them first is an irresponsible act. Tony