Re: [BEHAVE] (no subject)

Dan Wing <dwing@cisco.com> Thu, 20 June 2013 03:22 UTC

Return-Path: <dwing@cisco.com>
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 41D3A21E805F for <behave@ietfa.amsl.com>; Wed, 19 Jun 2013 20:22:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.569
X-Spam-Level:
X-Spam-Status: No, score=-110.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 vx-RqR4IE-nl for <behave@ietfa.amsl.com>; Wed, 19 Jun 2013 20:21:57 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8076B11E80CC for <behave@ietf.org>; Wed, 19 Jun 2013 20:21:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3896; q=dns/txt; s=iport; t=1371698517; x=1372908117; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=B7FQCJWno5oVSbKKDCrZRr+6u8CDAobMl/+fuDwmSW8=; b=bS8EGO8yqu0r+IKNMyGNFmWGkVLnTh6+I6484INz1dM/OKMbyC0d0BCd aS7usPuUn2bg5C0kaqUooi2WyuxpAp6DvomzJV+nYrBulftiWseDaaidg f/J2+e7nH8m/a9rRACMAD9Mx5acOgA/FbEVUW8evCf0t6qcVlxkiubz2N 8=;
X-IronPort-AV: E=Sophos;i="4.87,901,1363132800"; d="scan'208";a="83876723"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 20 Jun 2013 03:21:52 +0000
Received: from sjc-vpn3-98.cisco.com (sjc-vpn3-98.cisco.com [10.21.64.98]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5K3LovH026076; Thu, 20 Jun 2013 03:21:50 GMT
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Dan Wing <dwing@cisco.com>
In-Reply-To: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org>
Date: Wed, 19 Jun 2013 20:21:50 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <986A3C4C-2571-4C88-88A5-F822191856F1@cisco.com>
References: <CB1B483277FEC94E9B58357040EE5D02325A6E93@xmb-rcd-x15.cisco.com> <2f7dce8264c8a9a72640629502a44295@cacaoweb.org>
To: <ivan@cacaoweb.org>
X-Mailer: Apple Mail (2.1508)
Cc: Behave <behave@ietf.org>
Subject: Re: [BEHAVE] (no subject)
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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 03:22:03 -0000

On Jun 18, 2013, at 1:33 PM, ivan c <ivan@cacaoweb.org> wrote:

> Hi Senthil,
> 
> Thanks for your message. You might want to read
> http://tools.ietf.org/html/draft-ietf-behave-requirements-update-00 
> 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
> preservation:
> 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.
> 
> Misc:
> 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.

It is impossible to preserve TCP ports on a large or busy NAT (or a NAT that is both large and busy) because multiple clients will simultaneously use the same source port, especially if the clients are using the same operating system because most operating systems unfortunately do not bother to randomize their source ports.

It is also impossible to preserve TCP ports with A+P-related IPv4 address sharing mechanisms.  A+P was first described in RFC6346, and in the MAP-E and MAP-T specifications in Softwires (draft-ietf-softwire-map).  There are 2-3 similar Internet Drafts which have a static assignment of ports to subscribers.

-d


> 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
> http://tools.ietf.org/html/draft-ietf-behave-requirements-update-00 , 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_
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave