Re: 6MAN WG Adoption call : draft-jeong-6man-rdnss-rfc6106-bis

[Ole Troan <[e-mail]>]

Mark,

[…]

>> greatly appreciated if you could contribute new text. is this limited to section 5.3.1?
>> 
> 
> So I actually haven't read this draft in detail, and the reason I
> haven't is that I have read Fernando's draft in detail and provided
> detailed feedback on it, which is the link I provided earlier. I'd
> prefer to see the changes described in Fernando's draft and my
> comments to show up in this draft first (if they're valid of course).
> 
> "Current issues with DNS Configuration Options for SLAAC"
> https://tools.ietf.org/html/draft-gont-6man-slaac-dns-config-issues-01
> 
> My feedback on -00 of that, which mostly but I don't think completely
> was incorporated into -01 e.g. it still says that it is ok to ignore
> some of the DNSSL options.
> 
> https://www.ietf.org/mail-archive/web/ipv6/current/msg22436.html

with regards to DNSSL options. my personal view of these is that I’m uncomfortable with search lists in general, I expect that there is no scenario where their use will lead to unintended consequences. and that I expect them both to be filtered on the borders of a network and on hosts.

with that would a fix to 5.3.1 suffice?

the working group has chosen to make the minimal changes required to fix the issues identified by draft-gont-6man-slaac-dns-config-issues.

> I think there needs to be a bit more general thinking and
> clarification about the various cases that the current RFC/Draft
> doesn't cover or cover well e.g.
> 
> - RA lifetime of zero, RDNSS/DNSSL with non-zero lifetimes scenario,
> where the RA is effectively being used as a substitute for stateless
> DHCPv6 to convey DNS information to hosts that have no "off-link" via
> a default router.

my suggestion is to remove any text tying these lifetimes to the router lifetime.
are you OK with that?

> - RDNSS addresses are link-local or on-link addresses case, where DNS
> resolver address availability would be completely independent of
> advertising router RA lifetime, so the RDNSS/DNSSL lifetimes for these
> link-local/on-link addresses should probably be set to values that are
> not derived at all from the RA lifetime. For link-locals, it would
> probably be set to a reasonable static default, where as for on-link
> addresses is could be set to or derived from the corresponding
> prefix's valid or preferred lifetimes.

with the removal of the coupling above, would that suffice?

> - Whether two or more routers advertising the same RDNSS addresses or
> same DNSSL values with different lifetimes is an error, and if not,
> which lifetime to use i.e., the lowest or highest. (RFC4861 says for
> routers to perform consistency checks on each other's RA PIO lifetimes
> for the same prefix, and I wonder if this sort of consistency checking
> would be useful or necessary for these options.)

I hope the current text in 4861 is sufficient.
this would probably lead the clients to update their lifetimes / RDNSS lists with the last received RA. just like what happens with other inconsistencies.

> There may be other cases I haven't thought of.
> 
> I think this needs a bit more than just tweaking, and perhaps these
> sorts of RA option issues haven't been encountered before because RA
> options haven't been used for upper layer service/application
> configuration before - all other options conveyed in RAs are emitted
> by the devices operating at the same layer i.e., layer 3 routers are
> conveying layer 3 parameters via RA options. DHCPv6 on the other hand
> is an end-to-end protocol because it is riding over the top of UDP.

cheers,
Ole