Subject: avoiding pitfalls in v4/v6 NAT (was Re: About IETF communication skills)

From: Keith Moore <[email-masked]>
Date: Sat, 02 Aug 2008 13:32:41 -0400

Noel Chiappa wrote:
>     > From: Keith Moore <[email-masked]>
> 
>     > 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
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: [email-masked] (Noel Chiappa)
Date: Sat, 2 Aug 2008 12:15:18 -0400 (EDT)

> other very valid concerns 

Without scalable routing, you don't have a network anyway, right? So if other
_additional_ properties were 'required', the architecture needed to be
extended to support them (bearing in mind the old TANSTAAFL principle).
Ironically, by reusing the single-namespace IPv4 architecture without
modification (touted at the time as a 'feature' of IPv6), it made it
impossible to have a network which was both practicable (i.e. scalable
routing) and met user desires, e.g. for provider independence - which is,
in a further irony, one of the rhings driving the NATs you so dislike.

	Noel