Subject: RE: Architectural approaches to multi6

From: "Bound, Jim" <[email-masked]>
Date: Tue, 25 Mar 2003 14:31:56 -0500

No one uses FQDN's above IP till one gets to the Application layer.  Why
do you say this?

Also we need a solution that does not assume this at all.  Doing this
would at best be nice to have long term.

THere is also no way to enforce it.

/jim

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]] 
> Sent: Tuesday, March 25, 2003 1:25 PM
> To: Brian E Carpenter
> Cc: [email-masked]
> Subject: Re: Architectural approaches to multi6
> 
> 
> On dinsdag, maa 25, 2003, at 17:14 Europe/Amsterdam, Brian E 
> Carpenter 
> wrote:
> 
> >>>> 3: remove addresses from all places in the protocol 
> stack above the
> >>>> IP
> >>>>    layer. If higher layers are unaware of addresses and the 
> >>>> addresses
> >>>>    follow the topology, IP can route around failures by changing
> >>>>    addresses.
> 
> > We've been preaching against exposing addresses above the transport 
> > layer since RFC 1900 (dated 1996) at least. Little has 
> changed in the 
> > real world.
> 
> As far as I can tell, most people/applications use names rather than 
> addresses most of the time. The trouble is that protocols such as TCP 
> use the addresses in the IP header in their processing. If we make 
> these protocols look at something else (the FQDN, an address 
> that's not 
> in the IP header, ...) we are free to change addresses at any time 
> without breaking sessions.
> 
> >> And I have reason to believe transition won't be as hard as it may
> >> seem
> >> at first glance.
> 
> > Not sure I understand that statement.
> 
> Changing all references to addresses everywhere except in the 
> IP layer 
> is a huge undertaking. However, I think multihoming benefits can be 
> achieved before this process has been completed.
> 
> 
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 25 Mar 2003 21:22:05 +0100

> No one uses FQDN's above IP till one gets to the Application layer.  

I don't think I was saying that people are doing this today.

> Also we need a solution that does not assume this at all.

Why not?

> 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.