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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf