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

神明達哉 <jinmei@wide.ad.jp> Tue, 26 February 2019 19:13 UTC

Return-Path: <jinmei.tatuya@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 2EAD51228B7; Tue, 26 Feb 2019 11:13:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level:
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 Sw9CHiVWfmYJ; Tue, 26 Feb 2019 11:13:43 -0800 (PST)
Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (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 27F9B129532; Tue, 26 Feb 2019 11:13:43 -0800 (PST)
Received: by mail-wr1-f53.google.com with SMTP id l5so15221527wrw.6; Tue, 26 Feb 2019 11:13:42 -0800 (PST)
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=+X894PO95qi2y6CuxoYk0Wpr7eBesafNnoUOQIbDu3Q=; b=Ks78WIRmYEYq2edtPaXK48EZnnjZU77KihBDDwwQq6QIDeKEMiU+W7oI01tXxcOkS7 MPFO/RyLpVN9Oxcl/dSZTXiPm1a2xQcviQQ2R/JDttrF15bz116m4FTC79cJ3wFe+04L 9EsYbH0z1zjOMtU39eI09DJ4Hvv6tAtk4NqznLm9c1Gr0KeImyTlCZGkRtt0cXEknc+a 7hEDby0WG2el9xdLSc3X/CzxVIgAAhkywt3hryWMU0Kd7yvpVSzQrVZpW83EqEyQEX4f Q0CEmuZGmcaDdLBdZeBeHkYJ7Rjwh0fgT04W2aBcUsJIxCZayqPdAYHTcipTQPx0A7sJ zqgg==
X-Gm-Message-State: AHQUAubDrfnArsGrXCQkm2tWdpULmuQ2cM0Fn1yqZKijrlUH4eGdHSPD Hryl0KF0usuSiWCH0Cy8iPpKQYCTgT90DK8caKElOBMW
X-Google-Smtp-Source: AHgI3IZfRQ3nX/UWIrGldHdFHDK/TBDAzwnUaOjLBqG77NmzAYjGk1I+v7fQXfJGFpHDhfJeX68PWzp7IMYzjGIaIrU=
X-Received: by 2002:adf:f103:: with SMTP id r3mr19227293wro.50.1551208421086; Tue, 26 Feb 2019 11:13:41 -0800 (PST)
MIME-Version: 1.0
References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <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> <F4F90B88-3EED-4AF2-82FE-5F1023A05605@employees.org> <c3562b5b-0eec-636b-3bb1-1b0381109542@si6networks.com> <CAJE_bqdttuCfqbjyVRiyZrUOvckLhWMNr21eMfeXBVmv+UbTkA@mail.gmail.com> <924e562a-82e8-e224-d5c3-859c493657e8@si6networks.com>
In-Reply-To: <924e562a-82e8-e224-d5c3-859c493657e8@si6networks.com>
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Tue, 26 Feb 2019 11:13:29 -0800
Message-ID: <CAJE_bqfHcL202E+t+RdtdnFMdGNX7NbbFQ8v_rcc1u_gd4Yqog@mail.gmail.com>
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
To: Fernando Gont <fgont@si6networks.com>
Cc: Ole Troan <otroan@employees.org>, IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>, Fernando Gont <fernando@gont.com.ar>
Content-Type: multipart/alternative; boundary="000000000000e95c650582d0da11"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/-WWqmzL6LKnjjCQGWATwtk2Ip48>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 26 Feb 2019 19:13:45 -0000

At Tue, 26 Feb 2019 14:35:20 -0300,
Fernando Gont <fgont@si6networks.com> wrote:

> > while we cannot completely ignore non-compliant implementations (if
> > any) in practice, IMO the existence of violators shouldn't be the
> > primary reason for tweaking the protocol.
>
> Which specific tweak are you referring to?

Changing the default value of AdvPreferredLifetime and
AdvPreferredLifetime currently defined in in RFC4861.

>> and I suspect that non-negligible number of implementations support
>> this concept.  BSD's rtadvd does, apparently so does Linux radvd.
>> For these implementations, it's just a matter of configuration,
>> even if the DHCP-PD client and RA advertisement are implemented as
>> different pieces of software: a "script" takes the lifetimes from
>> DHCPv6 PD and dumps the RA configuration by setting AdvXXXLifetimes
>> to that values that decrement in real time.

> I haven't been following developments in this area... but I do remember
> scripts to put the two pieces together, and others doing the same.

The question is specifically how those script put the pieces together.
As long as the "RA piece" supports the "decrement in real time" part
of RFC4861, not using it is a mere bug of those scripts (in that it at
least violates Section 18.2.10.1 of RFC8415).  My point here is that
the existence of buggy implementation (if it exists at all) doesn't
seem to be a strong justification of updating the spec.

> > I don't necessarily oppose to the idea of revising the default prefix
> > lifetimes currently specified in RFC4861.  The growing deployment of
> > mobile environments may justify an update, for example.  But the
> > discussion should be based on accurate understanding of what's
> > possible with the current specification and actual implementations,
> > rather than speculative "red herring".
>
> Tee only thing that I mentioned is that the CPE should be prepared to
> "deprecate" a prefix for "Valid Lifetime". -- a local ISP recently
> reported that they employ DHCPv6-PD times of over a month. IN those
> cases, the spec you reference is complied with, and what I mention above
> is the case: -- if there-s a carsh-and-reboot scenario, the CPE should
> (in theory) be prepared to deprecate a prefix for "Valid LIfetime". --
> whether in practice you can get away with firing a few RAs is a
> different thing.

In that case I'd rather see a point in what Ole keeps saying: either
the ISP should use a much shorter DHCPv6-PD prefix lifetimes in the
first place or they shouldn't change the delegated prefix.  I'm not
saying this to argue there's nothing we can/should do for such a broken
operation.  But this case seems weak as a justification to change the
default lifetime values in RFC4861.

--
JINMEI, Tatuya