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

[Vasilenko Eduard <[e-mail]>]

Hi Jen,
> May I ask you to wait two days
No problem to wait.

If you put inside clear statements that other ways are possible too - it would be enough.
Even if you put inside additionally something like "because some OSes support only SLAAC then probably SLAAC would be the most popular mechanism for address sub-deligation". I am fine with that.
Currently draft misleads that this mechanism is compatible only with SLAAC.
Unfortunately, your e-mails are not attached to the draft.

Section 5 could be renamed to "the solution compatibility with the SLAAC sub-delegation".
It would better reflect the section's essence.
The section "The solution compatibility with the DHCPv6 sub-delegation" would be very welcome.
Ed/
> -----Original Message-----
> From: Jen Linkova [mailto:[e-mail]]
> Sent: Thursday, October 5, 2023 1:26 PM
> To: Vasilenko Eduard <[e-mail]>
> Cc: [e-mail]
> Subject: 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
> <[e-mail]> 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:[e-mail]]
> >
> > > Sent: Thursday, October 5, 2023 12:43 PM
> >
> > > To: Vasilenko Eduard <[e-mail]>
> >
> > > Cc: [e-mail]
> >
> > > 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=[e-mail]> 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
> >
> > > > [e-mail]
> >
> > > > https://www.ietf.org/mailman/listinfo/v6ops
> >
> > > > _______________________________________________
> >
> > > > v6ops mailing list
> >
> > > > [e-mail]
> >
> > > > https://www.ietf.org/mailman/listinfo/v6ops
> >
> > >
> >
> > >
> >
> > >
> >
> > > --
> >
> > > SY, Jen Linkova aka Furry
> >
> >
> 
> 
> 
> --
> SY, Jen Linkova aka Furry