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

"Templin (US), Fred L" <> Sat, 10 October 2020 16:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D75313A159F; Sat, 10 Oct 2020 09:12:08 -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 pNeMUh4dM8Gi; Sat, 10 Oct 2020 09:12:03 -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 B75813A159E; Sat, 10 Oct 2020 09:12:03 -0700 (PDT)
Received: from localhost (localhost []) by (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09AGC1D9004227; Sat, 10 Oct 2020 12:12:02 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=boeing-s1912; t=1602346322; bh=xh7cI6P+BuAEfPl4bESQXTK39YFH7yomB4ISQEexRFU=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=q3/YYCChHvmx00NsfJSVGYl5EnlbbRZvOfbgM6xAIx7OWiNJ371X5JxtyVi8w+5D4 JFS+fvKaZ2xWdbXuV/OxiNSc5E65TRvOH7WAq4RoGXoVjY8uooGeOeYdHuW27APfUa +9MQlPf3ASXBQwgSFG2rU9jPpYYpeO7UTaOgezDBlLSIDv0wnXsryZ3AE8RJRTLSTD KS3YDHL245lLxlnUSOGjKdL5iqTmGHauEvGH8HuSEm6+uEUL21+XQkoHY9I71mDNIt qng43Hui73OFsLBLC87AwDRtcN0KF0DUc8ChlpAx5+ouOVcz2+yPDcio3osEmQTaV4 ci9N8Amm/WhHQ==
Received: from ( []) by (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09AGBuNO003232 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Sat, 10 Oct 2020 12:11: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; Sat, 10 Oct 2020 09:11:55 -0700
Received: from ([fe80::e065:4e77:ac47:d9a8]) by ([fe80::e065:4e77:ac47:d9a8%2]) with mapi id 15.01.2044.004; Sat, 10 Oct 2020 09:11:55 -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+g8A==
Date: Sat, 10 Oct 2020 16:11:54 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-snts-smtp: 2A7C7FDE3B4EBEE21ACDC87F7172B802304467D863C9E06E0D7998CAA38FC5642000:8
Content-Type: multipart/alternative; boundary="_000_6c1b8260f1014b4bbcb05e618cb83aa3boeingcom_"
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: Sat, 10 Oct 2020 16:12:09 -0000

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 <>om>; Robert Moskowitz <>om>; 6man <>rg>;
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: