Re: Embedding IP information in an IPv6 address (OMNI)

Bob Hinden <> Mon, 19 October 2020 17:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 80C753A0C9B; Mon, 19 Oct 2020 10:01:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=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 XAgF7uIatFAN; Mon, 19 Oct 2020 10:01:03 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0EEDE3A0C9A; Mon, 19 Oct 2020 10:01:02 -0700 (PDT)
Received: by with SMTP id n15so569045wrq.2; Mon, 19 Oct 2020 10:01:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zVfc9/3GnuPWXZaV0oI5hGkDEmJett1aA+xprZU3pd0=; b=foaJABnpiUw+LF/4Jjh6Vq0aJv7R5bbSNafOraibHqDGVrKMLwr2ijvs1CM83UhIKp r3HXMhJ9IP0L1YBul0C2bGS6ue+erO/4i3Uo+s1gtNBTEFWLsfwKpAU+l6IBjfeZPfZ9 K/ZGOyARfWF067QTS+MwAc5HwsXyGXqDNjBNqDdakQQmVgV0gQ+51bUpGVZllWKtJDou 0/uxlyMqriWuD8Z1CK+IeHyeQpc+AjUPvF/lELgoZT17XRcGjHNqFVWCW+bnkqEIUvr8 oR/2xDba5x06nx2zhIGnHFy7xQ3kHdM9djAujv6Oha6INUrl4E13S5W/T2BN6yA7phe5 ICWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=zVfc9/3GnuPWXZaV0oI5hGkDEmJett1aA+xprZU3pd0=; b=iWbt9sj8xDiWtQg2XOGJllSTOvWfII46AEKVrXx1K3RAfSP8iydb2LamoVjcsne0MV G/9yArpbfz0r7tGIIxIzTlUk5+xTVHhpPgckXOPYRfDxi7DMjHLKdng3t7vRwz95OPno pRGHG86WzYHgILpko3ng3eR8jYMNYhCu69A7XUQs438NbqTti7Wt8itFU5st5PJRjVGd sKtdN12hFlxsb39fOm59oo4H+xCXEc9Be6oGOk2yhIwBEPKIQhNbLHmp83t6C7m6HBHT qNJbAHzp+zquz9VDTvHy4XoIja0fu2csIQ/1FX4wTNAJATtCahXgLSBJJrKUPoUAyGC4 Vc3A==
X-Gm-Message-State: AOAM5324HzPvZRH3EawSH6pFwrSsizHNQf5AFYXZcdkW2MIRUS8zrUAu qnEp2k//XfMnlFHAwnx4BQ8=
X-Google-Smtp-Source: ABdhPJzpv/zKcc/0HwfUDH/FamLWY223DF+tWvhGYLPwAW1Zg6vLit3F4YkK9ce3S7geOZgbkLBCNw==
X-Received: by 2002:adf:fd47:: with SMTP id h7mr155409wrs.245.1603126861369; Mon, 19 Oct 2020 10:01:01 -0700 (PDT)
Received: from ?IPv6:2601:647:5a00:ef0b:a4dc:ec38:3bbc:82ac? ([2601:647:5a00:ef0b:a4dc:ec38:3bbc:82ac]) by with ESMTPSA id p4sm386196wrf.67.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2020 10:01:00 -0700 (PDT)
From: Bob Hinden <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_3498E96B-F7F0-4BD6-8E1D-A450332A8CDD"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Subject: Re: Embedding IP information in an IPv6 address (OMNI)
Date: Mon, 19 Oct 2020 10:00:56 -0700
In-Reply-To: <>
Cc: Bob Hinden <>, "Manfredi (US), Albert E" <>, =?utf-8?Q?Ole_Tr=C3=B8an?= <>, IPv6 List <>, "" <>
To: "Templin (US), Fred L" <>
References: <> <>
X-Mailer: Apple Mail (2.3445.104.17)
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, 19 Oct 2020 17:01:05 -0000


I think most people read SLA as Site-Local Address, especially since you are proposing to use the prefix defined in RFC3513:

   Site-local unicast   1111111011           FEC0::/10       2.5.6

In my view any proposal to reuse this prefix, will need to deal with the issues raised in RFC 3879, the document that deprecated this prefix.   This would need its own document that would obsolete RFC 3879.  It would also need to investigate if deployed hosts and routers block these prefixes.


> On Oct 19, 2020, at 9:40 AM, Templin (US), Fred L <> wrote:
> Bob,
>>> There are very good reasons why SLA were deprecated, I don’t see a reason to change that.  ULAs are intended to replace the use
>> of
>>> SLAs.
>> OMNI Is a good reason to re-instate SLAs. OMNI will also want to use ULAs, but for
>> other and non-overlapping purposes.
> Before this discussion goes too much further, I want to point out that the term "SLA"
> has never been used in association with "Site Local Address" prior to the use in OMNI
> and these current list discussions; the term was introduced by me, but I would not like
> for it to retroactively refer to "site" because it never has before in the past. So, I would
> like to propose that we break that connection starting now.
> What OMNI needs is an address range that is unique within the scope of a layer-2
> spanning tree manifested by a service that joins together the segments of a
> (segmented) link. So, I propose we rename fec0::/10 for its use in OMNI as one
> of the following:
> "Spanning-tree Local Addresses (SLA)"
> "Service Local Addresses (SLA)"
> "Segment Local Addresses (SLA)"
> The term "site" is not relevant to OMNI and would no longer be used in that
> context (once we submit a document update, that is). Would that address
> the concern?
> Thanks - Fred