Rémi,
endpoint independent mapping and filtering enables address referrals
between
application instances (which use the same port number). This
advantage is
independent of the transport protocol and the connection model. The
exceptions you are listing are special cases for NAT'ing in general,
not only
with regard to the usefulness of endpoint independent mapping and
filtering.
Anyway, I am fine with requiring endpoint independence in transport-
specific
documents.
- Christian
Rémi Denis-Courmont wrote:
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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf