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