Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

"Manfredi (US), Albert E" <albert.e.manfredi@boeing.com> Wed, 20 February 2019 20:20 UTC

Return-Path: <albert.e.manfredi@boeing.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8BC130E96; Wed, 20 Feb 2019 12:20:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 dQQ9Q2dV9N43; Wed, 20 Feb 2019 12:19:59 -0800 (PST)
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 C88ED130E9A; Wed, 20 Feb 2019 12:19:57 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id x1KKJtrq019438; Wed, 20 Feb 2019 15:19:55 -0500
Received: from XCH16-01-09.nos.boeing.com (xch16-01-09.nos.boeing.com [144.115.65.234]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x1KKJmsp018370 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 20 Feb 2019 15:19:49 -0500
Received: from XCH16-01-11.nos.boeing.com (144.115.66.39) by XCH16-01-09.nos.boeing.com (144.115.65.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1591.10; Wed, 20 Feb 2019 12:19:47 -0800
Received: from XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323]) by XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323%4]) with mapi id 15.01.1591.014; Wed, 20 Feb 2019 12:19:47 -0800
From: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>
To: Gert Doering <gert@space.net>
CC: IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Thread-Topic: [v6ops] A common problem with SLAAC in "renumbering" scenarios
Thread-Index: AQHUyRB17V+FnESOAEi8Djm3PcxDpKXpHwZQ
Date: Wed, 20 Feb 2019 20:19:47 +0000
Message-ID: <28fbc2c305c640c9afb3704050f6e8d7@boeing.com>
References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <B6E2EC33-EEAF-40D0-AFCC-BDAFA9134ACD@consulintel.es> <20190220113603.GK71606@Space.Net>
In-Reply-To: <20190220113603.GK71606@Space.Net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [144.115.204.6]
x-tm-snts-smtp: 5CC738F2393790F25B78D1939AB2CF743C3AE181D140DBC0788078781482D5842000:8
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/f1W22Vmd15hdtCAl5JQc4QXJyjo>
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Feb 2019 20:20:01 -0000

-----Original Message-----
From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Gert Doering

> There's so much wrong with current IPv6 standards and implementations
and processes that "just go with NPT" would save a lot of pain.

Wait, whether that's partially said in jest or not, NPT was invented primarily to add the 16-bit Port ID to the limited 32-bit address space of IPv4. But with IPv6, a "basic NAT" would not need to also do port translation. Plenty of addresses available. And it would make addresses behind the NAT as stable as anyone could want. Just a 1:1 mapping, with the WAN addresses.

Doesn't that take away most of the pain, maybe all of the pain? And solve this problem?

(Sometimes, to solve a vexing problem, you have to do a "paradigm shift.")

Bert