Re: recommendation on DHCP6 source port numbers

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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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.
>>> 
> 
> 

_______________________________________________
dhcwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dhcwg