Subject: draft-ietf-ipngwg-addr-select-01: destination selection comments

From: "Powell, Ken" <[email-masked]>
Date: Wed, 20 Sep 2000 10:23:56 -0400

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-masked]
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 20 Sep 2000 17:35:15 -0700 (PDT)

Ken,
I'm offering some alternative opinions here.

>       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.

>       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

>         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

---

From: Jim Bound <[email-masked]>
Date: Thu, 21 Sep 2000 14:56:46 -0400

Erik,

>included in email messages.

But maybe we need to do this or we are not done with the site-local (or
other non-global scope addresses in the IPng)???

>we take it for given that it is the best way to proceed.

But there is a core architectural assumption here being proposed
regardless if non-global scopes work.  By axiom global scopes do work,
can exist in the DNS, and will work end-to-end, so from common sense
type engineering (I know an art being lost) prefer them.

But I do see your point.

/jim