Jim, as long as the application is link-local aware, and treats the scope-id properly, this is not a problem. Most stacks I'm aware of handle this situation correctly. But this means getting the address directly off something on the link, and not through some external lookup mechanism like the global DNS. Link-local addresses are ambiguous off link, and therefore should not (or rather, MUST NOT) appear in the global DNS. For the most part, this limits the use of link-local addresses to applications that are aware of the link.
--Brian > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bound, Jim > Sent: Monday, 18 August, 2003 18:01 > 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] --------------------------------------------------------------------
