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

"Templin (US), Fred L" <> Fri, 16 October 2020 16:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6A7943A0FB9; Fri, 16 Oct 2020 09:03:33 -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 C8xapMZMIGIh; Fri, 16 Oct 2020 09:03:31 -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 3AE2F3A0FB8; Fri, 16 Oct 2020 09:03:30 -0700 (PDT)
Received: from localhost (localhost []) by (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09GG3RWB024998; Fri, 16 Oct 2020 12:03:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=boeing-s1912; t=1602864208; bh=dydrX0YQAvuObTUywftSF3LFG2Abjmi1lJdRpsMqH+Q=; h=From:To:CC:Subject:Date:From; b=OmI4FP6PNFAgxhm1vBrbSTV02yyZ9dQ2nljSXjdd/+1lgkQN2RXHQcCUSt3tX4/+5 4BMakepGkpz+cKhmmecfpixkZBolxYAegrEBiCISeEdmvhqb5NKp+VWNZiF9da1zrO MOEgvaHDYYNmObggBruvNacD6FgRiVm3Ou/pEVKmNW3xBhyBO2ZfWHrJ9nttHX8V4q NOoyarW0oGX8eY9d45QGC+BFFl++tS13OMLK55XCQRkxCNY62baaSsyYToWO37Bpbu 668pIdvaBEuWNp017CkXJMnTSx7k6H4ZHeuRqQ0ubWqGVwRvM0YqE4lPokZs9WvRo7 da54HeooluiKQ==
Received: from ( []) by (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09GG3LIg023675 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 16 Oct 2020 12:03:22 -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; Fri, 16 Oct 2020 09:03:19 -0700
Received: from ([fe80::1522:f068:5766:53b5]) by ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Fri, 16 Oct 2020 09:03:19 -0700
From: "Templin (US), Fred L" <>
To: Philip Homburg <>, "" <>
CC: "" <>
Subject: Re: Embedding IP information in an IPv6 address (OMNI)
Thread-Topic: Embedding IP information in an IPv6 address (OMNI)
Thread-Index: Adaj1LkCxD3hGdlTThaXSslc4Lj72w==
Date: Fri, 16 Oct 2020 16:03:19 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-snts-smtp: 5B623982A0FA780EFFCDE7508A3826E86885416CC7CC5966DFABB03C26777A122000: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: Fri, 16 Oct 2020 16:03:33 -0000

Hi Philip,

> -----Original Message-----
> From: atn [] On Behalf Of Philip Homburg
> Sent: Friday, October 16, 2020 1:25 AM
> To:
> Cc: Templin (US), Fred L <>om>;
> Subject: Re: Embedding IP information in an IPv6 address (OMNI)
> > There are many reasons why I like what we have already, but one
> > that I will point out is the ease of constructing a routable OMNI
> > site-local address (SLA) from a non-routable OMNI link-local address
> > (LLA). For an OMNI LLA such as fe80:2001:db8:1:2:: all that is
> > needed to turn it into an OMNI SLA is to set bit #9 to yield
> > fec0:2001:db8:1:2::. That is computationally very simple and allows
> > a single-bit translation between LLAs and SLAs (to get an LLA,
> > clear bit #9 and to get an SLA se bit #9). If instead the LLA had
> > the embedded prefix in bits 64 thru 127, the translation between
> > SLAs and LLAs would be much more expensive.
> Site-local addresses are deprecated for a reason. Calling a new type of
> address 'site-local' is only creating confusion.

I don't want to call them "site-local" anymore; I want to rename them in
my draft as "segment-local".

> Of course, you can ask IANA to allocate a prefix for your particular purpose,
> and may be fec0:: but who knows. It seems bad to me to argue based on
> properties of a prefix you don't know you will get.

We can of course operate with any routable ::/10 prefix, and in fact the
draft called for ULAs until very recently until we were turned on to the
concept of re-purposing fec0::/10. It would be a good use of otherwise
wasted spaceo

> You call it 'site-local' and it seems that indeed you are recreating all of the
> problems of the original site-local. I.e, what if a single router is part
> of two OMNI sites, how the router distinguish between the two uses of the
> same prefix? Certainly if every mobile phone becomes an OMNI device it is quite
> likely that some router will serve multiple OMNI sites.

Bits 10-15 of the fec0::/10 prefix will be used to differentiate different
OMNI links. So, if we had multiple OMNI interfaces (e.g., omni0, omni1,
omni2, etc.) we would have multiple prefixes fec0::/16, fec1::/16, fec2::/16
up to feff::/16. That allows each node to connect to up to 64 OMNI links,
which is far more than we will need for aviation.
> ULA solved this problem. So it makes sense for OMNI to use ULA instead of a
> fixed prefix.

ULAs are what we started with - but what we want is a dedicated and
special-purpose mapping of a fixed ::/10 prefix, and my understanding
is that ULAs were intended to be general-purpose.

> Now back to your technical argument. Using a 64-bit IID for both link-local
> and the "site-local" makes changing from one prefix to another as cheap as
> you are proposing.
> That said, any architecture where routers change addresses of packets on
> the fly is something I would avoid using.

No, it is not going to be about changing addresses on the fly; what it means
is that packets with IPv6 LLAs would be encapsulated in RFC2473 headers
with corresponding IPv6 ULAs - so, we are doing encapsulation; not translation.

> It is up to the originating transport protocol to select the source and
> destination address of a packet, and then all routers do is transport
> it to the destination. At the destination the packet arrives (mostly)
> unchanged.
> If we wanted address translation, we could just stay with IPv4.

Not translation; encapsulation.


> --
> atn mailing list