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

From: [email-masked] (Noel Chiappa)
Date: Sun, 3 Aug 2008 10:09:46 -0400 (EDT)

> From: Keith Moore <[email-masked]>

    >>> these limitations don't inherently apply to NAT between v4 and v6,

    >> I thought the inherent problems ... 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?

    > 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
    > ...
    > For similar reasons you can make the management of the address:port
    > binding an explicit agreement between the host or app and the NAT.
    > ...
    > Explicit management of address bindings goes a long way toward getting
    > rid of the fragility due to address bindings in the NAT.

Ah, got it. I hadn't realized this was what you meant by "NAT between v4 and
v6", because to me these are the kind of things that (in IPv4) were being
explored by the middle-box (MidCom) WG, so I think of them as 'middle box
functionality', not 'NAT' (since to me, part of what NAT means is that 'you
don't have to modify the hosts').

    > The cost of this is that you need an established relationship between a
    > host and its v4/v6 NAT

Not just that, but to make this really useful, you'd have to add this 'NAT
interaction' stuff to the core IPv6 spec, get it added to all IPv6
implementations, and then get it deployed to all existing IPv6-capable boxes.

Leaving aside the engineering/logistical difficulties involved in doing all
that, it seems to me that this would basically amount to formally 'adding NAT
to IPv6', which is a claim made in the story which some people were saying
was inaccurate. The fact that it's not necesarily used in v6/v6 interactions
is an awfully fine hair to split, to claim that 'well, we're not actually
adding NAT to IPv6'. If it's in the core spec, it's in IPv6.

(And that v6/v6 exemption might not stand, if people deal with v6's inability
to give them provider independence, due to its retention of the obsoleteq
IPv4 single-namespace architecture, by using v6-v6 NATs to give them provider
independece - which is a big driver for v4-v4 NATs, I gather.)

Anyway, it seems like the story is more accurate than many people realized...
Either this functionality is added to the IPv6 core spec, or the IPv6/v4 NAT
boxes (which many people now seem to feel are required for a viable
deployment plan) will display the same crippling problems as v4/v4 NAT...

	Noel
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Sun, 03 Aug 2008 13:49:23 -0400

> don't have to modify the hosts').

But clearly, this assumption wasn't true even for v4 NAT, because hosts 
are shipping with support for UPnP and similar hacks to (minimally) deal 
with it, and apps are using significant amounts of code and 
infrastructure to deal with it.

> implementations, and then get it deployed to all existing IPv6-capable boxes.

Actually, no.

You do have to have a spec for it, of course, but there is no reason to 
add it to the core IP spec.  And IMHO it would be a bad idea for reasons 
unrelated to the overhead of doing so.  The NATs and their support 
should still be thought of as a stopgap measure.

You don't need to add it to all (or most) IPv6 implementations.  (Not 
that this is terribly difficult in these days where updates regularly 
get downloaded over the net.)  If the hacks needed to allow apps to deal 
with NATs are designed with this in mind, they can be implemented in 
separate libraries - even in shared libraries/DLLs that get associated 
with applications as needed.

The goal (in my mind) is not to magically make all boxes and apps 
suddenly be able to communicate with both IPv4-only and IPv6-only hosts 
as if there were no difference between the two.  It is merely to provide 
a standard way to allow a network operator OR an application vendor, by 
providing such a NAT, to allow v4/v6-NAT aware apps on that network to 
bridge the gap.

(note that - because it has an explicit relationship with the apps and 
hosts that use it - such a v4/v6 NAT can live anywhere on the network 
where it has access to both public v4 and v6 networks.  so an enterprise 
network operator could provide it for use on that enterprise network, or 
an application vendor could provide it for use by its products, or a 
third-party could sell the service to anyone who needed to give a 
v4-only app presence on the public v6 network or similarly for v6-only 
apps and v4.)

And it doesn't have to be applied to every app on every host.  For many 
apps, only one end of the app (say the server of a client-server pair) 
has to be aware of the hack.  The other end can just use whatever native 
IP access is available to it.

And the apps don't always have to be directly aware of the hack.  For 
some apps you can arrange them to be associated with a shared 
library/DLL that is aware of the hack.  They won't see the correct IP 
addresses but for some apps you can live with this.  (But it's important 
to not universally impose the hack on all hosts or apps.)

> adding NAT to IPv6'. If it's in the core spec, it's in IPv6.

But there's no need for it to be part of the core spec.

> independece - which is a big driver for v4-v4 NATs, I gather.)

That's a huge topic, way too big for a reply to an email message on the 
IETF list.  But even though that is one of the drivers for v4 NATs, I 
don't think v6 will end up the same way.   Enterprise network management 
will continue to evolve and they'll see the benefits of using v6.  And 
while I admit that some kind of network address translation combined 
with ULIAs might end up playing a role here, I don't think it will look 
like the role played by IPv4 NAT today.  (actually I think that if you 
do NAT properly, it starts to look more and more like tunneling, because 
one of the things the NAT really needs to do is communicate the "real" 
remote endpoint address of the peer to the host behind the NAT)

> deployment plan) will display the same crippling problems as v4/v4 NAT...

No, because (a) you're not trying to impose this on all hosts or apps, 
but rather use them in specific apps on a case-by-case basis, (b) you 
provide from the start a way for apps to be aware of these hacks, and 
(c) you engineer these boxes from day one in such a way as to avoid the 
crippling problems we've experience in v4 NAT.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Aug 2008 11:34:54 +1200

> deployment plan) will display the same crippling problems as v4/v4 NAT...

Certainly, my conclusion while working on
http://tools.ietf.org/id/draft-carpenter-shanti
(which is not an active proposal, so no need for a critique ;-)
and I suspect Remi's conclusion while working on
http://tools.ietf.org/id/draft-despres-v6ops-apbp
was very similar - the architectural holes can best be plugged
if the v6 host knows the translation that is in effect. But there's
a strong school of thought that we need to be able to deal
with RFC2460 hosts, i.e v6 hosts that have no such knowledge.

   Brian