[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Transport level multihoming
On Thu, 9 Aug 2001, Peter Tattam wrote:
> One question.
>
> In a transport level multihoming scenario, should two addresses that differ in
> the lower 64 bits (node address part) be considered independent nodes and
> handled in the traditional manner with regard to multiple addresses?
My opinion is that:
Hosts should consult DNS to get a list of addresses associated with a name
and pass these addresses to the transport API. This set of addresses MAY
or MAY NOT be for a single host.
The transport protocol will then attempt to connect, most likely by trying
to tack up a connection with the first host on the list. The transport
level will communicate the rest of the valid addresses for the hosts.
This allows DNS to continue to round robin separate hosts, as well as
initiating link.
> Why I ask is that the upper 64 bits of all possible full addresses for a
> particular node that is multihomed have particular properties that would be
> useful to exploit in transport level multihoming. If the lower 64 bits is not
> identical between multiple addresses, it could lead to inefficiencies in a
> compressed representation of the list of IPv6 addresses. It may also be
> important to some layers of any multihoming protocol to consider that addresses
> which differ in the lower 64 bits would not being equivalent for the purposes
> of multihoming.
I don't believe using the lower 64 bits to identify the host is the
correct solution. For example, what happens when I want to use the
16bits of site networking to perform future-internet-like multihoming
inside my own AS (I probably wouldn't do this because of address
proliferation and because I wouldn't have scaling problems with
traditional multihoming on a local scale)?
Or a more obvious example: The 8+8 limits the minimum network that can
separately multihome to /64. On the IPv4 internet, people complain that
some providers filter their deaggregated /24 announcements!
I would have to see some pretty compelling optimizations for a change
which would effectively exclude all small institutions from multihoming.