On 13 feb 2008, at 14:44, Jonathan Rosenberg wrote:
I wrote this because of a discussion that happened during behave at the
last IETF meeting in Vancouver. There was a presentation in the behave
working group on NAT ALG for SCTP - when run natively over IP - and I
found the entire conversation surreal.
I had the same feeling when reading your draft.
(I have no skin in this particular game, but some of the assertions below about
what is and isn't deployed out there caught my eye and I thought I'd respond.)
We can have a big, nasty fight about the philosophical points, but
fortunately, we don't have to, because the whole thing is based on
incorrect facts. I have never seen a consumer NAT that blocks ICMP.
I, OTOH, have recently seen several that give every appearance of doing this. I
have no idea why they do it, but it's incredibly annoying because it turns
connection refusals into timeouts, breaks traceroute, and so on.
Maybe my experience is unusual, but I doubt it. My general lament is that it
seems like it gets harder and harder to find even NATted connectivity that
doesn't have various wierdnesses imposed on it. For example, another major
annoyance are the places that time out connections after five mintues or so
regardless of activity.
I'm 98% sure that path MTU discovery black holes are NOT caused by
just NAT.
On this we agree.
Also, most of the NATs I've encountered have no problems
with non-TCP/UDP protocols (such as proto 41, IPv6-in-IP) except that
obviously only a single internal host gets to have a mapping for such
a protocol.
Man, you have no idea how much I wish this were true. I own four fireally/NAT
boxes (two different models, one of which as two firmware variants) and not a
one of the damn things has the ability to open up an IP-level protocol. This
means I can't let 6to4 traffic through and as a result I'm looking at some
fairly significant replacment costs, not to mention the time needed to
transition to new gear.
Mind you, I'm not saying that protocols should always use a UDP
shim layer. But I think the tradeoffs in favor of doing so are a bit stronger
than you seem to think.
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf