Re: [dhcwg] recommendation on DHCP6 source port numbers

[Bernie Volz <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
> <otroan=[e-mail]> 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
> <tsahara=[e-mail]> 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" rel="noreferrer nofollow" target="_blank">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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dhcwg" rel="noreferrer nofollow" target="_blank">https://www.ietf.org/mailman/listinfo/dhcwg
> >
> > _______________________________________________
> > dhcwg mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dhcwg" rel="noreferrer nofollow" target="_blank">https://www.ietf.org/mailman/listinfo/dhcwg
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg" rel="noreferrer nofollow" target="_blank">https://www.ietf.org/mailman/listinfo/dhcwg