IPv6 Router Advertisement Option for DNS Configuration
RFC 5006

[Note]: 'Email on 12/7 to work with Jari and David on DISCUSS issues with this document. Still need to determine whether Experimental or Informational is the best route for this document. Author has indicated that he will be producing a version 11. Jari indicated that he will get to this after Prague IETF.' added by Amy Vezza

[Ballot comment]
There are MUST requirements in the section that's introduced as non-normative (section 6)

  An RDNSS MUST be used only as long as both the RA router lifetime and...

Confusing to me, perhaps this requirement comes from elsewhere that can be referenced?

[Ballot comment]
This is a very interesting experiment as it has the potential to speed up
initialization time when connecting to a network.

If this were a standards track candidate I'd want a guess of how many
other DHCP options should be considered as potential ND RA options for
enhanced performance and discuss if the amount of overlap creates an
architecture problem.

[Note]: 'Email on 12/7 to work with Jari and David on DISCUSS issues with this document. Still need to determine whether Experimental or Informational is the best route for this document. Author has indicated that he will be producing a version 11.

Jari indicated that he will get to this after Prague IETF.' added by Mark Townsley

[Note]: 'Email on 12/7 to work with Jari and David on DISCUSS issues with this document. Still need to determine whether Experimental or Informational is the best route for this document. Author has indicated that he will be producing a version 11.' added by Mark Townsley

[Note]: 'Email on 12/7 to work with Jari and David on DISCUSS issues with this document. Still need to determine whether Experimental or Informational is the best route for this document.' added by Mark Townsley

[Ballot discuss]
Applicability statement does not address where
the use of this mechanism is possible and useful.
The cited reason for using lifetimes is not
a valid reason. (More below.) Also, either the
applicability statement or an IESG note should
indicate that the standard IETF recommended
approach to DNS server discovery is DHCP.

This draft needs to address interoperability issues
raised by the use of different discovery mechanisms.
If the network in question supports RA-based scheme
and my client does only stateless DHCP, I can't get
access. I would suggest requiring the standard
mechanism be supported at least on the network
side always.

The use of RDNSSes from a previous link is probably
not a good idea in the future. Where this mechanism
is deployed, you would expect the new link to
provide new RDNSSes. Usage of previous RDNSSes may
have issues -- you would have to allow anyone to
access your RDNSSes, and I understand that there
has been attacks on them. It is much better to take
the new servers from the RA that you'll have to
see on the new link anyway. Or do stateless DHCP.

The draft proposes a different handling for
RA options than is done for all other
RA options right now, i.e., that their
applicability extends beyond a link.

Preference value mechanism may not fit
the DNS resolver model and is unlikely
to work across administrative domains.

COMMENT-part: See also review from Thomas
Narten, copied below:

------

Besides the general problem I have with multiple ways of doing the
same thing, this one does have impact on DNS resolvers. Specifically,
unlike the existing DHC option, it includes the notion of preferences,
where one is supposed to use the high-preference DNS servers over
those with lower precedence. AFAIK, this does not plug cleanly into
existing DNS resolver implementations. Is this something the DNS folk
should weigh in on?

2006-09-14 review of -09 (on agenda)

General:

This option seems to change how DNS resolvers manage their DNS server
addresses. Currently, today, AFAIK, resolvers have a single list (of
equal priorty) servers, and use their own algorithms to decide which
ones are working (and should be used). This option adds priorities to
DNS servers. It is unclear to me how existing resolvers will fold the
new semantics into their implementations. In any case, this option
would seem to go beyond what current RFC 3646 DHC options do (they
just communicate a list of equal priority DNS servers.)

There are details to the protocol/option I think should be changed
(see below).

I believe this option definition makes some changes relative to other
RA options in the way they are handled. I do not see any compelling
reason for such changes. (details Below.)

This is (I believe) the first RA option that is not specific to the
link to which the node is connected. This means that one may want to
continue using the learned information even when moving to another
link (this is a first for an RA option). It is unclear how this plays
into the ongoing DNA work. I actually think it is a mistake to
continue using the information when one goes to a new link, especially
when that new link provides new (and presumably better)
information. Right now, the  document seem to take an approach of
using the union of all learned information.

Preference values can only be (sensibly) compared in the same
administrative domain. It is unclear the right thing will happen when
a node moves to a new domain and the old preferences are higher, but
no longer work, or work poorly. This should be discussed. (Note: this
a well known problem, with no good solutions, discussed in the past in
the context of preferences associated with routers, when a host is
connected to multiple networks and gets RAs from routers in different
administrative domains.)


>>    mobile environments where the addresses of the RDNSSes are added or


RDNSS used with expansion/definition.

When one moves from one network to another, does the RDNSS
configuration learned from the old old point of attachment (POA) get
removed? Or does it rely only on timeout of the lifetime? How does
this tie into DNA, where when one moves, one removes all the config
information from the old POA. (This is partially clarified later in
the document, but could still be better.)


>>    remote RDNSSes.  Using the lifetime field differentiates the RA
>>    approach from the DHCPv6 approach in that it allows mobile nodes to
>>    use local RDNSSes rather than remote RDNSSes in order to reduce the
>>    DNS resolution delay [6]-[8].


I don't understand this comment. Why can't exactly the same be done
with DHCP?


>>    The preference field in the RDNSS option allows IPv6 hosts to select
>>    a primary RDNSS among several RDNSSes; this can be used for load
>>    balancing of RDNSSes.


Doesn't this conflict with the basic DNS approach of all servers being
equal?


>>                      indicates the highest preference.  A value of
>>                      zero means stop using this RDNSS.  The default


Why not use lifetime of zero for this instead? (That is what all the
other RA options do for explicitely signalling the expiration of
information).

(Later, lifetime of zero does mean expire. Given that, I'd say the
above should not have the special meaning of "expire". Its not helpful
to have multiple ways of doing the same thing.)


>>                      value of the preference is 8.  This default
>>                      value is used as boundary value for RDNSS
>>                      selection.  That is, a preference less than 8
>>                      means less preferred than default RDNSSes and a
>>                      preference greater than 8 means more preferred.


Is the above really saying that the default value to insert in one of
these options in outgoing RAs (unless explicitely configured to be
something else) is 8? If so, please just say so (i.e., this would seem
to have no implication for clients).



>>                      (Length - 1) / 2.  For the maximum number of
>>                      RDNSS addresses in one RDNSS option, at most
>>                      three is recommended since three RDNSSes are
>>                      enough for DNS resolution service.  See Section


this seems bogus. Why restrict to 3? What is magic about this number?


>>    Since one RDNSS option is recommended to have at most three RDNSSes,
>>    the router MAY send more than one RDNSS option if it would like to
>>    advertise more than three RDNSSes.


why? What technical justification is there for this? (I can think of
none).

Also, the MAY is useless, because later in the document clients are
encouraged to ignore entries after the 3rd one.


>>    o  If the RDNSS option is present, the host SHOULD copy the option's
>>      value into the DNS Server List and the Resolver Repository as long
>>      as the value of Length field is greater than or equal to the
>>      minimum value (0x03).  The host MAY ignore additional RDNSS
>>      addresses within an RDNSS option and/or additional RDNSS options
>>      within an RA when it has gathered a sufficient number of RDNSSes.
>>      It is expected that most implementations will use at least two or
>>      three RDNSSes, but few will use a fourth or subsequent RDNSS.


This description seems incomplete. What if there are multiple options,
with different priorities?


>>    An RDNSS may only be used as long as both the RA router lifetime and
>>    the RDNSS option lifetime have not expired.  In the case where there


Why this restriction? I believe this is the first time that an RA
option with a lifetime is also subject to the lifetime constraints of
the router lifetime. Why is this necessary or desirable?


>>    are not any more eligible RDNSSes (with still valid lifetimes or
>>    learned through DHCP or manual configuration) are available [6]-[8],
>>    RDNSSes with expired lifetimes should be used as a last resort.  The


This goes against the notion of lifetimes. One should expire an entry
when the lifetime expires. If a host does not have a valid RDNSS, that
is a config problem associated with the network it is currently
attached to. We shouldn't try to fix that...


>>      Step (a): Receive and parse RDNSS option(s).  Process only the
>>      first three RDNSS addresses in each RDNSS option if one RDNSS
>>      option has more than three RDNSS addresses.


Again, its seems bogus to restrict this to three.


>>      Step (c): For each RDNSS option, check the following: If the value
>>      of "Lifetime" field is set to zero and the value of "Pref" field


s/and/or/ (since either being zero invalidates the option). Note: it
is this sort of complexity that leads me to suggest using only the
proper lifetime.


>>      is set to zero, delete the corresponding RDNSS entries from both


>>      Step (d): Delete each expired entry from DNS Server List and the
>>      RDNSS address corresponding to the entry from the Resolver
>>      Repository.  However, in mobile environment, in order that a
>>      mobile node can still use the RDNSS of the previous site when the
>>      host moves into another site and no RDNSS is available there, it
>>      MAY be allowed to maintain the expired entry in both the DNS
>>      Server List and the Resolver Repository.  The expired RDNSS entry


IMO, this should not be explicitely encouraged by this document.


>>    for the subnet.  It is necessary to disable the RA RDNSS option
>>    administratively to avoid this problem.  All of this can be done


not sure about this. Do they mean disable administratively on the
client?

Overall, I find the security considerations section could be better.


>>    The security of RA option for RDNSS is the same as ND protocol
>>    security [2].  The RA option does not add any new vulnerability.


Surely, having this option allows new vectors of attack. Saying it
adds no new vulnerability seems misleading, if not untrue.

It may  be that there are worse attacks already, so this one is
acceptable, but that is a different kind of statement.

[Ballot discuss]
1. Should this document contain an IESG note or text in the abstract explaining that DHC may also be used here. Similarly, should there be text in the operations section describing what to do when both are deployed on the same network?

2. Should this document be Informational or Experimental?

...the "experiment" lacks any description of how it will be
evaluated. So guideline 5 of http://www.ietf.org/u/ietfchair/info-exp.html
doesn't apply. Does guideline 4 apply:

"4. If the IETF may publish something based on this on the standards track once we know how well this one works, it's Experimental. This is the typical case of not being able to decide which protocol is "better" before we have experience of dealing with them from a stable specification." ?

[Ballot discuss]
1. Should this document contain an IESG note or text in the abstract explaining that DHC may also be used here. Similarly, should there be text in the operations section describing what to do when both are deployed on the same network?

2. Should this document be Informational or Experimental?

...the "experiment" lacks any description of how it will be
evaluated. So guideline 5 of http://www.ietf.org/u/ietfchair/info-exp.html
doesn't apply. Does guideline 4 apply:

"4. If the IETF may publish something based on this on the standards track once we know how well this one works, it's Experimental. This is the typical case of not being able to decide which protocol is "better" before we have experience of dealing with them from a stable specification." ?

[Ballot comment]
Section 5.1:

Pref          The preference of an RDNSS.


        Addresses of IPv6 Recursive DNS Servers
                      One or more 128-bit IPv6 addresses of the
                      recursive DNS servers.

As there is only one preference field in the option and the option may contain the address to multiple servers there should be a clarification that the preference field applies to all servers listed. The language anyway isn't in synch when it comes singular and plural usage.

[Ballot discuss]
Needs a discussion of, and a reference to:

RFC 4339

--------

In section '5.1  Recursive DNS Server Option':

  Addresses of IPv6 Recursive DNS Servers
  One or more 128-bit IPv6 addresses of the
  recursive DNS servers.  The number of addresses
  is determined by the Length field.  That is,
  the number of addresses is equal to
  (Length - 1) / 2.  For the maximum number of
  RDNSS addresses in one RDNSS option, at most
  three is recommended since three RDNSSes are
  enough for DNS resolution service.  See Section
  5.2 for how parts of RDNSSes in one RDNSS option
  can be selected by a host

Why is a maximum of three recommended ? Your reasoning can be used to support a value
of anything equal or larger than one (eg. 'since three RDNSSes are
enough for DNS resolution service', why not 'since one RDNSS are
enough for DNS resolution service' or 'since 200 RDNSSes are
enough for DNS resolution service')

-----------

In section '5.2.1  Procedure in IPv6 Router'

  An IPv6 router SHOULD include RDNSS option(s) in solicited and
  unsolicited RAs it sends if the router has been configured to send
  this RDNSS information to hosts on the link.

Isn't this stating the obvious ? Why would anybody bother to configure their router but than the router refuses to do its job ?

  Since one RDNSS option is recommended to have at most three RDNSSes,
  the router MAY send more than one RDNSS option if it would like to
  advertise more than three RDNSSes.

Why would one choose to do this ugly workaround instead of simply ignoring the recommendation ?
This section really doesn't make any sense to me.

[Ballot discuss]
Needs a discussion of, and a reference to:

RFC 4339

--------

In section '5.1  Recursive DNS Server Option':

  Addresses of IPv6 Recursive DNS Servers
  One or more 128-bit IPv6 addresses of the
  recursive DNS servers.  The number of addresses
  is determined by the Length field.  That is,
  the number of addresses is equal to
  (Length - 1) / 2.  For the maximum number of
  RDNSS addresses in one RDNSS option, at most
  three is recommended since three RDNSSes are
  enough for DNS resolution service.  See Section
  5.2 for how parts of RDNSSes in one RDNSS option
  can be selected by a host

Why is a maximum of three recommended ? Your reasoning can be used to support a value
of anything equal or larger than one (eg. 'since three RDNSSes are
enough for DNS resolution service', why not 'since one RDNSS are
enough for DNS resolution service' or 'since 200 RDNSSes are
enough for DNS resolution service')

IANA Last Call Comment:

Upon approval of this document IANA will add a single new option

Recursive DNS Server Option

to the IPv6 Neighbor Discovery Option Formats registry located at:

http://www.iana.org/assignments/icmpv6-parameters

IANA understands this to be the only action required upon approval of this document.

Review information from Bob Hinden:

> From: Bob Hinden
> Date: January 20, 2006 10:39:04 AM PST
> To: Margaret Wasserman
> Cc: Bob Hinden , Pekka Savola
> , Brian Haberman ,
> Iljitsch van Beijnum , Jaehoon Jeong
> , Soohong Daniel Park ,
> BELOEIL Luc RD-CORE-CAE , Syam
> Madanapalli
> Subject: Review of "IPv6 Router Advertisement Option for DNS
> Configuration"
>
> Margaret,
>
> I organized a review of "IPv6 Router Advertisement Option for DNS
> Configuration" prior to the authors submitting it to you as an
> individual submission.  We had discussed this earlier and you had
> agreed to shepard it in the IESG.  The authors will send you the
> document shortly.
>
> The reviewers were Pekka Savola, Brian Haberman, and Iljitsch van
> Beijnum.  They reviewed the document  discovery-05.txt> and two subsequent drafts.  Their review raised
> several issues.  After a discussion with the authors, a set of changes
> was agreed to and a revised draft was published as  jeong-dnsop-ipv6-dns-discovery-08.txt>.  The reviewers and I are
> satisfied with the changes and recommend that the document be
> published as an individual submitted RFC.
>
> Please let me know if you need any additional information.
>
> Thanks,
> Bob