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 17:09 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 917893A0A4A; Thu, 15 Oct 2020 10:09:56 -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 WoVOIdRFFuio; Thu, 15 Oct 2020 10:09:55 -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 DF7343A0A3B; Thu, 15 Oct 2020 10:09:54 -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 09FH9n1M032232; Thu, 15 Oct 2020 13:09:52 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602781792; bh=3pdVPYBIgXF4kGrQceV6t//ZW1JtRTPAh8TVVtHYyF4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=LMT3Mms/G9bOnwNN7OVxMTvskPSRS28NvmjvED6q+wde/+SJqfQpsT89Sd6o3MeAU nqnrDQ7my+P/2jb+dNZh6q3cluYV67NovTQwzaHBDA2VZPoqOadmliudupz3FdarDf t8QKeKUDFKiQJnOwIPGGOsSaGLOGdOHvy60HEBAzkHg+/Jhr7YLiS9NOwPlV63Z1cM Hmjybh5dShmaSntCWYD0YD33NNhxlPSnBlKLpXjuxkzmno264gAqEw3bCTV68Q6yS3 t7M6f61VA5aVDxw2qFEhaVGDwyJ589eRScnIgMbPsB110qqbKpJ5f9grctz3y70ksa l/lBbVgIVeXjA==
Received: from XCH16-07-10.nos.boeing.com (xch16-07-10.nos.boeing.com [144.115.66.112]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09FH9lTk032196 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 15 Oct 2020 13:09:47 -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 10:09:46 -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 10:09:46 -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: AdaeYhXTsIxJjBX3TKG3GOD4Nt9lNgECC1GAAAsux4AAHPgmBAAAQ58gAAGd5NwAALTH8A==
Date: Thu, 15 Oct 2020 17:09:46 +0000
Message-ID: <5dc9abd1d1484682ad8773db76f71d00@boeing.com>
References: <c068f71229404b3693b977ca7cde828f@boeing.com> <739bc23a-c48d-4791-be06-4f972b4699d8@si6networks.com> <5ae440c047db4b51811a00fd5dd15e3a@boeing.com> <m1kSzvJ-0000AXC@stereo.hq.phicoh.net> <d0ba7529d30d4a4bb839b1077d52ee9e@boeing.com> <m1kT6Lw-0000HIC@stereo.hq.phicoh.net>
In-Reply-To: <m1kT6Lw-0000HIC@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: A62A0A1A949749D55EE791EC1FB4EEF40FDBBE27CDE4DF2DFE588C079D4F59C02000: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/SGTOwdBN91eycpCKdWM_AlghGpc>
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 17:09:57 -0000

Philip - see below:

> -----Original Message-----
> From: atn [mailto:atn-bounces@ietf.org] On Behalf Of Philip Homburg
> Sent: Thursday, October 15, 2020 9:44 AM
> To: ipv6@ietf.org
> Cc: Templin (US), Fred L <Fred.L.Templin@boeing.com>om>; atn@ietf.org
> Subject: Re: [atn] [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)
> 
> >Thanks for having a look at OMNI; let me know if there are any questions.
> 
> I'll try to spend more time reading the draft.

OK, thanks.

> >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.
> 
> As long as we are talking about physical devices, I'm not sure how we
> are going to run out of /64s.

This is a very important point - it is not just about physical devices but also about
the arbitrarily complex virtual networks they may have on-board. In the future,
even my cellphone could have a deeply-nested virtual IPv6 network-of-networks
requiring subnetting and multi-addressing - its turtles all the way down.

> Even if that would happen, there are probably lessons learned for an OMNIv2

I'd rather get it right the first time.

Thanks - Fred

> In the past I would always relate handing out /64s to the number of 48-bit
> MAC addresses, which a device typically has to communicate. We are not
> even close to running out of those. However, with randomized MACs, it may be
> that future ethernet-like interfaces don't need a fixed MAC anymore.
> 
> Do you have a caculations when we would run out of /64 prefixes? Because that
> would affect many other parts of IPv6 as well.
> 
> >> 4) However, the main thing standing in the way of using all 118 bits allo=
> >wed 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.
> 
> Apart from the fact if there is consensus to make a change in this area,
> I guess it will also take quite some time to first mark the bits as reserved,
> urging implementations to make sure the support the full fe80::/10 and then
> allowing protocols like OMNI to use those bits.
> 
> So it seems to me that it might be better to start with at most a /64 today
> and plan for a new version of OMNI that supports longer prefixes. And maybe
> just testing if the link local prefix is take from fe80::/64 is enough to
> distinguish between the two formats.
> 
> --
> atn mailing list
> atn@ietf.org
> https://www.ietf.org/mailman/listinfo/atn