Yeah, Verizon and VZW are not the same animal ... FiOS *needs* to get
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@nanog.org] On Behalf Of Darren Pilgrim Sent: Sunday, June 22, 2014 8:41 PM To: trejrco@gmail.com; Lee Howard Cc: NANOG Subject: Re: Ars Technica on IPv4 exhaustion On 6/18/2014 11:49 AM, TJ wrote: 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.