IETF Logo Mail Archive

Re: Errata for RFC4862

Mark Smith <markzzzsmith@gmail.com> Tue, 10 January 2017 21:45 UTC

Return-Path: <markzzzsmith@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 9D76B1295BE for <ipv6@ietfa.amsl.com>; Tue, 10 Jan 2017 13:45:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Level:
X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3G45RJ3SUwl3 for <ipv6@ietfa.amsl.com>; Tue, 10 Jan 2017 13:45:50 -0800 (PST)
Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 D7F1E129DAB for <ipv6@ietf.org>; Tue, 10 Jan 2017 13:45:49 -0800 (PST)
Received: by mail-vk0-x22f.google.com with SMTP id x75so44194174vke.2 for <ipv6@ietf.org>; Tue, 10 Jan 2017 13:45:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hghfPEPVEqegBRZVAh6DRPjxVWYGEyTJn0r2VEkhO8I=; b=WOWWqGxAx+K3KME2We5KHeBLcjyVTADGSS8SveRaDrtyANZ3DaCxX3nDbt03TVnU9q Iz4J9E2e4NuV2J1OHi+HH1fzy71mHRU93973H/jGxL+pZiqJeXqpGaQoIXz52Et8ROnM Zg3cGNMKfj+Bmw+FGOE5ss0Ycns1HJCJlBPa8IrN5Ng0GczTWWiTg+4mggrpnVWT0oiC U2iuX8J+Vb7n5kxgtCFu6N8WIqyPLMC2HOWvti5mvSNsm7JJYt76HTSomUw+2L/ZZ6Kj hMPKcGY8QJBDnYQuO0JK6lG5DZ7G5di5Tma6w+zvDk7fXegpOYOTII/vwGXI/U04j7V+ /BkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hghfPEPVEqegBRZVAh6DRPjxVWYGEyTJn0r2VEkhO8I=; b=bbVkO0l6wAO1uNI4xXi67D0rKffBnmyN0doEYpVuXv5XNvwYQ0I2e9M8tO2UsEYjU6 pwGa6vTn9PMBGTBLCaAtLaa0ldvdN6uzQ6WwpJVm+XwfpMNLGSekMT7QoCneBHdbmcgF iV0XZwkyKgzPV99lQNcAK4yHLmh89gUdl8dftv2ejzeGpeOyrbOsRL6Ph5j3BiWIvLHN yZZL5Fbor+WKaMvP6CCeg8wErw7dA7D29BSFI3bD4hU9TjljJKSvwx2KCv+xrrUa9O1I lOqlLCimJzrevSL4mMrzj/W6errVIme+z8jLLbrAcFSezQ/0mfCWF8osarswCKyTYF9H toHg==
X-Gm-Message-State: AIkVDXJUkLdIijB8aUBUztKacsuEwMNxXebHdyqXbqyqrbHBGbQ2+L1nv2LNNPd8GVCB5pHcVRRLpidyZTtlxg==
X-Received: by 10.31.238.6 with SMTP id m6mr2186472vkh.28.1484084748909; Tue, 10 Jan 2017 13:45:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.2.235 with HTTP; Tue, 10 Jan 2017 13:45:48 -0800 (PST)
Received: by 10.176.2.235 with HTTP; Tue, 10 Jan 2017 13:45:48 -0800 (PST)
In-Reply-To: <CAJE_bqesE0Y+0mpmkWHji+JGhPAtmWJx4LjA4Kz+8ij+Li0E4g@mail.gmail.com>
References: <CAO42Z2xH9wqXKFjtAbv6isQ3cG1=FNUmkNFq2DGJdqj9BFDVaQ@mail.gmail.com> <E459F5B0-D088-4D74-B92A-9A8671249716@employees.org> <4921ADB7-42A6-443E-B639-A3F6F300B13C@jisc.ac.uk> <CAJE_bqesE0Y+0mpmkWHji+JGhPAtmWJx4LjA4Kz+8ij+Li0E4g@mail.gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Wed, 11 Jan 2017 08:45:48 +1100
Message-ID: <CAO42Z2xWT2gNmwjALCLbxXwBw94nmkn-if4cXXBECAsRLPxxxQ@mail.gmail.com>
Subject: Re: Errata for RFC4862
To: 神明達哉 <jinmei@wide.ad.jp>
Content-Type: multipart/alternative; boundary="94eb2c14971446b8480545c468b7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/FTdv0is_G0nrQgALinhRLAoLCdk>
Cc: 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
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, 10 Jan 2017 21:45:51 -0000

On 11 Jan. 2017 6:32 am, "神明達哉" <jinmei@wide.ad.jp> wrote:

At Tue, 10 Jan 2017 12:45:27 +0000,
Tim Chown <Tim.Chown@jisc.ac.uk> wrote:

> My recollection of running renumbering experiments is that it’s the
> Preferred Lifetime that matters, i.e. when that is set to zero for a
> prefix, the prefix is marked as deprecated.  So when renumbering,
> you run with two prefixes advertised, old and new, setting the
> Preferred Lifetime to 0 on the old prefix (even though the Valid
> Lifetime is set to 2+ hours), so that the address with the new
> prefix is used for newly initiated communications (as per RFC 6724,
> Rule 3).

Yes, but I guess what Ole tried to point out (which I agree with) is
that the valid lifetime will also have to decrease to 0 eventually,
and this original text of RFC4862 allows such decrease operation
without requiring explicit authentication if done by gradually:


If that is the case (and I don't think it is, it creates the DoS
opportunity that all other >2 hr checks attempt to defeat), then I think it
needs to be far better and more explicitly explained, including the
sequence of events.

What is the use case that can't be achieved by setting the preferred
lifetime to zero, immediately deprecating the addresses (and a VL of 2
hours to cause them to disappear shortly).

If it is to remove addresses immediately from a host by setting the RA PIO
VL to zero - actually that's not going to work, because seeing VL to zero
will fail the greater than remaining time check.

It would be very laborious to try to remove an address by only being able
to send a VL greater than the address's remaining time. Letting the address
age out/expire naturally by itself by stopping sending the RA PIO for the
prefix wolf be easier and I think quicker.

Regards,
Mark.


> >>     1.  If the received Valid Lifetime is greater than 2 hours or
> >>         greater than RemainingLifetime, set the valid lifetime of the
> >>         corresponding address to the advertised Valid Lifetime.



--
JINMEI, Tatuya

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

v2.23.0 | Report a Bug | By Email