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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 168753A0FEB for <>; Mon, 30 Nov 2020 12:25:00 -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 jLfrsy864Zbj for <>; Mon, 30 Nov 2020 12:24:58 -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 3EDF23A0EF3 for <>; Mon, 30 Nov 2020 12:24:57 -0800 (PST)
Received: from localhost (localhost []) by (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 0AUKOtwP030203; Mon, 30 Nov 2020 15:24:55 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=boeing-s1912; t=1606767896; bh=zOCRUp9QZTzWmqoRX5uTEcY/qI4ZTCydsEiTYx4I0/I=; h=From:To:Subject:Date:References:In-Reply-To:From; b=Qpe4ARGineaYu150dwWubNFX1rC2094ZSWFu0LTPX1gCdryCgDQ5pdpGdenblM8dd wWMoY4quGfBYMuiuYeapWPqf2SwfDDKofx8U8yIHMjxCzNX7gxTxydaVlT0tKECbbl CSJdJtmKiJ8NCGnAN1worgkWbC76tUbDds3hRzuHYumYo+5PCugvn/EYXeVv7rvwnd FKdwibVL1I43Gsfr5fkenbjX60ZpzG1QY6bMxqA+GSLBZnqhuAOPT9575viYBayz7H 7kyh9P3+A+5gzoqQSgAoX274ccgi56jmdFMlHfxfUZ4fkF6SOm93YLHI0uawdu3Mua mbEnoYQrRy7CQ==
Received: from ( []) by (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 0AUKOiLK030094 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 30 Nov 2020 15:24:45 -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 12:24:43 -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 12:24:43 -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: AdbHPO7yBmucpkuCTXSTQb2WL3XhTgAF1NBA
Date: Mon, 30 Nov 2020 20:24:43 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-snts-smtp: 2146C40CD30EB3BF1B31E3224729C910B4E2C13E1859867E64D5AD6EE22095B52000: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 20:25:00 -0000


For my OMNI case, I have convinced myself that I could drop this line of investigation
(i.e., and refrain from coding bits 10-63 of the LLA) iff I could be convinced that OMNI
interfaces will never need to use CGAs. I have considered both approaches in terms
of securing IPv6 ND messages on OMNI interfaces, namely SEND/CGA vs. HMAC.

RFC4380 uses HMAC for its IPv6 ND message authentication, i.e., and does not use
SEND/CGA. And, OMNI use cases for securing IPv6 ND messages are the same as
for RFC4380. So, is that good enough for OMNI IPv6 ND messages also? Will anyone
miss CGAs if they are not supported on OMNI interfaces?


> -----Original Message-----
> From: ipv6 [] On Behalf Of Templin (US), Fred L
> Sent: Monday, November 30, 2020 9:39 AM
> To: Philip Homburg <>om>;
> Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
> 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.
> Fred
> > I think 6lo does something similar for EUI-64.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------