IETF Logo Mail Archive

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

"Manfredi (US), Albert E" <albert.e.manfredi@boeing.com> Thu, 21 February 2019 01:11 UTC

Return-Path: <albert.e.manfredi@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 13E25126F72; Wed, 20 Feb 2019 17:11:50 -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 5dEVrir13-SX; Wed, 20 Feb 2019 17:11:48 -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 44CC4130E25; Wed, 20 Feb 2019 17:11:48 -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 x1L1Bk3L024011; Wed, 20 Feb 2019 20:11:46 -0500
Received: from XCH16-01-12.nos.boeing.com (xch16-01-12.nos.boeing.com [144.115.66.70]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x1L1Bf8O023058 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 20 Feb 2019 20:11:41 -0500
Received: from XCH16-01-11.nos.boeing.com (144.115.66.39) by XCH16-01-12.nos.boeing.com (144.115.66.70) 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 17:11:40 -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 17:11:40 -0800
From: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Subject: RE: [v6ops] A common problem with SLAAC in "renumbering" scenarios
Thread-Topic: [v6ops] A common problem with SLAAC in "renumbering" scenarios
Thread-Index: AQHUyRB17V+FnESOAEi8Djm3PcxDpKXpHwZQgACcI4D//4RNUIAAmbeA//+QzRA=
Date: Thu, 21 Feb 2019 01:11:39 +0000
Message-ID: <6cc7e8ac9c7e4a898018f117aabf1a88@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> <019c552eb1624d348641d6930829fd1f@boeing.com> <c6409f1a-a7f6-810e-625d-a2912bf15c7e@gmail.com>
In-Reply-To: <c6409f1a-a7f6-810e-625d-a2912bf15c7e@gmail.com>
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: 59019201BDE28B5BF53EF6722E4F10EDD9343DF1102D42CE2E3D978B1C0BD20F2000: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/4GYuC240UgHcjXbverRXym6DV0g>
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: Thu, 21 Feb 2019 01:11:50 -0000

-----Original Message-----
From: Brian E Carpenter <brian.e.carpenter@gmail.com> 

> NPTv6 is not NAT66, as the NPTv6 *Experimental* RFC explains.

Okay, NPTv6. No port translations. RFC 6296.

>> All of the advantages of the basic NAT come to bear, 
>
> I'm not sure that that is true, but NPTv6 brings some, but not all,
of the disadvantages of NAT too, as also explained in RFC6296.

Few of the disadvantages, I'd say. For example, use of IPsec AH is compromised. But many people objected to the mandatory use of IPsec in IPv6 already, because there are other ways of securing content that they prefer to deploy. I think that the wide deployment of NAPT in IPv4 has reduced the severity of the disadvantages of NPT, as application designers have long had to accommodate workarounds?

> NPTv6 as a work-around for a defect in SLAAC when there is an
unplanned renumbering?

I mentioned SLAAC timers as an example. What I should have said is, as far as I can tell, all of the problems we have been discussing in this thread would be solved with NPTv6. Privacy in home nets, renumbering, route aggregation, SLAAC, what else? I can't think of an issue mentioned here that NPTv6 wouldn’t solve.

It should not be all that surprising that the advantages of address independence have become entrenched in IP thinking, thanks to IPv4. So it should not be surprising if many have come to depend on these advantages, and don’t want to give them up.

Bert

v2.23.0 | Report a Bug | By Email