[AusNOG] FW: [Ap-ipv6tf] official shutdown date for IPv4. The date he is pushing for is April 4, 2024. "IPv4 can't go on forever, " Latour said. "

[Nathanael Bettridge]

Some direct responses below but I want to be clear - I'm not supporting IPv6 NAT as a universal solution. It is not. I'm merely saying it should continue to be an option for those who, on balance, feel it would be more useful for a given solution than other options. And I feel that arguing it has insufficient merit to *ever* be appropriate is oversimplification. Anyway, I think this thread is somewhat reaching the end of its tether anyway :)


> -----Original Message-----
> From: Mark ZZZ Smith [mailto:markzzzsmith at yahoo.com.au]
> Sent: Friday, 07 November 2014 18:03
> To: Nathanael Bettridge; 'Mark Newton'
> Cc: 'ausnog at lists.ausnog.net'
> Subject: Re: [AusNOG] FW: [Ap-ipv6tf] official shutdown date for IPv4. The
> date he is pushing for is April 4, 2024. "IPv4 can't go on forever, " Latour said.
> ----- Original Message -----
> > From: Nathanael Bettridge <nathanael at prodigy.com.au>
> >
> > I understand and somewhat agree with all the below, and with the
> > exception of the "Client doesn't know its own identity issue" (which
> > is more a software/protocol issue and can be solved at that level),
> 
> Saying it can be solved is different to knowing how it can be solved or how it
> can be solved easily, securely and scalably. So how are you going to solve it?
> Solving it is of course going to mean more time, more code and therefore
> more bugs. Instead of time spent on enhancements to applications adding
> features or reducing application bugs, instead time has to be spent to just
> make them work at all in the presence of NAT. NAT has had a huge cost,
> however it has mostly been hidden from the networking people who've put
> it in place, because it has been the application developers and the application
> end-users who've paid most of the price.

For most applications, it's already been solved, or there are alternatives that have solved it. This is no different than any other feature-checklist when selecting a tool for the job.
Any solution will have costs here and there. It's always a balancing act between who has to foot the bill and how much you need to sacrifice to achieve your goals.

> To put it into another context, to hopefully demonstrate and cause people to
> consider the trouble with not knowing your own identity and the value of
> global uniqueness, would people really be happy if each of our mobile
> network providers NAT'd the phone/mobile numbers at the network
> boundaries, such that you didn't know what your contact number was in
> other networks?
> 
> Would you want to have to know that if you use Telstra, your internal Telstra
> network phone number is 041 1234 5678, but it is 041 9876 5432 for customers
> of the other carriers? What about if multiple NATs were implemented such
> that Optus's customers needed to use a different number to reach you than
> Vodaphone  customers? How are you going to discover what your foreign
> network specific phone number is, and how are you going to be sure it is
> always the same so that you can reliably tell people what it is - once you find
> out what their mobile network number is so you can give them the right
> one?

We already do that. Phone extensions in PABX systems (and low-end voip providers) are directly analogous to NATing public numbers to private addressing. 
Also - most applications don't directly rely on specifying IP addresses - we have things like DNS and other referral mechanisms that abstract this problem somewhat away.

> A single, globally unique identifier is far simpler and less error prone across all
> networks, which is why the IPv4 Internet was originally designed that way
> and why IPv6 places such value on restoring that addressing property. Global
> uniqueness has huge value because there can (or should) only ever be one
> instance of it, so no other extra context information is needed to distinguish
> which instance is being referenced at any particular time.

For most situations a globally unique identifier is useful. There are situations when that causes more grief than it fixes.

> 
> > all the below are
> > considerations to be weighed when making the decision to NAT or not to
> NAT.
> >
> > However, I still say it's the network owner's call as to whether NAT
> > is
> 
> > appropriate, and shouldn't be prescribed as a matter of
> orthodoxy/ideology.
> >
> 
> If you don't know the drawbacks of something, or just do what everybody
> else does, then you're not making an informed decision.

Why would you assume I, or anyone else who makes such a decision, is not making an informed decision?

> People like me have been burned by NAT (literally the first day I tried to use
> it in 1995 on a brand new and very expensive Checkpoint Firewall) and have
> seen the costs of it over the years. Those costs are unavoidable in IPv4, even
> if you choose to dismiss our advice as "orthodoxy/ideology", so you or your
> end-users are paying them one way or another.
> 

I too have been burned by new technologies on new equipment the first time I tried to use them. That's usually my fault or software bugs, not inherent to the technology.