Re: [v6ops] Interesting problems with using IPv6

[Owen DeLong <[e-mail]>]

On Sep 12, 2014, at 4:12 PM, Chuck Anderson <[e-mail]> wrote:

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

It’s definitely a bug. I’ve never seen that many, so I’d love to know the specifics where this has occurred.

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

Ah, so the grotesque violations of network etiquette come from windows boxes… What a surprise. Explains why I haven’t seen them. I gave up on Windows over a decade ago.

On most well behaved OS, btw, it’s a maximum of ~7.

> And a thorough description of the problem and possible solutions:
> 
> http://inconcepts.biz/~jsw/ipv6_nd_problems_with_l2_mcast.pdf

Right… Again, it seems like large layer 2 zones+mld snooping+privacy addressing are the “fire triangle” here and that if you remove any leg, you eliminate the problem.

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

No, you can also avoid it by network design by limiting the size of your link local domains. If your switch has a 1000 multicast group limit, then you shouldn’t have more than about 120 hosts on that network. If you’re running Windows, turn off privacy addressing in group policy or demand that Micr0$0ft fix their broken shit.

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

Yes he does… He stated that he had a campus wide L2 zone.

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

Sure, and I’d welcome modifying ND for legitimate need, such as RFC6106.

In this case, ND doesn’t strike me as the place where ire is best targeted. MLD snooping could be improved to ignore solicited node addresses. This wouldn’t affect anything else and would clearly solve the problem. Micr0$0ft could fix their broken shit and not generate so many extra addresses for no reason.

Owen