> > LLMNR does not solve the problem. Yes the link-id can be sent from > > the stack to the app but then the app had to look at the > scope-id and > > that will work for LLMNR but not for an application that > initiates a > > packet it will not know which link to use unless some state > is kept outside of > > the app to check based on some criteria. I think not using them > > generally is a very good idea except in cases previously discussed. > > i guess i fail to understand your application... > are you talking about cases where users were told to "connect to > fe80::a" and cannot determine the link? if so, it is > the commander's > (or supervisor/peer/whatever) fault that he did not > specify "on which > link". link-local address is local to a link, > therefore "link" has to > be specified, always.
What I am saying is IPv6 has to work without LLMNR today. So lets assume the application obtains address to send to from foo.here.now.com by getaddrinfo not from user interface? You said LLs should not be in DNS. Hence. This case will not work for LLs. Lets assume app uses command line and app name is mickeyfinn csh> mickeyfinn fe80::1 May or may not work correctly. If csh> mickeyfinn fe80::1%eth0 How did the user know to use "eth0" (That is the issue.........) Lets just discuss the above for now for clarity? thanks /jim -------------------------------------------------------------------- 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] --------------------------------------------------------------------
