[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. "

[Mark ZZZ Smith]

----- Original Message -----
> From: Nathanael Bettridge <nathanael at prodigy.com.au>
> To: Mark ZZZ Smith <markzzzsmith at yahoo.com.au>; 'Mark Newton' <newton at atdot.dotat.org>
> Cc: "'ausnog at lists.ausnog.net'" <ausnog at lists.ausnog.net>
> Sent: Friday, 7 November 2014, 20:41
> 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. "
> 
> 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.

I don't think people shouldn't be using 'feelings' to make technology decisions, I think they should be using 'thinkings', and thinking involves finding out the trade-offs and costs vs benefits of the different options available.

> And I feel that arguing it has insufficient 
> merit to *ever* be appropriate is oversimplification.

My experience since first attempting to enable it in 1995 when NAT was a brand new thing tells me otherwise, and for a short period I even thought it was a good idea because it decoupled internal network addressing from Internet addressing. I however now don't think that benefit is worth the many other costs I've since seen and experienced. I will and have used 'public' IPv4 addressing by default just for the value global uniqueness provides, because that has been a very useful property during troubleshooting and I think one that is undervalued.

Networks should be transparent to applications so any application just works without any changes being needed to the Network. All that should be required to run a new application over a network is to load it up on the involved end-hosts. The day I first loaded up a web browser in 1991 was the day I was able to access the world wide web - no network changes required. The day I first tried to enable NAT was the day it broke or rather never could work, because the NAT box couldn't translate IPv4 addresses inside NetBIOS packets (because NATs have to dig around inside application payloads, and that means understanding the application protocols).


An application transparent network causes the least problems and is cheapest to run, because the network doesn't care what the applications are and therefore doesn't try to get involved in how the applications operate. NAT violates that transparency, and the costs of trying to again make it transparent to the application (e.g., NAT traversal, tunneling over UDP etc., less resilient and less scalable hub-and-spoke traffic topologies, trusted or perhaps not-to-be-trusted intermediaries between the communicating nodes etc.,), just so the application can work, have to be paid by somebody, even if it isn't you.




> 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.
>