[141909] in North American Network Operators' Group
Re: The stupidity of trying to "fix" DHCPv6
daemon@ATHENA.MIT.EDU (Owen DeLong)
Tue Jun 14 04:05:17 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <op.vw05dvlhtfhldh@rbeam.xactional.com>
Date: Tue, 14 Jun 2011 01:00:22 -0700
To: Ricky Beam <jfbeam@gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jun 13, 2011, at 12:50 PM, Ricky Beam wrote:
> On Sun, 12 Jun 2011 09:45:01 -0400, Leo Bicknell <bicknell@ufp.org> =
wrote:
>> In a message written on Sun, Jun 12, 2011 at 01:04:41PM +0200, =
Iljitsch van Beijnum wrote:
>>> Like I said before, that would pollute the network with many =
multicasts which can seriously degrade wifi performance.
>>=20
>> Huh? This is no worse than IPv4 where a host comes up and sends a
>> subnet-broadcast to get DHCP.
>=20
> Broadcast !=3D Multicast. esp. when talking about wireless chipsets. =
I've yet to find a wifi chipset that didn't completely fuck-up when =
presented with even a low pps of multicast traffic. Broadcast traffic =
doesn't seem to bother them -- it doesn't attempt to filter them in any =
way, or really pay them any attention. If I had to guess, the chip =
firmware is individually transmitting multicast packets to each peer; a =
broadcast packet is sent once to all peers.
>=20
> I've not had any wireless networks disrupted by broadcast traffic -- =
and with Radware load balancers in the network, there are *plenty* of =
broadcasts (ARP). Just a few 100pps of multicast and the AP fails. =
(linksys, netgear, even cisco... all broadcom crap radios.)
>=20
> --Ricky
You would need an AWFUL lot of hosts for this to add up to a few 100pps =
(or even 10pps) of multicast
traffic.
Owen
