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

神明達哉 <> Tue, 13 October 2020 22:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 476BA3A11F5; Tue, 13 Oct 2020 15:54:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EIq39FX9qwPq; Tue, 13 Oct 2020 15:54:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F36703A11F4; Tue, 13 Oct 2020 15:54:01 -0700 (PDT)
Received: by with SMTP id l6so986298vsr.7; Tue, 13 Oct 2020 15:54:01 -0700 (PDT)
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:content-transfer-encoding; bh=lSvHZ3GguGgZy6sI7qMOTX3O4SNfIiyx7yiNK5A4Sn0=; b=NIf5c8p4FYTUgYpiiu9bftANtS05MGwrQofP3hGPSNvLFYHVk+Aqj8AjCMI3Grg/DF 1U6TcKO/Lg/0QCcCNbyuN5pKpq8s+PsojF61tT8xaQ2lCAcWXk0TI2mlm9wrS+Lgw+5F 2pQmNInbU21ITnu8hRh7g8HjMe89fjooliUisXHCL7HOaLUgEJ+QZWNNwqWfo+6CMI4Y oUeKsj3y+QnaUNeU7b7JSniIWehpxjT33GOZU/GdPxcGtsjphZ5NgAzeTEtzmD0z1Vhi NGkELy6gQSBchTyCO1+Wm2VqzthW/vfysDKZM2tu4A47mNjuBKoRDVj4n9cEXTWZcp78 sORg==
X-Gm-Message-State: AOAM532+/Muo/POvjQRZfCheBhyJeZmiUu3rQQIgC8/S2s70KqErRD2b 6+9xiQJ+vGS8Yqmg7BrRMfIxsJXr3hpBXSuI9m8=
X-Google-Smtp-Source: ABdhPJyf5Dc8/lFmta/YrZlif/8eJk8tug8PBq3BmVGczcElY5OQjNxeTrYeuLW+9WSK9ibqsOCy4Wb/7uN4dK7WzDI=
X-Received: by 2002:a67:f453:: with SMTP id r19mr1850933vsn.43.1602629640896; Tue, 13 Oct 2020 15:54:00 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Tue, 13 Oct 2020 15:53:49 -0700
Message-ID: <>
Subject: Re: [atn] [EXTERNAL] Re: Embedding IP information in an IPv6 address (OMNI)
To: "Templin (US), Fred L" <>
Cc: Mark Smith <>, Robert Moskowitz <>, 6man <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Tue, 13 Oct 2020 22:54:04 -0000

At Mon, 12 Oct 2020 13:15:09 +0000,
"Templin (US), Fred L" <> wrote:

> 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”.

These three RFC don't have to update the addressing architecture RFC
(which is, currently, RFC4291) in this regard in that all of them
specify the intermediate 54 bits are zeros and the interface
identifier length being 64 bits.  It's the same for other existing
link-specific RFCs I know of.

If a new link-specific specification wants to use a non-0 value in
that 54-bit field, it will have to formerly update RFC4291 so that all
relevant RFCs are still kept consistent.  That's the sense when we
revised SLAAC as described in Section 2 of RFC4862:

   interface identifier -  [...]  The
      exact length of an interface identifier and the way it is created
      is defined in a separate link-type specific document that covers
      issues related to the transmission of IP over a particular link
      type (e.g., [RFC2464]).  Note that the address architecture
      [RFC4291] also defines the length of the interface identifiers for
      some set of addresses, but the two sets of definitions must be

We had essentially the same type of discussion about 1.5 years ago,
where the char of the relevant WG declared we can't just publish a
link-type specific doc that would become inconsistent with RFC4291:

I don't necessarily say such a change is never possible, but if
there's a lesson from that previous discussion, it would be that it's
not as easy/trivial as you might think.

JINMEI, Tatuya