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

"Templin (US), Fred L" <> Tue, 13 October 2020 20:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55DAC3A08C3; Tue, 13 Oct 2020 13:59:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KQl1rFd9WMYm; Tue, 13 Oct 2020 13:58:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6AB893A08C1; Tue, 13 Oct 2020 13:58:59 -0700 (PDT)
Received: from localhost (localhost []) by (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09DKwvx6019655; Tue, 13 Oct 2020 16:58:57 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=boeing-s1912; t=1602622737; bh=GDGM8W9qg7Uuz05s8D/F7gtSUR3hMHo0TKhOWUws74A=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=dB0PbBWu5sscjkybWWQDyV12aucqkWf62EKDlG+7yf8Wsqo4HC/dcpjyj93cFeebk ZJCohHhTPj2JftyIbV3oNEiVNwU0orb2/h3Jg9ohq/NoJe7e4qWArxEBMqfLNr70LY OPyuLLjUDzuUKu1C+giY4t0AgidwpEZU9vWKSssTkxhf+mnLxhnIHbcdmrMhHIgNOT lJxqOkJsXxqHnIDGD1Lch6Wk9hUINml97OAwVr6j+nlj+ZSWm/tVuPA6SKaxEei+x2 6ZyN+k1F/QfWlrbUqNrOkxecDKk3oIXqZpG5Saix/7MsQhW8HmenAicBGuk+leFzMm +/P7vfq2oestw==
Received: from ( []) by (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09DKwuN7019640 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 13 Oct 2020 16:58:56 -0400
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Tue, 13 Oct 2020 13:58:54 -0700
Received: from ([fe80::1522:f068:5766:53b5]) by ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Tue, 13 Oct 2020 13:58:54 -0700
From: "Templin (US), Fred L" <>
To: Mark Smith <>
CC: Fred Baker <>, Robert Moskowitz <>, 6man <>, "" <>
Subject: RE: [EXTERNAL] Re: [atn] Embedding IP information in an IPv6 address (OMNI)
Thread-Topic: [EXTERNAL] Re: [atn] Embedding IP information in an IPv6 address (OMNI)
Thread-Index: AQHWnoMLTQ3goFZI8k6V0haOyYZmuamPyXtggACXFACAAJ+g8IAFdiAA//+MCwA=
Date: Tue, 13 Oct 2020 20:58:54 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-snts-smtp: 5108322ED50387B4E4F62D85E444D89E5D4EB7F2E12FD1D554C2386B097D5ECD2000:8
Content-Type: multipart/alternative; boundary="_000_c9a68a4c52104e809d208f903b2a25c0boeingcom_"
MIME-Version: 1.0
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: Tue, 13 Oct 2020 20:59:02 -0000

Mark, see my follow-up message. There is no problem with an IPv6-over-foo spec
defining its link-local address format. Almost all of the existing IPv6-over-foo specs
define an interface-specific interpretation of link-locals with a prefix length (fe80::/64)
that does not appear in RFC4291, and none of them update RFC4291. All that is said
in RFC4291 is “fe80::/10”, which does not agree with the IPv6-over-foo specs. I hear
your point about the BSD hack of writing data into the 54 “unused” bits in memory,
but I am not sympathetic to that approach when what is being offered here is a
brand-new interface type that does not already exist in widely-deployed
implementations, so it is a chance for a fresh start for all implementations.

As it turns out, however, I am also seeking a re-purposing of the RFC4291 “site-local”
prefix fec0::/10 where the rightmost 118 bits of the address will be defined in exact
1x1 correspondence with what I am proposing for OMNI interface link-locals. You
might then say, “there you go – just use those, and leave link-locals alone”. I get
that, but the problem is that some documents (RFC4861 in particular) have exacting
requirements on link-local addresses to the point that we would have to do a major
“updates” to RFC4861 which I think would create an impasse far greater than the
one you seem to be implying for the proposed use of link-locals.

Personally, I do not see a problem. I have this link-local address format and
parsing in my OMNI interface implementation which I am hoping to make public
by the end of this year. There are no conflicts with existing code, and no overlaps
with other interface types. New documentation will clearly outline the use of
these link-locals within the context of the OMNI interface so there is no ambiguity.
So, greedy as I am, I yes do want to define both link-local and site-local addressing
according to the OMNI interface spec. The benefit IMHO far outweighs any of the
concerns I have heard.

Thanks - Fred

From: Mark Smith []
Sent: Tuesday, October 13, 2020 1:26 PM
To: Templin (US), Fred L <>
Cc: Fred Baker <>om>; Robert Moskowitz <>om>; 6man <>rg>;
Subject: Re: [EXTERNAL] Re: [atn] Embedding IP information in an IPv6 address (OMNI)

This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and know that the content is safe.

Hi Fred,
On Sun, 11 Oct 2020, 03:12 Templin (US), Fred L, <<>> wrote:
Hi Mark,

We want to use link-locals (fe80::/10) – else we would have to do a wholesale update
of key RFCs such as RFC4861. Plus, RFC4291 says:

   Routers must not forward any packets with Link-Local source or
   destination addresses to other links.

and since the OMNI link is the only one on which the addresses would appear on
the “wire” it should be possible to make a good use out of the otherwise-wasted
54 buts. All it takes is an “updates RFC4291” , for which we see many prior examples.

I don't think it is as easy as just updating RFC4291. There are literally billions of deployed implementations of IPv6 that expect these bits to be zero, and have for the past 25 years since the link-local prefix format was defined in RFC1884.

These zero bits aren't wasted, their value is to fill out the space between the high order link-local fe80::/10 prefix and the lower 64 bit IID to align them, so that the link-local address is 128 bits long. "Waste" only occurs when no useful value is gained from something, and if course field alignment is useful.

You possibly will run into an issue with BSD IPv6 implementations, which from what I understand, store information in these zero bits' position when they hold a link-local address in memory.

It would be easier to reclaim these bits if they were 'reserved', and if there was a statement such as "set to zero upon transmission, ignored upon receipt" however I've never seen such a clause for the link-local subnet-prefix (I think that sort of clause might only exist for flag bits in multicast addresses). Since RFC1884, these bits have always been specified as being set to zero, with no possible caveats or exceptions being suggested.

If you need to have another address space that isn't forwarded off link, then that can be specified as a requirement for the new address space (and you could do some receiver enforcement using the Hop Count == 255 trick that ND uses). Packets leaking off of a link that shouldn't is always a risk, and already occurs with link-locals (packets with DA=ULA/GUA, SA=LLA are known to leak off-link).



From: Mark Smith [<>]
Sent: Friday, October 09, 2020 4:30 PM
To: Templin (US), Fred L <<>>
Cc: Fred Baker <<>>; Robert Moskowitz <<>>; 6man <<>>;<>
Subject: Re: [EXTERNAL] Re: [atn] Embedding IP information in an IPv6 address (OMNI)

On Sat, 10 Oct 2020, 08:35 Templin (US), Fred L, <<>> wrote:

> The concept of embedding information in the 54 “must be zero” bits of the link local address is enticing, but may not prove
> interoperable, given the “must be zero” definition of a link local address.

Also good input, but given that these link-local addresses are defined and intended
for the exclusive use of a specific IPv6-over-(foo) interface type, only interfaces that
understand the address format will process the addresses and they will understand
the usage of the 54 bits.

Link specific versions of link-local addresses don't and won't comply with RFC4291 and all of its ancestors, because there is nothing that says the format of the link local address can be defined by link specific documents. These zero bits have always been zeros.

Why the effort to shoehorn new functionality into existing and long defined IPv6 address spaces?

Follow the ULA verses site-local example - if new functionality is considered different enough to justify updating existing, decades old and very widely deployed address formats, then I'd think the threshold of asking for new IPv6 address space for this functionality is passed. We have about 7/8ths of the IPv6 address space not defined for any purpose (it'd be a different story for new functionality in IPv4 addressing).

With new address space there is no need to both update and be constrained within old address space definitions, and there is much less if any compatibility considerations and concerns with existing deployments.

You could call your new address space OMNI Link-Local Addresses.


Thanks - Fred
IETF IPv6 working group mailing list<>
Administrative Requests: