Re: [IPv6] [v6ops] Smaller prefixes (/64-/96?) for draft-collink-v6ops-ent64pd

I think it was a couple of years ago that we had an argument here about 
the short prefix (/16) that ICAO was requesting from IANA for an address 
space for the forthcoming ATN/IPS. The use of the /16 has now been 
written into the ICAO specification - although I am not up-to-date on 
where the IANA request is. However, the point is that ICAO would not 
need to have requested such a short prefix if we could have used a /96 
for each aircraft's MNP. Squeezing a global mobility address plan into a 
/64, whilst providing for expansion, legacy and separation into 
different domains was not that easy - and admittedly wasteful on address 
space.

Aircraft do not need SLAAC. Indeed, in a carefully controlled 
environment IP Addresses are probably going to get hard wired into each 
box. So why have an addressing plan that is hobbled by support of SLAAC? 
I have no problem with SLAAC itself - I use it to configure my home 
network - but it does not and should not be a universal requirement.

So please lets make SLAAC optional and get rid of /64 dependencies.

Tony Whyman

On 29/03/2023 13:06, Vasilenko Eduard wrote:
>
> I do not object if /64 would be super-MUST to support by any 
> implementation. It is fine. Some people may really choose it.
>
> I am asking for /96 OPTIONAL support (MAY?).
>
> Eduard
>
> *From:*ipv6 [mailto:ipv6-bounces@ietf.org] *On Behalf Of *Philipp S. 
> Tiesel
> *Sent:* Wednesday, March 29, 2023 1:24 PM
> *To:* Ole Troan <otroan@employees.org>
> *Cc:* 6man WG <ipv6@ietf.org>; Bob Hinden <bob.hinden@gmail.com>; V6 
> Ops List <v6ops@ietf.org>
> *Subject:* Re: [IPv6] [v6ops] Smaller prefixes (/64-/96?) for 
> draft-collink-v6ops-ent64pd
>
>
>
>     On 29. Mar 2023, at 11:41, Ole Troan <otroan@employees.org> wrote:
>
>     Philipp,
>
>
>                 I think a V6OPS document could say use a specific
>                 length for operational reasons, but a 6MAN document
>                 should support a range of prefixes.
>
>
>             Actually it's what's happening now: v6ops draft explains
>             why /64 is a
>             good idea, while 6man draft is saying:
>
>             "When a host requests a prefix via DHCPv6 PD, it MUST use
>             the prefix
>             length hint Section 18.2.4 of [RFC8415] to request a
>             prefix that is
>             short enough to form addresses via SLAAC."
>
>
>         I don’t understand why this is a MUST. What if the host is not
>         interested in running SLAAC anyway?
>         - I think it is a good idea if the DHCP server would provide
>         at least a /64 if is asked todo so.
>         - I agree a /64 is a a pretty decent default, but there should
>         be room to diverge for specific environments
>
>
>     This draft is more describing one operational model, and the
>     “MUST” applies within that model.
>     It is not a protocol specification.
>
> Agreed. My argument is that this model has much more applications iff 
> we turn this “MUST” into a “SHOULD” without making it weaker.
>
>
>
>     What you describe below, you can do with DHCP-PD today. E.g.
>     delegate a /120or however many addresses you need, to each node
>     and then use whatever mechanism K8 uses to assign addresses from
>     that prefix.
>
> Yip, planning it that way anyway.
>
>
>
>         I have a concrete use-case. We are currently planning IPv6
>         addressing schemes for really large K8S deployments.
>         For these the K8S Nodes, we don’t use SLAAC anywhere and we
>         can’t afford to spend a /64 per K8S Node without either
>         de-aggregating a lot, blowing up assumptions of our IaaS
>         providers, or wasting more address space than RIPE would be
>         willing to give us.
>         With something between a /80 and /96 per K8S node, we have
>         enough room at all aggregation levels.
>
>         For similar use cases, I would really prefer to stay within
>         the proposed per-host-pd framework.
>
>
>
>     Cheers,
>     Ole
>
> AVE!
>
>  Philipp S. Tiesel
>
> -- 
> Philipp S. Tiesel
> https://philipp.tiesel.net/
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests:https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------