Subject: [dhcwg] A late review of draft-ietf-dhc-slap-quadrant-09

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 8 Jun 2020 15:10:44 +0200

Hi,
I was requested by IANA to do an expert review of dhc-slap-quadrant-09.
I did as requested and in the process I have reviewed the whole draft.
It's a bit late for editorial changes, but I was not able to dedicate
any time sooner. Sorry for that.

The proposed changes are mostly editorial in nature, except the one
about what the client should do if receives an address from different
quadrant than requested.

Abstract: "A new DHCPv6 option (OPTION_SLAP_QUAD, or QUAD)". Please pick
one name that you want to use for the option and stick with it. Using
alternate names is confusing. I'd prefer to not mention
OPTION_SLAP_QUAD, because that the constant representing a specific
value. The abstract should convey general idea, not the implementation
details.

Section 4.1, bullet 2: "The server, upon receiving an IA_LL option,
inspects its contents. [...] If suitable addresses are found, the server
sends back an Advertise message". This is imprecise. It can easily be
misunderstood as "if there's IA_LL option, always send Advertise,
regardless of if the client sent Solicit, Request or Renew.
This must be rephrased. I suggest something like "The server, upon
receiving an IA_LL option in Solicit, inspects its contents.".

Section 4.1, bullet 5: "When the assigned addresses are about to expire,
the client sends a Renew message." This is usually not true. The client
sends Renew after T1, which usually (as recommended by RFC8415) is set
to 50% of a valid lifetime.

Section 4.1, bullet 6: " 6.  The server responds with a Reply message,
including an LLADDR option with extended lifetime." This can easily be
misinterpreted as "the server sends LLADD as a top-level option in
Reply". This is not true. The LLADDR option is always supposed to be
sent in IA_LL.

"The client SHOULD check if the received MAC address comes from one of
the requested quadrants.  Otherwise, the client SHOULD NOT configure
the obtained address." What if the relay inserted a different an option
asking for a different quadrant and the server's policy used that?
Client following the text as written would drop the option and will not
used the LL address assigned. So how exactly the server policy would
work if anything the client didn't request would be dropped? The policy
could only possible rearrange order of quadrants that the client said is
willing to accept.

I don't particularly like that. There are many mechanisms in DHCPv6
where the client sends some options as hints or suggestions, but it's
not really a negotiation. The server knows best. Would you be willing to
change that, so the client always accepts what the server had said?

If you want the client to pick a different server, you can do so when
evaluating received Advertises. The text as written allows the client
to change his mind when Reply is received.

Section 4.2, bullet 2: "if a client sends multiple instances of the
IA_LL option in the same message, the DHCP relay MUST only add a single
instance of the QUAD option." What if the relay supports this draft,
but isn't configured to insert specific value?

Section 4.2, bullet 9: The same issue as 4.1, bullet 5 (sends renew
when address about to expire).

Section 5.1 "If the server cannot provide an assignment from one of the
specified quadrant-n fields, it MUST NOT assign any addresses and return
a status of NoQuadAvail (IANA-2) in the IA_LL Option." from one => from any.

I support the draft moving forward and I'll pass a note to IANA about my
positive expert review for the option format.

Tomek

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Mon, 8 Jun 2020 15:31:12 +0200

Hi Tomek,

Thanks for your review. I quickly went through your comments and I think I
mostly agree, but I'll come back to you with my responses to each of your
comments in the following days.

Thanks,

Carlos

On Mon, Jun 8, 2020 at 3:11 PM Tomek Mrugalski <[email-masked]>
wrote:

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>