Re: [EXTERNAL] Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?

Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com> Mon, 30 November 2020 16:03 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 2F78A3A0B05 for <ipv6@ietfa.amsl.com>; Mon, 30 Nov 2020 08:03:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, 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 UuI3zgul3Sqn for <ipv6@ietfa.amsl.com>; Mon, 30 Nov 2020 08:03:48 -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 967923A0846 for <ipv6@ietf.org>; Mon, 30 Nov 2020 08:03:46 -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 m1kjleO-0000FrC; Mon, 30 Nov 2020 17:03:40 +0100
Message-Id: <m1kjleO-0000FrC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Subject: Re: [EXTERNAL] Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
From: Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: Your message of "Wed, 25 Nov 2020 14:35:53 +0000 ." <1340a6a6fa2b429da0eca973ad6b08bf@boeing.com> <m1khxYl-0000J3C@stereo.hq.phicoh.net> <5531771ca5ff4978b339e69d4202b3e5@boeing.com> <m1kiFfz-0000IfC@stereo.hq.phicoh.net> <c34c0356eadd4bd8a6211fb3a6c3c272@boeing.com> <m1kjkYs-00007iC@stereo.hq.phicoh.net> <9a44be6bcb6140f2b8aa7120b42da430@boeing.com>
In-reply-to: Your message of "Mon, 30 Nov 2020 15:03:45 +0000 ." <9a44be6bcb6140f2b8aa7120b42da430@boeing.com>
Date: Mon, 30 Nov 2020 17:03:36 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/-7MOWxTyefzLaZnz1JiPqNHfkso>
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, 30 Nov 2020 16:03:49 -0000

> Having the Type field
> would allow an administrator to manually configure an
> administratively-assigned LLA without risk of colliding with another
> LLA that was configured via one of the multiple and growing numbers
> of LLA autoconfiguration methods. This is true today, and will
> become even more true as more and more LLA autoconfiguration methods
> are standardized.

Obviously, a manually configured LLA doesn't conflict with EUI-64. We can
assume that an administrator is smart enough to not set the middle two bytes
of the IID to FFFE. So that doesn't happen.

The chance that a manually configured IID collides with a pseudo random is 1 in
2^64. Realistically that doesn't happen.

In practice we also see that nodes with manually configured IIDs have all other
IID mechanisms disabled.

Any future IID mechanism that does not try to use IID bits for other purposes
is pseudo random. So there no risk of collisions.