Re: [v6ops] Implementation Status of PREF64

[Owen DeLong <[e-mail]>]

> On Oct 12, 2021, at 09:47 , Gert Doering <[e-mail]> wrote:
> 
> Hi,
> 
> On Tue, Oct 12, 2021 at 06:40:15PM +0200, Philip Homburg wrote:
>> In your letter dated Tue, 12 Oct 2021 18:19:14 +0200 you wrote:
>>> Right.  My mental model would not us "the same /64 that the wifi is
>>> attached to" but "a chunk of addresses from a second /64".
>>> 
>>> I strongly dislike the implications of "any larger site that has a wifi
>>> network needs to have a /52 provisioned, so thousands of wifi clients
>>> can have a /64 *each*" on address space management on all layers.
>> 
>> I wonder why this is an issue.
> 
> Because of hierarchy in routing.  Address space allocated is usually
> not "flat" as in "you can just use /64s one after another" but there is
> routing hierarchy built in - like, "this company has a /48, and needs
> to number a few buildings with it" (forming a "site" in whatever 
> definition of "site").  Thousands of devices is not a problem with
> "part of a /48", but thousands of *subnets* can easily become one.

That company made a mistake and should go back to whatever source
they obtained that /48 from and say “we’ve got X buildings, so we’re
going to need at least X /48s, ideally rounded up to a nibble boundary.”

(e.g. if you’ve got 7 buildings, you really ought to just get a /44, if you’ve
got more than 12 buildings, you ought to get a /40, etc.)

ARIN policy supports this. (I know, in part because I authored the policy).

> Yes, you can always construct plans that work for that specific case,
> but being wastive with *subnets* is actually not something we can 
> trivially afford without wrecking lots of people's existing address
> plans, and ruining the ease of building hierarchy with enough wiggle
> room on each level.

Disagree thoroughly. If you built your addressing plan badly, it probably
needs wrecking and sooner is better than later. The good news is that
you probably don’t have to return the addresses you’ve already deployed
in that way, but the bad news is continuing to use them that way will
tie up a few slots in your routing tables as long as you do.

> (ceterum censeo, /64 was not a very smart decision)

We can agree to disagree. So far, I’ve seen no data to support that.


Owen