Yes, this can be an issue, but it's not really a serious problem. Link-local addresses, like all scoped addresses, are disambiguated via their scope-id (which represents the zone they are valid in). At the application layer, this is part of the sockaddr_in6. So there is no ambiguity. Applications which want to compare two addresses for equivalency simply need to include the scope-id when making the comparision. It's very little work compared to porting an IPv4 app to be a protocol-independent app.
To answer your specific questions: 1) Yes, see above. 2) This should be a natural part of making the app protocol-independent. 3) There is no need to do this. In fact, I'm aware of several apps which want to do the opposite (i.e. limit themselves to scoped addresses only, in order to deliberately restrict their reach). 4) As mentioned above, the sockaddr_in6 structure already contains the scope-id field, which serves the purpose you want (note that while the interface index is often the same as the scope-id for link-local addresses, it might not necessarily be so. And for other scopes, the interface index isn't what you want anyway. The scope-id will always disambiguate a scoped address on a given machine). --Brian > -----Original Message----- > From: sasson, shuki [mailto:sasson_shuki@;emc.com] > Sent: Thursday, October 17, 2002 13:34 > To: [EMAIL PROTECTED] > Subject: Link Local Address usage for multi-home host. > > > > Hi all, > Link Local Addresses presents a new concept to the existing > IPv4 oriented systems. The concept is that two different > entities might have the same IPv6 (Link Local Address). The > big problem is that this goes up the stack up to the applications. > > Example: > NFS server, we would like to export it for a node that is on > the same link using a Link Local address. Up until now > mentioning the IP address was enough since it identified the > interface. With IPv6 one may have the situation where two > different interfaces may have the same Link Local address. In > this case the interface should also be mentioned by the user. > > Another problem (using the NFS example): > We may have a situation that two different entities (each of > them residing on a different link) will mount the file > system. Once again I think most of the application will not > work as expected in this case. > > > My Concern: > Presenting this ambiguity to the upper layer will require in > some cases redesign of the application. I do not think that > the developers of the IPv6 protocol were aiming for this... > From the little I have read Link Local addresses are used as > a mean to initially communicate with routers in order to > establish statefull Address Configuration (Global or Site > Local address..). > > My Questions: > 1. Has someone came across the same problem? What was the > solution chosen? 2. Should we redesign all the upper layer > application to properly support this? 3. Will restricting the > applications/clients to communicate only with global > addresses makes sense? 4. Will the new socket interface > include an interface index to properly resolve this ambiguity? > > Thanks for your answers, > Shuki Sasson > Principal Engineer, Network Storage Group > EMC˛ > where information lives > > Phone: 508 305 8515 > FaxNo: 508 435 8901 > Pager: 877 919 0794 > Email: [EMAIL PROTECTED] > > > > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
