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

"Templin (US), Fred L" <> Wed, 21 October 2020 14:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BFCED3A0BFD; Wed, 21 Oct 2020 07:38:50 -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 qExHYkwi3FoM; Wed, 21 Oct 2020 07:38:49 -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 D2BEF3A0957; Wed, 21 Oct 2020 07:38:48 -0700 (PDT)
Received: from localhost (localhost []) by (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09LEchIO002000; Wed, 21 Oct 2020 10:38:45 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=boeing-s1912; t=1603291126; bh=v46WpFBHp8ZeHN9fpo+YsWWusx9XMH3+LBsoc+F+mH8=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=fZ8R9gbVLFA5RXAfSPhL3NUCR4JcXyOm1PgpnK7f2UbLPtOF7ziG1ZcYrMVvhQWmG hEfknimyZtaTNMVHkyJ+1d1C/qaRh6vOkWy9ZOiYW9z3bC4oBKNnryYoxvJtDWqdoN W+Fm/rp7IVog8JcHi94uztH9WeU3c0gChLGdUlEebKvIgw/WDiPh9FICBCTEzAOThD 1sh8MK5GTA6/GkIgKmQC3YbqSCW3I2rzP+Its6EZ5KlGIZgQBPuNxiQA/9kV2YI2Kd PgVir1uEGKfdjPWAtPPLadzDZlH2f3VLjHD4w58ElYTLxtgbRx13TZaNFvl0D91IOg JEMSXwKJCY9NQ==
Received: from ( []) by (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09LEcaKL000625 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 21 Oct 2020 10:38:37 -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; Wed, 21 Oct 2020 07:38:35 -0700
Received: from ([fe80::1522:f068:5766:53b5]) by ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Wed, 21 Oct 2020 07:38:35 -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: AdamGxsTxD3hGdlTThaXSslc4Lj72wAGYdDgACa2Ti0AOGhwYA==
Date: Wed, 21 Oct 2020 14:38:35 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-snts-smtp: 1C8D7DC91DB2626CD7862083B0F8C10380DA431E324FFB29DB7DFA641A9CBCB12000: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: Wed, 21 Oct 2020 14:38:51 -0000

Philip, see below for my responses to your specific comments:

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: 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.

The document came from an aviation committee, but the applicability is
far broader than just airplanes. Cars, cellphones, drones, airplanes, ships,
trains and anything else that moves and has  an onboard network or uses
IPv6 multi-addressing are also candidate users. Applicability to the ipwave
problem space has also been documented, e.g.

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

Several people have objected to the use of that particular acronym, so
I will take action to remove it from the document and replace it with
something less objectionable. But the need is to have an address range
that can be used as the source and destination addresses of the RFC2473
IPv6 header inserted by the OAL. The addresses need to be routable
within a bounded domain, but they will never leak out onto the IPv6
Internet so they need not be GUAs. The clear candidates therefore
would be taking all of fec0::/10 or a sub-prefix portion of fc00::/7.
> 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]."

Yes, that stems from the requirement that the addresses need to be
routable within a bounded domain - in this case, IPv6 multi-hopping to
reach the boundary router of Mobile Ad-hoc Network for cases such
as vehicle-to-vehicle multihop access to infrastructure.

> 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?

For commercial airplanes, there will be a 24-bit ID that is unique to the
aircraft and travels with the aircraft wherever it goes. Aircraft can then
statically determine their MNPs by concatenating the 24-bit ID with the
Mobility Service Prefix (MSP). For example, if the MSP is 2001:db8::/32
and the unique ID is 0x123456  the MNP is 2001:db8:1234:56::/56.

For other cases where there is no hard-coded unique ID, the Mobile
Node can use either the unspecified address or a temporary MNP for
the first contact to the AR and request the network to allocate an MNP
via DHCPv6.

> 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

RFC5214 does not mandate multicast; I think you are referring to RFC2529?

> 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.

The MN can have a list of IPv4 addresses discovered the same way as for
ISATAP deployment in enterprises. It may not know the IPv4 address of
the actual AR that it will contact, so this seems to suggest that an anycast
address could be useful.

> 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?

No, this is not shoehorning - this is what ISATAP was designed for. We flew
ISATAP on drones back in Y2K.

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

It is not a DHCPv6 relay - it is a DHCPv6 *proxy*. The AR acts as a DHCPv6 client
on behalf of the MN the same way that a proxy would do. It is needed for cases
when the MN does not have a pre-assigned MNP, which may be the dominant
model for many use cases.

> 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?

I think what you may be missing is a couple of sentences explaining how the
Interface Attributes influence the Conceptual Sending Algorithm (section 11).
This is really the heart of what this mechanism is all about - it is about
multilink and Safety/Performance Based multilink selection. I think a few
connecting sentences - some in Section 11 and Section 9.1.3 might address
this concern.

> 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.

The terminology in Section 9 shifted to "Interface Attributes", but the change
did not carry forward into Appendix A as it should have. The Appendix A
language needs to be harmonized with the language used in Section 9.1.3.

> 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.

I may be too close to the document to comprehend the understanding gap
you seem to be indicating. Can you say more about what you think is missing?

> 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.

Yes, it is expected that the Access Routers (ARs) will engage in a Mobility
Service (MS) outside the scope of this document. The details of the MS are
intentionally omitted so as to be generic. What this document does is to
present an *interface* spec. From the perspective of the MN, all it cares
about are neighbors on the interface which would include ARs and potentially
also other MNs.