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

Mark Smith <> Fri, 09 October 2020 23:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19F513A162D; Fri, 9 Oct 2020 16:30:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.595
X-Spam-Status: No, score=-1.595 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, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5uoIhAJ2JqxM; Fri, 9 Oct 2020 16:30:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 776F53A162A; Fri, 9 Oct 2020 16:30:19 -0700 (PDT)
Received: by with SMTP id w141so11950114oia.2; Fri, 09 Oct 2020 16:30:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u/e3ebpzVCRDcO3++cJQtnKoHHEKJixAy6m1VdkuJYI=; b=QU9UnWELq3ahPLzFN3EmrcPBn+uR5c6HPXCfFtpToMUNkNJH55VQleTryjdI1/hjgg HwMMSahwMOcM7F6AZGipD9vjyatspvUvTv0qLUS3mTtTWY9NaWedZuPXbaAAeWVEGUhl sC76hkZw13X/zmgJhNqKKUVj8K7jcvrEgnxqQVAQ7Ewm+3j+9CESqTP9j9lGz/DKaUaA p14mZff098CjZ1JuOCxzHizHqzAIVTlHiEuvz6P74OTCMYt/yY6YBEp+2y4DRc26KEem iUqouJj/AmoQC9fn+L5kVvFBX158VVRGBEV6f7N+5Fg76/WvCvFr3a9bsacLSG1zX0fb ar0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=u/e3ebpzVCRDcO3++cJQtnKoHHEKJixAy6m1VdkuJYI=; b=CZA5yq7usFHPdQAkjJvCZe7oIvHOVHpp4o0U9tg4RZfXerGn2rb0ZaXKEvYqwBN3hx tLTSHSakx+qFVvXeR2VQ/yVOv05Mkod0WH5pfo6RC+P9hg6Cb0KwkLlby23xRNm9IzhZ bnLkrmCQ8Pkjrdtq4VlMQJFaIcIqJ4v2ZOIS/FR9IVCGGSLv/+neQ+s1YLtmbZ9EeNNw YZpnmkbtqF+1RKNv31e23se74JF+6/tnP7C00lTR9X/qT4U0C3JsAJfMnfXecy3frt2F 8AyMO5nsat62YP1Tgn7dyWApQniOiohAovKDMKwfRen1uF3itS+JJCzBHxyGjlVKk+nD mLNw==
X-Gm-Message-State: AOAM5332Lkn+JWAJmV4SGB2BejYKzMAARcSSWWLAxWnbsyGeomi/eqVT jjqj3v7i9RuC5sbLyKNNdlsak5kts81lQE7+DFE=
X-Google-Smtp-Source: ABdhPJxoiS1fQImdHRCBYqbPtd24eziqUNp8KpR4AKcpkGH6J6UYHX+9uOyMKiQv4xzzEnLTDFBEdhQJG5B5C3CvQs0=
X-Received: by 2002:aca:b206:: with SMTP id b6mr4099369oif.54.1602286218693; Fri, 09 Oct 2020 16:30:18 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Sat, 10 Oct 2020 10:30:06 +1100
Message-ID: <>
Subject: Re: [EXTERNAL] Re: [atn] Embedding IP information in an IPv6 address (OMNI)
To: "Templin (US), Fred L" <>
Cc: Fred Baker <>, Robert Moskowitz <>, 6man <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000e4d28505b145546f"
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: Fri, 09 Oct 2020 23:30:21 -0000

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

> Fred,
> > 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:
> --------------------------------------------------------------------