Hi Jim, I fully agree with the conclusion that link-local shouldn't be used for other than Neighbor Discovery. The only exception may be home networking where a router is not present (but I doubt that even one such network exists). We came across the same problem (our product is a multi-home host). This is how we tackled the scenario you are presenting: There are 2 cases here it is either that the multi-home is the initiator of the transaction or receiving a request. If it is receiving a request then the socket going up to the application will include the scope-id. Applications should maintain the socket structure as a handle for this transaction thus they actually are having a pointer to the interface throughout the packet came through. While responding to the packet using this handle will automatically send the packet through the right interface.
The second case is when the multi-home host is the initiator. In our system we discourage the human user from setting up Link-Local address as destination addresses for such transactions. If she (the user) insists on using Link-Local then this should be specified in the form FE80::LL%interface-name. This way the multi-home host wouldn't have to go and guess on what interface the LL destination address resides. We found the above approach to be the simplest one and one that will always work. Another important note:: A question rises what should be done in the case of VLANs where a single interface can support multiple VLANs. Answer:: Each VLAN should have its own scope-id and interface name. Hope this helps, Shuki -----Original Message----- From: Bound, Jim [mailto:[EMAIL PROTECTED] Sent: Monday, August 18, 2003 9:01 PM To: [EMAIL PROTECTED] Cc: Bound, Jim Subject: IPv6 Link-Local Use Issue for Applications Folks, Below is a picture of two links: Link 1 and Link 2. Link 1 has Host-L1-B and Host-L1-C. Link 2 has Host-L2-E and Host-L2-F. A multihomed Host-LX-D0 is connected to both Link 1 and Link 2. All hosts have both a Link-Local address FE80::XXXX and a Global Address 3FFE:YY::XXXX. Note that Host-L1-B and Host-L2-E have the same Link-Local address as FE80::MAC1. This is permitted in IPv6 for separate links. Host-L1-B Host-L1-C 3FFE:AB::MAC1 3FFE:AC::MAC2 FE80::MAC1 FE80::MAC2 Link 1 ___|_____________|___________ 3FFE:AD::MAC3 | FE80::MAC3 |--- Host-LX-D0 | FE80::MAC6 Link 2______________________________| 3FFE:A0::MAC6 | | FE80::MAC1 FE80::MAC5 3FFE:AE::MAC1 3FFE:AF::MAC5 Host-L2-E Host-L2-F If Host-LX-D0 user wants to ftp or telnet to Host-L2-E using FE80::MAC1 as an address 'ftp FE80::MAC1' being a multihomed host the routing or interface redirection (depending on how you wanted to implement) really does not know if it is for Link 1 or Link 2 as both will be in the destination cache potentially and duplicated, and this would be compliant to the IPv6 standard. But if Host-LX-D0 used Host-L2-E's global address 3FFE:AE::MAC1 there would be no problem, as IPv6 does not permit duplicate prefixes across links. What some implementations have done is require the user to specify the interface in addition to the address for link local (Linux did this as a note) 'ftp FE80::MAC1%Ethernet0' and other implementations perform a round robin to find the correct link-local address. The '%' is an artifact of the getaddrinfo() API as parameter. But this does not really solve the problem completely. How does the user know which Link to use for the link-local address? What if the user sent the message to the wrong link, especially in a mission critical situation (e.g. Patient in Hospital, Telecommunications Grid, Soldiers Device in Combat). This is not good and also has security issues that can be resolved with IPsec, but an encrypted packet to the wrong link is still not good as there is a chance in the diagram above that all Hosts are in fact using same PKI and IPsec encrypt and decrypt, and the packet could be accepted. IPv6 efforts in the IETF will not solve the future scoping capabilities within the IPv6 architecture any time soon, and it will be even longer to get scoping widely implemented in the market and tested well through interoperability events. The industry requires a solution today, and I would argue there is no solution. The solution that will work for now is make a statement in the IETF and in industry IPv6 implementation documentation that link-local addresses SHOULD not be used as an IPv6 address type by applications. That link-local addresses SHOULD not be included in the DNS. That link-local adddresses SHOULD be restricted to IETF protocols on Hosts to perform Neighbor Discovery, Stateless Address Configuration, DHCPv6, or other operation protocols to bring a Host up on a network. The bottom line is link-local address are not usable for applications. Would like to hear what my colleagues in IETF IPv6 WG think about this issue? This mail will also be sent to the IPv6 Forum deployment effort and to several users I know of that are deploying IPv6 currently, to hear from the operational and implementation community too. 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] -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
