> > But then again, I don't think that most apps need to do > > anything to discourage their use with link-local addresses. > > I agree. I am not worried about that if they are not in DNS. I am > worried about the case below.
What about apps that need to pass their hosts' addresses to their peers? Where do they get those addresses in the first place? For a variety of reasons, DNS isn't a reliable way to find your own addresses. So you get them from the interfaces. Right now the obvious thing to do is to skip over any LL addresses that are assigned to your interfaces, in order to avoid giving LL addresses to your peers, but this only works if all participating hosts have routable addresses. If we start expecing apps to use LL addresses, all bets are off, and we are back to a NAT-like situtation where multiparty apps have to implement their own proxies, routing, and perhaps even addressing in order to function. And what happens when vendors start shipping support for LLMNR? Will getaddrinfo() (or other API used for DNS lookup) suddenly start doing LLMNR queries if it thinks that DNS is unreachable? Will apps that were formerly using getaddrinfo to do DNS queries then get exposed to LL addresses even though they don't work properly with those apps? Personally I have strong doubts that LLMNR is fixable. But if it's going to be deployed, LLMNR needs to stay entirely separate from DNS even to the point of having separate APIs. My fear is that the misguided temptation to try to make LLMNR transparent to apps by overloading existing interfaces will be too great. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
