Re: Architectural approaches to multi6

[Iljitsch van Beijnum <iljitsch@muada.com>]

On dinsdag, maa 25, 2003, at 21:33 Europe/Amsterdam, Bound, Jim wrote:

> > > Also we need a solution that does not assume this at all.
> > Why not?
> WHen I say assume let me clarify.  By "assume" I mean, solution we end
> up with won't work if all *sockaddr_DL references to Network Byte Order
> addresses MUST become references to *char_foo_identifier strings.  I
> will assume you know the ramfications to the stack above IP "virtual"
> layer in the IP stack and then to what we often call "user" space where
> the applications reside.  That is a non-starter.
Yes, we need both a very long transition period during which certain 
parts can handle the new paradigm while others can't and first rate 
backward compatibility.

> > > Doing this would at best be nice to have long term. THere is also no
> > > way to enforce it.
> > So there we have our long term goal. If we can get there by using 16
> > byte values that look enough like IPv6 addresses to fool existing
> > implementations for a while but label them "identifier - not
> > to be used in routing" I don't have a problem with that.
> Yep that is what I was thinking architecturally.  But have not gone 
> down
> the affect to code yet.
There are lots of issues to consider before that.

> That being said I believe Christian's point was quite valid.
I'm not convinced by his example. Yes, applications will want to know 
something about the connectivity properties in order to adapt their 
behavior. But I don't see how access to the IP addresses is going to do 
that. An application can't tell if 3ffe:2500:310:1:203:93ff:fec5:2d28 
is an address used on a low-bandwidth, high-delay GPRS link or a 
high-bandwidth, low-delay fast ethernet link. The application needs to 
know which interface is going to be used, the address is immaterial. If 
the IP layer can move a session from one interface to another some 
additional glue is needed to provide this information on an ongoing 
basis.

However, there is another reason why people work around the DNS that I 
think may be a bigger problem: while the domain name system isn't open 
to trivial fakery like some other protocols (SMTP...) its security 
isn't stellar either.

The trouble with hardcoding addresses in configuration files is that 
invariably the addresses change and invariably it is next to impossible 
to find all the places they're stored beforehand. What we need here is 
something that isn't as fixed as a configuration file, but also isn't 
as ephemeral as information learned from the DNS.