Re: [dhcwg] draft-ietf-dhc-relay-port-10 & Reconfigure

["Naiming Shen (naiming)" <[e-mail]>]

This change I think would be confusing, in the case the local relay and downstream
relay both have non-DHCP ports, that is the reason this field is name as “downstream”.

thanks.
- Naiming

On Feb 6, 2018, at 10:27 AM, Bernie Volz (volz) <[e-mail]<mailto:[e-mail]>> wrote:

Yes, as -10 is written it requires the server record that a non-standard port was in use.

This also has an impact to Failover protocol (RFC 8156) and Leasequery (RFC 5007), as there is no carrier defined for this data.

For our server, I’m thinking we’ll avoid adding yet something else to save this data and instead store it in the outermost (closet to server) Relay-Forw “Downsteam Source Port” field (which would normally have 0 in it). That way, it is also available to Leasequery (perhaps a bit non-standard but better than defining more options).

I still think it would be much better to change:

      Downstream Source Port:  16 bit value.  To be set by the IPv6
               relay either to the downstream relay agent's UDP source
               port used for the UDP packet, or to zero if only the
               local relay agent uses the non-DHCP UDP port (not 547).

To:


      Downstream Source Port:  16 bit value.  To be set by the IPv6

               relay either to the downstream relay agent's UDP source

               port used for the UDP packet, or to the port used by the

               local relay agent if it does not use port 547.



That way, the port value is already there.

For DHCPv4, I’m less concerned about this (mostly because almost no one uses ForceRenew with that). But even there it would be nice if the option just stored the port number.

If we’re concerned about security, you would always add: “A relay or server MAY validate that the port number in the option matches the source port on which the packet was received and discard the received message is not.”

-          Bernie

From: Naiming Shen (naiming)
Sent: Tuesday, February 06, 2018 12:43 PM
To: Bernie Volz (volz) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Suresh Krishnan <[e-mail]<mailto:[e-mail]>>
Subject: Re: draft-ietf-dhc-relay-port-10 & Reconfigure


Hi Bernie,

This can be a server implementation also, as long as the server saves the encapsulated
relay stack on the client’s record. My thinking is this, some other relay options may also needs
to be saved in order for Reconfigure message through the relays to work properly.

thanks.
- Naiming

On Feb 6, 2018, at 8:05 AM, Bernie Volz (volz) <[e-mail]<mailto:[e-mail]>> wrote:

One issue that sadly was not addressed in https://tools.ietf.org/html/draft-ietf-dhc-relay-port-10 is what to do about Reconfigure message. There are two ways to deliver Reconfigure messages:

1.       Via the relay
2.       Via unicast to the client

If #1 is used (perhaps because the client and server do not have direct communication because of VPNs or for other reasons), what should the server do? Options are:

1.       Always use the standard port (547).
2.       Record the relay port and use that (since the relay will also be used). I would assume that this would be the “correct” behavior?

I’m not sure if we should (or can) put a hold on RFC-to-be to add something about this?

BTW: This would also have been a good reason to put the port number into the option ALWAYS. This avoids the server from having to record something “else” (the port number), since the server can just extract the value from the outermost (closest to server) Relay Port option.

-          Bernie