Ars Technica on IPv4 exhaustion

Mon Jun 23 02:32:48 UTC 2014

Our own fiber access vendor now does have IPv6 support, but I haven't been
able to keep it in production because a ~7.8 Mbps traffic IPv6 ND traffic
loop (side effect of another bug) knocked out voice services.  Turns out
that the traffic queue for IPv6 and DHCP (for the ONT's voice services) are
the same, and so I essentially DDoSed my customers' voice service.  Now,
I'll admit that ~7.8 Mbps of Neighbor Discovery traffic is atypical, but I
did learn that our access vendor does not have any rate-limiters in place
for that kind of traffic.  The vendor is planning to put voice in a higher
priority queue to avoid the voice-loss issue.

Some of you might ask why the access platform needs to be aware of ND
traffic.  My understanding is that for scalability and privacy reasons you
don't want to flood that traffic to all access ports, but just to the ones
that should respond.  The platform needs to do some traffic inspection.

Frank

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Darren Pilgrim
Sent: Sunday, June 22, 2014 8:41 PM
To: trejrco at gmail.com; Lee Howard
Cc: NANOG
Subject: Re: Ars Technica on IPv4 exhaustion

On 6/18/2014 11:49 AM, TJ wrote:
> Yeah, Verizon and VZW are not the same animal ... FiOS *needs* to get
their
> IPv6 house in order.
> Anyone have any information on that front ...?

For FiOS, the ONTs do transparent muckery at the IP level and aren't yet 
capable of equivalent IPv6 muckery.  Verizon is also quite confident 
they don't actually have to do anything about it.  Instead, they'll just 
roll out 6RD relays like Qwest/Centurylink did.  You didn't REALLY need 
a 1480 MTU, did you?

For Comcast business services, the SMC box on my demarc panel isn't IPv6 
capable and neither are any of Comcast's other business CPE.