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

[Mark Smith <[e-mail]>]

On 8 August 2017 at 04:13, james woodyatt <[e-mail]> wrote:
> On Aug 5, 2017, at 20:21, Brian E Carpenter <[e-mail]>
> wrote:
>
>
> […] If there's a problem, it's not in the area of a shortfall of /128s.
>
>
> This is where I point out that diamonds, unlike grains of sand, are just
> sufficiently uncommon that monopoly power admits the inducement of
> artificial scarcity to inflate market prices.
>
> If there's a shortfall of /64s, it's human error.
>
>
> There is more to the analogy than meets the eye, i.e. the error may be one
> of political and economic philosophy, and not a technical one, and moreover,
> the analogy may break down around the ways that numbers are not the same as
> stones. After all, if the point of the game is to create an artificial
> scarcity of numbers, what difference does it make where you put the prefix
> boundary in the process? You can set it anywhere you like and achieve the
> same effect.
>

So it was a metaphor. It's demonstrating the contrast between how we
value and handle diamonds (IPv4) verses how we value and handle sand
(IPv6).

I hadn't thought to think of it literally as Brian did, however I'm
not all that surprised for sand it is literal. It is probably fairly
literal for diamonds too.

Diamonds are rare, and therefore the dominant cost is in
finding/discovering them and extracting them. Transport and handling
after that are a trivial cost in comparison. Significantly reducing
the cost of diamonds would involve reducing the discovery and
extraction costs.

Sand is plentiful, so transport and handling becomes the dominant
cost. Reducing the cost of transport and handling directly reduces the
cost of sand.

Similarly, as IPv6 addresses are plentiful (once the infrastructure to
support IPv6 exists), "handling" them far outweighs the cost of
"finding" them. One of the ways to reduce the cost of IPv6 is to
reduce the cost of handling IPv6 addresses.

That's why I think simple universal sizes/boundaries like /48 per site
and /64 for subnets/64 bit IIDs are better. They reduce the cost of
handling - the cost of humans becoming involved to be parsimonious
with addresses and numbers of /64 prefixes increases the handling cost
of IPv6 addresses. They reduce costs in other places too - having a
single, common and generic IID size rather than a per link-specific
IID size means development and implementation of IPv6-over-foo
specifications is cheaper, because there does not have to be any per
link-specific IID size related effort.

The boundaries themselves are arbitrary, as long as they facilitate
all the requirements (in our IPv6 specific case, functionality,
ideally avoidance and tolerance of error (e.g., duplication of
addresses is rare, so DAD succeeds most of the time), security and
privacy). The important priority should be to have the least number of
boundaries.

For IPv6 to be as successful as we here want it to be, we want to make
adopting and using the technology as cheap as it possibly can be. That
will only encourage its use.

Regards,
Mark.