Re: [dhcwg] I-D Action: draft-shen-dhc-client-port-01.txt

[Andre Kostur <[e-mail]>]

A counterpoint for #1, I would argue that DHCPv4 does acknowledge the
possibility of chained relays.  (RFC 951, section 7.3 talking about
"If 'giaddr' is zero,....", would suggest that there are cases where
the GIADDR is non-zero.)  Granted, the DHCP server will reply back to
the original GIADDR, but by then this second relay which didn't modify
the GIADDR may now be sending from the standard DHCP port, resulting
in the destination port being determined to be the standard DHCP port
(used by the 2nd relay), not the non-standard DHCP port desired by the
first relay.

I would suggest that both forms of this option put in the desired port
number as the option's payload (2 octet, MSB first).

We have also seen a particular misbehaving load balancer fiddle with
the source port of DHCP packets as they passed by.  I'm not sure how
widely applicable this experience is... but it has been seen in the
wild.

On Fri, Jul 8, 2016 at 12:04 PM, Bernie Volz (volz) <[e-mail]> wrote:
> Hi:
>
>
>
> Some initial comments:
>
>
>
> 1.       For DHCPv4, the zero length option can work since there is no
> provision for relay chaining.
>
> 2.       For DHCPv6, the zero length option does NOT work since this
> provides no means for a case where Relay 1 uses port X which is sent to
> Relay 2 which uses port Y to send to the Server. The server can response to
> Relay 2 on port Y (since that is the incoming port), but there is no place
> for Relay 2 to have stored the port. You should go back and make this option
> a 2 octet option with the port number. The server would then see:
>
> Relay-Forw from Relay 2
>
>                 Relay Port Source Port option Y
>
>                 Relay-Message option
>
>                                 Relay-Forw from Relay 1
>
>                                                 Relay Port source Port
> option X
>
>                                                 Relay- Message Option
>
>                                                                 <client’s
> request>
>
>                 And all would work correctly as the Server would use the
> port Y from the outermost relay option, relay 2 would use the port X from
> the Relay 1 Relay-Forw.


-- 
Andre Kostur