IETF Logo Mail Archive

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

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 21 February 2019 21:22 UTC

Return-Path: <brian.e.carpenter@gmail.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 7D506130EC0; Thu, 21 Feb 2019 13:22:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=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 CUkvjRDlyUXp; Thu, 21 Feb 2019 13:22:53 -0800 (PST)
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 86075129B88; Thu, 21 Feb 2019 13:22:53 -0800 (PST)
Received: by mail-pl1-x633.google.com with SMTP id q3so34671pll.4; Thu, 21 Feb 2019 13:22:53 -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=oK+49gRrsCutgwH4VxKdDbTMKwzqK0z9x7j2yLNQz88=; b=B/ayzzt08+iTj5MoWnHWQ2PWUJfrjWhcLVnYkGNubQ57XLmpwpw4bz/qGMOkjfZC2N 7rpsVpNY+OIJIkXYNCC5X+MeOz3AqEQk0y2/+qlTV71SOi028oXJMu2CI/IJiDNQSRfA +HQhn5Tz+7cGNXxNF3n2E5AFfl1SNTazm+/aMmhUy6l4Tj2PqL+MbxGgXkXv+/tP7r2U 3Cw2BWPRtuGnjW2oK9XU+4VC9TriCoI2fhAd6ecwe9z+7Ks4NNqBLFcAu7/QWY2/Qng/ z8U8yoksuY42fwCcUVP0n5OSSKbNEwfZHPv6zmnOGZJJsaoH96jd7NQrSx/fZGlwEcGn b5aQ==
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=oK+49gRrsCutgwH4VxKdDbTMKwzqK0z9x7j2yLNQz88=; b=m3axXoi3oLqejpqhFzqTGsGimoy9bIrvaht08GQCCkj1cJiuTiAcp5XmmeGs6Ei3jV 8hPB7Cnepd/4BJU7yp+BZygc7+/nXPWaYJ2/p2H31QvvaOZ3C3Mc26dbsr3SskxrQOj7 bZB0k+mz5NSFxhj1pqhkiazZtUsRYBrKZKIE0X3hgJ56QUoWjYfDKTe55sRkrE06DJ07 KrlAW0RGmPR/JLaohoMEyM4ERM0nuRUyOgRgsIcW9tLjdmJ4rMBRCoN1xG+amPaIz3G0 Jxs+gntsG8gr7pqx3p6hAGWuczm9vsL27vwRWzgetoE1D3Mz5F8cCQGy9xf61Apxhmeq K5fQ==
X-Gm-Message-State: AHQUAuYiPRwHBZIppUJhrxQSBbX4ja+1u4dqz5lIYzrjL9P0OGwuTxl8 gDsqT8y4yZDAX57JCrjaEyZbfMmO
X-Google-Smtp-Source: AHgI3IaAxkWXn06cyuDYNQBd4AG0rGInstabFsA0ZhK4wavtFbxJ9u4GkW/HhgjJmF6fj7rbLdRkrA==
X-Received: by 2002:a17:902:8d97:: with SMTP id v23mr599458plo.274.1550784172662; Thu, 21 Feb 2019 13:22:52 -0800 (PST)
Received: from [130.216.36.44] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.36.44]) by smtp.gmail.com with ESMTPSA id f3sm1453815pfn.100.2019.02.21.13.22.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Feb 2019 13:22:51 -0800 (PST)
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
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> <CAKD1Yr0HBG+rhyFWg9zh0t3mW486Mjx9umjn+CRqAZg4z9r0dg@mail.gmail.com> <20190221073530.GT71606@Space.Net> <66d78b87461744128d83eaf09e0b460b@boeing.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <458d39d6-e971-59b4-022c-def58e061343@gmail.com>
Date: Fri, 22 Feb 2019 10:22:46 +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: <66d78b87461744128d83eaf09e0b460b@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/ipv6/06A9zpcxIB6lDVA8g4JKKEcXx8U>
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 21:22:56 -0000

On 2019-02-22 10:10, Manfredi (US), Albert E wrote:
> -----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.

Applications that recover smoothly from unexpected transport failures, including unexpected address failures or even unexpected changes between IPv6 and IPv4, have also become part of the culture. Masking NAPT glitches is only one of the things they do. In fact, they conceal NAPT glitches in most cases: we just have the odd RESTful transaction that fails from time to time with no explanation.

   Brian

v2.23.0 | Report a Bug | By Email