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

ivan c <> Thu, 20 June 2013 19:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 46C5721E808D for <>; Thu, 20 Jun 2013 12:20:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GppQpPyTX1Tz for <>; Thu, 20 Jun 2013 12:20:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5D84011E80BA for <>; Thu, 20 Jun 2013 12:20:03 -0700 (PDT)
Received: from www-data by with local (Exim 4.72) (envelope-from <>) id 1UpkPf-0005R8-Ab for; Thu, 20 Jun 2013 21:20:55 +0200
To: Behave <>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Date: Thu, 20 Jun 2013 21:20:55 +0200
From: ivan c <>
Organization: cacaoweb
In-Reply-To: <>
References: <>
Message-ID: <>
User-Agent: RoundCube Webmail/0.3.1
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: Thu, 20 Jun 2013 19:20:09 -0000

On Wed, 19 Jun 2013 14:38:12 +0000, "Senthil Sivakumar (ssenthil)"
<> wrote:
> Ok thanks for the pointers. The NATs that I was talking about were
> enterprise/SP NAT boxes,
> not the home routers. Many of the CGN implementations don¹t do port
> preservation. 

Yes, CGNs are not expected to be p2p-friendly at this stage, and I don't
think having any MUST requirements to help with TCP Hole Punching would do
any good. EIM for TCP can probably be safely ignored too as there is no
real use case, however if there is one thing they should try to implement
that's RFC 4787 for UDP. 
Having said that, I would support mentioning TCP Hole Punching and its
subvariants in the document and what a NAT should do to support them as a

> There are two distinct things here:
> 1. Port preservation is a must
> 2. Port preservation requires port overloading to work

Not exactly, port preservation can *never* work deterministically.
Consider the rare case where the two remote endpoints are the same too.
This breaks port preservation.
Not that it matters anyway, what we want is the interface provided by the
TCP Hole Punching protocol to be deterministic. The NAT falling back on EDM
in case of a collision is a case that is taken care deterministically by
the TCP Hole Punching protocol. (See my email in reply to Simon a few
minutes ago)
This is what home NATs do: TCP port preservation (which implies EIM for
TCP, so makes it easy for them), and in case of a source collision,
fallback on EDM.

> I don¹t have a lot of problem with an implementation choosing to do port
> preservation if it can.
> I do have issues with doing port overloading. Two reasons again.
> 1. Port overloading requires the destination information to be tracked
> NAT devices. That kills scalability.
> 2. Port overloading causes packets to be dropped if two connections
> to the same destination, causing indeterministic behavior.

(my email to Simon is more detailed regarding TCP port overloading and the
relationship with TCP Hole Punching)
I restrict the discussion to port overloading for TCP.
1. It kills scalability when logging is required (but in that case a CGN
would probably use static port ranges to segregate subscribers).
As far as session tracking is concerned, port overloading only makes the
key of the NAT's mapping hashtable twice as big. Not a concern for
2. That's a bit extreme, the NAT doesn't need to drop packets, it just
switches to EDM. This only adversely affects TCP Hole Punching, which is
prepared to deal with the case in its protocol.

> Maybe as Rajiv suggested in another thread, maybe we need a CPE NAT
> requirements document where the above requirement might be placed.
> But I don¹t know what good it is, if there is another CGN on the headend
> that would not honor the port preservation. As I said, in my earlier
> Email, the CGNs can now have a pre-allocated set of ports (like 1k
> ports/sub), where there is no way to do port preservation.

At this stage, CGNs are not very keen on EIM for TCP, and TCP port
preservation is a stronger condition, so it looks like a lost battle to me.
And in my opinion, if CGNs could at least do EIM for UDP, it would be a
good start indeed. That would have a higher priority.

There is one big difference between home NATs and CGNs: behind a home
NATs, users know each other, and can have a friendly policy to share
resources like ports forwardings. As opposed to a CGN which is more
concerned about isolating users from one another for privacy and security
This makes a big difference in what you can require from a CGN.

_Ivan Chollet_