Subject: NAT Not Needed To Make Renumbering Easy

From: Sabahattin Gucukoglu <[email-masked]>
Date: Sun, 25 Oct 2009 15:49:47 +0000

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?

Cheers,
Sabahattin

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 26 Oct 2009 05:41:31 +0900

Sabahattin Gucukoglu wrote:

> in particular: we need a simple way  to 
> express host relationships inside an organisation that is  independent 
> of external homing.

If renumbering is not a problem, it is simple and easy to do so
with IPv4.

You can assign both private and public addresseses to hosts, where
the private addresses express host relationships inside an organization
and are independent of external homing though the public addresses may
need renumbering.

A host may have a private address only, if the host does not need
end-to-end-transparent external communication and the host does
not need renumbering, extreme case of which is legacy NAT.

To make intra-organizational communication with private addresses,
a host (host with public addresses, only) software should be modified
so that, if the destination address is private/public, private/public
source address is used.

> What do we have right now, first?

End to end NAT (draft-ohta-e2e-nat-00.txt) is a way to let
hosts optionally have public addresses for end-to-end-transparent
global communication, where intra-organizational routing is
performed only with private addresses that intra-organizational
routers are not affected by external homing.

End to end NAT is already implemented with source address
selection.

In addition, end to end NAT enables port-wise routing for global
addresses, which reduces IPv4 address consumption *SIGNIFICANTLY*
that we don't need IPv6.

						Masataka Ohta

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sun, 25 Oct 2009 17:41:17 -0400

Sabahattin,

Note that IPv6 NAT makes multihoming to different ISPs much easier as well.

One thing that IPv6 NAT has in advantage to IPv4 NAT is that it can be
stateless, isomorphic, and port transparent by just translating the
upper part of the address, such as in the case where an enterprise is
internally using a PI /48, just translating the upper 48 bits of the
address.  This allows easy multihoming without needing to punch holes
in ISP address blocks. Especially with IPv6's huge address space, it's
extremely important for routing scalability to keep the number of
globally announced exceptions to aggregatable address blocks to a bare
minimum.

If you don't need to multihome, renumber, or use PI addresses, then I
agree that there's little utility to IPv6 NAT.

Cheers,
Andy

On Sun, Oct 25, 2009 at 11:49 AM, Sabahattin Gucukoglu
<[email-masked]> 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.
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 26 Oct 2009 08:32:06 +0900

Andrew G. Malis wrote:

> upper part of the address,

Not at all. Unless the NAT have end to end transparency,
statefull trasnration of raw IP addresses in payload is
still necessary.

Worse, port transparency is not very useful for IPv6, because,
transport check sum to be modified may be located in the second
or latter fragment, which means stateful reassembly is necessary
for IPv6 NAT.

And, remember to say IPSEC, which is *REQUIRED* by IPv6.

> This allows easy multihoming without needing to punch holes
> in ISP address blocks.

Wrong. It has nothing to do with NAT nor IPv6.

Punch holes are not necessary, if hosts have multiple addresses
assigned from ISPs *AND* transport and/or application layer of
their peers try all the IP addresses of the hosts, which is the
case with DNS/SMTP but not UDP/TCP and almost all the applications.

If we can fix transport/application over IP, IPv4 does not need
punch holes.

Of course, multiple addresses may be held not by individual end
hosts but by a middlebox (either IPv4 or Ipv6) and only UDP/TCP
of the middlebox may be modified, *IF* you sacrifice end to end
transparency.

						Masataka Ohta

---

From: AJ Jaghori <[email-masked]>
Date: Mon, 26 Oct 2009 00:39:20 -0400

Unless you have stringent NAT policies (e.g. multi Firewalls that require it
outside your Enterprise), then there is no shortage of IP space in v6.

What is your primary concern?

AJ Jaghori

---

From: Dean Willis <[email-masked]>
Date: Tue, 27 Oct 2009 11:01:57 -0500

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

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

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

---

From: "Greg Daley" <[email-masked]>
Date: Wed, 28 Oct 2009 03:42:59 +1100

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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dean Willis
> Sent: Wednesday, 28 October 2009 3:02 AM
> To: Sabahattin Gucukoglu
> Cc: [email-masked]
> Subject: Re: NAT Not Needed To Make Renumbering Easy
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Oct 2009 09:50:02 +1300

Greg,

On 2009-10-28 05:42, Greg Daley wrote:
> 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