Ken,
I'm offering some alternative opinions here.
> 1) We believe use of source address selection results
> during destination address selection is probably
> going to cause more trouble than its worth for
> the following reasons:
>
> o Under the socket API, destination address
> selection is performed by getaddrinfo.
> getaddrinfo does not have sufficient
> information to perform source address
> selection accurately every time, particularly
> on multi-interface nodes.
I agree that getaddrinfo needs to consult the kernel (or IP stack) in many/most
cases when it has more than one IP address to return. In Solaris we've done
this for IPv4 addresses in gethostbyname for about 10 years unless I'm
mistaken. It is true that with IPv6 it is likely that there be more FQDNs
returning more than one IP address than for IPv4, but I'm still not concerned
with the overhead of an extra ioctl (or whatever an implementation chooses to
use) since this is small compared to the cost of doing the actual DNS query.
> o getaddrinfo is already a very complex function
> with its requirement to handle all sorts of
> address family and protocol combinations. It
> will be difficult to specify these additional
> requirements in the context of all the other
> getaddrinfo requirements. The likelihood Xnet
> would accept such a change is questionable.
I think it is relatively easy to find the place in a getaddrinfo
implementation that deals with the IP address and insert
if (more than one IP address)
ask kernel to order them
> 2) We believe implementations should default to prefer
> higher scope destination addresses over lower scope
> destination addresses. Global scope destination
> addresses are most likely to be reachable when given
> the limited information getaddrinfo has available.
>
> As for the desire to allow some sites to avoid
> renumbering problems through the use of site-local
> destinations, we believe other methods make just as
> much sense:
>
> o Use a separate namespace for an organization's
> key site-local addresses.
Do you have a concrete proposal?
The only way I can think of doing this involves
- ICANN allocating a special tld for the local addresses, and
- applications like web servers know do on the fly use different URLs
in the HTML depending on who is asking for the page
(e.g. http://foo.local/xyz vs. http://foo.example.com/xyz)
This is problematic both at the political level and at the technical level.
And the foo.local URLs are sure to "leak" outside the site e.g. by being
included in email messages.
Thus it would be good to have a bit more detail on your proposal before
we take it for given that it is the best way to proceed.
Thanks,
Erik
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
