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