Re: [BEHAVE] TCP port overloading, preservation and CGNs

[ivan c <[e-mail]>]

On Wed, 26 Jun 2013 10:15:33 +0200, Simon Perreault
<[e-mail]> wrote:
> Le 2013-06-25 19:20, ivan c a écrit :
>>> Some NATs don't implement EDM and thus cannot switch to it.
>>>
>>
>> By definition, all NATs are "EDM".
> 
> Please explain.
> 
>> "Endpoint-dependent Mapping" really means "Address and port-dependent
>> Mapping". This is the most general case of NAT, where no requirement is
>> made on the type of mapping. For instance, "EIM" is a particular case
of
>> this general case.
> 
> I don't understand how this could be true.

"Endpoint-dependent Mapping" definition is that mappings with the same
internal endpoint may be assigned to different external endpoints.
It is verified for all NATs.


> 
>> Maybe we should use the term APDM instead of EDM for the sake of
clarity,
>> but the best is probably to avoid using the "EDM" acronym altogether if
>> it
>> leads to confusion.
> 
> EDM is defined in RFC 6887. Let's keep using already-defined terminology

> if it fits.

If it doesn't confuse anyone, I have no problem using it. See above.
Although new acronyms in general are best avoided since they require
readers to learn new acronyms for no particular reason.


> 
>> Instead, we can use the term "no particular
>> requirement
>> on the mapping scheme" or something similar. This way, people new to
the
>> discussion can understand the point immediately and we also avoid the
use
>> of new obscure acronyms.
> 
> EIM and EDM are not requirements. They are qualifiers of NAT behaviour.

Nope, "Endpoint-Independent Mapping" can be a requirement, for example REQ
1. of RFC 4787.


> 
>> Again, the goal here should be to suggest options for NAT to behave in
>> p2p
>> friendly ways. Some useful optional features for CGNs, like port
>> overloading, do have minor caveats that should be detailed in the
>> document,
>> and they also don't apply to "3-tuple" NATs as you mentioned.
>> This is the best way in my opinion to write a Best Current Practices
>> document.
> 
> I would simply like to first understand technically what you're
proposing.

Sounds great.

> 
> Simon

-- 
_Ivan Chollet_