[arin-ppml] IPv6 Non-connected networks

[George Bonser]

> The current kit deals with packets rather than flows. Flows was
> investigated thoroughly and looks very much like a blind alley. It has
> some useful niches but the failure modes are catastrophic.

Yeah, I know that, but they tend to cache information regarding a flow.
The cache isn't big enough is the problem I am worried about.  Some gear
likes to populate the routes (FIB) in hardware and if you don't have
enough space, they don't all get in there. Chip density being what it
is, I would think that more storage is available in the same form factor
today than was available when the module was initially designed.  It
isn't so much a performance issue with a large table these days because
that is switched in hardware, not by the CPU.  The problem is a lack of
space to hold all the routes in the hardware.

When you are talking about the ability to hold 250K routes of IPv6 or
1,000K routes of v4, the problem gets bad when multihomed v4 nets become
multihomed v4 AND v6 nets and have a route to their net in both
protocols because they are running both.  If you want to have space for
500K v4 routes in FIB that leaves you with only enough room for 125K v6
routes and while that is ok now, will that still be OK when A: more
networks begin to appear in both spaces and B: smaller v4 allocations
are made?  That is the concern I had.

I see the pushback against routing table growth as more of a hardware
limitation than anything else (problems with instability in a network
with more routes to announce/withdraw notwithstanding).

"dual stacking" might only work for some period of time before both
protocols combined outgrow the capability of the hardware and people
need to split the infrastructure from dual-stacked to dedicated stacks.

But this is more of an operational issue than an ARIN policy issue, the
point being that operational issues and RIR policy issues are tightly
coupled.

George