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 17:09 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 38E783A09D3 for <ipv6@ietfa.amsl.com>; Mon, 30 Nov 2020 09:09:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 2g9iYP40-arB for <ipv6@ietfa.amsl.com>; Mon, 30 Nov 2020 09:09:12 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E84D53A0FCD for <ipv6@ietf.org>; Mon, 30 Nov 2020 09:09:03 -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 m1kjmfZ-0000JjC; Mon, 30 Nov 2020 18:08:57 +0100
Message-Id: <m1kjmfZ-0000JjC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Subject: 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
In-reply-to: Your message of "Mon, 30 Nov 2020 16:08:37 +0000 ." <2c87c61340de451390a72eb42ff02c59@boeing.com>
Date: Mon, 30 Nov 2020 18:08:53 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/WQSMgwHy-TcVRY9_l1RcIhGUJC4>
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 17:09:14 -0000

> your statements
> don't match with the reality of Duplicate Address Detection.  DAD
> is required if there is not going to be any differentiation between
> LLA generation mechanisms. 

DAD is required, but DAD cannot detect things that aren't there.

If two hosts have different MAC addresses then their EUI-64 IIDs cannot collide.

By and large the implementation of the pseudo random IIDs generators is good
enough the collision don't occur.

Of course, there are plenty of lines that end up in loopback. But in that case
your flags scheme would not help either.

> I want to be able to avoid DAD whenever
> possible - certainly in the aviation domain this is very important.
> And, having the LLA Type field would aid in capitalizing on cases
> when DAD can be avoided.

You are trying to burden every IPv6 system with the specific needs you have
for aviation. That is a bad trade off.

Other link types still have to do DAD, so adding those flags doesn't help at all.

If you know that OMNI IIDs are unique, then just specify that on OMNI links only
OMNI IIDs are used and disable DAD.

I think 6lo does something similar for EUI-64.