Subject: [dhcwg] Fwd: RFC 8415 question: unicast Information-request

From: Felix Hamme <[email-masked]>
Date: Sat, 29 Aug 2020 11:55:16 +0200

Dear DHCPv6 experts,

does RFC8415 permit Information-request messages with an IPv6 unicast
destination address?

Section 16 states:
"A server MUST discard any Solicit, Confirm, Rebind, or
Information-request messages it receives with a Layer 3 unicast
destination address."
(unicast Information-request forbidden)

Section 18.2 states:
"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."
(unicast Information-request not mentioned)

Section 18.4 states:
"For example, unicast transmission is not allowed for Solicit, Confirm,
and Rebind messages (see Sections 18.3.1, 18.3.3, and 18.3.5,
respectively), even if the Server Unicast option (see Section 21.12) is
configured. For Request, Renew, Information-request, Release, and
Decline messages, it is allowed only if the Server Unicast option is
configured."
(unicast Information-request allowed if a Server Unicast option was
received)

Appendix B ("informational") does not permit a Server Unicast option in
a Reconfigure message.

I am not sure how to interpret those statements in total.

When sending an Information-request message in response to a Reconfigure
message, a client needs to include a Server Identifier option (see
section 18.2.6) to address a specific server. It appears reasonable to
me to permit a Server Unicast option in a Reconfigure message so that a
client can respond with an Information-request message with an unicast
destination address.

What if the Information-request message is sent after a
Solicit-Advertise-Request-Reply message exchange, in which the server
sent a Server Unicast option? May a client unicast Information-request
messages in that case?

Sincerely,
Felix Hamme

---

From: Ted Lemon <[email-masked]>
Date: Sat, 29 Aug 2020 09:11:56 -0400

The client can unicast if the server tells it to, using the Server Unicast option. The reason for this is to make sure that all DHCP packets transit the same infrastructure: if a client unicasts a packet to the server, it can reach the server via IP routing rather than DHCP relay, and may miss some information that needs to be collected about the network on the way to the server.

> On Aug 29, 2020, at 5:55 AM, Felix Hamme <[email-masked]> wrote:
> 
> Dear DHCPv6 experts,
> 
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Felix Hamme <[email-masked]>
Date: Sun, 30 Aug 2020 10:14:59 +0200

But does this apply to Information-request messages? Is a server allowed
to include a Server Unicast option in a Reconfigure message when it also
includes a Reconfigure Message option with msg-type 11 for
Information-request message?
Does a Server Unicast option in a Reply message allow a client to send
subsequent Information-request messages to the unicast address of the
server?

---

From: Ted Lemon <[email-masked]>
Date: Sun, 30 Aug 2020 09:50:33 -0400

Yes. That’s the reason we did this. We want a client that does an information request to get the same answer as a client that asks for an address. 

> On Aug 30, 2020, at 04:15, Felix Hamme <[email-masked]> wrote:
>