Re: IPv6 woes - RFC

[Owen DeLong via NANOG <nanog () nanog org>]

> On Sep 20, 2021, at 05:15 , Masataka Ohta <mohta () necom830 hpcl titech ac jp> wrote:
>
> Owen DeLong wrote:
>
> > > 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.
>
> Not at all.
>
> > Compare AS6939 v4 vs. v6:
>
> That is not a meaningful comparison.
>
> As mergers of ASes increases the number of announcements
> and IPv4 addresses were allocated a lot earlier than those
> of IPv6, comparing the current numbers of announcements is
> not meaningful.

Mergers of ASes does not increase announcements in IPv4 nearly as much as slow-start
and repeated expanding requests for additional IPv4 space have.

> As a result, size of global routing table will keep
> increasing unless there are other factors to limit it.

Sure, but it’s very clear that the rate of increase for IPv6 appears to be roughly 1/8th that of
IPv4, so even if IPv6 was 4x as expensive, the growth rate in cost would still be 1/2 that of
IPv4.

> An important factor is that, for IPv4 with globally
> routable /24, the absolute upper limit is merely 16M,
> to be looked up by a single memory access of conventional
> SRAM without needing TCAM. OTOH, IPv6 is hopeless.

The reality is that IPv4 will never be completely disaggregated into /24s and IPv6 will never
be completely disaggregated into /48s, so this is actually meaningless and not predictive
in any way.

> Another favorite factor for IPv4 is that, though most of
> routing table entries are generated from small entities
> having a /24 assuming NAT, if such entities are merged,
> renumbering is not so much a pain and they are motivated
> to rely on a single /24 and sell others. OTOH, there is
> no such motivation for IPv6.

There is no need for such motivation in IPv6 and better yet, since the two organizations
have fully globally unique addresses deployed throughout their network, there’s no risk
of collisions in RFC-1918 space necessitating large renumbering projects to merge the
networks. Indeed, all you need to do is turn on forwarding between the two networks
and you’re basically done.

As such, no, that’s an advantage that clearly goes to IPv6, not IPv4.

> > v4 is so thoroughly fragmented and v6 is a lot less likely to become
> > so.
>
> It is true that fragmentation is a problem. However, it merely
> means that IPv6 address space will also be fragmented and that
> IPv4 can but IPv6 can't be deployed at full scale,

Why would IPv6 become fragmented? When a provider the size of HE can
easily get a /24 from ARIN, what need is there for fragmentation. Sure, they
started with a /32 and they’re keeping that, but the equivalent growth in IPv4
would have resulted in a /20 + /19 + /18 + /17 + /16 + /15 + /14 + /13 and likely
an additional /12 eventually. So you get 7-8 prefixes for the same factor of growth
as 2 prefixes in IPv4.

It simply doesn’t make sense to claim that fragmentation in v6 will be nearly as bad
as it is in v4 because we don’t have the problems of slow start and we’re no longer
trying to balance scarcity against aggregation.

Owen