Re: [v6ops] Interesting problems with using IPv6

Excuse front posting, but telling somebody "your network breaks
our specs" just invites the response "your specs broke my
network." I think the obvious next step in this matter is to
write down operational and implementation guidance to prevent
this sort of problem occurring. That seems to be part of v6ops'
job. (Sorry, I'm not volunteering.)

Regards
   Brian

On 13/09/2014 11:12, Chuck Anderson 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.
> 
>>> 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.
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops