Re: [BEHAVE] (no subject)

ivan c <> Tue, 18 June 2013 20:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CDE1E21E8090 for <>; Tue, 18 Jun 2013 13:32:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lDTxIKWB8eVm for <>; Tue, 18 Jun 2013 13:32:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 600FC21E8054 for <>; Tue, 18 Jun 2013 13:32:36 -0700 (PDT)
Received: from www-data by with local (Exim 4.72) (envelope-from <>) id 1Up2ag-0008Pv-AQ; Tue, 18 Jun 2013 22:33:22 +0200
To: "Senthil Sivakumar (ssenthil)" <>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Date: Tue, 18 Jun 2013 22:33:22 +0200
From: ivan c <>
Organization: cacaoweb
In-Reply-To: <>
References: <>
Message-ID: <>
User-Agent: RoundCube Webmail/0.3.1
Cc: Behave <>
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 20:32:46 -0000

Hi Senthil,

Thanks for your message. You might want to read 
It features the list of updates to the existing RFC, adapted to new usage
contexts such as CGNs, mobile networks, etc.

On Tue, 18 Jun 2013 19:24:50 +0000, "Senthil Sivakumar (ssenthil)"

>>Are you talking about UDP port preservation? 
> Both TCP & UDP. The latest implementation in some router families is not
> to have port preservation
> (for both TCP & UDP).

The discussion here is not about UDP. UDP port preservation should
generally not be implemented by NATs, as it could generate conflicts when 2
internal hosts using the same local port, each with a session to the same
endpoint. This would break end-to-end connectivity in rare cases, as there
is no fallback mechanism (as opposed to TCP).

To be clear, the requirements are as follows:
* NAT SHOULD NOT use UDP port preservation
* NAT SHOULD use TCP port preservation

Here are some NATs that have been tested and implement TCP port
in the UK:
BT (British Telecom) (house-made gateway) - number 1 provider
Virgin (house-made gateway) - number 2 provider
Sky (Sagemcom) - number 3 provider

in France:
Orange (Livebox) (house-made gateway) - number 1 provider
Free (Freebox) (house-made gateway) - number 2 provider
SFR/Neuf (Neufbox) (house-made gateway) - number 3 provider

This covers the overwhelming majority of subscribers.

We have the same results in Spain in Italy.

Linksys E1200, latest generation.
Netgear, various models

It is difficult to find any NAT that does *not* implement TCP port
preservation in these countries.
If you think some gateway implementations have dropped TCP port
preservation, you need to substantially support your claim by a reference.
We are not aware of anything that would support it. 

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

This is the purpose of the new draft , to
make the use case for port overloading, as it is needed in CGNs. It wasn't
needed nearly as much in 2005 when RFC 5382 was first written.

REQ-7: A NAT MUST NOT have a "Port assignment" behavior of "Port
overloading" for TCP
is too stringent, as proved in my earlier message and in the
draft-ietf-behave-requirements-update-00, and not needed.

Port overloading is perfectly acceptable when the remote endpoints are
distinct, as it preserves the uniqueness of the 5-tuple.

As a result, REQ-7 must be corrected.

_Ivan Chollet_