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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Thu, 15 October 2020 20:58 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 070E73A0407; Thu, 15 Oct 2020 13:58:55 -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 DJq4FzmObyWo; Thu, 15 Oct 2020 13:58:53 -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 220973A03FA; Thu, 15 Oct 2020 13:58:53 -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 09FKwn4t022623; Thu, 15 Oct 2020 16:58:50 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602795530; bh=tw3aCdFwC+jsBIxPCisV8cqi+aU/99ydDqfSf6wCHTA=; h=From:To:CC:Subject:Date:From; b=YWwV0Q9O+J6RxKNJwz5Er8jy8QdtgNBMn3SfzD/hkoqVmtU0wt2jyIwTJAm1436ea 0r0anpvwMzd1bc7fHgKJVYX3grQL4mCLYiAcLB4fqn/WIGGGMPnpT6y5njKsWUPgUU 4twIXdkjSdVqmKcY5e3puUNVlarT4/JOwoRGlSHvTPX3a61zZv6WmXoAr1qhRBnaHv 67hCL2T4N3uRc/Z/T9rGn8ANgqZS9A634PyLeLRl72YykJSTv/wCK9TVT1KItPyCht jS6gUIDKy0On7QhRL6KKcKDHVBmZfss/SFuvuwhWKqONhrmykApsp5v0VstxsL7iu6 DFKa96pSnIPZQ==
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 09FKwg23022377 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 15 Oct 2020 16:58:42 -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 13:58:41 -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 13:58:41 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Bob Hinden <bob.hinden@gmail.com>
CC: =?utf-8?B?T2xlIFRyw7hhbg==?= <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: AdajMsD1xD3hGdlTThaXSslc4Lj72w==
Date: Thu, 15 Oct 2020 20:58:41 +0000
Message-ID: <6664a427f0334468ac0b8cba75b37d03@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: 2AC7847E2B7C213AE00FEFB88965BE2FF7FBBE93DA30F966DFD93D1D2E546E132000: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/kD3-x8ohQr0m5hjAvT19z7Vd38E>
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 20:58:55 -0000

Bob,

> -----Original Message-----
> From: Bob Hinden [mailto:bob.hinden@gmail.com]
> Sent: Thursday, October 15, 2020 1:29 PM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: Bob Hinden <bob.hinden@gmail.com>om>; Ole Trøan <otroan@employees.org>rg>; IPv6 List <ipv6@ietf.org>rg>; atn@ietf.org
> Subject: Re: Embedding IP information in an IPv6 address (OMNI)
> 
> Fred,
> 
> > On Oct 15, 2020, at 12:40 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> >
> >>>>
> >>>
> >>> That circles us right back to the subject of how RFC4861 is intrinsically tied to
> >>> the use of link-local address and the fact that all IPv6 interfaces are required
> >>> to configure a unique link-local address. It would be a bear to try to change
> >>> that, so OMNI employs RFC2473 encapsulation instead of trying to override
> >>> the bedrock IPv6 standards. The use of RFC2473 encapsulation also brings
> >>> other important benefits.
> >>
> >> Right, that how ND works.   Seems to me that you are proposing many changes to IPv6 for some degree of optimization.   It’s
> unclear
> >> to me that the benefit outweighs the cost.
> >
> > Rather than repeating them again here, I would invite you to go back over the
> > message exchanges I had with Ole yesterday (10/14/2020) where I outlined the
> > benefits.
> 
> I read that, but was not convinced that the benefits were sufficient to justify what you are proposing.

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. 

> > About changes to IPv6, all that has been asked so far is for the OMNI
> > interface to define its own link-local addresses - having that, none of the IPv6
> > standards like RFC4861, RFC8200 etc. are changed.
> 
> The OMNI draft updated RFC1191, RFC3879, RFC4291, RFC4443, and RFC8201.

When I said "all that has been asked for *so far*", I meant in terms of what has
been discussed on the list up to now. Up to now, the only aspects of OMNI we
have touched on are the LLAs and SLAs, and it is only RFC3879 and RFC4291 that
are in question. So, until we get around to discussing the OAL let's put the other
RFCs aside for now.

Thanks - Fred

> Bob
> 
>