> 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@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf