Re: Transport level multihoming

[Brian E Carpenter <brian@hursley.ibm.com>]

Greg Maxwell wrote:
> 
> On Wed, 8 Aug 2001, Brian E Carpenter wrote:
> 
> > Yes, this is one way to do it (almost identical to the "bump in the API"
> > approach to v4/v6 interworking). I don't see any reason why the IP address
> > returned by the resolver needs to be bogus; surely it can simply be any one
> > of the real IP addresses, which might have some advantages.
> 
> My only reasoning for not using one of the actual IP addresses is that
> some hosts may advertise a different set of addresses based on application:
> 
> Consider a single host with two DNS names:
> 
> ftp.host.company.com = A,B,C,D (where the letters are addresses in
>                                 different prefixes)
> www.host.company.com = A,B
> 
> Why? C,D are high latency satellite links.
> 
> The host is smart enough to not include the high-latency links in any
> assotiation binding in it's transport protocol for port 80. However, we
> don't want remote systems to attempt to initiate across those slow links
> either.
> 
> Of course, we could just declare that those kinds of smarts belong to
> applications that are aware of the transport-level multihoming (in that
> they pass all the addresses themselves) and go ahead and use one of it's
> correct IP addresses.

Indeed. It's only a binary number after all. 

> 
> This was my reasoning for using bogus identifyers.

I have a feeling that for diagnosis, using one of the actual values
to be found in DNS is probably better - a bogus (locally synthesised)
value has no diagnostic value. In any case it's a detail.

   Brian