From internet-drafts@ietf.org Mon Jun 3 14:11:43 2013 Return-Path: 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 E804421F8E12; Mon, 3 Jun 2013 14:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.362 X-Spam-Level: X-Spam-Status: No, score=-102.362 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 ab61+BK43vcc; Mon, 3 Jun 2013 14:11:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A81B21E80C3; Mon, 3 Jun 2013 14:06:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130603210625.31277.82122.idtracker@ietfa.amsl.com> Date: Mon, 03 Jun 2013 14:06:25 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-requirements-update-00.txt X-BeenThere: behave@ietf.org 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: Mon, 03 Jun 2013 21:11:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Avoida= nce Working Group of the IETF. Title : Network Address Translation (NAT) Behavioral Requirement= s Updates Author(s) : Reinaldo Penno Simon Perreault Sarat Kamiset Mohamed Boucadair Kengo Naito Filename : draft-ietf-behave-requirements-update-00.txt Pages : 14 Date : 2013-06-03 Abstract: This document clarifies and updates several requirements of RFC4787, RFC5382 and RFC5508 based on operational and development experience. The focus of this document is NAPT44. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-requirements-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-requirements-update-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rajiva@cisco.com Wed Jun 5 06:14:13 2013 Return-Path: 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 45E8621F99C0; Wed, 5 Jun 2013 06:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 L2XwwvJ6bt-r; Wed, 5 Jun 2013 06:14:08 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0728721F999B; Wed, 5 Jun 2013 06:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1002; q=dns/txt; s=iport; t=1370438048; x=1371647648; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=0VuYdvN4FLSfr85yDXqlZf0dSnY6M0edPgKpioihzao=; b=IsFey7HERh4NTYyrtRxyX7IYvSYGwc3qzOAIkhC6cDEseGxeGYeE45Ag v9OaffX2W1HTEiHAGOa8MdxsGDyvqDoqTL6YazdG0M1XSiDxg27/IYSya on/dZtGrpstimj1ra6G2QIMslR+Ca0ifm/wiGk92WeVCg9VIryO7NWkoc I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FADc5r1GtJXG9/2dsb2JhbABZFoJzMIJ1vDd8FnSCJQEEOj8SASoUQiYBBAENDQGIBL0MjnoxgwFhA6NfhSCDD4In X-IronPort-AV: E=Sophos;i="4.87,806,1363132800"; d="scan'208";a="219055757" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 05 Jun 2013 13:14:07 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r55DE7QQ019360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 13:14:07 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 08:14:06 -0500 From: "Rajiv Asati (rajiva)" To: "v6ops@ietf.org" , "Softwires-wg list (softwires@ietf.org)" , "behave@ietf.org" Thread-Topic: Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlA== Date: Wed, 5 Jun 2013 13:14:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Erik Kline \(ek@google.com\)" Subject: [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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: Wed, 05 Jun 2013 13:14:13 -0000 Some of you may recall our discussion (during the last IETF) around "how ma= ny TCP/UDP ports are enough with NAPT44" per home, as ISPs move into A+P pa= radigm. ~500, ~1000, ~3000??? Well, I started monitoring my home router and plotting the NAPT44 port util= ization on a minute-by-minute basis. You may find it here - http://www.empl= oyees.org/~rajiva In short, port range of 500 seems ok, though 1000 would be more than enough= for my home. Suffice to say, this is just a sample representation, since t= he port utilization would vary home to home, based on number of active devi= ces, type of applications, the degree of simultaneous device or application= usage etc. If any of you are doing similar monitoring, then please share. Cheers, Rajiv PS: Thanks to Erik Kline, who explained (with sufficient details) how to us= e google charting for my data. And thanks to Xun Wang & Shaoshuai Dai for h= elping me out significantly. PS: My home has 3-4 active devices. From kristian.poscic@alcatel-lucent.com Wed Jun 5 06:33:17 2013 Return-Path: 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 7DE1021F9ABB; Wed, 5 Jun 2013 06:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 dLrf+ofQT54B; Wed, 5 Jun 2013 06:33:12 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id EE70B21F9ACF; Wed, 5 Jun 2013 06:33:06 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r55DWwG0026696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Jun 2013 08:32:58 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r55DWtQK002234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 09:32:56 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.44]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Wed, 5 Jun 2013 09:32:54 -0400 From: "Poscic, Kristian (Kristian)" To: "Rajiv Asati (rajiva)" , "v6ops@ietf.org" , "Softwires-wg list (softwires@ietf.org)" , "behave@ietf.org" Thread-Topic: Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuw Date: Wed, 5 Jun 2013 13:32:53 +0000 Message-ID: <7921F977B17D5B49B8DCC955A339D2F02AB3A800@US70UWXCHMBA05.zam.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "Erik Kline \(ek@google.com\)" Subject: Re: [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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: Wed, 05 Jun 2013 13:33:17 -0000 Thanks. Can you tell us in general what applications did you use for this? This heavily depends on the application type in use...p2p apps, etc. Since = some apps spawn a large number of TCP ports for example. So the question is to what degree do you think is your sample representativ= e of a general user in any region? For example does it cover 30% of users for an ISP in NA while it covers 80%= of users for another ISP in APAC for example? -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Rajiv Asati (rajiva) Sent: Wednesday, June 05, 2013 6:14 AM To: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); behave@ietf.org Cc: Erik Kline (ek@google.com) Subject: [BEHAVE] Home NAPT44 - How many ports? Some of you may recall our discussion (during the last IETF) around "how ma= ny TCP/UDP ports are enough with NAPT44" per home, as ISPs move into A+P pa= radigm. ~500, ~1000, ~3000??? Well, I started monitoring my home router and plotting the NAPT44 port util= ization on a minute-by-minute basis. You may find it here - http://www.empl= oyees.org/~rajiva In short, port range of 500 seems ok, though 1000 would be more than enough= for my home. Suffice to say, this is just a sample representation, since t= he port utilization would vary home to home, based on number of active devi= ces, type of applications, the degree of simultaneous device or application= usage etc. If any of you are doing similar monitoring, then please share. Cheers, Rajiv PS: Thanks to Erik Kline, who explained (with sufficient details) how to us= e google charting for my data. And thanks to Xun Wang & Shaoshuai Dai for h= elping me out significantly. PS: My home has 3-4 active devices. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From mcr@sandelman.ca Wed Jun 5 06:52:30 2013 Return-Path: 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 C963F21F9B47; Wed, 5 Jun 2013 06:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 YT2szkZ2ol+k; Wed, 5 Jun 2013 06:52:29 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 07EE021F9B48; Wed, 5 Jun 2013 06:52:29 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5DEDF2017F; Wed, 5 Jun 2013 10:05:23 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9FD1963A8C; Wed, 5 Jun 2013 09:51:37 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7F07B63A5E; Wed, 5 Jun 2013 09:51:37 -0400 (EDT) From: Michael Richardson To: "Rajiv Asati (rajiva)" In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "Softwires-wg list \(softwires@ietf.org\)" , "Erik Kline \(ek@google.com\)" , "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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: Wed, 05 Jun 2013 13:52:30 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "rajiva" =3D=3D rajiva writes: rajiva> In short, port range of 500 seems ok, though 1000 would be rajiva> more than enough for my home. Suffice to say, this is just a rajiva> sample representation, since the port utilization would vary rajiva> home to home, based on number of active devices, type of rajiva> applications, the degree of simultaneous device or rajiva> application usage etc.=20 You are a home of how many computers? How many active people? (I don't assume those are 1:1...) I guess you have no IPv6 running? SIP? Skype? VPN (what kind? does it terminate on a desktop, or on your "router"?)=20 =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUa9CaIqHRg3pndX9AQKx8AQAwzO8Qpe9GP1fRz6ZxUyAKQ7hYnn8UGfv tRZv4oupP1uApQ7k3r3W+l87xhji6MeQAtrvh1XXpA7GMAdT06xt+K88rt8bmIoN BrPLh1GL33Ij5QYDt3tbOvBdv1GsYdBaMbwhgLHobA3QNRFxiEH6Ns9SWb3n4ZfA 1SoeM7iOi9o= =p17H -----END PGP SIGNATURE----- --=-=-=-- From repenno@cisco.com Wed Jun 5 08:44:35 2013 Return-Path: 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 58AC421F9B09; Wed, 5 Jun 2013 08:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8] 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 W0LI7gt3oTY0; Wed, 5 Jun 2013 08:44:30 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 42AE321F9AF8; Wed, 5 Jun 2013 08:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2691; q=dns/txt; s=iport; t=1370447068; x=1371656668; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jHCI/VUd1ESZajsS7uvW7d8rO0TeWCXku1tUS4ssbLA=; b=R/4VqVQr2yBXZvGbtaXuk/QQrKd3lbfVG8GyppDLAtBThdM40X+aHzlS 0xtGrnzhmA9WYpeBy9zLZIzAqCdZAKnUU4m8lICISBFDCVLtv9XiVYLN8 OLOC7ayQ+oUcHPmWMTmB4gHen2/LWGybEu0CFmNabTVuL4PdXT+vcWwka Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAHRbr1GtJV2Z/2dsb2JhbABaFoJzML8sfRZ0giMBAQEEAQEBNzQLDAYBCBEEAQELFAkuCxQJCAEBBAENBQgBiAQMvTGOejEHBoJ0YQOjX4Uggw+CJw X-IronPort-AV: E=Sophos;i="4.87,807,1363132800"; d="scan'208";a="216150526" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 05 Jun 2013 15:44:26 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r55FiQnl029315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 15:44:26 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 10:44:25 -0500 From: "Reinaldo Penno (repenno)" To: "Poscic, Kristian (Kristian)" , "Rajiv Asati (rajiva)" , "v6ops@ietf.org" , "Softwires-wg list (softwires@ietf.org)" , "behave@ietf.org" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAAkCoAA= Date: Wed, 5 Jun 2013 15:44:25 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A0972@xmb-rcd-x04.cisco.com> In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F02AB3A800@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.243.252] Content-Type: text/plain; charset="us-ascii" Content-ID: <9E976E5D808FB548B1EB58FDFADC5A00@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Erik Kline \(ek@google.com\)" Subject: Re: [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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: Wed, 05 Jun 2013 15:44:35 -0000 Yes, there are regional differences. But even then, in general, 90% of the active users can be covered by 1000 ports. I have been collecting data for many years, and actually the number of TCP ports consumed have been going Down due to a number of factors. On the other hand, as Rajiv captured,the number of UDP sessions can be much larger than the number of TCP. Because the way dynamic webpages are constructed today, there are sometimes literally 100s of DNS requests to download a single page. On 6/5/13 10:32 AM, "Poscic, Kristian (Kristian)" wrote: >Thanks. Can you tell us in general what applications did you use for this? >This heavily depends on the application type in use...p2p apps, etc. >Since some apps spawn a large number of TCP ports for example. > >So the question is to what degree do you think is your sample >representative of a general user in any region? > >For example does it cover 30% of users for an ISP in NA while it covers >80% of users for another ISP in APAC for example? > >-----Original Message----- >From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf >Of Rajiv Asati (rajiva) >Sent: Wednesday, June 05, 2013 6:14 AM >To: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); >behave@ietf.org >Cc: Erik Kline (ek@google.com) >Subject: [BEHAVE] Home NAPT44 - How many ports? > >Some of you may recall our discussion (during the last IETF) around "how >many TCP/UDP ports are enough with NAPT44" per home, as ISPs move into >A+P paradigm. ~500, ~1000, ~3000??? > >Well, I started monitoring my home router and plotting the NAPT44 port >utilization on a minute-by-minute basis. You may find it here - >http://www.employees.org/~rajiva > >In short, port range of 500 seems ok, though 1000 would be more than >enough for my home. Suffice to say, this is just a sample representation, >since the port utilization would vary home to home, based on number of >active devices, type of applications, the degree of simultaneous device >or application usage etc. > >If any of you are doing similar monitoring, then please share. > >Cheers, >Rajiv > >PS: Thanks to Erik Kline, who explained (with sufficient details) how to >use google charting for my data. And thanks to Xun Wang & Shaoshuai Dai >for helping me out significantly. > >PS: My home has 3-4 active devices. >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From mcr@sandelman.ca Wed Jun 5 09:24:31 2013 Return-Path: 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 08DE921F9BAF; Wed, 5 Jun 2013 09:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6] 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 N6WUJ3Alrsvn; Wed, 5 Jun 2013 09:24:30 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 14AE721F9BA8; Wed, 5 Jun 2013 09:24:29 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D361E2017F; Wed, 5 Jun 2013 12:37:21 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7B08C63A8C; Wed, 5 Jun 2013 12:23:35 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3D71E63A5E; Wed, 5 Jun 2013 12:23:35 -0400 (EDT) From: Michael Richardson To: "v6ops@ietf.org" , "Reinaldo Penno (repenno)" In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090A0972@xmb-rcd-x04.cisco.com> References: <45A697A8FFD7CF48BCF2BE7E106F0604090A0972@xmb-rcd-x04.cisco.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "Softwires-wg list \(softwires@ietf.org\)" , "Poscic, Kristian \(Kristian\)" , "behave@ietf.org" , "Erik Kline \(ek@google.com\)" , "Rajiv Asati \(rajiva\)" Subject: Re: [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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: Wed, 05 Jun 2013 16:24:31 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "repenno" =3D=3D repenno writes: repenno> On the other hand, as Rajiv captured,the number of repenno> UDP sessions can be much larger than the number of repenno> TCP. Because the way=20 repenno> dynamic webpages are constructed today, there are sometimes repenno> literally 100s=20 repenno> of DNS requests to download a single page. If one is doing CGN, wouldn't it be reasonable to point customers' at=20 a recursive DNS server with an interface inside the CGN? This seems to also suggest that having a *caching* recursive DNS(SEC, HOMENET+, mDNS+) server inside the customer router is also a big win. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUa9mBoqHRg3pndX9AQK2bwQAt1HNs9Z9y6Cx5YGN4gjzRbMSkOxaA83a bze577xQlPzJVeTuWpAnVshnGH3xwq1hqpwito4AxJdZEjr5ZOlpBDZlgWLV7cbC RzOhujuQpiCxnBCuajA+ydpTj0HsQVYGuef39pKJtoLiBrDBjLuxsLCh8HVa8+uG noImTMghE/A= =DWE4 -----END PGP SIGNATURE----- --=-=-=-- From repenno@cisco.com Wed Jun 5 09:28:06 2013 Return-Path: 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 2A4A821F9A87; Wed, 5 Jun 2013 09:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8] 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 yGr-Y8p1Sl2C; Wed, 5 Jun 2013 09:28:01 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id E5B1721F9B41; Wed, 5 Jun 2013 09:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1183; q=dns/txt; s=iport; t=1370449681; x=1371659281; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=OY/eyAImJt4Tl3Iu98qKlM/W50kA4qcNe27B1L9XoPg=; b=cOsft9Jeg8eigQZG+z4vKr5sBFlP8rDoE+XyOenOT2uDRUVxYa9XHGI5 kd3f27y7UHu6IWBil68uJLbVU+dIrV1xwYfZZ/Pqjo2BOwDr4xOJrjDq/ RbFvVGpHoAlLfSZqXbe3O2PIYw6gd8PlnRznsJbEjVwOjIB0ZR+QzCN7w Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAP1fr1GtJXG+/2dsb2JhbABZgwkwvyx9FnSCJQEEOj8SAQgiFEIlAQEEAQ0FCBaHb707jnoxB4J6YQOof4MPgic X-IronPort-AV: E=Sophos;i="4.87,808,1363132800"; d="scan'208";a="219157721" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 05 Jun 2013 16:28:00 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r55GS0Xb021059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 16:28:00 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 11:27:59 -0500 From: "Reinaldo Penno (repenno)" To: Michael Richardson , "v6ops@ietf.org" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAAkCoAAAB6fzgP//zuwA Date: Wed, 5 Jun 2013 16:27:59 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A0A82@xmb-rcd-x04.cisco.com> In-Reply-To: <20115.1370449415@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.243.252] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Softwires-wg list \(softwires@ietf.org\)" , "Poscic, Kristian \(Kristian\)" , "behave@ietf.org" , "Erik Kline \(ek@google.com\)" , "Rajiv Asati \(rajiva\)" Subject: Re: [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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: Wed, 05 Jun 2013 16:28:06 -0000 On 6/5/13 1:23 PM, "Michael Richardson" wrote: > >>>>>> "repenno" =3D=3D repenno writes: > repenno> On the other hand, as Rajiv captured,the number of > repenno> UDP sessions can be much larger than the number of > repenno> TCP. Because the way > repenno> dynamic webpages are constructed today, there are sometimes > repenno> literally 100s > repenno> of DNS requests to download a single page. > >If one is doing CGN, wouldn't it be reasonable to point customers' at >a recursive DNS server with an interface inside the CGN? Yes. That's what I suggest. But some people use, say, Google's DNS/OpenDns/etc and in some other cases the network is not setup correctly. > >This seems to also suggest that having a *caching* recursive DNS(SEC, >HOMENET+, mDNS+) server inside the customer router is also a big win. Yes, it is. > >--=20 >] Never tell me the odds! | ipv6 mesh >networks [=20 >] Michael Richardson, Sandelman Software Works | network >architect [=20 >] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails > [=20 >=09 From kaname@nttv6.jp Wed Jun 5 11:16:22 2013 Return-Path: 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 133B621F9B3F; Wed, 5 Jun 2013 11:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.11 X-Spam-Level: * X-Spam-Status: No, score=1.11 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6] 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 DZvU-ToUZH5O; Wed, 5 Jun 2013 11:16:17 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.148]) by ietfa.amsl.com (Postfix) with ESMTP id BAE5221F9B09; Wed, 5 Jun 2013 11:16:17 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:208::212]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 3F00FBDC21; Thu, 6 Jun 2013 03:15:59 +0900 (JST) Received: from [IPv6:::1] (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id C1D9DE1E27; Thu, 6 Jun 2013 03:15:58 +0900 (JST) Message-ID: <51AF805D.4000101@nttv6.jp> Date: Thu, 06 Jun 2013 03:15:57 +0900 From: kaname nishizuka User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Reinaldo Penno (repenno)" References: <45A697A8FFD7CF48BCF2BE7E106F0604090A0A82@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090A0A82@xmb-rcd-x04.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "behave@ietf.org" , "Poscic, Kristian \(Kristian\)" , "Softwires-wg list \(softwires@ietf.org\)" , "Erik Kline \(ek@google.com\)" , "Rajiv Asati \(rajiva\)" Subject: Re: [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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: Wed, 05 Jun 2013 18:16:22 -0000 With regard to the DNS packets, shortening the time-out of NAT table is another good solution. In larger environment, we tested that when the time-out of DNS was shortened to 3sec, the impact of such DNS requests was much smaller than TCP sessions. 3 sec is sufficient round-trip time in general situation. I don't think it's necessary to place a recursive DNS server inside the CGN. Though there are differences between Home NAPT44 and CGN, it will work well in both case. That is because there are many devices in home and those seldom access the web site within a short time simultaneously. regards, -- kaname (2013/06/06 1:27), Reinaldo Penno (repenno) wrote: > > On 6/5/13 1:23 PM, "Michael Richardson" wrote: > >>>>>>> "repenno" == repenno writes: >> repenno> On the other hand, as Rajiv captured,the number of >> repenno> UDP sessions can be much larger than the number of >> repenno> TCP. Because the way >> repenno> dynamic webpages are constructed today, there are sometimes >> repenno> literally 100s >> repenno> of DNS requests to download a single page. >> >> If one is doing CGN, wouldn't it be reasonable to point customers' at >> a recursive DNS server with an interface inside the CGN? > Yes. That's what I suggest. But some people use, say, Google's > DNS/OpenDns/etc and in some other cases the network is not setup correctly. > >> This seems to also suggest that having a *caching* recursive DNS(SEC, >> HOMENET+, mDNS+) server inside the customer router is also a big win. > Yes, it is. > >> -- >> ] Never tell me the odds! | ipv6 mesh >> networks [ >> ] Michael Richardson, Sandelman Software Works | network >> architect [ >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails >> [ >> > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- ---- Kaname Nishizuka Innovative Architecture Center NTT Communications Corporation +81-50-3812-4704 From rajiva@cisco.com Wed Jun 5 11:45:56 2013 Return-Path: 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 07D6621F9AA6; Wed, 5 Jun 2013 11:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ahPZqpGqqQ2n; Wed, 5 Jun 2013 11:45:51 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id B9F4721F99ED; Wed, 5 Jun 2013 11:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3077; q=dns/txt; s=iport; t=1370457948; x=1371667548; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=f5rug0kOETDeusEAiTCgIlRdRwbJjquFc+mpkHtKPCs=; b=GNVp3JFSu17BhPOp4oYnlZQGowSNnvT+lYD+Ars5789HeGInYYUszqoB q+b6ClM8lAh4Oww2h1M03X4gsicaBm5tK6dTTN1TdAOzF6hIJb371GtM7 8XKR4+DxSDF4yQC6bvimxWlYq2WD0T7lBFDuLHBSHcVUzbuzG+wfc31MX A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAP6Gr1GtJXG+/2dsb2JhbABaFoJzML8xfxZ0giMBAQEDAQEBATc0CwUHBAIBCBEEAQELFAkHJwsUCQgBAQQBDQUIAYd+Bgy9T456MQcGgnRhA6NfhSCDD4In X-IronPort-AV: E=Sophos;i="4.87,809,1363132800"; d="scan'208";a="216261513" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 05 Jun 2013 18:45:48 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r55Ijlrg014015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 18:45:47 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 13:45:47 -0500 From: "Rajiv Asati (rajiva)" To: "Poscic, Kristian (Kristian)" , "v6ops@ietf.org" , "Softwires-wg list (softwires@ietf.org)" , "behave@ietf.org" Thread-Topic: Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAArsfrA= Date: Wed, 5 Jun 2013 18:45:46 +0000 Message-ID: References: <7921F977B17D5B49B8DCC955A339D2F02AB3A800@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F02AB3A800@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Erik Kline \(ek@google.com\)" Subject: Re: [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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: Wed, 05 Jun 2013 18:45:56 -0000 Kristian,=20 > Thanks. Can you tell us in general what applications did you use for this= ? > This heavily depends on the application type in use...p2p apps, etc. Sinc= e > some apps spawn a large number of TCP ports for example. In my home, it is 99% web applications - predominant being OTT video consum= ption (besides SSL VPN for work). Wrt p2p, we aggressively use p2p telepho= ny (e.g. vonage, skype, facetime). > So the question is to what degree do you think is your sample > representative of a general user in any region? It is quite subjective to answer, but I think that it represents a reasonab= le chunk of the home internet usage around the world. Cheers, Rajiv > -----Original Message----- > From: Poscic, Kristian (Kristian) [mailto:kristian.poscic@alcatel-lucent.= com] > Sent: Wednesday, June 05, 2013 9:33 AM > To: Rajiv Asati (rajiva); v6ops@ietf.org; Softwires-wg list > (softwires@ietf.org); behave@ietf.org > Cc: Erik Kline (ek@google.com) > Subject: RE: Home NAPT44 - How many ports? >=20 > Thanks. Can you tell us in general what applications did you use for this= ? > This heavily depends on the application type in use...p2p apps, etc. Sinc= e > some apps spawn a large number of TCP ports for example. >=20 > So the question is to what degree do you think is your sample > representative of a general user in any region? >=20 > For example does it cover 30% of users for an ISP in NA while it covers 8= 0% > of users for another ISP in APAC for example? >=20 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Rajiv Asati (rajiva) > Sent: Wednesday, June 05, 2013 6:14 AM > To: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); behave@ietf.o= rg > Cc: Erik Kline (ek@google.com) > Subject: [BEHAVE] Home NAPT44 - How many ports? >=20 > Some of you may recall our discussion (during the last IETF) around "how > many TCP/UDP ports are enough with NAPT44" per home, as ISPs move into > A+P paradigm. ~500, ~1000, ~3000??? >=20 > Well, I started monitoring my home router and plotting the NAPT44 port > utilization on a minute-by-minute basis. You may find it here - > http://www.employees.org/~rajiva >=20 > In short, port range of 500 seems ok, though 1000 would be more than > enough for my home. Suffice to say, this is just a sample representation, > since the port utilization would vary home to home, based on number of > active devices, type of applications, the degree of simultaneous device o= r > application usage etc. >=20 > If any of you are doing similar monitoring, then please share. >=20 > Cheers, > Rajiv >=20 > PS: Thanks to Erik Kline, who explained (with sufficient details) how to = use > google charting for my data. And thanks to Xun Wang & Shaoshuai Dai for > helping me out significantly. >=20 > PS: My home has 3-4 active devices. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From rajiva@cisco.com Wed Jun 5 11:51:50 2013 Return-Path: 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 AA89521F9BCF; Wed, 5 Jun 2013 11:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8] 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 lf18YyCgu1Ji; Wed, 5 Jun 2013 11:51:45 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1B821F9BC9; Wed, 5 Jun 2013 11:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3724; q=dns/txt; s=iport; t=1370458305; x=1371667905; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tOuNyimLohr8bAWf69RssZO9QB8zWwDSRLTaDlxJPpc=; b=BMToZLHFACDLOTGjeb7ecCyb+HM/DdbicEgQdf86IlY4PZ6tSOafjIiB jR+N9IxPCEpaBJxobEueYqqpYUKyC8nnK0xbt/oPOkh6nEM/0ClSQSbjS D9zcP1ULh4sN5uf7uTKY4afj2PUMJAMaY09ufz3MTV3jeanQPX7oEf65E I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAMCHr1GtJV2b/2dsb2JhbABaFoJzML8xfxZ0giMBAQEEAQEBNzQLDAQCAQgRBAEBAQoUCQcnCxQJCAEBBAENBQgBiAQMvVCNaoEQMQcGgnRhA6NfhSCDD4FpPg X-IronPort-AV: E=Sophos;i="4.87,809,1363132800"; d="scan'208";a="219039825" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 05 Jun 2013 18:51:36 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r55Ipa5R022335 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 18:51:36 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 13:51:36 -0500 From: "Rajiv Asati (rajiva)" To: "Reinaldo Penno (repenno)" , "Poscic, Kristian (Kristian)" , "v6ops@ietf.org" , "Softwires-wg list (softwires@ietf.org)" , "behave@ietf.org" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAAkCoAAAAicnkA== Date: Wed, 5 Jun 2013 18:51:35 +0000 Message-ID: References: <7921F977B17D5B49B8DCC955A339D2F02AB3A800@US70UWXCHMBA05.zam.alcatel-lucent.com> <45A697A8FFD7CF48BCF2BE7E106F0604090A0972@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090A0972@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Erik Kline \(ek@google.com\)" Subject: Re: [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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: Wed, 05 Jun 2013 18:51:50 -0000 Reinaldo, I agree with you. Until I enabled DNS proxy on my router, I noticed that UD= P NAT exceeded TCP NAT entries in few occasions. Since DNS proxy got enable= d, UDP NAT entries became negligible. One interesting observation is how the lowest number of TCP NAT entries sta= yed within the range throughout the night time (when the devices were not m= anually used) based on how many apps (on the smartphones) were left running= . For ex, ~200 TCP ports on April 13-14, or ~30 TCP ports June 4. Cheers, Rajiv > -----Original Message----- > From: Reinaldo Penno (repenno) > Sent: Wednesday, June 05, 2013 11:44 AM > To: Poscic, Kristian (Kristian); Rajiv Asati (rajiva); v6ops@ietf.org; So= ftwires- > wg list (softwires@ietf.org); behave@ietf.org > Cc: Erik Kline (ek@google.com) > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >=20 > Yes, there are regional differences. But even then, in general, 90% of th= e > active users can be covered by 1000 ports. I have been collecting data fo= r > many years, and actually the number of TCP ports consumed have been > going Down due to a number of factors. >=20 > On the other hand, as Rajiv captured,the number of UDP sessions can be > much larger than the number of TCP. Because the way dynamic webpages > are constructed today, there are sometimes literally 100s of DNS requests= to > download a single page. >=20 >=20 >=20 > On 6/5/13 10:32 AM, "Poscic, Kristian (Kristian)" > wrote: >=20 > >Thanks. Can you tell us in general what applications did you use for thi= s? > >This heavily depends on the application type in use...p2p apps, etc. > >Since some apps spawn a large number of TCP ports for example. > > > >So the question is to what degree do you think is your sample > >representative of a general user in any region? > > > >For example does it cover 30% of users for an ISP in NA while it covers > >80% of users for another ISP in APAC for example? > > > >-----Original Message----- > >From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > >Behalf Of Rajiv Asati (rajiva) > >Sent: Wednesday, June 05, 2013 6:14 AM > >To: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); > >behave@ietf.org > >Cc: Erik Kline (ek@google.com) > >Subject: [BEHAVE] Home NAPT44 - How many ports? > > > >Some of you may recall our discussion (during the last IETF) around > >"how many TCP/UDP ports are enough with NAPT44" per home, as ISPs > move > >into > >A+P paradigm. ~500, ~1000, ~3000??? > > > >Well, I started monitoring my home router and plotting the NAPT44 port > >utilization on a minute-by-minute basis. You may find it here - > >http://www.employees.org/~rajiva > > > >In short, port range of 500 seems ok, though 1000 would be more than > >enough for my home. Suffice to say, this is just a sample > >representation, since the port utilization would vary home to home, > >based on number of active devices, type of applications, the degree of > >simultaneous device or application usage etc. > > > >If any of you are doing similar monitoring, then please share. > > > >Cheers, > >Rajiv > > > >PS: Thanks to Erik Kline, who explained (with sufficient details) how > >to use google charting for my data. And thanks to Xun Wang & Shaoshuai > >Dai for helping me out significantly. > > > >PS: My home has 3-4 active devices. > >_______________________________________________ > >Behave mailing list > >Behave@ietf.org > >https://www.ietf.org/mailman/listinfo/behave > >_______________________________________________ > >Behave mailing list > >Behave@ietf.org > >https://www.ietf.org/mailman/listinfo/behave From rajiva@cisco.com Wed Jun 5 11:58:05 2013 Return-Path: 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 6579221F9B84; Wed, 5 Jun 2013 11:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8] 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 l9ST4iSDB90E; Wed, 5 Jun 2013 11:58:00 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B179121F9C14; Wed, 5 Jun 2013 11:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2526; q=dns/txt; s=iport; t=1370458627; x=1371668227; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=z7dErHKNz1kXk0WbYia6JgrHEdbkA7ClmZ6RunDjO2M=; b=EpbTkqSyabqfOCwLsd4z/kUh0yC+nT59MPRBBiR2z7kVguusLy8YGEi4 izyHyfiiaKOvK+Hs1Yx1U7PjQHaCA5/8f3+1i2bi/BeeyaoKlsRy5FulE bIwue49tGUOADatpS0zyti4jhfR2TtIGK+hEbE78850Gitu2iv3l392n/ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAO2Ir1GtJV2c/2dsb2JhbABagwkwvzF/FnSCIwEBAQQ6PwwEAgEIEQQBAQEKFBAyHQgBAQQBDQUIFodvvVqOegYrBwaCdGEDqH+DD4In X-IronPort-AV: E=Sophos;i="4.87,809,1363132800"; d="scan'208";a="219244957" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 05 Jun 2013 18:57:06 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r55Iv6s0024229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 18:57:06 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 13:57:05 -0500 From: "Rajiv Asati (rajiva)" To: "Reinaldo Penno (repenno)" , Michael Richardson , "v6ops@ietf.org" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAAkCoAAAB6fzgP//zuwA///5RqA= Date: Wed, 5 Jun 2013 18:57:05 +0000 Message-ID: References: <20115.1370449415@sandelman.ca> <45A697A8FFD7CF48BCF2BE7E106F0604090A0A82@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090A0A82@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Softwires-wg list \(softwires@ietf.org\)" , "Poscic, Kristian \(Kristian\)" , "behave@ietf.org" , "Erik Kline \(ek@google.com\)" Subject: Re: [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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: Wed, 05 Jun 2013 18:58:05 -0000 > >If one is doing CGN, wouldn't it be reasonable to point customers' at a > >recursive DNS server with an interface inside the CGN? >=20 > Yes. That's what I suggest. But some people use, say, Google's > DNS/OpenDns/etc and in some other cases the network is not setup > correctly. And in some cases, it is not possible depending on where the NAT function i= s placed and where the DNS server is placed. I recently ran into this in a = large mobile network design.=20 Nonetheless, it is desired, but it is not really a big deal, since UDP NAT = usage tends to be a lot less than that TCP NAT usage (barring few exception= s). > >This seems to also suggest that having a *caching* recursive DNS(SEC, > >HOMENET+, mDNS+) server inside the customer router is also a big win. >=20 > Yes, it is. Well, DNS resolver with or without proxy is a big win, I would say.=20 Cheers, Rajiv > -----Original Message----- > From: Reinaldo Penno (repenno) > Sent: Wednesday, June 05, 2013 12:28 PM > To: Michael Richardson; v6ops@ietf.org > Cc: Poscic, Kristian (Kristian); Rajiv Asati (rajiva); Softwires-wg list > (softwires@ietf.org); behave@ietf.org; Erik Kline (ek@google.com) > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >=20 >=20 >=20 > On 6/5/13 1:23 PM, "Michael Richardson" wrote: >=20 > > > >>>>>> "repenno" =3D=3D repenno writes: > > repenno> On the other hand, as Rajiv captured,the number of > > repenno> UDP sessions can be much larger than the number of > > repenno> TCP. Because the way > > repenno> dynamic webpages are constructed today, there are > sometimes > > repenno> literally 100s > > repenno> of DNS requests to download a single page. > > > >If one is doing CGN, wouldn't it be reasonable to point customers' at a > >recursive DNS server with an interface inside the CGN? >=20 > Yes. That's what I suggest. But some people use, say, Google's > DNS/OpenDns/etc and in some other cases the network is not setup > correctly. >=20 > > > >This seems to also suggest that having a *caching* recursive DNS(SEC, > >HOMENET+, mDNS+) server inside the customer router is also a big win. >=20 > Yes, it is. >=20 > > > >-- > >] Never tell me the odds! | ipv6 mesh > >networks [ > >] Michael Richardson, Sandelman Software Works | network > >architect [ > >] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rail= s > > [ > > From rajiva@cisco.com Wed Jun 5 12:05:23 2013 Return-Path: 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 69CB521F8F4A; Wed, 5 Jun 2013 12:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 4Z2FD7NPuYv0; Wed, 5 Jun 2013 12:05:18 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id BBF6521F9C3D; Wed, 5 Jun 2013 12:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1754; q=dns/txt; s=iport; t=1370459010; x=1371668610; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=y58flFdw94Td7kMJ2B/nZ4ah0aqCovmOUxMFBxA5T+0=; b=SKZelwNloob1RIqjCrLYYIcflwuRaac7/UD1Hnw9989XP3hpIu7fMs+C mBHD0J5CVVzwkfB/3IeNLkUeSyt5RpMqrtBuYF0sg7Z33BZo5KDDf0yXa MJmm5u6I6Gvh4eu3DgQc4yeqLJQQcLL7+JBU/xW2/1Gm8+pxgZv8Vjeln k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAHiKr1GtJXHB/2dsb2JhbABagwkwvzZ/FnSCIwEBAQQ6PwwEAgEIEQQBAQsUCQcyFAkIAQEEDgUIiAW9Xo56BisHBoJ0YQOof4MPgic X-IronPort-AV: E=Sophos;i="4.87,809,1363132800"; d="scan'208";a="216270443" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 05 Jun 2013 19:03:28 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r55J3Sjw030404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 19:03:28 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 14:03:28 -0500 From: "Rajiv Asati (rajiva)" To: Michael Richardson Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAMUx6AAAA8pzA= Date: Wed, 5 Jun 2013 19:03:27 +0000 Message-ID: References: <24499.1370440297@sandelman.ca> In-Reply-To: <24499.1370440297@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Softwires-wg list \(softwires@ietf.org\)" , "Erik Kline \(ek@google.com\)" , "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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: Wed, 05 Jun 2013 19:05:24 -0000 Hi Michael, Total 8 computing devices. Usually 2-4 active devices. My ISP is yet to enable IPv6 in my location, and I have purposely disabled = HE IPv6 to collect my IPv4 NAT data of this round, before enabling my HE IP= v6 to contrast the IPv4 NAT usage. Host based IPSec VPN or SSL VPN on one device.=20 A lots of Vonage & Skype & FT usage. Predominantly OTT video consumption. Cheers, Rajiv > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Michael Richardson > Sent: Wednesday, June 05, 2013 9:52 AM > To: Rajiv Asati (rajiva) > Cc: Softwires-wg list (softwires@ietf.org); Erik Kline (ek@google.com); > v6ops@ietf.org; behave@ietf.org > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >=20 >=20 > >>>>> "rajiva" =3D=3D rajiva writes: > rajiva> In short, port range of 500 seems ok, though 1000 would be > rajiva> more than enough for my home. Suffice to say, this is just a > rajiva> sample representation, since the port utilization would vary > rajiva> home to home, based on number of active devices, type of > rajiva> applications, the degree of simultaneous device or > rajiva> application usage etc. >=20 > You are a home of how many computers? How many active people? > (I don't assume those are 1:1...) > I guess you have no IPv6 running? > SIP? Skype? VPN (what kind? does it terminate on a desktop, or on your > "router"?) >=20 > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | network archite= ct [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ >=20 From rajiva@cisco.com Wed Jun 5 12:07:05 2013 Return-Path: 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 6AE2121F9691; Wed, 5 Jun 2013 12:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.849 X-Spam-Level: X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8] 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 ntWVzFDX7n0N; Wed, 5 Jun 2013 12:06:59 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B721121F918C; Wed, 5 Jun 2013 12:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2860; q=dns/txt; s=iport; t=1370459109; x=1371668709; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2GshIMoSvnWIY4eCNh2XLvAdjstYt3mbx9PeWg9Ijk4=; b=mw7aEgHHwxtpeRgshM2GZW7Ta4GB/Yb1TbCqgU49zXpacIBfV0xPjoMm fXz4GQPgCCaQbYoD8fi4HXHaJ5AxR38YAYYCgZ6UlmgZ9R+mj5E1w0XvN 8OUm1YcsJBhRaku9KyKxii3JLZd+PgspVfPgqn5S4nk5eYE7aFvWdEWhO c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAFaLr1GtJXG+/2dsb2JhbABagwkwvzh/FnSCIwEBAQQBAQE3NAsMBAIBCBEBAwEBAQoUCQcnCxQDBggCBAENBQgTA4dvDL1SjnoGKwcGgnRhA6h/gw+CJw X-IronPort-AV: E=Sophos;i="4.87,809,1363132800"; d="scan'208";a="219046649" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 05 Jun 2013 19:04:44 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r55J4iqv030246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 19:04:44 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 14:04:44 -0500 From: "Rajiv Asati (rajiva)" To: kaname nishizuka , "Reinaldo Penno (repenno)" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAAkCoAAAB6fzgP//zuwAgABQeYCAAEZ/gA== Date: Wed, 5 Jun 2013 19:04:43 +0000 Message-ID: References: <45A697A8FFD7CF48BCF2BE7E106F0604090A0A82@xmb-rcd-x04.cisco.com> <51AF805D.4000101@nttv6.jp> In-Reply-To: <51AF805D.4000101@nttv6.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "behave@ietf.org" , "Poscic, Kristian \(Kristian\)" , "Softwires-wg list \(softwires@ietf.org\)" , "Erik Kline \(ek@google.com\)" Subject: Re: [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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: Wed, 05 Jun 2013 19:07:05 -0000 Kaname-san, That's a good suggestion, though the captured data suggests that UDP NAT ex= haustion is not a problem, but TCP NAT is. Cheers, Rajiv > -----Original Message----- > From: kaname nishizuka [mailto:kaname@nttv6.jp] > Sent: Wednesday, June 05, 2013 2:16 PM > To: Reinaldo Penno (repenno) > Cc: Michael Richardson; v6ops@ietf.org; Softwires-wg list > (softwires@ietf.org); Poscic, Kristian (Kristian); behave@ietf.org; Erik = Kline > (ek@google.com); Rajiv Asati (rajiva) > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >=20 >=20 > With regard to the DNS packets, shortening the time-out of NAT table is > another good solution. >=20 > In larger environment, we tested that when the time-out of DNS was > shortened to 3sec, the impact of such DNS requests was much smaller than > TCP sessions. > 3 sec is sufficient round-trip time in general situation. > I don't think it's necessary to place a recursive DNS server inside the C= GN. >=20 > Though there are differences between Home NAPT44 and CGN, it will work > well in both case. > That is because there are many devices in home and those seldom access > the web site within a short time simultaneously. >=20 > regards, > -- > kaname >=20 > (2013/06/06 1:27), Reinaldo Penno (repenno) wrote: > > > > On 6/5/13 1:23 PM, "Michael Richardson" > wrote: > > > >>>>>>> "repenno" =3D=3D repenno writes: > >> repenno> On the other hand, as Rajiv captured,the number of > >> repenno> UDP sessions can be much larger than the number of > >> repenno> TCP. Because the way > >> repenno> dynamic webpages are constructed today, there are > sometimes > >> repenno> literally 100s > >> repenno> of DNS requests to download a single page. > >> > >> If one is doing CGN, wouldn't it be reasonable to point customers' at > >> a recursive DNS server with an interface inside the CGN? > > Yes. That's what I suggest. But some people use, say, Google's > > DNS/OpenDns/etc and in some other cases the network is not setup > correctly. > > > >> This seems to also suggest that having a *caching* recursive DNS(SEC, > >> HOMENET+, mDNS+) server inside the customer router is also a big win. > > Yes, it is. > > > >> -- > >> ] Never tell me the odds! | ipv6 mesh > >> networks [ > >> ] Michael Richardson, Sandelman Software Works | network > >> architect [ > >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on ra= ils > >> [ > >> > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave >=20 >=20 > -- > ---- > Kaname Nishizuka > Innovative Architecture Center > NTT Communications Corporation > +81-50-3812-4704 From repenno@cisco.com Wed Jun 5 12:25:25 2013 Return-Path: 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 A581321F9AB8; Wed, 5 Jun 2013 12:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8] 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 XPoEmxseDO5A; Wed, 5 Jun 2013 12:25:19 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id ABC1321F8808; Wed, 5 Jun 2013 12:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4081; q=dns/txt; s=iport; t=1370460318; x=1371669918; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=b49WIL1Ep8qYdWlzth5PaJxUt/8WbzvqgibUvQOx73U=; b=dXje9RVTCeJK/Qu8GtSScltvBceLjH+GlEr1NubhVrOeu1xjEOOkVsp0 AnHsFKgTEGXU7T4CjZwRIwoxoOuv4ZYOBJpiVtaxpsdv9OuzyNk3gdVgo nw2tfIswffxaOJ7tzPVIip6/N6gadGXFJqMbWh25S2WvY8MMZmnF/qFvU 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMNAHiPr1GtJV2Z/2dsb2JhbABaFoFbCIEQML8/fxZ0giMBAQEEAQEBNzQLDAYBCBEEAQEBChQJLgsUCQgBAQQBDQUIAYgEDL1SjWoPgQExBwaCdGEDo1+FIIMPgWkIFx8 X-IronPort-AV: E=Sophos;i="4.87,809,1363132800"; d="scan'208";a="219224168" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 05 Jun 2013 19:25:18 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r55JPIEP026188 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 19:25:18 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 14:25:17 -0500 From: "Reinaldo Penno (repenno)" To: "Rajiv Asati (rajiva)" , "Poscic, Kristian (Kristian)" , "v6ops@ietf.org" , "Softwires-wg list (softwires@ietf.org)" , "behave@ietf.org" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAAkCoAAAAicnkAAFj40A Date: Wed, 5 Jun 2013 19:25:16 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A0B86@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.243.252] Content-Type: text/plain; charset="us-ascii" Content-ID: <7D2E7946FC55804CBDC577E1BBCD5C62@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Erik Kline \(ek@google.com\)" Subject: Re: [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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: Wed, 05 Jun 2013 19:25:25 -0000 that's right. Depending on how much stuff you have running there might be long term TCP connections to mail servers, IM servers, Etc. With the 'connected home' I'm assuming this will go up. On 6/5/13 3:51 PM, "Rajiv Asati (rajiva)" wrote: >Reinaldo, > >I agree with you. Until I enabled DNS proxy on my router, I noticed that >UDP NAT exceeded TCP NAT entries in few occasions. Since DNS proxy got >enabled, UDP NAT entries became negligible. > >One interesting observation is how the lowest number of TCP NAT entries >stayed within the range throughout the night time (when the devices were >not manually used) based on how many apps (on the smartphones) were left >running. For ex, ~200 TCP ports on April 13-14, or ~30 TCP ports June 4. > >Cheers, >Rajiv > > >> -----Original Message----- >> From: Reinaldo Penno (repenno) >> Sent: Wednesday, June 05, 2013 11:44 AM >> To: Poscic, Kristian (Kristian); Rajiv Asati (rajiva); v6ops@ietf.org; >>Softwires- >> wg list (softwires@ietf.org); behave@ietf.org >> Cc: Erik Kline (ek@google.com) >> Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >>=20 >> Yes, there are regional differences. But even then, in general, 90% of >>the >> active users can be covered by 1000 ports. I have been collecting data >>for >> many years, and actually the number of TCP ports consumed have been >> going Down due to a number of factors. >>=20 >> On the other hand, as Rajiv captured,the number of UDP sessions can be >> much larger than the number of TCP. Because the way dynamic webpages >> are constructed today, there are sometimes literally 100s of DNS >>requests to >> download a single page. >>=20 >>=20 >>=20 >> On 6/5/13 10:32 AM, "Poscic, Kristian (Kristian)" >> wrote: >>=20 >> >Thanks. Can you tell us in general what applications did you use for >>this? >> >This heavily depends on the application type in use...p2p apps, etc. >> >Since some apps spawn a large number of TCP ports for example. >> > >> >So the question is to what degree do you think is your sample >> >representative of a general user in any region? >> > >> >For example does it cover 30% of users for an ISP in NA while it covers >> >80% of users for another ISP in APAC for example? >> > >> >-----Original Message----- >> >From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> >Behalf Of Rajiv Asati (rajiva) >> >Sent: Wednesday, June 05, 2013 6:14 AM >> >To: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); >> >behave@ietf.org >> >Cc: Erik Kline (ek@google.com) >> >Subject: [BEHAVE] Home NAPT44 - How many ports? >> > >> >Some of you may recall our discussion (during the last IETF) around >> >"how many TCP/UDP ports are enough with NAPT44" per home, as ISPs >> move >> >into >> >A+P paradigm. ~500, ~1000, ~3000??? >> > >> >Well, I started monitoring my home router and plotting the NAPT44 port >> >utilization on a minute-by-minute basis. You may find it here - >> >http://www.employees.org/~rajiva >> > >> >In short, port range of 500 seems ok, though 1000 would be more than >> >enough for my home. Suffice to say, this is just a sample >> >representation, since the port utilization would vary home to home, >> >based on number of active devices, type of applications, the degree of >> >simultaneous device or application usage etc. >> > >> >If any of you are doing similar monitoring, then please share. >> > >> >Cheers, >> >Rajiv >> > >> >PS: Thanks to Erik Kline, who explained (with sufficient details) how >> >to use google charting for my data. And thanks to Xun Wang & Shaoshuai >> >Dai for helping me out significantly. >> > >> >PS: My home has 3-4 active devices. >> >_______________________________________________ >> >Behave mailing list >> >Behave@ietf.org >> >https://www.ietf.org/mailman/listinfo/behave >> >_______________________________________________ >> >Behave mailing list >> >Behave@ietf.org >> >https://www.ietf.org/mailman/listinfo/behave > From repenno@cisco.com Wed Jun 5 12:39:57 2013 Return-Path: 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 56A4C21F8CB5; Wed, 5 Jun 2013 12:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.699 X-Spam-Level: X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8] 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 jbPH-mz39LQo; Wed, 5 Jun 2013 12:39:52 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1FF21F84DF; Wed, 5 Jun 2013 12:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2825; q=dns/txt; s=iport; t=1370460459; x=1371670059; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/veQ6r28SRLWB37Ehd5E90SCc7kT+NUcWnvDVnnVIYo=; b=Tm3fL+iCeJpTlIYbkIy84+3JrGig+kKhVD6Qb6/iOmgyw5QBLrWbLO5g Bt95LtKcgQ4M9ho2nfwumZNXKlBtjsoBSiiNgRzffmsbCXW0yxrLWn5am 5z7zb0jDN/3G+Vvt7eHXvUuLusucM0KSEPhQ5uNtrpeoEuBVS+8zzkqmz o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4NAPGPr1GtJV2c/2dsb2JhbABagXEIgRAwvz9/FnSCIwEBAQQ6PwwGAQgRBAEBAQoUQh0IAgQBDQUIFodvvVuOegYrBwaCdGEDqH+DD4In X-IronPort-AV: E=Sophos;i="4.87,809,1363132800"; d="scan'208";a="216280288" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 05 Jun 2013 19:27:38 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r55JRcTf016095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 19:27:38 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 14:27:38 -0500 From: "Reinaldo Penno (repenno)" To: "Rajiv Asati (rajiva)" , Michael Richardson , "v6ops@ietf.org" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAAkCoAAAB6fzgP//zuwA///5RqCAADjsgA== Date: Wed, 5 Jun 2013 19:27:38 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A0BA6@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.243.252] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Softwires-wg list \(softwires@ietf.org\)" , "Poscic, Kristian \(Kristian\)" , "behave@ietf.org" , "Erik Kline \(ek@google.com\)" Subject: Re: [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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: Wed, 05 Jun 2013 19:39:57 -0000 There are some interesting measurements on this "background TCP radiation", i.e., how much state (and bandwidth) a home consumes even when there is no active use. On 6/5/13 3:57 PM, "Rajiv Asati (rajiva)" wrote: >> >If one is doing CGN, wouldn't it be reasonable to point customers' at a >> >recursive DNS server with an interface inside the CGN? >>=20 >> Yes. That's what I suggest. But some people use, say, Google's >> DNS/OpenDns/etc and in some other cases the network is not setup >> correctly. > >And in some cases, it is not possible depending on where the NAT function >is placed and where the DNS server is placed. I recently ran into this in >a large mobile network design. > >Nonetheless, it is desired, but it is not really a big deal, since UDP >NAT usage tends to be a lot less than that TCP NAT usage (barring few >exceptions). > >> >This seems to also suggest that having a *caching* recursive DNS(SEC, >> >HOMENET+, mDNS+) server inside the customer router is also a big win. >>=20 >> Yes, it is. > >Well, DNS resolver with or without proxy is a big win, I would say. > > >Cheers, >Rajiv > > >> -----Original Message----- >> From: Reinaldo Penno (repenno) >> Sent: Wednesday, June 05, 2013 12:28 PM >> To: Michael Richardson; v6ops@ietf.org >> Cc: Poscic, Kristian (Kristian); Rajiv Asati (rajiva); Softwires-wg list >> (softwires@ietf.org); behave@ietf.org; Erik Kline (ek@google.com) >> Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >>=20 >>=20 >>=20 >> On 6/5/13 1:23 PM, "Michael Richardson" wrote: >>=20 >> > >> >>>>>> "repenno" =3D=3D repenno writes: >> > repenno> On the other hand, as Rajiv captured,the number of >> > repenno> UDP sessions can be much larger than the number of >> > repenno> TCP. Because the way >> > repenno> dynamic webpages are constructed today, there are >> sometimes >> > repenno> literally 100s >> > repenno> of DNS requests to download a single page. >> > >> >If one is doing CGN, wouldn't it be reasonable to point customers' at a >> >recursive DNS server with an interface inside the CGN? >>=20 >> Yes. That's what I suggest. But some people use, say, Google's >> DNS/OpenDns/etc and in some other cases the network is not setup >> correctly. >>=20 >> > >> >This seems to also suggest that having a *caching* recursive DNS(SEC, >> >HOMENET+, mDNS+) server inside the customer router is also a big win. >>=20 >> Yes, it is. >>=20 >> > >> >-- >> >] Never tell me the odds! | ipv6 mesh >> >networks [ >> >] Michael Richardson, Sandelman Software Works | network >> >architect [ >> >] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on >>rails >> > [ >> > > From simon.perreault@viagenie.ca Thu Jun 6 00:29:44 2013 Return-Path: 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 9BE3421F9635 for ; Thu, 6 Jun 2013 00:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 Exr+Xl4oDtTb for ; Thu, 6 Jun 2013 00:29:44 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 482C321F9640 for ; Thu, 6 Jun 2013 00:29:42 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:2905:fce2:6a47:af4e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AFD744149F for ; Thu, 6 Jun 2013 03:29:40 -0400 (EDT) Message-ID: <51B03A65.6040701@viagenie.ca> Date: Thu, 06 Jun 2013 09:29:41 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: behave@ietf.org References: <45A697A8FFD7CF48BCF2BE7E106F0604090A0A82@xmb-rcd-x04.cisco.com> <51AF805D.4000101@nttv6.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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, 06 Jun 2013 07:29:44 -0000 Le 2013-06-05 21:04, Rajiv Asati (rajiva) a écrit : > That's a good suggestion, though the captured data suggests that UDP NAT exhaustion is not a problem, but TCP NAT is. For better TCP scaling, I'd be curious to see how your data set would look like if the NAT used endpoint-dependent mapping with aggressive port overloading for HTTP connections. Since HTTP clients often connect to several different hosts in parallel, multiple connections could share the same source port. And HTTP doesn't need EIM for NAT traversal. Simon From rajiva@cisco.com Thu Jun 6 06:43:48 2013 Return-Path: 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 DBFBC21F9399; Thu, 6 Jun 2013 06:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8] 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 M22Q7ulKIqQf; Thu, 6 Jun 2013 06:43:44 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E965221F9289; Thu, 6 Jun 2013 06:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4774; q=dns/txt; s=iport; t=1370526224; x=1371735824; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=I7M+/qo0hkPXbpmaFC2Uok5tewCDHiLzIZO6NTYB0nE=; b=lu7U40ikxNGjiWJ3yuEWqTeBhtl8XOdftf2Ti+K55Y4qGbQejekcK8Av h29HQu4S203EHwnGyfjuKhW1oLw8z7l6nNnjDvHf9Ia7R3MTgFnBLXulz JyhR5QmES9smx8YJtuWUZrPrJI8qphdPp9DGfjXCtYwJF5WUwMjUd0bb1 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFALaRsFGtJV2a/2dsb2JhbABZFoJzML9HeBZ0giMBAQEEAQEBNzQLDAQCAQgRBAEBAQoUCQcnCxQJCAEBBAENBQgBiAQMuxuNcQ+BATEHBoJ0YQOjX4Uggw+BaQgXHw X-IronPort-AV: E=Sophos;i="4.87,815,1363132800"; d="scan'208";a="219549165" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 06 Jun 2013 13:43:25 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r56DhPwW019104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 13:43:25 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 08:43:25 -0500 From: "Rajiv Asati (rajiva)" To: "Reinaldo Penno (repenno)" , "Poscic, Kristian (Kristian)" , "v6ops@ietf.org" , "Softwires-wg list (softwires@ietf.org)" , "behave@ietf.org" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlAAA9zuwAAkCoAAAAicnkAAFj40AACIhOTA= Date: Thu, 6 Jun 2013 13:43:24 +0000 Message-ID: References: <45A697A8FFD7CF48BCF2BE7E106F0604090A0B86@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090A0B86@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.252.87] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Erik Kline \(ek@google.com\)" Subject: Re: [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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, 06 Jun 2013 13:43:49 -0000 Good point. I agree.=20 And hopefully, most of the connected home would be on IPv6 (and not on IPv4= ) in the next few yrs . :) Cheers, Rajiv > -----Original Message----- > From: Reinaldo Penno (repenno) > Sent: Wednesday, June 05, 2013 3:25 PM > To: Rajiv Asati (rajiva); Poscic, Kristian (Kristian); v6ops@ietf.org; So= ftwires- > wg list (softwires@ietf.org); behave@ietf.org > Cc: Erik Kline (ek@google.com) > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >=20 > that's right. >=20 > Depending on how much stuff you have running there might be long term > TCP connections to mail servers, IM servers, Etc. >=20 > With the 'connected home' I'm assuming this will go up. >=20 >=20 > On 6/5/13 3:51 PM, "Rajiv Asati (rajiva)" wrote: >=20 > >Reinaldo, > > > >I agree with you. Until I enabled DNS proxy on my router, I noticed > >that UDP NAT exceeded TCP NAT entries in few occasions. Since DNS proxy > >got enabled, UDP NAT entries became negligible. > > > >One interesting observation is how the lowest number of TCP NAT entries > >stayed within the range throughout the night time (when the devices > >were not manually used) based on how many apps (on the smartphones) > >were left running. For ex, ~200 TCP ports on April 13-14, or ~30 TCP por= ts > June 4. > > > >Cheers, > >Rajiv > > > > > >> -----Original Message----- > >> From: Reinaldo Penno (repenno) > >> Sent: Wednesday, June 05, 2013 11:44 AM > >> To: Poscic, Kristian (Kristian); Rajiv Asati (rajiva); > >>v6ops@ietf.org; > >>Softwires- > >> wg list (softwires@ietf.org); behave@ietf.org > >> Cc: Erik Kline (ek@google.com) > >> Subject: Re: [BEHAVE] Home NAPT44 - How many ports? > >> > >> Yes, there are regional differences. But even then, in general, 90% > >>of the active users can be covered by 1000 ports. I have been > >>collecting data for many years, and actually the number of TCP ports > >>consumed have been going Down due to a number of factors. > >> > >> On the other hand, as Rajiv captured,the number of UDP sessions can > >>be much larger than the number of TCP. Because the way dynamic > >>webpages are constructed today, there are sometimes literally 100s of > >>DNS requests to download a single page. > >> > >> > >> > >> On 6/5/13 10:32 AM, "Poscic, Kristian (Kristian)" > >> wrote: > >> > >> >Thanks. Can you tell us in general what applications did you use for > >>this? > >> >This heavily depends on the application type in use...p2p apps, etc. > >> >Since some apps spawn a large number of TCP ports for example. > >> > > >> >So the question is to what degree do you think is your sample > >> >representative of a general user in any region? > >> > > >> >For example does it cover 30% of users for an ISP in NA while it > >> >covers 80% of users for another ISP in APAC for example? > >> > > >> >-----Original Message----- > >> >From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > >> >Behalf Of Rajiv Asati (rajiva) > >> >Sent: Wednesday, June 05, 2013 6:14 AM > >> >To: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); > >> >behave@ietf.org > >> >Cc: Erik Kline (ek@google.com) > >> >Subject: [BEHAVE] Home NAPT44 - How many ports? > >> > > >> >Some of you may recall our discussion (during the last IETF) around > >> >"how many TCP/UDP ports are enough with NAPT44" per home, as ISPs > >> move > >> >into > >> >A+P paradigm. ~500, ~1000, ~3000??? > >> > > >> >Well, I started monitoring my home router and plotting the NAPT44 > >> >port utilization on a minute-by-minute basis. You may find it here - > >> >http://www.employees.org/~rajiva > >> > > >> >In short, port range of 500 seems ok, though 1000 would be more than > >> >enough for my home. Suffice to say, this is just a sample > >> >representation, since the port utilization would vary home to home, > >> >based on number of active devices, type of applications, the degree > >> >of simultaneous device or application usage etc. > >> > > >> >If any of you are doing similar monitoring, then please share. > >> > > >> >Cheers, > >> >Rajiv > >> > > >> >PS: Thanks to Erik Kline, who explained (with sufficient details) > >> >how to use google charting for my data. And thanks to Xun Wang & > >> >Shaoshuai Dai for helping me out significantly. > >> > > >> >PS: My home has 3-4 active devices. > >> >_______________________________________________ > >> >Behave mailing list > >> >Behave@ietf.org > >> >https://www.ietf.org/mailman/listinfo/behave > >> >_______________________________________________ > >> >Behave mailing list > >> >Behave@ietf.org > >> >https://www.ietf.org/mailman/listinfo/behave > > From dwing@cisco.com Thu Jun 6 08:43:32 2013 Return-Path: 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 68E2621F9193; Thu, 6 Jun 2013 08:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 MHlk1C0F+5Jy; Thu, 6 Jun 2013 08:43:28 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF1921F972C; Thu, 6 Jun 2013 08:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2007; q=dns/txt; s=iport; t=1370533405; x=1371743005; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=txT9IPcn+l8DqfE0oZMDVqJhfJVx2BH1mJKxEvbLSIE=; b=lyygDkrAFl4bA0SQNTL6HYnUBgKEvW5ZF1FF3A5gC7sRV/dtwcpCiRgB sTNxsQTljsu5r7upKt0kagyiLZS1u8e6QHBwCcYgWPblZzVK/nSyLSeqd rHxoBMJnL0MN1Fi5UwnvWAWgiIlQjXdZ42RIGYhxf7TTm3l5QV2+SakvK 8=; X-IronPort-AV: E=Sophos;i="4.87,816,1363132800"; d="scan'208";a="79874449" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 06 Jun 2013 15:43:24 +0000 Received: from [10.32.240.194] ([10.32.240.194]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r56FhNUd003338; Thu, 6 Jun 2013 15:43:23 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: Date: Thu, 6 Jun 2013 08:43:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Rajiv Asati (rajiva) X-Mailer: Apple Mail (2.1503) Cc: "Softwires-wg list \(softwires@ietf.org\)" , "Erik Kline \(ek@google.com\)" , "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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, 06 Jun 2013 15:43:32 -0000 On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva) = wrote: > Some of you may recall our discussion (during the last IETF) around = "how many TCP/UDP ports are enough with NAPT44" per home, as ISPs move = into A+P paradigm. ~500, ~1000, ~3000??? >=20 > Well, I started monitoring my home router and plotting the NAPT44 port = utilization on a minute-by-minute basis. You may find it here - = http://www.employees.org/~rajiva >=20 > In short, port range of 500 seems ok, though 1000 would be more than = enough for my home. I see several spikes in your data over 500 ports. During those times, = applications would be unable to function (unable to get a port). April = 29/30 is a long time where that occurs very visibly, but there are = shorter spikes elsewhere such as on April 17 and April 18. If you had = only 500 ports on those days, creating a new TCP mapping would have been = impossible, impacting ability to send or receive email, order books from = Amazon.com, and so on. I am surprised you conclude that "500 seems ok" = when such a limit would interfere with your network use on those days. What is the maximum number of mappings supported by your NAPT device? = Some residential-class NATs have a limit of 1024 mappings. -d > Suffice to say, this is just a sample representation, since the port = utilization would vary home to home, based on number of active devices, = type of applications, the degree of simultaneous device or application = usage etc. >=20 > If any of you are doing similar monitoring, then please share. >=20 > Cheers, > Rajiv >=20 > PS: Thanks to Erik Kline, who explained (with sufficient details) how = to use google charting for my data. And thanks to Xun Wang & Shaoshuai = Dai for helping me out significantly. >=20 > PS: My home has 3-4 active devices. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From rajiva@cisco.com Thu Jun 6 15:41:50 2013 Return-Path: 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 EF59521F87B7; Thu, 6 Jun 2013 15:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 oTpdzmuxH9vS; Thu, 6 Jun 2013 15:41:46 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 20D6321F938E; Thu, 6 Jun 2013 15:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3557; q=dns/txt; s=iport; t=1370558506; x=1371768106; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GcRkabjegJdyA/Ic2V/3cSpwUoMxvBhBDzHbf+ZcycY=; b=glr8BFd7oj/hLQsswcCnfytqSRbvLO6cBKUwyxjK3LPgB9E2VwwnFXKx 4Kb/JpjmfSTxupP+eOb4Q74n+3WONPVBmCa8al7e7QbB7eknffhEhan05 q+kH4HW5f/ggwGHafBzmvB1kyLkOSYEc+d9V0ZJtylYWaxiauF0BjtR0T Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAOUOsVGtJV2Z/2dsb2JhbABZFoJzML5wehZ0giMBAQEDAQEBATc0CwUHBAIBCBEEAQEBChQQJwsdCAEBBA4FCAGHfgYMuz+NcAEJAYEGMQcGgnRhA5Ntj3KFIIMPgWgBCBcf X-IronPort-AV: E=Sophos;i="4.87,817,1363132800"; d="scan'208";a="219603490" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 06 Jun 2013 22:41:45 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r56Mfjcd011311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 22:41:45 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 17:41:44 -0500 From: "Rajiv Asati (rajiva)" To: "Dan Wing (dwing)" Thread-Topic: [BEHAVE] Home NAPT44 - How many ports? Thread-Index: Ac5h7Gh9xwUId/SJTdSA920KKgIqlABChP6AAALM1dA= Date: Thu, 6 Jun 2013 22:41:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.252.87] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Softwires-wg list \(softwires@ietf.org\)" , "Erik Kline \(ek@google.com\)" , "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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, 06 Jun 2013 22:41:51 -0000 Hi Dan, > and so on. I am surprised you conclude that "500 seems ok" when such a > limit would interfere with your network use on those days. I based that statement ("...seems ok,") on the very fact that the number of= times the NAT utilization exceeded 500 mappings (equating to 500 ports, in= my setup) in the sample period (~2 months) was relatively quite low. So, i= f the NAT device was limited to only 500 mappings, then the experience woul= d have been ok for 99% of the time and degraded 1% of the time. This is an = important consideration, IMO. For ex, in the last 2 weeks, the number of times NAT mappings exceeded 500 = were: June 3 - 1 time May 29 - 1 time May 28 - 3 times May 26 - 1 time May 23 - 1 time May 22 - 2 times May 21 - 3 times =20 Of course, 1000 ports (resulting in 1000+ mappings) would have been more th= an enough to accommodate the times when the mappings exceeded 500, but stay= ed within 1000 (except once). > What is the maximum number of mappings supported by your NAPT device? > Some residential-class NATs have a limit of 1024 mappings. My NAPT device seemingly can use upto 64K ports. :) Cheers, Rajiv > -----Original Message----- > From: Dan Wing (dwing) > Sent: Thursday, June 06, 2013 11:43 AM > To: Rajiv Asati (rajiva) > Cc: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); > behave@ietf.org; Erik Kline (ek@google.com) > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >=20 >=20 > On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva) wrote= : >=20 > > Some of you may recall our discussion (during the last IETF) around "ho= w > many TCP/UDP ports are enough with NAPT44" per home, as ISPs move into > A+P paradigm. ~500, ~1000, ~3000??? > > > > Well, I started monitoring my home router and plotting the NAPT44 port > utilization on a minute-by-minute basis. You may find it here - > http://www.employees.org/~rajiva > > > > In short, port range of 500 seems ok, though 1000 would be more than > enough for my home. >=20 > I see several spikes in your data over 500 ports. During those times, > applications would be unable to function (unable to get a port). April 2= 9/30 > is a long time where that occurs very visibly, but there are shorter spik= es > elsewhere such as on April 17 and April 18. If you had only 500 ports on > those days, creating a new TCP mapping would have been impossible, > impacting ability to send or receive email, order books from Amazon.com, > and so on. I am surprised you conclude that "500 seems ok" when such a > limit would interfere with your network use on those days. >=20 > What is the maximum number of mappings supported by your NAPT device? > Some residential-class NATs have a limit of 1024 mappings. >=20 > -d >=20 > > Suffice to say, this is just a sample representation, since the port > utilization would vary home to home, based on number of active devices, > type of applications, the degree of simultaneous device or application > usage etc. > > > > If any of you are doing similar monitoring, then please share. > > > > Cheers, > > Rajiv > > > > PS: Thanks to Erik Kline, who explained (with sufficient details) how t= o use > google charting for my data. And thanks to Xun Wang & Shaoshuai Dai for > helping me out significantly. > > > > PS: My home has 3-4 active devices. > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Thu Jun 6 17:19:07 2013 Return-Path: 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 6B2D921F9330; Thu, 6 Jun 2013 17:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 ytJ6g-ZpnowZ; Thu, 6 Jun 2013 17:19:03 -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 4E9F821F92E3; Thu, 6 Jun 2013 17:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12207; q=dns/txt; s=iport; t=1370564343; x=1371773943; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=85pyCK9m8qD2ywdUW+y5g6sX9+TFQ3DBCPnrzptH+SU=; b=A8AUfDdHRFKbm29heChSR/niteStnSa17JVZyXjAXz5H4EsPjsGOaqTh B1yV5Pa9KqVFgfdwWvulzgyhO84kdLs2+Sp3k6BWWQOfe7xXdbG1yiW4d PxpkDHAX9ofYnbNVkjVM8CQYroht7Odrk5hecPb8rZtwZt9Lu6fPbxNWU 4=; X-IronPort-AV: E=Sophos;i="4.87,818,1363132800"; d="scan'208,217";a="82926751" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 07 Jun 2013 00:19:02 +0000 Received: from [10.32.240.194] ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r570J1WU006938; Fri, 7 Jun 2013 00:19:01 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_8697BB8D-B577-4D1B-9B1B-27CA59643FD2" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: Date: Thu, 6 Jun 2013 17:19:01 -0700 Message-Id: References: To: John Mann X-Mailer: Apple Mail (2.1503) Cc: "Softwires-wg list \(softwires@ietf.org\)" , "v6ops@ietf.org" , "behave@ietf.org" , "Rajiv Asati \(rajiva\)" Subject: Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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, 07 Jun 2013 00:19:07 -0000 --Apple-Mail=_8697BB8D-B577-4D1B-9B1B-27CA59643FD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jun 6, 2013, at 5:02 PM, John Mann wrote: > Hi, >=20 > On 7 June 2013 08:41, Rajiv Asati (rajiva) wrote: > Hi Dan, >=20 > > and so on. I am surprised you conclude that "500 seems ok" when = such a > > limit would interfere with your network use on those days. >=20 > I based that statement ("...seems ok,") on the very fact that the = number of times the NAT utilization exceeded 500 mappings (equating to = 500 ports, in my setup) in the sample period (~2 months) was relatively = quite low. So, if the NAT device was limited to only 500 mappings, then = the experience would have been ok for 99% of the time and degraded 1% of = the time. This is an important consideration, IMO. >=20 > For ex, in the last 2 weeks, the number of times NAT mappings exceeded = 500 were: >=20 > June 3 - 1 time > May 29 - 1 time > May 28 - 3 times > May 26 - 1 time > May 23 - 1 time > May 22 - 2 times > May 21 - 3 times >=20 > I think a more-interesting statistic would be "how many connection = setups would have failed". > But I don't think you can measure that just by polling concurrent = connections at specific times. > It might take e.g. netflow exporting and analysis ... >=20 > However "number of concurrent connections that couldn't have been = setup" would be useful in gauging the impact > e.g. on May 29 there was one spike of 734 concurrent connections, then = report that as 234 potential failures. >=20 > Of course, 1000 ports (resulting in 1000+ mappings) would have been = more than enough to accommodate the times when the mappings exceeded = 500, but stayed within 1000 (except once). >=20 >=20 > > What is the maximum number of mappings supported by your NAPT = device? > > Some residential-class NATs have a limit of 1024 mappings. >=20 > Is that a combined limit of TCP and UDP and ICMP, or independent? The study at http://eggert.org/papers/2010-imc-hgw-study.pdf only = analyzed TCP bindings. -d >=20 > My NAPT device seemingly can use upto 64K ports. :) >=20 > Cheers, > Rajiv >=20 >=20 > > -----Original Message----- > > From: Dan Wing (dwing) > > Sent: Thursday, June 06, 2013 11:43 AM > > To: Rajiv Asati (rajiva) > > Cc: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); > > behave@ietf.org; Erik Kline (ek@google.com) > > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? > > > > > > On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva) = wrote: > > > > > Some of you may recall our discussion (during the last IETF) = around "how > > many TCP/UDP ports are enough with NAPT44" per home, as ISPs move = into > > A+P paradigm. ~500, ~1000, ~3000??? > > > > > > Well, I started monitoring my home router and plotting the NAPT44 = port > > utilization on a minute-by-minute basis. You may find it here - > > http://www.employees.org/~rajiva > > > > > > In short, port range of 500 seems ok, though 1000 would be more = than > > enough for my home. > > > > I see several spikes in your data over 500 ports. During those = times, > > applications would be unable to function (unable to get a port). = April 29/30 > > is a long time where that occurs very visibly, but there are shorter = spikes > > elsewhere such as on April 17 and April 18. If you had only 500 = ports on > > those days, creating a new TCP mapping would have been impossible, > > impacting ability to send or receive email, order books from = Amazon.com, > > and so on. I am surprised you conclude that "500 seems ok" when = such a > > limit would interfere with your network use on those days. > > > > What is the maximum number of mappings supported by your NAPT = device? > > Some residential-class NATs have a limit of 1024 mappings. > > > > -d > > > > > Suffice to say, this is just a sample representation, since the = port > > utilization would vary home to home, based on number of active = devices, > > type of applications, the degree of simultaneous device or = application > > usage etc. > > > > > > If any of you are doing similar monitoring, then please share. > > > > > > Cheers, > > > Rajiv > > > > > > PS: Thanks to Erik Kline, who explained (with sufficient details) = how to use > > google charting for my data. And thanks to Xun Wang & Shaoshuai Dai = for > > helping me out significantly. > > > > > > PS: My home has 3-4 active devices. > > > _______________________________________________ > > > Behave mailing list > > > Behave@ietf.org > > > https://www.ietf.org/mailman/listinfo/behave >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --Apple-Mail=_8697BB8D-B577-4D1B-9B1B-27CA59643FD2 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Jun 6, 2013, at 5:02 PM, John Mann <john.mann@monash.edu> wrote:

Hi,

On 7 June 2013 08:41, Rajiv Asati (rajiva) <rajiva@cisco.com> wrote:
Hi Dan,

> and so on.  I am surprised you conclude that "500 seems ok" when such a
> limit would interfere with your network use on those days.

I based that statement ("...seems ok,") on the very fact that the number of times the NAT utilization exceeded 500 mappings (equating to 500 ports, in my setup) in the sample period (~2 months) was relatively quite low. So, if the NAT device was limited to only 500 mappings, then the experience would have been ok for 99% of the time and degraded 1% of the time. This is an important consideration, IMO.

For ex, in the last 2 weeks, the number of times NAT mappings exceeded 500 were:

June 3 - 1 time
May 29 - 1 time
May 28 - 3 times
May 26 - 1 time
May 23 - 1 time
May 22 - 2 times
May 21 - 3 times

I think a more-interesting statistic would be "how many connection setups would have failed".
But I don't think you can measure that just by polling concurrent connections at specific times.
It might take e.g. netflow exporting and analysis ...

However "number of concurrent connections that couldn't have been setup" would be useful in gauging the impact
e.g. on May 29 there was one spike of 734 concurrent connections, then report that as 234 potential failures.

Of course, 1000 ports (resulting in 1000+ mappings) would have been more than enough to accommodate the times when the mappings exceeded 500, but stayed within 1000 (except once).


> What is the maximum number of mappings supported by your NAPT device?
> Some residential-class NATs have a limit of 1024 mappings.

Is that a combined limit of TCP and UDP and ICMP, or independent?

The study at http://eggert.org/papers/2010-imc-hgw-study.pdf only analyzed TCP bindings.

-d



My NAPT device seemingly can use upto 64K ports. :)

Cheers,
Rajiv


> -----Original Message-----
> From: Dan Wing (dwing)
> Sent: Thursday, June 06, 2013 11:43 AM
> To: Rajiv Asati (rajiva)
> Cc: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org);
> behave@ietf.org; Erik Kline (ek@google.com)
> Subject: Re: [BEHAVE] Home NAPT44 - How many ports?
>
>
> On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva) <rajiva@cisco.com> wrote:
>
> > Some of you may recall our discussion (during the last IETF) around "how
> many TCP/UDP ports are enough with NAPT44" per home, as ISPs move into
> A+P paradigm. ~500, ~1000, ~3000???
> >
> > Well, I started monitoring my home router and plotting the NAPT44 port
> utilization on a minute-by-minute basis. You may find it here -
> http://www.employees.org/~rajiva
> >
> > In short, port range of 500 seems ok, though 1000 would be more than
> enough for my home.
>
> I see several spikes in your data over 500 ports.  During those times,
> applications would be unable to function (unable to get a port).  April 29/30
> is a long time where that occurs very visibly, but there are shorter spikes
> elsewhere such as on April 17 and April 18.  If you had only 500 ports on
> those days, creating a new TCP mapping would have been impossible,
> impacting ability to send or receive email, order books from Amazon.com,
> and so on.  I am surprised you conclude that "500 seems ok" when such a
> limit would interfere with your network use on those days.
>
> What is the maximum number of mappings supported by your NAPT device?
> Some residential-class NATs have a limit of 1024 mappings.
>
> -d
>
> > Suffice to say, this is just a sample representation, since the port
> utilization would vary home to home, based on number of active devices,
> type of applications, the degree of simultaneous device or application
> usage etc.
> >
> > If any of you are doing similar monitoring, then please share.
> >
> > Cheers,
> > Rajiv
> >
> > PS: Thanks to Erik Kline, who explained (with sufficient details) how to use
> google charting for my data. And thanks to Xun Wang & Shaoshuai Dai for
> helping me out significantly.
> >
> > PS: My home has 3-4 active devices.
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


--Apple-Mail=_8697BB8D-B577-4D1B-9B1B-27CA59643FD2-- From Branimir.Rajtar@t.ht.hr Fri Jun 7 00:31:42 2013 Return-Path: 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 E35E921F9619; Fri, 7 Jun 2013 00:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] 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 FJ-9C7XsGGY0; Fri, 7 Jun 2013 00:31:36 -0700 (PDT) Received: from mx01.t.ht.hr (mx01.t.ht.hr [195.29.161.88]) by ietfa.amsl.com (Postfix) with SMTP id EBB9A21F944C; Fri, 7 Jun 2013 00:31:34 -0700 (PDT) Received: from no.name.available by mx01.t.ht.hr via smtpd (for mail.ietf.org [12.22.58.30]) with ESMTP; Fri, 7 Jun 2013 08:59:25 +0200 Received: from (unknown [172.17.66.76]) by scmg1.t.ht.hr with smtp id 5a79_411d_46d8ffac_cf44_11e2_850b_00221951415f; Fri, 07 Jun 2013 09:31:32 +0200 Received: (private information removed) Fri, 7 Jun 2013 09:31:32 +0200 Received: (private information removed) S2010EXCHCA1.ad.local ([::1]) with mapi id 14.03.0123.003; Fri, 7 Jun 2013 09:31:32 +0200 From: Branimir Rajtar To: Dan Wing , John Mann Thread-Topic: [BEHAVE] [v6ops] Home NAPT44 - How many ports? Thread-Index: AQHOYxSmFlmur/cKQ0iajTdwC2BYP5kp2xNQ Date: Fri, 7 Jun 2013 07:31:32 +0000 Message-ID: <786F13AA11E69F4DB2CCA23F7400C2FB01464D5F@S2010EXCH1.ad.local> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.5.14] Content-Type: multipart/alternative; boundary="_000_786F13AA11E69F4DB2CCA23F7400C2FB01464D5FS2010EXCH1adloc_" MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jun 2013 07:31:32.0737 (UTC) FILETIME=[088E5710:01CE6351] Cc: "Softwires-wg list \(softwires@ietf.org\)" , "v6ops@ietf.org" , "behave@ietf.org" , "Rajiv Asati \(rajiva\)" Subject: Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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, 07 Jun 2013 07:31:42 -0000 --_000_786F13AA11E69F4DB2CCA23F7400C2FB01464D5FS2010EXCH1adloc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 SGkgYWxsLAoKSSd2ZSBiZWVuIHdvcmtpbmcgcXVpdGUgc29tZSB0aW1lIHdpdGggSG9tZSBHYXRl d2F5cyBhbmQgaW4gbXkgZXhwZXJpZW5jZSB0aGUgb2xkZXIgbW9kZWxzICgzKyB5ZWFycykgdHlw aWNhbGx5IHN1cHBvcnQgMTAwMC0yMDAwIHNpbXVsdGFuZW91cyBzZXNzaW9ucywgd2hpbGUgdGhl IG5ld2VyIG9uZXMgZ28gdXAgdG8gNDAwMCwgc29tZSBldmVuIHVwIHRvIDkwMDAuCgpCcmFuaW1p cgoKRnJvbTogYmVoYXZlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpiZWhhdmUtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhbiBXaW5nClNlbnQ6IEZyaWRheSwgSnVuZSAwNywgMjAx MyAyOjE5IEFNClRvOiBKb2huIE1hbm4KQ2M6IFNvZnR3aXJlcy13ZyBsaXN0IChzb2Z0d2lyZXNA aWV0Zi5vcmcpOyB2Nm9wc0BpZXRmLm9yZzsgYmVoYXZlQGlldGYub3JnOyBSYWppdiBBc2F0aSAo cmFqaXZhKQpTdWJqZWN0OiBSZTogW0JFSEFWRV0gW3Y2b3BzXSBIb21lIE5BUFQ0NCAtIEhvdyBt YW55IHBvcnRzPwoKCk9uIEp1biA2LCAyMDEzLCBhdCA1OjAyIFBNLCBKb2huIE1hbm4gPGpvaG4u bWFubkBtb25hc2guZWR1PG1haWx0bzpqb2huLm1hbm5AbW9uYXNoLmVkdT4+IHdyb3RlOgoKCkhp LAoKT24gNyBKdW5lIDIwMTMgMDg6NDEsIFJhaml2IEFzYXRpIChyYWppdmEpIDxyYWppdmFAY2lz Y28uY29tPG1haWx0bzpyYWppdmFAY2lzY28uY29tPj4gd3JvdGU6CkhpIERhbiwKCj4gYW5kIHNv IG9uLiAgSSBhbSBzdXJwcmlzZWQgeW91IGNvbmNsdWRlIHRoYXQgIjUwMCBzZWVtcyBvayIgd2hl biBzdWNoIGEKPiBsaW1pdCB3b3VsZCBpbnRlcmZlcmUgd2l0aCB5b3VyIG5ldHdvcmsgdXNlIG9u IHRob3NlIGRheXMuCkkgYmFzZWQgdGhhdCBzdGF0ZW1lbnQgKCIuLi5zZWVtcyBvaywiKSBvbiB0 aGUgdmVyeSBmYWN0IHRoYXQgdGhlIG51bWJlciBvZiB0aW1lcyB0aGUgTkFUIHV0aWxpemF0aW9u IGV4Y2VlZGVkIDUwMCBtYXBwaW5ncyAoZXF1YXRpbmcgdG8gNTAwIHBvcnRzLCBpbiBteSBzZXR1 cCkgaW4gdGhlIHNhbXBsZSBwZXJpb2QgKH4yIG1vbnRocykgd2FzIHJlbGF0aXZlbHkgcXVpdGUg bG93LiBTbywgaWYgdGhlIE5BVCBkZXZpY2Ugd2FzIGxpbWl0ZWQgdG8gb25seSA1MDAgbWFwcGlu Z3MsIHRoZW4gdGhlIGV4cGVyaWVuY2Ugd291bGQgaGF2ZSBiZWVuIG9rIGZvciA5OSUgb2YgdGhl IHRpbWUgYW5kIGRlZ3JhZGVkIDElIG9mIHRoZSB0aW1lLiBUaGlzIGlzIGFuIGltcG9ydGFudCBj b25zaWRlcmF0aW9uLCBJTU8uCgpGb3IgZXgsIGluIHRoZSBsYXN0IDIgd2Vla3MsIHRoZSBudW1i ZXIgb2YgdGltZXMgTkFUIG1hcHBpbmdzIGV4Y2VlZGVkIDUwMCB3ZXJlOgoKSnVuZSAzIC0gMSB0 aW1lCk1heSAyOSAtIDEgdGltZQpNYXkgMjggLSAzIHRpbWVzCk1heSAyNiAtIDEgdGltZQpNYXkg MjMgLSAxIHRpbWUKTWF5IDIyIC0gMiB0aW1lcwpNYXkgMjEgLSAzIHRpbWVzCgpJIHRoaW5rIGEg bW9yZS1pbnRlcmVzdGluZyBzdGF0aXN0aWMgd291bGQgYmUgImhvdyBtYW55IGNvbm5lY3Rpb24g c2V0dXBzIHdvdWxkIGhhdmUgZmFpbGVkIi4KQnV0IEkgZG9uJ3QgdGhpbmsgeW91IGNhbiBtZWFz dXJlIHRoYXQganVzdCBieSBwb2xsaW5nIGNvbmN1cnJlbnQgY29ubmVjdGlvbnMgYXQgc3BlY2lm aWMgdGltZXMuCkl0IG1pZ2h0IHRha2UgZS5nLiBuZXRmbG93IGV4cG9ydGluZyBhbmQgYW5hbHlz aXMgLi4uCgpIb3dldmVyICJudW1iZXIgb2YgY29uY3VycmVudCBjb25uZWN0aW9ucyB0aGF0IGNv dWxkbid0IGhhdmUgYmVlbiBzZXR1cCIgd291bGQgYmUgdXNlZnVsIGluIGdhdWdpbmcgdGhlIGlt cGFjdAplLmcuIG9uIE1heSAyOSB0aGVyZSB3YXMgb25lIHNwaWtlIG9mIDczNCBjb25jdXJyZW50 IGNvbm5lY3Rpb25zLCB0aGVuIHJlcG9ydCB0aGF0IGFzIDIzNCBwb3RlbnRpYWwgZmFpbHVyZXMu CgpPZiBjb3Vyc2UsIDEwMDAgcG9ydHMgKHJlc3VsdGluZyBpbiAxMDAwKyBtYXBwaW5ncykgd291 bGQgaGF2ZSBiZWVuIG1vcmUgdGhhbiBlbm91Z2ggdG8gYWNjb21tb2RhdGUgdGhlIHRpbWVzIHdo ZW4gdGhlIG1hcHBpbmdzIGV4Y2VlZGVkIDUwMCwgYnV0IHN0YXllZCB3aXRoaW4gMTAwMCAoZXhj ZXB0IG9uY2UpLgoKCj4gV2hhdCBpcyB0aGUgbWF4aW11bSBudW1iZXIgb2YgbWFwcGluZ3Mgc3Vw cG9ydGVkIGJ5IHlvdXIgTkFQVCBkZXZpY2U/Cj4gU29tZSByZXNpZGVudGlhbC1jbGFzcyBOQVRz IGhhdmUgYSBsaW1pdCBvZiAxMDI0IG1hcHBpbmdzLgoKSXMgdGhhdCBhIGNvbWJpbmVkIGxpbWl0 IG9mIFRDUCBhbmQgVURQIGFuZCBJQ01QLCBvciBpbmRlcGVuZGVudD8KClRoZSBzdHVkeSBhdCBo dHRwOi8vZWdnZXJ0Lm9yZy9wYXBlcnMvMjAxMC1pbWMtaGd3LXN0dWR5LnBkZiBvbmx5IGFuYWx5 emVkIFRDUCBiaW5kaW5ncy4KCi1kCgoKCgpNeSBOQVBUIGRldmljZSBzZWVtaW5nbHkgY2FuIHVz ZSB1cHRvIDY0SyBwb3J0cy4gOikKCkNoZWVycywKUmFqaXYKCgo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tCj4gRnJvbTogRGFuIFdpbmcgKGR3aW5nKQo+IFNlbnQ6IFRodXJzZGF5LCBKdW5l IDA2LCAyMDEzIDExOjQzIEFNCj4gVG86IFJhaml2IEFzYXRpIChyYWppdmEpCj4gQ2M6IHY2b3Bz QGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz47IFNvZnR3aXJlcy13ZyBsaXN0IChzb2Z0 d2lyZXNAaWV0Zi5vcmc8bWFpbHRvOnNvZnR3aXJlc0BpZXRmLm9yZz4pOwo+IGJlaGF2ZUBpZXRm Lm9yZzxtYWlsdG86YmVoYXZlQGlldGYub3JnPjsgRXJpayBLbGluZSAoZWtAZ29vZ2xlLmNvbTxt YWlsdG86ZWtAZ29vZ2xlLmNvbT4pCj4gU3ViamVjdDogUmU6IFtCRUhBVkVdIEhvbWUgTkFQVDQ0 IC0gSG93IG1hbnkgcG9ydHM/Cj4KPgo+IE9uIEp1biA1LCAyMDEzLCBhdCA2OjE0IEFNLCBSYWpp diBBc2F0aSAocmFqaXZhKSA8cmFqaXZhQGNpc2NvLmNvbTxtYWlsdG86cmFqaXZhQGNpc2NvLmNv bT4+IHdyb3RlOgo+Cj4gPiBTb21lIG9mIHlvdSBtYXkgcmVjYWxsIG91ciBkaXNjdXNzaW9uIChk dXJpbmcgdGhlIGxhc3QgSUVURikgYXJvdW5kICJob3cKPiBtYW55IFRDUC9VRFAgcG9ydHMgYXJl IGVub3VnaCB3aXRoIE5BUFQ0NCIgcGVyIGhvbWUsIGFzIElTUHMgbW92ZSBpbnRvCj4gQStQIHBh cmFkaWdtLiB+NTAwLCB+MTAwMCwgfjMwMDA/Pz8KPiA+Cj4gPiBXZWxsLCBJIHN0YXJ0ZWQgbW9u aXRvcmluZyBteSBob21lIHJvdXRlciBhbmQgcGxvdHRpbmcgdGhlIE5BUFQ0NCBwb3J0Cj4gdXRp bGl6YXRpb24gb24gYSBtaW51dGUtYnktbWludXRlIGJhc2lzLiBZb3UgbWF5IGZpbmQgaXQgaGVy ZSAtCj4gaHR0cDovL3d3dy5lbXBsb3llZXMub3JnL35yYWppdmEKPiA+Cj4gPiBJbiBzaG9ydCwg cG9ydCByYW5nZSBvZiA1MDAgc2VlbXMgb2ssIHRob3VnaCAxMDAwIHdvdWxkIGJlIG1vcmUgdGhh bgo+IGVub3VnaCBmb3IgbXkgaG9tZS4KPgo+IEkgc2VlIHNldmVyYWwgc3Bpa2VzIGluIHlvdXIg ZGF0YSBvdmVyIDUwMCBwb3J0cy4gIER1cmluZyB0aG9zZSB0aW1lcywKPiBhcHBsaWNhdGlvbnMg d291bGQgYmUgdW5hYmxlIHRvIGZ1bmN0aW9uICh1bmFibGUgdG8gZ2V0IGEgcG9ydCkuICBBcHJp bCAyOS8zMAo+IGlzIGEgbG9uZyB0aW1lIHdoZXJlIHRoYXQgb2NjdXJzIHZlcnkgdmlzaWJseSwg YnV0IHRoZXJlIGFyZSBzaG9ydGVyIHNwaWtlcwo+IGVsc2V3aGVyZSBzdWNoIGFzIG9uIEFwcmls IDE3IGFuZCBBcHJpbCAxOC4gIElmIHlvdSBoYWQgb25seSA1MDAgcG9ydHMgb24KPiB0aG9zZSBk YXlzLCBjcmVhdGluZyBhIG5ldyBUQ1AgbWFwcGluZyB3b3VsZCBoYXZlIGJlZW4gaW1wb3NzaWJs ZSwKPiBpbXBhY3RpbmcgYWJpbGl0eSB0byBzZW5kIG9yIHJlY2VpdmUgZW1haWwsIG9yZGVyIGJv b2tzIGZyb20gQW1hem9uLmNvbTxodHRwOi8vQW1hem9uLmNvbT4sCj4gYW5kIHNvIG9uLiAgSSBh bSBzdXJwcmlzZWQgeW91IGNvbmNsdWRlIHRoYXQgIjUwMCBzZWVtcyBvayIgd2hlbiBzdWNoIGEK PiBsaW1pdCB3b3VsZCBpbnRlcmZlcmUgd2l0aCB5b3VyIG5ldHdvcmsgdXNlIG9uIHRob3NlIGRh eXMuCj4KPiBXaGF0IGlzIHRoZSBtYXhpbXVtIG51bWJlciBvZiBtYXBwaW5ncyBzdXBwb3J0ZWQg YnkgeW91ciBOQVBUIGRldmljZT8KPiBTb21lIHJlc2lkZW50aWFsLWNsYXNzIE5BVHMgaGF2ZSBh IGxpbWl0IG9mIDEwMjQgbWFwcGluZ3MuCj4KPiAtZAo+Cj4gPiBTdWZmaWNlIHRvIHNheSwgdGhp cyBpcyBqdXN0IGEgc2FtcGxlIHJlcHJlc2VudGF0aW9uLCBzaW5jZSB0aGUgcG9ydAo+IHV0aWxp emF0aW9uIHdvdWxkIHZhcnkgaG9tZSB0byBob21lLCBiYXNlZCBvbiBudW1iZXIgb2YgYWN0aXZl IGRldmljZXMsCj4gdHlwZSBvZiBhcHBsaWNhdGlvbnMsIHRoZSBkZWdyZWUgb2Ygc2ltdWx0YW5l b3VzIGRldmljZSBvciBhcHBsaWNhdGlvbgo+IHVzYWdlIGV0Yy4KPiA+Cj4gPiBJZiBhbnkgb2Yg eW91IGFyZSBkb2luZyBzaW1pbGFyIG1vbml0b3JpbmcsIHRoZW4gcGxlYXNlIHNoYXJlLgo+ID4K PiA+IENoZWVycywKPiA+IFJhaml2Cj4gPgo+ID4gUFM6IFRoYW5rcyB0byBFcmlrIEtsaW5lLCB3 aG8gZXhwbGFpbmVkICh3aXRoIHN1ZmZpY2llbnQgZGV0YWlscykgaG93IHRvIHVzZQo+IGdvb2ds ZSBjaGFydGluZyBmb3IgbXkgZGF0YS4gQW5kIHRoYW5rcyB0byBYdW4gV2FuZyAmIFNoYW9zaHVh aSBEYWkgZm9yCj4gaGVscGluZyBtZSBvdXQgc2lnbmlmaWNhbnRseS4KPiA+Cj4gPiBQUzogTXkg aG9tZSBoYXMgMy00IGFjdGl2ZSBkZXZpY2VzLgo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KPiA+IEJlaGF2ZSBtYWlsaW5nIGxpc3QKPiA+IEJlaGF2 ZUBpZXRmLm9yZzxtYWlsdG86QmVoYXZlQGlldGYub3JnPgo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9iZWhhdmUKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCnY2b3BzIG1haWxpbmcgbGlzdAp2Nm9wc0BpZXRmLm9yZzxtYWls dG86djZvcHNAaWV0Zi5vcmc+Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v djZvcHMKCgoKCjxIVE1MPjxQPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Izk5OTk5OSBzaXplPTE+ DQoNCklaSkFWQSBPIE9EUklDQU5KVSBPREdPVk9STk9TVEk6IFNhZHLFvmFqIG92ZSBwb3J1a2Ug aSBldmVudHVhbG5vIHByaWxvxb5lbmloIGRhdG90ZWthIGplIHBvdmplcmxqaXYgaSBuYW1pamVu amVuIGplIHNhbW8gb3NvYmFtYSBpbGkgc3ViamVrdGltYSBrb2ppIHN1IG5hdmVkZW5pIHUgYWRy ZXNpLiBVa29saWtvIHN0ZSBwcmltaWxpIG92dSBwb3J1a3UgZ3JlxaFrb20sIG1vbGltbyBWYXMs IG9iYXZpamVzdGl0ZSBwb8WhaWxqYXRlbGphLCBhIHBvcnVrdSBpIHN2ZSBuamVuZSBwcml2aXRr ZSBvZG1haCwgYmV6IMSNaXRhbmphLCB0cmFqbm8gdWtsb25pdGUgcyByYcSNdW5hbGEuIEJpbG8g a2Frdm8gcHJlbm/FoWVuamUsIGtvcGlyYW5qZSBpbGkgZGlzdHJpYnVjaWphIGluZm9ybWFjaWph IHNhZHLFvmFuaWggdSBwb3J1Y2kgdHJlxIdpbSBvc29iYW1hIGplIHphYnJhbmplbm8gaSBtb8W+ ZSBiaXRpIHpha29uc2tpIGthxb5uaml2by4gU2FkcsW+YWosIHN0YXZvdmkgaSBtacWhbGplbmph IGl6bmVzZW5pIHUgcG9ydWNpIHN1IGF1dG9yb3ZpIGkgbmUgcHJlZHN0YXZsamFqdSBudcW+bm8g c3Rhdm92ZSBIVCAtIEhydmF0c2tpaCB0ZWxla29tdW5pa2FjaWphIGQuZC4gSFQgbmUgcHJpaHZh xIdhIG5pa2FrdnUgb2Rnb3Zvcm5vc3QgemEgZXZlbnR1YWxudSDFoXRldHUgbmFzdGFsdSBwcmlt aXRrb20gb3ZlIHBvcnVrZSBpIHByaWxvZ2Egc2FkcsW+YW5paCB1IHBvcnVjaS4NCg0KPC9GT05U PjwvUD48UD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM5OTk5OTkgc2l6ZT0xPg0KDQogRElTQ0xB SU1FUjpUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhcyB3ZWxsIGFzIGFueSBmaWxlcyBhdHRh Y2hlZCB0byBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIGluZGl2 aWR1YWxzIG9yIGVudGl0aWVzIHdoaWNoIHRoZXkgYXJlIGFkZHJlc3NlZCB0by4gSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYW5kIHBlcm1hbmVudGx5IHJlbW92ZSB0aGUgbWVzc2FnZSBhbmQgYWxsIGF0dGFj aGVkIGZpbGVzIGZyb20gdGhlIGNvbXB1dGVyLiBBbnkgZGlzY2xvc3VyZSwgY29weWluZyBvciBk aXN0cmlidXRpb24gb2YgYWxsIG9yIGEgcGFydCBvZiBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVy ZWluIHRvIG9yIGJ5IHRoaXJkIHBhcnRpZXMgaXMgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3 ZnVsLiBQbGVhc2Ugbm90ZSB0aGF0IGFueSB2aWV3cyBvciBvcGluaW9ucyBwcmVzZW50ZWQgaW4g dGhpcyBtZXNzYWdlIGFyZSBzb2xlbHkgdGhvc2Ugb2YgdGhlIGF1dGhvciBhbmQgZG8gbm90IG5l Y2Vzc2FyaWx5IHJlcHJlc2VudCB0aGUgdmlld3MgYW5kIG9waW5pb25zIG9mIENyb2F0aWFuIFRl bGVjb20gSW5jLiBDcm9hdGlhbiBUZWxlY29tIEluYy4gYWNjZXB0cyBubyBsaWFiaWxpdHkgZm9y IGFueSBwb3RlbnRpYWwgZGFtYWdlIGNhdXNlZCBieSB0aGlzIG1lc3NhZ2UgYW5kIGZpbGVzIGF0 dGFjaGVkIHRvIGl0Lg0KDQo8L0ZPTlQ+PC9QPjwvSFRNTD4K --_000_786F13AA11E69F4DB2CCA23F7400C2FB01464D5FS2010EXCH1adloc_ Content-Type: text/HTML; charset="utf-8" Content-Transfer-Encoding: base64 X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4KPGhlYWQ+CjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQt VHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ CjxzdHlsZT48IS0tCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8KQGZvbnQtZmFjZQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOwoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9CkBmb250 LWZhY2UKCXtmb250LWZhbWlseTpDYWxpYnJpOwoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQpAZm9udC1mYWNlCgl7Zm9udC1mYW1pbHk6VGFob21hOwoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLwpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsCgl7bWFyZ2luOjBjbTsKCW1hcmdpbi1ib3R0b206LjAwMDFw dDsKCWZvbnQtc2l6ZToxMi4wcHQ7Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiO30KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluawoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsK CWNvbG9yOmJsdWU7Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6cHVy cGxlOwoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9CnNwYW4uRW1haWxTdHlsZTE3Cgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOwoJY29sb3I6IzFGNDk3RDt9Ci5Nc29DaHBEZWZhdWx0Cgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7Cglmb250LXNpemU6MTAuMHB0O30KQHBhZ2UgV29yZFNlY3Rpb24xCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7CgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVw dDt9CmRpdi5Xb3JkU2VjdGlvbjEKCXtwYWdlOldvcmRTZWN0aW9uMTt9Ci0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPgo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPgo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+CjwvaGVhZD4KPGJvZHkgbGFu Zz0iSFIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFr LXdvcmQ7LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOy13ZWJraXQtbGluZS1icmVhazogYWZ0ZXIt d2hpdGUtc3BhY2UiPgo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkhpIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkndmUgYmVlbiB3 b3JraW5nIHF1aXRlIHNvbWUgdGltZSB3aXRoIEhvbWUgR2F0ZXdheXMgYW5kIGluIG15IGV4cGVy aWVuY2UgdGhlIG9sZGVyIG1vZGVscyAoMyYjNDM7IHllYXJzKSB0eXBpY2FsbHkgc3VwcG9ydCAx MDAwLTIwMDAgc2ltdWx0YW5lb3VzCiBzZXNzaW9ucywgd2hpbGUgdGhlIG5ld2VyIG9uZXMgZ28g dXAgdG8gNDAwMCwgc29tZSBldmVuIHVwIHRvIDkwMDAuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+QnJhbmltaXI8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjojMUY0OTdEIj4KPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPGRpdj4KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBiZWhhdmUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmJlaGF2ZS1ib3VuY2Vz QGlldGYub3JnXQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkRhbiBXaW5nPGJyPgo8Yj5TZW50OjwvYj4g RnJpZGF5LCBKdW5lIDA3LCAyMDEzIDI6MTkgQU08YnI+CjxiPlRvOjwvYj4gSm9obiBNYW5uPGJy Pgo8Yj5DYzo8L2I+IFNvZnR3aXJlcy13ZyBsaXN0IChzb2Z0d2lyZXNAaWV0Zi5vcmcpOyB2Nm9w c0BpZXRmLm9yZzsgYmVoYXZlQGlldGYub3JnOyBSYWppdiBBc2F0aSAocmFqaXZhKTxicj4KPGI+ U3ViamVjdDo8L2I+IFJlOiBbQkVIQVZFXSBbdjZvcHNdIEhvbWUgTkFQVDQ0IC0gSG93IG1hbnkg cG9ydHM/PG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPC9kaXY+CjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+CjxkaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5PbiBKdW4gNiwgMjAxMywgYXQgNTowMiBQTSwgSm9obiBNYW5uICZsdDs8YSBocmVmPSJt YWlsdG86am9obi5tYW5uQG1vbmFzaC5lZHUiPmpvaG4ubWFubkBtb25hc2guZWR1PC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4KPGJyPgo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxkaXY+ CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5PbiA3IEp1bmUgMjAxMyAwODo0MSwgUmFqaXYgQXNhdGkgKHJhaml2 YSkgJmx0OzxhIGhyZWY9Im1haWx0bzpyYWppdmFAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ cmFqaXZhQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIERhbiw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4KJmd0OyBhbmQgc28gb24uICZuYnNwO0kg YW0gc3VycHJpc2VkIHlvdSBjb25jbHVkZSB0aGF0ICZxdW90OzUwMCBzZWVtcyBvayZxdW90OyB3 aGVuIHN1Y2ggYTxicj4KJmd0OyBsaW1pdCB3b3VsZCBpbnRlcmZlcmUgd2l0aCB5b3VyIG5ldHdv cmsgdXNlIG9uIHRob3NlIGRheXMuPG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgYmFzZWQgdGhhdCBzdGF0ZW1lbnQg KCZxdW90Oy4uLnNlZW1zIG9rLCZxdW90Oykgb24gdGhlIHZlcnkgZmFjdCB0aGF0IHRoZSBudW1i ZXIgb2YgdGltZXMgdGhlIE5BVCB1dGlsaXphdGlvbiBleGNlZWRlZCA1MDAgbWFwcGluZ3MgKGVx dWF0aW5nIHRvIDUwMCBwb3J0cywgaW4gbXkgc2V0dXApIGluIHRoZSBzYW1wbGUgcGVyaW9kICh+ MiBtb250aHMpIHdhcyByZWxhdGl2ZWx5IHF1aXRlIGxvdy4KIFNvLCBpZiB0aGUgTkFUIGRldmlj ZSB3YXMgbGltaXRlZCB0byBvbmx5IDUwMCBtYXBwaW5ncywgdGhlbiB0aGUgZXhwZXJpZW5jZSB3 b3VsZCBoYXZlIGJlZW4gb2sgZm9yIDk5JSBvZiB0aGUgdGltZSBhbmQgZGVncmFkZWQgMSUgb2Yg dGhlIHRpbWUuIFRoaXMgaXMgYW4gaW1wb3J0YW50IGNvbnNpZGVyYXRpb24sIElNTy48YnI+Cjxi cj4KRm9yIGV4LCBpbiB0aGUgbGFzdCAyIHdlZWtzLCB0aGUgbnVtYmVyIG9mIHRpbWVzIE5BVCBt YXBwaW5ncyBleGNlZWRlZCA1MDAgd2VyZTo8YnI+Cjxicj4KSnVuZSAzIC0gMSB0aW1lPGJyPgpN YXkgMjkgLSAxIHRpbWU8YnI+Ck1heSAyOCAtIDMgdGltZXM8YnI+Ck1heSAyNiAtIDEgdGltZTxi cj4KTWF5IDIzIC0gMSB0aW1lPGJyPgpNYXkgMjIgLSAyIHRpbWVzPGJyPgpNYXkgMjEgLSAzIHRp bWVzPG86cD48L286cD48L3NwYW4+PC9wPgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPGRpdj4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgdGhpbmsgYSBtb3JlLWlu dGVyZXN0aW5nIHN0YXRpc3RpYyB3b3VsZCBiZSAmcXVvdDtob3cgbWFueSBjb25uZWN0aW9uIHNl dHVwcyB3b3VsZCBoYXZlIGZhaWxlZCZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2 Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QnV0IEkgZG9u J3QgdGhpbmsgeW91IGNhbiBtZWFzdXJlIHRoYXQganVzdCBieSBwb2xsaW5nIGNvbmN1cnJlbnQg Y29ubmVjdGlvbnMgYXQgc3BlY2lmaWMgdGltZXMuPG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rp dj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkl0IG1pZ2h0 IHRha2UgZS5nLiBuZXRmbG93IGV4cG9ydGluZyBhbmQgYW5hbHlzaXMgLi4uPG86cD48L286cD48 L3NwYW4+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Ib3dldmVyICZxdW90O251bWJlciBvZiBj b25jdXJyZW50IGNvbm5lY3Rpb25zIHRoYXQgY291bGRuJ3QgaGF2ZSBiZWVuIHNldHVwJnF1b3Q7 IHdvdWxkIGJlIHVzZWZ1bCBpbiZuYnNwO2dhdWdpbmcmbmJzcDt0aGUgaW1wYWN0PG86cD48L286 cD48L3NwYW4+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPmUuZy4gb24gTWF5IDI5IHRoZXJlIHdhcyBvbmUgc3Bpa2Ugb2YgNzM0IGNvbmN1 cnJlbnQgY29ubmVjdGlvbnMsIHRoZW4gcmVwb3J0IHRoYXQgYXMgMjM0IHBvdGVudGlhbCBmYWls dXJlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8L2Rp dj4KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9m IGNvdXJzZSwgMTAwMCBwb3J0cyAocmVzdWx0aW5nIGluIDEwMDAmIzQzOyBtYXBwaW5ncykgd291 bGQgaGF2ZSBiZWVuIG1vcmUgdGhhbiBlbm91Z2ggdG8gYWNjb21tb2RhdGUgdGhlIHRpbWVzIHdo ZW4gdGhlIG1hcHBpbmdzIGV4Y2VlZGVkIDUwMCwgYnV0IHN0YXllZCB3aXRoaW4gMTAwMCAoZXhj ZXB0IG9uY2UpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4KPGJyPgomZ3Q7IFdoYXQgaXMgdGhlIG1heGltdW0g bnVtYmVyIG9mIG1hcHBpbmdzIHN1cHBvcnRlZCBieSB5b3VyIE5BUFQgZGV2aWNlPzxicj4KJmd0 OyBTb21lIHJlc2lkZW50aWFsLWNsYXNzIE5BVHMgaGF2ZSBhIGxpbWl0IG9mIDEwMjQgbWFwcGlu Z3MuPG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPC9ibG9ja3F1b3RlPgo8ZGl2Pgo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPklzIHRoYXQgYSBjb21iaW5lZCBsaW1pdCBvZiBUQ1AgYW5kIFVEUCBhbmQgSUNNUCwgb3Ig aW5kZXBlbmRlbnQ/PG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPC9kaXY+CjwvZGl2Pgo8 L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgc3R1ZHkgYXQmbmJzcDs8YSBocmVmPSJodHRwOi8vZWdn ZXJ0Lm9yZy9wYXBlcnMvMjAxMC1pbWMtaGd3LXN0dWR5LnBkZiI+aHR0cDovL2VnZ2VydC5vcmcv cGFwZXJzLzIwMTAtaW1jLWhndy1zdHVkeS5wZGY8L2E+IG9ubHkgYW5hbHl6ZWQgVENQIGJpbmRp bmdzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2 Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LWQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4KPGJyPgo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+CjxkaXY+CjxkaXY+CjxkaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow Y20iPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TXkgTkFQVCBkZXZp Y2Ugc2VlbWluZ2x5IGNhbiB1c2UgdXB0byA2NEsgcG9ydHMuIDopPGJyPgo8YnI+CkNoZWVycyw8 YnI+ClJhaml2PG86cD48L286cD48L3NwYW4+PC9wPgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPgo8YnI+CiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08YnI+CiZndDsgRnJvbTogRGFuIFdpbmcgKGR3aW5nKTxicj4KJmd0OyBTZW50OiBUaHVy c2RheSwgSnVuZSAwNiwgMjAxMyAxMTo0MyBBTTxicj4KJmd0OyBUbzogUmFqaXYgQXNhdGkgKHJh aml2YSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGll dGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT47IFNvZnR3aXJlcy13ZyBsaXN0ICg8YSBocmVmPSJt YWlsdG86c29mdHdpcmVzQGlldGYub3JnIj5zb2Z0d2lyZXNAaWV0Zi5vcmc8L2E+KTs8YnI+CiZn dDsgPGEgaHJlZj0ibWFpbHRvOmJlaGF2ZUBpZXRmLm9yZyI+YmVoYXZlQGlldGYub3JnPC9hPjsg RXJpayBLbGluZSAoPGEgaHJlZj0ibWFpbHRvOmVrQGdvb2dsZS5jb20iPmVrQGdvb2dsZS5jb208 L2E+KTxicj4KJmd0OyBTdWJqZWN0OiBSZTogW0JFSEFWRV0gSG9tZSBOQVBUNDQgLSBIb3cgbWFu eSBwb3J0cz88YnI+CiZndDs8YnI+CiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8 ZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBP biBKdW4gNSwgMjAxMywgYXQgNjoxNCBBTSwgUmFqaXYgQXNhdGkgKHJhaml2YSkgJmx0OzxhIGhy ZWY9Im1haWx0bzpyYWppdmFAY2lzY28uY29tIj5yYWppdmFAY2lzY28uY29tPC9hPiZndDsgd3Jv dGU6PGJyPgomZ3Q7PGJyPgomZ3Q7ICZndDsgU29tZSBvZiB5b3UgbWF5IHJlY2FsbCBvdXIgZGlz Y3Vzc2lvbiAoZHVyaW5nIHRoZSBsYXN0IElFVEYpIGFyb3VuZCAmcXVvdDtob3c8YnI+CiZndDsg bWFueSBUQ1AvVURQIHBvcnRzIGFyZSBlbm91Z2ggd2l0aCBOQVBUNDQmcXVvdDsgcGVyIGhvbWUs IGFzIElTUHMgbW92ZSBpbnRvPGJyPgomZ3Q7IEEmIzQzO1AgcGFyYWRpZ20uIH41MDAsIH4xMDAw LCB+MzAwMD8/Pzxicj4KJmd0OyAmZ3Q7PGJyPgomZ3Q7ICZndDsgV2VsbCwgSSBzdGFydGVkIG1v bml0b3JpbmcgbXkgaG9tZSByb3V0ZXIgYW5kIHBsb3R0aW5nIHRoZSBOQVBUNDQgcG9ydDxicj4K Jmd0OyB1dGlsaXphdGlvbiBvbiBhIG1pbnV0ZS1ieS1taW51dGUgYmFzaXMuIFlvdSBtYXkgZmlu ZCBpdCBoZXJlIC08YnI+CiZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5lbXBsb3llZXMub3JnL35y YWppdmEiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmVtcGxveWVlcy5vcmcvfnJhaml2YTwv YT48YnI+CiZndDsgJmd0Ozxicj4KJmd0OyAmZ3Q7IEluIHNob3J0LCBwb3J0IHJhbmdlIG9mIDUw MCBzZWVtcyBvaywgdGhvdWdoIDEwMDAgd291bGQgYmUgbW9yZSB0aGFuPGJyPgomZ3Q7IGVub3Vn aCBmb3IgbXkgaG9tZS48YnI+CiZndDs8YnI+CiZndDsgSSBzZWUgc2V2ZXJhbCBzcGlrZXMgaW4g eW91ciBkYXRhIG92ZXIgNTAwIHBvcnRzLiAmbmJzcDtEdXJpbmcgdGhvc2UgdGltZXMsPGJyPgom Z3Q7IGFwcGxpY2F0aW9ucyB3b3VsZCBiZSB1bmFibGUgdG8gZnVuY3Rpb24gKHVuYWJsZSB0byBn ZXQgYSBwb3J0KS4gJm5ic3A7QXByaWwgMjkvMzA8YnI+CiZndDsgaXMgYSBsb25nIHRpbWUgd2hl cmUgdGhhdCBvY2N1cnMgdmVyeSB2aXNpYmx5LCBidXQgdGhlcmUgYXJlIHNob3J0ZXIgc3Bpa2Vz PGJyPgomZ3Q7IGVsc2V3aGVyZSBzdWNoIGFzIG9uIEFwcmlsIDE3IGFuZCBBcHJpbCAxOC4gJm5i c3A7SWYgeW91IGhhZCBvbmx5IDUwMCBwb3J0cyBvbjxicj4KJmd0OyB0aG9zZSBkYXlzLCBjcmVh dGluZyBhIG5ldyBUQ1AgbWFwcGluZyB3b3VsZCBoYXZlIGJlZW4gaW1wb3NzaWJsZSw8YnI+CiZn dDsgaW1wYWN0aW5nIGFiaWxpdHkgdG8gc2VuZCBvciByZWNlaXZlIGVtYWlsLCBvcmRlciBib29r cyBmcm9tIDxhIGhyZWY9Imh0dHA6Ly9BbWF6b24uY29tIj4KQW1hem9uLmNvbTwvYT4sPGJyPgom Z3Q7IGFuZCBzbyBvbi4gJm5ic3A7SSBhbSBzdXJwcmlzZWQgeW91IGNvbmNsdWRlIHRoYXQgJnF1 b3Q7NTAwIHNlZW1zIG9rJnF1b3Q7IHdoZW4gc3VjaCBhPGJyPgomZ3Q7IGxpbWl0IHdvdWxkIGlu dGVyZmVyZSB3aXRoIHlvdXIgbmV0d29yayB1c2Ugb24gdGhvc2UgZGF5cy48YnI+CiZndDs8YnI+ CiZndDsgV2hhdCBpcyB0aGUgbWF4aW11bSBudW1iZXIgb2YgbWFwcGluZ3Mgc3VwcG9ydGVkIGJ5 IHlvdXIgTkFQVCBkZXZpY2U/PGJyPgomZ3Q7IFNvbWUgcmVzaWRlbnRpYWwtY2xhc3MgTkFUcyBo YXZlIGEgbGltaXQgb2YgMTAyNCBtYXBwaW5ncy48YnI+CiZndDs8YnI+CiZndDsgLWQ8YnI+CiZn dDs8YnI+CiZndDsgJmd0OyBTdWZmaWNlIHRvIHNheSwgdGhpcyBpcyBqdXN0IGEgc2FtcGxlIHJl cHJlc2VudGF0aW9uLCBzaW5jZSB0aGUgcG9ydDxicj4KJmd0OyB1dGlsaXphdGlvbiB3b3VsZCB2 YXJ5IGhvbWUgdG8gaG9tZSwgYmFzZWQgb24gbnVtYmVyIG9mIGFjdGl2ZSBkZXZpY2VzLDxicj4K Jmd0OyB0eXBlIG9mIGFwcGxpY2F0aW9ucywgdGhlIGRlZ3JlZSBvZiBzaW11bHRhbmVvdXMgZGV2 aWNlIG9yIGFwcGxpY2F0aW9uPGJyPgomZ3Q7IHVzYWdlIGV0Yy48YnI+CiZndDsgJmd0Ozxicj4K Jmd0OyAmZ3Q7IElmIGFueSBvZiB5b3UgYXJlIGRvaW5nIHNpbWlsYXIgbW9uaXRvcmluZywgdGhl biBwbGVhc2Ugc2hhcmUuPGJyPgomZ3Q7ICZndDs8YnI+CiZndDsgJmd0OyBDaGVlcnMsPGJyPgom Z3Q7ICZndDsgUmFqaXY8YnI+CiZndDsgJmd0Ozxicj4KJmd0OyAmZ3Q7IFBTOiBUaGFua3MgdG8g RXJpayBLbGluZSwgd2hvIGV4cGxhaW5lZCAod2l0aCBzdWZmaWNpZW50IGRldGFpbHMpIGhvdyB0 byB1c2U8YnI+CiZndDsgZ29vZ2xlIGNoYXJ0aW5nIGZvciBteSBkYXRhLiBBbmQgdGhhbmtzIHRv IFh1biBXYW5nICZhbXA7IFNoYW9zaHVhaSBEYWkgZm9yPGJyPgomZ3Q7IGhlbHBpbmcgbWUgb3V0 IHNpZ25pZmljYW50bHkuPGJyPgomZ3Q7ICZndDs8YnI+CiZndDsgJmd0OyBQUzogTXkgaG9tZSBo YXMgMy00IGFjdGl2ZSBkZXZpY2VzLjxicj4KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPgomZ3Q7ICZndDsgQmVoYXZlIG1haWxpbmcg bGlzdDxicj4KJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpCZWhhdmVAaWV0Zi5vcmciPkJlaGF2 ZUBpZXRmLm9yZzwvYT48YnI+CiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2JlaGF2ZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVoYXZlPC9hPjxicj4KPGJyPgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4KdjZvcHMgbWFpbGluZyBsaXN0 PGJyPgo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjxi cj4KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZv cHM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPC9kaXY+CjwvYmxvY2txdW90ZT4K PC9kaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8L2Rpdj4KPC9kaXY+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2 PgoKPERJVj48UD48SFI+CjxQPjxGT05UIGNvbG9yPSM5OTk5OTkgc2l6ZT0xIGZhY2U9QXJpYWw+ SVpKQVZBIE8gT0RSSUNBTkpVIE9ER09WT1JOT1NUSTogU2FkciYjMzgyO2FqIG92ZSBwb3J1a2Ug aSBldmVudHVhbG5vIHByaWxvJiMzODI7ZW5paCBkYXRvdGVrYSBqZSBwb3ZqZXJsaml2IGkgbmFt aWplbmplbiBqZSBzYW1vIG9zb2JhbWEgaWxpIHN1Ympla3RpbWEga29qaSBzdSBuYXZlZGVuaSB1 IGFkcmVzaS4gVWtvbGlrbyBzdGUgcHJpbWlsaSBvdnUgcG9ydWt1IGdyZSYjMzUzO2tvbSwgbW9s aW1vIFZhcywgb2JhdmlqZXN0aXRlIHBvJiMzNTM7aWxqYXRlbGphLCBhIHBvcnVrdSBpIHN2ZSBu amVuZSBwcml2aXRrZSBvZG1haCwgYmV6ICYjMjY5O2l0YW5qYSwgdHJham5vIHVrbG9uaXRlIHMg cmEmIzI2OTt1bmFsYS4gQmlsbyBrYWt2byBwcmVubyYjMzUzO2VuamUsIGtvcGlyYW5qZSBpbGkg ZGlzdHJpYnVjaWphIGluZm9ybWFjaWphIHNhZHImIzM4MjthbmloIHUgcG9ydWNpIHRyZSYjMjYz O2ltIG9zb2JhbWEgamUgemFicmFuamVubyBpIG1vJiMzODI7ZSBiaXRpIHpha29uc2tpIGthJiMz ODI7bmppdm8uIFNhZHImIzM4Mjthaiwgc3Rhdm92aSBpIG1pJiMzNTM7bGplbmphIGl6bmVzZW5p IHUgcG9ydWNpIHN1IGF1dG9yb3ZpIGkgbmUgcHJlZHN0YXZsamFqdSBudSYjMzgyO25vIHN0YXZv dmUgSFQgLSBIcnZhdHNrb2cgVGVsZWtvbWEgZC5kLiBIVCBuZSBwcmlodmEmIzI2MzthIG5pa2Fr dnUgb2Rnb3Zvcm5vc3QgemEgZXZlbnR1YWxudSAmIzM1Mzt0ZXR1IG5hc3RhbHUgcHJpbWl0a29t IG92ZSBwb3J1a2UgaSBwcmlsb2dhIHNhZHImIzM4MjthbmloIHUgcG9ydWNpLiA8L0ZPTlQ+PC9Q Pg0KPFA+PEZPTlQgY29sb3I9Izk5OTk5OSBzaXplPTEgZmFjZT1BcmlhbD5ESVNDTEFJTUVSOlRo ZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFzIHdlbGwgYXMgYW55IGZpbGVzIGF0dGFjaGVkIHRv IGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgaW5kaXZpZHVhbHMg b3IgZW50aXRpZXMgd2hpY2ggdGhleSBhcmUgYWRkcmVzc2VkIHRvLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgcGVybWFuZW50bHkgcmVtb3ZlIHRoZSBtZXNzYWdlIGFuZCBhbGwgYXR0YWNoZWQgZmls ZXMgZnJvbSB0aGUgY29tcHV0ZXIuIEFueSBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1 dGlvbiBvZiBhbGwgb3IgYSBwYXJ0IG9mIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gdG8g b3IgYnkgdGhpcmQgcGFydGllcyBpcyBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIFBs ZWFzZSBub3RlIHRoYXQgYW55IHZpZXdzIG9yIG9waW5pb25zIHByZXNlbnRlZCBpbiB0aGlzIG1l c3NhZ2UgYXJlIHNvbGVseSB0aG9zZSBvZiB0aGUgYXV0aG9yIGFuZCBkbyBub3QgbmVjZXNzYXJp bHkgcmVwcmVzZW50IHRoZSB2aWV3cyBhbmQgb3BpbmlvbnMgb2YgQ3JvYXRpYW4gVGVsZWNvbSBJ bmMuIENyb2F0aWFuIFRlbGVjb20gSW5jLiBhY2NlcHRzIG5vIGxpYWJpbGl0eSBmb3IgYW55IHBv dGVudGlhbCBkYW1hZ2UgY2F1c2VkIGJ5IHRoaXMgbWVzc2FnZSBhbmQgZmlsZXMgYXR0YWNoZWQg dG8gaXQuIDwvRk9OVD48L1A+CjwvUD48L0RJVj4KPC9ib2R5Pgo8L2h0bWw+Cg== --_000_786F13AA11E69F4DB2CCA23F7400C2FB01464D5FS2010EXCH1adloc_-- From owen@delong.com Thu Jun 6 15:57:59 2013 Return-Path: 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 D30CB21F99FE; Thu, 6 Jun 2013 15:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 VPiWlS0SnTV3; Thu, 6 Jun 2013 15:57:58 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id B19E821F99FC; Thu, 6 Jun 2013 15:57:58 -0700 (PDT) Received: from [10.255.251.221] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r56Ms3Pv023866 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 6 Jun 2013 15:54:03 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r56Ms3Pv023866 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370559244; bh=XOC6aJPR8ro+Jbb4/SAmvP7Hdu4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=SA5hoKDz17nUDDu819T+QXxURVg5vDL6MxfHNWI2gsuqSHcSGDm/wA3Bb94VfGyU8 tL5lZTfbrlcaBGAGXRjAcv5/YVd0nGFE0vlw/lzdO+B+zdlLrdU6Eh6ST6dPVsGHbD 6ZDn11/OSpdj/4GNhZuoviIC8FSIQJ5C8c1YDXrQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: Date: Thu, 6 Jun 2013 17:54:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2FB6F4EA-F632-43E1-B7ED-A13338610746@delong.com> References: To: "Rajiv Asati (rajiva)" X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 06 Jun 2013 15:54:04 -0700 (PDT) X-Mailman-Approved-At: Fri, 07 Jun 2013 08:57:20 -0700 Cc: "Softwires-wg list \(softwires@ietf.org\)" , "v6ops@ietf.org" , "behave@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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, 06 Jun 2013 22:58:00 -0000 At the point where we start calling any form of NAT "non-degraded" = service, we have already strayed so far from rational thought that it is = difficult to believe any rational conclusion can come from it. ANY NAT is a degraded service. More NAT is inherently more degraded, = even if it doesn't suffer an additional lack of available port numbers. Owen On Jun 6, 2013, at 5:41 PM, "Rajiv Asati (rajiva)" = wrote: > Hi Dan, >=20 >> and so on. I am surprised you conclude that "500 seems ok" when such = a >> limit would interfere with your network use on those days. >=20 > I based that statement ("...seems ok,") on the very fact that the = number of times the NAT utilization exceeded 500 mappings (equating to = 500 ports, in my setup) in the sample period (~2 months) was relatively = quite low. So, if the NAT device was limited to only 500 mappings, then = the experience would have been ok for 99% of the time and degraded 1% of = the time. This is an important consideration, IMO. >=20 > For ex, in the last 2 weeks, the number of times NAT mappings exceeded = 500 were: >=20 > June 3 - 1 time > May 29 - 1 time > May 28 - 3 times > May 26 - 1 time > May 23 - 1 time > May 22 - 2 times > May 21 - 3 times >=20 > Of course, 1000 ports (resulting in 1000+ mappings) would have been = more than enough to accommodate the times when the mappings exceeded = 500, but stayed within 1000 (except once). >=20 >=20 >> What is the maximum number of mappings supported by your NAPT device? >> Some residential-class NATs have a limit of 1024 mappings. >=20 > My NAPT device seemingly can use upto 64K ports. :) >=20 > Cheers, > Rajiv >=20 >=20 >> -----Original Message----- >> From: Dan Wing (dwing) >> Sent: Thursday, June 06, 2013 11:43 AM >> To: Rajiv Asati (rajiva) >> Cc: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); >> behave@ietf.org; Erik Kline (ek@google.com) >> Subject: Re: [BEHAVE] Home NAPT44 - How many ports? >>=20 >>=20 >> On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva) = wrote: >>=20 >>> Some of you may recall our discussion (during the last IETF) around = "how >> many TCP/UDP ports are enough with NAPT44" per home, as ISPs move = into >> A+P paradigm. ~500, ~1000, ~3000??? >>>=20 >>> Well, I started monitoring my home router and plotting the NAPT44 = port >> utilization on a minute-by-minute basis. You may find it here - >> http://www.employees.org/~rajiva >>>=20 >>> In short, port range of 500 seems ok, though 1000 would be more than >> enough for my home. >>=20 >> I see several spikes in your data over 500 ports. During those = times, >> applications would be unable to function (unable to get a port). = April 29/30 >> is a long time where that occurs very visibly, but there are shorter = spikes >> elsewhere such as on April 17 and April 18. If you had only 500 = ports on >> those days, creating a new TCP mapping would have been impossible, >> impacting ability to send or receive email, order books from = Amazon.com, >> and so on. I am surprised you conclude that "500 seems ok" when such = a >> limit would interfere with your network use on those days. >>=20 >> What is the maximum number of mappings supported by your NAPT device? >> Some residential-class NATs have a limit of 1024 mappings. >>=20 >> -d >>=20 >>> Suffice to say, this is just a sample representation, since the port >> utilization would vary home to home, based on number of active = devices, >> type of applications, the degree of simultaneous device or = application >> usage etc. >>>=20 >>> If any of you are doing similar monitoring, then please share. >>>=20 >>> Cheers, >>> Rajiv >>>=20 >>> PS: Thanks to Erik Kline, who explained (with sufficient details) = how to use >> google charting for my data. And thanks to Xun Wang & Shaoshuai Dai = for >> helping me out significantly. >>>=20 >>> PS: My home has 3-4 active devices. >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From john.mann@monash.edu Thu Jun 6 17:03:08 2013 Return-Path: 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 2BC4E21F8F69 for ; Thu, 6 Jun 2013 17:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.376 X-Spam-Level: X-Spam-Status: No, score=-5.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] 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 pXxQJ2AVet9E for ; Thu, 6 Jun 2013 17:03:02 -0700 (PDT) Received: from na3sys009aog128.obsmtp.com (na3sys009aog128.obsmtp.com [74.125.149.141]) by ietfa.amsl.com (Postfix) with ESMTP id E56F921F8E89 for ; Thu, 6 Jun 2013 17:02:50 -0700 (PDT) Received: from mail-we0-f176.google.com ([74.125.82.176]) (using TLSv1) by na3sys009aob128.postini.com ([74.125.148.12]) with SMTP ID DSNKUbEjJfrtp0Oh38iVwUdksgI1WdcuTmoT@postini.com; Thu, 06 Jun 2013 17:02:54 PDT Received: by mail-we0-f176.google.com with SMTP id t56so2531445wes.7 for ; Thu, 06 Jun 2013 17:02:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=3kc58T8ylttI1qpEPU5Y+ebdfdTQ/WZquFtnPlGJLrU=; b=V87G+s4EvBwttPLmbUul2dbBNdisqro3AI0G/pWOvpqCN4nKaIWHf7/AYl8NAHDD/A F77xg3d92qkrwTt7hECgIsWxImLdO7TSUjkJqJZ7JNRXMCohnWr1ar5L0rc9xPi4Xu/3 85Wl5QqiWlxdg4KZsyKcOO3B5kgTjxA8ff6ENmyiP+NsCEHvqrhORgRJGr9aIvK/gAwR At/rA2XyQSEl+ysd1zQEOcFjgtxup5BCodUQsuzD194n+Yr756hhdBl0AHYfJy3BGLCR 7nuqADjV9xjJXZNHNtHM7qAh1OASN24Q6ZgsyhYGXK9GiATqXyZuUiROaZiikPojNQ5B UtTA== X-Received: by 10.180.206.176 with SMTP id lp16mr232132wic.43.1370563364469; Thu, 06 Jun 2013 17:02:44 -0700 (PDT) X-Received: by 10.180.206.176 with SMTP id lp16mr232123wic.43.1370563364344; Thu, 06 Jun 2013 17:02:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.112.201 with HTTP; Thu, 6 Jun 2013 17:02:24 -0700 (PDT) In-Reply-To: References: From: John Mann Date: Fri, 7 Jun 2013 10:02:24 +1000 Message-ID: To: "Rajiv Asati (rajiva)" Content-Type: multipart/alternative; boundary=001a11c37be079626904de8526d7 X-Gm-Message-State: ALoCoQnenmXLjr7ZKE4kvgbLy6TUvbwcqIMz84xhE75f9+iQ3hoNhdAp5qd/RC9nKusq3wVAsD9oBSztjL2ghr0PEsC5Sbghb97KnEqsujwtRaAoZhKcrFeefq5YVS+VHCujatecZKayBqfs8RvOeibzLYtASX8hSQ== X-Mailman-Approved-At: Fri, 07 Jun 2013 08:57:20 -0700 Cc: "Softwires-wg list \(softwires@ietf.org\)" , "v6ops@ietf.org" , "behave@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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, 07 Jun 2013 00:03:08 -0000 --001a11c37be079626904de8526d7 Content-Type: text/plain; charset=ISO-8859-1 Hi, On 7 June 2013 08:41, Rajiv Asati (rajiva) wrote: > Hi Dan, > > > and so on. I am surprised you conclude that "500 seems ok" when such a > > limit would interfere with your network use on those days. > > I based that statement ("...seems ok,") on the very fact that the number > of times the NAT utilization exceeded 500 mappings (equating to 500 ports, > in my setup) in the sample period (~2 months) was relatively quite low. So, > if the NAT device was limited to only 500 mappings, then the experience > would have been ok for 99% of the time and degraded 1% of the time. This is > an important consideration, IMO. > > For ex, in the last 2 weeks, the number of times NAT mappings exceeded 500 > were: > > June 3 - 1 time > May 29 - 1 time > May 28 - 3 times > May 26 - 1 time > May 23 - 1 time > May 22 - 2 times > May 21 - 3 times > I think a more-interesting statistic would be "how many connection setups would have failed". But I don't think you can measure that just by polling concurrent connections at specific times. It might take e.g. netflow exporting and analysis ... However "number of concurrent connections that couldn't have been setup" would be useful in gauging the impact e.g. on May 29 there was one spike of 734 concurrent connections, then report that as 234 potential failures. Of course, 1000 ports (resulting in 1000+ mappings) would have been more > than enough to accommodate the times when the mappings exceeded 500, but > stayed within 1000 (except once). > > > > What is the maximum number of mappings supported by your NAPT device? > > Some residential-class NATs have a limit of 1024 mappings. > Is that a combined limit of TCP and UDP and ICMP, or independent? My NAPT device seemingly can use upto 64K ports. :) > > Cheers, > Rajiv > > > > -----Original Message----- > > From: Dan Wing (dwing) > > Sent: Thursday, June 06, 2013 11:43 AM > > To: Rajiv Asati (rajiva) > > Cc: v6ops@ietf.org; Softwires-wg list (softwires@ietf.org); > > behave@ietf.org; Erik Kline (ek@google.com) > > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? > > > > > > On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva) > wrote: > > > > > Some of you may recall our discussion (during the last IETF) around > "how > > many TCP/UDP ports are enough with NAPT44" per home, as ISPs move into > > A+P paradigm. ~500, ~1000, ~3000??? > > > > > > Well, I started monitoring my home router and plotting the NAPT44 port > > utilization on a minute-by-minute basis. You may find it here - > > http://www.employees.org/~rajiva > > > > > > In short, port range of 500 seems ok, though 1000 would be more than > > enough for my home. > > > > I see several spikes in your data over 500 ports. During those times, > > applications would be unable to function (unable to get a port). April > 29/30 > > is a long time where that occurs very visibly, but there are shorter > spikes > > elsewhere such as on April 17 and April 18. If you had only 500 ports on > > those days, creating a new TCP mapping would have been impossible, > > impacting ability to send or receive email, order books from Amazon.com, > > and so on. I am surprised you conclude that "500 seems ok" when such a > > limit would interfere with your network use on those days. > > > > What is the maximum number of mappings supported by your NAPT device? > > Some residential-class NATs have a limit of 1024 mappings. > > > > -d > > > > > Suffice to say, this is just a sample representation, since the port > > utilization would vary home to home, based on number of active devices, > > type of applications, the degree of simultaneous device or application > > usage etc. > > > > > > If any of you are doing similar monitoring, then please share. > > > > > > Cheers, > > > Rajiv > > > > > > PS: Thanks to Erik Kline, who explained (with sufficient details) how > to use > > google charting for my data. And thanks to Xun Wang & Shaoshuai Dai for > > helping me out significantly. > > > > > > PS: My home has 3-4 active devices. > > > _______________________________________________ > > > Behave mailing list > > > Behave@ietf.org > > > https://www.ietf.org/mailman/listinfo/behave > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a11c37be079626904de8526d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

On 7 June 2013 08:41, Rajiv Asati (rajiva) <rajiva@cisco.com> wrote:
Hi Dan,

> and so on. =A0I am surprised you conclude that "500 seems ok"= ; when such a
> limit would interfere with your network use on those days.

I based that statement ("...seems ok,") on the very fact th= at the number of times the NAT utilization exceeded 500 mappings (equating = to 500 ports, in my setup) in the sample period (~2 months) was relatively = quite low. So, if the NAT device was limited to only 500 mappings, then the= experience would have been ok for 99% of the time and degraded 1% of the t= ime. This is an important consideration, IMO.

For ex, in the last 2 weeks, the number of times NAT mappings exceeded 500 = were:

June 3 - 1 time
May 29 - 1 time
May 28 - 3 times
May 26 - 1 time
May 23 - 1 time
May 22 - 2 times
May 21 - 3 times

I think a more-i= nteresting statistic would be "how many connection setups would have f= ailed".
But I don't think you can measure that jus= t by polling concurrent connections at specific times.
It might take e.g. netflow exporting and analysis ...

However "number of concurrent connections t= hat couldn't have been setup" would be useful in=A0gauging=A0the i= mpact
e.g. on May 29 there was one spike of 734 concurrent connections= , then report that as 234 potential failures.

Of course, 1000 ports (resulting in 1000+ mappings) would have been more th= an enough to accommodate the times when the mappings exceeded 500, but stay= ed within 1000 (except once).


> What is the maximum number of mappings supported by your NAPT device?<= br> > Some residential-class NATs have a limit of 1024 mappings.

Is that a combined limit of TCP and UD= P and ICMP, or independent?

My NAPT device seemingly can use upto 64K ports. :)

Cheers,
Rajiv


> -----Original Message-----
> From: Dan Wing (dwing)
> Sent: Thursday, June 06, 2013 11:43 AM
> To: Rajiv Asati (rajiva)
> Cc: v= 6ops@ietf.org; Softwires-wg list (softwires@ietf.org);
> behave@ietf.org; Erik Kline (ek@google.com)
> Subject: Re: [BEHAVE] Home NAPT44 - How many ports?
>
>
> On Jun 5, 2013, at 6:14 = AM, Rajiv Asati (rajiva) <rajiva@cis= co.com> wrote:
>
> > Some of you may recall our discussion (during the last IETF) arou= nd "how
> many TCP/UDP ports are enough with NAPT44" per home, as ISPs move= into
> A+P paradigm. ~500, ~1000, ~3000???
> >
> > Well, I started monitoring my home router and plotting the NAPT44= port
> utilization on a minute-by-minute basis. You may find it here -
> http://= www.employees.org/~rajiva
> >
> > In short, port range of 500 seems ok, though 1000 would be more t= han
> enough for my home.
>
> I see several spikes in your data over 500 ports. =A0During those time= s,
> applications would be unable to function (unable to get a port). =A0Ap= ril 29/30
> is a long time where that occurs very visibly, but there are shorter s= pikes
> elsewhere such as on April 17 and April 18. =A0If you had only 500 por= ts on
> those days, creating a new TCP mapping would have been impossible,
> impacting ability to send or receive email, order books from Amazon.co= m,
> and so on. =A0I am surprised you conclude that "500 seems ok"= ; when such a
> limit would interfere with your network use on those days.
>
> What is the maximum number of mappings supported by your NAPT device?<= br> > Some residential-class NATs have a limit of 1024 mappings.
>
> -d
>
> > Suffice to say, this is just a sample representation, since the p= ort
> utilization would vary home to home, based on number of active devices= ,
> type of applications, the degree of simultaneous device or application=
> usage etc.
> >
> > If any of you are doing similar monitoring, then please share. > >
> > Cheers,
> > Rajiv
> >
> > PS: Thanks to Erik Kline, who explained (with sufficient details)= how to use
> google charting for my data. And thanks to Xun Wang & Shaoshuai Da= i for
> helping me out significantly.
> >
> > PS: My home has 3-4 active devices.
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--001a11c37be079626904de8526d7-- From kristian.poscic@alcatel-lucent.com Fri Jun 7 10:49:44 2013 Return-Path: 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 7A48121F9968; Fri, 7 Jun 2013 10:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] 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 Gu0p-srhJXoZ; Fri, 7 Jun 2013 10:49:39 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1C58821F9962; Fri, 7 Jun 2013 10:49:38 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r57HgGSw022575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 7 Jun 2013 12:49:36 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r57G6Di4004375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Jun 2013 12:06:15 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.44]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Fri, 7 Jun 2013 12:06:13 -0400 From: "Poscic, Kristian (Kristian)" To: John Mann , "Rajiv Asati (rajiva)" Thread-Topic: [BEHAVE] [v6ops] Home NAPT44 - How many ports? Thread-Index: AQHOY5e9UtUF75OTtk6+SrU9uyYH2JkqaW8w Date: Fri, 7 Jun 2013 16:06:13 +0000 Message-ID: <7921F977B17D5B49B8DCC955A339D2F02AB410F8@US70UWXCHMBA05.zam.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_7921F977B17D5B49B8DCC955A339D2F02AB410F8US70UWXCHMBA05z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "Softwires-wg list \(softwires@ietf.org\)" , "v6ops@ietf.org" , "behave@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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, 07 Jun 2013 17:49:44 -0000 --_000_7921F977B17D5B49B8DCC955A339D2F02AB410F8US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable But why is this a problem in CGN? You initially allocate a port block of 500ports to the subscriber and then = they can dynamically extend this on as needed basis (allocate a new port bl= ock). To me the value of this exercise is to determine what will this initial por= t block size be, not at which point the service will be denied since this c= an be easily extended. For RGs, it is what it is, if they have the limit of 500mapping, then yes, = this is the problem. But for CGN it shouldn't be. From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= John Mann Sent: Thursday, June 06, 2013 5:02 PM To: Rajiv Asati (rajiva) Cc: Softwires-wg list (softwires@ietf.org); v6ops@ietf.org; behave@ietf.org= ; Dan Wing (dwing) Subject: Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports? Hi, On 7 June 2013 08:41, Rajiv Asati (rajiva) > wrote: Hi Dan, > and so on. I am surprised you conclude that "500 seems ok" when such a > limit would interfere with your network use on those days. I based that statement ("...seems ok,") on the very fact that the number of= times the NAT utilization exceeded 500 mappings (equating to 500 ports, in= my setup) in the sample period (~2 months) was relatively quite low. So, i= f the NAT device was limited to only 500 mappings, then the experience woul= d have been ok for 99% of the time and degraded 1% of the time. This is an = important consideration, IMO. For ex, in the last 2 weeks, the number of times NAT mappings exceeded 500 = were: June 3 - 1 time May 29 - 1 time May 28 - 3 times May 26 - 1 time May 23 - 1 time May 22 - 2 times May 21 - 3 times I think a more-interesting statistic would be "how many connection setups w= ould have failed". But I don't think you can measure that just by polling concurrent connectio= ns at specific times. It might take e.g. netflow exporting and analysis ... However "number of concurrent connections that couldn't have been setup" wo= uld be useful in gauging the impact e.g. on May 29 there was one spike of 734 concurrent connections, then repo= rt that as 234 potential failures. Of course, 1000 ports (resulting in 1000+ mappings) would have been more th= an enough to accommodate the times when the mappings exceeded 500, but stay= ed within 1000 (except once). > What is the maximum number of mappings supported by your NAPT device? > Some residential-class NATs have a limit of 1024 mappings. Is that a combined limit of TCP and UDP and ICMP, or independent? My NAPT device seemingly can use upto 64K ports. :) Cheers, Rajiv > -----Original Message----- > From: Dan Wing (dwing) > Sent: Thursday, June 06, 2013 11:43 AM > To: Rajiv Asati (rajiva) > Cc: v6ops@ietf.org; Softwires-wg list (softwires@i= etf.org); > behave@ietf.org; Erik Kline (ek@google.com) > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? > > > On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva) > wrote: > > > Some of you may recall our discussion (during the last IETF) around "ho= w > many TCP/UDP ports are enough with NAPT44" per home, as ISPs move into > A+P paradigm. ~500, ~1000, ~3000??? > > > > Well, I started monitoring my home router and plotting the NAPT44 port > utilization on a minute-by-minute basis. You may find it here - > http://www.employees.org/~rajiva > > > > In short, port range of 500 seems ok, though 1000 would be more than > enough for my home. > > I see several spikes in your data over 500 ports. During those times, > applications would be unable to function (unable to get a port). April 2= 9/30 > is a long time where that occurs very visibly, but there are shorter spik= es > elsewhere such as on April 17 and April 18. If you had only 500 ports on > those days, creating a new TCP mapping would have been impossible, > impacting ability to send or receive email, order books from Amazon.com, > and so on. I am surprised you conclude that "500 seems ok" when such a > limit would interfere with your network use on those days. > > What is the maximum number of mappings supported by your NAPT device? > Some residential-class NATs have a limit of 1024 mappings. > > -d > > > Suffice to say, this is just a sample representation, since the port > utilization would vary home to home, based on number of active devices, > type of applications, the degree of simultaneous device or application > usage etc. > > > > If any of you are doing similar monitoring, then please share. > > > > Cheers, > > Rajiv > > > > PS: Thanks to Erik Kline, who explained (with sufficient details) how t= o use > google charting for my data. And thanks to Xun Wang & Shaoshuai Dai for > helping me out significantly. > > > > PS: My home has 3-4 active devices. > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_7921F977B17D5B49B8DCC955A339D2F02AB410F8US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

But why is this a problem= in CGN?

You initially allocate a = port block of 500ports to the subscriber and then they can dynamically exte= nd this on as needed basis (allocate a new port block).

 <= /p>

To me the value of this e= xercise is to determine what will this initial port block size be, not at w= hich point the service will be denied since this can be easily extended.

 <= /p>

For RGs, it is what it is= , if they have the limit of 500mapping, then yes, this is the problem.=

But for CGN it shouldn= 217;t be.

 <= /p>

From: behave-b= ounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of John Mann
Sent: Thursday, June 06, 2013 5:02 PM
To: Rajiv Asati (rajiva)
Cc: Softwires-wg list (softwires@ietf.org); v6ops@ietf.org; behave@i= etf.org; Dan Wing (dwing)
Subject: Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports?

 

Hi,

 

On 7 June 2013 08:41, Rajiv Asati (rajiva) <rajiva@cisco.com> w= rote:

Hi Dan,


> and so on.  I am surprised you conclude that "500 seems ok&q= uot; when such a
> limit would interfere with your network use on those days.<= /p>

I based that statement ("...seems ok,") on= the very fact that the number of times the NAT utilization exceeded 500 ma= ppings (equating to 500 ports, in my setup) in the sample period (~2 months= ) was relatively quite low. So, if the NAT device was limited to only 500 mappings, then the experience would have been ok f= or 99% of the time and degraded 1% of the time. This is an important consid= eration, IMO.

For ex, in the last 2 weeks, the number of times NAT mappings exceeded 500 = were:

June 3 - 1 time
May 29 - 1 time
May 28 - 3 times
May 26 - 1 time
May 23 - 1 time
May 22 - 2 times
May 21 - 3 times

 

I think a more-interesting statistic would be "= how many connection setups would have failed".

But I don't think you can measure that just by polli= ng concurrent connections at specific times.

It might take e.g. netflow exporting and analysis ..= .

 

However "number of concurrent connections that = couldn't have been setup" would be useful in gauging the imp= act

e.g. on May 29 there was one spike of 734 concurrent= connections, then report that as 234 potential failures.

 

Of course, 1000 ports (resulting in 1000+ mappin= gs) would have been more than enough to accommodate the times when the mapp= ings exceeded 500, but stayed within 1000 (except once).



> What is the maximum number of mappings supported by your NAPT device?<= br> > Some residential-class NATs have a limit of 1024 mappings.<= /p>

 

Is that a combined limit of TCP and UDP and ICMP, or= independent?

 

My NAPT device seemingly can use upto 64K ports. :)<= br>
Cheers,
Rajiv



> -----Original Message-----
> From: Dan Wing (dwing)
> Sent: Thursday, June 06, 2013 11:43 AM
> To: Rajiv Asati (rajiva)

> Cc: v6ops@iet= f.org; Softwires-wg list (softwir= es@ietf.org);
> behave@ietf.org; Erik Kline (ek@google.com)
> Subject: Re: [BEHAVE] Home NAPT44 - How many ports?
>
>

> On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva= ) <rajiva@cisco.com> wrote: >
> > Some of you may recall our discussion (during the last IETF) arou= nd "how
> many TCP/UDP ports are enough with NAPT44" per home, as ISPs move= into
> A+P paradigm. ~500, ~1000, ~3000???
> >
> > Well, I started monitoring my home router and plotting the NAPT44= port
> utilization on a minute-by-minute basis. You may find it here -
> http://= www.employees.org/~rajiva
> >
> > In short, port range of 500 seems ok, though 1000 would be more t= han
> enough for my home.
>
> I see several spikes in your data over 500 ports.  During those t= imes,
> applications would be unable to function (unable to get a port).  = ;April 29/30
> is a long time where that occurs very visibly, but there are shorter s= pikes
> elsewhere such as on April 17 and April 18.  If you had only 500 = ports on
> those days, creating a new TCP mapping would have been impossible,
> impacting ability to send or receive email, order books from Amazon.co= m,
> and so on.  I am surprised you conclude that "500 seems ok&q= uot; when such a
> limit would interfere with your network use on those days.
>
> What is the maximum number of mappings supported by your NAPT device?<= br> > Some residential-class NATs have a limit of 1024 mappings.
>
> -d
>
> > Suffice to say, this is just a sample representation, since the p= ort
> utilization would vary home to home, based on number of active devices= ,
> type of applications, the degree of simultaneous device or application=
> usage etc.
> >
> > If any of you are doing similar monitoring, then please share. > >
> > Cheers,
> > Rajiv
> >
> > PS: Thanks to Erik Kline, who explained (with sufficient details)= how to use
> google charting for my data. And thanks to Xun Wang & Shaoshuai Da= i for
> helping me out significantly.
> >
> > PS: My home has 3-4 active devices.
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

 

--_000_7921F977B17D5B49B8DCC955A339D2F02AB410F8US70UWXCHMBA05z_-- From repenno@cisco.com Fri Jun 7 11:09:14 2013 Return-Path: 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 EF25C21F9600; Fri, 7 Jun 2013 11:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] 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 gBGr+x+1mzqF; Fri, 7 Jun 2013 11:09:08 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF7321F8F6E; Fri, 7 Jun 2013 11:09:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20455; q=dns/txt; s=iport; t=1370628548; x=1371838148; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=ndEDmyQo9qlHKOw7hms0yEu0UUNZRTfZAnGj/jkBQ7I=; b=BXp/RoWewM3LprHPGBAp3OqnKesd1+R4XSRPtXbnf6+s9eOcINwhLSAq dq//fqCfNq1AdwIDywJA+nKfFtuvJl+QzMHqG3aJCQkuX88FMaeMaNzfj Fw9IHrARfILxpgnWDftXymyb6Sz3JlsT76FKV5+GvgJau6fDBXvaOSiD9 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFACAhslGtJV2b/2dsb2JhbABZDgiCL0Qwvm+BABZ0giMBAQEDAQEBASpBCwUHBgEIEQMBAQEBCh0uCxQJCAIEAQ0FCAGHfgYMvHKNdgEJAYEGIA0EBgEGgnVhA5Nuj3OFIYJRPoFoAQgXHw X-IronPort-AV: E=Sophos;i="4.87,823,1363132800"; d="scan'208,217";a="220192563" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 07 Jun 2013 18:09:07 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r57I97vW024157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Jun 2013 18:09:07 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Fri, 7 Jun 2013 13:09:06 -0500 From: "Reinaldo Penno (repenno)" To: "Poscic, Kristian (Kristian)" , "John Mann" , "Rajiv Asati (rajiva)" Thread-Topic: [BEHAVE] [v6ops] Home NAPT44 - How many ports? Thread-Index: AQHOY5e6wCO8rb0sYUquZ4EU6EXcyJkqvn+A///wB4A= Date: Fri, 7 Jun 2013 18:09:06 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A28CA@xmb-rcd-x04.cisco.com> In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F02AB410F8@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.253.76] Content-Type: multipart/alternative; boundary="_000_45A697A8FFD7CF48BCF2BE7E106F0604090A28CAxmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "Softwires-wg list \(softwires@ietf.org\)" , "v6ops@ietf.org" , "behave@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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, 07 Jun 2013 18:09:14 -0000 --_000_45A697A8FFD7CF48BCF2BE7E106F0604090A28CAxmbrcdx04ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable There are certain port allocation methods where extending the port block is= tricky, such as (Stateless) Deterministic NAT. From: "Poscic, Kristian (Kristian)" > Date: Fri, 7 Jun 2013 16:06:13 +0000 To: John Mann >, "Rajiv A= sati (rajiva)" > Cc: "Softwires-wg list (softwires@ietf.org)" >, "v6ops@ietf.org" >, "behave@ietf.org" >, "Dan Wing (dw= ing)" > Subject: Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports? But why is this a problem in CGN? You initially allocate a port block of 500ports to the subscriber and then = they can dynamically extend this on as needed basis (allocate a new port bl= ock). To me the value of this exercise is to determine what will this initial por= t block size be, not at which point the service will be denied since this c= an be easily extended. For RGs, it is what it is, if they have the limit of 500mapping, then yes, = this is the problem. But for CGN it shouldn=92t be. From: behave-bounces@ietf.org [mailto:behav= e-bounces@ietf.org] On Behalf Of John Mann Sent: Thursday, June 06, 2013 5:02 PM To: Rajiv Asati (rajiva) Cc: Softwires-wg list (softwires@ietf.org); v6op= s@ietf.org; behave@ietf.org;= Dan Wing (dwing) Subject: Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports? Hi, On 7 June 2013 08:41, Rajiv Asati (rajiva) > wrote: Hi Dan, > and so on. I am surprised you conclude that "500 seems ok" when such a > limit would interfere with your network use on those days. I based that statement ("...seems ok,") on the very fact that the number of= times the NAT utilization exceeded 500 mappings (equating to 500 ports, in= my setup) in the sample period (~2 months) was relatively quite low. So, i= f the NAT device was limited to only 500 mappings, then the experience woul= d have been ok for 99% of the time and degraded 1% of the time. This is an = important consideration, IMO. For ex, in the last 2 weeks, the number of times NAT mappings exceeded 500 = were: June 3 - 1 time May 29 - 1 time May 28 - 3 times May 26 - 1 time May 23 - 1 time May 22 - 2 times May 21 - 3 times I think a more-interesting statistic would be "how many connection setups w= ould have failed". But I don't think you can measure that just by polling concurrent connectio= ns at specific times. It might take e.g. netflow exporting and analysis ... However "number of concurrent connections that couldn't have been setup" wo= uld be useful in gauging the impact e.g. on May 29 there was one spike of 734 concurrent connections, then repo= rt that as 234 potential failures. Of course, 1000 ports (resulting in 1000+ mappings) would have been more th= an enough to accommodate the times when the mappings exceeded 500, but stay= ed within 1000 (except once). > What is the maximum number of mappings supported by your NAPT device? > Some residential-class NATs have a limit of 1024 mappings. Is that a combined limit of TCP and UDP and ICMP, or independent? My NAPT device seemingly can use upto 64K ports. :) Cheers, Rajiv > -----Original Message----- > From: Dan Wing (dwing) > Sent: Thursday, June 06, 2013 11:43 AM > To: Rajiv Asati (rajiva) > Cc: v6ops@ietf.org; Softwires-wg list (softwires@i= etf.org); > behave@ietf.org; Erik Kline (ek@google.com) > Subject: Re: [BEHAVE] Home NAPT44 - How many ports? > > > On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva) > wrote: > > > Some of you may recall our discussion (during the last IETF) around "ho= w > many TCP/UDP ports are enough with NAPT44" per home, as ISPs move into > A+P paradigm. ~500, ~1000, ~3000??? > > > > Well, I started monitoring my home router and plotting the NAPT44 port > utilization on a minute-by-minute basis. You may find it here - > http://www.employees.org/~rajiva > > > > In short, port range of 500 seems ok, though 1000 would be more than > enough for my home. > > I see several spikes in your data over 500 ports. During those times, > applications would be unable to function (unable to get a port). April 2= 9/30 > is a long time where that occurs very visibly, but there are shorter spik= es > elsewhere such as on April 17 and April 18. If you had only 500 ports on > those days, creating a new TCP mapping would have been impossible, > impacting ability to send or receive email, order books from Amazon.com, > and so on. I am surprised you conclude that "500 seems ok" when such a > limit would interfere with your network use on those days. > > What is the maximum number of mappings supported by your NAPT device? > Some residential-class NATs have a limit of 1024 mappings. > > -d > > > Suffice to say, this is just a sample representation, since the port > utilization would vary home to home, based on number of active devices, > type of applications, the degree of simultaneous device or application > usage etc. > > > > If any of you are doing similar monitoring, then please share. > > > > Cheers, > > Rajiv > > > > PS: Thanks to Erik Kline, who explained (with sufficient details) how t= o use > google charting for my data. And thanks to Xun Wang & Shaoshuai Dai for > helping me out significantly. > > > > PS: My home has 3-4 active devices. > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ Behave mailing list Behave@= ietf.org https://www.ietf.org/mailman/listinfo/beha= ve --_000_45A697A8FFD7CF48BCF2BE7E106F0604090A28CAxmbrcdx04ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
There are certain port allocation methods where extending the port blo= ck is tricky, such as (Stateless) Deterministic NAT.


From: "Poscic, Kristian (Krist= ian)" <kristi= an.poscic@alcatel-lucent.com>
Date: Fri, 7 Jun 2013 16:06:13 += ;0000
To: John Mann <john.mann@monash.edu>, "Rajiv Asati (raj= iva)" <rajiva@cisco.com>=
Cc: "Softwires-wg list (softwires@ietf.org)" <softwires@ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>, "behave@ietf.org" <behave@ietf.org>, "Dan Wing (dw= ing)" <dwing@cisco.com> Subject: Re: [BEHAVE] [v6ops] Home = NAPT44 - How many ports?

But why is this a problem in CGN?<= o:p>

You initially allocate a port bloc= k of 500ports to the subscriber and then they can dynamically extend this o= n as needed basis (allocate a new port block).

 

To me the value of this exercise i= s to determine what will this initial port block size be, not at which poin= t the service will be denied since this can be easily extended.

 

For RGs, it is what it is, if they= have the limit of 500mapping, then yes, this is the problem.

But for CGN it shouldn=92t be.

 

From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of John Mann
Sent: Thursday, June 06, 2013 5:02 PM
To: Rajiv Asati (rajiva)
Cc: Softwires-wg list (softwir= es@ietf.org); v6ops@ietf.org; behave@ietf.org; Dan Wing (dwing)
Subject: Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports?

 

Hi,

 

On 7 June 2013 08:41, Rajiv Asati (rajiva) <rajiva@cisco.com> w= rote:

Hi Dan,


> and so on.  I am surprised you conclude that "500 seems ok&q= uot; when such a
> limit would interfere with your network use on those days.<= /p>

I based that statement ("...seems ok,") on= the very fact that the number of times the NAT utilization exceeded 500 ma= ppings (equating to 500 ports, in my setup) in the sample period (~2 months= ) was relatively quite low. So, if the NAT device was limited to only 500 mappings, then the experience would have been ok f= or 99% of the time and degraded 1% of the time. This is an important consid= eration, IMO.

For ex, in the last 2 weeks, the number of times NAT mappings exceeded 500 = were:

June 3 - 1 time
May 29 - 1 time
May 28 - 3 times
May 26 - 1 time
May 23 - 1 time
May 22 - 2 times
May 21 - 3 times

 

I think a more-interesting statistic would be "= how many connection setups would have failed".

But I don't think you can measure that just by polli= ng concurrent connections at specific times.

It might take e.g. netflow exporting and analysis ..= .

 

However "number of concurrent connections that = couldn't have been setup" would be useful in gauging the imp= act

e.g. on May 29 there was one spike of 734 concurrent= connections, then report that as 234 potential failures.

 

Of course, 1000 ports (resulting in 1000+ mappin= gs) would have been more than enough to accommodate the times when the mapp= ings exceeded 500, but stayed within 1000 (except once).



> What is the maximum number of mappings supported by your NAPT device?<= br> > Some residential-class NATs have a limit of 1024 mappings.<= /p>

 

Is that a combined limit of TCP and UDP and ICMP, or= independent?

 

My NAPT device seemingly can use upto 64K ports. :)<= br>
Cheers,
Rajiv



> -----Original Message-----
> From: Dan Wing (dwing)
> Sent: Thursday, June 06, 2013 11:43 AM
> To: Rajiv Asati (rajiva)

> Cc: v6ops@iet= f.org; Softwires-wg list (softwir= es@ietf.org);
> behave@ietf.org; Erik Kline (ek@google.com)
> Subject: Re: [BEHAVE] Home NAPT44 - How many ports?
>
>

> On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva= ) <rajiva@cisco.com> wrote: >
> > Some of you may recall our discussion (during the last IETF) arou= nd "how
> many TCP/UDP ports are enough with NAPT44" per home, as ISPs move= into
> A+P paradigm. ~500, ~1000, ~3000???
> >
> > Well, I started monitoring my home router and plotting the NAPT44= port
> utilization on a minute-by-minute basis. You may find it here -
> http://= www.employees.org/~rajiva
> >
> > In short, port range of 500 seems ok, though 1000 would be more t= han
> enough for my home.
>
> I see several spikes in your data over 500 ports.  During those t= imes,
> applications would be unable to function (unable to get a port).  = ;April 29/30
> is a long time where that occurs very visibly, but there are shorter s= pikes
> elsewhere such as on April 17 and April 18.  If you had only 500 = ports on
> those days, creating a new TCP mapping would have been impossible,
> impacting ability to send or receive email, order books from Amazon.co= m,
> and so on.  I am surprised you conclude that "500 seems ok&q= uot; when such a
> limit would interfere with your network use on those days.
>
> What is the maximum number of mappings supported by your NAPT device?<= br> > Some residential-class NATs have a limit of 1024 mappings.
>
> -d
>
> > Suffice to say, this is just a sample representation, since the p= ort
> utilization would vary home to home, based on number of active devices= ,
> type of applications, the degree of simultaneous device or application=
> usage etc.
> >
> > If any of you are doing similar monitoring, then please share. > >
> > Cheers,
> > Rajiv
> >
> > PS: Thanks to Erik Kline, who explained (with sufficient details)= how to use
> google charting for my data. And thanks to Xun Wang & Shaoshuai Da= i for
> helping me out significantly.
> >
> > PS: My home has 3-4 active devices.
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

 

_______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave --_000_45A697A8FFD7CF48BCF2BE7E106F0604090A28CAxmbrcdx04ciscoc_-- From jhw@apple.com Fri Jun 7 18:11:03 2013 Return-Path: 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 4311D21F99CD for ; Fri, 7 Jun 2013 18:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 OmziOMiTPdX0 for ; Fri, 7 Jun 2013 18:10:57 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 14BAC21F9972 for ; Fri, 7 Jun 2013 18:10:57 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MO100MY7VA8H4R1@mail-out.apple.com> for behave@ietf.org; Fri, 07 Jun 2013 18:10:56 -0700 (PDT) X-AuditID: 11807158-b7f486d0000079b6-0d-51b284a09c56 Received: from [17.113.32.202] (Unknown_Domain [17.113.32.202]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 19.7B.31158.0A482B15; Fri, 07 Jun 2013 18:10:56 -0700 (PDT) From: james woodyatt In-reply-to: <51B03A65.6040701@viagenie.ca> Date: Fri, 07 Jun 2013 18:10:55 -0700 Message-id: <5309D333-092B-45C6-B57B-8F6AB5AEF185@apple.com> References: <45A697A8FFD7CF48BCF2BE7E106F0604090A0A82@xmb-rcd-x04.cisco.com> <51AF805D.4000101@nttv6.jp> <51B03A65.6040701@viagenie.ca> To: behave@ietf.org X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphluLIzCtJLcpLzFFi42IRLFQ4pbugZVOgweUXBhZTF15hd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvH5K5gKzjNVnJ1xhLWBsYmpi5GTQ0LAROL+qXdsELaYxIV7 64FsLg4hgV4miamP3oIVMQvoSOzcegesiFdAT2LpvzmMXYwcHMICxhKLTrmBhNkEVCS+Xb4L Vs4poC1xYMpOMJsFKL6hexUjxBhtiWULXzNDjLGR2PbtIRPErhOMEkdebGcFSYgICEvc+P2M BWS+hICsxM7fSRMY+WYhuWIWkitmIRm7gJF5FaNAUWpOYqWpXmJBQU6qXnJ+7iZGUBg1FEbs YPy/zOoQowAHoxIP7w6TTYFCrIllxZW5hxglOJiVRHgbN20MFOJNSaysSi3Kjy8qzUktPsQo zcGiJM4bVQhULZCeWJKanZpakFoEk2Xi4JRqYOxXmzVBV8XIKqjJjXNVcWX44q64tOgpfaG8 Ot27Vho3bazQbhbNPHFT5IpyYmHVh1ADq2Vm/F+3JkQf69L81qX6XSvm3oEjxX/ZKvOffzB5 uM5iVmC6UuXNaac+Gvte5NewFT/xZ0/JzcKPm1fpd0y/Y1yyTSFm548Qt8S7C3YxnngaK+V9 X4mlOCPRUIu5qDgRAMVEKWcfAgAA Subject: Re: [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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: Sat, 08 Jun 2013 01:11:03 -0000 On Jun 6, 2013, at 00:29 , Simon Perreault wrote: > And HTTP doesn't need EIM for NAT traversal. You're going to make me send a PCP requests to get EI mappings for my TCP state in the NAT? Or will that even be allowed anymore? -- james woodyatt core os networking From simon.perreault@viagenie.ca Mon Jun 10 05:46:36 2013 Return-Path: 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 EDE2321F86B2 for ; Mon, 10 Jun 2013 05:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 A0YP6aSaKFx1 for ; Mon, 10 Jun 2013 05:46:34 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF6A21F8481 for ; Mon, 10 Jun 2013 05:38:49 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:975:db0c:5b8b:bf26]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7C15D4044B for ; Mon, 10 Jun 2013 08:38:31 -0400 (EDT) Message-ID: <51B5C8C5.5030006@viagenie.ca> Date: Mon, 10 Jun 2013 14:38:29 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: behave@ietf.org References: <45A697A8FFD7CF48BCF2BE7E106F0604090A0A82@xmb-rcd-x04.cisco.com> <51AF805D.4000101@nttv6.jp> <51B03A65.6040701@viagenie.ca> <5309D333-092B-45C6-B57B-8F6AB5AEF185@apple.com> In-Reply-To: <5309D333-092B-45C6-B57B-8F6AB5AEF185@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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: Mon, 10 Jun 2013 12:46:36 -0000 Le 2013-06-08 03:10, james woodyatt a écrit : > On Jun 6, 2013, at 00:29 , Simon Perreault wrote: > >> And HTTP doesn't need EIM for NAT traversal. > > You're going to make me send a PCP requests to get EI mappings for my TCP state in the NAT? No, I'm suggesting that a NAT could by itself decide to use EDM for HTTP flows. There's no PCP here, and nothing to change on the clients. Simon From simon.perreault@viagenie.ca Mon Jun 10 05:46:43 2013 Return-Path: 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 551BB21F8EF7 for ; Mon, 10 Jun 2013 05:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 EOGR2ebpQBku for ; Mon, 10 Jun 2013 05:46:41 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC8621F84F5 for ; Mon, 10 Jun 2013 05:42:37 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:975:db0c:5b8b:bf26]) by jazz.viagenie.ca (Postfix) with ESMTPSA id CC3BE4044B for ; Mon, 10 Jun 2013 08:41:27 -0400 (EDT) Message-ID: <51B5C977.50700@viagenie.ca> Date: Mon, 10 Jun 2013 14:41:27 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: behave@ietf.org References: <45A697A8FFD7CF48BCF2BE7E106F0604090A28CA@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090A28CA@xmb-rcd-x04.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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: Mon, 10 Jun 2013 12:46:43 -0000 Le 2013-06-07 20:09, Reinaldo Penno (repenno) a écrit : > There are certain port allocation methods where extending the port block > is tricky, such as (Stateless) Deterministic NAT. ...or simply impossible, if you just statically allocate port blocks. Simon From ivan@cacaoweb.org Sun Jun 16 12:13:32 2013 Return-Path: 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 5C09221F9B10 for ; Sun, 16 Jun 2013 12:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 0G6w26GN+rb8 for ; Sun, 16 Jun 2013 12:13:28 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id BCA9621F9B12 for ; Sun, 16 Jun 2013 12:13:27 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1UoIP2-0006zX-HO for behave@ietf.org; Sun, 16 Jun 2013 21:14:16 +0200 To: X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_53505bc5841078ca128b127b021f622a" Date: Sun, 16 Jun 2013 21:14:16 +0200 From: ivan c Organization: cacaoweb Message-ID: <3a724be2431cf7249b3d46cf378f85bf@cacaoweb.org> X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Subject: [BEHAVE] review of draft-penno-behave-rfc4787-5382-5508-bis 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jun 2013 19:28:49 -0000 --=_53505bc5841078ca128b127b021f622a Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hello, This is my review of draft-penno-behave-rfc4787-5382-5508-bis [1], which is indeed a step in the right direction and corrects omissions and unspecified behaviors left by previous documents. I support its adoption as a working group document. * 3.1.2.1. Rewrite timestamp and sequence number values at NAT Requiring NATs to rewrite timestamps and ISNs seems overkill. Generally, mangling with the TCP protocol header other than by rewriting the source endpoint should not be done by NATs. On the other hand, improving the current situation regarding the TIME_WAIT state by carefully designed filtering rules without altering the TCP header seems acceptable. * 4. Port overlapping behavior This is becoming a pressing issue due to increase deployment of CGNs for IPv4 worldwide. As far as I know, the traditional term to describe this behavior is "port overloading". The term overlapping refers to when two sets have a non empty intersection (they are said to be "overlapping" sets). Overloading is the correct term and was previously used in RFC5382 and RFC4787. Port overloading is problematic for UDP, as P2P applications generally multiplex several UDP communications over the same socket. The probability that two internal peers communicate to the same remote endpoint can be non-negligeable, depending on the number of UDP communications and characteristics intrinsic to the p2p application. See Birthday Paradox. For TCP, this problem does not arise nrealy as much as there is a one-to-one mapping between sockets and TCP communications (POSIX does not allow to bind multiple sockets to the same local endpoint for outbound connections). Thus the probability for conflict is much lower. [RFC5382] REQ-1 indeed requires EIM, but it is important to note that the EIM behavior is required by applications that rely on a POSIX "hack", that is the set up of the SO_REUSEADDR option on the socket to bind two successive outbound connections on the same local endpoint. This hack is controversial and thus [RFC5382] REQ-1 is subject to controversy, for the following reasons: SO_REUSEADDR behavior is left unspecified by POSIX. SO_REUSEADDR is generally implemented by OSes to bypass the TIME_WAIT state for network servers. It violates TCP quiet time, TIME_WAIT and can lead to data corruption. It should generally only be used by listening servers, not client making outbound connections. Its use is discouraged in production for listening servers. RFC 6528. A correct way to achieve TCP port prediction (which is what [RFC5382] REQ-1 is really about without saying it) without relying on POSIX hacks is to require the NAT to be port-preserving. Port prediction is straightforward in the case of port preservation. It also works nicely with port overloading, and allows p2p applications to work without the need of a third party public server for each TCP communication instantiation. Thus it allows NAT traversal for fully decentralized p2p applications. Most NATs in the wild implement TCP port preservation for this reason. * End of page 8 The external references provided point to a website written only in japanese. It would be nice to provide a pointer to the english version of these web pages. * 6. EIF Security Indeed, EIF poses security concerns. At the very least, use of Address-Dependent Filtering should be recommended. Applications requiring EIF to function are clearly badly designed and it is not the role of an RFC to support incorrect designs. * 7. EIF Protocol Independence Do you have any reasonable use for this? In other words, a situation where to punch a UDP hole in a NAT, you want to send a TCP SYN first? (If that's the case, why not sending a UDP packet instead of a TCP SYN...?). If not, it would be cleaner in my opinion to leave this requirement out. If yes, it would be nicer to describe the real-world use, as i'm sure most of us are not familiar with it. * 8. EIF Mapping Refresh (This really only applies to UDP. For TCP, NATs simply keep the mapping as long as the connection is considered on from TCP point of view.) Agreed, [RFC4787]: REQ-6 is too liberal regarding mapping refreshes. It would be better to recommend Address-Dependent Filtering and Address-Dependent mapping refreshes. 8.1 Agreed, this point has definitely been overlooked too by RFC5382 * 9. EIM Protocol Independence Agreed * 11. Port Randomization Agreed, although it doesn't alleviate the fact the port randomization should be implemented by the client OS in the first place. The NAT role is not to harden TCP security. And as you note, this cannot be implemented if the NAT is TCP port preserving, which makes up the majority of NATs in the wild. -- _Ivan C._ Links: ------ [1] http://www.ietf.org/mail-archive/web/behave/current/msg10831.html --=_53505bc5841078ca128b127b021f622a Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hello,

This is my review of draft-penno-behave-rfc4787-5382-5= 508-bis, which is indeed a step in the right direction and corrects omi= ssions and unspecified behaviors left by previous documents. I support its = adoption as a working group document.

 

 


* 3.1.2.1. Rewrite timestamp and sequence number values at NAT

Requiring NATs to rewrite timestamps and ISNs seems overkill. Gener= ally, mangling with the TCP protocol header other than by rewriting the sou= rce endpoint should not be done by NATs.
On the other hand, improving = the current situation regarding the TIME_WAIT state by carefully designed f= iltering rules without altering the TCP header seems acceptable.


* 4. Port overlapping behavior

This is becoming a pressin= g issue due to increase deployment of CGNs for IPv4 worldwide.
As far = as I know, the traditional term to describe this behavior is "port overload= ing". The term overlapping refers to when two sets have a non empty interse= ction (they are said to be "overlapping" sets). Overloading is the correct = term and was previously used in RFC5382 and RFC4787.
Port overloading = is problematic for UDP, as P2P applications generally multiplex several UDP= communications over the same socket. The probability that two internal pee= rs communicate to the same remote endpoint can be non-negligeable, dependin= g on the number of UDP communications and characteristics intrinsic to the = p2p application. See Birthday Paradox.
For TCP, this problem does not = arise nrealy as much as there is a one-to-one mapping between sockets and T= CP communications (POSIX does not allow to bind multiple sockets to the sam= e local endpoint for outbound connections). Thus the probability for confli= ct is much lower.

[RFC5382] REQ-1 indeed requires EIM, but it is= important to note that the EIM behavior is required by applications that r= ely on a POSIX "hack", that is the set up of the SO_REUSEADDR option on the= socket to bind two successive outbound connections on the same local endpo= int. This hack is controversial and thus [RFC5382] REQ-1 is subject to cont= roversy, for the following reasons: SO_REUSEADDR behavior is left unspecifi= ed by POSIX. SO_REUSEADDR is generally implemented by OSes to bypass the TI= ME_WAIT state for network servers. It violates TCP quiet time, TIME_WAIT an= d can lead to data corruption. It should generally only be used by listenin= g servers, not client making outbound connections. Its use is discouraged i= n production for listening servers. RFC 6528.

A correct way to a= chieve TCP port prediction (which is what [RFC5382] REQ-1 is really about w= ithout saying it) without relying on POSIX hacks is to require the NAT to b= e port-preserving. Port prediction is straightforward in the case of port p= reservation. It also works nicely with port overloading, and allows p2p app= lications to work without the need of a third party public server for each = TCP communication instantiation. Thus it allows NAT traversal for fully dec= entralized p2p applications. Most NATs in the wild implement TCP port prese= rvation for this reason.


* End of page 8

The e= xternal references provided point to a website written only in japanese. It= would be nice to provide a pointer to the english version of these web pag= es.


* 6. EIF Security

Indeed, EIF poses securit= y concerns. At the very least, use of Address-Dependent Filtering should be= recommended. Applications requiring EIF to function are clearly badly desi= gned and it is not the role of an RFC to support incorrect designs.

* 7. EIF Protocol Independence

Do you have any reasona= ble use for this? In other words, a situation where to punch a UDP hole in = a NAT, you want to send a TCP SYN first? (If that's the case, why not sendi= ng a UDP packet instead of a TCP SYN...?).
If not, it would be cleaner= in my opinion to leave this requirement out. If yes, it would be nicer to = describe the real-world use, as i'm sure most of us are not familiar with i= t.


* 8. EIF Mapping Refresh

(This really only a= pplies to UDP. For TCP, NATs simply keep the mapping as long as the connect= ion is considered on from TCP point of view.)

Agreed, [RFC4787]:= REQ-6 is too liberal regarding mapping refreshes. It would be better to re= commend Address-Dependent Filtering and Address-Dependent mapping refreshes= =2E

  8.1 Agreed, this point has definitely been overlooked= too by RFC5382


* 9. EIM Protocol Independence

= Agreed



* 11. Port Randomization

Agreed, a= lthough it doesn't alleviate the fact the port randomization should be impl= emented by the client OS in the first place. The NAT role is not to harden = TCP security.
And as you note, this cannot be implemented if the NAT i= s TCP port preserving, which makes up the majority of NATs in the wild.



 

 

--

Ivan C.
--=_53505bc5841078ca128b127b021f622a-- From ivan@cacaoweb.org Sun Jun 16 15:24:27 2013 Return-Path: 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 4007A21F9D3A for ; Sun, 16 Jun 2013 15:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] 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 v3FlSOqbTTlM for ; Sun, 16 Jun 2013 15:24:22 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id BBAB121F9D27 for ; Sun, 16 Jun 2013 15:24:22 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1UoLNi-0001Ll-UH; Mon, 17 Jun 2013 00:25:06 +0200 To: X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_d9393dc2356d000a176ce6bac8d0b70b" Date: Mon, 17 Jun 2013 00:25:06 +0200 From: ivan c Organization: cacaoweb Message-ID: <6d6816c3367bc3c3bcf3795fbc850701@cacaoweb.org> X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Cc: rajiva@cisco.com Subject: Re: [BEHAVE] =?utf-8?q?=5Bv6ops=5D_Home_NAPT44_-_How_many_ports=3F?= 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jun 2013 22:24:27 -0000 --=_d9393dc2356d000a176ce6bac8d0b70b Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 On Jun 6, 2013, at 5:41 PM, "Rajiv Asati (rajiva)" wrote: > Hi Dan, > >> and so on. I am surprised you conclude that "500 seems ok" when such a >> limit would interfere with your network use on those days. > > I based that statement ("...seems ok,") on the very fact that the number of times the NAT utilization exceeded 500 mappings (equating to 500 ports, in my setup) in the sample period (~2 months) was relatively quite low. So, if the NAT device was limited to only 500 mappings, then the experience would have been ok for 99% of the time and degraded 1% of the time. This is an important consideration, IMO. > > For ex, in the last 2 weeks, the number of times NAT mappings exceeded 500 were: > > June 3 - 1 time > May 29 - 1 time > May 28 - 3 times > May 26 - 1 time > May 23 - 1 time > May 22 - 2 times > May 21 - 3 times > > Of course, 1000 ports (resulting in 1000+ mappings) would have been more than enough to accommodate the times when the mappings exceeded 500, but stayed within 1000 (except once). > > >> What is the maximum number of mappings supported by your NAPT device? >> Some residential-class NATs have a limit of 1024 mappings. > > My NAPT device seemingly can use upto 64K ports. :) > > Cheers, > Rajiv I'm not sure whether observing traffic on your local personal internet correction and then extrapolating this behavior for the worldwide internet as a whole is a very scientific method, especially when the purpose is the redaction of normalization and interoperability documents. But it's surely an interesting exercise. I noticed that in your experiment you leave out popular protocols like bittorrent, which makes up most of the internet world traffic and would surely gain to be integrated in such data series. On the other hand, some people on this mailing list (who work at large ISPs, or core network routers manufacturers) have access to would look more like real-world statistical data and we should probably turn to them to get proper information about what is currently happening on the inter networks. -- _Ivan C._ --=_d9393dc2356d000a176ce6bac8d0b70b Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 
On Jun 6, 2013, at 5:41 PM, "Rajiv Asati (rajiva)" <rajiva at cisco=
=2Ecom> wrote:

> Hi Dan,
>=20
>> and so on.  I am surprised you conclude that "500 seems ok" when s=
uch a
>> limit would interfere with your network use on those days.
>=20
> I based that statement ("...seems ok,") on the very fact that the numb=
er of times the NAT utilization exceeded 500 mappings (equating to 500 port=
s, in my setup) in the sample period (~2 months) was relatively quite low=
=2E So, if the NAT device was limited to only 500 mappings, then the experi=
ence would have been ok for 99% of the time and degraded 1% of the time. Th=
is is an important consideration, IMO.
>=20
> For ex, in the last 2 weeks, the number of times NAT mappings exceeded=
 500 were:
>=20
> June 3 - 1 time
> May 29 - 1 time
> May 28 - 3 times
> May 26 - 1 time
> May 23 - 1 time
> May 22 - 2 times
> May 21 - 3 times
>=20
> Of course, 1000 ports (resulting in 1000+ mappings) would have been mo=
re than enough to accommodate the times when the mappings exceeded 500, but=
 stayed within 1000 (except once).
>=20
>=20
>> What is the maximum number of mappings supported by your NAPT devi=
ce?
>> Some residential-class NATs have a limit of 1024 mappings.
>=20
> My NAPT device seemingly can use upto 64K ports. :)
>=20
> Cheers,
> Rajiv

 

 

I'm not sure whether observing traffic on your local personal internet c= orrection and then extrapolating this behavior for the worldwide internet a= s a whole is a very scientific method, especially when the purpose is the r= edaction of normalization and interoperability documents. But it's surely a= n interesting exercise. I noticed that in your experiment you leave out pop= ular protocols like bittorrent, which makes up most of the internet world t= raffic and would surely gain to be integrated in such data series.

On the other hand, some people on this mailing list (who work at large I= SPs, or core network routers manufacturers) have access to would look more = like real-world statistical data and we should probably turn to them to get= proper information about what is currently happening on the inter networks= =2E

 

--

Ivan C.
--=_d9393dc2356d000a176ce6bac8d0b70b-- From swmike@swm.pp.se Sun Jun 16 22:28:55 2013 Return-Path: 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 04B5021F99D0; Sun, 16 Jun 2013 22:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.555 X-Spam-Level: X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[AWL=1.044, 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 lVNCx2fq6BTI; Sun, 16 Jun 2013 22:28:54 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 501AD21F89EB; Sun, 16 Jun 2013 22:28:54 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9E0F99C; Mon, 17 Jun 2013 07:28:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 95E779A; Mon, 17 Jun 2013 07:28:53 +0200 (CEST) Date: Mon, 17 Jun 2013 07:28:53 +0200 (CEST) From: Mikael Abrahamsson To: "Softwires-wg list (softwires@ietf.org)" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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: Mon, 17 Jun 2013 05:28:55 -0000 On Thu, 6 Jun 2013, Dan Wing wrote: > What is the maximum number of mappings supported by your NAPT device? > Some residential-class NATs have a limit of 1024 mappings. I read some RFQ answers for residential gateways lately and at least the devices there seemed to support around 2048-4096 mapping. Other numbers I've heard kicked around is for larger populations of fixed line customers (CGN for ADSL and similar tech), one needs to support around 30 connections per customer on average. This goes down a bit when it's a single mobile device (without tethering), then it's more like 4-6 TCP connections needed on average. If I was going to support a student dorm I'm pretty sure the above values would be a lot higher though, especially compared to a retirement home Wifi :) -- Mikael Abrahamsson email: swmike@swm.pp.se From ivan@cacaoweb.org Mon Jun 17 06:14:57 2013 Return-Path: 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 F36AB21F9BB4 for ; Mon, 17 Jun 2013 06:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 WldIMZ1TKaRG for ; Mon, 17 Jun 2013 06:14:51 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id 96C7321F9B88 for ; Mon, 17 Jun 2013 06:14:51 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1UoZHY-0005kr-2d for behave@ietf.org; Mon, 17 Jun 2013 15:15:40 +0200 To: Behave X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_5fee2611e790f18ebe4b124d8b53fd62" Date: Mon, 17 Jun 2013 15:15:40 +0200 From: ivan c Organization: cacaoweb Message-ID: X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Subject: [BEHAVE] REQ 1 and REQ 7 of RFC5382 were supposed to be fixed years ago 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 13:14:57 -0000 --=_5fee2611e790f18ebe4b124d8b53fd62 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Speaking of this, reading draft-penno-behave-rfc4787-5382-5508-bis reminded me of a conversation I had many years ago with the Editor of RFC5382. Back then, it was acknowledged that the most desirable behavior for a NAT to support TCP simultaneous open between 2 peers behind NATs was to have TCP port preservation. REQ 1 is a weaker condition that can be used by NAT that do not implement port preservation, but can use a third party server to perform port prediction. The Editor said at the time that this would be updated in the next version of RFC5382, but I actually haven't heard of him since then as he seems to have vanished off the group a long time ago. REQ 7 was supposed to be fixed too, as the condition it requires is way too strong as everyone can see. Port overloading for TCP is perfectly acceptable when the remote endpoints are distinct. With large scale deployments of CGNs, it has now become a desirable behavior. Another point, as far as I'm aware, no peer to peer application implements the SO_REUSEADDR hack that RFC5382 advocates to perform TCP simultaneous open. Again, TCP port preservation is generally used as there is more support for this scheme in NAT deployments in the wild. Use of the SO_REUSEADDR hack violates RFC793 and should be used with extra care. If NAT implementers are really reading this RFC as it is, this is going to be the source of much confusion. I'm not sure whether the correct thing to do would be to write an Errata for these points or simply to write a new RFC based on the new work of draft-penno-behave-rfc4787-5382-5508-bis . Please don't hesitate to ask me for technical clarifications, as these discussions happened many years ago and some of the context might have been lost by the current participants. -- _Ivan Chollet_ --=_5fee2611e790f18ebe4b124d8b53fd62 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Speaking of this, reading draft-penno-behave-rfc4787-5382-5508-bis remin= ded me of a conversation I had many years ago with the Editor of RFC5382.

Back then, it was acknowledged that the most desirable behavior for a NA= T to support TCP simultaneous open between 2 peers behind NATs was to have = TCP port preservation. REQ 1 is a weaker condition that can be used by NAT = that do not implement port preservation, but can use a third party server t= o perform port prediction. The Editor said at the time that this would be u= pdated in the next version of RFC5382, but I actually haven't heard of him = since then as he seems to have vanished off the group a long time ago.

REQ 7 was supposed to be fixed too, as the condition it requires is way = too strong as everyone can see. Port overloading for TCP is perfectly accep= table when the remote endpoints are distinct. With large scale deployments = of CGNs, it has now become a desirable behavior.

Another point, as far as I'm aware, no peer to peer application implemen= ts the SO_REUSEADDR hack that RFC5382 advocates to perform TCP simultaneous= open. Again, TCP port preservation is generally used as there is more supp= ort for this scheme in NAT deployments in the wild. Use of the SO_REUSEADDR= hack violates RFC793 and should be used with extra care.

 

If NAT implementers are really reading this RFC as it is, this is going = to be the source of much confusion.

I'm not sure whether the correct thing to do would be to write an Errata= for these points or simply to write a new RFC based on the new work of dra= ft-penno-behave-rfc4787-5382-5508-bis .

 

Please don't hesitate to ask me for technical clarifications, as these d= iscussions happened many years ago and some of the context might have been = lost by the current participants.

 

 

--

Ivan Chollet
--=_5fee2611e790f18ebe4b124d8b53fd62-- From ivan@cacaoweb.org Mon Jun 17 06:24:36 2013 Return-Path: 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 94A1421F9BCA for ; Mon, 17 Jun 2013 06:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 O3ssTXEf09rF for ; Mon, 17 Jun 2013 06:24:30 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id 84E8321F9C19 for ; Mon, 17 Jun 2013 06:24:26 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1UoZQq-00063C-BI for behave@ietf.org; Mon, 17 Jun 2013 15:25:16 +0200 To: Behave X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_5f43f0c600d54debd96ad753129c1bf1" Date: Mon, 17 Jun 2013 15:25:16 +0200 From: ivan c Organization: cacaoweb Message-ID: X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Subject: [BEHAVE] RFC5382, RFC4787 update and draft-penno-behave-rfc4787-5382-5508-bis 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 13:24:37 -0000 --=_5f43f0c600d54debd96ad753129c1bf1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 It seems from my private email communication today with the Editor of RFC5382 that he is happy to participate in the update of RFC 5382 but does not wish to take the lead on this. In my opinion, it would be possible to work on an update that would integrate the changes mandated by draft-penno-behave-rfc4787-5382-5508-bis, as long as these changes do not change the philosophy of RFC5382 and RFC4787. Authors of draft-penno-behave-rfc4787-5382-5508-bis could be added as co-authors. Please let us know what is your opinion on this. -- _Ivan Chollet_ --=_5f43f0c600d54debd96ad753129c1bf1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

It seems from my private email communication today with the Editor of RF= C5382 that he is happy to participate in the update of RFC 5382 but does no= t wish to take the lead on this.

In my opinion, it would be possible to work on an update that would inte= grate the changes mandated by draft-penno-behave-rfc4787-5382-5508-bis, as = long as these changes do not change the philosophy of RFC5382 and RFC4787= =2E

Authors of draft-penno-behave-rfc4787-5382-5508-bis could be added as co= -authors.

Please let us know what is your opinion on this.

 

--

Ivan Chollet
--=_5f43f0c600d54debd96ad753129c1bf1-- From repenno@cisco.com Mon Jun 17 06:26:57 2013 Return-Path: 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 BC16721F8FF8 for ; Mon, 17 Jun 2013 06:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 ErFMdciEXV1o for ; Mon, 17 Jun 2013 06:26:52 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8146421F8E8C for ; Mon, 17 Jun 2013 06:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13678; q=dns/txt; s=iport; t=1371475612; x=1372685212; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=ly8nThCbs48yY+goofkcfsD8RbnWr3X28ixREV/WMZE=; b=PDRAtmBrcgwlDB39c+gavTJHcTpE14JselmuoO30Ry4j2K378kG2PT7h uodONgg8mt/moCwRQiS24SxdSSLNMLWeDRRc44n1nsjU6NLgIBpuxng89 X7eEr9O/YZfAsz/pdfE4cQHXWit3Ex/oOFNEBiebI9KKE1Sy3ZpuqnB+o w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncFAAcOv1GtJV2c/2dsb2JhbABagkVEMUm2LIg8fRZ0gh8EAQEBBAEBAWsdAQgRAwECCx0uCxQJCAIEARIIAYVAB4IgHgy4Zo4VgQEgDQuCf2EDkzOFN5Aagw+BcTc X-IronPort-AV: E=Sophos;i="4.87,881,1363132800"; d="scan'208,217";a="223696117" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 17 Jun 2013 13:26:52 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5HDQp9J023414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Jun 2013 13:26:51 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Mon, 17 Jun 2013 08:26:51 -0500 From: "Reinaldo Penno (repenno)" To: "ivan@cacaoweb.org" , "behave@ietf.org" Thread-Topic: [BEHAVE] review of draft-penno-behave-rfc4787-5382-5508-bis Thread-Index: AQHOase+18zSZk4grEaE3Z51QZKhl5k6CJmA Date: Mon, 17 Jun 2013 13:26:50 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A89E4@xmb-rcd-x04.cisco.com> In-Reply-To: <3a724be2431cf7249b3d46cf378f85bf@cacaoweb.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.242.102] Content-Type: multipart/alternative; boundary="_000_45A697A8FFD7CF48BCF2BE7E106F0604090A89E4xmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: Re: [BEHAVE] review of draft-penno-behave-rfc4787-5382-5508-bis X-BeenThere: behave@ietf.org 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: Mon, 17 Jun 2013 13:26:57 -0000 --_000_45A697A8FFD7CF48BCF2BE7E106F0604090A89E4xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ivan, Thanks for the detailed review of the draft. You might want to reference th= e newer version at http://tools.ietf.org/html/draft-ietf-behave-requiremen= ts-update-00 I'm going through your comments and will start a discussion shortly. Thanks, Reinaldo From: ivan c > Organization: cacaoweb Reply-To: > Date: Sun, 16 Jun 2013 21:14:16 +0200 To: > Subject: [BEHAVE] review of draft-penno-behave-rfc4787-5382-5508-bis Hello, This is my review of draft-penno-behave-rfc4787-5382-5508-bis, which is indeed a st= ep in the right direction and corrects omissions and unspecified behaviors = left by previous documents. I support its adoption as a working group docum= ent. * 3.1.2.1. Rewrite timestamp and sequence number values at NAT Requiring NATs to rewrite timestamps and ISNs seems overkill. Generally, ma= ngling with the TCP protocol header other than by rewriting the source endp= oint should not be done by NATs. On the other hand, improving the current situation regarding the TIME_WAIT = state by carefully designed filtering rules without altering the TCP header= seems acceptable. * 4. Port overlapping behavior This is becoming a pressing issue due to increase deployment of CGNs for IP= v4 worldwide. As far as I know, the traditional term to describe this behavior is "port o= verloading". The term overlapping refers to when two sets have a non empty = intersection (they are said to be "overlapping" sets). Overloading is the c= orrect term and was previously used in RFC5382 and RFC4787. Port overloading is problematic for UDP, as P2P applications generally mult= iplex several UDP communications over the same socket. The probability that= two internal peers communicate to the same remote endpoint can be non-negl= igeable, depending on the number of UDP communications and characteristics = intrinsic to the p2p application. See Birthday Paradox. For TCP, this problem does not arise nrealy as much as there is a one-to-on= e mapping between sockets and TCP communications (POSIX does not allow to b= ind multiple sockets to the same local endpoint for outbound connections). = Thus the probability for conflict is much lower. [RFC5382] REQ-1 indeed requires EIM, but it is important to note that the E= IM behavior is required by applications that rely on a POSIX "hack", that i= s the set up of the SO_REUSEADDR option on the socket to bind two successiv= e outbound connections on the same local endpoint. This hack is controversi= al and thus [RFC5382] REQ-1 is subject to controversy, for the following re= asons: SO_REUSEADDR behavior is left unspecified by POSIX. SO_REUSEADDR is = generally implemented by OSes to bypass the TIME_WAIT state for network ser= vers. It violates TCP quiet time, TIME_WAIT and can lead to data corruption= . It should generally only be used by listening servers, not client making = outbound connections. Its use is discouraged in production for listening se= rvers. RFC 6528. A correct way to achieve TCP port prediction (which is what [RFC5382] REQ-1= is really about without saying it) without relying on POSIX hacks is to re= quire the NAT to be port-preserving. Port prediction is straightforward in = the case of port preservation. It also works nicely with port overloading, = and allows p2p applications to work without the need of a third party publi= c server for each TCP communication instantiation. Thus it allows NAT trave= rsal for fully decentralized p2p applications. Most NATs in the wild implem= ent TCP port preservation for this reason. * End of page 8 The external references provided point to a website written only in japanes= e. It would be nice to provide a pointer to the english version of these we= b pages. * 6. EIF Security Indeed, EIF poses security concerns. At the very least, use of Address-Depe= ndent Filtering should be recommended. Applications requiring EIF to functi= on are clearly badly designed and it is not the role of an RFC to support i= ncorrect designs. * 7. EIF Protocol Independence Do you have any reasonable use for this? In other words, a situation where = to punch a UDP hole in a NAT, you want to send a TCP SYN first? (If that's = the case, why not sending a UDP packet instead of a TCP SYN...?). If not, it would be cleaner in my opinion to leave this requirement out. If= yes, it would be nicer to describe the real-world use, as i'm sure most of= us are not familiar with it. * 8. EIF Mapping Refresh (This really only applies to UDP. For TCP, NATs simply keep the mapping as = long as the connection is considered on from TCP point of view.) Agreed, [RFC4787]: REQ-6 is too liberal regarding mapping refreshes. It wou= ld be better to recommend Address-Dependent Filtering and Address-Dependent= mapping refreshes. 8.1 Agreed, this point has definitely been overlooked too by RFC5382 * 9. EIM Protocol Independence Agreed * 11. Port Randomization Agreed, although it doesn't alleviate the fact the port randomization shoul= d be implemented by the client OS in the first place. The NAT role is not t= o harden TCP security. And as you note, this cannot be implemented if the NAT is TCP port preservi= ng, which makes up the majority of NATs in the wild. -- Ivan C. _______________________________________________ Behave mailing list Behave@= ietf.org https://www.ietf.org/mailman/listinfo/beha= ve --_000_45A697A8FFD7CF48BCF2BE7E106F0604090A89E4xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Ivan,

Thanks for the detailed review of the draft. You might want to referen= ce the newer version at  http://tools.ietf.org/html/draft-ietf-be= have-requirements-update-00

I'm going through your comments and will start a discussion shortly.&n= bsp;

Thanks,

Reinaldo

From: ivan c <ivan@cacaoweb.org>
Organization: cacaoweb
Reply-To: <ivan@cacaoweb.org>
Date: Sun, 16 Jun 2013 21:14:16 = 3;0200
To: <behave@ietf.org>
Subject: [BEHAVE] review of draft-p= enno-behave-rfc4787-5382-5508-bis

Hello,

This is my review of draft-penno-behave-rfc4787-5382-5508-bis, which is indeed a step in the= right direction and corrects omissions and unspecified behaviors left by p= revious documents. I support its adoption as a working group document.

 

 


* 3.1.2.1. Rewrite timestamp and sequence number values at NAT

Requiring NATs to rewrite timestamps and ISNs seems overkill. Generally, ma= ngling with the TCP protocol header other than by rewriting the source endp= oint should not be done by NATs.
On the other hand, improving the current situation regarding the TIME_WAIT = state by carefully designed filtering rules without altering the TCP header= seems acceptable.


* 4. Port overlapping behavior

This is becoming a pressing issue due to increase deployment of CGNs for IP= v4 worldwide.
As far as I know, the traditional term to describe this behavior is "p= ort overloading". The term overlapping refers to when two sets have a = non empty intersection (they are said to be "overlapping" sets). = Overloading is the correct term and was previously used in RFC5382 and RFC4787.
Port overloading is problematic for UDP, as P2P applications generally mult= iplex several UDP communications over the same socket. The probability that= two internal peers communicate to the same remote endpoint can be non-negl= igeable, depending on the number of UDP communications and characteristics intrinsic to the p2p application= . See Birthday Paradox.
For TCP, this problem does not arise nrealy as much as there is a one-to-on= e mapping between sockets and TCP communications (POSIX does not allow to b= ind multiple sockets to the same local endpoint for outbound connections). = Thus the probability for conflict is much lower.

[RFC5382] REQ-1 indeed requires EIM, but it is important to note that the E= IM behavior is required by applications that rely on a POSIX "hack&quo= t;, that is the set up of the SO_REUSEADDR option on the socket to bind two= successive outbound connections on the same local endpoint. This hack is controversial and thus [RFC5382] REQ-1 is sub= ject to controversy, for the following reasons: SO_REUSEADDR behavior is le= ft unspecified by POSIX. SO_REUSEADDR is generally implemented by OSes to b= ypass the TIME_WAIT state for network servers. It violates TCP quiet time, TIME_WAIT and can lead to data corrup= tion. It should generally only be used by listening servers, not client mak= ing outbound connections. Its use is discouraged in production for listenin= g servers. RFC 6528.

A correct way to achieve TCP port prediction (which is what [RFC5382] REQ-1= is really about without saying it) without relying on POSIX hacks is to re= quire the NAT to be port-preserving. Port prediction is straightforward in = the case of port preservation. It also works nicely with port overloading, and allows p2p applications to wo= rk without the need of a third party public server for each TCP communicati= on instantiation. Thus it allows NAT traversal for fully decentralized p2p = applications. Most NATs in the wild implement TCP port preservation for this reason.


* End of page 8

The external references provided point to a website written only in japanes= e. It would be nice to provide a pointer to the english version of these we= b pages.


* 6. EIF Security

Indeed, EIF poses security concerns. At the very least, use of Address-Depe= ndent Filtering should be recommended. Applications requiring EIF to functi= on are clearly badly designed and it is not the role of an RFC to support i= ncorrect designs.


* 7. EIF Protocol Independence

Do you have any reasonable use for this? In other words, a situation where = to punch a UDP hole in a NAT, you want to send a TCP SYN first? (If that's = the case, why not sending a UDP packet instead of a TCP SYN...?).
If not, it would be cleaner in my opinion to leave this requirement out. If= yes, it would be nicer to describe the real-world use, as i'm sure most of= us are not familiar with it.


* 8. EIF Mapping Refresh

(This really only applies to UDP. For TCP, NATs simply keep the mapping as = long as the connection is considered on from TCP point of view.)

Agreed, [RFC4787]: REQ-6 is too liberal regarding mapping refreshes. It wou= ld be better to recommend Address-Dependent Filtering and Address-Dependent= mapping refreshes.

  8.1 Agreed, this point has definitely been overlooked too by RFC5382=


* 9. EIM Protocol Independence

Agreed



* 11. Port Randomization

Agreed, although it doesn't alleviate the fact the port randomization shoul= d be implemented by the client OS in the first place. The NAT role is not t= o harden TCP security.
And as you note, this cannot be implemented if the NAT is TCP port preservi= ng, which makes up the majority of NATs in the wild.



 

 

--

Ivan C.
_______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave --_000_45A697A8FFD7CF48BCF2BE7E106F0604090A89E4xmbrcdx04ciscoc_-- From simon.perreault@viagenie.ca Mon Jun 17 07:54:48 2013 Return-Path: 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 0717921F9C9E for ; Mon, 17 Jun 2013 07:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 Sh2H3VUb0yG5 for ; Mon, 17 Jun 2013 07:54:47 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 05C1221F9CCB for ; Mon, 17 Jun 2013 07:54:44 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:84c5:867d:e648:8153]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6D7F14040F for ; Mon, 17 Jun 2013 10:54:43 -0400 (EDT) Message-ID: <51BF2333.2010700@viagenie.ca> Date: Mon, 17 Jun 2013 16:54:43 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: behave@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] REQ 1 and REQ 7 of RFC5382 were supposed to be fixed years ago X-BeenThere: behave@ietf.org 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: Mon, 17 Jun 2013 14:54:48 -0000 Le 2013-06-17 15:15, ivan c a écrit : > Back then, it was acknowledged that the most desirable behavior for a > NAT to support TCP simultaneous open between 2 peers behind NATs was to > have TCP port preservation. I would argue that port preservation is useless for traversal. > REQ 1 is a weaker condition that can be used > by NAT that do not implement port preservation, but can use a third > party server to perform port prediction. I don't see how EIM can be used for port prediction. > REQ 7 was supposed to be fixed too, as the condition it requires is way > too strong as everyone can see. Port overloading for TCP is perfectly > acceptable when the remote endpoints are distinct. In your opinion, what is it about TCP that makes EDM OK? > Use of the SO_REUSEADDR hack violates RFC793 and should be used with > extra care. Please explain. Simon From bs@stepladder-it.com Mon Jun 17 03:47:08 2013 Return-Path: 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 CFA9821F9958; Mon, 17 Jun 2013 03:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 B+Gi-JBcin9D; Mon, 17 Jun 2013 03:47:04 -0700 (PDT) Received: from mail.speedpartner.de (mail.speedpartner.de [IPv6:2a01:198::3]) by ietfa.amsl.com (Postfix) with ESMTP id 6247921F9B93; Mon, 17 Jun 2013 03:46:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.speedpartner.de (Postfix) with ESMTP id F2CDD62226; Mon, 17 Jun 2013 12:46:24 +0200 (CEST) Received: from mail.speedpartner.de ([127.0.0.1]) by localhost (mail.speedpartner.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SwXZx5ar8Li; Mon, 17 Jun 2013 12:46:24 +0200 (CEST) Received: from stepladder-it.com (port-83-236-238-169.static.qsc.de [83.236.238.169]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mxbot@stepladder-it.com) by mail.speedpartner.de (Postfix) with ESMTPSA id D589961BBD; Mon, 17 Jun 2013 12:46:24 +0200 (CEST) Received: from ip6-localhost ([::1] helo=natrix) by stepladder-it.com with esmtp (Exim 4.80) (envelope-from ) id 1UoWx3-0004bz-2J; Mon, 17 Jun 2013 10:46:21 +0000 From: Benedikt Stockebrand To: "Softwires-wg list \(softwires\@ietf.org\)" , "v6ops\@ietf.org" , "behave\@ietf.org" References: Date: Mon, 17 Jun 2013 10:46:20 +0000 In-Reply-To: (Dan Wing's message of "Thu, 6 Jun 2013 08:43:23 -0700") Message-ID: <877ghtt3pf.fsf@stepladder-it.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailman-Approved-At: Mon, 17 Jun 2013 10:10:42 -0700 Subject: Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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: Mon, 17 Jun 2013 13:10:24 -0000 Hi Dan and lists, Dan Wing writes: > On Jun 5, 2013, at 6:14 AM, Rajiv Asati (rajiva) wrote: >> >> In short, port range of 500 seems ok, though 1000 would be more than enough for my home. > > I see several spikes in your data over 500 ports. [...] If you had > only 500 ports on those days, creating a new TCP mapping would have > been impossible, impacting ability to send or receive email, order > books from Amazon.com, and so on. ...or make an emergency phone call using SIP---which currently spooks triple play providers at least here in Germany, not only because it is bad press but disrupting emergency calls is in some cases considered a criminal offense here. Otherwise, in November I saw a presentation by Alain Fiocco (also Cisco) pointing out that a single Bittorrent client already needs about 700 simultaneous connections. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.stepladder-it.com/ From dwing@cisco.com Mon Jun 17 16:50:39 2013 Return-Path: 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 C450521F92E3 for ; Mon, 17 Jun 2013 16:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.556 X-Spam-Level: X-Spam-Status: No, score=-110.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 D8ryBF0TrDmO for ; Mon, 17 Jun 2013 16:50:30 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id BDE8E21F8605 for ; Mon, 17 Jun 2013 16:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=600; q=dns/txt; s=iport; t=1371513030; x=1372722630; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=i8RbQkRyOzY6/thLV8k5NZ2xid2OvWHTMJPPHWDxRjc=; b=Xi2otomgSyw3BeUM8Mwa6Zz+RRNn8hH3IO1XyK3OiECzn3dhN6pt/jEu xWStI57Vw4hgB0Ddb6+aZqhOmoGEQ8+AwQJxBKYJxuaztzg9pLDNLVk8l ZCSqff0d+gIQNBXOMUFgetZ6TGy8gtrWtQ97gM2Slh03WtaNQI22eozOT U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUHAFWgv1GrRDoJ/2dsb2JhbABbgwmDMr1JFm0HgmQ0gTIXExaHd5odoDaOBYRIYQOJII4hhiCLI4MvHIE1 X-IronPort-AV: E=Sophos;i="4.87,884,1363132800"; d="scan'208";a="80666768" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 17 Jun 2013 23:50:27 +0000 Received: from [10.156.17.51] ([10.156.17.51]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5HNoM6e028974 for ; Mon, 17 Jun 2013 23:50:22 GMT From: Dan Wing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 17 Jun 2013 16:50:22 -0700 To: "behave@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [BEHAVE] BEHAVE presentations for IETF78 (Berlin) X-BeenThere: behave@ietf.org 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: Mon, 17 Jun 2013 23:50:39 -0000 If you want to present at the BEHAVE meeting at IETF78 (Berlin), please = send email to behave-chairs@tools.ietf.org with: * name of presenter * minutes * internet draft filename(s) * reason to present (e.g., education, resolve mailing list disagreement = on certain point) Preference will be given to working group milestone items, and then = (time permitting) drafts which have received significant discussion on = the list. We requested a 1.5 hour slot and expect to have presentations = on SYSLOG NAT logging, IPFIX NAT logging, the NAT MIB, and NAT = requirements update. -d From ivan@cacaoweb.org Mon Jun 17 19:21:10 2013 Return-Path: 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 014A521F9CB3 for ; Mon, 17 Jun 2013 19:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 aqwXTlLYZRbe for ; Mon, 17 Jun 2013 19:21:06 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id C039321F9BBA for ; Mon, 17 Jun 2013 19:21:05 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1UolYR-0001MU-19 for behave@ietf.org; Tue, 18 Jun 2013 04:21:55 +0200 To: Behave X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Tue, 18 Jun 2013 04:21:55 +0200 From: ivan c Organization: cacaoweb In-Reply-To: <51BF2333.2010700@viagenie.ca> References: <51BF2333.2010700@viagenie.ca> Message-ID: X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Subject: Re: [BEHAVE] REQ 1 and REQ 7 of RFC5382 were supposed to be fixed years ago 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 02:21:10 -0000 Hi Simon, You will find my explanations to your 4 questions interleaved below. First of all, a word about the context considered in this discussion: We have peers, all behind NATs, attempting to connect to each other via TCP simultaneous open (TCP simultaneous open being described in TCP RFC793 Section 3.4 Figure 8). The first step is for these peers to discover or guess what each other's remote external endpoint will be for the TCP connection. This step is called "remote external endpoint prediction" or informally "port prediction" (as the hard part is to predict the external port, as created by the NAT). Once external mapping have been negotiated/discovered, this information is shared amongst the peers over some arbitrary out-of-band communication channel. The second step consists in performing the actual TCP simultaneous open to the relevant endpoint. These steps constitute the TCP Hole Punching process, it can be used for NAT Traversal. On Mon, 17 Jun 2013 16:54:43 +0200, Simon Perreault wrote: > > I would argue that port preservation is useless for traversal. TCP port preservation in NAT mappings allows peers to perform port prediction trivially: the external port value of their own mapping is the same as the local/internal port. The information of the external endpoint can then be shared amongst all peers over an arbitrary out-of-band channel. This completes the port prediction step of TCP Hole Punching. The alternative to port preservation for the purpose of port prediction is to use an EIM-NAT, and use SO_REUSEADDR set on all local sockets, and use a third-party public server. I explained this process as the answer to your second question below. However, such technique uses POSIX-unspecified behavior (SO_REUSEADDR is left unspecified) and is TCP non-compliant (as it violates the TIME_WAIT state). As a result, port preservation is desirable (and implies EIM anyway) for TCP NAT traversal and adopted in the vast majority of NAT implementations (in Saikat Gupta's paper, he mentions 89% of EIM NATs). Port preservation becomes absolutely necessary in the context of fully decentralized p2p networks. In such networks, third-party STUNT public servers are generally not available, and thus a TCP Hole Punching technique using a STUNT server is not possible. Port Preservation alleviates the need of a third-party STUNT server for the purpose of performing port prediction. See Saikat Guha (Editor of existing RFCs) paper http://saikat.guha.cc/pub/imc05-tcpnat.pdf, section 5. > > I don't see how EIM can be used for port prediction. The single purpose of a EIM NAT for TCP is to allow an easy port prediction with a STUNT server. First of all, we use the term "port prediction" as a synonym for any remote endpoint port discovery or guessing mechanism. When 2 peers behind NATs attempt to communicate with each other through TCP, they need to predict each other's external endpoint to perform a TCP simultaneous open. An EIM NAT guarantees that two successive outgoing TCP connections from the same internal endpoint are mapped to the same external endpoint on the NAT. This is port prediction: the first connection assists in predicting the external endpoint that will be used by the NAT for the second connection. Such behavior can be used for TCP Hole Punching as follows: Let S be a server (no NAT) with a listening port Ps, let A and B be peers behind NATs. Port prediction works as follows: Peer A binds a local socket on port Pa, then makes a TCP connection with this socket to S on port Ps. Peer B does the same. S gives the information of their respective port mapping to both peers. Port Prediction has now been achieved: because the NAT uses Endpoint-Independent Mapping, any subsequent connection from the same internal endpoint will reuse the mapping. The rest of the TCP Hole Punching process will then go as follows: Peer A closes its local socket. Peer B does the same. Peer A creates a new socket and binds it on the *same* port Pa. Most OS stacks allow this as long as the SO_REUSEADDR option is set on *both* sockets. Peer B does the same. Then both make a connect() on this socket, to each respective endpoint. TCP simultaneous open is now in progress. This is also explained in Saikat Guha's paper http://saikat.guha.cc/pub/imc05-tcpnat.pdf, in section 5. > >> REQ 7 was supposed to be fixed too, as the condition it requires is way >> too strong as everyone can see. Port overloading for TCP is perfectly >> acceptable when the remote endpoints are distinct. > > In your opinion, what is it about TCP that makes EDM OK? My point is about the "TCP Port overloading" behavior and showing that REQ 7 is too stringent. This is orthogonal to Endpoint-Dependent Mapping (EDM) behavior. Please explain your question. > >> Use of the SO_REUSEADDR hack violates RFC793 and should be used with >> extra care. > > Please explain. The SO_REUSEADDR socket option was added exclusively to bypass the TCP TIME_WAIT state for listening servers. (which is an annoyance in development) The TCP TIME_WAIT state is there to avoid the old duplicate problem. The TIME_WAIT state lasts for 2*MSL, which is about 4 minutes. When SO_REUSEADDR is used on sockets, an application can bind a socket on a port that has a TIME_WAIT state pending. Bypassing the TIME_WAIT state violates the data corruption provisions of TCP, and should only be used by servers, in non-production environments. Furthermore, the behavior with SO_REUSEADDR is intentionally left unspecified in POSIX: "SO_REUSEADDR: Specifies that the rules used in validating addresses supplied to bind() should allow reuse of local addresses". > > Simon > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave Please do not hesitate to ask me for further clarification about the points above. -- _Ivan Chollet_ From rmohanr@cisco.com Mon Jun 17 21:53:39 2013 Return-Path: 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 900AB21F9DCA for ; Mon, 17 Jun 2013 21:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.3 X-Spam-Level: X-Spam-Status: No, score=-9.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 E8x0y8yB9nzx for ; Mon, 17 Jun 2013 21:53:34 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 6C66921F9AAB for ; Mon, 17 Jun 2013 21:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1677; q=dns/txt; s=iport; t=1371531214; x=1372740814; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=+9GIWlJPYDL/OeG6SpwBYdhF3xaEv8+4xnFyq2Tuugk=; b=dV+14JsnJCDXEstlfaVsFsp+l2KxvCqfitYcIRXSMbDkTqWfBHC5bJjV 4cGzc9OJVnHJdXIUeYqhNNdOV2XxbtBfocYcY+Rpyy41ZXNy82L7DRhMI DV+egDKwTnJ6dwZAdoV0oHc8nNTkW16OT3MBFaWjVuejmeSqDgfBI8MX5 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAGAEDnv1GtJV2Z/2dsb2JhbABagwkxQwa/BX8WbQeCIwEBAQMBOj0HDQEIIhRCGwEGAwIEEwgBh38GBwWaBaBAjxQ4gn9hA5hqkBqDD4Io X-IronPort-AV: E=Sophos;i="4.87,886,1363132800"; d="scan'208";a="224044278" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 18 Jun 2013 04:53:33 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5I4rXs6026319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 18 Jun 2013 04:53:33 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.242]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Mon, 17 Jun 2013 23:53:33 -0500 From: "Ram Mohan R (rmohanr)" To: "behave@ietf.org" Thread-Topic: New Version Notification for draft-reddy-behave-turn-auth-02.txt Thread-Index: AQHOZ1hEvEcLpFOM4U2OtQirK7luDJk7oYQA Date: Tue, 18 Jun 2013 04:53:32 +0000 Message-ID: In-Reply-To: <20130612103314.16399.8755.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [72.163.212.105] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] FW: New Version Notification for draft-reddy-behave-turn-auth-02.txt X-BeenThere: behave@ietf.org 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 04:53:39 -0000 We have published the revision of this draft. This has changes to following text of "Problems with STUN Authentication" section 5. Hosting multiple realms on a single IP address is challenging with TURN. When a TURN server needs to send the REALM attribute in response to an unauthenticated request, it has no useful information for determining which realm it should send, except the source transport address of the TURN request. Note this is a problem with multi-tenant scenarios only. This is not a problem when deployed in Enterprise. Please review and provide any inputs/comments on this draft. Authors > On 12/06/13 4:03 PM, "internet-drafts@ietf.org" > wrote: > >A new version of I-D, draft-reddy-behave-turn-auth-02.txt >has been successfully submitted by Tirumaleswar Reddy and posted to the >IETF repository. > >Filename: draft-reddy-behave-turn-auth >Revision: 02 >Title: Problems with STUN Authentication for TURN >Creation date: 2013-06-12 >Group: Individual Submission >Number of pages: 7 >URL: =20 >http://www.ietf.org/internet-drafts/draft-reddy-behave-turn-auth-02.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-reddy-behave-turn-auth >Htmlized: =20 >http://tools.ietf.org/html/draft-reddy-behave-turn-auth-02 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-reddy-behave-turn-auth-02 > >Abstract: > This document discusses some of the issues with STUN authentication > for TURN messages. > > =20 > =20 > > >The IETF Secretariat > > From naito.kengo@lab.ntt.co.jp Mon Jun 17 21:57:06 2013 Return-Path: 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 ED73C21F9E63 for ; Mon, 17 Jun 2013 21:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.089 X-Spam-Level: X-Spam-Status: No, score=-0.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001] 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 C5AnGN+cvisF for ; Mon, 17 Jun 2013 21:57:00 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1BC21F9E02 for ; Mon, 17 Jun 2013 21:57:00 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id r5I4ugI7016564; Tue, 18 Jun 2013 13:56:42 +0900 Received: from mfs6.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id D567DE0155; Tue, 18 Jun 2013 13:56:42 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id C9551E014E; Tue, 18 Jun 2013 13:56:42 +0900 (JST) Received: from [127.0.0.1] ([129.60.7.245]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id r5I4ueDf028739; Tue, 18 Jun 2013 13:56:41 +0900 Message-ID: <51BFE896.2000006@lab.ntt.co.jp> Date: Tue, 18 Jun 2013 13:56:54 +0900 From: Kengo Naito User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: ivan@cacaoweb.org References: <3a724be2431cf7249b3d46cf378f85bf@cacaoweb.org> In-Reply-To: <3a724be2431cf7249b3d46cf378f85bf@cacaoweb.org> Content-Type: multipart/alternative; boundary="------------020003090909030907050509" Cc: behave@ietf.org Subject: Re: [BEHAVE] review of draft-penno-behave-rfc4787-5382-5508-bis X-BeenThere: behave@ietf.org 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 04:57:06 -0000 This is a multi-part message in MIME format. --------------020003090909030907050509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Ivan, Thank you for the review of our draft. Please see my comments inline, (2013/06/17 4:14), ivan c wrote: > > Hello, > > This is my review of draft-penno-behave-rfc4787-5382-5508-bis > , > which is indeed a step in the right direction and corrects omissions > and unspecified behaviors left by previous documents. I support its > adoption as a working group document. > > > * 3.1.2.1. Rewrite timestamp and sequence number values at NAT > > Requiring NATs to rewrite timestamps and ISNs seems overkill. > Generally, mangling with the TCP protocol header other than by > rewriting the source endpoint should not be done by NATs. > On the other hand, improving the current situation regarding the > TIME_WAIT state by carefully designed filtering rules without altering > the TCP header seems acceptable. > Then, how about using 3.1.2.2 ? This alternative do not rewrite timestamps nor ISNs. Also, I do not intend to make 3.1.2.1 "must", this is only one of alternatives. > > * 4. Port overlapping behavior > > This is becoming a pressing issue due to increase deployment of CGNs > for IPv4 worldwide. > As far as I know, the traditional term to describe this behavior is > "port overloading". The term overlapping refers to when two sets have > a non empty intersection (they are said to be "overlapping" sets). > Overloading is the correct term and was previously used in RFC5382 and > RFC4787. > Port overloading is problematic for UDP, as P2P applications generally > multiplex several UDP communications over the same socket. The > probability that two internal peers communicate to the same remote > endpoint can be non-negligeable, depending on the number of UDP > communications and characteristics intrinsic to the p2p application. > See Birthday Paradox. > In the draft, I meant that Port overlapping behavior can only be used when the 5-tupple of connections are different. So I think it is a bit different from overlapping behavior you wrote. Does this behavior cause any bad effect? > For TCP, this problem does not arise nrealy as much as there is a > one-to-one mapping between sockets and TCP communications (POSIX does > not allow to bind multiple sockets to the same local endpoint for > outbound connections). Thus the probability for conflict is much lower. > > [RFC5382] REQ-1 indeed requires EIM, but it is important to note that > the EIM behavior is required by applications that rely on a POSIX > "hack", that is the set up of the SO_REUSEADDR option on the socket to > bind two successive outbound connections on the same local endpoint. > This hack is controversial and thus [RFC5382] REQ-1 is subject to > controversy, for the following reasons: SO_REUSEADDR behavior is left > unspecified by POSIX. SO_REUSEADDR is generally implemented by OSes to > bypass the TIME_WAIT state for network servers. It violates TCP quiet > time, TIME_WAIT and can lead to data corruption. It should generally > only be used by listening servers, not client making outbound > connections. Its use is discouraged in production for listening > servers. RFC 6528. > > A correct way to achieve TCP port prediction (which is what [RFC5382] > REQ-1 is really about without saying it) without relying on POSIX > hacks is to require the NAT to be port-preserving. Port prediction is > straightforward in the case of port preservation. It also works nicely > with port overloading, and allows p2p applications to work without the > need of a third party public server for each TCP communication > instantiation. Thus it allows NAT traversal for fully decentralized > p2p applications. Most NATs in the wild implement TCP port > preservation for this reason. > > > * End of page 8 > > The external references provided point to a website written only in > japanese. It would be nice to provide a pointer to the english version > of these web pages. > Thanks for pointing, I should find the English page, and rewrite in next version of the draft. > > > * 6. EIF Security > > Indeed, EIF poses security concerns. At the very least, use of > Address-Dependent Filtering should be recommended. Applications > requiring EIF to function are clearly badly designed and it is not the > role of an RFC to support incorrect designs. > > > * 7. EIF Protocol Independence > > Do you have any reasonable use for this? In other words, a situation > where to punch a UDP hole in a NAT, you want to send a TCP SYN first? > (If that's the case, why not sending a UDP packet instead of a TCP > SYN...?). > If not, it would be cleaner in my opinion to leave this requirement > out. If yes, it would be nicer to describe the real-world use, as i'm > sure most of us are not familiar with it. > > > * 8. EIF Mapping Refresh > > (This really only applies to UDP. For TCP, NATs simply keep the > mapping as long as the connection is considered on from TCP point of > view.) > > Agreed, [RFC4787]: REQ-6 is too liberal regarding mapping refreshes. > It would be better to recommend Address-Dependent Filtering and > Address-Dependent mapping refreshes. > > 8.1 Agreed, this point has definitely been overlooked too by RFC5382 > > > * 9. EIM Protocol Independence > > Agreed > > > > * 11. Port Randomization > > Agreed, although it doesn't alleviate the fact the port randomization > should be implemented by the client OS in the first place. The NAT > role is not to harden TCP security. > And as you note, this cannot be implemented if the NAT is TCP port > preserving, which makes up the majority of NATs in the wild. > > > > -- > > /Ivan C./ > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- ---------------------------------------- NTT Network Technology Laboratories Kengo Naito E-Mail: naito.kengo@lab.ntt.co.jp TEL: +81 422-59-4949 ---------------------------------------- --------------020003090909030907050509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Ivan,

Thank you for the review of our draft.
Please see my comments inline,

(2013/06/17 4:14), ivan c wrote:

Hello,

This is my review of draft-penno-behave-rfc4787-5382-5508-bis, which is indeed a step in the right direction and corrects omissions and unspecified behaviors left by previous documents. I support its adoption as a working group document.

 

 


* 3.1.2.1. Rewrite timestamp and sequence number values at NAT

Requiring NATs to rewrite timestamps and ISNs seems overkill. Generally, mangling with the TCP protocol header other than by rewriting the source endpoint should not be done by NATs.
On the other hand, improving the current situation regarding the TIME_WAIT state by carefully designed filtering rules without altering the TCP header seems acceptable.

Then, how about using 3.1.2.2 ? This alternative do not rewrite timestamps nor ISNs.
Also, I do not intend to make 3.1.2.1 "must", this is only one of alternatives.


* 4. Port overlapping behavior

This is becoming a pressing issue due to increase deployment of CGNs for IPv4 worldwide.
As far as I know, the traditional term to describe this behavior is "port overloading". The term overlapping refers to when two sets have a non empty intersection (they are said to be "overlapping" sets). Overloading is the correct term and was previously used in RFC5382 and RFC4787.
Port overloading is problematic for UDP, as P2P applications generally multiplex several UDP communications over the same socket. The probability that two internal peers communicate to the same remote endpoint can be non-negligeable, depending on the number of UDP communications and characteristics intrinsic to the p2p application. See Birthday Paradox.

In the draft, I meant that Port overlapping behavior can only be used when the 5-tupple of connections are different.
So I think it is a bit different from overlapping behavior you wrote.
Does this behavior cause any bad effect?

For TCP, this problem does not arise nrealy as much as there is a one-to-one mapping between sockets and TCP communications (POSIX does not allow to bind multiple sockets to the same local endpoint for outbound connections). Thus the probability for conflict is much lower.

[RFC5382] REQ-1 indeed requires EIM, but it is important to note that the EIM behavior is required by applications that rely on a POSIX "hack", that is the set up of the SO_REUSEADDR option on the socket to bind two successive outbound connections on the same local endpoint. This hack is controversial and thus [RFC5382] REQ-1 is subject to controversy, for the following reasons: SO_REUSEADDR behavior is left unspecified by POSIX. SO_REUSEADDR is generally implemented by OSes to bypass the TIME_WAIT state for network servers. It violates TCP quiet time, TIME_WAIT and can lead to data corruption. It should generally only be used by listening servers, not client making outbound connections. Its use is discouraged in production for listening servers. RFC 6528.

A correct way to achieve TCP port prediction (which is what [RFC5382] REQ-1 is really about without saying it) without relying on POSIX hacks is to require the NAT to be port-preserving. Port prediction is straightforward in the case of port preservation. It also works nicely with port overloading, and allows p2p applications to work without the need of a third party public server for each TCP communication instantiation. Thus it allows NAT traversal for fully decentralized p2p applications. Most NATs in the wild implement TCP port preservation for this reason.


* End of page 8

The external references provided point to a website written only in japanese. It would be nice to provide a pointer to the english version of these web pages.

Thanks for pointing, I should find the English page, and rewrite in next version of the draft.



* 6. EIF Security

Indeed, EIF poses security concerns. At the very least, use of Address-Dependent Filtering should be recommended. Applications requiring EIF to function are clearly badly designed and it is not the role of an RFC to support incorrect designs.


* 7. EIF Protocol Independence

Do you have any reasonable use for this? In other words, a situation where to punch a UDP hole in a NAT, you want to send a TCP SYN first? (If that's the case, why not sending a UDP packet instead of a TCP SYN...?).
If not, it would be cleaner in my opinion to leave this requirement out. If yes, it would be nicer to describe the real-world use, as i'm sure most of us are not familiar with it.


* 8. EIF Mapping Refresh

(This really only applies to UDP. For TCP, NATs simply keep the mapping as long as the connection is considered on from TCP point of view.)

Agreed, [RFC4787]: REQ-6 is too liberal regarding mapping refreshes. It would be better to recommend Address-Dependent Filtering and Address-Dependent mapping refreshes.

  8.1 Agreed, this point has definitely been overlooked too by RFC5382


* 9. EIM Protocol Independence

Agreed



* 11. Port Randomization

Agreed, although it doesn't alleviate the fact the port randomization should be implemented by the client OS in the first place. The NAT role is not to harden TCP security.
And as you note, this cannot be implemented if the NAT is TCP port preserving, which makes up the majority of NATs in the wild.



 

 

--

Ivan C.


_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave



-- 
----------------------------------------
NTT Network Technology Laboratories
Kengo Naito
E-Mail: naito.kengo@lab.ntt.co.jp
TEL: +81 422-59-4949 
----------------------------------------
--------------020003090909030907050509-- From simon.perreault@viagenie.ca Tue Jun 18 01:05:19 2013 Return-Path: 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 42F2521F9AAE for ; Tue, 18 Jun 2013 01:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 YyHHp2x5BZM6 for ; Tue, 18 Jun 2013 01:05:18 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id BFF8221F9AAC for ; Tue, 18 Jun 2013 01:05:18 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:84c5:867d:e648:8153]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3C86E40411 for ; Tue, 18 Jun 2013 04:05:17 -0400 (EDT) Message-ID: <51C014BD.8070008@viagenie.ca> Date: Tue, 18 Jun 2013 10:05:17 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: behave@ietf.org References: <51BF2333.2010700@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] REQ 1 and REQ 7 of RFC5382 were supposed to be fixed years ago X-BeenThere: behave@ietf.org 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 08:05:19 -0000 Ivan, Thanks for the explanation. I believe I have a good understanding of what you are proposing now. There are several smaller technical issues with your reasoning which I won't address now because they are tangential. I want to focus on your suggestion that we should recommend port preservation. I see the following major issues: - Adding new constraints on NAT implementations is not going to meet much success. I don't believe anyone is going to change their existing NAT code now in such a fundamental way as to implement port preservation just because the IETF asks for it in a new RFC. - Port preservation is not applicable to CGN, where a subscriber often only has access to a limited range of external ports. - There are ways to improve the scalability of EIM without killing it. I've been advocating for some time that NATs should be allowed to use EDM for protocols that they know will not break, with EIM as a default. For example, using EDM for TCP port 80 and UDP port 53 is easy, harmless, and has a big impact. Simon From ssenthil@cisco.com Tue Jun 18 09:17:02 2013 Return-Path: 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 D5F9921F9AAA for ; Tue, 18 Jun 2013 09:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 OoR98dnWyyLe for ; Tue, 18 Jun 2013 09:16:57 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D905021F9AA1 for ; Tue, 18 Jun 2013 09:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2107; q=dns/txt; s=iport; t=1371572209; x=1372781809; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=gUEaclw+RSlllm/mQTKjMHhiR7ZveIfBcWBWSsK7Eo4=; b=RlNNuBdnis5doF8N7pzPbZ9fiDVAir/iuWe1mQ/6w6mXhIJxT7FUygFf WEFI/2ogQAAdcN/EhXVP2WHiN3hnjhILJVseMYtWq0J46E+DoM2+Qaz+/ jgvFxN9N/KdlXIgwYovE0cMIw6I8PrhCkWftEjsGlJkZ+5LuX5wVCnIEa M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAJeHwFGtJXG+/2dsb2JhbABZgwkxSb8PgQIWdIIlAQQBAQFrHQEIIksLJQIEARIIiAYMuwIEjgOBBziDAGEDiGigHIMPgWhA X-IronPort-AV: E=Sophos;i="4.87,890,1363132800"; d="scan'208";a="224130002" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 18 Jun 2013 16:16:33 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5IGGXIc006630 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Jun 2013 16:16:33 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.94]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Tue, 18 Jun 2013 11:16:33 -0500 From: "Senthil Sivakumar (ssenthil)" To: Simon Perreault , "behave@ietf.org" Thread-Topic: [BEHAVE] REQ 1 and REQ 7 of RFC5382 were supposed to be fixed years ago Thread-Index: AQHOa/qXCubtvgYPbUeZdTOIuz/LZJk7ty+A Date: Tue, 18 Jun 2013 16:16:33 +0000 Message-ID: In-Reply-To: <51C014BD.8070008@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [64.102.83.125] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] REQ 1 and REQ 7 of RFC5382 were supposed to be fixed years ago X-BeenThere: behave@ietf.org 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 16:17:03 -0000 On 6/18/13 4:05 AM, "Simon Perreault" wrote: >Ivan, > >Thanks for the explanation. I believe I have a good understanding of >what you are proposing now. > >There are several smaller technical issues with your reasoning which I >won't address now because they are tangential. I want to focus on your >suggestion that we should recommend port preservation. I see the >following major issues: > >- Adding new constraints on NAT implementations is not going to meet >much success. I don't believe anyone is going to change their existing >NAT code now in such a fundamental way as to implement port preservation >just because the IETF asks for it in a new RFC. I just want to add that I did a port preservation implementation a while ago, but realized that the number of times that the ports couldn=B9t be preserved were getting more and more. Even though this wasn't causing any application behavior issues, the customers were complaining because they construed that as NAT not working properly, (whether their assumption that is right or wrong is a different discussion), so we ended up not using the port preservation as a default behavior in later implementations. It also improves the performance. > >- Port preservation is not applicable to CGN, where a subscriber often >only has access to a limited range of external ports. Exactly, with the allocation of port sets in CGN, it becomes very difficult to do any kind of port preservation. > >- There are ways to improve the scalability of EIM without killing it. >I've been advocating for some time that NATs should be allowed to use >EDM for protocols that they know will not break, with EIM as a default. >For example, using EDM for TCP port 80 and UDP port 53 is easy, >harmless, and has a big impact. For allowing EDM, one has to know their applications they are using, but as you say port 80 can work well with EDM. > >Simon >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From ivan@cacaoweb.org Tue Jun 18 09:50:03 2013 Return-Path: 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 6F2E621F9A5F for ; Tue, 18 Jun 2013 09:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_25=0.6] 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 kn-jaAtfrgM9 for ; Tue, 18 Jun 2013 09:49:58 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id 47E8221F9A34 for ; Tue, 18 Jun 2013 09:49:58 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1Uoz7I-000526-NC for behave@ietf.org; Tue, 18 Jun 2013 18:50:48 +0200 To: Behave X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Tue, 18 Jun 2013 18:50:48 +0200 From: ivan c Organization: cacaoweb In-Reply-To: <51BFE896.2000006@lab.ntt.co.jp> References: <3a724be2431cf7249b3d46cf378f85bf@cacaoweb.org> <51BFE896.2000006@lab.ntt.co.jp> Message-ID: <1d235e99689e55aba94258ff65895f75@cacaoweb.org> X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Subject: Re: [BEHAVE] review of draft-penno-behave-rfc4787-5382-5508-bis 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 16:50:03 -0000 Hi Kengo, See my answers interleaved below. On Tue, 18 Jun 2013 13:56:54 +0900, Kengo Naito wrote: > Then, how about using 3.1.2.2 ? This alternative do not rewrite > timestamps nor ISNs. > Also, I do not intend to make 3.1.2.1 "must", this is only one of > alternatives. 3.1.2.1 will be most definitely frowned upon. Before suggesting such alternative, the benefits need to be quantified in terms of CGN resources usage. Is the TIME_WAIT state really that much of an issue for CGN resource utilization? It looks to me as a micro-optimization. Of course, this can still be suggested as a MAY in the document (as it's an interesting idea). 3.1.2.2 I was unable to fully grasp the idea and its relationship with the TIME_WAIT state, it would be nice if you could elaborate on this. 3.1.2.3 you're mangling with the TCP protocol itself, which is arguably even more intrusive than mangling with so fields in the TCP header like in 3.1.2.1 3.1.2.4 I don't think that RFC6191 is widely deployed, do you have any reference for this? > In > the draft, I meant that Port overlapping behavior can only be used when the > 5-tupple of connections are different. > So I think it is a bit different from overlapping behavior you wrote. > Does this behavior cause any bad effect? There are a few issues with the section 4. of the draft. Quoting: "This document clarifies that this port overlapping behavior can be extended to connections originating from different interal source IP:ports as long as their destinations are different. This known as EDM (Endpoint Dependent Mapping)." No, EDM, EIM, always refer to sessions originating from the *same local endpoint*. Here you are describing a "port overlapping" behavior for sessions originating from distinct endpoints. This is known as "port overloading". EDM refers to the case where we can sometimes "break" the EIM requirement, for example when we know it doesn't adversely affect the application (such as with HTTP). In your second paragraph, you clearly describe the "port overloading" behavior. Thus, I think you should drop the "port overlapping" terminology, replace it with "port overloading", and don't mention EDM (Endpoint-Dependent Mapping), which is not directly related to the topic. Port overloading does not have any bad effects. Of course, as long as the 5-tuple uniqueness is preserved by the NAT, which is a MUST in any case. However, doing aggressive port overloading generates opportunities for collisions, which must be dealt with by dropping a session or breaking the EIM requirement, which is a serious problem for UDP, but not so much for TCP. Such collision events remain rare, and it is OK to break EIM sometimes for TCP, as the application can make a retry (using a new ephemeral local port), that will most certainly work the second time. I can help you develop and improve the section 4. of the draft with you if you'd like. Regards, Ivan From ivan@cacaoweb.org Tue Jun 18 09:56:24 2013 Return-Path: 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 AB13421F9AAE for ; Tue, 18 Jun 2013 09:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 aO249KJ0nTcf for ; Tue, 18 Jun 2013 09:56:20 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id 390C021F972E for ; Tue, 18 Jun 2013 09:56:16 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1UozDP-00058K-DX for behave@ietf.org; Tue, 18 Jun 2013 18:57:07 +0200 To: Behave X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Tue, 18 Jun 2013 18:57:07 +0200 From: ivan c Organization: cacaoweb In-Reply-To: <51C014BD.8070008@viagenie.ca> References: <51BF2333.2010700@viagenie.ca> <51C014BD.8070008@viagenie.ca> Message-ID: X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Subject: Re: [BEHAVE] REQ 1 and REQ 7 of RFC5382 were supposed to be fixed years ago 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 16:56:24 -0000 Hi Simon, See my comments interleaved. On Tue, 18 Jun 2013 10:05:17 +0200, Simon Perreault wrote: > Ivan, > > Thanks for the explanation. I believe I have a good understanding of > what you are proposing now. > > There are several smaller technical issues with your reasoning which I > won't address now because they are tangential. I want to focus on your > suggestion that we should recommend port preservation. I see the > following major issues: > > - Adding new constraints on NAT implementations is not going to meet > much success. I don't believe anyone is going to change their existing > NAT code now in such a fundamental way as to implement port preservation > just because the IETF asks for it in a new RFC. (First, to avoid any confusion, it is important to use the term "TCP port preservation" instead of just "port preservation", as this only applies to TCP) In reality, TCP port preservation has already implemented by most home NATs at least. As already noted in Saikat Guha's paper back in 2005, almost all EIM NATs in his sample set were already implementing TCP port preservation. Nowadays, this is even more pervasive: Linksys, Netgear, and many others; in a country like France, this is implemented by most ISP-made internet triple-play gateways (called "Boxes" there) including the ones of Orange, Free, SFR, Numericable, offering a near 100% coverage of the country. The goal is to standardize what has already been widely deployed worldwide, following the IETF mantra, "running code wins". The alternatives for applications when a NAT does not have TCP port preservation are not appealing: STUNT when the NAT is EIM, otherwise UPnP, port forwarding, and, when all options have been exhausted, fallback on the worst of the worst: TCP over UDP (extensively used by bittorrent), which is dangerous for the internet as a whole. > > - Port preservation is not applicable to CGN, where a subscriber often > only has access to a limited range of external ports. It would be nice to elaborate on this. A CGN should leave the whole ephemeral ports range to all its subscribers, which is defined by the IANA to be [2^15+2^14; 2^16-1]. Combined with TCP port overloading, this allows usage of TCP port preservation by CGNs. Rationale of why port overloading is acceptable for TCP: - as long as endpoints are distincts, port overloading preserves the uniqueness of the 5-tuple. - when 2 endpoints are the same, the NAT refuses, silently or actively, the second TCP connection. The application can then retry with a new ephemeral port. If p is the probability of conflict, and n the number of tries, the probability of failure decreases exponentially in p^n, which gives an essentially deterministic behavior. As a collision is expected to be a rare event, the probability p would be small anyway. > > - There are ways to improve the scalability of EIM without killing it. > I've been advocating for some time that NATs should be allowed to use > EDM for protocols that they know will not break, with EIM as a default. > For example, using EDM for TCP port 80 and UDP port 53 is easy, > harmless, and has a big impact. Agreed, although some extra care is needed, as explained below, the benefits clearly outweigh the complexity of the implementation. As a preliminary remark, the use case that you mention of DNS request is out of scope because each DNS request uses a new socket (non-bound, so it uses a new local endpoint). As a result this doesn't reuse an existing NAT mapping. Anyway, EDM should not be used as a fallback for UDP, for reasons i'll skip for now, as I'm assuming the contentious point for CGNs is TCP, not UDP. First of all, the context for TCP: fallback on EDM is somewhat desirable when there is a conflicting mapping. The alternative would be to actively or silently refuse the outgoing TCP SYN, which is not desirable as it somewhat breaks end-to-end connectivity guarantees. (although browsers for instance are known to retry connections) A NAT can fallback on EDM when it is clearly assumed that the application issuing the TCP SYN is not P2P. This is often the case for HTTP, and can be used as a heuristic by the NAT/CGN. However, these heuristics might be a lot more complicated that what we may have anticipated, for the following non-exhaustive list of reasons: - although HTTP is usually used with active/passive TCP socket pairs (client/server), nothing prevents it from being used in a P2P context with TCP simultaneous open. This is already being seen in the wild. - port numbers do not give any information about the upper-layer protocol, at most they can provide some heuristics. We know that P2P applications *love* to impersonate well-known ports to bypass firewall policies. For example, Skype *always* binds on 80 or 443 if it sees you have UPnP activated in your gateway - DPI doesn't prove to be a much help either for our heuristics: for instance, Skype simulate an HTTP or SSL handshake on ports 80 or 443. The reason, again, is to bypass intermediate firewall policies. On the other hand, in the following use case, EDM is perfectly acceptable: a TCP SYN is sent by a client behind a NAT, and the destination appears to be a well-known HTTP server belonging to Google, Facebook, etc. As this use case represents a sizeable amount of the current internet traffic, I would definitely mention this in an RFC. A CGN would simply need to carry a static, updatable list of ip addresses ranges of well-known popular HTTP servers, to allow fallback on EDM when desired. > > Simon > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- _Ivan Chollet_ From ivan@cacaoweb.org Tue Jun 18 10:10:11 2013 Return-Path: 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 4344121F9B7E for ; Tue, 18 Jun 2013 10:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 44OFeA4VhB9K for ; Tue, 18 Jun 2013 10:10:06 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id EB59521F9B7D for ; Tue, 18 Jun 2013 10:10:05 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1UozQm-0005Q5-Ig; Tue, 18 Jun 2013 19:10:56 +0200 To: Behave X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Tue, 18 Jun 2013 19:10:56 +0200 From: ivan c Organization: cacaoweb In-Reply-To: References: Message-ID: <29cbc62347efa3a4efcf6105d04e531d@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 17:10:11 -0000 Hi Senthil, See my comments below. On Tue, 18 Jun 2013 16:16:33 +0000, "Senthil Sivakumar (ssenthil)" wrote: > > I just want to add that I did a port preservation implementation a while > ago, but realized that the number of times that the ports couldn¹t be > preserved were getting more and more. Even though this wasn't causing any > application behavior issues, the customers were complaining because they > construed that as NAT not working properly, (whether their assumption that > is right or wrong is a different discussion), so we ended up not using the > port preservation as a default behavior in later implementations. It also > improves the performance. > Are you talking about UDP port preservation? I think we all agree UDP port preservation is not necessary, as long as the NAT is EIM for UDP. About TCP port preservation, most NAT implementations have it. In some countries (like France), all ISP-provided gateways have it. As you note, TCP port preservation improves latency and thus performance, when compared to the alternative of using a STUNT server. It does not need the intermediate step of contacting the STUNT server to perform TCP port prediction. > >> >>- Port preservation is not applicable to CGN, where a subscriber often >>only has access to a limited range of external ports. > > Exactly, with the allocation of port sets in CGN, it becomes very > difficult to do any kind of port preservation. > Nope, you would need to elaborate on this. The probability that of an internal port collision is high because of the birthday paradox, but port overloading is perfectly acceptable, and when a full collision occurs (when internal ports and remote endpoints are the same for two outgoing TCP connections), which is supposed to be a rare event, the CGN can fallback on EDM or simply drop the connection. >> >>- There are ways to improve the scalability of EIM without killing it. >>I've been advocating for some time that NATs should be allowed to use >>EDM for protocols that they know will not break, with EIM as a default. >>For example, using EDM for TCP port 80 and UDP port 53 is easy, >>harmless, and has a big impact. > > For allowing EDM, one has to know their applications they are using, but > as you say port 80 can work well with EDM. > Exactly, see my message to Simon for a more in-depth discussion about this topic. -- _Ivan Chollet_ From ivan@cacaoweb.org Tue Jun 18 10:25:00 2013 Return-Path: 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 3356B21F9B88 for ; Tue, 18 Jun 2013 10:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 yrn0vC3BG381 for ; Tue, 18 Jun 2013 10:24:46 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id 19C6E21F9B91 for ; Tue, 18 Jun 2013 10:24:46 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1Uozez-0005hP-AX for behave@ietf.org; Tue, 18 Jun 2013 19:25:37 +0200 To: Behave X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_aed318f3e2ca49a2ddb41f478050057f" Date: Tue, 18 Jun 2013 19:25:37 +0200 From: ivan c Organization: cacaoweb Message-ID: X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Subject: [BEHAVE] p2p applications using STUNT and EIM NATs for TCP 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 17:25:00 -0000 --=_aed318f3e2ca49a2ddb41f478050057f Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hello, Does any of you has examples of applications that use a STUNT server together with an EIM NAT for TCP? This is the single purpose (besides the convenience of the implementation) of having an EIM NAT in the first place: performing port prediction with the help of a STUNT server. Surprisingly, I am not aware of any applications that rely on that. All the p2p applications that I know of use different techniques for TCP Hole Punching or use other alternatives, such as UPnP, port forwarding, etc. It would be important to somewhat quantify the usage of this technique in the wild. -- _Ivan Chollet_ --=_aed318f3e2ca49a2ddb41f478050057f Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hello,

Does any of you has examples of applications that use a STUNT server tog= ether with an EIM NAT for TCP?

This is the single purpose (besides the convenience of the implementatio= n) of having an EIM NAT in the first place: performing port prediction with= the help of a STUNT server. Surprisingly, I am not aware of any applicatio= ns that rely on that. All the p2p applications that I know of use different= techniques for TCP Hole Punching or use other alternatives, such as UPnP, = port forwarding, etc.

It would be important to somewhat quantify the usage of this technique i= n the wild.

 

--

Ivan Chollet
--=_aed318f3e2ca49a2ddb41f478050057f-- From ssenthil@cisco.com Tue Jun 18 12:24:58 2013 Return-Path: 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 6DE9211E80FA for ; Tue, 18 Jun 2013 12:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.723 X-Spam-Level: X-Spam-Status: No, score=-9.723 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_HI=-8] 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 wWKWTwXfVQsA for ; Tue, 18 Jun 2013 12:24:52 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7A05111E80F6 for ; Tue, 18 Jun 2013 12:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4062; q=dns/txt; s=iport; t=1371583492; x=1372793092; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=omyAhBnL+HKOtcZl7u9vAuntLu2Ym6c8Qi4JElcNFXs=; b=KXX5TSiBgfC+J7xyai5ioQuMm9mhYc8cnVx3YyR7+gf+2Q3wpEz6ZbNs yMGpk5CtSnIaJld3y8eUVa10nST0ocgm62mp6/lbyU1FvAC43QC7cqBHb zb5iLD9YKP8X2e1wBhGU5DNtveiPsStQ9Q19dKPRhF4mapW40hLQj2JQq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAPeywFGtJV2Z/2dsb2JhbABZgwl6gwG8Dw12FnSCIwEBAQQ0VwkYBAYiBDAlAgQBEgiIBo1/mzUGkUaBIIxjgQcWIoJHOWEDoVSHMIMPgWhA X-IronPort-AV: E=Sophos;i="4.87,890,1363132800"; d="scan'208";a="224216674" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 18 Jun 2013 19:24:51 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5IJOpVQ010583 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Jun 2013 19:24:51 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.94]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Tue, 18 Jun 2013 14:24:51 -0500 From: "Senthil Sivakumar (ssenthil)" To: "ivan@cacaoweb.org" , Behave Thread-Index: AQHObFmAgdHlRyxSR02wAQ7tdo7juA== Date: Tue, 18 Jun 2013 19:24:50 +0000 Message-ID: In-Reply-To: <29cbc62347efa3a4efcf6105d04e531d@cacaoweb.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [64.102.83.125] Content-Type: text/plain; charset="euc-kr" Content-ID: <64B5F9250930354A9695958C16900D8B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 19:24:58 -0000 SGkgSXZhbiwNCg0KT24gNi8xOC8xMyAxOjEwIFBNLCAiaXZhbiBjIiA8aXZhbkBjYWNhb3dlYi5v cmc+IHdyb3RlOg0KDQo+SGkgU2VudGhpbCwNCj4NCj5TZWUgbXkgY29tbWVudHMgYmVsb3cuDQo+ DQo+T24gVHVlLCAxOCBKdW4gMjAxMyAxNjoxNjozMyArMDAwMCwgIlNlbnRoaWwgU2l2YWt1bWFy IChzc2VudGhpbCkiDQo+PHNzZW50aGlsQGNpc2NvLmNvbT4gd3JvdGU6DQo+DQo+PiANCj4+IEkg anVzdCB3YW50IHRvIGFkZCB0aGF0IEkgZGlkIGEgcG9ydCBwcmVzZXJ2YXRpb24gaW1wbGVtZW50 YXRpb24gYSB3aGlsZQ0KPj4gYWdvLCBidXQgcmVhbGl6ZWQgdGhhdCB0aGUgbnVtYmVyIG9mIHRp bWVzIHRoYXQgdGhlIHBvcnRzIGNvdWxkbqn2dCBiZQ0KPj4gcHJlc2VydmVkIHdlcmUgZ2V0dGlu ZyBtb3JlIGFuZCBtb3JlLiBFdmVuIHRob3VnaCB0aGlzIHdhc24ndCBjYXVzaW5nDQo+YW55DQo+ PiBhcHBsaWNhdGlvbiBiZWhhdmlvciBpc3N1ZXMsIHRoZSBjdXN0b21lcnMgd2VyZSBjb21wbGFp bmluZyBiZWNhdXNlIHRoZXkNCj4+IGNvbnN0cnVlZCB0aGF0IGFzIE5BVCBub3Qgd29ya2luZyBw cm9wZXJseSwgKHdoZXRoZXIgdGhlaXIgYXNzdW1wdGlvbg0KPnRoYXQNCj4+IGlzIHJpZ2h0IG9y IHdyb25nIGlzIGEgZGlmZmVyZW50IGRpc2N1c3Npb24pLCBzbyB3ZSBlbmRlZCB1cCBub3QgdXNp bmcNCj50aGUNCj4+IHBvcnQgcHJlc2VydmF0aW9uIGFzIGEgZGVmYXVsdCBiZWhhdmlvciBpbiBs YXRlciBpbXBsZW1lbnRhdGlvbnMuIEl0DQo+YWxzbw0KPj4gaW1wcm92ZXMgdGhlIHBlcmZvcm1h bmNlLg0KPj4gDQo+DQo+QXJlIHlvdSB0YWxraW5nIGFib3V0IFVEUCBwb3J0IHByZXNlcnZhdGlv bj8gSSB0aGluayB3ZSBhbGwgYWdyZWUgVURQIHBvcnQNCj5wcmVzZXJ2YXRpb24gaXMgbm90IG5l Y2Vzc2FyeSwgYXMgbG9uZyBhcyB0aGUgTkFUIGlzIEVJTSBmb3IgVURQLg0KPkFib3V0IFRDUCBw b3J0IHByZXNlcnZhdGlvbiwgbW9zdCBOQVQgaW1wbGVtZW50YXRpb25zIGhhdmUgaXQuIEluIHNv bWUNCj5jb3VudHJpZXMgKGxpa2UgRnJhbmNlKSwgYWxsIElTUC1wcm92aWRlZCBnYXRld2F5cyBo YXZlIGl0Lg0KPkFzIHlvdSBub3RlLCBUQ1AgcG9ydCBwcmVzZXJ2YXRpb24gaW1wcm92ZXMgbGF0 ZW5jeSBhbmQgdGh1cyBwZXJmb3JtYW5jZSwNCj53aGVuIGNvbXBhcmVkIHRvIHRoZSBhbHRlcm5h dGl2ZSBvZiB1c2luZyBhIFNUVU5UIHNlcnZlci4NCj5JdCBkb2VzIG5vdCBuZWVkIHRoZSBpbnRl cm1lZGlhdGUgc3RlcCBvZiBjb250YWN0aW5nIHRoZSBTVFVOVCBzZXJ2ZXIgdG8NCj5wZXJmb3Jt IFRDUCBwb3J0IHByZWRpY3Rpb24uDQoNCkJvdGggVENQICYgVURQLiBUaGUgbGF0ZXN0IGltcGxl bWVudGF0aW9uIGluIHNvbWUgcm91dGVyIGZhbWlsaWVzIGlzIG5vdA0KdG8gaGF2ZSBwb3J0IHBy ZXNlcnZhdGlvbg0KKGZvciBib3RoIFRDUCAmIFVEUCkuDQoNCj4NCj4NCj4+IA0KPj4+DQo+Pj4t IFBvcnQgcHJlc2VydmF0aW9uIGlzIG5vdCBhcHBsaWNhYmxlIHRvIENHTiwgd2hlcmUgYSBzdWJz Y3JpYmVyIG9mdGVuDQo+Pj5vbmx5IGhhcyBhY2Nlc3MgdG8gYSBsaW1pdGVkIHJhbmdlIG9mIGV4 dGVybmFsIHBvcnRzLg0KPj4gDQo+PiBFeGFjdGx5LCB3aXRoIHRoZSBhbGxvY2F0aW9uIG9mIHBv cnQgc2V0cyBpbiBDR04sIGl0IGJlY29tZXMgdmVyeQ0KPj4gZGlmZmljdWx0IHRvIGRvIGFueSBr aW5kIG9mIHBvcnQgcHJlc2VydmF0aW9uLg0KPj4gDQo+DQo+Tm9wZSwgeW91IHdvdWxkIG5lZWQg dG8gZWxhYm9yYXRlIG9uIHRoaXMuDQo+VGhlIHByb2JhYmlsaXR5IHRoYXQgb2YgYW4gaW50ZXJu YWwgcG9ydCBjb2xsaXNpb24gaXMgaGlnaCBiZWNhdXNlIG9mIHRoZQ0KPmJpcnRoZGF5IHBhcmFk b3gsIGJ1dCBwb3J0IG92ZXJsb2FkaW5nIGlzIHBlcmZlY3RseSBhY2NlcHRhYmxlLCBhbmQgd2hl biBhDQo+ZnVsbCBjb2xsaXNpb24gb2NjdXJzICh3aGVuIGludGVybmFsIHBvcnRzIGFuZCByZW1v dGUgZW5kcG9pbnRzIGFyZSB0aGUNCj5zYW1lIGZvciB0d28gb3V0Z29pbmcgVENQIGNvbm5lY3Rp b25zKSwgd2hpY2ggaXMgc3VwcG9zZWQgdG8gYmUgYSByYXJlDQo+ZXZlbnQsIHRoZSBDR04gY2Fu IGZhbGxiYWNrIG9uIEVETSBvciBzaW1wbHkgZHJvcCB0aGUgY29ubmVjdGlvbi4NCg0KTW9zdCBv ZiB0aGUgTkFUcyB0aGF0IEkga25vdyBkb26hr3QgZG8gcG9ydCBvdmVybG9hZGluZyBhbnkgbW9y ZS4NClJGQyA1MzgyIGFsc28gc2F5cywNClJFUS03OiAgQSBOQVQgTVVTVCBOT1QgaGF2ZSBhICJQ b3J0IGFzc2lnbm1lbnQiIGJlaGF2aW9yIG9mICJQb3J0DQogICAgICBvdmVybG9hZGluZyIgZm9y IFRDUC4NCg0KDQpUaGFua3MNClNlbnRoaWwNCj4NCj4NCj4NCj4+Pg0KPj4+LSBUaGVyZSBhcmUg d2F5cyB0byBpbXByb3ZlIHRoZSBzY2FsYWJpbGl0eSBvZiBFSU0gd2l0aG91dCBraWxsaW5nIGl0 Lg0KPj4+SSd2ZSBiZWVuIGFkdm9jYXRpbmcgZm9yIHNvbWUgdGltZSB0aGF0IE5BVHMgc2hvdWxk IGJlIGFsbG93ZWQgdG8gdXNlDQo+Pj5FRE0gZm9yIHByb3RvY29scyB0aGF0IHRoZXkga25vdyB3 aWxsIG5vdCBicmVhaywgd2l0aCBFSU0gYXMgYSBkZWZhdWx0Lg0KPj4+Rm9yIGV4YW1wbGUsIHVz aW5nIEVETSBmb3IgVENQIHBvcnQgODAgYW5kIFVEUCBwb3J0IDUzIGlzIGVhc3ksDQo+Pj5oYXJt bGVzcywgYW5kIGhhcyBhIGJpZyBpbXBhY3QuDQo+PiANCj4+IEZvciBhbGxvd2luZyBFRE0sIG9u ZSBoYXMgdG8ga25vdyB0aGVpciBhcHBsaWNhdGlvbnMgdGhleSBhcmUgdXNpbmcsIGJ1dA0KPj4g YXMgeW91IHNheSBwb3J0IDgwIGNhbiB3b3JrIHdlbGwgd2l0aCBFRE0uDQo+PiANCj4NCj5FeGFj dGx5LCBzZWUgbXkgbWVzc2FnZSB0byBTaW1vbiBmb3IgYSBtb3JlIGluLWRlcHRoIGRpc2N1c3Np b24gYWJvdXQgdGhpcw0KPnRvcGljLg0KPg0KPg0KPg0KPi0tIA0KPl9JdmFuIENob2xsZXRfDQoN Cg== From rajiva@cisco.com Tue Jun 18 13:25:09 2013 Return-Path: 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 34C7F11E80E9 for ; Tue, 18 Jun 2013 13:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 nHFaNPq2uawF for ; Tue, 18 Jun 2013 13:24:57 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E679511E80EC for ; Tue, 18 Jun 2013 13:24:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6254; q=dns/txt; s=iport; t=1371587097; x=1372796697; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=wmmuWQofZnh63U964MwLtNu7JgO3hkIcg0+yBj+4SEI=; b=jxWzijboFJDOd9S5d6iG1GDdky9Y3hfKx4AFj/ClUc2mEJW4jfFciQzH IbBwkoBXWo4IXfiASmX3g/VlNNRK+5N0jf756SaYB1rZIwI96LKjaEpHP S2yYAq5iT6fKvQ0bE9WsEFfJm10l/A0afEsTdoWcrTQeJockJFcD9/vqH s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAK3BwFGtJXG9/2dsb2JhbABagwkxSYMBvA4NdxZ0giMBAQECAQEjETgCCAgHBAIBCBEEAQEBAgIGHQMCAgIwFAEICAIEARIIE4dtBgypNJE/gSaMUwEJAYEGDykGgkczYQOYapAagw+BaAEIFyA X-IronPort-AV: E=Sophos;i="4.87,891,1363132800"; d="scan'208";a="224409248" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 18 Jun 2013 20:24:56 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5IKOu2G014784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Jun 2013 20:24:56 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.251]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Tue, 18 Jun 2013 15:24:56 -0500 From: "Rajiv Asati (rajiva)" To: "ivan@cacaoweb.org" , "behave@ietf.org" Thread-Topic: [BEHAVE] [v6ops] Home NAPT44 - How many ports? Thread-Index: AQHOauBIZqLTYe5o/06CtFUC+f5ixpk7pGSA Date: Tue, 18 Jun 2013 20:24:55 +0000 Message-ID: References: <6d6816c3367bc3c3bcf3795fbc850701@cacaoweb.org> In-Reply-To: <6d6816c3367bc3c3bcf3795fbc850701@cacaoweb.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.238.113] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [BEHAVE] [v6ops] Home NAPT44 - How many ports? X-BeenThere: behave@ietf.org 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:25:09 -0000 PkknbSBub3Qgc3VyZSB3aGV0aGVyIG9ic2VydmluZyB0cmFmZmljIG9uIHlvdXIgbG9jYWwgcGVy c29uYWwgaW50ZXJuZXQgY29ycmVjdGlvbiANCj5hbmQgdGhlbiBleHRyYXBvbGF0aW5nIHRoaXMg YmVoYXZpb3IgZm9yIHRoZSB3b3JsZHdpZGUgaW50ZXJuZXQgYXMgYSB3aG9sZSBpcyBhIHZlcnkN Cj5zY2llbnRpZmljIG1ldGhvZCwgDQoNCkl0IGlzIG5vdC4gSSBhZ3JlZS4gDQpJdCBpcyBtZWFu dCB0byBiZSBqdXN0IGEgc2FtcGxlIChhcyBJIHN0YXRlZCBpbiBteSB2ZXJ5IGZpcnN0IGVtYWls KS4NCg0KDQo+IGVzcGVjaWFsbHkgd2hlbiB0aGUgcHVycG9zZSBpcyB0aGUgcmVkYWN0aW9uIG9m IG5vcm1hbGl6YXRpb24gYW5kDQo+IGludGVyb3BlcmFiaWxpdHkgZG9jdW1lbnRzLiBCdXQgaXQn cyBzdXJlbHkgYW4gaW50ZXJlc3RpbmcgZXhlcmNpc2UuIA0KDQpJbmRlZWQuIFNvbWV0aGluZyBp cyBiZXR0ZXIgdGhhbiBub3RoaW5nLiANCg0KPiBJIG5vdGljZWQgdGhhdCBpbiB5b3VyIGV4cGVy aW1lbnQgeW91IGxlYXZlIG91dCBwb3B1bGFyIHByb3RvY29scyBsaWtlIGJpdCB0b3JyZW50LCAN Cj4gd2hpY2ggbWFrZXMgdXAgbW9zdCBvZiB0aGUgaW50ZXJuZXQgd29ybGQgdHJhZmZpYyBhbmQg d291bGQgc3VyZWx5IGdhaW4gdG8gYmUNCj4gIGludGVncmF0ZWQgaW4gc3VjaCBkYXRhIHNlcmll cy4NCg0KSW50ZXJlc3RpbmcgZW5vdWdoLCBtYW55IG9mIHRoZSByZWNlbnQgbWVhc3VyZW1lbnRz IHN1Z2dlc3QgdGhhdCB0aGUgdG9ycmVudCcgbGlrZSBwMnAgYXBwbGljYXRpb25zIGFyZSBubyBs b25nZXIgdGhlIGJhbmR3aWR0aCBjb25zdW1lcnMgdGhlIHdheSB0aGV5IG9uY2UgdXNlZCB0byBi ZS4gSW4gZmFjdCwgdGhleSBhcmUgbm93IHBlcmNlaXZlZCB0byBiZSAxMC0yMCUgKGFuZCBkZWNs aW5pbmcpIG9mIGludGVybmV0IGJhbmR3aWR0aC4gVGhlIGxhcmdlc3QgaW50ZXJuZXQgd29ybGQg dHJhZmZpYyBjb25zdW1lciBpcyBIVFRQIChhbmQgSFRUUCB2aWRlbykuDQoNCmh0dHA6Ly93d3cu Y2lzY28uY29tL2VuL1VTL3NvbHV0aW9ucy9jb2xsYXRlcmFsL25zMzQxL25zNTI1L25zNTM3L25z NzA1L25zODI3L2ltYWdlcy9WTklfSHlwZXJjb25uZWN0aXZpdHlfV1AtMTIuanBnDQoNCmh0dHA6 Ly93d3cubWljaGFlbHNpbnNpZ2h0LmNvbS8yMDA5LzEwL3NhbmR2aW5lLXRyYWZmaWMtc3R1ZHkt Y29uZmlybXMtdGhlLWRlY2xpbmUtb2YtcDJwLmh0bWwNCg0KaHR0cDovL3d3dy5yZXNlYXJjaC5h dHQuY29tL2V4cG9ydC9zaXRlcy9hdHRfbGFicy90ZWNoZG9jcy9URF8xMDAxOTMucGRmDQoNCg0K Tm9uZXRoZWxlc3MsIEkgZG8gdGhpbmsgYWJvdXQgdGhlIG51bWJlciBvZiBwb3J0cyB0aGF0IHRo ZXNlIHAycCBhcHBsaWNhdGlvbnMgY2FuIGNvbnN1bWUvZXhoYXVzdCwgc2luY2UgdGhhdCBjb3Vs ZCBiZSBpbiAxMDBzIChvciBpbiAxMDAwcykuIFRoYW5rZnVsbHksIG1hbnkgaG9tZSByb3V0ZXIg aW1wbGVtZW50YXRpb25zIG1heSBwcm92aWRlIGNhcGFiaWxpdGllcyB0byByZXN0cmljdCB0aGUg ZXhoYXVzdGlvbiBieSB0aGUgcDJwIGFwcHMuDQoNCj5PbiB0aGUgb3RoZXIgaGFuZCwgc29tZSBw ZW9wbGUgb24gdGhpcyBtYWlsaW5nIGxpc3QgKHdobyB3b3JrIGF0IGxhcmdlIElTUHMsIG9yIGNv cmUgbmV0d29yayByb3V0ZXJzIG1hbnVmYWN0dXJlcnMpIGhhdmUgYWNjZXNzIHRvIHdvdWxkIGxv b2sgbW9yZSBsaWtlIHJlYWwtd29ybGQgc3RhdGlzdGljYWwgZGF0YSBhbmQgd2Ugc2hvdWxkIHBy b2JhYmx5IHR1cm4gdG8gdGhlbSB0byBnZXQgcHJvcGVyIGluZm9ybWF0aW9uIGFib3V0IHdoYXQg aXMgY3VycmVudGx5IGhhcHBlbmluZyBvbiB0aGUgaW50ZXIgbmV0d29ya3MuDQoNCkkgaG9wZSBz by4gSGF2aW5nIHNhaWQgdGhhdCwgbW9zdCB3aXJlbGluZSBJU1BzIGRpZG4ndCB1c2UgQ0dOIHVu dGlsIG5vdywgc28gcG9ydCB1c2FnZSBkYXRhIGlzIG5vdCBkaWZmaWN1bHQgdG8gZ2V0IGJ5Lg0K DQoNCkNoZWVycywNClJhaml2DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBiZWhhdmUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmJlaGF2ZS1ib3VuY2VzQGlldGYu b3JnXSBPbg0KPiBCZWhhbGYgT2YgaXZhbiBjDQo+IFNlbnQ6IFN1bmRheSwgSnVuZSAxNiwgMjAx MyA2OjI1IFBNDQo+IFRvOiBiZWhhdmVAaWV0Zi5vcmcNCj4gQ2M6IFJhaml2IEFzYXRpIChyYWpp dmEpDQo+IFN1YmplY3Q6IFJlOiBbQkVIQVZFXSBbdjZvcHNdIEhvbWUgTkFQVDQ0IC0gSG93IG1h bnkgcG9ydHM/DQo+IA0KPiBPbiBKdW4gNiwgMjAxMywgYXQgNTo0MSBQTSwgIlJhaml2IEFzYXRp IChyYWppdmEpIiA8cmFqaXZhIGF0IGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPiA+IEhpIERhbiwN Cj4gPg0KPiA+PiBhbmQgc28gb24uICBJIGFtIHN1cnByaXNlZCB5b3UgY29uY2x1ZGUgdGhhdCAi NTAwIHNlZW1zIG9rIiB3aGVuIHN1Y2gNCj4gPj4gYSBsaW1pdCB3b3VsZCBpbnRlcmZlcmUgd2l0 aCB5b3VyIG5ldHdvcmsgdXNlIG9uIHRob3NlIGRheXMuDQo+ID4NCj4gPiBJIGJhc2VkIHRoYXQg c3RhdGVtZW50ICgiLi4uc2VlbXMgb2ssIikgb24gdGhlIHZlcnkgZmFjdCB0aGF0IHRoZSBudW1i ZXIgb2YNCj4gdGltZXMgdGhlIE5BVCB1dGlsaXphdGlvbiBleGNlZWRlZCA1MDAgbWFwcGluZ3Mg KGVxdWF0aW5nIHRvIDUwMCBwb3J0cywgaW4NCj4gbXkgc2V0dXApIGluIHRoZSBzYW1wbGUgcGVy aW9kICh+MiBtb250aHMpIHdhcyByZWxhdGl2ZWx5IHF1aXRlIGxvdy4gU28sIGlmDQo+IHRoZSBO QVQgZGV2aWNlIHdhcyBsaW1pdGVkIHRvIG9ubHkgNTAwIG1hcHBpbmdzLCB0aGVuIHRoZSBleHBl cmllbmNlDQo+IHdvdWxkIGhhdmUgYmVlbiBvayBmb3IgOTklIG9mIHRoZSB0aW1lIGFuZCBkZWdy YWRlZCAxJSBvZiB0aGUgdGltZS4gVGhpcw0KPiBpcyBhbiBpbXBvcnRhbnQgY29uc2lkZXJhdGlv biwgSU1PLg0KPiA+DQo+ID4gRm9yIGV4LCBpbiB0aGUgbGFzdCAyIHdlZWtzLCB0aGUgbnVtYmVy IG9mIHRpbWVzIE5BVCBtYXBwaW5ncyBleGNlZWRlZA0KPiA1MDAgd2VyZToNCj4gPg0KPiA+IEp1 bmUgMyAtIDEgdGltZQ0KPiA+IE1heSAyOSAtIDEgdGltZQ0KPiA+IE1heSAyOCAtIDMgdGltZXMN Cj4gPiBNYXkgMjYgLSAxIHRpbWUNCj4gPiBNYXkgMjMgLSAxIHRpbWUNCj4gPiBNYXkgMjIgLSAy IHRpbWVzDQo+ID4gTWF5IDIxIC0gMyB0aW1lcw0KPiA+DQo+ID4gT2YgY291cnNlLCAxMDAwIHBv cnRzIChyZXN1bHRpbmcgaW4gMTAwMCsgbWFwcGluZ3MpIHdvdWxkIGhhdmUgYmVlbiBtb3JlDQo+ IHRoYW4gZW5vdWdoIHRvIGFjY29tbW9kYXRlIHRoZSB0aW1lcyB3aGVuIHRoZSBtYXBwaW5ncyBl eGNlZWRlZCA1MDAsDQo+IGJ1dCBzdGF5ZWQgd2l0aGluIDEwMDAgKGV4Y2VwdCBvbmNlKS4NCj4g Pg0KPiA+DQo+ID4+IFdoYXQgaXMgdGhlIG1heGltdW0gbnVtYmVyIG9mIG1hcHBpbmdzIHN1cHBv cnRlZCBieSB5b3VyIE5BUFQNCj4gZGV2aWNlPw0KPiA+PiBTb21lIHJlc2lkZW50aWFsLWNsYXNz IE5BVHMgaGF2ZSBhIGxpbWl0IG9mIDEwMjQgbWFwcGluZ3MuDQo+ID4NCj4gPiBNeSBOQVBUIGRl dmljZSBzZWVtaW5nbHkgY2FuIHVzZSB1cHRvIDY0SyBwb3J0cy4gOikNCj4gPg0KPiA+IENoZWVy cywNCj4gPiBSYWppdg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IEknbSBub3Qgc3VyZSB3aGV0aGVy IG9ic2VydmluZyB0cmFmZmljIG9uIHlvdXIgbG9jYWwgcGVyc29uYWwgaW50ZXJuZXQNCj4gY29y cmVjdGlvbiBhbmQgdGhlbiBleHRyYXBvbGF0aW5nIHRoaXMgYmVoYXZpb3IgZm9yIHRoZSB3b3Js ZHdpZGUgaW50ZXJuZXQNCj4gYXMgYSB3aG9sZSBpcyBhIHZlcnkgc2NpZW50aWZpYyBtZXRob2Qs IGVzcGVjaWFsbHkgd2hlbiB0aGUgcHVycG9zZSBpcyB0aGUNCj4gcmVkYWN0aW9uIG9mIG5vcm1h bGl6YXRpb24gYW5kIGludGVyb3BlcmFiaWxpdHkgZG9jdW1lbnRzLiBCdXQgaXQncyBzdXJlbHkN Cj4gYW4gaW50ZXJlc3RpbmcgZXhlcmNpc2UuIEkgbm90aWNlZCB0aGF0IGluIHlvdXIgZXhwZXJp bWVudCB5b3UgbGVhdmUgb3V0DQo+IHBvcHVsYXIgcHJvdG9jb2xzIGxpa2UgYml0dG9ycmVudCwg d2hpY2ggbWFrZXMgdXAgbW9zdCBvZiB0aGUgaW50ZXJuZXQNCj4gd29ybGQgdHJhZmZpYyBhbmQg d291bGQgc3VyZWx5IGdhaW4gdG8gYmUgaW50ZWdyYXRlZCBpbiBzdWNoIGRhdGEgc2VyaWVzLg0K PiANCj4gT24gdGhlIG90aGVyIGhhbmQsIHNvbWUgcGVvcGxlIG9uIHRoaXMgbWFpbGluZyBsaXN0 ICh3aG8gd29yayBhdCBsYXJnZSBJU1BzLA0KPiBvciBjb3JlIG5ldHdvcmsgcm91dGVycyBtYW51 ZmFjdHVyZXJzKSBoYXZlIGFjY2VzcyB0byB3b3VsZCBsb29rIG1vcmUgbGlrZQ0KPiByZWFsLXdv cmxkIHN0YXRpc3RpY2FsIGRhdGEgYW5kIHdlIHNob3VsZCBwcm9iYWJseSB0dXJuIHRvIHRoZW0g dG8gZ2V0DQo+IHByb3BlciBpbmZvcm1hdGlvbiBhYm91dCB3aGF0IGlzIGN1cnJlbnRseSBoYXBw ZW5pbmcgb24gdGhlIGludGVyDQo+IG5ldHdvcmtzLg0KPiANCj4gDQo+IA0KPiAtLQ0KPiANCj4g SXZhbiBDLg0K From ivan@cacaoweb.org Tue Jun 18 13:32:45 2013 Return-Path: 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 CDE1E21E8090 for ; Tue, 18 Jun 2013 13:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 lDTxIKWB8eVm for ; Tue, 18 Jun 2013 13:32:41 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id 600FC21E8054 for ; Tue, 18 Jun 2013 13:32:36 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1Up2ag-0008Pv-AQ; Tue, 18 Jun 2013 22:33:22 +0200 To: "Senthil Sivakumar (ssenthil)" X-PHP-Originating-Script: 0:func.inc 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: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Cc: Behave 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 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 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. 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_ From rajiva@cisco.com Tue Jun 18 13:57:29 2013 Return-Path: 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 9F9BA21E8092 for ; Tue, 18 Jun 2013 13:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 i+9LHNb0Bb+0 for ; Tue, 18 Jun 2013 13:57:24 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 681D721F991E for ; Tue, 18 Jun 2013 13:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4886; q=dns/txt; s=iport; t=1371589044; x=1372798644; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MObUpKnwwankE0lWkGC1z5Hbq5UCkpCPtcLYHw75Vso=; b=Vk1ARS9NVmrcBDP8tqGjBV71LWeG+prQucyiBDT3VxLoD2Kqi70+p4Lh wCK0bzARcvmVKCIQSfXlpuk+mIRe6jhUjaMbt+0SO3X2q9mbielRmu7A3 eRtLJtNmUABcI0KtewoQXNV0wRN6gy0ciZfNFqu/r/df1+C06hQpQyasu 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFADXJwFGtJXG//2dsb2JhbABagwkxSYMBvA8NdxZ0giMBAQEEAQEBIBE6CwwEAgEIEQQBAQMCBh0DAgICJQsUAQgIAgQBDQUIiAYMqT2RPYEmjWQWGwcGgkczYQOYapAagw+CKA X-IronPort-AV: E=Sophos;i="4.87,891,1363132800"; d="scan'208";a="221475454" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 18 Jun 2013 20:57:21 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5IKvLWY030214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Jun 2013 20:57:21 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.251]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Tue, 18 Jun 2013 15:57:21 -0500 From: "Rajiv Asati (rajiva)" To: "ivan@cacaoweb.org" , "Senthil Sivakumar (ssenthil)" Thread-Topic: [BEHAVE] (no subject) Thread-Index: AQHObEcIVnKEk9pXtEWzyn0CP3I8p5k8LkQAgAATJgD//7KAYA== Date: Tue, 18 Jun 2013 20:57:20 +0000 Message-ID: References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> In-Reply-To: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.238.113] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Behave 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 20:57:29 -0000 SXQgc2VlbXMgd29ydGh3aGlsZSB0byBkaWZmZXJlbnRpYXRlIGhvbWUgcm91dGVyIE5BVCBpbXBs ZW1lbnRhdGlvbnMgZnJvbSBlbnRlcnByaXNlL1NQIHJvdXRlciBOQVQgaW1wbGVtZW50YXRpb25z LiBBbmQgdGhlIHF1ZXN0aW9uIHRvIGFzayBvdXJzZWx2ZXMgaXMgd2hldGhlciB3ZSBuZWVkIGEg Y29tbW9uIHNldCBvZiByZXF1aXJlbWVudHMgZm9yIGJvdGggc2NlbmFyaW9zICEhDQoNCkNoZWVy cywNClJhaml2DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBiZWhh dmUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmJlaGF2ZS1ib3VuY2VzQGlldGYub3JnXSBPbg0K PiBCZWhhbGYgT2YgaXZhbiBjDQo+IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMTgsIDIwMTMgNDozMyBQ TQ0KPiBUbzogU2VudGhpbCBTaXZha3VtYXIgKHNzZW50aGlsKQ0KPiBDYzogQmVoYXZlDQo+IFN1 YmplY3Q6IFJlOiBbQkVIQVZFXSAobm8gc3ViamVjdCkNCj4gDQo+IEhpIFNlbnRoaWwsDQo+IA0K PiBUaGFua3MgZm9yIHlvdXIgbWVzc2FnZS4gWW91IG1pZ2h0IHdhbnQgdG8gcmVhZA0KPiBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJlaGF2ZS1yZXF1aXJlbWVudHMtdXBk YXRlLTAwDQo+IEl0IGZlYXR1cmVzIHRoZSBsaXN0IG9mIHVwZGF0ZXMgdG8gdGhlIGV4aXN0aW5n IFJGQywgYWRhcHRlZCB0byBuZXcgdXNhZ2UNCj4gY29udGV4dHMgc3VjaCBhcyBDR05zLCBtb2Jp bGUgbmV0d29ya3MsIGV0Yy4NCj4gDQo+IA0KPiBPbiBUdWUsIDE4IEp1biAyMDEzIDE5OjI0OjUw ICswMDAwLCAiU2VudGhpbCBTaXZha3VtYXIgKHNzZW50aGlsKSINCj4gDQo+ID4+DQo+ID4+QXJl IHlvdSB0YWxraW5nIGFib3V0IFVEUCBwb3J0IHByZXNlcnZhdGlvbj8NCj4gPg0KPiA+IEJvdGgg VENQICYgVURQLiBUaGUgbGF0ZXN0IGltcGxlbWVudGF0aW9uIGluIHNvbWUgcm91dGVyIGZhbWls aWVzIGlzIG5vdA0KPiA+IHRvIGhhdmUgcG9ydCBwcmVzZXJ2YXRpb24NCj4gPiAoZm9yIGJvdGgg VENQICYgVURQKS4NCj4gPg0KPiANCj4gVGhlIGRpc2N1c3Npb24gaGVyZSBpcyBub3QgYWJvdXQg VURQLiBVRFAgcG9ydCBwcmVzZXJ2YXRpb24gc2hvdWxkDQo+IGdlbmVyYWxseSBub3QgYmUgaW1w bGVtZW50ZWQgYnkgTkFUcywgYXMgaXQgY291bGQgZ2VuZXJhdGUgY29uZmxpY3RzIHdoZW4NCj4g Mg0KPiBpbnRlcm5hbCBob3N0cyB1c2luZyB0aGUgc2FtZSBsb2NhbCBwb3J0LCBlYWNoIHdpdGgg YSBzZXNzaW9uIHRvIHRoZSBzYW1lDQo+IGVuZHBvaW50LiBUaGlzIHdvdWxkIGJyZWFrIGVuZC10 by1lbmQgY29ubmVjdGl2aXR5IGluIHJhcmUgY2FzZXMsIGFzIHRoZXJlDQo+IGlzIG5vIGZhbGxi YWNrIG1lY2hhbmlzbSAoYXMgb3Bwb3NlZCB0byBUQ1ApLg0KPiANCj4gVG8gYmUgY2xlYXIsIHRo ZSByZXF1aXJlbWVudHMgYXJlIGFzIGZvbGxvd3M6DQo+ICogTkFUIFNIT1VMRCBOT1QgdXNlIFVE UCBwb3J0IHByZXNlcnZhdGlvbg0KPiAqIE5BVCBTSE9VTEQgdXNlIFRDUCBwb3J0IHByZXNlcnZh dGlvbg0KPiANCj4gSGVyZSBhcmUgc29tZSBOQVRzIHRoYXQgaGF2ZSBiZWVuIHRlc3RlZCBhbmQg aW1wbGVtZW50IFRDUCBwb3J0DQo+IHByZXNlcnZhdGlvbjoNCj4gaW4gdGhlIFVLOg0KPiBCVCAo QnJpdGlzaCBUZWxlY29tKSAoaG91c2UtbWFkZSBnYXRld2F5KSAtIG51bWJlciAxIHByb3ZpZGVy DQo+IFZpcmdpbiAoaG91c2UtbWFkZSBnYXRld2F5KSAtIG51bWJlciAyIHByb3ZpZGVyDQo+IFNr eSAoU2FnZW1jb20pIC0gbnVtYmVyIDMgcHJvdmlkZXINCj4gDQo+IGluIEZyYW5jZToNCj4gT3Jh bmdlIChMaXZlYm94KSAoaG91c2UtbWFkZSBnYXRld2F5KSAtIG51bWJlciAxIHByb3ZpZGVyDQo+ IEZyZWUgKEZyZWVib3gpIChob3VzZS1tYWRlIGdhdGV3YXkpIC0gbnVtYmVyIDIgcHJvdmlkZXIN Cj4gU0ZSL05ldWYgKE5ldWZib3gpIChob3VzZS1tYWRlIGdhdGV3YXkpIC0gbnVtYmVyIDMgcHJv dmlkZXINCj4gDQo+IFRoaXMgY292ZXJzIHRoZSBvdmVyd2hlbG1pbmcgbWFqb3JpdHkgb2Ygc3Vi c2NyaWJlcnMuDQo+IA0KPiBXZSBoYXZlIHRoZSBzYW1lIHJlc3VsdHMgaW4gU3BhaW4gaW4gSXRh bHkuDQo+IA0KPiBNaXNjOg0KPiBMaW5rc3lzIEUxMjAwLCBsYXRlc3QgZ2VuZXJhdGlvbi4NCj4g TmV0Z2VhciwgdmFyaW91cyBtb2RlbHMNCj4gDQo+IA0KPiBJdCBpcyBkaWZmaWN1bHQgdG8gZmlu ZCBhbnkgTkFUIHRoYXQgZG9lcyAqbm90KiBpbXBsZW1lbnQgVENQIHBvcnQNCj4gcHJlc2VydmF0 aW9uIGluIHRoZXNlIGNvdW50cmllcy4NCj4gSWYgeW91IHRoaW5rIHNvbWUgZ2F0ZXdheSBpbXBs ZW1lbnRhdGlvbnMgaGF2ZSBkcm9wcGVkIFRDUCBwb3J0DQo+IHByZXNlcnZhdGlvbiwgeW91IG5l ZWQgdG8gc3Vic3RhbnRpYWxseSBzdXBwb3J0IHlvdXIgY2xhaW0gYnkgYSByZWZlcmVuY2UuDQo+ IFdlIGFyZSBub3QgYXdhcmUgb2YgYW55dGhpbmcgdGhhdCB3b3VsZCBzdXBwb3J0IGl0Lg0KPiAN Cj4gDQo+ID4NCj4gPiBNb3N0IG9mIHRoZSBOQVRzIHRoYXQgSSBrbm93IGRvbuKAmXQgZG8gcG9y dCBvdmVybG9hZGluZyBhbnkgbW9yZS4NCj4gPiBSRkMgNTM4MiBhbHNvIHNheXMsDQo+ID4gUkVR LTc6ICBBIE5BVCBNVVNUIE5PVCBoYXZlIGEgIlBvcnQgYXNzaWdubWVudCIgYmVoYXZpb3Igb2Yg IlBvcnQNCj4gPiAgICAgICBvdmVybG9hZGluZyIgZm9yIFRDUC4NCj4gPg0KPiANCj4gVGhpcyBp cyB0aGUgcHVycG9zZSBvZiB0aGUgbmV3IGRyYWZ0DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtYmVoYXZlLXJlcXVpcmVtZW50cy11cGRhdGUtMDAgLCB0bw0KPiBtYWtl IHRoZSB1c2UgY2FzZSBmb3IgcG9ydCBvdmVybG9hZGluZywgYXMgaXQgaXMgbmVlZGVkIGluIENH TnMuIEl0IHdhc24ndA0KPiBuZWVkZWQgbmVhcmx5IGFzIG11Y2ggaW4gMjAwNSB3aGVuIFJGQyA1 MzgyIHdhcyBmaXJzdCB3cml0dGVuLg0KPiANCj4gUkVRLTc6IEEgTkFUIE1VU1QgTk9UIGhhdmUg YSAiUG9ydCBhc3NpZ25tZW50IiBiZWhhdmlvciBvZiAiUG9ydA0KPiBvdmVybG9hZGluZyIgZm9y IFRDUA0KPiBpcyB0b28gc3RyaW5nZW50LCBhcyBwcm92ZWQgaW4gbXkgZWFybGllciBtZXNzYWdl IGFuZCBpbiB0aGUNCj4gZHJhZnQtaWV0Zi1iZWhhdmUtcmVxdWlyZW1lbnRzLXVwZGF0ZS0wMCwg YW5kIG5vdCBuZWVkZWQuDQo+IA0KPiBQb3J0IG92ZXJsb2FkaW5nIGlzIHBlcmZlY3RseSBhY2Nl cHRhYmxlIHdoZW4gdGhlIHJlbW90ZSBlbmRwb2ludHMgYXJlDQo+IGRpc3RpbmN0LCBhcyBpdCBw cmVzZXJ2ZXMgdGhlIHVuaXF1ZW5lc3Mgb2YgdGhlIDUtdHVwbGUuDQo+IA0KPiBBcyBhIHJlc3Vs dCwgUkVRLTcgbXVzdCBiZSBjb3JyZWN0ZWQuDQo+IA0KPiANCj4gDQo+IC0tDQo+IF9JdmFuIENo b2xsZXRfDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IEJlaGF2ZSBtYWlsaW5nIGxpc3QNCj4gQmVoYXZlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVoYXZlDQo= From ivan@cacaoweb.org Tue Jun 18 14:55:17 2013 Return-Path: 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 B662221E80B7 for ; Tue, 18 Jun 2013 14:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] 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 Upjni8wXFkL4 for ; Tue, 18 Jun 2013 14:55:13 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id B44A721E80BA for ; Tue, 18 Jun 2013 14:55:13 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1Up3si-0001Km-E2; Tue, 18 Jun 2013 23:56:04 +0200 To: "Rajiv Asati (rajiva)" X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Tue, 18 Jun 2013 23:56:04 +0200 From: ivan c Organization: cacaoweb In-Reply-To: References: <6d6816c3367bc3c3bcf3795fbc850701@cacaoweb.org> Message-ID: X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Cc: behave@ietf.org Subject: Re: [BEHAVE] =?utf-8?q?=5Bv6ops=5D_Home_NAPT44_-_How_many_ports=3F?= 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 21:55:17 -0000 On Tue, 18 Jun 2013 20:24:55 +0000, "Rajiv Asati (rajiva)" wrote: > > Interesting enough, many of the recent measurements suggest that the > torrent' like p2p applications are no longer the bandwidth consumers the > way they once used to be. In fact, they are now perceived to be 10-20% (and > declining) of internet bandwidth. The largest internet world traffic > consumer is HTTP (and HTTP video). > > http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/images/VNI_Hyperconnectivity_WP-12.jpg > > http://www.michaelsinsight.com/2009/10/sandvine-traffic-study-confirms-the-decline-of-p2p.html > > http://www.research.att.com/export/sites/att_labs/techdocs/TD_100193.pdf > > > Nonetheless, I do think about the number of ports that these p2p > applications can consume/exhaust, since that could be in 100s (or in > 1000s). Thankfully, many home router implementations may provide > capabilities to restrict the exhaustion by the p2p apps. > Interesting links. I wish we had access to more studies like the third one. However these documents seem to refer to the situation in North America, who has Netflix, Hulu, Youtube, and is back in 2009. Apparently after the Megavideo debacle in 2011, there was a significant drop of traffic towards video streaming services. It is difficult to get information about internet usage per continent/countries. Europe: Netflix and Hulu are not available. Netflix actually just came to the UK. They make a large chunk of the US traffic. Youtube is heavily throttled in France. From studies done by Orange, P2P still seems the dominant usage. China: P2P live streaming appears to be massively used. Japan, India, South America: i have little information -- _Ivan Chollet_ From ivan@cacaoweb.org Tue Jun 18 15:04:25 2013 Return-Path: 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 58EAC21E80CA for ; Tue, 18 Jun 2013 15:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 dpEzKGS+tOs8 for ; Tue, 18 Jun 2013 15:04:20 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAE121F9A0B for ; Tue, 18 Jun 2013 15:04:20 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1Up41Q-0001Xh-E8; Wed, 19 Jun 2013 00:05:04 +0200 To: "Rajiv Asati (rajiva)" X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Wed, 19 Jun 2013 00:05:04 +0200 From: ivan c Organization: cacaoweb In-Reply-To: References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> Message-ID: <1769fef997bd7a220673fde14c5294cd@cacaoweb.org> X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Cc: Behave 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 22:04:25 -0000 On Tue, 18 Jun 2013 20:57:20 +0000, "Rajiv Asati (rajiva)" wrote: > It seems worthwhile to differentiate home router NAT implementations from > enterprise/SP router NAT implementations. And the question to ask ourselves > is whether we need a common set of requirements for both scenarios !! > > Cheers, > Rajiv > > Indeed, hopefully our new work in draft-ietf-behave-requirements-update-00 will help defining in what extent the requirements for both use cases (CGN versus home gateways) might diverge. We need to make each requirement's justification very clear and detailed, so implementers can make informed decisions based on the intended usage. -- _Ivan Chollet_ From simon.perreault@viagenie.ca Wed Jun 19 01:13:17 2013 Return-Path: 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 252DE21F9F46 for ; Wed, 19 Jun 2013 01:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 dREuKFmEd9dT for ; Wed, 19 Jun 2013 01:13:16 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 429C221F99A0 for ; Wed, 19 Jun 2013 01:13:16 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:84c5:867d:e648:8153]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6DCAB403D3 for ; Wed, 19 Jun 2013 04:13:15 -0400 (EDT) Message-ID: <51C1681A.5030909@viagenie.ca> Date: Wed, 19 Jun 2013 10:13:14 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: behave@ietf.org References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> In-Reply-To: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 08:13:17 -0000 Le 2013-06-18 22:33, ivan c a écrit : > 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). Please explain how TCP is not subject to the same problem. Simon From ssenthil@cisco.com Wed Jun 19 07:38:19 2013 Return-Path: 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 AD56D21F9CE0 for ; Wed, 19 Jun 2013 07:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.38 X-Spam-Level: X-Spam-Status: No, score=-10.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 VPRBq-itRcKy for ; Wed, 19 Jun 2013 07:38:14 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 61B3921F9CC2 for ; Wed, 19 Jun 2013 07:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4220; q=dns/txt; s=iport; t=1371652694; x=1372862294; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ms/pvdAmlEadfk+25NL8nicir1CLDhgAcbPMWx1hMjc=; b=P8i6TKjb4gU515jBY5J3Bm4Rvln3dLYAbTbKJNRZPSMU4X/Yaw2eMbtR C1FvdQZcpdN/NeCLAnPLU4t38RY2Tt7mpvm8vtNI5tKrY9i2StoClpLzV FY65QJfUITU62kzQz2mLK15orEA2mMQpTjFsuJIiNusFrc1C/MywdSp6d I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkHALTBwVGtJV2b/2dsb2JhbABagwkxSb8bgQAWbQeCJQEEeRIBCCJWJQIEDgUIiAYMu0WOAIERMQeDAGEDiGiQApAbgw+BcTc X-IronPort-AV: E=Sophos;i="4.87,896,1363132800"; d="scan'208";a="224836098" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 19 Jun 2013 14:38:13 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5JEcDBo007285 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jun 2013 14:38:13 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.94]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Wed, 19 Jun 2013 09:38:13 -0500 From: "Senthil Sivakumar (ssenthil)" To: "ivan@cacaoweb.org" Thread-Topic: [BEHAVE] (no subject) Thread-Index: AQHObFmAgdHlRyxSR02wAQ7tdo7juJk8QUUAgADsCAA= Date: Wed, 19 Jun 2013 14:38:12 +0000 Message-ID: In-Reply-To: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [64.102.83.125] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6BFB065914272A4AA1DADF1D49466F28@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Behave 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 14:38:19 -0000 Hi Ivan, On 6/18/13 4:33 PM, "ivan c" 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. I have reviewed this draft and we had a bit of discussion around these topics in the last IETF. > > >On Tue, 18 Jun 2013 19:24:50 +0000, "Senthil Sivakumar (ssenthil)" > >>> >>>Are you talking about UDP port preservation? >>=20 >> Both TCP & UDP. The latest implementation in some router families is not >> to have port preservation >> (for both TCP & UDP). >>=20 > >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. 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=B9t do port preservation.=20 > >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. >We are not aware of anything that would support it. > > >>=20 >> Most of the NATs that I know don=B9t 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. >>=20 > >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. There are two distinct things here: 1. Port preservation is a must 2. Port preservation requires port overloading to work deterministically. I don=B9t 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. =20 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=B9t 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. Senthil > >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. > > > >--=20 >_Ivan Chollet_ From dwing@cisco.com Wed Jun 19 20:22:03 2013 Return-Path: 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 ; 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 ; 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 ; 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 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: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> To: X-Mailer: Apple Mail (2.1508) Cc: Behave 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 03:22:03 -0000 On Jun 18, 2013, at 1:33 PM, ivan c wrote: > Hi Senthil, >=20 > Thanks for your message. You might want to read > http://tools.ietf.org/html/draft-ietf-behave-requirements-update-00=20 > It features the list of updates to the existing RFC, adapted to new = usage > contexts such as CGNs, mobile networks, etc. >=20 >=20 > On Tue, 18 Jun 2013 19:24:50 +0000, "Senthil Sivakumar (ssenthil)" >=20 >>>=20 >>> Are you talking about UDP port preservation?=20 >>=20 >> Both TCP & UDP. The latest implementation in some router families is = not >> to have port preservation >> (for both TCP & UDP). >>=20 >=20 > 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). >=20 > To be clear, the requirements are as follows: > * NAT SHOULD NOT use UDP port preservation > * NAT SHOULD use TCP port preservation >=20 > 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 >=20 > 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 >=20 > This covers the overwhelming majority of subscribers. >=20 > We have the same results in Spain in Italy. >=20 > Misc: > Linksys E1200, latest generation. > Netgear, various models >=20 >=20 > 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.=20 >=20 >=20 >>=20 >> Most of the NATs that I know don=92t 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. >>=20 >=20 > 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. >=20 > 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. >=20 > Port overloading is perfectly acceptable when the remote endpoints are > distinct, as it preserves the uniqueness of the 5-tuple. >=20 > As a result, REQ-7 must be corrected. >=20 >=20 >=20 > --=20 > _Ivan Chollet_ > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Wed Jun 19 20:25:20 2013 Return-Path: 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 0586711E80E9 for ; Wed, 19 Jun 2013 20:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.572 X-Spam-Level: X-Spam-Status: No, score=-110.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 8-gLZbYYQn-N for ; Wed, 19 Jun 2013 20:25:15 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5F02211E80E6 for ; Wed, 19 Jun 2013 20:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5557; q=dns/txt; s=iport; t=1371698715; x=1372908315; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/GY8UY86OtjQv4U5JkPMC86mM4fwagcHMFbBS9jzdvc=; b=F65wWFujxEYTkVDLOUeHIlPJaBjzNernsTmKbvQT6gSCxoixDl4KTm3b HRCfHYvZRqpPA3Wko6QC2aqzc9D/iikiI6RSpXlYiHJZ2f8CSEAGLBeps QFVVs398iKoLaxJ/w4g9nJr5lKDly+KGS5bLlNDlMUHJlhCcKgYvJkvNV I=; X-IronPort-AV: E=Sophos;i="4.87,901,1363132800"; d="scan'208";a="83943923" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 20 Jun 2013 03:25:15 +0000 Received: from sjc-vpn3-98.cisco.com (sjc-vpn3-98.cisco.com [10.21.64.98]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5K3PE3x024295; Thu, 20 Jun 2013 03:25:14 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: Date: Wed, 19 Jun 2013 20:25:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <80BFC9AE-2ADD-4F5D-9229-FBD6B0E403F3@cisco.com> References: To: Senthil Sivakumar (ssenthil) X-Mailer: Apple Mail (2.1508) Cc: Behave , "ivan@cacaoweb.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 03:25:20 -0000 On Jun 19, 2013, at 7:38 AM, Senthil Sivakumar (ssenthil) = wrote: > Hi Ivan, >=20 > On 6/18/13 4:33 PM, "ivan c" wrote: >=20 >> Hi Senthil, >>=20 >> 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. >=20 > I have reviewed this draft and we had a bit of discussion around these > topics in the last IETF. >>=20 >>=20 >> On Tue, 18 Jun 2013 19:24:50 +0000, "Senthil Sivakumar (ssenthil)" >>=20 >>>>=20 >>>> Are you talking about UDP port preservation? >>>=20 >>> Both TCP & UDP. The latest implementation in some router families is = not >>> to have port preservation >>> (for both TCP & UDP). >>>=20 >>=20 >> 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). >>=20 >> To be clear, the requirements are as follows: >> * NAT SHOULD NOT use UDP port preservation >> * NAT SHOULD use TCP port preservation >>=20 >> 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 >>=20 >> 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 >>=20 >> This covers the overwhelming majority of subscribers. >=20 > 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=B9t do port > preservation.=20 >=20 >=20 >>=20 >> We have the same results in Spain in Italy. >>=20 >> Misc: >> Linksys E1200, latest generation. >> Netgear, various models >>=20 >>=20 >> 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. >>=20 >>=20 >>>=20 >>> Most of the NATs that I know don=B9t 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. >>>=20 >>=20 >> 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. >>=20 >> 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. >=20 > There are two distinct things here: > 1. Port preservation is a must > 2. Port preservation requires port overloading to work = deterministically. >=20 > I don=B9t 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. >=20 > 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=B9t 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. The impact to applications is the same, no matter if the NAT function is = within the user's home or in the service provider's network. With some = of the A+P techniques, the ISP controls the in-home CPE behavior, = assigning it a limited number of ports. Thus the difference between a = "carrier" NAT and the "consumer" NAT is far too blurred to make a useful = distinction between port overloading behavior. This discussion should continue, even if to repeat the arguments that = were made years ago when the port overloading text was the WG's = consensus. If WG consensus has changed, let's change the updated = document. But we do need a careful analysis and discussion of the = impact of such a change to applications and to NATs. -d >=20 > Senthil >=20 >>=20 >> Port overloading is perfectly acceptable when the remote endpoints = are >> distinct, as it preserves the uniqueness of the 5-tuple. >>=20 >> As a result, REQ-7 must be corrected. >>=20 >>=20 >>=20 >> --=20 >> _Ivan Chollet_ >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Wed Jun 19 20:50:17 2013 Return-Path: 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 AC02021E8086 for ; Wed, 19 Jun 2013 20:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.573 X-Spam-Level: X-Spam-Status: No, score=-110.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 4UziJ1S-3rNe for ; Wed, 19 Jun 2013 20:50:13 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0074021E8084 for ; Wed, 19 Jun 2013 20:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4327; q=dns/txt; s=iport; t=1371700213; x=1372909813; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=5TN4Zeuc9bqx3WgNXvNSAh8rDGNNb7q2ds1jhZTf2Y4=; b=ixUVGtSOVLZVXM4X+B8A5lGJUTUoQ83CQN7kIgJMV6Ctpf3+cmVZHjlv Ot09sABZCzr/h9jsQhg8tK+cxfG5pK7lc8TLlcylhUjMH30t/FOP9F/Eg anIFTwaY8re/b3UUCxXrpe7bKXQTHch55X4uOnTkKABy5koRV1Mc4qnWO s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8FAIZ7wlGrRDoJ/2dsb2JhbABagwkxty+IOn0WdIIjAQEBAwEBAQFqAQsFCwsEQicwBhOICAUNvBWPQgcWgmphA4kgjiGBKZAbgy8c X-IronPort-AV: E=Sophos;i="4.87,901,1363132800"; d="scan'208,217";a="83945365" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 20 Jun 2013 03:50:12 +0000 Received: from sjc-vpn3-98.cisco.com (sjc-vpn3-98.cisco.com [10.21.64.98]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5K3oB2t029788; Thu, 20 Jun 2013 03:50:11 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_F8DEFBCA-523A-4EEF-BBD9-70E9CE77A714" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: Date: Wed, 19 Jun 2013 20:50:11 -0700 Message-Id: <6728C5CA-F1DD-4564-A218-E4809BF92B6F@cisco.com> References: To: X-Mailer: Apple Mail (2.1508) Cc: Behave Subject: Re: [BEHAVE] p2p applications using STUNT and EIM NATs for TCP X-BeenThere: behave@ietf.org 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 03:50:17 -0000 --Apple-Mail=_F8DEFBCA-523A-4EEF-BBD9-70E9CE77A714 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 18, 2013, at 10:25 AM, ivan c wrote: > Hello, >=20 > Does any of you has examples of applications that use a STUNT server = together with an EIM NAT for TCP? >=20 > This is the single purpose (besides the convenience of the = implementation) of having an EIM NAT in the first place: performing port = prediction with the help of a STUNT server. >=20 I don't think you mean 'port prediction' where the software is trying to = guess the next-used port ("predicting"), but I believe you mean learning = the external IP address and TCP port (by talking to a TCP server on the = Internet) and communicating that learned address/port to a rendezvous = server of some kind (DNS server, SIP server, game server, whatever). > Surprisingly, I am not aware of any applications that rely on that. = All the p2p applications that I know of use different techniques for TCP = Hole Punching or use other alternatives, such as UPnP, port forwarding, = etc. >=20 I found this discussion of folks utilizing TCP hole punching (as I = summarized above) for their projects, = http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/d82f5cd9-b33c= -4ea6-aeef-e489750021e4/tcp-simultaneous-open-for-tcp-hole-punching. -d > It would be important to somewhat quantify the usage of this technique = in the wild. >=20 > =20 > -- >=20 > Ivan Chollet > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --Apple-Mail=_F8DEFBCA-523A-4EEF-BBD9-70E9CE77A714 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii ivan@cacaoweb.org> = wrote:

Hello,

Does any of you has examples of = applications that use a STUNT server together with an EIM NAT for = TCP?

This is the single purpose (besides the convenience of the = implementation) of having an EIM NAT in the first place: performing port = prediction with the help of a STUNT server.

I = don't think you mean 'port prediction' where the software is trying to = guess the next-used port ("predicting"), but I believe you mean learning = the external IP address and TCP port (by talking to a TCP server on the = Internet) and communicating that learned address/port to a rendezvous = server of some kind (DNS server, SIP server, game server, = whatever).

Surprisingly, I am not = aware of any applications that rely on that. All the p2p applications = that I know of use different techniques for TCP Hole Punching or use = other alternatives, such as UPnP, port forwarding, = etc.

I found this discussion of folks utilizing TCP hole = punching (as I summarized above) for their projects, http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/d82f5cd9-b= 33c-4ea6-aeef-e489750021e4/tcp-simultaneous-open-for-tcp-hole-punching= .

-d


It would be important to somewhat quantify the usage of = this technique in the wild.

 

--

Ivan Chollet
_______________________________________________
Behave mailing = list
Behave@ietf.org
https://www.ietf.or= g/mailman/listinfo/behave

= --Apple-Mail=_F8DEFBCA-523A-4EEF-BBD9-70E9CE77A714-- From ivan@cacaoweb.org Thu Jun 20 11:26:17 2013 Return-Path: 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 00B3021F871D for ; Thu, 20 Jun 2013 11:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 Nx+eR2deJeT7 for ; Thu, 20 Jun 2013 11:26:11 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id 71FCF21F99D1 for ; Thu, 20 Jun 2013 11:26:11 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1UpjZX-0004eK-B2 for behave@ietf.org; Thu, 20 Jun 2013 20:27:03 +0200 To: Behave 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 20:27:03 +0200 From: ivan c Organization: cacaoweb In-Reply-To: <51C1681A.5030909@viagenie.ca> References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 18:26:17 -0000 On Wed, 19 Jun 2013 10:13:14 +0200, Simon Perreault wrote: > Le 2013-06-18 22:33, ivan c a écrit : >> 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). > > Please explain how TCP is not subject to the same problem. > This question is really about Port Overloading and is the crux of the discussion, so i'm giving a short answer and a longer, more detailed answer. I voluntarily leave the long answer on this mailing-list, so it can provide raw material for the draft later on. THE SHORT ANSWER: Port overloading (UDP or TCP) introduces the small possibility of a non-deterministic behavior of the NAT: the fallback on EDM in the event of a 5-tuple conflict. It's a rare event, and only affects p2p applications, who are already prepared to deal with it. After all, a large part of NATs in the wild aren't cooperative, so p2p applications always have fallback mechanisms in place. Beacause of the potential benefits of port overloading for CGNs, this should be a no brainer. In short, port overloading is fine for both UDP and TCP and won't break any p2p application. That been said, the use case for NAT port overloading was always only TCP, as applications do not need to create that many local endpoints for UDP. So let's not even bother with the corner cases for UDP for simplicity sake and tell the NAT not do port overloading for UDP. Conclusion: - UDP port overloading is not particularly useful, Req 3 of RFC 4787 is fine. - TCP port overloading can be very useful, RFC 5382 should mention support for it. THE LONGER ANSWER: There is one major difference between UDP and TCP from the application point of view: (1) one UDP socket (local endpoint) can have multiple communication sessions. (with multiple remote endpoints) (2) one TCP socket can have only one session. Condition (2) is not implied by RFC 793, but is enforced by POSIX. This originates from the fact that Unix had a special recv() function for connected socket, as opposed to recvfrom() for general sockets. POSIX later standardized on this Unix behavior. This Unix idiosyncrasy prevents sessions multiplexing for connected sockets. Consequence: Applications don't need to use more than one UDP local endpoint, but need to use many TCP local endpoints. The impact on applications behavior: For UDP, a p2p application will tend to multiplex all its p2p sessions over one UDP socket (actually, some use 2 or 3 sockets for convenience). This is what you observe with Skype, uTorrent, etc. but is applicable to virtually all applications: it saves scarce resources (ports) and is considered good design. Unfortunately, since POSIX doesn't support the same thing for TCP, and a large number of TCP sockets will be created by the application, on many local endpoints, as you have witnessed for most "torrent-like" applications. Consequence (1): The use case for port overloading should be TCP, not UDP. Back to NAT port overloading. A collision occurs when 2 sessions share the same 5-tuple. It is usually a rare event. Let's look at the corner case of when a collision occurs, with p being the probability of a collision: - NAT fallbacks on EDM for this particular session (note: non-deterministic behavior from the application pov, with probability p) - two possible outcomes for the application: 1) session initiation succeeds, OK. 2) session initiation fails, application fallbacks on the following: * create a new socket (with a new local endpoint) and restart. Probability of success increases exponentially in (1-p^n) at each re-try. * use another fallback mechanism (UPnP, relaying, etc.), but this is out of scope and not part of the TCP Hole Punching protocol. Note 1: The session usually often succeeds when NAT fallbacks to EDM. It only fails in the case where the remote endpoint is also behind a NAT. Note 2: Here, the slight probability of failure for a connection attempt is corrected by the TCP Hole Punching protocol as a whole. (Analogy with TCP: the non-deterministic behavior introduced by packet loss is abstracted away by the TCP layer, by resending the lost packets) The failure case when the session fails is dealt with by the more complicated code path in 2). Here the application creates a new socket. What it implies, in both UDP and TCP cases: UDP: creating a new socket for UDP is ok, but an annoyance. Goes against good design practices. TCP: creating a new socket is ok, this is what the application is doing anyway for each new session. Conclusion: UDP: there is not much of a case for port overloading, and the more complicated behavior path could possibly go against application good design practices. TCP: port overloading fits well with the TCP Hole Punching protocol. In my opinion, although we can leave the requirements for UDP as they are for the sake of simplicity, we need to write about the possibility of port overloading for TCP in the documents. -- _Ivan Chollet_ From ivan@cacaoweb.org Thu Jun 20 12:20:09 2013 Return-Path: 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 46C5721E808D for ; Thu, 20 Jun 2013 12:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 GppQpPyTX1Tz for ; Thu, 20 Jun 2013 12:20:03 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5D84011E80BA for ; Thu, 20 Jun 2013 12:20:03 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1UpkPf-0005R8-Ab for behave@ietf.org; Thu, 20 Jun 2013 21:20:55 +0200 To: Behave 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 21:20:55 +0200 From: ivan c Organization: cacaoweb In-Reply-To: References: Message-ID: <9637befefe07c43417c758a004e03f3c@cacaoweb.org> X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Subject: Re: [BEHAVE] TCP port overloading, preservation and CGNs 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 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 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. 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 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. 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 reasons. This makes a big difference in what you can require from a CGN. -- _Ivan Chollet_ From ivan@cacaoweb.org Thu Jun 20 13:12:42 2013 Return-Path: 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 ; 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 ; 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 ; Thu, 20 Jun 2013 13:12:36 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1UplEV-0006Di-Sh for behave@ietf.org; Thu, 20 Jun 2013 22:13:27 +0200 To: Behave 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 Organization: cacaoweb In-Reply-To: <986A3C4C-2571-4C88-88A5-F822191856F1@cisco.com> References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <986A3C4C-2571-4C88-88A5-F822191856F1@cisco.com> Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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_ From tireddy@cisco.com Thu Jun 20 19:32:25 2013 Return-Path: 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 491F421F994A for ; Thu, 20 Jun 2013 19:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 N9PrZWaPqPxo for ; Thu, 20 Jun 2013 19:32:20 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 430B921F91CE for ; Thu, 20 Jun 2013 19:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8734; q=dns/txt; s=iport; t=1371781940; x=1372991540; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=87KWj7r76JKapipL9xLRVcxKikhDbWMLb9wjSUBZONI=; b=DyF5cOsu+q+zC7LdcRXvqe+Ntv01iZQJJABWrcpR30CKQPYPgSh+5Xit 288fhhT1nfCSdNH2S2O2xObb9T7Llf9MovTHHWGkeUoI883/S05aN94PX uo3IFxMXNU5BDmyUhaJy3fkVrmUjZJwUH6H9dEM3yu5c41azM3zN+N0Lg U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIFAD66w1GtJXG+/2dsb2JhbABbgkVEMUmFZLEPhmGBYoECFnSCIwEBAQQBAQEqQAELEAIBCBEEAQELHQcnCxQJCAIEAQ0FCIgGDLwqjxgxBgGDAGEDmGyQG4E0gVuCKA X-IronPort-AV: E=Sophos;i="4.87,909,1363132800"; d="scan'208,217";a="225666033" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 21 Jun 2013 02:32:19 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5L2WJsK015955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Jun 2013 02:32:19 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Thu, 20 Jun 2013 21:32:18 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Dan Wing (dwing)" , "ivan@cacaoweb.org" Thread-Topic: [BEHAVE] p2p applications using STUNT and EIM NATs for TCP Thread-Index: AQHObejGeFKfTZ+QUUuM98+t+t5hoJk/ch8A Date: Fri, 21 Jun 2013 02:32:17 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B899A8@xmb-rcd-x10.cisco.com> References: <6728C5CA-F1DD-4564-A218-E4809BF92B6F@cisco.com> In-Reply-To: <6728C5CA-F1DD-4564-A218-E4809BF92B6F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.74.116] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A14B899A8xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: Behave Subject: Re: [BEHAVE] p2p applications using STUNT and EIM NATs for TCP X-BeenThere: behave@ietf.org 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 02:32:25 -0000 --_000_913383AAA69FF945B8F946018B75898A14B899A8xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Another example would be ICE support for TCP http://tools.ietf.org/html/rfc= 6544 using simultaneous-open between ICE TCP candidates exchanged in offer/= answer. --Tiru. From: Dan Wing (dwing) Sent: Thursday, June 20, 2013 9:20 AM To: ivan@cacaoweb.org Cc: Behave Subject: Re: [BEHAVE] p2p applications using STUNT and EIM NATs for TCP On Jun 18, 2013, at 10:25 AM, ivan c > wrote: Hello, Does any of you has examples of applications that use a STUNT server togeth= er with an EIM NAT for TCP? This is the single purpose (besides the convenience of the implementation) = of having an EIM NAT in the first place: performing port prediction with th= e help of a STUNT server. I don't think you mean 'port prediction' where the software is trying to gu= ess the next-used port ("predicting"), but I believe you mean learning the = external IP address and TCP port (by talking to a TCP server on the Interne= t) and communicating that learned address/port to a rendezvous server of so= me kind (DNS server, SIP server, game server, whatever). Surprisingly, I am not aware of any applications that rely on that. All the= p2p applications that I know of use different techniques for TCP Hole Punc= hing or use other alternatives, such as UPnP, port forwarding, etc. I found this discussion of folks utilizing TCP hole punching (as I summariz= ed above) for their projects, http://social.msdn.microsoft.com/Forums/windo= wsdesktop/en-US/d82f5cd9-b33c-4ea6-aeef-e489750021e4/tcp-simultaneous-open-= for-tcp-hole-punching. -d It would be important to somewhat quantify the usage of this technique in t= he wild. -- Ivan Chollet _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave --_000_913383AAA69FF945B8F946018B75898A14B899A8xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Another example would be ICE support for TCP http://tools.ietf.org/html/r= fc6544 using simultaneous-open between ICE TCP candidates exchanged in = offer/answer.

 

--Tiru.

From: Dan Wing= (dwing)
Sent: Thursday, June 20, 2013 9:20 AM
To: ivan@cacaoweb.org
Cc: Behave
Subject: Re: [BEHAVE] p2p applications using STUNT and EIM NATs for = TCP

 

 

On Jun 18, 2013, at 10:25 AM, ivan c <ivan@cacaoweb.org> wrote:



Hello,

Does any of you has examples of applications that use a STUNT server tog= ether with an EIM NAT for TCP?

This is the single purpose (besides the convenience of the implementatio= n) of having an EIM NAT in the first place: performing port prediction with= the help of a STUNT server.

I don't think you mean 'port prediction' where the s= oftware is trying to guess the next-used port ("predicting"), but= I believe you mean learning the external IP address and TCP port (by talki= ng to a TCP server on the Internet) and communicating that learned address/port to a rendezvous server of some kind (DNS server,= SIP server, game server, whatever).



Surprisingly, I am not aware of any applications that rely on that. All = the p2p applications that I know of use different techniques for TCP Hole P= unching or use other alternatives, such as UPnP, port forwarding, etc.=

I found this discussion of folks utilizing TCP hole = punching (as I summarized above) for their projects, http://social= .msdn.microsoft.com/Forums/windowsdesktop/en-US/d82f5cd9-b33c-4ea6-aeef-e48= 9750021e4/tcp-simultaneous-open-for-tcp-hole-punching.

 

-d

 



It would be important to somewhat quantify the usage of this technique i= n the wild.

 

--

Ivan Chollet

_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave

 

--_000_913383AAA69FF945B8F946018B75898A14B899A8xmbrcdx10ciscoc_-- From oeichenwei@gmail.com Thu Jun 20 19:48:57 2013 Return-Path: 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 A637A11E814F for ; Thu, 20 Jun 2013 19:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 g8rdkrKdAy7u for ; Thu, 20 Jun 2013 19:48:56 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 47BB011E8149 for ; Thu, 20 Jun 2013 19:48:56 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id fo12so6345827lab.25 for ; Thu, 20 Jun 2013 19:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=srJzVB2yXicz4lNiscSNhWKmOn0+hYDT7J2qjUNf2lk=; b=KbvMq+D+SBMYqYJwaGixBGW0CLaEplsWS8RieuPgZ8JgKJ8KWrDSqurMv2Q40UwYEf VqfjZmGRPg+M85fcYehWihtRKynrQlp5B6UjLISIPDRI/J9XVlffSog8jzIwCjSEBcXs STOLwlJN3+VgjsjFEb4oKTJwkmJEcta9n7mf8FmmGEnFd5Wz23FQxJJJfI8kYO4Ca10g GRtfy6uB/9IYybG+CUv0FbenEOf9POK6bEd2D3Ou77hp0e1MN2GwxQkFV2x9Dpj79JFN rJgQdciJSPEcVb4348QZ5Kb0Cgy4LERD4Y6fkvfPMLq7RED3dXD6G5tFI2QxWdr6o05+ KQoQ== MIME-Version: 1.0 X-Received: by 10.112.55.9 with SMTP id n9mr6851209lbp.5.1371782934946; Thu, 20 Jun 2013 19:48:54 -0700 (PDT) Received: by 10.112.67.133 with HTTP; Thu, 20 Jun 2013 19:48:54 -0700 (PDT) In-Reply-To: References: <20130612103314.16399.8755.idtracker@ietfa.amsl.com> Date: Fri, 21 Jun 2013 10:48:54 +0800 Message-ID: From: chen wilson To: "Ram Mohan R (rmohanr)" Content-Type: multipart/alternative; boundary=001a11c333b08be97b04dfa11aee Cc: "behave@ietf.org" Subject: Re: [BEHAVE] FW: New Version Notification for draft-reddy-behave-turn-auth-02.txt X-BeenThere: behave@ietf.org 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 02:48:57 -0000 --001a11c333b08be97b04dfa11aee Content-Type: text/plain; charset=ISO-8859-1 Good point, If the TURN server is configured with multiple realms, it might want to respond all realms it supports (multiple realm attributes), or it might respond some special meaningful realm then the client can get help out of band, or just randomly pick one, etc... The problem 1 and 2, listed in the draft is very common. Implementers are easy to get missed without a clear guidance. Thanks, Wilson Chen On Tue, Jun 18, 2013 at 12:53 PM, Ram Mohan R (rmohanr) wrote: > We have published the revision of this draft. This has changes to > following text of "Problems with STUN Authentication" section > > > 5. Hosting multiple realms on a single IP address is challenging > with TURN. When a TURN server needs to send the REALM attribute > in response to an unauthenticated request, it has no useful > information for determining which realm it should send, except > the source transport address of the TURN request. Note this is a > problem with multi-tenant scenarios only. This is not a problem > when deployed in Enterprise. > > > > > Please review and provide any inputs/comments on this draft. > > Authors > > > On 12/06/13 4:03 PM, "internet-drafts@ietf.org" > > wrote: > > > > >A new version of I-D, draft-reddy-behave-turn-auth-02.txt > >has been successfully submitted by Tirumaleswar Reddy and posted to the > >IETF repository. > > > >Filename: draft-reddy-behave-turn-auth > >Revision: 02 > >Title: Problems with STUN Authentication for TURN > >Creation date: 2013-06-12 > >Group: Individual Submission > >Number of pages: 7 > >URL: > >http://www.ietf.org/internet-drafts/draft-reddy-behave-turn-auth-02.txt > >Status: > >http://datatracker.ietf.org/doc/draft-reddy-behave-turn-auth > >Htmlized: > >http://tools.ietf.org/html/draft-reddy-behave-turn-auth-02 > >Diff: > >http://www.ietf.org/rfcdiff?url2=draft-reddy-behave-turn-auth-02 > > > >Abstract: > > This document discusses some of the issues with STUN authentication > > for TURN messages. > > > > > > > > > > > >The IETF Secretariat > > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > --001a11c333b08be97b04dfa11aee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Good point, If the TURN server is configured with multiple= realms, it might want to respond all realms it supports (multiple realm at= tributes), or it might respond some special meaningful realm then the clien= t can get help out of band, or just randomly pick one, etc...
The problem 1 and 2, listed in the draft is very common. Implementers are e= asy to get missed without a clear guidance.

Thanks,
Wilson Chen

On Tue, Jun 18, 2013 at 12:53 PM, Ram Mohan R (rmohanr) &= lt;rmohanr@cisco.com= > wrote:
We have published the revision of this draft. This has changes to
following text of "Problems with STUN Authentication" section

<snip>
5. =A0Hosting multiple realms on a single IP address is challenging
=A0 =A0 =A0 =A0with TURN. =A0When a TURN server needs to send the REALM att= ribute
=A0 =A0 =A0 =A0in response to an unauthenticated request, it has no useful<= br> =A0 =A0 =A0 =A0information for determining which realm it should send, exce= pt
=A0 =A0 =A0 =A0the source transport address of the TURN request. =A0Note th= is is a
=A0 =A0 =A0 =A0problem with multi-tenant scenarios only. =A0This is not a p= roblem
=A0 =A0 =A0 =A0when deployed in Enterprise.


</snip>

Please review and provide any inputs/comments on this draft.

Authors

> On 12/06/13 4:03 PM, "internet-drafts@ietf.org"
><internet-drafts@ietf.or= g> wrote:

>
>A new version of I-D, draft-reddy-behave-turn-auth-02.txt
>has been successfully submitted by Tirumaleswar Reddy and posted to the=
>IETF repository.
>
>Filename: =A0 =A0 =A0 draft-reddy-behave-turn-auth
>Revision: =A0 =A0 =A0 02
>Title: =A0 =A0 =A0 =A0 =A0Problems with STUN Authentication for TURN >Creation date: =A02013-06-12
>Group: =A0 =A0 =A0 =A0 =A0Individual Submission
>Number of pages: 7
>URL:
>http://www.ietf.org/internet-drafts/draft-re= ddy-behave-turn-auth-02.txt
>Status:
>http://datatracker.ietf.org/doc/draft-reddy-behave-turn= -auth
>Htmlized:
>http://tools.ietf.org/html/draft-reddy-behave-turn-auth-0= 2
>Diff:
>http://www.ietf.org/rfcdiff?url2=3Ddraft-reddy-be= have-turn-auth-02
>
>Abstract:
> =A0 This document discusses some of the issues with STUN authenticatio= n
> =A0 for TURN messages.
>
>
>
>
>
>The IETF Secretariat
>
>


_______________________________________________
Behave mailing list
Behave@ietf.org
= https://www.ietf.org/mailman/listinfo/behave

--001a11c333b08be97b04dfa11aee-- From naito.kengo@lab.ntt.co.jp Thu Jun 20 23:22:38 2013 Return-Path: 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 0A8F721F9F54 for ; Thu, 20 Jun 2013 23:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.511 X-Spam-Level: X-Spam-Status: No, score=0.511 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_25=0.6, J_CHICKENPOX_74=0.6] 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 fE6M7zIguW2g for ; Thu, 20 Jun 2013 23:22:32 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id 58D5621F9F53 for ; Thu, 20 Jun 2013 23:22:28 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id r5L6M8w4032526; Fri, 21 Jun 2013 15:22:08 +0900 Received: from mfs6.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 8D6CCE0149; Fri, 21 Jun 2013 15:22:08 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 81906E0146; Fri, 21 Jun 2013 15:22:08 +0900 (JST) Received: from [127.0.0.1] ([129.60.7.245]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id r5L6M78j024866; Fri, 21 Jun 2013 15:22:08 +0900 Message-ID: <51C3F11D.1030501@lab.ntt.co.jp> Date: Fri, 21 Jun 2013 15:22:21 +0900 From: Kengo Naito User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: ivan@cacaoweb.org References: <3a724be2431cf7249b3d46cf378f85bf@cacaoweb.org> <51BFE896.2000006@lab.ntt.co.jp> <1d235e99689e55aba94258ff65895f75@cacaoweb.org> In-Reply-To: <1d235e99689e55aba94258ff65895f75@cacaoweb.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Behave Subject: Re: [BEHAVE] review of draft-penno-behave-rfc4787-5382-5508-bis X-BeenThere: behave@ietf.org 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 06:22:38 -0000 Hi Ivan, Thanks for comments, (2013/06/19 1:50), ivan c wrote: > Hi Kengo, > > See my answers interleaved below. > > On Tue, 18 Jun 2013 13:56:54 +0900, Kengo Naito wrote: > >> Then, how about using 3.1.2.2 ? This alternative do not rewrite >> timestamps nor ISNs. >> Also, I do not intend to make 3.1.2.1 "must", this is only one of >> alternatives. > 3.1.2.1 will be most definitely frowned upon. Before suggesting such > alternative, the benefits need to be quantified in terms of CGN resources > usage. Is the TIME_WAIT state really that much of an issue for CGN resource > utilization? It looks to me as a micro-optimization. Of course, this can > still be suggested as a MAY in the document (as it's an interesting idea). For someone who uses CGN and do not have enough ports ready can use this micro-optimization(3.1.2). Ofcourse, there are other ways to handle port shortage problem(such as port-overloading). So, I agree with your point that this should be suggested as MAY. Also, we should remove 3.1.2.1 and only write 3.1.2.2. I'll explain 3.1.2.2 below. > > 3.1.2.2 I was unable to fully grasp the idea and its relationship with the > TIME_WAIT state, it would be nice if you could elaborate on this. In this mechanism, usable port set are splited to each client, which means that for each port, arriving packets have monotonically increasing values of TCP timestamp or ISN. In this case, as values are monotonically increasing, 6191 will work and terminate TIME_WAIT. > 3.1.2.3 you're mangling with the TCP protocol itself, which is arguably > even more intrusive than mangling with so fields in the TCP header like in > 3.1.2.1 Okay. If the last ACK getting lost is the rare case and no bad effects occure, we should remove this part. > > 3.1.2.4 I don't think that RFC6191 is widely deployed, do you have any > reference for this? > Section 1. of RFC 6191 says that RFC 1122 4.2.2.13(which uses ISN to terminate TIME_WAIT) is included in the Linux kernel. (RFC 1122 4.2.2.13 functuion is a part of 6191.) Also, I checked some OSes a year ago which had RFC 1122 4.2.2.13 function. -Linux 2.6.18(CentOS 5.6) -FreeBSD 7.4R -Windows 7 -MacOSX Lion >> In >> the draft, I meant that Port overlapping behavior can only be used when > the >> 5-tupple of connections are different. >> So I think it is a bit different from overlapping behavior you wrote. >> Does this behavior cause any bad effect? > > There are a few issues with the section 4. of the draft. > > Quoting: "This document clarifies that this port > overlapping behavior can be extended to connections originating from > different interal source IP:ports as long as their destinations are > different. This known as EDM (Endpoint Dependent Mapping)." > > No, EDM, EIM, always refer to sessions originating from the *same local > endpoint*. > Here you are describing a "port overlapping" behavior for sessions > originating from distinct endpoints. This is known as "port overloading". > EDM refers to the case where we can sometimes "break" the EIM requirement, > for example when we know it doesn't adversely affect the application (such > as with HTTP). > > In your second paragraph, you clearly describe the "port overloading" > behavior. Thus, I think you should drop the "port overlapping" terminology, > replace it with "port overloading", and don't mention EDM > (Endpoint-Dependent Mapping), which is not directly related to the topic. I understood that as you wrote below, 5-tuple uniqueness for port overloading is a MUST, and that means I was trying to describe "port overloading". Excuse me for my misunderstanding. I should write "port overloading" in next revision. > > Port overloading does not have any bad effects. Of course, as long as the > 5-tuple uniqueness is preserved by the NAT, which is a MUST in any case. > However, doing aggressive port overloading generates opportunities for > collisions, which must be dealt with by dropping a session or breaking the > EIM requirement, which is a serious problem for UDP, but not so much for > TCP. Such collision events remain rare, and it is OK to break EIM sometimes > for TCP, as the application can make a retry (using a new ephemeral local > port), that will most certainly work the second time. > > > I can help you develop and improve the section 4. of the draft with you if > you'd like. I'll be glad if you do so. > > > > Regards, > Ivan > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > -- ---------------------------------------- NTT Network Technology Laboratories Kengo Naito E-Mail: naito.kengo@lab.ntt.co.jp TEL: +81 422-59-4949 ---------------------------------------- From simon.perreault@viagenie.ca Fri Jun 21 00:40:47 2013 Return-Path: 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 EF91411E8108 for ; Fri, 21 Jun 2013 00:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: 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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6DaNFkkVoMr for ; Fri, 21 Jun 2013 00:40:45 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 84FDE11E8166 for ; Fri, 21 Jun 2013 00:40:45 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 604F640426 for ; Fri, 21 Jun 2013 03:40:37 -0400 (EDT) Message-ID: <51C40374.8080403@viagenie.ca> Date: Fri, 21 Jun 2013 09:40:36 +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 To: behave@ietf.org References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 07:40:47 -0000 Le 2013-06-20 20:27, ivan c a écrit : > On Wed, 19 Jun 2013 10:13:14 +0200, Simon Perreault > wrote: >> Le 2013-06-18 22:33, ivan c a écrit : >>> 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). >> >> Please explain how TCP is not subject to the same problem. >> > > This question is really about Port Overloading and is the crux of the > discussion, so i'm giving a short answer and a longer, more detailed > answer. > I voluntarily leave the long answer on this mailing-list, so it can > provide raw material for the draft later on. > > > THE SHORT ANSWER: > Port overloading (UDP or TCP) introduces the small possibility of a > non-deterministic behavior of the NAT: the fallback on EDM in the event of > a 5-tuple conflict. > It's a rare event, and only affects p2p applications, who are already > prepared to deal with it. After all, a large part of NATs in the wild > aren't cooperative, so p2p applications always have fallback mechanisms in > place. > Beacause of the potential benefits of port overloading for CGNs, this > should be a no brainer. > In short, port overloading is fine for both UDP and TCP and won't break > any p2p application. > That been said, the use case for NAT port overloading was always only TCP, > as applications do not need to create that many local endpoints for UDP. So > let's not even bother with the corner cases for UDP for simplicity sake and > tell the NAT not do port overloading for UDP. > Conclusion: > - UDP port overloading is not particularly useful, Req 3 of RFC 4787 is > fine. > - TCP port overloading can be very useful, RFC 5382 should mention support > for it. > > > THE LONGER ANSWER: > There is one major difference between UDP and TCP from the application > point of view: > > (1) one UDP socket (local endpoint) can have multiple communication > sessions. (with multiple remote endpoints) > (2) one TCP socket can have only one session. > > Condition (2) is not implied by RFC 793, but is enforced by POSIX. This > originates from the fact that Unix had a special recv() function for > connected socket, as opposed to recvfrom() for general sockets. POSIX later > standardized on this Unix behavior. This Unix idiosyncrasy prevents > sessions multiplexing for connected sockets. > > Consequence: > Applications don't need to use more than one UDP local endpoint, but need > to use many TCP local endpoints. > > The impact on applications behavior: > For UDP, a p2p application will tend to multiplex all its p2p sessions > over one UDP socket (actually, some use 2 or 3 sockets for convenience). > This is what you observe with Skype, uTorrent, etc. but is applicable to > virtually all applications: it saves scarce resources (ports) and is > considered good design. > Unfortunately, since POSIX doesn't support the same thing for TCP, and a > large number of TCP sockets will be created by the application, on many > local endpoints, as you have witnessed for most "torrent-like" > applications. > > Consequence (1): > The use case for port overloading should be TCP, not UDP. I don't understand how you jump from sockets on the host to external ports on the NAT. I don't see how you reach this conclusion. > Back to NAT port overloading. A collision occurs when 2 sessions share the > same 5-tuple. Stop right here. Some NATs don't track sessions. Those NATs don't care about 5-tuples. All they do is map internal 3-tuple to external 3-tuple. So for those NATs there is no conflict. They will just translate the packets according to the existing mapping. All the following doesn't make sense to me given this. Simon > It is usually a rare event. Let's look at the corner case of > when a collision occurs, with p being the probability of a collision: > - NAT fallbacks on EDM for this particular session (note: > non-deterministic behavior from the application pov, with probability p) > - two possible outcomes for the application: > 1) session initiation succeeds, OK. > 2) session initiation fails, application fallbacks on the following: > * create a new socket (with a new local endpoint) and restart. > Probability of success increases exponentially in (1-p^n) at each re-try. > * use another fallback mechanism (UPnP, relaying, etc.), but this is > out of scope and not part of the TCP Hole Punching protocol. > > Note 1: The session usually often succeeds when NAT fallbacks to EDM. It > only fails in the case where the remote endpoint is also behind a NAT. > > Note 2: Here, the slight probability of failure for a connection attempt > is corrected by the TCP Hole Punching protocol as a whole. > (Analogy with TCP: the non-deterministic behavior introduced by packet > loss is abstracted away by the TCP layer, by resending the lost packets) > > The failure case when the session fails is dealt with by the more > complicated code path in 2). Here the application creates a new socket. > What it implies, in both UDP and TCP cases: > UDP: creating a new socket for UDP is ok, but an annoyance. Goes against > good design practices. > TCP: creating a new socket is ok, this is what the application is doing > anyway for each new session. > > > Conclusion: > UDP: there is not much of a case for port overloading, and the more > complicated behavior path could possibly go against application good design > practices. > TCP: port overloading fits well with the TCP Hole Punching protocol. > > > In my opinion, although we can leave the requirements for UDP as they are > for the sake of simplicity, we need to write about the possibility of port > overloading for TCP in the documents. > > > -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Fri Jun 21 00:48:16 2013 Return-Path: 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 39E7511E8166 for ; Fri, 21 Jun 2013 00:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: 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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnrvNv5+saYS for ; Fri, 21 Jun 2013 00:48:15 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 443C711E816D for ; Fri, 21 Jun 2013 00:48:15 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 97F5F40426 for ; Fri, 21 Jun 2013 03:48:14 -0400 (EDT) Message-ID: <51C4053D.5050703@viagenie.ca> 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 To: behave@ietf.org References: <9637befefe07c43417c758a004e03f3c@cacaoweb.org> In-Reply-To: <9637befefe07c43417c758a004e03f3c@cacaoweb.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] TCP port overloading, preservation and CGNs X-BeenThere: behave@ietf.org 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. Simon >> 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 --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Fri Jun 21 02:10:37 2013 Return-Path: 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 D965D11E8171 for ; Fri, 21 Jun 2013 02:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 UAuZufkxz+4J for ; Fri, 21 Jun 2013 02:10:37 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D33AD11E817C for ; Fri, 21 Jun 2013 02:10:36 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 80C1D4044E; Fri, 21 Jun 2013 05:10:35 -0400 (EDT) Message-ID: <51C4188A.4010602@viagenie.ca> Date: Fri, 21 Jun 2013 11:10:34 +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 To: ietfdbh References: <005a01ce5e20$ebb93130$c32b9390$@comcast.net> In-Reply-To: <005a01ce5e20$ebb93130$c32b9390$@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: behave@ietf.org, draft-ietf-behave-nat-mib@tools.ietf.org, 'Dave Thaler' Subject: Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib - SMI violation? X-BeenThere: behave@ietf.org 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 09:10:38 -0000 Le 2013-05-31 19:04, ietfdbh a écrit : > natAddrPortBindLocalAddr - the one being deprecated - is redefined in the > new document. The original had InetAddress syntax with no range; the new doc > adds a range (thereby redefining the range). > I think this violates SMI rules (but it deserves checking to be sure). That was done in order to silence this smilint warning: NAT-MIB.mib:1126: warning: index of row `natAddrPortBindEntry' can exceed OID size limit by 143 subidentifier(s) I don't think we need to fix such things in objects we're deprecating, so the next revision will just revert back to the definition from RFC4008. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From ivan@cacaoweb.org Fri Jun 21 10:15:05 2013 Return-Path: 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 41D9A21F9FA6 for ; Fri, 21 Jun 2013 10:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 v+KhBY1tS3Lq for ; Fri, 21 Jun 2013 10:14:53 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id 43D3F21F9F91 for ; Fri, 21 Jun 2013 10:14:53 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1Uq4w1-0007k9-R9; Fri, 21 Jun 2013 19:15:41 +0200 To: Dan Wing X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Fri, 21 Jun 2013 19:15:41 +0200 From: ivan c Organization: cacaoweb In-Reply-To: <80BFC9AE-2ADD-4F5D-9229-FBD6B0E403F3@cisco.com> References: <80BFC9AE-2ADD-4F5D-9229-FBD6B0E403F3@cisco.com> Message-ID: X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Cc: Behave 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 17:15:05 -0000 On Wed, 19 Jun 2013 20:25:14 -0700, Dan Wing wrote: > > This discussion should continue, even if to repeat the arguments that were > made years ago when the port overloading text was the WG's consensus. If > WG consensus has changed, let's change the updated document. But we do > need a careful analysis and discussion of the impact of such a change to > applications and to NATs. > Applications are not impacted. Port overloading is a transparent NAT-only behavior that preserves that 5-tuple uniqueness. As for NATs, they should be free to do port overloading if they wish. It's not reasonable to force them into one behavior or the other, since none affect interoperability. -- _Ivan Chollet_ From ivan@cacaoweb.org Fri Jun 21 10:39:42 2013 Return-Path: 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 44D2921F9F8B for ; Fri, 21 Jun 2013 10:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] 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 zW0k7Vf5Mwww for ; Fri, 21 Jun 2013 10:39:37 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id DA2A321F9F8F for ; Fri, 21 Jun 2013 10:39:36 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1Uq5K0-000836-85; Fri, 21 Jun 2013 19:40:28 +0200 To: Dan Wing X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_29953c12b941797c1a2ce71d1ca8a83b" Date: Fri, 21 Jun 2013 19:40:28 +0200 From: ivan c Organization: cacaoweb In-Reply-To: <6728C5CA-F1DD-4564-A218-E4809BF92B6F@cisco.com> References: <6728C5CA-F1DD-4564-A218-E4809BF92B6F@cisco.com> Message-ID: X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Cc: Behave Subject: Re: [BEHAVE] p2p applications using STUNT and EIM NATs for TCP 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 17:39:42 -0000 --=_29953c12b941797c1a2ce71d1ca8a83b Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 On Wed, 19 Jun 2013 20:50:11 -0700, Dan Wing wrote: Surprisingly, I am not aware of any applications that rely on that. All the p2p applications that I know of use different techniques for TCP Hole Punching or use other alternatives, such as UPnP, port forwarding, etc. I found this discussion of folks utilizing TCP hole punching (as I summarized above) for their projects, http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/d82f5cd9-b33c-4ea6-aeef-e489750021e4/tcp-simultaneous-open-for-tcp-hole-punching [1]. That's what I mean, besides proof-of-concepts and academic discussions, this does not seem to have found a use so far in any real-world application. It is easy to see if any application uses it: check TCP connections with tcpdump/wireshark, if you see that each connection is "doubled" by a previous one on the same local endpoint, this is very likely to be STUNT. Here are the reason why this technique didn't get much love so far: 1) It requires a STUNT server for *each* outgoing TCP connection. This is in opposition to STUN (for UDP NAT traversal) where the server is typically only needed once, to discover the external port. After that the application re-uses the same UDP socket for its whole lifetime. Using a STUNT server (for TCP NAT traversal) doesn't scale well for very large p2p networks that can have millions of peers and billions of TCP connections / day. Additionally, a TCP connection costs a lot more to a server than a UDP session. The server needs to keep state in TCP, in UDP it does not. * a STUNT server *has to* be used for each TCP session / a STUN server need only to be used once, as applications multiplex their UDP sessions over the same socket * lots of TCP connections cost a lot for a STUNT server 2) It requires setting up the SO_REUSEADDR on all sockets Besides SO_REUSEADDR being an unspecified characteristic of POSIX, it should be noted that what it does on systems that support it is bypass completely the TIME_WAIT state. It means TIME_WAIT state doesn't last 2*MSL, or a bit less, it means it does not exist anymore. If SO_REUSEADDR is used on all the sockets of all p2p apps of a system, what you get is TIME_STATE that is bypassed for all your sockets. As soon as a local endpoints are reused, and this is very likely to happen if the system is busy, you introduce the possibility of data corruption (a new connection will happily accept an old TCP segment). So the application would have to build a layer to protect against data corruption. Not ideal and goes against OSI layers isolation, breaks TCP data corruption provisions, etc. This is what happens when you mess with the TCP protocol. Again, this is just to explain why the STUNT technique for TCP NAT traversal has not seen much use. I would still consider it a useful technique that NATs should try to support if they can, after all it is up to the applications to choose what they are comfortable with. But not present it as the only available technique, this is misleading and dangerous. -- _Ivan Chollet_ Links: ------ [1] http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/d82f5cd9-b33c-4ea6-aeef-e489750021e4/tcp-simultaneous-open-for-tcp-hole-punching --=_29953c12b941797c1a2ce71d1ca8a83b Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

On Wed, 19 Jun 2013 20:50:11 -0700, Dan Wing <dwing@cisco.com> wro= te:

Surprisingly, I am not aware of any applications that rely on that. All = the p2p applications that I know of use different techniques for TCP Hole P= unching or use other alternatives, such as UPnP, port forwarding, etc.

I found this discussion of folks utilizing TCP hole punching (as I summariz= ed above) for their projects, http://social.msdn.microsoft.com/= Forums/windowsdesktop/en-US/d82f5cd9-b33c-4ea6-aeef-e489750021e4/tcp-simult= aneous-open-for-tcp-hole-punching.

 

That's what I mean, besides proof-of-concepts and academic discussions, = this does not seem to have found a use so far in any real-world application= =2E

It is easy to see if any application uses it: check TCP connections with= tcpdump/wireshark, if you see that each connection is "doubled" by a previ= ous one on the same local endpoint, this is very likely to be STUNT.

 

Here are the reason why this technique didn't get much love so far:

1) It requires a STUNT server for *each* outgoing TCP connection.

This is in opposition to STUN (for UDP NAT traversal) where the server i= s typically only needed once, to discover the external port. After that the= application re-uses the same UDP socket for its whole lifetime.
Using= a STUNT server (for TCP NAT traversal) doesn't scale well for very large p= 2p networks that can have millions of peers and billions of TCP connections= / day. Additionally, a TCP connection costs a lot more to a server than a = UDP session. The server needs to keep state in TCP, in UDP it does not.

* a STUNT server *has to* be used for each TCP session / a STUN server n= eed only to be used once, as applications multiplex their UDP sessions over= the same socket
* lots of TCP connections cost a lot for a STUNT serv= er

2) It requires setting up the SO_REUSEADDR on all sockets

Besides SO_REUSEADDR being an unspecified characteristic of POSIX, it sh= ould be noted that what it does on systems that support it is bypass comple= tely the TIME_WAIT state. It means TIME_WAIT state doesn't last 2*MSL, or a= bit less, it means it does not exist anymore.
If SO_REUSEADDR is used= on all the sockets of all p2p apps of a system, what you get is TIME_STATE= that is bypassed for all your sockets. As soon as a local endpoints are re= used, and this is very likely to happen if the system is busy, you introduc= e the possibility of data corruption (a new connection will happily accept = an old TCP segment). So the application would have to build a layer to prot= ect against data corruption. Not ideal and goes against OSI layers isolatio= n, breaks TCP data corruption provisions, etc.

This is what happens when you mess with the TCP protocol.

 

Again, this is just to explain why the STUNT technique for TCP NAT trave= rsal has not seen much use. I would still consider it a useful technique th= at NATs should try to support if they can, after all it is up to the applic= ations to choose what they are comfortable with. But not present it as the = only available technique, this is misleading and dangerous.

 

--

Ivan Chollet
--=_29953c12b941797c1a2ce71d1ca8a83b-- From ietfdbh@comcast.net Sat Jun 22 07:00:02 2013 Return-Path: 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 EC22611E80FA for ; Sat, 22 Jun 2013 07:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, 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 OE1plXbkuc92 for ; Sat, 22 Jun 2013 06:59:56 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id E135221F9FC5 for ; Sat, 22 Jun 2013 06:59:55 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta14.westchester.pa.mail.comcast.net with comcast id rRY21l0080Fqzac5ERzvnu; Sat, 22 Jun 2013 13:59:55 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta08.westchester.pa.mail.comcast.net with comcast id rRzu1l01M2yZEBF3URzvD0; Sat, 22 Jun 2013 13:59:55 +0000 From: "ietfdbh" To: "'Simon Perreault'" , Date: Sat, 22 Jun 2013 09:59:44 -0400 Message-ID: <000001ce6f50$c0427250$40c756f0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5HjBSH/YKZhBSZRPuEFWqjmmaU4Q== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371909595; bh=Ap4Kl9ouujIKKEc7NnATGGw9Tul6yGOItmq4T8y12Rs=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=epMK5E/LX6aKKIXLcA/nuPpSHsQfHMzGRi7YukJsqBmwvccYOuTyH+6XevkeZzKOi VX5HFHF/GJgmicdhUJ5L67HOCiKBwKJH8MAZ7C/p7O0GzcC3m2j3yeupIPMSvDuNj5 WyD+KwNVlPAuNlvc6D2w7D5CtcDiGdv/glkStTHl9vxmyfu468lgca48x5tc/Q2NYq so4reAwgFqCpaYV1T+l/ZhKD7w3a4vEDm0GxXM7mw8OHRn2xLN0dgX20w0vr+SUrAe kaU/CkdrcnyH9NDIQnLcPTnxM1qOSe5bl3T0OuLdZmd1mImk35/XEYdcM29Gxvwtzp S0SDDBUcGI2CA== Subject: [BEHAVE] nat-mib-06 abbreviations X-BeenThere: behave@ietf.org 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: Sat, 22 Jun 2013 14:00:02 -0000 Hi, My experience is that operators find abbreviations irritating. "Let's see, was that spelled out as counter, or abbreviated as Cnt, or Cntr, ...?" Counter names have often historically ended with an "s", which helps identify it as a counter. I'm not convinced you need the extra hierarchy of natCounters and natLimits and natPoolObjects, but I can live with it. Meaningful descriptors are preferred. Some NMS applications display the object name without a corresponding description, so meaningful object names help operators. Let's see, I wonder what natCntOOP means? The number of object-oriented programming counters? How about using natCntNoPorts instead? Do you really need the "Cnt" in the names? Wouldn't natNoPorts suffice? natCntTranslates => natTranslations? natCntResource => natResourceErrors? natCntStateMismatch => natStateMismatches? I also have concerns that this definition is ambiguous. You give an example rather than a clear description of what MUST and MUST NOT be counted in this counter. If the only thing that gets counted is incompatible flags, then name it natIncompatibleFlags. If other things are supposed to be counted, be explicit about WHAT gets counted in this counter. Ambiguity leads to differing interpretations, which hurts interoperability. I think this description needs tightening (and possibly a reference to a discussion of state mismatch) natCntQuota => natQuotaErrors? natQuotaRejects? natQuotaRefusedPkts? Does this only apply to incoming packets? I'm a bit uncomfortable with "The number of packets to which NAT could not be applied because ..." Does this mean "The number of packets not translated because ..." natCntMappings - it is generally considered bad practice to define objects that are easily derived from existing objects. These objects are instantiated on devices that should be focused on forwarding packets, not running formula calculations. Forwarding devices often have very limited resources, so having the nat device use its CPU to do unnecessary calculations and store the results in scarce memory is not a good idea. Let the NM application get Creations and Removals and let it do the calculations. Complexity should be pushed to the SNMP manager, not the SNMP agent. Here are the guidelines used in the BRIDGE-MIB: " To be consistent with IAB directives and good engineering practices, an explicit attempt was made to keep this MIB module as simple as possible. This was accomplished by applying the following criteria to objects proposed for inclusion: 1. Start with a small set of essential objects and add only as further objects are needed. 2. Require that objects be essential for either fault or configuration management. 3. Consider evidence of current use and/or utility. 4. Limit the total number of objects. 5. Exclude objects that are simply derivable from others in this or other MIB modules. 6. Avoid causing critical sections to be heavily instrumented. The guideline that was followed is one counter per critical section per layer. " natCntMappings - Can Creations exceed Removals? That would seem reasonable to me. If so, then Mappings = removals - creations would generate negative numbers, right? Shouldn't this be creations - removals? David Harrington ietfdbh@comcast.net +1-603-828-1401 From trac+behave@trac.tools.ietf.org Sat Jun 22 13:39:17 2013 Return-Path: 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 60C0C21F9E2F for ; Sat, 22 Jun 2013 13:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 QLv8yQP-vI+C for ; Sat, 22 Jun 2013 13:39:16 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8030721F9E2A for ; Sat, 22 Jun 2013 13:39:16 -0700 (PDT) Received: from localhost ([127.0.0.1]:37344 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UqUaT-00042Z-Hw; Sat, 22 Jun 2013 22:39:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "behave issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-behave-nat-mib@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: behave Date: Sat, 22 Jun 2013 20:39:09 -0000 X-URL: http://tools.ietf.org/wg/behave/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/behave/trac/ticket/15 Message-ID: <065.3afc93e0d2a3edd9af1ed12f11c3a4b7@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-behave-nat-mib@tools.ietf.org, dthaler@microsoft.com, behave@ietf.org X-SA-Exim-Mail-From: trac+behave@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: simon.perreault@viagenie.ca, ssenthil@cisco.com, tina.tsou.zouting@huawei.com Resent-Message-Id: <20130622203916.8030721F9E2A@ietfa.amsl.com> Resent-Date: Sat, 22 Jun 2013 13:39:16 -0700 (PDT) Resent-From: trac+behave@trac.tools.ietf.org X-Mailman-Approved-At: Sun, 23 Jun 2013 10:44:52 -0700 Cc: behave@ietf.org Subject: [BEHAVE] [behave] #15: DThaler comments on nat-mib-06 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Reply-To: behave@ietf.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 20:39:17 -0000 #15: DThaler comments on nat-mib-06 1) Section 5 of the current draft has " Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP." Per http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security that's supposed to be followed with " These are the tables and objects and their sensitivity/vulnerability: " Also the document has 2 paragraphs of text "There are a number of managed objects in this MIB that may contain ... versions of SNMP provide features for such a secure environment." which do not appear in the current MIB boilerplate at the link above. Should those 2 paragraphs be removed? 2) Section 5 contains MUST, SHOULD, etc. But the document is missing the boilerplate reference to RFC 2119. 3) Section 6 does not say whether any additional actions for IANA are needed. Suggest adding "No IANA actions are required by this document." 4) The MIB compiler I used complained about this: > natMappingPool OBJECT-TYPE > SYNTAX NatPoolId (0|1..4294967295) Because of > NatPoolId ::= TEXTUAL-CONVENTION > SYNTAX Unsigned32 (1..4294967295) That is, NatPoolId does not allow 0, and so natMappingPool cannot add it and still use the NatPoolId syntax. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-behave-nat- dthaler@microsoft.com | mib@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: nat-mib | Version: -06 Severity: In WG Last | Keywords: Call | -------------------------+------------------------------------------------- Ticket URL: behave From trac+behave@trac.tools.ietf.org Sat Jun 22 13:43:52 2013 Return-Path: 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 AB81221F9C52 for ; Sat, 22 Jun 2013 13:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 fDgS6FKWLT5T for ; Sat, 22 Jun 2013 13:43:52 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A8A0321F9E2F for ; Sat, 22 Jun 2013 13:43:47 -0700 (PDT) Received: from localhost ([127.0.0.1]:37702 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UqUen-0007n3-OI; Sat, 22 Jun 2013 22:43:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "behave issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-behave-nat-mib@tools.ietf.org, ietfdbh@comcast.net X-Trac-Project: behave Date: Sat, 22 Jun 2013 20:43:37 -0000 X-URL: http://tools.ietf.org/wg/behave/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/behave/trac/ticket/16 Message-ID: <063.8b5ba2cb04c71bf35a032d6599636819@trac.tools.ietf.org> X-Trac-Ticket-ID: 16 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-behave-nat-mib@tools.ietf.org, ietfdbh@comcast.net, behave@ietf.org X-SA-Exim-Mail-From: trac+behave@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: simon.perreault@viagenie.ca, ssenthil@cisco.com, tina.tsou.zouting@huawei.com Resent-Message-Id: <20130622204347.A8A0321F9E2F@ietfa.amsl.com> Resent-Date: Sat, 22 Jun 2013 13:43:47 -0700 (PDT) Resent-From: trac+behave@trac.tools.ietf.org X-Mailman-Approved-At: Sun, 23 Jun 2013 10:44:52 -0700 Cc: behave@ietf.org Subject: [BEHAVE] [behave] #16: David Harrington comments on nat-mib-06 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Reply-To: behave@ietf.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 20:43:52 -0000 #16: David Harrington comments on nat-mib-06 1) A while back, I suggested that, if you are deprecating all of the NAT- MIB in rfc4008, that it would be better to do this as a separate document from the NEW-NAT-MIB (or whatever the new module gets called). Simon asked me to get consensus from the MIB Doctors. I checked with the MIB Doctor list, and only got one reply - from Juergen, who apparently recommended a single document. His response: " I have probably been pushing them into this because at the beginning it was not really clear why the existing NAT-MIB is fatally flawed such that it needs a complete replacement. If the behave WG has meanwhile reached consensus that indeed the existing NAT-MIB is fatally flawed and needs a complete replacement, then indeed what you suggest makes sense. I assume the WG has checked with those who have implementations of the existing NAT-MIB (if any) that they agree on a need for a complete new MIB." 2) Since deprecated objects are not obsoleted, I think new security considerations might be called for relating to the deprecated objects - especially if there are security implications of implementing BOTH the current and deprecated objects. Some NMS applications will support only the old MIB module; others may support only the new MIB module. Some agents will want to implement both, to make their devices manageable from either type of NMS application. Some NMS applications will want to support both, to deal with both legacy and new agents. MIB modules often make information available that could potentially be used by attackers. Are there particular risks involved in exposing the information of these two NAT-MIBs in combination? Are there potential risks associated with the potential confusion of looking at a NAT from the different perspectives used by these two NAT MIB approaches? 3) I notice there is no "Operational Considerations" section. I wonder if one is called for here, because operators may be faced with NMS applications and/or agents that support both the deprecated and the new MIB module. What should operators (and NMS applications) do with this potentially conflicting information? What should they explicitly NOT do? E.g., What assumptions should they NOT make about the relationships between specific objects in the old and new versions? My impression is that the old and the new MIB modules might be appropriate depending on the environment in which they exist, and the old MIB is implemented (to whatever degree of compliance) in existing legacy devices, so simply saying "never use the old MIB" is not going to be an acceptable approach. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-behave-nat- ietfdbh@comcast.net | mib@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: nat-mib | Version: -06 Severity: In WG Last | Keywords: Call | -------------------------+------------------------------------------------- Ticket URL: behave From trac+behave@trac.tools.ietf.org Sat Jun 22 13:47:20 2013 Return-Path: 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 6156221F9CCD for ; Sat, 22 Jun 2013 13:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 OALMnC484aiK for ; Sat, 22 Jun 2013 13:47:19 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8A16721F9C52 for ; Sat, 22 Jun 2013 13:47:19 -0700 (PDT) Received: from localhost ([127.0.0.1]:37976 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UqUiJ-0006Pi-Qn; Sat, 22 Jun 2013 22:47:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "behave issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-behave-64-analysis@tools.ietf.org, ietfdbh@comcast.net X-Trac-Project: behave Date: Sat, 22 Jun 2013 20:47:15 -0000 X-URL: http://tools.ietf.org/wg/behave/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/behave/trac/ticket/17 Message-ID: <063.99a8d4e800904094387dd94f53364273@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-behave-64-analysis@tools.ietf.org, ietfdbh@comcast.net, behave@ietf.org X-SA-Exim-Mail-From: trac+behave@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mohamed.boucadair@orange.com, rpenno@juniper.net, ssenthil@cisco.com, tasaxena@cisco.com Resent-Message-Id: <20130622204719.8A16721F9C52@ietfa.amsl.com> Resent-Date: Sat, 22 Jun 2013 13:47:19 -0700 (PDT) Resent-From: trac+behave@trac.tools.ietf.org X-Mailman-Approved-At: Sun, 23 Jun 2013 10:44:52 -0700 Cc: behave@ietf.org Subject: [BEHAVE] [behave] #17: nat-mib-06 abbreviations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Reply-To: behave@ietf.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 20:47:20 -0000 #17: nat-mib-06 abbreviations My experience is that operators find abbreviations irritating. "Let's see, was that spelled out as counter, or abbreviated as Cnt, or Cntr, ...?" Counter names have often historically ended with an "s", which helps identify it as a counter. I'm not convinced you need the extra hierarchy of natCounters and natLimits and natPoolObjects, but I can live with it. Meaningful descriptors are preferred. Some NMS applications display the object name without a corresponding description, so meaningful object names help operators. Let's see, I wonder what natCntOOP means? The number of object-oriented programming counters? How about using natCntNoPorts instead? Do you really need the "Cnt" in the names? Wouldn't natNoPorts suffice? natCntTranslates => natTranslations? natCntResource => natResourceErrors? natCntStateMismatch => natStateMismatches? I also have concerns that this definition is ambiguous. You give an example rather than a clear description of what MUST and MUST NOT be counted in this counter. If the only thing that gets counted is incompatible flags, then name it natIncompatibleFlags. If other things are supposed to be counted, be explicit about WHAT gets counted in this counter. Ambiguity leads to differing interpretations, which hurts interoperability. I think this description needs tightening (and possibly a reference to a discussion of state mismatch) natCntQuota => natQuotaErrors? natQuotaRejects? natQuotaRefusedPkts? Does this only apply to incoming packets? I'm a bit uncomfortable with "The number of packets to which NAT could not be applied because ..." Does this mean "The number of packets not translated because ..." natCntMappings - it is generally considered bad practice to define objects that are easily derived from existing objects. These objects are instantiated on devices that should be focused on forwarding packets, not running formula calculations. Forwarding devices often have very limited resources, so having the nat device use its CPU to do unnecessary calculations and store the results in scarce memory is not a good idea. Let the NM application get Creations and Removals and let it do the calculations. Complexity should be pushed to the SNMP manager, not the SNMP agent. Here are the guidelines used in the BRIDGE-MIB: " To be consistent with IAB directives and good engineering practices, an explicit attempt was made to keep this MIB module as simple as possible. This was accomplished by applying the following criteria to objects proposed for inclusion: 1. Start with a small set of essential objects and add only as further objects are needed. 2. Require that objects be essential for either fault or configuration management. 3. Consider evidence of current use and/or utility. 4. Limit the total number of objects. 5. Exclude objects that are simply derivable from others in this or other MIB modules. 6. Avoid causing critical sections to be heavily instrumented. The guideline that was followed is one counter per critical section per layer. " natCntMappings - Can Creations exceed Removals? That would seem reasonable to me. If so, then Mappings = removals - creations would generate negative numbers, right? Shouldn't this be creations - removals? -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf- ietfdbh@comcast.net | behave-64-analysis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: 64-analysis | Version: Severity: In WG Last | Keywords: Call | -------------------------+------------------------------------------------- Ticket URL: behave From trac+behave@trac.tools.ietf.org Sat Jun 22 13:49:02 2013 Return-Path: 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 84D1D21F9E92 for ; Sat, 22 Jun 2013 13:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 VWZUW5eQ1wCP for ; Sat, 22 Jun 2013 13:49:01 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1FC21F9E4E for ; Sat, 22 Jun 2013 13:48:59 -0700 (PDT) Received: from localhost ([127.0.0.1]:38057 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UqUju-0005MR-8c; Sat, 22 Jun 2013 22:48:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "behave issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-behave-nat-mib@tools.ietf.org, ietfdbh@comcast.net X-Trac-Project: behave Date: Sat, 22 Jun 2013 20:48:54 -0000 X-URL: http://tools.ietf.org/wg/behave/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/behave/trac/ticket/18 Message-ID: <063.b6847b9b775fe95bbb6d73326f6f043a@trac.tools.ietf.org> X-Trac-Ticket-ID: 18 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-behave-nat-mib@tools.ietf.org, ietfdbh@comcast.net, behave@ietf.org X-SA-Exim-Mail-From: trac+behave@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: simon.perreault@viagenie.ca, ssenthil@cisco.com, tina.tsou.zouting@huawei.com Resent-Message-Id: <20130622204859.7F1FC21F9E4E@ietfa.amsl.com> Resent-Date: Sat, 22 Jun 2013 13:48:59 -0700 (PDT) Resent-From: trac+behave@trac.tools.ietf.org X-Mailman-Approved-At: Sun, 23 Jun 2013 10:44:52 -0700 Cc: behave@ietf.org Subject: [BEHAVE] [behave] #18: SMI violation in nat-mib-06 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Reply-To: behave@ietf.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 20:49:02 -0000 #18: SMI violation in nat-mib-06 natAddrPortBindLocalAddr - the one being deprecated - is redefined in the new document. The original had InetAddress syntax with no range; the new doc adds a range (thereby redefining the range). I think this violates SMI rules (but it deserves checking to be sure). -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-behave-nat- ietfdbh@comcast.net | mib@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: nat-mib | Version: -06 Severity: In WG Last | Keywords: Call | -------------------------+------------------------------------------------- Ticket URL: behave From simon.perreault@viagenie.ca Mon Jun 24 04:00:19 2013 Return-Path: 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 A3DC711E80FB for ; Mon, 24 Jun 2013 04:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 dSb73Nc4mlHJ for ; Mon, 24 Jun 2013 04:00:14 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4330711E8127 for ; Mon, 24 Jun 2013 04:00:10 -0700 (PDT) Received: from [127.0.0.1] (h228.viagenie.ca [206.123.31.228]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5E4FB403D1; Mon, 24 Jun 2013 07:00:08 -0400 (EDT) Message-ID: <51C7F88F.1090406@viagenie.ca> Date: Mon, 24 Jun 2013 09:43:11 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: behave@ietf.org References: <065.3afc93e0d2a3edd9af1ed12f11c3a4b7@trac.tools.ietf.org> In-Reply-To: <065.3afc93e0d2a3edd9af1ed12f11c3a4b7@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: behave issue tracker , draft-ietf-behave-nat-mib@tools.ietf.org, dthaler@microsoft.com Subject: Re: [BEHAVE] [behave] #15: DThaler comments on nat-mib-06 X-BeenThere: behave@ietf.org 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: Mon, 24 Jun 2013 11:00:19 -0000 Meta-comment: I would prefer if we don't make use of the issue tracker for this draft. I already have my process for tracking issues, so this just makes my job a bit more tedious. Thanks. Le 2013-06-22 22:39, behave issue tracker a écrit : > #15: DThaler comments on nat-mib-06 > > 1) Section 5 of the current draft has > " Some of the readable objects in this MIB module (i.e., objects with a > MAX-ACCESS other than not-accessible) may be considered sensitive or > vulnerable in some network environments. It is thus important to > control even GET and/or NOTIFY access to these objects and possibly > to even encrypt the values of these objects when sending them over > the network via SNMP." > > Per http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security > that's supposed to be followed with > " These are the tables and objects and their > sensitivity/vulnerability: > > " > > Also the document has 2 paragraphs of text "There are a number of managed > objects in this MIB that may contain ... > versions of SNMP provide features for such a secure environment." > which do not appear in the current MIB boilerplate at the link above. > Should those 2 paragraphs be removed? Fixed in my local copy. > 2) Section 5 contains MUST, SHOULD, etc. But the document is missing > the boilerplate reference to RFC 2119. Added. > 3) Section 6 does not say whether any additional actions for IANA are > needed. Suggest adding "No IANA actions are required by this document." Added. > 4) The MIB compiler I used complained about this: > > natMappingPool OBJECT-TYPE > > SYNTAX NatPoolId (0|1..4294967295) > Because of > > NatPoolId ::= TEXTUAL-CONVENTION > > SYNTAX Unsigned32 (1..4294967295) > > That is, NatPoolId does not allow 0, and so natMappingPool cannot add it > and still use the NatPoolId syntax. Fixed. Simon From simon.perreault@viagenie.ca Mon Jun 24 04:00:35 2013 Return-Path: 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 4CE7211E8125 for ; Mon, 24 Jun 2013 04:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 TRDzjJca4eDO for ; Mon, 24 Jun 2013 04:00:34 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB5811E812A for ; Mon, 24 Jun 2013 04:00:34 -0700 (PDT) Received: from [127.0.0.1] (h228.viagenie.ca [206.123.31.228]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 054D94043F; Mon, 24 Jun 2013 07:00:32 -0400 (EDT) Message-ID: <51C7F652.6080100@viagenie.ca> Date: Mon, 24 Jun 2013 09:33:38 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: ietfdbh References: <000001ce6f50$c0427250$40c756f0$@comcast.net> In-Reply-To: <000001ce6f50$c0427250$40c756f0$@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: behave@ietf.org Subject: Re: [BEHAVE] nat-mib-06 abbreviations X-BeenThere: behave@ietf.org 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: Mon, 24 Jun 2013 11:00:35 -0000 Le 2013-06-22 15:59, ietfdbh a écrit : > My experience is that operators find abbreviations irritating. > "Let's see, was that spelled out as counter, or abbreviated as Cnt, or Cntr, > ...?" > > Counter names have often historically ended with an "s", which helps > identify it as a counter. > > I'm not convinced you need the extra hierarchy of natCounters and natLimits > and natPoolObjects, but I can live with it. > > Meaningful descriptors are preferred. > Some NMS applications display the object name without a corresponding > description, so meaningful object names help operators. > Let's see, I wonder what natCntOOP means? The number of object-oriented > programming counters? > How about using natCntNoPorts instead? > > Do you really need the "Cnt" in the names? Wouldn't natNoPorts suffice? > natCntTranslates => natTranslations? > natCntResource => natResourceErrors? > > natCntStateMismatch => natStateMismatches? That makes sense, and I don't see a big problem with changing names now. I remember that when naming some objects I hit the length limit and had to use abbreviations instead of full names. I'll see what I can do while staying under the limit. > I also have concerns that this definition is ambiguous. You give an example > rather than a clear description of what MUST and MUST NOT be counted in this > counter. Could this be due to the underspecified nature of NAT itself? > If the only thing that gets counted is incompatible flags, then name it > natIncompatibleFlags. It's not just flags. Various NAT implementations expect various things from packets so that they match state entries. One example of something that is not a flag would be TCP sequence number mismatches. Some NATs track TCP sequence numbers. When a packet is outside an acceptable window, this counter would get incremented. > If other things are supposed to be counted, be explicit about WHAT gets > counted in this counter. That's pretty much impossible given that NAT is underspecified and various NAT implementations do various things. What we can do is eliminate any ambiguity, while remaining generic. > Ambiguity leads to differing interpretations, which hurts interoperability. > I think this description needs tightening (and possibly a reference to a > discussion of state mismatch) > > natCntQuota => natQuotaErrors? natQuotaRejects? natQuotaRefusedPkts? > Does this only apply to incoming packets? The whole MIB assumes that 1 packet in = 1 packet out. If an incoming packet gets dropped because an outbound quota is reached, then that still increments the counter. Is that what you meant? > I'm a bit uncomfortable with "The number of packets to which NAT could not > be applied because ..." > Does this mean "The number of packets not translated because ..." Agreed. Fixed in my local copy. > natCntMappings - it is generally considered bad practice to define objects > that are easily derived from existing objects. > These objects are instantiated on devices that should be focused on > forwarding packets, not running formula calculations. > Forwarding devices often have very limited resources, so having the nat > device use its CPU to do unnecessary calculations and store the results in > scarce memory is not a good idea. > Let the NM application get Creations and Removals and let it do the > calculations. > Complexity should be pushed to the SNMP manager, not the SNMP agent. Makes sense. Fixed in my local copy. > Here are the guidelines used in the BRIDGE-MIB: > " To be consistent with IAB directives and good engineering practices, > an explicit attempt was made to keep this MIB module as simple as > possible. This was accomplished by applying the following criteria > to objects proposed for inclusion: > > 1. Start with a small set of essential objects and add only as > further objects are needed. > > 2. Require that objects be essential for either fault or > configuration management. > > 3. Consider evidence of current use and/or utility. > > 4. Limit the total number of objects. > > 5. Exclude objects that are simply derivable from others in this or > other MIB modules. > > 6. Avoid causing critical sections to be heavily instrumented. The > guideline that was followed is one counter per critical section > per layer. > " > > natCntMappings - Can Creations exceed Removals? That would seem reasonable > to me. > If so, then Mappings = removals - creations would generate negative numbers, > right? > Shouldn't this be creations - removals? You're absolutely right! Fixed in my local copy. Thanks a lot! Simon From ietfdbh@comcast.net Mon Jun 24 07:40:32 2013 Return-Path: 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 5C1C521E8115 for ; Mon, 24 Jun 2013 07:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, 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 GzNfgVc0c3Gs for ; Mon, 24 Jun 2013 07:40:26 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 05F2121E8142 for ; Mon, 24 Jun 2013 07:40:15 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta05.westchester.pa.mail.comcast.net with comcast id sBxl1l0020EZKEL55EgFU7; Mon, 24 Jun 2013 14:40:15 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta01.westchester.pa.mail.comcast.net with comcast id sEgE1l01q2yZEBF3MEgFN4; Mon, 24 Jun 2013 14:40:15 +0000 From: "ietfdbh" To: "'Simon Perreault'" References: <000001ce6f50$c0427250$40c756f0$@comcast.net> <51C7F652.6080100@viagenie.ca> In-Reply-To: <51C7F652.6080100@viagenie.ca> Date: Mon, 24 Jun 2013 10:40:01 -0400 Message-ID: <00e101ce70e8$b59bc010$20d34030$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJxKzn4rWfaH+itd3rmJ/7nRk9KZAFwIbJhl/PhwYA= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372084815; bh=7DfpU6bQ1OAWdXgmEmeQps/7QZf+0OuhZWBogBRajw8=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=srosPoXwn1tcV24nM6IQ4AeM7tKZS7CsUSpphBYetk/smxUzL0ucMSSCmtx5VZ43C cWVhkCmiY/9Rbt7mBTGAvWHx0QdTKtXtlzs6KiAN4kG0lTss3vys9CginFLTNIVrh0 22Q0tjB5Xq9+5cPkNDZt7/zWzHDMzLZ6qcWK2ZGvKqTsP0SP0eFhIoaQPGxe8eihVG O6SLh1lJe7+cwcY702/zdwN9MulNFLQIAX2eLndsriUoiYZXDvbz2jLxRwQ4DO4n0S uttrycCHqNQV1jHCq65a0ectuGKseYtqQtm4k3WoVmBSkYjk/w96R3ZZw7VMhsKJqw 0DF9q/ikMnYPg== Cc: behave@ietf.org Subject: Re: [BEHAVE] nat-mib-06 abbreviations X-BeenThere: behave@ietf.org 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: Mon, 24 Jun 2013 14:40:32 -0000 > I also have concerns that this definition is ambiguous. You give an > example rather than a clear description of what MUST and MUST NOT be > counted in this counter. Could this be due to the underspecified nature of NAT itself? > If the only thing that gets counted is incompatible flags, then name > it natIncompatibleFlags. It's not just flags. Various NAT implementations expect various things from packets so that they match state entries. One example of something that is not a flag would be TCP sequence number mismatches. Some NATs track TCP sequence numbers. When a packet is outside an acceptable window, this counter would get incremented. > If other things are supposed to be counted, be explicit about WHAT > gets counted in this counter. That's pretty much impossible given that NAT is underspecified and various NAT implementations do various things. What we can do is eliminate any ambiguity, while remaining generic. [dbh>] But you're NOT eliminating the ambiguity. I have a background in NMS development, and know that it is frustrating to have the same counter name used to count different things on different implementations. The counter simply becomes useless. Having a "standard" is pretty useless if I have to code my application to know that the xyzCounter counts one thing on Cisco NATs, but Juniper NATs count something else, and Acme NATs some other implementation-dependent stuff, while Foobar NATs include their implementation-dependent things. And if the standard is ambiguous, then different models from the same vendors can choose to count different things as well, making it REALLY useless. The problem is that an NMS cannot compare the value of this counter across different implementations because the meaning of the counter differs across implementations. I recommend standardizing what can be agreed upon, and let those things that are implementation-specific (i.e., not agreed upon) be documented in implementation-specific MIB modules; maybe at some time in the future, agreement can be reached to extend the standard. if the counter goes into an IETF standard MIB, then it should standardize what gets counted in that counter. > Ambiguity leads to differing interpretations, which hurts interoperability. > I think this description needs tightening (and possibly a reference to > a discussion of state mismatch) > > natCntQuota => natQuotaErrors? natQuotaRejects? natQuotaRefusedPkts? > Does this only apply to incoming packets? The whole MIB assumes that 1 packet in = 1 packet out. If an incoming packet gets dropped because an outbound quota is reached, then that still increments the counter. Is that what you meant? [dbh>] well, yes, that is what I meant, at least to a degree. Remember that under SMI rules, you cannot go back and change the semantics of this description later. As long as there is a 1:1 mapping, it probably doesn't matter whether you count this as an incoming packets of an outgoing packet issue. However, given the variety of NAT implementations, as you've mentioned, and I'm not sure that variability will go away anytime soon, somebody might choose to implement different quotas for incoming and outgoing. Hence, it could be better to specify that this counts "the number of incoming packets that did not get translated ..."; that way if ever implementations allow for a not-1:1 mapping, they still know which packets to count in this counter. And if the 1:1 assumption always holds true, it makes no difference. I think the naming should change to reflect that this is a drop counter - I suggest natQuotaDrops. In general, counters count behaviors/actions such as drops, rather than things like quotas, so the behavior/action being counted should be part of the name. If I am an operator looking at a counter named natCntResource, is this counting the resources? Or is it counting the drops caused by inadequate resources? Ideally an operator should not need to go read the MIB description clause to figure this out, while trying to debug why the company's shopping cart network connection suddenly isn't working. It helps a lot to use meaningful object names. Dbh From dthaler@microsoft.com Mon Jun 24 09:08:30 2013 Return-Path: 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 8F35921E8113 for ; Mon, 24 Jun 2013 09:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.467 X-Spam-Level: X-Spam-Status: No, score=-97.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, 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 iAclFRxRu4mI for ; Mon, 24 Jun 2013 09:08:25 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id F393A21E80EA for ; Mon, 24 Jun 2013 09:08:24 -0700 (PDT) Received: from BY2FFO11FD028.protection.gbl (10.1.15.203) by BY2FFO11HUB023.protection.gbl (10.1.14.110) with Microsoft SMTP Server (TLS) id 15.0.707.0; Mon, 24 Jun 2013 16:08:24 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD028.mail.protection.outlook.com (10.1.15.217) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Mon, 24 Jun 2013 16:08:23 +0000 Received: from CO9EHSOBE031.bigfish.com (157.54.51.81) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.3.136.1; Mon, 24 Jun 2013 16:08:12 +0000 Received: from mail162-co9-R.bigfish.com (10.236.132.254) by CO9EHSOBE031.bigfish.com (10.236.130.94) with Microsoft SMTP Server id 14.1.225.23; Mon, 24 Jun 2013 16:07:58 +0000 Received: from mail162-co9 (localhost [127.0.0.1]) by mail162-co9-R.bigfish.com (Postfix) with ESMTP id EF39B3E015D for ; Mon, 24 Jun 2013 16:07:57 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -22 X-BigFish: PS-22(zz9371Ic89bh936eI542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz31h2a8h668h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: softfail (mail162-co9: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=dthaler@microsoft.com; helo=BL2PRD0310HT002.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB272; H:BY2PR03MB269.namprd03.prod.outlook.com; LANG:en; Received: from mail162-co9 (localhost.localdomain [127.0.0.1]) by mail162-co9 (MessageSwitch) id 1372090075854368_24108; Mon, 24 Jun 2013 16:07:55 +0000 (UTC) Received: from CO9EHSMHS016.bigfish.com (unknown [10.236.132.229]) by mail162-co9.bigfish.com (Postfix) with ESMTP id CE0DE2E0270; Mon, 24 Jun 2013 16:07:55 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by CO9EHSMHS016.bigfish.com (10.236.130.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 24 Jun 2013 16:07:52 +0000 Received: from BY2PR03MB272.namprd03.prod.outlook.com (10.242.37.24) by BL2PRD0310HT002.namprd03.prod.outlook.com (10.255.97.37) with Microsoft SMTP Server (TLS) id 14.16.324.0; Mon, 24 Jun 2013 16:07:52 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB272.namprd03.prod.outlook.com (10.242.37.24) with Microsoft SMTP Server (TLS) id 15.0.702.21; Mon, 24 Jun 2013 16:07:50 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.25]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.25]) with mapi id 15.00.0702.005; Mon, 24 Jun 2013 16:07:49 +0000 From: Dave Thaler To: Simon Perreault , "behave@ietf.org" Thread-Topic: [BEHAVE] [behave] #15: DThaler comments on nat-mib-06 Thread-Index: AQHOb4irgrtSCKpf206jR9TXgEbTZ5lEfeKAgACMhxA= Date: Mon, 24 Jun 2013 16:07:48 +0000 Message-ID: <127fa65575ef496db0b2a7ddc7186321@BY2PR03MB269.namprd03.prod.outlook.com> References: <065.3afc93e0d2a3edd9af1ed12f11c3a4b7@trac.tools.ietf.org> <51C7F88F.1090406@viagenie.ca> In-Reply-To: <51C7F88F.1090406@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.141.94.226] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB272.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TRAC.TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%VIAGENIE.CA$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377424004)(199002)(51704005)(377454003)(13464003)(189002)(76482001)(44976004)(50986001)(63696002)(47776003)(59766001)(65816001)(47736001)(4396001)(20776003)(56776001)(6806003)(66066001)(81342001)(79102001)(51856001)(76576001)(47446002)(76796001)(47976001)(16676001)(74502001)(50466002)(31966008)(23676002)(74706001)(74662001)(49866001)(69226001)(76786001)(54316002)(77096001)(15202345003)(33646001)(80022001)(81542001)(53806001)(46102001)(54356001)(74316001)(56816003)(74366001)(77982001)(74876001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB023; H:TK5EX14HUBC107.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 088751B4D4 Cc: behave issue tracker , "draft-ietf-behave-nat-mib@tools.ietf.org" Subject: Re: [BEHAVE] [behave] #15: DThaler comments on nat-mib-06 X-BeenThere: behave@ietf.org 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: Mon, 24 Jun 2013 16:08:30 -0000 QXMgZG9jdW1lbnQgc2hlcGhlcmQsIEkgd2FudCB0byBtYWtlIHVzZSBvZiB0aGUgaXNzdWUgdHJh Y2tlci4NCkl0IGJlbmVmaXRzIHRoZSBjaGFpcnMgYW5kIHRoZSBXRyBieSBzZWVpbmcgd2hhdCB3 ZSdyZSBzdGlsbCB3YWl0aW5nIGZvciBiZWZvcmUgc3VibWl0dGluZyB0byB0aGUgSUVTRywNCmFu ZCB3aGF0IHdhcyBhZGRyZXNzZWQgaW4gd2hhdCBwcmV2aW91cyB2ZXJzaW9uIG9mIHRoZSBkb2Mu DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBiZWhhdmUtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOmJlaGF2ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU2ltb24g UGVycmVhdWx0DQpTZW50OiBNb25kYXksIEp1bmUgMjQsIDIwMTMgMTI6NDMgQU0NClRvOiBiZWhh dmVAaWV0Zi5vcmcNCkNjOiBiZWhhdmUgaXNzdWUgdHJhY2tlcjsgZHJhZnQtaWV0Zi1iZWhhdmUt bmF0LW1pYkB0b29scy5pZXRmLm9yZzsgRGF2ZSBUaGFsZXINClN1YmplY3Q6IFJlOiBbQkVIQVZF XSBbYmVoYXZlXSAjMTU6IERUaGFsZXIgY29tbWVudHMgb24gbmF0LW1pYi0wNg0KDQpNZXRhLWNv bW1lbnQ6IEkgd291bGQgcHJlZmVyIGlmIHdlIGRvbid0IG1ha2UgdXNlIG9mIHRoZSBpc3N1ZSB0 cmFja2VyIGZvciB0aGlzIGRyYWZ0LiBJIGFscmVhZHkgaGF2ZSBteSBwcm9jZXNzIGZvciB0cmFj a2luZyBpc3N1ZXMsIHNvIHRoaXMganVzdCBtYWtlcyBteSBqb2IgYSBiaXQgbW9yZSB0ZWRpb3Vz LiBUaGFua3MuDQoNCkxlIDIwMTMtMDYtMjIgMjI6MzksIGJlaGF2ZSBpc3N1ZSB0cmFja2VyIGEg w6ljcml0IDoNCj4gIzE1OiBEVGhhbGVyIGNvbW1lbnRzIG9uIG5hdC1taWItMDYNCj4NCj4gICAx KSBTZWN0aW9uIDUgb2YgdGhlIGN1cnJlbnQgZHJhZnQgaGFzDQo+ICAgIiBTb21lIG9mIHRoZSBy ZWFkYWJsZSBvYmplY3RzIGluIHRoaXMgTUlCIG1vZHVsZSAoaS5lLiwgb2JqZWN0cyB3aXRoIGEN Cj4gICAgICBNQVgtQUNDRVNTIG90aGVyIHRoYW4gbm90LWFjY2Vzc2libGUpIG1heSBiZSBjb25z aWRlcmVkIHNlbnNpdGl2ZSBvcg0KPiAgICAgIHZ1bG5lcmFibGUgaW4gc29tZSBuZXR3b3JrIGVu dmlyb25tZW50cy4gIEl0IGlzIHRodXMgaW1wb3J0YW50IHRvDQo+ICAgICAgY29udHJvbCBldmVu IEdFVCBhbmQvb3IgTk9USUZZIGFjY2VzcyB0byB0aGVzZSBvYmplY3RzIGFuZCBwb3NzaWJseQ0K PiAgICAgIHRvIGV2ZW4gZW5jcnlwdCB0aGUgdmFsdWVzIG9mIHRoZXNlIG9iamVjdHMgd2hlbiBz ZW5kaW5nIHRoZW0gb3Zlcg0KPiAgICAgIHRoZSBuZXR3b3JrIHZpYSBTTk1QLiINCj4NCj4gICBQ ZXIgaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9vcHMvdHJhYy93aWtpL21pYi1zZWN1 cml0eQ0KPiAgIHRoYXQncyBzdXBwb3NlZCB0byBiZSBmb2xsb3dlZCB3aXRoDQo+ICAgIiBUaGVz ZSBhcmUgdGhlIHRhYmxlcyBhbmQgb2JqZWN0cyBhbmQgdGhlaXINCj4gICAgICBzZW5zaXRpdml0 eS92dWxuZXJhYmlsaXR5Og0KPg0KPiAgICAgICA8bGlzdCB0aGUgdGFibGVzIGFuZCBvYmplY3Rz IGFuZCBzdGF0ZSB3aHkgdGhleSBhcmUgc2Vuc2l0aXZlPiINCj4NCj4gICBBbHNvIHRoZSBkb2N1 bWVudCBoYXMgMiBwYXJhZ3JhcGhzIG9mIHRleHQgIlRoZXJlIGFyZSBhIG51bWJlciBvZiBtYW5h Z2VkDQo+ICAgb2JqZWN0cyBpbiB0aGlzIE1JQiB0aGF0IG1heSBjb250YWluIC4uLg0KPiAgIHZl cnNpb25zIG9mIFNOTVAgcHJvdmlkZSBmZWF0dXJlcyBmb3Igc3VjaCBhIHNlY3VyZSBlbnZpcm9u bWVudC4iDQo+ICAgd2hpY2ggZG8gbm90IGFwcGVhciBpbiB0aGUgY3VycmVudCBNSUIgYm9pbGVy cGxhdGUgYXQgdGhlIGxpbmsgYWJvdmUuDQo+ICAgU2hvdWxkIHRob3NlIDIgcGFyYWdyYXBocyBi ZSByZW1vdmVkPw0KDQpGaXhlZCBpbiBteSBsb2NhbCBjb3B5Lg0KDQo+ICAgMikgU2VjdGlvbiA1 IGNvbnRhaW5zIE1VU1QsIFNIT1VMRCwgZXRjLiAgIEJ1dCB0aGUgZG9jdW1lbnQgaXMgbWlzc2lu Zw0KPiAgIHRoZSBib2lsZXJwbGF0ZSByZWZlcmVuY2UgdG8gUkZDIDIxMTkuDQoNCkFkZGVkLg0K DQo+ICAgMykgU2VjdGlvbiA2IGRvZXMgbm90IHNheSB3aGV0aGVyIGFueSBhZGRpdGlvbmFsIGFj dGlvbnMgZm9yIElBTkEgYXJlDQo+ICAgbmVlZGVkLiAgU3VnZ2VzdCBhZGRpbmcgIk5vIElBTkEg YWN0aW9ucyBhcmUgcmVxdWlyZWQgYnkgdGhpcyBkb2N1bWVudC4iDQoNCkFkZGVkLg0KDQo+ICAg NCkgVGhlIE1JQiBjb21waWxlciBJIHVzZWQgY29tcGxhaW5lZCBhYm91dCB0aGlzOg0KPiAgID4g bmF0TWFwcGluZ1Bvb2wgT0JKRUNULVRZUEUNCj4gICA+ICAgICBTWU5UQVggTmF0UG9vbElkICgw fDEuLjQyOTQ5NjcyOTUpDQo+ICAgQmVjYXVzZSBvZg0KPiAgID4gTmF0UG9vbElkIDo6PSBURVhU VUFMLUNPTlZFTlRJT04NCj4gICA+ICAgICBTWU5UQVggVW5zaWduZWQzMiAoMS4uNDI5NDk2NzI5 NSkNCj4NCj4gICBUaGF0IGlzLCBOYXRQb29sSWQgZG9lcyBub3QgYWxsb3cgMCwgYW5kIHNvIG5h dE1hcHBpbmdQb29sIGNhbm5vdCBhZGQgaXQNCj4gICBhbmQgc3RpbGwgdXNlIHRoZSBOYXRQb29s SWQgc3ludGF4Lg0KDQpGaXhlZC4NCg0KU2ltb24NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpCZWhhdmUgbWFpbGluZyBsaXN0DQpCZWhhdmVAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVoYXZlDQo= From ivan@cacaoweb.org Tue Jun 25 09:45:46 2013 Return-Path: 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 3D98E21F92D3 for ; Tue, 25 Jun 2013 09:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 3cIyXtGItF15 for ; Tue, 25 Jun 2013 09:45:41 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1529121F9A1A for ; Tue, 25 Jun 2013 09:45:41 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1UrWO2-0002yn-5e; Tue, 25 Jun 2013 18:46:34 +0200 To: Simon Perreault X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Tue, 25 Jun 2013 18:46:34 +0200 From: ivan c Organization: cacaoweb In-Reply-To: <51C40374.8080403@viagenie.ca> References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> Message-ID: <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Cc: behave@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 16:45:46 -0000 On Fri, 21 Jun 2013 09:40:36 +0200, Simon Perreault wrote: >> >> (1) one UDP socket (local endpoint) can have multiple communication >> sessions. (with multiple remote endpoints) >> (2) one TCP socket can have only one session. >> (...) >> Consequence: >> Applications don't need to use more than one UDP local endpoint, but need >> to use many TCP local endpoints. >> (...) >> Consequence (1): >> The use case for port overloading should be TCP, not UDP. > > I don't understand how you jump from sockets on the host to external > ports on the NAT. I don't see how you reach this conclusion. > We have, for all UDP communications and all outbound TCP sessions: - one socket is bound to one local endpoint on the host. Additionally, two sockets have to bind to two different local endpoints. - one internal endpoint (=local endpoint) is mapped to one external endpoint on the NAT As a result, if no overloading, the NAT has to allocate a new external endpoint for every outbound TCP session. This doesn't apply to UDP. >> Back to NAT port overloading. A collision occurs when 2 sessions share >> the >> same 5-tuple. > > Stop right here. Some NATs don't track sessions. Those NATs don't care > about 5-tuples. All they do is map internal 3-tuple to external 3-tuple. > So for those NATs there is no conflict. They will just translate the > packets according to the existing mapping. > > All the following doesn't make sense to me given this. > Sure, *stateless* NATs also can't do much endpoint dependent filtering and lots of other things. They certainly can't do port overloading and are out of scope of this discussion. Nevertheless, NATs that do look at the full 5-tuple are free to implement port overloading if they wish. The purpose of my text was to explain how p2p applications interact with this, and in particular the relationship with TCP Hole Punching. Hope this helps. -- _Ivan Chollet_ From ivan@cacaoweb.org Tue Jun 25 10:19:11 2013 Return-Path: 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 E2BE111E8129 for ; Tue, 25 Jun 2013 10:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 z0ByH7oIFR82 for ; Tue, 25 Jun 2013 10:19:06 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id BC75011E8124 for ; Tue, 25 Jun 2013 10:19:06 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1UrWuR-0003V3-4U; Tue, 25 Jun 2013 19:20:03 +0200 To: Simon Perreault X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Tue, 25 Jun 2013 19:20:03 +0200 From: ivan c Organization: cacaoweb In-Reply-To: <51C4053D.5050703@viagenie.ca> References: <9637befefe07c43417c758a004e03f3c@cacaoweb.org> <51C4053D.5050703@viagenie.ca> Message-ID: X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Cc: Behave Subject: Re: [BEHAVE] TCP port overloading, preservation and CGNs 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 17:19:12 -0000 Hi, On Fri, 21 Jun 2013 09:48:13 +0200, Simon Perreault wrote: > 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? > TCP NAT traversal has many variants but as far as I'm aware no application has ever used EIM for TCP. It's nice for NAT to support different variants for applications to fall back on. > > Many NATs don't care about remote endpoints. Senthil and I were making the point that port preservation can never be satisfied for all TCP connections, regardless of whether we do port overloading or whether the NAT looks at the whole 5-tuple or not. Your comment is also a true statement, although not directly related to this point. >> 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. > (...) > Some NATs don't track sessions. > Sure, NATs can behave in many ways. The main point of the discussion is to provide suggestions so NAT can have some support for p2p applications, both for UDP and TCP. It is expected that stateless NATs won't have too much support for this. On the other hand, home NATs do offer such support and have done so for many years now. > Some NATs don't implement EDM and thus cannot switch to it. > By definition, all NATs are "EDM". "Endpoint-dependent Mapping" really means "Address and port-dependent Mapping". This is the most general case of NAT, where no requirement is made on the type of mapping. For instance, "EIM" is a particular case of this general case. Maybe we should use the term APDM instead of EDM for the sake of clarity, but the best is probably to avoid using the "EDM" acronym altogether if it leads to confusion. Instead, we can use the term "no particular requirement on the mapping scheme" or something similar. This way, people new to the discussion can understand the point immediately and we also avoid the use of new obscure acronyms. Again, the goal here should be to suggest options for NAT to behave in p2p friendly ways. Some useful optional features for CGNs, like port overloading, do have minor caveats that should be detailed in the document, and they also don't apply to "3-tuple" NATs as you mentioned. This is the best way in my opinion to write a Best Current Practices document. -- _Ivan Chollet_ From simon.perreault@viagenie.ca Wed Jun 26 00:51:47 2013 Return-Path: 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 D2D7711E80C5 for ; Wed, 26 Jun 2013 00:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 KMlgWuNBBqiJ for ; Wed, 26 Jun 2013 00:51:47 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2798F21E80D7 for ; Wed, 26 Jun 2013 00:51:46 -0700 (PDT) Received: from [127.0.0.1] (h228.viagenie.ca [206.123.31.228]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4CB784043D; Wed, 26 Jun 2013 03:51:45 -0400 (EDT) Message-ID: <51CA9D92.9050504@viagenie.ca> Date: Wed, 26 Jun 2013 09:51:46 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: ietfdbh References: <000001ce6f50$c0427250$40c756f0$@comcast.net> <51C7F652.6080100@viagenie.ca> <00e101ce70e8$b59bc010$20d34030$@comcast.net> In-Reply-To: <00e101ce70e8$b59bc010$20d34030$@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: behave@ietf.org Subject: Re: [BEHAVE] nat-mib-06 abbreviations X-BeenThere: behave@ietf.org 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: Wed, 26 Jun 2013 07:51:47 -0000 Le 2013-06-24 16:40, ietfdbh a écrit : > That's pretty much impossible given that NAT is underspecified and various > NAT implementations do various things. What we can do is eliminate any > ambiguity, while remaining generic. > [dbh>] But you're NOT eliminating the ambiguity. Right. I did not propose a way to eliminate the ambiguity. I was only suggesting that that is what we should do (as opposed to eliminating generality). > I have a background in NMS development, and know that it is frustrating to > have the same counter name used to count different things on different > implementations. The counter simply becomes useless. Having a "standard" is > pretty useless if I have to code my application to know that the xyzCounter > counts one thing on Cisco NATs, but Juniper NATs count something else, and > Acme NATs some other implementation-dependent stuff, while Foobar NATs > include their implementation-dependent things. And if the standard is > ambiguous, then different models from the same vendors can choose to count > different things as well, making it REALLY useless. > > The problem is that an NMS cannot compare the value of this counter across > different implementations because the meaning of the counter differs across > implementations. I recommend standardizing what can be agreed upon, and let > those things that are implementation-specific (i.e., not agreed upon) be > documented in implementation-specific MIB modules; maybe at some time in the > future, agreement can be reached to extend the standard. > > if the counter goes into an IETF standard MIB, then it should standardize > what gets counted in that counter. That's a fair point. Unless the WG disagrees, the state mismatches counters will be removed from the next revision. >> natCntQuota => natQuotaErrors? natQuotaRejects? natQuotaRefusedPkts? >> Does this only apply to incoming packets? > > The whole MIB assumes that 1 packet in = 1 packet out. If an incoming packet > gets dropped because an outbound quota is reached, then that still > increments the counter. Is that what you meant? > [dbh>] well, yes, that is what I meant, at least to a degree. > Remember that under SMI rules, you cannot go back and change the semantics > of this description later. > As long as there is a 1:1 mapping, it probably doesn't matter whether you > count this as an incoming packets of an outgoing packet issue. However, > given the variety of NAT implementations, as you've mentioned, and I'm not > sure that variability will go away anytime soon, somebody might choose to > implement different quotas for incoming and outgoing. Hence, it could be > better to specify that this counts "the number of incoming packets that did > not get translated ..."; that way if ever implementations allow for a > not-1:1 mapping, they still know which packets to count in this counter. And > if the 1:1 assumption always holds true, it makes no difference. Will do. > I think the naming should change to reflect that this is a drop counter - I > suggest natQuotaDrops. Ok. > In general, counters count behaviors/actions such as drops, rather than > things like quotas, so the behavior/action being counted should be part of > the name. If I am an operator looking at a counter named natCntResource, is > this counting the resources? Or is it counting the drops caused by > inadequate resources? Ideally an operator should not need to go read the MIB > description clause to figure this out, while trying to debug why the > company's shopping cart network connection suddenly isn't working. It helps > a lot to use meaningful object names. Makes total sense. Thanks for the help! Simon From simon.perreault@viagenie.ca Wed Jun 26 01:10:57 2013 Return-Path: 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 4AE6C21F9A3F for ; Wed, 26 Jun 2013 01:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 MJULKY7Mb78n for ; Wed, 26 Jun 2013 01:10:55 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 85C2E21F9967 for ; Wed, 26 Jun 2013 01:10:54 -0700 (PDT) Received: from [127.0.0.1] (h228.viagenie.ca [206.123.31.228]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9B3494043D; Wed, 26 Jun 2013 04:10:53 -0400 (EDT) Message-ID: <51CAA20F.4070307@viagenie.ca> Date: Wed, 26 Jun 2013 10:10:55 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: ivan@cacaoweb.org References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> In-Reply-To: <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 08:10:57 -0000 Le 2013-06-25 18:46, ivan c a écrit : > We have, for all UDP communications and all outbound TCP sessions: > - one socket is bound to one local endpoint on the host. Additionally, two > sockets have to bind to two different local endpoints. Not true. If you call connect() on a UDP socket, it behaves just like a TCP socket. > - one internal endpoint (=local endpoint) is mapped to one external > endpoint on the NAT > As a result, if no overloading, the NAT has to allocate a new external > endpoint for every outbound TCP session. > This doesn't apply to UDP. Not true because of the above. >>> Back to NAT port overloading. A collision occurs when 2 sessions share >>> the >>> same 5-tuple. >> >> Stop right here. Some NATs don't track sessions. Those NATs don't care >> about 5-tuples. All they do is map internal 3-tuple to external 3-tuple. > >> So for those NATs there is no conflict. They will just translate the >> packets according to the existing mapping. >> >> All the following doesn't make sense to me given this. >> > > Sure, *stateless* NATs also can't do much endpoint dependent filtering and > lots of other > things. They certainly can't do port overloading and are out of scope of > this discussion. I'm not referring to stateless NATs. I'm referring to stateful NATs that only map internal 3-tuple to external 3-tuple and do not do anything with 5-tuples. > Nevertheless, NATs that do look at the full 5-tuple are free to implement > port overloading if they wish. I still haven't seen any explanation why the following excerpts do not apply. RFC 4787: REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port overloading". Justification: This requirement must be met in order to enable two applications on the internal side of the NAT both to use the same port to try to communicate with the same destination. NATs that implement port preservation have to deal with conflicts on ports, and the multiple code paths this introduces often result in nondeterministic behavior. However, it should be understood that when a port is randomly assigned, it may just randomly happen to be assigned the same port. Applications must, therefore, be able to deal with both port preservation and no port preservation. RFC 5382: REQ-7: A NAT MUST NOT have a "Port assignment" behavior of "Port overloading" for TCP. Justification: This requirement allows two applications on the internal side of the NAT to consistently communicate with the same destination. Simon From simon.perreault@viagenie.ca Wed Jun 26 01:15:40 2013 Return-Path: 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 C775821F8904 for ; Wed, 26 Jun 2013 01:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 AL1FVnSaA5qa for ; Wed, 26 Jun 2013 01:15:39 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 67EFA21E8064 for ; Wed, 26 Jun 2013 01:15:36 -0700 (PDT) Received: from [127.0.0.1] (h228.viagenie.ca [206.123.31.228]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B947D4043D; Wed, 26 Jun 2013 04:15:31 -0400 (EDT) Message-ID: <51CAA325.8080201@viagenie.ca> Date: Wed, 26 Jun 2013 10:15:33 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: ivan@cacaoweb.org References: <9637befefe07c43417c758a004e03f3c@cacaoweb.org> <51C4053D.5050703@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Behave Subject: Re: [BEHAVE] TCP port overloading, preservation and CGNs X-BeenThere: behave@ietf.org 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: Wed, 26 Jun 2013 08:15:40 -0000 Le 2013-06-25 19:20, ivan c a écrit : >> Some NATs don't implement EDM and thus cannot switch to it. >> > > By definition, all NATs are "EDM". Please explain. > "Endpoint-dependent Mapping" really means "Address and port-dependent > Mapping". This is the most general case of NAT, where no requirement is > made on the type of mapping. For instance, "EIM" is a particular case of > this general case. I don't understand how this could be true. > Maybe we should use the term APDM instead of EDM for the sake of clarity, > but the best is probably to avoid using the "EDM" acronym altogether if it > leads to confusion. EDM is defined in RFC 6887. Let's keep using already-defined terminology if it fits. > Instead, we can use the term "no particular > requirement > on the mapping scheme" or something similar. This way, people new to the > discussion can understand the point immediately and we also avoid the use > of new obscure acronyms. EIM and EDM are not requirements. They are qualifiers of NAT behaviour. > Again, the goal here should be to suggest options for NAT to behave in p2p > friendly ways. Some useful optional features for CGNs, like port > overloading, do have minor caveats that should be detailed in the > document, > and they also don't apply to "3-tuple" NATs as you mentioned. > This is the best way in my opinion to write a Best Current Practices > document. I would simply like to first understand technically what you're proposing. Simon From ivan@cacaoweb.org Wed Jun 26 06:51:18 2013 Return-Path: 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 4B84421F9B4B for ; Wed, 26 Jun 2013 06:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 tMBKsghBxqDr for ; Wed, 26 Jun 2013 06:51:13 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id 290E621F9C37 for ; Wed, 26 Jun 2013 06:51:01 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1Urq8b-0003Yk-W8; Wed, 26 Jun 2013 15:51:58 +0200 To: Simon Perreault X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Wed, 26 Jun 2013 15:51:57 +0200 From: ivan c Organization: cacaoweb In-Reply-To: <51CAA20F.4070307@viagenie.ca> References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> Message-ID: <88c0ada2b8ebad078fb249ac6572fd8b@cacaoweb.org> X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Cc: behave@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 13:51:18 -0000 On Wed, 26 Jun 2013 10:10:55 +0200, Simon Perreault wrote: > Le 2013-06-25 18:46, ivan c a écrit : >> We have, for all UDP communications and all outbound TCP sessions: >> - one socket is bound to one local endpoint on the host. Additionally, >> two >> sockets have to bind to two different local endpoints. > > Not true. If you call connect() on a UDP socket, it behaves just like a > TCP socket. "Not true". interesting... Do you mind providing a counterexample, ie some pseudo-code that binds two sockets of the same protocol to the same local endpoint? -- _Ivan Chollet_ From cb.list6@gmail.com Wed Jun 26 06:56:54 2013 Return-Path: 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 7345D21F9079 for ; Wed, 26 Jun 2013 06:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 24HfwGlB8duo for ; Wed, 26 Jun 2013 06:56:53 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2813521F9BC9 for ; Wed, 26 Jun 2013 06:56:36 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id j13so10675000wgh.24 for ; Wed, 26 Jun 2013 06:56:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8+pVCZXvi8AtQ5P2Wx8+HGRCoSkQwi2TlODXquKDswo=; b=PmiAcbAlyU4zEstKQAfDBfiq5t5P6YJHHyVbkUkCI5PsaeUR6A4k35jrL6wmxdkAL3 LY8rWD+tvTUeDUqEPrwwHdfE9X2H2AEBAI8+FtI81V/VKfALGFecW5crHz6aLUdZ+IEU eqWxPW01zfWoP7XaBhWsmUi+1xngssKUsn4Q0P5IaNJhVIwO91nKuKFAFkVjgt2Js2cz 53u5vSiyg/7O0heUdkerc0e2cE7me/8pdqgivanzimBY4E5WTFrXAZZcFjBdsv+0hFQq WIOIZr1uTFOU7tQ/6Q8WsdTv78OTS7iMUH9sbZSwKPzuLEWNA/pjuuX5tcurdCluScxr 7IPQ== MIME-Version: 1.0 X-Received: by 10.180.12.11 with SMTP id u11mr2673581wib.61.1372254993322; Wed, 26 Jun 2013 06:56:33 -0700 (PDT) Received: by 10.194.240.36 with HTTP; Wed, 26 Jun 2013 06:56:33 -0700 (PDT) Received: by 10.194.240.36 with HTTP; Wed, 26 Jun 2013 06:56:33 -0700 (PDT) In-Reply-To: <51CAA20F.4070307@viagenie.ca> References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> Date: Wed, 26 Jun 2013 06:56:33 -0700 Message-ID: From: "cb.list6" To: Simon Perreault Content-Type: multipart/alternative; boundary=001a11c244926b1bd404e00f0340 Cc: behave@ietf.org, ivan@cacaoweb.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 13:56:54 -0000 --001a11c244926b1bd404e00f0340 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Jun 26, 2013 1:11 AM, "Simon Perreault" wrote: > > Le 2013-06-25 18:46, ivan c a =E9crit : > >> We have, for all UDP communications and all outbound TCP sessions: >> - one socket is bound to one local endpoint on the host. Additionally, two >> sockets have to bind to two different local endpoints. > > > Not true. If you call connect() on a UDP socket, it behaves just like a TCP socket. > > >> - one internal endpoint (=3Dlocal endpoint) is mapped to one external >> endpoint on the NAT >> As a result, if no overloading, the NAT has to allocate a new external >> endpoint for every outbound TCP session. >> This doesn't apply to UDP. > > > Not true because of the above. > > >>>> Back to NAT port overloading. A collision occurs when 2 sessions share >>>> the >>>> same 5-tuple. >>> >>> >>> Stop right here. Some NATs don't track sessions. Those NATs don't care >>> about 5-tuples. All they do is map internal 3-tuple to external 3-tuple= . >> >> >>> So for those NATs there is no conflict. They will just translate the >>> packets according to the existing mapping. >>> >>> All the following doesn't make sense to me given this. >>> >> >> Sure, *stateless* NATs also can't do much endpoint dependent filtering and >> lots of other >> things. They certainly can't do port overloading and are out of scope of >> this discussion. > > > I'm not referring to stateless NATs. I'm referring to stateful NATs that only map internal 3-tuple to external 3-tuple and do not do anything with 5-tuples. > > >> Nevertheless, NATs that do look at the full 5-tuple are free to implemen= t >> port overloading if they wish. > > > I still haven't seen any explanation why the following excerpts do not apply. > > RFC 4787: > > REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port > overloading". > > Justification: This requirement must be met in order to enable two > applications on the internal side of the NAT both to use the same > port to try to communicate with the same destination. NATs that > implement port preservation have to deal with conflicts on ports, > and the multiple code paths this introduces often result in > nondeterministic behavior. However, it should be understood that > when a port is randomly assigned, it may just randomly happen to > be assigned the same port. Applications must, therefore, be able > to deal with both port preservation and no port preservation. > > RFC 5382: > > > REQ-7: A NAT MUST NOT have a "Port assignment" behavior of "Port > overloading" for TCP. > > Justification: This requirement allows two applications on the > internal side of the NAT to consistently communicate with the same > destination. > > Simon > > i have the port overloading feature and plan to use it. Furthermore, i run a substantial endpoint dependent cgn. P2p on ipv4 is dead, has been dead. CB _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --001a11c244926b1bd404e00f0340 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jun 26, 2013 1:11 AM, "Simon Perreault" <simon.perreault@viagenie.ca> wrote:
>
> Le 2013-06-25 18:46, ivan c a =E9crit :
>
>> We have, for all UDP communications and all outbound TCP sessions:=
>> - one socket is bound to one local endpoint on the host. Additiona= lly, two
>> sockets have to bind to two different local endpoints.
>
>
> Not true. If you call connect() on a UDP socket, it behaves just like = a TCP socket.
>
>
>> - one internal endpoint (=3Dlocal endpoint) is mapped to one exter= nal
>> endpoint on the NAT
>> As a result, if no overloading, the NAT has to allocate a new exte= rnal
>> endpoint for every outbound TCP session.
>> This doesn't apply to UDP.
>
>
> Not true because of the above.
>
>
>>>> Back to NAT port overloading. A collision occurs when 2 se= ssions share
>>>> the
>>>> same 5-tuple.
>>>
>>>
>>> Stop right here. Some NATs don't track sessions. Those NAT= s don't care
>>> about 5-tuples. All they do is map internal 3-tuple to externa= l 3-tuple.
>>
>>
>>> So for those NATs there is no conflict. They will just transla= te the
>>> packets according to the existing mapping.
>>>
>>> All the following doesn't make sense to me given this.
>>>
>>
>> Sure, *stateless* NATs also can't do much endpoint dependent f= iltering and
>> lots of other
>> things. They certainly can't do port overloading and are out o= f scope of
>> this discussion.
>
>
> I'm not referring to stateless NATs. I'm referring to stateful= NATs that only map internal 3-tuple to external 3-tuple and do not do anyt= hing with 5-tuples.
>
>
>> Nevertheless, NATs that do look at the full 5-tuple are free to im= plement
>> port overloading if they wish.
>
>
> I still haven't seen any explanation why the following excerpts do= not apply.
>
> RFC 4787:
>
> =A0 =A0REQ-3: =A0A NAT MUST NOT have a "Port assignment" beh= avior of "Port
> =A0 =A0 =A0 overloading".
>
> =A0 =A0Justification: =A0This requirement must be met in order to enab= le two
> =A0 =A0 =A0 applications on the internal side of the NAT both to use t= he same
> =A0 =A0 =A0 port to try to communicate with the same destination. =A0N= ATs that
> =A0 =A0 =A0 implement port preservation have to deal with conflicts on= ports,
> =A0 =A0 =A0 and the multiple code paths this introduces often result i= n
> =A0 =A0 =A0 nondeterministic behavior. =A0However, it should be unders= tood that
> =A0 =A0 =A0 when a port is randomly assigned, it may just randomly hap= pen to
> =A0 =A0 =A0 be assigned the same port. =A0Applications must, therefore= , be able
> =A0 =A0 =A0 to deal with both port preservation and no port preservati= on.
>
> RFC 5382:
>
>
> =A0 =A0REQ-7: =A0A NAT MUST NOT have a "Port assignment" beh= avior of "Port
> =A0 =A0 =A0 overloading" for TCP.
>
> =A0 =A0Justification: =A0This requirement allows two applications on t= he
> =A0 =A0 =A0 internal side of the NAT to consistently communicate with = the same
> =A0 =A0 =A0 destination.
>
> Simon
>
>

i have the port overloading feature and plan to use it.

Furthermore, i run a substantial endpoint dependent cgn. P2p= on ipv4 is dead, has been dead.

CB _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.i= etf.org/mailman/listinfo/behave

--001a11c244926b1bd404e00f0340-- From simon.perreault@viagenie.ca Wed Jun 26 22:45:48 2013 Return-Path: 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 B5D4321F9C11 for ; Wed, 26 Jun 2013 22:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 rBbR76n0lpTT for ; Wed, 26 Jun 2013 22:45:48 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 35A2321F9C10 for ; Wed, 26 Jun 2013 22:45:47 -0700 (PDT) Received: from porto.nomis80.org (87-231-137-212.rev.numericable.fr [87.231.137.212]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1E97B4043D; Thu, 27 Jun 2013 01:45:45 -0400 (EDT) Message-ID: <51CBD188.4060408@viagenie.ca> Date: Thu, 27 Jun 2013 07:45:44 +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 To: ivan@cacaoweb.org References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <88c0ada2b8ebad078fb249ac6572fd8b@cacaoweb.org> In-Reply-To: <88c0ada2b8ebad078fb249ac6572fd8b@cacaoweb.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 05:45:48 -0000 Le 2013-06-26 15:51, ivan c a écrit : >>> We have, for all UDP communications and all outbound TCP sessions: >>> - one socket is bound to one local endpoint on the host. Additionally, >>> two sockets have to bind to two different local endpoints. >> >> Not true. If you call connect() on a UDP socket, it behaves just like a >> TCP socket. > > "Not true". interesting... > Do you mind providing a counterexample, ie some pseudo-code that binds two > sockets of the same protocol to the same local endpoint? s1 = socket(..., SOCK_DGRAM, ...); s2 = socket(..., SOCK_DGRAM, ...); connect(s1, ...); connect(s2, ...); The kernel is free to use the same local endpoint for those two sockets as long as the remote endpoint is different. If you really want to force reusing the same local endpoint, you do the SO_REUSEADDR+bind() dance before calling connect(). Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Thu Jun 27 02:21:09 2013 Return-Path: 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 14CD921F9C7E for ; Thu, 27 Jun 2013 02:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 WHcfqLZ0zjCp for ; Thu, 27 Jun 2013 02:21:01 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 32DE721F9C99 for ; Thu, 27 Jun 2013 02:20:52 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:7ddf:d947:bc5f:fe38]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BA2134040B; Thu, 27 Jun 2013 05:20:50 -0400 (EDT) Message-ID: <51CC03F4.5010505@viagenie.ca> Date: Thu, 27 Jun 2013 11:20:52 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "cb.list6" References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: behave@ietf.org, ivan@cacaoweb.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 09:21:15 -0000 Le 2013-06-26 15:56, cb.list6 a écrit : > i have the port overloading feature and plan to use it. > > Furthermore, i run a substantial endpoint dependent cgn. P2p on ipv4 is > dead, has been dead. One of the motivations behind our draft is to describe how port overloading can be safely enabled without adversely affecting P2P, based on CGN deployment experience. Are you saying that that effort is useless? Simon From repenno@cisco.com Thu Jun 27 03:08:17 2013 Return-Path: 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 2689921F9D58 for ; Thu, 27 Jun 2013 03:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 OPxJLIpxmAca for ; Thu, 27 Jun 2013 03:08:11 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id CB63821F9D4F for ; Thu, 27 Jun 2013 03:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3285; q=dns/txt; s=iport; t=1372327691; x=1373537291; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=U3EnTB/jG7TZ5ihesaRDg05yBYxG6iZsHvCaKX8FPdo=; b=aC7whwu1YVh9DKGtzhym0CiN/rS+OctmZQSHNdjdwz1xxLHlVKsERktN F4/bJ81mVinZgsvtEoray4CSKe54E4zIdYO5TLCjrwM7Yr+jqzpkiOnUF CBCa0Or3qNrQxAOqLA+LvuPrymJEvdMpJbHAb5MPTNbvrZRhU2uokrDC/ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAGEOzFGtJXG+/2dsb2JhbABbgkVEer8DfRZ0giMBAQEEeRIBCAQNAwECCx0oERQJCAIEAQ0FCId0Aw+xZg2IUoxtgjcgEQeDAmEDlV6OB4UlgxGCKA X-IronPort-AV: E=Sophos;i="4.87,951,1363132800"; d="scan'208,217";a="228028553" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 27 Jun 2013 10:08:00 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5RA7x3e008235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Jun 2013 10:07:59 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 27 Jun 2013 05:07:59 -0500 From: "Reinaldo Penno (repenno)" To: "cb.list6" , Simon Perreault Thread-Topic: [BEHAVE] (no subject) Thread-Index: AQHObEcIZ4P/TUzLjkeUtSRus7VxwZk8LkQAgAATJgCAAMOKAIACPdSAgADdtwCABuHeAIABAkOAgABgkoCAASArgA== Date: Thu, 27 Jun 2013 10:07:58 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090BE2EC@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.243.140] Content-Type: multipart/alternative; boundary="_000_45A697A8FFD7CF48BCF2BE7E106F0604090BE2ECxmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "behave@ietf.org" , "ivan@cacaoweb.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 10:08:17 -0000 --_000_45A697A8FFD7CF48BCF2BE7E106F0604090BE2ECxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can you cite any references of P2P being dead in Wireline both US and outsi= de? From: "cb.list6" > Date: Wed, 26 Jun 2013 06:56:33 -0700 To: Simon Perreault > Cc: >, > Subject: Re: [BEHAVE] (no subject) > i have the port overloading feature and plan to use it. Furthermore, i run a substantial endpoint dependent cgn. P2p on ipv4 is dea= d, has been dead. --_000_45A697A8FFD7CF48BCF2BE7E106F0604090BE2ECxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Can you cite any references of P2P being dead in Wireline both US and = outside? 


From: "cb.list6" <cb.list6@gmail.com>
Date: Wed, 26 Jun 2013 06:56:33 -07= 00
To: Simon Perreault <simon.perreault@viagenie.ca>
Cc: <behave@ietf.org>, <i= van@cacaoweb.org>
Subject: Re: [BEHAVE] (no subject)<= br>

>

i have the port overloading feature and plan to use it.

Furthermore, i run a substantial endpoint dependent cgn. P2p= on ipv4 is dead, has been dead.

 --_000_45A697A8FFD7CF48BCF2BE7E106F0604090BE2ECxmbrcdx04ciscoc_-- From ivan@cacaoweb.org Thu Jun 27 04:28:19 2013 Return-Path: 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 6832021F9D05 for ; Thu, 27 Jun 2013 04:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 h0Rxee5hrDff for ; Thu, 27 Jun 2013 04:28:14 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA3121F9CC5 for ; Thu, 27 Jun 2013 04:28:14 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1UsANx-000537-F7; Thu, 27 Jun 2013 13:29:09 +0200 To: Simon Perreault X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Thu, 27 Jun 2013 13:29:09 +0200 From: ivan c Organization: cacaoweb In-Reply-To: <51CBD188.4060408@viagenie.ca> References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <88c0ada2b8ebad078fb249ac6572fd8b@cacaoweb.org> <51CBD188.4060408@viagenie.ca> Message-ID: X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Cc: behave@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 11:28:19 -0000 On Thu, 27 Jun 2013 07:45:44 +0200, Simon Perreault wrote: > Le 2013-06-26 15:51, ivan c a écrit : >>>> We have, for all UDP communications and all outbound TCP sessions: >>>> - one socket is bound to one local endpoint on the host. Additionally, >>>> two sockets have to bind to two different local endpoints. >>> >>> Not true. If you call connect() on a UDP socket, it behaves just like a >>> TCP socket. >> >> "Not true". interesting... >> Do you mind providing a counterexample, ie some pseudo-code that binds >> two >> sockets of the same protocol to the same local endpoint? > > s1 = socket(..., SOCK_DGRAM, ...); > s2 = socket(..., SOCK_DGRAM, ...); > connect(s1, ...); > connect(s2, ...); > > The kernel is free to use the same local endpoint for those two sockets > as long as the remote endpoint is different. > > If you really want to force reusing the same local endpoint, you do the > SO_REUSEADDR+bind() dance before calling connect(). > > Simon Your pseudo-code will never bind the sockets on the same local endpoint. It is forbidden POSIX behavior. The option SO_REUSEADDR won't help either, this option is used to bind over an *already closed* socket in TIME_WAIT state, that's all. This is basic BSD-sockets: you can't bind two sockets to the same local endpoint. Never, ever. Not knowing this reveals deep ignorance of the basics of the topic. And since this point is key to the discussion about NATs... -- _Ivan Chollet_ From simon.perreault@viagenie.ca Thu Jun 27 05:23:51 2013 Return-Path: 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 CBEDD21F9D0A for ; Thu, 27 Jun 2013 05:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.306 X-Spam-Level: X-Spam-Status: No, score=-0.306 tagged_above=-999 required=5 tests=[AWL=-2.294, BAYES_00=-2.599, FRT_STOCK2=3.988, J_CHICKENPOX_63=0.6, NO_RELAYS=-0.001] 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 flaz1W65Xjrx for ; Thu, 27 Jun 2013 05:23:50 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 71E7A21F9CDD for ; Thu, 27 Jun 2013 05:23:47 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:7ddf:d947:bc5f:fe38]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9D9E14150E; Thu, 27 Jun 2013 08:23:46 -0400 (EDT) Message-ID: <51CC2ED4.7090506@viagenie.ca> Date: Thu, 27 Jun 2013 14:23:48 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ivan@cacaoweb.org References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <88c0ada2b8ebad078fb249ac6572fd8b@cacaoweb.org> <51CBD188.4060408@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 12:23:51 -0000 Le 2013-06-27 13:29, ivan c a écrit : >> s1 = socket(..., SOCK_DGRAM, ...); >> s2 = socket(..., SOCK_DGRAM, ...); >> connect(s1, ...); >> connect(s2, ...); >> >> The kernel is free to use the same local endpoint for those two sockets >> as long as the remote endpoint is different. >> >> If you really want to force reusing the same local endpoint, you do the >> SO_REUSEADDR+bind() dance before calling connect(). > > Your pseudo-code will never bind the sockets on the same local endpoint. > It is forbidden POSIX behavior. I'm ready to accept that, with a proper citation. > The option SO_REUSEADDR won't help either, this option is used to bind > over an *already closed* socket in TIME_WAIT state, that's all. I humbly believe that you are mistaken. It works, try it. This is a full example: #include #include int main() { struct sockaddr_in sin; int s1, s2, on = 1; memset(&sin, 0, sizeof(sin)); sin.sin_family = AF_INET; sin.sin_addr.s_addr = htonl(0xc1319f4e); sin.sin_port = htons(12345); s1 = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP); s2 = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP); setsockopt(s1, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on)); setsockopt(s2, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on)); bind(s1, (struct sockaddr *)&sin, sizeof(sin)); bind(s2, (struct sockaddr *)&sin, sizeof(sin)); sin.sin_addr.s_addr = htonl(0xce7b1f02); sin.sin_port = htons(53); connect(s1, (struct sockaddr *)&sin, sizeof(sin)); sin.sin_addr.s_addr = htonl(0x42e42d6e); sin.sin_port = htons(53); connect(s2, (struct sockaddr *)&sin, sizeof(sin)); return 0; } Here's the output of strace'ing that program on Linux: > socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3 > socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4 > setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 > setsockopt(4, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 > bind(3, {sa_family=AF_INET, sin_port=htons(12345), sin_addr=inet_addr("193.49.159.78")}, 16) = 0 > bind(4, {sa_family=AF_INET, sin_port=htons(12345), sin_addr=inet_addr("193.49.159.78")}, 16) = 0 > connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("206.123.31.2")}, 16) = 0 > connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("66.228.45.110")}, 16) = 0 connect()ing UDP sockets has two big advantages: 1) It allows using the same programming model for UDP and TCP. More code can be factored out, which is good software engineering. 2) It propagates ICMP errors up through the BSD API, allowing straightforward error handling that is again similar to TCP and can be factored out. For non-connected UDP sockets, ICMP errors are simply ignored. Since file descriptors are basically free, come at no additional performance cost when you use something like epoll, kqueue, or windows IOCP, and since this method does not consume additional ports, I recommend it over sendto()/recvfrom() when I teach network programming. This comes from W. Richard Stevens "UNIX Network Programming". The technique is used a lot in the wild. I'm not inventing anything. Simon From ivan@cacaoweb.org Thu Jun 27 06:26:19 2013 Return-Path: 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 91CF021F962D for ; Thu, 27 Jun 2013 06:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 3rj+1xIWP5Yy for ; Thu, 27 Jun 2013 06:26:15 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id CB3AE21F9DD7 for ; Thu, 27 Jun 2013 06:26:11 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1UsCE4-0006lW-AK; Thu, 27 Jun 2013 15:27:04 +0200 To: Simon Perreault X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Thu, 27 Jun 2013 15:27:04 +0200 From: ivan c Organization: cacaoweb In-Reply-To: <51CC2ED4.7090506@viagenie.ca> References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <88c0ada2b8ebad078fb249ac6572fd8b@cacaoweb.org> <51CBD188.4060408@viagenie.ca> <51CC2ED4.7090506@viagenie.ca> Message-ID: <4d2e082fd02ce46cd003631e8ca8eae9@cacaoweb.org> X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Cc: behave@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 13:26:19 -0000 On Thu, 27 Jun 2013 14:23:48 +0200, Simon Perreault wrote: > Le 2013-06-27 13:29, ivan c a écrit : >>> s1 = socket(..., SOCK_DGRAM, ...); >>> s2 = socket(..., SOCK_DGRAM, ...); >>> connect(s1, ...); >>> connect(s2, ...); >>> >>> The kernel is free to use the same local endpoint for those two sockets >>> as long as the remote endpoint is different. >>> >>> If you really want to force reusing the same local endpoint, you do the >>> SO_REUSEADDR+bind() dance before calling connect(). >> >> Your pseudo-code will never bind the sockets on the same local endpoint. >> It is forbidden POSIX behavior. > > I'm ready to accept that, with a proper citation. Without the option SO_REUSEADDR, this is forbidden POSIX behavior >> The option SO_REUSEADDR won't help either, this option is used to bind >> over an *already closed* socket in TIME_WAIT state, that's all. > > I humbly believe that you are mistaken. It works, try it. It surely *works* on platforms that support this use of SO_REUSEADDR, we discussed it numerous times already, including on the phone. I also made the point in numerous posts already that SO_REUSEADDR is used to bypass the TIME_WAIT state on closed sockets, and even this is not specified by POSIX. See http://www.ietf.org/mail-archive/web/behave/current/msg10876.html In another post, I explained that if you use SO_REUSEADDR on all your TCP sockets you expose them to the old duplicate problem, and the worst is that this crosses applications boundaries. See http://www.ietf.org/mail-archive/web/behave/current/msg10906.html However, applications should be free to use it if they wish. I also made the point numerous times that applications should have as many ways as possible to cross NATs. -- _Ivan Chollet_ From ivan@cacaoweb.org Thu Jun 27 06:43:12 2013 Return-Path: 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 5758E21F9D89 for ; Thu, 27 Jun 2013 06:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 JxiVtp5OBPAV for ; Thu, 27 Jun 2013 06:43:08 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id E7C5A21F9D87 for ; Thu, 27 Jun 2013 06:43:04 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1UsCUW-0006zj-9O; Thu, 27 Jun 2013 15:44:04 +0200 To: Simon Perreault X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Thu, 27 Jun 2013 15:44:04 +0200 From: ivan c Organization: cacaoweb In-Reply-To: <51CAA20F.4070307@viagenie.ca> References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> Message-ID: <7f35bf30538732e3953bd33bcab7a791@cacaoweb.org> X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Cc: behave@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 13:43:12 -0000 On Wed, 26 Jun 2013 10:10:55 +0200, Simon Perreault wrote: > I still haven't seen any explanation why the following excerpts do not > apply. > > RFC 4787: > > REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port > overloading". > > RFC 5382: > > REQ-7: A NAT MUST NOT have a "Port assignment" behavior of "Port > overloading" for TCP. > > Simon Because some NATs would like to do port overloading, which is in contradiction with these requirements. See section 4. of http://tools.ietf.org/html/draft-ietf-behave-requirements-update-00 . You're mentioned as an author on this draft by the way. In this post I explain why port overloading can be somewhat desirable: http://www.ietf.org/mail-archive/web/behave/current/msg10896.html I make the same point across a large number of my posts. -- _Ivan Chollet_ From simon.perreault@viagenie.ca Thu Jun 27 06:45:41 2013 Return-Path: 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 6DE6321F9DEB for ; Thu, 27 Jun 2013 06:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=0.765, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 mR+icmlwy4G8 for ; Thu, 27 Jun 2013 06:45:41 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E14AB21F9DE8 for ; Thu, 27 Jun 2013 06:45:40 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:7ddf:d947:bc5f:fe38]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 318B94150E; Thu, 27 Jun 2013 09:45:40 -0400 (EDT) Message-ID: <51CC4204.1040109@viagenie.ca> Date: Thu, 27 Jun 2013 15:45:40 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ivan@cacaoweb.org References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <88c0ada2b8ebad078fb249ac6572fd8b@cacaoweb.org> <51CBD188.4060408@viagenie.ca> <51CC2ED4.7090506@viagenie.ca> <4d2e082fd02ce46cd003631e8ca8eae9@cacaoweb.org> In-Reply-To: <4d2e082fd02ce46cd003631e8ca8eae9@cacaoweb.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 13:45:41 -0000 Le 2013-06-27 15:27, ivan c a écrit : >>> Your pseudo-code will never bind the sockets on the same local > endpoint. >>> It is forbidden POSIX behavior. >> >> I'm ready to accept that, with a proper citation. > > Without the option SO_REUSEADDR, this is forbidden POSIX behavior Please provide a citation. >>> The option SO_REUSEADDR won't help either, this option is used to bind >>> over an *already closed* socket in TIME_WAIT state, that's all. >> >> I humbly believe that you are mistaken. It works, try it. > > It surely *works* on platforms that support this use of SO_REUSEADDR, we > discussed it numerous times already, including on the phone. So what is the problem exactly? My point is that UDP and TCP are not different from the point of view of the NAT w.r.t. port preservation, since applications routinely call connect() on UDP sockets and it is entirely possible that two UDP sockets share the same local endpoint. POSIX standards have nothing to do with it. The functionality is available on many (all?) platforms, and applications use it. > I also made the point in numerous posts already that SO_REUSEADDR is used > to bypass the TIME_WAIT state on closed sockets, and even this is not > specified by POSIX. See > http://www.ietf.org/mail-archive/web/behave/current/msg10876.html > In another post, I explained that if you use SO_REUSEADDR on all your TCP > sockets you expose them to the old duplicate problem, and the worst is that > this crosses applications boundaries. See > http://www.ietf.org/mail-archive/web/behave/current/msg10906.html We're talking about UDP here. There is no TIME_WAIT. Simon From simon.perreault@viagenie.ca Thu Jun 27 06:55:23 2013 Return-Path: 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 0CEDC21F9E7C for ; Thu, 27 Jun 2013 06:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.026 X-Spam-Level: X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 ZMypxzUkeRSM for ; Thu, 27 Jun 2013 06:55:22 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB8621F9997 for ; Thu, 27 Jun 2013 06:55:22 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:7ddf:d947:bc5f:fe38]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9D1D6403E9; Thu, 27 Jun 2013 09:55:21 -0400 (EDT) Message-ID: <51CC444C.1030507@viagenie.ca> Date: Thu, 27 Jun 2013 15:55:24 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ivan@cacaoweb.org References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <7f35bf30538732e3953bd33bcab7a791@cacaoweb.org> In-Reply-To: <7f35bf30538732e3953bd33bcab7a791@cacaoweb.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 13:55:23 -0000 Le 2013-06-27 15:44, ivan c a écrit : >> I still haven't seen any explanation why the following excerpts do not >> apply. >> >> RFC 4787: >> >> REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port >> overloading". >> >> RFC 5382: >> >> REQ-7: A NAT MUST NOT have a "Port assignment" behavior of "Port >> overloading" for TCP. > > Because some NATs would like to do port overloading, which is in > contradiction with these requirements. "Would like to" is not a valid reason. We need technical arguments. > See section 4. of > http://tools.ietf.org/html/draft-ietf-behave-requirements-update-00 . > You're mentioned as an author on this draft by the way. I'm not disagreeing with myself. I am only observing that this discussion still has not yielded any good technical argument that we could add to our draft. I have suggested that one condition where port overloading could be used is when the NAT knows that it will not disrupt the application protocol. For example, the protocols running on TCP port 80 and UDP port 53 (HTTP and DNS) are purely client-server and therefore would not be affected by port overloading. Allowing NATs to do port overloading for those ports only would probably solve the scalability problem since they account for a large portion of the traffic. Do we really need anything more complex? > In this post I explain why port overloading can be somewhat desirable: > http://www.ietf.org/mail-archive/web/behave/current/msg10896.html > I make the same point across a large number of my posts. We know that port overloading is desirable for a number of reasons. What we need to argue is why the undesirable effects of port overloading do not apply or can be ignored. Simon From marka@isc.org Thu Jun 27 07:14:53 2013 Return-Path: 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 DE6E821F9B81 for ; Thu, 27 Jun 2013 07:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 tAzVGDh3yRTL for ; Thu, 27 Jun 2013 07:14:49 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 7C30D21F9D6A for ; Thu, 27 Jun 2013 07:14:49 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id E9664C9465; Thu, 27 Jun 2013 14:14:40 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372342489; bh=MYQIr2WNVO2roDyQxbOgJ8SisFeknSbIXG0b0HH2NLU=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=HWlP8mFdwV2x/nsD1Fu2N133NDOxmPMWkeQx+Z9lB+8kh3u1Qu83wlYeCxhS8kFyr uS/wM1fO/ns5FS/l20iuGtZUwVk82Rk+Bf3Xd9fOn8R9Ia4t/BJQvxE0KwB2HRX2yv QOZ8fviESXbx6NNkmOooaf5A95v7lF0TGMJlualU= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 27 Jun 2013 14:14:40 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C76BD16004A; Thu, 27 Jun 2013 14:15:57 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 1jbobOKIbGSB; Thu, 27 Jun 2013 14:15:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 7832E16009F; Thu, 27 Jun 2013 14:15:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2ugA6OuCeAFN; Thu, 27 Jun 2013 14:15:57 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id 2750816004A; Thu, 27 Jun 2013 14:15:57 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 3B0BD365EA62; Fri, 28 Jun 2013 00:14:34 +1000 (EST) To: Simon Perreault From: Mark Andrews References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <7f35bf30538732e3953bd33bcab7a791@cacaoweb.org> <51CC444C.1030507@viagenie.ca> In-reply-to: Your message of "Thu, 27 Jun 2013 15:55:24 +0200." <51CC444C.1030507@viagenie.ca> Date: Fri, 28 Jun 2013 00:14:34 +1000 Message-Id: <20130627141434.3B0BD365EA62@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: behave@ietf.org, ivan@cacaoweb.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 14:14:54 -0000 In message <51CC444C.1030507@viagenie.ca>, Simon Perreault writes: > Le 2013-06-27 15:44, ivan c a crit : > >> I still haven't seen any explanation why the following excerpts do not > >> apply. > >> > >> RFC 4787: > >> > >> REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port > >> overloading". > >> > >> RFC 5382: > >> > >> REQ-7: A NAT MUST NOT have a "Port assignment" behavior of "Port > >> overloading" for TCP. > > > > Because some NATs would like to do port overloading, which is in > > contradiction with these requirements. > > "Would like to" is not a valid reason. We need technical arguments. > > > See section 4. of > > http://tools.ietf.org/html/draft-ietf-behave-requirements-update-00 . > > You're mentioned as an author on this draft by the way. > > I'm not disagreeing with myself. I am only observing that this > discussion still has not yielded any good technical argument that we > could add to our draft. > > I have suggested that one condition where port overloading could be used > is when the NAT knows that it will not disrupt the application protocol. > For example, the protocols running on TCP port 80 and UDP port 53 (HTTP > and DNS) are purely client-server and therefore would not be affected by > port overloading. Allowing NATs to do port overloading for those ports > only would probably solve the scalability problem since they account for > a large portion of the traffic. And overloading DNS could potentially defeat the port randomisation done by the server even though nameservers do port overloading themselves to send traffic out a large set of ports choosen at random and reselected from at random. > Do we really need anything more complex? > > > In this post I explain why port overloading can be somewhat desirable: > > http://www.ietf.org/mail-archive/web/behave/current/msg10896.html > > I make the same point across a large number of my posts. > > We know that port overloading is desirable for a number of reasons. > > What we need to argue is why the undesirable effects of port overloading > do not apply or can be ignored. > > Simon > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ivan@cacaoweb.org Thu Jun 27 07:16:25 2013 Return-Path: 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 EBF5521F88AC for ; Thu, 27 Jun 2013 07:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 HyY4Zz+8x+xB for ; Thu, 27 Jun 2013 07:16:21 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id AD71B21F88A9 for ; Thu, 27 Jun 2013 07:16:21 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1UsD0j-0007Z8-4z; Thu, 27 Jun 2013 16:17:21 +0200 To: Simon Perreault X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Thu, 27 Jun 2013 16:17:21 +0200 From: ivan c Organization: cacaoweb In-Reply-To: <51CC4204.1040109@viagenie.ca> References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <88c0ada2b8ebad078fb249ac6572fd8b@cacaoweb.org> <51CBD188.4060408@viagenie.ca> <51CC2ED4.7090506@viagenie.ca> <4d2e082fd02ce46cd003631e8ca8eae9@cacaoweb.org> <51CC4204.1040109@viagenie.ca> Message-ID: X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Cc: behave@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 14:16:26 -0000 On Thu, 27 Jun 2013 15:45:40 +0200, Simon Perreault wrote: > > So what is the problem exactly? > I have no problem, however it seems that you do have an attitude problem :) (joking, but please do try keep it in friendly way, as this is a public mailing list after all) > My point is that UDP and TCP are not different from the point of view of > the NAT w.r.t. port preservation, since applications routinely call > connect() on UDP sockets and it is entirely possible that two UDP > sockets share the same local endpoint. POSIX standards have nothing to > do with it. It has everything to do with POSIX standards. Options that are outside the POSIX standards are usually quite flaky. See the shortcomings of the SO_REUSEADDR option that I mention in my previous post. I also totally agree that: UDP and TCP are not different from the point of view of the NAT w.r.t. port overloading (i assume you meant port overloading, you wrote "port preservation") It's just that applications usually use many more TCP local endpoints than UDP ones. See bittorrent and all others, empirical observations. So if there is a shortage of internal endpoints, it's more likely to happen for TCP. But it can also happen for UDP, i totally agree. > The functionality is available on many (all?) platforms, and > applications use it. Which applications use it for TCP? Reference needed. (Although I fully agree that p2p applications should consider using it) This was the point of this post: http://www.ietf.org/mail-archive/web/behave/current/msg10884.html With this follow-up: http://www.ietf.org/mail-archive/web/behave/current/msg10906.html >> I also made the point in numerous posts already that SO_REUSEADDR is used >> to bypass the TIME_WAIT state on closed sockets, and even this is not >> specified by POSIX. See >> http://www.ietf.org/mail-archive/web/behave/current/msg10876.html >> In another post, I explained that if you use SO_REUSEADDR on all your TCP >> sockets you expose them to the old duplicate problem, and the worst is >> that >> this crosses applications boundaries. See >> http://www.ietf.org/mail-archive/web/behave/current/msg10906.html > > We're talking about UDP here. There is no TIME_WAIT. > No, we are talking about TCP and UDP, this is the point of the whole discussion. SO_REUSEADDR is not needed on UDP anyway since you can already multiplex multiple sessions over the same UDP socket. Applications can still use it for pure convenience though, i agree, your previous post being a nice illustration of this use case. -- _Ivan Chollet_ From simon.perreault@viagenie.ca Thu Jun 27 07:21:14 2013 Return-Path: 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 AC16E21F9948 for ; Thu, 27 Jun 2013 07:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 ho-rBoxchhFI for ; Thu, 27 Jun 2013 07:21:14 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 941C321F9E48 for ; Thu, 27 Jun 2013 07:21:11 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:7ddf:d947:bc5f:fe38]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BD60047121; Thu, 27 Jun 2013 10:21:10 -0400 (EDT) Message-ID: <51CC4A59.8080801@viagenie.ca> Date: Thu, 27 Jun 2013 16:21:13 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Mark Andrews References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <7f35bf30538732e3953bd33bcab7a791@cacaoweb.org> <51CC444C.1030507@viagenie.ca> <20130627141434.3B0BD365EA62@drugs.dv.isc.org> In-Reply-To: <20130627141434.3B0BD365EA62@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: behave@ietf.org, ivan@cacaoweb.org Subject: [BEHAVE] DNS vs port overloading X-BeenThere: behave@ietf.org 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, 27 Jun 2013 14:21:14 -0000 Le 2013-06-27 16:14, Mark Andrews a écrit : >> I have suggested that one condition where port overloading could be used >> is when the NAT knows that it will not disrupt the application protocol. >> For example, the protocols running on TCP port 80 and UDP port 53 (HTTP >> and DNS) are purely client-server and therefore would not be affected by >> port overloading. Allowing NATs to do port overloading for those ports >> only would probably solve the scalability problem since they account for >> a large portion of the traffic. > > And overloading DNS could potentially defeat the port randomisation > done by the server even though nameservers do port overloading > themselves to send traffic out a large set of ports choosen at > random and reselected from at random. Good point. Could that be solved with operational advice? In the case of CGN, we could advise the ISP could to make sure that its recursive nameserver sits on the border between the internal and external realm such that no DNS traffic is handled by the CGN. Would that fully address your concern? Simon From ietfdbh@comcast.net Thu Jun 27 07:24:02 2013 Return-Path: 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 DB41221F9DA6 for ; Thu, 27 Jun 2013 07:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.937 X-Spam-Level: X-Spam-Status: No, score=-100.937 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, 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 pIPBahv5LKXh for ; Thu, 27 Jun 2013 07:23:48 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id BAE8C21F9D98 for ; Thu, 27 Jun 2013 07:23:47 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta02.westchester.pa.mail.comcast.net with comcast id tPjo1l0031swQuc51SPmQl; Thu, 27 Jun 2013 14:23:46 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta15.westchester.pa.mail.comcast.net with comcast id tSPl1l0152yZEBF3bSPmEt; Thu, 27 Jun 2013 14:23:46 +0000 From: "ietfdbh" To: , "'Simon Perreault'" References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <88c0ada2b8ebad078fb249ac6572fd8b@cacaoweb.org> <51CBD188.4060408@viagenie.ca> <51CC2ED4.7090506@viagenie.ca> <4d2e082fd02ce46cd003631e8ca8eae9@cacaoweb.org> In-Reply-To: <4d2e082fd02ce46cd003631e8ca8eae9@cacaoweb.org> Date: Thu, 27 Jun 2013 10:23:29 -0400 Message-ID: <014f01ce7341$e5416620$afc43260$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLopP1eobUZPgtPz7naKi/y960HhQEQ/aQnAlumSF0Bo1rV/wEHlPnhAnk6xGQBzTAyiAJ11cxSAPSb3cUCEdhSQAIen9OmAfAGgZWWdfFs4A== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372343026; bh=vBjBPBJ65PEjBjZ/7D/bbNFvG0vZ/ViSxKVe54pDHd8=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=mMvhlOKbBz9/GeLzbzZuVqhxfZZfV2kwc06iSKqkNcezU3USA4xbDHymE+Y1I7u7q mBokaPilRKl/E0B76LxgRVHM+ZbM7753c8eiXMiFarXTMKDUI1pyKvkc/8E0pbpzyD UrTCsymzyu4sKwrVG3iDPXJJvq2W0mSs1JMvlkdHwLfeQe1MFyggkmbARJV0BRE4MN GLb/X8nrppvu73EWdZzOSpDuU4M5TPvwgxxXhoYfyut+9S21PqgiaaVstxANdMZDam n395gkDSDW2+ORF7YiMRbLnBpNRdl4FfRoEye2XHSZ+WVc+637iQxRIb/hhl+GO4Th YOmUc+QoCg28Q== Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 14:24:02 -0000 -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf = Of ivan c Without the option SO_REUSEADDR, this is forbidden POSIX behavior [dbh>]=20 Ivan, can you provide a reference to the POSIX document and section that = says this is forbidden? If we design for this restriction, the document should provide a = reference so readers know why. David Harrington ietfdbh@comcast.net From simon.perreault@viagenie.ca Thu Jun 27 07:29:33 2013 Return-Path: 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 32E7B21F9DE3 for ; Thu, 27 Jun 2013 07:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 MEm+ls4jsYTA for ; Thu, 27 Jun 2013 07:29:32 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2C521F9DEB for ; Thu, 27 Jun 2013 07:29:14 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:7ddf:d947:bc5f:fe38]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6D81A47121; Thu, 27 Jun 2013 10:29:09 -0400 (EDT) Message-ID: <51CC4C37.90708@viagenie.ca> Date: Thu, 27 Jun 2013 16:29:11 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ivan@cacaoweb.org References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <88c0ada2b8ebad078fb249ac6572fd8b@cacaoweb.org> <51CBD188.4060408@viagenie.ca> <51CC2ED4.7090506@viagenie.ca> <4d2e082fd02ce46cd003631e8ca8eae9@cacaoweb.org> <51CC4204.1040109@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 14:29:33 -0000 Le 2013-06-27 16:17, ivan c a écrit : >> My point is that UDP and TCP are not different from the point of view of >> the NAT w.r.t. port preservation, since applications routinely call >> connect() on UDP sockets and it is entirely possible that two UDP >> sockets share the same local endpoint. POSIX standards have nothing to >> do with it. > > It has everything to do with POSIX standards. Options that are outside the > POSIX standards are usually quite flaky. See the shortcomings of the > SO_REUSEADDR option that I mention in my previous post. > I also totally agree that: UDP and TCP are not different from the point of > view of the NAT w.r.t. port overloading (i assume you meant port > overloading, you wrote "port preservation") No, I meant port preservation. I'm having a hard time following, and I thought that the UDP-vs-TCP distinction was w.r.t. port preservation. > It's just that applications usually use many more TCP local endpoints than > UDP ones. See bittorrent and all others, empirical observations. So if > there is a shortage of internal endpoints, it's more likely to happen for > TCP. But it can also happen for UDP, i totally agree. Fully agree. >> The functionality is available on many (all?) platforms, and >> applications use it. > > Which applications use it for TCP? Reference needed. By "it", I was referring to "the ability to open multiple sockets bound to the same client endpoint". With TCP, applications do it by default. > SO_REUSEADDR is not needed on UDP anyway since you can already multiplex > multiple sessions over the same UDP socket. Applications can still use it > for pure convenience though, i agree, your previous post being a nice > illustration of this use case. Exactly. My point is that UDP applications do sometimes create 5-tuples sharing the same local 3-tuple. Empirically we see that it is a minority of the traffic, but the functionality is there, is being used, and needs to be considered in the recommendations for NAT that we end up writing. Simon From marka@isc.org Thu Jun 27 07:36:38 2013 Return-Path: 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 4161321F9AD6 for ; Thu, 27 Jun 2013 07:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 7af+XVBIE8L1 for ; Thu, 27 Jun 2013 07:36:33 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id E393E21F9AFA for ; Thu, 27 Jun 2013 07:36:24 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 5DD26C94E8; Thu, 27 Jun 2013 14:36:17 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372343784; bh=rw3iM9+3CaQOa1hzT9SglALuXxlz/cQujLyG5Ui705Q=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=egdh+tjG59ViQ2H00+Ay82xFLwFC6MZaXJ8/xWQm+EJ2A0eAdhm7bk2dgWfDeUKBA sobuQWNDesGRE2Lpx9Ib9gs9TAWaVXg2Gns18qabC4n9LfmW9DhspcmuUYpI5I3/oA NYSwvm1A38pg1kHLzxH7IlJGzf7KPCANt129QIwc= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 27 Jun 2013 14:36:17 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4B1D116004A; Thu, 27 Jun 2013 14:37:34 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id PzD4MmwgBUOV; Thu, 27 Jun 2013 14:37:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 31E201600A2; Thu, 27 Jun 2013 14:37:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bbWgzkN7irjK; Thu, 27 Jun 2013 14:37:33 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id D6FA816009F; Thu, 27 Jun 2013 14:37:32 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 51ECB365ED5A; Fri, 28 Jun 2013 00:36:12 +1000 (EST) To: Simon Perreault From: Mark Andrews References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <7f35bf30538732e3953bd33bcab7a791@cacaoweb.org> <51CC444C.1030507@viagenie.ca> <20130627141434.3B0BD365EA62@drugs.dv.isc.org> <51CC4A59.8080801@viagenie.ca> In-reply-to: Your message of "Thu, 27 Jun 2013 16:21:13 +0200." <51CC4A59.8080801@viagenie.ca> Date: Fri, 28 Jun 2013 00:36:12 +1000 Message-Id: <20130627143612.51ECB365ED5A@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: behave@ietf.org, ivan@cacaoweb.org Subject: Re: [BEHAVE] DNS vs port overloading X-BeenThere: behave@ietf.org 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, 27 Jun 2013 14:36:38 -0000 In message <51CC4A59.8080801@viagenie.ca>, Simon Perreault writes: > Le 2013-06-27 16:14, Mark Andrews a écrit : > >> I have suggested that one condition where port overloading could be used > >> is when the NAT knows that it will not disrupt the application protocol. > >> For example, the protocols running on TCP port 80 and UDP port 53 (HTTP > >> and DNS) are purely client-server and therefore would not be affected by > >> port overloading. Allowing NATs to do port overloading for those ports > >> only would probably solve the scalability problem since they account for > >> a large portion of the traffic. > > > > And overloading DNS could potentially defeat the port randomisation > > done by the server even though nameservers do port overloading > > themselves to send traffic out a large set of ports choosen at > > random and reselected from at random. > > Good point. > > Could that be solved with operational advice? In the case of CGN, we > could advise the ISP could to make sure that its recursive nameserver > sits on the border between the internal and external realm such that no > DNS traffic is handled by the CGN. > > Would that fully address your concern? > > Simon No. Many ISP's have a history of mucking with DNS results when you use their servers. Most ISP's don't muck DNS queries not directed to their servers. For those that do you can usually see that they are mucking with results. You can't just redirect queries at a normal recursive server and think that will provide a "transparent DNS caching server". Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From simon.perreault@viagenie.ca Thu Jun 27 07:48:16 2013 Return-Path: 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 0680C21F9A6B for ; Thu, 27 Jun 2013 07:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 XvAzihDzyVcG for ; Thu, 27 Jun 2013 07:48:15 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 79C4921F9A43 for ; Thu, 27 Jun 2013 07:48:15 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:7ddf:d947:bc5f:fe38]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EC1F747121; Thu, 27 Jun 2013 10:48:13 -0400 (EDT) Message-ID: <51CC50AE.2080909@viagenie.ca> Date: Thu, 27 Jun 2013 16:48:14 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Mark Andrews References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <7f35bf30538732e3953bd33bcab7a791@cacaoweb.org> <51CC444C.1030507@viagenie.ca> <20130627141434.3B0BD365EA62@drugs.dv.isc.org> <51CC4A59.8080801@viagenie.ca> <20130627143612.51ECB365ED5A@drugs.dv.isc.org> In-Reply-To: <20130627143612.51ECB365ED5A@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: behave@ietf.org, ivan@cacaoweb.org Subject: Re: [BEHAVE] DNS vs port overloading X-BeenThere: behave@ietf.org 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, 27 Jun 2013 14:48:16 -0000 Le 2013-06-27 16:36, Mark Andrews a écrit : >>> And overloading DNS could potentially defeat the port randomisation >>> done by the server even though nameservers do port overloading >>> themselves to send traffic out a large set of ports choosen at >>> random and reselected from at random. >> >> Good point. >> >> Could that be solved with operational advice? In the case of CGN, we >> could advise the ISP could to make sure that its recursive nameserver >> sits on the border between the internal and external realm such that no >> DNS traffic is handled by the CGN. >> >> Would that fully address your concern? > > No. Many ISP's have a history of mucking with DNS results when you > use their servers. Most ISP's don't muck DNS queries not directed > to their servers. For those that do you can usually see that they > are mucking with results. > > You can't just redirect queries at a normal recursive server and > think that will provide a "transparent DNS caching server". Right, but, port overloading is not what kills the randomization done by the DNS client. Non-port preserving NAT is what kills it. Non-port preserving NATs are already required to implement port randomization according to: https://tools.ietf.org/html/rfc6056#section-4 Port overloading is not incompatible with port randomization. Maybe we should explicitly write this and add a reference to RFC 6056? Simon From ivan@cacaoweb.org Thu Jun 27 07:50:17 2013 Return-Path: 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 AFE7921F9C3A for ; Thu, 27 Jun 2013 07:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 o4ofDvbiZTxH for ; Thu, 27 Jun 2013 07:50:10 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id 324A821F9D0A for ; Thu, 27 Jun 2013 07:50:10 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1UsDXP-00084X-9j; Thu, 27 Jun 2013 16:51:07 +0200 To: ietfdbh X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Thu, 27 Jun 2013 16:51:07 +0200 From: ivan c Organization: cacaoweb In-Reply-To: <014f01ce7341$e5416620$afc43260$@comcast.net> References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <88c0ada2b8ebad078fb249ac6572fd8b@cacaoweb.org> <51CBD188.4060408@viagenie.ca> <51CC2ED4.7090506@viagenie.ca> <4d2e082fd02ce46cd003631e8ca8eae9@cacaoweb.org> <014f01ce7341$e5416620$afc43260$@comcast.net> Message-ID: X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Cc: behave@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 14:50:17 -0000 On Thu, 27 Jun 2013 10:23:29 -0400, "ietfdbh" wrote: > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of ivan c > > Without the option SO_REUSEADDR, this is forbidden POSIX behavior > [dbh>] > Ivan, can you provide a reference to the POSIX document and section that > says this is forbidden? > If we design for this restriction, the document should provide a reference > so readers know why. > > David Harrington > ietfdbh@comcast.net This is taken from "The Open Group Base Specifications" (or informally The Single Unix Specification), by the IEEE. Volume "System Interfaces", function "bind()": "The bind() function shall fail if: [EADDRINUSE] The specified address is already in use." As we mentioned in our posts, this can be bypassed by the use of the SO_REUSEADDR option, which behavior is unspecified by POSIX but has consistent semantics across major OSes. It is now defined with the following: "SO_REUSEADDR Specifies that the rules used in validating addresses supplied to bind() should allow reuse of local addresses, if this is supported by the protocol. This option takes an int value. This is a Boolean option." -- _Ivan Chollet_ From simon.perreault@viagenie.ca Thu Jun 27 07:57:11 2013 Return-Path: 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 7E8E221F9263 for ; Thu, 27 Jun 2013 07:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 lVzGxaADmKKY for ; Thu, 27 Jun 2013 07:57:11 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEE221F93E5 for ; Thu, 27 Jun 2013 07:56:43 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:7ddf:d947:bc5f:fe38]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5554647121; Thu, 27 Jun 2013 10:56:42 -0400 (EDT) Message-ID: <51CC52AC.8010702@viagenie.ca> Date: Thu, 27 Jun 2013 16:56:44 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ivan@cacaoweb.org References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <88c0ada2b8ebad078fb249ac6572fd8b@cacaoweb.org> <51CBD188.4060408@viagenie.ca> <51CC2ED4.7090506@viagenie.ca> <4d2e082fd02ce46cd003631e8ca8eae9@cacaoweb.org> <014f01ce7341$e5416620$afc43260$@comcast.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: behave@ietf.org, ietfdbh 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 14:57:11 -0000 Le 2013-06-27 16:51, ivan c a écrit : > This is taken from "The Open Group Base Specifications" (or informally The > Single Unix Specification), by the IEEE. > Volume "System Interfaces", function "bind()": > > > "The bind() function shall fail if: > > [EADDRINUSE] > The specified address is already in use." Unless I misunderstand, there is no call to bind() in the sample that you assert is prohibited by POSIX: s1 = socket(..., SOCK_DGRAM, ...); s2 = socket(..., SOCK_DGRAM, ...); connect(s1, ...); connect(s2, ...); About that code, I said: "The kernel is free to use the same local endpoint for those two sockets as long as the remote endpoint is different." To which you replied: "Your pseudo-code will never bind the sockets on the same local endpoint. It is forbidden POSIX behavior." Simon From ivan@cacaoweb.org Thu Jun 27 08:30:57 2013 Return-Path: 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 2101621F99E3 for ; Thu, 27 Jun 2013 08:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 Np5PeXW1-PRI for ; Thu, 27 Jun 2013 08:30:51 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id 29F7121F9CE9 for ; Thu, 27 Jun 2013 08:28:55 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1UsE8v-0000JG-GZ; Thu, 27 Jun 2013 17:29:53 +0200 To: Simon Perreault X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Thu, 27 Jun 2013 17:29:53 +0200 From: ivan c Organization: cacaoweb In-Reply-To: <51CC52AC.8010702@viagenie.ca> References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <88c0ada2b8ebad078fb249ac6572fd8b@cacaoweb.org> <51CBD188.4060408@viagenie.ca> <51CC2ED4.7090506@viagenie.ca> <4d2e082fd02ce46cd003631e8ca8eae9@cacaoweb.org> <014f01ce7341$e5416620$afc43260$@comcast.net> <51CC52AC.8010702@viagenie.ca> Message-ID: <4a641d08eccfd84d2882e32369ad8e61@cacaoweb.org> X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Cc: behave@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 15:30:57 -0000 On Thu, 27 Jun 2013 15:55:24 +0200, Simon Perreault wrote: > Le 2013-06-27 15:44, ivan c a écrit : >>> I still haven't seen any explanation why the following excerpts do not >>> apply. >>> >>> RFC 4787: >>> >>> REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port >>> overloading". >>> >>> RFC 5382: >>> >>> REQ-7: A NAT MUST NOT have a "Port assignment" behavior of "Port >>> overloading" for TCP. >> >> Because some NATs would like to do port overloading, which is in >> contradiction with these requirements. > > "Would like to" is not a valid reason. We need technical arguments. That's right, but I think it's the above requirements that needed a valid technical argument in the first place. The only argument that was given is that the set of requirements guarantees a deterministic (consistent) behavior of the NAT from the application point of view. But NATs never behave in a deterministic way, they might drop packets, or random NATs can sometimes appear to be deterministic. And it is not the point. What is required is that the *interfaces* of each *protocol* behaves in a deterministic way (ie, a function must behave according to its specification 100% of the time). Generally, a deterministic NAT allows you to write simpler protocols. In this post, I explain how the TCP Hole Punching protocol determinism is not affected: http://www.ietf.org/mail-archive/web/behave/current/msg10896.html > >> See section 4. of >> http://tools.ietf.org/html/draft-ietf-behave-requirements-update-00 . >> You're mentioned as an author on this draft by the way. > > I'm not disagreeing with myself. I am only observing that this > discussion still has not yielded any good technical argument that we > could add to our draft. see above, I feel it is a valid point. > > I have suggested that one condition where port overloading could be used > is when the NAT knows that it will not disrupt the application protocol. > For example, the protocols running on TCP port 80 and UDP port 53 (HTTP > and DNS) are purely client-server and therefore would not be affected by > port overloading. Allowing NATs to do port overloading for those ports > only would probably solve the scalability problem since they account for > a large portion of the traffic. > > Do we really need anything more complex? Allowing port overloading on 80 is the same as allowing it on all ports (applications are free to use any port for any protocol, Skype for instance uses port 80 for p2p communications). Your suggestion is good though, because I don't think any protocol is affected by port overloading. If they were, they would be badly designed, but still I have never heard of any such protocol. > We know that port overloading is desirable for a number of reasons. > > What we need to argue is why the undesirable effects of port overloading > do not apply or can be ignored. Definitely, this is the main point of our argument. I think we have progressed in this argument and provided useful material. In this post: http://www.ietf.org/mail-archive/web/behave/current/msg10896.html , I explain (among other things), why the TCP Hole Punching Protocol is not affected by the rare cases of collision due to port overloading. The application simply retries with a new TCP socket (on a new local endpoint). Also, it is mentioned in many RFCs that p2p applications need to expect NATs to have a variety of non-deterministic behaviors wrt port allocation, and have fallback mechanisms in place to deal with all cases. -- _Ivan Chollet_ From tom.taylor.stds@gmail.com Thu Jun 27 08:35:04 2013 Return-Path: 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 D39F621F997F for ; Thu, 27 Jun 2013 08:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 PU3pcp9JIUys for ; Thu, 27 Jun 2013 08:35:04 -0700 (PDT) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2E68021F9DCA for ; Thu, 27 Jun 2013 08:34:57 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id i7so1018986oag.2 for ; Thu, 27 Jun 2013 08:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=CKGVDMqGYnc0Xqr5nl1Wt+qJVIyvbL2BxLRlEomLP+U=; b=cvIxo6vzOK6htTp5PiAol2z9cvCb1Q8J8cpoJp9aRYw4FSIFjNYV5u+V3yQIjcsJvx znKXysB1HFcNO6EMrfVDCarL4Al+uNRt2QEVDWqGRC6ZyXQeS6FALOmy/nKeNY27YRgj duiVtp+5nEDmLpHbi2f0KgSj7zC63v89v/Z/0OjyISrsiCvQSo3JDVl3Y8YybLg1AO+/ JojYBDVf2fsn2IGNnrrJgonatJmSQJwfqcMbunVMxy+f0veieKPbVqSWvyH2jHS6uPWJ q+nTcBOn5Yist8z7TNhTMeGIDv52dZzymeeJchtdwJz1qNGjRWz6bis6rQ94OqkH3iPN cqtA== X-Received: by 10.60.132.230 with SMTP id ox6mr3109011oeb.66.1372347295583; Thu, 27 Jun 2013 08:34:55 -0700 (PDT) Received: from [192.168.1.64] ([216.254.161.150]) by mx.google.com with ESMTPSA id b7sm563749oby.5.2013.06.27.08.34.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Jun 2013 08:34:54 -0700 (PDT) Message-ID: <51CC5B9D.1050706@gmail.com> Date: Thu, 27 Jun 2013 11:34:53 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Simon Perreault References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <88c0ada2b8ebad078fb249ac6572fd8b@cacaoweb.org> <51CBD188.4060408@viagenie.ca> <51CC2ED4.7090506@viagenie.ca> <4d2e082fd02ce46cd003631e8ca8eae9@cacaoweb.org> <014f01ce7341$e5416620$afc43260$@comcast.net> <51CC52AC.8010702@viagenie.ca> In-Reply-To: <51CC52AC.8010702@viagenie.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: ietfdbh , behave@ietf.org, ivan@cacaoweb.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 15:35:05 -0000 The POSIX.1 specification for Connect() says the following: "If the socket has not already been bound to a local address, connect() shall bind it to an address which, unless the socket's address family is AF_UNIX, is an unused local address." On 27/06/2013 10:56 AM, Simon Perreault wrote: > Le 2013-06-27 16:51, ivan c a écrit : >> This is taken from "The Open Group Base Specifications" (or informally >> The >> Single Unix Specification), by the IEEE. >> Volume "System Interfaces", function "bind()": >> >> >> "The bind() function shall fail if: >> >> [EADDRINUSE] >> The specified address is already in use." > > Unless I misunderstand, there is no call to bind() in the sample that > you assert is prohibited by POSIX: > > s1 = socket(..., SOCK_DGRAM, ...); > s2 = socket(..., SOCK_DGRAM, ...); > connect(s1, ...); > connect(s2, ...); > > About that code, I said: "The kernel is free to use the same local > endpoint for those two sockets as long as the remote endpoint is > different." > > To which you replied: "Your pseudo-code will never bind the sockets on > the same local endpoint. It is forbidden POSIX behavior." > > Simon > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From simon.perreault@viagenie.ca Thu Jun 27 08:59:37 2013 Return-Path: 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 8960021F9E46 for ; Thu, 27 Jun 2013 08:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[NO_RELAYS=-0.001] 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 BHH+LGlco9xv for ; Thu, 27 Jun 2013 08:59:35 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 04C0221F9C34 for ; Thu, 27 Jun 2013 08:59:03 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:7ddf:d947:bc5f:fe38]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2582E4040A; Thu, 27 Jun 2013 11:59:00 -0400 (EDT) Message-ID: <51CC6144.3080000@viagenie.ca> Date: Thu, 27 Jun 2013 17:59:00 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ivan@cacaoweb.org References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <88c0ada2b8ebad078fb249ac6572fd8b@cacaoweb.org> <51CBD188.4060408@viagenie.ca> <51CC2ED4.7090506@viagenie.ca> <4d2e082fd02ce46cd003631e8ca8eae9@cacaoweb.org> <014f01ce7341$e5416620$afc43260$@comcast.net> <51CC52AC.8010702@viagenie.ca> <4a641d08eccfd84d2882e32369ad8e61@cacaoweb.org> In-Reply-To: <4a641d08eccfd84d2882e32369ad8e61@cacaoweb.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 15:59:37 -0000 Le 2013-06-27 17:29, ivan c a écrit : >> We know that port overloading is desirable for a number of reasons. >> What we need to argue is why the undesirable effects of port overloading >> do not apply or can be ignored. > > Definitely, this is the main point of our argument. > I think we have progressed in this argument and provided useful material. > In this post: > http://www.ietf.org/mail-archive/web/behave/current/msg10896.html , I > explain (among other things), why the TCP Hole Punching Protocol is not > affected by the rare cases of collision due to port overloading. The > application simply retries with a new TCP socket (on a new local endpoint). ...as long as the NAT does port preservation, right? If so, the problem I see is that CGNs do not / can not / will not do port preservation, as a few people already pointed out. Simon From ivan@cacaoweb.org Thu Jun 27 09:02:22 2013 Return-Path: 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 B44D121F9E3E for ; Thu, 27 Jun 2013 09:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 y86K08SE+X+K for ; Thu, 27 Jun 2013 09:02:16 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id 35EBA21F9E67 for ; Thu, 27 Jun 2013 09:02:16 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1UsEfD-0000qc-55; Thu, 27 Jun 2013 18:03:15 +0200 To: Simon Perreault X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Thu, 27 Jun 2013 18:03:15 +0200 From: ivan c Organization: cacaoweb In-Reply-To: <51CC52AC.8010702@viagenie.ca> References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <88c0ada2b8ebad078fb249ac6572fd8b@cacaoweb.org> <51CBD188.4060408@viagenie.ca> <51CC2ED4.7090506@viagenie.ca> <4d2e082fd02ce46cd003631e8ca8eae9@cacaoweb.org> <014f01ce7341$e5416620$afc43260$@comcast.net> <51CC52AC.8010702@viagenie.ca> Message-ID: X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Cc: behave@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 16:02:22 -0000 On Thu, 27 Jun 2013 16:56:44 +0200, Simon Perreault wrote: > Le 2013-06-27 16:51, ivan c a écrit : >> This is taken from "The Open Group Base Specifications" (or informally >> The >> Single Unix Specification), by the IEEE. >> Volume "System Interfaces", function "bind()": >> >> >> "The bind() function shall fail if: >> >> [EADDRINUSE] >> The specified address is already in use." > > Unless I misunderstand, there is no call to bind() in the sample that > you assert is prohibited by POSIX: > > s1 = socket(..., SOCK_DGRAM, ...); > s2 = socket(..., SOCK_DGRAM, ...); > connect(s1, ...); > connect(s2, ...); > > About that code, I said: "The kernel is free to use the same local > endpoint for those two sockets as long as the remote endpoint is > different." > > To which you replied: "Your pseudo-code will never bind the sockets on > the same local endpoint. It is forbidden POSIX behavior." > > Simon Yes, the kernel will actually call bind() in the connect() function from within the kernel (implicit bind()). strace wouldn't show it as it is a kernel-mode call. -- _Ivan Chollet_ From ivan@cacaoweb.org Thu Jun 27 09:46:09 2013 Return-Path: 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 20C2921F9E5B for ; Thu, 27 Jun 2013 09:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 BGxZP4mSOjfy for ; Thu, 27 Jun 2013 09:46:04 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id E703721F99FE for ; Thu, 27 Jun 2013 09:46:00 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1UsFLX-0001Sk-1y; Thu, 27 Jun 2013 18:46:59 +0200 To: Simon Perreault X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Thu, 27 Jun 2013 18:46:59 +0200 From: ivan c Organization: cacaoweb In-Reply-To: <51CC6144.3080000@viagenie.ca> References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <88c0ada2b8ebad078fb249ac6572fd8b@cacaoweb.org> <51CBD188.4060408@viagenie.ca> <51CC2ED4.7090506@viagenie.ca> <4d2e082fd02ce46cd003631e8ca8eae9@cacaoweb.org> <014f01ce7341$e5416620$afc43260$@comcast.net> <51CC52AC.8010702@viagenie.ca> <4a641d08eccfd84d2882e32369ad8e61@cacaoweb.org> <51CC6144.3080000@viagenie.ca> Message-ID: X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Cc: Behave 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 16:46:09 -0000 On Thu, 27 Jun 2013 17:59:00 +0200, Simon Perreault wrote: > Le 2013-06-27 17:29, ivan c a écrit : >>> We know that port overloading is desirable for a number of reasons. >>> What we need to argue is why the undesirable effects of port overloading >>> do not apply or can be ignored. >> >> Definitely, this is the main point of our argument. >> I think we have progressed in this argument and provided useful material. >> In this post: >> http://www.ietf.org/mail-archive/web/behave/current/msg10896.html , I >> explain (among other things), why the TCP Hole Punching Protocol is not >> affected by the rare cases of collision due to port overloading. The >> application simply retries with a new TCP socket (on a new local >> endpoint). > > ...as long as the NAT does port preservation, right? > No, I meant it in the general case with port overloading, with or without TCP port preservation. As you know, port overloading breaks the EIM requirement in the general case. This is why port overloading is a MUST NOT in the existing RFCs. But since collisions are supposed to be rare, p2p application can simply retry with a new socket (on a new local endpoint) if the NAT happened to refuse or drop a packet. > If so, the problem I see is that CGNs do not / can not / will not do > port preservation, as a few people already pointed out. Sure, regarding port preservation, on very busy CGNs it will surely not be granted all the time. But they are free to use the port allocation scheme they like. As you say, I assume a lot of CGNs won't support it. Port preservation should probably be an optional feature (especially for home NATs, that generally already have it). It is not necessarily related to port overloading. Port overloading, i feel, should probably be an optional feature too, since it is used in the wild and has limited impact on TCP Hole Punching. I'm not a NAT implementer though and thus my voice is not the most important here, as I see it as a NAT only feature that doesn't seriously affect p2p applications. Hope this helps clarifying the point. -- _Ivan Chollet_ From marka@isc.org Thu Jun 27 15:11:50 2013 Return-Path: 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 8671721F9DE3 for ; Thu, 27 Jun 2013 15:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 uJB259AHQha2 for ; Thu, 27 Jun 2013 15:11:46 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFD221F9DCE for ; Thu, 27 Jun 2013 15:11:46 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 22740C94B0; Thu, 27 Jun 2013 22:11:38 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372371106; bh=zrMLiLV903BcfOa7h+B/VGMt5BEX1CZp6Odo8M/TNJ8=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=M0qLIkoePJAYAHBqkCLi97dAn8p+SrN7zXb3s+/ZTM3m+TG2KL7g9y48FYoSgnodG qWuLRYOcj0XuCbqbCe+FBZjaZS1Bq3GkFcKvDxd1AsvFpdYUGA/B8oYpClGlBMNQt4 CwIcM5/f+wiiAkAyJc4wSfDkDnpNKuPbqYEKeh5Y= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 27 Jun 2013 22:11:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6D6E416004A; Thu, 27 Jun 2013 22:12:56 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 4ZXZqR1WVVxw; Thu, 27 Jun 2013 22:12:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1F6551600A4; Thu, 27 Jun 2013 22:12:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gNQlsWfjVphA; Thu, 27 Jun 2013 22:12:55 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id B0F8516004A; Thu, 27 Jun 2013 22:12:54 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 4FBF936609FC; Fri, 28 Jun 2013 08:11:33 +1000 (EST) To: Simon Perreault From: Mark Andrews References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <7f35bf30538732e3953bd33bcab7a791@cacaoweb.org> <51CC444C.1030507@viagenie.ca> <20130627141434.3B0BD365EA62@drugs.dv.isc.org> <51CC4A59.8080801@viagenie.ca> <20130627143612.51ECB365ED5A@drugs.dv.isc.org> <51CC50AE.2080909@viagenie.ca> In-reply-to: Your message of "Thu, 27 Jun 2013 16:48:14 +0200." <51CC50AE.2080909@viagenie.ca> Date: Fri, 28 Jun 2013 08:11:33 +1000 Message-Id: <20130627221133.4FBF936609FC@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: behave@ietf.org, ivan@cacaoweb.org Subject: Re: [BEHAVE] DNS vs port overloading X-BeenThere: behave@ietf.org 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, 27 Jun 2013 22:11:50 -0000 In message <51CC50AE.2080909@viagenie.ca>, Simon Perreault writes: > Le 2013-06-27 16:36, Mark Andrews a écrit : > >>> And overloading DNS could potentially defeat the port randomisation > >>> done by the server even though nameservers do port overloading > >>> themselves to send traffic out a large set of ports choosen at > >>> random and reselected from at random. > >> > >> Good point. > >> > >> Could that be solved with operational advice? In the case of CGN, we > >> could advise the ISP could to make sure that its recursive nameserver > >> sits on the border between the internal and external realm such that no > >> DNS traffic is handled by the CGN. > >> > >> Would that fully address your concern? > > > > No. Many ISP's have a history of mucking with DNS results when you > > use their servers. Most ISP's don't muck DNS queries not directed > > to their servers. For those that do you can usually see that they > > are mucking with results. > > > > You can't just redirect queries at a normal recursive server and > > think that will provide a "transparent DNS caching server". > > Right, but, port overloading is not what kills the randomization done by > the DNS client. Non-port preserving NAT is what kills it. Deterministic (e.g. sequential) port assignment kills it. Port overloading kills it if not done sensibly. > Non-port preserving NATs are already required to implement port > randomization according to: > > https://tools.ietf.org/html/rfc6056#section-4 > > Port overloading is not incompatible with port randomization. Maybe we > should explicitly write this and add a reference to RFC 6056? > > Simon -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ivan@cacaoweb.org Thu Jun 27 15:12:50 2013 Return-Path: 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 CE7CB21F8C66 for ; Thu, 27 Jun 2013 15:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 gFqddwgDyhK7 for ; Thu, 27 Jun 2013 15:12:45 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id A416121F9A50 for ; Thu, 27 Jun 2013 15:12:45 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1UsKRk-0006Jw-Q3; Fri, 28 Jun 2013 00:13:44 +0200 To: Simon Perreault X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Fri, 28 Jun 2013 00:13:44 +0200 From: ivan c Organization: cacaoweb In-Reply-To: <51CC2ED4.7090506@viagenie.ca> References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <88c0ada2b8ebad078fb249ac6572fd8b@cacaoweb.org> <51CBD188.4060408@viagenie.ca> <51CC2ED4.7090506@viagenie.ca> Message-ID: <8335eb535d5b47319b8c804c65490ecb@cacaoweb.org> X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Cc: behave@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 22:12:50 -0000 On Thu, 27 Jun 2013 14:23:48 +0200, Simon Perreault wrote: > > connect()ing UDP sockets has two big advantages: > > 1) It allows using the same programming model for UDP and TCP. More code > can be factored out, which is good software engineering. Usually applications use UDP and TCP differently and for different things, but that's an interesting point. > 2) It propagates ICMP errors up through the BSD API, allowing > straightforward error handling that is again similar to TCP and can be > factored out. For non-connected UDP sockets, ICMP errors are simply > ignored. All errors (including ICMP) are received for all UDP sockets. If you call select() on your sockets, the sockets with the errors will be select()-ed, and the subsequent recvfrom() call will return the error code. An ICMP message will trigger a ECONNRESET error I think. > Since file descriptors are basically free, come at no additional > performance cost when you use something like epoll, kqueue, or windows > IOCP, and since this method does not consume additional ports, I > recommend it over sendto()/recvfrom() when I teach network programming. > > This comes from W. Richard Stevens "UNIX Network Programming". The > technique is used a lot in the wild. I'm not inventing anything. -- _Ivan Chollet_ From dwing@cisco.com Thu Jun 27 18:04:28 2013 Return-Path: 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 F166221F9A8D for ; Thu, 27 Jun 2013 18:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 5wQ6sqEFWHZT for ; Thu, 27 Jun 2013 18:04:24 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 94B8C21F9AA2 for ; Thu, 27 Jun 2013 18:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=189; q=dns/txt; s=iport; t=1372381463; x=1373591063; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=L8EwidbiH1IwyU/9zOj9cz9NDzE2VCcKfvwE82iM+PM=; b=NtzePnowvjMcZGIrO7kR59zZ0N1NNrXdQZrjwT7ru6sRTnal7/uWFCBS EHVGF1IWfxXkj8QlR+U1mz69goEv5jgUoBILtAHb/cFkWaH/PtyYwFnQX 52O/8dQhl24Bgp4q+OAzpNGsCcmFEHTqrUoL88fMHkxbazmexdxt70syq g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEaAJzgzFGtJV2Y/2dsb2JhbABbgwkBMAG5CIZHBIEDFnSCZIF9iCEMmxWgMo5DhBtjA4kijiOBKYR4iySDMRw X-IronPort-AV: E=Sophos;i="4.87,955,1363132800"; d="scan'208";a="228414055" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 28 Jun 2013 01:04:21 +0000 Received: from [10.32.240.195] ([10.32.240.195]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5S14KM4030840 for ; Fri, 28 Jun 2013 01:04:20 GMT From: Dan Wing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <33118E39-0223-4162-9769-4217DA4329BB@cisco.com> Date: Thu, 27 Jun 2013 18:04:19 -0700 To: Behave Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [BEHAVE] 2 hours in Berlin X-BeenThere: behave@ietf.org 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, 28 Jun 2013 01:04:29 -0000 The preliminary agenda was published today and BEHAVE is on Friday = morning conflicting with httpbis, precis, dnssdext, clue, mpls, tls. http://tools.ietf.org/agenda/87/#FRIDAY -d From simon.perreault@viagenie.ca Fri Jun 28 05:01:44 2013 Return-Path: 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 1CA2C21F8493 for ; Fri, 28 Jun 2013 05:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 EtYC8oVOgjBb for ; Fri, 28 Jun 2013 05:01:38 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE8221F9CF3 for ; Fri, 28 Jun 2013 05:01:33 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9C4DE414F9; Fri, 28 Jun 2013 08:01:32 -0400 (EDT) Message-ID: <51CD7B1B.5050301@viagenie.ca> Date: Fri, 28 Jun 2013 14:01:31 +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 To: ivan@cacaoweb.org References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <88c0ada2b8ebad078fb249ac6572fd8b@cacaoweb.org> <51CBD188.4060408@viagenie.ca> <51CC2ED4.7090506@viagenie.ca> <4d2e082fd02ce46cd003631e8ca8eae9@cacaoweb.org> <014f01ce7341$e5416620$afc43260$@comcast.net> <51CC52AC.8010702@viagenie.ca> <4a641d08eccfd84d2882e32369ad8e61@cacaoweb.org> <51CC6144.3080000@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Behave 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 12:01:44 -0000 Le 2013-06-27 18:46, ivan c a écrit : >>> In this post: >>> http://www.ietf.org/mail-archive/web/behave/current/msg10896.html , I >>> explain (among other things), why the TCP Hole Punching Protocol is not >>> affected by the rare cases of collision due to port overloading. The >>> application simply retries with a new TCP socket (on a new local >>> endpoint). >> >> ...as long as the NAT does port preservation, right? >> > > No, I meant it in the general case with port overloading, with or without > TCP port preservation. > As you know, port overloading breaks the EIM requirement in the general > case. This is why port overloading is a MUST NOT in the existing RFCs. > But since collisions are supposed to be rare, p2p application can simply > retry with a new socket (on a new local endpoint) if the NAT happened to > refuse or drop a packet. I think I'm starting to understand your proposal. Correct me if I'm wrong: you're proposing that NATs should be allowed to do port overloading as long as their default behaviour is EIM. They would only do port overloading if they're running out of ports. Is that correct? That would solve the port scalability problem for busy NATs. Your argument is that this kind of NAT can still be easily traversed by P2P applications, correct? Now, the thing I don't understand is how. You say "p2p application can simply retry with a new socket (on a new local endpoint) if the NAT happened to refuse or drop a packet". - What packet gets dropped? - How does the application know? - How will using a new local endpoint result in no port overloading if the NAT is already busy enough that it has started overloading ports? >> If so, the problem I see is that CGNs do not / can not / will not do >> port preservation, as a few people already pointed out. > > Sure, regarding port preservation, on very busy CGNs it will surely not be > granted all the time. But they are free to use the port allocation scheme > they like. As you say, I assume a lot of CGNs won't support it. > Port preservation should probably be an optional feature (especially for > home NATs, that generally already have it). It is not necessarily related > to port overloading. Ok. Then it seems nothing needs to be said about port preservation, correct? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Fri Jun 28 05:03:13 2013 Return-Path: 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 5E8AD21F894E for ; Fri, 28 Jun 2013 05:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 H2J7-LJXnjJA for ; Fri, 28 Jun 2013 05:03:07 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6615221F9CF7 for ; Fri, 28 Jun 2013 05:03:07 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A8B5A4042D; Fri, 28 Jun 2013 08:03:06 -0400 (EDT) Message-ID: <51CD7B7A.8000604@viagenie.ca> Date: Fri, 28 Jun 2013 14:03:06 +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 To: Mark Andrews References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <7f35bf30538732e3953bd33bcab7a791@cacaoweb.org> <51CC444C.1030507@viagenie.ca> <20130627141434.3B0BD365EA62@drugs.dv.isc.org> <51CC4A59.8080801@viagenie.ca> <20130627143612.51ECB365ED5A@drugs.dv.isc.org> <51CC50AE.2080909@viagenie.ca> <20130627221133.4FBF936609FC@drugs.dv.isc.org> In-Reply-To: <20130627221133.4FBF936609FC@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: behave@ietf.org, ivan@cacaoweb.org Subject: Re: [BEHAVE] DNS vs port overloading X-BeenThere: behave@ietf.org 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, 28 Jun 2013 12:03:13 -0000 Le 2013-06-28 00:11, Mark Andrews a écrit : >> Right, but, port overloading is not what kills the randomization done by >> the DNS client. Non-port preserving NAT is what kills it. > > Deterministic (e.g. sequential) port assignment kills it. Port > overloading kills it if not done sensibly. Sure, but isn't all that already covered by RFC 6056? That is, does anything still need to be said about this? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Fri Jun 28 05:16:20 2013 Return-Path: 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 7CBF521F9CA9 for ; Fri, 28 Jun 2013 05:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 u-BHw2cWGgQS for ; Fri, 28 Jun 2013 05:16:13 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id B7E2721F9C9B for ; Fri, 28 Jun 2013 05:16:12 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C89FA4040A; Fri, 28 Jun 2013 08:16:03 -0400 (EDT) Message-ID: <51CD7E83.6070503@viagenie.ca> Date: Fri, 28 Jun 2013 14:16:03 +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 To: ivan@cacaoweb.org References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <88c0ada2b8ebad078fb249ac6572fd8b@cacaoweb.org> <51CBD188.4060408@viagenie.ca> <51CC2ED4.7090506@viagenie.ca> <8335eb535d5b47319b8c804c65490ecb@cacaoweb.org> In-Reply-To: <8335eb535d5b47319b8c804c65490ecb@cacaoweb.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: behave@ietf.org Subject: [BEHAVE] UDP socket programming X-BeenThere: behave@ietf.org 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, 28 Jun 2013 12:16:20 -0000 Le 2013-06-28 00:13, ivan c a écrit : >> 2) It propagates ICMP errors up through the BSD API, allowing >> straightforward error handling that is again similar to TCP and can be >> factored out. For non-connected UDP sockets, ICMP errors are simply >> ignored. > > All errors (including ICMP) are received for all UDP sockets. > If you call select() on your sockets, the sockets with the errors will be > select()-ed, and the subsequent recvfrom() call will return the error code. > An ICMP message will trigger a ECONNRESET error I think. ...on Linux. Not on BSD. Don't know about Windows. W. Richard Stevens says: "Asynchronous errors are returned to the process for connected UDP sockets. The corollary, as we previously described, is that unconnected UDP sockets do not receive asynchronous errors." Also: "Linux returns most ICMP "destination unreachable" errors even for unconnected sockets, as long as the SO_BSDCOMPAT socket option is not enabled. All the ICMP "destination unreachable" errors from Figure A.15 are returned, except codes 0, 1, 4, 5, 11, and 12." Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From ssenthil@cisco.com Fri Jun 28 10:45:17 2013 Return-Path: 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 7C0C321F9C29 for ; Fri, 28 Jun 2013 10:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 xrtXgdgl5uRZ for ; Fri, 28 Jun 2013 10:45:12 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5495C21F9C26 for ; Fri, 28 Jun 2013 10:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14334; q=dns/txt; s=iport; t=1372441512; x=1373651112; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=tJzgjsOEPrtB6vm9s3a9q8mkiEj0Q2Ywg/eZTmRw1ds=; b=RYfrmxQS1ain6J1wxuOrmdD9kCnm49Z3JcE7Q+XnObeGCAbpg9GsHaU4 v2rXNLv0d0NBbmwDdSbFtpibr+A4hQwPyxzs/j8BrekVRIuc/QjOnTDcA ImSzUEkWZnhKXX8agMw6LddWQHyXSUYJAPoBUn4la15i5Q9YWvPstphb5 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFALHKzVGtJV2a/2dsb2JhbABRCoMJMkm/BoEKFnSCIwEBAQMBAQEBJEAHCxIBCBgKRQYLJQIEAQ0FCId1AwkGDLMiDYhOBIxugSQIBAEHfzEHgwRjA4hqjHSOB4UlgxGBaAEfIA X-IronPort-AV: E=Sophos;i="4.87,960,1363132800"; d="scan'208";a="228729176" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 28 Jun 2013 17:45:11 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5SHjBWJ023123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Jun 2013 17:45:11 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.94]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 12:45:10 -0500 From: "Senthil Sivakumar (ssenthil)" To: "Dan Wing (dwing)" , Tom Taylor Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-syslog-nat-logging-01.txt Thread-Index: AQHOTAMfYLBmigMp3EWmDtOmMJ6JaJj7xMiAgBOD44CAPH6HAA== Date: Fri, 28 Jun 2013 17:45:10 +0000 Message-ID: In-Reply-To: <6ACBECAC-F476-4947-8F02-FC267403219C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.117.198.132] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <159AC3FDAEB289498974EAF57A690388@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-syslog-nat-logging-01.txt X-BeenThere: behave@ietf.org 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, 28 Jun 2013 17:45:17 -0000 Sorry for the long delay in responding.. Please see inline. On 5/20/13 9:56 PM, "Dan Wing (dwing)" wrote: >Thanks for writing this document. > >My personal review, not as chair, > >Section 2.1 seems to be trying to distinguish between mechanisms that are >dynamic and those that are static. Static are DS-Lite with >[I-D.tsou-behave-natx4-log-reduction] and [I-D.pcp-port-set], MAP-E, and >lightweight 4over6. Dynamic is dynamic. Then there is the combination, >which is popularly described in draft-donley-behave-deterministic-cgn. I >would suggest separate sections explaining these three things, and more >concisely. Also, Section 2.1 is titled "NAT Logging Requirements For >Different Transition Methods" and has 3 paragraphs describing MAP-E, >which does not do network address translation in the ISP's network; a >different title for the section that discusses MAP-E seems useful. >Afterall, with MAP-E the NAT function occurs in the customer premise NAT, >which is not going to generate logging messages. It seems Section 2 >might be something we would want common between the SYSLOG and IPFIX >documents, perhaps? Do you think those would have to be repeated or one document just refers to the other. I prefer the later approach. > >I noticed the non-normative "Note:" regarding Gateway-Initiated DS-Lite >underneath Figure 1. Can that be moved to somewhere else so it is more >normative? (It looks like a centered ). Perhaps it should be >explained in Section 2.1, rather than here. This is specific to syslog. So I am going to let the syslog authors address this. > >In Figure 1, can the user identifier be generalized a bit? There are >lots of NATs which use interface identifiers (e.g., en0, en1, en2), VLAN >IDs, VRFs, to separate the inside addresses -- rather than using the >fields shown here in Figure 1. This seems to have happened in Section >3.1 (which shows VLAN ID and VRFs) but the table does not appear to allow >that sort of flexibility. This is specific to syslog. So I am going to let the syslog authors address this. > > >Section 3.1, > "NAT session creation and deletion events are recorded when a binding > to a specific destination address and port is recorded in or deleted > from the session database. See the discussion in Section 3 of > [RFC6146]." > >That does not align with the endpoint-independent mapping described in >Section 3 of RFC6146. That is, a 'creation' event does not occur with >every new destination address. > >I found Section 3.1 really difficult to understand what is generated for >a TCP/UDP mapping, versus what is supposed to be generated for an ICMP >mapping. =20 > >" o Destination IPv4 (for NAT44) or IPv6 (for NAT64) address > (OPTIONAL);" > >A NAT64 would have an IPv4 destination address. Note this is for >*destination logging*, which needs its own discussion beyond just >"(OPTIONAL)" and beyond the citation that RFC6888 recommends against >destination logging. There are implementation issues with destination >logging (state creation in the logging device to avoid generating a log >event with every packet), and it deserves mentioning in a logging >document that destination logging more than destroys the log reduction >benefit of bulk port assignment. Agree, I will add a paragraph on the destination logging and its effects. > > >" o Post-NAT destination IPv4 address (OPTIONAL);" > >Seems redundant with the preceding item. > >"The pre-NAT value of destination > address will differ from the post-NAT value only in a double-NAT > situation. Hence in most cases even with destination logging the > pre-NAT value will not be recorded." > >I don't understand what that means. Please make it clearer in the >document. This is the first and only time the term "double-NAT" appears >in the document, which might be part of my confusion. Seems specific to syslog document. > > >Section 3.4 says: "The same allocation applies to each protocol supported >by the NAT." -> but you really only mean UDP and TCP, even though the NAT >supports ICMP (which doesn't use ports) or even if it were to support >SCTP (which does not expect NAPT devices to rewrite port numbers). So, >please say "The same ports are allocated for TCP and UDP." > >Section 3.4, why are the starting and ending port numbers optional, can >this work? =20 > >Section 3.4, the Port Range Size and Range Step are too complicated. Are I guess your words are truncated here. There has been some interest on having non-contiguous ports. It has been established that this doesn=B9t provide any added security, but it isnt as complex as you think it is to implement. There are implementations that uses a range and step size. >=20 > >Section 3.4 needs to explain if the same single logging event will be >generated when ports are deleted, or if they are consolidated. For >example, let's say ports 100-200 are allocated to a subscriber and a >logging event generated, then ports 200-250 are (later) allocated to the >same subscriber and a logging event generated. Will that second logging >event indicate ports 100-250? (I could see someone reasonably >implementing that). Would two separate deletion log events be generated, >one deletion for 100-200, and another deletion for 201-250? Or would >only one log deletion event be generated? All of these corner cases need >discussion with some rules for how this is expected to work. This could >perhaps be left to implementation decision, but if that is the decision >it should clearly say. I think it is clearly an implementation choice. But I agree, we should have some text explaining some possible options and leave it to the implementation. > >General comment for all of sections 3.5, 3.6, and 3.7: Can a SYSLOG >message be generated *before* we hit a limit? It seems there is no >highwater mark for any of those. I expect operators would prefer knowing >before hitting a limit and also when hitting a limit (because users will >notice the hard failure when a limit is hit). Thoughts? Interesting thought. I have always thought that logging is more useful in case of post mortem, to understand what happened and when. And MIB is used as a proactive monitoring tool. We have added the threshold values in the new mib for the address and pool exhaustion, this would serve as an alarm/trap.=20 > >"3.5. NAT Address Exhaustion Event", is there expected to be anything to >prevent this event from being continually generated? Because, if the NAT >is running near its limit and hits it, it will likely have a port >released, then one allocated (hitting the limit again), over and over >again. Same question for Section 3.4 (port exhaustion). And, are both >events generated when the final port is allocated (seems like both would >be generated). =20 These events should be rate limited. It shouldn=B9t be generated on a per-packet basis. In our current implementation, we generate an event when we first hit the limit, and then either periodically, every n secs if there are packets still getting dropped because of the lack of resources OR when some ports were released back into the pool and exhausted again. I am pretty sure there are other ways to implement this rate limiting but I think adding some text around this would be helpful to the implementors. I will do this in the ipfix document. > >Section 3.7, Quota exhausted -- for the (per-user) quota a citation to >REQ-11 of RFC6888 would be helpful. I found the paragraph describing >which fields are mandatory for which sort of quota difficult to >understand. I played around with a table (which did not help clarity) >and some alternative wording. But I couldn't improve the text much, >because I don't really know what fields are best to send for the >different sort of events. This feels very free-form and a cause of >interoperability problems with the various ways a NAT or the SYSLOG >parsing code would interpret the presence of certain fields. For >example, does the lack of a subscriber-identifying address mean that a >non-subscriber-specific administrative limit was hit? It seems that is >the case, which is okay, but more explicit explanation could be helpful. >Or creating separate events like was done with 3.5 and 3.6 > >=09 >Section 5.2.1, "NTyp: NAT Type" where it mentions NAT44 it should cite >the canonical NAPT44 definition in RFC3022. For NAT64, probably want to >reference both stateful NAT64 (RFC6146) and stateless (RFC6145). > >5.2.5. PreS4: Pre-NAT IPv4 Source Address > > PARAM-VALUE: part or all of an IPv4 address, represented in dotted > decimal form. > >Why provide only part of the IPv4 address? For on-the-wire efficiency? >If some of the address is omitted, is it the first NNN bits that are >omitted, or the last NNN bits that are omitted. I would omit the first >NNN bits if all the internal addresses shared those same NNN bits (e.g., >all were 100.64/10, I could omit the first 10 bits). I would omit the >last NNN bits if assigning a /24 to a subscriber and I don't care which >of their devices caused the NAT event. > >5.2.6. PreS6: Pre-NAT IPv6 Source Address: "PARAM-VALUE: Part or all >of an IPv6 address, represented in the form specified by [ >RFC5952]." > >Same question -- the first part or the last part of the address? Most >subscribers are assigned a /64, so reporting the full 128 bit address is >awkward, I agree. But, similarly, most of an ISP's network will use the >same IPv6 prefix so reporting the first 8 or 24 bits is redundant. The >document needs to clarify. > >And as this is string-encoded, what rules should be followed for "::", as >that has changed in the last couple of years and would be good to cite. All of the above three comments are specific to Syslog, hence ignoring. > >In IANA considerations a new IANA registry is created. This needs to >additionally provide guidance for how that new registry can be extended >in teh future, and a few other things. RFC5226 has details. IPFIX registry is already in place and is being used by people to add new fields. > >Security considerations: > >" When logs are being recorded for regulatory reasons, preservation of > their integrity and authentication of their origin is essential." > >The accuracy and unambiguity of the information is important, as well. >To that point, the address compression has me concerned and address >compression needs more text in the document, and may deserve calling out >explicitly in the security considerations section. Also worth pointing >out is the address ranges and "step range" (whatever that is) might be >changed while the NAT is operating -- which impacts almost everything >reported to the SYSLOG server. Seems useful to add NAT Configuration >Changed events when such things occur? > >In security considerations, missing messages are not mentioned. They >should be. Would it be worthwhile to include a sequence number (which >does not appear to be part of the SYSLOG header, nor of the messages >defined in this spec.) Thanks for the review, let me know if there is anything specific to IPFIX that I have missed to respond in this review. Senthil > >-d > >=20 >On May 8, 2013, at 8:55 AM, Tom Taylor wrote: > >> Done at last. The updated document has two new sections: >>=20 >> 2. Deployment Considerations >> - discusses the logging implications of the various Softwires >> transition methods, as well some considerations arising out >> of the architectural role of the NAT. >>=20 >> 3. NAT-Related Events and Parameters >> - is a description at a generally coding-independent level of >> the events to be logged at NATs and their associated parameters. >> In principle the contents are the same as in the IPFIX >> document, but some reconciliation may be required. >>=20 >> These sections are followed by SYSLOG-specific stuff: applicability >>statement, parameter and event encoding (with lots examples of complete >>logs), and an extensive IANA section. Then the usual remaining sections. >>=20 >> Comments are welcome. Fire away. >>=20 >> Tom Taylor >>=20 >> On 08/05/2013 11:44 AM, internet-drafts@ietf.org wrote: >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >>>directories. >>> This draft is a work item of the Behavior Engineering for Hindrance >>>Avoidance Working Group of the IETF. >>>=20 >>> Title : Syslog Format for NAT Logging >>> Author(s) : Zhonghua Chen >>> Cathy Zhou >>> Tina Tsou >>> T. Taylor >>> Filename : draft-ietf-behave-syslog-nat-logging-01.txt >>> Pages : 31 >>> Date : 2013-05-08 >>>=20 >>> Abstract: >>> With the wide deployment of Carrier Grade NAT (CGN) devices, the >>> logging of NAT-related events has become very important for legal >>> purposes. The logs may be required to identify a host that was used >>> to launch malicious attacks or engage in illegal behaviour, and/or >>> may be required for accounting purposes. This document identifies >>> the events that need to be logged and the parameters that are >>> required in the logs depending on the context in which the NAT is >>> being used. It goes on to standardize formats for reporting these >>> events and parameters using SYSLOG (RFC 5424). A companion document >>> specifies formats for reporting the same events and parameters using >>> IPFIX (RFC 5101). Applicability statements are provided in this >>> document and its companion to guide operators and implementors in >>> their choice of which technology to use for logging. >>>=20 >> ... >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From tom.taylor.stds@gmail.com Sun Jun 30 08:17:07 2013 Return-Path: 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 7675521F9B64 for ; Sun, 30 Jun 2013 08:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Gaq3ijg88Uun for ; Sun, 30 Jun 2013 08:17:06 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A5AA621F9B58 for ; Sun, 30 Jun 2013 08:17:06 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id qd12so7386547ieb.2 for ; Sun, 30 Jun 2013 08:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=2UN7qvGGbZttNeWlxTUGxFX9FOjA8WxnENJ3ag+Ok/o=; b=CJHfKc7kgny/3yUdlTFl3BFNpY6oKNrmIDdZBTl7W3ctY0xKF5Sz9tQW9+LxD/c/fl H109KuidzIiX1uYZUyYl6QarZGuRRMkgaVytkd6ywzHKk8fqf2xyZsdRJN7zRt1XasB8 17X1PUrgu8cMe3/JbhlYnopDYCromvaVBFsmtGpx9xnPnG7+zQ37pjvXndmE/MDd8J/b Osf1RIt1aTxh7B1EARm/Bu0VahdfV9MwIkdmKYI/Dmeh5bN/dF6QxxgLQsFc3YeUdwEv egGl6SYcWTj32d9qLiIy/NRD10y8k/ZRA0pyI8iu3SS3ZO05fAi9QzHJbd9d5yD9me7a i70w== X-Received: by 10.50.114.229 with SMTP id jj5mr11647846igb.36.1372605424606; Sun, 30 Jun 2013 08:17:04 -0700 (PDT) Received: from [192.168.1.64] ([216.254.161.150]) by mx.google.com with ESMTPSA id n5sm8694493igv.5.2013.06.30.08.17.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 30 Jun 2013 08:17:03 -0700 (PDT) Message-ID: <51D04BEF.60206@gmail.com> Date: Sun, 30 Jun 2013 11:17:03 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Dan Wing References: <20130508154447.24024.36769.idtracker@ietfa.amsl.com> <518A757F.5000701@gmail.com> <6ACBECAC-F476-4947-8F02-FC267403219C@cisco.com> In-Reply-To: <6ACBECAC-F476-4947-8F02-FC267403219C@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-syslog-nat-logging-01.txt X-BeenThere: behave@ietf.org 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: Sun, 30 Jun 2013 15:17:07 -0000 Thanks again for the time you put into this. Sorry I took so long to get back to you. On 20/05/2013 9:56 PM, Dan Wing wrote: > Thanks for writing this document. > > My personal review, not as chair, > > Section 2.1 seems to be trying to distinguish between mechanisms that > are dynamic and those that are static. Static are DS-Lite with > [I-D.tsou-behave-natx4-log-reduction] and [I-D.pcp-port-set], MAP-E, > and lightweight 4over6. Dynamic is dynamic. Then there is the > combination, which is popularly described in > draft-donley-behave-deterministic-cgn. I would suggest separate > sections explaining these three things, and more concisely. Also, > Section 2.1 is titled "NAT Logging Requirements For Different > Transition Methods" and has 3 paragraphs describing MAP-E, which does > not do network address translation in the ISP's network; a different > title for the section that discusses MAP-E seems useful. Afterall, > with MAP-E the NAT function occurs in the customer premise NAT, which > is not going to generate logging messages. It seems Section 2 might > be something we would want common between the SYSLOG and IPFIX > documents, perhaps? [PTT] I receive your suggestions with enthusiasm. I had a problem with logs that would be generated during provisioning rather than dynamically, and drew an arbitrary line that said provisioning-time logs would be out of scope of this draft. By sorting things out as you suggest, I have a neat framework for specifying the log requirements in each case. The Donley draft has a section on the topic to which we can refer. > > I noticed the non-normative "Note:" regarding Gateway-Initiated > DS-Lite underneath Figure 1. Can that be moved to somewhere else so > it is more normative? (It looks like a centered ). > Perhaps it should be explained in Section 2.1, rather than here. [PTT] OK, the note was really to open the question of whether we should deal with the case of GW-initiated DS-Lite. I'll take it from your comment that we should. BTW I don't see why this is a SYSLOG-specific matter, as Senthil suggested. > > In Figure 1, can the user identifier be generalized a bit? There are > lots of NATs which use interface identifiers (e.g., en0, en1, en2), > VLAN IDs, VRFs, to separate the inside addresses -- rather than using > the fields shown here in Figure 1. This seems to have happened in > Section 3.1 (which shows VLAN ID and VRFs) but the table does not > appear to allow that sort of flexibility. > [PTT] Will do. Are interface identifiers, VLAN IDs and VRFs an exhaustive list or should we provide for arbitrary strings including type identification (opaque to the logging system)? > > Section 3.1, "NAT session creation and deletion events are recorded > when a binding to a specific destination address and port is recorded > in or deleted from the session database. See the discussion in > Section 3 of [RFC6146]." > > That does not align with the endpoint-independent mapping described > in Section 3 of RFC6146. That is, a 'creation' event does not occur > with every new destination address. > > I found Section 3.1 really difficult to understand what is generated > for a TCP/UDP mapping, versus what is supposed to be generated for an > ICMP mapping. > [PTT] I think Senthil and I have to sort out a few details in Sections 3.1 to 3.3. > " o Destination IPv4 (for NAT44) or IPv6 (for NAT64) address > (OPTIONAL);" > > A NAT64 would have an IPv4 destination address. Note this is for > *destination logging*, which needs its own discussion beyond just > "(OPTIONAL)" and beyond the citation that RFC6888 recommends against > destination logging. There are implementation issues with > destination logging (state creation in the logging device to avoid > generating a log event with every packet), and it deserves mentioning > in a logging document that destination logging more than destroys the > log reduction benefit of bulk port assignment. > [PTT] OK > > " o Post-NAT destination IPv4 address (OPTIONAL);" > > Seems redundant with the preceding item. > > "The pre-NAT value of destination address will differ from the > post-NAT value only in a double-NAT situation. Hence in most cases > even with destination logging the pre-NAT value will not be > recorded." > > I don't understand what that means. Please make it clearer in the > document. This is the first and only time the term "double-NAT" > appears in the document, which might be part of my confusion. > [PTT] I ran into this when doing the Midcom semantics. Basically the problem occurs when you map from one private space to another, or when hairpinning. ... [PTT] I'll respond to the rest of your remarks later.