Re: question on RDNSS, RFC 6106 part 5.1

Teemu Savolainen <tsavo.stds@gmail.com> Mon, 14 May 2012 12:37 UTC

Return-Path: <tsavo.stds@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571C321F844A for <ipv6@ietfa.amsl.com>; Mon, 14 May 2012 05:37:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.148
X-Spam-Level:
X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uc8sWwA18FKa for <ipv6@ietfa.amsl.com>; Mon, 14 May 2012 05:37:23 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6478621F8449 for <ipv6@ietf.org>; Mon, 14 May 2012 05:37:23 -0700 (PDT)
Received: by dacx6 with SMTP id x6so6061697dac.31 for <ipv6@ietf.org>; Mon, 14 May 2012 05:37:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bxwwfBJ4SVstLiP5ZeNfC3L2m/mWWPMNGseUdh2qYE0=; b=zStfitBeFNEiHc6/pl1Dm1R6FCyaTjjM1ZFWqDa4VNs1Ik1FgOHQayg0gCDElghtho QiJknIxwY/9yNupktgiaVwhSc1Se+q5X6OZ899I6zHbiALdqF96sNfrSEEvwQwtc00Ed A8ps62VXNlcGNxVak95sl6HmozXzLrQhwpS3RJCNBJAIMJmWGaPYEvyFndyQfopKUYCD 64mrr89GVoRxCRTVx3AT5i57c3R//5sCThebKOuEHaoopgQjbTyL+Q3yV565VT1dWV9d WO7C7Ego1HDtIScmAgYYn7vuuaZIi75ysx2fJoo9KGWcz1P/g0zNs5cLWJB/L3nZ7g4Y wmcw==
MIME-Version: 1.0
Received: by 10.68.241.69 with SMTP id wg5mr16483362pbc.148.1336999043045; Mon, 14 May 2012 05:37:23 -0700 (PDT)
Received: by 10.68.38.199 with HTTP; Mon, 14 May 2012 05:37:23 -0700 (PDT)
In-Reply-To: <1335540450.12143.0.camel@dragon.pavlix.net>
References: <1334871165.15947.2.camel@dragon.pavlix.net> <3556F78D-A80E-4975-8E87-3138E3DFCCAA@employees.org> <1335540450.12143.0.camel@dragon.pavlix.net>
Date: Mon, 14 May 2012 15:37:23 +0300
Message-ID: <CABmgDzQH=ghCcp-qZ8sDYrj4_aktfiEnX583fy7eFbdOXU8K6A@mail.gmail.com>
Subject: Re: question on RDNSS, RFC 6106 part 5.1
From: Teemu Savolainen <tsavo.stds@gmail.com>
To: Pavel Simerda <pavlix@pavlix.net>
Content-Type: multipart/alternative; boundary=047d7b339c59069a4804bffe59b6
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 May 2012 12:37:24 -0000

Hi,

So how do we proceed from here?

Would it be enough to discuss and agree an errata for the RFC? Doing full
RFC6106bis might be overkill.

Chairs?

Best regards,

Teemu

2012/4/27 Pavel Simerda <pavlix@pavlix.net>

> Hello,
>
> my proposition is the same as Teemu's or very similar.
>
> 1) I propose to change the default Lifetime from
> [MaxRtrAdvInterval, 2*MaxRtrAdvInterva] to a single
> agreed-upon recommended default value. Almost nobody
> would need to change this default value.
>
> 5*MaxRtrAdvInterval is IMO a good value to start with. This should
> be enough to avoid the need to send RS.
>
> 2) I propose to add at least some best practice about router
> solicitations. Typically, RS should only be used as a last resort.
>
> I suggest to start sending RS at 0.8*Lifetime +/- 0.1*Lifetime (if
> sending RS at all) and repeat let's say every 10-20 seconds.
>
> Note:
>
> Please remember that wireless links *sometimes* lose packets. Please
> remember that wireless links *often* lose multicast packets. Even
> some ethernet switches do.
>
> Example:
>
> MaxRtrAdvInterval = 10 minutes
> AdvRDNSSLifetime = (Default) 5*MaxRtrAdvInterval = 50 minutes
> 0.8*Lifetime = 40 minutes
> 0.1*Lifetime = 5 minutes
>
> Let's simplify the situation and act as if MaxRtrAdvInterval is the
> absolute interval (it is not!).
>
> 00:00 Router Advertisement, Lifetime = 50 minutes
> 00:10 Lifetime = 40 minutes (it could already time out according to the
> current RFC)
> 00:10 Router Advertisement (lost)
> 00:20 Lifetime = 30 minutes
> 00:20 Router Advertisement (lost again)
> 00:30 Lifetime = 20 minutes
> 00:30 Router Advertisement (lost the third time!)
> 00:35 Lifetime = 15 minutes
> 00:35 This is the first time RS can be sent with this best practice
> (the last time is 00:45, counted like that 0.8*00:50 +/- 0.1*00:50)
> 00:35 Router Solicitation
>
> Since then, router solicitations would be issued regularly until
> client recieves RA with RDNSS, connection is cancelled by user or:
>
> 00:50 Lifetime = 0
> 00:50 RDNSS expired
>
> Note:
>
> It is not perfect. The concept of finitely valid RDNSS is quite new.
> There is an open question, when to consider RDNSS information lost. It
> could be:
>
> 1) Last RDNSS from RAs expired.
> 2) Last IPv6 RDNSS expired (RDNSS or DHCPv6)
> 3) Last RDNSS lost (IPv6 or IPv4)
>
> Pavel Simerda
>
>
> On Thu, 2012-04-26 at 14:00 +0200, Ole Trøan wrote:
> > Pavel,
> >
> > I concur with your description of the problem.
> > do you have a proposal for how it can be solved?
> >
> > Best regards,
> > Ole
> >
> >
> > On Apr 19, 2012, at 23:32 , Pavel Šimerda wrote:
> >
> > > Hello,
> > >
> > > I'm starting my work on linux NetworkManager. I've been following
> > > several bugreports during the recent months that all lead to problems
> > > with maintaining the list of recursive nameservers.
> > >
> > > I've already spent quite some time analyzing RDNSS problems and I came
> > > to a conclusion that the problem actually lives in the RFC itself.
> > >
> > > Please look at section 5.1. in RFC 6106. It states:
> > >
> > > MaxRtrAdvInterval <= Lifetime <= 2*MaxRtrAdvInterval
> > >
> > > Considering MaxRtrAdvInterval the maximum time between RAs, setting
> > > Lifetime to MaxRtrAdvInterval IMO constitutes a race condition.
> > > Moreover, any Lifetime in this interval can timeout with just one or
> two
> > > lost RAs.
> > >
> > > This makes RA-based IPv6-only networks drop RDNSS regularly. In many
> > > implementations IPv6 and IPv4 are bound together so that if one of them
> > > fails, the whole link is restarted. This is also the case in
> > > NetworkManager.
> > >
> > > In the current situation, it's not advisable to use RFC 6106 in
> > > production because it can cause problems even to IPv4 applications.
> > >
> > > In the real world, radvd uses Lifetime=MaxRtrAdvInterval by default and
> > > NetworkManager internally adds 10s to the lifetime, that only helps to
> > > avoid the race condition but not lost packets that are common on
> > > wireless networks.
> > >
> > > I appreciate any help to get this right both in the standards and in
> the
> > > software.
> > >
> > > Cheers,
> > >
> > > Pavel Šimerda
> > >
> > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf.org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> >
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>