Re: [v6ops] WGLC: draft-ietf-v6ops-dhcp-pd-per-device-02 -> SLAAC is still the "MUST"

On Thu, Oct 5, 2023 at 2:55 AM Vasilenko Eduard
<vasilenko.eduard@huawei.com> wrote:
> > So to increase the applicability
>
> Actually, restricting to 1 mechanism from 3 is to"decrease applicability", not "increase".
>
> Let network administrators decide what to use between the "DHCP-PD client" and the real host.

It's not always up to the administrator to decide. If the host needs
SLAAC, not much the administrator can do: either provide the
SLAAC-suitable prefix, or have a device with a broken connectivity.

> I expect that in the 3GPP TE case, SLAAC would be enforced.
>
> But to block other mechanisms outside the Android domain – is too much.

The draft doesn't block anything. It's an informational document
describing a deployment scenario - one of many. However I think it
would be a good idea to ensure that that scenario allows the
administrator to connect an arbitrary device to the network and do not
limit the solution to the cases when the devices can operate w/o SLAAC
- I guess it would be a completely different draft.
Let me give you an example: most network segments in my network
contain no Android devices at all, so it has nothing to do with
Android not supporting DHCPv6-PD. However if I disable SLAAC on those
segments and provide DHCPv6 IA_NA only, the network connectivity would
be broken for the vast majority of the devices. The reason is - as
I've mentioned before - that currently all implementations I know do
require SLAAC for forming 464xlat addresses.

> > The draft doesn't say the client MUST use SLAAC.
>
> It does:
>
> " The server MUST provide a prefix short enough for the client to assign addresses to its interfaces and connected systems via SLAAC"

This sentence requires *the server* to provide the prefix suitable for
SLAAC - in case the client needs it. If the client (and connected
systems) are happy with DHCPv6 IA_NA or manual config or smth else -
fine, the proposed solution would still work.
So I do not see where the draft puts any requirements on the client -
actually, please wait till the end of the week, -03 would make it
explicit that the draft doesn't put any requirements to the client,
re: what to do with the delegated prefix - it's about the network
part.

> And section 5 is very misleading in the SLAAC direction.

May I ask you to wait two days, we are rewriting section 5 so it would
contain facts and facts only - so hopefully it will be less
misleading.

> > -----Original Message-----
>
> > From: Jen Linkova [mailto:furry13@gmail.com]
>
> > Sent: Thursday, October 5, 2023 12:43 PM
>
> > To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
>
> > Cc: v6ops@ietf.org
>
> > Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-dhcp-pd-per-device-02 -> SLAAC
>
> > is still the "MUST"
>
> >
>
> > On Thu, Oct 5, 2023 at 2:09 AM Vasilenko Eduard
>
> > <vasilenko.eduard=40huawei.com@dmarc.ietf.org> wrote:
>
> > > Section 7, second bullet. I strongly object "MUST" for SLAAC.
>
> > >
>
> > > "Client" may use 3 mechanisms to re-distribute the DHCP-PD prefix:
>
> > > 1. SLAAC
>
> > > 2. DHCP
>
> > > 3. Local algorithm (if VMs or Containers are local to the "client").
>
> >
>
> > It's not about  how the client distributes the addresses from the
>
> > delegate prefix, it's about what devices *downstream* support.
>
> > So to increase the applicability of the solution and support an
>
> > arbitrary device, SLAAC is needed.
>
> > In particular, currently even if a device supports DHCPv6 IA_NA for
>
> > address assignment, all implementations I'm aware of would require a
>
> > PIO with A=1 to form a 464xlat address. So even if *all* systems use
>
> > DHCPv6 IA_NA, you'd need  a SLAAC suitable prefix to make those
>
> > systems work in IPv6-only mode.
>
> >
>
> > > It is wrong that section 5 and section 7 restrict the use case to only the first
>
> > option.
>
> >
>
> > Quite the opposite, actually. The draft doesn't prescribe what the
>
> > client does with the prefix (wait for -03, we are making the text more
>
> > clear on that) - the client can do whatever it wants. The draft
>
> > doesn't say the client MUST use SLAAC. It only prescribes that the
>
> > server guarantees that the client can use SLAAC if it desires.
>
> > It would be unreasonable to restrict this solution to exclude devices
>
> > which need SLAAC (e.g. for 464XLAT) - that would limit the
>
> > applicability drastically for absolutely no reason.
>
> >
>
> > > On 9/30/2023 4:42 PM, Xipengxiao wrote:
>
> > >
>
> > > Hi Folks,
>
> > >
>
> > > This message initiates a WGLC for draft-ietf-v6ops-dhcp-pd-per-device-02.
>
> > The call will end on Oct 14, 2023.  Your opinion will be valued.
>
> > >
>
> > > Ron & XiPeng
>
> > >
>
> > >
>
> > >
>
> > > _______________________________________________
>
> > > v6ops mailing list
>
> > > v6ops@ietf.org
>
> > > https://www.ietf.org/mailman/listinfo/v6ops
>
> > > _______________________________________________
>
> > > v6ops mailing list
>
> > > v6ops@ietf.org
>
> > > https://www.ietf.org/mailman/listinfo/v6ops
>
> >
>
> >
>
> >
>
> > --
>
> > SY, Jen Linkova aka Furry
>
>

-- 
SY, Jen Linkova aka Furry