Re: [Add] I-D Action: draft-ietf-add-dnr-06.txt

[Ben Schwartz <[e-mail]>]

On Wed, Mar 23, 2022 at 5:06 AM tirumal reddy <[e-mail]> wrote:

> Hi Ben,
>
> Please see inline
>
> On Tue, 22 Mar 2022 at 17:47, Ben Schwartz <bemasc=
> [e-mail]> wrote:
>
>> As I noted in my previous review, this draft is in violation of the IPv6
>> RA forming requirements: (
>> https://www.rfc-editor.org/rfc/rfc4861#section-9):
>>
>>    Options in Neighbor Discovery packets can appear in any order;
>>    receivers MUST be prepared to process them independently of their
>>    order.
>>
>
>> By omitting the SvcPriority from the IPv6 RA option, this syntax becomes
>> order-reliant, which is not allowed.  (My proposed syntax revision would
>> avoid this problem.)
>>
>
> Our understanng is https://datatracker.ietf.org/doc/html/rfc8106 allows
> ordering of DNS information without an explicit preference field. We sent
> an mail to 6man WG to clarify whether our interpretation of RFC8106 is
> correct or not (please see
> https://mailarchive.ietf.org/arch/msg/ipv6/qeSwxWBoPTOs0fzyaSBzUC2g-sc/).
>

Thanks.  I've sent a followup mentioning RFC 4861.

I also note that this draft now says
>>
>>    AliasMode (Section 2.4.2 of [I-D.ietf-dnsop-svcb-https]) is not
>>    supported because such a mode will trigger additional Do53 queries
>>    while the data can be supplied directly by DHCP servers.
>>
>> I don't think we should impose this restriction.  As I noted in my
>> previous review, it is easy to identify deployments where additional Do53
>> queries would be highly preferable, instead of trying to distribute all of
>> this information via DHCP.  Do53 followup seems straightforward, since it
>> is exactly name-based DDR and is likely to be implemented in the same
>> codebase, but it could be made optional if this is a concern.
>>
>
> We intended to avoid the Do53 look-up to avoid the possibility of an
> external attack, additional lookup and relying on unencrypted DNS for
> bootstrapping. The same reasons for adding IP addresses to the DHCP option.
>

Yes, I think it's reasonable to prefer ServiceMode and specified IP
addresses.

However, I see your point that a deployment may want to move the complexity
> to the client. We can update the draft to replace "MUST NOT" with "SHOULD
> NOT" and add the reason for allowing AliasMode.
>

I'm not sure "SHOULD NOT" is appropriate (as I said, there are cases where
it is likely preferable).  Perhaps "SHOULD use ServiceMode if possible".
Regardless, note that this requires* including SvcPriority in the IPv6
Neighbor Discovery DNR Option.

*Unless you want to diverge further from the SVCB specification and do
something Very Clever.