Re: recommendation on DHCP6 source port numbers

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

>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