RE: Embedding IP information in an IPv6 address (OMNI)

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Thu, 15 October 2020 22:27 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 7C5D73A0A3D; Thu, 15 Oct 2020 15:27:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_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 pFDw0JqyNFch; Thu, 15 Oct 2020 15:27:28 -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 6089D3A0A13; Thu, 15 Oct 2020 15:27:27 -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 09FMRMTZ009799; Thu, 15 Oct 2020 18:27:25 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602800845; bh=xvAPO5m+8DuPVgYCxIUMM60k7pwoGwhnhhq9zfKxXPY=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=DrNDVD6bUnVEftIzDlA7hlemBOBa4woCuDBO8mRxaNHEJ/30nHRODL6JlDdiyiMf+ CS7Rq9fY9RLa20vsISqsYklsDh6W6hCR9AW71YIJxBvc+afFyzL9Z1FDANm8tgHTg7 y831EmkhS5krt4CCNllodhCZL57ublefEf4VE0rEwLxBKCN2ue/f3O/zQKTQhPJDWB Ag9EpIwecwfOHEM1Exsa6FBqkFTIcBhoB13VaJfnYwXSO/s2um6sPtwKI/qlai+qCE cQJNtpJstJe/BuewYA7kr3Mq+3Rx76Vk6vSDEvmKcSgfSq4LIJchRtx4a8sDYpaoyb GGZHq8MrSt/og==
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 09FMRHDO008829 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 15 Oct 2020 18:27:17 -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; Thu, 15 Oct 2020 15:27:16 -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; Thu, 15 Oct 2020 15:27:16 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Bob Hinden <bob.hinden@gmail.com>
CC: Ole Trøan <otroan@employees.org>, IPv6 List <ipv6@ietf.org>, "atn@ietf.org" <atn@ietf.org>
Subject: RE: Embedding IP information in an IPv6 address (OMNI)
Thread-Topic: Embedding IP information in an IPv6 address (OMNI)
Thread-Index: AdajMsD1xD3hGdlTThaXSslc4Lj72wABksWAAAIobZA=
Date: Thu, 15 Oct 2020 22:27:15 +0000
Message-ID: <2e8f3723848c4ea28b2b2cf4777e5890@boeing.com>
References: <6664a427f0334468ac0b8cba75b37d03@boeing.com> <e2ec5f065e41473a9b164df8d79d1645@boeing.com>
In-Reply-To: <e2ec5f065e41473a9b164df8d79d1645@boeing.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: 50137031945645394D5AEE51BBCFA3BDBF94C7317E39E3499D92B18158125E302000:8
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/7aFh4CG-IIpYoazXu8T6Q4ynGnc>
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: Thu, 15 Oct 2020 22:27:31 -0000

And even more:

> -----Original Message-----
> From: atn [mailto:atn-bounces@ietf.org] On Behalf Of Templin (US), Fred L
> Sent: Thursday, October 15, 2020 2:25 PM
> To: Bob Hinden <bob.hinden@gmail.com>
> Cc: Ole Trøan <otroan@employees.org>; IPv6 List <ipv6@ietf.org>; atn@ietf.org
> Subject: Re: [atn] Embedding IP information in an IPv6 address (OMNI)
> 
> A bit more to this:
> 
> > I think that may be due to the fact that we have only examined a few fundamental
> > aspects of the architecture, and there is more to it than what has been discussed
> > so far - a *lot* more.  For instance, the reason for wanting both LLAs and SLAs is so
> > that we can use overlay "L2 bridging" to join disjoint Internetworks together as
> > though they were one big bridged campus LAN. For example, in civil aviation there
> > are many network service providers including ARINC, SITA, Inmarsat and others and
> > each runs their own networks as an independent entity. But, an aircraft connected
> > to ARINC may need to communicate with an air traffic controller in SITA. OMNI then
> > views each of the providers as a link *segment* and bridges the segments using
> > RFC2473 encapsulation with SLAs and BGP router peerings between the providers.
> > The IPv6 layer then sees this bridged arrangement as a single, connected IPv6 link
> > and the aircraft and ATC can communicate as peers on the link even though they
> > are located in different provider networks in the underlay.
> 
> It is important to understand that the RFC2473 encapsulation I am referring to is
> a "mid-layer" encapsulation and not the outermost encapsulation. When joining
> multiple providers as I have said above, the SLAs are not routable in the public
> Internet; only public IP addresses are routable within that realm. The OMNI
> approach fully understands this, and therefore the RFC2473 encapsulation I am
> referring to occurs as a *mid-layer* encapsulation and not the outermost
> encapsulation. The outer encapsulation would use public IP addresses and some
> form of security like IPsec or Wiregurad. So what we would end up with is:
> 
>   1) an inner IPv6 packet with GUA or LLA addresses
>   2) a mid-layer RFC2473 encapsulation IPv6 header with SLA addresses
>   3) an outer encapsulation IP header with public addresses plus any security codes

There are several benefits for using RFC2473 encapsulation in this way. First, it allows
IPv6 Neighbor Discovery (IPv6 ND) messages to travel across multiple Internetworks.
Let's say that a Client is connected to the ARINC network, but its Server is in the SITA
network. The RS/RA/NS/NA messages that make up the IPv6 ND protocol can be
encapsulated in an RFC2473 header and shipped between the client and server
without decrementing the IPv6 Hop Limit nor sending a packet with link-local
addresses through a router.

That is on the control plane. In the data plane, RFC2473 is at the heart of the OMNI
Adaptation Layer (OAL) which is in Chapter 5 of the document and I really recommend
you read. The OAL performs an analogous function as for AAL5, and adapts message
sizes to the diverse MTUs of the underlying interfaces and/or the underlying network
minimum path MTU. It selects a "cell size" for segmentation and reassembly the same
as for AAL5 (albeit with a larger cell size than ATM) and uses IPv6 fragmentation and
reassembly on the RFC2473 mid-layer packet as its segmentation and reassembly
scheme. This enables lossless and adaptive packet sizing, with soft error feedback
to the original source when packets are becoming "uncomfortably large". It is the
long-sought solution for tunnel path MTU discovery, and it is a major improvement
over the current state of affairs.

Fred