Subject: Link Local Address usage for multi-home host.

From: "sasson, shuki" <[email-masked]>
Date: Thu, 17 Oct 2002 16:34:19 -0400

Hi all, 
Link Local Addresses presents a new concept to the existing IPv4 oriented
systems. The concept is that two different entities might have the same IPv6
(Link Local Address).
The big problem is that this goes up the stack up to the applications.

Example:
NFS server, we would like to export it for a node that is on the same link
using a Link Local address. Up until now mentioning the IP address was
enough since it identified the interface. With IPv6 one may have the
situation where two different interfaces may have the same Link Local
address. In this case the interface should also be mentioned by the user.

Another problem (using the NFS example):
We may have a situation that two different entities (each of them residing
on a different link) will mount the file system. Once again I think most of
the application will not work as expected in this case.

My Concern:
Presenting this ambiguity to the upper layer will require in some cases
redesign of the application. I do not think that the developers of the IPv6
protocol were aiming for this...
From the little I have read Link Local addresses are used as a mean to
initially communicate with routers in order to establish statefull Address
Configuration (Global or Site Local address..).

My Questions:
1. Has someone came across the same problem? What was the solution chosen?
2. Should we redesign all the upper layer application to properly support
this?
3. Will restricting the applications/clients to communicate only with global
addresses makes sense?
4. Will the new socket interface include an interface index to properly
resolve this ambiguity?

Thanks for your answers,
Shuki Sasson
Principal Engineer, Network Storage Group
	EMC²  		
where information lives

Phone: 508 305 8515
FaxNo: 508 435 8901
Pager: 877 919 0794
Email:  [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: "sasson, shuki" <[email-masked]>
Date: Thu, 17 Oct 2002 21:04:04 -0400

Hi Keith & Brian, thanks for your answers. It seems like there is still some
confusion here...

Still a few questions:
Looking at the documentation I have that Link Local address is FE80::/64 +64
bits of interface ID.
There is no place for the zone.
Do you mean that the zone will be assigned by the IfIndex of the interface
that the message was recieved by?

Another question:
MAC address is required to be unique (48 bits) a part of the interface ID.
Thus the Link Local assigned to it is unique...
So why we bother doing DAD?
And also If the above is correct we do not have a problem really...

Basically, based on the assumtion that Link Local should be unique
everywhere. The only possibility of duplicate Link Local Address is
miss-configuration by a human. Can we follow what we are doing in IPv4 in
case of wrongly configured address? Basically requiring the network manager
to deal with that.

Thanks,
Shuki

-----Original Message-----
From: Keith Moore [mailto:[email-masked]]
Sent: Thursday, October 17, 2002 8:49 PM
To: Brian Zill
Cc: sasson, shuki; [email-masked]
Subject: Re: Link Local Address usage for multi-home host. 

> Yes, this can be an issue, but it's not really a serious problem.  

forcing apps to deal with scopes at all is a serious problem.
being able to compare scopes from different addresses only addresses
one small aspect of that problem.

though making an app 'protocol independent' is one example of having
apps deal with scopes since presumably the app may have to deal with
a mixture of v4 and v6 addresses, a mixture of v4-only and v6-only
and dual-stack hosts, and various kinds of connectivity (no v4, local
v4, global v4) X (no v6, local v6 only, global v6)

it should not be assumed that it's appropriate to expect every app to be
protocol independent.  there will be v4-only apps.  there will be v6-only
apps.  there will be apps that can run one or the other but not both.
this is a natural consequence of v6 deployment scenarios.

app vendors shouldn't expect that limiting themselves to scoped addresses 
provides anything in the way of security other than delusion.    it's not
appropriate for the vendor to assume that the site or local environment
is secure.

bottom line: there is insufficient justification for expecting apps
to deal with scoped addresses.

Keith

---

From: "Brian Zill" <[email-masked]>
Date: Thu, 17 Oct 2002 19:17:09 -0700

> Still a few questions:
> Looking at the documentation I have that Link Local address 
> is FE80::/64 +64 bits of interface ID. There is no place for 
> the zone. Do you mean that the zone will be assigned by the 
> IfIndex of the interface that the message was recieved by?

If I understand your question correctly, then the answer is essentially
yes.  Packets on the wire do not have a zone field in the header.  But
an interface is only in a single zone at each scope level (i.e. an
interface can only be on one link, or in one site).  So a packet
received on an interface can be assigned a zone value based on the zone
the interface is in (for link-local addresses this is often the
interface index, but not necessarily).  That zone value is visible to
applications via the scope-id field in the sockaddr_in6 structure
(assuming an implementation with a socket based API).

Going the other way, if you want to send a datagram to a link-local
address, the scope-id in the sockaddr_in6 is only used to identify which
interface (or set of interfaces) on your machine it is allowed to go
out.  The zone identifier (scope-id) isn't included in the packet on the
wire.

> Another question:
> MAC address is required to be unique (48 bits) a part of the 
> interface ID. Thus the Link Local assigned to it is unique... 
> So why we bother doing DAD? And also If the above is correct 
> we do not have a problem really...

This issue has been long debated in the working group.  My impression is
that the argument was presented that since (a) there have been cases
where the MAC address is not unique (card manufactors have been known to
ship NICs which have the same address, for example) and (b) the degree
of the problems that result from having duplicate addresses is pretty
bad and (c) can be very hard to diagnose, it seemed the safest thing to
do was just do DAD anyway.  Occasionally various proposals come up to
change this in various ways, but we should probably change the subject
line before going into that.

--Brian