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 mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf