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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Mon, 19 October 2020 17:30 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 4F6903A0E60; Mon, 19 Oct 2020 10:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 pDB2yBCXi9ny; Mon, 19 Oct 2020 10:30:02 -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 107793A09E8; Mon, 19 Oct 2020 10:30:01 -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 09JHT4Z6004492; Mon, 19 Oct 2020 13:29:59 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1603128599; bh=ZsJ1Zen0EiBfthDfog8stLvdZAcp/UyeeotkQK9+jBM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=hoafEgE+j2GiqStSqpoPENC4GMol9hspjAwTtxj2SMK/AnuLKTgEyYwQc4mQ0AIN9 6zetRTk9ziH5EV3uJYFnm+DX1b3JcrbyExlp9SR91zif0ebDwAp23HfOBhIJodaY6F 9Rf/vQYTB4JoNr4D6t3SA18iSiSaQueeuT0FKLKe3dWdnyrDAXHNatu2opAhAyYYT8 TsvUs4oAvx/6fm9GNkegvScUm+0rz4Kt8eyvNZjWm7jTN4BgqUmZrauiEohzg5HoPc 8R4sWeLWU5mRdkosEZfXHq1O8Ee8uSnM01B8ErYzar3fPoBOdcb8NEs4TQuyFhE44X pFcCmPaDdX09w==
Received: from XCH16-01-10.nos.boeing.com (xch16-01-10.nos.boeing.com [144.115.66.5]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09JHRBF4020579 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 19 Oct 2020 13:27:11 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-01-10.nos.boeing.com (144.115.66.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Mon, 19 Oct 2020 10:27:10 -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; Mon, 19 Oct 2020 10:27:09 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Bob Hinden <bob.hinden@gmail.com>
CC: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>, =?utf-8?B?T2xlIFRyw7hhbg==?= <otroan@employees.org>, IPv6 List <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: AdamGxsTxD3hGdlTThaXSslc4Lj72wAGYdDgAA/cxgAADhoo0A==
Date: Mon, 19 Oct 2020 17:27:09 +0000
Message-ID: <ca2a6dde76a54e97847014fb159a83c4@boeing.com>
References: <093fce506718470bb147e2eefbf02b42@boeing.com> <d4d270dfac7d4f8f8296582e4fd54fbc@boeing.com> <BF1F0EA0-2A70-4FF1-9031-EE1F6708BC47@gmail.com>
In-Reply-To: <BF1F0EA0-2A70-4FF1-9031-EE1F6708BC47@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: 4D2686790AD6F32CE7DC184A371C5C782B932F66FEF5B7103DD5EB082282B0752000: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/3pH3lvdb1xv8krt-NO3Kvm4gzJo>
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: Mon, 19 Oct 2020 17:30:04 -0000

Bob, we could call it "Domain-Local Addresses (DLA)" and include the following
definition in the OMNI spec:

OMNI Domain - a set of affiliated OMNI links that collectively provide services
                                 under a common Mobility Service Prefix (MSP).

About whether routers will route fec0::/10 prefixes, I know I can make quagga
route fc80::/10 and I assume that it will also route fec0::/10 but I will test that
out and let you know. My assumption is that if quagga will route it, then
commercial routers will too?

Thanks - Fred

> -----Original Message-----
> From: Bob Hinden [mailto:bob.hinden@gmail.com]
> Sent: Monday, October 19, 2020 10:01 AM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: Bob Hinden <bob.hinden@gmail.com>om>; Manfredi (US), Albert E <albert.e.manfredi@boeing.com>om>; Ole Trøan
> <otroan@employees.org>rg>; IPv6 List <ipv6@ietf.org>rg>; atn@ietf.org
> Subject: [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)
> 
> Fred,
> 
> I think most people read SLA as Site-Local Address, especially since you are proposing to use the prefix defined in RFC3513:
> 
>    Site-local unicast   1111111011           FEC0::/10       2.5.6
> 
> In my view any proposal to reuse this prefix, will need to deal with the issues raised in RFC 3879, the document that deprecated this
> prefix.   This would need its own document that would obsolete RFC 3879.  It would also need to investigate if deployed hosts and
> routers block these prefixes.
> 
> Bob
> 
> 
> 
> 
> > On Oct 19, 2020, at 9:40 AM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> >
> > Bob,
> >
> >>> There are very good reasons why SLA were deprecated, I don’t see a reason to change that.  ULAs are intended to replace the
> use
> >> of
> >>> SLAs.
> >>
> >> OMNI Is a good reason to re-instate SLAs. OMNI will also want to use ULAs, but for
> >> other and non-overlapping purposes.
> >
> > Before this discussion goes too much further, I want to point out that the term "SLA"
> > has never been used in association with "Site Local Address" prior to the use in OMNI
> > and these current list discussions; the term was introduced by me, but I would not like
> > for it to retroactively refer to "site" because it never has before in the past. So, I would
> > like to propose that we break that connection starting now.
> >
> > What OMNI needs is an address range that is unique within the scope of a layer-2
> > spanning tree manifested by a service that joins together the segments of a
> > (segmented) link. So, I propose we rename fec0::/10 for its use in OMNI as one
> > of the following:
> >
> > "Spanning-tree Local Addresses (SLA)"
> > "Service Local Addresses (SLA)"
> > "Segment Local Addresses (SLA)"
> >
> > The term "site" is not relevant to OMNI and would no longer be used in that
> > context (once we submit a document update, that is). Would that address
> > the concern?
> >
> > Thanks - Fred