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

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 11 Aug 2015 20:55:48 +0900

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/

Before we publish this document, I would like it to answer one more
question: are link-local addresses valid in an RDNSS option? There is
nothing saying that they are not valid, but on the other hand, the text
about the "resolver repository" says nothing about scope IDs.

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 Aug 2015 22:02:20 +1000

> about the "resolver repository" says nothing about scope IDs.

I think link-local addresses should be valid for RDNSS options.
They're valid for applications to use (as per RFC4007), and mean that
an on-link resolver service would not be impacted by GUA or ULA
renumbering events.

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 11 Aug 2015 21:05:29 +0900

> an on-link resolver service would not be impacted by GUA or ULA

Saying that link-local addresses are valid seems like a reasonable position
to take, yes. I'd like us to note it explicitly in the document, though.

---

From: 神明達哉 <[email-masked]>
Date: Tue, 11 Aug 2015 09:05:04 -0700

At Tue, 11 Aug 2015 21:05:29 +0900,

> to take, yes. I'd like us to note it explicitly in the document, though.

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.  It might even look trivial, but I still think it's better
to clarify that explicitly.  (And, I wouldn't be surprised if someone
disagrees with this interpretation that makes most sense to me quite
obviously.  In that case it's even a stronger reason why this should
better be clarified explicitly).

--
JINMEI, Tatuya

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 Aug 2015 19:18:49 +0200

> better be clarified explicitly).

it can’t possibly apply to a different link as there wouldn’t be any way to signal that.
3646 is silent on the issue of link-locals, my preference would be to stay silent in 6106bis too.
it isn’t obvious to me that common resolver libraries support link-local addresses?

cheers,
Ole

---

From: Tore Anderson <[email-masked]>
Date: Tue, 11 Aug 2015 19:59:47 +0200

* Ole Troan

> it isn’t obvious to me that common resolver libraries support

Hi Ole,

glibc does at least, but for it to work the the interface ID must be
written to /etc/resolv.conf. That's a corner case that isn't
necessarily immediately obvious to the developers of the piece of
software that interprets RAs.

I can't help but think that if RFC6106 had explicitly mentioned this
corner case, bugs such as
https://bugzilla.redhat.com/show_bug.cgi?id=720001 could have been
prevented. So I'm with Lorenzo on this one.

Tore

---

From: 神明達哉 <[email-masked]>
Date: Tue, 11 Aug 2015 11:04:17 -0700

At Tue, 11 Aug 2015 19:18:49 +0200,
Ole Troan <[email-masked]> wrote:

> > address belongs to. [...]
>

I personally agree, but I still thought it's better to be noted
explicitly *if we mention link-locals explicitly*.

> it isn’t obvious to me that common resolver libraries support link-local addresses?

It would depend on implementation details and on the definition of
"support", but I wouldn't be surprised if it looks like working as
long as the host implementation supports the concept of the default
zone IDs and enables the feature (although in that case it could use
the wrong link zone).  In this case, the resolver library doesn't need
any extra "support" beyond the generic support for IPv6.

In addition, from a quick look, FreeBSD's libc implementation
internally uses getaddrinfo(), so it should work perfectly fine with
handling link-local address for the correct link zone, if, for
example, the textual link-local address specified in /etc/resolv.conf
uses the extended textual format for scoped addresses described in
RFC4007.  And, its rtsold seems to support that textual format.

--
JINMEI, Tatuya

---

From: David Farmer <[email-masked]>
Date: Tue, 11 Aug 2015 14:41:41 -0500

> prevented. So I'm with Lorenzo on this one.

I'm fine with link-locals being allowed or not, but they should be 
discussed either way, in hopes of avoiding bugs or incompatibilities.

I think I prefer to allowing them from a protocol perspective and maybe 
a future operational document could make recommendations about if it is 
good idea to actually use link-local DNS servers or not.

-- 
================================================
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: Lorenzo Colitti <[email-masked]>
Date: Wed, 12 Aug 2015 10:12:56 +0900

> prevented. So I'm with Lorenzo on this one.

Yp, this is non-obvious. The Android RDNSS implementation also didn't
properly support-local DNS servers and we had to fix it in M. If the RFC
had stated this these bugs might not have happened.

When we did fix it, our assumption was mostly that the router(s) in
question were announcing link-local DNS due to a bug and that even once we
fixed the OS, it wouldn't actually work. We were surprised that (on some of
the routers, at least) it did.

---

From: Mark Smith <[email-masked]>
Date: Wed, 12 Aug 2015 11:14:23 +1000

On 12 August 2015 at 02:05, 神明達哉 <[email-masked]> wrote:
> address belongs to.
>  In the case of router advertisements, I guess it

I don't disagree with clarifying it, however RAs themselves are
link-local scope or local to the link. With exception to these
options' possible values, the other parameter values that RAs provide
are all specific to the link the RA arrived over.

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.

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 12 Aug 2015 10:18:24 +0900

> context of an RA is the link it was sent over.

+1

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 19 Aug 2015 11:01:24 -0400

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

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