[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, 17:03
> 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. "
> 
> 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.

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?

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.



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

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.




> For the record, I do use IPv6, and I don’t boycott the protocol due to lack of 

> widespread support of one or two features in the wild :)
> 
> Nathanael Bettridge
> Prodigy Communications Pty Ltd
> Mobile: +61 (0)4 1048 0170
> Office: +61 (0)2 8214 8920
> Fax:    +61 (0)2 9427 4203
> Email:  nathanael at prodigy.com.au
> Web:    www.prodigy.com.au 
> 
> 
> 
>>  -----Original Message-----
>>  From: Mark ZZZ Smith [mailto:markzzzsmith at yahoo.com.au]
>>  Sent: Friday, 7 November 2014 2:17 PM
>>  To: Mark Newton; Nathanael Bettridge
>>  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: Mark Newton <newton at atdot.dotat.org>
>>  > To: Nathanael Bettridge <nathanael at prodigy.com.au>
>>  > Cc: "ausnog at lists.ausnog.net" 
> <ausnog at lists.ausnog.net>
>>  > Sent: Thursday, 6 November 2014, 11:05
>>  > 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. "
>>  >
>>  >
>>  > On Nov 6, 2014, at 9:12 AM, Nathanael Bettridge
>>  <nathanael at prodigy.com.au>
>>  > wrote:
>>  >
>>  >>  I like and regularly use the ability to remap ports between 
> disparate
>>  > machines or to different ports transparently, without having to use a 
> port
>>  > proxy.
>>  >>  I like and regularly use the ability to present an arbitrary 
> number of
>>  > addresses as one to another network, or map between different address
>>  > structures.
>>  >
>>  > I like and regularly use networks which keep concentrations of state 
> on the
>>  > edge.
>>  >
>>  > (why do you even care about ports? Oh, substandard application
>>  architecture
>>  > which forces you to micromanage 16 bit numbers. Never mind, carry on…)
>>  >
>>  >>  These are really handy tools to have to solve problems.
>>  >
>>  > They’re also really handy tools to turn yourself into a DoS-magnet.
>>  >
>>  > An important plank of security is “availability.”  You’re reducing 
> that every
>>  > time you put another bit of state in your core. These people who claim 
> that
>>  NAT
>>  > is helping their security seem to have a somewhat more limited view of
>>  > “security” than the commonly accepted one that network professionals
>>  strive to
>>  > attain.
>>  >
>> 
>>  Yep. Have been tempted to do an Ausnog presentation on "The Trouble 
> With
>>  NAT", but didn't think it was necessary.
>> 
>> 
>>  NAT forces a hub-and-spoke forwarding topology between the hosts at the
>>  spokes. The trouble with hub-and-spoke topologies, both generally, and
>>  specific to NAT, are:
>> 
>> 
>>  - the hub is a single point of failure
>> 
>>  - the hub is hard to scale because the only way to scale it is vertically 
> ("scale
>>  up") (i.e., buy bigger and more expensive hardware to replace the 
> existing
>>  one) rather than scale horizontally ("scale out") (i.e., buy more 
> the same box
>>  and add them beside the existing ones)
>> 
>>  - the hub is a great point to conduct pervasive monitoring (consider public
>>  jabber servers for example (as jabber follows a hub-and-spoke or
>>  client/server application architecture/topology) - who runs those? Are you
>>  sure the one you're using *isn't* being run by the NSA/GCHQ/et. 
> al.)
>> 
>>  - security between a spoke and hub doesn't ensure security exists 
> between
>>  the communicating spokes, and security is an end-to-end problem. If you
>>  can't be sure of end-to-end security, then you can't be anywhere 
> near as
>>  sure of your security (jabber again used to be or still is an example)
>> 
>>  - specific to NAT, clients don't know their own actual identity (e.g., 
> their NAT
>>  "public side" address, assuming they have a unique one, which 
> commonly
>>  they won't), and therefore even if the opportunity exists to support 
> direct or
>>  peer-to-peer communication, they have to trust an intermediary to tell them
>>  what their identity is and possibly to facilitate setting up that direct
>>  communications (e.g., a STUN server). That intermediary may be prepared to
>>  lie about what the client's identity is (because e.g., it's run by 
> NSA/GCHQ/et.
>>  al.)
>> 
>>  - specific to NAT, periodic 'bubble' traffic usually has to be sent 
> and received
>>  to keep NAT state sessions open. This is additional traffic on the network
>>  which carries no user payload (the fundamental goal of the network), so it 
> is
>>  just overhead, and in particular reduces the time a battery powered device
>>  an operate
>> 
>>  "peer-to-peer" or "full-mesh" communications
>>  protocols/topologies/forwarding paths/application architectures have none
>>  of these limitations. IPv4 before NAT, and IPv6 are peer-to-peer protocols
>>  (as were DECNET, XNS, IPX, Appletalk, CLNS and I'm pretty sure other 
> old
>>  ones). Each device is supposed to have its own unique identity, so all 
> other
>>  devices can directly send to it or directly receive from it. In other 
> words, at
>>  the network layer, all devices are able to equally send or receive to all 
> other
>>  devices - the true definition of a 'peer'. The "device" 
> classification of
>>  client/server or peer is an architecture attribute of the application 
> running on
>>  the device, not a network layer attribute.
>> 
>>  Using a hub-and-spoke topology can be useful to introduce a
>>  concentration/inspection point between the spokes if you need one. The
>>  problem comes when there is no choice - when a peer-to-peer/full mesh
>>  topology or application architecture would be better, because it 
> doesn't have
>>  any of the above limitations, yet because of e.g., NAT, you are forced to 
> use
>>  a hub-and-spoke or client/server topology or application architecture just 
> to
>>  make the application work.
>> 
>>  There is a specification for "NAT" for IPv6, RFC6296, 
> "IPv6-to-IPv6 Network
>>  Prefix Translation", which does stateless 1-to-1 NAT for IPv6 
> addresses.
>>  However, it is *not* a standard both because not all RFCs are, and has
>>  EXPERIMENTAL status. That is because it still doesn't get rid of all of 
> the
>>  limitations that NAT creates - it still prevents hosts from knowing their 
> own
>>  identities. The Internet protocols are peer-to-peer protocols, and NAT in 
> any
>>  form prevents hosts being able to act as full network layer peers.
>> 
>>  RFC1958, "Architectural Principles of the Internet", and RFC2993,
>>  "Architectural Implications of NAT", are well worth a read.
>> 
>> 
>>  Regards,
>>  Mark.
>