Re: [BEHAVE] (no subject)

ivan c <ivan@cacaoweb.org> Thu, 20 June 2013 20:12 UTC

Return-Path: <ivan@cacaoweb.org>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E9621E80C1 for <behave@ietfa.amsl.com>; Thu, 20 Jun 2013 13:12:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.554
X-Spam-Level:
X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znQl10aiOm9l for <behave@ietfa.amsl.com>; Thu, 20 Jun 2013 13:12:36 -0700 (PDT)
Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB1C21E8091 for <behave@ietf.org>; Thu, 20 Jun 2013 13:12:36 -0700 (PDT)
Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from <ivan@cacaoweb.org>) id 1UplEV-0006Di-Sh for behave@ietf.org; Thu, 20 Jun 2013 22:13:27 +0200
To: Behave <behave@ietf.org>
X-PHP-Originating-Script: 0:func.inc
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Date: Thu, 20 Jun 2013 22:13:27 +0200
From: ivan c <ivan@cacaoweb.org>
Organization: cacaoweb
In-Reply-To: <986A3C4C-2571-4C88-88A5-F822191856F1@cisco.com>
References: <CB1B483277FEC94E9B58357040EE5D02325A6E93@xmb-rcd-x15.cisco.com> <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <986A3C4C-2571-4C88-88A5-F822191856F1@cisco.com>
Message-ID: <df8d79fffb4855141b09c6459522e851@cacaoweb.org>
X-Sender: ivan@cacaoweb.org
User-Agent: RoundCube Webmail/0.3.1
Subject: Re: [BEHAVE] (no subject)
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ivan@cacaoweb.org
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Jun 2013 20:12:42 -0000

Hi Dan,

On Wed, 19 Jun 2013 20:21:50 -0700, Dan Wing <dwing@cisco.com> wrote:
> 
> It is impossible to preserve TCP ports on a large or busy NAT (or a NAT
> that is both large and busy)
> 

Yes, it's impossible (regardless of the NAT's size). Home NATs usually
fall back on EDM in collision cases. This doesn't bother the TCP Hole
Punching protocol.


> It is also impossible to preserve TCP ports with A+P-related IPv4
address
> sharing mechanisms. 
> 

Yes, such NATs map the ports topology of the host to a coarser topology
(less available ports), and although easy to implement it isn't too
satisfying. A NAT should be as transparent as possible by trying to mimic
the host's behavior and its use of ports. It's nicer to leave the host
topology intact and superpose usages of each subscriber instead. Squeezing
the number of available ports is expected to break quite a few things,
although not in major ways. This is not really an issue in the context of
p2p applications, as they are used to deal with a variety of corner cases
and weirder NATs behaviors.



-- 
_Ivan Chollet_