Re: Embedding IP information in an IPv6 address (OMNI)

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Tue, 20 October 2020 10:55 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 BA6503A1161; Tue, 20 Oct 2020 03:55:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.623
X-Spam-Level:
X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.275, 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 dbtvbGz6YAh9; Tue, 20 Oct 2020 03:55:08 -0700 (PDT)
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 8F5773A1160; Tue, 20 Oct 2020 03:55:06 -0700 (PDT)
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 m1kUpIA-0000GWC; Tue, 20 Oct 2020 12:54:58 +0200
Message-Id: <m1kUpIA-0000GWC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Cc: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, "atn@ietf.org" <atn@ietf.org>
Subject: Re: Embedding IP information in an IPv6 address (OMNI)
From: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <093fce506718470bb147e2eefbf02b42@boeing.com> <d4d270dfac7d4f8f8296582e4fd54fbc@boeing.com>
In-reply-to: Your message of "Mon, 19 Oct 2020 16:40:53 +0000 ." <d4d270dfac7d4f8f8296582e4fd54fbc@boeing.com>
Date: Tue, 20 Oct 2020 12:54:54 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Tujz1V18pPZsZlpKx62O5THjQFw>
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: Tue, 20 Oct 2020 10:55:10 -0000

> > OMNI Is a good reason to re-instate SLAs. OMNI will also want to use ULAs, 
> but for
> > other and non-overlapping purposes.

When I read the draft from the point of view of a general purpose overlay
network technology, then I find the architecture far from clear.

Maybe the draft would benefit from a separate architecture document. The draft
reads like at large collection of ideas that may work in aviation, but it is
unclear how they would apply to other domains.

For example, the draft introduces technical details, like SLAs, without
describing why they are needed and how they are used.

Then later they pop up seemly at random, for example in Section 12.1 (Router
Discovery in IP Multihop and IPv4-Only Access Networks):
"For IPv6-enabled ANETs, the MN then encapsulates the message in
"an IPv6 header with source address set to the SLA corresponding to
"the LLA source address and with destination set to site-scoped
"All-Routers multicast (ff05::2)[RFC4291]."

How does a mobile node that is doing router discovery know the link number
to put in the SLA? How does the mobile node knows its MNP?

Then later in the same section:
"for unicast-only
"IPv4-only ANETs, the MN instead sets the destination address to the
"unicast IPv4 adddress of an AR [RFC5214].

RFC 5214 is 6over4. Section 6 says: "IPv4 multicast MUST be available.". It
is not clear how this connects to the previous sentence. It also not clear
how the mobile node would know the IPv4 address of an AR.

If you know that the router is multiple hops away, why not use protocols that
are designed for this situation, https for example, to receive configuration
indead of trying to shoehorn a protocol that is designed to work on a single
link?

Somehow, Section 12.3 introduces a poor man's DHCPv6 relay. No explanation
is given why that is needed. 

Section 9.1.3 (Interface Attributes) is something that could benefit from
Ole's CBOR draft. Beyond that, it is completely unclear to me how this would
work in general. For example:

"Link encodes a 4-bit link metric.  The value '0' means the link
"is DOWN, and the remaining values mean the link is UP with
"metric ranging from '1' ("lowest") to '15' ("highest").

And now what?

There is Appendix A (Interface Attribute Heuristic Bitmap Encoding)

"Adaptation of the OMNI option Interface Attributes Heuristic Bitmap
"encoding to specific Internetworks such as the Aeronautical
"Telecommunications Network with Internet Protocol Services (ATN/IPS)
"may include link selection preferences based on other traffic
"classifiers (e.g., transport port numbers, etc.) in addition to the
"existing DSCP-based preferences.

The first time the word Heuristic appears in the draft is in Appendix A.
I have no clue what is going on there. 

Section 17 (OMNI Interfaces on the Open Internet) is quite relevant to any
kind of general purpose deployment. Note that connecting to the internet is
only described this late in the document. However, this section leaves me
without any kind of understanding of what is acually going on. There are
references to VPNs, and SEND. But I have no clue how this all connects.

The document reads as 'mobile nodes talk to access routers and then magic
happens'. I can see how in aviation you would have dedicated access routers
around the globe that run a routing protocol, etc. to make this work.
Outside such a confined environment I don't see how this would work.