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

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

> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Templin (US), Fred L
> Sent: Monday, November 30, 2020 12:25 PM
> To: Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com>; ipv6@ietf.org
> Subject: RE: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
> 
> 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
> 
> > -----Original Message-----
> > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Templin (US), Fred L
> > Sent: Monday, November 30, 2020 9:39 AM
> > To: Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com>; ipv6@ietf.org
> > Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
> >
> > 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.
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------