IETF Logo Mail Archive

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

Lorenzo Colitti <lorenzo@google.com> Wed, 20 February 2019 23:43 UTC

Return-Path: <lorenzo@google.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 CCAC412D7EA for <ipv6@ietfa.amsl.com>; Wed, 20 Feb 2019 15:43:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Level:
X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 fajpTKrcKzEc for <ipv6@ietfa.amsl.com>; Wed, 20 Feb 2019 15:43:34 -0800 (PST)
Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 F213F1274D0 for <6man@ietf.org>; Wed, 20 Feb 2019 15:43:33 -0800 (PST)
Received: by mail-it1-x130.google.com with SMTP id e24so6039514itl.1 for <6man@ietf.org>; Wed, 20 Feb 2019 15:43:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=89jIuysLQPQkJXmMqbkh0Gz7Jsd4Q9zSmqAZdMmc8k4=; b=K9oCdZc+Xp8BWXJ46yGulEpiGR9SvZhCEIVnburfE3BABZ4/Dx6AiiFjyPEpkGpUFk 58Do7HCww/gz1LGtdRa+CsJ1HXY+r1gDn96U7JJ6GkjStQ+lNfXeVh19jGXzFFDplcBg erMm/CyFLAK6d1nQkH7/1+hLYMfZpW5y6mOrCcNUJAYxTnBKV5nAe+bnEaboPcxAi1ha 86hoFDTuo6A5LYYYVmuQlp1dSUhj8OHe7VYGralfFKpYGsC+RYqYyVy8sJ48uJU0DUte RowPhyH7mzd+Rl1GB6qghohvyd5QYXSKsUfZOrappUU1O6EzX26bntG1P5CQNqeadYUY OOIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=89jIuysLQPQkJXmMqbkh0Gz7Jsd4Q9zSmqAZdMmc8k4=; b=I2xbW7CPYi0yITvhaOH6pww/edpgm557ydpx7WxC5boAYwoMS6tD11suPxNK29exb1 9KdQW7cnpu1oo1LYBJfacqMFeSpMt5W3yEmRBs3AjH8VV+hYrD23pVmoUq9e2xSY+AVj RYIqpBvUKXkWbIbVVb2NgpQSLxx5l4t7fW0qofJ7RrTV89OFsuWVb4HcriXUq32Cs4pA Hr8KKk2/93CSmyIGeJH+mk5jeuYh+H8z5X21/qIi+Nlr9wdoViuPt6uiFqOwYfeXOTVW //0Qv4VWb9Vf7y5uoviMXk3bX550O2Z5COZuedS8qapUG6ZZTJydLkYx6VlGcS8kywz0 J4yg==
X-Gm-Message-State: AHQUAuY39YjBIPPJd2FZ+YkSXaBEJeMLfPn0fc1zBVo5d5AlGqgMhRq6 Gh1s944bk0ajiiDYrLiVo9Nqj0gI2L90KRmIzbFCoA==
X-Google-Smtp-Source: AHgI3IasoAX/WjUI26qZpqiRCQY9WuFQIdlBdeSL0q0HjPsIVw/yDY4EY7/qrCgQS4bdF2k6ikoDTRPpmZABTm3Ok+M=
X-Received: by 2002:a24:4290:: with SMTP id i138mr6758613itb.24.1550706212732; Wed, 20 Feb 2019 15:43:32 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <019c552eb1624d348641d6930829fd1f@boeing.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Thu, 21 Feb 2019 08:43:21 +0900
Message-ID: <CAKD1Yr0HBG+rhyFWg9zh0t3mW486Mjx9umjn+CRqAZg4z9r0dg@mail.gmail.com>
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
To: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>
Cc: Gert Doering <gert@space.net>, IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f67ac305825becb7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/xBLtKl_KmhkY6csZhERsSHbFqPs>
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: Wed, 20 Feb 2019 23:43:37 -0000

On Thu, Feb 21, 2019 at 7:17 AM Manfredi (US), Albert E <
albert.e.manfredi@boeing.com> wrote:

> 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.
>

Because the advantages are for network operators have corresponding
disadvantages for application developers and thus for users. Application
complexity and brittleness due to NAT traversal. Battery impact of NAT
keepalives. Higher-latency due to relaying and rendezvous. And so on.

v2.23.0 | Report a Bug | By Email