Re: recommendation on DHCP6 source port numbers

> It may be a violation.
> But I think the RFC text is not crystal clear on that.

Yes, I also think this is ambiguous.

Cheers,
Ole


> 
>> Isn't b) a violation of the RFC? If a client sends a message from
>> port 12345 to 547, then shouldn't the server send the message to
>> destination port 546, since the RFC says "clients listen for DHCP messages
>> on UDP port 546"?
>> 
>> On Thu, Feb 29, 2024 at 4:19 PM Tomoyuki Sahara <[email protected]> wrote:
>> 
>>> The clarification text should be helpful for new DHCP6 implementers
>>> and network operators who write firewall rules.
>>> 
>>> But when client/server received a request message from a random port,
>>> which port should they send a response message to?  There are two types
>>> of implementations on the market (and on my desk):
>>> 
>>>  (a) returns to 546/547.
>>>  (b) returns to the source port of the request message.
>>> 
>>> (a) follows the text in RFC8415 strictly.  (b) follows normal UDP
>>> communication rules.  To interoperaate with both (a) and (b), we should
>>> send request messages from the standard source port number 546/547.
>>> That is not obvious and I think it is worth mentioning that in the spec.
>>> 
>>> 
>>> Thanks,
>>> Tomoyuki
>>> 
>>>> Yes, I got it wrong. Been a while since that part of the code was done.
>>>> 
>>>> I agree with Lorenzo:
>>>> 
>>>> I do think the current text is ambiguous. In practice it allows
>>>> arbitrary source ports, but because this is unusual, implementers might
>>>> assume that the other side is using the same port to send and receive.
>>>> Such an implementation might not interoperate. So if we think the
>>>> behaviour is OK, then we should clarify the text to say that the source
>>>> port is not specified and clients and servers need to be prepared to
>>>> receive messages from arbitrary source ports.
>>>> 
>>>> We do allow arbitrary source ports and as there are lots if
>>> implementations
>>>> in existence with that behavior, we should just clarify it: "The source
>>>> port is not specified and clients, servers, and relay agents need to be
>>>> prepared to receive messages from arbitrary source ports."
>>>> 
>>>> - Bernie
>>>> 
>>>> On Feb 28, 2024, at 3:28 AM, Lorenzo Colitti <[email protected]> wrote:
>>>> 
>>>> FWIW the Android client binds to port 546 and does not connect() the
>>>> socket but uses sendto(). So it will send packets from port 546 and it
>>>> will receive any packet to port 546 regardless of the source port used
>>>> by the server. So I guess that happens to be correct.
>>>> 
>>>> Having the client send from 12345 -> 547 and the server send from 33333
>>>> -> 546 is sort of unusual - usually each party in a connection will use
>>>> the same source port for sending and receiving - but DHCPv6 is not a
>>>> connected protocol (e.g., some of the messages are multicast and some
>>>> are unicast), so...
>>>> 
>>>> I do think the current text is ambiguous. In practice it allows
>>>> arbitrary source ports, but because this is unusual, implementers might
>>>> assume that the other side is using the same port to send and receive.
>>>> Such an implementation might not interoperate. So if we think the
>>>> behaviour is OK, then we should clarify the text to say that the source
>>>> port is not specified and clients and servers need to be prepared to
>>>> receive messages from arbitrary source ports.
>>>> 
>>>> On Wed, Feb 28, 2024 at 4:47 PM Ole Troan
>>>> <[email protected]> wrote:
>>>> 
>>>> Bernie,
>>>> 
>>>>> No. Normal UDP communication rules apply. A client sends traffic
>>>> to a well-known destination port and it is free to select whatever
>>>> port number it likes as the source port. The server’s response is
>>>> sent from that well known port (as source port) and sent to the
>>>> client’s selected port (as destination port). This is normal
>>>> communication and dhcpv6 follows it. That is why nothing is said or
>>>> needs to be said about the client source port.
>>>> 
>>>> I’m with Tomoyuki here.
>>>> 
>>>> "
>>>> 7.2. UDP Ports
>>>> 
>>>> Clients listen for DHCP messages on UDP port 546. Servers and relay
>>>> agents listen for DHCP messages on UDP port 547.
>>>> 
>>>> “
>>>> 
>>>> Just checked my little scapy based DHCPv6 server and I do:
>>>> 
>>>>       reply = (Ether(src=self.interface_info.mac, dst=request
>>>> [Ether].src) /
>>>>                    IPv6(src=self.interface_info.ip6ll, dst=request
>>>> [IPv6].src) /
>>>>                    UDP(sport=547, dport=546) /
>>>>                    DHCP6_Reply(trid=trid) /
>>>>                    DHCP6OptServerId(duid=self.duid) /
>>>>                    DHCP6OptClientId(duid=clientduid) /
>>>>                    DHCP6OptIA_NA(iaid=request[DHCP6OptIA_NA].iaid,
>>>> T1=t1, T2=t2,
>>>>                                  ianaopts = DHCP6OptIAAddress
>>>> (addr=ipv6,
>>>> 
>>>> preflft=self.preflft,
>>>> 
>>>> validlft=self.validlft)
>>>>                    )
>>>> 
>>>> I couldn’t find any text supporting your position Bernie. Although
>>>> I would be fine if that was also the outcome.
>>>> As another implementor I cannot figure out what the correct
>>>> behaviour is from the RFC.
>>>> 
>>>> Cheers,
>>>> Ole
>>>> 
>>>>> - Bernie Volz
>>>>> 
>>>>>> On Feb 26, 2024, at 1:00 AM, Tomoyuki Sahara
>>>> <[email protected]> wrote:
>>>>>> 
>>>>>> Hi, DHC wg members:
>>>>>> 
>>>>>> Can we make recommendations on source port numbers of DHCP6
>>>> messages
>>>>>> in rfc8415bis?
>>>>>> 
>>>>>> DHCP6 specification says that DHCP6 clients and servers listen on
>>>> UDP
>>>>>> port 546 and 547 respectively, in RFC8415 section 7.2.  It
>>>> implies
>>>>>> that DHCP6 clients MUST send messages to UDP port 547 (server
>>>> port) and
>>>>>> servers MUST send messages to UDP port 546 (client port) to work
>>>> with
>>>>>> their counterpart correctly (though restrictions can be relaxed
>>>> with
>>>>>> RFC8357 for relays).
>>>>>> 
>>>>>> But it says nothing about source port numbers.  Without any
>>>>>> restrictions, some implementations use ephemeral source port
>>>>>> (e.g. 12345) to send their messages.  DHCP6 conversations look
>>>> like:
>>>>>> 
>>>>>> 1. client send Solicit    fe80::2#49876    -> ff02::1:2#547
>>>>>> 2. server send Advertise  fe80::1#547      -> fe80::2#546 (!)
>>>>>> 3. client send Request    fe80::2#49877(?) -> ff02::1:2#547
>>>>>> 4. server send Confirm    fe80::1#547      -> fe80::2#546
>>>>>> 
>>>>>> This behavior is not prohibited by the specification but makes
>>>>>> confusions for DHCP6 implementer and network/firewall operators
>>>> (*1).
>>>>>> Most Internet protocols nowadays assume that servers send
>>>> response
>>>>>> messages from the port number they received on.
>>>>>> (*1 e.g. https://bugzilla.redhat.com/show_bug.cgi?id=952126 )
>>>>>> 
>>>>>> In my humble opinion, it is too late to require that DHCP6 client
>>>> and
>>>>>> server MUST send messages from the fixed port number (546/547)
>>>> because
>>>>>> there are too many DHCP6 implementations in the wild.  But making
>>>> a
>>>>>> recommendation is helpful for new implementations/deployments of
>>>> DHCP6.
>>>>>> 
>>>>>> An idea to make such recommendation is adding a text in
>>>> rfc8415bis:
>>>>>> 
>>>>>> OLD:
>>>>>>  7.2. UDP Ports
>>>>>>    Clients listen for DHCP messages on UDP port 546.  Servers
>>>> and
>>>>>>    relay agents listen for DHCP messages on UDP port 547.
>>>>>> 
>>>>>> NEW:
>>>>>>  7.2. UDP Ports
>>>>>>    Clients listen for DHCP messages on UDP port 546.  Servers
>>>> and
>>>>>>    relay agents listen for DHCP messages on UDP port 547.
>>>>>> 
>>>>>>    Clients are RECOMMENDED to send DHCP messages from UDP port
>>>> 546.
>>>>>>    Servers and relay agents are RECOMMENDED to send DHCP
>>>> messages
>>>>>>    from UDP port 547 (unless relay agent includes Relay Source
>>>> Port
>>>>>>    Option for DHCP6 [RFC8357]).
>>>>>> 
>>>>>> I know WGLC has been concluded but I believe the recommendations
>>>> above
>>>>>> encourage new implementations to use the standard DHCP6 port
>>>> numbers
>>>>>> on UDP source port.
>>>>>> 
>>>>>> 
>>>>>> Best regards,
>>>>>> Tomoyuki Sahara
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> dhcwg mailing list
>>>>>> [email protected]
>>>>>> https://www.ietf.org/mailman/listinfo/dhcwg
>>>>> 
>>>>> _______________________________________________
>>>>> dhcwg mailing list
>>>>> [email protected]
>>>>> https://www.ietf.org/mailman/listinfo/dhcwg
>>>> 
>>>> _______________________________________________
>>>> dhcwg mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/dhcwg
>>> 


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