NAT66: my conclusions

[Iljitsch van Beijnum]

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
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Eric Klein-3]

On Sun, Nov 30, 2008 at 19:38, Iljitsch van Beijnum <iljitsch@...> 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>
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.

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
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Brian E Carpenter-2]

On 2008-12-01 06:38, Iljitsch van Beijnum wrote:
...

>
> 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 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
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Iljitsch van Beijnum]

On 30 nov 2008, at 23:34, Brian E Carpenter wrote:

> 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.

> 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.

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
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Keith Moore-5]

> 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
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Matthew Kaufman]

Brian E Carpenter wrote:

>
> 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.
>  

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
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Keith Moore-5]

Matthew Kaufman wrote:

> Brian E Carpenter wrote:
>>
>> 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.
>>  
>
> 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.

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.

> 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.

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.

_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Margaret Wasserman-2]

On Nov 30, 2008, at 7:23 PM, Keith Moore wrote:
>> 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.
>
This is absolutely true.  The goal of the checksum correction in NAT66  
is to avoid having to touch the TCP, UDP and ICMPv6 checksums which  
contain an IPv6 pseudo-header checksum (a 16-bit one's complement  
sum).  It will work for any transport layer that includes the IPv6  
addresses in a 16-bit one's complement checksum and will have no  
benefit (or detriment) for transport layers that don't.

Margaret


_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Iljitsch" == Iljitsch van Beijnum <iljitsch@...> writes:
    Iljitsch> After having debated the virtues of having NAT66 in the
    Iljitsch> first place and its features if we were to have it, my
    Iljitsch> conclusion is that we're not going to be able to create a
    Iljitsch> NAT66 specification that makes all parties happy enough to
    Iljitsch> reach rough consensus.

  As one who would like to have no NAT66 (I believe in SHIM6, ULA-like
objects, and better implementations of source address selection) I would
like to know the details of where the NAT66 people diverge.

  My opinion is that it would be useful to have 1 or 5 documents that
explains the requirements that people think they have.

  My impression is that we can't figure out if anything would be
acceptable, because we don't know what the assumptions each party has
made.

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

  I see. I believed what you did.

    Iljitsch> However, I believe there is something useful that the IETF
    Iljitsch> can do, and that is mostly what the BEHAVE wg has already
    Iljitsch> been doing: document NAT behavior, and create
    Iljitsch> specifications for applications that want to work through
    Iljitsch> those NATs.  But with IPv6 we have the opportunity to be
    Iljitsch> proactive: rather than describe the harm that existing
    Iljitsch> NATs do, BEHAVE could publish a document that describes
    Iljitsch> the various ways IPv6 NATs could be implemented, and then
    Iljitsch> order these in order of increasing harm, outlining the

  I think that this will become the document which you say will cause
more harm than good.

    Iljitsch> harmful effects each type of NAT66s would have.  Along
    Iljitsch> with some easy to understand terminology or numeric
    Iljitsch> ranking, this would allow application vendors to
    Iljitsch> communicate what types of NAT their products will work
    Iljitsch> with and which they won't, and allow end- users to specify
    Iljitsch> to their middlebox vendors what kind of NAT they want to
    Iljitsch> buy.

  Yes.

- --
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@... http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBSTRvloCLcPvd0N1lAQLZBAgAsFOVhrxjm/MVXKv6FvMgphqAQRrdf5oE
nsLDmpGK4CirfQ+lnFreiSd3RPhlJejZYP1kz1JZx54WXtm8e4J9j2oBxSQ8xUBI
69nSnF25dqh2YRM4pCV2wP2Q9ZQbRxQIkMt9FJP8bZRxg3WmRVXFvRMTo+ip9ZSF
muYhka1YAOxI1F03kCnUWElXGQ7fTJBiSK40GCQwTxU7FUqoMPS/ALKBlvsss0nQ
0fP96cEJHi99iPOaUjcubMeABSzYiM9I98eDMBj1pJdfiN9+89xIqMTNWCu5wcFU
AsDyOA/XgkG0HQXXiniv3XeSw3v7NW4dBsSIqjQMbwHtEl7jtksDzg==
=t2+4
-----END PGP SIGNATURE-----
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave