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

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 20 February 2019 23:18 UTC

Return-Path: <brian.e.carpenter@gmail.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 0D9F1130E9C; Wed, 20 Feb 2019 15:18:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 oHYb2Q5mhff2; Wed, 20 Feb 2019 15:18:42 -0800 (PST)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8537E130E58; Wed, 20 Feb 2019 15:18:42 -0800 (PST)
Received: by mail-pl1-x62d.google.com with SMTP id o6so13056695pls.13; Wed, 20 Feb 2019 15:18:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Q5R6KZGEGZsTDI+0JdjoFI1AS03198LpKTzo7l6qjl4=; b=Nn/jFOzhfeWRorZGTTOT24DVto3z7dFxCtl3km4O8VuI53x1ohVvxG43lYU/voOOEf GZucbU33dHqXhXK3CCy0R+5IhPr1QZdhDMPdXZxaR0CvMBy6jzXVeRaXc/UoFTzLHfzi Zo0f0+jYEbM1Lt4T5vCgu0tMq5L50UJ5W0+anh6VSRrgmnZnimJAopLqj3fwRGFwrMux 6wWuHM56LhouwKZJN0AR7fRyKru6ooyMQyZt4rL6rOfNlU9r8DObraM8qihiTk88Luf2 qZEFleNeWf2o1M23f2Qbzu0PQgI/Gy7bw/85z4OGU+HykvepeJRnYe9rQ+df+Ro7RliO g1zw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Q5R6KZGEGZsTDI+0JdjoFI1AS03198LpKTzo7l6qjl4=; b=SfelCvPLwYjz4VCKl5LwKt1Mq/JU3OcYMAWWU1Lyb0EKZiNjQ9WKZ3kpU/UspPBVZw F2FKfs/IPLpwQKI1jKP638Y6w6Sd2UCLZlXoUvA5Vh/kbWKzNxpL6/uS/fLLLgBCOd28 S/JfniUVtzPo2wVrsauQ6GDCw4TDZ1gYUY1XdeYaSF8w7Yw2nFuj5fVYQn8up5Z/y5vq VNxVd0JeJ4lfF0hsSoC5bws2fzjCovP7TxnxFOZ21sDhuHl1eeFsiJJecV2EHdChWTj3 AkQblPi8q+At4J67ETaDUGU1dD02MOBqpepCMBrsBht6KzjsGTgR1PTyXFa4taHFv9Yz oMPw==
X-Gm-Message-State: AHQUAuYS9MA843LHopI3WWQ3s985Xeeb748hAM4W1UKAosCDJENew9sP yBUTjAxdBhTXPxODuaU7d4bKIwzo
X-Google-Smtp-Source: AHgI3IYiyXpPh3vURehPZCYJHXaNjuy8WsVwALt47V6BHlo90ZTMxbdqJBDXqNuxRahjBmgsBGIqKg==
X-Received: by 2002:a17:902:6a4:: with SMTP id 33mr38493746plh.99.1550704721633; Wed, 20 Feb 2019 15:18:41 -0800 (PST)
Received: from [192.168.178.30] ([118.148.79.176]) by smtp.gmail.com with ESMTPSA id y133sm27089193pfb.107.2019.02.20.15.18.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Feb 2019 15:18:40 -0800 (PST)
To: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>, Gert Doering <gert@space.net>
Cc: IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <c6409f1a-a7f6-810e-625d-a2912bf15c7e@gmail.com>
Date: Thu, 21 Feb 2019 12:18:33 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <019c552eb1624d348641d6930829fd1f@boeing.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/6yief0X459itpuYXmJMCz6H2vSY>
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 23:18:45 -0000

On 2019-02-21 11:16, Manfredi (US), Albert E wrote:
> -----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? 

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

> 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. It
isn't needed for enterprise renumbering, and it isn't needed for
enterprise security. This is all very old news. I mean, 10 years
old at least.

NPTv6 as a work-around for a defect in SLAAC when there is an
unplanned renumbering? That's a very large hammer applied to quite
a small screw, IMNSHO. Fixing SLAAC seems like a more scientific
approach.

In the context of homenets and HNCP, NPTv6 is even more pointless.

   Brian

> 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
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>