Subject: draft-ietf-add-dnr: ordered list of options

From: <[email-masked]>
Date: Wed, 23 Mar 2022 08:27:20 +0000

Hi all,

We are developing a solution in ADD WG for the discovery of network encrypted resolvers: draft-ietf-add-dnr.

The document includes an RA option for which we tried to reuse as much from RFC8106. However, we have a doubt about this part of RFC8106:

   If there is DNS
   information available from multiple RAs and/or from DHCP, the host
   MUST maintain an ordered list of this information as specified in
   Section 5.3.1.

We initially interpreted that text as it also covers ordering options, and hence this text in draft-ietf-add-dnr:

   Multiple Encrypted DNS options may be returned to an IPv6 host.

   Similar to [RFC8106], these options are ordered in the preference for

   use by the IPv6 host.

We do appreciate if you can share your feedback on the following:

  *   Is our interpretation of the intent in 8106 accurate?
  *   Is there any reason why an explicit preference was not used in RFC8106?
  *   Do your recommend to model the RA option to also include an explicit preference field (as we are doing for DHCP)?

Thank you.

Cheers,
Med

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 23 Mar 2022 12:32:09 -0400

Apologies for the broken threading; I am off-list.

One clarification on this topic: RFC 4861 Section 9 says

   Options in Neighbor Discovery packets can appear in any order;
   receivers MUST be prepared to process them independently of their
   order.

and

   The semantics of an option should depend only on the
   information in the fixed part of the ND packet and on the
   information contained in the option itself.

This seems to contradict the quoted text from RFC 8106, and we are trying
to figure out which guidance applies.

--Ben Schwartz