Re: IPv6 NAT?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 > So, I think it would be good to define IPv6 NAT behavior, and do so
 > NOW before its too late, and define it in a way that it would appeal
 > to the admins that have deployed IPv4 NAT today.


There are at least five things about IPv4 NAT that are not now and never 
were workable:

(1) Changing addresses midstream without the endpoints being aware of 
the change.

(especially in the absence of any other reliable host identifier in the 
IPv4 architecture and a fast, scalable, and reliable id<->address 
mapping facility...an existence proof for which does not yet exist)

(2) The existence of multiple address realms, with some applications 
that communicate across realm boundaries potentially needing to know 
which hosts were in which realms, and which of a host's addresses to use 
from any particular location, and with no way for an application to 
distinguish one realm from another.

(multifaced DNS and its associated problems are ripple effects of this 
general problem, but there are many others)

(3) Overlapping address spaces, with all that this implies, including 
its effects on traceability, increased difficulty in merging networks, 
and difficulty in communicating between networks using the same address 
space.

(4) Address bindings subject to being removed or changed with no notice 
to the endpoints, and no handover.

(5) Arbitrary (from an application's view) blocking of traffic through a 
NAPT for any network sufficiently large or diverse to require different 
policies for different hosts or apps, coupled with the expectation that 
apps operate across those boundaries.

Even assuming some utility for NATs in IPv6 (as a v4-v6 transition tool, 
or for topology hiding) all five of these problems need to be fixed.

--

Offhand, it appears that it might be possible to solve problems 1-5 
above in a NATted IPv6 world.  What would this look like?

- All networks, even those behind NATs, would have globally-unique 
address blocks.

- Every IPv6 host that were permitted to accept traffic from any host 
outside of its enterprise network would have one or more public IPv6 
addresses.

Its ability to use those addresses might be limited by policy, but it 
would still have them, and it would be aware of them.  Such addresses 
could be publicly advertised in DNS, and the public addresses would also 
be usable (whether by hairpin routing or an extension to ND that 
facilitated direct routing) from within the enterprise network. 
Essentially the NAT and the local host would be using NAT as a 
low-overhead tunneling mechanism.

What this would mean (among other things) is that when opening a 
connection to any host that had a public address, it would be reasonable 
to use that address in preference to all other addresses associated with 
that host.

- Address bindings would be able to be explicitly managed by host stacks 
via a standard, authenticated protocol.  Applications would be able to 
access this protocol through a standard API.  "Binding leases" would be 
maintained by the stacks without applications having to be aware of 
them, and applications would be able to request (subject to policy) that 
incoming traffic matching certain criteria (source address, dest 
address, source port, dest port, etc) be permitted to transit the 
nat/firewall.

What would this buy us?

a) A common application framework for communicating between IPv4 and 
IPv6 hosts, and IPv6 and IPv6 hosts, whether or not in the presence of 
NATs...and with it, a way to transition apps from IPv4 to mixed IPv4/v6 
to pure IPv6 with less disruption.

b) Topology hiding for IPv6 networks, and address hiding for client 
hosts on IPv6 networks.  (perhaps better than privacy addresses)

c) The potential for insulation of IPv6 networks from disruption to 
purely-local apps due to renumbering or other changes.  (This would 
require that such apps be configurable to use local addresses in 
preference to global ones, as the default should be the other way around)

d) Something to satisfy people who think they need NAT in IPv6, even if 
they don't understand why they need it and aren't able to evaluate.

Keith
_______________________________________________

Ietf@xxxxxxxx
http://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]