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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Fri, 16 October 2020 16:03 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 6A7943A0FB9; Fri, 16 Oct 2020 09:03:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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_H2=-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 C8xapMZMIGIh; Fri, 16 Oct 2020 09:03:31 -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 3AE2F3A0FB8; Fri, 16 Oct 2020 09:03:30 -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 09GG3RWB024998; Fri, 16 Oct 2020 12:03:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602864208; bh=dydrX0YQAvuObTUywftSF3LFG2Abjmi1lJdRpsMqH+Q=; h=From:To:CC:Subject:Date:From; b=OmI4FP6PNFAgxhm1vBrbSTV02yyZ9dQ2nljSXjdd/+1lgkQN2RXHQcCUSt3tX4/+5 4BMakepGkpz+cKhmmecfpixkZBolxYAegrEBiCISeEdmvhqb5NKp+VWNZiF9da1zrO MOEgvaHDYYNmObggBruvNacD6FgRiVm3Ou/pEVKmNW3xBhyBO2ZfWHrJ9nttHX8V4q NOoyarW0oGX8eY9d45QGC+BFFl++tS13OMLK55XCQRkxCNY62baaSsyYToWO37Bpbu 668pIdvaBEuWNp017CkXJMnTSx7k6H4ZHeuRqQ0ubWqGVwRvM0YqE4lPokZs9WvRo7 da54HeooluiKQ==
Received: from XCH16-07-07.nos.boeing.com (xch16-07-07.nos.boeing.com [144.115.66.109]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09GG3LIg023675 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 16 Oct 2020 12:03:22 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-07.nos.boeing.com (144.115.66.109) 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:03:19 -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:03:19 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>, "ipv6@ietf.org" <ipv6@ietf.org>
CC: "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: Adaj1LkCxD3hGdlTThaXSslc4Lj72w==
Date: Fri, 16 Oct 2020 16:03:19 +0000
Message-ID: <3493409050e1414ebb7a1d9bf4243f77@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: 5B623982A0FA780EFFCDE7508A3826E86885416CC7CC5966DFABB03C26777A122000: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/yV4nxMOph9dEayb4YnLYqUcshRc>
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:03:33 -0000

Hi Philip,

> -----Original Message-----
> From: atn [mailto:atn-bounces@ietf.org] On Behalf Of Philip Homburg
> Sent: Friday, October 16, 2020 1:25 AM
> To: ipv6@ietf.org
> Cc: Templin (US), Fred L <Fred.L.Templin@boeing.com>om>; atn@ietf.org
> Subject: Re: Embedding IP information in an IPv6 address (OMNI)
> 
> > There are many reasons why I like what we have already, but one
> > that I will point out is the ease of constructing a routable OMNI
> > site-local address (SLA) from a non-routable OMNI link-local address
> > (LLA). For an OMNI LLA such as fe80:2001:db8:1:2:: all that is
> > needed to turn it into an OMNI SLA is to set bit #9 to yield
> > fec0:2001:db8:1:2::. That is computationally very simple and allows
> > a single-bit translation between LLAs and SLAs (to get an LLA,
> > clear bit #9 and to get an SLA se bit #9). If instead the LLA had
> > the embedded prefix in bits 64 thru 127, the translation between
> > SLAs and LLAs would be much more expensive.
> 
> Site-local addresses are deprecated for a reason. Calling a new type of
> address 'site-local' is only creating confusion.

I 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

> You call it 'site-local' and it seems that indeed you are recreating all of the
> problems of the original site-local. I.e, what if a single router is part
> of two OMNI sites, how the router distinguish between the two uses of the
> same prefix? Certainly if every mobile phone becomes an OMNI device it is quite
> likely that some router will serve multiple OMNI sites.

Bits 10-15 of the fec0::/10 prefix will be used to differentiate different
OMNI links. So, if we had multiple OMNI interfaces (e.g., omni0, omni1,
omni2, etc.) we would have multiple prefixes fec0::/16, fec1::/16, fec2::/16
up to feff::/16. That allows each node to connect to up to 64 OMNI links,
which is far more than we will need for aviation.
 
> ULA solved this problem. So it makes sense for OMNI to use ULA instead of a
> fixed prefix.

ULAs are what we started with - but what we want is a dedicated and
special-purpose mapping of a fixed ::/10 prefix, and my understanding
is that ULAs were intended to be general-purpose.

> Now back to your technical argument. Using a 64-bit IID for both link-local
> and the "site-local" makes changing from one prefix to another as cheap as
> you are proposing.
> 
> That said, any architecture where routers change addresses of packets on
> the fly is something I would avoid using.

No, it is not going to be about changing addresses on the fly; what it means
is that packets with IPv6 LLAs would be encapsulated in RFC2473 headers
with corresponding IPv6 ULAs - so, we are doing encapsulation; not translation.

> It is up to the originating transport protocol to select the source and
> destination address of a packet, and then all routers do is transport
> it to the destination. At the destination the packet arrives (mostly)
> unchanged.
> 
> If we wanted address translation, we could just stay with IPv4.

Not translation; encapsulation.

Fred

> --
> atn mailing list
> atn@ietf.org
> https://www.ietf.org/mailman/listinfo/atn