Hi Dean, I appreciate that this is a realistic challenge for one of the key users of the technology. As a key user of the technology. Why didn't we learn about this earlier in the process? Perhaps if we did, we could have supplied a solution which doesn't suck as badly as NAT. I am quite interested to know your opinion. Was it because we weren't looking to meet the customer's need, a breakdown in requirements specification, or something else? Sincerely, Greg > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On > Behalf Of Dean Willis > Sent: Wednesday, 28 October 2009 3:02 AM > To: Sabahattin Gucukoglu > Cc: ietf@xxxxxxxx > Subject: Re: NAT Not Needed To Make Renumbering Easy > > > 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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf