Subject: RE: IPv6 Link-Local Use Issue for Applications

From: "Bound, Jim" <[email-masked]>
Date: Mon, 18 Aug 2003 22:20:06 -0400

>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?

The rule you state is only per Link.  Not multiple links.  There is no
rule that you cannot duplicate link-locals on separate links only
prefixes. 

/jim

>
>-- 
>Andrew White
>--------------------------------------------------------------------
>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]
>--------------------------------------------------------------------
>

--------------------------------------------------------------------
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: "Brian Zill" <[email-masked]>
Date: Mon, 18 Aug 2003 20:00:03 -0700

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-masked] 
> [mailto:[email-masked]] On Behalf Of Bound, Jim
> Sent: Monday, 18 August, 2003 18:01
> To: [email-masked]
> 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
>

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 18 Aug 2003 22:18:47 -0400

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

Hmmm.  I can see that but need to go reread LLMNR.  But so far when I
chase it I find a glitch and another failure mode.

I even thought if the multihomed node sees a duplicate on a multi
segment link it could do something to inform the network but that still
does not get around how does the user know?  

But if LLMNR works we can check it out.  As I said I have to go reread.

>
>	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).

Yes for that link for sure.  But not clear how that helps for multihome
multilink?

>	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.

OK I have not read this but will.  

Thanks
/jim

>itojun

---

From: "sasson, shuki" <[email-masked]>
Date: Tue, 19 Aug 2003 08:43:03 -0400

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-masked]] 
Sent: Monday, August 18, 2003 9:01 PM
To: [email-masked]
Cc: Bound, Jim
Subject: IPv6 Link-Local Use Issue for Applications

Folks,

          Host-L1-B    Host-L1-C

                                    |--- Host-LX-D0

                                    |    FE80::MAC6

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.

Thanks
/jim

---

From: "Brian Zill" <[email-masked]>
Date: Tue, 19 Aug 2003 10:27:09 -0700

> 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.

The scope-id field in the sockaddr_in6 is there so that applications can
inform the kernel of the scope of potentially ambiguous addresses.  At
least our implementation (and presumably most others) will not accept a
scoped address in a sockaddr_in6 structure without a properly set
scope-id field.

I really think we're making a mountain out of a molehill here.  Most
apps that use getaddrinfo will naturally support link-local literal
addresses, if the user bothers to type one in.  I suspect mostly only
administrators and the network savvy will ever use literal addresses,
ordinary users will use DNS names.  Link-local addresses won't work in
the DNS, so no one using DNS names will ever get one.  If someone comes
up with a way for ad-hoc applications to present an understandable UI to
ordinary users that happens to use link-local addresses underneath,
well, more power to them.  This is really outside of the IETF's purview
(as actually, is the whole IPv6 API; RFC 2553 and friends are
informational, not standards).

Basically, I agree with Jinmei's points on this issue, so I'll just say
that instead of repeating them.

--Brian

---

From: "Michel Py" <[email-masked]>
Date: Tue, 19 Aug 2003 17:45:05 -0700

> 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 have seen it 10+ years ago with a batch of NE2000 clones. They were
perfect copies of the Novell model (including the logo) but they all had
the same MAC address. For what I remember they were made by a large
scale copy facility in HK and the guys there had never done a serialized
card before, so they all came out the same.

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

I have stopped using 16-bit ISA cards a while ago.

Michel.

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 21 Aug 2003 23:35:05 -0400

> > What I am saying is IPv6 has to work without LLMNR today.
> > 
> > So lets assume the application obtains address to send to from 
> > foo.here.now.com by getaddrinfo not from user interface?
> > 
> > You said LLs should not be in DNS.
> > 
> > Hence.  This case will not work for LLs.
> 
> 	you can resolve the name "foo.here.now.com" into 
> link-local address
> 	with scope id by LLMNR.

Uh........I said today?  No one has deployed LLMNR as product and I
applaud our colleague at Apple for doing what I recall was mdns.  But it
don't exist and its unclear it will be widely currently.

Plus this now implies the node has this yet other software running
called LLMNR?  

Not sure I agree that is good deployment model at this point.

Ergo "today" it don't work.

> 
> > Lets assume app uses command line and app name is mickeyfinn
> > 
> > csh> mickeyfinn fe80::1
> > 
> > May or may not work correctly.
> 
> 	correct.  it won't work as the specified address is ambiguous.
> 	error mode might be OS dependent.

In addition to what Brian stated using sin6_scope_ID in this case we
will try round robin if it fails but the fear is now what if it goes to
the wrong node?

> 
> > If
> > 
> > csh> mickeyfinn fe80::1%eth0
> > 
> > How did the user know to use "eth0"  (That is the issue.........)
> > 
> > Lets just discuss the above for now for clarity?
> 
> 	LLMNR (or icmp6 node info query).

Neither have consenus or support in the market for products.  At this
point.  But again I am unclear this is a good deployment mode for
general applications.

thanks
/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 21 Aug 2003 23:46:58 -0400

> > > But then again, I don't think that most apps need to do
> > > anything to discourage their use with link-local addresses. 
> > 
> > I agree.  I am not worried about that if they are not in DNS. I am 
> > worried about the case below.
> 
> What about apps that need to pass their hosts' addresses to 
> their peers? 
> Where do they get those addresses in the first place?  For a 
> variety of reasons, DNS isn't a reliable way to find your own 
> addresses. So you get them from the interfaces.  Right now 
> the obvious thing to do is to skip over any LL addresses that 
> are assigned to your interfaces, in order to avoid giving LL 
> addresses to your peers, but this only works if all 
> participating hosts have routable addresses.  If we start 
> expecing apps to use LL addresses, all bets are off, and we 
> are back to a NAT-like situtation where multiparty apps have 
> to implement their own proxies, routing, and perhaps even 
> addressing in order to function.

Ouch your right.  OK its even worse than I stated.  LLs need controls.

> 
> And what happens when vendors start shipping support for LLMNR?  Will
> getaddrinfo() (or other API used for DNS lookup) suddenly 
> start doing LLMNR queries if it thinks that DNS is 
> unreachable?  Will apps that were formerly using getaddrinfo 
> to do DNS queries then get exposed to LL addresses even 
> though they don't work properly with those apps?

Yes this will happen without controls for sure.

> 
> Personally I have strong doubts that LLMNR is fixable.  But 
> if it's going to be deployed, LLMNR needs to stay entirely 
> separate from DNS even to the point of having separate APIs.  
> My fear is that the misguided temptation to try to make LLMNR 
> transparent to apps by overloading existing interfaces will 
> be too great.

Good point.  We should tell LLMNR go build a new API.  I agree.

thanks
/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 23 Aug 2003 00:04:45 -0400

Hi Brian,

> From: Brian Zill [mailto:[email-masked]] 
> Sent: Friday, August 22, 2003 2:37 AM
> To: Bound, Jim; [email-masked]
> Subject: RE: IPv6 Link-Local Use Issue for Applications
> 
> 
> Hi Jim,
> 
> I'm still not sure I understand your position?

Do not use LLs on command lines for applications in most cases.  This is
not necessary to do in the IETF.  Those cases where it is necessary
should be documented.

thanks
/jim