Re: [dhcwg] Client Port Option?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bud Millwood wrote:
> On Tuesday 13 November 2007 18:47, Shane Kerr wrote:
>> Bud Millwood wrote:
>>> On Tuesday 13 November 2007 13:02, Shane Kerr wrote:
>>>> Shane Kerr wrote:
>>>>> I think it might be useful for DHCP clients to use a different port,
>>>>> other than 68/546.
>>>> Hm... I just realized that I didn't explain the actual proposal. :(
>>>>
>>>> The idea is that if clients did want to use a different port, they would
>>>> include an option with the port number when the sent a packet.
>>> We respond to whatever the source port was *by default*, and allow an
>>> administrative override that forces responses to a particular dest port
>>> (68 being the obvious choice). That way you can skip the need for a
>>> client option.
>> Interesting to hear that you do this by default. IMHO this should have been
>> the defined behavior all along. I wonder why this wasn't corrected, at
>> least for DHCPv6?
>>
>> I can't think of a way to change this in the protocol without potential
>> pain. Still, maybe a hack is possible. Something like:
>>
>> - Send the first reply to the UDP port in the packet.
>> - If a retransmission is detected, send the reply to port 68 and the UDP
>> port in the packet.
> 
> If the client used src port N, why would it not expect a reply on that same 
> port? It seems to me that a client that's straddling two ports - 68 for 
> inbound and something else for outbound - is already on thin ice.

Well, I agree, but happens to be the thin ice that the protocol defines as okay. :)

I think that RFC 2131 is the only place where this is defined:

   DHCP uses UDP as its transport protocol.  DHCP messages from a client
   to a server are sent to the 'DHCP server' port (67), and DHCP
   messages from a server to a client are sent to the 'DHCP client' port
   (68). A server with multiple network address (e.g., a multi-homed
   host) MAY use any of its network addresses in outgoing DHCP messages.

>> This will cause extra packets and delay, but mostly for clients that send
>> from a port other than 68 and expect a reply on port 68.
> 
> Do you know of any clients that do this, or is this just debug code? And if 
> it's debug code, why not allow the server to respond to the client's source 
> port instead? That way you can transmit from as many source ports as you 
> want.

I don't know of any clients that send from a port other than 68 and expect a
reply on port 68. But if there are any, then they are following RFC 2131, and if
we change the specification then they will break even though they do the right
thing according to the RFC.

I don't really know if there are clients that send from a port other than 68 at
all. I guess from the server point of view it is "almost safe" to send back to
the originating port. You have experience with this, since it is how your
software operates - have you seen any problems with this in the field? Does
anybody ever set the option to change from this behavior?

Thinking about it, the problem is tricker from a client point of view. Since
servers may have the address hard-coded in, a generic client cannot assume that
a port other than 68 will ever work. I can imagine how to do this from a
operational point of view (try it with your server) or maybe from a OS point of
view (use port 68 by default, and if you want to run multiple clients try it and
give appropriate error messages if it doesn't work). But from a protocol point
of view? No idea. :(

Maybe the best thing is just to set it as a non-standard option in our server...

- --
Shane
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHOv/+MsfZxBO4kbQRAgI1AJ9FruPv/3f+h4T40YPQ39ods9Q39ACglx/s
VcXOY08O73XAkMJTA2qzkQs=
=zaJA
-----END PGP SIGNATURE-----

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg