Noel Chiappa wrote:
> From: Keith Moore <moore(_at_)network-heretics(_dot_)com>
> But these limitations don't inherently apply to NAT between v4 and v6,
> particularly not when the v4 address is a public one.
I don't understand this; I thought the inherent problems you so ably and
clearly laid out in your other message (e.g. the inability to allow incoming
connections based on incoming application packets only; the inability to pass
an address to a third party; the increased fragility due to state in the
network) would apply to an IPv4-IPv6 NAT, when such a device is used to allow
a group of hosts with only IPv6 addresses to communicate with IPv4-only
machines. What am I missing?
First, with a v4/v6 NAT you don't have to have overlapping v6 address
realms behind the NAT. You can (certainly should) give each host
behind the NAT its own globally unique IPv6 address. That keeps
multiparty applications from having to create their own address spaces
for hosts, and minimizes the effort required to route between them. It
also makes referrals easier: they can pass a (public IPv4 address, port,
IPv6 address, port) tuple to a peer. If the IPv6 address isn't directly
reachable, the IPv4 address will suffice.
Second, one of the worst assumptions in v4 NAT design was the assumption
that the endpoints don't need to know about the NATs. By now it should
be obvious that for a great many reasons, they do. For example, they
clearly need to know about the address binding across the NAT, which is
why we have so many hacks to let apps and hosts find that out. A
standardized v4/v6 NAT can define a mandatory protocol to let "internal"
apps and hosts be able to find out their "external" endpoint addresses.
And this is a lot more useful in a world where you don't have
overlapping address realms.
For similar reasons you can make the management of the address:port
binding an explicit agreement between the host or app and the NAT.
Which means that a host or app on a v6 network can say to its v4/v6 NAT:
"Please accept incoming connections on this v4 host:port (where either
can be a wildcard) and forward them to me at this v6 host:port." (and
when I do get an incoming connection, let me know what it's external
source and destination addresses are BEFORE I have to accept the
incoming connection. maybe they can be piggybacked in an IP option).
Or "I want to open an outgoing connection to this address:port, please
set up this binding for me and let me know what NAT address:port to use
when talking to the NAT in order to do that." Explicit management of
address bindings goes a long way toward getting rid of the fragility due
to address bindings in the NAT. E.g. you can require hosts to
explicitly renew them (much like DHCP leases).
Making management of the address binding explicit also helps resolve a
tussle between the application/host and the network operator (or at
least the NAT operator), because it gives the application a way to know
whether a particular failure to connect with a peer is a matter of
policy (that should be respected, at least while talking to that NAT) or
just brain-damage (that should be routed around). And the application
can accurately report the nature of the problem to the user or operator,
reducing support costs.
And with the right kind of API support you can even allow
v4/v6NAT-unaware apps to still function (though with reduced
functionality) but apps that know how to talk to NATs can function more
effectively. if nothing else, they can log the correct external addresses.
The cost of this is that you need an established relationship between a
host and its v4/v6 NAT - in particular, with some way for a host inside
a NAT to know that it really is talking to its designated NAT and that
the NAT is trustworthy.
> there's a whole other discussion to be had about how the IPv6 feature
> set was chosen - e.g. why concerns like WAN routing scalability trumped
> other very valid concerns
Without scalable routing, you don't have a network anyway, right?
arguably we don't have scalable routing now, and yet we still seem to
have a network.
I think it's a matter of strategy, i.e. fighting the right battle at the
right time.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf