Re: [v6ops] Implementation Status of PREF64

[Owen DeLong <[e-mail]>]

> On Oct 12, 2021, at 01:45 , Gert Doering <[e-mail]> wrote:
> 
> Hi,
> 
> On Tue, Oct 12, 2021 at 08:12:22AM +0000, Pascal Thubert (pthubert) wrote:
>> When that???s the case, and the node needs, say, less than 1000 addresses, could we delegate a /118?
>> This way, we can build a /64 NBMA subnet, which maintains the subnet boundary at /64, but allow routing inside.
>> We could, e.g., terminate vxlan on the /118 and use routing over them.
>> I would love to see that???
> 
> This is an interesting comment indeed.
> 
> I do not feel comfortable with giving out /64 or larger to "random
> devices connecting to Wifi", as that (think "1000 devices in a building")
> will drastically increase the number of subnets required for a generic
> office building

Will it? Let’s consider giving a /64 to every device in an office building.

Let’s consider that there are 1,000 other LAN segments for various purposes
in the building. Let’s further suppose that there are 1,000 LAN segments just
for point to point infrastructure, etc.

Now, let’s add 5,000 devices, each of which gets its own subnet. That brings
us to a building total of 7,000 /64s needed.

Assuming the office building gets the recommended /48, you still have
58,636 subnets left over.

> - where a /56 might be sufficient before, with plenty of
> headroom, you'd then need a full /48 (or more, if you want/need to keep 
> routing aggregated, and have to set aside something like a /52 per 
> "end device segment").

You should have gotten a /48 in the first place, so I’m not seeing any
harm here.

> Now, "something which will aggregate to a /64 in total, for an arbitrary
> number of devices" - like, a /96, given 4 billion addresses each to up to
> 4 billion devices - would definitely be something nice to have.

I’m really not seeing the benefit here.

There are more than enough /48s to give a few to each building on the
planet and still have plenty left over for Mars, Alpha Centauri, the Moon,
and anywhere else you can foresee us extending the internet.

> But I assume that this is not going to work, as I hear that this is 
> not (only) for "things happening inside the device" but also "tethering",
> which would require a /64 then.  Which, incidentially, is a use case
> not desired in Enterprise context.

I think we are discussing both scenarios and perhaps that makes
it more confusing.

I would propose that generically, it makes almost as much or more
sense to route a prefix to the loopback inside the device as it does
to issue multiple addresses on the LAN segment to the device.

In the former case (routed to loopback), it takes up one slot in
a routing table. In the latter case, each address the device is holding
takes up a slot in the ND Table of each L3 device on the LAN segment.

So the better way to handle this leaves the in-device scenario being
identical to tethering from the LAN perspective, which as you point
out may be undesirable in some enterprises. Personally, I think that
eventually, enterprises are going to have to recognize that the
LAN extensions ship has sailed and that it’s a purely policy and
political issue which cannot be adequately or effectively controlled
through technical means.

Owen