IETF Logo Mail Archive

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

Jan Zorz - Go6 <jan@go6.si> Wed, 13 February 2019 16:40 UTC

Return-Path: <jan@go6.si>
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 0CA291200B3 for <ipv6@ietfa.amsl.com>; Wed, 13 Feb 2019 08:40:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=go6.si
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 dZnGvEfC73en for <ipv6@ietfa.amsl.com>; Wed, 13 Feb 2019 08:40:39 -0800 (PST)
Received: from mx.go6lab.si (mx.go6lab.si [IPv6:2001:67c:27e4::23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC2931200ED for <ipv6@ietf.org>; Wed, 13 Feb 2019 08:40:38 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.go6lab.si (Postfix) with ESMTP id 4E23566077 for <ipv6@ietf.org>; Wed, 13 Feb 2019 17:40:37 +0100 (CET)
X-Virus-Scanned: amavisd-new at go6.si
Received: from mx.go6lab.si ([IPv6:::1]) by localhost (mx.go6lab.si [IPv6:::1]) (amavisd-new, port 10024) with LMTP id WS7wjvHrrWn6 for <ipv6@ietf.org>; Wed, 13 Feb 2019 17:40:36 +0100 (CET)
Received: from mail.go6.si (mail.go6.si [IPv6:2001:67c:27e4::61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.go6.si", Issuer "Let's Encrypt Authority X3" (not verified)) by mx.go6lab.si (Postfix) with ESMTPS id 59D116602B for <ipv6@ietf.org>; Wed, 13 Feb 2019 17:40:36 +0100 (CET)
Received: from ISOC-BMDKQ4.local (unknown [IPv6:2001:67c:27e4:102:182a:e622:682:93c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Jan Zorz", Issuer "COMODO RSA Client Authentication and Secure Email CA" (not verified)) (Authenticated sender: jan) by mail.go6.si (Postfix) with ESMTPSA id 77E878054D for <ipv6@ietf.org>; Wed, 13 Feb 2019 17:40:34 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=go6.si; s=mail; t=1550076034; bh=5tfIY1CVOdahroH2Xt9QTB37jnrojFf3Su0/2cbFjZ0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=LmLLC15k9hhFXe6zibi046Q1z4K7yQx8cTzmxvYF7RACZlZEdRmgeM2Ab+Du9/kGK fGZtvuy351OyjNkGQHJaM6IKh2OBbpC7p0JpO598zAGM5fc9vo07AMteLPKL3BtPTQ 1WdNR0Wldw2k1fQu2WZSB1nymXQX1GORDiQquBLM=
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
To: ipv6@ietf.org
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <ac773bb5-0da8-064b-d46b-3a218b8c9e7a@si6networks.com> <CFAEACC4-BA78-4DF9-AD8A-3EB0790B8000@employees.org> <a4f6742e-f18e-3384-d4cc-06bfab49101f@si6networks.com> <FEFA99C2-4F09-4D8F-8D51-C9D9D7090637@employees.org> <a484d5de-0dce-a41a-928e-785d8d80d05d@si6networks.com> <A40C5116-9474-4F2B-BD94-F57D155ECD4C@employees.org> <b05e3872-d63b-108c-6c00-21b951dad263@si6networks.com> <A9FBBED3-A858-4BB1-A02A-2A06CBEB7662@consulintel.es> <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com> <A0201A4B-77BB-40F4-A35F-F1491732D537@consulintel.es> <749b121f-cac5-30e0-686c-9f7f29313d91@huitema.net> <2BAD7ADA-6940-45EA-B7DD-0D82B9E95A05@employees.org> <6440.1549227369@dooku.sandelman.ca> <85C3CE49-93CC -48E1-94FB-46A0203783A2@employees.org> <391AE39D-F754-47A8-B20A-3AEC4C174B9F@huitema.net> <DFDEF631-B6EF-440E-A245-261FBC780BBB@employees.org> <38eb8b47-6ae9-f256-81b4-3313c7f0a83f@si6networks.com>
From: Jan Zorz - Go6 <jan@go6.si>
Message-ID: <3d609c48-399f-b3b4-385e-50a58b9b72b3@go6.si>
Date: Wed, 13 Feb 2019 17:40:34 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <38eb8b47-6ae9-f256-81b4-3313c7f0a83f@si6networks.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/N1CRHEwGtqf690_GUJ3LbXltP4w>
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: Wed, 13 Feb 2019 16:40:40 -0000

On 13/02/2019 03:37, Fernando Gont wrote:>> Well, this is caused by the 
ISP, so perhaps the call should be the
>> recommended action. :-)
> 
> Not necessarily. There is no requirement that the ISP leases the
> same prefix if the client just asks a new prefix.

Seriously? Same DUID should get the same PD inside the lifetime cycle 
(whatever lifetime is set, 1h or 30 years).

No requirement? Well, then we need one, do we?

Cheers, Jan

v2.23.0 | Report a Bug | By Email