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

"Templin (US), Fred L" <> Wed, 14 October 2020 12:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A6F293A09FC; Wed, 14 Oct 2020 05:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, 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 yrGTvMrss-4l; Wed, 14 Oct 2020 05:59:34 -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 42E923A09F8; Wed, 14 Oct 2020 05:59:33 -0700 (PDT)
Received: from localhost (localhost []) by (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09ECxToZ000644; Wed, 14 Oct 2020 08:59:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=boeing-s1912; t=1602680371; bh=jq8m20C/GZD55vY039WyLyoukpgjhWtjVqtlHlslaFQ=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=UDtjXseeppzGiNWpb9jge300ygDIaL3AYUZb8d/1YUTxIhLWSr7cHQg/Dom9x2gPb IqSODX1WlVE7wzPZJ3MbAI1DVOW+O0PoKsZp0X0ezg6IsoSwlGwUP6MfyQZBmIkCQa O7VmMiLW13Ux4pJYdTyqLCQwKZdrOytZbvhd6qOz7bFoRI/WHSIl8/SICYVpQhTuIk w4dQwxObvmePeIPnDIxpO2GUpy0kOn2EoqocPqXApECu5qb6+ISUozd4GBgf4JYWdx s+NkF4UbQIit9SO2N3XZAcFQhaUQWCzIuPp6zb366SsRmstYVXloVbdW1yV4b0pRgE hlctMu/pqmywg==
Received: from ( []) by (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09ECxOQj000610 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 14 Oct 2020 08:59:24 -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; Wed, 14 Oct 2020 05:59:23 -0700
Received: from ([fe80::1522:f068:5766:53b5]) by ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Wed, 14 Oct 2020 05:59:23 -0700
From: "Templin (US), Fred L" <>
To: "" <>
CC: =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= <>, "Robert Moskowitz" <>, 6man WG <>, "" <>
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: AQHWoJm1AtWogmp2iUqGT24OuvvuX6mWm5KA//+O2ZCAAS+YAP//pZ2w
Date: Wed, 14 Oct 2020 12:59:23 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-snts-smtp: 9594463C0AF7E2C7E47F13D57A1FA2D110710DE680F8F8F16726FE34C49A6E742000:8
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
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: Wed, 14 Oct 2020 12:59:37 -0000

Ole - see below:

> -----Original Message-----
> From: []
> Sent: Wednesday, October 14, 2020 3:15 AM
> To: Templin (US), Fred L <>
> Cc: 神明達哉 <>jp>; Robert Moskowitz <>om>; 6man WG <>rg>;
> Subject: Re: Embedding IP information in an IPv6 address (OMNI)
> Fred,
> >
> > What in your opinion would be easier - a) update RFC4291 to allow coding of
> > the link-local address 54 zero bits, or b) update RFC4861 to allow routers to use
> > site-local addresses instead of link-local?
> >
> > We need a good answer for this - either a) or b). The benefit of what is being
> > proposed by OMNI is too great to simply say no to both.
> It's unclear to me what the benfits are.
> Would you be able to summarize here, or point to the relevant paragraphs in the OMNI draft? 

The benefits include:

+ a means for configuring a unique IPv6 link-local address (i.e., the "OMNI LLA")
  that is known to be unique on the link without requiring SLAAC or MLD/DAD
+ a means for asserting and/or receiving IPv6 GUA prefixes without explicit
   prefix delegation messaging over the wire

So, for example, if a node has been pre-assigned an IPv6 GUA prefix 2001:db8:1:2::/64
then it can configure the OMNI LLA fe80:2001:db8:1:2:: (but note that this is not RFC4862
SLAAC; it is a simplified means of setting up an administratively-configured LLA that is
known to be unique on the link). The node can then assert its IPv6 GUA to the routing
system by sending an RS with fe80:2001:db8:1:2:: as the source address and with a
Prefix Length value 'N'.

In a second example, if a node has no pre-assigned IPv6 GUA then it can send an RS
message with IPv6 address unspecified. When it gets back an RA, it can determine its
(delegated) IPv6 GUA prefix by examining the destination address. For example, if
the RA message has destination address fe80:2001:db8:3:4:: and the message includes
a Prefix Length 'N' and lifetime value, it can adopt fe80:2001:db8:3:4:: as its own
OMNI LLA and adopt 2001:db8:1:2::/N as its own IPv6 GUA prefix.

There are also IPv4-compatible OMNI LLAs of the form fe80::ffff:[v4addr] and
"Service" OMNI LLAs of the form fe80::[32-bit ID]. All of these address forms
appear in Section 7 of the document, and their use is discussed throughout:

Thanks - Fred

> Best regards,
> Ole=