|
»
« Return to Thread: NAT66: my conclusions
Re: NAT66: my conclusions
by Iljitsch van Beijnum
::
Rate this Message:
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
> 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
« Return to Thread: NAT66: my conclusions
| Free embeddable forum powered by Nabble | Forum Help |
