I agree with Erik below.
There are many examples where the destination address selection really needs
to know about the available source addresses. For example, suppose a DNS
name resolves to two addresses, a 6to4 address A and a native global address
B. If the node only has a 6to4 address itself, then it should sort A before
B; if the node only has a native global address itself, it should sort B
before A.
Our getaddrinfo implementation uses an ioctl as Erik describes. This
interacts well with our implementation of
draft-ietf-ipngwg-site-prefixes-04.txt.
The draft allows implementations that prefer not to use an ioctl, but
instead do everything in user space, by caching in user space information
about the node's source addresses. It's an implementation choice.
I don't see the need for any XNET coordination or acceptance. The
destination address selection is orthogonal to and independent of XNET's
getaddrinfo specification.
Rich
> -----Original Message-----
> From: Erik Nordmark [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 20, 2000 5:35 PM
> To: Powell, Ken
> Cc: Richard Draves; '[EMAIL PROTECTED]'; Yasevich, Vladislav
> Subject: Re: draft-ietf-ipngwg-addr-select-01: destination selection
> comments
>
>
>
> 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]
--------------------------------------------------------------------
