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

Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com> Thu, 26 November 2020 11:43 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.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 ABDE53A125E for <ipv6@ietfa.amsl.com>; Thu, 26 Nov 2020 03:43:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
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 ji2wq_z6sSy6 for <ipv6@ietfa.amsl.com>; Thu, 26 Nov 2020 03:43:14 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2413D3A125C for <ipv6@ietf.org>; Thu, 26 Nov 2020 03:43:12 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kiFfz-0000IfC; Thu, 26 Nov 2020 12:43:03 +0100
Message-Id: <m1kiFfz-0000IfC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Subject: Re: [EXTERNAL] Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
From: Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: Your message of "Wed, 25 Nov 2020 14:35:53 +0000 ." <1340a6a6fa2b429da0eca973ad6b08bf@boeing.com> <m1khxYl-0000J3C@stereo.hq.phicoh.net> <5531771ca5ff4978b339e69d4202b3e5@boeing.com>
In-reply-to: Your message of "Wed, 25 Nov 2020 17:06:12 +0000 ." <5531771ca5ff4978b339e69d4202b3e5@boeing.com>
Date: Thu, 26 Nov 2020 12:42:58 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/cbV9PBTyH--25zaFLMrBWn8ly_Y>
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: Thu, 26 Nov 2020 11:43:17 -0000

> > Indeed. Where does it go wrong? Any real world deployment reports where this
> > is an issue?
> 
> Any interface type that configures multiple LLAs based on different
> specs (the RFCs mentioned above as well as others and any future
> RFCs) is susceptible to autoconfigurtion collisions where an LLA
> configured according to spec A collides with an LLA configured
> according to spec B.

You keep saying this but provide no proof. For many years we have been
using EUI-64 IIDs next to pseudo random ones (privacy extensions). This
has caused no problem.

This is a problem that only seems to affect OMNI. No other links have this
issue.

> > No, because IIDs have no network semantics. Locally a stack knows what the
> > address type is. And we don't want to go the BSD route of putting local stat
> e
> > in the zero bits of the link-local address.
> 
> BSD did what they did as a implementation-local hack that leveraged
> the coincidence that the LLA bits 10-63 were currently specified
> as all-0. They ran the risk that some future spec might define
> non-0 uses for those bits, and that is what is being considered
> here.

I was trying to point out that allocating those bit makes sense only if they
appear on the wire (as opposed to BSD that uses them within their system).

However, those bits only benefit OMNI. No other link type needs to know about
what way an IID was created. It doesn't make sense to make major changes
to the architecture for one obscure link type.

> Some LLA types can be generated without having to do DAD - or at
> least while observing optimistic DAD. But, if multiple types of
> LLAs are assigned on a link then the DAD-avoidance property goes
> out the window.  Again, if there is an LLA Type field, then there
> is no chance that an LLA formed from autoconfiguration scheme A
> could be seen as a duplicated for an LLA formed from scheme B since
> the "Type" values would not match.

Again this only a problem for OMNI. Pseudo random IIDs have essentially no
collisions. EUI-64 can collide within the group (two devices with the same
ethernet MAC), but that cannot be solved by adding flags.

However, a very common cause of a duplicate address is a link in loopback. 
Of course, adding flags doesn't do anything solve this isuee.

In short, you are solving a problem that doesn't currently exist outside OMNI.
No matter how much you want it to exists, it just doesn't.

> SEND may not have seen an uptake in adoption yet, but with OMNI we
> see a case where that may change. The SEND specs have not been
> moved to historic category as far as I can tell.

FTP also has not been moved to historic. That doesn't mean we will see a
lot more FTP servers showing up in the near future.

If OMNI does SEND, then we are still talking about a very obscure link type.
And there is something seriously wrong if you need major architectural 
changes for an obscure link type.

> > security reasons, if a link uses SEND then all addresses have to be SEND
> > anyhow.
> 
> Not if there is a Type field to differentiate the LLA types. I can
> imagine an interface that wants to assign both SEND/CGAs and
> RFC4941(bis) LLAs, for example.

No, you don't want a mix of secure ND and insecure ND. That's just a
downgrade attack waiting to happen. You would have to add the same flags
to GUA as well. And that for protocols that have hardly any use.

> We is anyone with good architectural sense who can see the value
> in what is being proposed, and there is value there. And no, this
> is not motivated by GPRS; it is motivated by a need to accommodate
> any link type that may be low-end in nature. There are many examples
> of these in the aviation domain, and I think we will see many in
> other mobile internetworking applications (cars, urban air mobility,
> etc.).

We are talking about solving the prefix delegation problem for mobile
connections.

This is not the working group to deal with low-bandwidth links. Making
random changes to optimize a packet exchange that is extremely rare is 
great way to end up with a broken architecture.

> > What if IPv6 over ethernet had specified that ND would simply take the
> > ethernet address out of the EUI-64 IID and use that as detination address?
> > Then we would have been stuck.
> 
> I don't see any way in which this analogy applies to the discussion
> we are having.

It is exactly what OMNI is doing. Putting forwarding information in IIDs.
I.e., you cannot both put prefix information in an IID and use SEND at the
same time.

> > I'm clueless what you are saying about 'For example, a router can determine
> > the IPv6 next hop by examining the neighbor's link-local address without
> > having to do a forwarding table lookup'
> 
> What I mean is that the LLA can be statelessly derived from the
> GUA prefix and vice-versa. So, if an IPv6 packet with GUA
> 2001:db8:1:2::3 is received on an interface, and there is a neighbor
> cache entry on the same interface for LLA fe80::2001:db8:1:2 then
> the packet can be forwarded directly to the neighbor without having
> to send it to ip6_forward() - so, what I mean is a fast-path
> "hairpinning" capability on interface types that support hairpinning.

So you have a separate link local address for each /64? So a delegated
/48 would potentially require a router to install 64k link local addresses in
the NC?

You continue to ignore my argument that you need to do a FIB lookup anyhow
to find the outgoing interface. So this idea that you have a GUA without the
next hop link-local address just doesn't happen outside OMNI.

> > Knowing the link-local address doesn't say anything about the outgoing
> > interface. So the router has to lookup the GUA in its FIB anyhow.
> 
> No, not in the case I described above.

In your example, how does the router know the outgoing interface? 

Or do you do a separate table lookup to map the link local address to an
outgoing interface. In that case you just moved the problem.

> > We are talking about p2p links, so ND is essentially empty. Any packet that
> > needs to be forwarded just goes to the other end of the link.
> 
> Who is "we"? I am talking about all link types, and not just one
> link type. What is being proposed is good for all link types.

"we", in a thread called 'How do you solve 3GPP issue if neither opera
tor nor handset supports PD?' are trying to solve the mobile problem.

Other link types have deployed DHCPv6 PD a long time ago and don't need fixing.