Re: recommendation on DHCP6 source port numbers

>  (b) sends response messages to the source port of the request message.

This server is broken and needs to follow the RFC.

Yes, you could fix this by changing client to send from 546 source port. But it is server that is broken and should be fixed.

And it is usually a lot easier to fix (& update) a few servers than lots of clients.

- Bernie (from iPad)

> On Feb 29, 2024, at 11:26 PM, Tomoyuki Sahara <[email protected]> wrote:
> 
> 
>> 
>> That would not solve anything for (b) clients.
> 
> Yes.  The recomendation is not for the existing clients but
> for new client implementations.
> 
> Consider 3 new DHCP6 client implementations:
> 
>  (C1) sends messages from 546 and receives messages on 546.
>  (C2) sends messages from 12345 (a random port) and receives messages
>      on 546.
>  (C3) sends messages from 12345 and receives messages on 12345.
> 
> and 2 existing DHCP6 servers on the market:
> 
>  (a) sends response messages to 546.
>  (b) sends response messages to the source port of the request message.
> 
> (C1) interoperates with both (a) and (b).
> (C2) interoperates with (a) but does not interoperate with (b).
> (C3) does not interoperate with (a) but interoperates with (b).
> 
> (C1) and (C2) follow the specification to listen on 546.  But (C2) does
> not interoperate with (b).  So, I have recommended (C1) - sending
> messages from the standard source port.
> 
> 
> Thanks,
> Tomoyuki
> 
>> Yes, that is correct - (a).
>> 
>> If a client does (b), it would never get any messages from server.
>> 
>> To interoperaate with both (a) and (b), we should
>> send request messages from the standard source port number 546/547.
>> 
>> That would not solve anything for (b) clients. The source port doesn’t
>> matter to them if they are waiting for traffic on another port.
>> 
>> - Bernie
>> 
>> On Feb 29, 2024, at 2:23 AM, Lorenzo Colitti <[email protected]> wrote:
>> 
>> 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