Re: [v6ops] Interesting problems with using IPv6

[Chuck Anderson <[e-mail]>]

On Fri, Sep 12, 2014 at 03:33:52PM -0700, Owen DeLong wrote:
> > 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.

Actually deployed networks are encountering 300+ privacy addresses on
some machines.  Is that a bug or by design of the OS vendor?  I don't
know.

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

Agreed.  Good idea.

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

It isn't hyperbole.  It has been observed multiple times by different
people:

http://blog.bimajority.org/2014/07/16/ipv6-privacy-addresses-windows-just-say-no/

"it was a Windows machine, [...] I saw that it was responsible for the
vast majority of those multicast memberships: 350 different multicast
groups in all, nearly all of which were “solicited node” groups for
different IPv6 “privacy” addresses"

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

"I used Ubuntu as an example, but it is hardly the worst offender. We
have seen Windows machines with more than 300 IPv6 addresses"

And a thorough description of the problem and possible solutions:

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

> > 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 only reasonable way to avoid this problem today via network
design, is to design you network to use DHCPv6 instead of SLAAC or
turn off privacy addressing on all hosts.  Unfortunately for less
managed networks (the exact use case that SLAAC is designed for--hands
off) it isn't feasible to go to every host and manually turn off
privacy addressing.  That means the only practical way to solve this
problem is to only ever use DHCPv6.  This is a somewhat surprising
result, perhaps unanticipated by those who worked on ND & MLD, and
probably not desireable for those who champion SLAAC.

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

He doesn't have large Layer 2 zones.

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

Modifying ND is not without precedent.