On Friday 07 November 2008 13:00:19 ext Christian Vogt, you wrote: > > Whether it's of any use depends on the connection model (or lack > > thereof) of > > the transport protocol. I don't want to presume that this would make > > sense > > for all future transport protocols. [...] > > I don't agree. A reason for recommending endpoint-independent mapping > and filtering is to enable applications to refer each other to a host > behind a NAT. This is desirable independent of the transport protocol. But whether this is useful depends on the transport protocol and/or connection model. It does help for unicast UDP (and UDP-Lite). It does help for TCP, only if simultaneous open is supported by the application, the operating system and the middleboxes. If does help for DCCP _only_ if the DCCP stack implements the simultaneous open option, which is _not_ in the baseline DCCP document. It does not help with, e.g. multicast UDP. It does not mean anything for port-less protocol, including ICMP, proto-41, etc. It is insufficient for SCTP. Who knows how it applies to would-be future transports? Besides, I think it's too late for a "factorized" BEHAVE specification. Good news: we have much of the baseline in the BEHAVE-UDP RFC. The other documents already borrow quite a lot from it, especially the general concepts and terminology. > > REQ-6: If a NAT includes ALGs, they MUST NOT affect DCCP. > > Make it even clearer: > > REQ-6: If a NAT includes ALGs, the ALGs MUST NOT affect DCCP. Right. -- Rémi Denis-Courmont Maemo Software, Nokia Devices R&D _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf