Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO)

Brian Dickson brian.peter.dickson at
Wed Dec 4 20:04:35 UTC 2013

On Wed, Dec 4, 2013 at 2:34 PM, Tony Hain <alh-ietf at> wrote:

> Brian Dickson wrote:
> > > And root of the problem was brought into existence by the insistence
> > > that every network (LAN) must be a /64.

> about how many bits to add for hosts on the lan. The fact it came out to 64
The point I'm making (and have made before), is not how many bits, but that
it is a fixed number (64).

And again, the concern isn't about bits, it is about slots in routing
Routing table hardware is generally:
(a) non-upgradeable in currently deployed systems, and
(b) very very expensive (at least for TCAMs).
(c) for lots of routers, is per-linecard (not per-router) cost

If you look back at the need for CIDR (where we went from class A, B, and C
to variable-length subnet masks),
it might be a bit more obvious. CIDR fixed the total number of available
routes problem, but fundamentally
cannot do anything about # route slots.

Fixed sizes do not have the scalability that variable sizes do,
when it comes to networks, even within a fixed total size (network + host).
Variable sizes are needed for aggregation, which is the only solution to
router slot issues.

IF deployed by operators correctly, the global routing table should be 1
IPv6 route per ASN.
However, that is only feasible if each ASN can efficiently aggregate
forever (or 50 years at least).

The math shows that 61 bits, given out in 16-bit chunks to end users, when
aggregation is used
hierarchically, runs the risk of not lasting 50 years.


> Now
> go back to the concept of miserly central control of lan bits and figure
> out
> how one might come up with something like RFC3971 (SEND) that would work in
> any network.
There are two really easy ways, just off the top of my head:
(1) prefix delegation. Host wanting SEND asks its upstream router to
delegate a prefix of adequate size.
The prefix is routed to the host, with only the immediate upstream router
knowing the host's non-SEND address.
The host picks SEND addresses from the prefix, rotates whenever it wants,
problem solved. QED.

(2) pass the prefix size to the host. Have the SEND math use whatever
scheme it wants, modulo that size.
E.g. rand(2**64-1) -> rand(2**prefix_size-1). Host redoes this whenever it
changes addresses, problem solved. QED.
(The question of how much space is adequate for the protection offered by
SEND. I suggest that 32 bits as a minimum,
would still be adequate.)

As far as I have been able to determine, there are very few places where
fixed /64 (as a requirement) actually makes sense.
For example, the code for IPv6 on Linux, basically does "check that we're
/64 and if not fail", but otherwise has no /64 dependencies.

We can always do an IPv6-bis in future, to first fix SEND, then fix
autoconf, and finally remove /64 from IPv6 -- if we think the usage rate
justifies doing so.


More information about the NANOG mailing list