> 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 PROTECTED] and cc [EMAIL PROTECTED] 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 PROTECTED] --------------------------------------------------------------------
