On Sep 9, 2014, at 7:22 AM, Chuck Anderson <cra@WPI.EDU> wrote:

> Disagree.  
> 
> In common practice, ARP doesn't need to scale to hundreds of IPv4
> addresses per host.  Unforutnately, IPv6 SLAAC with Privacy Addressing
> means that ND and hence MLD does need to scale much larger than ARP
> ever did.  The cure of using Solicited Node multicast for ND is worse
> than the disease of using broadcast for ARP.

Privacy addressing is the true disease here, not ND. Solicited Node multicast actually isn’t all that bad in any sane implementation. ARP has certainly created its share of problems over the years.

However, I’ve never seen privacy addressing result in hundreds of addresses per host. That would have to be a pretty broken implementation or some really strange values for preferred/valid.

If you use the (relatively standard) 3600/86400, then any addresses that are more than a day old should get removed from the interface.
Assuming you generate a new privacy address every hour, that shouldn’t be more than ~25 addresses per interface at any given time.

> It is not reasonable to expect a switch to scale to maintaining state
> for 300 * (# of hosts connected) Solicited-Node multicast groups.

Nor does any rational use of SLAAC+Privacy addresses result in anything near that.

> 15,000 MLD groups for 48 hosts on a 48 port switch is unreasonable.

25*48 = 1,200, not 15,000. Even if we double that, it’s still 2,400 max.

A potential improvement could be if privacy addressing created a persistent random lower 24 bits and only rehashed the upper 40 bits of the suffix with each address rotation. In that way, you’d only have ~2 ND multicast groups per host.

> 90,000 MLD groups for a 300 port switch stack is also unreasonable.
> Most switches cannot handle that many IPv4 multicast groups--expecting
> them to handle that many IPv6 multicast groups is unreasonable.

Again, this is not anything close to a real world scale for the situation. Using hyperbole derived numbers to make things sound bad enough that you can blame the protocol for a situation that is much more directly the result of bad network design is absurd.

> How many MLD reports per second have to be processed by the switch CPU
> given reports every 150 seconds by each of the many Solicited Node
> multicast groups on every connected host?  100 pps?  600 pps?

Let’s assume a 300 node subnet (rather large by most standards). Let’s further assume that you have 50 SNMGs per host with zero overlap.
That’s a total of 15,000 SNMGs network wide which, divided by 150 seconds results in a PPS rate of 100. Note, this is double the actual anticipated number of SNMGs per host and that zero overlap is a worst case scenario. A switch stack supporting 300 nodes shouldn’t have any problem at all forwarding 100PPS.

MLD snooping of ND traffic is a pretty bad idea and there’s really no good reason for the switch to not simply flood ND traffic.

> What are the scaling numbers for IGMP groups and MLD groups and how
> many IGMP/MLD reports can be processed per second on commonly
> available access-layer switches?

You probably aren’t running a 300-node subnet on lower end common access-layer switch hardware. It’s going to require something higher end than that.

> Having designed a ubiquitous protocol 16 years ago that can't be
> implemented reasonably cheaply on current hardware is an operational
> problem that can and should be dealt with by tweaking the protocol in
> some cases.  I think the protocol change proposals put forward in the
> article are a quite reasonable starting point for discussing how to
> mitigate this issue and shouldn't be dismissed out of hand.

I think that the protocol can be implemented reasonably cheaply on current hardware if you don’t design your network so poorly that the fact it hasn’t collapsed in on itself in IPv4 is a minor miracle. Lots of people have very large IPv6 networks running just fine on a  pretty wide variety of commodity hardware at this point.

The OP makes clear a number of places where his network design is an utter failure waiting to happen, then goes on to blame IPv6 based on little more than speculation about the cause.

Smaller layer 2 zones would greatly improve his situation. Turning off privacy addressing would also help. (This is, as has been pointed out, under the control of the network operator as he can set the M bit, turn off the A bit, and give out DHCP addresses as an example.)

I suspect there are a number of other viable solutions.  OTOH, modifying ipv6 to support such an environment seems a fools errand to me.

Owen

> 
> On Tue, Sep 09, 2014 at 10:43:07AM +0000, Hemant Singh (shemant) wrote:
>> Agreed.  Just because one vendor’s switch melted an ipv6 network is not enough justification to change protocols.
>> 
>> Hemant
>> 
>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo Colitti
>> Sent: Tuesday, September 09, 2014 6:29 AM
>> To: Nick Hilliard
>> Cc: l.wood@surrey.ac.uk; IPv6 Operations
>> Subject: Re: [v6ops] Interesting problems with using IPv6
>> 
>> On Tue, Sep 9, 2014 at 6:42 PM, Nick Hilliard <nick@foobar.org<mailto:nick@foobar.org>> wrote:
>> This happened because the switch CPUs were overloaded with mld report packets due to end hosts on the extended L2 network replying to MLD all-groups queries every 150 seconds.
>> 
>> So the switch was configured to send all-groups queries to all hosts, but did not have the CPU power to process them, and could not, or was not configured, to rate-limit them.
>> 
>> News at 11: building a network beyond the capabilities of the gear that runs it will result in failure.
>> 
>> That does not mean the protocol is flawed. ARP could have done the same thing, and in fact that was a common problem many years ago... except that these days ARP is usually processed on the fast path and it doesn't matter.
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops