Subject: Linux & draft-gont-6man-slaac-dns-config-issues

From: Fernando Gont <[email-masked]>
Date: Mon, 23 Mar 2015 10:08:27 -0500

Folks,

I'm close to present the aforementioned I-D at the 6man meeting. But
since it's a 5' presentation, I thought it would be helpful to provide
this information here.

This is how Linux fixes this problem (client-side) in Network Manager:

*
<http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=c0d2ad580748a7305bdf882911be3d2a18b6cfc0>
*
<http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=c0048e7b40d5fe6243253179d749d8b7a30179eb>

We cover both items (sanitizing the Lifetime value, and RS probing) in
our I-D, of course.

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 24 Mar 2015 08:20:37 -0500

On Mon, Mar 23, 2015 at 10:08 AM, Fernando Gont <[email-masked]>
wrote:

> <
> http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=c0d2ad580748a7305bdf882911be3d2a18b6cfc0
> >
> *
> <
> http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=c0048e7b40d5fe6243253179d749d8b7a30179eb
> >
>

Limiting the maximum duration of DNS servers announced in the RA seems like
a clear bug in the spec. We should fix that.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 24 Mar 2015 08:26:16 -0500

On Tue, Mar 24, 2015 at 8:20 AM, Lorenzo Colitti <[email-masked]> wrote:

> Limiting the maximum duration of DNS servers announced in the RA seems
> like a clear bug in the spec. We should fix that.
>

To clarify: I mean that we should just strike the text that specifies that
the maximum duration SHOULD be <= 2x the router advertisement interval.
That doesn't make sense to me.

Yes, it's possible that the router lifetime in the RA will expire while the
DNS servers have not yet expired, but there might be another route via
another unexpired router. Nothing else in the RA has such strict
requirements on lifetimes - for example, RIOs have their own lifetimes, and
so do PIOs; both can and usually are longer than the RA interval. Why
should RDNSS be different?

---

From: Jen Linkova <[email-masked]>
Date: Tue, 24 Mar 2015 15:20:09 +0100

On Tue, Mar 24, 2015 at 2:26 PM, Lorenzo Colitti <[email-masked]> wrote:
> the maximum duration SHOULD be <= 2x the router advertisement interval. That
> doesn't make sense to me.

+1
I agree that "<= 2x MaxRtrAdvInterval" limitation is way too strict
and we SHOULD fix this.
However I do not like the idea of sanitizing the received values and
limiting them to 10xMaxRtrAdvInterval. It really sounds like a
micromanaging network administrators in how they run their networks.
There might be valid reasons to have RDNSS/DNSSL Lifetime to be close
enough to how often RAs are sent (what if a router is a DNS server
itself? So if a router does down I don't want a client to use it).
BTW it is also a reason I'm concerned about changing the Lifetime
field semantic.

Actually, the wording of Sanitizing section is not accurate. Clients
do not know MaxRtrAdvInterval value as it's something configured on a
router. I assume it should be "the default MaxRtrAdvInterval value of
600 sec"?

e that the router lifetime in the RA will expire while the
> so do PIOs; both can and usually are longer than the RA interval. Why should
> RDNSS be different?
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

-- 
SY, Jen Linkova aka Furry

---

From: Fernando Gont <[email-masked]>
Date: Tue, 24 Mar 2015 11:22:19 -0500

Hi, Jen,

On 03/24/2015 09:20 AM, Jen Linkova wrote:
> limiting them to 10xMaxRtrAdvInterval.

The thing here is that that's the only way (along with the change of the
semantics of the Lifetime parameter) in which you can fix the problem on
the client side.

> It really sounds like a

If that's de goal, then the Lifetime value should be set according to
the "Valid Lifetime" of the RA, rather than according to MaxRtrAdvInterval

> router. I assume it should be "the default MaxRtrAdvInterval value of

Yes.

Thanks!

Cheers,

---

From: Jen Linkova <[email-masked]>
Date: Tue, 24 Mar 2015 18:24:56 +0100

> semantics of the Lifetime parameter) in which you can fix the problem on

Did I get it right that you are trying to solve one particular case
when people are shooting themselves in the foot?  I do not believe
that every single possible network misconfiguration case should be
solved on the client side, especially at the price of making life
harder for people who know what they are doing.

> the "Valid Lifetime" of the RA, rather than according to MaxRtrAdvInterval

You mean Router Lifetime, don't you?
And yes, it might be equal to Router Lifetime, which might be
significantly lower than 6000 sec (1 hr 40 mins) you are proposing.

>> router. I assume it should be "the default MaxRtrAdvInterval value of

It would be nice to update the text accordingly.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 24 Mar 2015 18:12:12 -0500

Hi, Jen,

> harder for people who know what they are doing.

It is not a network misconfiguration. It's a bug in the spec. And until
the spec is updated and the routers are updated accordingly, the only
thing for a client to do is to sanitize the Lifetime value to a more
sane value. -- that's what Linux is doing.

> You mean Router Lifetime, don't you?

Yes (sorry).

> significantly lower than 6000 sec (1 hr 40 mins) you are proposing.

I think that the specific value that we use is the low-order bit (I can
certainly live with 6000 sec). The high order bit is that there is a
problem to be fixed.

> It would be nice to update the text accordingly.

We certainly will.

Thanks!

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 24 Mar 2015 23:00:25 -0500

> sane value. -- that's what Linux is doing.

I agree there's a bug. Instead of hacking around it in the client, I'd
prefer to update 6106 and fix it in the spec.

FWIW, I don't know who obeys that guidance. The ietf-nat64 network sends
RAs every 5s with a router lifetime of 600 and an RDNSS lifetime of 1800.
Android is perfectly happy to accept that:

22:59:48.747613 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 96)
fe80::998:1 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 96
hop limit 64, Flags [other stateful], pref medium, *router lifetime 600s*,
reachable time 0s, retrans time 0s
  source link-address option (1), length 8 (1): 00:00:5e:00:02:c6
  rdnss option (25), length 40 (5):  *lifetime 1800s*, addr:
2001:67c:370:229::4 addr: 2001:67c:370:229::5
  prefix info option (3), length 32 (4): 2001:67c:1231:998::/64, Flags
[onlink, auto], valid time 2592000s, pref. time 604800s

---

From: Ole Troan <[email-masked]>
Date: Wed, 25 Mar 2015 05:52:10 -0500

> sane value. -- that's what Linux is doing.

at least one random router vendor has the lifetime configurable, and I would expect others do too.
router(config-if)#ipv6 nd ra dns server 1::1 ?
  <200-4294967295>  Lifetime (seconds)

how much of the problem would be fixed if we issued an errata replacing
"the value of Lifetime SHOULD be bounded as MaxRtrAdvInterval <= Lifetime <= 2*MaxRtrAdvInterval”

with e.g. “the value of the Lifetime SHOULD be bounded by Router Lifetime”.

cheers,
Ole

---

From: Dan Lüdtke <[email-masked]>
Date: Wed, 25 Mar 2015 12:13:13 +0100

> with e.g. “the value of the Lifetime SHOULD be bounded by Router Lifetime”.

I think it is in general a good idea to upper limit lifetimes of entities announced in a RA by the lifetime of that RA, given the maximum lifetime of RA is proposed to be changed to 65535 as proposed in draft-krishnan-6man-maxra-01.

Cheers

Dan

---

From: Jen Linkova <[email-masked]>
Date: Wed, 25 Mar 2015 12:46:01 +0100

On Wed, Mar 25, 2015 at 12:12 AM, Fernando Gont <[email-masked]> wrote:
> It is not a network misconfiguration. It's a bug in the spec.

Again, I totally agree that the lifetime value probably should not be
limited to 2x MaxRtrAdvInterval
and it should be fixed. However I strongly object updating RFC6106 with
'The default value of AdvRDNSSLifetime and AdvDNSSLLifetime MUST be at
least 10*MaxRtrAdvInterval'.
I think we shall remove "<2x MaxRtrAdvInterval" limitation in 6106, that's it.

Bounding it to "> 10x MaxRtrAdvInterval" seems to be unnecessary overkill.

BTW most of the router implementations I've seen do allow specifying
lifetime values > 2MaxRtrAdvInterval, so I do believe that in many
cases the problem you are describing could be solved by properly
configuring routers.

> certainly live with 6000 sec). The high order bit is that there is a

I want be able to configure machines with lifetime much lower than
6000 secs, that's my problem with this draft. IMHO,  if LIfetime is <
MaxRtrAdvInterval - that's insane and should not be used, Lifetime <
3x MaxRtrAdvInterval is just "do it on your own risk if you really
know what you are doing", everything else is OK.

---

From: Ole Troan <[email-masked]>
Date: Wed, 25 Mar 2015 06:56:17 -0500

rather:
“the value of the Lifetime SHOULD by default be bounded by Router Lifetime”.

cheers,
Ole

---

From: Jen Linkova <[email-masked]>
Date: Wed, 25 Mar 2015 13:32:21 +0100

> “the value of the Lifetime SHOULD by default be bounded by Router Lifetime”.

Looks good to me. Particularly I like 'by default' part.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 25 Mar 2015 12:42:23 -0500

On 03/24/2015 11:00 PM, Lorenzo Colitti wrote:
> On Tue, Mar 24, 2015 at 6:12 PM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

Agreed. The question here is that if we just modify the router behavior,
in scenarios where routers employ a (too) small Lifetime value, you'd
still hit the problem. (I guess the client side hack would be quicker to
kick in).

> FWIW, I don't know who obeys that guidance. 

I will check with Pavel and report back.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 25 Mar 2015 12:54:19 -0500

Hi, Jen,

> I think we shall remove "<2x MaxRtrAdvInterval" limitation in 6106, that's it.

Fair enough. Although there are two issues here:

1) Allowed bounds
2) Default value

For #1, removing the upper bound is good enough. But there's still #2.

> cases the problem you are describing could be solved by properly

Yes. Thing here is that we should have:

1) Sane defaults
2) The spec should allow for configuring sane Lifetime values

> 6000 secs, that's my problem with this draft.

Fair enough. But the *default* value should be something that actually
works, even if you don't know what you're doing.

Cheers,

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 25 Mar 2015 13:37:47 -0500

I disagree. Why place any limits at all? Why is it incorrect to specify a
higher lifetime for the DNS servers than the router lifetime?

---

From: Jen Linkova <[email-masked]>
Date: Wed, 25 Mar 2015 19:39:37 +0100

> For #1, removing the upper bound is good enough. But there's still #2.

I like Ole's suggestion:
“the value of the Lifetime SHOULD by default be bounded by Router Lifetime”.
As Router Lifetime by default is 3 * MaxRtrAdvInterval, we can use that value...

---

From: Jen Linkova <[email-masked]>
Date: Wed, 25 Mar 2015 19:41:09 +0100

> higher lifetime for the DNS servers than the router lifetime?

Ah, I think the wording is confusing. We should say 'the default value
should be Router Lifetime' and *remove* the upper limit.

---

From: Jen Linkova <[email-masked]>
Date: Wed, 25 Mar 2015 19:44:30 +0100

> As Router Lifetime by default is 3 * MaxRtrAdvInterval, we can use that value...

Clarification (sorry for unclear wording..):
IMHO we should:

1) remove the upper bound at all and just say that Lifetime SHOULD be
> MaxRtrAdvInterval.
2) specify that the default value SHOULD be more or equal than Router
Lifetime (or 3 * MaxRtrAdvInterval or 1800 sec).

---

From: Ole Troan <[email-masked]>
Date: Wed, 25 Mar 2015 13:45:49 -0500

> should be Router Lifetime' and *remove* the upper limit.

that’s what I meant, while probably not what I said. ;-)

cheers,
Ole

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 26 Mar 2015 02:18:51 +0000 (UTC)

________________________________
From: Lorenzo Colitti <[email-masked]>
To: Fernando Gont <[email-masked]> 
Cc: [email-masked]; "[email-masked]" <[email-masked]> 
Sent: Wednesday, 25 March 2015, 0:26
Subject: Re: Linux & draft-gont-6man-slaac-dns-config-issues

On Mon, Mar 23, 2015 at 10:08 AM, Fernando Gont <[email-masked]> wrote:
>Limiting the maximum duration of DNS servers announced in the RA seems like a clear bug in the spec. We should fix that.

To clarify: I mean that we should just strike the text that specifies that the maximum duration SHOULD be <= 2x the router advertisement interval. That doesn't make sense to me.

Yes, it's possible that the router lifetime in the RA will expire while the DNS servers have not yet expired, but there might be another route via another unexpired router. Nothing else in the RA has such strict requirements on lifetimes - for example, RIOs have their own lifetimes, and so do PIOs; both can and usually are longer than the RA interval. Why should RDNSS be different?

/ And the RA RFC says they shouldn't have been:

Router Lifetime
<snip>

Narten, et al.              Standards Track                    [Page 20]
^L
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. ***