Subject: [BEHAVE] NAT66: my conclusions

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 30 Nov 2008 18:38:06 +0100

After having debated the virtues of having NAT66 in the first place  
and its features if we were to have it, my conclusion is that we're  
not going to be able to create a NAT66 specification that makes all  
parties happy enough to reach rough consensus.

Having NAT66 at all is hard to swallow for a good number of people.  
The best description of my feelings about the subject are "the only  
good NAT is a dead NAT". But even in IPv4, there's a huge difference  
between different NAT implementations, causing various levels of harm.  
In IPv6, additiotional variations are possible, some causing  
significantly less harm than even the best IPv4 NATs.

For a while I thought it would be a good compromise to standardize one  
of these less nefarious NAT66s in order to avoid ending up with the  
really bad ones. But after the discussion the past few weeks my  
conclusion is that this isn't going to work.

Even within this subset of IETF members who have a decent  
understanding of IPv6 and the internet architecture, there have been  
people arguing for NATs that are more harmful than the minimum  
necessary to implement NAT66. For instance, some people have been  
speaking out for using global unicast or (none-unique) site local  
address space on the inside of a NAT66.

And in practice, people who don't know any better, or don't care, will  
implement even more harmful NAT66s regardless of any IETF consensus.  
For instance, the PF firewall already included a port overloading NAT  
for IPv6 years ago.

So the way I see it, the IETF publishing a NAT66 specification won't  
do much to discourage more harmful NATs, while it will encourage the  
use of the less harmful variant that is specified, but which still  
breaks referrals and end-to-end transparency. As such, doing this work  
will cause more harm than good.

However, I believe there is something useful that the IETF can do, and  
that is mostly what the BEHAVE wg has already been doing: document NAT  
behavior, and create specifications for applications that want to work  
through those NATs.  But with IPv6 we have the opportunity to be  
proactive: rather than describe the harm that existing NATs do, BEHAVE  
could publish a document that describes the various ways IPv6 NATs  
could be implemented, and then order these in order of increasing  
harm, outlining the harmful effects each type of NAT66s would have.  
Along with some easy to understand terminology or numeric ranking,  
this would allow application vendors to communicate what types of NAT  
their products will work with and which they won't, and allow end- 
users to specify to their middlebox vendors what kind of NAT they want  
to buy.

So I suggest that when the moment comes that BEHAVE is in the position  
to take on new work, a new charter include this as an item.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Eric Klein" <[email-masked]>
Date: Sun, 30 Nov 2008 20:48:53 +0200

On Sun, Nov 30, 2008 at 19:38, Iljitsch van Beijnum <[email-masked]>wrote:

> After having debated the virtues of having NAT66 in the first place and its
> features if we were to have it, my conclusion is that we're not going to be
> able to create a NAT66 specification that makes all parties happy enough to
> reach rough consensus.
>
> <snip>
> implement even more harmful NAT66s regardless of any IETF consensus. For
> instance, the PF firewall already included a port overloading NAT for IPv6
> years ago.
>
> So the way I see it, the IETF publishing a NAT66 specification won't do
> much to discourage more harmful NATs, while it will encourage the use of the
> less harmful variant that is specified, but which still breaks referrals and
> end-to-end transparency. As such, doing this work will cause more harm than
> good.
>
> However, I believe there is something useful that the IETF can do, and that
> is mostly what the BEHAVE wg has already been doing: document NAT behavior,
> and create specifications for applications that want to work through those
> NATs.  But with IPv6 we have the opportunity to be proactive: rather than
> describe the harm that existing NATs do, BEHAVE could publish a document
> that describes the various ways IPv6 NATs could be implemented, and then
> order these in order of increasing harm, outlining the harmful effects each
> type of NAT66s would have. Along with some easy to understand terminology or
> numeric ranking, this would allow application vendors to communicate what
> types of NAT their products will work with and which they won't, and allow
> end-users to specify to their middlebox vendors what kind of NAT they want
> to buy.
>
I have to disagree with Ilitsch here. If we put out a list of say the top 5
ways to do NAT66, and say that #1 is the least harmful, and #5 is the most
harmful (and we explain why this is so) then someone will implement #5 and
claim to be RFC xxxx compliant even though it is the worse possible choice
given. They will do this either because it is easier for them to implment
using old v4 base code or because this is the way they are used to think of
doing NAT.

Thus we can be incouraging people to do what we all agree is the wrong way
to do it.

Either we can agree on the "least harmful" choices and then list 1-3 of them
or we need to endorse no NAT at all (to be clear, I mean not doing NAT
rather than not choosing one over the others).

The question still remains what do we need to achieve and can we agree on
how to do it? Various messages have dealt with the most common mentioned
items in ways that are out of scope for NAT: Topology Masking/hiding and
renumbering come to mind. What else do we need?
Eric
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 01 Dec 2008 11:34:32 +1300

On 2008-12-01 06:38, Iljitsch van Beijnum wrote:
...
> could publish a document that describes the various ways IPv6 NATs could
> be implemented, and then order these in order of increasing harm,
> outlining the harmful effects each type of NAT66s would have. Along with
> some easy to understand terminology or numeric ranking, this would allow
> application vendors to communicate what types of NAT their products will
> work with and which they won't, and allow end-users to specify to their
> middlebox vendors what kind of NAT they want to buy.

I think you're a bit optimistic about the average vendor's concern about
the greater good of the Internet as opposed to their own revenue stream.

http://en.wikipedia.org/wiki/Wikipedia:Don't_stuff_beans_up_your_nose

Documenting the more harmful forms of NAT may just encourage people
to look for a good commercial reason to sell them. Documenting only
the least harmful will still run the risk of encouraging vendors,
but maybe only to do the least bad thing.

If you *must* stuff beans up your nose, here is how do it somewhat safely...

It's a dilemma.

    Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 30 Nov 2008 23:55:33 +0100

> but maybe only to do the least bad thing.

I think you and Eric are misunderstanding my intent. Let me make it  
more clear.

What I'm thinking of is something like:

1. A stateless 1-to-1 checksum-proof NAT breaks referrals.

2. A stateless 1-to-1 non-checksum-proof NAT breaks referrals and can  
only support transport protocols known to the NAT.

3. A stateful 1-to-1 non-checksum-proof NAT breaks referrals, can only  
support transport protocols and breaks sessions when the NAT fails,  
when return traffic arrives through a different NAT or when a routing  
change makes traffic flow through a different NAT.

4. A port overloading cone NAT breaks...

And so on. So no explanation of how to perform the different kinds of  
NATs, just an identification of the type. I don't think think such a  
list can reasonably be interpreted as an IETF blessing of any  
particular kind of NAT implementation. I also don't think it will  
bring people to do things that are worse than what they were planning  
to do in the first place.

On the contrary, when they see what the downsides are of the  
particular NAT type they were thinking of implementhing, some of them  
will move up the list a few steps and implement the least harmful type  
of NAT that gives them what they want.

Currently, nobody bothers to tell users what type of NAT they're going  
to get. Hopefully, a document like this will put enough pressure on  
vendors to at least mention the NAT type somewhere so caveat emptor  
becomes a possibility.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Keith Moore <[email-masked]>
Date: Sun, 30 Nov 2008 19:23:33 -0500

> 1. A stateless 1-to-1 checksum-proof NAT breaks referrals.

this actually doesn't exist, because nothing says that all transport
protocols have to use the same kind of pseudo-header or checksum.

Keith

---

From: Matthew Kaufman <[email-masked]>
Date: Sun, 30 Nov 2008 19:34:43 -0800

> If you *must* stuff beans up your nose, here is how do it somewhat safely...

Well, how about one RFC per possible NAT implementation? Some of them 
would be anti-recommendations... but it wouldn't be the first time an 
RFC recommended what NOT to do.

A side-effect would be that one could tell what kind of NAT it was by 
looking at which RFC number is in the specs.

I have to say that the idea that vendors will create bad things because 
bad ideas are put in RFCs seems a lot less likely than the idea that 
vendors will create bad things without regard to what is in the RFCs.

Matthew Kaufman

---

From: Keith Moore <[email-masked]>
Date: Sun, 30 Nov 2008 22:56:43 -0500

> RFC recommended what NOT to do.

I don't think we should spend our energy trying to enumerate all of the
possible bad ways one can implement a NAT - partially because this will
take a lot of time, and partially because we'll fail to enumerate them
all anyway.  There's also the problem that the more documents there are
to read about NAT in IPv6, the less likely it is that any of those
documents will be read closely.

Our energy would be far better spent trying to describe how to make the
optimal NAT, and explaining why the optimal NAT is still not recommended
in IPv6 - or why NAT is satisfactory only in narrow corner cases.

> vendors will create bad things without regard to what is in the RFCs.

Not clear.

Keith

p.s. As far as I can tell, BEHAVE is already spending a bit too much
energy enumerating all of the possible solutions to X, for various
problems named X.  I realize it's difficult to find a one-size-fits-all
solution. I also realize that sometimes it's necessary to fully
understand the implications of a solution until the effort is made to
work out all of the details and document them.

But the marketplace will have a hard time making sense of a litany of
solutions, each with different applicability.  If we continue down that
path, what we'll get as a result will be a network whose behavior is
unpredictable and therefore difficult for applications to use.