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

Philip Homburg <> Thu, 15 October 2020 16:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 501EF3A090B; Thu, 15 Oct 2020 09:43:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.624
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hTbZ8tp7TIg7; Thu, 15 Oct 2020 09:43:53 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id E51123A0906; Thu, 15 Oct 2020 09:43:51 -0700 (PDT)
Received: from (localhost [::ffff:]) by 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: <>
Cc: "Templin (US), Fred L" <>, "" <>
Subject: Re: [atn] [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)
From: Philip Homburg <>
References: <> <> <> <> <>
In-reply-to: Your message of "Thu, 15 Oct 2020 16:18:35 +0000 ." <>
Date: Thu, 15 Oct 2020 18:43:40 +0200
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.