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

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

Andre:

Yes, I would agree. Far better to specify the port :).

Yeah, firewalls or NAT[P] boxes between the relays/servers could create
issues. Probably something that should be indicated in the draft that it
may not work well with NAT[P] boxes between relays or the servers (also
perhaps those boxes may drop the packets as not considering them valid
DHCP packets). Probably a minor issue as most likely that part of an
operators network would not use NAT[P], but worth just mentioning.

- Bernie

On 7/8/16, 3:17 PM, "Andre Kostur" <[e-mail]> wrote:

>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