Hi Richard,
I was talking to Vlad Yasevich here at Compaq about
your spec. Vlad has detailed knowledge about how
getaddrinfo is implemented and understands Xnet
issues far better than I. After discussing how
the implementation works and what the likely
impacts of your spec are, we decided to make the
following additional comments.
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.
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.
o In IPv4, getaddrinfo is capable of sorting
destination addresses according to a list of
address prefixes stored in /etc/resolv.conf.
This is similar to the prefixes in your
precedence table. There should be no problem
selecting the correct destination address if
this table is defined correctly (more on that
later).
We ask that you remove rules 1 and 3 from
destination address selection.
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.
o Define the destination address precedence
table on each node in the site to prefer site-
locals. Yes, there is no way to easily do this
now, but it is something that could be added
through a future tool.
3) You mentioned in a previous message that you were going
to remove scoped addresses from your default precedence
table. This sounds like a good idea. It would allow us
to "prefer lower scope source addresses" and "prefer
higher scope destination addresses" at the same time.
If you do this, I think the precedence table should take
priority over the "prefer higher scoped destination
addresses" rule.
Ken Powell
Compaq Computer Corporation
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
