From shara-bounces@ietf.org Mon Feb 2 16:11:34 2009 Return-Path: X-Original-To: shara-archive@ietf.org Delivered-To: ietfarch-shara-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A24F3A6B1B; Mon, 2 Feb 2009 16:11:34 -0800 (PST) X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD52A3A6975 for ; Mon, 2 Feb 2009 16:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBwsQjnjHTHF for ; Mon, 2 Feb 2009 16:11:31 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id A9E923A6B1B for ; Mon, 2 Feb 2009 16:11:28 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n130ABDX022949 for ; Mon, 2 Feb 2009 18:11:07 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Feb 2009 02:10:59 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Feb 2009 02:10:54 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 3 Feb 2009 01:10:53 +0100 From: To: Date: Tue, 3 Feb 2009 01:10:51 +0100 Thread-Topic: proposed update for SHARA BOF charter text Thread-Index: AcmFk9/erKv3Zl7JTKmWi+LF5ne+3g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 03 Feb 2009 00:10:54.0622 (UTC) FILETIME=[E17863E0:01C98593] X-Nokia-AV: Clean Subject: [shara] proposed update for SHARA BOF charter text X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: shara-bounces@ietf.org Errors-To: shara-bounces@ietf.org I have updated the charter text for the BOF proposal taking into account the comments received so far on the mailing list. I intend to upload the text to wiki within a day or so. Comments are welcome. - Gabor Sharing IPv4 Addresses (SHARA) BOF proposal: ------------------------------------------------------- Background and Motivation: ------------------------- When IPv6 was designed, the assumption was that the transition from IPv4 to IPv6 will occur way before the exhaustion of the available IPv4 address pool. The unexpected growth of the IPv4 Internet and the hesitation and technical difficulties to deploy IPv6 indicates that the transition may take much longer than originally anticipated. It is expected that communication using IPv6 addresses will increase during the next few years to come at the expense of communication using IPv4 addresses. We should reach a safety point in the future, where the number of IPv4 public addresses in use at a given time begins decreasing. It is very likely that the IPv4 public address pool currently available at IANA will be exhausted before the internet reaches this safety point. This creates a need to prolong the lifetime of the available IPv4 addresses. While IPv6 is the long-term solution, IPv4 connectivity needs to be provided for hosts and applications unable to utilize IPv6 and/or require NATless IPv4 connectivity. This can happen for example when: * a host is provided with IPv6 only connectivity by access network, but it is running (legacy) applications requiring NATless IPv4 connectivity * a distribution of NAT to edges instead of core is desired e.g. for better end-user control of NAT or for distribution of NAT function In IETF multiple IPv6 transition solutions have been and are being worked on, including protocol translation that is worked on behave WG and Dual-Stack Lite that is worked on softwire WG. This BOF proposes new work on: * defining complementary, _not competing_, transition mechanism based on shared IPv4 addresses * documenting the deployment scenarios where usage of such addresses is envisioned and beneficial over other solutions being standardized * defining protocols for assigning and routing shared IPv4 addresses * documenting the benefits, drawbacks, dangers of using shared IPv4 addresses Prior activity: -------------- IPv6 transition mechanisms have a long history. Port-restricted IPv4 addresses as a solution approach have been discussed during 2008 at least in IETF#72, IETF#73, and to lesser extent in v4v6 interim meeting held in Montreal: IETF#73 * Softwires WG: https://www.ietf.org/proceedings/08nov/index.html * Behave WG: https://www.ietf.org/proceedings/08nov/index.html IPv4-IPv6 Co-Existence Interim * http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim IETF#72 * intarea: https://www.ietf.org/proceedings/08jul/index.html * v6ops: https://www.ietf.org/proceedings/08jul/index.html Proposed Work: ------------- The proposed SHARA working group will focus on following topics relevant for shared IPv4 addresses: * Problem statement and requirements document: a document describing the problems caused by IPv4 address shortage and why sharing IPv4 addresses could be a solution for the problem; what requirements solutions using shared IP addresses need to fulfill * Document as many of the issues that shared IPv4 addresses create that can be identified by the community (e.g. blind attacks, ICMP handling, fragmentation, routing, tunneling, etc), develop solutions where possible; describe drawbacks and consequences. Analyze the behaviour of legacy applications that have some IPv4 NAT traversal capabilities, determine under what circumstances they could still work with shared IPv4 addresses. * Deployment scenarios: describe deployment scenarios where shared IPv4 addresses are applicable (e.g. point-to-point physical links, distributing Carrier Grade NAT, integration with Dual-Stack Lite, IP mobility protocols etc) * Shared address assignment: describe mechanisms for assigning shared IPv4 addresses for hosts The BoF proposes to discuss the above items and gauge interest in forming a working Group. There is already work in progress addressing some of the identified problems, which is expected to be the starting point for the deliverables: * http://tools.ietf.org/internet-drafts/draft-levis-behave-ipv4-shortage-framework * http://tools.ietf.org/html/draft-ymbk-aplusp * http://tools.ietf.org/html/draft-boucadair-port-range * http://tools.ietf.org/html/draft-bajko-v6ops-port-restricted-ipaddr-assign * http://tools.ietf.org/html/draft-boucadair-dhc-port-range * http://tools.ietf.org/html/draft-boucadair-behave-bittorrent-portrange * http://tools.ietf.org/html/draft-arkko-townsley-coexistence * http://tools.ietf.org/html/draft-despres-sam Approximate Timeline for Deliverables: ------------------------------------- * April 2009 WG approved by IESG * 2H09 Submit problem statement I-D to IESG * 1H10 Submit address assignment I-D to IESG * 2H10 Submit deployment scenarios I-D to IESG * 2H10 Recharter or close WG _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara From Gabor.Bajko@nokia.com Tue Feb 3 17:45:22 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8C033A6809 for ; Tue, 3 Feb 2009 17:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AW2s+ZZ9r2B8 for ; Tue, 3 Feb 2009 17:45:22 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 0A54E3A63D3 for ; Tue, 3 Feb 2009 17:45:21 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n141iuWZ014895 for ; Tue, 3 Feb 2009 19:45:00 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Feb 2009 03:44:58 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Feb 2009 03:44:53 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Feb 2009 03:44:47 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 4 Feb 2009 02:44:44 +0100 From: To: Date: Wed, 4 Feb 2009 02:44:42 +0100 Thread-Topic: SHARA BOF WIKI page updated Thread-Index: AcmFk9/erKv3Zl7JTKmWi+LF5ne+3gA1jBbA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Feb 2009 01:44:47.0332 (UTC) FILETIME=[293D7A40:01C9866A] X-Nokia-AV: Clean Subject: [shara] SHARA BOF WIKI page updated X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 01:45:22 -0000 http://trac.tools.ietf.org/bof/trac/wiki/WikiStart?version=3D330#Transport From teemu.savolainen@nokia.com Thu Feb 5 01:06:00 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0523E3A6B64; Thu, 5 Feb 2009 01:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNTKb82qhB1w; Thu, 5 Feb 2009 01:05:59 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 053F53A6B60; Thu, 5 Feb 2009 01:05:57 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1595UHc000553; Thu, 5 Feb 2009 03:05:34 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Feb 2009 11:05:26 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Feb 2009 11:05:17 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Thu, 5 Feb 2009 10:05:16 +0100 From: To: , Date: Thu, 5 Feb 2009 10:04:51 +0100 Thread-Topic: [BEHAVE] Pref64 nature and referral support. Thread-Index: Acl+C9z3lfmfsF4ARSGkar+Hi6JnMwJYhfUA Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F27E86EA1AE@NOK-EUMSG-01.mgdnok.nokia.com> References: <4975B691.2040009@it.uc3m.es><21AC353A-5C47-48CC-A02B-6AB425543E00@muada.com> <4977E563.5060202@gmail.com> <04fe01c97d87$5cac4320$c2f0200a@cisco.com> <497A0FB7.4030903@it.uc3m.es> <055801c97d92$133b4b40$c2f0200a@cisco.com> <497A3AA7.5000205@gmail.com> <497AE857.8040701@free.fr> In-Reply-To: <497AE857.8040701@free.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Feb 2009 09:05:17.0278 (UTC) FILETIME=[DD20EFE0:01C98770] X-Nokia-AV: Clean Cc: behave@ietf.org, shara@ietf.org, dwing@cisco.com Subject: Re: [shara] [BEHAVE] Pref64 nature and referral support. X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 09:06:00 -0000 Inline, >-----Original Message----- >From: ext R=E9mi Despr=E9s [mailto:remi.despres@free.fr] >Sent: 24 January, 2009 12:07 >To: Brian E Carpenter >Cc: Dan Wing; 'Behave WG'; Savolainen Teemu (Nokia-D-MSW/Tampere) >Subject: Re: [BEHAVE] Pref64 nature and referral support. > >>> As chair, I would certainly like to see documents that detail such >>> proposals. A discussion of the trade-offs and benefits would be >>> valuable. >To my knowledge, and for example, Teemu Savolainen ran a test >in August 2008. It showed that a Google map use involved 4 >server addresses in parallel. With port dependent mapping on >port 80, the number of needed client ports would have been >divided by 4 . Correct. To be more exact, one test showed burst of 8 SYNs: - TCP SYN to 74.125.77.136:80 (local port 1380) =3D> requires new local por= t reservation 1 - TCP SYN to 74.125.77.136:80 (local port 1381) =3D> requires new local por= t reservation 2 - TCP SYN to 74.125.77.93:80 (local port 1382) =3D> could have shared exist= ing local port '1' - TCP SYN to 74.125.77.93:80 (local port 1383) =3D> could have shared exist= ing local port '2' - TCP SYN to 74.125.77.91:80 (local port 1384) =3D> could have shared exist= ing local port '1' - TCP SYN to 74.125.77.91:80 (local port 1385) =3D> could have shared exist= ing local port '2' - TCP SYN to 74.125.77.190:80 (local port 1386) =3D> could have shared exis= ting local port '1' - TCP SYN to 74.125.77.190:80 (local port 1387) =3D> could have shared exis= ting local port '2' I.e. 8 different TCP sessions could have been multiplexed into 2 local port= s. And another test showed burst of 16 SYNs: - TCP SYN to 74.125.77.93:80 (local port 1906) =3D> requires new local port= reservation 1 - TCP SYN to 74.125.77.136:80 (local port 1907) =3D> could have shared exis= ting local port '1' - TCP SYN to 74.125.77.91:80 (local port 1908) =3D> could have shared exist= ing local port '1' - TCP SYN to 74.125.77.91:80 (local port 1909) =3D> requires new local port= reservation 2 - TCP SYN to 74.125.77.190:80 (local port 1910) =3D> could have shared exis= ting local port '1' - TCP SYN to 74.125.77.190:80 (local port 1911) =3D> could have shared exis= ting local port '2' - TCP SYN to 74.125.77.190:80 (local port 1912) =3D> requires new local por= t reservation 3 - TCP SYN to 74.125.77.136:80 (local port 1913) =3D> could have shared exis= ting local port '2' - TCP SYN to 74.125.77.136:80 (local port 1914) =3D> could have shared exis= ting local port '3' - TCP SYN to 74.125.77.93:80 (local port 1915) =3D> could have shared exist= ing local port '2' - TCP SYN to 74.125.77.91:80 (local port 1916) =3D> could have shared exist= ing local port '3' - TCP SYN to 74.125.77.93:80 (local port 1917) =3D> could have shared exist= ing local port '3' - TCP SYN to 74.125.77.93:80 (local port 1918) =3D> requires new local port= reservation 4 - TCP SYN to 74.125.77.136:80 (local port 1919) =3D> could have shared exis= ting local port '4' - TCP SYN to 74.125.77.91:80 (local port 1920) =3D> could have shared exist= ing local port '4' - TCP SYN to 74.125.77.190:80 (local port 1921) > could have shared existin= g local port '4' For me it looked like there could have been possibility for 75% local port = savings in these two scenarios. Of course if the destination server is having just one IP address, these ki= nds of savings would not be possible for such applications utilizing multip= le parallel transport sessions. Maybe these kinds of applications should be= hosted by servers with multiple IP addresses (even if all configured for s= ame interface)? What comes to hosts possibly having port restricted IP address allocated to= themselves, it would seem they should utilize address dependent mapping (w= hen applications are utilizing implicit source port bindings) to save ports= in these kinds of use-cases (also in the case where the host implements in= ternal NAT (for serving non-port-restricted IPv4 address compatible applica= tions)). Best regards, Teemu From mohamed.boucadair@orange-ftgroup.com Thu Feb 5 06:09:26 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99FBD3A6AFD; Thu, 5 Feb 2009 06:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8BdtHctvIA1; Thu, 5 Feb 2009 06:09:21 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 4436A3A6A93; Thu, 5 Feb 2009 06:09:21 -0800 (PST) Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Feb 2009 15:09:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9879B.4ABFD090" Date: Thu, 5 Feb 2009 15:08:59 +0100 Message-ID: <6CF039C5B32037498B02251E11CDE6B007BB7096@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-boucadair-pppext-portrange-option-00.txt Thread-Index: AcmHmiHQQHeVCnr9Sg+q3yOEBZEYnAAAQO6A From: To: , X-OriginalArrivalTime: 05 Feb 2009 14:09:02.0733 (UTC) FILETIME=[4C58ABD0:01C9879B] Subject: [shara] TR: I-D Action:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 14:09:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9879B.4ABFD090 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 FYI. A new ID has been submitted to IETF. This draft specifies new PPP = IPCP options to be used in the context of Port Range solutions. Comments are more than welcome. Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] De la part de = Internet-Drafts@ietf.org Envoy=E9 : jeudi 5 f=E9vrier 2009 15:00 =C0 : i-d-announce@ietf.org Objet : I-D Action:draft-boucadair-pppext-portrange-option-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Port Range Configuration Options for PPP IPCP Author(s) : M. Boucadair, et al. Filename : draft-boucadair-pppext-portrange-option-00.txt Pages : 13 Date : 2009-02-05 This memo defines two IPCP (IP Configuration Protocol, [RFC1332]) = Options to be used in the context of Port Range solutions. IPCP is the = configuration protocol used when PPP (Point-to-Point Protocol, [RFC1548]) is deployed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boucadair-pppext-portrange-opti= on-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader = implementation to automatically retrieve the ASCII version of the = Internet-Draft. ------_=_NextPart_001_01C9879B.4ABFD090 Content-Type: application/octet-stream; name="draft-boucadair-pppext-portrange-option-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-boucadair-pppext-portrange-option-00.URL Content-Disposition: attachment; filename="draft-boucadair-pppext-portrange-option-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1ib3VjYWRhaXItcHBwZXh0LXBvcnRyYW5nZS1vcHRpb24tMDAudHh0DQo= ------_=_NextPart_001_01C9879B.4ABFD090-- From dwing@cisco.com Thu Feb 5 15:29:09 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82C9E3A6916; Thu, 5 Feb 2009 15:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVikh0Bp6ZGv; Thu, 5 Feb 2009 15:29:08 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id AC6E23A67D1; Thu, 5 Feb 2009 15:29:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,388,1231113600"; d="scan'208";a="138550724" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 05 Feb 2009 23:29:10 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n15NTA2k004041; Thu, 5 Feb 2009 15:29:10 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n15NT9OS015226; Thu, 5 Feb 2009 23:29:10 GMT From: "Dan Wing" To: , References: <6CF039C5B32037498B02251E11CDE6B007BB7096@ftrdmel3> Date: Thu, 5 Feb 2009 15:29:08 -0800 Message-ID: <004e01c987e9$8b837df0$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <6CF039C5B32037498B02251E11CDE6B007BB7096@ftrdmel3> Thread-Index: AcmHmiHQQHeVCnr9Sg+q3yOEBZEYnAAAQO6AABNkjBA= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2187; t=1233876550; x=1234740550; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20TR=3A=20I-DAction=3Adraft-bo ucadair-pppext-portrange-option-00.txt |Sender:=20; bh=y4hznzYC9F+xJDpKli3q7q+JgNmd1eEE/XdEFSJht7o=; b=nlG0IPmISBQM7ABJ8b8f4tRMcUq2ILZ6nSGY56p9W1289AaEccRb5TETiP QSfB7FB63IWWjn0BBPAOvl+U7rb3RRKQmvj89QL8/Vu+9c59TtPmIt5Qn/rA Uij++vhWrZ; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: behave@ietf.org Subject: Re: [shara] [BEHAVE] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 23:29:09 -0000 I like this draft overall, but I would restrict this so that only = contiguous port ranges are permitted. Non-contiguous subnet masks are difficult = for many people to understand (even today) and I expect there would be similar confusion with non-contiguous port ranges. -d > -----Original Message----- > From: behave-bounces@ietf.org=20 > [mailto:behave-bounces@ietf.org] On Behalf Of=20 > mohamed.boucadair@orange-ftgroup.com > Sent: Thursday, February 05, 2009 6:09 AM > To: behave@ietf.org; shara@ietf.org > Subject: [BEHAVE] TR:=20 > I-DAction:draft-boucadair-pppext-portrange-option-00.txt >=20 > =20 >=20 > FYI. A new ID has been submitted to IETF. This draft=20 > specifies new PPP IPCP options to be used in the context of=20 > Port Range solutions. >=20 > Comments are more than welcome. >=20 > Cheers, > Med >=20 >=20 >=20 >=20 > -----Message d'origine----- > De : i-d-announce-bounces@ietf.org=20 > [mailto:i-d-announce-bounces@ietf.org] De la part de=20 > Internet-Drafts@ietf.org > Envoy=E9 : jeudi 5 f=E9vrier 2009 15:00 > =C0 : i-d-announce@ietf.org > Objet : I-D Action:draft-boucadair-pppext-portrange-option-00.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : Port Range Configuration Options for PPP IPCP > Author(s) : M. Boucadair, et al. > Filename : draft-boucadair-pppext-portrange-option-00.txt > Pages : 13 > Date : 2009-02-05 >=20 > This memo defines two IPCP (IP Configuration Protocol,=20 > [RFC1332]) Options to be used in the context of Port Range=20 > solutions. IPCP is the configuration protocol used when PPP=20 > (Point-to-Point Protocol, > [RFC1548]) is deployed. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-boucadair-pppext-por > trange-option-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 From randy@psg.com Thu Feb 5 15:35:12 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FB933A69E4; Thu, 5 Feb 2009 15:35:12 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FiF-ObIp9Mo; Thu, 5 Feb 2009 15:35:12 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 8ED7D3A69CB; Thu, 5 Feb 2009 15:35:08 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LVDkP-000Dzd-Px; Thu, 05 Feb 2009 23:35:05 +0000 Received: from rmac.psg.com.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id C2FE92BEF3B; Fri, 6 Feb 2009 08:35:04 +0900 (JST) Date: Fri, 06 Feb 2009 08:35:04 +0900 Message-ID: From: Randy Bush To: "Dan Wing" In-Reply-To: <004e01c987e9$8b837df0$c2f0200a@cisco.com> References: <6CF039C5B32037498B02251E11CDE6B007BB7096@ftrdmel3> <004e01c987e9$8b837df0$c2f0200a@cisco.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: behave@ietf.org, shara@ietf.org Subject: Re: [shara] [BEHAVE] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 23:35:12 -0000 > I like this draft overall, but I would restrict this so that only contiguous > port ranges are permitted. Non-contiguous subnet masks are difficult for many > people to understand (even today) and I expect there would be similar > confusion with non-contiguous port ranges. do people have to understand these? randy From dthaler@windows.microsoft.com Thu Feb 5 17:09:40 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B665A3A6A18; Thu, 5 Feb 2009 17:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.514 X-Spam-Level: X-Spam-Status: No, score=-110.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRPvnaVdfiJM; Thu, 5 Feb 2009 17:09:40 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 07CE33A69CB; Thu, 5 Feb 2009 17:09:39 -0800 (PST) Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.99.4; Thu, 5 Feb 2009 17:09:41 -0800 Received: from tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com (157.54.18.33) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) with Microsoft SMTP Server id 8.2.99.4; Thu, 5 Feb 2009 17:09:41 -0800 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::75be:c82f:ae04:55bf]) by tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.33]) with mapi; Thu, 5 Feb 2009 17:09:41 -0800 From: Dave Thaler To: Randy Bush , Dan Wing Date: Thu, 5 Feb 2009 17:09:40 -0800 Thread-Topic: [shara] [BEHAVE] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt Thread-Index: AcmH6rF7O8eIFT3dRwGVzm6VhD6rmwADK9cQ Message-ID: References: <6CF039C5B32037498B02251E11CDE6B007BB7096@ftrdmel3> <004e01c987e9$8b837df0$c2f0200a@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" , "shara@ietf.org" Subject: Re: [shara] [BEHAVE] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 01:09:40 -0000 Yes. :) I had the same feedback last IETF. This is the same thing all over again as a non-contiguous subnet mask, which the industry effectively got rid of as having too many problems in practice (but being fine in theory). -Dave -----Original Message----- From: shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] On Behalf Of R= andy Bush Sent: Thursday, February 05, 2009 3:35 PM To: Dan Wing Cc: behave@ietf.org; shara@ietf.org Subject: Re: [shara] [BEHAVE] TR: I-DAction:draft-boucadair-pppext-portrang= e-option-00.txt > I like this draft overall, but I would restrict this so that only contigu= ous > port ranges are permitted. Non-contiguous subnet masks are difficult for= many > people to understand (even today) and I expect there would be similar > confusion with non-contiguous port ranges. do people have to understand these? randy _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara From randy@psg.com Thu Feb 5 22:11:51 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96F413A6850; Thu, 5 Feb 2009 22:11:51 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Za0wLeNTrFfD; Thu, 5 Feb 2009 22:11:50 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 5EC8F3A6827; Thu, 5 Feb 2009 22:11:50 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LVJwL-000F52-Ij; Fri, 06 Feb 2009 06:11:49 +0000 Received: from rmac.psg.com.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 740502BF565; Fri, 6 Feb 2009 13:55:07 +0800 (HKT) Date: Fri, 06 Feb 2009 13:55:07 +0800 Message-ID: From: Randy Bush To: Dave Thaler In-Reply-To: References: <6CF039C5B32037498B02251E11CDE6B007BB7096@ftrdmel3> <004e01c987e9$8b837df0$c2f0200a@cisco.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "behave@ietf.org" , "shara@ietf.org" Subject: Re: [shara] [BEHAVE] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 06:11:51 -0000 > Yes. :) they do? when? > I had the same feedback last IETF. > This is the same thing all over again as a non-contiguous subnet mask, > which the industry effectively got rid of as having too many problems > in practice (but being fine in theory). >> I like this draft overall, but I would restrict this so that only contiguous >> port ranges are permitted. Non-contiguous subnet masks are difficult for many >> people to understand (even today) and I expect there would be similar >> confusion with non-contiguous port ranges. > do people have to understand these? imiho, this is like ASDOT notation. useless. randy From teemu.savolainen@nokia.com Thu Feb 5 22:21:14 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADEBF3A6B3D; Thu, 5 Feb 2009 22:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYu+i1vazT8R; Thu, 5 Feb 2009 22:21:13 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 664233A6827; Thu, 5 Feb 2009 22:21:13 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n166Kto9005769; Fri, 6 Feb 2009 08:21:09 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Feb 2009 08:20:53 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Feb 2009 08:20:49 +0200 Received: from nok-am1mhub-07.mgdnok.nokia.com (65.54.30.14) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 6 Feb 2009 07:20:48 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-07.mgdnok.nokia.com ([65.54.30.14]) with mapi; Fri, 6 Feb 2009 07:20:48 +0100 From: To: , , Date: Fri, 6 Feb 2009 07:20:47 +0100 Thread-Topic: [shara] [BEHAVE] TR: I-DAction:draft-boucadair-pppext-portrang e-option-00.txt Thread-Index: AQHJiCMNTzrmZ0dtOk+kwKu3E6/2ng== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Feb 2009 06:20:49.0454 (UTC) FILETIME=[0DDC3CE0:01C98823] X-Nokia-AV: Clean Cc: behave@ietf.org Subject: Re: [shara] [BEHAVE] TR: I-DAction:draft-boucadair-pppext-portrang e-option-00.txt X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 06:21:14 -0000 Hi, Continuous, especially if small, port ranges make it difficult for a host t= o pick good random source ports. We have I-D related to this on the way. Best regards, Teemu --- original message --- From: "ext Dan Wing" Subject: Re: [shara] [BEHAVE] TR: I-DAction:draft-boucadair-pppext-portrang= e-option-00.txt Date: 6th February 2009 Time: 1:29:27 am I like this draft overall, but I would restrict this so that only contiguou= s port ranges are permitted. Non-contiguous subnet masks are difficult for m= any people to understand (even today) and I expect there would be similar confusion with non-contiguous port ranges. -d > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange-ftgroup.com > Sent: Thursday, February 05, 2009 6:09 AM > To: behave@ietf.org; shara@ietf.org > Subject: [BEHAVE] TR: > I-DAction:draft-boucadair-pppext-portrange-option-00.txt > > > > FYI. A new ID has been submitted to IETF. This draft > specifies new PPP IPCP options to be used in the context of > Port Range solutions. > > Comments are more than welcome. > > Cheers, > Med > > > > > -----Message d'origine----- > De : i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] De la part de > Internet-Drafts@ietf.org > Envoy=E9 : jeudi 5 f=E9vrier 2009 15:00 > =C0 : i-d-announce@ietf.org > Objet : I-D Action:draft-boucadair-pppext-portrange-option-00.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > Title : Port Range Configuration Options for PPP IPCP > Author(s) : M. Boucadair, et al. > Filename : draft-boucadair-pppext-portrange-option-00.txt > Pages : 13 > Date : 2009-02-05 > > This memo defines two IPCP (IP Configuration Protocol, > [RFC1332]) Options to be used in the context of Port Range > solutions. IPCP is the configuration protocol used when PPP > (Point-to-Point Protocol, > [RFC1548]) is deployed. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-boucadair-pppext-por > trange-option-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail > reader implementation to automatically retrieve the ASCII > version of the Internet-Draft. > _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara From mohamed.boucadair@orange-ftgroup.com Thu Feb 5 22:35:28 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D60643A693D; Thu, 5 Feb 2009 22:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0c65G66ORl2; Thu, 5 Feb 2009 22:35:27 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id BDAEA3A6B18; Thu, 5 Feb 2009 22:35:26 -0800 (PST) Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Feb 2009 07:35:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Feb 2009 07:35:18 +0100 Message-ID: <6CF039C5B32037498B02251E11CDE6B007BB734A@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] [shara]TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt Thread-Index: AcmH6rF7O8eIFT3dRwGVzm6VhD6rmwADK9cQAAsCqgA= References: <6CF039C5B32037498B02251E11CDE6B007BB7096@ftrdmel3><004e01c987e9$8b837df0$c2f0200a@cisco.com> From: To: , , X-OriginalArrivalTime: 06 Feb 2009 06:35:19.0582 (UTC) FILETIME=[147F3BE0:01C98825] Cc: behave@ietf.org, shara@ietf.org Subject: Re: [shara] [BEHAVE] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 06:35:28 -0000 Thank you for your comment. There is a subtlety between subnet mask and port mask: subnets need to = be hierarchical but not port ranges! Non contiguous port range is proposed as a solution to assign with a = single mask for instance "M" Port Ranges with "n" Port Ranges within the = well-known Port Range. This means that well-known PR won't be assigned = to the same user.=20 I see other advantages on the usage of non contiguous PR: e.g. an = attacker would have more difficulty to "guess" a port value within the = Port Range. By the way, I have the same question as Randy. Med =20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part = de Dave Thaler Envoy=E9 : vendredi 6 f=E9vrier 2009 02:10 =C0 : Randy Bush; Dan Wing Cc : behave@ietf.org; shara@ietf.org Objet : Re: [BEHAVE] [shara]TR: = I-DAction:draft-boucadair-pppext-portrange-option-00.txt Yes. :) I had the same feedback last IETF. This is the same thing all over again as a non-contiguous subnet mask, = which the industry effectively got rid of as having too many problems in = practice (but being fine in theory). -Dave -----Original Message----- From: shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] On Behalf = Of Randy Bush Sent: Thursday, February 05, 2009 3:35 PM To: Dan Wing Cc: behave@ietf.org; shara@ietf.org Subject: Re: [shara] [BEHAVE] TR: = I-DAction:draft-boucadair-pppext-portrange-option-00.txt > I like this draft overall, but I would restrict this so that only=20 > contiguous port ranges are permitted. Non-contiguous subnet masks are = > difficult for many people to understand (even today) and I expect=20 > there would be similar confusion with non-contiguous port ranges. do people have to understand these? randy _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From randy@psg.com Thu Feb 5 22:40:37 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 646833A6B35; Thu, 5 Feb 2009 22:40:37 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORBRNXuBXMp8; Thu, 5 Feb 2009 22:40:36 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 8B82F3A6B04; Thu, 5 Feb 2009 22:40:36 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LVKOC-000FAN-6d; Fri, 06 Feb 2009 06:40:36 +0000 Received: from rmac.psg.com.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 2F29F2C2766; Fri, 6 Feb 2009 14:40:35 +0800 (HKT) Date: Fri, 06 Feb 2009 14:40:33 +0800 Message-ID: From: Randy Bush To: In-Reply-To: <6CF039C5B32037498B02251E11CDE6B007BB734A@ftrdmel3> References: <6CF039C5B32037498B02251E11CDE6B007BB7096@ftrdmel3> <004e01c987e9$8b837df0$c2f0200a@cisco.com> <6CF039C5B32037498B02251E11CDE6B007BB734A@ftrdmel3> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: behave@ietf.org, shara@ietf.org Subject: Re: [shara] [BEHAVE] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 06:40:37 -0000 > subnets need to be hierarchical fwiw, paul francis publiched a scheme back in about '92 where subnet masks were not contiguous. it was self-consistent. randy From dwing@cisco.com Thu Feb 5 22:47:23 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 909303A6B35; Thu, 5 Feb 2009 22:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82lci584LM5j; Thu, 5 Feb 2009 22:47:22 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DBE763A6827; Thu, 5 Feb 2009 22:47:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,390,1231113600"; d="scan'208";a="244070903" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 06 Feb 2009 06:47:25 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n166lOl0008804; Thu, 5 Feb 2009 22:47:24 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n166lOon003373; Fri, 6 Feb 2009 06:47:24 GMT From: "Dan Wing" To: "'Randy Bush'" , References: <6CF039C5B32037498B02251E11CDE6B007BB7096@ftrdmel3><004e01c987e9$8b837df0$c2f0200a@cisco.com><6CF039C5B32037498B02251E11CDE6B007BB734A@ftrdmel3> Date: Thu, 5 Feb 2009 22:47:24 -0800 Message-ID: <014a01c98826$c4ad5b40$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: Thread-Index: AcmIJdN79YJSKSXQQBeU8fwSnJwtIAAAMCiA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=244; t=1233902844; x=1234766844; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20[shara]TR=3A=09I-DAction=3Ad raft-boucadair-pppext-portrange-option-00.txt |Sender:=20; bh=+f4vOHe1BX1etL5tTKYT9nPa8RMcS3UWmqGyl0YN2sM=; b=Nc9B5gk0HOFb87u0a06bMD/37iqweEZWufU0s6ip4+tohp/2sHYkq69u+Y O9rV9EmZq2muXYaM5bMS87FEKYZrDDN5Wjy37sthO10N1pMTgAc02+ivJ1w4 cRZSUKnmJ1o1vUUhAtkTQVmMRVooByZRIJH0/WFjR8smaaiqwIpRk=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: behave@ietf.org, shara@ietf.org Subject: Re: [shara] [BEHAVE] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 06:47:23 -0000 > > subnets need to be hierarchical > > fwiw, paul francis publiched a scheme back in about '92 where > subnet masks were not contiguous. it was self-consistent. Can you describe the adoption of the scheme in the last 16 years? -d From mohamed.boucadair@orange-ftgroup.com Thu Feb 5 23:01:32 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AD293A693D; Thu, 5 Feb 2009 23:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PMXLF6l1ljP; Thu, 5 Feb 2009 23:01:31 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 0B73C3A680A; Thu, 5 Feb 2009 23:01:30 -0800 (PST) Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Feb 2009 07:50:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Feb 2009 07:50:39 +0100 Message-ID: <6CF039C5B32037498B02251E11CDE6B007BB7354@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt Thread-Index: AcmHmiHQQHeVCnr9Sg+q3yOEBZEYnAAAQO6AABNkjBAAD41EUA== References: <6CF039C5B32037498B02251E11CDE6B007BB7096@ftrdmel3> <004e01c987e9$8b837df0$c2f0200a@cisco.com> From: To: , X-OriginalArrivalTime: 06 Feb 2009 06:50:40.0006 (UTC) FILETIME=[391CCA60:01C98827] Cc: behave@ietf.org Subject: Re: [shara] [BEHAVE] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 07:01:32 -0000 Thank you for your comment. By the way, the draft introduces the notion of non contiguous "Port = Mask". Non-contiguous subnet masks are NOT mentioned in the draft. Cheers, Med -----Message d'origine----- De : Dan Wing [mailto:dwing@cisco.com]=20 Envoy=E9 : vendredi 6 f=E9vrier 2009 00:29 =C0 : BOUCADAIR Mohamed RD-CORE-CAE; shara@ietf.org Cc : behave@ietf.org Objet : RE: [BEHAVE] TR: = I-DAction:draft-boucadair-pppext-portrange-option-00.txt I like this draft overall, but I would restrict this so that only = contiguous port ranges are permitted. Non-contiguous subnet masks are = difficult for many people to understand (even today) and I expect there = would be similar confusion with non-contiguous port ranges. -d > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of=20 > mohamed.boucadair@orange-ftgroup.com > Sent: Thursday, February 05, 2009 6:09 AM > To: behave@ietf.org; shara@ietf.org > Subject: [BEHAVE] TR:=20 > I-DAction:draft-boucadair-pppext-portrange-option-00.txt >=20 > =20 >=20 > FYI. A new ID has been submitted to IETF. This draft specifies new PPP = > IPCP options to be used in the context of Port Range solutions. >=20 > Comments are more than welcome. >=20 > Cheers, > Med >=20 >=20 >=20 >=20 > -----Message d'origine----- > De : i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] De la part de=20 > Internet-Drafts@ietf.org Envoy=E9 : jeudi 5 f=E9vrier 2009 15:00 =C0 : = > i-d-announce@ietf.org Objet : I-D=20 > Action:draft-boucadair-pppext-portrange-option-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. >=20 > Title : Port Range Configuration Options for PPP IPCP > Author(s) : M. Boucadair, et al. > Filename : draft-boucadair-pppext-portrange-option-00.txt > Pages : 13 > Date : 2009-02-05 >=20 > This memo defines two IPCP (IP Configuration Protocol, > [RFC1332]) Options to be used in the context of Port Range solutions. = > IPCP is the configuration protocol used when PPP (Point-to-Point=20 > Protocol, > [RFC1548]) is deployed. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-boucadair-pppext-por > trange-option-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. >=20 From dwing@cisco.com Thu Feb 5 23:11:14 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52B333A6B6A; Thu, 5 Feb 2009 23:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUdl8KI4G3f7; Thu, 5 Feb 2009 23:11:12 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id CC3093A680A; Thu, 5 Feb 2009 23:11:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,390,1231113600"; d="scan'208";a="129332900" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 06 Feb 2009 07:11:14 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n167BE26006663; Thu, 5 Feb 2009 23:11:14 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n167BEmQ013422; Fri, 6 Feb 2009 07:11:14 GMT From: "Dan Wing" To: , , References: <6CF039C5B32037498B02251E11CDE6B007BB7096@ftrdmel3><004e01c987e9$8b837df0$c2f0200a@cisco.com> <6CF039C5B32037498B02251E11CDE6B007BB734A@ftrdmel3> Date: Thu, 5 Feb 2009 23:11:14 -0800 Message-ID: <014b01c9882a$19255210$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <6CF039C5B32037498B02251E11CDE6B007BB734A@ftrdmel3> Thread-Index: AcmH6rF7O8eIFT3dRwGVzm6VhD6rmwADK9cQAAsCqgAAANc0wA== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3996; t=1233904275; x=1234768275; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20[shara]TR=3A=09I-DAction=3Ad raft-boucadair-pppext-portrange-option-00.txt |Sender:=20; bh=wq6tkXM36laWoGi96HsRZVfztJVtI92sQK+Fl9Nmjss=; b=DS3k8otAQdaXsMBVfQ2N8qAlI7lsCklIxnk0ZBqQauhCeM9sDKdsdTx7Yk xdYSdJZsOkVT38Smk0h3j7kg/EA0226kem64ym0CaXEQ4db8rxn9gzA0PDkZ fVPjMTlemA; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: behave@ietf.org, shara@ietf.org Subject: Re: [shara] [BEHAVE] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 07:11:14 -0000 =20 > -----Original Message----- > From: mohamed.boucadair@orange-ftgroup.com=20 > [mailto:mohamed.boucadair@orange-ftgroup.com]=20 > Sent: Thursday, February 05, 2009 10:35 PM > To: dthaler@windows.microsoft.com; randy@psg.com; dwing@cisco.com > Cc: behave@ietf.org; shara@ietf.org > Subject: RE: [BEHAVE] [shara]TR:=20 > I-DAction:draft-boucadair-pppext-portrange-option-00.txt >=20 >=20 > Thank you for your comment. >=20 > There is a subtlety between subnet mask and port mask:=20 > subnets need to be hierarchical but not port ranges! I disagree. Port ranges all belong to the same IP address --=20 from the view of the rest of the Internet. This is akin to the=20 rest of the Internet's view of a subnet. It is only the local IP address (subnet) that is aware of the separation of ports (or IP addresses) to individual hosts. > Non contiguous port range is proposed as a solution to assign=20 > with a single mask for instance "M" Port Ranges with "n" Port=20 > Ranges within the well-known Port Range. This means that=20 > well-known PR won't be assigned to the same user.=20 >=20 > I see other advantages on the usage of non contiguous PR:=20 > e.g. an attacker would have more difficulty to "guess" a port=20 > value within the Port Range. draft-boucadair-pppext-portrange-option does not describe this advantage. I am not convinced this would thwart an attacker significantly. If a user is permitted XXXX ports, an attacker can determine what ports they are by a range of contiguous bits or a range of non-contiguous bits. I agree the attacker has to perform more probes to learn the non-contiguous bit pattern, of course. But an analysis of this advantage would be useful. > By the way, I have the same question as Randy. I am not talking about the proverbial Grandma or "Joe Sixpack" when I say "users". Those users have no need to understand 255.255.255.0, or IP addresses, or ARP. However, network administrators are users, and they need=20 to understand these bit-masks in order to successfully configure equipment. Based on industry experience with IP, non-contiguous subnet masks are not used in very many networks. This is because the complexity to use them exceeds their value. Justification of the value of non-contiguous port masks=20 would be useful. -d >=20 >=20 > Med >=20 > =20 >=20 > -----Message d'origine----- > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org]=20 > De la part de Dave Thaler > Envoy=E9 : vendredi 6 f=E9vrier 2009 02:10 > =C0 : Randy Bush; Dan Wing > Cc : behave@ietf.org; shara@ietf.org > Objet : Re: [BEHAVE] [shara]TR:=20 > I-DAction:draft-boucadair-pppext-portrange-option-00.txt >=20 > Yes. :) >=20 > I had the same feedback last IETF. > This is the same thing all over again as a non-contiguous=20 > subnet mask, which the industry effectively got rid of as=20 > having too many problems in practice (but being fine in theory). >=20 > -Dave >=20 > -----Original Message----- > From: shara-bounces@ietf.org [mailto:shara-bounces@ietf.org]=20 > On Behalf Of Randy Bush > Sent: Thursday, February 05, 2009 3:35 PM > To: Dan Wing > Cc: behave@ietf.org; shara@ietf.org > Subject: Re: [shara] [BEHAVE] TR:=20 > I-DAction:draft-boucadair-pppext-portrange-option-00.txt >=20 > > I like this draft overall, but I would restrict this so that only=20 > > contiguous port ranges are permitted. Non-contiguous=20 > subnet masks are=20 > > difficult for many people to understand (even today) and I expect=20 > > there would be similar confusion with non-contiguous port ranges. >=20 > do people have to understand these? >=20 > randy > _______________________________________________ > shara mailing list > shara@ietf.org > https://www.ietf.org/mailman/listinfo/shara >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From teemu.savolainen@nokia.com Thu Feb 5 23:32:55 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 815033A69AA; Thu, 5 Feb 2009 23:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ayZHaaT05U9; Thu, 5 Feb 2009 23:32:54 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id E26153A695E; Thu, 5 Feb 2009 23:32:53 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n167WMkn011174; Fri, 6 Feb 2009 09:32:31 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Feb 2009 09:32:19 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Feb 2009 09:32:14 +0200 Received: from nok-am1mhub-08.mgdnok.nokia.com (65.54.30.15) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 6 Feb 2009 08:32:13 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-08.mgdnok.nokia.com ([65.54.30.15]) with mapi; Fri, 6 Feb 2009 08:32:13 +0100 From: To: , , , Date: Fri, 6 Feb 2009 08:31:48 +0100 Thread-Topic: [BEHAVE] [shara]TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt Thread-Index: AcmH6rF7O8eIFT3dRwGVzm6VhD6rmwADK9cQAAsCqgAAANc0wAABZXTg Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F27E8726BD7@NOK-EUMSG-01.mgdnok.nokia.com> References: <6CF039C5B32037498B02251E11CDE6B007BB7096@ftrdmel3><004e01c987e9$8b837df0$c2f0200a@cisco.com> <6CF039C5B32037498B02251E11CDE6B007BB734A@ftrdmel3> <014b01c9882a$19255210$c2f0200a@cisco.com> In-Reply-To: <014b01c9882a$19255210$c2f0200a@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Feb 2009 07:32:14.0325 (UTC) FILETIME=[07D7AA50:01C9882D] X-Nokia-AV: Clean Cc: behave@ietf.org, shara@ietf.org Subject: Re: [shara] [BEHAVE] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 07:32:55 -0000 Dan, We have a draft pending on Internet-Draft submission tool: http://www.ietf.= org/proceedings/staging/draft-bajko-pripaddrassign-00.txt that describes wh= at you ask. (Note: that link will not work after the draft gets published). Please check that out, it is discussing more about this and also describing= alternative solution using cryptographically random port allocation scheme= . These administrators could configure a host to get say 1000 ports, but of c= ourse not specific ones as those would be randomized from the 64K-1K range.= With proper tools administrators can of course see what ports are/were ass= igned to users. Best regards, Teemu >-----Original Message----- >From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] >On Behalf Of ext Dan Wing >Sent: 06 February, 2009 09:11 >To: mohamed.boucadair@orange-ftgroup.com; >dthaler@windows.microsoft.com; randy@psg.com >Cc: behave@ietf.org; shara@ietf.org >Subject: Re: [BEHAVE] [shara]TR: >I-DAction:draft-boucadair-pppext-portrange-option-00.txt > > > > >> -----Original Message----- >> From: mohamed.boucadair@orange-ftgroup.com >> [mailto:mohamed.boucadair@orange-ftgroup.com] >> Sent: Thursday, February 05, 2009 10:35 PM >> To: dthaler@windows.microsoft.com; randy@psg.com; dwing@cisco.com >> Cc: behave@ietf.org; shara@ietf.org >> Subject: RE: [BEHAVE] [shara]TR: >> I-DAction:draft-boucadair-pppext-portrange-option-00.txt >> >> >> Thank you for your comment. >> >> There is a subtlety between subnet mask and port mask: >> subnets need to be hierarchical but not port ranges! > >I disagree. Port ranges all belong to the same IP address -- >from the view of the rest of the Internet. This is akin to >the rest of the Internet's view of a subnet. It is only the >local IP address (subnet) that is aware of the separation of >ports (or IP addresses) to individual hosts. > >> Non contiguous port range is proposed as a solution to assign with a >> single mask for instance "M" Port Ranges with "n" Port Ranges within >> the well-known Port Range. This means that well-known PR won't be >> assigned to the same user. >> >> I see other advantages on the usage of non contiguous PR: >> e.g. an attacker would have more difficulty to "guess" a port value >> within the Port Range. > >draft-boucadair-pppext-portrange-option does not describe this >advantage. I am not convinced this would thwart an attacker >significantly. If a user is permitted XXXX ports, an attacker >can determine what ports they are by a range of contiguous >bits or a range of non-contiguous bits. I agree the attacker >has to perform more probes to learn the non-contiguous bit >pattern, of course. But an analysis of this advantage would be useful. > >> By the way, I have the same question as Randy. > >I am not talking about the proverbial Grandma or "Joe Sixpack" >when I say "users". Those users have no need to understand >255.255.255.0, or IP addresses, or ARP. > >However, network administrators are users, and they need to >understand these bit-masks in order to successfully configure >equipment. Based on industry experience with IP, >non-contiguous subnet masks are not used in very many >networks. This is because the complexity to use them exceeds >their value. > >Justification of the value of non-contiguous port masks would >be useful. > >-d > > >> >> >> Med >> >> >> >> -----Message d'origine----- >> De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la >> part de Dave Thaler Envoy=E9 : vendredi 6 f=E9vrier 2009 02:10 =C0 : Ran= dy >> Bush; Dan Wing Cc : behave@ietf.org; shara@ietf.org Objet : Re: >> [BEHAVE] [shara]TR: >> I-DAction:draft-boucadair-pppext-portrange-option-00.txt >> >> Yes. :) >> >> I had the same feedback last IETF. >> This is the same thing all over again as a non-contiguous >subnet mask, >> which the industry effectively got rid of as having too many >problems >> in practice (but being fine in theory). >> >> -Dave >> >> -----Original Message----- >> From: shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] >On Behalf >> Of Randy Bush >> Sent: Thursday, February 05, 2009 3:35 PM >> To: Dan Wing >> Cc: behave@ietf.org; shara@ietf.org >> Subject: Re: [shara] [BEHAVE] TR: >> I-DAction:draft-boucadair-pppext-portrange-option-00.txt >> >> > I like this draft overall, but I would restrict this so that only >> > contiguous port ranges are permitted. Non-contiguous >> subnet masks are >> > difficult for many people to understand (even today) and I expect >> > there would be similar confusion with non-contiguous port ranges. >> >> do people have to understand these? >> >> randy >> _______________________________________________ >> shara mailing list >> shara@ietf.org >> https://www.ietf.org/mailman/listinfo/shara >> >> _______________________________________________ >> 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 Gabor.Bajko@nokia.com Thu Feb 5 23:37:47 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D10433A69AA; Thu, 5 Feb 2009 23:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.118 X-Spam-Level: X-Spam-Status: No, score=-4.118 tagged_above=-999 required=5 tests=[AWL=-2.419, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, MANGLED_MEDS=2.3, RCVD_IN_DNSWL_MED=-4, SARE_RAND_1=2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+PNV8A96Dpg; Thu, 5 Feb 2009 23:37:44 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id A3C5C3A6959; Thu, 5 Feb 2009 23:37:43 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n167bNwp005216; Fri, 6 Feb 2009 09:37:40 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Feb 2009 09:37:36 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Feb 2009 09:37:36 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Fri, 6 Feb 2009 08:37:34 +0100 From: To: , , , Date: Fri, 6 Feb 2009 08:37:23 +0100 Thread-Topic: [shara] [BEHAVE] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt Thread-Index: AcmH6rF7O8eIFT3dRwGVzm6VhD6rmwADK9cQAAsCqgAAANc0wAABCkFA Message-ID: References: <6CF039C5B32037498B02251E11CDE6B007BB7096@ftrdmel3><004e01c987e9$8b837df0$c2f0200a@cisco.com> <6CF039C5B32037498B02251E11CDE6B007BB734A@ftrdmel3> <014b01c9882a$19255210$c2f0200a@cisco.com> In-Reply-To: <014b01c9882a$19255210$c2f0200a@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_A99B171D26E1564B92D36826128CD66127E350E97ENOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 06 Feb 2009 07:37:36.0015 (UTC) FILETIME=[C795A9F0:01C9882D] X-Nokia-AV: Clean Cc: behave@ietf.org, shara@ietf.org Subject: Re: [shara] [BEHAVE] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 07:37:47 -0000 --_002_A99B171D26E1564B92D36826128CD66127E350E97ENOKEUMSG01mgd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dan, The attached document should appear shortly in the ietf directories. Sectio= n 2 tries to justify the need for non-contiguous port range allocation. Sec= tions 4 and 5 explain how the non-contiguous port range and random port del= egation works. - gabor >-----Original Message----- >From: shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] On Behalf O= f >ext Dan Wing >Sent: Thursday, February 05, 2009 11:11 PM >To: mohamed.boucadair@orange-ftgroup.com; dthaler@windows.microsoft.com; >randy@psg.com >Cc: behave@ietf.org; shara@ietf.org >Subject: Re: [shara] [BEHAVE] TR: I-DAction:draft-boucadair-pppext- >portrange-option-00.txt > > > > >> -----Original Message----- >> From: mohamed.boucadair@orange-ftgroup.com >> [mailto:mohamed.boucadair@orange-ftgroup.com] >> Sent: Thursday, February 05, 2009 10:35 PM >> To: dthaler@windows.microsoft.com; randy@psg.com; dwing@cisco.com >> Cc: behave@ietf.org; shara@ietf.org >> Subject: RE: [BEHAVE] [shara]TR: >> I-DAction:draft-boucadair-pppext-portrange-option-00.txt >> >> >> Thank you for your comment. >> >> There is a subtlety between subnet mask and port mask: >> subnets need to be hierarchical but not port ranges! > >I disagree. Port ranges all belong to the same IP address -- >from the view of the rest of the Internet. This is akin to the >rest of the Internet's view of a subnet. It is only the local >IP address (subnet) that is aware of the separation of ports >(or IP addresses) to individual hosts. > >> Non contiguous port range is proposed as a solution to assign >> with a single mask for instance "M" Port Ranges with "n" Port >> Ranges within the well-known Port Range. This means that >> well-known PR won't be assigned to the same user. >> >> I see other advantages on the usage of non contiguous PR: >> e.g. an attacker would have more difficulty to "guess" a port >> value within the Port Range. > >draft-boucadair-pppext-portrange-option does not describe >this advantage. I am not convinced this would thwart an >attacker significantly. If a user is permitted XXXX ports, >an attacker can determine what ports they are by a range >of contiguous bits or a range of non-contiguous bits. I >agree the attacker has to perform more probes to learn >the non-contiguous bit pattern, of course. But an analysis >of this advantage would be useful. > >> By the way, I have the same question as Randy. > >I am not talking about the proverbial Grandma or "Joe >Sixpack" when I say "users". Those users have no >need to understand 255.255.255.0, or IP addresses, >or ARP. > >However, network administrators are users, and they need >to understand these bit-masks in order to successfully >configure equipment. Based on industry experience with >IP, non-contiguous subnet masks are not used in very >many networks. This is because the complexity to use >them exceeds their value. > >Justification of the value of non-contiguous port masks >would be useful. > >-d > > >> >> >> Med >> >> >> >> -----Message d'origine----- >> De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] >> De la part de Dave Thaler >> Envoy=E9 : vendredi 6 f=E9vrier 2009 02:10 >> =C0 : Randy Bush; Dan Wing >> Cc : behave@ietf.org; shara@ietf.org >> Objet : Re: [BEHAVE] [shara]TR: >> I-DAction:draft-boucadair-pppext-portrange-option-00.txt >> >> Yes. :) >> >> I had the same feedback last IETF. >> This is the same thing all over again as a non-contiguous >> subnet mask, which the industry effectively got rid of as >> having too many problems in practice (but being fine in theory). >> >> -Dave >> >> -----Original Message----- >> From: shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] >> On Behalf Of Randy Bush >> Sent: Thursday, February 05, 2009 3:35 PM >> To: Dan Wing >> Cc: behave@ietf.org; shara@ietf.org >> Subject: Re: [shara] [BEHAVE] TR: >> I-DAction:draft-boucadair-pppext-portrange-option-00.txt >> >> > I like this draft overall, but I would restrict this so that only >> > contiguous port ranges are permitted. Non-contiguous >> subnet masks are >> > difficult for many people to understand (even today) and I expect >> > there would be similar confusion with non-contiguous port ranges. >> >> do people have to understand these? >> >> randy >> _______________________________________________ >> shara mailing list >> shara@ietf.org >> https://www.ietf.org/mailman/listinfo/shara >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > >_______________________________________________ >shara mailing list >shara@ietf.org >https://www.ietf.org/mailman/listinfo/shara --_002_A99B171D26E1564B92D36826128CD66127E350E97ENOKEUMSG01mgd_ Content-Type: text/plain; name="draft-bajko-pripaddrassign-00.txt" Content-Description: draft-bajko-pripaddrassign-00.txt Content-Disposition: attachment; filename="draft-bajko-pripaddrassign-00.txt"; size=42463; creation-date="Wed, 04 Feb 2009 04:18:58 GMT"; modification-date="Wed, 04 Feb 2009 04:21:54 GMT" Content-Transfer-Encoding: base64 DQoKCk5ldHdvcmsgV0cgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEdhYm9yIEJhamtvIA0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFRlZW11IFNhdm9sYWluZW4gDQpJbnRlbmRlZCBTdGF0dXM6IFBy b3Bvc2VkIFN0YW5kYXJkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOb2tpYSANCkV4 cGlyZXM6IEF1Z3VzdCAzLCAyMDA5ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg TS4gQm91Y2FkYWlyIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgUC4gTGV2aXMgDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGcmFuY2UgVGVsZWNvbSANCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAz LCAyMDA5IA0KICAgIA0KICAgIA0KICAgICAgICAgICAgICAgICBQb3J0IFJlc3RyaWN0ZWQgSVAg QWRkcmVzcyBBc3NpZ25tZW50IA0KICAgICAgICAgICAgICAgICAgICAgZHJhZnQtYmFqa28tcHJp cGFkZHJhc3NpZ24tMDAgDQogDQogDQpTdGF0dXMgb2YgdGhpcyBNZW1vIA0KICAgIA0KICAgVGhp cyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgdG8gSUVURiBpbiBmdWxsIGNvbmZvcm1hbmNl IHdpdGggDQogICB0aGUgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4gDQogICAgDQog ICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBF bmdpbmVlcmluZyANCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29y a2luZyBncm91cHMuICBOb3RlIHRoYXQgDQogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJp YnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NCiAgIERyYWZ0cy4gDQogICAgDQog ICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVt IG9mIHNpeCANCiAgIG1vbnRocyBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNv bGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIA0KICAgYXQgYW55IHRpbWUuIEl0IGlzIGluYXBwcm9w cmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UgDQogICBtYXRlcmlhbCBv ciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iIA0KICAgIA0K ICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0 IA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LiANCiAgICAN CiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUg YWNjZXNzZWQgYXQgDQogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLiANCiAgICAN CiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gQXVndXN0IDMsIDIwMDkuIA0K ICAgIA0KICAgQ29weXJpZ2h0IE5vdGljZSANCiAgICANCiAgIENvcHlyaWdodCAoYykgMjAwOSBJ RVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZSANCiAgIGRvY3VtZW50 IGF1dGhvcnMuIEFsbCByaWdodHMgcmVzZXJ2ZWQuIA0KICAgIA0KICAgVGhpcyBkb2N1bWVudCBp cyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbCANCiAgIFByb3Zp c2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMgDQogICAoaHR0cDovL3RydXN0ZWUuaWV0 Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YgDQogICBwdWJsaWNh dGlvbiBvZiB0aGlzIGRvY3VtZW50LiBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cyANCiAg IGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25z IHdpdGggDQogICByZXNwZWN0IHRvIHRoaXMgZG9jdW1lbnQuIA0KICAgIA0KICAgIA0KQWJzdHJh Y3QgDQogICAgDQogICBXaGVuIElQdjYgd2FzIGRlc2lnbmVkLCB0aGUgYXNzdW1wdGlvbiB3YXMg dGhhdCB0aGUgdHJhbnNpdGlvbiBmcm9tIA0KICAgSVB2NCB0byBJUHY2IHdpbGwgb2NjdXIgd2F5 IGJlZm9yZSB0aGUgZXhoYXVzdGlvbiBvZiB0aGUgYXZhaWxhYmxlIA0KICANCkJhamtvICAgICAg ICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDMsIDIwMDkgICAgICAgICAgICAgICBbUGFnZSAx XSANCiAMDQogDQpQb3J0IFJlc3RyaWN0ZWQgSVAgYWRkcmVzcyBhc3NpZ25tZW50ICAgICAgICAg ICAgICAgICAgICAgSmFudWFyeSAyMDA5IA0KICAgIA0KICAgSVB2NCBhZGRyZXNzIHBvb2wuIFRo ZSB1bmV4cGVjdGVkIGdyb3d0aCBvZiB0aGUgSVB2NCBJbnRlcm5ldCBhbmQgDQogICB0aGUgaGVz aXRhdGlvbiBhbmQgdGVjaG5pY2FsIGRpZmZpY3VsdGllcyB0byBkZXBsb3kgSVB2NiBpbmRpY2F0 ZXMgDQogICB0aGF0IHRoZSB0cmFuc2l0aW9uIG1heSB0YWtlIG11Y2ggbG9uZ2VyIHRoYW4gb3Jp Z2luYWxseSANCiAgIGFudGljaXBhdGVkLiANCiAgIEl0IGlzIGV4cGVjdGVkIHRoYXQgY29tbXVu aWNhdGlvbiB1c2luZyBJUHY2IGFkZHJlc3NlcyB3aWxsIGluY3JlYXNlIA0KICAgZHVyaW5nIHRo ZSBuZXh0IGZldyB5ZWFycyB0byBjb21lIGF0IHRoZSBleHBlbnNlIG9mIGNvbW11bmljYXRpb24g DQogICB1c2luZyBJUHY0IGFkZHJlc3Nlcy4gVGhlIEludGVybmV0IHNob3VsZCByZWFjaCBhIHNh ZmV0eSBwb2ludCBpbiANCiAgIHRoZSBmdXR1cmUsIHdoZXJlIHRoZSBudW1iZXIgb2YgSVB2NCBw dWJsaWMgYWRkcmVzc2VzIGluIHVzZSBhdCBhIA0KICAgZ2l2ZW4gdGltZSBiZWdpbnMgZGVjcmVh c2luZy4gSXQgaXMgdmVyeSBsaWtlbHkgdGhhdCB0aGUgSVB2NCBwdWJsaWMgDQogICBhZGRyZXNz IHBvb2wgY3VycmVudGx5IGF2YWlsYWJsZSBhdCBJQU5BIHdpbGwgYmUgZXhoYXVzdGVkIGJlZm9y ZSANCiAgIHRoZSBpbnRlcm5ldCByZWFjaGVzIHRoaXMgc2FmZXR5IHBvaW50LiBUaGlzIGNyZWF0 ZXMgYSBuZWVkIHRvIA0KICAgcHJvbG9uZyB0aGUgbGlmZXRpbWUgb2YgdGhlIGF2YWlsYWJsZSBJ UHY0IGFkZHJlc3Nlcy4gDQogICAgDQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgbWV0aG9kcyB0 byBhbGxvY2F0ZSB0aGUgc2FtZSBJUHY0IGFkZHJlc3MgdG8gDQogICBtdWx0aXBsZSBob3N0cywg d2l0aCB0aGUgYWltIHRvIHByb2xvbmcgdGhlIGF2YWlsYWJpbGl0eSBvZiBwdWJsaWMgDQogICBJ UHY0IGFkZHJlc3NlcywgcG9zc2libHkgZm9yIGFzIGxvbmcgYXMgaXQgdGFrZXMgZm9yIElQdjYg dG8gdGFrZSANCiAgIG92ZXIgdGhlIGRlbWFuZCBmb3IgSVB2NC4gIA0KICAgIA0KQ29udmVudGlv bnMgdXNlZCBpbiB0aGlzIGRvY3VtZW50IA0KICAgIA0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIs ICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLCANCiAgICJTSE9V TEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICAiTUFZIiwgYW5kICJPUFRJT05BTCIg aW4gDQogICB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQg aW4gUkZDLTIxMTkgDQogICBbUkZDMjExOV0uIA0KICAgIA0KVGVybWlub2xvZ3kgYW5kIGFiYnJl dmlhdGlvbnMgdXNlZCBpbiB0aGlzIGRvY3VtZW50IA0KICAgIA0KICAgUG9ydCByZXN0cmljdGVk IElQdjQgYWRkcmVzczogYW4gSVAgYWRkcmVzcyB3aGljaCBjYW4gb25seSBiZSB1c2VkIA0KICAg aW4gY29uanVuY3Rpb24gd2l0aCB0aGUgc3BlY2lmaWVkIHBvcnRzLiBQb3J0IHJlc3RyaWN0aW9u IHJlZmVycyB0byANCiAgIGFsbCBrbm93biB0cmFuc3BvcnQgcHJvdG9jb2xzIChVRFAsIFRDUCwg U0NUUCwgRENDUCkuICANCiAgICANCiAgIENHTiAgICAgICAgICBDYXJyaWVyIEdyYWRlIE5ldHdv cmsgQWRkcmVzcyBUcmFuc2xhdG9yICANCiAgIENQRSAgICAgICAgICBDb25zdW1lciBQcmVtaXNl cyBFcXVpcG1lbnQsIGEgZGV2aWNlIHRoYXQgcmVzaWRlcyANCiAgICAgICAgICAgICAgICBiZXR3 ZWVuIGludGVybmV0IHNlcnZpY2UgcHJvdmlkZXIncyBuZXR3b3JrIGFuZCANCiAgICAgICAgICAg ICAgICBjb25zdW1lcnMnIGhvbWUgbmV0d29yay4gIA0KICAgUFJBICAgICAgICAgIFBvcnQgUmVz dHJpY3RlZCBJUHY0IEFkZHJlc3MgIA0KICAgIA0KCgoKCgoKCgoKCgoKCgoKIA0KQmFqa28gICAg ICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMywgMjAwOSAgICAgICAgICAgICAgIFtQYWdl IDJdIA0KIAwNCiANClBvcnQgUmVzdHJpY3RlZCBJUCBhZGRyZXNzIGFzc2lnbm1lbnQgICAgICAg ICAgICAgICAgICAgICBKYW51YXJ5IDIwMDkgDQogICAgDQpUYWJsZSBvZiBDb250ZW50IA0KICAg IA0KICAgMS4gSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLjQgDQogICAyLiBQb3J0IFJhbmRvbWl6YXRpb24gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuNSANCiAgIDMuIERIQ1B2NCBPcHRpb24g Zm9yIGFsbG9jYXRpbmcgcG9ydCByZXN0cmljdGVkIHB1YmxpYyBJUHY0ICANCiAgICAgIGFkZHJl c3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA2IA0KICAgNC4gUG9ydCBNYXNrIHN1Yi1vcHRpb24gdXNhZ2UgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLjggDQogICA0LjEgSWxsdXN0cmF0aW9uIEV4YW1wbGVzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuOSANCiAgIDUuIFJhbmRvbSBQb3J0 IGRlbGVnYXRpb24gZnVuY3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLjEwIA0K ICAgNi4gT3B0aW9uIFVzYWdlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTIgDQogICA2LjEgQ2xpZW50IEJlaGF2aW91ciAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4xMiANCiAgIDYuMiBTZXJ2ZXIgQmVoYXZpb3Vy IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLjEzIA0KICAgNy4g QXBwbGljYWJpbGl0eSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuMTQgDQogICA3LjEgSUNNUCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4xNSANCiAgIDcuMiA2dG80IC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLjE1IA0KICAgNy4zIFByb3Rv Y29scyBub3Qgc3VwcG9ydGVkIGJ5IG11bHRpcGxleGluZyBnYXRld2F5IC4gLiAuIC4gLiAuIC4g MTUgDQogICA4LiBJQU5BIGNvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4xNSANCiAgIDkuIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLjE1IA0KICAgMTAuIE5vcm1hdGl2ZSBS ZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuMTYgDQog ICAxMS4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4xNiANCiAgIDEyLiBDb250cmlidXRvcnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLjE3IA0KICAgMTMuIEVkaXRvcidzIEFkZHJlc3Nl cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuMTcgDQogICAgDQoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCiANCkJhamtvICAgICAgICAgICAgICAgICAgIEV4 cGlyZXMgQXVndXN0IDMsIDIwMDkgICAgICAgICAgICAgICBbUGFnZSAzXSANCiAMDQogDQpQb3J0 IFJlc3RyaWN0ZWQgSVAgYWRkcmVzcyBhc3NpZ25tZW50ICAgICAgICAgICAgICAgICAgICAgSmFu dWFyeSAyMDA5IA0KICAgIA0KMS4gSW50cm9kdWN0aW9uIA0KICAgICAgICAgDQogICBUaGVyZSBh cmUgYSBudW1iZXIgb2YgcG9zc2libGUgc29sdXRpb25zIHRvIGRlYWwgd2l0aCB0aGUgcHJvYmxl bSBvZiANCiAgIHRyYW5zaXRpb25pbmcgZnJvbSBJUHY0IHRvIElQdjY7IGhvd2V2ZXIgbm9uZSBv ZiB0aGVtIGlzIGEgb25lIGZpdHMgDQogICBhbGwgc29sdXRpb24uIERpZmZlcmVudCBzb2x1dGlv bnMgZml0IGRpZmZlcmVudCBkZXBsb3ltZW50IHNjZW5hcmlvcyANCiAgIChzZWUgYWxzbyBbQVJL SzIwMDhdKS4gU2VlIFtXSU5HMjAwOF0gZm9yIGNvbXBhcmlzb24uIA0KICAgICANCiAgIEFzIGEg cG9zc2libGUgYWRkaXRpb25hbCBhbmQgY29tcGxlbWVudGFyeSBzb2x1dGlvbiBmb3IgdGhlIElQ djQtDQogICBJUHY2IGNvZXhpc3RlbmNlIHBlcmlvZCwgdGhpcyBkb2N1bWVudCBkZXNjcmliZXMg YSBtZXRob2QsIHVzaW5nIA0KICAgbmV3bHkgZGVmaW5lZCBESENQdjQgW1JGQzIxMzFdIG9wdGlv biB0aGF0IGFsbG93cyBzZXJ2ZXJzIHRvIGFzc2lnbiANCiAgIHBvcnQgcmVzdHJpY3RlZCBJUHY0 IGFkZHJlc3NlcyB0byBjbGllbnRzLiBCeSBhc3NpZ25pbmcgdGhlIHNhbWUgDQogICBJUHY0IGFk ZHJlc3MgdG8gbXVsdGlwbGUgY2xpZW50cywgdGhlIGF2YWlsYWJpbGl0eSBvZiBJUHY0IGFkZHJl c3NlcyANCiAgIGNhbiBiZSwgaG9wZWZ1bGx5LCBwcm9sb25nZWQgZm9yIGFzIGxvbmcgYXMgaXQg dGFrZXMgZm9yIElQdjYgdG8gDQogICB0YWtlIG92ZXIgdGhlIGRlbWFuZCBmb3IgSVB2NC4gDQog ICAgDQogICBUaGUgc29sdXRpb24gZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgaXMgaW50ZW5k ZWQgdG8gYmUgdXNlZCBieSANCiAgIGxhcmdlIElTUHMsIHdobyBhcyBvZiB0aGUgZGF0ZSBvZiB3 cml0aW5nIHRoaXMgZG9jdW1lbnQsIGhhdmUgYSANCiAgIGxhcmdlIGVub3VnaCBJUHY0IGFkZHJl c3MgcG9vbCB0byBiZSBhYmxlIHRvIGFsbG9jYXRlIG9uZSBwdWJsaWMgDQogICBJUHY0IGFkZHJl c3MgZm9yIGVhY2ggYW5kIGV2ZXJ5IGNsaWVudC4gVGhleSBleHBlY3QgdGhvdWdoIHRoYXQgdGhl IA0KICAgc2l0dWF0aW9uIGlzIHVuc3VzdGFpbmFibGUgYW5kIHRoZXkgd2lsbCBzb29uIG5vdCBi ZSBhYmxlIHRvIHByb3ZpZGUgDQogICBldmVyeSBjbGllbnQgd2l0aCBhIHB1YmxpYyBJUHY0IGFk ZHJlc3MuIFN1Y2ggSVNQcyBoYXZlIHR3byANCiAgIHBvc3NpYmlsaXRpZXMgdG8gY2hvb3NlIGZy b206ICANCiAgIC0gZGVwbG95IE5ldHdvcmsgQWRkcmVzcyBUcmFuc2xhdG9ycyAoTkFUKSwgd2hp Y2ggY2FuIGJlIGEgDQogICBzaWduaWZpY2FudCBpbnZlc3RtZW50IGZvciBJU1BzIG5vdCBoYXZp bmcgTkFUcyB5ZXQuIFRoZSBhZGRyZXNzIA0KICAgc3BhY2UgbGltaXRhdGlvbnMgb2YgW1JGQzE5 MThdIG1heSBldmVuIGZvcmNlIHRoZXNlIGxhcmdlIElTUHMgdG8gDQogICBkZXBsb3kgZG91Ymxl IE5BVHMsIHdoaWNoIGNvbWUgd2l0aCBhbGwgdGhlIGhhcm1mdWwgYmVoYXZpb3VyIG9mIA0KICAg Q2FycmllciBHcmFkZSBOQVRzIChDR04pLCBhcyBkZXNjcmliZWQgaW4gW01BRU4yMDA4XTsgb3Ig IA0KICAgLSBhbGxvY2F0ZSBmcmFnbWVudHMgb2YgdGhlIHNhbWUgcHVibGljIElQdjQgYWRkcmVz cyBkaXJlY3RseSB0byANCiAgIG11bHRpcGxlIGNsaWVudHMgKHdoaWNoIGNhbiBiZSBDUEVzIG9y IGVuZCBob3N0cyksIHRodXMgYXZvaWQgdGhlIA0KICAgY29zdCBvZiBkZXBsb3lpbmcgbXVsdGlw bGUgbGF5ZXJzIG9mIE5BVHMgb3IgY2FycmllciBncmFkZSBOQVRzLiBJdCANCiAgIGlzIGhvd2V2 ZXIgYXNzdW1lZCwgdGhhdCB0aGUgZGVtYW5kIGZvciBJUHY0IGFkZHJlc3NlcyB3aWxsIGRlY3Jl YXNlIA0KICAgaW4gdGhlIG5vdCBzbyBkaXN0YW50IGZ1dHVyZSwgYmVpbmcgdGFrZW4gb3ZlciBi eSBJUHY2LCBhcyB0aGUgDQogICBwcm9wb3NhbCBpbiB0aGlzIGRyYWZ0IGlzIG5vdCBieSBhbnkg bWVhbnMgYSBwZXJtYW5lbnQgc29sdXRpb24gZm9yIA0KICAgdGhlIElQdjQgYWRkcmVzcyBleGhh dXN0aW9uIHByb2JsZW0uIEluIGZhY3QsIHNvbWUgcHJlc2VudGVkIA0KICAgZGVwbG95bWVudCBz Y2VuYXJpb3MgcmVxdWlyZSBleGlzdGVuY2Ugb2YgSVB2NiBhY2Nlc3MgbmV0d29yay4gDQogICAg DQogICBGb3IgSVNQcyBub3QgaGF2aW5nIE5BVHMgeWV0LCBhIHNvbHV0aW9uIG5vdCByZXF1aXJp bmcgTkFUcyB3b3VsZCANCiAgIHByb2JhYmx5IGJlIHByZWZlcnJlZC4gRm9yIHNvbWUgb3RoZXIg SVNQcywgd2hvIGFscmVhZHkgaGF2ZSBOQVRzIGluIA0KICAgcGxhY2UsIGluY3JlYXNpbmcgdGhl IGNhcGFjaXR5IG9mIHRoZWlyIE5BVHMgbWlnaHQgYmUgYSB2aWFibGUgDQogICBhbHRlcm5hdGl2 ZS4gDQogICAgDQogICBJbiBvdGhlciBkZXBsb3ltZW50IHNjZW5hcmlvcywgYWxsb2NhdGlvbiBv ZiBzaGFyZWQgYWRkcmVzc2VzIHRvIA0KICAgZGV2aWNlcyBhdCB0aGUgZWRnZSBvZiB0aGUgbmV0 d29yayB3b3VsZCByZXN1bHQgaW4gZGlzdHJpYnV0aW9uIG9mIA0KICAgTkFUIGZ1bmN0aW9uYWxp dHkgdG8gdGhlIGVkZ2VzLCBpbiBzb21lIGNhc2VzIGV2ZW4gdG8gQ1BFcyBbQVBMVVNQXS4gDQog ICAgDQogICBUaGlzIGRvY3VtZW50IHByb3Bvc2VzIHRvIHVzZSBuZXcgREhDUHY0IG9wdGlvbiB0 byBhbGxvY2F0ZSBwb3J0LQ0KICAgcmVzdHJpY3RlZCBJUHY0IGFkZHJlc3NlcyB0byB0aGUgY2xp ZW50cy4gVGhpcyBtZXRob2QgaXMgbWVhbnQgdG8gYmUgDQogICBhbiBJUHY0IHRvIElQdjYgdHJh bnNpdGlvbiB0b29sLCB0byBiZSBvbmx5IHRlbXBvcmFyaWx5IHVzZWQgZHVyaW5nIA0KICAgdGhl IHBlcmlvZCB3aGVuIHRoZSBkZW1hbmQgZm9yIHB1YmxpYyBJUHY0IGFkZHJlc3NlcyB3aWxsIGV4 Y2VlZCB0aGUgDQogICBhdmFpbGFiaWxpdHkgb2YgdGhlbS4gIA0KIA0KCiANCkJhamtvICAgICAg ICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDMsIDIwMDkgICAgICAgICAgICAgICBbUGFnZSA0 XSANCiAMDQogDQpQb3J0IFJlc3RyaWN0ZWQgSVAgYWRkcmVzcyBhc3NpZ25tZW50ICAgICAgICAg ICAgICAgICAgICAgSmFudWFyeSAyMDA5IA0KICAgIA0KICAgVGhlIHBvcnQgcmVzdHJpY3RlZCBJ UHY0IGFkZHJlc3Mgb3B0aW9uIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IA0KICAgY2FuIGJl IHVzZWQgaW4gdmFyaW91cyBkZXBsb3ltZW50IHNjZW5hcmlvcywgc29tZSBvZiB3aGljaCBhcmUg DQogICBkZXNjcmliZWQgaW4gW0JPVUNBREFJUkFSQ0hdLCBbQVBMVVNQXSwgYW5kIFtEU0xJVEVd LiANCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgogDQpC YWprbyAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAzLCAyMDA5ICAgICAgICAgICAg ICAgW1BhZ2UgNV0gDQogDA0KIA0KUG9ydCBSZXN0cmljdGVkIElQIGFkZHJlc3MgYXNzaWdubWVu dCAgICAgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAwOSANCiAgICANCiAgICANCjIuIFBvcnQg UmFuZG9taXphdGlvbiANCiAgICANCiAgIEl0IGlzIHdlbGwgZG9jdW1lbnRlZCB0aGF0IGF0dGFj a2VycyBjYW4gcGVyZm9ybSAiYmxpbmQiIGF0dGFja3MgDQogICBhZ2FpbnN0IHRyYW5zcG9ydCBw cm90b2NvbHMuIFRoZSBjb25zZXF1ZW5jZXMgb2YgdGhlc2UgYXR0YWNrcyByYW5nZSANCiAgIGZy b20gdGhyb3VnaHB1dC1yZWR1Y3Rpb24gdG8gYnJva2VuIGNvbm5lY3Rpb25zIG9yIGRhdGEgY29y cnVwdGlvbi4gDQogICBUaGVzZSBhdHRhY2tzIHJlbHkgb24gdGhlIGF0dGFja2VyJ3MgYWJpbGl0 eSB0byBndWVzcyBvciBrbm93IHRoZSANCiAgIGZpdmUtdHVwbGUgKFByb3RvY29sLCBTb3VyY2Ug QWRkcmVzcywgRGVzdGluYXRpb24gQWRkcmVzcywgU291cmNlIA0KICAgUG9ydCwgRGVzdGluYXRp b24gUG9ydCkgdGhhdCBpZGVudGlmaWVzIHRoZSB0cmFuc3BvcnQgcHJvdG9jb2wgDQogICBpbnN0 YW5jZSB0byBiZSBhdHRhY2tlZC4gTW9zdCBvZiB0aGVzZSBhdHRhY2tzIGNhbiBiZSBwcmV2ZW50 ZWQgYnkgDQogICByYW5kb21seSBzZWxlY3RpbmcgdGhlIGNsaWVudCBzb3VyY2UgcG9ydCBudW1i ZXIgc3VjaCB0aGF0IHRoZSANCiAgIHBvc3NpYmlsaXR5IG9mIGFuIGF0dGFja2VyIGd1ZXNzaW5n IHRoZSBleGFjdCB2YWx1ZSBpcyByZWR1Y2VkLiANCiAgIFtSQU5ET01QT1JUXSBkZWZpbmVzIGEg ZmV3IGFsZ29yaXRobXMgd2hpY2ggY2FuIHNlbGVjdCBhIHJhbmRvbSBwb3J0IA0KICAgZnJvbSB0 aGUgYXZhaWxhYmxlIHBvcnQgcmFuZ2UuIENsaWVudHMgdXN1YWxseSBoYXZlIHRoZSAoMTAyNCwg DQogICA2NTUzNSkgcG9ydCByYW5nZSBhdCB0aGVpciBkaXNwb3NhbCB0byBzZWxlY3QgYSByYW5k b20sIG5vdCB5ZXQgdXNlZCANCiAgIHBvcnQuIA0KICAgIA0KICAgV2hlbiBhbiBJUCBhZGRyZXNz IGlzIGFsbG9jYXRlZCB0byBtdWx0aXBsZSBjbGllbnRzLCB0aGUgc291cmNlIHBvcnQgDQogICBy YW5nZSBoYXMgdG8gYmUgZGl2aWRlZCBiZXR3ZWVuIHRoZSBjbGllbnRzLiBUaGUgc21hbGxlciB0 aGUgcG9ydCANCiAgIHJhbmdlLCB0aGUgZWFzaWVyIGlzIGZvciBhbiBhdHRhY2tlciB0byBndWVz cyB0aGUgbmV4dCBwb3J0IHRoZSANCiAgIGNsaWVudCBpcyBnb2luZyB0byB1c2UuIFRoZXJlZm9y ZSwgaXQgaXMgaW1wZXJhdGl2ZSB0byBkaXZpZGUgdGhlIA0KICAgcG9ydCByYW5nZSBiZXR3ZWVu IGNsaWVudHMgc2hhcmluZyB0aGUgc2FtZSBJUCBhZGRyZXNzIGluIHN1Y2ggYSB3YXkgDQogICB0 aGF0IHJhbmRvbSBzZWxlY3Rpb24gaXMgcHJlc2VydmVkLiBUaGlzIGRvY3VtZW50IHByb3Bvc2Vz IHR3byANCiAgIGRpZmZlcmVudCBtZXRob2RzIGZvciBwb3J0IGFsbG9jYXRpb24sIHdoaWNoIHBy ZXNlcnZlcyBwYXJ0bHkgb3IgDQogICBjb21wbGV0ZWx5IHRoZSByYW5kb21uZXNzIG9mIHRoZSBz b3VyY2UgcG9ydHM6IA0KICAgIA0KICAgICAgbyBUaGUgZmlyc3QgbWVjaGFuaXNtIHVzZXMgYSBw b3J0IG1hc2sgd2l0aCBhIGJpdCBsb2NhdG9yIHRvIA0KICAgICAgICBjb21tdW5pY2F0ZSBhIHJh bmdlIG9yIG11bHRpcGxlIHJhbmdlcyBvZiBwb3J0cyB0byBhIGNsaWVudC4gDQogICAgICAgIFJh bmRvbW5lc3MgaXMgcHJlc2VydmVkIHdoZW4gdGhlIGNsaWVudCBpcyBhYmxlIHRvIHNlbGVjdCBh IA0KICAgICAgICBwb3J0IHJhbmRvbWx5IGFjcm9zcyBhbGwgdGhlIGF2YWlsYWJsZSBwb3J0IHJh bmdlcy4gVGhlIA0KICAgICAgICBhbGdvcml0aG1zIGRlc2NyaWJlZCBpbiBbUkFORE9NUE9SVF0g Y2FuIGJlIHVzZWQgdG8gc2VsZWN0IGEgDQogICAgICAgIHJhbmRvbSBwb3J0IGZyb20gb25lIHBv cnQgcmFuZ2UsIGJ1dCBpbXBsZW1lbnRhdGlvbnMgbWF5IGZpbmQgDQogICAgICAgIGl0IGRpZmZp Y3VsdCB0byBzZWxlY3QgcmFuZG9tIHBvcnRzIGFjcm9zcyBwb3J0IHJhbmdlcy4gIA0KICAgICAg ICAgDQogICAgICBvIFRoZSBzZWNvbmQgbWVjaGFuaXNtIHVzZXMgYSBjcnlwdG9ncmFwaGljIGZ1 bmN0aW9uIHRvIA0KICAgICAgICBwcmVhbGxvY2F0ZSByYW5kb20gcG9ydHMgZnJvbSB0aGUgZW50 aXJlIHBvcnQgcmFuZ2UuIFRoZSBrZXkgDQogICAgICAgIGFuZCBvdGhlciBpbnB1dCBwYXJhbWV0 ZXJzIGFyZSBjb21tdW5pY2F0ZWQgdG8gdGhlIGNsaWVudCwgDQogICAgICAgIHdoaWNoIGNhbiBj YWxjdWxhdGUgdGhlIHBvcnRzIGl0IGNhbiB1c2UuIFRoZSAnc2lkZSBlZmZlY3QnIG9mIA0KICAg ICAgICB0aGlzIG1lY2hhbmlzbSBpcyB0aGF0IHRoZSBjbGllbnQgaXMgZm9yY2VkIHRvIHVzZSBy YW5kb20gDQogICAgICAgIHBvcnRzLCBhcyBhIG51bWJlciBvZiByYW5kb20gcG9ydHMgYWxsb3dl ZCB0byBiZSB1c2VkIGJ5IHRoZSANCiAgICAgICAgY2xpZW50IGFyZSBwcmVhbGxvY2F0ZWQgYnkg dGhlIHNlcnZlci4gV2hlbiB0aGlzIG1vZGUgaXMgdXNlZCwgDQogICAgICAgIHRoZSBuZXR3b3Jr IGVxdWlwbWVudHMgaW4gY2hhcmdlIG9mIHJvdXRpbmcgdGhlIGluYm91bmQgcGFja2V0cyANCiAg ICAgICAgdG93YXJkcyB0aGUgY2xpZW50cyBtYXkgcmVxdWlyZSBtb3JlIHByb2Nlc3NpbmcgcmVz b3VyY2VzLiANCiAgICANCgoKCgoKCgoKIA0KQmFqa28gICAgICAgICAgICAgICAgICAgRXhwaXJl cyBBdWd1c3QgMywgMjAwOSAgICAgICAgICAgICAgIFtQYWdlIDZdIA0KIAwNCiANClBvcnQgUmVz dHJpY3RlZCBJUCBhZGRyZXNzIGFzc2lnbm1lbnQgICAgICAgICAgICAgICAgICAgICBKYW51YXJ5 IDIwMDkgDQogICAgDQozLiBESENQdjQgT3B0aW9uIGZvciBhbGxvY2F0aW5nIHBvcnQgcmVzdHJp Y3RlZCBwdWJsaWMgSVB2NCBhZGRyZXNzICANCiAgICAgDQogICBUaGlzIHNlY3Rpb24gZGVmaW5l cyBuZXcgREhDUHY0IG9wdGlvbiwgd2hpY2ggYWxsb3dzIGFsbG9jYXRpb24gb2YgDQogICBwb3J0 IHJlc3RyaWN0ZWQgSVB2NCBhZGRyZXNzZXMuICANCiAgICANCiAgIFRoZSBvcHRpb24gbGF5b3V0 IGlzIGRlcGljdGVkIGJlbG93OiAgDQogICAgDQogICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxICANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IE9wdGlvbiBDb2RlICAgfCAgICBs ZW5ndGggICAgIHwgDQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgIHwgICAgICAgICAgICAgICAgICAgICBTdWIt T3B0aW9uIDEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgLiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4gDQog ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKyANCiAgIHwgICAgICAgICAgICAgICAgICAgICAgIC4uLiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgLiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4gDQogICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAg IHwgICAgICAgICAgICAgICAgICAgICBTdWItT3B0aW9uIG4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8IA0KICAgLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC4gDQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgICAgDQogICAgICBPcHRp b24gQ29kZSAgDQogICAgICAgIE9wdGlvbiBDb2RlICAgICAgDQogICAgICAgICAgT1BUSU9OLUlQ djQtUFJBIChUQkQpIC0gMSAgICAgYnl0ZSAgIA0KICAgIA0KICAgICAgICBMZW5ndGggDQogICAg ICAgICAgQW4gOC1iaXQgZmllbGQgaW5kaWNhdGluZyB0aGUgbGVuZ3RoIG9mIHRoZSBvcHRpb24g ZXhjbHVkaW5nIA0KICAgICAgICAgIHRoZSAnT3B0aW9uIENvZGUnIGFuZCB0aGUgJ0xlbmd0aCcg ZmllbGRzICANCiAgICANCiAgICAgICAgU3ViLW9wdGlvbnMgIA0KICAgICAgICAgIEEgc2VyaWVz IG9mIERIQ1B2NCBzdWItb3B0aW9ucy4gIA0KICAgIA0KICAgVGhlIHN1Yi1vcHRpb24gbGF5b3V0 IGlzIGRlcGljdGVkIGJlbG93OiANCiAgICANCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgIA0KICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQog ICB8IFN1Yi1vcHQgVHlwZSAgfCAgICBsZW5ndGggICAgIHwgICAgICAgICAgICAgIERBVEEgICAg ICAgICAgICAgLiANCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KICAgLiAgICAgICAgICAgICAgICAgREFUQSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAg ICANCiAgIFRoZSBzdWItb3B0aW9uIHR5cGVzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBhcmU6 IA0KICAgMSAgICBwb3J0IG1hc2sgDQogICAyICAgIHJhbmRvbSBwb3J0IGRlbGVnYXRpb24gZnVu Y3Rpb24gDQogICAgDQogICBUaGVzZSB0d28gb3B0aW9ucyBhcmUgZXhjbHVzaXZlIHdpdGggZWFj aCBvdGhlciAoaWYgb25lIGlzIHVzZWQsIHRoZSANCiAgIG90aGVyIG9uZSBpcyBub3QpLiANCiAg ICANCiAgICAgIExlbmd0aCANCiAgICAgICAgQW4gOC1iaXQgZmllbGQgaW5kaWNhdGluZyB0aGUg bGVuZ3RoIG9mIHRoZSBzdWItb3B0aW9uIA0KICAgICAgICBleGNsdWRpbmcgdGhlICdTdWItb3B0 IFR5cGUnIGFuZCB0aGUgJ0xlbmd0aCcgZmllbGRzLiBUaGUgdmFsdWUgDQoKIA0KQmFqa28gICAg ICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMywgMjAwOSAgICAgICAgICAgICAgIFtQYWdl IDddIA0KIAwNCiANClBvcnQgUmVzdHJpY3RlZCBJUCBhZGRyZXNzIGFzc2lnbm1lbnQgICAgICAg ICAgICAgICAgICAgICBKYW51YXJ5IDIwMDkgDQogICAgDQogICAgICAgIG9mIHRoZSBsZW5ndGgg ZmllbGQgaXMgOCB3aGVuIHRoZSBTdWItb3B0IFR5cGUgZXF1YWxzIDEgYW5kIDI2IA0KICAgICAg ICB3aGVuIHRoZSBzdWItb3B0IFR5cGUgZXF1YWxzIDIuIA0KICAgVGhlIGZvcm1hdCBvZiB0aGUg REFUQSBmaWVsZCB3aGVuIHRoZSBzdWItb3B0IHR5cGUgaW5kaWNhdGVzIHBvcnQgDQogICBtYXNr ICh2YWx1ZSA9IDEpOiANCiAgICANCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgDQogICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgSVB2NCBhZGRyZXNzICAgICAgICAgICAgICAgICAgICAgICAg ICB8IA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsgDQogICB8ICAgICBQb3J0IFJhbmdlIFZhbHVlICAgICAgICAgIHwg ICAgICAgUG9ydCBSYW5nZSBNYXNrICAgICAgICAgfCANCiAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KICAgIA0KICAg SVB2NCBhZGRyZXNzIA0KICAgICAgICBQdWJsaWMgSVB2NCBhZGRyZXNzIA0KICAgIA0KICAgUG9y dCBSYW5nZSBWYWx1ZSBhbmQgUG9ydCBSYW5nZSBNYXNrIA0KICAgICAgICBQb3J0IFJhbmdlIFZh bHVlIGluZGljYXRlcyB0aGUgdmFsdWUgb2YgdGhlIG1hc2sgdG8gYmUgYXBwbGllZCANCiAgICAg ICAgYW5kIFBvcnQgUmFuZ2UgTWFzayBpbmRpY2F0ZXMgdGhlIHBvc2l0aW9uIG9mIHRoZSBiaXRz IHdoaWNoIA0KICAgICAgICBhcmUgdXNlZCB0byBidWlsZCB0aGUgbWFzay4gDQogICAgDQogICBT ZWN0aW9uIDQgZGVzY3JpYmVzIGhvdyB0aGUgY2xpZW50IGRlcml2ZXMgdGhlIGFsbG9jYXRlZCBw b3J0IHJhbmdlIA0KICAgZnJvbSB0aGUgUG9ydCBSYW5nZSBWYWx1ZSBhbmQgUG9ydCBSYW5nZSBN YXNrIHZhbHVlcy4gDQogICAgDQogICBUaGUgZm9ybWF0IG9mIHRoZSBEQVRBIGZpZWxkIHdoZW4g dGhlIHN1Yi1vcHQgdHlwZSBpbmRpY2F0ZXMgcmFuZG9tIA0KICAgcG9ydCBkZWxlZ2F0aW9uIGZ1 bmN0aW9uICh2YWx1ZSA9IDIpOiANCiAgICANCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgIA0KICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQog ICB8ICAgICAgICAgICAgICAgICAgICAgICAgIElQdjQgYWRkcmVzcyAgICAgICAgICAgICAgICAg ICAgICAgICAgfCANCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KICAgfCAgICAgICAgZnVuY3Rpb24gICAgICAgICAg ICAgICB8ICAgICAgICAgc3RhcnRpbmcgcG9pbnQgICAgICAgIHwgDQogICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAg IHwgICAgbnVtYmVyIG9mIGRlbGVnYXRlZCBwb3J0cyAgfCAgICAgICAgIGtleSBLICAgICAgICAg ICAgICAgLi4uIA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsgDQogICAuLi4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4uLiANCiAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KICAg Li4uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAuLi4gDQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgIC4uLiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLi4uIA0KICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQogICAu Li4ga2V5IEsgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsgDQogICAgDQogICAgDQogICBJUCBhZGRyZXNzICANCiAgICAgICAgUHVi bGljIElQdjQgYWRkcmVzcyAgDQogICAgDQogICBGdW5jdGlvbiANCiAgICAgICAgQSAxNmJpdCBm aWVsZCB3aG9zZSB2YWx1ZSBpcyBhc3NvY2lhdGVkIHdpdGggcHJlZGVmaW5lZCANCiAgICAgICAg ZW5jcnlwdGlvbiBmdW5jdGlvbnMuIFRoaXMgc3BlY2lmaWNhdGlvbiBhc3NvY2lhdGVzIHZhbHVl IDEgDQogICAgICAgIHdpdGggdGhlIHByZWRlZmluZWQgZnVuY3Rpb24gZGVzY3JpYmVkIGluIHNl Y3Rpb24gNS4gDQogICAgDQogDQpCYWprbyAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3Vz dCAzLCAyMDA5ICAgICAgICAgICAgICAgW1BhZ2UgOF0gDQogDA0KIA0KUG9ydCBSZXN0cmljdGVk IElQIGFkZHJlc3MgYXNzaWdubWVudCAgICAgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAwOSAN CiAgICANCiAgIFN0YXJ0aW5nIFBvaW50IA0KICAgICAgICBBIDE2Yml0IHZhbHVlIHVzZWQgYXMg YW4gaW5wdXQgdG8gdGhlIHNwZWNpZmllZCBmdW5jdGlvbiANCiAgICANCiAgICANCiAgIE51bWJl ciBvZiBkZWxlZ2F0ZWQgcG9ydHMgDQogICAgICAgIEEgMTZiaXQgdmFsdWUgc3BlY2lmeWluZyB0 aGUgbnVtYmVyIG9mIHBvcnRzIGRlbGVnYXRlZCB0byB0aGUgDQogICAgICAgIGNsaWVudCBmb3Ig dXNlIGFzIHNvdXJjZSBwb3J0IHZhbHVlcyANCiAgICANCiAgIEtleSBLIA0KICAgICAgICBBIDEy OCBiaXQga2V5IHVzZWQgYXMgaW5wdXQgdG8gdGhlIHByZWRlZmluZWQgZnVuY3Rpb24gZm9yIA0K ICAgICAgICBkZWxlZ2F0ZWQgcG9ydCBjYWxjdWxhdGlvbiANCiAgICANCjQuIFBvcnQgTWFzayBz dWItb3B0aW9uIHVzYWdlIA0KICAgIA0KICAgVGhlIHBvcnQgbWFzayBzdWItb3B0aW9uIGlzIHVz ZWQgdG8gc3BlY2lmeSBvbmUgb3IgbXVsdGlwbGUgcmFuZ2Ugb2YgDQogICBwb3J0cyBwZXJ0YWlu aW5nIHRvIHRoZSBnaXZlbiBJUCBhZGRyZXNzLiAgDQogICAgDQogICBDb25jcmV0ZWx5LCB0aGlz IG9wdGlvbiBpcyB1c2VkIHRvIG5vdGlmeSBhIHJlbW90ZSBESENQIGNsaWVudCBhYm91dCANCiAg IHRoZSBQb3J0IE1hc2sgdG8gYmUgYXBwbGllZCB3aGVuIHNlbGVjdGluZyBhIHBvcnQgdmFsdWUg YXMgYSBzb3VyY2UgDQogICBwb3J0LiBUaGUgUG9ydCBNYXNrIG9wdGlvbiBpcyB1c2VkIHRvIGlu ZmVyIGEgc2V0IG9mIGFsbG93ZWQgcG9ydCANCiAgIHZhbHVlcy4gQSBQb3J0IE1hc2sgZGVmaW5l cyBhIHNldCBvZiBwb3J0cyB0aGF0IGFsbCBoYXZlIGluIGNvbW1vbiBhIA0KICAgc3Vic2V0IG9m IHByZS1wb3NpdGlvbmVkIGJpdHMuIFRoaXMgcG9ydHMgc2V0IGlzIGFsc28gY2FsbGVkIFBvcnQg DQogICBSYW5nZS4gVHdvIHBvcnQgbnVtYmVycyBhcmUgc2FpZCB0byBiZWxvbmcgdG8gdGhlIHNh bWUgUG9ydCBSYW5nZSBpZiANCiAgIGFuZCBvbmx5IGlmLCB0aGV5IGhhdmUgdGhlIHNhbWUgUG9y dCBNYXNrLiANCiAgICANCiAgIEEgUG9ydCBNYXNrIGNvbnRhaW5zIHR3byBmaWVsZHM6IFBvcnQg UmFuZ2UgVmFsdWUgYW5kIFBvcnQgUmFuZ2UgDQogICBNYXNrLiAgDQogICAgDQogICAtIFRoZSAn UG9ydCBSYW5nZSBWYWx1ZScgZmllbGQgaW5kaWNhdGVzIHRoZSB2YWx1ZSBvZiB0aGUgDQogICBz aWduaWZpY2FudCBiaXRzIG9mIHRoZSBQb3J0IE1hc2suIFRoZSAuUG9ydCBSYW5nZSBWYWx1ZS4g aXMgY29kZWQgDQogICBhcyBmb2xsb3dzOiAgDQogICAgICAgICAgIC0gVGhlIHNpZ25pZmljYW50 IGJpdHMgYXJlIHRob3NlIHdoZXJlICIxIiB2YWx1ZXMgYXJlIHNldCBpbiANCiAgIHRoZSBQb3J0 IFJhbmdlIE1hc2suIFRoZXNlIGJpdHMgbWF5IHRha2UgYSB2YWx1ZSBvZiAiMCIgb3IgIjEgIi4g IA0KICAgICAgICAgICAtIEFsbCB0aGUgb3RoZXIgYml0cyAobm9uIHNpZ25pZmljYW50IG9uZXMp IGFyZSBzZXQgdG8gIjAiLiANCiAgICANCiAgIC0gVGhlICdQb3J0IFJhbmdlIE1hc2snIGZpZWxk IGluZGljYXRlcyB0aGUgcG9zaXRpb24gb2YgdGhlIA0KICAgc2lnbmlmaWNhbnQgYml0cyBpZGVu dGlmaWVkIGJ5IHRoZSBiaXQocykgc2V0IHRvICIxIi4gDQogICAgDQogICBUaGUgUG9ydCBSYW5n ZSBWYWx1ZSBmaWVsZCBpbmRpY2F0ZXMgdGhlIHZhbHVlIG9mIHRoZSBtYXNrIHRvIGJlIA0KICAg YXBwbGllZCBhbmQgdGhlIFBvcnQgUmFuZ2UgTWFzayBmaWVsZCBpbmRpY2F0ZXMgdGhlIHBvc2l0 aW9uIG9mIHRoZSANCiAgIGJpdHMgd2hpY2ggYXJlIHVzZWQgdG8gYnVpbGQgdGhlIG1hc2suIFRo ZSAiMSIgdmFsdWVzIGluIHRoZSBQb3J0IA0KICAgUmFuZ2UgTWFzayBmaWVsZCBpbmRpY2F0ZSBi eSB0aGVpciBwb3NpdGlvbiB0aGUgc2lnbmlmaWNhbnQgYml0cyBvZiANCiAgIHRoZSBQb3J0IFJh bmdlIFZhbHVlICh0aGUgcGF0dGVybiBvZiB0aGUgUG9ydCBSYW5nZSBWYWx1ZSkuIA0KICAgIA0K ICAgRm9yIGV4YW1wbGU6IA0KICAgICAgICAtIEEgUG9ydCBSYW5nZSBNYXNrIGZpZWxkIGVxdWFs IHRvIDEwMDAwMDAwMDAwMDAwMDAgaW5kaWNhdGVzIA0KICAgICAgICB0aGF0IHRoZSBmaXJzdCBi aXQgKHRoZSBtb3N0IHNpZ25pZmljYW50IG9uZSkgaXMgdXNlZCBhcyBhIA0KICAgICAgICBwYXR0 ZXJuIG9mIHRoZSBQb3J0IFJhbmdlIFZhbHVlIGZpZWxkOyANCiAgICAgICAgIA0KICAgICAgICAt IEEgUG9ydCBSYW5nZSBNYXNrIGZpZWxkIGVxdWFsIHRvIDAwMDAxMDEwMDAwMDAwMDAgaW5kaWNh dGVzIA0KICAgICAgICB0aGF0IHRoZSA1dGggYW5kIHRoZSA3dGggbW9zdCBzaWduaWZpY2FudCBi aXRzIGFyZSB1c2VkIGFzIGEgDQogICAgICAgIHBhdHRlcm4gb2YgdGhlIFBvcnQgUmFuZ2UgVmFs dWUuIA0KIA0KQmFqa28gICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMywgMjAwOSAg ICAgICAgICAgICAgIFtQYWdlIDldIA0KIAwNCiANClBvcnQgUmVzdHJpY3RlZCBJUCBhZGRyZXNz IGFzc2lnbm1lbnQgICAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDkgDQogICAgDQogICAg DQogICBUaGUgcGF0dGVybiBvZiB0aGUgUG9ydCBSYW5nZSBWYWx1ZSBpcyBhbGwgdGhlIGZpeGVk IGJpdHMgaW4gdGhlIA0KICAgUG9ydCBSYW5nZSBWYWx1ZS4gQWxsIHRoZSBwb3J0cyB0aGUgQ1BF IGlzIGFsbG93ZWQgdG8gdXNlIGFzIHNvdXJjZSANCiAgIHBvcnRzIG11c3QgaGF2ZSB0aGVpciBu dW1iZXIgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBwYXR0ZXJuLiANCiAgICANCiAgIFRoZSBQb3J0 IFJhbmdlIFZhbHVlIGlzIGNvZGVkIGFzIGZvbGxvd3M6IA0KICAgICAgICAtIFRoZSBwYXR0ZXJu IGJpdHMgb2YgdGhlIFBvcnQgUmFuZ2UgVmFsdWUgYXJlIHRob3NlIHdoZXJlICIxIiANCiAgICAg ICAgdmFsdWVzIGFyZSBzZXQgaW4gdGhlIFBvcnQgUmFuZ2UgTWFzay4gIFRoZXNlIGJpdHMgbWF5 IHRha2UgYSANCiAgICAgICAgdmFsdWUgb2YgMCBvciAxLiANCiAgICAgICAgLSBBbGwgdGhlIG90 aGVyIGJpdHMgYXJlIHNldCB0byAiMCIuIA0KICAgICAgICAgDQo0LjEgSWxsdXN0cmF0aW9uIEV4 YW1wbGVzIA0KICAgIA0KICAgSW4gZWFjaCBvZiB0aGUgdGhyZWUgZXhhbXBsZXMgYmVsb3cgYWxs b2NhdGlvbiBvZiAyMDQ4IHBvcnRzIGlzIGRvbmUgDQogICBkaWZmZXJlbnRseS4gSW4gYWxsIGV4 YW1wbGVzIGl0IGlzIHBvc3NpYmxlIGZvciAzMiBob3N0cyB0byBzaGFyZSANCiAgIHRoZSBzYW1l IHB1YmxpYyBJUHY0IGFkZHJlc3MuIFRoZSA0dGggZXhhbXBsZSBpbGx1c3RyYXRlcyB0aGUgDQog ICBhYmlsaXR5IG9mIHRoZSBwcm9jZWR1cmUgdG8gZW5mb3JjZSBhIGJhbGFuY2VkIGRpc3RyaWJ1 dGlvbiBvZiBwb3J0IA0KICAgbnVtYmVycyBpbmNsdWRpbmcgdGhlIHdlbGwta25vd24tcG9ydCB2 YWx1ZXMuIA0KIA0KICAgYSkgdGhlIGZvbGxvd2luZyBQb3J0IFJhbmdlIE1hc2sgYW5kIFBvcnQg UmFuZ2UgVmFsdWUgYXJlIGNvbnZleWVkIA0KICAgdXNpbmcgREhDUCB0byBhc3NpZ24gYSBQb3J0 IFJhbmdlIChmcm9tIDIwNDggdG8gNDA5NSkgdG8gYSBnaXZlbiANCiAgIGRldmljZTogDQogICAg ICAgIC0gUG9ydCBSYW5nZSBWYWx1ZTogMDAwMDEwMDAwMDAwMDAwMCAoMjA0OCkgDQogICAgICAg IC0gUG9ydCBSYW5nZSBNYXNrOiAxMTExMTAwMDAwMDAwMDAwICg2MzQ4OCkgDQogICAgDQogICBi KSBVbmxpa2UgdGhlIHByZXZpb3VzIGV4YW1wbGUsIHRoaXMgb25lIGlsbHVzdHJhdGVzIHRoZSBj YXNlIHdoZXJlIA0KICAgYSBub24gQ29udGludW91cyBQb3J0IFJhbmdlIGlzIGFzc2lnbmVkIHRv IGEgZ2l2ZW4gY3VzdG9tZXIncyANCiAgIGRldmljZS4gSW4gdGhpcyBleGFtcGxlLCB0aGUgUG9y dCBSYW5nZSBWYWx1ZSBkZWZpbmVzIDEyOCBDb250aW51b3VzIA0KICAgUG9ydCBSYW5nZXMsIGVh Y2ggb25lIHdpdGggYSBsZW5ndGggb2YgMTYgcG9ydCB2YWx1ZXMuICBOb3RlIHRoYXQgDQogICB0 aGUgdHdvIGZpcnN0IFBvcnQgUmFuZ2VzIGFyZSBib3RoIGluIHRoZSB3ZWxsLWtub3duIHBvcnRz IHNwYW4gDQogICAoaS5lLiAwLTEwMjMpIGJ1dCB0aGVzZSB0d28gcmFuZ2VzIGFyZSBub3QgYWRq YWNlbnQuIA0KICAgIA0KICAgVGhlIGZvbGxvd2luZyBQb3J0IFJhbmdlIE1hc2sgYW5kIFBvcnQg UmFuZ2UgVmFsdWUgYXJlIGNvbnZleWVkIGluIA0KICAgREhDUCBtZXNzYWdlczogDQogICAgICAg IC0gUG9ydCBSYW5nZSBWYWx1ZSA6IDAwMDAwMDAwMDEwMTAwMDAgKDgwKSANCiAgICAgICAgLSBQ b3J0IFJhbmdlIE1hc2sgOiAwMDAwMDAwMTExMTEwMDAwICg0OTYpIA0KICAgIA0KICAgVGhpcyBt ZWFucyB0aGF0IHRoZSAxMjggZm9sbG93aW5nIENvbnRpbnVvdXMgUG9ydCBSYW5nZXMgYXJlIA0K ICAgYXNzaWduZWQgdG8gdGhlIHNhbWUgZGV2aWNlOiANCiAgICAgICAgLSBmcm9tIDgwIHRvIDk1 IA0KICAgICAgICAtIGZyb20gNTkyIHRvIDYwNyANCiAgICAgICAgLSAuLi4gDQogICAgICAgIC0g ZnJvbSA2NTEwNCB0byA2NTExOSANCiAgICANCiAgIGMpIEluIHRoaXMgZXhhbXBsZSwgdGhlIFBv cnQgUmFuZ2UgVmFsdWUgZGVmaW5lcyB0d28gQ29udGludW91cyBQb3J0IA0KICAgUmFuZ2VzLCBl YWNoIG9uZSBiZWluZyAxMDI0IHBvcnRzIGxvbmc6IA0KICAgIA0KICAgICAgICAtIFBvcnQgUmFu Z2UgVmFsdWUgOiAwMDAwMDAwMDAwMDAwMDAwICgwKSANCiAgICAgICAgLSBQb3J0IFJhbmdlIE1h c2sgOiAxMTExMDEwMDAwMDAwMDAwICg2MjQ2NCkgDQogICAgDQogICBUaGlzIG1lYW5zIHRoYXQg dGhlIHR3byBmb2xsb3dpbmcgQ29udGludW91cyBQb3J0IFJhbmdlcyBhcmUgDQogICBhc3NpZ25l ZCB0byB0aGUgc2FtZSBkZXZpY2U6IA0KIA0KQmFqa28gICAgICAgICAgICAgICAgICAgRXhwaXJl cyBBdWd1c3QgMywgMjAwOSAgICAgICAgICAgICAgW1BhZ2UgMTBdIA0KIAwNCiANClBvcnQgUmVz dHJpY3RlZCBJUCBhZGRyZXNzIGFzc2lnbm1lbnQgICAgICAgICAgICAgICAgICAgICBKYW51YXJ5 IDIwMDkgDQogICAgDQogICAgICAgIC0gZnJvbSAwIHRvIDEwMjMsIGFuZCANCiAgICAgICAgLSBm cm9tIDIwNDggdG8gMzA3MSANCiAgICANCiAgIGQpIEluIHRoaXMgZXhhbXBsZSwgNjQgY29udGlu dW91cyBQb3J0IFJhbmdlcyBhcmUgYWxsb2NhdGVkIHRvIGVhY2ggDQogICBDUEUgKGFtb25nIGEg c2V0IG9mIDQgQ1BFcyBzaGFyaW5nIHRoZSBzYW1lIElQdjQgYWRkcmVzcykuIA0KICAgIA0KICAg QW1vbmcgdGhlIDY0IGNvbnRpbnVvdXMgUG9ydCBSYW5nZXMgdG8gZWFjaCBDUEUsIHRoZXJlIGlz IGFsd2F5cyBvbmUgDQogICB3aXRoaW4gdGhlIHNwYW4gb2YgdGhlIGZpcnN0IDEwMjQgd2VsbC1r bm93biBwb3J0IHZhbHVlcy4gSGVyZWFmdGVyIA0KICAgaXMgZ2l2ZW4gdGhlIFBvcnQgUmFuZ2Ug VmFsdWUgYW5kIFBvcnQgUmFuZ2UgTWFzayBhc3NpZ25lZCB0byAyIENQRXMgDQogICAoQ1BFIzAg YW5kIENQRSMzLCBDUEUjMSBhbmQgQ1BFIzIgYmVpbmcgbm90IHJlcHJlc2VudGVkIGhlcmUpOiAN CiAgICANCiAgIDEuICBDUEUjMCANCiAgICANCiAgICAgICAgLSBQb3J0IFJhbmdlIFZhbHVlOiAw MDAwMDAwMDAwMDAwMDAwICgwKSANCiAgICAgICAgLSBQb3J0IFJhbmdlIE1hc2s6ICAwMDAwMDAx MTAwMDAwMDAwICg3NjgpIA0KICAgIA0KICAgVGhlIENQRSMwIGhhcyB0aGVyZWZvcmUgdGhlIDY0 IGZvbGxvd2luZyBDb250aW51b3VzIFBvcnQgUmFuZ2VzOiANCiAgICAgICAgLSAxc3QgcmFuZ2U6 IDAtMjU1IA0KICAgICAgICAtIC4uLiANCiAgICAgICAgLSA2NHRoIHJhbmdlOiA2NDUxMi02NDc2 NyANCiAgICANCiAgIDIuICBDUEUjMyANCiAgICANCiAgICAgICAgLSBQb3J0IFJhbmdlIFZhbHVl OiAwMDAwMDAxMTAwMDAwMDAwICg3NjgpIA0KICAgICAgICAtIFBvcnQgUmFuZ2UgTWFzazogIDAw MDAwMDExMDAwMDAwMDAgKDc2OCkgDQogICAgDQogICBUaGUgQ1BFIzIgaGFzIHRoZXJlZm9yZSB0 aGUgNjQgZm9sbG93aW5nIENvbnRpbnVvdXMgUG9ydCBSYW5nZXM6IA0KICAgICAgICAtIDFzdCBy YW5nZTogNzY4LTEwMjMgDQogICAgICAgIC0gLi4uIA0KICAgICAgICAtIDY0dGggcmFuZ2U6IDY1 MjgwLTY1NTM1IA0KICAgIA0KNS4gUmFuZG9tIFBvcnQgZGVsZWdhdGlvbiBmdW5jdGlvbiANCiAg ICANCiAgIERlbGVnYXRpbmcgcmFuZG9tIHBvcnRzIGNhbiBiZSBhY2hpZXZlZCBieSBkZWZpbmlu ZyBhIGZ1bmN0aW9uIHdoaWNoIA0KICAgdGFrZXMgYXMgaW5wdXQgYSBrZXkgJ2snIGFuZCBhbiBp bnRlZ2VyICd4JyB3aXRoaW4gdGhlIHJhbmdlICgxMDI0LCANCiAgIDY1NTM1KSBhbmQgcHJvZHVj ZXMgYW4gb3V0cHV0ICd5JyBhbHNvIHdpdGhpbiB0aGUgcmFuZ2UgKDEwMjQsIA0KICAgNjU1MzUp LiAgDQogICAgDQogICBUaGUgc2VydmVyIHVzZXMgYSBjcnlwdG9ncmFwaGljYWwgbWVjaGFuaXNt IChkZXNjcmliZWQgYmVsb3cpIHRvIA0KICAgc2VsZWN0IHRoZSByYW5kb20gcG9ydHMgZm9yIGVh Y2ggaG9zdC4gSW5zdGVhZCBvZiBhc3NpZ25pbmcgYSByYW5nZSANCiAgIG9mIHBvcnRzIHVzaW5n IHBvcnQgbWFzayB0byB0aGUgY2xpZW50LCB0aGUgc2VydmVyIHNlbmRzIHRoZSBpbnB1dHMgDQog ICBvZiBhIHByZWRlZmluZWQgY3J5cHRvZ3JhcGhpYyBtZWNoYW5pc206IGEga2V5LCBhbiBpbml0 aWFsIHZhbHVlLCANCiAgIGFuZCB0aGUgbnVtYmVyIG9mIHBvcnRzIGFzc2lnbmVkIHRvIHRoaXMg aG9zdC4gVGhlIGNsaWVudCBjYW4gdGhlbiANCiAgIGNhbGN1bGF0ZSB0aGUgZnVsbCBsaXN0IG9m IGFzc2lnbmVkIHBvcnRzIGl0c2VsZi4gDQogICAgDQogICBUaGUgY3J5cHRvZ3JhcGhpY2FsIG1l Y2hhbmlzbSBlbnN1cmVzIHRoYXQgdGhlIGVudGlyZSA2NGsgcG9ydCByYW5nZSANCiAgIGNhbiBi ZSBlZmZpY2llbnRseSBkaXN0cmlidXRlZCB0byBtdWx0aXBsZSBob3N0cyBpbiBhIHdheSB0aGF0 IHdoZW4gDQogICBob3N0cyBjYWxjdWxhdGUgdGhlIHBvcnRzLCB0aGUgcmVzdWx0cyB3aWxsIG5l dmVyIG92ZXJsYXAgd2l0aCBwb3J0cyANCiAgIG90aGVyIGhvc3RzIGhhdmUgY2FsY3VsYXRlZCAo cHJvcGVydHkgb2YgcGVybXV0YXRpb24pLCBhbmQgcG9ydHMgaW4gDQogICB0aGUgcmVzZXJ2ZWQg cmFuZ2UgKHNtYWxsZXIgdGhhbiAxMDI0KSBhcmUgbm90IHVzZWQuIEFzIHRoZSANCiAgIHJhbmRv bWl6YXRpb24gaXMgZG9uZSBjcnlwdGhvZ3JhcGhpY2FsbHksIGFuIGF0dGFja2VyIHNlZWluZyBh IGhvc3QgDQoKIA0KQmFqa28gICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMywgMjAw OSAgICAgICAgICAgICAgW1BhZ2UgMTFdIA0KIAwNCiANClBvcnQgUmVzdHJpY3RlZCBJUCBhZGRy ZXNzIGFzc2lnbm1lbnQgICAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDkgDQogICAgDQog ICB1c2luZyBzb21lIHBvcnQgWCBjYW5ub3QgZGV0ZXJtaW5lIHdoaWNoIG90aGVyIHBvcnRzIHRo ZSBob3N0IG1heSBiZSANCiAgIHVzaW5nIChhcyB0aGUgYXR0YWNrZXIgZG9lcyBub3Qga25vdyB0 aGUga2V5KS4gDQogICAgDQogICBDYWxjdWxhdGlvbiBvZiB0aGUgcmFuZG9tIHBvcnQgbGlzdCBp cyBkb25lIGFzIGZvbGxvd3M6ICANCiAgICANCiAgIFRoZSBjcnlwdG9ncmFwaGljIG1lY2hhbmlz bSB1c2VzIGFuIGVuY3J5cHRpb24gZnVuY3Rpb24geSA9IEUoSyx4KSANCiAgIHRoYXQgdGFrZXMg YXMgaW5wdXQgYSBrZXkgSyAoZm9yIGV4YW1wbGUsIDEyOCBiaXRzKSBhbmQgYW4gaW50ZWdlciB4 IA0KICAgKHRoZSBwbGFpbnRleHQpIGluIHJhbmdlICgxMDI0LCA2NTUzNSksIGFuZCBwcm9kdWNl cyBhbiBvdXRwdXQgeSANCiAgICh0aGUgY2lwaGVydGV4dCksIGFsc28gYW4gaW50ZWdlciBpbiBy YW5nZSAoMTAyNCwgNjU1MzUpLiBUaGlzIA0KICAgc2VjdGlvbiBkZXNjcmliZXMgb25lIHN1Y2gg ZW5jcnlwdGlvbiBmdW5jdGlvbiwgYnV0IG90aGVycyBhcmUgYWxzbyANCiAgIHBvc3NpYmxlLiAN CiAgICANCiAgIFRoZSBzZXJ2ZXIgd2lsbCBzZWxlY3QgdGhlIGtleSBLLiBXaGVuIHNlcnZlciB3 YW50cyB0byBhbGxvY2F0ZSBlLmcuIA0KICAgMjA0OCByYW5kb20gcG9ydHMsIGl0IHNlbGVjdHMg YSBzdGFydGluZyBwb2ludCAnYScgKDEwMjQgPD0gYSA8PSANCiAgIDY1NTM2LTIwNDgpIGluIGEg d2F5IHRoYXQgdGhlIHJhbmdlIChhLCBhKzIwNDgpIGRvZXMgbm90IG92ZXJsYXAgDQogICB3aXRo IGFueSBvdGhlciBhY3RpdmUgY2xpZW50LCBhbmQgY2FsY3VsYXRlcyB0aGUgdmFsdWVzIEUoSyxh KSwgDQogICBFKEssYSsxKSwgRShLLGErMiksIC4uLiwgRShLLGErMjA0NiksIEUoSyxhKzIwNDcp LiBUaGVzZSBhcmUgdGhlIA0KICAgcG9ydCBudW1iZXJzIGFsbG9jYXRlZCBmb3IgdGhpcyBob3N0 LiBJbnN0ZWFkIG9mIHNlbmRpbmcgdGhlIHBvcnQgDQogICBudW1iZXJzIGluZGl2aWR1YWxseSwg dGhlIHNlcnZlciBqdXN0IHNlbmRzIHRoZSB2YWx1ZXMgJ0snLCAnIGEnLCANCiAgIGFuZCAnMjA0 OCcuIFRoZSBjbGllbnQgd2lsbCB0aGVuIHJlcGVhdCB0aGUgc2FtZSBjYWxjdWxhdGlvbi4gDQog ICAgDQogICBUaGUgc2VydmVyIFNIT1VMRCB1c2UgZGlmZmVyZW50IEsgZm9yIGVhY2ggSVB2NCBh ZGRyZXNzIGl0IGFsbG9jYXRlcyANCiAgIHRvIG1ha2UgYXR0YWNrcyBhcyBkaWZmaWN1bHQgYXMg cG9zc2libGUuIFRoaXMgd2F5LCBsZWFybmluZyB0aGUgSyANCiAgIHVzZWQgaW4gSVB2NCBhZGRy ZXNzIElQMSB3b3VsZCBub3QgaGVscCBpbiBhdHRhY2tpbmcgSVB2NCBhZGRyZXNzIA0KICAgSVAy IHRoYXQgaXMgYWxsb2NhdGVkIGJ5IHRoZSBzYW1lIHNlcnZlciB0byBkaWZmZXJlbnQgaG9zdHMu IA0KICAgIA0KICAgV2l0aCB0eXBpY2FsIGVuY3J5cHRpb24gZnVuY3Rpb25zIChzdWNoIGFzIEFF UyBhbmQgREVTKSwgdGhlIGlucHV0IA0KICAgKHBsYWludGV4dCkgYW5kIG91dHB1dCAoY2lwaGVy dGV4dCkgYXJlIGJsb2NrcyBvZiBzb21lIGZpeGVkIHNpemU7IA0KICAgZm9yIGV4YW1wbGUsIDEy OCBiaXRzIGZvciBBRVMsIGFuZCA2NCBiaXRzIGZvciBERVMuIEZvciBwb3J0IA0KICAgcmFuZG9t aXphdGlvbiwgd2UgbmVlZCBhbiBlbmNyeXB0aW9uIGZ1bmN0aW9uIHdob3NlIGlucHV0IGFuZCBv dXRwdXQgDQogICBpcyBhbiBpbnRlZ2VyIGluIHJhbmdlICgxMDI0LCA2NTUzNSkuIA0KICAgIA0K ICAgT25lIHBvc3NpYmxlIHdheSB0byBkbyB0aGlzIGlzIHRvIHVzZSB0aGUgJ0dlbmVyYWxpemVk LUZlaXN0ZWwgDQogICBDaXBoZXInIFtDSVBIRVJTXSBjb25zdHJ1Y3Rpb24gYnkgQmxhY2sgYW5k IFJvZ2F3YXksIHdpdGggQUVTIGFzIHRoZSANCiAgIHVuZGVybHlpbmcgcm91bmQgZnVuY3Rpb24u IA0KICAgIA0KICAgVGhpcyB3b3VsZCBsb29rIGFzIGZvbGxvd3MgKHVzaW5nIHBzZXVkby1jb2Rl KTogIA0KICAgIA0KICAgICAgICBkZWYgRShrLCB4KTogDQogICAgICAgICAgICB5ID0gRmVpc3Rl bDE2KGssIHgpIA0KICAgICAgICAgICAgaWYgeSA+PSAxMDI0OiANCiAgICAgICAgICAgICAgICAg IHJldHVybiB5IA0KICAgICAgICAgICAgZWxzZTogDQogICAgICAgICAgICAgICAgICByZXR1cm4g RShrLCB5KSANCiAgICANCiAgIE5vdGUgdGhhdCBhbHRob3VnaCBFKGsseCkgaXMgcmVjdXJzaXZl LCBpdCBpcyBndWFyYW50ZWVkIHRvIA0KICAgdGVybWluYXRlLiBUaGUgYXZlcmFnZSBudW1iZXIg b2YgaXRlcmF0aW9ucyBpcyBqdXN0IHNsaWdodGx5IG92ZXIgMS4gDQogICAgDQogICBGZWlzdGVs MTYgaXMgYSAxNi1iaXQgYmxvY2sgY2lwaGVyOiANCiAgICANCiAgICAgICAgZGVmIEZlaXN0ZWwx NihrLCB4KTogDQogICAgICAgICAgICBsZWZ0ID0geCAmIDB4ZmYgDQogDQpCYWprbyAgICAgICAg ICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAzLCAyMDA5ICAgICAgICAgICAgICBbUGFnZSAxMl0g DQogDA0KIA0KUG9ydCBSZXN0cmljdGVkIElQIGFkZHJlc3MgYXNzaWdubWVudCAgICAgICAgICAg ICAgICAgICAgIEphbnVhcnkgMjAwOSANCiAgICANCiAgICAgICAgICAgIHJpZ2h0ID0geCA+PiA4 IA0KICAgICAgICAgICAgZm9yIHJvdW5kID0gMSB0byAzOiANCiAgICAgICAgICAgICAgICB0ZW1w ID0gKGxlZnQgKyBGZWlzdGVsUm91bmQoaywgcm91bmQsIHJpZ2h0KSkgJiAweGZmIA0KICAgICAg ICAgICAgICAgIGxlZnQgPSByaWdodCANCiAgICAgICAgICAgICAgICByaWdodCA9IHRlbXAgDQog ICAgICAgICAgICByZXR1cm4gKHJpZ2h0IDw8IDgpIHwgbGVmdCANCiAgICANCiAgIFRoZSBGZWlz dGVsIHJvdW5kIGZ1bmN0aW9uIHVzZXM6IA0KICAgIA0KICAgICAgICBkZWYgRmVpc3RlbFJvdW5k KGssIHJvdW5kLCB4KTogDQogICAgICAgICAgICBtc2dbMF0gPSByb3VuZCANCiAgICAgICAgICAg IG1zZ1sxXSA9IHggPj4gOCANCiAgICAgICAgICAgIG1zZ1syXSA9IHggJiAweGZmIA0KICAgICAg ICAgICAgbXNnWzMuLi4xNV0gPSAwIA0KICAgICAgICAgICAgcmV0dXJuIEFFUyhrLCBtc2cpIA0K ICAgIA0KICAgUGVyZm9ybWFuY2U6IFRvIGdlbmVyYXRlIGxpc3Qgb2YgMjA0OCBwb3J0IG51bWJl cnMsIGFib3V0IDYwMDAgY2FsbHMgDQogICB0byBBRVMgYXJlIHJlcXVpcmVkIChpLmUuLCBlbmNy eXB0aW5nIDk2IGtpbG9ieXRlcykuIFRodXMsIGl0IHdpbGwgDQogICBub3QgYmUgYSBwcm9ibGVt IGZvciBhbnkgZGV2aWNlIHRoYXQgY2FuIGRvLCBmb3IgZXhhbXBsZSwgSFRUUFMgKHdlYiANCiAg IGJyb3dzaW5nIG92ZXIgU1NML1RMUykuIA0KICAgIA0KICAgT3RoZXIgcG9ydCBnZW5lcmF0b3Ig ZnVuY3Rpb25zIG1heSBiZSBwcmVkZWZpbmVkIGluIFN0YW5kYXJkcyBUcmFjayANCiAgIGRvY3Vt ZW50cyBhbmQgYWxsb2NhdGVkIGEgbm90IHlldCBhbGxvY2F0ZWQgJ2Z1bmN0aW9uJyB2YWx1ZSB3 aXRoaW4gDQogICB0aGUgY29ycmVzcG9uZGluZyBzdWItb3B0aW9uIHR5cGUgZmllbGQuIA0KICAg IA0KNi4gT3B0aW9uIFVzYWdlICANCiAgICAgICAgDQo2LjEgQ2xpZW50IEJlaGF2aW91ciAgDQog ICAgICAgIA0KICAgQSBESENQIGNsaWVudCB3aGljaCBzdXBwb3J0cyB0aGUgb3B0aW9uIGRlZmlu ZWQgaW4gdGhpcyBkb2N1bWVudCANCiAgIE1VU1Qgc3VwcG9ydCBib3RoIHN1Yi1vcHRpb24gdHlw ZXMuIA0KICAgIA0KICAgQSBESENQIGNsaWVudCB3aGljaCBzdXBwb3J0cyB0aGUgZXh0ZW5zaW9u cyBkZWZpbmVkIGluIHRoaXMgDQogICBkb2N1bWVudCwgU0hPVUxEIGluc2VydCB0aGUgb3B0aW9u IE9QVElPTi1JUHY0LVBSQSB3aXRoIGJvdGggc3ViLQ0KICAgb3B0aW9uIHR5cGVzIGludG8gREhD UERJU0NPVkVSIG1lc3NhZ2UgdG8gZXhwbGljaXRseSBsZXQgdGhlIHNlcnZlciANCiAgIGtub3cg dGhhdCBpdCBzdXBwb3J0cyBwb3J0IHJlc3RyaWN0ZWQgSVB2NCBhZGRyZXNzZXMuIA0KICAgICAg byBJbiB0aGUgcG9ydCBtYXNrIHN1Yi1vcHRpb24gdHlwZSwgdGhlIGNsaWVudCBTSEFMTCBzZXQg dGhlIElQdjQgDQogICAgICAgIGFkZHJlc3MgYW5kIE1hc2sgTG9jYXRvciBmaWVsZHMgdG8gYWxs IHplcm9zLiBUaGUgY2xpZW50IE1BWSANCiAgICAgICAgaW5kaWNhdGUgdGhlIG51bWJlciBvZiBk ZXNpcmVkIHBvcnRzIGluIFBvcnQgUmFuZ2UgVmFsdWUtZmllbGQsIA0KICAgICAgICBvciBzZXQg dGhhdCB0byBhbGwgemVyb2VzLiANCiAgICAgIG8gSW4gdGhlIHJhbmRvbSBwb3J0IGRlbGVnYXRp b24gc3ViLW9wdGlvbiB0eXBlLCB0aGUgY2xpZW50IFNIQUxMIA0KICAgICAgICBzZXQgdGhlIElQ djQgYWRkcmVzcyBmaWVsZCwga2V5IGZpZWxkIGFuZCBzdGFydGluZyBwb2ludCBmaWVsZCANCiAg ICAgICAgdG8gYWxsIHplcm9zLiBUaGUgY2xpZW50IE1BWSBpbmRpY2F0ZSBpbiBmdW5jdGlvbiBm aWVsZCB3aGljaCANCiAgICAgICAgZW5jcnlwdGlvbiBmdW5jdGlvbiBpdCBwcmVmZXJzLCBhbmQg aW4gdGhlIG51bWJlciBvZiBkZWxlZ2F0ZWQgDQogICAgICAgIHBvcnRzIGZpZWxkIHRoZSBudW1i ZXIgb2YgcG9ydHMgdGhlIGNsaWVudCB3b3VsZCBkZXNpcmUuIA0KICAgICAgDQogICBXaGVuIGEg Y2xpZW50LCB3aGljaCBzdXBwb3J0cyB0aGUgb3B0aW9uIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVu dCwgDQogICByZWNlaXZlcyBhIERIQ1BPRkZFUiB3aXRoIHRoZSAneWlhZGRyJyAoY2xpZW50IElQ IGFkZHJlc3MpIGZpZWxkIHNldCANCiAgIHRvIDAuMC4wLjAsIGl0IFNIT1VMRCBjaGVjayBmb3Ig dGhlIHByZXNlbmNlIG9mIE9QVElPTi1JUHY0LVBSQSANCiAgIG9wdGlvbi4gSWYgc3VjaCBhbiBv cHRpb24gaXMgcHJlc2VudCwgdGhlIGNsaWVudCBNQVkgc2VuZCBhIA0KICAgREhDUFJFUVVFU1Qg bWVzc2FnZSBhbmQgaW5zZXJ0IHRoZSBvcHRpb24gT1BUSU9OLUlQdjQtUFJBIHdpdGggdGhlIA0K ICAgY29ycmVzcG9uZGluZyBzdWItb3B0aW9ucyByZWNlaXZlZCBpbiB0aGUgT1BUSU9OLUlQdjQt UFJBIG9wdGlvbiBvZiANCiANCkJhamtvICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0 IDMsIDIwMDkgICAgICAgICAgICAgIFtQYWdlIDEzXSANCiAMDQogDQpQb3J0IFJlc3RyaWN0ZWQg SVAgYWRkcmVzcyBhc3NpZ25tZW50ICAgICAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDA5IA0K ICAgIA0KICAgdGhlIHByZXZpb3VzIERIQ1BPRkZFUi4gVGhlIGNsaWVudCBNVVNUIE5PVCBpbmNs dWRlIGEgJ1JlcXVlc3RlZCBJUCANCiAgIEFkZHJlc3MnIERIQ1Agb3B0aW9uIChjb2RlIDUwKSBp bnRvIHRoaXMgREhDUFJFUVVFU1QuICANCiAgICAgICAgDQogICBUaGUgY2xpZW50IE1VU1QgTk9U IGluc2VydCB0aGUgSVAgYWRkcmVzcyByZWNlaXZlZCBpbiBPUFRJT04tSVB2NC0NCiAgIFBSQSBp bnRvIHRoZSAnUmVxdWVzdGVkIElQIEFkZHJlc3MnIERIQ1Agb3B0aW9uIChjb2RlIDUwKS4gV2hl biB0aGUgDQogICBjbGllbnQgcmVjZWl2ZXMgYSBESENQQUNLIG1lc3NhZ2Ugd2l0aCBhbiBPUFRJ T04tSVB2NC1QUkEgb3B0aW9uLCBpdCANCiAgIE1BWSBzdGFydCB1c2luZyB0aGUgc3BlY2lmaWVk IElQIGFkZHJlc3MgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgDQogICBzb3VyY2UgcG9ydHMgc3Bl Y2lmaWVkIGJ5IHRoZSBtZWNoYW5pc20gY2hvc2VuIGJ5IERIQ1Agc2VydmVyLiBUaGUgDQogICBj bGllbnQgTVVTVCBOT1QgdXNlIHRoZSBJUCBhZGRyZXNzIHdpdGggZGlmZmVyZW50IHNvdXJjZSBw b3J0IA0KICAgbnVtYmVycywgYXMgdGhhdCBtYXkgcmVzdWx0IGluIGEgY29uZmxpY3QsIHNpbmNl IHRoZSBzYW1lIElQIGFkZHJlc3MgDQogICB3aXRoIGEgZGlmZmVyZW50IHNvdXJjZSBwb3J0IGdy b3VwIG1heSBiZSBhc3NpZ25lZCB0byBhIGRpZmZlcmVudCANCiAgIGNsaWVudC4gRnVydGhlcm1v cmUsIHRoZSBjbGllbnQgTVVTVCBub3RpY2UgdGhlIHNpdHVhdGlvbiB3aGVyZSBhbiANCiAgIG91 dGdvaW5nIElQIHBhY2tldCBoYXMgdGhlIHNhbWUgSVAgYWRkcmVzcyBhcyBkZXN0aW5hdGlvbiBh ZGRyZXNzIA0KICAgdGhhbiB0aGUgY2xpZW50IGl0c2VsZiBoYXMsIGJ1dCB0aGUgcG9ydCBudW1i ZXIgaXMgbm90IGJlbG9uZ2luZyB0byANCiAgIHRoZSBhbGxvY2F0ZWQgc2V0LiBJbiB0aGlzIGNh c2UgdGhlIGNsaWVudCBNVVNUIGRldGVjdCB0aGF0IHRoZSANCiAgIHBhY2tldCBpcyBub3QgZGVz dGluZWQgZm9yIGl0c2VsZiwgYW5kIGl0IE1VU1Qgc2VuZCBpdCBmb3J3YXJkLiAgDQogICAgICAg IA0KICAgSW4gY2FzZSB0aGUgaW5pdGlhbCBwb3J0IHNldCByZWNlaXZlZCBieSB0aGUgY2xpZW50 IGZyb20gdGhlIHNlcnZlciANCiAgIGlzIGV4aGF1c3RlZCBhbmQgdGhlIGNsaWVudCBuZWVkcyBh ZGRpdGlvbmFsIHBvcnRzLCBpdCBNQVkgcmVxdWVzdCANCiAgIHNvIGJ5IHNlbmRpbmcgYSBuZXcg REhDUERJU0NPVkVSIG1lc3NhZ2UuICANCiAgICAgICAgDQogICBJbiBzb21lIGRlcGxveW1lbnQg c2NlbmFyaW9zIHRoZSBESENQIGNsaWVudCBtYXkgYWxzbyBhY3QgYXMgYSBESENQIA0KICAgc2Vy dmVyIGZvciBhIG5ldHdvcmsgYmVoaW5kIGl0LCBpbiB3aGljaCBjYXNlIHRoZSBob3N0IG1heSBm dXJ0aGVyIA0KICAgc3BsaXQgdGhlIGFsbG9jYXRlZCBzZXQgZm9yIG90aGVyIGhvc3RzLiAgDQog ICAgIA0KNi4yIFNlcnZlciBCZWhhdmlvdXIgIA0KICAgICAgICANCiAgIFdoZW4gYSBzZXJ2ZXIs IHdoaWNoIHN1cHBvcnRzIHRoZSBvcHRpb24gZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50LCANCiAg IHJlY2VpdmVzIGEgREhDUERJU0NPVkVSIG1lc3NhZ2UsIGl0IFNIT1VMRCBjaGVjayB0aGUgcHJl c2VuY2Ugb2YgdGhlIA0KICAgT1BUSU9OLUlQdjQtUFJBIG9wdGlvbi4gIA0KICAgIA0KICAgSWYg T1BUSU9OLUlQdjQtUFJBIGlzIG5vdCBwcmVzZW50IGluIERIQ1BESVNDT1ZFUiwgdGhlIHNlcnZl ciBTSE9VTEQgDQogICBhbGxvY2F0ZSBmdWxsIHVucmVzdHJpY3RlZCBwdWJsaWMgb3IgcHJpdmF0 ZSBbUkZDMTkxOF0gSVB2NCBhZGRyZXNzIA0KICAgdG8gdGhlIGNsaWVudCwgaWYgYXZhaWxhYmxl LCBieSBnZW5lcmF0aW5nIGEgREhDUE9GRkVSIGFzIGRlc2NyaWJlZCANCiAgIGluIFtSRkMyMTMx XS4gIA0KICAgICAgICANCiAgIFRoZSBzZXJ2ZXIgU0hPVUxEIG9mZmVyIHRoZSBwb3J0IHJlc3Ry aWN0ZWQgSVB2NCBhZGRyZXNzIHdoZW4gdGhlIA0KICAgc2VydmVyIGhhcyBzdXBwb3J0IHRoZSBl eHRlbnNpb25zIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50IGFuZCANCiAgIHdoZW46ICANCiAg ICAgIG8gREhDUCBjbGllbnQgaGFzIGluY2x1ZGVkIE9QVElPTi1JUHY0LVBSQSBvcHRpb24gYW5k IHNlcnZlci5zIA0KICAgICAgICBwb2xpY3kgaW5kaWNhdGVzIHNhdmluZyB1bnJlc3RyaWN0ZWQg SVB2NCBhZGRyZXNzZXMgZm9yIGNsaWVudHMgDQogICAgICAgIHRoYXQgZG8gbm90IHN1cHBvcnQg dGhlIGV4dGVuc2lvbnMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IA0KICAgICAgbyBzZXJ2ZXIg cmVjZWl2ZXMgYSBESENQRElTQ09WRVIgbWVzc2FnZSBhbmQgc2VydmVyIGNhbiBvbmx5IA0KICAg ICAgICBvZmZlciBwb3J0IHJlc3RyaWN0ZWQgSVAgYWRkcmVzcyB0byB0aGUgY2xpZW50ICANCiAg ICAgIG8gc2VydmVyIHJlY2VpdmVzIGEgREhDUERJU0NPVkVSIG1lc3NhZ2UgZnJvbSBhIGNsaWVu dCB3aXRob3V0IA0KICAgICAgICB0aGUgT1BUSU9OLUlQdjQtUFJBLCBidXQga25vd3MgYnkgbWVh bnMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgDQogICAgICAgIHRoaXMgZG9jdW1lbnQgdGhhdCB0aGUg Y2xpZW50IHN1cHBvcnRzIHRoZSB1c2FnZSBvZiBwb3J0LQ0KICAgICAgICByZXN0cmljdGVkIElQ djQgYWRkcmVzc2VzIChvciBpdCBpcyBvbmx5IGVudGl0bGVkIHRvIGJlIA0KICAgICAgICBwcm92 aXNpb25lZCB3aXRoIHN1Y2ggYWRkcmVzc2VzKSANCiAgICAgICAgDQogICBXaGVuIHNlcnZlciBj aG9vc2VzIHRvIG9mZmVyIHBvcnQgcmVzdHJpY3RlZCBJUHY0IGFkZHJlc3MgZm9yIA0KICAgY2xp ZW50cyB3aXRoIE9QVElPTi1JUHY0LVBSQSwgaXQgTVVTVDogDQogDQpCYWprbyAgICAgICAgICAg ICAgICAgICBFeHBpcmVzIEF1Z3VzdCAzLCAyMDA5ICAgICAgICAgICAgICBbUGFnZSAxNF0gDQog DA0KIA0KUG9ydCBSZXN0cmljdGVkIElQIGFkZHJlc3MgYXNzaWdubWVudCAgICAgICAgICAgICAg ICAgICAgIEphbnVhcnkgMjAwOSANCiAgICANCiAgICAgIG8gc2V0IHRoZSAneWlhZGRyJyAoY2xp ZW50IElQIGFkZHJlc3MpIGZpZWxkIG9mIHRoZSBESENQT0ZGRVIgDQogICAgICAgIG1lc3NhZ2Ug dG8gMC4wLjAuMCANCiAgICAgIG8gY2hvb3NlIHRoZSBwb3J0IGFsbG9jYXRpb24gbWVjaGFuaXNt cywgaWYgaXQgaXMgbm90IHN0YXRpY2FsbHkgDQogICAgICAgIGNvbmZpZ3VyZWQgDQogICAgICBv IHNlbGVjdCBhIHBvcnQgcmVzdHJpY3RlZCBJUHY0IGFkZHJlc3MgdG8gYmUgYWxsb2NhdGVkIGZv ciB0aGUgDQogICAgICAgIGNsaWVudCANCiAgICAgIG8gZ2VuZXJhdGUgcGFyYW1ldGVycyByZXF1 aXJlZCBmb3IgdGhlIGNob3NlbiBwb3J0IGFsbG9jYXRpb24gDQogICAgICAgIG1lY2hhbmlzbSBp biBjYXNlIG9mIHVzaW5nIHN1Yi1vcHRpb24gdHlwZSAnMScsIG9yIGluY2x1ZGluZyANCiAgICAg ICAgdGhlIGtleSBLIGZvciByYW5kb20gcG9ydCBnZW5lcmF0aW9uIGluIGNhc2Ugb2YgdXNpbmcg dGhlIHN1Yi0NCiAgICAgICAgb3B0aW9uIHR5cGUgJzInIA0KICAgICAgIA0KICAgV2hlbiB0aGUg c2VydmVyIHJlY2VpdmVzIGEgREhDUFJFUVVFU1QgbWVzc2FnZSBmcm9tIHRoZSBjbGllbnQgd2l0 aCANCiAgIGFuIE9QVElPTi1JUHY0LVBSQSBvcHRpb24gZmllbGQgY29udGFpbmluZyB0aGUgSVAg YWRkcmVzcyBhbmQgcG9ydCANCiAgIGFsbG9jYXRpb24gbWVjaGFuaXNtIHBhcmFtZXRlcnMgaXQg aGFzIHByZXZpb3VzbHkgb2ZmZXJlZCB0byB0aGUgDQogICBjbGllbnQsIHRoZSBzZXJ2ZXIgTVVT VCBzZW5kIGEgREhDUEFDSywgd2hlcmUgdGhlICd5aWFkZHInIChjbGllbnQgDQogICBJUCBhZGRy ZXNzKSBmaWVsZCBpcyBzZXQgdG8gMC4wLjAuMCBhbmQgdGhlIE9QVElPTi1JUHY0LVBSQSBvcHRp b24gDQogICBpbmNsdWRpbmcgdGhlIElQdjQgYWRkcmVzcyBhbmQgcGFyYW1ldGVycyByZXF1aXJl ZCBmb3IgdGhlIHVzZWQgDQogICBhbGxvY2F0aW9uIG1lY2hhbmlzbS4gDQogICAgICAgIA0KICAg V2hlbiB0aGUgc2VydmVyIHJlY2VpdmVzIGEgREhDUFJFUVVFU1QgbWVzc2FnZSBmcm9tIHRoZSBj bGllbnQgd2l0aCANCiAgIGFuIE9QVElPTi1JUHY0LVBSQSBvcHRpb24gZmllbGQgY29udGFpbmlu ZyBhbiBJUHY0IGFkZHJlc3MgYW5kIHBvcnQgDQogICBzZXQgaXQgaGFzIHByZXZpb3VzbHkgbm90 IG9mZmVyZWQgdG8gdGhlIGNsaWVudCwgdGhlIHNlcnZlciBNVVNUIA0KICAgc2VuZCBhIERIQ1BO QUsgdG8gdGhlIGNsaWVudC4gIA0KICAgICAgICANCiAgIFdoZW4gdGhlIHNlcnZlciBkZXRlY3Rz IHRoYXQgYSBjbGllbnQgKGJ5IGVnIGhhdmluZyBhIHNwZWNpZmljIA0KICAgaGFyZHdhcmUgYWRk cmVzcyksIGhhcyBhbHJlYWR5IGJlZW4gYWxsb2NhdGVkIHdpdGggYSBwb3J0IHJlc3RyaWN0ZWQg DQogICBJUHY0IGFkZHJlc3MsIHNlbnQgYW5vdGhlciBESENQRElTQ09WRVIsIGl0IE1BWSwgYmFz ZWQgb24gbG9jYWwgDQogICBwb2xpY3ksIG9mZmVyIHRoZSBjbGllbnQgd2l0aCBhZGRpdGlvbmFs IHBvcnQgcmVzdHJpY3RlZCBJUHY0IA0KICAgYWRkcmVzcy4gIA0KICAgICAgICANCiAgIElmIHRo ZSBzZXJ2ZXIgaXMgZGVwbG95ZWQgaW4gYSBjYXNjYWRlZCBESENQIHNlcnZlciBzY2VuYXJpbywg dGhlIA0KICAgaG9zdCBNQVkgYm90aCBhY3QgYXMgYSBESENQIGNsaWVudCBmb3IgYW5vdGhlciBz ZXJ2ZXIgYW5kIERIQ1AgDQogICBzZXJ2ZXIgZm9yIG90aGVyIERIQ1AgY2xpZW50cy4gDQogICAg ICAgIA0KICAgQSBzZXJ2ZXIgU0hPVUxEIGVuc3VyZSB0aGUgY2xpZW50IGlzIHJlc2lkaW5nIG9u IGFuIGFjY2VzcyBsaW5rIA0KICAgd2hlcmUgdXNhZ2Ugb2YgcG9ydC1yZXN0cmljdGVkIGFkZHJl c3NlcyBpcyBub3QgY2F1c2luZyBwcm9ibGVtcywgDQogICBiZWZvcmUgYWxsb2NhdGluZyBpdCBh IHBvcnQgcmVzdHJpY3RlZCBJUHY0IGFkZHJlc3MuIA0KICAgIA0KNy4gQXBwbGljYWJpbGl0eSAN CiAgICANCiAgIFRoZSBtdWx0aXBsZXhpbmcgb2YgSVAgZmxvd3MgaW4gZ2F0ZXdheSBpcyBiYXNl ZCBvbiB0aGUgcG9ydCBudW1iZXJzIA0KICAgdXNlZCBieSB0cmFuc3BvcnQgbGF5ZXIgcHJvdG9j b2xzIHN1Y2ggYXMgVENQLCBVRFAsIFNDVFAsIGFuZCBEQ0NQLiANCiAgIEhvd2V2ZXIsIHRoZSBw cm90b2NvbHMgbm90IGNvbnRhaW5pbmcgcG9ydCBudW1iZXJzIG5lZWQgc3BlY2lhbCANCiAgIGhh bmRsaW5nIGluIG9yZGVyIHRvIGJlIG11bHRpcGxleGVkIGNvcnJlY3RseS4gDQogICAgDQogICAg DQogICAgDQogICAgDQogICAgDQo3LjEgSUNNUCANCiAgICANCgogDQpCYWprbyAgICAgICAgICAg ICAgICAgICBFeHBpcmVzIEF1Z3VzdCAzLCAyMDA5ICAgICAgICAgICAgICBbUGFnZSAxNV0gDQog DA0KIA0KUG9ydCBSZXN0cmljdGVkIElQIGFkZHJlc3MgYXNzaWdubWVudCAgICAgICAgICAgICAg ICAgICAgIEphbnVhcnkgMjAwOSANCiAgICANCiAgIFRob3NlIElDTVAgbWVzc2FnZXMgdGhhdCBl bWJlZCB0aGUgSVAgcGFja2V0IHRoYXQgdHJpZ2dlcmVkIHNlbmRpbmcgDQogICBvZiBJQ01QIG1l c3NhZ2UsIHN1Y2ggYXMgSUNNUCBlcnJvciwgY2FuIGJlIG11bHRpcGxleGVkIGJhc2VkIG9uIHRo ZSANCiAgIHBvcnQgbnVtYmVyIHByZXNlbnQgaW4gdGhlIGVtYmVkZGVkIG9yaWdpbmFsIHBhY2tl dC4gDQogICAgDQogICBJQ01QIG1lc3NhZ2VzIG5vdCBjb250YWluaW5nIGVtYmVkZGVkIHBhY2tl dHMsIGxpa2UgSUNNUCBlY2hvLCBhcmUgDQogICBUQkQuIA0KICAgIA0KNy4yIDZ0bzQgDQogICAg DQogICBBIGhvc3QgdXRpbGl6aW5nIDZ0bzQgW1JGQzMwNTZdIHdpdGggcG9ydCByZXN0cmljdGVk IElQdjQgYWRkcmVzc2VzIA0KICAgTVVTVCBwaWNrIHRoZSAxNi1iaXQgLlNMQSBJRC4gdmFsdWUg Zm9yIHRoZSA2dG80IHByZWZpeChlcykgDQogICBjb25zdHJ1Y3Rpb24gZnJvbSB0aGUgcG9vbCBv ZiBhbGxvY2F0ZWQgcG9ydCB2YWx1ZXMuIFRoZSANCiAgIG11bHRpcGxleGluZyBnYXRld2F5IE1V U1QgdGhlbiBtdWx0aXBsZXggNnRvNCB0cmFmZmljIGJhc2VkIG9uIC5TTEEgDQogICBJRC4gdmFs dWUgYXMgaXQgd291bGQgbXVsdGlwbGV4IHBsYWluIElQdjQgdHJhZmZpYyBiYXNlZCBvbiBwb3J0 IA0KICAgdmFsdWVzLiBJLmUuIGZvciBpbmNvbWluZyBwYWNrZXRzIHRoZSBnYXRld2F5IHNoYWxs IGxvb2sgYXQgdGhlIA0KICAgZGVzdGluYXRpb24gSVB2NCBhZGRyZXNzIGFuZCB0aGUgLlNMQSBJ RC4tZmllbGQgZnJvbSB0dW5uZWxlZCBJUHY2IA0KICAgcGFja2V0LnMgZGVzdGluYXRpb24gSVB2 NiBhZGRyZXNzLCBhbmQgdGhlbiBzZWxlY3QgdGhlIHJpZ2h0IHJvdXRlIA0KICAgYXMgaXQgd291 bGQgaGF2ZSBwaWNrZWQgdGhlIHBvcnQgbnVtYmVyIGZyb20gYSB0cmFuc3BvcnQgbGF5ZXIgDQog ICBoZWFkZXIuIA0KICAgIA0KNy4zIFByb3RvY29scyBub3Qgc3VwcG9ydGVkIGJ5IG11bHRpcGxl eGluZyBnYXRld2F5IA0KICAgIA0KICAgVGhlIGNhc2Ugd2hlcmUgcG9ydCByYW5nZSByb3V0ZXIg aXMgbm90IGFibGUgdG8gbXVsdGlwbGV4IGEgcHJvdG9jb2wgDQogICBpcyBzaW1pbGFyIHRvIGEg Y2FzZSB3aGVyZSBtaWRkbGUgYm94LCBzdWNoIGFzIGZpcmV3YWxsIG9yIE5BVCwgDQogICBibG9j a3MgdHJhZmZpYyBpdCBpcyBub3QgYWJsZSBvciB3aWxsaW5nIHRvIHBhc3MgdHJvdWdoLiBUaGUg DQogICBhcHBsaWNhdGlvbiBpcyByZWNvbW1lbmRlZCB0byBmYWxsYmFjayB0byBVRFAgZW5jYXBz dWxhdGlvbiBvZnRlbiANCiAgIHVzZWQgZm9yIE5BVCB0cmF2ZXJzYWwsIGZvciB3aGljaCBnYXRl d2F5IGlzIGFibGUgdG8gcGVyZm9ybSANCiAgIG11bHRpcGxleGluZy4gDQogICAgDQo4LiBJQU5B IGNvbnNpZGVyYXRpb25zIA0KICAgIA0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIG5ldyBESENQ djQgb3B0aW9uIGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDM6IA0KICAgUG9ydCBSZXN0cmljdGVk IElQIEFkZHJlc3MgT3B0aW9uIGZvciBESENQdjQgKE9QVElPTi1JUHY0LVBSQSkgVEJELiAgDQog ICAgICAgIA0KOS4gU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgDQogICAgDQogICBUaGUgc29sdXRp b24gaXMgZ2VuZXJhbGx5IHZ1bG5lcmFibGUgdG8gRG9TIHdoZW4gdXNlZCBpbiBzaGFyZWQgDQog ICBtZWRpdW0gb3Igd2hlbiBhY2Nlc3MgbmV0d29yayBhdXRoZW50aWNhdGlvbiBpcyBub3QgYSBw cmVyZXF1aXNpdGUgDQogICB0byBJUCBhZGRyZXNzIGFzc2lnbm1lbnQuIFRoZSBzb2x1dGlvbiBT SE9VTEQgb25seSBiZSB1c2VkIG9uIHBvaW50LQ0KICAgdG8tcG9pbnQgbGlua3MsIHR1bm5lbHMs IGFuZC9vciBpbiBlbnZpcm9ubWVudHMgd2hlcmUgYXV0aGVudGljYXRpb24gDQogICBhdCBsaW5r IGxheWVyIGlzIHBlcmZvcm1lZCBiZWZvcmUgSVAgYWRkcmVzcyBhc3NpZ25tZW50LCBhbmQgbm90 IA0KICAgc2hhcmVkIG1lZGl1bS4gIA0KICAgIA0KICAgVGhlIGNyeXB0b2dyYXBoaWNhbGx5IHJh bmRvbSBwb3J0IGRlbGVnYXRpb24gbWVjaGFuaXNtIGlzIHZ1bG5lcmFibGUgDQogICBmb3IgYmxp bmQgYXR0YWNrcyBpbml0aWF0ZWQgYnkgaG9zdHMgbG9jYXRlZCBpbiB0aGUgc2FtZSANCiAgIGFk bWluaXN0cmF0aXZlIGRvbWFpbiwgc2VydmVkIGJ5IHRoZSBzYW1lIERIQ1Agc2VydmVyLCBhbmQg dGhhdCBhcmUgDQogICBzaGFyaW5nIHRoZSBzYW1lIHB1YmxpYyBJUHY0IGFkZHJlc3MsIGFuZCB0 aGVyZWZvcmUgaGF2ZSBrbm93bGVkZ2UgDQogICBvZiB0aGUgY3J5cHRvZ3JhcGhpYyBrZXkgdXNl ZCBmb3IgdGhhdCBwYXJ0aWN1bGFyIHB1YmxpYyBJUHY0IA0KICAgYWRkcmVzcy4gIA0KICAgIA0K MTAuIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIA0KICAgIA0KIA0KQmFqa28gICAgICAgICAgICAgICAg ICAgRXhwaXJlcyBBdWd1c3QgMywgMjAwOSAgICAgICAgICAgICAgW1BhZ2UgMTZdIA0KIAwNCiAN ClBvcnQgUmVzdHJpY3RlZCBJUCBhZGRyZXNzIGFzc2lnbm1lbnQgICAgICAgICAgICAgICAgICAg ICBKYW51YXJ5IDIwMDkgDQogICAgDQogICBbUkZDMjExOV0gICAgQnJhZG5lciwgUy4sIC5LZXkg d29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIA0KICAgICAgICAgICAgICAgIFJlcXVp cmVtZW50IExldmVscy4sIE1hcmNoIDE5OTcgDQogICAgDQogICBbUkZDMjEzMV0gICAgRHJvbXMs IFIuLCAiRHluYW1pYyBIb3N0IENvbmZpZ3VyYXRpb24gUHJvdG9jb2wiLCAgDQogICAgICAgICAg ICAgICAgUkZDMjEzMSwgTWFyY2ggMTk5NyANCiAgICANCiAgIFtSRkMzMDU2XSAgICBDYXJwZW50 ZXIsIEIuLCBNb29yZSwgSy4sIC5Db25uZWN0aW9uIG9mIElQdjYgRG9tYWlucyANCiAgICAgICAg ICAgICAgICB2aWEgSVB2NCBDbG91ZHMuLCBGZWJydWFyeSAyMDAxIA0KICAgIA0KICAgIA0KICAg IA0KMTEuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgDQogICAgDQogICBbQVJLSzIwMDhdICAgQXJr a28sIEouLCBUb3duc2xleSwgTS4sICJJUHY0IFJ1bi1PdXQgYW5kIElQdjQtSVB2NiAgDQogICAg ICAgICAgICAgICAgQ28tRXhpc3RlbmNlIFNjZW5hcmlvcyIsIFNlcHRlbWJlciAyMDA4LCBkcmFm dC1hcmtrby0gDQogICAgICAgICAgICAgICAgdG93bnNsZXktY29leGlzdGVuY2UtMDAgDQogICAg DQogICBbV0lORzIwMDhdICAgV2luZywgRC4sIFdhcmQsIEQuLCBEdXJhbmQsIEEuLCAiQSBDb21w YXJpc29uIG9mICANCiAgICAgICAgICAgICAgICBQcm9wb3NhbHMgdG8gUmVwbGFjZSBOQVQtUFQi LCBTZXB0ZW1iZXIgMjAwOCwgZHJhZnQtIA0KICAgICAgICAgICAgICAgIHdpbmctbmF0LXB0LXJl cGxhY2VtZW50LWNvbXBhcmlzb24gDQogICAgDQogICBbUkZDMTkxOF0gICAgUmVraHRlciwgWS4s IE1vc2tvd2l0eiwgQi4sIEthcnJlbmJlcmcsIEQuLCBKLiBkZSAgDQogICAgICAgICAgICAgICAg R3Jvb3QsIEcuLCBMZWFyLCBFLiwgIkFkZHJlc3MgQWxsb2NhdGlvbiBmb3IgUHJpdmF0ZSAgDQog ICAgICAgICAgICAgICAgSW50ZXJuZXRzIiwgUkZDMTkxOCwgRmVicnVhcnkgMTk5NiAgDQogICAg DQogICBbTUFFTjIwMDhdICAgTWFlbm5lbCwgTy4sIEJ1c2gsIFIuLCBDaXR0YWRpbmksIEwuLCBC ZWxsb3ZpbiwgUy4sICJBICANCiAgICAgICAgICAgICAgICBCZXR0ZXIgQXBwcm9hY2ggdGhhbiBD YXJyaWVyLUdyYWRlLU5BVCIsIDIwMDgsICANCiAgICAgICAgICAgICAgICBUZWNobmljYWwgUmVw b3J0IENVQ1MtMDQxLTA4ICAgICANCiAgICANCiAgIFtSQU5ET01QT1JUXSBMYXJzZW4sIE0uLCBH b250LCBGLiwgLlBvcnQgUmFuZG9taXphdGlvbi4sIEF1Z3VzdCANCiAgICAgICAgICAgICAgICAy MDA4LCBkcmFmdC1pZXRmLXRzdndnLXBvcnQtcmFuZG9taXphdGlvbi0wMiANCiAgICANCiAgIFtD SVBIRVJTXSAgICBKb2huIEJsYWNrIGFuZCBQaGlsbGlwIFJvZ2F3YXk6IC5DaXBoZXJzIHdpdGgg QXJiaXRyYXJ5IA0KICAgICAgICAgICAgICAgIEZpbml0ZSBEb21haW5zLiwgVG9waWNzIGluIENy eXB0b2xvZ3kgLSBDVC1SU0EgMjAwMiwgDQogICAgICAgICAgICAgICAgTGVjdHVyZSBOb3RlcyBp biBDb21wdXRlciBTY2llbmNlIHZvbC4gMjI3MSwgMjAwMiANCiAgICANCiAgIFtEU0xJVEVdICAg ICBBLiBEdXJhbmQgZXQgYWwgLkR1YWwtc3RhY2sgbGl0ZSBicm9hZGJhbmQgZGVwbG95bWVudHMg DQogICAgICAgICAgICAgICAgcG9zdCBJUHY0IGV4aGF1c3Rpb24uLCBOb3ZlbWJlciAyMDA4LCBk cmFmdC1kdXJhbmQtDQogICAgICAgICAgICAgICAgc29mdHdpcmUtZHVhbC1zdGFjay1saXRlIA0K ICAgIA0KICAgW0JPVUNBREFJUl0gIEJvdWNhZGFpciwgTSwgRWQuLCBHcmltYXVsdCwgSi1MLiwg TGV2aXMsIFAuLCANCiAgICAgICAgICAgICAgICBWaWxsZWZyYW5xdWUsIEEuLCAuREhDUCBPcHRp b25zIGZvciBDb252ZXlpbmcgUG9ydCBNYXNrIA0KICAgICAgICAgICAgICAgIGFuZCBQb3J0IFJh bmdlIFJvdXRlciBJUCBBZGRyZXNzLiwgT2N0b2JlciAyMDA4LCBkcmFmdC0NCiAgICAgICAgICAg ICAgICBib3VjYWRhaXItZGhjLXBvcnQtcmFuZ2UgDQogICAgDQogICBbQk9VQ0FEQUlSQVJDSF0g IEJvdWNhZGFpciwgTS4sIEVkLiwgTGV2aXMsIFAuLCBCYWprbywgRy4sIA0KICAgICAgICAgICAg ICAgIFNhdm9sYWluZW4sIFQuLCAuSVB2NCBDb25uZWN0aXZpdHkgQWNjZXNzIGluIHRoZSANCiAg ICAgICAgICAgICAgICBDb250ZXh0IG9mIElQdjQgQWRkcmVzcyBFeGhhdXN0aW9uLiwgSmFudWFy eSAyMDA5LCANCiAgICAgICAgICAgICAgICBkcmFmdC1ib3VjYWRhaXItcG9ydC1yYW5nZSANCiAg ICANCgoKIA0KQmFqa28gICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMywgMjAwOSAg ICAgICAgICAgICAgW1BhZ2UgMTddIA0KIAwNCiANClBvcnQgUmVzdHJpY3RlZCBJUCBhZGRyZXNz IGFzc2lnbm1lbnQgICAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDkgDQogICAgDQogICBb QVBMVVNQXSAgICAgTWFlbm5lbCwgTy4sIEJ1c2gsIFIuLCBDaXR0YWRpbmksIEwuLCBCZWxsb3Zp biwgUy4sICJUaGUgDQogICAgICAgICAgICAgICAgQStQIEFwcHJvYWNoIHRvIHRoZSBJUHY0IEFk ZHJlc3MgU2hvcnRhZ2UiLCBKYW51YXJ5IA0KICAgICAgICAgICAgICAgIDIwMDksIGRyYWZ0LXlt YmstYXBsdXNwIA0KICAgIA0KMTIuIENvbnRyaWJ1dG9ycyANCiAgICANCiAgIFRoZSBwb3J0IHJh bmdlIGFsbG9jYXRpb24gdXNpbmcgUG9ydCBSYW5nZSBWYWx1ZSAvIFBvcnQgUmFuZ2UgTWFzayAN CiAgIGNvbWVzIGZyb20gW0JPVUNBREFJUl0sIGF1dGhvcmVkIGJ5IE1vaGFtZWQgQm91Y2FkYWly LCBKZWFuIEx1YyANCiAgIEdyaW1hdWx0IGFuZCBQaWVycmUgTGV3aXMuIA0KICAgIA0KICAgVGhl IGVuY3J5cHRpb24gZnVuY3Rpb24gZnJvbSBzZWN0aW9uIDUgd2FzIHByb3ZpZGVkIGJ5IFBhc2kg RXJvbmVuLiAgDQogICAgDQogICBUaGUgdGV4dCBvbiA2dG80IGhhbmRsaW5nIHdhcyBwcm9wb3Nl ZCBieSBEYXZlIFRoYWxlci4gDQogICAgDQogICBUaGUgcmVzdCBvZiB0aGUgZG9jdW1lbnQgd2Fz IHdyaXR0ZW4gYW5kIGVkaXRlZCBieSBHYWJvciBCYWprbyBhbmQgDQogICBUZWVtdSBTYXZvbGFp bmVuLiANCiAgICANCiAgIFRoZSBhdXRob3JzIHdvdWxkIGFsc28gbGlrZSB0byB0aGFuayBMYXJz IEVnZ2VydCwgT2xhZiBNYWVuZWwsIFJhbmR5IA0KICAgQnVzaCwgQWxhaW4gRHVyYW5kLCBKZWFu LUx1YyBHcmltYXVsdCwgQWxhaW4gVmlsbGVmcmFucXVlIGZvciB0aGVpciANCiAgIHZhbHVhYmxl IGNvbW1lbnRzLiANCiAgICANCiAgICANCjEzLiBBdXRob3JzJyBBZGRyZXNzZXMgDQogICAgDQog ICBHYWJvciBCYWprbyANCiAgIGdhYm9yKGRvdCliYWprbyhhdClub2tpYShkb3QpY29tIA0KICAg IA0KICAgIA0KICAgVGVlbXUgU2F2b2xhaW5lbiANCiAgIE5va2lhIA0KICAgSGVybWlhbmthdHUg MTIgRCANCiAgIEZJLTMzNzIwIFRBTVBFUkUgDQogICBGaW5sYW5kIA0KICAgIA0KICAgRW1haWw6 IHRlZW11LlNhdm9sYWluZW5Abm9raWEuY29tIA0KICAgIA0KICAgIA0KICAgTW9oYW1lZCBCb3Vj YWRhaXIgDQogICBGcmFuY2UgVGVsZWNvbSANCiAgIDQyIHJ1ZSBkZXMgQ291dHVyZXMgDQogICBC UCA2MjQzIA0KICAgQ2FlbiBDZWRleCA0ICAxNDA2NiANCiAgIEZyYW5jZSANCiAgICANCiAgIEVt YWlsOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UtZnRncm91cC5jb20gDQogICAgDQogICAgDQog ICBQaWVycmUgTGV2aXMgDQogICBGcmFuY2UgVGVsZWNvbSANCiAgIDQyIHJ1ZSBkZXMgQ291dHVy ZXMgDQogICBCUCA2MjQzIA0KICAgQ2FlbiBDZWRleCA0ICAxNDA2NiANCiANCkJhamtvICAgICAg ICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDMsIDIwMDkgICAgICAgICAgICAgIFtQYWdlIDE4 XSANCiAMDQogDQpQb3J0IFJlc3RyaWN0ZWQgSVAgYWRkcmVzcyBhc3NpZ25tZW50ICAgICAgICAg ICAgICAgICAgICAgSmFudWFyeSAyMDA5IA0KICAgIA0KICAgRnJhbmNlIA0KICAgIA0KICAgRW1h aWw6IHBpZXJyZS5sZXZpc0BvcmFuZ2UtZnRncm91cC5jb20gDQogICAgDQoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgogDQpCYWprbyAgICAgICAgICAgICAg ICAgICBFeHBpcmVzIEF1Z3VzdCAzLCAyMDA5ICAgICAgICAgICAgICBbUGFnZSAxOV0gDQogDA== --_002_A99B171D26E1564B92D36826128CD66127E350E97ENOKEUMSG01mgd_-- From pierre.levis@orange-ftgroup.com Thu Feb 5 23:55:15 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 646B63A6963; Thu, 5 Feb 2009 23:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.054 X-Spam-Level: X-Spam-Status: No, score=-3.054 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jo04Te9D7sFY; Thu, 5 Feb 2009 23:55:14 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id C6DA43A6880; Thu, 5 Feb 2009 23:55:13 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Feb 2009 08:55:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Feb 2009 08:55:06 +0100 Message-ID: In-Reply-To: <014b01c9882a$19255210$c2f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [shara] [BEHAVE]TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt Thread-Index: AcmH6rF7O8eIFT3dRwGVzm6VhD6rmwADK9cQAAsCqgAAANc0wAABkDQQ From: To: , , , X-OriginalArrivalTime: 06 Feb 2009 07:55:08.0892 (UTC) FILETIME=[3B25F1C0:01C98830] Cc: behave@ietf.org, shara@ietf.org Subject: Re: [shara] [BEHAVE]TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 07:55:15 -0000 Hi all, Forbid people to use non-contiguous port ranges, at this point in time, = seems rather dangerous to me. What if it later appears that for some use cases it is an interesting = feature? As Med and Teemu pointed out it could improve, to some extent = the security.=20 If we say we do not permit non contiguous port ranges, does that mean = implementers will have to code it? (as nowadays it is impossible to use = 240/4). May be we could simply say that if there is no particular reason to do = otherwise, by default use contiguous port ranges Regards, Pierre > -----Message d'origine----- > De : shara-bounces@ietf.org [mailto:shara-bounces@ietf.org]=20 > De la part de Dan Wing > Envoy=E9 : vendredi 6 f=E9vrier 2009 08:11 > =C0 : BOUCADAIR Mohamed RD-CORE-CAE;=20 > dthaler@windows.microsoft.com; randy@psg.com > Cc : behave@ietf.org; shara@ietf.org > Objet : Re: [shara] [BEHAVE]TR:=20 > I-DAction:draft-boucadair-pppext-portrange-option-00.txt >=20 > =20 >=20 > > -----Original Message----- > > From: mohamed.boucadair@orange-ftgroup.com=20 > > [mailto:mohamed.boucadair@orange-ftgroup.com]=20 > > Sent: Thursday, February 05, 2009 10:35 PM > > To: dthaler@windows.microsoft.com; randy@psg.com; dwing@cisco.com > > Cc: behave@ietf.org; shara@ietf.org > > Subject: RE: [BEHAVE] [shara]TR:=20 > > I-DAction:draft-boucadair-pppext-portrange-option-00.txt > >=20 > >=20 > > Thank you for your comment. > >=20 > > There is a subtlety between subnet mask and port mask:=20 > > subnets need to be hierarchical but not port ranges! >=20 > I disagree. Port ranges all belong to the same IP address --=20 > from the view of the rest of the Internet. This is akin to the=20 > rest of the Internet's view of a subnet. It is only the local > IP address (subnet) that is aware of the separation of ports > (or IP addresses) to individual hosts. >=20 > > Non contiguous port range is proposed as a solution to assign=20 > > with a single mask for instance "M" Port Ranges with "n" Port=20 > > Ranges within the well-known Port Range. This means that=20 > > well-known PR won't be assigned to the same user.=20 > >=20 > > I see other advantages on the usage of non contiguous PR:=20 > > e.g. an attacker would have more difficulty to "guess" a port=20 > > value within the Port Range. >=20 > draft-boucadair-pppext-portrange-option does not describe > this advantage. I am not convinced this would thwart an > attacker significantly. If a user is permitted XXXX ports, > an attacker can determine what ports they are by a range > of contiguous bits or a range of non-contiguous bits. I > agree the attacker has to perform more probes to learn > the non-contiguous bit pattern, of course. But an analysis > of this advantage would be useful. >=20 > > By the way, I have the same question as Randy. >=20 > I am not talking about the proverbial Grandma or "Joe > Sixpack" when I say "users". Those users have no > need to understand 255.255.255.0, or IP addresses, > or ARP. >=20 > However, network administrators are users, and they need=20 > to understand these bit-masks in order to successfully > configure equipment. Based on industry experience with > IP, non-contiguous subnet masks are not used in very > many networks. This is because the complexity to use > them exceeds their value. >=20 > Justification of the value of non-contiguous port masks=20 > would be useful. >=20 > -d >=20 >=20 > >=20 > >=20 > > Med > >=20 > > =20 > >=20 > > -----Message d'origine----- > > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org]=20 > > De la part de Dave Thaler > > Envoy=E9 : vendredi 6 f=E9vrier 2009 02:10 > > =C0 : Randy Bush; Dan Wing > > Cc : behave@ietf.org; shara@ietf.org > > Objet : Re: [BEHAVE] [shara]TR:=20 > > I-DAction:draft-boucadair-pppext-portrange-option-00.txt > >=20 > > Yes. :) > >=20 > > I had the same feedback last IETF. > > This is the same thing all over again as a non-contiguous=20 > > subnet mask, which the industry effectively got rid of as=20 > > having too many problems in practice (but being fine in theory). > >=20 > > -Dave > >=20 > > -----Original Message----- > > From: shara-bounces@ietf.org [mailto:shara-bounces@ietf.org]=20 > > On Behalf Of Randy Bush > > Sent: Thursday, February 05, 2009 3:35 PM > > To: Dan Wing > > Cc: behave@ietf.org; shara@ietf.org > > Subject: Re: [shara] [BEHAVE] TR:=20 > > I-DAction:draft-boucadair-pppext-portrange-option-00.txt > >=20 > > > I like this draft overall, but I would restrict this so that only=20 > > > contiguous port ranges are permitted. Non-contiguous=20 > > subnet masks are=20 > > > difficult for many people to understand (even today) and I expect=20 > > > there would be similar confusion with non-contiguous port ranges. > >=20 > > do people have to understand these? > >=20 > > randy > > _______________________________________________ > > shara mailing list > > shara@ietf.org > > https://www.ietf.org/mailman/listinfo/shara > >=20 > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave >=20 > _______________________________________________ > shara mailing list > shara@ietf.org > https://www.ietf.org/mailman/listinfo/shara >=20 From magnus.westerlund@ericsson.com Fri Feb 6 01:18:04 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96AB53A6B8A; Fri, 6 Feb 2009 01:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIWm6k0Ee-aX; Fri, 6 Feb 2009 01:18:03 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 761163A6B82; Fri, 6 Feb 2009 01:18:03 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0C0D72058D; Fri, 6 Feb 2009 10:18:04 +0100 (CET) X-AuditID: c1b4fb3e-b0072bb00000429e-53-498c004b3977 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D586020073; Fri, 6 Feb 2009 10:18:03 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 10:18:03 +0100 Received: from [153.88.45.128] ([153.88.45.128]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 10:18:03 +0100 Message-ID: <498C004B.7020300@ericsson.com> Date: Fri, 06 Feb 2009 10:18:03 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: shara@ietf.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 06 Feb 2009 09:18:03.0315 (UTC) FILETIME=[D022A830:01C9883B] X-Brightmail-Tracker: AAAAAA== Cc: 'Softwire Chairs' , "behave-chairs@tools.ietf.org" Subject: [shara] BOF Approval but with modifications of scope X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 09:18:04 -0000 Dear SHARA interested, I have decided to approve the SHARA BOF but with somewhat different scope. This will be a non-wg forming BOF. I think it is important that we first discuss the problems and benefits before deciding if work should be chartered or not. The proposed work and solutions does have close relation to the currently ongoing work in BEHAVE and SOFTWIRE WGs. For example it is important to understand how SHARA relates to Dual Stack-Lite and if it is a different architecture or simple different choices within the same architecture. One of the reasons I decided to make it a non-wg forming BOF is the overloaded agenda. Removing all discussion about chartering will clearly help reduced the load. I think further discussion and consideration of what to put on the BOF agenda is important. I would already now like to point out that if there are consensus about the problem and the benefits of the trade off we can initiate chartering discussion and actions before holding any second BOF in Stockholm. I also appreciate proposals and volunteers for BOF chairs. As usual I don't like the major proponents to chair the session. Instead I look for individuals that think they can lead the discussion and ensure that the important points are being discussed. Best Regards Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From teemu.savolainen@nokia.com Fri Feb 6 02:25:49 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DFD83A6B46 for ; Fri, 6 Feb 2009 02:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4D183KU7Rfe for ; Fri, 6 Feb 2009 02:25:48 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 1B3AE3A6923 for ; Fri, 6 Feb 2009 02:25:47 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n16APdMS006844; Fri, 6 Feb 2009 04:25:45 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Feb 2009 12:25:38 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Feb 2009 12:25:30 +0200 Received: from nok-am1mhub-06.mgdnok.nokia.com (65.54.30.10) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 6 Feb 2009 11:25:29 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-06.mgdnok.nokia.com ([65.54.30.10]) with mapi; Fri, 6 Feb 2009 11:25:29 +0100 From: To: , Date: Fri, 6 Feb 2009 11:25:04 +0100 Thread-Topic: [shara] BOF Approval but with modifications of scope Thread-Index: AcmIO9dRzmTCLx0bTMCm8S5A2SprUwAB7mdQ Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F27E8726E33@NOK-EUMSG-01.mgdnok.nokia.com> References: <498C004B.7020300@ericsson.com> In-Reply-To: <498C004B.7020300@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Feb 2009 10:25:30.0850 (UTC) FILETIME=[3CA77C20:01C98845] X-Nokia-AV: Clean Cc: softwire-chairs@tools.ietf.org, behave-chairs@tools.ietf.org Subject: Re: [shara] BOF Approval but with modifications of scope X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 10:25:49 -0000 Magnus, Thank you for approving the BOF. The proposed approach is fine as well. We'll continue working to enhance documentation, and the agenda, by the BOF= with feedback received this far. Best regards, Teemu >-----Original Message----- >From: shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] >On Behalf Of ext Magnus Westerlund >Sent: 06 February, 2009 11:18 >To: shara@ietf.org >Cc: 'Softwire Chairs'; behave-chairs@tools.ietf.org >Subject: [shara] BOF Approval but with modifications of scope > >Dear SHARA interested, > >I have decided to approve the SHARA BOF but with somewhat >different scope. This will be a non-wg forming BOF. I think it >is important that we first discuss the problems and benefits >before deciding if work should be chartered or not. The >proposed work and solutions does have close relation to the >currently ongoing work in BEHAVE and SOFTWIRE WGs. >For example it is important to understand how SHARA relates to >Dual Stack-Lite and if it is a different architecture or >simple different choices within the same architecture. > >One of the reasons I decided to make it a non-wg forming BOF >is the overloaded agenda. Removing all discussion about >chartering will clearly help reduced the load. I think further >discussion and consideration of what to put on the BOF agenda >is important. > >I would already now like to point out that if there are >consensus about the problem and the benefits of the trade off >we can initiate chartering discussion and actions before >holding any second BOF in Stockholm. > >I also appreciate proposals and volunteers for BOF chairs. As >usual I don't like the major proponents to chair the session. >Instead I look for individuals that think they can lead the >discussion and ensure that the important points are being discussed. > >Best Regards > >Magnus Westerlund > >IETF Transport Area Director & TSVWG Chair >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- >_______________________________________________ >shara mailing list >shara@ietf.org >https://www.ietf.org/mailman/listinfo/shara > From mohamed.boucadair@orange-ftgroup.com Fri Feb 6 02:27:56 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D2D43A69EB; Fri, 6 Feb 2009 02:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdSBdCM6mNIs; Fri, 6 Feb 2009 02:27:55 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id D38D63A6B46; Fri, 6 Feb 2009 02:27:54 -0800 (PST) Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Feb 2009 11:27:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C98845.927F5798" Date: Fri, 6 Feb 2009 11:27:53 +0100 Message-ID: <6CF039C5B32037498B02251E11CDE6B007BB754F@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] TR: I-D Action:draft-boucadair-pppext-portrange-option-00.txt Thread-Index: AcmIP0F9r5XyLwZXRm+s58mSmO5ZEQABU7og References: <6CF039C5B32037498B02251E11CDE6B007BB7096@ftrdmel3> <498C0586.2040201@free.fr> From: To: X-OriginalArrivalTime: 06 Feb 2009 10:27:54.0440 (UTC) FILETIME=[923D9480:01C98845] Cc: behave@ietf.org, shara@ietf.org Subject: Re: [shara] [BEHAVE] TR: I-D Action:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 10:27:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C98845.927F5798 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear R=E9mi, =20 Thank your for your comments. =20 Please see inline. =20 Cheers Med _____ =20 De : R=E9mi Despr=E9s [mailto:remi.despres@free.fr]=20 Envoy=E9 : vendredi 6 f=E9vrier 2009 10:40 =C0 : BOUCADAIR Mohamed RD-CORE-CAE Cc : behave@ietf.org; shara@ietf.org Objet : Re: [BEHAVE] TR: I-D = Action:draft-boucadair-pppext-portrange-option-00.txt Mohamed, Thanks for this draft. It does contribute to the promotion of Port-Extended IPv4 addressing, = which is the only known way to AVOID, during the IPv4-IPv6 coexistence = period, that users MUST depend on CGNs .=20 Yet, the mask and value parameters which you propose, to express port = ranges, are in my understanding, both too complex and too limited.=20 - too complex, because it's hard to imagine a practical use of non = contiguous port ranges. (In particular I don't see where to use the = chosen example of ports xxx0x1xxxxxxxxxx.)=20 [Med] Non contiguous port ranges are only on example. The specification = supports both. There is no overhead of the spec which is due to the type = of the assigned port ranges=20 - too limited, because it cannot express an IPv4-address extension based = on dynamic ports, which, as I already discussed in various places, is = IMO the most simple choice for a realistic deployment. [Med] Contiguous port ranges could be used for this purpose. =20 For example, no mask and value parameters can express 4-bits address = extension based on dynamic ports (i.e. with ports 11EEEExxxxxxxxxx, = where Es are the address extension bits).=20 If no need is identified for more complex solutions than dynamic-ports = only, I then propose to amend the document so that parameters are = simplified, e.g. but not necessarily to become: Port Prefix Length (6 in the above example). Port Prefix Value (11EEEE0000000000 in the above example). [Med] I need to think about that a little bit more.=20 Some other set of parameters could be proposed if a good reason would = be found to also use Well-Known ports and/or Registered ports. (I don't = see such a reason, while avoiding interference with firewalls is an = important reason against),=20 [Med] I think assigning the overall well known port range to a single = user is not **fair**, IMO means to distributed these values should be = encouraged. And again, this is naturally supported by our proposal. The = values to be carried in an IPCP conf message is out of scope. SP are = free to assign the Port Masks they want! Cheers, RD ------_=_NextPart_001_01C98845.927F5798 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear R=E9mi,
 
Thank your for your = comments.
 
Please see inline.
 
Cheers
Med

De : R=E9mi Despr=E9s=20 [mailto:remi.despres@free.fr]
Envoy=E9 : vendredi 6 = f=E9vrier 2009=20 10:40
=C0 : BOUCADAIR Mohamed = RD-CORE-CAE
Cc :=20 behave@ietf.org; shara@ietf.org
Objet : Re: [BEHAVE] TR: = I-D=20 Action:draft-boucadair-pppext-portrange-option-00.txt

Mohamed,

Thanks for this = draft.
It=20 does contribute to the promotion of Port-Extended IPv4 addressing, which = is the=20 only known way to AVOID, during the = IPv4-IPv6=20 coexistence period, that users MUST depend on CGNs .=20

Yet, the mask and value parameters which you propose, to express = port=20 ranges, are in my understanding, both too complex and too limited.
- = too=20 complex, because it's hard to imagine a practical use of non contiguous = port=20 ranges. (In particular I don't see where to use the chosen example of = ports=20 xxx0x1xxxxxxxxxx.)
[Med] Non contiguous port ranges are only on example. = The=20 specification supports both. There is no overhead of the spec = which is=20 due to the type of the assigned port ranges 
- too = limited, because it cannot express an IPv4-address extension based on = dynamic=20 ports, which, as I already discussed in various places, is IMO the most = simple=20 choice for a realistic deployment.
[Med] Contiguous port = ranges could=20 be used for this purpose.  

For example, no = mask and=20 value parameters can express 4-bits = address=20 extension based on dynamic ports (i.e. with ports 11EEEExxxxxxxxxx, = where Es are=20 the address extension bits).

If no = need is=20 identified for more complex solutions than dynamic-ports only, I then = propose to=20 amend the document so that parameters are simplified, e.g. but not = necessarily=20 to become:
   Port Prefix Length (6 in the above=20 example).
   Port Prefix Value (11EEEE0000000000 in the = above=20 example).
[Med] I need to think about that a = little bit=20 more. 

Some = other set of=20 parameters could be proposed if  a = good reason=20 would be found to also use Well-Known ports and/or Registered ports. (I = don't=20 see such a reason, while avoiding interference with firewalls is an = important=20 reason  against),
[Med] I think = assigning the overall=20 well known port range to a single user is not **fair**, IMO means=20 to distributed these values should be encouraged. And again, = this is=20 naturally supported by our proposal. The values to be carried in an IPCP = conf=20 message is out of scope. SP are free to assign the Port Masks they=20 want!

Cheers,

RD



------_=_NextPart_001_01C98845.927F5798-- From pierre.levis@orange-ftgroup.com Fri Feb 6 03:58:13 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51FE03A6A77; Fri, 6 Feb 2009 03:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.078 X-Spam-Level: X-Spam-Status: No, score=-3.078 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hT6f1HsZ-7Wi; Fri, 6 Feb 2009 03:58:12 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id ED6E93A68D3; Fri, 6 Feb 2009 03:58:11 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Feb 2009 12:58:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Feb 2009 12:58:05 +0100 Message-ID: In-Reply-To: <014b01c9882a$19255210$c2f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [shara] [BEHAVE]TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt Thread-Index: AcmH6rF7O8eIFT3dRwGVzm6VhD6rmwADK9cQAAsCqgAAANc0wAAE+lpA From: To: , , , X-OriginalArrivalTime: 06 Feb 2009 11:58:07.0107 (UTC) FILETIME=[2C710530:01C98852] Cc: behave@ietf.org, shara@ietf.org Subject: Re: [shara] [BEHAVE]TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 11:58:13 -0000 =20 > De la part de Dan Wing > >=20 > > Thank you for your comment. > >=20 > > There is a subtlety between subnet mask and port mask:=20 > > subnets need to be hierarchical but not port ranges! >=20 > I disagree. Port ranges all belong to the same IP address --=20 > from the view of the rest of the Internet. This is akin to the=20 > rest of the Internet's view of a subnet. It is only the local > IP address (subnet) that is aware of the separation of ports > (or IP addresses) to individual hosts. >=20 I see your point. What we had in mind is different; when we say subnets are hierarchical we mean a subnet can be in a bigger subnet which can be in a bigger subnet, and so forth (within the limit of the 32 bits!). There are some cases where this scheme can apply to port ranges, when several A+P devices are cascaded, as a CPE and its hosts. But in a configuration where only CPEs are Port Range-enabled there is no hierarchy from this standpoint. Another difference with subnets is if subnet bits are not contiguous, the bits in between do exist in the address, are completely part of the address, and refer, as a whole, to the host id. If Port Range bits are not contiguous, there are no other significant bits melt with that have a separate meaning. What I'm trying to say is, it is not because non contiguous bits are a bad thing for subnets that they are automatically bad for Port Ranges. Regards, Pierre From remi.despres@free.fr Fri Feb 6 01:42:39 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC26D3A6BA9; Fri, 6 Feb 2009 01:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.514 X-Spam-Level: X-Spam-Status: No, score=-0.514 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xd4oOzXtUmoN; Fri, 6 Feb 2009 01:42:39 -0800 (PST) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by core3.amsl.com (Postfix) with ESMTP id 48E533A6BA0; Fri, 6 Feb 2009 01:42:36 -0800 (PST) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id 7940B81805F; Fri, 6 Feb 2009 10:42:33 +0100 (CET) Received: from RD-Mac.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp3-g21.free.fr (Postfix) with ESMTP id 49B7C8181A6; Fri, 6 Feb 2009 10:42:31 +0100 (CET) Message-ID: <498C0586.2040201@free.fr> Date: Fri, 06 Feb 2009 10:40:22 +0100 From: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com References: <6CF039C5B32037498B02251E11CDE6B007BB7096@ftrdmel3> In-Reply-To: <6CF039C5B32037498B02251E11CDE6B007BB7096@ftrdmel3> Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 06 Feb 2009 08:30:04 -0800 Cc: behave@ietf.org, shara@ietf.org Subject: Re: [shara] [BEHAVE] TR: I-D Action:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 09:42:40 -0000 Mohamed,

Thanks for this draft.
It does contribute to the promotion of Port-Extended IPv4 addressing, which is the only known way to AVOID, during the IPv4-IPv6 coexistence period, that users MUST depend on CGNs .

Yet, the mask and value parameters which you propose, to express port ranges, are in my understanding, both too complex and too limited.
- too complex, because it's hard to imagine a practical use of non contiguous port ranges. (In particular I don't see where to use the chosen example of ports xxx0x1xxxxxxxxxx.)
- too limited, because it cannot express an IPv4-address extension based on dynamic ports, which, as I already discussed in various places, is IMO the most simple choice for a realistic deployment.

For example, no mask and value parameters can express 4-bits address extension based on dynamic ports (i.e. with ports 11EEEExxxxxxxxxx, where Es are the address extension bits).

If no need is identified for more complex solutions than dynamic-ports only, I then propose to amend the document so that parameters are simplified, e.g. but not necessarily to become:
   Port Prefix Length (6 in the above example).
   Port Prefix Value (11EEEE0000000000 in the above example).

Some other set of parameters could be proposed if  a good reason would be found to also use Well-Known ports and/or Registered ports. (I don't see such a reason, while avoiding interference with firewalls is an important reason  against),

Cheers,

RD



From remi.despres@free.fr Fri Feb 6 04:57:03 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C71B83A69B0 for ; Fri, 6 Feb 2009 04:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.243 X-Spam-Level: X-Spam-Status: No, score=-1.243 tagged_above=-999 required=5 tests=[AWL=0.706, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOvDUJSqwPsB for ; Fri, 6 Feb 2009 04:57:03 -0800 (PST) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by core3.amsl.com (Postfix) with ESMTP id DB5203A695D for ; Fri, 6 Feb 2009 04:57:01 -0800 (PST) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id C1F7C4B005A; Fri, 6 Feb 2009 13:56:58 +0100 (CET) Received: from RD-Mac.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp2-g21.free.fr (Postfix) with ESMTP id 50CDD4B01F6; Fri, 6 Feb 2009 13:56:55 +0100 (CET) Message-ID: <498C3316.9030008@free.fr> Date: Fri, 06 Feb 2009 13:54:46 +0100 From: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com References: <6CF039C5B32037498B02251E11CDE6B007BB7096@ftrdmel3> <498C0586.2040201@free.fr> <6CF039C5B32037498B02251E11CDE6B007BB754F@ftrdmel3> In-Reply-To: <6CF039C5B32037498B02251E11CDE6B007BB754F@ftrdmel3> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 06 Feb 2009 08:30:04 -0800 Cc: Gabor Bajko , shara@ietf.org Subject: Re: [shara] [BEHAVE] TR: I-D Action:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 12:57:03 -0000 Thanks for your reaction. Comments below. `RD mohamed.boucadair@orange-ftgroup.com - le (m/j/a) 2/6/09 11:27 AM: > If no need is identified for more complex solutions than dynamic-ports only, I then propose to amend the document so that parameters are simplified, e.g. but not necessarily to become: > Port Prefix Length (6 in the above example). > Port Prefix Value (11EEEE0000000000 in the above example). > [Med] I need to think about that a little bit more. > I do hope we can converge on something. Note that dynamic-ports only is not per se incompatible with some sort of cryptographic mechanism (like the one you are proposing with Gabor and Teemu). Of course only bits 2 to 15 of a dynamic port could be concerned with cryptography. > [Med] I think assigning the overall well known port range to a single user is not **fair**, IMO means to distributed these values should be encouraged. And again, this is naturally supported by our proposal. The values to be carried in an IPCP conf message is out of scope. SP are free to assign the Port Masks they want! Note that in my proposal, NO user gets well-known ports as a way to extend its IPv4 address (no unfairness then). From randy@psg.com Fri Feb 6 21:20:46 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5E6E3A68A9; Fri, 6 Feb 2009 21:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sz6WkdLPSeeC; Fri, 6 Feb 2009 21:20:46 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id CFFC73A67A8; Fri, 6 Feb 2009 21:20:45 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LVfcT-000IKQ-5l; Sat, 07 Feb 2009 05:20:45 +0000 Received: from rmac.psg.com.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 4AA592C4078; Fri, 6 Feb 2009 14:58:47 +0800 (HKT) Date: Fri, 06 Feb 2009 14:58:47 +0800 Message-ID: From: Randy Bush To: "Dan Wing" In-Reply-To: <014a01c98826$c4ad5b40$c2f0200a@cisco.com> References: <6CF039C5B32037498B02251E11CDE6B007BB7096@ftrdmel3> <004e01c987e9$8b837df0$c2f0200a@cisco.com> <6CF039C5B32037498B02251E11CDE6B007BB734A@ftrdmel3> <014a01c98826$c4ad5b40$c2f0200a@cisco.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: behave@ietf.org, shara@ietf.org Subject: Re: [shara] [BEHAVE] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 05:20:46 -0000 >>> subnets need to be hierarchical >> fwiw, paul francis publiched a scheme back in about '92 where >> subnet masks were not contiguous. it was self-consistent. > Can you describe the adoption of the scheme in the last 16 years? no need to. the point is that they need not be. you are not required to like it. randy From dwing@cisco.com Thu Feb 19 17:14:39 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF0E3A69E3 for ; Thu, 19 Feb 2009 17:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYDCC7LCnCYE for ; Thu, 19 Feb 2009 17:14:38 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id AE80C3A68B4 for ; Thu, 19 Feb 2009 17:14:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,237,1233532800"; d="scan'208";a="253144998" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 20 Feb 2009 01:14:39 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1K1EdY8014429; Thu, 19 Feb 2009 17:14:39 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n1K1EcFL013515; Fri, 20 Feb 2009 01:14:38 GMT From: "Dan Wing" To: , , , References: <6CF039C5B32037498B02251E11CDE6B007BB7096@ftrdmel3><004e01c987e9$8b837df0$c2f0200a@cisco.com><6CF039C5B32037498B02251E11CDE6B007BB734A@ftrdmel3> <014b01c9882a$19255210$c2f0200a@cisco.com> Date: Thu, 19 Feb 2009 17:14:38 -0800 Message-ID: <07b901c992f8$99e3fd10$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcmH6rF7O8eIFT3dRwGVzm6VhD6rmwADK9cQAAsCqgAAANc0wAABCkFAArFNDuA= In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6456; t=1235092479; x=1235956479; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[shara]=20[BEHAVE]=09TR=3AI-DAction=3Ad raft-boucadair-pppext-portrange-option-00.txt |Sender:=20; bh=qQ3pwc8sLWGEV2YfwWQ9wFpRqMUIvOZmW4I52Vtus8c=; b=sAURpRmowHmXGTA8jRdHtTX0k06+OrhIuAur9nYA9UN5NfyzzM8ENExRPx 30BGQ0Gj2TLLZtYiwk2IYil2ShM7Hut0C6bN1kGTMjPvwXSLK0G/4cw0J5D+ wp7cbJkQDz; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: shara@ietf.org Subject: Re: [shara] [BEHAVE] TR:I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 01:14:40 -0000 =20 > -----Original Message----- > From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com]=20 > Sent: Thursday, February 05, 2009 11:37 PM > To: dwing@cisco.com; mohamed.boucadair@orange-ftgroup.com;=20 > dthaler@windows.microsoft.com; randy@psg.com > Cc: behave@ietf.org; shara@ietf.org > Subject: RE: [shara] [BEHAVE]=20 > TR:I-DAction:draft-boucadair-pppext-portrange-option-00.txt >=20 > Dan, >=20 > The attached document should appear shortly in the ietf=20 > directories. Section 2 tries to justify the need for=20 > non-contiguous port range allocation. Sections 4 and 5=20 > explain how the non-contiguous port range and random port=20 > delegation works. (dropped BEHAVE) Thanks. I finally had time to look at this again. It is now posted at http://tools.ietf.org/html/draft-bajko-pripaddrassign-00 Thanks for providing explanation for the bit-mask. I now understand=20 why a bit mask is being proposed. The two schemes described in your draft (bit mask and cryptographic function) appear to be the best achievable. More complex mechanisms such as changing the secret key [1] would=20 require even more coordination between the customer premise=20 equipment and the service provider's equipment, which seems=20 untenable. [1] http://tools.ietf.org/html/draft-ietf-tsvwg-port-randomization-02#section= -3.4 -d > - gabor >=20 > >-----Original Message----- > >From: shara-bounces@ietf.org=20 > [mailto:shara-bounces@ietf.org] On Behalf Of > >ext Dan Wing > >Sent: Thursday, February 05, 2009 11:11 PM > >To: mohamed.boucadair@orange-ftgroup.com;=20 > dthaler@windows.microsoft.com; > >randy@psg.com > >Cc: behave@ietf.org; shara@ietf.org > >Subject: Re: [shara] [BEHAVE] TR: I-DAction:draft-boucadair-pppext- > >portrange-option-00.txt > > > > > > > > > >> -----Original Message----- > >> From: mohamed.boucadair@orange-ftgroup.com > >> [mailto:mohamed.boucadair@orange-ftgroup.com] > >> Sent: Thursday, February 05, 2009 10:35 PM > >> To: dthaler@windows.microsoft.com; randy@psg.com; dwing@cisco.com > >> Cc: behave@ietf.org; shara@ietf.org > >> Subject: RE: [BEHAVE] [shara]TR: > >> I-DAction:draft-boucadair-pppext-portrange-option-00.txt > >> > >> > >> Thank you for your comment. > >> > >> There is a subtlety between subnet mask and port mask: > >> subnets need to be hierarchical but not port ranges! > > > >I disagree. Port ranges all belong to the same IP address -- > >from the view of the rest of the Internet. This is akin to the > >rest of the Internet's view of a subnet. It is only the local > >IP address (subnet) that is aware of the separation of ports > >(or IP addresses) to individual hosts. > > > >> Non contiguous port range is proposed as a solution to assign > >> with a single mask for instance "M" Port Ranges with "n" Port > >> Ranges within the well-known Port Range. This means that > >> well-known PR won't be assigned to the same user. > >> > >> I see other advantages on the usage of non contiguous PR: > >> e.g. an attacker would have more difficulty to "guess" a port > >> value within the Port Range. > > > >draft-boucadair-pppext-portrange-option does not describe > >this advantage. I am not convinced this would thwart an > >attacker significantly. If a user is permitted XXXX ports, > >an attacker can determine what ports they are by a range > >of contiguous bits or a range of non-contiguous bits. I > >agree the attacker has to perform more probes to learn > >the non-contiguous bit pattern, of course. But an analysis > >of this advantage would be useful. > > > >> By the way, I have the same question as Randy. > > > >I am not talking about the proverbial Grandma or "Joe > >Sixpack" when I say "users". Those users have no > >need to understand 255.255.255.0, or IP addresses, > >or ARP. > > > >However, network administrators are users, and they need > >to understand these bit-masks in order to successfully > >configure equipment. Based on industry experience with > >IP, non-contiguous subnet masks are not used in very > >many networks. This is because the complexity to use > >them exceeds their value. > > > >Justification of the value of non-contiguous port masks > >would be useful. > > > >-d > > > > > >> > >> > >> Med > >> > >> > >> > >> -----Message d'origine----- > >> De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] > >> De la part de Dave Thaler > >> Envoy=E9 : vendredi 6 f=E9vrier 2009 02:10 > >> =C0 : Randy Bush; Dan Wing > >> Cc : behave@ietf.org; shara@ietf.org > >> Objet : Re: [BEHAVE] [shara]TR: > >> I-DAction:draft-boucadair-pppext-portrange-option-00.txt > >> > >> Yes. :) > >> > >> I had the same feedback last IETF. > >> This is the same thing all over again as a non-contiguous > >> subnet mask, which the industry effectively got rid of as > >> having too many problems in practice (but being fine in theory). > >> > >> -Dave > >> > >> -----Original Message----- > >> From: shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] > >> On Behalf Of Randy Bush > >> Sent: Thursday, February 05, 2009 3:35 PM > >> To: Dan Wing > >> Cc: behave@ietf.org; shara@ietf.org > >> Subject: Re: [shara] [BEHAVE] TR: > >> I-DAction:draft-boucadair-pppext-portrange-option-00.txt > >> > >> > I like this draft overall, but I would restrict this=20 > so that only > >> > contiguous port ranges are permitted. Non-contiguous > >> subnet masks are > >> > difficult for many people to understand (even today)=20 > and I expect > >> > there would be similar confusion with non-contiguous=20 > port ranges. > >> > >> do people have to understand these? > >> > >> randy > >> _______________________________________________ > >> shara mailing list > >> shara@ietf.org > >> https://www.ietf.org/mailman/listinfo/shara > >> > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www.ietf.org/mailman/listinfo/behave > > > >_______________________________________________ > >shara mailing list > >shara@ietf.org > >https://www.ietf.org/mailman/listinfo/shara >=20 From marcelo@it.uc3m.es Mon Feb 23 01:38:15 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91DEA3A6954 for ; Mon, 23 Feb 2009 01:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.978 X-Spam-Level: X-Spam-Status: No, score=-5.978 tagged_above=-999 required=5 tests=[AWL=0.621, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCJyZuCyWBS5 for ; Mon, 23 Feb 2009 01:38:14 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 3A5173A68AF for ; Mon, 23 Feb 2009 01:38:10 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (195.pool85-53-140.dynamic.orange.es [85.53.140.195]) by smtp01.uc3m.es (Postfix) with ESMTP id 9CE8BB4D1AD; Mon, 23 Feb 2009 10:38:26 +0100 (CET) Message-ID: <49A26E92.3040703@it.uc3m.es> Date: Mon, 23 Feb 2009 10:38:26 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: pierre.levis@orange-ftgroup.com, mohamed.boucadair@orange-ftgroup.com, jeanluc.grimault@orange-ftgroup.com, alain.villefranque@orange-ftgroup.com, shara@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16480.006 Subject: [shara] comments about draft-levis-behave-ipv4-shortage-framework-00.txt X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 09:38:15 -0000 Hi, Thanks for writing this. I have some comments and questions about this draft In section 1. Introduction it reads This document analyses the main issues related to IPv4 Internet access in the context of public IPv4 address exhaustion. The IPv4 Internet access from an IPv6 stack, and the IPv6 Internet access whatever the means, are out of the scope of this memo. I am not sure why is that. I mean, the problem seems to exists in the case the the host is IPv6 and it is using an IPv6-IP^v4 trnaslator to access to the IPv4 Internet, right? Then in section 3. Address Space Multiplicative Factor The purpose of sharing IPv4 addresses is to potentially increase the addressing space. A key parameter is the factor by which ISPs want or need to multiply their IPv4 public address space; and the consequence is the number of customers sharing the same public IPv4 address. The intention is not to replace IPv6. However, we should be very careful; whatever the network model deployed, applications and business will run on top of it. The fact that the IPv4 shortage mechanisms will not postpone IPv6 deployment, heavily relies on voluntarism. While i agree with this, i think it is imporntat to understand the impact of the shara work on the IPv6 deployment. This is why i am puzzled that you haven't considered the shara problem for IPv6 only clients accessing the IPv4 Internet through an IPv4 IPv6 translator. Providing a solution for the shara problem to IPv4 only hosts and not providing a solution for IPv6 only hosts, will make staying in IPv4 even more attractive than migrating to IPv6. So, i think that solving the share problem for IPv6 only hosts should be at least as important than solving it for the IPv4 clients (i do understand that solving it for IPv4 clients is more pressing, but solving it for the IPv6 clients is critical to not hinder the IPPv6 deployment) 6.3. Scarcity of Private Addressing According to [RFC1918], IPv4 private addresses must be chosen in the following ranges: o 10/8 o 172.16/12 o 192.168/16 There is a potential of 2 at the power of (224 + 220 + 216) addresses, or 17,891,328 addresses. Actually, private addresses are not that abundant when deployments are concerned. Some ISPs already use private addresses within their networks for specific usage such as walled garden services, in a way they cannot reuse them for another usage. As a consequence, the smallness of the IPv4 private address pool available for the Internet service could force some ISPs to use Virtual Private Networks (VPNs) such as [RFC4364] to allow reusing the same private addresses several times with no routing overlaps. This brings a lot of complexity in network configuration and management. It has been suggested to make the 240./4 block available for private addressing [I-D.wilson-class-e]. This address block, formerly designated as "Class E", is still noted as being reserved in the IANA IPv4 address registry. If it were reassigned for private addressing that would yield around 268 millions extra private addresses. However, many current implementations of the TCP/IP protocol stack do not allow the use of the 240./4 block. This is a severe blocking point for a lot of existing devices: CPE, NAT or routers. This issue will only be solved when the vendors' implementations accept the (240./4) addresses. Another suggestion [I-D.shirasaki-isp-shared-addr] is to reserve some public blocks (typically three or four /8) only for internal usage. So far, there has been no consensus upon this proposal. So, what is the the exact aspect of this issue that needs to be considered when looking into IPv4 sharing solutions? 6.4. Impact on Information System The IPv4 address shortage solutions could add port information in the Information System (IS) at different levels. For instance, the possibility to give either a unique or a shared address, coupled or not with an IPv6 address, could yield several types of customers to deal with in the IS: IPv4 unique only, IPv4 shared only, IPv4 unique + IPv6, IPv4 shared + IPv6, IPv6 only. The impact on the IS platforms and IS applications should be evaluated and assessed. I don't understand what you mean by information system in this section, could you expand or include an example? 6.5. Port Related Entries in the ISP Equipment Additional data related to port information should be stored and maintained by the ISP equipment. As an example, a set of entries (e.g. session states, binding entries) are to be instantiated and maintained. The logic instantiation (behavior and not necessarily detailed algorithms) of these entries should be standardized to avoid interoperability problems, and ease management tasks. Optimization means for instantiating new entries should be investigated and deployed if required. In addition, the amount of entries to be maintained should not be too big. I am not sure what is the issue been considered here.... is the scalability of the solution or do you have some other issue in mind? Regards, marcelo From pierre.levis@orange-ftgroup.com Mon Feb 23 22:49:07 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AF5E3A6861 for ; Mon, 23 Feb 2009 22:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNaAVLB33jld for ; Mon, 23 Feb 2009 22:49:06 -0800 (PST) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 153423A6839 for ; Mon, 23 Feb 2009 22:49:02 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 07:49:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Feb 2009 07:49:15 +0100 Message-ID: In-Reply-To: <49A26E92.3040703@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments about draft-levis-behave-ipv4-shortage-framework-00.txt Thread-Index: AcmVmpCRlkQk8jlMTvmoyfyHXoekUQAr7+dw References: <49A26E92.3040703@it.uc3m.es> From: To: , X-OriginalArrivalTime: 24 Feb 2009 06:49:16.0769 (UTC) FILETIME=[02EF5510:01C9964C] Cc: alain.villefranque@orange-ftgroup.com Subject: Re: [shara] comments about draft-levis-behave-ipv4-shortage-framework-00.txt X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 06:49:07 -0000 Hi Marcelo,=20 Thank you for your comments,please find my answers below:=20 -----Message d'origine----- De : marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 Envoy=E9 : lundi 23 f=E9vrier 2009 10:38 =C0 : LEVIS Pierre RD-CORE-CAE; BOUCADAIR Mohamed RD-CORE-CAE; GRIMAULT = Jean-Luc RD-CORE-CAE; VILLEFRANQUE Alain RD-CORE-CAE; shara@ietf.org Objet : comments about draft-levis-behave-ipv4-shortage-framework-00.txt Hi, Thanks for writing this. I have some comments and questions about this draft In section 1. Introduction it reads This document analyses the main issues related to IPv4 Internet access in the context of public IPv4 address exhaustion. The IPv4 Internet access from an IPv6 stack, and the IPv6 Internet access whatever the means, are out of the scope of this memo. I am not sure why is that. I mean, the problem seems to exists in the = case the the host is IPv6 and it is using an IPv6-IP^v4 trnaslator to = access to the IPv4 Internet, right? PL> Yes you're right, in the case of IPv6-IPv4 translation the need to = spare IPv4 public addresses still apply. Then in section 3. Address Space Multiplicative Factor The purpose of sharing IPv4 addresses is to potentially increase the addressing space. A key parameter is the factor by which ISPs want or need to multiply their IPv4 public address space; and the consequence is the number of customers sharing the same public IPv4 address. The intention is not to replace IPv6. However, we should be very careful; whatever the network model deployed, applications and business will run on top of it. The fact that the IPv4 shortage mechanisms will not postpone IPv6 deployment, heavily relies on voluntarism. While i agree with this, i think it is imporntat to understand the = impact of the shara work on the IPv6 deployment. This is why i am = puzzled that you haven't considered the shara problem for IPv6 only = clients accessing the IPv4 Internet through an IPv4 IPv6 translator.=20 Providing a solution for the shara problem to IPv4 only hosts and not = providing a solution for IPv6 only hosts, will make staying in IPv4 even = more attractive than migrating to IPv6. So, i think that solving the share problem for IPv6 only hosts should be = at least as important than solving it for the IPv4 clients (i do = understand that solving it for IPv4 clients is more pressing, but = solving it for the IPv6 clients is critical to not hinder the IPPv6 deployment) PL> I first excluded this issue because I thought it was not the most = urgent case, but re-considering it I guess you're right, it is indeed an = important issue and I will not explicitly exclude it in the next = version. 6.3. Scarcity of Private Addressing According to [RFC1918], IPv4 private addresses must be chosen in the following ranges: o 10/8 o 172.16/12 o 192.168/16 There is a potential of 2 at the power of (224 + 220 + 216) addresses, or 17,891,328 addresses. Actually, private addresses are not that abundant when deployments are concerned. Some ISPs already use private addresses within their networks for specific usage such as walled garden services, in a way they cannot reuse them for another usage. As a consequence, the smallness of the IPv4 private address pool available for the Internet service could force some ISPs to use Virtual Private Networks (VPNs) such as [RFC4364] to allow reusing the same private addresses several times with no routing overlaps. This brings a lot of complexity in network configuration and management. It has been suggested to make the 240./4 block available for private addressing [I-D.wilson-class-e]. This address block, formerly designated as "Class E", is still noted as being reserved in the IANA IPv4 address registry. If it were reassigned for private addressing that would yield around 268 millions extra private addresses. However, many current implementations of the TCP/IP protocol stack do not allow the use of the 240./4 block. This is a severe blocking point for a lot of existing devices: CPE, NAT or routers. This issue will only be solved when the vendors' implementations accept the (240./4) addresses. Another suggestion [I-D.shirasaki-isp-shared-addr] is to reserve some public blocks (typically three or four /8) only for internal usage. So far, there has been no consensus upon this proposal. So, what is the the exact aspect of this issue that needs to be = considered when looking into IPv4 sharing solutions? PL> I need to add a sentence to make it clear, such as: "What needs to = be considered is to what extent the IPv4 sharing solution makes use of = IPv4 private addresses". For example, if your solution is Double NAT, one NAT-level in the CPE = and one NAT-level in the Network, you'll give private addresses to the = CPEs, and some ISPs may encounter both an IPv4 public and an IPv4 = private address shortage. This is one argument for DS-lite vs. Double = NAT. 6.4. Impact on Information System The IPv4 address shortage solutions could add port information in the Information System (IS) at different levels. For instance, the possibility to give either a unique or a shared address, coupled or not with an IPv6 address, could yield several types of customers to deal with in the IS: IPv4 unique only, IPv4 shared only, IPv4 unique + IPv6, IPv4 shared + IPv6, IPv6 only. The impact on the IS platforms and IS applications should be evaluated and assessed. I don't understand what you mean by information system in this section,=20 could you expand or include an example? PL> I will add in this paragraphe a sentence such as: "The impact on the = IS platforms and applications handling the administrative and technical = information to control the activation of services and to manage the = customer profiles, should be evaluated and assessed." And add also the following example: "Common practice used to rely upon the global IPv4 address assigned to a CPE device for customer identification purposes. The forthcoming address depletion therefore encourages ISPs to revisit their customer identification schemes since global IPv4 addresses will be shared amongst several customers." 6.5. Port Related Entries in the ISP Equipment Additional data related to port information should be stored and maintained by the ISP equipment. As an example, a set of entries (e.g. session states, binding entries) are to be instantiated and maintained. The logic instantiation (behavior and not necessarily detailed algorithms) of these entries should be standardized to avoid interoperability problems, and ease management tasks. Optimization means for instantiating new entries should be investigated and deployed if required. In addition, the amount of entries to be maintained should not be too big. I am not sure what is the issue been considered here.... is the=20 scalability of the solution or do you have some other issue in mind? PL> Basically it is scalability, complexity, performance, cost.=20 The main point if the number of entries you have.=20 According to the solution it can vary from millions of entries (CGN) to = almost no entries (port range with clever handling of port based routing = -see R=E9mi Despres's proposal for instance-) I will make it clearer. Regards, marcelo PL> Regards, Pierre From denghui02@gmail.com Wed Feb 25 04:37:17 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0F1728C19B for ; Wed, 25 Feb 2009 04:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.799, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48HRCd2oE8hD for ; Wed, 25 Feb 2009 04:37:17 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id 27C4128C16F for ; Wed, 25 Feb 2009 04:37:17 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2791102rvb.49 for ; Wed, 25 Feb 2009 04:37:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=IGOFEEf2JlE5p4FUjbq5H9LYH/Muzg06iMJwPIfyV2E=; b=XibGJLDMsZ3/jZ3B+T8bco/GEY3q+NXxXb42emxjMWzyoQ3RjkALSeIggg1Bt6+Xt+ Lzi1dN6y2+fxt6fCpRFp7XyzOiQc0X5XsU6AFKylvqnmZbKWe+2EwHLcwlhksmtl3bsM tKWTZ6L/uwhdFqraDzDmwG4NFWAd2tfVa1W38= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=PI9ap2tK2QETMSKfeuA+xzCVh0+U4DQVh8drSo0VzijQMlP9JxV67JJwtAEnWxwhwi sJVo+fmDIcOfH0SzRBgup4finUe/Ap98CtdXtLiee9JZhGZ2HDUD+6ZNZRgxrsC0NYlF E8mDyKVFlv9XtEo9mzrtc9pwwEiayvSuemO/k= MIME-Version: 1.0 Received: by 10.143.156.17 with SMTP id i17mr46668wfo.13.1235565457416; Wed, 25 Feb 2009 04:37:37 -0800 (PST) Date: Wed, 25 Feb 2009 20:37:37 +0800 Message-ID: <1d38a3350902250437v3ad37690sc5d2dca7f78dddd4@mail.gmail.com> From: Hui Deng To: shara@ietf.org Content-Type: multipart/alternative; boundary=001636e1fca22fa1350463bd80c6 Subject: [shara] comments about draft-bajko-pripaddrassign-00 X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 12:37:17 -0000 --001636e1fca22fa1350463bd80c6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, Authors. I read through the document 1) when some clients support option-pra, but others don't, will server behavior section describe this scenario? 2) how to handle lease life time of dhcp address thanks -Hui --001636e1fca22fa1350463bd80c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello, Authors.
=A0
I read through the document
1) when some clients support option-pra, but others don't, will se= rver behavior section
describe this scenario?
=A0
2) how to handle lease life time=A0of dhcp address
=A0
thanks
=A0
-Hui
--001636e1fca22fa1350463bd80c6-- From teemu.savolainen@nokia.com Wed Feb 25 04:57:36 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2197728C169 for ; Wed, 25 Feb 2009 04:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.255 X-Spam-Level: X-Spam-Status: No, score=-6.255 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMn3kAH0J1Fq for ; Wed, 25 Feb 2009 04:57:35 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 5ECD23A688A for ; Wed, 25 Feb 2009 04:57:34 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1PCvcoC028349; Wed, 25 Feb 2009 14:57:50 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 14:57:33 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 14:57:32 +0200 Received: from nok-am1mhub-07.mgdnok.nokia.com (65.54.30.14) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 25 Feb 2009 13:57:32 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-07.mgdnok.nokia.com ([65.54.30.14]) with mapi; Wed, 25 Feb 2009 13:57:32 +0100 From: To: , Date: Wed, 25 Feb 2009 13:56:59 +0100 Thread-Topic: [shara] comments about draft-bajko-pripaddrassign-00 Thread-Index: AcmXReIow6JlaZIPRJ+ROmdvzrZk0AAAFaXA Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F27E89F0EEF@NOK-EUMSG-01.mgdnok.nokia.com> References: <1d38a3350902250437v3ad37690sc5d2dca7f78dddd4@mail.gmail.com> In-Reply-To: <1d38a3350902250437v3ad37690sc5d2dca7f78dddd4@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E89F0EEFNOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 25 Feb 2009 12:57:32.0906 (UTC) FILETIME=[9FAC04A0:01C99748] X-Nokia-AV: Clean Subject: Re: [shara] comments about draft-bajko-pripaddrassign-00 X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 12:57:36 -0000 --_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E89F0EEFNOKEUMSG01mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, 1) It should be described in 6.2 Server behaviour: -- If OPTION-IPv4-PRA is not present in DHCPDISCOVER, the server SHOULD allocate full unrestricted public or private [RFC1918] IPv4 address to the client, if available, by generating a DHCPOFFER as described in [RFC2131]. -- and forward. So essentially the same DHCP server is allocating both full and port restri= cted IPv4 addresses, depending on host's support. 2) Excellent question. The lease time will have to be per port set instead = of per IPv4 address as currently. - For a client this does not make any difference when compared to full IPv4= address (client has to renew the address and when the lease ends, the IPv4= address expires whatever was the size of allocated port set) - For the DHCP server this is clearly more complex, though. The DHCP server= has to follow lease times per allocated port set. So if the server splits = an IPv4 address into 10 sets, it has to have lease time follow-up for all t= hose 10 sets. The clients will be varyingly renewing the port set they were= allocated, and also individual port sets may be released/expired individua= lly. For me it looks the DHCP server needs two tables: one for managing full IPv= 4 addresses, and one for managing port-restricted IPv4 addresses. Maybe tho= se could be combined as well if the full IPv4 address is just considered a = port-restricted IPv4 address with single 64K port allocation. I.e. somethin= g like: { 10.0.0.1 - port set FULL } { 10.0.0.2 - port set partial-A } { 10.0.0.2 - port set partial-B } I hope I find time to digg deeper into this before next IETF, but let's see= . Anyhow, I believe the actual impact to lease time management on the serve= r side depends on individual implementations. I hope I answered your questions. Best regards, Teemu ________________________________ From: shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] On Behalf Of e= xt Hui Deng Sent: 25 February, 2009 14:38 To: shara@ietf.org Subject: [shara] comments about draft-bajko-pripaddrassign-00 Hello, Authors. I read through the document 1) when some clients support option-pra, but others don't, will server beha= vior section describe this scenario? 2) how to handle lease life time of dhcp address thanks -Hui --_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E89F0EEFNOKEUMSG01mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
1) It should be described in 6.2 Server=20 behaviour:
--

 = ; =20 If OPTION-IPv4-PRA is not present in DHCPDISCOVER, the server SHOULD= =20

 = ; =20 allocate full unrestricted public or private [RFC1918] IPv4 address= =20

 = ; =20 to the client, if available, by generating a DHCPOFFER as described= =20

 = ; =20 in [RFC2131].    

--
and forward.
 
So essentially the same DHCP server is allocating = both full=20 and port restricted IPv4 addresses, depending on host's support.=20
 
2) Excellent question. The lease time will have to= be per=20 port set instead of per IPv4 address as currently.
- For a client this does not make any difference w= hen=20 compared to full IPv4 address (client has to renew the address and when the= =20 lease ends, the IPv4 address expires whatever was the size of=20 allocated port set)
- Fo= r the DHCP=20 server this is clearly more complex, though. The DHCP server has = to=20 follow lease times per allocated port set. So if the server splits an IPv4= =20 address into 10 sets, it has to have lease time follow-up for all those 10 = sets.=20 The clients will be varyingly renewing the port set they were allocated, an= d=20 also individual port sets may be released/expired=20 individually.
 
For me it looks the DHCP server needs two tables: = one for=20 managing full IPv4 addresses, and one for managing port-restricted IPv4=20 addresses. Maybe those could be combined as well if the full IPv4 address i= s=20 just considered a port-restricted IPv4 address with single 64K port allocat= ion.=20 I.e. something like:
{ 10.0.0.1 - port set FULL }
{ 10.0.0.2 - port set partial-A }
{ 10.0.0.2 - port set partial-B }
 
I hope I find time to digg deeper into this before= next=20 IETF, but let's see. Anyhow, I believe the actual impact to lease time=20 management on the server side depends on individual=20 implementations.
 
I hope I answered your questions.
 
Best regards,
 
  &n= bsp; Teemu

From: shara-bounces@ietf.org=20 [mailto:shara-bounces@ietf.org] On Behalf Of ext Hui=20 Deng
Sent: 25 February, 2009 14:38
To:=20 shara@ietf.org
Subject: [shara] comments about=20 draft-bajko-pripaddrassign-00

Hello, Authors.
 
I read through the document
1) when some clients support option-pra, but others don't, will serv= er=20 behavior section
describe this scenario?
 
2) how to handle lease life time of dhcp address
 
thanks
 
-Hui
--_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E89F0EEFNOKEUMSG01mgd_-- From denghui02@gmail.com Thu Feb 26 05:19:17 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 833F43A6967 for ; Thu, 26 Feb 2009 05:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=0.715, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6jCZc8fuK2E for ; Thu, 26 Feb 2009 05:19:16 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id DB1803A6916 for ; Thu, 26 Feb 2009 05:19:16 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so626120wfd.31 for ; Thu, 26 Feb 2009 05:19:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=XOfitD0t6WSIuDfN2Vb36DRVnSuBYE7T4075IQt3Q7Q=; b=mE3bVIfPvJStQJh6ZQElM40/7+rfPx3/d8xM19jwvgGyH+Q5a8IfD0dnSFDeVFtcOC CYW22Pv2btTqDpIaGHhalkLH7Oo7SgHM67LUx1Zio4ncFvOvjccK/0OKZv9Bx/7fERAm 9OcBxKmK0s3B0uf+qjvwtJ2+f6ls9XeLEPo4A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=EowcYDX07B4bFvl4R4XNOz/cUDPyeImxDo1QqgI68qPO9F4zlOCM+4VGgNXRS/P2hQ mfusx0dJsQ4JDvKDd+AO3XDc/y3PqJL6fiwMXZIRzHGhyoKueuRP3B5+pml8uYfVjze/ pVCxAyr/j82d95fcBnbwNFolUn/JMaWMfoOcY= MIME-Version: 1.0 Received: by 10.142.254.6 with SMTP id b6mr668949wfi.157.1235654377974; Thu, 26 Feb 2009 05:19:37 -0800 (PST) Date: Thu, 26 Feb 2009 21:19:37 +0800 Message-ID: <1d38a3350902260519x22f0e37ay7b7d2831fcb2d325@mail.gmail.com> From: Hui Deng To: shara@ietf.org Content-Type: multipart/alternative; boundary=00504502c3cc43aa770463d2346c Subject: [shara] Questions about draft-boucadair-port-range-01 X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 13:19:17 -0000 --00504502c3cc43aa770463d2346c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear authors, After reading the draft, I have two questions: 1) This draft doesn't describe the DNS work, what happen if the correspondent node need visit node behind the CPE? 2) Some application which couldn't be supported by ALG will not work in this scenarios? thanks -Hui --00504502c3cc43aa770463d2346c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear authors,
=A0
After reading the draft, I have two questions:
1) This draft doesn't describe the DNS work, what happen if the co= rrespondent node need
visit node behind the CPE?
2) Some application which couldn't be supported by ALG will not wo= rk in this scenarios?
=A0
thanks
=A0
-Hui
--00504502c3cc43aa770463d2346c-- From denghui02@gmail.com Thu Feb 26 05:20:38 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18F663A69D4 for ; Thu, 26 Feb 2009 05:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[AWL=0.688, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUk7Al32FkCy for ; Thu, 26 Feb 2009 05:20:37 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id 2D1793A6916 for ; Thu, 26 Feb 2009 05:20:35 -0800 (PST) Received: by gxk22 with SMTP id 22so1305784gxk.13 for ; Thu, 26 Feb 2009 05:20:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=7WxGQ0azsXyBi9v1p0+d/NpIERO6OqRw+IqeSLTDQ/c=; b=pkvyy4um0jCIk+uJFF/QOTj6VZUQyizcTI7lJ0Kw8Ar8LqbWc770IgYs/7S6k3fwpl okx/Rc7g4gSto5piJfvBGtE3N/NTuwhzFa6o/4Zy9xOJV3VeA2SMATwfAQWctgxDVAJe 6hVlOxzv3jE2WfUch+pwXhUgwYus9vTKmqI7Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZQBziInPpr7p4NeFhl/UfnOwtG9war88Gl6zl34hHH+iiAOkzjxMJ32MH+fNPP4p4V wuWonhhKy/hwSx1u4QRP5jKonbhE6GVThwGK9EWit9FDo18Cm8v6Fq+CJ0JWnVvzYbly wakreknX2ldQKIHC9PyE+Qd708DK9eArqNOik= MIME-Version: 1.0 Received: by 10.142.139.14 with SMTP id m14mr662454wfd.253.1235654455767; Thu, 26 Feb 2009 05:20:55 -0800 (PST) In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F27E89F0EEF@NOK-EUMSG-01.mgdnok.nokia.com> References: <1d38a3350902250437v3ad37690sc5d2dca7f78dddd4@mail.gmail.com> <18034D4D7FE9AE48BF19AB1B0EF2729F27E89F0EEF@NOK-EUMSG-01.mgdnok.nokia.com> Date: Thu, 26 Feb 2009 21:20:55 +0800 Message-ID: <1d38a3350902260520u6428447dyc0bc44213772ee42@mail.gmail.com> From: Hui Deng To: teemu.savolainen@nokia.com Content-Type: multipart/alternative; boundary=000e0cd2dc40e6b4dd0463d2388c Cc: shara@ietf.org Subject: Re: [shara] comments about draft-bajko-pripaddrassign-00 X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 13:20:38 -0000 --000e0cd2dc40e6b4dd0463d2388c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Teemu It looks workable, but need to change a lot of thing. thanks. -Hui 2009/2/25 > Hi, > > 1) It should be described in 6.2 Server behaviour: > -- > > If OPTION-IPv4-PRA is not present in DHCPDISCOVER, the server SHOULD > > allocate full unrestricted public or private [RFC1918] IPv4 address > > to the client, if available, by generating a DHCPOFFER as described > > in [RFC2131]. > -- > and forward. > > So essentially the same DHCP server is allocating both full and port > restricted IPv4 addresses, depending on host's support. > > 2) Excellent question. The lease time will have to be per port set instead > of per IPv4 address as currently. > - For a client this does not make any difference when compared to full IPv4 > address (client has to renew the address and when the lease ends, the IPv4 > address expires whatever was the size of allocated port set) > - For the DHCP server this is clearly more complex, though. The DHCP > server has to follow lease times per allocated port set. So if the server > splits an IPv4 address into 10 sets, it has to have lease time follow-up for > all those 10 sets. The clients will be varyingly renewing the port set they > were allocated, and also individual port sets may be released/expired > individually. > > For me it looks the DHCP server needs two tables: one for managing full > IPv4 addresses, and one for managing port-restricted IPv4 addresses. Maybe > those could be combined as well if the full IPv4 address is just considered > a port-restricted IPv4 address with single 64K port allocation. I.e. > something like: > { 10.0.0.1 - port set FULL } > { 10.0.0.2 - port set partial-A } > { 10.0.0.2 - port set partial-B } > > I hope I find time to digg deeper into this before next IETF, but let's > see. Anyhow, I believe the actual impact to lease time management on the > server side depends on individual implementations. > > I hope I answered your questions. > > Best regards, > > Teemu > > ------------------------------ > *From:* shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] *On Behalf > Of *ext Hui Deng > *Sent:* 25 February, 2009 14:38 > *To:* shara@ietf.org > *Subject:* [shara] comments about draft-bajko-pripaddrassign-00 > > Hello, Authors. > > I read through the document > 1) when some clients support option-pra, but others don't, will server > behavior section > describe this scenario? > > 2) how to handle lease life time of dhcp address > > thanks > > -Hui > > --000e0cd2dc40e6b4dd0463d2388c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,=A0Teemu
=A0
It looks workable, but need to change=A0a lot of thing.
thanks.
=A0
-Hui

2009/2/25 <teemu.savolainen@nokia.com>
Hi,
=A0
1) It should be described in 6.2 Server behaviour:
--

=A0=A0 If OPTION-IPv4-PRA is not pre= sent in DHCPDISCOVER, the server SHOULD

=A0=A0 allocate full unrestricted pu= blic or private [RFC1918] IPv4 address

=A0=A0 to the client, if available, = by generating a DHCPOFFER as described

=A0=A0 in [RFC2131].=A0=A0=A0=A0

--
and forward.
=A0
So essentially the same DHCP server is allocating both full an= d port restricted IPv4 addresses, depending on host's support. <= /span>
=A0
2) Excellent question. The lease time will have to be per port= set instead of per IPv4 address as currently.
- For a client this does not make any difference when compared= to full IPv4 address (client has to renew the address and when the lease e= nds, the IPv4 address expires whatever=A0was the size=A0of allocated port s= et)
- For the DHCP server this is clearly more comple= x, though.=A0The DHCP server=A0has to follow lease times per allocated port= set. So if the server splits an IPv4 address into 10 sets, it has to have = lease time follow-up for all those 10 sets. The clients will be varyingly r= enewing the port set they were allocated, and also individual port sets may= be released/expired individually.
=A0
For me it looks the DHCP server needs two tables: one for mana= ging full IPv4 addresses, and one for managing port-restricted IPv4 address= es. Maybe those could be combined as well if the full IPv4 address is just = considered a port-restricted IPv4 address with single 64K port allocation. = I.e. something like:
{=A010.0.0.1 - port set FULL }
{ 10.0.0.2 - port set partial-A }
{ 10.0.0.2 - port set partial-B }
=A0
I hope I find time to digg deeper into this before next IETF, = but let's see. Anyhow, I believe the actual impact to lease time manage= ment on the server side depends on individual implementations.
=A0
I hope I answered your questions.
=A0
Best regards,
=A0
=A0=A0=A0 Teemu

From: shara-bounces@ietf.org [mailto:shara-bounces@ietf.org= ] On Behalf Of ext Hui Deng
Sent: 25 February, 2009 14:38
To: shara@ietf.org
Subject: [shara] c= omments about draft-bajko-pripaddrassign-00

Hello, Authors.
=A0
I read through the document
1) when some clients support option-pra, but others don't, will se= rver behavior section
describe this scenario?
=A0
2) how to handle lease life time=A0of dhcp address
=A0
thanks
=A0
-Hui

--000e0cd2dc40e6b4dd0463d2388c-- From teemu.savolainen@nokia.com Thu Feb 26 05:38:49 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA6AF3A67F7 for ; Thu, 26 Feb 2009 05:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3udSeEPpEyM for ; Thu, 26 Feb 2009 05:38:48 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 401213A69A8 for ; Thu, 26 Feb 2009 05:38:48 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1QDd3Wa021132; Thu, 26 Feb 2009 15:39:05 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 15:38:52 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 15:38:33 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Thu, 26 Feb 2009 14:38:33 +0100 From: To: , Date: Thu, 26 Feb 2009 14:37:59 +0100 Thread-Topic: [shara] Questions about draft-boucadair-port-range-01 Thread-Index: AcmYFO1O0oQeQMhqSwagQNTtGaYrygAATR3g Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F27E8A33BDD@NOK-EUMSG-01.mgdnok.nokia.com> References: <1d38a3350902260519x22f0e37ay7b7d2831fcb2d325@mail.gmail.com> In-Reply-To: <1d38a3350902260519x22f0e37ay7b7d2831fcb2d325@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E8A33BDDNOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 26 Feb 2009 13:38:33.0737 (UTC) FILETIME=[84DAC790:01C99817] X-Nokia-AV: Clean Subject: Re: [shara] Questions about draft-boucadair-port-range-01 X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 13:38:49 -0000 --_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E8A33BDDNOKEUMSG01mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Port restricted addresses certainly provide less functionality than full IP= v4 addresses. My understanding is that 1) would probably work as currently with private I= Pv4 addresses and NATs: node behind CPE finds out what its external IPv4 ad= dress+port is (STUN, UPnP, NAT-PMP) and communicates that by some means to = correspondent node (e.g. with SIP & ICE). 2) Applications requiring ALG would suffer. However, if the port restricted= address is handled by the host instead of CPE, the application itself coul= d be capable of directly utilizing port restricted addresses and thus get p= ossibility for NATless communication. My personal opinion is that application developers should not longer assume= existence of ALGs, especially when number of NATs that would need to imple= ment ALG are growing increasingly - I believe (e.g. my phone has a third-pa= rty NAT (JoikuSpot) that I use when I need to share the HSDPA connection to= my laptop via WLAN - I doubt it has very large set of ALGs implemented..). Best regards, Teemu ________________________________ From: shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] On Behalf Of e= xt Hui Deng Sent: 26 February, 2009 15:20 To: shara@ietf.org Subject: [shara] Questions about draft-boucadair-port-range-01 Dear authors, After reading the draft, I have two questions: 1) This draft doesn't describe the DNS work, what happen if the corresponde= nt node need visit node behind the CPE? 2) Some application which couldn't be supported by ALG will not work in thi= s scenarios? thanks -Hui --_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E8A33BDDNOKEUMSG01mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Port restricted addresses certainly provide less=20 functionality than full IPv4 addresses.
 
My understanding is that 1) would probably work as= =20 currently with private IPv4 addresses and NATs: node behind CPE finds out w= hat=20 its external IPv4 address+port is (STUN, UPnP, NAT-PMP) and communicates th= at by=20 some means to correspondent node (e.g. with SIP & ICE). <= /DIV>
 
2) Applications requiring ALG would suffer. Howeve= r, if the=20 port restricted address is handled by the host instead of CPE, the=20 application itself could be capable of directly utilizing port restric= ted=20 addresses and thus get possibility for NATless=20 communication.
 
My personal opinion is that application developers= should=20 not longer assume existence of ALGs, especially when number of NATs that wo= uld=20 need to implement ALG are growing increasingly - I believe (e.g. my phone h= as a=20 third-party NAT (JoikuSpot) that I use when I need to share the HSDPA conne= ction=20 to my laptop via WLAN - I doubt it has very large set of ALGs=20 implemented..).
 
Best regards,
 
  &n= bsp; Teemu

From: shara-bounces@ietf.org=20 [mailto:shara-bounces@ietf.org] On Behalf Of ext Hui=20 Deng
Sent: 26 February, 2009 15:20
To:=20 shara@ietf.org
Subject: [shara] Questions about=20 draft-boucadair-port-range-01

Dear authors,
 
After reading the draft, I have two questions:
1) This draft doesn't describe the DNS work, what happen if the=20 correspondent node need
visit node behind the CPE?
2) Some application which couldn't be supported by ALG will not work= in=20 this scenarios?
 
thanks
 
-Hui
--_000_18034D4D7FE9AE48BF19AB1B0EF2729F27E8A33BDDNOKEUMSG01mgd_-- From mohamed.boucadair@orange-ftgroup.com Thu Feb 26 23:51:40 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9B0028C208 for ; Thu, 26 Feb 2009 23:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kON5gP5P1+FR for ; Thu, 26 Feb 2009 23:51:40 -0800 (PST) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id A69F628C1E8 for ; Thu, 26 Feb 2009 23:51:39 -0800 (PST) Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 08:52:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Feb 2009 08:51:59 +0100 Message-ID: <6CF039C5B32037498B02251E11CDE6B007CDB05D@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-boucadair-behave-ipv6-portrange-00.txt Thread-Index: AcmYq0h+6e/ICqqLSNKEhX+9jRJKbQABOdaA From: To: X-OriginalArrivalTime: 27 Feb 2009 07:52:00.0124 (UTC) FILETIME=[454EFBC0:01C998B0] Subject: [shara] TR: I-D Action:draft-boucadair-behave-ipv6-portrange-00.txt X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 07:51:40 -0000 =20 Dear all, FYI, we have submitted a new ID. Comments are more than welcome. Cheers Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] De la part de = Internet-Drafts@ietf.org Envoy=E9 : vendredi 27 f=E9vrier 2009 08:15 =C0 : i-d-announce@ietf.org Objet : I-D Action:draft-boucadair-behave-ipv6-portrange-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Flexible IPv6 Migration Scenarios in the Context of = IPv4 Address Shortage Author(s) : M. Boucadair, et al. Filename : draft-boucadair-behave-ipv6-portrange-00.txt Pages : 45 Date : 2009-02-26 This memo presents a solution to solve IPv4 address shortage and ease IPv4-IPv6 interworking. The document presents a set of incremental = steps for the deployment of IPv6 as a means to solve IPv4 address = exhaustion. Stateless IPv4/IPv6 address mapping functions are = introduced and IPv4-IPv6 interconnection scenarios presented. This memo = advocates for a more proactive approach for the deployment of IPv6 into operational networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boucadair-behave-ipv6-portrange= -00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader = implementation to automatically retrieve the ASCII version of the = Internet-Draft. From marcelo@it.uc3m.es Sat Feb 28 11:46:14 2009 Return-Path: X-Original-To: shara@core3.amsl.com Delivered-To: shara@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC8CC3A6848 for ; Sat, 28 Feb 2009 11:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.176 X-Spam-Level: X-Spam-Status: No, score=-6.176 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4twxR1Xtd+NO for ; Sat, 28 Feb 2009 11:46:13 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 609803A6A14 for ; Sat, 28 Feb 2009 11:46:12 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (231.pool85-53-147.dynamic.orange.es [85.53.147.231]) by smtp02.uc3m.es (Postfix) with ESMTP id 9EFEE65A123 for ; Sat, 28 Feb 2009 20:46:34 +0100 (CET) Message-ID: <49A99499.9090008@it.uc3m.es> Date: Sat, 28 Feb 2009 20:46:33 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: shara@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16492.001 Subject: [shara] SHARA scenarios X-BeenThere: shara@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Sharing of an IPv4 Address discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 19:46:14 -0000 Hi, I am trying to understand the scenarios the apply to shara. In other words, whcih are the use cases for A+P type of solutions. Looking into draft-arkko-townsley-coexistence-00, they identify that the following scenarios where the A+P (or distributed NAT approaches) can be used. The problem that A+P attempts to solve is defined in section 2.1. Reaching the IPv4 Internet +----+ +---------------+ IPv4 host(s)-----+ GW +------IPv4-------------| IPv4 Internet | +----+ +---------------+ <---private v4--->NAT<--------------public v4-----------------> Figure 1: Accessing the IPv4 Internet today ... Taking the typical residential subscriber as an example, each subscriber line is allocated one global IPv4 address for it to use with as many devices as the NAT GW and local network can handle. As IPv4 address space becomes more constrained and without substantial movement to IPv6, it is expected that service providers will be pressured to assign a single global IPv4 address to multiple subscribers. Indeed, in some deployments this is already the case. So, they identify the following A+P deployment possibilities. one frac addr one public addr +----+ +---+ +-------------+ IPv4 host(s)-----+ GW +-----p2p link------+CGN+--+IPv4 Internet| +----+ +---+ +-------------+ <---private v4---> NAT <----public v4---> (distributed, over a p2p link) Figure 3: Distributed-NAT service and one frac addr one public addr +----+ +---+ +-------------+ IPv4 host(s)-----+ GW +======tunnel=======+CGN+--+IPv4 Internet| +----+ +---+ +-------------+ <---private v4---> NAT <----public v4---> (distributed, over a tunnel) Figure 4: Point-to-point link created through a tunnel These seem clear cases for A+P. Next, it seems that the above cases can be combined with the problem they describe in section 2.2. Running out of IPv4 Private Address Space, in particular with the following scenario: IPv6-only network +----+ +---+ +-------------+ IPv4 host--------+ GW +=======tunnel========+CGN+--+IPv4 Internet| +----+ +---+ +-------------+ <---private v4----> <----- v4 over v6 -----> <---public v4----> Figure 5: Running IPv4 over IPv6-only network I understand that this case is simply changing the tunnel technology used in the figure 4 above, so current A+P proposals should work without much problem in this scenario as well. Would this be correct? In any case, imho there are a couple of observations to make: - IMHO it is important that whatever A+P solution supports the above scenario and this should be explicitly included in the scope of the work - I understand the work to support this scenario is being done in the sofwires WG, so i think it would be important to understand how the A+P solution would interact with the dula stack lite mechanism defined in softwires to support this scenario. Does anyone can shed some light on this? Now, i think there is another scenario that it is related to the A+P, that is also covered in draft-arkko-townsley-coexistence-00 Section 2.3. Enterprise IPv6 Only Networks describes a site that is running only IPv6. The proposed approach to support this scenario is depicted in the draft as follows: +----+ +-------------+ | +------------------+IPv6 Internet+ | | +-------------+ IPv6 host-----------------+ GW | | | +-------------+ | +------------------+IPv4 Internet+ +----+ +-------------+ <-------------------------public v6-----------------------------> <-------public v6--------->NAT<----------public v4--------------> Figure 7: Enterprise IPv6-only network Now, i think that we need to analyse this situation a bit more in depth in order to understand how this related to A+P type of solutions. The GW depicted in the picture, will be an IPv6 to IPv4 translator (AKA NAT64). The NAT64 as a regular NAT, needs a public IPv4 address in the "external" side. This implies that the same considerations of IPv4 public address shortage will apply to the NAT64 scenarios. So, similarly to the NAT cases described above, there are two deployment models for NAT64. Either we will have a carrier grade NAT64 deeper in the ISP network, or we can have A+P approaches in NAT64, where the NAT64 is located in the edge between the IPv6 only site and its ISP. the NAT64 in this case, would obtain a public IPv4 address and a port range. I think it is important that any A+P effort supports also the NAT64 case. I think this is important cause, if we think that the A+P approach has some advantages over the CGA approach, and we make only the CGA approach available to the users running IPv6 only networks, we are creating a disadvantage for the IPv6 adopters, which i guess is exactly what we don't want to do at this stage. I mean, f for isntance, p2p apps work with A+P type of approaches and don't work with CGN and if A+P is available only for IPv4 users and the only thing available for IPv6 users is CGN NAT64, then people would be even more reluctant to adopt IPv6. So, my point here is that we should support this scenario as well. At this point, i would like to understand whether the current proposed A+P approaches can support this scenario and if not how much work is needed to support it... if someone could comment on this it would be appreciated. I think these are the scenarios where A+P can be used, am i missing any? Regards, marcelo