Re: question on RDNSS, RFC 6106 part 5.1
Pavel Simerda <pavlix@pavlix.net> Tue, 15 May 2012 10:10 UTC
Return-Path: <pavlix@pavlix.net>
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 A203721F8793 for <ipv6@ietfa.amsl.com>; Tue, 15 May 2012 03:10:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.781
X-Spam-Level:
X-Spam-Status: No, score=-1.781 tagged_above=-999 required=5 tests=[AWL=0.818, BAYES_00=-2.599]
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 ogt6Do+WKu5p for <ipv6@ietfa.amsl.com>; Tue, 15 May 2012 03:10:23 -0700 (PDT)
Received: from fox.pavlix.net (fox.pavlix.net [84.246.161.104]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9B021F864A for <ipv6@ietf.org>; Tue, 15 May 2012 03:10:22 -0700 (PDT)
Received: from [192.168.100.33] (unknown [127.0.0.1]) by fox.pavlix.net (Postfix) with ESMTPSA id 5F8451760684; Tue, 15 May 2012 12:10:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=pavlix.net; s=default; t=1337076621; bh=r/IuXF9+kHdvKaXXDB4+b+4oYXJxe40wNpb6qbRuxd8=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:Content-Transfer-Encoding:Mime-Version; b=IcZe3xvfKX5DvXU5WiQsXjrOTpzFFesdBLWlk05oS3Q7tMY9kgWuxif3+Fx9szMgG mdHoHd1KS1qeDViAewPMgpE84XSKFFaUWYiZKe1/CUw6mLJJy8cAAaq2k90POWrzCo ujBy5Q5DwNUCQIuh/SIjogzkR1mxn0YWI8JZuyO8=
Message-ID: <1337076618.3168.7.camel@dragon.pavlix.net>
Subject: Re: question on RDNSS, RFC 6106 part 5.1
From: Pavel Simerda <pavlix@pavlix.net>
To: Teemu Savolainen <tsavo.stds@gmail.com>
Date: Tue, 15 May 2012 12:10:18 +0200
In-Reply-To: <CABmgDzQH=ghCcp-qZ8sDYrj4_aktfiEnX583fy7eFbdOXU8K6A@mail.gmail.com>
References: <1334871165.15947.2.camel@dragon.pavlix.net> <3556F78D-A80E-4975-8E87-3138E3DFCCAA@employees.org> <1335540450.12143.0.camel@dragon.pavlix.net> <CABmgDzQH=ghCcp-qZ8sDYrj4_aktfiEnX583fy7eFbdOXU8K6A@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.4.1 (3.4.1-2.fc17)
Content-Transfer-Encoding: 8bit
Mime-Version: 1.0
Cc: Fernando Gont <fgont@si6networks.com>, 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: Tue, 15 May 2012 10:10:25 -0000
I believe Fernando will forgive me. For the curious, an *unofficial* version of our work can be found here: http://git.pavlix.net/gitweb/?p=rdnss.git;a=summary Cheers, Pavel On Mon, 2012-05-14 at 15:37 +0300, Teemu Savolainen wrote: > 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 > -------------------------------------------------------------------- > >
- question on RDNSS, RFC 6106 part 5.1 Pavel Šimerda
- question on RDNSS, RFC 6106 part 5.1 Pavel Šimerda
- Re: question on RDNSS, RFC 6106 part 5.1 Teemu Savolainen
- Re: question on RDNSS, RFC 6106 part 5.1 Ole Trøan
- Re: question on RDNSS, RFC 6106 part 5.1 Pavel Simerda
- Re: question on RDNSS, RFC 6106 part 5.1 Pavel Simerda
- Re: question on RDNSS, RFC 6106 part 5.1 Teemu Savolainen
- Re: question on RDNSS, RFC 6106 part 5.1 Dan Luedtke
- Re: question on RDNSS, RFC 6106 part 5.1 Pavel Simerda
- Re: question on RDNSS, RFC 6106 part 5.1 Pavel Simerda