[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IPv6 Link-Local Use Issue for Applications


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.


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 majordomo@sunroof.eng.sun.com