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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98DBA3A0EFC for <>; Mon, 30 Nov 2020 09:39:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.119
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PsBBmJ41tEZH for <>; Mon, 30 Nov 2020 09:39:09 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2774D3A0FB1 for <>; Mon, 30 Nov 2020 09:39:07 -0800 (PST)
Received: from localhost (localhost []) by (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;; 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 ( []) by (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 ( by ( 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 ([fe80::1522:f068:5766:53b5]) by ([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" <>
To: Philip Homburg <>, "" <>
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: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-snts-smtp: 9BB090F7EE7850E590A651F27FDD6AA17BD5481FA5E46CC8748D1A96A347E0002000:8
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 30 Nov 2020 17:39:12 -0000

Philip - see below:

> -----Original Message-----
> From: [] On Behalf Of Philip Homburg
> Sent: Monday, November 30, 2020 9:09 AM
> To:
> Cc: Templin (US), Fred L <>
> 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.


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