Greg,
On 2009-10-28 05:42, Greg Daley wrote:
> 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?
Well, the military interest in damage-proof tactical networks hasn't
been a secret over the last 5 years or more. However, "tactical networks"
only gets 90 hits on the IETF search button, which does seem
surprising. Similarly for "network centric operations", the other
euphemism for battlefield networks.
Perhaps if we did, we could have supplied
> a solution which doesn't suck as badly as NAT.
"The purpose of the MANET working group is to standardize IP routing
protocol functionality suitable for wireless routing application within
both static and dynamic topologies with increased dynamics due to node
motion or other factors."
"The main purpose of the AUTOCONF WG is to describe the addressing model
for ad hoc networks and how nodes in these networks configure their
addresses."
I think the IETF has taken the attitude that the only non-sucking approaches
involve dynamic addressing and routing. And it's quite hard, which is why
MANET and AUTOCONF aren't quite done yet...
Brian
>
> 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 mailing list
> Ietf@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf
>
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf