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

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

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76553A1215; Tue, 13 Oct 2020 16:16:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6GLimhFJcZm; Tue, 13 Oct 2020 16:16:23 -0700 (PDT)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E02223A120C; Tue, 13 Oct 2020 16:16:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (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; d=boeing.com; 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 XCH16-07-07.nos.boeing.com (xch16-07-07.nos.boeing.com [144.115.66.109]) by clt-mbsout-01.mbs.boeing.net (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 XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-07.nos.boeing.com (144.115.66.109) 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 XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([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" <Fred.L.Templin@boeing.com>
To: =?utf-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
CC: Mark Smith <markzzzsmith@gmail.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, 6man <ipv6@ietf.org>, "atn@ietf.org" <atn@ietf.org>
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: <301d22a813914f7c845b4715c4fdd628@boeing.com>
References: <7af0ab36-4a6b-cb44-609c-6e81b364a01c@labs.htt-consult.com> <8009C8E3-E654-4623-BDC8-F794346C33B1@gmail.com> <026e1f94f9d646f38e6912174998b929@boeing.com> <CAO42Z2x7B3sjaV-v1Ox8Vojjv6Vcfpn58PYUOp5jj6iixJau7A@mail.gmail.com> <6c1b8260f1014b4bbcb05e618cb83aa3@boeing.com> <2d9a93ce82be4364bf9004ca94812641@boeing.com> <CAJE_bqc1YKy2ZFrq92gQkbtvq2cvx9EHYwu6rakP1LoLE8_kSw@mail.gmail.com>
In-Reply-To: <CAJE_bqc1YKy2ZFrq92gQkbtvq2cvx9EHYwu6rakP1LoLE8_kSw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 02C70E4BBD425DD1519381FF1A95679F3E0D97BBCC6A52A300F5B5D7CCC0A88A2000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/zBeoZqrwrEPpHsETx1urJUcYvAA>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Oct 2020 23:16:25 -0000

Below:

> -----Original Message-----
> From: 神明達哉 [mailto:jinmei@wide.ad.jp]
> Sent: Tuesday, October 13, 2020 3:54 PM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: Mark Smith <markzzzsmith@gmail.com>om>; Robert Moskowitz <rgm@labs.htt-consult.com>om>; 6man <ipv6@ietf.org>rg>; atn@ietf.org
> 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" <Fred.L.Templin@boeing.com> 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:
> https://mailarchive.ietf.org/arch/msg/its/-OlXR-zYgsPcAioh58RObbigSp0/
> 
> 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