Re: [v6ops] Fwd: New Version Notification for draft-collink-v6ops-ent64pd-01.txt

[Jen Linkova <[e-mail]>]

On Fri, Dec 16, 2022 at 7:09 PM Gert Doering <[e-mail]> wrote:
> I never said that I *like* a /64 per VLAN, but that ship has sailed
> long ago and can no longer be stopped (personally, I think it was a
> blatantly stupid idea).

;) My experience is so much different - /64 is the best thing which
happened to me in my professional life.
I've wasted so much time first discussing what should be subnet size
for a given network segment and then renumbering /21s to /20s because
the DHCP pool is exhausted and so on and so on...
So I definitely don't want to do it anymore. No subnet should ever
need expansion/resizing.
/64 gives it to us.

> I strongly dislike having to assign a /56 or larger "per VLAN", just
> because there might be 100s of hosts requesting a /64.  This is an
> order of magnitude different in subnet consumption - and while we
> have limitless addresses in a single subnet, we do not have limitless
> subnets in a typical hierarchical network deployment ("country,
> region, site, department, firewall zone, ...").
>
> > > To implement this, network admins need not only to add v6 subnets
> > > to broadcast segments but also add pools of sizeable size, which does
> > > create pressure in the /48.../64 range of the addresses they have
> > > ("one /48 per site").
> >
> > Even 1 /48 per site gives you 65K /64s.
> > Also I do not think that "one /48 per site" is set in stone. It's
> > mostly because you can't assign less if you want local ISP egress -
> > but nothing would prevent you from assigning more.
>
> Good luck trying to get global RIR policies relaxed on that - there's
> a reason (called "Geoff Huston math") why it was lowered from "always,
> every customer/site gets a /48" to "most will only get a /56".

This proposal is targeted to large networks. They are usually capable
of having multiple /48s per site if needed.
Nobody's suggesting doing it on SMB/home networks.

> > > Something like a /96 per host - so "limitless amounts of host would
> > > fit into a single /64" would avoid that, and still fulfill the
> > > stated necessity of having many many many addresses per hosts.
> >
> > Am I right that smth like "the prefix MUST be at least /96 but SHOULD
> > be /64" would make you less unhappy about the proposal?
>
> No.  It should not even suggest that adding a /64 per host for a regular
> "there could be hundreds of hosts" multiaccess network would be something
> reasonable to do.

I'm not sure why you think it's unreasonable. Section 9
(https://www.ietf.org/archive/id/draft-collink-v6ops-ent64pd-01.html#name-benefits)
describes the benefits.
It's up to an operator to decide if the benefits are worth some
additional address space.
As an operator, I think it's worth it.

> It could say "operators that have sufficient address space MAY assign
> a /64 per host".
>
> OTOH, there are no mechanisms on the hosts today to deal with "incoming
> DHCPv6 PD, and address assignment to consumers on the host" - so if we
> can get that right *first*, not relying on "SLAAC, so /64" for this
> step, the benefit of a /64 "it can do SLAAC!!" goes away.

I'd let the implementers comment on this but I suspect it would take
implementation complexity to a whole new level.



-- 
SY, Jen Linkova aka Furry