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

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 30 Nov 2020 17:38:50 +0000

Philip - see below:

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

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 30 Nov 2020 20:24:43 +0000

Philip,

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?

Fred

> From: ipv6 [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
> Sent: Monday, November 30, 2020 9:39 AM
> To: Philip Homburg <[email-masked]>; [email-masked]
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 30 Nov 2020 21:52:47 +0000

Anyone who would miss having SEND/CGA on OMNI interfaces needs to speak up
now; else, they will be gone from the next draft version and OMNI will perform
IPv6 ND message authentication over Internet links the same as for Teredo.

Fred

> Sent: Monday, November 30, 2020 12:25 PM
> Subject: RE: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
> 
> Philip,
>