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

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 22 Jul 2015 01:22:03 +0000 (UTC)

Hi,

My comments below in part on this draft and Fernando's earlier one seem to have been ignored again. 

The advice to consider RDNSS and DNSSL option values to be invalid if RA lifetime has expired is inconsistent with RFC4861's advice on the use of Router Lifetimes. A RA Lifetime of zero is valid, and should not cause options within the RA to be considered invalid - that is why they have their on lifetime values. Again quoting from RFC4861, 

"The Router Lifetime applies only to
                     the router's usefulness as a default router; it
                     does not apply to information contained in other
                     message fields or options. "

For example, RDNSS addresses could be link-local addresses, so the expiry of the default router information (specifically and only indicated by the Router Lifetime) would not impact the ability to use the on-link DNS resolvers. NUD and/or the DNS resolver's failure detection methods would determine if link-local addressed resolvers are still valid to send requests to.

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.

Regards,
Mark.

________________________________
From: Mark ZZZ Smith <[email-masked]>
To: Erik Kline <[email-masked]>; Ole Troan <[email-masked]> 
Cc: 6man Chairs <[email-masked]>; 6man WG <[email-masked]> 
Sent: Friday, 19 June 2015, 17:59
Subject: Re: 6MAN WG Adoption call : draft-jeong-6man-rdnss-rfc6106-bis

Hi,

I provided quite a bit of feedback on the draft Fernando wrote up about this, which doesn't seem to have been considered/included. For example, I don't think retaining a subset of DNSSL option values is the right thing to do because they're not providing information about alternative entities that provide or are expected to provide the equivalent service, unlike the RDNSS options.

https://www.ietf.org/mail-archive/web/ipv6/current/msg22436.html

A further thought I've had is that if the DNS resolver addresses are on-link, then NUD status can also be an indication of DNS resolver liveness.

I don't think the following should be followed.

--
Note:  An RDNSS address or a DNSSL domain name MUST be used only as

      long as both the RA router Lifetime (advertised by a Router
      Advertisement message [RFC4861]) and the corresponding option
      Lifetime have not expired.  The reason is that in the current
      network to which an IPv6 host is connected, the RDNSS may not be
      currently reachable, that the DNSSL domain name is not valid any
      more, or that these options do not provide service to the host's
      current address (e.g., due to network ingress filtering
      [RFC2827][RFC5358]).
--

It is quite valid that RA lifetimes are less than the lifetimes of the options in them - a RA router lifetime of zero means that the router issuing them is not to be used as a default router, but that doesn't mean that the RA options the RA is carrying are now invalid too (which is I think the fundamental reason why options have their own lifetimes, so option information is decoupled from the RA router lifetime). Here's what RFC4861 says about Router Lifetimes:

      Router Lifetime
                     16-bit unsigned integer.  The lifetime associated
                     with the default router in units of seconds.  The
                     field can contain values up to 65535 and receivers
                     should handle any value, while the sending rules in
                     Section 6 limit the lifetime to 9000 seconds.  A
                     Lifetime of 0 indicates that the router is not a
                     default router and SHOULD NOT appear on the default

Narten, et al.              Standards Track                    [Page 20]
RFC 4861               Neighbor Discovery in IPv6         September 2007

                     router list.  The Router Lifetime applies only to
                     the router's usefulness as a default router; it
                     does not apply to information contained in other
                     message fields or options.  Options that need time
                     limits for their information include their own
                     lifetime fields.

Regards,
Mark.

________________________________
From: Erik Kline <[email-masked]>
To: Ole Troan <[email-masked]> 
Cc: 6man Chairs <[email-masked]>; 6man WG <[email-masked]> 
Sent: Friday, 19 June 2015, 12:05
Subject: Re: 6MAN WG Adoption call : draft-jeong-6man-rdnss-rfc6106-bis

+1 to extending the lifetime, I suppose
-1 to obsoleting 6106

"""
Appendix B.  Changes from RFC 6106

   The lifetime's upper bound of 2 * MaxRtrAdvInterval was shown to lead
   to the expiry of these options on links with a relatively high rate
   of packet loss.  This revision relaxes the upper bound and sets a
   higher default value to avoid this problem.
"""

Why not just have a 2-pager that updates 6106 with some discussion of
lifetime changes?

On Tue, Jun 9, 2015 at 5:11 AM, Ole Troan <[email-masked]> wrote:
> This message starts a two week 6MAN Working Group Last Call on adopting:
>
>     Title           : IPv6 Router Advertisement Options for DNS Configuration
>     Authors     : J. Jeong, S. Park, L. Beloeil, S. Madanapalli
>     Filename   : draft-jeong-6man-rdnss-rfc6106-bis
>     Pages       : 18
>     Date          : 2015-05-09
>
>    http://datatracker.ietf.org/doc/draft-jeong-6man-rdnss-rfc6106-bis/
>
> as a working group item. Substantive comments and statements of support for adopting this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This adoption call will end on June 22nd, 2015.
>
> This document is intended to resolve the issues with RFC6106 documented in draft-gont-6man-slaac-dns-config-issues.
>
> Regards,
>
> Bob Hinden & Ole Trøan
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

> --------------------------------------------------------------------
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Ole Troan <[email-masked]>
Date: Wed, 22 Jul 2015 09:36:48 +0200

Mark,

> My comments below in part on this draft and Fernando's earlier one seem to have been ignored again.

it wasn’t our intention to ignore your comments. I don’t see them as blocking for adoption, and we wanted that done first.

> For example, RDNSS addresses could be link-local addresses, so the expiry of the default router information (specifically and only indicated by the Router Lifetime) would not impact the ability to…

let me try to answer the point on lifetime first.
I’m a little confused why you say the RDNSS lifetime is tied to the Router Lifetime, that certainly wasn’t the intention.

the RDNSS Lifetime text is:
                   The value of Lifetime SHOULD by
                   default be at least 3 * MaxRtrAdvInterval where
                   MaxRtrAdvInterval is the Maximum RA Interval defined
                   in [RFC4861].  A value of all one bits (0xffffffff)
                   represents infinity.  A value of zero means that the
                   RDNSS address MUST no longer be used.

the text states that the should be larger than lifetime > 3 RA advertisement interval.
that’s to ensure that a network that runs with very short lifetimes would survive even if a few RAs are lost.
that’s independent of those RAs having Router Lifetime of 0.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 22 Jul 2015 09:42:38 +0200

Mark,

I see the problem now. this text in 6106 states:

I can understand the reasoning behind putting that text in there, but I agree with you that it is too strong. I would suggest removing that paragraph and declare this an application (DNS) problem. the RDNSS list is not guaranteed to be reachable at any point in time.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 22 Jul 2015 09:48:59 +0200

Mark,

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

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?

cheers,
Ole

---

From: Mark Smith <[email-masked]>
Date: Wed, 22 Jul 2015 17:50:20 +1000

Hi Ole,

> it wasn’t our intention to ignore your comments. I don’t see them as blocking for adoption, and we wanted that done first.

Ok. It is only that I've posted them a couple of times over the last
few months (once in feedback to Fernando's ID, once to this one) and
nothing in the draft seemed to have changed.

> that’s independent of those RAs having Router Lifetime of 0.

Here's the text that says Router Lifetime is a constraint on the
use/validity of the RDNSS and DNSSL option values:

"Note:  An RDNSS address or a DNSSL domain name MUST be used only as
      long as both the RA router Lifetime (advertised by a Router
      Advertisement message [RFC4861]) and the corresponding option
      Lifetime have not expired."

Regards,
Mark.

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 22 Jul 2015 11:35:31 +0200

Mark,
Here is a new text to address your first comments:

 Note:  An RDNSS address or a DNSSL domain name MUST be used only as
      long as both the RA router Lifetime (a positive lifetime value
      advertised by Router Lifetime field in a Router Advertisement
      message [RFC4861]) and the corresponding option
      Lifetime have not expired.  The reason is that in the current
      network to which an IPv6 host is connected, the RDNSS may not be
      currently reachable, that the DNSSL domain name is not valid any
      more, or that these options do not provide service to the host's
      current address (e.g., due to network ingress filtering
      [RFC2827][RFC5358]).
      However, Router Lifetime of 0 in a Router Advertisement message
      does not invalidate the RDNSS address or DNSSL domain name
      because the Router Lifetime applies only to the router’s
      usefulness as a default router and it does not apply to
      information contained in other message fields or options, such as
      RDNSS and DNSSL options [RFC4861].

Could you review this?

Thanks.

Paul

On Wed, Jul 22, 2015 at 9:50 AM, Mark Smith <[email-masked]> wrote:

> > it wasn’t our intention to ignore your comments. I don’t see them as
> blocking for adoption, and we wanted that done first.
>
> >> The advice to consider RDNSS and DNSSL option values to be invalid if
> RA lifetime has expired is inconsistent with RFC4861's advice on the use of
> Router Lifetimes. A RA Lifetime of zero is valid, and should not cause
> options within the RA to be considered invalid - that is why they have
> their on lifetime values. Again quoting from RFC4861,
> >>
> >> For example, RDNSS addresses could be link-local addresses, so the
> expiry of the default router information (specifically and only indicated
> by the Router Lifetime) would not impact the ability to use the on-link DNS
> resolvers. NUD and/or the DNS resolver's failure detection methods would
> determine if link-local addressed resolvers are still valid to send
> requests to.
> >
> > I’m a little confused why you say the RDNSS lifetime is tied to the
> Router Lifetime, that certainly wasn’t the intention.
> >
> > that’s to ensure that a network that runs with very short lifetimes
> would survive even if a few RAs are lost.

-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php

---

From: Mark Smith <[email-masked]>
Date: Wed, 22 Jul 2015 19:51:30 +1000

Hi Ole,

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

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.

---

From: Ole Troan <[email-masked]>
Date: Wed, 22 Jul 2015 13:24:12 +0200

Mark,

[…]

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

> DHCPv6 to convey DNS information to hosts that have no "off-link" via

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

> prefix's valid or preferred lifetimes.

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

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

cheers,
Ole

---

From: Mark Smith <[email-masked]>
Date: Thu, 23 Jul 2015 15:16:15 +1000

Hi Ole,

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

> my suggestion is to remove any text tying these lifetimes to the router lifetime.

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.

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

Yes.

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

---

From: Ole Troan <[email-masked]>
Date: Thu, 23 Jul 2015 19:00:31 +0200

Mark, et al:

looking more closely at the issues Mark has pointed out, I fear we have to fix a few more bugs than I originally intended.

possible set of changes:

Section 5.1:
OLD:
Lifetime      32-bit unsigned integer.  The maximum time, in
                   seconds (relative to the time the packet is sent),
                   over which this RDNSS address MAY be used for name
                   resolution.  Hosts MAY send a Router Solicitation to
                   ensure the RDNSS information is fresh before the
                   interval expires.  The value of Lifetime SHOULD by
                   default be at least 3 * MaxRtrAdvInterval where
                   MaxRtrAdvInterval is the Maximum RA Interval defined
                   in [RFC4861].  A value of all one bits (0xffffffff)
                   represents infinity.  A value of zero means that the
                   RDNSS address MUST no longer be used.

NEW:
Lifetime      32-bit unsigned integer.  The maximum time, in
                   seconds (relative to the time the packet is sent),
                   over which this RDNSS address MAY be used for name
                   resolution. The value of Lifetime SHOULD by
                   default be at least 3 * MaxRtrAdvInterval where
                   MaxRtrAdvInterval is the Maximum RA Interval defined
                   in [RFC4861].  A value of all one bits (0xffffffff)
                   represents infinity.  A value of zero means that the
                   RDNSS address MUST no longer be used.

Section 5.2
OLD:
NEW:
  <deleted paragraph>

Section 5.3.1
OLD:
   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.  As an
   exceptional case, if the received RDNSS addresses (or DNS search
   domain names) already exist in the IPv6 host, their Lifetime fields
   update their Expiration-time, that is, when the corresponding DNS
   information expires in the IPv6 host; note that when the Lifetime
   field has zero, the corresponding RDNSS (or DNS search domain name)
   is deleted from the IPv6 host.  Except for this update, the IPv6 host
   SHOULD ignore other RDNSS addresses (or DNS search domain names)
   within an RDNSS (or a DNSSL) option and/or additional RDNSS (or
   DNSSL) options within an RA.  Refer to Section 6 for the detailed
   procedure.  Note that the sufficient number is a system parameter, so
   it can be determined by a local policy.  Also, separate parameters
   can be specified for the sufficient number of RDNSS addresses and
   that of DNS search domain names, respectively.  In this document,
   three is RECOMMENDED as a sufficient number considering both the
   robust DNS query and the reasonably time-bounded recognition of the
   unreachability of DNS servers.

NEW:
   <deleted>
   (I tried making sense of this paragraph, I think the document would read better without it, but if someone can propose correct text that would be fine)

cheers,
Ole