IETF Logo Mail Archive

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

"Manfredi (US), Albert E" <albert.e.manfredi@boeing.com> Wed, 20 February 2019 22:16 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 B2952129AA0; Wed, 20 Feb 2019 14:16:48 -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 agoqLXNDQWN3; Wed, 20 Feb 2019 14:16:47 -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 01FD5128701; Wed, 20 Feb 2019 14:16:46 -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 x1KMGiqH001799; Wed, 20 Feb 2019 17:16:45 -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 x1KMGb3p032600 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 20 Feb 2019 17:16:37 -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 14:16:36 -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 14:16:36 -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+FnESOAEi8Djm3PcxDpKXpHwZQgACcI4D//4RNUA==
Date: Wed, 20 Feb 2019 22:16:36 +0000
Message-ID: <019c552eb1624d348641d6930829fd1f@boeing.com>
References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <B6E2EC33-EEAF-40D0-AFCC-BDAFA9134ACD@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net>
In-Reply-To: <20190220213107.GS71606@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: 108F5043C15D8D455BC54FD4A5296282BD5F09A0B228FE87AF3D5C8E6A7AF6D42000: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/aVLaohKZF8GBWiqi_0u55FKBT9c>
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 22:16:49 -0000

-----Original Message-----
From: Gert Doering <gert@space.net> 

> My "NPT" was intended to be an acronym for "Network Prefix Translation",
so yes, exactly this.  Keep ports, keep host part (if desired), just
translate prefix.  We even have an RFC for that :-)

Right. So, why shouldn't this NAT66 idea be taken more seriously? All of the advantages of the basic NAT come to bear, including the renumbering problem in enterprises, including no changes required to SLAAC timers, and sessions easily survive a reboot of the edge router, and yet none of the port translation kludge that made NATs useful in IPv4.

And the solution can be introduced gradually. For homenets, for example, you let things default back to IPv4 as they seem to do today, until the user acquires the CPE with NAT66, or ntil the ISP finishes updating all of the subscriber households. From then on, "it just works." And IPv4 can be retired.

Bert

v2.23.0 | Report a Bug | By Email