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

[Mark Smith <[e-mail]>]

Hi Ole,

On 22 July 2015 at 21:24, Ole Troan <[e-mail]> wrote:
> 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.

I can see some value in search lists, because they allow people to
just type the local host name within the local network rather than
always having to provide the fully qualified domain name. That is
convenient.


> and that I expect them both to be filtered on the borders of a network and on hosts.
>

In my experience it has been fairly common for ISPs to advise their
customers to use the ISP's domain name as their domain name. I suspect
it is partly because it sounds right, rather than making it convenient
for customers to just be able to type "www" to get to their ISP's
website.

In the past, that meant that every FQDN request was first searched for
in the ISPs domain e.g., a lookup for www.ietf.org.ispdomain.com
before www.ietf.org was looked up in the root, adding an additional
DNS lookup and commonly . Going by the manual page for resolve.conf on
this Linux host, resolvers are smarter now, and do an absolute query
if there is a specified number of dots in the query, with the default
here being 1.

> with that would a fix to 5.3.1 suffice?
>

I think so. For people who want to use them (and know how they work),
all of the search domains supplied via the DNSSL options should be
added to the DNS search list.

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

Yes.

I think these options' lifetime values also need to always be greater
than the unsolicited multicast RA interval, to ensure they don't age
out before they're refreshed.

The draft suggests a host could send an (multicast) RS to initiate a
refresh, however that would increase multicast traffic on the link,
and I think that would be better to be avoided.

I think these RA options would be simpler than using DHCPv6 for DNS
and search domain information if all it took was piggybacking them on
the existing RAs and RSes that routers and hosts are already going to
send. However, if extra messages are necessary, then I think the
simplicity has gone, as mechanisms that are already in DHCPv6 are now
being duplicated, and therefore DHCPv6 would be better to use.


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

Yes.

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

RFC4861 makes a general statement that routers should be checking each
other's RA contents consistency, and should be logging messages about
inconsistency. It then specifies a minimum of things to check. In
other words, it is saying that consistency should be checked, but not
that literally everything in the RAs must be exactly the same (e.g.,
it specifically says that not all RAs need to contain the same set of
PIOs).

As errors with these specific options are more likely to cause faults
that will be visible to the receiving devices' end-users, I think it
would be useful to clarify whether or not any consistency checking or
validation is to be performed.

> this would probably lead the clients to update their lifetimes / RDNSS lists with the last received RA. just like what happens with other inconsistencies.
>

Yes.

Regards,
Mark.


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