Is NAT66 a help in migration to IPv6?

Vasilenko Eduard <vasilenko.eduard@huawei.com> Mon, 30 November 2020 09:40 UTC

Return-Path: <vasilenko.eduard@huawei.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 EC4143A118F for <ipv6@ietfa.amsl.com>; Mon, 30 Nov 2020 01:40:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 I_JjMQfA4tMW for <ipv6@ietfa.amsl.com>; Mon, 30 Nov 2020 01:40:10 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ED333A118E for <ipv6@ietf.org>; Mon, 30 Nov 2020 01:40:10 -0800 (PST)
Received: from fraeml736-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Cl0XL3hlmz67KTY for <ipv6@ietf.org>; Mon, 30 Nov 2020 17:38:10 +0800 (CST)
Received: from msceml701-chm.china.huawei.com (10.219.141.159) by fraeml736-chm.china.huawei.com (10.206.15.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 30 Nov 2020 10:40:02 +0100
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml701-chm.china.huawei.com (10.219.141.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 30 Nov 2020 12:40:02 +0300
Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.2106.002; Mon, 30 Nov 2020 12:40:02 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: "ipv6@ietf.org" <ipv6@ietf.org>
Subject: Is NAT66 a help in migration to IPv6?
Thread-Topic: Is NAT66 a help in migration to IPv6?
Thread-Index: AdbG/FnHwsKbAOh9QKKbKxoijh3awA==
Date: Mon, 30 Nov 2020 09:40:02 +0000
Message-ID: <8a37e3ea48b0451bb9a84ce4658bc8bb@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.198.144]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/hedmTAcnSbqOEvfQqWdlvLeL0jM>
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: Mon, 30 Nov 2020 09:40:13 -0000

IPv6 is much more flexible and complex on 1st hop: many prefixes, 2x more mechanisms for address assignment, SASA algorithm, and so on, so on, so on.
But NAT is still prohibited - Looks like a political decision.
Some people come and say: NAT was very useful (more useful than many new IPv6 features), Please return it. We would like to have this tool too.
The answer is "no", it is "the policy". Or else not enough incentives to migrate from IPv4 to IPv6 (partially true).

IMHO: the market should choose what is more useful and what is less. People should vote by resources (money in 1st place).
NAT66 should be available as a choice.

On discussion below about Mobility (hand-over) support - I do agree with Alexander that:
1. Additional Overlay (based on some sort of tunneling) with independent addressing is the "universal solution".
2. Some use cases do not want the complexity associated with universal mobility solution.
But I do not agree that NAT44 was not the resiliency solution for some scenarios (example: simple topology with 1 inevitable node on the path) - It was. It did decrease the need for universal Overlay solution.
The policy to block NAT66 really increases the importance of Overlay solutions in IPv6.

It reminds me the story that all important application 20+ years ago were running on "clustering" with full memory replication between hosts. Additionally, DC was designed and certified to high level of resiliency.
Then OTT did show that is it better to assume really minimal level of resiliency from infrastructure. If some resiliency is needed - then it is the particular application problem.
IMHO: Both approaches have their market niche (finance does still prefer to keep 100% resiliency on infrastructure level). The world is big enough for this diversity.

IMHO: the world is big enough to have the choice from:
1. no any resilience at all for some scenarios (mostly for the cases when only 1 PA carrier) - applications could go through the pain of address change (some mechanisms are still needed to inform about address change)
2. NAT66 for simplified topologies - permits to preserve address on applications. 1 roaming Notebook or just 1 CPE in the apartment are the very good examples. Or any topology where 1 node is mandatory on the path (single CPE).
3. Overlay with stable address space for complex scenarios. May be even 2 overlay solutions: optimized for roaming host and roaming router.
Let people vote by money.
I could bet that if NAT66 would be available then market niche for Universal Overlay solution would be at least 10x less compare to NAT66 (by number of IP addresses practicing this functionality).

The policy "let's block NAT66" did play well to stimulate subscribers migration from IPv4 to IPv6. Because great majority of them are single attached to Carrier.
The same policy would effectively block IPv4 to IPv6 migration for Enterprises, because they would not agree to deal with the complexity of Multi-home multi-prefix PA environment. Brian and Ole did show (in different RFC) "how deep is the rabbit hole".
IMHO: no NAT66 -> no progress for IPv6 in Enterprises. Because redundant connectivity to Carriers is needed very often.

Ed/
> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Alexandre Petrescu
> Sent: 27 ноября 2020 г. 20:28
> To: ipv6@ietf.org
> Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor
> handset supports PD?
> 
> 
> 
> Le 27/11/2020 à 17:43, Philip Homburg a écrit :
> >> Can you please write a draft explaining how it is supposed to work?
> >> And if it is true as you say that it is currently implemented and
> >> deployed, what implementations support that, how do the topologies
> >> look like etc? I work for a reasonably large vendor I can guarantee
> >> you that we have not implemented support for ephemeral addressing.
> >> ;-)
> >
> > Maybe we are talking about different things.
> >
> > What I'm talking about if that applications on phones keep working
> > even if the phone witch between mobile and wifi connections or moves
> > from one wifi to the next.
> 
> In IPv4 _most_ applications on smartphone do work ok after handover.
> Other particular apps, eg Skype ongoing calls, break after handover.
> 
> The same behaviour is with IPv6.
> 
> If one wants an universal solution to deal with that mobility universally at
> network layer, such that all apps - even the ones that are not improved to deal
> with address changes - will continue working after addresses change then that
> solution is the protocol Mobile IP (there is Mobile IPv4 and Mobile IPv6).  But
> people dont need that.
> Most apps that need to resist handovers do have some sort of handover
> management built in; other apps never need to be handed over either (eg always
> use the 4G everywhere).
> 
> In the case of cars, such a universal mobility protocol Mobile IP has been
> extended with NEMO extensions (network mobility).  But it has some drawbacks
> stemming from the mandatory use of tunnels and from the security risks of its
> route optimization.
> 
> Without Mobile IP, it would be already an exceptional achievement if cars got a
> shorter than /64 prefix from the cellular network, or if it used /65 RAs SLAAC in
> the onboard network.  That would already have a high impact.
> 
> > Similarly laptops can move from one wifi to the next. VM running on a
> > laptop can be taken from one wifi to the next and keep working, etc.
> >
> > Nobody expects to reboot a phone or laptop just because you connect to
> > another wifi. In the case of the VMs running on my laptop, they are
> > bridged, so they pick up new addresses even though there connections
> > stay up.
> >
> > Now the question is we can also make this work for prefixes. Can I
> > give my VMs a separate prefix and expect that to be updated as I move
> > around.
> 
> Mobile IP with NEMO extensions does mobility for prefixes, but it is hard; it even
> use DHCPv6-PD to dynamically get a prefix - through the tunnel - from home.
> Yet it has too much encapsulation and a difficult triangular routing involved.
> 
> In small networks (eg VMs moving between Xeon blades in datacenters) it is
> possible to use something else than Mobile IP.  Maybe DHCPv6-PD with
> CONFIRM messages coupled to a route update mechanism.
> 
> But in distant and non-cooperating networks (eg wifi hotspot and cellular
> networks separated by firewalls) it's impossible to hand-over even an address,
> because the route update involved will provoke 'route churn'.  Imagine then
> handing over an entire prefix (not an address) and the route updates that go
> with it.  One exception to this is the Boeing/BGP/NASA experiments which
> update the routes to a plane ok.  But despite the geographically large areas,
> they are still small networks - the number of hops is small, the number of routers
> is small.
> 
> In these cases, one (myself included), would be very happy if one could rely on
> the layer-2 handover mechanisms of the cellular networks which guarantee the
> allocated address (and potentially a prefix) stays the same within an area of
> certain size as long as the phone keeps heartbeating.
> 
> But we dont have even that: we cant connect a car to a cellular network without
> involving multiple SIM cards, or additional Gateways (Home Agents, VPN
> ageways, etc), additional tunnels, triangular routing, etc.
> 
> > If vendors of network equipment don't care about this, then there is
> > always IPv4 and NAT. Or maybe IPv6 and NAT.
> 
> I doubt the necessity of threatening, even if in this case the threatening might
> indeed reflect a legitimate irritation.
> 
> In IPv4 the question is not well posed.  The fortunate fact that some apps do
> resist handovers wifi-cellular is not thanks to NAT-IPv4.  It is thanks to app-
> specific software dealing with such events, or due to the web browsing nature
> which is bursts of req-response messages during which address changes get
> unnoticed often; their speed is the speed at which human users 'tap' or 'click'.
> Also the nature of audio stream listening where re-transmits and buffer
> accommodate temporary losses of connectivity until next address is allocated.
> 
> It is not IPv4 NAT that helps apps continue after handovers.
> 
> As such, it will not be IPv6 NAT either that will help apps to continue after
> handovers.
> 
> But, conceptually, IPv4 NAT and IPv6 NAT certainly do help to extend the
> networks, to go beyond that bottom.
> 
> It is IPv4 NAT that makes today to extend networks beyond a smartphone.
>   That is the legitimate irritation, because the immediate availablity of
> IPv6 NAT software coupled with the lack of other-than-64 prefixes in cellular
> networks and coupled to the 64-only SLAAC, it leads to this potential fear that
> IPv6 NAT will also extend the networks.  I share that potential fear.
> 
> Alex
> 
> 
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> > Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------