Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-port-01.txt

["Bernie Volz (volz)" <[e-mail]>]

I understand the v4 case as there is no relay chaining. And, in that case just having the option is sufficient (port number is not needed). (If you want relay chaining in DHCPv4, it is much more complex and you have to have a place to store a bunch of information, such as original giaddr … and then you can also store port – there is no standard for this).

For DHCPv6, things are different and I think it is very bad (and as a WG “member” would not support this) to have one relay change another Relay-Forw’s packet (we used encapsulation of messages for a reason). While we have nothing that breaks today, that doesn’t mean it won’t in the future. And if a relay is adding the option already, it can stick the port number into it (rather than 0).

If you wanted to have the target relay store it for the return (if needed), you would then need two options. The sender of a non-standard port Relay-Forw includes an option (with no value) that just tells the next hop that a non-standard port is being used and that receiving relay that stores this into a new option in the Relay-Forw it adds. But again, this seems overly complex for non-benefit. Just have the SENDING relay store the port number in the Relay-Forw. Yes, this is different than DHCPv4, but so are a lot of other things different between v4 and v6. That’s life.

Note also that you’ve made the Relay processing for DHCPv6 much more complex for the forwarding towards server. By having the sender include the option with the port, there is NOTHING the receiver (next relay) needs to do. You only need to change the code for the sending path on the relay that wants to use a non-standard port and the Relay-Reply processing (to extract the option if present and use a different port). There’s no Relay-Forw processing that needs to change.


-          Bernie

From: Naiming Shen (naiming)
Sent: Wednesday, January 18, 2017 5:15 PM
To: Bernie Volz (volz) <[e-mail]>
Cc: dhcwg <[e-mail]>; Enke Chen (enkechen) <[e-mail]>
Subject: Re: I-D Action: draft-ietf-dhc-relay-port-01.txt


Move them to the front.

BV> OK, while you could implement it this way -- saying that the presence of the option in the Relay's packet (with a 0 value) is an indication that the port number is not the default and therefore the RECEIVER must insert it (replace the 0 value with the non-zero value based on the source port), I think this is NOT a good idea. I think the sender (that wants to response on the non-standard port) should be the one that adds the option with the correct port number. In DHCPv6, changing some other entities message is frown upon (hence why we encapsulate). And, I think it is simpler and less work for the receiver. There's also a security mechanism that the receiver can use to CONFIRM that the port is the indicated port.

For DHCPv6, because there is cascading relays. Otherwise, this is what we
agreed on for DHCPv4 UDP PORT option, and there is no local port number
needed. For v6 it has to if the ‘downstream’ relay uses a non-standard port.

Since I’ve done some implementation now, it is really straightforward to
get the UDP port number from the dhcp packet, since the ‘upstream’ has
already got the IP address of the source, which is even a lower layer in
the network stack.



BV> I guess the ONE benefit of doing it your way is that a server COULD detect if there are relays in the mix that don't support this, as when it copies the Relay-Forw's port option to the Relay-Reply, if the value is 0 it could report that the response will not get back to the client since a relay doesn't support the return path. But I don't see that benefit to be very large (since you already require that all entities must support this feature to use it).

For this to work, any ‘upstream’ device has to support that, but not further
besides the server side has to copy the option back. I can see a case:

client — relay1(1000)——relay2——relay3——server

in this case, relay1 uses a non-standard port, and relay2 has to support
this extension. But relay3 does not have to support that. Server has to
support that, since it copies the options back in relay-reply. When it
gets to relay2, which is really the place to use this option with a non-zero
port number in the options.