Re: Is NAT66 a help in migration to IPv6?

[Brian E Carpenter <[e-mail]>]

Eduard,

It seems that we agree about 99%...

On 01-Dec-20 20:52, Vasilenko Eduard wrote:
> Hi Brian,
>> Answering the question in the subject field: No [RFC2993] [RFC4864] [RFC6296].
> 2 RFCs are informational. 1 is experimental.

Indeed, but 2993 is an IAB document and architectural in nature, and 4864 is certainly only descriptive. 6296 is experimental because it is not, in fact, the IETF's recommendation. It was very controversial to publish it at all.

> And dozens RFCs where NAT is proclaimed "never-ever" in a very strong form.

I don't know about "dozens" but yes. NAT44 (and worse, NAT444) has been very harmful to many users who don't even know it, due to lost transactions that are never logged by anyone. It was probably the most lazy hack ever to reach the mass market.


> I do agree that RFC 8028 is the best from what we have for this problem now.
> You said "run two prefixes everywhere" - it is not enough to explain the essence of this RFC.
> One additionally should mention that it reverts the host logic: source address should be chosen first, only then next hop should be decided.

Correct. I believe that if you add RFC 8028 to RFC 6724, that is what happens.

> Unfortunately, I believe that RFC 8028 would fail market acceptance too. For 2 reasons:
> 1. As Fernando said - it is not "MUST-MUST".

We can fix that when Host Requirements is updated again. It was quite new work when RFC 8504 was published.

> I would say more: it is written in the gentle language without clear recommendation to change host logic. It is possible to read only "between lines". Hence, not many people have even understood this.
> 2. The problem is very complex (it is not the fault of RFC 8028, just IPv6 has too much flexibility). Comparing to current situation - Enterprise admins would not agree to all this complexity.

Yes, it means that the address management mechanism must manage several prefixes.

> Yes, NAT has some problems. Tom is right with his list of challenges.
> But in the current satiation - it is the only way to persuade Enterprises to migrate to IPv6.
> They do accustom to NAT - it is the natural path for them.

That doesn't mean it's right.

> Except PI addresses that I am not sure is possible to promote properly.

I still don't believe that scales to tens of millions of sites.

>> PS: Any overlay would not be accepted as the mainstream solution too.

Agreed.

      Brian
> 
> Eduard
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:[e-mail]]
>> Sent: 30 ноября 2020 г. 22:52
>> To: Vasilenko Eduard <[e-mail]>; [e-mail]
>> Subject: Re: Is NAT66 a help in migration to IPv6?
>>
>> Answering the question in the subject field: No [RFC2993] [RFC4864] [RFC6296].
>>
>>> IMHO: no NAT66 -> no progress for IPv6 in Enterprises. Because redundant
>> connectivity to Carriers is needed very often.
>>
>> It is, and that's why the failure of SHIM6 is very sad. But the real failure is the
>> reluctance of enterprise operators to do what comes naturally in IPv6: if you
>> have two providers, run two prefixes everywhere [RFC8028]. That's why there is
>> still, sadly enough, a case for [RFC6296]. Sadly, because [RFC2993] explains why
>> NAT or NPT is a problem, and [RFC4864] explains how to avoid them (and needs
>> [RFC8028], which came very late, sorry).
>>
>> Regards
>>    Brian Carpenter
>>
>> On 30-Nov-20 22:40, Vasilenko Eduard 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
>>> --------------------------------------------------------------------
>>>
>