Subject: [dhcwg] Adam Roach's No Objection on draft-ietf-dhc-relay-port-07: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Tue, 28 Nov 2017 17:30:32 -0800

Adam Roach has entered the following ballot position for
draft-ietf-dhc-relay-port-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-port/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Wed, 29 Nov 2017 02:00:12 +0000

Hi Adam,

Thanks for the comments, replies inline <NS> … </NS>

> On Nov 28, 2017, at 5:30 PM, Adam Roach <[email-masked]> wrote:
> 

Yes. Will fix.

> not precluding the valid (if admittedly rare) use of port=0.

Although it’s valid, but should not be used. Or here this draft saying an
alternative relay-port is a non-zero number. Will mention that.

> Agent in the forwarding chain is allowed to use a Non-DHCP UDP Port?

No, there is no limitation on how many relay-agents in the chain to use the Non-DHCP
UDP port.

The rule is that, a relay-agent needs to use this relay-port option either
this agent itself uses a Non-DHCP port, or it’s downstream agent uses
a Non-DHCP port.

So, in the above example quoted, 
- Relay1 will include the relay-port option in its relay-forward message
- Relay2 will include the relay-port option (also set the downstream port to 1000) in
  ins relay-forward message

when the relay-relay message comes to Relay2, it checks it’s own
relay-port option is included, and it gets the 1000 port number to use.
this is no different when Relay2 itself does not use a Non-DHCP port.

thanks.
- Naiming

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Wed, 29 Nov 2017 02:47:21 +0000

Just to add that, every relay-agent will add its ‘downstream’ non-dhcp port,
not its own non-dhcp port. So, relay2 sets relay1’s port, relay3 sets relay2’s
port, that how the upstream relay device know how to reach the downstream
relay non-dhcp port when relay the relay-reply message by looking at its own option.

thanks.
- Naiming

On Nov 28, 2017, at 6:00 PM, Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Adam,

On Nov 28, 2017, at 5:30 PM, Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:

Yes. Will fix.

Section 5.2 says:

thanks.
- Naiming

---

From: Adam Roach <[email-masked]>
Date: Wed, 29 Nov 2017 13:48:18 -0600

Naiming --

Thanks for your quick reply. I had to do a bit more reading about DHCP 
relay behavior to understand your response to my third point, but it all 
seems to make sense now. I appreciate your taking the time to clarify. 
It might be helpful to extend the final paragraph in the examples 
section to include getting the Relay-reply all the way back to Relay1.

Your answers for the other two points seem reasonable.

Thanks!

/a

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Wed, 29 Nov 2017 20:00:28 +0000

Hi Adam,

> On Nov 29, 2017, at 11:48 AM, Adam Roach <[email-masked]> wrote:
> 
> Naiming --
> 
> Thanks for your quick reply. I had to do a bit more reading about DHCP relay behavior to understand your response to my third point, but it all seems to make sense now. I appreciate your taking the time to clarify. It might be helpful to extend the final paragraph in the examples section to include getting the Relay-reply all the way back to Relay1.

Thanks. Yes, I just added a sentence to complete the whole thing in my updated
draft in 08.txt.

BTW, for the length=0 part, one more note:-)
I initially was going to do that, but when I implemented this draft in the
ISC DHCP code base, I found that the DHCPv6 option does not support
variable size structure;-) and I also searched for all the other v6 options,
none of them are variable sized; thus the choice to use fixed size and
make the ‘downstream port’ = 0 is the choice. just FYI.

thanks.
- Naiming