[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]

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

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.