Re: [dhcwg] recommendation on DHCP6 source port numbers

[Ole Troan <[e-mail]>]

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