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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf