Subject: RE: draft-ietf-ipngwg-addr-select-01: destination selection comme nts

From: Erik Nordmark <[email-masked]>
Date: Tue, 26 Sep 2000 21:26:52 -0700 (PDT)

> I still don't understand why it should be mandatory for all
> nodes to implement consulting the kernel. I look at it as a
> terrific value-added feature that Solaris put in for IPv4 and
> definitely believe it should be allowed in IPv6.

I wasn't claiming that it was mandatory to consult a kernel - it
isn't mandatory for an implementation to have a kernel.
The general point is 
1) the address selection rules are useful
2) I know how to implement them in one implementation without
   creating a noticable performance hit and without adding much
   complexity.

You were arguing that for implementation performance and complexity
reasons certain parts of the rules should not be mandatory.
Seems like we are coming to different conclusions on the
cost/benefit tradeoffs for those particular rules.

> As for the performance aspect, I thought about that too. I
> agree you, its probably not significant.
> 

> The problem is defining everything else getaddrinfo can handle
> to the level of detail needed to support this destination address
> selection algorithm. For example, what order do addresses get
> returned when family, socktype, and/or protocol are unspecified?

That issues is completely orthogonal to the subject of default
address selection.

> I was thinking something much simpler and confused things with
> the term "namespace". The suggestion was intended to be "use
> separate names for an organization's key site-local addresses":
> 
>   servername.mysite.com        ; node's global addresses
>   servername-loc.mysite.com    ; node's site-local address

That avoids the TLD allocation problem, but it doesn't
address the issue of the -loc names leaking outside the site.
For instance, if I send a email to [email-masked] and cc
[email-masked] alice can't reply to bob unless
the mail system does rewriting between the two above types of names
for email that leaves the site.
Same thing for URLs etc.

> This is what we do now in our lab (not in a production
> namespace). It doesn't matter where the names are defined.
> The point is, many organizations will probably only need to
> define the site local addresses of a few nodes for the few
> specific applications that would otherwise break during a
> renumbering event. Let all other applications that will
> work fine with global addresses use global addresses.

draft-ietf-ipngwg-site-prefixes-* shows a different way to approach
the same problem.

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