ietf
[Top] [All Lists]

RE: A follow up question

2003-04-23 13:00:34
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






<Prev in Thread] Current Thread [Next in Thread>