RE: OMNI Interface - formal issues

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Tue, 02 June 2020 16:33 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 CE9E33A0CAB for <ipv6@ietfa.amsl.com>; Tue, 2 Jun 2020 09:33:31 -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_H3=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 v9dNYr86ekY8 for <ipv6@ietfa.amsl.com>; Tue, 2 Jun 2020 09:33:30 -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 BFD873A0C87 for <ipv6@ietf.org>; Tue, 2 Jun 2020 09:33:29 -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 052GXSkX028373; Tue, 2 Jun 2020 12:33:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1591115608; bh=4F9HGmRcGnmMg6O/frmCCweu+RDBkF8V+Dd064YFRik=; h=From:To:Subject:Date:References:In-Reply-To:From; b=Bj7+2UM2D92G1TazThDhW/FOeRdZEpCbjjCmlAQofT7IBY3VAAquAM0JALd2u5CbP ppc7HtdALstADGSAlysfHIXmX7SHwoEqms73C2onXEGm82glGYY7FFm8STdvoND+9p Odf6/m2UIl/LQm38iCYV7E38PKApfqKAr6hejOU+brrguq0WxZz66wBOZgOo5YZuTK /NPU0OllQ4E/aJPpGONxdI4GLi++IsTFt+RQWHEV5I7jkrc0IgJ+7zzz2Adjzm70gL RqS3TEzy4vBEFKmwQ5E9zAMGRUmOwylOU7jt2jJXR0xbSHYPnA6kLxajf965HPvSTN X+Aqjt6gBV5Dg==
Received: from XCH16-07-09.nos.boeing.com (xch16-07-09.nos.boeing.com [144.115.66.111]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 052GXE0Z026727 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK) for <ipv6@ietf.org>; Tue, 2 Jun 2020 12:33:14 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-09.nos.boeing.com (144.115.66.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1979.3; Tue, 2 Jun 2020 09:33:13 -0700
Received: from XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8]) by XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8%2]) with mapi id 15.01.1979.003; Tue, 2 Jun 2020 09:33:13 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: "Jaron, Zdenek" <Zdenek.Jaron@Honeywell.com>, 6man WG <ipv6@ietf.org>
Subject: RE: OMNI Interface - formal issues
Thread-Topic: OMNI Interface - formal issues
Thread-Index: AdY49AM8FoyllRr3TCe37gdKFErDlgABEttA
Date: Tue, 2 Jun 2020 16:33:13 +0000
Message-ID: <a70e879faf474d17a3ad54e48886865f@boeing.com>
References: <DM6PR07MB5978C1ADD3827A786B2D48829F8B0@DM6PR07MB5978.namprd07.prod.outlook.com>
In-Reply-To: <DM6PR07MB5978C1ADD3827A786B2D48829F8B0@DM6PR07MB5978.namprd07.prod.outlook.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: B24EB24A85B3465C6AB902CF481A3084EE3B88D2E296F4F6AF0E9594402934632000:8
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/1rfKy4fiisTcBRBMOy6I7z7cHnY>
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, 02 Jun 2020 16:33:38 -0000

Zdenek, see below for responses:

> -----Original Message-----
> From: Jaron, Zdenek [mailto:Zdenek.Jaron@Honeywell.com]
> Sent: Tuesday, June 02, 2020 8:40 AM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>om>; 6man WG <ipv6@ietf.org>
> Subject: RE: OMNI Interface - formal issues
> 
> Dear Fred
> Thank you for your reply.
> 
> > The OMNI spec is an "IPv6-over-foo" document which specifies the
> > operation of IPv6 over specific link layers. That includes the formation and
> > use of IPv6 link-local addresses. So, since only nodes that implement the
> > OMNI spec will ever see these link-local addresses it should be OK to define
> > the link local addresses as being relative to fe80::/10 as permitted by RFC4291
> > while overriding the default zero settings of the 54 intermediate bits. So,
> > since this is wholly contained within the OMNI spec I don't think we need to
> > formally update RFC4291.
>
> I still believe that any "IPv6-over-foo" must conform to the IPv6 Addressing
> Architecture [RFC4291]. This document says that all addresses from FE80::/10
> are interpreted as link-local (see Section 2.4.), but only addresses from
> range FE80::/64 may be actually used (see Section 2.5.6.: the 54 zeros are
> not "default", they are mandatory). In my understanding, this makes the rest
> of FE80::/10 reserved for future updates of [RFC4291]. Although I agree
> that chances to collision seem to be low, I think that using the whole
> FE80::/10 is otherwise equivalent to using any other currently
> unassigned/reserved IP address range.

The reason for the specification is that it is important that the LLAs align exactly
with the ULAs we are asking for (below) starting with the most significant bits
so that the ULAs can be used in longest-prefix-match decisions in routing
protocols. If it means that we need to update RFC4291 then so be it; we can
add that to our list of RFCs to update.
 
> > Good point, Zdenek - I honestly never dug deeply into RFC4193 and thought
> > that all of fc::/7 was our own playground for free expression. However, I
> > notice that RFC4193 says that bit 7 is "Set to 1 if the prefix is locally assigned
> > and Set to 0 may be defined in the future". The behavior you are describing
> > above is therefore with respect to "fd::/8", so what if we were to change the
> > OMNI spec to define "fc::/8" as permitted by RFC4193? That way, we would
> > be free to define the setting of fc80::/10 in the way we currently do in the
> > OMNI spec. However, I think you are correct we would still need to say
> > "updates RFC4193. What do you think?
>
> FC00::/8 is currently reserved and cannot be used at all without update
> to [RFC4193]. The "locally assigned" range FD00::/8 is limited to have
> bits 8-47 randomly generated (see [RFC4193], Section 3.2.), so currently it
> could only be used as a source of (any number of) unrelated /48 prefixes.

Right, which is why we will have to update RFC4193 to make use of fc00::/8.
Thanks for pointing this out.

> Personally, I would reconsider the need to introduce "OMNI ULAs". They seem
> to be used only for segment routing (which could probably use some
> deployment-specific addresses) and fragmentation (which, if I understand
> it correctly, could use link-local addresses).

Aside from the use in segment routing, the OMNI ULAs will match in 1x1
correspondence with OMNI LLAs. So, for example, if the OMNI LLA is
fe80:2001:db8:1:2:: then the corresponding OMNI ULA is fc80:2001:db8:1:2.
What this means is that, on the access network, we can use OMNI ULAs
as the source and destination addresses of IPv6 ND messages to get them
to travel multiple hops before reaching an access router. For example, if
we had airplane A serving as a multihop relay for airplane B, which in turn
serves as a multihop relay for airplane C, etc. then the outermost airplane
can send its IPv6 ND messages with ULA addresses instead of LLA ones,
and the messages would travel over multiple (MANET) hops before
reaching the ultimate airplane that has a connection to the ground
access router.

This is really just MANET 101 - nothing special or fancy - it's just that we
would be bending the rules ever so slightly in making the (unencapsulated)
IPv6 ND messages travel multiple MANET hops before reaching the router.
But, since we have stateless translation between our ULAs and LLAs it
is trivial for the router to regard the message as if it came from the local
link. So yes, we will also look to update RFC4861. Does this make us bad
people? In my opinion, no; we are simply being ambitious and with good
intentions.

Thanks - Fred

> Best regards
> Zdenek Jaron