> On Sep 18, 2021, at 23:20 , Masataka Ohta <mo...@necom830.hpcl.titech.ac.jp>
> 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.
Well, it’s a combination. Even with full v6 adoption, the routing table in v6
should be substantially smaller.
Compare AS6939 v4 vs. v6:
+ 6939 is probably the most v6 fully implemented ASN on the planet.
+ 6939 announces 4 of their own prefixes in v6 (They do originate 19
prefixes on behalf of customers)
+ 6939 announces at least 41 of their own prefixes in v4 and originates
myriad customer prefixes in v4.
That’s more than 10x the prefixes in v4 for the same network fully dual-stacked
vs. what is announced in v6.
v4 is so thoroughly fragmented and v6 is a lot less likely to become so.
>
>
> 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.
Why would one need to do that? For customers with a static prefix that want
reverse DNS capabilities,
offer to point the NS records for their prefix wherever they want and let them
run their own DNS servers.
>
> > 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.
Why do you think 128 bits isn’t enough?
Owen
