One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

Sat Jan 13 12:09:56 UTC 2024

Let me start with I think we're largely on the same page here.

The transition I see happening next is that the consumer traffic largely
moves to IPv6 with no CG-NAT.  That is, if you're at home or on your phone
watching video or doing social media or using whatever app is all the rage
it's going to be over IPv6.

My point was largely that I believe that at some point the big consumer
(not business) focused companies are going to realize they can use market
forces to encourage the remaining IPv4-only eyeball networks to transition
to support IPv6 connections from their customers.  I don't know if the
timeframe is next year or 20 years from now,  but I do know the tech
companies are very good at looking at the costs of maintaining backwards
compatibility with old tech and figuring out ways to shed those costs when
they no longer make sense.  If they can utilize various forms of pressure
to make this happen quicker, I fully expect them to do so.

Inside a business network,  or even at home,  it wouldn't surprise me if
we're both long gone before IPv4 is eradicated.   I know there is going to
be a lot of IPv4 in my network for years to come just because of product
lifecycles.

As far as "CG-NAT-like" technologies go (meaning NAT in a provider's
network), they're unfortunately going to be with us for a long time since
customers seem to want to be able to reach everything regardless of the
IPv4 or IPv6 status of the customer or endpoint.   I also expect that most
service providers with business customers are going to be carrying both
IPv4 and IPv6 for a long time, not to mention doing a fair bit of
translation in both directions.

I won't go deeply into the whole IPv4 vs IPv6 discussion for a business
customer's "public address" because the topic is far too nuanced for an
email to cover them accurately.   Suffice it to say that I don't disagree
that business today largely wants IPv4, but some seem to be becoming aware
of what IPv6 can do and are looking to have both options available to them,
at least outside the firewall.

On Sat, Jan 13, 2024, 2:04 AM Brett O'Hara <brett at fj.com.au> wrote:

> Ok you've triggered me on your point 2.  I'll address the elephant in the
> room.
>
> IPv4 is never ever going away.
>
> Right now consumer services are mostly (mobile, wireless, landline, wide
> generalization) are IPv6 capable.  Most consumer applications are ipv6
> capable, Google, Facebook, etc.There is light at the very end of the tunnel
> that suggests that one day we won't have to deploy CGNAT444 for our
> consumers to get to content, we may only have to do NAT64 for them to get
> to the remaining Ipv4 Internet.  We're still working hard on removing our
> reliance on genuine ipv4 ranges to satisfy our customer needs, It's still a
> long way off, but it's coming.
>
> Here's the current problem.  Enterprise doesn't need ipv6 or want ipv6.
> You might be able to get away with giving CGNAT to your consumers, but your
> enterprise customer will not accept this. How will they terminate their
> remote users?  How will they do B2B with out inbound NAT?  Yes, there are
> solutions, but if you don't need to, why?  They pay good money, why can't
> they have real ipv4?  All their internal networks are IPv4 rfc1918.  They
> are happy with NAT.  Their application service providers are ipv4
> only. Looking at the services I access for work things like SAP,
> SerivceNow, Office386, Sharepoint, Okta, Dayforce, Xero, and I'm sure many
> more, none can not be accessed on ipv6 alone..  Their internal network
> lifecycle is 10+ years.  They have no interest in trying new things or
> making new technology work without a solid financial reason and there is
> none for them implementing ipv6.   And guess where all the IP addresses
> we're getting back from our consumers are going?  Straight to our good
> margin enterprise customers and their application service providers.
> Consumer CGNAT isn't solving problems, it's creating more.
>
> The end of IPv4 isn't nigh, it's just privileged only.
>
> PS When you solve that problem in 50 years time, I'll be one of those old
> fogey's keeping an IPv4 service alive as an example of "the old Internet"
> for those young whippersnappers to be amazed by.
>
> Regards,
>    Brett
>
>
>
> On Sat, Jan 13, 2024 at 7:31 PM Forrest Christian (List Account) <
> lists at packetflux.com> wrote:
>
>> A couple of points:
>>
>> 1) There is less work needed to support IPv6 than your proposed
>> solution.  I'm not taking about 230/4.  I'm talking about your EzIP
>> overlay.
>>
>> 2) Assume that Google decided that they would no longer support IPv4 for
>> any of their services at a specific date a couple of years in the future.
>> That is,  you either needed an IPv6 address or you couldn't reach Google,
>> youtube, Gmail and the rest of the public services.  I bet that in this
>> scenario every eyeball provider in the country all of a sudden would be
>> extremely motivated to deploy IPv6, even if the IPv4 providers end up
>> natting their IPv4 customers to IPv6.  I really expect something like this
>> to be the next part of the end game for IPv4.
>>
>> Or stated differently: at some point someone with enough market power is
>> going to basically say "enough is enough" and make the decision for the
>> rest of us that IPv4 is effectively done on the public internet.   The
>> large tech companies all have a history of sunsetting things when it
>> becomes a bigger problem to support than it's worth.  Try getting a modern
>> browser that works on 32 bit windows.   Same with encryption protocols,
>> Java in the browser,  Shockwave and flash, and on and on.
>>
>> I see no reason why IPv4 should be any different.
>>
>> On Fri, Jan 12, 2024, 3:42 PM Abraham Y. Chen <aychen at avinta.com> wrote:
>>
>>> Hi, Forrest:
>>>
>>> 0)    You put out more than one topic, all at one time. Allow me to
>>> address each briefly.
>>>
>>> 1)   "  The existence of that CG-NAT box is a thorn in every provider's
>>> side and every provider that has one wants to make it go away as quickly as
>>> possible.   ":
>>>
>>>     The feeling and desire are undeniable facts. However, the existing
>>> configuration was evolved from various considerations through a long time.
>>> There is a tremendous inertia accumulated on it. There is no magic bullet
>>> to get rid of it quickly. We must study carefully to evolve it further
>>> incrementally. Otherwise, an even bigger headache or disaster will happen.
>>>
>>> 2)    "  The quickest and most straightforward way to eliminate the
>>> need for any CG-NAT is to move to a bigger address space.  ":
>>>
>>>     The obvious answer was IPv6. However, its performance after near two
>>> decades of deployment has not been convincing. EzIP is an alternative,
>>> requiring hardly any development, to address this need immediately.
>>>
>>> 3)   "  Until the cost (or pain) to stay on IPv4 is greater than the
>>> cost to move,  we're going to see continued resistance to doing so.   ":
>>>
>>>     This strategy is easily said than done. It reminds me of my system
>>> planning work for the old AT&T. At that time, Bell Operating Companies
>>> (BOCs) could be coerced to upgrade their facility by just gradually raising
>>> the cost of owning the old equipment by assuming fewer would be be used,
>>> while the newer version would cost less because growing number of
>>> deployments. Looking at resultant financial forecast, the BOC decisions
>>> were easy. Originally trained as a hardware radio engineer, I was totally
>>> stunned. But, it worked well under the regulated monopoly environment.
>>>
>>>     Fast forward by half a century, the Internet promotes distributed
>>> approaches. Few things can be controlled by limited couple parties. The
>>> decision of go or no-go is made by parties in the field who have their own
>>> respective considerations. Accumulated, they set the direction of the
>>> Internet. In this case, IPv6 has had the opportunity of over four decades
>>> of planning and nearly two decades of deployment. Its future growth rate is
>>> set by its own performance merits. No one can force its rate by persuasion
>>> tactic of any kind. Hoping so is wishful thinking which contributes to
>>> wasteful activities. So, we need realistic planning.
>>> Regards,
>>>
>>>
>>> Abe (2024-01-12 18:42)
>>>
>>>
>>>
>>> On 2024-01-12 01:34, Forrest Christian (List Account) wrote:
>>>
>>> The problem isn't the quantity of "inside" CG-NAT address space.  It's
>>> the existence of CG-NAT at all.
>>>
>>> It doesn't matter if the available space is a /12 or a /4, you still
>>> need something to translate it to the public internet.   The existence of
>>> that CG-NAT box is a thorn in every provider's side and every provider that
>>> has one wants to make it go away as quickly as possible.
>>>
>>> The quickest and most straightforward way to eliminate the need for any
>>> CG-NAT is to move to a bigger address space.  As I pointed out, IPv6 is
>>> already ready and proven to work so moving to IPv6 is a straightforward
>>> process technically.  What isn't straightforward is convincing IPv4 users
>>> to move.  Until the cost (or pain) to stay on IPv4 is greater than the cost
>>> to move,  we're going to see continued resistance to doing so.
>>>
>>>
>>> On Thu, Jan 11, 2024, 7:36 PM Abraham Y. Chen <aychen at avinta.com> wrote:
>>>
>>>> Hi, Forrest:
>>>>
>>>> 0)    Thanks for your in-depth analysis.
>>>>
>>>> 1)     However, my apologies for not presenting the EzIP concept
>>>> clearer. That is, one way to look at the EzIP scheme is to substitute the
>>>> current 100.64/10  netblock in the CG-NAT with 240/4. Everything else in
>>>> the current CG-NAT setup stays unchanged. This makes each CG-NAT cluster 64
>>>> fold bigger. And, various capabilities become available.
>>>>
>>>> Regards,
>>>>
>>>> Abe (2024-01-11 22:35)
>>>>
>>>>
>>>
>>>
>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>> Virus-free.www.avast.com
>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>> <#m_-2645487333541622617_m_814193715557979764_m_-2264817505018915121_m_-871507042037526857_m_-3709659627675338528_m_5461191486991014945_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20240113/5f5b40f7/attachment.html>