Subject: [dhcwg] Client Port Option?

From: Shane Kerr <[email-masked]>
Date: Tue, 13 Nov 2007 12:59:28 +0100

All,

I think it might be useful for DHCP clients to use a different port, other than
68/546.

One use case is when someone wants to run multiple clients on a single
interface. It is possible to write a client that request multiple addresses now,
but running separate clients has some benefits: clients that only manage a
single lease are simpler, and many existing clients could be easily changed to
bind to a different port and add a new option. Plus you get a (small) degree of
fault isolation with separate clients.

Another use case is for testing and debugging. Administrators could use
DHCPLEASEQUERY (or maybe DHCPINFORM) to learn about their network, but since
answers go to reserved ports, the uses are slightly limited. Plus it is much
easier to simulate a set of clients if you can run them all on a single box.

If this is not considered generally useful I might just make it an ISC vendor
option (for our own testing), but I think it could have wider application.

Please let me know what you think!

- --
Shane

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

---

From: Shane Kerr <[email-masked]>
Date: Tue, 13 Nov 2007 13:02:27 +0100

> I think it might be useful for DHCP clients to use a different port, other than

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.

I know some DHCP servers would drop the queries, and there are firewalling
issues, but these can be addressed in the long term.

- --
Shane

---

From: Bud Millwood <[email-masked]>
Date: Tue, 13 Nov 2007 13:43:42 +0100

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

- Bud

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Nov 2007 09:05:57 -0700

> Hm... I just realized that I didn't explain the actual proposal. :(

Okay, it makes a lot more sense now.

> issues, but these can be addressed in the long term.

My main concern would be relay agents not handling it correctly.

My other concern is that on a practical level, it's not the case that
DHCP servers will respond incorrectly; rather, they will respond to the
standard port if they don't implement the option.   So I don't see any
way to reliably get the behavior you are hoping for; that is, I don't
see what good it would do.

In the case of something like leasequery, it seems like you'd need to
*inquire* whether the server would do port return, but expect the answer
to come to the usual port.   And then, if the answer was in the
affirmative, you could just send your unicast packets from a different
source port, with the same flag, and the server could answer to that
port.

This seems like it would have utility for things like DHCPINFORM and
DHCPLEASEQUERY, but not so much for regular DHCP action.   I'm also not
sure how broad the use for this would be outside of debugging - clearly
it's useful for debugging to be able to do DHCPLEASEQUERY from a
separate process on a machine that got its address using DHCP, but would
it ever happen in a real deployment?

So I guess I'm interested, but lukewarm, on the idea... :')

---

From: Shane Kerr <[email-masked]>
Date: Tue, 13 Nov 2007 18:47:35 +0100

> being the obvious choice). That way you can skip the need for a client 

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.

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.

Actually, in this case a 1-byte option saying "don't send to port 68" might be
useful (0-byte in DHCPv6). That will prevent extra packets in the case where a
retransmission is required due to lost packets or busy servers.

- --
Shane

---

From: Bud Millwood <[email-masked]>
Date: Tue, 13 Nov 2007 23:39:50 +0100

On Tuesday 13 November 2007 18:47, Shane Kerr wrote:
> > 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.

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

- Bud

Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687

---

From: Shane Kerr <[email-masked]>
Date: Wed, 14 Nov 2007 15:02:42 +0100

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

> port instead? That way you can transmit from as many source ports as you 

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

---

From: Bud Millwood <[email-masked]>
Date: Wed, 14 Nov 2007 14:44:08 +0100

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

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

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