Re: [v6ops] New Version Notification for draft-ietf-v6ops-dhcp-pd-per-device-05.txt

[Martin Huněk <[e-mail]>]

Hi Jen,

Dne neděle 5. listopadu 2023 17:17:13 CET, Jen Linkova napsal(a):
> Hello,
> 
> Following the conclusion of the WGLC (thanks to everyone who
> commented!), we've submitted a -05 version with the following changes:
> 1. Making it more clear that the draft requires the network to
> delegate a SLAAC-suitable prefix, and /64 is currently required for
> SLAAC to work - but it  doesn't have to be like that in the future.
> Examples also use /64. Brian, does it address your comment?

Even in the hypothetical situation in which IETF agrees on making SLAAC work on longer prefixes, you will still need to maintain compatibility with older implementations that require /64. So the /64 is set to the stone.

> 2. To address most of Ole's comments:
>   2.1 Making it explicit that the draft only covers the network
> behavior, while host requirements are out of scope.

This seems to be an elegant way to solve the elephant-in-the-room problem. Pretend that the elephant is out of scope. The Client/Host behaviour makes a difference between address space hungry draft dangerous for a lot of address plans and the useful tool that can solve multiple entries in neighbour cache for all networks (even for those with a single /64). The difference in question is in what the client puts in the prefix-length hint field (together with 2nd point of section 7 - an unnecessary requirement of implicit min. /64).

>   2.2 Clarifying that the network can support both flat and
> hierarchical models - it's up to the host to specify the hint.

Undefined behaviour of the host ...

> 3. Rewriting examples in the prefix length consideration section to
> make it clearer that the proposal does not require an excessive amount
> of IPv6 space.

But it does! It is the same address-space-hungry draft as the initial collin-00 version. The formula used in the -05 version of the draft means: If you have at least X+32 of IPv6, you can be in the same situation with IPv6 as you are in IPv4. Now, do we want to be in the same situation? Why migrate to IPv6, then?

At least, I want to have some reasonable route aggregation and not look so often if I'm running out of space every time. This cost some additional space. If I can choose between having a "nicer," more aggregated addressing plan or allowing every host to extend the network, what do you think I will choose? I don't want to be in the same situation as I'm in IPv4.

I agree with Gert. You can have /80s all you want, but you are not getting /64s from me. If your implementation requires it, then it is NAT66 for you, ND proxy, or IPv4 only. You choose.

We are trying to solve the excessive amount of addresses used by some implementations by the excessive prefix size given to them. Is it a smart solution?

Regard,
Martin
> 
> 
> 
> On Sun, Nov 5, 2023 at 4:54 PM <[e-mail]> wrote:
> >
> > A new version of Internet-Draft draft-ietf-v6ops-dhcp-pd-per-device-05.txt has
> > been successfully submitted by Jen Linkova and posted to the
> > IETF repository.
> >
> > Name:     draft-ietf-v6ops-dhcp-pd-per-device
> > Revision: 05
> > Title:    Using DHCPv6-PD to Allocate Unique IPv6 Prefix per Client in Large Broadcast Networks
> > Date:     2023-11-05
> > Group:    v6ops
> > Pages:    20
> > URL:      https://www.ietf.org/archive/id/draft-ietf-v6ops-dhcp-pd-per-device-05.txt
> > Status:   https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcp-pd-per-device/
> > HTML:     https://www.ietf.org/archive/id/draft-ietf-v6ops-dhcp-pd-per-device-05.html
> > HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-dhcp-pd-per-device
> > Diff:     https://author-tools.ietf.org/iddiff?url2=draft-ietf-v6ops-dhcp-pd-per-device-05
> >
> > Abstract:
> >
> >    This document discusses an IPv6 deployment scenario when individual
> >    clients connected to large broadcast networks (such as enterprise
> >    networks or public Wi-Fi networks) are allocated unique prefixes via
> >    DHCPv6 Prefix Delegation (DHCPv6-PD).
> >
> >
> >
> > The IETF Secretariat
> >
> >
> 
> 
>