RE: [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)

"Templin (US), Fred L" <> Tue, 20 October 2020 20:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDE193A1353; Tue, 20 Oct 2020 13:07:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 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_H2=-0.001, 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 1O6O4TnhiSFw; Tue, 20 Oct 2020 13:07:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 83B1F3A1368; Tue, 20 Oct 2020 13:07:27 -0700 (PDT)
Received: from localhost (localhost []) by (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09KK7Phn010287; Tue, 20 Oct 2020 16:07:25 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=boeing-s1912; t=1603224445; bh=lZEnpRlpFqKV3UlEzPE0sL8AsF+ELkoOwqLwi0HLzAc=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=V9RsaaaF2NqaXV5pck9pzWhIcvMS/gSTW9OlUwOpz681VLrUQ3Ho2qb/cn8Y+ALsC MApiSKLz4zdpnGFo6kb9YdlEzTrYnjlxh6amVYqn/v1nFQSmF3LfWUKrOLtohBf4dX grm0nV5+iZB1iA2QbN95sNm61nSLTWxCYteuZxdU6w3wMf/m5rkQ7uA2CFoS7AaKTG Ss4G3rKvi6VQMSF69JAm+q+quaWXVunr2EHaRGS47nNXZxli8SwHfusSq2hzsAUNRd sSOi/YCw4dhEzae70zOA2pPal1I/4qsG3e7ThiX6hQ5A7k0h4/mg1Y4viybYKP6KT5 vZ7aDN0gYj6Gg==
Received: from ( []) by (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09KK7EBn009157 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 20 Oct 2020 16:07:15 -0400
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Tue, 20 Oct 2020 13:07:13 -0700
Received: from ([fe80::1522:f068:5766:53b5]) by ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Tue, 20 Oct 2020 13:07:13 -0700
From: "Templin (US), Fred L" <>
To: Philip Homburg <>, "" <>
CC: "" <>
Subject: RE: [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)
Thread-Topic: [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)
Thread-Index: AdamGxsTxD3hGdlTThaXSslc4Lj72wAGYdDgACa2Ti0AEqbrsA==
Date: Tue, 20 Oct 2020 20:07:12 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-snts-smtp: 3CCCD380C3452876EF639A56A611EB1C73D3B3A943284905B18D52EDBECB528E2000: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: Tue, 20 Oct 2020 20:07:36 -0000

Philip, sorry to top-post, but your comments by-and-large seem to be about not
having sufficient context and I think I can offer an explanation. Up to the beginning
of this year, what we now know as OMNI was previously wrapped up into a larger
integrated proposal called AERO:

The work had been progressing in the ICAO "Working Group-I Mobility Subgroup"
as an integrated package until a decision point was made by the group to separate
the air-ground interface specification from the mobility solution specification. So,
we split the doc into two parts, with everything relating to the interface moved
into the OMNI draft and everything pertaining to mobility left in the AERO draft.
This allowed the OMNI draft to take on the form of an "IPv6-over-foo" spec
independently of the AERO draft. In this way, the interface specification can be
made to work with other mobility solution alternatives than just AERO, as ICAO
still has other candidate mobility solutions under consideration. 

So, the part you referred to as "magic" is exactly those aspects that are covered
by the Mobility Service (MS) specification which is outside the scope of OMNI.
But, IMHO, the OMNI spec stands alone as an interface specification with the
understanding that details of the MS are out-of-scope.

Thanks - Fred

> -----Original Message-----
> From: [] On Behalf Of Philip Homburg
> Sent: Tuesday, October 20, 2020 3:55 AM
> To:
> Cc: Templin (US), Fred L <>om>;
> Subject: [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)
> > > 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.