RIPE our of IPv4

Mailman List Mirror (Read Only)
1

Hello,

Date: Tue, 26 Nov 2019 00:13:48 -0800 (PST)
From: Sabri Berisha <sabri@cluecentral.net>
To: Doug Barton <dougb@dougbarton.us>
Cc: nanog <nanog@nanog.org>
Subject: Re: RIPE our of IPv4
Message-ID:
  <1383247942.183700.1574756028904.JavaMail.zimbra@cluecentral.net>
Content-Type: text/plain; charset=utf-8

I get that some people still don't like it, but the answer is IPv6. Or,
folks can keep playing NAT games, etc. But one wonders at what point
rolling out IPv6 costs less than all the fun you get with [CG]NAT.

When the MBAs start realizing the risk of not deploying it.

I have some inside knowledge about the IPv6 efforts of a large eyeball network. In that particular case, the cost of deploying IPv6 internally is not simply configuring it on the network gear; that has already been done. The cost of fully supporting IPv6 includes (but is probably not limited to):

- Support for deploying IPv6 across more than 20 different teams;
- Modifying old (ancient) internal code;
- Modifying old (ancient) database structures (think 16 character fields for IP addresses);
- Upgrading/replacing load balancers and other legacy crap that only support IPv4 (yeah, they still exist);
- Modifying the countless home-grown tools that automate firewalls etc;
- Auditing the PCI infrastructure to ensure it is still compliant after deploying IPv6;

If it was as simple as upgrading a few IP stacks here and there, it would be a non-issue.

No matter how complex is your network (and your teams), from my humble
point of view, there is always something you can do regarding IPv6. The
key is not to solve one million problems on one day. The key is to go
gradually, one small block after another one.
You can even keep all your internal network on v4 (forever if that is
your intent ) and use IPv6 on specific portions of your network.

Don't get me wrong, I'm not advocating against IPv6 deployment; on the contrary. But it is not that simple in the real corporate world. Execs have bonus targets. IPv6 is not yet important enough to become part of that bonus target: there is no ROI at this point. In this kind of environment there needs to be a strong case to invest the capex to support IPv6.

IPv6 must be supported on the CxO level in order to be deployed.

I would have said the very very minimum could be to invest in a
dual-stack 'proxy' for public-facing services; internal or external
solution, you have the choice.

And why even do that ? Because the other side is not only on IPv4.

2

Hi,

I would have said the very very minimum could be to invest in a
dual-stack 'proxy' for public-facing services; internal or external
solution, you have the choice.

And why even do that ? Because the other side is not only on IPv4.

Using a dual-stack proxy is not always an option. Source IP information may be needed on the app level for risk analysis, OFAC compliance, and copyright purposes. For example, Paypal will definitely use IP address information in its fraud risk analysis.

That said, there are of course ways to do that while using a proxy. However, that will now require some for of development. Dev time better used to properly implement v6.

Unfortunately, I've been part of way to many discussions where the only thing a beancounter wants to know is: what is the short term effect of not doing it?

Short term exec bonuses, short term decisions.

Thanks,

Sabri

3

Hi,

I would have said the very very minimum could be to invest in a
dual-stack 'proxy' for public-facing services; internal or external
solution, you have the choice.

And why even do that ? Because the other side is not only on IPv4.

Using a dual-stack proxy is not always an option. Source IP information may be needed on the app level for risk analysis, OFAC compliance, and copyright purposes. For example, Paypal will definitely use IP address information in its fraud risk analysis.

And existing proxies don’t already pass through the connecting IP address? There are even header fields that are dedicated for this purpose [1].

Most web sites could be dual stacked today with zero issues. Web site analytic tools already deal with IPv6 and have for years.

That said, there are of course ways to do that while using a proxy. However, that will now require some for of development. Dev time better used to properly implement v6.

And the difference in time between reading the address from X-Forwarded-For: vs directly is negligible.

Unfortunately, I've been part of way to many discussions where the only thing a beancounter wants to know is: what is the short term effect of not doing it?

Short term exec bonuses, short term decisions.

Thanks,

Sabri

[1] X-Forwarded-For - Wikipedia