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

Simon Perreault <> Wed, 26 June 2013 08:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C775821F8904 for <>; Wed, 26 Jun 2013 01:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AL1FVnSaA5qa for <>; Wed, 26 Jun 2013 01:15:39 -0700 (PDT)
Received: from ( [IPv6:2620:0:230:8000::2]) by (Postfix) with ESMTP id 67EFA21E8064 for <>; Wed, 26 Jun 2013 01:15:36 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id B947D4043D; Wed, 26 Jun 2013 04:15:31 -0400 (EDT)
Message-ID: <>
Date: Wed, 26 Jun 2013 10:15:33 +0200
From: Simon Perreault <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Behave <>
Subject: Re: [BEHAVE] TCP port overloading, preservation and CGNs
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Jun 2013 08:15:40 -0000

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.

> 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.

> 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.

> 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.