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

"Templin (US), Fred L" <> Mon, 12 October 2020 13:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9EFBB3A14B9; Mon, 12 Oct 2020 06:15:24 -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 euDCu0OpRjhB; Mon, 12 Oct 2020 06:15:22 -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 C918F3A14BE; Mon, 12 Oct 2020 06:15:21 -0700 (PDT)
Received: from localhost (localhost []) by (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09CDFHJG026809; Mon, 12 Oct 2020 09:15:18 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=boeing-s1912; t=1602508519; bh=q6elh9yGjw7a/EoZaq+VmR3CkrxqVGsYQhacovz96L0=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ALqQKvdiIA3djBhzm7vgQtcMquiqdHhZ5KMaOg9hRm4lJpt+uzu7binePufqy2T2r QQbXco8C0do86jSoLY0GG9WFzE+fu20/yf+EO3TOIL8IWO7Xk987C/5hHHKqkaCs/T KsLOA7Ax6YQYeme5xB1lGZanjNoJPkWKl6+evPwPYp85GNt5DG61Qx6Vjlr6AriUUz YF3mimcbHHBex01JS+/qWlsjGrtHtTGY1+11ZCu/+sARZe4ATxDIw8WptVKqmL8O14 YJ8uJvTDWObryHn3GEeySQqY0Z0erVVfKM/4jxiYpvKdl+873D4H62PBMdsfb+VRCF MzWC9yguRSjAg==
Received: from ( []) by (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09CDFArt025704 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 12 Oct 2020 09:15:10 -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; Mon, 12 Oct 2020 06:15:09 -0700
Received: from ([fe80::e065:4e77:ac47:d9a8]) by ([fe80::e065:4e77:ac47:d9a8%2]) with mapi id 15.01.2044.004; Mon, 12 Oct 2020 06:15:09 -0700
From: "Templin (US), Fred L" <>
To: Mark Smith <>
CC: Robert Moskowitz <>, 6man <>, "" <>, Fred Baker <>
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: AQHWoJm1AtWogmp2iUqGT24OuvvuXw==
Date: Mon, 12 Oct 2020 13:15:09 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-snts-smtp: E157416A8FD5A3A163E5C7295E31E0CA116C6B52FA74B4252A75ECD7046EAA832000:8
Content-Type: multipart/alternative; boundary="_000_2d9a93ce82be4364bf9004ca94812641boeingcom_"
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: Mon, 12 Oct 2020 13:15:25 -0000

Responding to this point again:

Ø  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

IPv6-over-foo documents already do place their own link-specific interpretations on
link-local addresses. It happens in RFC2464, RFC2467, RFC2470, etc. Each of these specs
gives its own link-specific representation of link-local addresses including a prefix
length definition that does not appear in RFC4291. This is the way that link-locals are
defined within the context of *that specific interface type*, and the addresses are
not to be forwarded to other interface types. And, none of these documents say
“updates RFC4291”. What is being proposed in the OMNI spec is really no different
in spirit – it just makes a good use out of otherwise-wasted bits which by the way is
very important on low-end data links such as those that occur in aviation applications.


From: atn [] On Behalf Of Templin (US), Fred L
Sent: Saturday, October 10, 2020 9:12 AM
To: Mark Smith <>
Cc: Robert Moskowitz <>om>; 6man <>rg>;; Fred Baker <>
Subject: Re: [atn] [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)

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.


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: