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 21:10 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 53E991311D1; Thu, 21 Feb 2019 13:10:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 9GuRYNnFWRjg; Thu, 21 Feb 2019 13:10:40 -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 6AFF9130E6E; Thu, 21 Feb 2019 13:10:40 -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 x1LLAc70008654; Thu, 21 Feb 2019 16:10:38 -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 x1LLAW2m008020 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Thu, 21 Feb 2019 16:10:32 -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; Thu, 21 Feb 2019 13:10:30 -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; Thu, 21 Feb 2019 13:10:30 -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//4RNUIAAoKWAgACD6gCAAFvVIA==
Date: Thu, 21 Feb 2019 21:10:30 +0000
Message-ID: <66d78b87461744128d83eaf09e0b460b@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> <CAKD1Yr0HBG+rhyFWg9zh0t3mW486Mjx9umjn+CRqAZg4z9r0dg@mail.gmail.com> <20190221073530.GT71606@Space.Net>
In-Reply-To: <20190221073530.GT71606@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: 6CF9DC8BC226351F56A11AB361627CF9A98EF36588F793A1626BF6B5B6856B4F2000: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/s66UD1NEw5CWRSOpiqza57KdQnc>
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: Thu, 21 Feb 2019 21:10:42 -0000

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

> NPTv6 does not need state, so no keepalives and battery impact.
>
> Applications today seem to be all "HTTP(S)" or "QUIC", and they all had to
learn how to deal with NAPT.  New protocols that embed IP addresses are 
killed by IPv4 NAPT anyway, so that ship has sailed - and everything that
doesn't care about embedded IP addresses will nicely work throug NPTv6.

That's my feeling about this too. NAPT in IPv4 has solved a lot of the application issues, and even more than necessary for NPTv6. Plus, we, I mean me, related to work, have dealt with very many IPv4 "basic" NAT firewalls, for years now, and they are really quite trouble-free. I think that the problems Fernando is concerned about should be manageable with NPTv6.

More to the point, I'm not sure how feasible it is, long term, to NOT have this level of address independence. From my point of view, it has sort of become part of the culture.

Bert

v2.23.0 | Report a Bug | By Email