Hello,
The original udhcpc6 code sent regular Renew and Release messages to
the DHCPv6 server as unicast. I know that not long ago, commit
ef21820dc9dd7520cc89469ef2b9d7387c7be78b ("udhcpc6: improvements")
added the -m option to always use multicast, and even added a comment
in Status Code option processing about the server sending UseMulticast
code:
+ if (status != 0) {
+//TODO: handle status == 5 (UseMulticast)?
+ /* return to init state */
In most of my testing, I found servers to be okay with unicast Renew
and Release, except for one that rejects them with UseMulticast status
code. I even added code to detect this, resend the Renew with
multicast, and save a flag to use multicast for future communications,
as per rfc8415, sec. 18.2.10. And that works fine for that particular
network. (It was easy to modify send_d6_release for multicast
following the example of send_d6_renew). However, reading more of the
rfc8415 I see:
* sec. 18.2 "Client Behavior":
If the client has a source address of sufficient scope that can be
used by the server as a return address and the client has received a
Server Unicast option (see Section 21.12) from the server, the client
SHOULD unicast any Request, Renew, Release, and Decline messages to
the server.
* sec. 18.4 "Reception of Unicast Messages" (by the server):
For Request, Renew,
Information-request, Release, and Decline messages, it is allowed
only if the Server Unicast option is configured.
When the server receives a message via unicast from a client to which
the server has not sent a Server Unicast option (or is not currently
configured to do so), the server discards that message and responds
with an Advertise (when responding to a Solicit message) or Reply
message (when responding to any other messages) containing a Status
Code option (see Section 21.13) with the value UseMulticast, a Server
Identifier option (see Section 21.3) containing the server's DUID,
the Client Identifier option (see Section 21.2) from the client
message (if any), and no other options.
* sec 21.12 "Server Unicast Option":
The server sends this option to a client to indicate to the client
that it is allowed to unicast messages to the server.
Based on this, I think that we are just getting lucky that unicast is
being tolerated by these servers at all rather than always rejecting
the unicast Renew and Release. It feels like BusBox can be both more
RFC-compliant *and* reduce code by dropping the -m flag and always
using multicast. The wording describing Server Unicast option makes
it seem like unicast is optional ("SHOULD" rather than "MUST") so no
need to bother with Server Unicast at all.
Danomi -
_______________________________________________
busybox mailing list
[email protected]
https://lists.busybox.net/mailman/listinfo/busybox
