Re: [BEHAVE] (no subject)

"Senthil Sivakumar (ssenthil)" <> Tue, 18 June 2013 19:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6DE9211E80FA for <>; Tue, 18 Jun 2013 12:24:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.723
X-Spam-Status: No, score=-9.723 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wWKWTwXfVQsA for <>; Tue, 18 Jun 2013 12:24:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7A05111E80F6 for <>; Tue, 18 Jun 2013 12:24:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4062; q=dns/txt; s=iport; t=1371583492; x=1372793092; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=omyAhBnL+HKOtcZl7u9vAuntLu2Ym6c8Qi4JElcNFXs=; b=KXX5TSiBgfC+J7xyai5ioQuMm9mhYc8cnVx3YyR7+gf+2Q3wpEz6ZbNs yMGpk5CtSnIaJld3y8eUVa10nST0ocgm62mp6/lbyU1FvAC43QC7cqBHb zb5iLD9YKP8X2e1wBhGU5DNtveiPsStQ9Q19dKPRhF4mapW40hLQj2JQq Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag4FAPeywFGtJV2Z/2dsb2JhbABZgwl6gwG8Dw12FnSCIwEBAQQ0VwkYBAYiBDAlAgQBEgiIBo1/mzUGkUaBIIxjgQcWIoJHOWEDoVSHMIMPgWhA
X-IronPort-AV: E=Sophos;i="4.87,890,1363132800"; d="scan'208";a="224216674"
Received: from ([]) by with ESMTP; 18 Jun 2013 19:24:51 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r5IJOpVQ010583 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Jun 2013 19:24:51 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Tue, 18 Jun 2013 14:24:51 -0500
From: "Senthil Sivakumar (ssenthil)" <>
To: "" <>, Behave <>
Thread-Index: AQHObFmAgdHlRyxSR02wAQ7tdo7juA==
Date: Tue, 18 Jun 2013 19:24:50 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="euc-kr"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [BEHAVE] (no subject)
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: Tue, 18 Jun 2013 19:24:58 -0000

Hi Ivan,

On 6/18/13 1:10 PM, "ivan c" <> wrote:

>Hi Senthil,
>See my comments below.
>On Tue, 18 Jun 2013 16:16:33 +0000, "Senthil Sivakumar (ssenthil)"
><> wrote:
>> I just want to add that I did a port preservation implementation a while
>> ago, but realized that the number of times that the ports couldn¹t be
>> preserved were getting more and more. Even though this wasn't causing
>> application behavior issues, the customers were complaining because they
>> construed that as NAT not working properly, (whether their assumption
>> is right or wrong is a different discussion), so we ended up not using
>> port preservation as a default behavior in later implementations. It
>> improves the performance.
>Are you talking about UDP port preservation? I think we all agree UDP port
>preservation is not necessary, as long as the NAT is EIM for UDP.
>About TCP port preservation, most NAT implementations have it. In some
>countries (like France), all ISP-provided gateways have it.
>As you note, TCP port preservation improves latency and thus performance,
>when compared to the alternative of using a STUNT server.
>It does not need the intermediate step of contacting the STUNT server to
>perform TCP port prediction.

Both TCP & UDP. The latest implementation in some router families is not
to have port preservation
(for both TCP & UDP).

>>>- Port preservation is not applicable to CGN, where a subscriber often
>>>only has access to a limited range of external ports.
>> Exactly, with the allocation of port sets in CGN, it becomes very
>> difficult to do any kind of port preservation.
>Nope, you would need to elaborate on this.
>The probability that of an internal port collision is high because of the
>birthday paradox, but port overloading is perfectly acceptable, and when a
>full collision occurs (when internal ports and remote endpoints are the
>same for two outgoing TCP connections), which is supposed to be a rare
>event, the CGN can fallback on EDM or simply drop the connection.

Most of the NATs that I know don’t do port overloading any more.
RFC 5382 also says,
REQ-7:  A NAT MUST NOT have a "Port assignment" behavior of "Port
      overloading" for TCP.

>>>- There are ways to improve the scalability of EIM without killing it.
>>>I've been advocating for some time that NATs should be allowed to use
>>>EDM for protocols that they know will not break, with EIM as a default.
>>>For example, using EDM for TCP port 80 and UDP port 53 is easy,
>>>harmless, and has a big impact.
>> For allowing EDM, one has to know their applications they are using, but
>> as you say port 80 can work well with EDM.
>Exactly, see my message to Simon for a more in-depth discussion about this
>_Ivan Chollet_