Re: [dhcwg] recommendation on DHCP6 source port numbers

[Bernie Volz <[e-mail]>]

Server reply is sent to destination port 546. How would that confuse any other host?

And, IPv6 doesn’t have broadcast. Server always sends to client’s link-local address (or whatever source address it used).

- Bernie (from iPad)

> On Feb 29, 2024, at 10:22 AM, Ole Troan <[e-mail]> wrote:
> 
> Bernie,
> 
> Why isn’t this text relevant also for DHCPv6:
> 
>> We could not simply allow the client to pick a 'random' port
>> number for the UDP source port field; since the server reply may be
>> broadcast, a randomly chosen port number could confuse other hosts
>> that happened to be listening on that port.
> 
> 
> Cheers,
> Ole
> 
>> On 29 Feb 2024, at 15:56, Bernie Volz <[e-mail]> wrote:
>> 
>> This text seems a bit off. If the server always sends to the client port, its source port doesn’t matter.
>> 
>> I think this original text was because normal UDP communication could then happen and may have been because of limits in the APIs available at the time?
>> 
>> This is unnecessary today.
>> 
>> If you follow the rules, all is ok with whatever source ports are used:
>> 
>>     Clients listen for DHCP messages on UDP port 546.  Servers and
>>     relay agents listen for DHCP messages on UDP port 547.
>> 
>> I don’t know if the word “listen” in this is what causes confusion? Maybe it should just be:
>> 
>>     Clients receive DHCP messages on UDP (destination) port 546.  Servers and
>>     relay agents receive DHCP messages on UDP (destination) port 547.
>> 
>> But maybe even that is still confusing to some.
>> 
>> - Bernie
>> 
>>>> On Feb 29, 2024, at 9:16 AM, Ole Trøan <[e-mail]> wrote:
>>> 
>>> Guess we haven’t departed too far from bootp.
>>> Which seems to make a case for the client using the reserved port number also as the source port.
>>> 
>>> Rfc951:
>>> The UDP header contains source and destination port numbers. The
>>> BOOTP protocol uses two reserved port numbers, 'BOOTP client' (68)
>>> and 'BOOTP server' (67). The client sends requests using 'BOOTP
>>> server' as the destination port; this is usually a broadcast. The
>>> server sends replies using 'BOOTP client' as the destination port;
>>> depending on the kernel or driver facilities in the server, this may
>>> or may not be a broadcast (this is explained further in the section
>>> titled 'Chicken/Egg issues' below). The reason TWO reserved ports
>>> are used, is to avoid 'waking up' and scheduling the BOOTP server
>>> daemons, when a bootreply must be broadcast to a client. Since the
>>> server and other hosts won't be listening on the 'BOOTP client' port,
>>> any such incoming broadcasts will be filtered out at the kernel
>>> level. We could not simply allow the client to pick a 'random' port
>>> number for the UDP source port field; since the server reply may be
>>> broadcast, a randomly chosen port number could confuse other hosts
>>> that happened to be listening on that port.
>>> 
>>> 
>>> O.
>>> 
> 
>