Subject: Re: Is NAT66 a help in migration to IPv6?

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 1 Dec 2020 12:48:21 +0000

Ole,

You nailed it... I was (and still am) fan of RFC 8028 and SADR (draft-ietf-rtgwg-dst-src-routing) but there is a lot of inertia in "enterprise" networks where the catch22 game is still there: little mid-size networks deployed hence manufacturers do not implement :-( Little IPv4 addressing shortage pressure for those mid-size network

BTW, enterprises already have 2 IPv4 addresses per host and it is a pain: the RFC 1918 one and the shared public one... ;-)

-éric

-----Original Message-----
From: ipv6 <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Tuesday, 1 December 2020 at 00:12
To: Brian E Carpenter <[email-masked]>
Cc: 6man WG <[email-masked]>
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).

    The failure of SHIM6 or ILNP or even 8+8 is indeed sad.
    MPMH hasn't exactly taken off. I ran it for a while but gave up. 8028 isn't enough, SADR is a big change.
    Enterprises don't want to depend on host behaviour for exit selection.
    Ref, the slaac-renum discussion I'd imagine Enterprises also wants a level of isolation from ISP/global addressing.
    Keeping track of 4++ addresses per-host isn't a favourite with Enterprise network operators either.
    And we can't exactly say that host implementations and applications have caught up with MPMH either.

    PI or LISP MH are available solutions.
    Multi-homing with NAT66 wouldn't work nearly as well (and you could argue stick with v4 then, which I guess is what they do).

    Ole

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 1 Dec 2020 15:30:21 +0000

FYI
This may just be my interpretation of the comment below, but .......
It is not common at most enterprises that we have two IPv4 addresses per host.    Rather a single 1918 address internally and then NAT to a registered public address for external traffic. 
Thanks
Mike

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Eric Vyncke (evyncke)
Sent: Tuesday, December 1, 2020 7:48 AM
To: [email-masked]; Brian E Carpenter <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: Re: Is NAT66 a help in migration to IPv6?

[External email]

Ole,

-éric

-----Original Message-----
From: ipv6 <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Tuesday, 1 December 2020 at 00:12
To: Brian E Carpenter <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: Re: Is NAT66 a help in migration to IPv6?

    Ole

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 1 Dec 2020 15:46:03 +0000

Michael

Of course, IPv4 host have a single IPv4 address (most of the time) but the network operator has to manage TWO IPv4 addresses per host: one for packets 'inside' and one for packets 'outside' and the NAT log is used to do the mapping... So, it is painful as well (this was my point expressed in a 2nd degree way -- sorry)

-éric

-----Original Message-----
From: "Ackermann, Michael" <[email-masked]>
Date: Tuesday, 1 December 2020 at 16:30
To: Eric Vyncke <[email-masked]>, "[email-masked]" <[email-masked]>, Brian E Carpenter <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: RE: Is NAT66 a help in migration to IPv6?

    FYI

    -----Original Message-----
    From: ipv6 <[email-masked]> On Behalf Of Eric Vyncke (evyncke)
    Sent: Tuesday, December 1, 2020 7:48 AM
    To: [email-masked]; Brian E Carpenter <[email-masked]>
    Cc: 6man WG <[email-masked]>
    Subject: Re: Is NAT66 a help in migration to IPv6?

    [External email]

    Ole,

    -éric

    -----Original Message-----
    From: ipv6 <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
    Date: Tuesday, 1 December 2020 at 00:12
    To: Brian E Carpenter <[email-masked]>
    Cc: 6man WG <[email-masked]>
    Subject: Re: Is NAT66 a help in migration to IPv6?

        Ole

---

From: Mark Smith <[email-masked]>
Date: Wed, 2 Dec 2020 06:14:26 +1100

The main problem IPv6 solves is running out of IPv4 addresses.

Most enterprises don't have the problem of running out of IPv4 addresses,
because they have lots of RFC1918 addresses. The IETF endorsing NAT66 isn't
going to change that (and NAT for IPv6 defeats IPv6's purpose, easier to
stick with current deployed NAT44).

If these sorts of organisations want to be able to access an eventual IPv6
only Internet site, the simplest and cheapest option, which is usually what
enterprises choose, will be to put IPv6 on the outside of their current
NAT44 device, which will also likely be an Internet access policy
enforcement device. IPv6

Thinking that an enterprise will adopt a technology for the technology's
misunderstands what motivates enterprises. Technology solves business
problems, and if there is no business problem the technology solves, it
won't be used (people experimenting with it is solving a business problem
of staff gaining experience with a technology they think they'll soon be
using).

IPv6 is being adopted where it solves a business problem. For example, the
cost of CGNAT and having to buy more public IPv4 addresses is the problem
that is starting and is driving IPv6 deployment in ISPs.

The adoption of IPv6 has been slow, because NAT44 and RFC1918 addressing
"solved" for many years the running out of public IPv4 addresses problem.

Regards,
Mark.

On Tue, 1 Dec 2020, 23:48 Eric Vyncke (evyncke), <evyncke=
[email-masked]> wrote:

> Ole,
>
> You nailed it... I was (and still am) fan of RFC 8028 and SADR
> (draft-ietf-rtgwg-dst-src-routing) but there is a lot of inertia in
> "enterprise" networks where the catch22 game is still there: little
> mid-size networks deployed hence manufacturers do not implement :-( Little
> IPv4 addressing shortage pressure for those mid-size network
>
> BTW, enterprises already have 2 IPv4 addresses per host and it is a pain:
> the RFC 1918 one and the shared public one... ;-)
>
> -éric
>
>     >> 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).
>
>
>     Ref, the slaac-renum discussion I'd imagine Enterprises also wants a
> level of isolation from ISP/global addressing.
>     Multi-homing with NAT66 wouldn't work nearly as well (and you could
> argue stick with v4 then, which I guess is what they do).
>
>     Ole
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 Dec 2020 08:48:30 +1300

Eduard,

It seems that we agree about 99%...

On 01-Dec-20 20:52, Vasilenko Eduard wrote:
> Hi Brian,
> 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
>> From: Brian E Carpenter [mailto:[email-masked]]
>> Sent: 30 ноября 2020 г. 22:52
>> To: Vasilenko Eduard <[email-masked]>; [email-masked]
>>> 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/
>>>> From: ipv6 [mailto:[email-masked]] On Behalf Of Alexandre
>>>> Petrescu
>>>> Sent: 27 ноября 2020 г. 20:28
>>>> To: [email-masked]
>>>> 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 [email-masked] Administrative
>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Jen Linkova <[email-masked]>
Date: Wed, 2 Dec 2020 10:33:17 +1100

On Tue, Dec 1, 2020 at 1:49 AM Vasilenko Eduard
<[email-masked]> 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

---

From: Philip Homburg <[email-masked]>
Date: Wed, 02 Dec 2020 18:02:00 +0100

>level of isolation from ISP/global addressing.

What does 'enterprise' mean in this context?

Is that a company with potentially multiple locations and multiple upstreams?
In that case, the company should just get enough PI space and an ASN.

Is it a company that has a single upstream ISP but multiple independent
links to the ISP? In that case the company might also get PI space, but I
assume many companies would just use a static prefix provided by the ISP.

When it comes to routing and addressing, enterprises have the money to
get their own prefixes, get routing sorted out, etc. Whether they want to
spend the money is of course a different question.

I find the uses cases where people don't want to spend a lot of money a lot
more interesting.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 2 Dec 2020 21:35:36 +0100

Le 01/12/2020 à 20:14, Mark Smith a écrit :
> Most enterprises don't have the problem of running out of IPv4 
> addresses, because they have lots of RFC1918 addresses.

In my setting, I can tell that when facing the problem of extending the
class B network in old office buildings to several new office buildings
the IT had the choice of solution between IPv4 10.x addresses and IPv6
publicly routable addresses which were already available, routed and
connected to the ISP.   The selection was easy: it was IPv4 10.x.  This
was an event of a few years ago (cca 2013).

So yes, most enterprises might have only RFC1918 addresses at the start,
but I would say that even those which have class A or class B or IPv6
/56s at the start for old offices will still go to use RFC1918 addresses
for new offices.

In my setting an Enterprise network is a large managed behemoth with an
enormous set of dynamic and ephemeral apps, printers, displays, blades,
farms, cameras, secrecy, property, various sensors, smart HVAC, climate
and so on. Suffices it for one of these features to not be IPv6-capable,
and for someone to absolutely need that feature now, and the whole IPv6
proposal falls apart.

Other than these issues from a few years back, currently I have other
issues about IPv6 and my office network.  They relate to VPN, remote 
attendance meeting tools and BLE-based smartphone apps for contact tracing.

Alex