Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt

[Lorenzo Colitti <[e-mail]>]

On Wed, Aug 16, 2017 at 7:40 PM, Simon Hobson <[e-mail]>
wrote:

> Turning that around, do we have to hard-code limitations in that we cannot
> know the consequences of ?
> Even hard-coding /64 doesn't remove the need to be able to work with
> variable length prefixes in all but the most trivial of systems, and given
> modern hardware capabilities, the processing cost can hardly be called
> expensive (even on the most basic of processors). Bear in mind that it's
> now hard to buy a processor that isn't orders of magnitude more powerful
> (and resource endowed) than the computers that first put men on the moon.
>

/64 gives you something that no longer prefix does: the ability to run
SLAAC and connect unlimited devices behind the host.

I'd suggest that this is a side effect of the "/64 everywhere" mantra.
> Someone inexperienced has picked up a spec, seen that "everything is /64",
> so they've (incorrectly) assumed all they need to deal with is a /64.
>

No. Someone wrote code that gets a prefix via DHCPv6 PD, and blindly
announces it in an RA. That doesn't work because SLAAC only works with
64-bit IIDs, and for good reason.

I'm sure many developers (or at least, their managers) once thought that
> their code would never be used into the year 2000 - that turned out to be
> an incorrect assumption. The history of computing is littered with similar
> examples where people went for the 'easy" option, only to hardcode in
> something which later turned around to bite their backside. I keep seeing
> an argument for the easy option of "/64 everywhere" which is ALREADY
> causing problems.


Already? 64 everywhere has been the standard for 20 almost years now. It
predates pretty much every IPv6 network and every IPv6 implementation out
there today.