прикольно

и?

Ну мне кажется  отклонять Юниаст странно, как может не совпасть server identifier
Кажется тут отсылка к mcast

так что если у руссо есть пкап с мультикастовым запросом ренью - это нормально, но клиент OUGHT TO (по RFC 6919) предпочесть юникаст, если это возможно

в принципе, несложно соорудить ситуацию, в которой и в в4 ренью будут посылаться бродкастом

мне кажется, тут отсылка к Anycast

достаточно жирная отсылка на мкаст как дефолт

ну или так

Но это не обьясняет )))8
Я не понял
A client uses multicast to reach all servers or an individual server.
  An individual server is indicated by specifying that server's DUID in
  a Server Identifier option (see Section 21.3) in the client's
  message.  (All servers will receive this message, but only the
  indicated server will respond.)  All servers are indicated when this
  option is not supplied.

  A client may send some messages directly to a server using unicast,
  as described in Section 21.12.
————
Типо на откуп реализаторам dhcpv6-клиента ?

18.4.  Reception of Unicast Messages

  Unless otherwise stated in the subsections of Section 18.3 that
  discuss the receipt of specific messages, the server is not supposed
  to accept unicast traffic when it is not explicitly configured to do
  so.  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.

Я вот про эту часть:
A client may send some messages directly to a server using unicast,

ну так там дальше ссылка на Server Unicast Option

а из нее ссылка на секцию 18

таки да, что юникаст по запросу

а в 18.2.  Client Behavior написано довольно конкретно: если сервер не возражает и  если клиент может, то лучше использовать юникаст