IPv6 woes - RFC

Wed Sep 22 16:48:01 UTC 2021

On 2021-09-19 09:20, Masataka Ohta wrote:
> John Levine wrote:
> 
>>> Unless their infrastructure runs significantly on hardware and
>>> software pre-2004 (unlikely), so does the cost of adding IPv6 to
>>> their content servers. Especially if they’re using a CDN such as
>>> Akamai.
>> 
>> I wasn't talking about switches and routers.
> 
> But, on routers, IPv6 costs four times more than IPv4 to
> look up routing table with TCAM or Patricia tree.
> 
> It is not a problem yet, merely because full routing table of
> IPv6 is a lot smaller than that of IPv4, which means most
> small ISPs and multihomed sites do not support IPv6.
> 
> 
> Mark Andrews wrote:
> 
>> There is nothing at the protocol level stopping AT&T offering a
>> similar level of service.
> 
> Setting up reverse DNS lookup for 16B address is annoying,
> which may stop AT&T offering it.
> 
>> Don’t equate poor implementation with the protocol being broken.
> 
> IPv6 is broken in several ways. One of the worst thing is its
> address length.
> 
> 						Masataka Ohta
+1
Different scope problem: on inexpensive software BRAS solutions 
(PPPoE/IPoE). Enabling ipv6 just jacked up neighbour table usage and 
lookups cost in benchmark profiling, because now it have to keep for all 
users IPv6 /64 + MAC entries.
Another drop is neighbor discovery on device with 10k IPOE termination 
vlans and privacy extensions.
Also, i wonder how this changed? 
https://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/
Another problem is privacy extension and IoT, they are not supported in 
lwip stack shipped with most of IoT SoC. As far as i see in git it is 
not added yet too.
And SLAAC vs DHCPv6, again, first lacking some critical features, and 
second is often not implemented properly.

As many say - this is tiny, a drops of mess and complexities, but the 
ocean is made up of tiny drops. All these little things lead to the fact 
that very few want to mess with v6.