Subject: IPv6 Link-Local Use Issue for Applications

From: "Bound, Jim" <[email-masked]>
Date: Mon, 18 Aug 2003 21:00:36 -0400

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-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Tue, 19 Aug 2003 10:15:16 +0900

>the user know which Link to use for the link-local address?  

	we could use LLMNR to resolve names to link-local addresses,
	or vice versa.  i have done it and it works okay.

	under our current implementation, LLMNR daemon talks to libc resolver
	by normal DNS protocol (port 53) so link identifier will be lost.
	however, if we use different inter-process communication, or integrate
	LLMNR into libc, we won't lose link identification (and we can set
	sin6_scope_id right).

>line is link-local address are not usable for applications.

	I completely agree that link-local address SHOULD NOT be on public
	DNS database.  i have already asked the author of
	draft-ietf-dnsop-dontpublish-unreachable-03.txt to include the text,
	and it is included.

itojun

---

From: Andrew White <[email-masked]>
Date: Tue, 19 Aug 2003 11:17:33 +1000

> same Link-Local address as FE80::MAC1.   This is permitted in IPv6

It was my understanding that duplicate MACs are not permitted by the MAC
allocations, which are *supposed* to guarantee that each physical interface
device has a unique MAC.

Which would imply that a link-local addressed based on a MAC is in fact
globally unique, by definition?

What have I missed?

-- 
Andrew White

---

From: Mark Smith <[email-masked]>
Date: Tue, 19 Aug 2003 11:44:12 +0930

On Tue, 19 Aug 2003 11:17:33 +1000

> globally unique, by definition?

a) MAC addresses are reasonably easily to change. You can't guarantee that the end-users will follow the recommendations ie. enable the locally administered bit. Most networking people I've met don't know there is a "locally administered" bit in a MAC address.

b) There have been cases where manufacturers have allocated non-unique MAC addresses. What is worse is that these duplications have apparently tended to happen within the same batch of NICs, and have been encountered when somebody goes to deploy a group of say 20 new NICs they have just bought, and encounter one or more duplications.

c) MAC addresses are typically placed in outgoing ethernet frame headers by the device driver, not by the NIC itself, which is why it changing the MAC address of an interface is usually functionally quite easy. The device driver gets the MAC address to use from an EEPROM or something similar from the card. Bugs in that part of the device driver can cause duplicates.

You can generally _assume_ MAC addresses are globally unique, which is why they are used as node IDs in IPv6, IPX, but there aren't any guarantees.

Further, global uniqueness of MAC addresses is really only so that the device can be plugged in and work "out of the box". For the network to actually work, the MAC address only has to be unique on the segment it is attached to.

Regards,
Mark.

---

From: Keith Moore <[email-masked]>
Date: Mon, 18 Aug 2003 22:26:42 -0400

On Mon, 18 Aug 2003 21:00:36 -0400
"Bound, Jim" <[email-masked]> wrote:

> type by applications. 

agree emphatically.  LL should only be used by special-purpose apps that are
aware of LL and its limitations.

(and no, LLMNR doesn't solve the problem.  LLMNR in its current form is a
worse mistake than Site Local.)
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Benny Amorsen <[email-masked]>
Date: Tue, 19 Aug 2003 07:15:04 +0200

On 2003-08-19 at 04:14, Mark Smith wrote:

> a) MAC addresses are reasonably easily to change. You can't guarantee
> that the end-users will follow the recommendations ie. enable the
> locally administered bit. Most networking people I've met don't know
> there is a "locally administered" bit in a MAC address.
> 
> b) There have been cases where manufacturers have allocated non-unique
> MAC addresses. What is worse is that these duplications have
> apparently tended to happen within the same batch of NICs, and have
> been encountered when somebody goes to deploy a group of say 20 new
> NICs they have just bought, and encounter one or more duplications.
> 
> c) MAC addresses are typically placed in outgoing ethernet frame
> headers by the device driver, not by the NIC itself, which is why it
> changing the MAC address of an interface is usually functionally quite
> easy. The device driver gets the MAC address to use from an EEPROM or
> something similar from the card. Bugs in that part of the device
> driver can cause duplicates.

You are forgetting:

d) Some manufacturers allocate only one MAC address per host, with the
expectation that two interfaces would never end up on the same network.
Sun was the canonical example, but you can turn that behaviour off in
the PROM. I do not know how modern Sun machines behave.

/Benny

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 19 Aug 2003 17:07:51 +0900

>>>>> On Mon, 18 Aug 2003 21:00:36 -0400, 
>>>>> "Bound, Jim" <[email-masked]> said:

> IETF and in industry IPv6 implementation documentation

> That link-local addresses SHOULD not be 
> included in the DNS.

I agree with this.

Regarding the rest of the statements, my opinion depends on the
details:

> that 
> That link-local adddresses SHOULD be 

First of all, we need to define "applications" clearly.  I believe all
existing IPv6 routing protocol and DHCPv6 implementations are
user-space "applications."  Also, some IPv6 stack implements (all or
some part of) Neighbor Discovery as a user-space "application."  So,
it is not really clear if we just say "link-local addresses are not
usable for *applications*."

Additionally, with the fact some fundamental protocols such as
routing/ND/DHCPv6 use link-local addresses, network administrators
need a tool to deal with the addresses.  For example, they sometimes
need to ping to a link-local address to see if a remote router showed
in the routing table of another router is alive.  As an IPv6 network
operator, I sometimes even need to log in to an on-link node by ssh
using a link-local address, when a routing or ND trouble happens.  I
can easily imagine that some people dislike this kind of usage, but
this is a real IPv6 life I'm spending today anyway, and ping and ssh
are of course applications.

I personally think it is reasonable to assume that such administrators
(or more generally "advanced" users) have the ability to disambiguate
the correct link when they use such tools (applications).  (Router
administrators have to understand the notion of links after all.)

Also, ping and ssh that I'm using, or more concretely, ping6 and
OpenSSH_3.5p1 on FreeBSD 4.8, do not really care about "links."  These
applications just use the getaddrinfo function provided by FreeBSD
4.8, and the library function understands the "%" notation to tell the
correct link to the kernel.  (Note: the reasy why these applications
use getaddrinfo() is not because they need to deal with link-local
addresses.  They use the function to support IPv6.)

I agree that ordinary users that do not have the knowledge about
"links" should not be bothered with the link-local stuff.  I also
agree that it is not meaningful to forth applications something (API,
whatever) just to deal with link-local addresses.  (But I'm not sure
if this is something that the IETF should declare with the upper-cased
wording.)

At the same time, however, I believe it is convenient or even
necessary for "advanced" users (such as network operators) to have the
ability to use link-local addresses even with an "ordinary"
applications such as ping or ssh.  I also believe it is useful to
define the common syntax and the library support (e.g., the % notation
support in getaddrinfo()) to provide the ability.

I also have some personal opinions on the LLMNR or zeroconf usage wrt
link-local addresses, but I won't go further on this for now.  I
believe my main points should be covered by what I've said above, and
I'm afraid discussing the zeroconf usage in this context would make
this thread divergent without contributing to the essential point
here.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: "Chirayu Patel" <[email-masked]>
Date: Tue, 19 Aug 2003 15:58:03 +0530

> -----Original Message-----
> From: [email-masked] [mailto:owner-
> [email-masked]] On Behalf Of Bound, Jim
> 

Networks can be formed ad-hoc. I meet two friends, and all three of us want
to use our laptops to play a networking game, or maybe exchange files. In
the absence of a router (for RA) or a DHCPv6 server, we all will be forced
to use link-local addresses. 

It might not be that difficult to use the link-local addresses, if there
were a "network neighborhood" kind of application existed which would detect
all the nodes on the network, maybe even gets their name using NI queries,
and somehow pass (maybe /etc/hosts) the hostnames to the applications.

Convenience will any day override IETF statements. We might be better off if
we develop an API through which the kernel can inform the applications about
an ambiguous address. A call to connect() could return EAMBIGUOUS. Ofcourse,
this error will only happen if the user did not specify the scope.

Comments?

CP

---

From: Dean Strik <[email-masked]>
Date: Tue, 19 Aug 2003 14:21:02 +0200

> the PROM. I do not know how modern Sun machines behave.

e) Things like 802.1Q tagged vlans that providee multiple logical
interfaces with their own link-local address space yet the same MAC
addresses.

-- 
Dean C. Strik             Eindhoven University of Technology
[email-masked]  |  [email-masked]  |  http://www.ipnet6.org/
"This isn't right. This isn't even wrong." -- Wolfgang Pauli
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Mika Liljeberg <[email-masked]>
Date: 19 Aug 2003 18:14:57 +0300

> 	LLMNR into libc, we won't lose link identification (and we can set

Indeed. We have done it this way and it works quite nicely. The resolver
API returns any scoped addresses together with an appropriate scope id.

	MikaL

---

From: Bob Hinden <[email-masked]>
Date: Tue, 19 Aug 2003 16:01:06 -0700

Mark,

>b) There have been cases where manufacturers have allocated non-unique MAC 
>addresses. What is worse is that these duplications have apparently tended 
>to happen within the same batch of NICs, and have been encountered when 
>somebody goes to deploy a group of say 20 new NICs they have just bought, 
>and encounter one or more duplications.

Do you have any first hand experience of this happening?  I have heard the 
story several times, but I would like to see something definitive.  I 
wonder if it is an "internet urban myth".

Does anyone have in their possession two or more NICs with the same MAC 
address?

Thanks,
Bob

---

From: "Alan E. Beard" <[email-masked]>
Date: Tue, 19 Aug 2003 19:48:26 -0400 (EDT)

Bob:

I have encountered duplicate MAC addresses on ethernet NICs on two
occasions: once from Novell and once from IBM.  These incidents were
widely spaced in time: the first approximately ten years ago; the second
about four years ago.  In each case, the problem was uncovered during a
mass deployment of new systems when one machine proved unreliable during
post-install testing. In both cases, the problem was initially
mis-diagnosed as a switch CAM table logic failure.  In one case we found
only one duplicated value (two cards each with the same MAC address); in
the other case we found that the manufacturer had duplicated 16 MAC
addresses, and we got 22 cards with duplicated addresses. (We never did
determine what became of the remaining four cards with duplicate
addresses, although we found 15 of the 16 duplicated addresses in our
stock.)  In each case the manufacturer replaced _all_ the cards out of the
affected production runs with new units, and required that all the cards
we had out of the afficted production run be returned to the maker.

This is not an urban legend, but, based on my experience, manufacturers
tend to react vigorously and very rapidly indeed to remove from public
circulation _all_ cards bearing MAC addresses which may have been
duplicated.

BTW, the networks in which these duplications were discovered are fairly
large; one about 32K hosts, the other about 8K.  I would judge instances
of duplicated MAC addresses to be quite rare.

Hope this helps.

AEB

-- 
Alan E. Beard <[email-masked]>
AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809
863.815.2529

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 19 Aug 2003 17:41:30 -0700

Bound, Jim wrote:
> ...

Jim, this is simply pointless. I haven't gotten through all the mail yet so
somebody has probably already pointed this out, but you can't use an ad-hoc
network without routers if the apps won't bind to a LL address. 

Tony

---

From: Mark Smith <[email-masked]>
Date: Wed, 20 Aug 2003 14:36:24 +0930

Hi Bob, Alan,

My reply to Bob's question at end.

On Tue, 19 Aug 2003 19:48:26 -0400 (EDT)

> Bob:
<snip>
> circulation _all_ cards bearing MAC addresses which may have been

The story I'd heard was the problem most often occured at the bottom end of the NIC market, rather than the top ie. the el-cheapo cards manufactured in Taiwan etc.

The two reasons were 

1) The NIC manufacturer couldn't be bothered with getting an official OUI from IEEE, due to the costs involved cutting into their profit margin (although I'd assumed it cost money to get an OUI, if it doesn't, then that isn't a reason - being lazy does minimise your costs in a small way though).

2) QA was low, again due to it cutting into profit margins.

This may actually be a business strategy as 

1) the el-cheapo market would typically be the SOHO market, where very few NICs are connected to the same link, and are typically bought one at a time.

2) if the SOHO customer does buy more than one NIC from a batch with duplicate MAC addresses, they won't work, will take one or both, or the group back to the shop, and get replacements, hopefully not from the same batch. Alternatively, because of the hassle they have just suffered, they may decide to go a bit more up market, where MACs are not duplicated. Because of the low cost, the shop will probably just assume the el-cheapo NICs were DOA, and throw them away.

With cheap, yet widely supported (eg Windows, Linux, etc) 10/100 MBps NICs costing around $15 AU / ~$8 US, it isn't surprising that people may not bother trying to find the real reason why NICs with duplicated MAC addresses don't work.

> > wonder if it is an "internet urban myth".

No :-), but I seem to remember that the person who told me about 10 years ago did.

Regards,
Mark.

---

From: Bill Manning <[email-masked]>
Date: Tue, 19 Aug 2003 22:22:46 -0700 (PDT)

% > > >somebody goes to deploy a group of say 20 new NICs they have just bought,
% > > >and encounter one or more duplications.
% > >
% > > Do you have any first hand experience of this happening?  I have heard the
% > > story several times, but I would like to see something definitive.  I
% > > wonder if it is an "internet urban myth".
% > >
% 
% No :-), but I seem to remember that the person who told me about 10 years ago did.
% 
% Regards,
% Mark.

	3com - 3c501 cards circa 1987
	DEC  - circa 1985 (although DECnet rewrote the MAC by default)
	generic - circa 1996

	in the first two cases, the vendor had tools to re-write the mac 
	inthe latter case, get the money back and buy better cards.

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Wed, 20 Aug 2003 14:52:55 +0930

Did a bit of googling, looks like Intel has had a duplicate MAC address problem as recently as January last year :

http://www.intel.com/support/motherboards/server/stl2/ta-503.htm

---

From: Keith Moore <[email-masked]>
Date: Wed, 20 Aug 2003 19:58:52 -0400

> network without routers if the apps won't bind to a LL address. 

that's okay, you can't use ordinary apps with LL addresses (even on ad hoc
networks) if the hosts on which those apps run have more than one active
network interface.
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: "Chirayu Patel" <[email-masked]>
Date: Fri, 22 Aug 2003 10:46:37 +0530

> Would like to hear what my colleagues in IETF IPv6 WG think

The emails on this subject have been a revelation. I too think that we should
have a statement from the IETF about the pitfalls of using LL's by
applications. Is anyone working on such a statement? If not, I can volunteer
to be an editor...but beware I will need a lot of support from this group. :-)

CP