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

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Thu, 15 October 2020 16:43 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.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 501EF3A090B; Thu, 15 Oct 2020 09:43:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.624
X-Spam-Level:
X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.274, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
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 hTbZ8tp7TIg7; Thu, 15 Oct 2020 09:43:53 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E51123A0906; Thu, 15 Oct 2020 09:43:51 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kT6Lw-0000HIC; Thu, 15 Oct 2020 18:43:44 +0200
Message-Id: <m1kT6Lw-0000HIC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Cc: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, "atn@ietf.org" <atn@ietf.org>
Subject: Re: [atn] [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)
From: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <c068f71229404b3693b977ca7cde828f@boeing.com> <739bc23a-c48d-4791-be06-4f972b4699d8@si6networks.com> <5ae440c047db4b51811a00fd5dd15e3a@boeing.com> <m1kSzvJ-0000AXC@stereo.hq.phicoh.net> <d0ba7529d30d4a4bb839b1077d52ee9e@boeing.com>
In-reply-to: Your message of "Thu, 15 Oct 2020 16:18:35 +0000 ." <d0ba7529d30d4a4bb839b1077d52ee9e@boeing.com>
Date: Thu, 15 Oct 2020 18:43:40 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/IjljLr4DQ5RS1WUGfwbTXwv0_xo>
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:43:55 -0000

>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.

>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.

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

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.