Re: Is NAT66 a help in migration to IPv6?

[Lorenzo Colitti <[e-mail]>]

The problem with your statement "should vote by resources" is that NAT
reduces the cost of the party that deploys it (network operators) by
increasing the costs of the parties that do not deploy it (app developers,
OS developers). Those latter parties are the ones pushing back against NAT.

On Mon, Nov 30, 2020 at 6:40 PM Vasilenko Eduard <
[e-mail]> wrote:

> 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:[e-mail]] On Behalf Of Alexandre
> Petrescu
> > Sent: 27 ноября 2020 г. 20:28
> > To: [e-mail]
> > 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 [e-mail] Administrative
> > > Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> > >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>