> Convenience will any day override IETF statements. > We might be better off if we develop an API through > which the kernel can inform the applications about > an ambiguous address. A call to connect() could > return EAMBIGUOUS. Ofcourse, this error will only > happen if the user did not specify the scope.
The scope-id field in the sockaddr_in6 is there so that applications can inform the kernel of the scope of potentially ambiguous addresses. At least our implementation (and presumably most others) will not accept a scoped address in a sockaddr_in6 structure without a properly set scope-id field. I really think we're making a mountain out of a molehill here. Most apps that use getaddrinfo will naturally support link-local literal addresses, if the user bothers to type one in. I suspect mostly only administrators and the network savvy will ever use literal addresses, ordinary users will use DNS names. Link-local addresses won't work in the DNS, so no one using DNS names will ever get one. If someone comes up with a way for ad-hoc applications to present an understandable UI to ordinary users that happens to use link-local addresses underneath, well, more power to them. This is really outside of the IETF's purview (as actually, is the whole IPv6 API; RFC 2553 and friends are informational, not standards). Basically, I agree with Jinmei's points on this issue, so I'll just say that instead of repeating them. --Brian -------------------------------------------------------------------- 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] --------------------------------------------------------------------
