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

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Thu, 28 May 2020 11:24 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.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 30CA83A0DAF for <ipv6@ietfa.amsl.com>; Thu, 28 May 2020 04:24:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.622
X-Spam-Level:
X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=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 Z17OMHlok4fI for <ipv6@ietfa.amsl.com>; Thu, 28 May 2020 04:24:27 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 379573A0DAE for <ipv6@ietf.org>; Thu, 28 May 2020 04:24:26 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jeGe7-0000LPC; Thu, 28 May 2020 13:24:23 +0200
Message-Id: <m1jeGe7-0000LPC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Cc: Fernando Gont <fgont@si6networks.com>
Subject: Re: slaac-renum: New rev of draft-gont-6man-slaac-renum (Fwd: New Version Notification for draft-gont-6man-slaac-renum-08.txt)
From: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
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> <a2710dfc-ec66-9e9f-8a2b-0fa0ad7e2b32@si6networks.com> <m1jc9hu-0000K8C@stereo.hq.phicoh.net> <772d4a92-9a4d-ef71-dac5-cb944acba925@si6networks.com> <m1jdEpw-0000IEC@stereo.hq.phicoh.net> <3da7df4d-a191-d9d9-6d00-b9c30d7b03d1@si6networks.com> <m1jdcCQ-0000IUC@stereo.hq.phicoh.net> <6c96a3a5-d7fd-c5bc-6f37-2dd142a7037b@si6networks.com>
In-reply-to: Your message of "Thu, 28 May 2020 00:42:14 -0300 ." <6c96a3a5-d7fd-c5bc-6f37-2dd142a7037b@si6networks.com>
Date: Thu, 28 May 2020 13:24:21 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/CAxz62h8B_WYWO8wHbvbDhvXJCI>
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, 28 May 2020 11:24:29 -0000

>> I'm saying it is fragile, because it will fail if a third type of address
>> is in use.
>
>That's an overstatement. Firstly, it's impossible to tell what may be 
>specified in the future, and how (whatever is specified) may work with 
>existing standards. For example, it is impossible to tell how a new 
>address type may work (or break) with source address selection (RFC6724).
>
>Unless you can't predict the future, you can't say "it will fail" 
>(modulo the fact that, failing requires a bunch of other conditions).

I described how ULAs essentially require no host changes (i.e., it would
work fine with the old policy table). I can think if one corner case where
the policy table would make a difference.

So to be specific, I expect that in the future, some organisations with
either use public IPv6 address as if they were ULAs, or use two different
ULA prefixes for different perposes.

These two use cases can be analysed in the context of your proposal.

>> Packets gets lost all the time. It is very fragile if we have one part
>> of a standard that says that you can split RAs and then another where hosts
>> will fail in unexpected ways if you do that. In my book that's just a bad
>> standard.
>
>This document says "SHOULD NOT". That means "don't, unless you really 
>know what you are doing".

This is why I call it fragile. We have SHOULD NOT, and then operators have
to be aware of obscure corner cases of host behavior to evaluate the 
SHOULD NOT.

This is in particular bad, because aternatives do exist.


>We have kept it as "SHOULD" because it doesn't warrant a MUST. As noted: 
>worst case scenario you unprefer an address.

Which as I described before, in the case an organisation has three different
type of addresses will lead to failure. So it is not a benign as you make
it out to be.

>Please see the rules in RFC6724: "longest match" is Rule #8 -- the 
>*last* one. And it is Rule #2 (which needs to be ULA-aware) that 
>guarantees that ULA will be used for ULA.
>
>So your statement is certainly incorrect.

Rule #2 says 'Prefer appropriate scope', however ULAs have global scope
(see Section 3.1). So it is not clear to me what you are try to say here.