Subject: IPv6 Link-Local Address on Mediums that are Glued Together

From: Jim Bound <[email-masked]>
Date: Thu, 02 Dec 1999 13:42:27 -0500

Folks,

This a.m. Mike Carney, Charlie Perkins, and I were discussing DHCPv6 and
we came across something that I want to bring to the list.  

For example:

There is an Ethernet Segment ETH1 with nodes:

 nA - linklocal address fe80::a, and nB - linklocal address fe80::b

There is another not connected to ETH1 Ethernet Segment ETH2 with nodes:

 nX - linklocal address fe80::a, and nY - linklocal address fe80::b

Then some admin decides to connect the two Ether segments together with
a bridge and make them one segment ETH3 without disrupting in anyway or
telling the nodes on ETH1 or ETH2.

Once they are connected nA and nX; & nX and nY; have duplicate
link-local addresses on the same link now ETH3.

This is not good and I don't see anything in Neighbor Discovery or
Stateless Addrconf anything to address this problem?

I use Ethernet segments as the example but there could be other mediums
like joining to cell-device networks together.

This has some ramifications we need to discuss and what do we tell users
about doing this?

Thoughts/Comments?

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: "Brian Haberman" <[email-masked]>
Date: Thu, 02 Dec 1999 14:36:53 -0500

I don't see this as being a pressing issue.  In fact, similar problems occur

today when people connect running networks with L2 devices.  Such an
event requires human intervention, especially if those previously separate
networks were using administratively configured MAC addresses.  My
recommendation is that we not concern ourselves with this problem when
we have more pressing concerns at hand.

Brian

--
Brian Haberman
Advanced Network Research
Nortel Networks
[email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Thu, 02 Dec 1999 14:59:32 -0500

Jim,

This is something that has been talked about over the years. One would
certainly hope that it won't be a common occurance, given the IEEE
identifiers are used in many cases and they are globally unique.

It would also be relatively easy to detect this condition by having a
node send out periodic NS's for itself and seeing if anyone else
responds.

But detecting the situation is the easy part. How do you recover?
Bottom line is that two nodes are using the same address and that
doesn't work. One of those nodes should stop using the address. But
who? How does one decide?  Having nodes automatically determine who
should give up their address may also open interesting denial of
service attacks.

Observation: if anonymous addresses (as in
draft-ietf-ipngwg-addrconf-privacy-01.txt) take off, this may become
more of concern. Address collisions will become more likely, but it
remains to be seen I think how much of a problem in practice.

Thomas

---

From: Jim Bound <[email-masked]>
Date: Thu, 02 Dec 1999 15:08:54 -0500

Brian,

>I don't see this as being a pressing issue.  In fact, similar problems occur

Do you mean a pressing problem given our work load on IPv6 and we should
work on it later?

Or a pressing problem if a customer really does this and it breaks?

Two different issues here.  Esp for folks shipping IPv6 products now and
ones shipping them very soon.

>we have more pressing concerns at hand.

True.  But if today this happened with my example and the nodes on the
two segments were connected and using IPv4 Global addresses I believe it
would work and keep on ticking if as they each would have different
subnet masks.  For Net 10 (private addresses) this could happen with
IPv4 theoretically but I doubt it (two segments doing there own Net 10).

But with IPv6 things whether things keep on ticking is something we
should at a minimum add to our testing and interoperability tests. I
think it will cause a problem because IPv6 states pretty clearly that
any node on the same link will not have the same link-local address.
That is broken in this case.

It could be we not work on it now in the IETF Standards body but I think
it will need to be documented at least "Don't do this for now" in
vendors product documentation.               

I will start a thread with the deployment folks too to see what they
think.

If both the IETF and the Deployment folks want to ignore it for now then 
fine, but I doubt that the case.

thanks
/jim

---

From: Jim Bound <[email-masked]>
Date: Thu, 02 Dec 1999 15:11:53 -0500

I think I read your mail that this is then an issue?

/jim

---

From: Thomas Narten <[email-masked]>
Date: Thu, 02 Dec 1999 15:24:57 -0500

> I think I read your mail that this is then an issue?

Yes and no. Yes, it is a potential issue. However, I think this will
be a rare event in practice, so it's not clear we should try do
address it in a way that requires more protocols be developed, etc.

Also, I am not at all sure there is a simply fix (or even a correct
one). If two nodes have the same link-local address, and both have
been operating happily for some time, and they suddenly find
themselves on the same link, one of them MUST be shut down (i.e., it
needs to stop using the address). There is no graceful way to do this
-- all connections using the address will fail. Moreover, which node
should be the one that shuts down? I think this really requires manual
intervention if you want one machine to continue operating while the
other other one shuts down.

Unless we use a simple heuristic like the equivalent of flipping a
coin to see which machine shuts down. That would be the right answer,
in say, 50% of the cases. I don't know that we can do better than
that, and this isn't a very good percentage!!

Thomas

---

From: Jim Bound <[email-masked]>
Date: Thu, 02 Dec 1999 15:35:27 -0500

if i were king i would put in documentation of Ipv6 don't do this?

Is there any reason why its really valid to join to mediums together in
this manner?  I can see it happening cause someone wants two to become
one giant extended LAN.

in my docs I would say.  if you do this shutdown all machines and
reboot.

but if there is a real network application need to join two mediums like
this it will break without rebooting each node.

I am not sure we should fix it either I just want to be sure the
users no about it somewhere when implementations rollout.  some have
rolled out already.

/jim

---

From: Jim Bound <[email-masked]>
Date: Thu, 02 Dec 1999 15:53:36 -0500

Thomas,

This may be relative to the IETF v6 directorate if it is formed checking
out specs across the IETF for IPv6ness .....  I don't think other specs
using link-local addresses from Ipv6 should develop work arounds to this
bug like routing, snmp, or client/server apps.  They should keep the bug in
their stuff till we fix it here then its fixed uniformly the same way
everywhere when we get around to it.  Or as if you said it really may
not be fixable without a pretty hacked up heuristic then we all have the
same applicability statement or whatever that should be, or the same
hack.

/jim

---

From: Thomas Narten <[email-masked]>
Date: Thu, 02 Dec 1999 15:57:46 -0500

> this manner?  I can see it happening cause someone wants two to become

In today's internet, if it can be done, it will. :-) (But that doesn't
mean we should should address all issues either.)

FWIW, at least some folks in the zeroconf WG think this is a problem
they need to address. Scenario: grampa and gramma have multiple
subnets at home and their grandchild comes to visit. While playing,
she connects segments together via bridge. Oven, phone, tv and toilet
stop working. Not acceptable.

But they are thinking of a slightly different problem, where IPv4
link-local addresses are generated via stateless addrconf. Collisions
are much more likely there because they can't fit the MAC address
inside the remaining two bytes of the 169.254/16 IPv4 address.

Thomas

---

From: "Ralph E. Droms" <[email-masked]>
Date: Thu, 2 Dec 1999 16:06:48 -0500 (EST)

> in my docs I would say.  if you do this shutdown all machines and

Can you say "AppleTalk"?

- Ralph

---

From: Steve Deering <[email-masked]>
Date: Thu, 2 Dec 1999 14:00:17 -0800

Jim,

As long as people use stateless addr conf, or configure their DHCPv6
servers to generate IPv6 interface IDs from requestors' MAC addresses,
the probability of IPv6 address collisions when two separate LANs are
merged ought to be negligible (assuming IEEE 802-style LAN addressing).
That would seem to be the prudent thing to do.  I suppose nodes could
run DAD periodically at some low rate, but if the rate is low enough to
ensure that no one will care about the overhead, then it'll be too low
to quickly detect the collision; and then there's the problem Thomas
pointed out about deciding which of the colliders gets nuked.  Better
just to use MAC-derived link-locals, so collisions will be extremely
unlikely to occur, no matter how much unintentional bridging happens.

Steve

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 02 Dec 1999 14:47:36 -0800

If two different LANs were joined together, with two different
prefixes, what might go wrong?

- Any protocol that uses link-local addresses
- nothing else that I can think of just now.

It would suddenly look like two prefixes on the same
network link.  I can't think of any difficulty right now for
NUD or other parts of Neighbor Discovery.

So, in order to limit the damage, we would just have to be more
careful with anything that uses link-local addresses without
re-checking their validity.

How can it be fixed?

With stateless, one (not me) _could_ mandate that detection of a
_new_ Router Advertisement prefix would require running DAD again,
and as Thomas notes, some sort of arbitration about which node
loses (or maybe both of them do).  This wouldn't be so horrible,
I don't think.

With DHCPv6, almost the same thing can be said.  Not much would
go wrong, as long as the client uses the same relay address to
identify itself to the server for subsequent DHCP Requests.  If
a node changes its link-local address, then it would also has to
issue a DHCP Request and possibly a Release.

For DHCPv6, putting the two networks together SHOULD be accompanied
by the issuance of a RECONFIGURE message containing a newly created
routing prefix.  For stateless, putting the two networks together
does not trigger any currently mandated behavior.  However, one
_might_ write vendor code that re-executes DAD whenever a _new_
Router Advertisement prefix is detected.  I don't want to
be seen as suggesting that we modify a Draft Standard. (!)

So, if a link-local address has to be changed (say because of
overlap after joining two networks), it can cause protocol problems.
It is also possible that a link-local address can change for other
reasons.  For instance, a node may wish to re-randomize its
link-local address.  I think that many of the considerations
would be the same for that case also.

Regards,
Charlie P.

---

From: "Matt Crawford" <[email-masked]>
Date: Thu, 02 Dec 1999 16:51:14 -0600

The selection of MAC/EUI64-derived interface identifiers was the best we
could do to address the problem.  It was discussed.
--------------------------------------------------------------------
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: Steve Deering <[email-masked]>
Date: Thu, 2 Dec 1999 15:58:38 -0800

At 2:47 PM -0800 12/2/99, Charles E. Perkins wrote:
>_new_ Router Advertisement prefix would require running DAD again,...

Charlie,

There's no assurance that each of the merged segments would have an
operational router attached at the time of merge, so that would not
be a reliable way to detect such an event.  And note that even two
routerless segments that were merged could suffer communications
problems if the same link-local address were assigned to hosts on
different segments.  Thus, if it's important to detect, then it's
important to be able to detect it without the assistance of router
advertisements.  (Personally, I don't think it's worth worrying about.)

Steve

---

From: Jim Bound <[email-masked]>
Date: Thu, 02 Dec 1999 22:46:23 -0500

Steve,

>unlikely to occur, no matter how much unintentional bridging happens.

Nice response on what to tell folks.  

I don't want us to beat this to death.  I know we discussed it just
pointing out it popped up again.  We may hear from zeroconf folks
though.  

thanks
/jim