Re: interop problems with getaddrinfo() address selection

[Keith Moore <[e-mail]>]

Tony Finch wrote:
> On Sat, 8 Dec 2007, Keith Moore wrote:
>   
>> this seems like an almost-inherent consequence of IPv6's expecting hosts
>> to have multiple addresses and asking hosts initiating a communication
>> to do address selection.  it's not specific to getaddrinfo() - any API
>> that tried to solve that problem would be likely to reorder addresses to
>> some degree.
>>     
>
> The problem isn't specific to IPv6 - for example see the comments about
> address selection for "multihomed" MXs in RFC 2821. However in practice we
> ignore this possibility and treat host names with multiple IP addresses as
> equally reachable at any address. I don't think IPv6 substantially changes
> this situation, because most of its common extra addresses have limited
> scope and will not be published in the DNS.
>   
I think it's a stretch to assume that in the future that all IP
addresses associated with a domain and advertised in DNS are equally
reachable.

As a start IPv4 isn't going away.  So a site may need to advertise both
IPv4 and IPv6 addresses in order to be widely reachable, and the party
initiating a connection gets to decide which is better.

>From my own experience it is a good idea for a site to advertise both
6to4 and native IPv6 addresses.  A 6to4 site initiating a connection
will probably do better to use the destination's 6to4 address; similarly
for a native site using the destination's native address.  An
IPv4-to-IPv4 connection is almost certainly better than a connection
between a native and 6to4 IPv6 address.

Then you have ULIAs which are globally unique and globally scoped but
which might not be globally reachable.  As long as there's an
expectation that IPv6 addresses are PA, there will be a need for ULIAs. 
But networks using ULIAs will interconnect with other networks including
those using PA space and other networks using ULIAs. 

Then you have mobile IP which creates additional choices, and a growing
tendency for hosts to have multiple network interfaces where more than
one interface can be connected to the Internet.

The notion that you can control address visibility using DNS in this
world is pretty much a fantasy.

>> though it should be possible for the client implementation to go through
>> the list of addresses, assign a preference value to each one (based on
>> address type and number of leading bits in common with one of the
>> hosts's local addresses), then perform a stable sort by preference value.
>>     
>
> That's essentially what RFC 3484 recommends, and what causes the problem.
>   
What causes the problem is the assumption that a destination can have
multiple addresses, a source can have multiple addresses, and the party
initiating the connection can somehow make a good decision about which
address pair to use without any information from the network.

As for DNS randomization, it's never been reasonable to expect an
application to try each of several addresses in the order returned by
DNS.  The fact that many apps happened to work this way (because it was
often the easiest way to do things) was an accident, not something
required by the DNS protocol or the defined protocol for most of those apps.

Keith