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

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Mon, 5 Oct 2015 19:30:47 +0900

Hi 6MAN WG,
Here is the revised draft reflecting the discussion of link-local addresses
for recursive DNS servers:
https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-03

The major changes are as follows:

5.1.  Recursive DNS Server Option
...
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 interfaces (or zones) that received the RDNSS
      option(s) for them.  The interface names (or zone indices) SHOULD
      be represented in the textual format for scoped addresses in
      described in [RFC4007].  When a resolver sends a DNS query message
      to an RDNSS with a link-local address, it MUST use the
      corresponding interface.
...

10.1.  Normative References
...
   [RFC4007]        Deering, S., Haberman, B., Jinmei, T., Nordmark, E.,
                    and B. Zill, "IPv6 Scoped Address Architecture",
                    RFC 4007, March 2005.

...

Appendix B.  Changes from RFC 6106
...
 o  The addresses for recursive DNS servers in the RDNSS option can be
      not only global addresses, but also link-local addresses.  The
      link-local addresses for RDNSSes should be specified in the
      resolver repository along with the corresponding interface names
      (or zone indices).
...

If you have comments and concerns on these updates, please let me know.
Otherwise, I believe that we can do WGLC.

Thanks.

Cheers!

Paul

On Thu, Aug 20, 2015 at 12:01 AM, Mr. Jaehoon Paul Jeong <
[email-masked]> wrote:

> Hi Lorenzo,
> As the editor, I agree at Lorenzo's comments.
>
> Lorenzo, could you prepare for a text for your proposal about the usage of
> link-local address of RDNSS?
>
> If so, I will reflect yours on the revised one.
>
> Thanks.
>
> Paul
>
> On Tue, Aug 11, 2015 at 9:18 PM, Lorenzo Colitti <[email-masked]>
> wrote:
>
>> On Wed, Aug 12, 2015 at 10:14 AM, Mark Smith <[email-masked]>
>> wrote:
>>
>>> So I think any link-local address received in an RA could only be
>>> interpreted as being on the link over which the RA arrived, as the
>>> context of an RA is the link it was sent over.
>>>
>>
>> +1
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>>
>
>
> --
> ===========================
> 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
>

-- 
===========================
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: 神明達哉 <[email-masked]>
Date: Tue, 6 Oct 2015 09:47:52 -0700

At Mon, 5 Oct 2015 19:30:47 +0900,

I guess you're trying to address the following comment of mine:

>> I don't have a strong opinion on whether to allow link-local
>> addresses per se, but if we allow that, I think we should clarify
>> which link (or link zone, in RFC4007 terminology) that link-local
>> address belongs to.  In the case of router advertisements, I guess it
>> makes most sense if it's the link over which the RA is sent out and
>> received.

My impression of that discussion was that for others this is too
trivial to explicitly note.  So I would have been okay with not saying
anything about it, but now you're actually trying to address that
(which I appreciate), I'd like to offer some changes based on the
following observations:

- the above text seems to indicate the common confusion on the
  difference between interfaces and links. For example, technically,
  there's no "corresponding interface" or a link-local address;
  there's only "corresponding link", and you can identify the link if
  you know an interface that belongs to the link as a context, but
  that's not the "corresponding interface of a link-local address".
- using the interface name to represent a link index is an
  implementation specific hack with the implicit assumption of
  one-to-one mapping between links and interfaces (that's often the
  case but architecturally not entirely correct).  so I suspect it's
  not really appropriate for normative and generic text like this

So I suggest revising the above note as follows:

 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 indices of the links that receive the RDNSS
       option(s) for them.  The link zone indices SHOULD
       be represented in the textual format for 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.

Or, as we saw in the previous discussion, if many others don't see
the need for a note like this in the first place, I wouldn't be
opposed to removing it completely.

--
JINMEI, Tatuya

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 7 Oct 2015 09:32:53 +0900

Hi Jinmei,
Thanks for your clarified comments.
I prefer to explicitly note the usage of link-local addresses
to prevent possible problems addressed by Lorenzo.

I think your revised text for the note looks good to me.
One thing to modify is the term of link indices and link zone indices.
I believe that one unified term such as link zone indices will be better as
follows:

       corresponding link zone indices of the links that receive the RDNSS

If it is okay, I will revise the draft to reflect this change.

Thanks.

Paul

---

From: David Farmer <[email-masked]>
Date: Wed, 7 Oct 2015 02:34:39 -0500

...

Those changes all look good to me.  However, I have a few more issues;

1. The first paragraph of the Introduction says the following;

    The purpose of this document is to standardize an IPv6 Router
    Advertisement (RA) option for DNS Recursive Server Addresses used for
    the DNS name resolution in IPv6 hosts.  This RA option was specified
    in an earlier Experimental specification [RFC5006].  This document is
    also to define a new RA option for Domain Name Search Lists for an
    enhanced DNS configuration.  Thus, this document obsoletes [RFC5006],
    which only defines the RA option for DNS Recursive Server Addresses.

The last two sentences of this paragraph probably need to be rewritten 
consistent with the changes already made to the Abstract .  Here is some 
possible text, use it if you like;

    The purpose of this document is to standardize an IPv6 Router
    Advertisement (RA) option for DNS Recursive Server Addresses used for
    the DNS name resolution in IPv6 hosts.  This RA option was originally
    specified in an earlier Experimental specification [RFC5006].  This
    document obsoletes [RFC6106], allowing a higher default value of the
    lifetime of the RA DNS options to avoid the frequent expiry of the
    options on links with a relatively high rate of packet loss, and
    additional clarifications, see Appendix B for details.

2. I'd like to see the Security Considerations section updated with an 
Informational reference regarding "rogue Router Advertisements" [RFC6104].

3. I think the IANA Considerations section should be updated to request 
the references for these options to be updated to point at this document.

http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5

4.  The Acknowledgements section is the text originally in RFC6106.  I'm 
assuming this is just an oversight, as I believe several people have 
made comments worthy of acknowledgement for the new document.

Thanks
-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: 神明達哉 <[email-masked]>
Date: Wed, 7 Oct 2015 10:43:13 -0700

At Wed, 7 Oct 2015 09:32:53 +0900,

> If it is okay, I will revise the draft to reflect this change.

Works for me.

--
JINMEI, Tatuya

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 9 Oct 2015 01:56:43 +0900

David,
I have reflected all of your comments on the revision.
https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-04

Thanks.

Paul

On Wed, Oct 7, 2015 at 4:34 PM, David Farmer <[email-masked]> wrote:

> assuming this is just an oversight, as I believe several people have made
> comments worthy of acknowledgement for the new document.
>
> Thanks
>
> --

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 9 Oct 2015 08:57:46 +0900

Hi Bob and Ole,
I believe we address all of the comments for IPv6 DNS RA Options draft.
Could you go ahead of WGLC?

BTW, I have updated the draft with the affiliation and address of Soohong
Daniel Park.

The draft is:
https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-05

Thanks.

Paul

---

From: Ole Troan <[email-masked]>
Date: Fri, 9 Oct 2015 09:10:13 +0200

Paul,

> BTW, I have updated the draft with the affiliation and address of Soohong Daniel Park.
> 
> The draft is:

Thank you we will slot draft in to the working group last call queue.

Best regards,
Ole

---

From: David Farmer <[email-masked]>
Date: Sat, 10 Oct 2015 12:19:16 -0400

> On Oct 8, 2015, at 12:56, Mr. Jaehoon Paul Jeong <[email-masked]> wrote:
> 
> David,

That looks good.

>> 2. I'd like to see the Security Considerations section updated with an Informational reference regarding "rogue Router Advertisements" [RFC6104].

I found another Informational reference to go in the Security Considerations section regarding "rogue DHCP servers" [RFC7610].

Thanks.

-- 
===============================================
David Farmer                          Email: [email-masked]
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Sun, 11 Oct 2015 02:41:08 +0900

Hi David,
I have reflected your comments on an informative reference
on the revisition as follows:
https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-06

7.2.  Recommendations
...
   It is common for network devices such as switches to include
   mechanisms to block unauthorized ports from running a DHCPv6 server
   to provide protection from rogue DHCPv6 servers [RFC7610].
...

10.2.  Informative References
...
   [RFC7610]        Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-
                    Shield: Protecting against Rogue DHCPv6 Servers",
                    RFC 7610, August 2015.

Thanks.

Paul

On Sun, Oct 11, 2015 at 1:19 AM, David Farmer <[email-masked]> wrote:

> I found another Informational reference to go in the Security
> Considerations section regarding "rogue DHCP servers" [RFC7610].
>
> Thanks.
>
> --