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 14:54 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 358973A0CC3 for <ipv6@ietfa.amsl.com>; Mon, 30 Nov 2020 06:54:04 -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 KMzcZ_u-r2aA for <ipv6@ietfa.amsl.com>; Mon, 30 Nov 2020 06:54:02 -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 61A9F3A0418 for <ipv6@ietf.org>; Mon, 30 Nov 2020 06:54:02 -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 m1kjkYs-00007iC; Mon, 30 Nov 2020 15:53:54 +0100
Message-Id: <m1kjkYs-00007iC@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>
In-reply-to: Your message of "Mon, 30 Nov 2020 13:52:13 +0000 ." <c34c0356eadd4bd8a6211fb3a6c3c272@boeing.com>
Date: Mon, 30 Nov 2020 15:53:50 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/dvZhq-k3xYMRBiv1bgp4PFEpepM>
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 14:54:04 -0000

> Having a Type field that unambiguously differentiates the multiple
> LLA config types that could all be used on the same interface avoids
> collisions. 

You keep talking about collisions and confusion, but there is no evidence
that collision among pseudo random IIDs actually happen. Furthermore, pseudo
randoms IID doesn't collide with EUI-64. We have many years of experience with
this.

Similarly, where IIDs are used as identifers, and not as a hack to obtain
a few protocol bits, there is no confusion when it comes to different ways
of generating IIDs. An address is just something to pass to ND to revolve
to an L2 address (for multi-access links). There is no need to know how 
remote host generates it's IIDs.