Generalized UDP Source Port for DHCP Relay
draft-ietf-dhc-relay-port-10

Thanks for your time on this document. I have one minor correction and two questions.

The introduction says: "...for IPv6 the server port is (546) and the client port is (547)."  I believe this is backwards.

Section 5.2 says:

   If this option is included to
   indicate only the local non-DHCP UDP port usage and there is no
   downstream relay agent's non-DHCP UDP port usage, the field
   Downstream Source Port field MUST be set to zero.

Was the use of length=0 considered rather that port=0 here? The reason I ask is that UDP port 0 is *reserved*, but not technically *invalid*, and the use of "length=0" would distinguish between the flag usage and the port usage while not precluding the valid (if admittedly rare) use of port=0.

Finally, I have a question about DHCPv6 relay agent chains that arose in reading the document. The example section actually gives a pretty good jumping off point to ask the question, so I'll quote an excerpt here:

   Similar to the above example, now assume that Relay2 uses the UDP
   source port of 2000 instead of 547 as in the diagram.  The Relay3
   device needs to support this DHCP extension and it will set 2000 in
   its "Downstream Source Port" field of the option in the Relay-forward
   message.  When DHCP server sends the DHCP Relay-reply to Relay3,
   Relay3 finds its own relay option has this "Downstream Source Port"
   with the value of 2000.  Relay3 will use this UDP port when sending
   the Relay-reply message to Relay2.

If we were to continue this paragraph all the way back to Relay1, it's not clear how Relay2 would know to use port 1000 when sending its Relay-reply message to Relay1. Does this mechanism have a limitation that only one Relay Agent in the forwarding chain is allowed to use a Non-DHCP UDP Port?

Looking forward to hearing answer to Adam's last question.

Please have a look at the Gen-ART review, although I disagree with the reviewer's suggestion about replacing the reference to RFC 2119 with one to RFC 8174. If there is a desire to make usage of normative keywords clearer in this document, I would suggest replacing the two occurrences of lowercase "must" with "needs to."

Discussion seems to be moving in the right direction, so I have cleared my response. I've added it back as a comment for now:

<former-discuss>
(I want to "discuss" the following  DISCUSS point. If the answer is that this is by design, and the working group thinks that the operational aspects are reasonable, then I will clear.)

This extension places normative requirements on any upstream server or relay, which may or may not implement this spec.  It further appears that if you try to use this extension without that support, things will break. That seems to require at least an update to the DCHP and DCHPv6 RFCs[1], and some method of discovery or fallback would be helpful. Section 5.4 discusses this a little bit, but I think it needs to talk about what to do when things fail. "Turn off the feature if you don't get DHCP responses" doesn't seem satisfying.

[1] I see 3.1 and 3.2 make changes to 2131 and 3315, so it seems an "UPDATES... " tag is needed one way or another.

</former-discuss>


-1, last paragraph: It seems like the 2119 keywords here would be better placed in the later sections about relay and server behavior. I suggest moving them there, and making the introductory language non-normative.

- 3.1 and 3.2: I am surprised not to see 2119 keywords in the language added to 2131 and 3315:

-8: This spec adds the ability to direct dhcp responses to non-standard ports. If the working group believes that does not affect the security considerations, please describe the rational. (I'm not saying that I think there's a problem, but I think the burden is on the working group to explain why they think there is not.)

I really think this document should update RFC2131 and RFC3315 as it proposed concrete changes to both RFCs. The point is that, while the use of the described mechanism and options is optional, I think the updates of the texts apply more generally.

Further, I would think that if a DHCP server now has to listen on all ports for incoming traffic, that this would raise additional security considerations. However, didn’t think enough about it to name a specific threat.

I am watching the discussion about whether the same port is used to send and receive these messages on Ben's (previous) Discuss (now a No-Objection).