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

Philip Homburg <> Fri, 16 October 2020 08:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43B8D3A0DFA; Fri, 16 Oct 2020 01:25:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e64CH8K5YwRJ; Fri, 16 Oct 2020 01:25:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6D4803A0E14; Fri, 16 Oct 2020 01:25:18 -0700 (PDT)
Received: from (localhost [::ffff:]) by with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kTL2y-0000IdC; Fri, 16 Oct 2020 10:25:08 +0200
Message-Id: <>
Cc: "Templin (US), Fred L" <>, "" <>
Subject: Re: [atn] [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)
From: Philip Homburg <>
References: <> <> <> <> <> <> <> <> <>
In-reply-to: Your message of "Thu, 15 Oct 2020 17:31:17 +0000 ." <>
Date: Fri, 16 Oct 2020 10:25:05 +0200
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 08:25:30 -0000

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

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.

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.

ULA solved this problem. So it makes sense for OMNI to use ULA instead of a
fixed prefix.

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.

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)

If we wanted address translation, we could just stay with IPv4.