Re: slaac-renum: New rev of draft-gont-6man-slaac-renum (Fwd: New Version Notification for draft-gont-6man-slaac-renum-08.txt)

Fernando Gont <fgont@si6networks.com> Thu, 21 May 2020 02:33 UTC

Return-Path: <fgont@si6networks.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 CC13C3A09BC for <ipv6@ietfa.amsl.com>; Wed, 20 May 2020 19:33:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 09nvIVnGbCjC for <ipv6@ietfa.amsl.com>; Wed, 20 May 2020 19:33:47 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91BA73A09B5 for <ipv6@ietf.org>; Wed, 20 May 2020 19:33:47 -0700 (PDT)
Received: from [IPv6:2800:810:464:11f:c935:b93f:29b2:80d5] (unknown [IPv6:2800:810:464:11f:c935:b93f:29b2:80d5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 99E08281572; Thu, 21 May 2020 02:33:41 +0000 (UTC)
Subject: Re: slaac-renum: New rev of draft-gont-6man-slaac-renum (Fwd: New Version Notification for draft-gont-6man-slaac-renum-08.txt)
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>, ipv6@ietf.org
References: <158986953939.9945.6882780269741835824@ietfa.amsl.com> <8354111a-7d3f-ecfa-bcf1-baaae27209ee@si6networks.com> <m1jb46e-0000K4C@stereo.hq.phicoh.net> <04027980-51a1-a831-df0c-750c4194333e@si6networks.com> <m1jbRDw-0000IQC@stereo.hq.phicoh.net> <c8cb21e1-ce96-8fe3-8be8-1be225c916a9@gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <7f65a352-a99b-9d54-be30-69caccc123b3@si6networks.com>
Date: Wed, 20 May 2020 23:19:06 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <c8cb21e1-ce96-8fe3-8be8-1be225c916a9@gmail.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/AiPYVcPNGdWJMw0kbHNqbJ-ZSXQ>
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: Thu, 21 May 2020 02:33:51 -0000

Hi, Brian,

On 20/5/20 17:57, Brian E Carpenter wrote:
[....]
>>
>> So in my opinion, the algorithm has to work correctly without knowledge
>> of ULA.
>>
>>> When a prefix is missing, that's an indication that the prefix has
>>> become stale. Now, you might process the RAs irrelevant of ULA nad
>>> non-ULA, and it would also be fine.
>>>
>>> But the logic here is that it is better to have one stale address of
>>> each type, than no address of that type. If you want, this is the
>>> algorithm being more conservative.
>>
>> Again, without special treatment of ULAs, the algorithm is dangerous. It can
>> take an RA with a ULA to invalid all non-ULA prefixes.
> 
> I'm finding this hard to understand, since the text says:
> 
>    "o  Only RAs that advertise Global Unicast prefixes may deprecate
>        Global Unicast Addresses (GUAs), while only RAs that advertise
>        Unique Local prefixes may deprecate Unique Local Addresses (ULAs)."
> 
> Perhaps that should be reformulated with MUST NOT terminology to make it
> clearer:
> 
>     o  RAs that advertise Global Unicast prefixes MUST NOT deprecate
>        Unique Local prefixes, and RAs that advertise Unique Local
>        prefixes MUST NOT deprecate Global Unicast prefixes.
> 
>> So, the ULAs need to be treated specially to make it to work at all.
> 
> Yes, of course. They *are* special. They work even if the WAN side drops
> and even if the WAN prefix changes.

FWIW, this text is meant to describe what the algorithm does, as opposed 
to actually specifying anything. i.e., it's goal is to "explain" the 
algorithm. I don't mind changing the text, though.


>> This
>> locks us into a situation where ULA, non-ULA is all that can exist.
>> Introducing a third type of addresses would cause this algorithm to fail.
> 
> Yes. If there was a 4th type of address (we already have three, counting
> link-local), every router in the universe would need a fix.

In fact, if there was a 4th type of address probably all nodes would 
need a fix (including source address selection and others).

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492