Subject: Re: 6MAN Working group last call: draft-ietf-6man-rdnss-rfc6106bis

From: Fernando Gont <[email-masked]>
Date: Thu, 3 Mar 2016 07:55:00 -0300

Authors,

Please respond to the reviews that have been posted on list. You need to
do this to agree on any necessary updates before this document can move
forward.

Thanks!

Cheers,
Fernando
(as document shepherd)

On 02/09/2016 06:54 AM, [email-masked] wrote:
> This message starts a two week 6MAN Working Group Last Call on advancing:
> 
>      Title    : IPv6 Router Advertisement Options for DNS Configuration
>      Authors  : J. Jeong, S. Park, L. Beloeil, S. Madanapalli
>      Filename : draft-ietf-6man-rdnss-rfc6106bis-06
>      Pages    : 17
>      Date     : 2015-10-09
> 
>     https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-06
> 
> as a Proposed Standard.  Substantive comments and statements of support for publishing this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This last call will end on 23 February 2016.
> 
> We would like this document to follow the experimental document shepherd procedure. We will need a volunteer document shepherd, before we can advance this document.
> 
> Best regards,
> Ole & Bob
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 3 Mar 2016 20:05:39 +0900

Hi Fernando,
I will respond to the reviews by the end of this weekend.

Thanks.

Best Regards,
Paul

On Thu, Mar 3, 2016 at 7:55 PM, Fernando Gont <[email-masked]> wrote:

> > as a Proposed Standard.  Substantive comments and statements of support
> for publishing this document should be directed to the mailing list.
> Editorial suggestions can be sent to the authors.  This last call will end
> on 23 February 2016.
> >
> > We would like this document to follow the experimental document shepherd
> procedure. We will need a volunteer document shepherd, before we can
> advance this document.
> >
> > Best regards,
> > Ole & Bob
> >
> >
> >

-- 
===========================
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://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Mon, 7 Mar 2016 04:21:59 +0900

Hi Jinmei,
I tried to address your comments in the following draft:
https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-08

Could you double-check whether your comments are resolved well or not?

Also, I put my answers inline with =>.

If you have some unclear parts, please let me clarify them.

Thanks.

Paul

On Thu, Feb 25, 2016 at 4:27 AM, 神明達哉 <[email-masked]> wrote:

> At Tue, 9 Feb 2016 10:54:16 +0100,
> [email-masked] wrote:
>
> > as a Proposed Standard.  Substantive comments and statements of
> > support for publishing this document should be directed to the
> > mailing list.  Editorial suggestions can be sent to the authors.
> > This last call will end on 23 February 2016.
>
> I've reviewed the 06 version.  I don't have a particular opinion on
> whether to publish it, but I have some comments:
>
> - Section 5
>
>    The IPv6 DNS configuration mechanism in this document needs two new
>    ND options in Neighbor Discovery: (i) the Recursive DNS Server
>    (RDNSS) option and (ii) the DNS Search List (DNSSL) option.
>
>   "new" sounds like awkward since, well, it's not new any more.  I
>   don't know the usual practice (if any) in cases like this for "-bis"
>   specifications, but I'd suggest just removing "new".
>
>  => Done.

> - Section 5.1
>
>      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.
>
>   Shouldn't "relative to the time the packet is sent" actually be
>   "relative to the time the packet is received"?  In practice these
>   two wouldn't be different very much anyway, but, technically, the
>   former looks awkward to me since the recipient can't know that time.
>
>  => Done.

> - Section 5.1
>
>    Note:  [...]  The link zone indices SHOULD be
>       represented in the textual format for scoped addresses as
>       described in [RFC4007].
>
>   Perhaps the actual intent is "The link-local addresses SHOULD be
>   represented with their link zone indices in the textual format for
>   scoped addresses as described in [RFC4007]."?  Also, it's not very
>   clear to me why it's a "SHOULD".  Maybe because it's convenient as
>   the DNS client (stub resolver) implementation can simply pass the
>   textual text (whether it's link-local or not) to a utility function
>   like getaddrinfo()?  If so, that's understandable, but I guess it's
>   not obvious and should be explained explicitly.  Also, I'm not sure
>   if this convenience (if that's the reason for the SHOULD) is worth
>   the RFC2119 keyword.  While it'd certainly be convenient, this seems
>   to be a pure implementation choice.
>
>  => Done.

> - Section 5.2: s/name/names/
>
>      Lifetime      32-bit unsigned integer.  The maximum time, in
>                    [...]
>                    (0xffffffff) represents infinity.  A value of zero
>                    means that the DNSSL domain name MUST no longer be
>                    used.
>
>  => Done.

> - Section 5.2
>
>      Domain Names of DNS Search List
>                    One or more domain names of DNS Search List that MUST
>                    be encoded using the technique described in Section
>                    3.1 of [RFC1035].
>
>   The word "technique" sounds awkward to me as it's the standard wire
>   format of domain names.  I suggest, e.g., just saying "...encoded as
>   described in Section 3.1 of [RFC1035]".
>
>  => Done.

> - Section 6
>
>    In environments where the DNS information is stored in user space and
>    ND runs in the kernel, it is necessary to synchronize the DNS
>    information (i.e., RDNSS addresses and DNS search domain names) in
>    kernel space and the Resolver Repository in user space.  For the
>    synchronization, an implementation where ND works in the kernel
>    should provide a write operation for updating DNS information from
>    the kernel to the Resolver Repository.  One simple approach is to
>    have a daemon (or a program that is called at defined intervals) that
>    keeps monitoring the Lifetimes of RDNSS addresses and DNS search
>    domain names all the time.  [...]
>
>   This seems to assume that "ND runs in the kernel" means that all
>   information in RAs is managed in the kernel.  I don't know if
>   there's such an implementation (does Linux work that way?), but it
>   doesn't necessarily have to be so, and is actually different from
>   the BSD implementation: the FreeBSD's rtsol(d) completely works as a
>   user space application, receives RA via an ICMPv6 socket using the
>   standard advanced socket API (RFC3542), and manages RDNSS
>   implementation independently from the kernel (even if some other
>   parts of the RA are managed in the kernel).  So, I'd at least
>   suggest clarifying that this kind of approach is only necessary for
>   some deviant protocol stack implementation that doesn't even support
>   RFC3542.  And, I'd also mention the FreeBSD-style approach as it
>   should be more generic and portable.
>
>  => I tried the current text as follows:
      In environments where the DNS information is stored in user space and
      ND runs in the kernel, it is necessary to synchronize the DNS
      information (i.e., RDNSS addresses and DNS search domain names) in
      kernel space and the Resolver Repository in user space.  In these
      environments, a user space application cannot receive RA via an
      ICMPv6 socket using the standard advanced socket Application Program
      Interface (API) in [RFC3542].

> - Section 6.3: this section largely repeats the text of Section 6.2
>   and looks redundant to me.  I'd consider unifying these two sections
>   and eliminate unnecessary duplicates.
>
>  => Done. I removed the redundant ones and specified a different in Step
(b).
      In Step (b), if the DNSSL domain name already exists in the DNS
      Search List and the DNSSL option's Lifetime field is set to zero,
      delete the corresponding DNSSL entry from both the DNS Search List
      and the Resolver Repository in order to prevent the DNSSL domain name
      from being used any more for certain reasons in network management,
      e.g., the termination of the usage of the DNSSL domain name.  That
      is, the DNSSL domain name may not be used any more by the policy of
      the network.

> - Section 6.3: on a related point, this text looks awkward:
>
>       Step (b): For each DNSSL domain name, check the following: [...]
>       [...] for certain reasons in network management,
>       e.g., the termination of the RDNSS or a renaming situation.  That
>       is, the RDNSS can resign from its DNS service because the machine
>       running the RDNSS is out of service intentionally or
>       unintentionally.  Also, under the renaming situation, the DNSSL
>
>   How can the termination of a particular RDNSS mean that DNSSL names
>   are not usable anymore?  There may be a case where one event is
>   realted to the other, but I don't see any obvious relationship
>   between these two (the RDNSS may simply be replaced with a new,
>   different node).  This text rather seems to be a result of a naive
>   copy of Section 6.2.
>
>  => Done like the previous answer.

> - Section 7.1, second paragraph.  Most of the text in this paragraph
>   is irrelevant to this protocol and looks redundant to me.  I'd
>   consider just referring to some other document for the general
>   issue.
>
>  => Removed.

> - Section 7.2
>
>    The Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as a
>    security mechanism for ND.  It is RECOMMENDED that ND use SEND to
>    allow all the ND options including the RDNSS and DNSSL options to be
>    automatically included in the signatures.
>
>   I don't think this "RECOMMENDED" is realistic.  As a matter of fact,
>   SEND isn't even widely implemented, and, IMO, its deployability
>   issues are not easily resolved.  I don't have a specific suggestion
>   on how to make the whole text realistic, but I'd at least suggest
>   stopping to make such an unrealistic requirement, especially with an
>   RFC2119 keyword.
>
>  => I replaced "RECOMMENDED" with "MAY" as follows:
      The Secure Neighbor Discovery (SEND) protocol [RFC3971] MAY be used
      as a security mechanism for ND.  In this case, ND can use SEND to
      allow all the ND options including the RDNSS and DNSSL options to be
      automatically included in the signatures.  Other approaches specified
      in [RFC4861] can be used for securing the RA options for DNS
      configuration.

 Thanks.

 Best Regards,
 Paul

--
> JINMEI, Tatuya

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Mon, 7 Mar 2016 04:28:02 +0900

Hi Bing,

BTW, I added your name in Acknowledgements.

Thanks.

Paul

On Thu, Feb 25, 2016 at 10:52 PM, Liubing (Leo) <[email-masked]>
wrote:

> Hi Dear authors,
>
> I've read the draft. It was my first time to read it, so please pardon me
> if I iterated some questions that had been addressed before.
>
> 1. Since RFC5006 was already obsolete by RFC6106, and this document is
> going to obsolete 6106, I guess this draft should not necessary to mention
> 5006 anymore?
> When the document says it defines a "new" option (DNSSL), it is still
> comparing to 5006. But it is not "new" comparing to 6106. So this is a bit
> confusing for me.
> So I'd suggest the whole text be tweaked in the perspective of obsolete
> RFC6106, not just iterate it.
>
>  => Done.

> 2. Section 1.1, page3
> "  Furthermore,
>    the host learns this DNS configuration from the same RA message that
>    provides configuration information for the link, thereby avoiding
>    also running DHCPv6."
> Do you mean the host decides not to initial DHCPv6?
> I think "avoiding also running DHCPv6" should not be a principle from
> hosts' perspective. That should come from the administrator's deployment
> plan.
>
 => I removed "thereby avoiding also running DHCPv6" for the
administrator's deployment plan in the text.

>
> 3. Section 5.3.2
> " Second, if different DNS information is provided on different network
>    interfaces, this can lead to inconsistent behavior.  The IETF is
>    working on solving this problem for both DNS and other information
>    obtained by multiple interfaces [MIF-PROBLEM][MIF-PRACTICE]. "
>
> Regarding MIF problems, I think it's nice to mention RFC6731 here, which
> is the solution for DNSS selection.
> Btw, the [MIF-PROBLEM][MIF-PRACTICE] are already RFC6418 and RFC6419.
>
>  => Reflected the text as follows:
      Second, if different DNS information is provided on different network
      interfaces, this can lead to inconsistent behavior.  The IETF worked
      on solving this problem for both DNS and other information obtained
      by multiple interfaces [RFC6418][RFC6419], and standardized the
      solution for RDNSS selection for multi-interfaced nodes in [RFC6731],
      which is based on DHCP.

> 4. Section 7.2
> "It is RECOMMENDED that ND use SEND to
>    automatically included in the signatures."
> I think recommending SEND is not very specific to this document. We should
> have more considerations whether to use SEND, not only in term of
> protecting RDNSS/DNSSL options.
>
>  => I replaced "RECOMMENDED" with "MAY" to tell that SEND can be used as a
mitigation approach.

> 5. Section 1.1, page 3
> "However, when in many networks some additional information needs to be
> distributed, those networks are likely to employ DHCPv6."
> This sentence reads a bit odd. I guess you intended to mean like this:
> " However, for networks that need to distribute additional information,
> DHCPv6 is likely to be employed."
>
>  => Done.

 Thanks.

 Best Regards,
 Paul

> Best regards,
> Bing
>
> > -----Original Message-----
> > From: ipv6 [mailto:[email-masked]] On Behalf Of
> > [email-masked]
> > Sent: Tuesday, February 09, 2016 5:54 PM
> > To: 6man WG
> > Cc: [email-masked]
> > Subject: 6MAN Working group last call: draft-ietf-6man-rdnss-rfc6106bis
> >
> Editorial
> > suggestions can be sent to the authors.  This last call will end on 23
> > February 2016.
> >

---

From: 神明達哉 <[email-masked]>
Date: Mon, 7 Mar 2016 10:21:39 -0800

At Mon, 7 Mar 2016 04:21:59 +0900,

> >   the BSD implementation: [...]  So, I'd at least

I don't think the revised text really addresses my point (or I was not
clear enough).  According to a follow-up message from the chairs they
don't seem to be willing to change text that hasn't been changed from
RFC6106, but just in case we can still make it the document more
sense, I'd like to propose alternate text.  It replaces the entire
Section 6, although the first paragraph is intact:

   For the configuration and management of DNS information, the
   advertised DNS configuration information can be stored and managed in
   both the DNS Repository and the Resolver Repository.

   Since there is nothing special in an RA message as a link-local
   ICMPv6 message, a user space application should be readily able to
   get access to its content including the RDNSS or DNSSL option by
   the standard socket API [RFC3542].  Environments where the DNS
   information (i.e., RDNSS addresses and DNS search domain names) is
   stored in the user space can take this approach.  Note that this is
   the case even if some other parts of the ND protocol such as router
   discovery or link-layer address resolution are performed within the
   kernel.

   For some peculiar environments that do not provide such an API and
   still need to store the DNS information in the user space, it is
   necessary to synchronize the DNS information in the kernel space
   and the Resolver Repository in user space.  For the
   synchronization, the implementation should provide a write
   operation for updating DNS information from the kernel to the
   Resolver Repository.  One approach is to have a daemon (or a
   program that is called at defined intervals) that keeps monitoring
   the Lifetimes of RDNSS addresses and DNS search domain names all
   the time.  Whenever there is an expired entry in the DNS
   Repository, the daemon can delete the corresponding entry from the
   Resolver Repository.

BTW, out of curiosity is there any such "peculiar" environment?  As I
said BSDs shouldn't need such an ugly hack.  I don't know much detail
of Linux, but a quick look at the man page of its rdnssd(8) it also
seems to work on the received RA content directly (though not using
the standard API - Linux is notorious about its lack of support of the
API).  If this "environment" is only an imaginary thing, I'd even
consider removing the third paragraph (or the second paragraph of the
original draft).

> >   and eliminate unnecessary duplicates.

I'd also remove the duplicate 'e.g.' from the first sentence of
Section 6.3:

   When an IPv6 host receives the information of multiple DNSSL domain
   names within a network (e.g., campus network and company network)

>       in [RFC4861] can be used for securing the RA options for DNS

Personally, I don't even see the need for using an RFC2119 keyword
here, but if non one else bothers I wouldn't object.  But in any case
I think this change has to be noted in Appendix A.

--
JINMEI, Tatuya

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 8 Mar 2016 13:27:58 +0900

Hi Jinmei,
Thanks for your comments.
I will reflect yours on the revision.

6MAN WG,
for Linux implementation for RDNSS,
are there any other comments from Jinmei below?

Thanks.

Paul

---

From: [email-masked]
Date: Fri, 11 Mar 2016 13:11:58 +0100

I would in general prefer not to see implementation specific text or text on specific implementation issues in a protocol specification.
I don't think any discussion on kernel vs user space belongs.

Best regards,
Ole

> On 07 Mar 2016, at 19:21, 神明達哉 <[email-masked]> wrote:
>

---

From: 神明達哉 <[email-masked]>
Date: Fri, 11 Mar 2016 08:32:50 -0800

At Fri, 11 Mar 2016 13:11:58 +0100,
[email-masked] wrote:

> I would in general prefer not to see implementation specific text or
> text on specific implementation issues in a protocol specification.

That's perfectly fine to me, and in that sense I'd rather suggest just
removing Section 6.  My suggestion was not to provide new
implementation-specific text; it was a suggestion to (IMO) improve
already existing such text.

--
JINMEI, Tatuya

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Sat, 12 Mar 2016 16:39:42 +0900

Hi Jinmei,
I have submitted the revised draft:
https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-09

Here are my answers for your comments below.

On Tue, Mar 8, 2016 at 3:21 AM, 神明達哉 <[email-masked]> wrote:

>  => Along with Ole's comments, I prefer to leave Section 6 for the general
guidelines of the implementation of the RA DNS Options.
I modified the beginning of Section 6 as follows:

   For the configuration and management of DNS information, the
   advertised DNS configuration information can be stored and managed in
   both the DNS Repository and the Resolver Repository.  These two
   repositories should be synchronized however the processing of RA DNS
   options are implemented in the kernel space or user space.

 => Also, I specified this change in Appendix A:

   o  The guidance of the specific implementation for the
      synchronization of the DNS Repository and Resolver Repository on
      the kernel space and user space is removed.

>  => I removed the 'e.g.' as follows:

   When an IPv6 host receives the information of multiple DNSSL domain
   names within a network through an RA message with DNSSL option(s), it
   stores the DNSSL domain names (in order) into both the DNS Search
   List and the Resolver Repository.

>  => I removed the keyword "MAY" for SEND and have the following text:

   The Secure Neighbor Discovery (SEND) protocol [RFC3971] is designed
   as a security mechanism for ND.  In this case, ND can use SEND to
   allow all the ND options including the RDNSS and DNSSL options to be
   automatically included in the signatures.

 => Also, I specified this change in Appendix A:

   o  The usage of the keywords of SHOULD and RECOMMENDED in RFC 2119 is
       removed in the recommendation of using SEND for secure ND.
       Instead of the keywords, SEND is specified as a possible solution
       for secure ND.

 Thanks.

 Best Regards,
 Paul

--

---

From: [email-masked]
Date: Sat, 12 Mar 2016 17:55:09 +0100

Jinmei,

> already existing such text.

Ah yes, sorry about that Jinmei.
Yes, I would also be supportive of removing section 6.

Best regards,
Ole

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Mon, 14 Mar 2016 16:25:01 +0900

Ole and Jinmei,
I removed Section 6 of Implementation Considerations according to your
suggestion.
The new version is:
https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-10

Ole and Bob,
I believe that all of the issues are resolved, so
we can go ahead for the next step after WGLC.

Thanks.

Best Regards,
Paul

---

From: 神明達哉 <[email-masked]>
Date: Mon, 14 Mar 2016 09:32:23 -0700

At Mon, 14 Mar 2016 16:25:01 +0900,

> https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-10

When I said removing Section 6, I meant the couple of leading
paragraphs in the section before Section 6.1, i.e.,

from

   Note:  This non-normative section gives some hints for implementing
      the processing of the RDNSS and DNSSL options in an IPv6 host.

to

   [...]  Whenever there is an expired entry in the DNS Repository, the
   daemon can delete the corresponding entry from the Resolver
   Repository.

I didn't mean removing Section 6.x, and I'm not even sure if it's a
good idea.  We'd certainly revise the first sentence of Section 6.1:

   For DNS repository management, the kernel or user-space process
   (depending on where RAs are processed) should maintain two data
   structures: (i) DNS Server List that keeps the list of RDNSS

so it will be independent from kernel vs user-space considerations,
but the rest of this section rather seems to be describing the general
protocol handling using some conceptual data structures.  They don't
necessarily have to be removed in the context of this discussion, and
I guess they can actually be an important part of this document.

--
JINMEI, Tatuya

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 15 Mar 2016 08:28:43 +0900

Jinmei,
I will reflect your comments on the revision by modifying the sentence
mentioned below and getting back Section 6.x's.

Thanks.

Best Regards,
Paul

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 15 Mar 2016 11:38:49 +0900

Hi Jinmei,
I submitted the revision with Section 6 of Implementation Considerations:
https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-11

Section 6 and Section 6.1 are modified as follows:

6.  Implementation Considerations

   The implementation considerations in this document include the
   following three: (i) DNS repository management, (ii) synchronization
   between DNS server list and resolver repository, and (iii)
   synchronization between DNS search list and resolver repository.

6.1.  DNS Repository Management

   For DNS repository management, the kernel or user-space process
   (depending on where RAs are processed) should maintain the following
   two data structures to be synchronized with each other: (i) DNS
   Server List that keeps the list of RDNSS addresses and (ii) DNS
   Search List that keeps the list of DNS search domain names.

Thanks.

Best Regards,
Paul

---

From: 神明達哉 <[email-masked]>
Date: Wed, 16 Mar 2016 11:12:09 -0700

At Tue, 15 Mar 2016 11:38:49 +0900,

It still talks about the kernel-US relationship:

>    two data structures to be synchronized with each other:

--
JINMEI, Tatuya

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 17 Mar 2016 09:16:42 +0900

Jinmei,
How about the following sentence?

For DNS repository management, the following two data structures SHOULD
be synchronized with each other:

Thanks.

Best Regards,
Paul

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Thu, 17 Mar 2016 12:55:35 +0200

Just two comments:

>
>    Note:  The addresses for recursive DNS servers in the RDNSS option
>       MAY be link-local addresses.  Such link-local addresses SHOULD be
>       registered into the resolver repository along with the
>       corresponding link zone indices of the links that receive the
>       RDNSS option(s) for them.  The link-local addresses MAY be
>       scoped addresses as described in [RFC4007].  When a resolver sends
>       a DNS query message to an RDNSS with a link-local address, it MUST
>       use the corresponding link.

I guess "The link-local addresses MAY be represented with their link
zone indices in the textual format for scoped addresses as described in
[RFC4007]" refers to the representation on the resolver repository and
not on the RDNSS option. Maybe it should be clarified a bit ("The
link-local addresses MAY be represented in the resolver repository with
their link zone indices".

> The DNS options from Router Advertisements and DHCP
>    SHOULD be stored into the DNS Repository and Resolver Repository so
>    that information from DHCP appears there first and therefore takes
>    precedence.  Thus, the DNS information from DHCP takes precedence
>    over that from RA for DNS queries. 

I do not oppose to the above, but i would like to see an
explanation/justification (trust/security?) there.

--
Tassos

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 17 Mar 2016 21:37:41 +0900

Tassos,

For the first comment, I agree with your suggested sentence for the
clarification:

The link-local addresses MAY be represented in the resolver repository
with their link zone indices in the textual format for scoped addresses as
described in [RFC4007].

For the second comment, I suggest the following sentence for the rationale:

The DNS options from Router Advertisements and DHCP SHOULD be
stored into the DNS Repository and Resolver Repository so that
information from DHCP appears there first and therefore takes
precedence. This is because IPv6 hosts usually prefer DHCP to
RA for their network configuration. Thus, the DNS information
from DHCP takes precedence over that from RA for DNS queries.

Thanks.

Best Regards,
Paul

On Thu, Mar 17, 2016 at 7:55 PM, Tassos Chatzithomaoglou <[email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 17 Mar 2016 22:04:46 +0900

> from DHCP takes precedence over that from RA for DNS queries.

Um... "DHCP should be first because hosts prefer DHCP to be first,
therefore DHCP should be first"? That's circular reasoning.

I'm not even sure "IPv6 hosts usually prefer DHCP to RA for their network
configuration" is a true statement. Do we have data on that?

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Mar 2016 10:12:22 -0300

On 03/17/2016 10:04 AM, Lorenzo Colitti wrote:
> On Thu, Mar 17, 2016 at 9:37 PM, Mr. Jaehoon Paul Jeong
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I'm not even sure "IPv6 hosts usually prefer DHCP to RA for their
> network configuration" is a true statement. Do we have data on that?

The v6ops draft that you don't like covers this one.

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 17 Mar 2016 22:18:37 +0900

Fernando,
Do you tell me the draft you mentioned?

I will let the revised rdnss draft refer to the draft.

Thanks.

Best Regards,
Paul

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 17 Mar 2016 22:21:39 +0900

> The v6ops draft that you don't like covers this one.

... and the answer is....?

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Mar 2016 13:42:47 -0300

On 03/17/2016 10:21 AM, Lorenzo Colitti wrote:
> On Thu, Mar 17, 2016 at 10:12 PM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

Section A.2.2. (and probably others) of:
https://www.ietf.org/id/draft-ietf-v6ops-dhcpv6-slaac-problem-06.txt

---

From: 神明達哉 <[email-masked]>
Date: Thu, 17 Mar 2016 11:38:54 -0700

At Thu, 17 Mar 2016 09:16:42 +0900,

> be synchronized with each other:

Works for me.

--
JINMEI, Tatuya

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 18 Mar 2016 10:02:54 +0900

Fernando and Lorenzo,

I took a look at the draft of
https://www.ietf.org/id/draft-ietf-v6ops-dhcpv6-slaac-problem-06.txt.

>From Case 4 (all RA flags are set, that is, M=1, A=1, O=1) in A.2.2,
Fedora 21 and Centos 7 let the DNS of the RAs have higher priority, but
MAC OS-X lets the DNS of DHCPv6 have higher priority.
In the current implementations, there is no consistency to handle RDNSS
options from RA and DHCPv6.

Thus, I suggest the following text with the preference for DHCPv6 because
there is no a stong rationale, but there must be somehow a guidance to
handle this case:

The DNS options from Router Advertisements and DHCP SHOULD be
stored into the DNS Repository and Resolver Repository so that
information from DHCP appears there first and therefore takes
precedence. This document recommends that the DNS information
from DHCP should have higher priority than that of RA for
DNS queries to handle the case of the coexistence of RA and DHCP.

If anyone does not object this text, I will revise the draft with it.

Thanks.

Paul

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 18 Mar 2016 11:04:32 +0900

> https://www.ietf.org/id/draft-ietf-v6ops-dhcpv6-slaac-problem-06.txt

You can't use that section to make a general statement about IPv6
implementation behaviour because it only covers a minority of hosts.

Among other things, that section does not cover recent versions of Windows,
only seems to include one (unspecified) version of OS X, and includes no
mobile operating systems at all.

---

From: [email-masked]
Date: Fri, 18 Mar 2016 09:44:07 +0100

Paul,

> I took a look at the draft of https://www.ietf.org/id/draft-ietf-v6ops-dhcpv6-slaac-problem-06.txt.
> 
> In the current implementations, there is no consistency to handle RDNSS options from RA and DHCPv6.
> 
> there is no a stong rationale, but there must be somehow a guidance to handle this case:
> 

I would prefer this document focused solely on specifying the RA DNS options, and did not stray into more general configuration complexity.

getting information from multiple sources is a more general problem in IPv6, and I don't want us to "solve" (if that's possible) that problem in this document.

"the less you say, the less likely you are to say something wrong". ;-)

Best regards,
Ole

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Fri, 18 Mar 2016 11:38:00 +0200

> "the less you say, the less likely you are to say something wrong". ;-)
So we leave the DHCP/RA preference choice to the implementers?

Something else that doesn't seem ok to me.
> However, the security of these RA options for DNS configuration does
>    not affect ND protocol security [RFC4861].  This is because learning
>    DNS information via the RA options cannot be worse than learning bad
>    router information via the RA options.  Therefore, the vulnerability
>    of ND is not worse and is a subset of the attacks that any node
>    attached to a LAN can do.

I do not agree with the statement "learning DNS information via the RA
options cannot be worse than learning bad router information via the RA
options".
I believe that bad router exploitation is at a local level, while bad
DNS exploitation is at a global level. So while the origin of the attack
can be the same (a node attached to the LAN), the easiness/effectiveness
of the attack can be greater in the case of DNS.

Also, i have spotted a few more places for further clarification:

> Step (c): For each RDNSS address, if it already exists in the DNS
>       Server List, then...

Step (c): For each RDNSS address, if it already exists in the DNS
      Server List and the RDNSS option's Lifetime field is not set to
zero, then....

> Step (d): For each RDNSS address, if it does not exist in the DNS
>       Server List, register the RDNSS address and Lifetime with the DNS
>       Server List and then insert the RDNSS address in front of the
>       Resolver Repository.

...and then insert the RDNSS address as the first one in the Resolver
Repository.

--
Tassos

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 22 Mar 2016 09:24:51 +0900

Ole,
I agree with you.
I will keep the original text in the revision for the coexistence of RA and
DHCP.

Thanks.

Best Regards,
Paul

On Fri, Mar 18, 2016 at 5:44 PM, <[email-masked]> wrote:

> I would prefer this document focused solely on specifying the RA DNS
> options, and did not stray into more general configuration complexity.
>
> getting information from multiple sources is a more general problem in
> IPv6, and I don't want us to "solve" (if that's possible) that problem in
> this document.
>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 22 Mar 2016 09:41:32 +0900

Hi Tassos,
Thanks for your comments.
I put my answers inline below with "=>".

On Fri, Mar 18, 2016 at 6:38 PM, Tassos Chatzithomaoglou <[email-masked]

> So we leave the DHCP/RA preference choice to the implementers?
 => Since this issue  is not standardized yet, we will leave it to the
implementers.

>  => By the invalid RDNSS addresses, the DNS query messages from
      IPv6 hosts can be generated and sent toward those addresses over the
link
      to which the hosts are attached. However, in the aspect of IPv6
hosts,
      the vulnerability level for ND service seems still the same.

>  => This clarification looks good. I will reflect this in the revision.

>   => This clarification looks good, too. I will reflect this in the
revision.

 Thanks.

 Best Regards,
 Paul