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

[Mark Smith <[e-mail]>]

On 7 August 2017 at 21:07, Gert Doering <[e-mail]> wrote:
> Hi,
>
> On Mon, Aug 07, 2017 at 12:35:25PM +0200, JORDI PALET MARTINEZ wrote:
>> Most of the RIR policies allow a shorter prefix than /48 for a single site
>> if justified.
>
> "If justified" has traditionally been along the lines of "number of buildings,
> number of subnets, number of aggregation levels", so, number of *networks*.
>
> "Number of hosts" has not been a justification argument in (at least)
> RIPE IPv6 policy, so that would be a fairly significant change.
>
> Personally, I would be very careful here - permitting assignments of
> larger address blocks because we *waste* a /64 on a potentially very
> large number of hosts in a network might cause shortage further up.
>
> And yes, I think this is extremely wastive, well over the limits of what
> is normal "do not care about wasting addresses!" level of IPv6 normal.
>

So it's worth considering what the word "waste" means. It means
getting no value at all from some quantity of a resource. That
quantity of resource isn't being used for anything of value to the
resource's user.

What we get from /64s/64 bit IIDs is simplicity (in planning and
operation), robustness (because if there is only one valid value for
something, every other value is an error and easy to see), and the
ability to give a addresses useful privacy and security properties.
They are all of use and value to the end-users users of the Internet,
so /64s/64 bit IIDs are not wasteful.

Of course, it would be possible to be reckless with resource
consumption such that you encounter unexpected and unnecessary
resource scarcity. The induced scarcity will then cause people to have
to start to make choices and trade-offs as to which beneficial uses
and values they get from the resource to give up.

So there needs to be a balance. Consumption must not be reckless,
however it also should not be so intentionally and artificially
constrained that trade-offs between beneficial uses and values have to
be made.

Brian's beach sand maths shows that there isn't a scarcity of /64s, in
particular as his calculations were within the 1/8th of the IPv6
address space we are currently using for global addresses (i.e.,
2000::/3). Leaving 1/8th for ULAs, Loopback etc., would still have
enough /64s in the other 6/8ths of the IPv6 address space to give one
to each grain of beach sand on 6 other Earth like planets.

> On a subnet, having a "it is big enough for everything, no matter how
> many hosts" is a desirable property because it makes network planning much
> easier - single size fits all, focus on more interesting work.  A /64
> is already excessive here, but given that the number of subnets is
> bound by factors like "how many different purposes can you come up
> with?", "router config", etc.  I'm willing to accept a /64 here.
>
> A /64 per *host* is much less bound - while far beyond anything you can
> configure on that host, so the trade-off "waste vs. useful number of bits"
> is not reasonable for me.
>

I don't think anybody is suggesting that a "host shared /64" model is
to be universally replaced with a universal "per-host /64 prefix"
model. It is an alternative option that has benefits in some
situations.

Sticking with a /64 boundary in this prefix per host model is for
simplicity and compatibility with existing specifications and
implementations. We should only give it up (and pay the costs of
giving it up) if it can be shown it can't work.

>
> Should this topic come up in RIPE policy discussion, I'll chair the
> discussion and refrain from having an opinion, but will reserve the right
> for a "told you so" later.
>

I assume RIPE give out /32s as the minimum to an ISP, or 4+ billion
/64s? If an ISP isn't giving out at least /56s to customers, the
problem isn't with the /64 boundary, it is the ISP carrying IPv4
address scarcity management practices over to IPv6 where they aren't
needed.

We are wasting our time (getting no value from it) trying to
accommodate unneeded IPv4 practices carried over to IPv6. We end up
trying to make things accommodate more and more perverse and
unnecessarily conservative IPv4 carried over practices. If we
accommodate them, we're also tacitly endorsing them.

Regards,
Mark.