Re: Review of draft-ietf-behave-dccp-04

[Christian Vogt <christian.vogt at ericsson.com>]

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