Re: [dhcwg] recommendation on DHCP6 source port numbers

[Lorenzo Colitti <[e-mail]>]

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 )
> >>
> >> 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
> >
> > _______________________________________________
> > dhcwg mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dhcwg
>
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>