> 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