Subject: Interesting problems with using IPv6

From: <[email-masked]>
Date: Sun, 7 Sep 2014 09:28:45 +0000

http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/

Interesting scaling concerns...

Lloyd Wood
http://about.me/lloydwood

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 08 Sep 2014 07:50:26 +1200

If they really are interesting problems, it might be more to the
point to analyse them over on v6ops. Given the number of large
IPv6 deployments that don't have such problems, it seems like
this particular deployment hit an unfortunate combination of
implementation issues. That is worth understanding (for example,
how large is the layer 2 network that leads to the MLD listener
report overload?).

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Sun, 7 Sep 2014 16:25:14 -0400

> how large is the layer 2 network that leads to the MLD listener

Apparently the issue is that although they have isolated various L3 networks with quite reasonable client loads, they are using a hybrid L2/L3 virtualized switch environment that winds up not properly containing the MLD multicasts.   And they have a lot of buggy machines that keep temporary addresses around longer than they should.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 08 Sep 2014 15:35:41 +0900

Ted Lemon wrote:

> Apparently the issue is that although they have isolated various L3
> networks with quite reasonable client loads, they are using a hybrid
> L2/L3 virtualized switch environment that winds up not properly
> containing the MLD multicasts.

Seemingly, the problem becomes apparent because MLD snooping is
now being deployed.

But, even without MLD snooping, a lot of multicast traffic
should have been and will continue to be annoying.

 > And they have a lot of buggy
> machines that keep temporary addresses around longer than they
> should.

According to:

	http://inconcepts.biz/~jsw/ipv6_nd_problems_with_l2_mcast.pdf

in page 15:

	How will I run out of 1000 groups?

	If your layer-2 domain contains 1000 VMs (one rack of modern
	servers)

	Then just link-local IPv6 addresses will produce 1000 groups

the problem is more fundamental.

Then, though the slide says:

	FIX: Eliminate Solicited-Nodes How could we transition to
	this?

	Add a bit or Option to ND Router Advertisement so all hosts
	on the subnet will know about it
	–In about 10 years everyone will be updated… :-/

it is more straight forward to totally abandon ND and just
use ARP even for IPv6, especially because no protocol work
is necessary (RFC826, as is, is applicable to IPv6 and ND
is not mandated for IPv6).

Useful features of ND not supported by ARP can be offered
by DHCP.

						Masataka Ohta

---

From: "Dale W. Carder" <[email-masked]>
Date: Mon, 08 Sep 2014 13:33:40 -0500

> how large is the layer 2 network that leads to the MLD listener

Implementing MLD snooping for Solicited-Node multicast addresses 
is probably a bad idea.

See: draft-pashby-magma-simplify-mld-snooping-01

Dale

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Sep 2014 11:52:00 +0200

> Interesting scaling concerns...

The first problem mentioned is about how IPv6 ND uses multicast capable 
link-layers (more recent Ethernet) instead of broadcast.

We discussed about v6 over multicast-less Ethernet some years back.  It 
was deemed to be a hardware problem (the interface would not support 
33:33::1 but rather 48 1bits)
http://marc.info/?l=ipng&m=110961443317697&w=2.

Since then that hardware interface was updated to support IPv6, and 
further outdated by even more performing cards and subsystems.

But it is also true that new interface cards recurrently show on the 
market with little concern about IPv6 and its multicast needs in ND. 
Worse, some cards have various problems with the way the Interface ID is 
formed (IEEE identifiers presence on non-IEEE cards, 'random' Interface 
IDs, and other non-documented ways of negotiating an Interface ID via 
obscure protocols).

If needed maybe one could bring this in one of the v6-related WGs.

Alex