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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Mon, 30 November 2020 17:39 UTC

Return-Path: <Fred.L.Templin@boeing.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 98DBA3A0EFC for <ipv6@ietfa.amsl.com>; Mon, 30 Nov 2020 09:39:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com
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 PsBBmJ41tEZH for <ipv6@ietfa.amsl.com>; Mon, 30 Nov 2020 09:39:09 -0800 (PST)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2774D3A0FB1 for <ipv6@ietf.org>; Mon, 30 Nov 2020 09:39:07 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 0AUHd5iS012317; Mon, 30 Nov 2020 12:39:05 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1606757945; bh=cqfM5vbW1LwmLWSj4ien8BmP8Gc6Z/5zqId+3GD6eoE=; h=From:To:Subject:Date:From; b=sbeUo9lA6vB+gegV5UamJnUe8dOaxa5V20dfZD4prAWhn3MUZgSIxTq1hVr7+x4Io NLqAlZuQcAE8eEkSbgjak8fdMBK+mhugQGcw2ZCyokAHnPnhDnbtfUrkZlz8F73Ozs kzCaQEDhVg6Bietsv9olYWRWNzLNQux75cCjHr6TPWyN7ktZxuWOkDjk7UQfu2G2hc nO9ti6u1Qs6gxxzIP36o3FuTnRo9TVeUMXGqs3QE98sNTn2t5b2/EBF6d0NWzbc0Hx A3GpTKz7aIMIFLOPRU8TCyn4OjRFfvxXtbnZs5oJ1P4Q2I5Qp80opbIYsX5RMXmdjy T38XFVBFbysvA==
Received: from XCH16-07-11.nos.boeing.com (xch16-07-11.nos.boeing.com [144.115.66.113]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 0AUHcpu1011995 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 30 Nov 2020 12:38:52 -0500
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-11.nos.boeing.com (144.115.66.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Mon, 30 Nov 2020 09:38:50 -0800
Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Mon, 30 Nov 2020 09:38:50 -0800
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
Thread-Topic: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
Thread-Index: AdbHPO7yBmucpkuCTXSTQb2WL3XhTg==
Date: Mon, 30 Nov 2020 17:38:50 +0000
Message-ID: <c65ee3e9ad9847aaaafaf8dea5a689f9@boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 9BB090F7EE7850E590A651F27FDD6AA17BD5481FA5E46CC8748D1A96A347E0002000:8
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/aa1SodKQlhq8FjvkolPMzo7I1ow>
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:39:12 -0000

Philip - see below:

> -----Original Message-----
> From: pch-b9D3CB0F5@u-1.phicoh.com [mailto:pch-b9D3CB0F5@u-1.phicoh.com] On Behalf Of Philip Homburg
> Sent: Monday, November 30, 2020 9:09 AM
> To: ipv6@ietf.org
> Cc: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
> 
> > 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.

DAD is a "cry in the wilderness" to see if anyone with a duplicate address
is out there. The vast majority of times there will be no answer, but many
LLA specs still say that the cry must be made. If I have an LLA type for which
DAD is not required, and I apply it to an interface that may be exposed to
other LLA types, I do not want the non-DAD LLA type to incur the burden
of making the cry.

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

Yet, for RFC4291-based LLAs the specs say that DAD is required.

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

Yet the specs say DAD is required, unless Optimistic DAD is invoked.

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

I don't understand the loopback comment.

> > 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.

No, there is no burden implied for existing deployments. Existing interfaces
will see a "Type" value of 0 (i.e., unspecified) and will continue to operate
as they always have. 

> 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.

OMNI IIDs are unique because the IPv6 Prefix Delegations they are derived
from are unique. But, if a node has not been assigned an OMNI IID in advance
it will have to request one using a temporary IID such as from RFC4941(bis).
And, it is this temporary IID that needs to be de-conflicted from OMNI IIDs.

Fred

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