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

[Mark Smith <[e-mail]>]

Hi Ole,

On 22 July 2015 at 17:48, Ole Troan <[e-mail]> wrote:
> Mark,
>
>> There is also a problem with only using a subset of DNSSL options because they won't convey the equivalent service/values unless multiple DNSSL options have exactly the same values, unlike (in theory) RDNSS values.
>>
>> For example, 3 x DNSSL of example.com, example.org and example.net, if the host ignores example.net DNSSL, then any relative lookups for hostnames within example.net that don't exist in example.com or example.org will be looked up in root, and perhaps resolve unexpectedly if they're for one of the new vanity GTLDs.
>>
>> In other words, a host should remember completely the set of unique DNSSL values it receives, because they're each expressing something different. The set of unique DNSSL values are not equivalents, so none of them should be ignored.
>
> agree.
> it does indeed seem wrong that a host should have a "sufficient number" of DNSSLs.
> e.g. this text treating RDNSS and DNSSL the same:
>
>    When the IPv6 host has gathered a sufficient number (e.g., three) of
>    RDNSS addresses (or DNS search domain names), it SHOULD maintain
>    RDNSS addresses (or DNS search domain names) by the sufficient number
>    such that the latest received RDNSS or DNSSL is more preferred to the
>    old ones; that is, when the number of RDNSS addresses (or DNS search
>    domain names) is already the sufficient number, the new one replaces
>    the old one that will expire first in terms of Lifetime.
>
> 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

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.

- 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.

- 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.)

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.


Regards,
Mark.


> cheers,
> Ole
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>