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

["Philipp S. Tiesel" <[e-mail]>]

Hi

> On 20. Dec 2022, at 08:36, Jen Linkova <[e-mail]> wrote:
> 
> 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.

Not managing too many eyeball-networks, but having to care about k8 clusters,
hosting and community networks in different contexts, I see that quite differently…

- When herding k8-clusters, a /64 per hosts is too large to be
  feasible to accommodate all necessary aggregation levels, 
  i.e. host/availability-zone/cluster/region. I would either run into having
  to renumbers clusters as I run out of bits for the hosts or blow up
  the address space to sizes I won’t get from any RIR
- When hosting customers’ servers in a different context, a /64 will be much
  too tight for some use cases, but I could easily afford a /52 per hosts
- For developer laptops, a /64 or even a /60 looks quite right to be able to
  host multiple VM subnets.
- For community networks and non-profits, an uplink that allows a /64 per device
  without unreasonably limiting the number of hosts may not be affordable.

So I am convinced it really depends on the context what a reasonable size would be.
Therefore I would really love to see this draft leaving it to the administrator of
the local network to choose the right size and probably giving a reasonable advice
for different use-cases.
Also, one should think about allowing devices giving a hint about what would be a
reasonable size. In some networks, a few developer laptops that have use for a /60
and a IoT devices and printers that are fine with a /128 might be present, so the
administrator may configure the dhcpv6-server accordingly.


> 
>> 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.

AVE!
   Philipp S. Tiesel

--  
Philipp S. Tiesel
https://philipp.tiesel.net/