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

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

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B54A3A1324; Tue, 20 Oct 2020 12:16:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_1hRJ1ME0AK; Tue, 20 Oct 2020 12:16:08 -0700 (PDT)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17C073A131E; Tue, 20 Oct 2020 12:16:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (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; d=boeing.com; 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 XCH16-07-10.nos.boeing.com (xch16-07-10.nos.boeing.com [144.115.66.112]) by clt-mbsout-01.mbs.boeing.net (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 XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-10.nos.boeing.com (144.115.66.112) 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 XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([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" <Fred.L.Templin@boeing.com>
To: Bob Hinden <bob.hinden@gmail.com>, Michael Richardson <mcr@sandelman.ca>
CC: IPv6 List <ipv6@ietf.org>, "atn@ietf.org" <atn@ietf.org>
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: <dd7dbfa50aa647c4a70add4d7ab65745@boeing.com>
References: <093fce506718470bb147e2eefbf02b42@boeing.com> <d4d270dfac7d4f8f8296582e4fd54fbc@boeing.com> <BF1F0EA0-2A70-4FF1-9031-EE1F6708BC47@gmail.com> <8671.1603129044@localhost> <FEF21AE6-6A61-49EC-8039-8C23AA5E32EA@gmail.com>
In-Reply-To: <FEF21AE6-6A61-49EC-8039-8C23AA5E32EA@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: E340C7A99869FE50CB18F6C0A38E3271B75DCD1E2274E5A51FB1FAF38FE7E9402000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/sek3rMBSjY9I_kGn3rEPgZOJHCU>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Oct 2020 19:16:10 -0000

Bob,

> -----Original Message-----
> From: atn [mailto:atn-bounces@ietf.org] On Behalf Of Bob Hinden
> Sent: Tuesday, October 20, 2020 10:05 AM
> To: Michael Richardson <mcr@sandelman.ca>
> Cc: IPv6 List <ipv6@ietf.org>rg>; Bob Hinden <bob.hinden@gmail.com>om>; atn@ietf.org
> Subject: [EXTERNAL] Re: [atn] Embedding IP information in an IPv6 address (OMNI)
> 
> Michael,
> 
> > On Oct 19, 2020, at 10:37 AM, Michael Richardson <mcr@sandelman.ca> wrote:
> >
> > Signed PGP part
> >
> > Bob Hinden <bob.hinden@gmail.com> 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. 

Fred

> Bob
>