ietf
[Top] [All Lists]

Re: NAT Not Needed To Make Renumbering Easy

2009-10-27 12:02:29

On Oct 25, 2009, at 10:49 AM, Sabahattin Gucukoglu wrote:

Not in the IPv6 address space, anyway. And if it is, there's something wrong and we should put it right.

Just been reading IAB's commentary on IPv6 NAT. It seems to me that we are perpetuating the worst technology in existence *simply* for one feature, network mobility, that is better served by proposing new techniques and technologies and, in particular: we need a simple way to express host relationships inside an organisation that is independent of external homing. I refuse to suffer because of NAT any longer and don't want to accommodate those that prefer it. If IPv6 does ever get wide enough deployment, and I truly hope it does, I might just *give up* things to accommodate the trouble-free life that is no NAT.

What do we have right now, first?


As I understand it, the folks really pushing for IPv6 NAT are from the US department of defense.

Let's consider a battlefield operation.


We have a hierarchical organizational structure. At any given level, there are a collection of numbered boxes. For example, consider infantry companies, of which there might be 8 or so in an infantry battalion.

Company A has a bunch of networked boxes, A1, A2, A3, and so on. Companies B, C, D, and so on have the like.

A1 is configured exactly like B1, C1, D1, and so on, with the same IP addresses, passwords, default routes, everything. The inter-layer boxes use NAT to make everything work, even that we have re-used local addresses at every level of the hierarchy.

The battalion command post may also have some spare #1 boxes, #2 boxes, etc.

Assume artillery falls on the command posts for Company A and Company B and blows up some of their boxes. Recovery may necessitate combining the networked boxes and command structures of both companies.

So, while getting shot at, the network techs are busy running boxes back and forth. Let's make a simple case: Boxes A2, A5, and A7 got hit, so they're replaced by B2, B5, and B7. B3 and B4 are also hit, bringing the B network down completely Meanwhile, the battalion guys are shipping out spare #2, #3, #4, #5, and #7 boxes to company B.

The B-boxes need to work instantly when plugged-in as replacements for A boxes. There's no time for manual reconfiguration, probably no time for dynamic topology discovery, or anything else. The techs on the ground don't have the passwords, equipment, or know-how to reconfigure the boxes anyhow -- mostly, they just know to plug wire 1-4 into box 1 port 5. And the same goes when the spare boxes from the battalion level arrive at company B -- they have to plug in and work instantly without renumbering anything.

NAT is the glue that makes all this work with minimal reconfiguration, and isolates what manual reconfiguration is needed to a specific set of boxes at interconnect points, for which standardized procedures can be developed that allow topology to be reconfigured on demand under very difficult circumstances.

Keep in mind that all this stuff also has to be wrapped in military- grade crypto, resist Tempest-style interception, remote radio data insertion attacks, jamming, and sorts of protocol attacks, so "brutal simplicity" is the by-word of the day. We can't have a network fall apart just because some enemy sapper managed to clamp a rogue Linksys access point with a DHCP server onto a wire somewhere ...

So, if IP applications and protocols worked entirely differently, we could get away without NAT in IPv6. We'd kind of hoped that things like Bonjour and multicast service discovery and P2P would have matured fast enough to plug the gap, but so far they haven't been seen as adequate (and I'm not an expert on "why not"). Plus, the military mindset is understandably reluctant to change things that work. And since NAT made all this stuff work for IPv4, they're planning to use it for IPv6 too.

--
Dean

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf