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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B54A3A1324; Tue, 20 Oct 2020 12:16:09 -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 R_1hRJ1ME0AK; Tue, 20 Oct 2020 12:16:08 -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 17C073A131E; Tue, 20 Oct 2020 12:16:01 -0700 (PDT)
Received: from localhost (localhost []) by (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09KJFxfA001689; Tue, 20 Oct 2020 15:15:59 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=boeing-s1912; t=1603221360; bh=f2XEfB3pRBunHzcEjsQ5k6XMXFCyueNlN2MPIUFfMo4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=LV7bjFreZnXLTAWqUwD+XsuGI9oMR/dnEv80FwkPUkBOr72RD9LpksieqZk0JT/lY PeUgERyOp7h1RgiRJeKJHBbXPO1NTKNl4BhYGlBxBpc4+5xGbVS2SyOwhQaNhltZLl ZlOiJHbp6pHs9qNoXYCjNKOn8t453+HwYc4QTau0HHAru2slkM2QLebMulMVL5Y9Jk wV2OXGDMo1eKMx/A53GiJ2+//e7BoS7iwYLK5Z7POJuTiO8vZsCgjn/zJpRqewdcZd VguowsXUhRwLtSa3f6kiYCP196GDqD39mKdihdXSdCADVGdLG3jR6wPjoidjgJmYnl BBYMcwc2kQ/Kg==
Received: from ( []) by (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09KJFkG3032315 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 20 Oct 2020 15:15:46 -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 12:15:45 -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 12:15:45 -0700
From: "Templin (US), Fred L" <>
To: Bob Hinden <>, Michael Richardson <>
CC: IPv6 List <>, "" <>
Subject: RE: [EXTERNAL] Re: [atn] Embedding IP information in an IPv6 address (OMNI)
Thread-Topic: [EXTERNAL] Re: [atn] Embedding IP information in an IPv6 address (OMNI)
Thread-Index: AdamGxsTxD3hGdlTThaXSslc4Lj72wAGYdDgADOlTmsAA3Vw0A==
Date: Tue, 20 Oct 2020 19:15:45 +0000
Message-ID: <>
References: <> <> <> <8671.1603129044@localhost> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-snts-smtp: E340C7A99869FE50CB18F6C0A38E3271B75DCD1E2274E5A51FB1FAF38FE7E9402000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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 19:16:10 -0000


> -----Original Message-----
> From: atn [] On Behalf Of Bob Hinden
> Sent: Tuesday, October 20, 2020 10:05 AM
> To: Michael Richardson <>
> Cc: IPv6 List <>rg>; Bob Hinden <>om>;
> Subject: [EXTERNAL] Re: [atn] Embedding IP information in an IPv6 address (OMNI)
> Michael,
> > On Oct 19, 2020, at 10:37 AM, Michael Richardson <> wrote:
> >
> > Signed PGP part
> >
> > Bob Hinden <> wrote:
> >> I think most people read SLA as Site-Local Address, especially since
> >> you are proposing to use the prefix defined in RFC3513:
> >
> > Yes, I keep saying to Fred, that overloading SLA is a recipe for
> > misunderstanding.   I think Fred has fixated on those three letters though.
> I agree.

I am fine with dropping "SLA"; it says that in the current OMNI draft, but we
can make it say something different in the next draft version.

> > Bob, can you file away all the historical objections to SLA, and can we just
> > use another name.
> >
> It’s all written down in RFC 3879.
> > Fred needs a /10 with some new name and new semantics.
> >     Reusing FEC0::/10 is ONE option, given that it's just sitting there rotting.
> >     Allocating another prefix that satisfies the needs of OMNI is another.
> >
> Trying to reuse the site-local prefix is IMHO not going to have a good outcome, and I don’t think it is necessary.
> If OMNI needs its own prefix, it can request that.   The length of that prefix will have to be justified.
> Also, I would like to see if Fred can solve the “OMNI” problem using existing addresses, like Global Unicast and ULAs without anything
> new.   The networks that OMNI is proposing to use could easily get their own provider allocations.

Bob, I honestly thought you would be warm to the idea, and that your initial
pushback was a way of encouraging a more thorough analysis of the proposal.
But, after several iterations now I am getting the sense that you truly don't
like it. Which surprises me, but I am open to discussing the alternatives.

In particular, the use case for the /10 prefix we need is for addressing in the
OMNI Adaptation Layer (OAL). The OAL inserts an RFC2473 IPv6 encapsulation
header which requires source and destination addresses - and the addresses
need to be routable within a bounded domain. The addresses will never leak
out onto the IPv6 Internet, so they need not be GUAs. We have already had
quite a bit of discussion on fec0::/10, so let's discuss ULAs as an alternative.

As it turns out, earlier versions of the OMNI draft called for using fc80::/10
(i.e., a /10 sub-prefix of fc00::/7). In fact, that is still what the code is using
because I have not had a chance to convert it over to SLAs yet. And, IPv6
routing services (e.g., quagga) route the fc80::/10 space just fine and without
allowing leakage out onto the IPv6 Internet. Which is sort of exactly what we
want. However, binding the fc80::/10 space for operating the OAL has the
disadvantage that the space can no longer be used for end system addressing,
and in some environments that might be seen as a limiting factor. But, on the
flip-side, there would still be ample portions of fc00::/7 left over to designate
as end system addresses in an all-ULA environment - or, GUAs could be used
for end system addressing instead.

So, with that analysis, the benefit of using fec0::/10 is that it makes a firm break
between what is LLA, what is OAL-dedicated and what is end-system ULA/GUA.
And, the OMNI draft could claim it as its "own" space. True that chopping up
fc00::/7 as described above can work too, but it somehow does not seem as
clean-cut as it would be if we had used fec0::/10. 


> Bob