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

"Templin (US), Fred L" <> Tue, 13 October 2020 23:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D76553A1215; Tue, 13 Oct 2020 16:16:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 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_H2=-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 P6GLimhFJcZm; Tue, 13 Oct 2020 16:16:23 -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 E02223A120C; Tue, 13 Oct 2020 16:16:22 -0700 (PDT)
Received: from localhost (localhost []) by (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09DNGJpb029211; Tue, 13 Oct 2020 19:16:21 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=boeing-s1912; t=1602630981; bh=CSr5Zry2ac44tXF5nAqSLv1qAMU+6denZO5PA7ZzCEI=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=Nr6IEH8CL7CZUnxBkipHLrpAvrl8RRIfbquLYNmZt/qY8LgMwVlFeFj6AnG6I6GVy nF54TLNIBPZO/oHs7U8cKkxZQarR5Q5skH+F+IydqpA/cPlNCxFX35U1QQML7qViO3 XVUmDUKmFMIjmpE7CPf7fcoSrQ48WNWavBZUCIz3OiODwNlQlVQzbCLp+1186arxLc Rlm7YooYIAfiLano19nd9bgWDWWnahPN6jWGjsDKFtAg8lB3r6Qa6x/4HC4u5fJZ9r VmvtNkQAuYfMSUqTfSnpWx7J3DZGm5mx5zoh3C6r/dXcybv5RfyA7ebaaUbFKPiEX9 88ffbetOTQjGg==
Received: from ( []) by (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09DNGFh6029083 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 13 Oct 2020 19:16:15 -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; Tue, 13 Oct 2020 16:16:14 -0700
Received: from ([fe80::1522:f068:5766:53b5]) by ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Tue, 13 Oct 2020 16:16:14 -0700
From: "Templin (US), Fred L" <>
To: =?utf-8?B?56We5piO6YGU5ZOJ?= <>
CC: Mark Smith <>, Robert Moskowitz <>, 6man <>, "" <>
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//+O2ZA=
Date: Tue, 13 Oct 2020 23:16:14 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-snts-smtp: 02C70E4BBD425DD1519381FF1A95679F3E0D97BBCC6A52A300F5B5D7CCC0A88A2000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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: Tue, 13 Oct 2020 23:16:25 -0000


> -----Original Message-----
> From: 神明達哉 []
> Sent: Tuesday, October 13, 2020 3:54 PM
> To: Templin (US), Fred L <>
> Cc: Mark Smith <>om>; Robert Moskowitz <>om>; 6man <>rg>;
> Subject: Re: [atn] Re: Embedding IP information in an IPv6 address (OMNI)
> 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
>       consistent.
> 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.

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.

Thanks - Fred

> --
> JINMEI, Tatuya