Re: Is NAT66 a help in migration to IPv6?

Jen Linkova <furry13@gmail.com> Tue, 01 December 2020 23:33 UTC

Return-Path: <furry13@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 802DC3A0B25 for <ipv6@ietfa.amsl.com>; Tue, 1 Dec 2020 15:33:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 RoNhZJ9aXKx7 for <ipv6@ietfa.amsl.com>; Tue, 1 Dec 2020 15:33:30 -0800 (PST)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 201F43A0B23 for <ipv6@ietf.org>; Tue, 1 Dec 2020 15:33:30 -0800 (PST)
Received: by mail-qk1-x72d.google.com with SMTP id n132so3176007qke.1 for <ipv6@ietf.org>; Tue, 01 Dec 2020 15:33:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=kbL1n+sZrxMSRxj06lVzxRuoNvNqyOY6nS4MhmT4ewQ=; b=Er+zCWf+j6rAGhpPZp18JYKfKV33WutcyaorBh13UnffVsL/ZVVD1vahBzqEfEB68l 3oC5TncfFiHOoTzo3tanuJpae13svwf2Mbs4MlotfQP6H5lVpGGRr2scMh5ZjxBXyojK goE5AgETUGwNemhd/UstQa+0+mH1SLbh2a++jpF+tWt1uKybUr/FhSE1Ly460OXxXsVC yjkSwtpMzR157V3N6vsYGMKVCU8vFb/EJGnDDoGmFgnRZxidK3dz3EsvjyUocFyh+icY lU903YIwHc/Fps88UVZxIg8GFyf58erZce4ht4PKkvU3cygPSI25sGwKQ1lsPnooz8nl a8jQ==
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:content-transfer-encoding; bh=kbL1n+sZrxMSRxj06lVzxRuoNvNqyOY6nS4MhmT4ewQ=; b=TpcUzMwvQ87YukHfiyAEA741IUoaqn+Wh/FsPPwkRkvUxfzjbCylsJ7LTYemwXC0+E 4ElcEd7abV/LwGzZXX3D5XTpN33mxP2+ePbyjxqI97LNhlmk9fu/pYBCApt60ZyWf/J1 YbUgXqo1BO6VW3u2Cp/upbL8CT23xVmlfTY2rMXH1ReOQdthkRK0Ujsji6a9+2Gnn1VH aOlPRxWXY+f9DeerzDsqyskB/bafL9g434KZcDZlLuvKU+KfBf1CXu2PuQeP2xuTATD7 cgqUGViJIZYi/XW279nLF2w7PCoTJI3VWN3vVZ4qLpmiq/srR9/Qv/FfpMo7Ciiz/e0C gYTQ==
X-Gm-Message-State: AOAM5326RmHOCDh8Zd3Yn0FtvTyA5ho4ZyrLacHtZBQ/U6jwGid10dsH O3abJrNER+eIbJ69lkyr7PVj3+84NpFFdiF93ts=
X-Google-Smtp-Source: ABdhPJyWpXDDm1Lw5RMZvMF7PSK+MF7iduX7OT3bNVdx7CCevWsi1ON5YWlVszc06XPUGXWNds7lH6gzBLbu+cOQ3vQ=
X-Received: by 2002:a37:941:: with SMTP id 62mr5489604qkj.444.1606865608959; Tue, 01 Dec 2020 15:33:28 -0800 (PST)
MIME-Version: 1.0
References: <8a37e3ea48b0451bb9a84ce4658bc8bb@huawei.com> <CAKD1Yr2j5KmjvMdUcPE9jH68iz4s_5qEKcP63VM66dPNSbefJg@mail.gmail.com> <bdbf6662d8624fa9a163fbd2087e882f@huawei.com>
In-Reply-To: <bdbf6662d8624fa9a163fbd2087e882f@huawei.com>
From: Jen Linkova <furry13@gmail.com>
Date: Wed, 02 Dec 2020 10:33:17 +1100
Message-ID: <CAFU7BARszS59vnYAtKXi2qzP=HVxtgbFJBLdriZ40bPA5J32Tg@mail.gmail.com>
Subject: Re: Is NAT66 a help in migration to IPv6?
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: Lorenzo Colitti <lorenzo@google.com>, "ipv6@ietf.org" <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/whP8elaiMURAGJ_Xi3Nbu2Y8ptk>
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: Tue, 01 Dec 2020 23:33:32 -0000

On Tue, Dec 1, 2020 at 1:49 AM Vasilenko Eduard
<vasilenko.eduard@huawei.com> wrote:
>Just in my opinion: complexity of MHMP on PA addresses (see RFC 7157 and RFC 8028) overweights the complexity of NAT that exist only for some applications.
>Looking to it – “other people” (responsible for networking) would block IPv6 progress in enterprises. Especially if they would read above mentioned RFCs

I do not see how those things are more complex than STUN, for example.
They are not more complex, they are just new.
I suspect (might be wrong indeed) that there are not so many people
reading RFCs anyway. The majority of network engineers would read the
vendor documentation first.
Most of the complexity in the modern networks are very well hidden
from people operating those networks.
RFC8028 talks about hosts mostly, so very few changes are required
from the network.
It might be a shameless plug ;) but I did try to make rfc8475 as
simple as 'vrrp uplink tracking' which any enterprise engineer can
configure, I hope ;)
So it's all about *vendors* providing configuration knobs and
configuration guides.

> It should be not be a problem for big Enterprises that are ready to manage their own PI addresses.

Big enterprises - ones which could 'vote with money' are usually using
their PA address space as they are usually LIRs themselves.
PI addresses are more suitable for multihomed SMB.
So if an enterprise is large enough to vote with money, then they do
not need NAT66. AFAIR in Europe setting up an LIR would cost EUR2000
sign-up fee + EUR1400/year.
Definitely less than it would cost to deploy NAT.

> I am wondering: is it possible to migrate more Enterprises to PI addresses?

It would be an enterprise choice. The obvious drawbacks for using PIs
instead of using PAs from the uplinks (we are not comparing 'PI va
getting your own PA' as the latter is in most cases the best choice
anyway)
1) For the Internet at whole: inflating the global routing table and
increasing instability
2) For the enterprise itself:
   - Money. I've stopped following all those address allocations
policies development but AFAIR getting PI is not free, at least in
some regions. You either need to be an LIR (then you have your own PA
space) or pay an LIR to get PIs for you.
   - you need to run BGP. In some cases it's just not possible as the
uplink might not even support it.

-- 
SY, Jen Linkova aka Furry