Re: Extending a /64

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Mon, 09 November 2020 10:30 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 A70C03A0E29 for <ipv6@ietfa.amsl.com>; Mon, 9 Nov 2020 02:30:57 -0800 (PST)
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 6eSaOAoXSjKz for <ipv6@ietfa.amsl.com>; Mon, 9 Nov 2020 02:30:56 -0800 (PST)
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 276B23A0E1F for <ipv6@ietf.org>; Mon, 9 Nov 2020 02:30:55 -0800 (PST)
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 m1kc4Ri-0000KVC; Mon, 9 Nov 2020 11:30:46 +0100
Message-Id: <m1kc4Ri-0000KVC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Subject: Re: Extending a /64
From: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <005ECBB3-088B-4363-BB53-8D4AD25CA3D2@employees.org> <da13ad27-7493-c350-5a0b-38776f5e065e@gmail.com> <634E73FD-5809-4C1E-AE8C-C94D9CDE034E@employees.org>
In-reply-to: Your message of "Mon, 9 Nov 2020 08:21:33 +0100 ." <634E73FD-5809-4C1E-AE8C-C94D9CDE034E@employees.org>
Date: Mon, 09 Nov 2020 11:30:45 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/mtJnlAiPaeMCeaVy4SsqbIbSTZQ>
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: Mon, 09 Nov 2020 10:30:58 -0000

In your letter dated Mon, 9 Nov 2020 08:21:33 +0100 you wrote:
>Brian,
>> You need
>> 
>> R-5: Preserve existing security solutions
>> R-6: Preserve existing privacy solutions
>> R-7: Preserve e2e transparency
>
>Yes. Although I'm a little unsure what you think of regarding R-5?

One thing to consider, though I don't know how to formulate that as a
requirement is that if we change the lenght of IIDs, does that render all
devices that only support 64 bit IIDs obsolete?

I.e., should we make changes to IPv6 that render all currently conforming
implementations obsolete?

Of course we can create a nice bit of operatial chaos if we make shorter IIDs
an optional feature.

So the requirement should be something to the effect that a change to the
IPv6 standard that affect all hosts requires use cases that cannot be
solved without updating all hosts.