Sure. If you don't have this algorithm, you have to put in a special case
for 6to4 - which I really think would be a kludge.
Brian
Richard Draves wrote:
>
> 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]
> --------------------------------------------------------------------
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
