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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Thu, 15 October 2020 16:18 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 832CC3A08CB; Thu, 15 Oct 2020 09:18:54 -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 PZAw4FKB8GJy; Thu, 15 Oct 2020 09:18:52 -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 247203A08C5; Thu, 15 Oct 2020 09:18:51 -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 09FGIm1i007613; Thu, 15 Oct 2020 12:18:49 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602778729; bh=OT/LO8Vr094A1ogdwzWDkqlT1W/DdSXhAIzLpWob9V4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=KipCSksJQcdgt8IFf9Ve+1orOxt8CzKr/BWe9l/OOp24NvaYDwmHeW87Ylf2M0Kgr kMFcrjEsbtoirXxahRTUKNTljhkVuCPsgeE2kKmP7qMhUi3B6krcEhLXrOBYJbxvj2 3ItPL8U8Kzbtuj+WuyeiqyuDFPz572o1QXqEq5OZOfzo1x4C5ypmu2BFwtyl5Mr9hO oEgadNc4ZuqVi0sAk0SuCGWXTXDPnjfeVd5GNahLyc6v63SoeQjg/jiE6q2WdtCn3x SZkeYAVNTYsa6quGJnAy++IuByzNdoYFJdpEynDF/QvRd+uHQ1XF4SysQ/MITpMyKU O9/sAgLk+FX3w==
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 09FGIaw7006134 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 15 Oct 2020 12:18:36 -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; Thu, 15 Oct 2020 09:18:35 -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 09:18:35 -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: [atn] [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)
Thread-Topic: [atn] [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)
Thread-Index: AdaeYhXTsIxJjBX3TKG3GOD4Nt9lNgECC1GAAAsux4AAHPgmBAAAQ58g
Date: Thu, 15 Oct 2020 16:18:35 +0000
Message-ID: <d0ba7529d30d4a4bb839b1077d52ee9e@boeing.com>
References: <c068f71229404b3693b977ca7cde828f@boeing.com> <739bc23a-c48d-4791-be06-4f972b4699d8@si6networks.com> <5ae440c047db4b51811a00fd5dd15e3a@boeing.com> <m1kSzvJ-0000AXC@stereo.hq.phicoh.net>
In-Reply-To: <m1kSzvJ-0000AXC@stereo.hq.phicoh.net>
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: 039191EC7A6774FE7D16670A1FD6EEC8251ED9F5BC74969A1B230A3DADCB62C52000: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/86JIUyHMSCn7kXWfK07OaTbztb4>
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 16:18:55 -0000

Hi Philip,

> -----Original Message-----
> From: atn [mailto:atn-bounces@ietf.org] On Behalf Of Philip Homburg
> Sent: Thursday, October 15, 2020 2:52 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) 
> 
> >We really do want to define the link-local address format for OMNI interfaces.
> >Too many things depend on every IPv6 interface configuring a unique link-local
> >address. The address format and the means by which it is assured unique is wha
> >t
> >we want to specify for OMNI in an "IPv6-over-foo"-specifc document.
> 
> A few thoughts:
> 1) I think a general system for an IPv6-over-IPv6 overlay network is useful.
>    I don't know enough about OMNI to know if OMNI is the right answer, but
>    some of the concepts in OMNI seem quite useful to me.

Thanks for having a look at OMNI; let me know if there are any questions.

> 2) There is too much code that knows about the link local prefix, that
>    adding a another one is probably not going to fly.
> 3) Traditionally (i.e. since the inception of IPv6) IIDs are 64 bits. So it
>    makes sense for OMNI to conform to that. Embedding the MNP in the IID
>    means that the MNP can be at most 64 bits long. I don't see any big problem
>    with that.

That is the way we had it in older draft versions, but have more recently
changed to using all of the bits 10 thru 128. The thing that inspired the
change was the realization that (not now, but in the not too distant
future) every air, ground, sea and space vehicle on the planet may
need to use OMNI - pedestrians, too. And, at some point, we may find
the /64 limit too restricting.

> 4) However, the main thing standing in the way of using all 118 bits allowed by
>    the fe80::/10 prefix seems to be the *BSD hack of putting an interface
>    number in the zero bits of a link local address. I think that the BSD
>    communities should remove this hack, and we should not effectively let
>    them squat those bits.

I agree.

> 5) I don't see any argument why the MNP should be longer than 64 bits. So
>    point 3 seems the best way to go forward.

When the number of end systems needing MNPs goes up into the
countless billons scale, we may find ourselves hamstrung in the future
if we build in a hard /64 limit today.

Thanks - Fred

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