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

Simon Perreault <> Fri, 21 June 2013 07:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 39E7511E8166 for <>; Fri, 21 Jun 2013 00:48:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.586
X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XnrvNv5+saYS for <>; Fri, 21 Jun 2013 00:48:15 -0700 (PDT)
Received: from ( [IPv6:2620:0:230:8000::2]) by (Postfix) with ESMTP id 443C711E816D for <>; Fri, 21 Jun 2013 00:48:15 -0700 (PDT)
Received: from (unknown [IPv6:2620:0:230:2001::1000]) by (Postfix) with ESMTPSA id 97F5F40426 for <>; Fri, 21 Jun 2013 03:48:14 -0400 (EDT)
Message-ID: <>
Date: Fri, 21 Jun 2013 09:48:13 +0200
From: Simon Perreault <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 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
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: Fri, 21 Jun 2013 07:48:16 -0000

Le 2013-06-20 21:20, ivan c a écrit :
> 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

I, for one, would expect them to be! See RFC 6888.

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

 From the start of this discussion, it has appeared to me like you do 
have a use case for EIM TCP. Don't you want to do TCP NAT traversal?

> 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
> recommendation.
>> There are two distinct things here:
>> 1. Port preservation is a must
>> 2. Port preservation requires port overloading to work
> deterministically.
> 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.

Many NATs don't care about remote endpoints.

> 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

Assuming that NATs will "fall back on EDM" seems very risky.

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

Please understand that there are many different ways to implement NAT, 
and this is just one of them.

>> 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
> by
>> NAT devices. That kills scalability.
>> 2. Port overloading causes packets to be dropped if two connections
> going
>> 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
> scalability.

Some NATs don't track sessions.

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

Some NATs don't implement EDM and thus cannot switch to it.


>> 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
> reasons.
> This makes a big difference in what you can require from a CGN.

DTN made easy, lean, and smart -->
NAT64/DNS64 open-source        -->
STUN/TURN server               -->