IETF Logo Mail Archive

Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

Lorenzo Colitti <lorenzo@google.com> Tue, 26 February 2019 14:20 UTC

Return-Path: <lorenzo@google.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96AB1128CE4 for <v6ops@ietfa.amsl.com>; Tue, 26 Feb 2019 06:20:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Level:
X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvsLc8tg20fY for <v6ops@ietfa.amsl.com>; Tue, 26 Feb 2019 06:20:12 -0800 (PST)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3077130EA0 for <v6ops@ietf.org>; Tue, 26 Feb 2019 06:20:09 -0800 (PST)
Received: by mail-io1-xd2b.google.com with SMTP id e1so10611640iok.1 for <v6ops@ietf.org>; Tue, 26 Feb 2019 06:20:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6C+lNwplNCxFv81StS0vD2fsY/J9dmoZ9oVPYOCTZaE=; b=L1tQZe/rJErfHLM/8uF1agM8CHji7XvChhe0r+O+uS4giiqipf7zMQCCJ7BFM2Aw9r uuy74Q3t4Ekj/tFYkqai3dF20b58dQ4NALCYq3/MFEt5b0wYUV7qk/ZtugtMVu8TQ9uQ a6uDm6bu77nPl2Trk6VuWeHZbkx/sd3pSSHKPBTzoCwSO+GOyNLxaAPm+S+lJgCiFdzU Q2i1/2y1vWXEqJyBXjDqpZiOlWFO1SLgwIUlfmW2WCe+IzvcAwX7aMSSnumAcH4UsTX0 R1EpeZqKw3Z12Wzdq7vEZVIw2U02aiZBqGu3JCQBIzO0gTV+7MrgoYvDmquS1BXGGaF9 7b+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6C+lNwplNCxFv81StS0vD2fsY/J9dmoZ9oVPYOCTZaE=; b=S+9UVORKhA7HPTU3XCNWwQoKVbcxoKNPx8P4waALIRWPuQ+dgTizF/oaYteQNaZmaI LCvYKpBTDq0nxVqr47aA9You13rdIG6WDxgMfB4qxg8SoRet8Op+x668q24tWBXl4sYC 1fSovkxESkJ3zX9eqgeKBELbd29ZdQjxFN2CzK+iWCYB0C9MfkO5uZd05RdgJ0CKlbuc o9Ogx1WNRTe74iGkrNGpgqQtSFBMNUPI6SygxiA0z5W3IfCe3KSZsEdvs2flH3U0nbwv 37+xOoojpqw22+RP8z5O9YODR2VWABqpygmQ9AW2yhP2QCsrwilHRE3P5b/GQ7idPbA+ nVdA==
X-Gm-Message-State: AHQUAuai0X+us6Kk7eHXnqN5WS9MK2Ma64mmMZT9TX2BG5Uqmt/WPFI8 YGfZl68YRQzjzB7iq1zR+wrZ1TT+iCO8dnnNSqcdUw==
X-Google-Smtp-Source: AHgI3IYI9OqKd4kBeAznRB55mS7aMT9SRsO/iWj0jnV/0e5dtA5Y9NFRQuNi8hzHNyynFL/GvCMuU5ZrjrFb3Sq/Gbo=
X-Received: by 2002:a5e:c605:: with SMTP id f5mr12977992iok.252.1551190808779; Tue, 26 Feb 2019 06:20:08 -0800 (PST)
MIME-Version: 1.0
References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <CAKD1Yr0HBG+rhyFWg9zh0t3mW486Mjx9umjn+CRqAZg4z9r0dg@mail.gmail.com> <20190221073530.GT71606@Space.Net> <CAO42Z2wmB2W52b4MZ2h9sW5E9cQKm-HRjyf--q8C26jezS7LXQ@mail.gmail.com> <a73818d31db7422b99a524bc431b00ed@boeing.com> <CAO42Z2z9-48Gbb_Exf+oWUqDO=axSLpZBtqeDcxkAoFq5OziGw@mail.gmail.com> <CALx6S3624hnGauG1HaSWPMvQw0t2Q5R3gb8W4R8w3kuK7dcrWQ@mail.gmail.com> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> <CAHL_VyD34V=TRcsCp0DOO9HJNHyy5xkiMQ_cZoBa7zTE4fe5OA@mail.gmail.com> <ead01e0a-9211-7944-88d6-ae8d037c03a8@si6networks.com> <FB8B77EE-CC16-4418-BB5E-D44EE66D6B72@jisc.ac.uk> <29dcc6ed-03f6-3ead-6866-eecbefdf1483@si6networks.com> <899A1249-D3D9-4824-8B2E-7E950FBB316A@jisc.ac.uk> <3c265000-8651-817d-f19f-cf7ccd8fd48e@si6networks.com>
In-Reply-To: <3c265000-8651-817d-f19f-cf7ccd8fd48e@si6networks.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Tue, 26 Feb 2019 23:19:56 +0900
Message-ID: <CAKD1Yr1ic9OS8rJQJcuT8=D6Abux+OsDcBH1L3wTHLK98RneKg@mail.gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Cc: Tim Chown <Tim.Chown@jisc.ac.uk>, IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>, Fernando Gont <fernando@gont.com.ar>
Content-Type: multipart/alternative; boundary="00000000000023763d0582ccc189"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/9kkkEXeqVtTL_uSBQq1OqQ6w4Ic>
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Feb 2019 14:20:14 -0000

On Tue, Feb 26, 2019 at 7:59 PM Fernando Gont <fgont@si6networks.com> wrote:

> >>                             Default: 2592000 seconds (30 days), fixed
> >>                             (i.e., stays the same in consecutive
> >>                             advertisements).
> >
> > So given that document is 12 years old, with that default copied from
> one that is 21 years old, is an update required?
>
> That's my take.
>
> > And if so, to what?
>
> At the very least, never larger than the "Router Lifetime". Please see:
>
> https://github.com/fgont/draft-slaac-renum/blob/master/draft-gont-6man-slaac-renum-02.txt
>  (particularly Section 5.1.1)
>

Disagree that prefix lifetimes must never be larger than the router
lifetime, particularly because 0 is a perfectly valid default lifetime.

Also looking at section 5.1.1, the default MaxRtrAdvInterval of 5 minutes
violates the best practices in RFC 7772.

v2.23.0 | Report a Bug | By Email