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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Fri, 16 October 2020 16:31 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 24A2A3A0FCB; Fri, 16 Oct 2020 09:31:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 mPvl7BuP_86g; Fri, 16 Oct 2020 09:31:33 -0700 (PDT)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 245183A0FB8; Fri, 16 Oct 2020 09:31:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09GGVPSZ024928; Fri, 16 Oct 2020 12:31:29 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602865890; bh=jQqdHOOe18eO+wHMrjsaVx87WJKL612DF1iqHMy7NC8=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=Bkuhrr8hCFeZjOWqGZS0AoDYDY+IMrTVfTUJfDSiksCQKSwQxPMgmsJMkn9e0a2/1 4+ziDrX1zDMXqWT2RGT+pf0hSQJ5dIOUjjXkimQdq6cNJtYNcBwi3bxoCFQ+wJC3fg kf1wccMKumo5WAwGr1H3G2Vz7esK1TPJPIGzRu+f5vmgGaeav/vJu/cc/gslZ/LUy3 HkkZ+fQ6YF5s/zv2+mzFb3eZ54WTWPr7ZVriRlvTAamtAA16/LUzZGb2lkaxBlgTPL Y+ZoHSY5gudsnSpRLMbV+4Bl56QbHj3/4PA9kBe5KB23XsB/ulsHH8nBNI9t0IHBfs k5mJthe3oG16g==
Received: from XCH16-07-10.nos.boeing.com (xch16-07-10.nos.boeing.com [144.115.66.112]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09GGVNoL024892 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 16 Oct 2020 12:31:23 -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; Fri, 16 Oct 2020 09:31:22 -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; Fri, 16 Oct 2020 09:31:22 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Ted Hardie <ted.ietf@gmail.com>
CC: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>, "ipv6@ietf.org" <ipv6@ietf.org>, "atn@ietf.org" <atn@ietf.org>
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: Adaj1LkCxD3hGdlTThaXSslc4Lj72wAPVSsAAA5jY0A=
Date: Fri, 16 Oct 2020 16:31:21 +0000
Message-ID: <81c2b0adda744231ae790408dcb594a2@boeing.com>
References: <3493409050e1414ebb7a1d9bf4243f77@boeing.com> <CA+9kkMD9ZqE4rE4HMf19dY_ghiL7g0in=VGbV9_ve-6_s+X98w@mail.gmail.com>
In-Reply-To: <CA+9kkMD9ZqE4rE4HMf19dY_ghiL7g0in=VGbV9_ve-6_s+X98w@mail.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: DB1E7FBA22AE5A4FA0E3D26C436D8BEFE2E3282C74FB2826E8BAD6F60870EF4A2000:8
Content-Type: multipart/alternative; boundary="_000_81c2b0adda744231ae790408dcb594a2boeingcom_"
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Msd3vLMmp4nfWl84zXyfx9KAK_g>
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: Fri, 16 Oct 2020 16:31:35 -0000

Ted, thanks for your input. We actually started with ULAs but were turned on to SLAs
by the notion that we would be making good use of an otherwise-wasted space. The
other thing to consider is that whatever ::/10 prefix we use, it will be dedicated for
use with operating the OMNI Adaptation Layer (OAL). If we were to use ULAs for
that, then the ULAs could not be used for any other purposes within the OMNI
domain. If we instead use SLAs, then we can still use ULAs for end system addressing.

So, yes, I think we want to allow for all three of LLAs, SLAs and ULAs to coexist
within an OMNI domain and to be used for their respective purposes. GUAs will
also naturally fit in where needed.

Thanks - Fred

From: Ted Hardie [mailto:ted.ietf@gmail.com]
Sent: Friday, October 16, 2020 9:14 AM
To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
Cc: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>om>; ipv6@ietf.org; atn@ietf.org
Subject: [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)


This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and know that the content is safe.




Hi Fred

On Fri, Oct 16, 2020 at 9:04 AM Templin (US), Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> wrote:
  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
Given the very large amount of space, I think re-using fec0:: is not really needed and probably not a good idea.  I think managing that would require first moving it from "deprecated" to "unallocated" then waiting a good long time for that to percolate through the industry's consciousness.  Only then would I think it safe to re-allocate.  It seems simpler to use ULAs (or ask for a new allocation, if you really believe that is necessary).

Just my opinion, of course.

Ted