Re: [dhcwg] recommendation on DHCP6 source port numbers

[Bernie Volz <[e-mail]>]

DHCPv6 has been successfully deployed and this is the first I recall of this kind of discussion/issue.

You would likely also invalidate a lot of implementations with such a change, which is not really in line with advancing this to Full Standard.

- Bernie (from iPad)

> On Feb 29, 2024, at 10:33 AM, Ole Troan <[e-mail]> wrote:
> 
> 
>> 
>> Server reply is sent to destination port 546. How would that confuse any other host?
> 
> I don’t think that’s obvious in RFC8415.
> If a client sends from a random port number, it would typically listen on that port, and the server could very well send to that port.
> That’s the ambiguity.
> In my view the specification should be clarified, and I think I prefer to state that only ports 546 and 547 are used. Both for source and destination port. That makes it easier to filter and is also consistent with how you expect UDP to look like on the wire.
> 
>> And, IPv6 doesn’t have broadcast. Server always sends to client’s link-local address (or whatever source address it used).
> 
> Yes, the use of link-local in the reply removes that.
> (IPv6 multicast is in most cases indistinguishable from broadcast :-))
> 
> Cheers,
> Ole
> 
> 
> 
>> 
>> - 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.
>>>>> 
>>> 
>>> 
>> 
> 
>