Re: [dhcwg] Client Port Option?

[Bud Millwood <[e-mail]>]

On Wednesday 14 November 2007 15:02, Shane Kerr wrote:

> 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?

Originally we simply transmitted back to the source port, and I seem to recall 
having someone report that it was not strictly compliant behavior. That was 
many years ago, and IIRC it was an engineer writing in-house debug code. I'm 
not aware of anyone that's asked how to configure the server to enforce 
strict dest-port compliance since then, and our default is still to transmit 
to the source port. So in practice, for us, it hasn't been an issue at all if 
you discount the original report.

There's always the possibility that a user has figured out how to enforce 
dest-port compliance without asking, though.

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

If you make it an option that defaults to the opposite of ours, your behavior 
doesn't change, but you get the same flexibility.

- Bud

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg