From paul.mackell@tandberg.com Wed Feb 4 03:48:43 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99C3A28C0F8 for ; Wed, 4 Feb 2009 03:48:43 -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=[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 MEmIg6AMcsl3 for ; Wed, 4 Feb 2009 03:48:42 -0800 (PST) Received: from mail194.messagelabs.com (mail194.messagelabs.com [85.158.140.211]) by core3.amsl.com (Postfix) with SMTP id 657713A6944 for ; Wed, 4 Feb 2009 03:48:42 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: paul.mackell@tandberg.com X-Msg-Ref: server-13.tower-194.messagelabs.com!1233748089!16256543!3 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [62.70.2.252] Received: (qmail 4225 invoked from network); 4 Feb 2009 11:48:16 -0000 Received: from unknown (HELO OSLEXCP11.eu.tandberg.int) (62.70.2.252) by server-13.tower-194.messagelabs.com with SMTP; 4 Feb 2009 11:48:16 -0000 Received: from oslexcp2.eu.tandberg.int ([10.47.136.30]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Feb 2009 12:48:14 +0100 Received: from 10.47.5.139 ([10.47.5.139]) by oslexcp2.eu.tandberg.int ([10.47.136.30]) with Microsoft Exchange Server HTTP-DAV ; Wed, 4 Feb 2009 11:48:13 +0000 Received: from PTMackellR60 by oslexcp2.eu.tandberg.int; 04 Feb 2009 12:48:14 +0100 From: Paul Mackell To: Behave WG Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 04 Feb 2009 12:48:14 +0100 Message-Id: <1233748094.8694.37.camel@PTMackellR60.rd.tandberg.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-OriginalArrivalTime: 04 Feb 2009 11:48:14.0200 (UTC) FILETIME=[76371780:01C986BE] Subject: [BEHAVE] TURN-12 Comments (refresh) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 11:48:43 -0000 After implementing a TURN-12 client, I have the following comments regarding refreshing of allocations, permissions and channel bindings. Having to refresh an allocation, refresh a permission and refresh a channel binding makes the client implementation complex. However, I note that once a channel is bound then there is no need to refresh the permission explicitly with a CreatePermissionRequest as ChanneBindRequest also creates/refreshes a permission. The client implementation would be simpler if all these refreshes could be carried out in a single refresh message. i.e. By putting the attributes of CreatePermissionRequest and ChannelBindRequest into the Refresh method. In this way the client would only need to implement a single supervision timer. One issue I have come across is that the default permission lifetime is 300 sec (see section 8). However, a channelBinding lasts for 10 minutes (section 11). The problem is that the ChannelBindRequest also installs/refreshes a permission and a permission times out after 300 sec. So if the client creates a permission (using CreatePermissionRequest) then at a later time does a ChannelBind and refreshes the ChannelBind every 10 minutes then in actual fact, after 5 minutes the permission will timeout, whereas you would expect it to be 10 minutes. Such is the consequence of placing 2 functions (channel Bind and create permission) in one method. Making the 2 timers the same value would simplify this. Paul Mackell Senior Software Engineer Tandberg Telecom From simon.perreault@viagenie.ca Wed Feb 4 05:24:59 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEAF628C1CB for ; Wed, 4 Feb 2009 05:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, NO_RELAYS=-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 1p13GXNxtxds for ; Wed, 4 Feb 2009 05:24:59 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id F213E28C194 for ; Wed, 4 Feb 2009 05:24:58 -0800 (PST) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 6D3A329E155A; Wed, 4 Feb 2009 08:24:39 -0500 (EST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 0ED1A29E154E for ; Wed, 4 Feb 2009 08:24:39 -0500 (EST) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: behave@ietf.org Date: Wed, 4 Feb 2009 08:24:31 -0500 User-Agent: KMail/1.10.4 (Linux/2.6.27.9-159.fc10.x86_64; KDE/4.1.4; x86_64; ; ) References: <1233748094.8694.37.camel@PTMackellR60.rd.tandberg.com> In-Reply-To: <1233748094.8694.37.camel@PTMackellR60.rd.tandberg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902040824.33398.simon.perreault@viagenie.ca> Subject: Re: [BEHAVE] TURN-12 Comments (refresh) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 13:25:00 -0000 On Wednesday 04 February 2009 06:48:14 Paul Mackell wrote: > Having to refresh an allocation, refresh a permission and refresh a > channel binding makes the client implementation complex. I agree. > One issue I have come across is that the default permission lifetime is > 300 sec (see section 8). However, a channelBinding lasts for 10 minutes > (section 11). The problem is that the ChannelBindRequest also > installs/refreshes a permission and a permission times out after 300 > sec. So if the client creates a permission (using > CreatePermissionRequest) then at a later time does a ChannelBind and > refreshes the ChannelBind every 10 minutes then in actual fact, after 5 > minutes the permission will timeout, whereas you would expect it to be > 10 minutes. Such is the consequence of placing 2 functions (channel > Bind and create permission) in one method. Making the 2 timers the same > value would simplify this. I'm not sure it would make anything simpler from the point of view of the client. What you need to do now is to send a ChannelBind every 5 minutes. It will automatically refresh the permission. -- Please try Numb, a STUN/TURN server implementation. Free access at http://numb.viagenie.ca/. From dwing@cisco.com Wed Feb 4 10:11:09 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DE8828C27C for ; Wed, 4 Feb 2009 10:11: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 8mGfrMvXhg+z for ; Wed, 4 Feb 2009 10:11: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 409EC28C26B for ; Wed, 4 Feb 2009 10:11:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,380,1231113600"; d="scan'208";a="137811463" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 04 Feb 2009 18:10:48 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n14IAmcR026870; Wed, 4 Feb 2009 10:10:48 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n14IAmNG010310; Wed, 4 Feb 2009 18:10:48 GMT From: "Dan Wing" To: References: Date: Wed, 4 Feb 2009 10:10:48 -0800 Message-ID: <031201c986f3$e820d310$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 Thread-Index: Acl9gyoFqJQHahqfQE++MKFFnjVLlwJcKdtA In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1467; t=1233771049; x=1234635049; 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=20WGLC,=20draft-ietf-behave-nat-icmp-12 |Sender:=20; bh=0qBsoNg91otCxXafFc7kWYj/kS0iS/bAB5kEhBhOeqE=; b=AsZ6Vz6gfpgjFqqbPOIG24L4DUj2Dwg4xcrV/IV6ABV2EKa17G7Gc0kfOA 4D3ed4T9gwCRt8+YEcjUE6nMKFdEwbzjc+7oKh4wvj/smG9fQ0c/PEWCtCNo qyD/J3heHJeokYdVdMZw7RRHZ57EGcBdRZtKiqDMhWpWhe35Shr/4=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: behave-chairs@tools.ietf.org, draft-ietf-behave-nat-icmp@tools.ietf.org Subject: Re: [BEHAVE] WGLC, draft-ietf-behave-nat-icmp-12 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 18:11:09 -0000 A reminder: There are two days left in this re-WGLC for draft-ietf-behave-nat-icmp-12. -d > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Friday, January 23, 2009 9:51 AM > To: 'behave@ietf.org' > Cc: 'draft-ietf-behave-nat-icmp@tools.ietf.org'; > 'behave-chairs@tools.ietf.org' > Subject: WGLC, draft-ietf-behave-nat-icmp-12 > > Over a year ago we finished WGLC and forwarded > draft-ietf-behave-nat-icmp-04 to the IESG for publication. > It has now finished IESG review. During IESG review the > document underwent a lot of revisions and we would like to > make sure the BEHAVE working group is comfortable with these changes. > > The most recent version is available at: > http://tools.ietf.org/html/draft-ietf-behave-nat-icmp-12 > > Side-by-side diffs from -04 (which went through WGLC) to -12 are at: > http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/dr > aft-ietf-behave-nat-icmp-04.txt&url2=http://tools.ietf.org/id/ > draft-ietf-behave-nat-icmp-12.txt > > The IESG tracker of activity is at: > https://datatracker.ietf.org/idtracker/draft-ietf-behave-nat-icmp/ > > > We will hold this document for two weeks for further > comments, after which we will release this document to the > RFC editor. Please send comments to the BEHAVE mailing list > and also CC the authors at > draft-ietf-behave-nat-icmp@tools.ietf.org by FEBRUARY 6. > > Thanks, > -d > From philip_matthews@magma.ca Wed Feb 4 15:58:07 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DABE128C174 for ; Wed, 4 Feb 2009 15:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 oVrjVGMI+X0z for ; Wed, 4 Feb 2009 15:58:07 -0800 (PST) Received: from mail-01.primus.ca (mail3.primus.ca [216.254.141.170]) by core3.amsl.com (Postfix) with ESMTP id 09F8528C159 for ; Wed, 4 Feb 2009 15:58:06 -0800 (PST) Received: from [65.218.107.2] (helo=[172.16.1.112]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1LUrco-00076x-0U; Wed, 04 Feb 2009 18:57:46 -0500 Message-Id: <84DCEF0E-201C-4528-B4FA-5592BA09B03F@magma.ca> From: Philip Matthews To: Scott Godin In-Reply-To: <82d15bd90901141039v11c109b4scbad54d83e7d7664@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 4 Feb 2009 13:01:10 -0500 References: <82d15bd90901071801s751a6cc9m6a285e2de37cd6dd@mail.gmail.com> <82d15bd90901141039v11c109b4scbad54d83e7d7664@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - ([172.16.1.112]) [65.218.107.2] Cc: Rohan Mahy , Behave WG Subject: Re: [BEHAVE] TURN-12 Comments/Typos X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 23:58:07 -0000 Hi Scott: Here are replies to your remaining comments. - Philip On Wed, 14-Jan-09, at 13:39 , Scott Godin wrote: > A couple of additional notes: > > Section 11 - "To prevent race conditions, the client MUST wait 5 > muntes after the channel binding expires before attempting to bind the > channel number to a different transport address or the transport > address to a different channel number". I think this statement should > be expanded to explicitly say that this is within the context of an > allocation. The client should be able to re-use the transport address > in a channel binding of a new allocation, anytime after the previous > allocation that it was used in has been destroyed. Section 11 already says: Channel bindings are specific to an allocation, so that the use of a channel number or peer transport address in a channel binding in one allocation has no impact on their use in a different allocation. If an allocation expires, all its channel bindings expire with it. This is also mentioned in the Overview. One of the problems with an earlier version of the spec was that it repeated things over and over again. So I would prefer to say it only once. > > > Radical Ideal - In writing my client library, I would like to mask as > many of the lower level TURN details as possible. This means that > masking the details behind channel binding, and channel messaging vs > Data/Send Ind data sending mechanism is desirable. I don't see any > draw backs of using the channel binding mechanism over the Data/Send > Ind method, and it uses lower bandwidth, so I'm considering that my > client API will just always use this mechanism. This leads me to > think - do we really need both mechanisms? Supporting only the > Channel Binding mechanism would really simplify this draft, you would > be able to get rid of the following concepts: Create/Refresh > Permission (done explicily via Channel Binding), Data Indication > sending/handling, Send Indication sending/handling. I'm not really > understanding the value of offering both mechanisms. With previous > versions (pre-Create Permission), it made sense to support both > mechanisms in order to avoid having the queue data to send in the > client waiting for the channel bind response, but now you need to wait > for the permission to be installed before you send data, so some > queuing will be required anyway. The Data indication is needed for the situation where a server receives data from an (address,port) combination where a permission has been installed to that address, but the client has been sending to a different port. This can happen, for example, when the peer is behind a symmetric NAT. Send indications are needed when the DONT-FRAGMENT attribute is used. > > > Thanks, > Scott > From philip_matthews@magma.ca Wed Feb 4 15:58:08 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E584828C159 for ; Wed, 4 Feb 2009 15:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 qlqi1GMs5Z2B for ; Wed, 4 Feb 2009 15:58:07 -0800 (PST) Received: from mail-01.primus.ca (mail3.primus.ca [216.254.141.170]) by core3.amsl.com (Postfix) with ESMTP id A7B1228C171 for ; Wed, 4 Feb 2009 15:58:07 -0800 (PST) Received: from [65.218.107.2] (helo=[172.16.1.112]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1LUrcp-00076x-35; Wed, 04 Feb 2009 18:57:48 -0500 Message-Id: <720B57BF-7467-416D-BA1D-80B9ABE9B7CA@magma.ca> From: Philip Matthews To: Scott Godin In-Reply-To: <82d15bd90901071801s751a6cc9m6a285e2de37cd6dd@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 4 Feb 2009 17:36:26 -0500 References: <82d15bd90901071801s751a6cc9m6a285e2de37cd6dd@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - ([172.16.1.112]) [65.218.107.2] Cc: Behave WG Subject: Re: [BEHAVE] TURN-12 Comments/Typos X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 23:58:09 -0000 Hi Scott: Thanks for your comments on TURN. My apologies for being so slow to respond to your message. Unfortunately, TURN is not currently a part of my day job, and I am have been very busy with other things in the evenings. - Philip On Wed, 7-Jan-09, at 21:01 , Scott Godin wrote: > I'm in the process updating reTurn (opensource Turn server in > resiprocate project) to the latest turn-12, and have the following > comments/typos after reviewing the draft. > > 1. section 1, 4th paragraph, "When the client send...." - should be > "...sends..." Fixed. > > > 2. section 2.1, last paragraph, ".., the client may send and received > packets..." - should be "...receive..." Fixed. > > > 3. section 2.6, list "The ECN field is may be reset..." - remove "is" Fixed. > > > 4. section 5, 3rd last paragraph indicates that username, password, > realm and nonce are used to verify subsequent requests - but according > to section 4 paragraph 6 the only information authentication > information used to verify subsequent requests is the username. I > think one of these sections needs to be re-worded to avoid confusion. > Perhaps section 4 should indicate that username, realm and password > should be stored and verified across all requests for an allocation - > this will cover cases where the same username exists in two different > realms. However note that if password hash is stored instead of the > plain password, then we don't really need to store and compare realm, > since it is hashed into the password. I think both paragraphs are accurate. The username is not allowed to change, and to authenticate the request, extra authentication information is required. In fact paragraph 4 in section 4 says that all request should be authenticated and mentions the realm value. To make this clearer, I have moved paragraph 6 in section 4 to follow immediately after paragraph 4. > > > 5. section 6.2 - step 5 "... request contains a EVEN-PORT > attribute..." - should be "...contains an EVEN-PORT attribute..." Fixed. > > > 6. section 7.2 - first step indicates that "the additional username > check of section 4" should be complete. This comment needs to be > brought inline with the wording decided for comment 4. > > 7. section 9, 2nd paragraph - missing space "... inSection..." Fixed. > > > 8. section 9.2 is missing the steps/checks to process similar to > Allocate and Refresh requests - it would be good to add these for > consistency. It should also include: Long Term Cred check, existing > allocation check, and the required auth (username, etc.) checks. The text for an Allocate and Refresh request is very explicit because the processing of these requests (especially the Allocate request) is rather complex and there are some less-obvious situations that needed to be discussed. By contrast, the processing of the other requests and indications are much more straightforward. For example, the need to do the existing allocation check seems pretty obvious (not to mention that it is said explicitly in section 4). I added a sentence mentioning the authentication check. I also added a sentence saying that, if the server considers the IP addresses to be out-of-range, then it should return 400 (Bad Request). However, I don't feel like doing a rewrite of this section unless others see a need. > > > 9. section 10, 1st paragraph - "...for sending and receive data > from..." - should read "...for sending and receiving data..." Fixed. > > > 10. section 10.2 - should include a step to ensure that an allocation > exists for the 5-tuple, else message is dropped This is said explicitly in section 4. Furthermore, it would be impossible for an implementator to forget this, since the server could not check permissions or have a source address for the UDP datagram if no allocation existed. > > > 11. section 10.2, 4th paragraph, last sentence - "...the server MUST > NOT refresh the permission due to the receipt of the Send > indication..." - should be removed since Send Indication never refresh > permissions now I believe that this sentence was added at the request of Cullen, who wanted to make it very clear that Send indications did not refresh permissions. However, I agree that the MUST NOT looks a bit strange. I have reworded this sentence as follows: Note that a Send indication never causes the server to refresh the permission. > > > 12. section 10 indicates that Data attribute is mandatory in a Send > Indication - should we allow no data attribute to indicate that a 0 > length UDP packet? Note the ChannelBinding section discusses sending > a 0 length packet (section 11.6 last paragraph). Perhaps this could > also be accomplished using a Data attribute containing a data length > of 0 - but I think there should be some mention of this in section 10. I don't really see a use for it, but to be consistent with the ChannelData message, I have added a sentence to the sections describing the processing of a Send indication and a Data indication to say that zero bytes of data are allowed in a DATA attribute. Since I think this will be very uncommon, I don't feel that the optimization of omitting the DATA attribute to indicate this is needed at this time. > > > 13. section 11, paragraph 5 - "...or may choose never to bind a > channel it." - should be "...channel to it." Fixed. > > > 14. section 11.2 - check list should be numeric to be consistent with > Allocate and Refresh requests. Should also contain Long Term Cred > check, existing allocation check, and the required auth (username, > etc.) checks I have added a sentence about authenticating the packet. > > > 15. section 11.5 - I'm not sure I understand the need to pad the > ChannelData message to a multiple of four bytes. TCP implementations > are capable of reading in the exact right number of bytes from the > stream. Can this requirement be removed? It has been a long-standing property of STUN (and thus TURN) that both messages and the attributes within messages are aligned on four-byte boundaries. The requirement to pad ChannelData messages over TCP was inserted to keep this property. Do you have a technical reason why you think it is important to remove this padding? > > > 16. Is there are reason we don't just make the default permission and > channel binding lifetime the same, to facilitate use of the > ChannelBind refresh to accomplish both refreshes without worrying > about the difference? When the mechanism to age-out channels was first introduced, there was a request that the lifetime for channels be longer than that for permissions. As I recall, it was felt that there would be some race conditions introduced if the two timeout intervals were the same. Personally, I now feel that there would be no problems in making these two intervals the same and I agree with you that things would be slightly cleaner. But I am not sure it is worthwhile making the change at this late date. > > > My apologies if my questions/suggestions have already been discussed. > > Thanks, > Scott Godin > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From philip_matthews@magma.ca Wed Feb 4 16:34:28 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C85028C159 for ; Wed, 4 Feb 2009 16:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 XrYS+E5iuuBB for ; Wed, 4 Feb 2009 16:34:27 -0800 (PST) Received: from mail-01.primus.ca (mail3.primus.ca [216.254.141.170]) by core3.amsl.com (Postfix) with ESMTP id 4E3DA3A69D3 for ; Wed, 4 Feb 2009 16:34:27 -0800 (PST) Received: from [65.218.107.2] (helo=[172.16.1.112]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1LUrcp-00076x-1U; Wed, 04 Feb 2009 18:57:47 -0500 Message-Id: From: Philip Matthews To: Behave WG , Cullen Jennings , Magnus Westerlund Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 4 Feb 2009 16:15:34 -0500 X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - ([172.16.1.112]) [65.218.107.2] Cc: draft-ietf-behave-turn@tools.ietf.org Subject: [BEHAVE] TURN: Magnus's ICMP proposal X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 00:34:28 -0000 In his message to the mailing list on Jan 19, Magnus proposed to add the following to the _preferred_ fragmentation behavior: If the server goes to send a packet with the DF bit set, either because it was copied from the incoming packet (when this is possible) or because the incoming packet included the DONT-FRAGMENT attribute, and if the outgoing link's MTU will not permit the packet to be transmitted without fragmentation, then the server sends an ICMP message (Type=3, Code=4 (Fragmentation needed and DF set)) back towards the sender of the incoming packet. Note that Magnus proposes to add this only to the preferred behavior -- the alternate behavior would not include this. This preferred behavior would most likely require OS support -- I don't know of any OSes that allow applications to send ICMP messages. Here are my thoughts on this proposal: This proposes that the server generate an ICMP message when the outgoing packet is too large, but does not propose that the server relay ICMP messages. However, in order for the client to use an ICMP- based Path MTU Discovery algorithm, I think the server would have to do both. Consider a client that uses an ICMP-based Path MTU Discovery algorithm. If the client uses a server that does NOT do this proposal, then the client can only discover the MTU along the path to the server. If the client uses a server that DOES do this proposal, then the client can discover the MTU along the path to the server, plus the server's outgoing link. However, in neither case can the client discover the MTU along the rest of the path. By contrast, a client that uses a Path MTU Discovery algorithm that is based on packet loss can detect the MTU along the entire path to the peer (by using the DONT-FRAGMENT attribute). Furthermore, that algorithm will also work through NATs that filter out ICMP messages -- recall that the client is using TURN in the first place because it is behind a "nasty" NAT, and I am speculating that "nasty" NATs often don't relay ICMP message. (Cullen: Do you have any stats on the percentage of symmetric NATs that relay ICMP messages?) For these reasons, I am wondering how useful this proposal would be. Does anyone else have any comments or insights? - Philip From philip_matthews@magma.ca Wed Feb 4 19:47:02 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F44F3A6968 for ; Wed, 4 Feb 2009 19:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 mPGxXAcCadp4 for ; Wed, 4 Feb 2009 19:47:01 -0800 (PST) Received: from mail-07.primus.ca (mail3.primus.ca [216.254.141.170]) by core3.amsl.com (Postfix) with ESMTP id 6560E3A6858 for ; Wed, 4 Feb 2009 19:47:01 -0800 (PST) Received: from [65.218.107.2] (helo=[172.16.1.112]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1LUvCD-0001Dw-1C for behave@ietf.org; Wed, 04 Feb 2009 22:46:33 -0500 Message-Id: From: Philip Matthews To: Behave WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 4 Feb 2009 22:46:37 -0500 X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - ([172.16.1.112]) [65.218.107.2] Subject: [BEHAVE] TURN: IANA registry for channel numbers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 03:47:02 -0000 I have received two last call comments on TURN saying "You seem to be missing an IANA registry for channel numbers". Personally, I didn't think that an IANA registry for channel numbers was appropriate or necessary. IANA registries are usually used for codepoints, while here we are registering a range of allowed values. Channel numbers are something that get dynamically allocated within a range, and the allowed range is (in part) dictated by packet formats: specifically, the current need to distinguish ChannelData messages from STUN-formatted messages, and a possible future need to distinguish them from something else. However, given that I have now received two last-call comments on this subject, I am now re-considering my position. It might be clearer to add one, even though it seems weird. Comments? - Philip From philip_matthews@magma.ca Wed Feb 4 19:50:19 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EF383A6858 for ; Wed, 4 Feb 2009 19:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] 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 CPAkSzAQLrt9 for ; Wed, 4 Feb 2009 19:50:17 -0800 (PST) Received: from mail-06.primus.ca (mail3.primus.ca [216.254.141.170]) by core3.amsl.com (Postfix) with ESMTP id 612103A6B4C for ; Wed, 4 Feb 2009 19:50:16 -0800 (PST) Received: from [65.218.107.2] (helo=[172.16.1.112]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1LUvFU-00021b-1k; Wed, 04 Feb 2009 22:49:56 -0500 Message-Id: <895C0888-73BA-4F42-A823-588D4118D3E7@magma.ca> From: Philip Matthews To: Magnus Westerlund In-Reply-To: <497473B4.6060305@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 4 Feb 2009 22:49:52 -0500 References: <20090113155237.4C50E3A690A@core3.amsl.com> <497473B4.6060305@ericsson.com> X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - ([172.16.1.112]) [65.218.107.2] Cc: Behave WG Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-turn (Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 03:50:19 -0000 On Mon, 19-Jan-09, at 07:36 , Magnus Westerlund wrote: > Hi, > > Here is my IETF last call comments. > > 1. Section 2.6: > > " o Path MTU Discovery does not work, except in the limited way > available using the DONT-FRAGMENT attribute (see below); and" > > I think it would be more correct to say: "ICMP based Path MTU DIsovery > does not ..." I think the non-ICMP version also needs some modification. In the client-->peer direction, the client can ensure that the DF bit =20= is set for the entire path by set the DF bit on the Send indication =20 packet and including the DONT-FRAGMENT attribute. However, in the peer-->client direction, the peer can set the DF bit =20 in the UDP datagram, but there is no way for it to ask the server to =20 set the DF bit on the Data indication packet. That's why I worded the sentence the way it is. > > > 2. Section 9.1 and 9.2: > > These two sections doesn't as clearly as the other request chapters > discuss the issue of authentication of the request. I think that > CreatePermission is equally important to protect to the other =20 > management > requests. I have added the sentence: If the server is using the Long-Term Credential mechanism, the =20 message is authenticated. in section 9.2. (Note that authentication for all requests is already covered in =20 section 4, so we are just repeating ourselves here). > > > 3. Section 11.2: > > " The server MAY also impose restrictions on the range of IP =20 > addresses > and ports allowed in the XOR-PEER-ADDRESS attribute." > > How does one learn that this is happening from the response? Shouldn't > there be an error code for "Administratively Prohibited" that is > indicated to be return in this case? Good point. I previously felt that a 400 (Bad Request) response would =20= be ok, but after further reflection I decided that a different error =20 code would be better. So I have added a 403 (Forbidden) error code. > > > 4. Regarding the Fragmentation Question. > > I have raised this before and we didn't come to a conclusion. Below =20= > are > a text proposal for including the thing I think is missing in the > preferred behavior. I know this clearly requires OS level =20 > implementation > but that is why there is alternative behavior and this only =20 > specified at > should level. I do hope that we get some feedback on this proposal. I > personally think it is important to indicate how it should be properly > done, even if a number of implementation will not do it. > > My proposed text for the IPv4 Fragementation field: > > Preferred Behavior: > > When the server sends a packet to a peer in response to a Send > indication containing the DONT-FRAGMENT attribute, then set =20= > the > DF bit in the outgoing IP header to 1. In all other cases =20 > when > sending an outgoing packet containing application data (e.g., > Data indication, ChannelData message, or DONT-FRAGMENT > attribute not included in the Send indication), copy the DF =20= > bit > from the DF bit of the incoming packet that contained the > application data. > > Set the other fragmentation fields (Identification, MF, > Fragment Offset) as appropriate for a packet originating from > the server. > > For a packet that had the DF bit set on reception by the server, or =20= > was > delivered to the server with a Send Indication including a DONT-=20 > FRAGMENT > attribute and which require fragmentation when being sent from the > server should result in a ICMP message (Type=3D3, Code=3D4 = (Fragmentation > needed and DF set)) towards the sender of the packet. > > Alternate Behavior: As described in the Preferred Behavior, =20 > except > always assume the incoming DF bit is 0 and that no ICMP messages > needs to be sent. > > In both the Preferred and Alternate Behaviors, the resulting > packet may be too large for the outgoing link. If this is the > case, then the normal fragmentation rules apply [RFC1122]. See my separate e-mail on this subject. > > > NITS: > > Section 2.6: Missing space: > "still require this,TURN allows the client to request that the =20 > server" Fixed. > > > Section 5: Extra space before "." > The username, realm, and nonce > values are initially those used in the authenticated Allocate =20 > request > that creates the allocation, though the server can change the nonce > value during the lifetime of the allocation using a 438 (Stale =20 > Nonce) > reply . > Fixed. > > --=20 > > 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 > ---------------------------------------------------------------------- > > From philip_matthews@magma.ca Wed Feb 4 20:31:59 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D17B3A69B6 for ; Wed, 4 Feb 2009 20:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 NAT5lJz8Vgz5 for ; Wed, 4 Feb 2009 20:31:57 -0800 (PST) Received: from mail-06.primus.ca (mail3.primus.ca [216.254.141.170]) by core3.amsl.com (Postfix) with ESMTP id 89D403A68E1 for ; Wed, 4 Feb 2009 20:31:57 -0800 (PST) Received: from [65.218.107.2] (helo=[172.16.1.112]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1LUvtp-0006Rg-12; Wed, 04 Feb 2009 23:31:37 -0500 Message-Id: <054D61F9-3641-4FBB-B902-DBEF9CAD55D6@magma.ca> From: Philip Matthews To: Brian E Carpenter In-Reply-To: <4975116F.3050802@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 4 Feb 2009 22:31:35 -0600 References: <4975116F.3050802@gmail.com> X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - ([172.16.1.112]) [65.218.107.2] Cc: Behave WG Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-turn (Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 04:31:59 -0000 [Brian sent his comments as an attachment. I have taken the liberty to paste them into this message so they can be read without needing to open up an attachment.] Brian: Thanks for your comments. My apologies for being slow in responding. See my detailed reponses inline. - Philip On Mon, 19-Jan-09, at 18:49 , Brian E Carpenter wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer > for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-behave-turn-12.txt > Reviewer: Brian Carpenter > Review Date: 2008-01-20 > IETF LC End Date: 2009-01-27. > IESG Telechat date: (if known) > > Summary: In good shape, a few issues raised. > -------- > > Comments: > --------- > > I don't normally post my Gen-ART reviews to the main IETF list, but > will do so > in this case since there are some issues of principle mentioned below. > In general it is a well written and clear draft and I trust the WG > consensus > that the TURN protocol exchanges are technically sound. I have not > reviewed > the protocol details in sections 6 through 16. > > Major issues: > ------------- > > > 19. IAB Considerations > > > > The IAB has studied the problem of "Unilateral Self Address > Fixing", > > I don't know whether the IAB has considered this draft, but IMHO they > should probably do so. It is extremely hard** to qualify TURN as a > short-term fix for a specific problem (IAB criterion #1) or to agree > that a realistic exit strategy is: "will no longer be needed once > there > are no longer any NATs" (IAB criterion #2). I'm not saying that TURN > shouldn't be standardised - obviously, we need a solution in this > space, > and TURN is the one that has gathered consensus. But it's a bit > hypocritical > to publish it without saying honestly that its lifetime is > indefinite and > the first two IAB criteria cannot realistically be satisfied in this > case. > > ** For example, the Introduction says: > > TURN was originally invented to support multimedia sessions > signaled > > using SIP. > > ...However, care has been taken to > > make sure that TURN is suitable for other types of applications. > I agree with you that it seems very unlikely that the need for TURN will go away soon. Though ICE endeavors to find a direct path whenever this is possible, the nature of NATs means that there will be corner cases where TURN is needed for a long time. For that reason, I don't see TURN going away until NATs themselves go away. And I think that NATs will be around for a long time, especially as we are now considering using NATs as a core part of our IPv4-to-IPv6 transition story. I view this comment as being directed more towards the IAB than the authors of TURN. Or do you have specific suggestions on how the text in this section should be reworded? > > > 2.6. Other Features > ... > > Note that, because the > > server does not relay ICMP messages, the client will have to > use a > > Path MTU discovery algorithm based on the one in [RFC4821]. > > This seems like a major point, not just a note. Doesn't it impose a > rather > large and novel requirement on client implementations? Is it in fact > a hidden > normative requirement for a TURN client? Support for ICMP relaying was in a earlier version of the draft, but was removed because it was felt to be too immature and because none of the current TURN implementations were interested in supporting it. Right now, no one is really interested in this because most applications using TURN use small packets anyway, and a TURN server supporting ICMP relaying is much harder to implement. Do you have some suggested wording change? > > > 17.1.5. Impersonating a Server > ... > > This attack is prevented through the digest authentication > mechanism, > > which provides message integrity for responses in addition to > > verifying that they came from the server. > > I'm no expert, but is this subject to the sort of vulnerability > discussed in RFC4169, if an attacker has observed previous traffic > and is capable of spoofing the server's IP address? I am no expert either, but I understand that changing the nonce regularly (which TURN allows) solves this problem. > > > 18. IANA Considerations > > I'm surprised there is no registry for the channel numbers, > especially since: > > > 0x8000 through 0xFFFF: These values are reserved for future use. Channel numbers are not codepoints in the usual meaning of this word, so I didn't think one was appropriate. However, you are the second person to make this comment, so I have asked with WG for their opinion on this question. > > > Minor issues: > ------------- > > > 1. Introduction > ... > > The client does this by allocating an IP address and port on the > > server, called the relayed-transport-address. > > This reads rather strangely, as if the client was able to pick any > address and port that it likes, which is clearly impossible. (The > description in section 2.2 is fine.) > Maybe s/allocating/obtaining/ OK. I went with "obtaining". > > > 2. Overview of Operation > ... > > The client learns the server's transport > > address through some unspecified means (e.g., configuration), > > Other protocols involving relays, for example 6to4, have got into > operational > trouble in this area, especially when using anycast addresses. While > this > probably shouldn't be a topic for the base spec, I'd appreciate a > pointer > to work on this topic, or at least a warning that it conceals > serious operational > issues. (The TURN authentication and permissions mechanisms don't > address this > issue, since they apply after a client has decided which relay to > use.) Due to some recent requests by one or two WG participants, the design of the protocol has been recently tweaked so that anycast location of servers should be possible. However, no draft on how to put the pieces together into a workable anycast solution has appeared yet. > > > 2.1. Transports > > > > TURN as defined in this specification always uses UDP between the > > server and the peer. However, this specification allows the > use of > > any one of UDP, TCP, or TLS over TCP to carry the TURN messages > > Is there a reason that SCTP is not mentioned? Of course SCTP has its > own > issues with NATs, but it would be a useful clarification to say either > that it is definitely not supported or that it is left for future > work. The initial motivation for TURN was to allow a client behind non- BEHAVE-compliant NATs to communicate with a peer that is also behind a non-BEHAVE-compliant NAT. Because the NAT is non-BEHAVE-compliant, it seems highly unlikely that the NAT would support SCTP traffic. Yes, I can invent deployment scenarios where TURN is needed even with BEHAVE- compliant NATs, but this is not the current driver for this work. From brian.e.carpenter@gmail.com Wed Feb 4 20:43:09 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FAC73A6809 for ; Wed, 4 Feb 2009 20:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 rUAjYh7XZAzg for ; Wed, 4 Feb 2009 20:43:08 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id 7DD193A6359 for ; Wed, 4 Feb 2009 20:43:08 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so55303rvf.49 for ; Wed, 04 Feb 2009 20:42:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=dvo4ORFRhdrm0Svk1V3QsXVh3FVuIhb/hsjJcNYm2VY=; b=xLGpFjECDmZC2pFDNiwOdlCEJJi7RLNfSiQg0EzodaduCNKm54cgQQu5RhVzTAt1sZ GYTFnHMuHQgCuAw5Ajw1Oah79Ut+ujiWApVvS27lF38+aYGmmszxhR+fvji0VUzS8P6x kKxhRAqk5hxj4o2kdvlUb/FN2gFUv51z49pYc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=Rf3WcXcn2GTmHEF+b+tLvovOmsqTzYrFwLyJ496NgGZnOc+2woORkb2MK//xVgTSUb zBQP1VJDkjq/xwD91bh7nhzumyZVCA6PfRfMnekT3fCoW0Ow0RIFd5QLsXcGW5gwJXNB abs2P1ySJZmPcQJHEzooC98hl1zx6+lgo0cI4= Received: by 10.141.128.19 with SMTP id f19mr18623rvn.276.1233808968330; Wed, 04 Feb 2009 20:42:48 -0800 (PST) Received: from ?10.1.1.4? (118-92-192-26.dsl.dyn.ihug.co.nz [118.92.192.26]) by mx.google.com with ESMTPS id k41sm225184rvb.3.2009.02.04.20.42.46 (version=SSLv3 cipher=RC4-MD5); Wed, 04 Feb 2009 20:42:48 -0800 (PST) Message-ID: <498A6E3E.8050707@gmail.com> Date: Thu, 05 Feb 2009 17:42:38 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Matthews References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Behave WG Subject: Re: [BEHAVE] TURN: IANA registry for channel numbers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 04:43:09 -0000 On 2009-02-05 16:46, Philip Matthews wrote: > I have received two last call comments on TURN saying "You seem to be > missing an IANA registry for channel numbers". > > Personally, I didn't think that an IANA registry for channel numbers was > appropriate or necessary. IANA registries are usually used for > codepoints, while here we are registering a range of allowed values. > Channel numbers are something that get dynamically allocated within a > range, and the allowed range is (in part) dictated by packet formats: > specifically, the current need to distinguish ChannelData messages from > STUN-formatted messages, and a possible future need to distinguish them > from something else. > > However, given that I have now received two last-call comments on this > subject, I am now re-considering my position. It might be clearer to add > one, even though it seems weird. I was one of the two, wearing my Gen-ART reviewer hat, and what prompted my comment was this: > > 0x8000 through 0xFFFF: These values are reserved for future use. If there isn't an IANA registry, there's no way to find out easily if those values have been allocated subsequently. Brian From matthew@matthew.at Wed Feb 4 20:56:22 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 438603A6A7C for ; Wed, 4 Feb 2009 20:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 qcQ+HwK3B-kd for ; Wed, 4 Feb 2009 20:56:21 -0800 (PST) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by core3.amsl.com (Postfix) with ESMTP id A2D2A3A687E for ; Wed, 4 Feb 2009 20:56:21 -0800 (PST) Received: from [10.10.155.2] (unknown [10.10.155.2]) by where.matthew.at (Postfix) with ESMTP id 0B6BC14804C; Wed, 4 Feb 2009 20:56:02 -0800 (PST) Message-ID: <498A7148.2030500@matthew.at> Date: Wed, 04 Feb 2009 20:55:36 -0800 From: Matthew Kaufman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Philip Matthews References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Behave WG Subject: Re: [BEHAVE] TURN: IANA registry for channel numbers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: matthew@matthew.at List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 04:56:22 -0000 Philip Matthews wrote: > I have received two last call comments on TURN saying "You seem to be > missing an IANA registry for channel numbers". > ... > Comments? Not necessary. Rewrite it to say "the high bit must be zero". Then it is clear that 0x0000-0x7FFF can be used for whatever this draft/RFC says, and that 0x8000-0xFFFF aren't allowed by this draft/RFC. A subsequent draft/RFC can define the behavior with the high bit set. There isn't an IANA registry for TCP initial sequence numbers, even though subsequent RFCs have changed the recommendation for how they should be chosen. Matthew Kaufman From Remi.Denis-Courmont@nokia.com Thu Feb 5 00:39:51 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AD2E3A6AA8 for ; Thu, 5 Feb 2009 00:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.236 X-Spam-Level: X-Spam-Status: No, score=-6.236 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 afk00f8StPFu for ; Thu, 5 Feb 2009 00:39:50 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id A87313A6A81 for ; Thu, 5 Feb 2009 00:39:50 -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 n158TFoY029537; Thu, 5 Feb 2009 02:29:23 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Feb 2009 10:28:48 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Feb 2009 10:28:47 +0200 Received: from leon.remlab.net (esdhcp041160.research.nokia.com [172.21.41.160]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id n158Sjb2007409; Thu, 5 Feb 2009 10:28:46 +0200 From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Maemo Software - Nokia Devices R&D To: behave@ietf.org Date: Thu, 5 Feb 2009 10:29:13 +0200 User-Agent: KMail/1.10.3 (Linux/2.6.27.13; KDE/4.1.3; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200902051029.14393.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 05 Feb 2009 08:28:47.0870 (UTC) FILETIME=[C423C9E0:01C9876B] X-Nokia-AV: Clean Cc: "draft-ietf-behave-turn@tools.ietf.org" , ext Philip Matthews Subject: Re: [BEHAVE] TURN: Magnus's ICMP proposal X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 08:39:51 -0000 On Wednesday 04 February 2009 23:15:34 ext Philip Matthews, you wrote: > In his message to the mailing list on Jan 19, Magnus proposed to add > the following to the _preferred_ fragmentation behavior: > > If the server goes to send a packet with the DF bit set, either > because it was copied from the incoming packet (when this is possible) > or because the incoming packet included the DONT-FRAGMENT attribute, > and if the outgoing link's MTU will not permit the packet to be > transmitted without fragmentation, then the server sends an ICMP > message (Type=3D3, Code=3D4 (Fragmentation needed and DF set)) back > towards the sender of the incoming packet. > > Note that Magnus proposes to add this only to the preferred behavior > -- the alternate behavior would not include this. > > This preferred behavior would most likely require OS support -- I > don't know of any OSes that allow applications to send ICMP messages. As long as the source address of the outer IP header of the ICMP message=20 belongs to the TURN server... Windows can do this, or at least it did at so= me=20 point. Virtually all BSD/POSIX-based system can; this requires "root", but = no=20 kernel changes. This will be a problem for some consumer embedded operating systems. But I= =20 think these would only have TURN clients, rather than TURN servers anyway. =2D-=20 R=E9mi Denis-Courmont Maemo Software, Nokia Devices R&D From paul.mackell@tandberg.com Thu Feb 5 00:42:20 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 835443A69E0 for ; Thu, 5 Feb 2009 00:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_55=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 rh+Hsg9QkLUo for ; Thu, 5 Feb 2009 00:42:19 -0800 (PST) Received: from mail189.messagelabs.com (mail189.messagelabs.com [85.158.139.179]) by core3.amsl.com (Postfix) with SMTP id 30FF53A69D4 for ; Thu, 5 Feb 2009 00:42:19 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: paul.mackell@tandberg.com X-Msg-Ref: server-15.tower-189.messagelabs.com!1233823318!19156197!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [62.70.2.252] Received: (qmail 30954 invoked from network); 5 Feb 2009 08:41:58 -0000 Received: from unknown (HELO OSLEXCP11.eu.tandberg.int) (62.70.2.252) by server-15.tower-189.messagelabs.com with SMTP; 5 Feb 2009 08:41:58 -0000 Received: from oslexcp2.eu.tandberg.int ([10.47.136.30]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Feb 2009 09:41:58 +0100 Received: from 10.47.5.139 ([10.47.5.139]) by oslexcp2.eu.tandberg.int ([10.47.136.30]) with Microsoft Exchange Server HTTP-DAV ; Thu, 5 Feb 2009 08:41:57 +0000 Received: from PTMackellR60 by oslexcp2.eu.tandberg.int; 05 Feb 2009 09:42:01 +0100 From: Paul Mackell To: Simon Perreault In-Reply-To: <200902040824.33398.simon.perreault@viagenie.ca> References: <1233748094.8694.37.camel@PTMackellR60.rd.tandberg.com> <200902040824.33398.simon.perreault@viagenie.ca> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 05 Feb 2009 09:42:01 +0100 Message-Id: <1233823321.8694.64.camel@PTMackellR60.rd.tandberg.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-OriginalArrivalTime: 05 Feb 2009 08:41:58.0194 (UTC) FILETIME=[9B35A920:01C9876D] Cc: behave@ietf.org Subject: Re: [BEHAVE] TURN-12 Comments (refresh) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 08:42:20 -0000 On Wed, 2009-02-04 at 08:24 -0500, Simon Perreault wrote: > On Wednesday 04 February 2009 06:48:14 Paul Mackell wrote: > > Having to refresh an allocation, refresh a permission and refresh a > > channel binding makes the client implementation complex. > > I agree. > > > One issue I have come across is that the default permission lifetime is > > 300 sec (see section 8). However, a channelBinding lasts for 10 minutes > > (section 11). The problem is that the ChannelBindRequest also > > installs/refreshes a permission and a permission times out after 300 > > sec. So if the client creates a permission (using > > CreatePermissionRequest) then at a later time does a ChannelBind and > > refreshes the ChannelBind every 10 minutes then in actual fact, after 5 > > minutes the permission will timeout, whereas you would expect it to be > > 10 minutes. Such is the consequence of placing 2 functions (channel > > Bind and create permission) in one method. Making the 2 timers the same > > value would simplify this. > > I'm not sure it would make anything simpler from the point of view of the > client. What you need to do now is to send a ChannelBind every 5 minutes. It > will automatically refresh the permission. > It would be simpler (to implement and test) in that only one supervision timer (and wait state) would be required to refresh both the allocation, the channel binding and the permission. With the current draft, at worst case 1-3 supervision timers are required and there is the issue of timers going off "simultaneously". It would be simple to combine refresh of the allocation and the channel binding by (optionally) adding the XOR_PEER_ADDRESS and CHANNEL_NUMBER to the refresh method. We could code the XOR_PEER_ADDRESS/CHANNEL_NUMBER combination as a new attribute in order to differentiate between a channel bind refresh and a Permission refresh (the later consisting of XOR_PEER_ADDRESS only) in the refresh message. Some client implementations have many simultaneous media streams e.g. audio,Video,duo-video,BFC etc... and each of these have both RTP and RTCP streams resulting in a multitude of TURN allocations, all of which having their own independent supervision timers, and this is a pain to debug. Reducing the complexity of the supervision would simplify things. From teemu.savolainen@nokia.com Thu Feb 5 01:06:00 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@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: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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 simon.perreault@viagenie.ca Thu Feb 5 05:29:43 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 299B33A6AF2 for ; Thu, 5 Feb 2009 05:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, NO_RELAYS=-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 G0EphfPmXqsi for ; Thu, 5 Feb 2009 05:29:42 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 1811B3A6909 for ; Thu, 5 Feb 2009 05:29:42 -0800 (PST) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 4F26629E1562; Thu, 5 Feb 2009 08:29:22 -0500 (EST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 4478029E1551; Thu, 5 Feb 2009 08:29:22 -0500 (EST) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: behave@ietf.org, matthew@matthew.at Date: Thu, 5 Feb 2009 08:29:21 -0500 User-Agent: KMail/1.10.4 (Linux/2.6.27.12-170.2.5.fc10.x86_64; KDE/4.1.4; x86_64; ; ) References: <498A7148.2030500@matthew.at> In-Reply-To: <498A7148.2030500@matthew.at> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902050829.22059.simon.perreault@viagenie.ca> Cc: Philip Matthews Subject: Re: [BEHAVE] TURN: IANA registry for channel numbers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 13:29:43 -0000 On Wednesday 04 February 2009 23:55:36 Matthew Kaufman wrote: > Rewrite it to say "the high bit must be zero". Then it is > clear that 0x0000-0x7FFF can be used for whatever this draft/RFC says, > and that 0x8000-0xFFFF aren't allowed by this draft/RFC. A subsequent > draft/RFC can define the behavior with the high bit set. This is just playing with words, it doesn't change anything. I also strongly support creating an IANA registry. -- Please try Numb, a STUN/TURN server implementation. Free access at http://numb.viagenie.ca/. From mohamed.boucadair@orange-ftgroup.com Thu Feb 5 06:09:26 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@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: [BEHAVE] TR: I-D Action:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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 slgodin@gmail.com Thu Feb 5 06:36:52 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA26428C197 for ; Thu, 5 Feb 2009 06:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 HUhLjEjvkqSD for ; Thu, 5 Feb 2009 06:36:52 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id 0B74028C182 for ; Thu, 5 Feb 2009 06:36:52 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so276139rvf.49 for ; Thu, 05 Feb 2009 06:36:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=5p9QRhCG66pZd4bqWTDd4XnRDa0ng+BFLnUa0q1MDUk=; b=i2vYBg3dpWVTljq9xjGZz89s9kmVFeVwFLkinddzxWd/xsTmII8fgMWrQpwJu75RfW VcTP0OlB78TmMlFbyQ7r03IPFzyhxyCP+jyWQ/S29EOa05Igtf7U8qa7VTm855GHJoKC lbiFbb352iD4zy8QkMwTxtkdiqi926JETopEs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=r+8TS328jcOYbyuBsxMGDUK7MxecGT1WKCz1bNAjwKOnlwihH7StGAHfDSHqDKBUOF dIyQofGRfbSv9zZZl8uukmEOcuhmN5GnOREtXZdgvzpu1RwNXxxep+uG01WEQsC0hKLy KMu0TBswbkQRFsG7gY4QtF1Hv60JCjnR5I3ss= MIME-Version: 1.0 Sender: slgodin@gmail.com Received: by 10.140.136.5 with SMTP id j5mr387621rvd.167.1233844591959; Thu, 05 Feb 2009 06:36:31 -0800 (PST) In-Reply-To: <720B57BF-7467-416D-BA1D-80B9ABE9B7CA@magma.ca> References: <82d15bd90901071801s751a6cc9m6a285e2de37cd6dd@mail.gmail.com> <720B57BF-7467-416D-BA1D-80B9ABE9B7CA@magma.ca> Date: Thu, 5 Feb 2009 09:36:31 -0500 X-Google-Sender-Auth: eb963546e83d60d6 Message-ID: <82d15bd90902050636i14e016e7ra0a2bb9001fe7238@mail.gmail.com> From: Scott Godin To: Philip Matthews , jdrosen@cisco.com, Rohan Mahy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Behave WG Subject: Re: [BEHAVE] TURN-12 Comments/Typos X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 14:36:52 -0000 Hi Philip, A few responses.... >> 10. section 10.2 - should include a step to ensure that an allocation >> exists for the 5-tuple, else message is dropped > > This is said explicitly in section 4. Furthermore, it would be impossible > for an implementator to forget this, since the server could not check > permissions or have a source address for the UDP datagram if no allocation > existed. This step is mentioned in the processing of other methods. Many of my suggestions are to improve the overall consistency in the document when describing the processing required for various methods. >> 15. section 11.5 - I'm not sure I understand the need to pad the >> ChannelData message to a multiple of four bytes. TCP implementations >> are capable of reading in the exact right number of bytes from the >> stream. Can this requirement be removed? > > It has been a long-standing property of STUN (and thus TURN) that both > messages and the attributes within messages are aligned on four-byte > boundaries. The requirement to pad ChannelData messages over TCP was > inserted to keep this property. > > Do you have a technical reason why you think it is important to remove this > padding? My only reason was that it adds unnecessary complexity for implementors. However, I can buy your argument that you would like to keep ChannelData messages somewhat consistent with StunMessage packing. >> 16. Is there are reason we don't just make the default permission and >> channel binding lifetime the same, to facilitate use of the >> ChannelBind refresh to accomplish both refreshes without worrying >> about the difference? > > When the mechanism to age-out channels was first introduced, there was a > request that the lifetime for channels be longer than that for permissions. > As I recall, it was felt that there would be some race conditions introduced > if the two timeout intervals were the same. > > Personally, I now feel that there would be no problems in making these two > intervals the same and I agree with you that things would be slightly > cleaner. But I am not sure it is worthwhile making the change at this late > date. I would definitely support pushing this change through, given that a good counter argument is not presented. Reading some other postings on the list, it seems others feel the same way. Thanks, Scott From slgodin@gmail.com Thu Feb 5 06:40:33 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AEDC28C1E1 for ; Thu, 5 Feb 2009 06:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 QJWFYo+Ipaez for ; Thu, 5 Feb 2009 06:40:32 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id 52C7428C1DC for ; Thu, 5 Feb 2009 06:40:32 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id g9so2492089rvb.5 for ; Thu, 05 Feb 2009 06:40:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=eI6AlgbRYsyXo/NSuwqaPDljD/A8X7by4sEN995rWcw=; b=l62WnVAaBVcs3UJbmBYEHEhvUSEKvYyyyZxdJnSq3QhmguxeJR8Xv2r0iF8tvf73Ap NNnglRi1h8xcFNCeE1pyon5UMm1rsaUU6pC6PX2bJi1MOoAwvwwrlksCQEW0+eVE8sZm irRykMopSLw49el58LKasWW6wYBLxkB6iVpjc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=pbS+XY8MpFRuqs6WYrPEOOEmyUmcwP1/JAoqEGZi3g9Uf6SGxfsWPw4fmO7f8B78Dt dT0g8YBd+miwZMnpEsxKAg85f8AN13eQbC4IhqeKsSg7ovLUFpxKmioJsVZXuaNcyDEf PGVZjk1g3MS0rpjqWYPwepGME5D5LyqXaJxXw= MIME-Version: 1.0 Sender: slgodin@gmail.com Received: by 10.140.134.15 with SMTP id h15mr386464rvd.190.1233844812186; Thu, 05 Feb 2009 06:40:12 -0800 (PST) In-Reply-To: <84DCEF0E-201C-4528-B4FA-5592BA09B03F@magma.ca> References: <82d15bd90901071801s751a6cc9m6a285e2de37cd6dd@mail.gmail.com> <82d15bd90901141039v11c109b4scbad54d83e7d7664@mail.gmail.com> <84DCEF0E-201C-4528-B4FA-5592BA09B03F@magma.ca> Date: Thu, 5 Feb 2009 09:40:12 -0500 X-Google-Sender-Auth: eea91ee1f5d69158 Message-ID: <82d15bd90902050640j356fce3cy4e023495dfbd3c7b@mail.gmail.com> From: Scott Godin To: Philip Matthews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Behave WG Subject: Re: [BEHAVE] TURN-12 Comments/Typos X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 14:40:33 -0000 Hi Philip, >> Radical Idea - In writing my client library, I would like to mask as >> many of the lower level TURN details as possible. This means that >> masking the details behind channel binding, and channel messaging vs >> Data/Send Ind data sending mechanism is desirable. I don't see any >> draw backs of using the channel binding mechanism over the Data/Send >> Ind method, and it uses lower bandwidth, so I'm considering that my >> client API will just always use this mechanism. This leads me to >> think - do we really need both mechanisms? Supporting only the >> Channel Binding mechanism would really simplify this draft, you would >> be able to get rid of the following concepts: Create/Refresh >> Permission (done explicily via Channel Binding), Data Indication >> sending/handling, Send Indication sending/handling. I'm not really >> understanding the value of offering both mechanisms. With previous >> versions (pre-Create Permission), it made sense to support both >> mechanisms in order to avoid having the queue data to send in the >> client waiting for the channel bind response, but now you need to wait >> for the permission to be installed before you send data, so some >> queuing will be required anyway. > > The Data indication is needed for the situation where a server receives data > from an (address,port) combination where a permission has been installed to > that address, but the client has been sending to a different port. This can > happen, for example, when the peer is behind a symmetric NAT. > > Send indications are needed when the DONT-FRAGMENT attribute is used. Good points - thanks. Scott From brian.e.carpenter@gmail.com Thu Feb 5 13:30:04 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8AEA3A6ACC for ; Thu, 5 Feb 2009 13:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scJ6u3GYjy+O for ; Thu, 5 Feb 2009 13:30:03 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by core3.amsl.com (Postfix) with ESMTP id BCCBB3A67F6 for ; Thu, 5 Feb 2009 13:30:02 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id 11so524587tim.25 for ; Thu, 05 Feb 2009 13:30:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ybBG6FviB0qBouUi5tZpDNJx05ezkFLudO/tr2XA9oc=; b=hnxN05CQMvf3ksk0c1rsbE14OyuKijfCd6jSEFGRD/EfPA17bBNFUm/lDQekkZeHdH ZmbzE01kv4u53dDELooUFTQDv94MtdkTMOOKXdIvK0TP8+zu2A0jbN1MAxwReX+p9nPj +hgSCzYWRq68kL79IUiS0zOJnHvP/MxpHhoY4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=TwMPCUB9bUyuFIK4f5hT1W6KGsjOnSTmMrQZ8cPyBWZ7OvbGCcBgxQYSWakWh02MEP VW2uGgKeQBeb7dLtnw3z6ms4ix0+hpSbGFNeem/L2U4p4XTx+stc1g0gnsnp5bt2R5X8 eSafvLtLnQs2xxxXz66T0r+0tcn30zG3cAwoo= Received: by 10.110.86.3 with SMTP id j3mr294544tib.51.1233869403066; Thu, 05 Feb 2009 13:30:03 -0800 (PST) Received: from ?10.1.1.4? (118-92-131-113.dsl.dyn.ihug.co.nz [118.92.131.113]) by mx.google.com with ESMTPS id i9sm2582193tid.13.2009.02.05.13.29.59 (version=SSLv3 cipher=RC4-MD5); Thu, 05 Feb 2009 13:30:01 -0800 (PST) Message-ID: <498B5A52.6060404@gmail.com> Date: Fri, 06 Feb 2009 10:29:54 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Matthews References: <4975116F.3050802@gmail.com> <054D61F9-3641-4FBB-B902-DBEF9CAD55D6@magma.ca> In-Reply-To: <054D61F9-3641-4FBB-B902-DBEF9CAD55D6@magma.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Behave WG Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-turn (Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 21:30:04 -0000 On 2009-02-05 17:31, Philip Matthews wrote: > [Brian sent his comments as an attachment. I have taken the liberty to > paste them into this message so they can be read without needing to open > up an attachment.] [I do that with Gen-ART reviews, since they are detached and added to the Gen-ART archive of reviews.] > > Brian: > > Thanks for your comments. My apologies for being slow in responding. > > See my detailed reponses inline. > > - Philip > > > On Mon, 19-Jan-09, at 18:49 , Brian E Carpenter wrote: >> I have been selected as the General Area Review Team (Gen-ART) reviewer >> for this draft (for background on Gen-ART, please see >> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >> Please resolve these comments along with any other Last Call comments >> you may receive. >> >> Document: draft-ietf-behave-turn-12.txt >> Reviewer: Brian Carpenter >> Review Date: 2008-01-20 >> IETF LC End Date: 2009-01-27. >> IESG Telechat date: (if known) >> >> Summary: In good shape, a few issues raised. >> -------- >> >> Comments: >> --------- >> >> I don't normally post my Gen-ART reviews to the main IETF list, but >> will do so >> in this case since there are some issues of principle mentioned below. >> In general it is a well written and clear draft and I trust the WG >> consensus >> that the TURN protocol exchanges are technically sound. I have not >> reviewed >> the protocol details in sections 6 through 16. >> >> Major issues: >> ------------- >> >> > 19. IAB Considerations >> > >> > The IAB has studied the problem of "Unilateral Self Address Fixing", >> >> I don't know whether the IAB has considered this draft, but IMHO they >> should probably do so. It is extremely hard** to qualify TURN as a >> short-term fix for a specific problem (IAB criterion #1) or to agree >> that a realistic exit strategy is: "will no longer be needed once there >> are no longer any NATs" (IAB criterion #2). I'm not saying that TURN >> shouldn't be standardised - obviously, we need a solution in this space, >> and TURN is the one that has gathered consensus. But it's a bit >> hypocritical >> to publish it without saying honestly that its lifetime is indefinite and >> the first two IAB criteria cannot realistically be satisfied in this >> case. >> >> ** For example, the Introduction says: >> > TURN was originally invented to support multimedia sessions signaled >> > using SIP. >> > ...However, care has been taken to >> > make sure that TURN is suitable for other types of applications. >> > > > I agree with you that it seems very unlikely that the need for TURN will > go away soon. Though ICE endeavors to find a direct path whenever this > is possible, the nature of NATs means that there will be corner cases > where TURN is needed for a long time. For that reason, I don't see TURN > going away until NATs themselves go away. And I think that NATs will be > around for a long time, especially as we are now considering using NATs > as a core part of our IPv4-to-IPv6 transition story. > > I view this comment as being directed more towards the IAB than the > authors of TURN. Or do you have specific suggestions on how the text in > this section should be reworded? No, I really wanted to avoid the IAB saying later that they weren't happy with this document. Having made my point on the IETF list, I'm done. > > > >> >> > 2.6. Other Features >> ... >> > Note that, because the >> > server does not relay ICMP messages, the client will have to use a >> > Path MTU discovery algorithm based on the one in [RFC4821]. >> >> This seems like a major point, not just a note. Doesn't it impose a >> rather >> large and novel requirement on client implementations? Is it in fact a >> hidden >> normative requirement for a TURN client? > > > Support for ICMP relaying was in a earlier version of the draft, but was > removed because it was felt to be too immature and because none of the > current TURN implementations were interested in supporting it. Right > now, no one is really interested in this because most applications using > TURN use small packets anyway, and a TURN server supporting ICMP > relaying is much harder to implement. > > Do you have some suggested wording change? Well, 'will have to' sounds very close to 'MUST' to me. I would suggest either making it a MUST or toning it down to 'may need to'; otherwise it's ambiguous whether it's normative or not. > > > >> >> > 17.1.5. Impersonating a Server >> ... >> > This attack is prevented through the digest authentication >> mechanism, >> > which provides message integrity for responses in addition to >> > verifying that they came from the server. >> >> I'm no expert, but is this subject to the sort of vulnerability >> discussed in RFC4169, if an attacker has observed previous traffic >> and is capable of spoofing the server's IP address? > > I am no expert either, but I understand that changing the nonce > regularly (which TURN allows) solves this problem. OK, maybe add a sentence saying that? > > >> >> > 18. IANA Considerations >> >> I'm surprised there is no registry for the channel numbers, especially >> since: >> >> > 0x8000 through 0xFFFF: These values are reserved for future use. > > Channel numbers are not codepoints in the usual meaning of this word, so > I didn't think one was appropriate. However, you are the second person > to make this comment, so I have asked with WG for their opinion on this > question. Sure, whatever the consensus is. > > >> >> >> Minor issues: >> ------------- I leave these up to you; none of them were intended as blocking comments. Thanks Brian >> >> > 1. Introduction >> ... >> > The client does this by allocating an IP address and port on the >> > server, called the relayed-transport-address. >> >> This reads rather strangely, as if the client was able to pick any >> address and port that it likes, which is clearly impossible. (The >> description in section 2.2 is fine.) >> Maybe s/allocating/obtaining/ > > OK. I went with "obtaining". > >> >> > 2. Overview of Operation >> ... >> > The client learns the server's transport >> > address through some unspecified means (e.g., configuration), >> >> Other protocols involving relays, for example 6to4, have got into >> operational >> trouble in this area, especially when using anycast addresses. While this >> probably shouldn't be a topic for the base spec, I'd appreciate a pointer >> to work on this topic, or at least a warning that it conceals serious >> operational >> issues. (The TURN authentication and permissions mechanisms don't >> address this >> issue, since they apply after a client has decided which relay to use.) > > Due to some recent requests by one or two WG participants, the design of > the protocol has been recently tweaked so that anycast location of > servers should be possible. However, no draft on how to put the pieces > together into a workable anycast solution has appeared yet. > > >> >> > 2.1. Transports >> > >> > TURN as defined in this specification always uses UDP between the >> > server and the peer. However, this specification allows the use of >> > any one of UDP, TCP, or TLS over TCP to carry the TURN messages >> >> Is there a reason that SCTP is not mentioned? Of course SCTP has its own >> issues with NATs, but it would be a useful clarification to say either >> that it is definitely not supported or that it is left for future work. > > > The initial motivation for TURN was to allow a client behind > non-BEHAVE-compliant NATs to communicate with a peer that is also behind > a non-BEHAVE-compliant NAT. Because the NAT is non-BEHAVE-compliant, it > seems highly unlikely that the NAT would support SCTP traffic. Yes, I > can invent deployment scenarios where TURN is needed even with > BEHAVE-compliant NATs, but this is not the current driver for this work. > > > > > > > From dwing@cisco.com Thu Feb 5 15:29:09 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@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: [BEHAVE] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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 dthaler@windows.microsoft.com Thu Feb 5 17:09:40 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@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: [BEHAVE] [shara] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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 philip_matthews@magma.ca Thu Feb 5 21:11:58 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BD7F3A6901 for ; Thu, 5 Feb 2009 21:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, J_CHICKENPOX_55=0.6] 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 gq9p4-kY0S2N for ; Thu, 5 Feb 2009 21:11:57 -0800 (PST) Received: from mail-09.primus.ca (mail4.primus.ca [216.254.141.171]) by core3.amsl.com (Postfix) with ESMTP id 794923A68BA for ; Thu, 5 Feb 2009 21:11:57 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1LVJ0D-0001cz-2S; Fri, 06 Feb 2009 00:11:46 -0500 Message-Id: From: Philip Matthews To: Paul Mackell In-Reply-To: <1233823321.8694.64.camel@PTMackellR60.rd.tandberg.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 5 Feb 2009 18:12:07 -0600 References: <1233748094.8694.37.camel@PTMackellR60.rd.tandberg.com> <200902040824.33398.simon.perreault@viagenie.ca> <1233823321.8694.64.camel@PTMackellR60.rd.tandberg.com> X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] Cc: behave@ietf.org Subject: Re: [BEHAVE] TURN-12 Comments (refresh) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 05:11:58 -0000 Let me point out that, in practice, the client needs to send some sort of packet to the TURN server a lot more frequently than once every 10 minutes (channel binding lifetime) or even once every 5 minutes (permission lifetime). Typical NAT binding lifetimes are two minutes or less, with some as low as 30 seconds. ICE recommends keep-alives be sent every 15 seconds. Having said that, I have no problem with changing the channel binding lifetime from 10 minutes to 5 minutes if this is what the WG wants. (This is, of course, a non-backwards-compatible change, so implementors who care should speak up) - Philip On Thu, 5-Feb-09, at 02:42 , Paul Mackell wrote: > On Wed, 2009-02-04 at 08:24 -0500, Simon Perreault wrote: >> On Wednesday 04 February 2009 06:48:14 Paul Mackell wrote: >>> Having to refresh an allocation, refresh a permission and refresh a >>> channel binding makes the client implementation complex. >> >> I agree. >> >>> One issue I have come across is that the default permission >>> lifetime is >>> 300 sec (see section 8). However, a channelBinding lasts for 10 >>> minutes >>> (section 11). The problem is that the ChannelBindRequest also >>> installs/refreshes a permission and a permission times out after 300 >>> sec. So if the client creates a permission (using >>> CreatePermissionRequest) then at a later time does a ChannelBind and >>> refreshes the ChannelBind every 10 minutes then in actual fact, >>> after 5 >>> minutes the permission will timeout, whereas you would expect it >>> to be >>> 10 minutes. Such is the consequence of placing 2 functions (channel >>> Bind and create permission) in one method. Making the 2 timers >>> the same >>> value would simplify this. >> >> I'm not sure it would make anything simpler from the point of view >> of the >> client. What you need to do now is to send a ChannelBind every 5 >> minutes. It >> will automatically refresh the permission. >> > It would be simpler (to implement and test) in that only one > supervision > timer (and wait state) would be required to refresh both the > allocation, > the channel binding and the permission. > > With the current draft, at worst case 1-3 supervision timers are > required and there is the issue of timers going off "simultaneously". > It would be simple to combine refresh of the allocation and the > channel > binding by (optionally) adding the XOR_PEER_ADDRESS and CHANNEL_NUMBER > to the refresh method. We could code the XOR_PEER_ADDRESS/ > CHANNEL_NUMBER > combination as a new attribute in order to differentiate between a > channel bind refresh and a Permission refresh (the later consisting of > XOR_PEER_ADDRESS only) in the refresh message. > > Some client implementations have many simultaneous media streams e.g. > audio,Video,duo-video,BFC etc... and each of these have both RTP and > RTCP streams resulting in a multitude of TURN allocations, all of > which > having their own independent supervision timers, and this is a pain to > debug. Reducing the complexity of the supervision would simplify > things. > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From philip_matthews@magma.ca Thu Feb 5 21:12:06 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E5F53A6A35 for ; Thu, 5 Feb 2009 21:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 cH1wXBQ2ZkcA for ; Thu, 5 Feb 2009 21:12:05 -0800 (PST) Received: from mail-09.primus.ca (mail4.primus.ca [216.254.141.171]) by core3.amsl.com (Postfix) with ESMTP id 9B4F03A6A03 for ; Thu, 5 Feb 2009 21:12:05 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1LVJ0P-0001cz-0Y; Fri, 06 Feb 2009 00:11:57 -0500 Message-Id: From: Philip Matthews To: OKUMURA Shinji In-Reply-To: <12C97ACF0547E8shin@softfront.co.jp> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 5 Feb 2009 18:16:34 -0600 References: <20090113155237.4C50E3A690A@core3.amsl.com> <12C97ACF0547E8shin@softfront.co.jp> X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] Cc: Behave WG Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-turn (Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 05:12:06 -0000 Sinji: Thanks for your comment. This is now fixed. - Philip On Tue, 20-Jan-09, at 01:16 , OKUMURA Shinji wrote: > Hi. > > I have one comment. > > Page 51 > "alerted or forged", it would be "altered or forged". > > Regards, > Shinji > From philip_matthews@magma.ca Thu Feb 5 21:12:20 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFA7B3A6B25 for ; Thu, 5 Feb 2009 21:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 TjZGxo8AEsam for ; Thu, 5 Feb 2009 21:12:19 -0800 (PST) Received: from mail-09.primus.ca (mail4.primus.ca [216.254.141.171]) by core3.amsl.com (Postfix) with ESMTP id 8439D3A6ADF for ; Thu, 5 Feb 2009 21:12:19 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1LVJ0a-0001cz-0R; Fri, 06 Feb 2009 00:12:08 -0500 Message-Id: <352D9B02-5958-4BE2-B87D-3D58C20F27BB@magma.ca> From: Philip Matthews To: Brian E Carpenter In-Reply-To: <498B5A52.6060404@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 5 Feb 2009 18:29:06 -0600 References: <4975116F.3050802@gmail.com> <054D61F9-3641-4FBB-B902-DBEF9CAD55D6@magma.ca> <498B5A52.6060404@gmail.com> X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] Cc: Behave WG Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-turn (Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 05:12:20 -0000 On Thu, 5-Feb-09, at 15:29 , Brian E Carpenter wrote: > On 2009-02-05 17:31, Philip Matthews wrote: >> [Brian sent his comments as an attachment. I have taken the liberty >> to >> paste them into this message so they can be read without needing to >> open >> up an attachment.] > > [I do that with Gen-ART reviews, since they are detached and added to > the Gen-ART archive of reviews.] > >> >> Brian: >> >> Thanks for your comments. My apologies for being slow in responding. >> >> See my detailed reponses inline. >> >> - Philip >> >> >> On Mon, 19-Jan-09, at 18:49 , Brian E Carpenter wrote: >>> I have been selected as the General Area Review Team (Gen-ART) >>> reviewer >>> for this draft (for background on Gen-ART, please see >>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>> Please resolve these comments along with any other Last Call >>> comments >>> you may receive. >>> >>> Document: draft-ietf-behave-turn-12.txt >>> Reviewer: Brian Carpenter >>> Review Date: 2008-01-20 >>> IETF LC End Date: 2009-01-27. >>> IESG Telechat date: (if known) >>> >>> Summary: In good shape, a few issues raised. >>> -------- >>> >>> Comments: >>> --------- >>> >>> I don't normally post my Gen-ART reviews to the main IETF list, but >>> will do so >>> in this case since there are some issues of principle mentioned >>> below. >>> In general it is a well written and clear draft and I trust the WG >>> consensus >>> that the TURN protocol exchanges are technically sound. I have not >>> reviewed >>> the protocol details in sections 6 through 16. >>> >>> Major issues: >>> ------------- >>> >>>> 19. IAB Considerations >>>> >>>> The IAB has studied the problem of "Unilateral Self Address >>>> Fixing", >>> >>> I don't know whether the IAB has considered this draft, but IMHO >>> they >>> should probably do so. It is extremely hard** to qualify TURN as a >>> short-term fix for a specific problem (IAB criterion #1) or to agree >>> that a realistic exit strategy is: "will no longer be needed once >>> there >>> are no longer any NATs" (IAB criterion #2). I'm not saying that TURN >>> shouldn't be standardised - obviously, we need a solution in this >>> space, >>> and TURN is the one that has gathered consensus. But it's a bit >>> hypocritical >>> to publish it without saying honestly that its lifetime is >>> indefinite and >>> the first two IAB criteria cannot realistically be satisfied in this >>> case. >>> >>> ** For example, the Introduction says: >>>> TURN was originally invented to support multimedia sessions >>>> signaled >>>> using SIP. >>>> ...However, care has been taken to >>>> make sure that TURN is suitable for other types of applications. >>> >> >> >> I agree with you that it seems very unlikely that the need for TURN >> will >> go away soon. Though ICE endeavors to find a direct path whenever >> this >> is possible, the nature of NATs means that there will be corner cases >> where TURN is needed for a long time. For that reason, I don't see >> TURN >> going away until NATs themselves go away. And I think that NATs >> will be >> around for a long time, especially as we are now considering using >> NATs >> as a core part of our IPv4-to-IPv6 transition story. >> >> I view this comment as being directed more towards the IAB than the >> authors of TURN. Or do you have specific suggestions on how the >> text in >> this section should be reworded? > > No, I really wanted to avoid the IAB saying later that they > weren't happy with this document. Having made my point on the IETF > list, I'm done. OK. > > >> >> >> >>> >>>> 2.6. Other Features >>> ... >>>> Note that, because the >>>> server does not relay ICMP messages, the client will have to >>>> use a >>>> Path MTU discovery algorithm based on the one in [RFC4821]. >>> >>> This seems like a major point, not just a note. Doesn't it impose a >>> rather >>> large and novel requirement on client implementations? Is it in >>> fact a >>> hidden >>> normative requirement for a TURN client? >> >> >> Support for ICMP relaying was in a earlier version of the draft, >> but was >> removed because it was felt to be too immature and because none of >> the >> current TURN implementations were interested in supporting it. Right >> now, no one is really interested in this because most applications >> using >> TURN use small packets anyway, and a TURN server supporting ICMP >> relaying is much harder to implement. >> >> Do you have some suggested wording change? > > Well, 'will have to' sounds very close to 'MUST' to me. I would > suggest either making it a MUST or toning it down to > 'may need to'; otherwise it's ambiguous whether it's normative > or not. It is not a normative requirement, so I changed it to "may need to". > > >> >> >> >>> >>>> 17.1.5. Impersonating a Server >>> ... >>>> This attack is prevented through the digest authentication >>> mechanism, >>>> which provides message integrity for responses in addition to >>>> verifying that they came from the server. >>> >>> I'm no expert, but is this subject to the sort of vulnerability >>> discussed in RFC4169, if an attacker has observed previous traffic >>> and is capable of spoofing the server's IP address? >> >> I am no expert either, but I understand that changing the nonce >> regularly (which TURN allows) solves this problem. > > OK, maybe add a sentence saying that? Since I am not at all an expert on security, I have e-mailed Jonathan (who wrote the security section) to see if he can comment. Any other security experts are welcome to comment as well ... > From philip_matthews@magma.ca Thu Feb 5 21:12:31 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A00B3A6901 for ; Thu, 5 Feb 2009 21:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 Xq55rNhTS8ld for ; Thu, 5 Feb 2009 21:12:30 -0800 (PST) Received: from mail-09.primus.ca (mail4.primus.ca [216.254.141.171]) by core3.amsl.com (Postfix) with ESMTP id D11EF3A68BA for ; Thu, 5 Feb 2009 21:12:29 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1LVJ0n-0001cz-29; Fri, 06 Feb 2009 00:12:21 -0500 Message-Id: <5406CD72-7525-4C14-B943-41D4051E39A0@magma.ca> From: Philip Matthews To: Scott Godin In-Reply-To: <82d15bd90902050636i14e016e7ra0a2bb9001fe7238@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 5 Feb 2009 18:49:00 -0600 References: <82d15bd90901071801s751a6cc9m6a285e2de37cd6dd@mail.gmail.com> <720B57BF-7467-416D-BA1D-80B9ABE9B7CA@magma.ca> <82d15bd90902050636i14e016e7ra0a2bb9001fe7238@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] Cc: Behave WG Subject: Re: [BEHAVE] TURN-12 Comments/Typos X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 05:12:31 -0000 On Thu, 5-Feb-09, at 08:36 , Scott Godin wrote: > Hi Philip, > > A few responses.... > >>> 10. section 10.2 - should include a step to ensure that an >>> allocation >>> exists for the 5-tuple, else message is dropped >> >> This is said explicitly in section 4. Furthermore, it would be >> impossible >> for an implementator to forget this, since the server could not check >> permissions or have a source address for the UDP datagram if no >> allocation >> existed. > > This step is mentioned in the processing of other methods. Many of my > suggestions are to improve the overall consistency in the document > when describing the processing required for various methods. OK. In the sections describing Refresh, CreatePermission, ChannelBinding, and Send, I have added a reference to section 4. As a consequence, I removed the explicit mention of some of the section 4 processing from the Refresh section. > > >>> 15. section 11.5 - I'm not sure I understand the need to pad the >>> ChannelData message to a multiple of four bytes. TCP >>> implementations >>> are capable of reading in the exact right number of bytes from the >>> stream. Can this requirement be removed? >> >> It has been a long-standing property of STUN (and thus TURN) that >> both >> messages and the attributes within messages are aligned on four-byte >> boundaries. The requirement to pad ChannelData messages over TCP was >> inserted to keep this property. >> >> Do you have a technical reason why you think it is important to >> remove this >> padding? > > My only reason was that it adds unnecessary complexity for > implementors. However, I can buy your argument that you would like to > keep ChannelData messages somewhat consistent with StunMessage > packing. OK. > > >>> 16. Is there are reason we don't just make the default permission >>> and >>> channel binding lifetime the same, to facilitate use of the >>> ChannelBind refresh to accomplish both refreshes without worrying >>> about the difference? >> >> When the mechanism to age-out channels was first introduced, there >> was a >> request that the lifetime for channels be longer than that for >> permissions. >> As I recall, it was felt that there would be some race conditions >> introduced >> if the two timeout intervals were the same. >> >> Personally, I now feel that there would be no problems in making >> these two >> intervals the same and I agree with you that things would be slightly >> cleaner. But I am not sure it is worthwhile making the change at >> this late >> date. > > I would definitely support pushing this change through, given that a > good counter argument is not presented. Reading some other postings > on the list, it seems others feel the same way. > OK. Let's see what others say. - Philip From teemu.savolainen@nokia.com Thu Feb 5 22:21:14 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@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: [BEHAVE] [shara] TR: I-DAction:draft-boucadair-pppext-portrang e-option-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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: behave@core3.amsl.com Delivered-To: behave@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: [BEHAVE] [shara]TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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 dwing@cisco.com Thu Feb 5 22:47:23 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@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, dthaler@windows.microsoft.com Subject: Re: [BEHAVE] [shara]TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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: behave@core3.amsl.com Delivered-To: behave@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: [BEHAVE] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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: behave@core3.amsl.com Delivered-To: behave@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: [BEHAVE] [shara]TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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: behave@core3.amsl.com Delivered-To: behave@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: [BEHAVE] [shara]TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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 gaborbajko@gmail.com Thu Feb 5 23:40:33 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CADB3A69AA for ; Thu, 5 Feb 2009 23:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.301 X-Spam-Level: ** X-Spam-Status: No, score=2.301 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, MANGLED_MEDS=2.3, 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 G43v3GoZ0CmB for ; Thu, 5 Feb 2009 23:40:30 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id F0B623A6959 for ; Thu, 5 Feb 2009 23:40:29 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so728857wfd.31 for ; Thu, 05 Feb 2009 23:40:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :x-mimeole; bh=wUv5PYs0kd4o11fHiDHxdKIOjT4OkSj7vXZTg9SO4CM=; b=jLQ9nrIPkdB+ospywmXl0pba0NUar82b5jwFINeSf7KqA/hChsBYrGjnBmGZpFxkza avkW4/S4yP/Plw2WOwLrnTdYpQlugHc1WllIQSJ1pcs9F22aBvZR9IeKo6aJ8f8M72GP PMxbGvuN+8EAMD3n4hPJ1ImE/Ij8eQefUJEe4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:x-mimeole; b=nyDPRMz0ORKdumJGeQd2L2aRgLsyHaSNKEFCl2/kcSsVy2JCcYZYfxU+uD+hBfoTMh 3lIgzSqRL4jtgtuStKNIJkPdgHfrfhL9pzBdvtofsVP/p8y6Etb0t+jxFW9EnpzpIHTj UCDfoTDQBzcbTTgby/ksnX61gaCKbYBZaQ89A= Received: by 10.142.126.6 with SMTP id y6mr806721wfc.52.1233906031673; Thu, 05 Feb 2009 23:40:31 -0800 (PST) Received: from 1USL00618 (c-67-169-182-244.hsd1.ca.comcast.net [67.169.182.244]) by mx.google.com with ESMTPS id 29sm3468162wfg.53.2009.02.05.23.40.27 (version=SSLv3 cipher=RC4-MD5); Thu, 05 Feb 2009 23:40:29 -0800 (PST) From: "Gabor Bajko" To: Date: Thu, 5 Feb 2009 23:40:25 -0800 Message-ID: <007401c9882e$2eb11480$6400a8c0@NOE.Nokia.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0075_01C987EB.208DD480" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmH6rF7O8eIFT3dRwGVzm6VhD6rmwADK9cQAAsCqgAAANc0wAABCkFAAADKtBA= X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: [BEHAVE] FW: [shara] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 07:40:33 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0075_01C987EB.208DD480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dan, The attached document should appear shortly in the ietf directories. = Section 2 tries to justify the need for non-contiguous port range allocation. Sections 4 and 5 explain how the non-contiguous port range and random = port delegation works. - gabor >-----Original Message----- >From: shara-bounces@ietf.org [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; = 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 ------=_NextPart_000_0075_01C987EB.208DD480 Content-Type: text/plain; name="draft-bajko-pripaddrassign-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-bajko-pripaddrassign-00.txt" =0A= =0A= Network WG Gabor Bajko=20 Internet Draft Teemu Savolainen=20 Intended Status: Proposed Standard Nokia=20 Expires: August 3, 2009 M. Boucadair=20 P. Levis=20 France Telecom=20 February 3, 2009=20 =20 =20 Port Restricted IP Address Assignment=20 draft-bajko-pripaddrassign-00=20 =20 =20 Status of this Memo=20 =20 This Internet-Draft is submitted to IETF in full conformance with=20 the provisions of BCP 78 and BCP 79.=20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other documents=20 at any time. It is inappropriate to use Internet-Drafts as reference=20 material or to cite them other than as "work in progress."=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt.=20 =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 This Internet-Draft will expire on August 3, 2009.=20 =20 Copyright Notice=20 =20 Copyright (c) 2009 IETF Trust and the persons identified as the=20 document authors. All rights reserved.=20 =20 This document is subject to BCP 78 and the IETF Trust's Legal=20 Provisions Relating to IETF Documents=20 (http://trustee.ietf.org/license-info) in effect on the date of=20 publication of this document. Please review these documents=20 carefully, as they describe your rights and restrictions with=20 respect to this document.=20 =20 =20 Abstract=20 =20 When IPv6 was designed, the assumption was that the transition from=20 IPv4 to IPv6 will occur way before the exhaustion of the available=20 =20 Bajko Expires August 3, 2009 [Page 1]=20 =0C =20 Port Restricted IP address assignment January 2009=20 =20 IPv4 address pool. The unexpected growth of the IPv4 Internet and=20 the hesitation and technical difficulties to deploy IPv6 indicates=20 that the transition may take much longer than originally=20 anticipated.=20 It is expected that communication using IPv6 addresses will increase=20 during the next few years to come at the expense of communication=20 using IPv4 addresses. The Internet should reach a safety point in=20 the future, where the number of IPv4 public addresses in use at a=20 given time begins decreasing. It is very likely that the IPv4 public=20 address pool currently available at IANA will be exhausted before=20 the internet reaches this safety point. This creates a need to=20 prolong the lifetime of the available IPv4 addresses.=20 =20 This document defines methods to allocate the same IPv4 address to=20 multiple hosts, with the aim to prolong the availability of public=20 IPv4 addresses, possibly for as long as it takes for IPv6 to take=20 over the demand for IPv4. =20 =20 Conventions used in this document=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20 this document are to be interpreted as described in RFC-2119=20 [RFC2119].=20 =20 Terminology and abbreviations used in this document=20 =20 Port restricted IPv4 address: an IP address which can only be used=20 in conjunction with the specified ports. Port restriction refers to=20 all known transport protocols (UDP, TCP, SCTP, DCCP). =20 =20 CGN Carrier Grade Network Address Translator =20 CPE Consumer Premises Equipment, a device that resides=20 between internet service provider's network and=20 consumers' home network. =20 PRA Port Restricted IPv4 Address =20 =20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =20 Bajko Expires August 3, 2009 [Page 2]=20 =0C =20 Port Restricted IP address assignment January 2009=20 =20 Table of Content=20 =20 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .4=20 2. Port Randomization . . . . . . . . . . . . . . . . . . . . . . .5=20 3. DHCPv4 Option for allocating port restricted public IPv4 =20 address . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6=20 4. Port Mask sub-option usage . . . . . . . . . . . . . . . . . . .8=20 4.1 Illustration Examples . . . . . . . . . . . . . . . . . . . . .9=20 5. Random Port delegation function . . . . . . . . . . . . . . . .10=20 6. Option Usage . . . . . . . . . . . . . . . . . . . . . . . . . 12=20 6.1 Client Behaviour . . . . . . . . . . . . . . . . . . . . . . .12=20 6.2 Server Behaviour . . . . . . . . . . . . . . . . . . . . . . .13=20 7. Applicability . . . . . . . . . . . . . . . . . . . . . . . . .14=20 7.1 ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15=20 7.2 6to4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15=20 7.3 Protocols not supported by multiplexing gateway . . . . . . . 15=20 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . .15=20 9. Security considerations . . . . . . . . . . . . . . . . . . . .15=20 10. Normative References . . . . . . . . . . . . . . . . . . . . .16=20 11. Informative References . . . . . . . . . . . . . . . . . . . .16=20 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . .17=20 13. Editor's Addresses . . . . . . . . . . . . . . . . . . . . . .17=20 =20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =20 Bajko Expires August 3, 2009 [Page 3]=20 =0C =20 Port Restricted IP address assignment January 2009=20 =20 1. Introduction=20 =20 There are a number of possible solutions to deal with the problem of=20 transitioning from IPv4 to IPv6; however none of them is a one fits=20 all solution. Different solutions fit different deployment scenarios=20 (see also [ARKK2008]). See [WING2008] for comparison.=20 =20 As a possible additional and complementary solution for the IPv4- IPv6 coexistence period, this document describes a method, using=20 newly defined DHCPv4 [RFC2131] option that allows servers to assign=20 port restricted IPv4 addresses to clients. By assigning the same=20 IPv4 address to multiple clients, the availability of IPv4 addresses=20 can be, hopefully, prolonged for as long as it takes for IPv6 to=20 take over the demand for IPv4.=20 =20 The solution described in this document is intended to be used by=20 large ISPs, who as of the date of writing this document, have a=20 large enough IPv4 address pool to be able to allocate one public=20 IPv4 address for each and every client. They expect though that the=20 situation is unsustainable and they will soon not be able to provide=20 every client with a public IPv4 address. Such ISPs have two=20 possibilities to choose from: =20 - deploy Network Address Translators (NAT), which can be a=20 significant investment for ISPs not having NATs yet. The address=20 space limitations of [RFC1918] may even force these large ISPs to=20 deploy double NATs, which come with all the harmful behaviour of=20 Carrier Grade NATs (CGN), as described in [MAEN2008]; or =20 - allocate fragments of the same public IPv4 address directly to=20 multiple clients (which can be CPEs or end hosts), thus avoid the=20 cost of deploying multiple layers of NATs or carrier grade NATs. It=20 is however assumed, that the demand for IPv4 addresses will decrease=20 in the not so distant future, being taken over by IPv6, as the=20 proposal in this draft is not by any means a permanent solution for=20 the IPv4 address exhaustion problem. In fact, some presented=20 deployment scenarios require existence of IPv6 access network.=20 =20 For ISPs not having NATs yet, a solution not requiring NATs would=20 probably be preferred. For some other ISPs, who already have NATs in=20 place, increasing the capacity of their NATs might be a viable=20 alternative.=20 =20 In other deployment scenarios, allocation of shared addresses to=20 devices at the edge of the network would result in distribution of=20 NAT functionality to the edges, in some cases even to CPEs [APLUSP].=20 =20 This document proposes to use new DHCPv4 option to allocate port- restricted IPv4 addresses to the clients. This method is meant to be=20 an IPv4 to IPv6 transition tool, to be only temporarily used during=20 the period when the demand for public IPv4 addresses will exceed the=20 availability of them. =20 =20 =0A= =20 Bajko Expires August 3, 2009 [Page 4]=20 =0C =20 Port Restricted IP address assignment January 2009=20 =20 The port restricted IPv4 address option described in this document=20 can be used in various deployment scenarios, some of which are=20 described in [BOUCADAIRARCH], [APLUSP], and [DSLITE].=20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =20 Bajko Expires August 3, 2009 [Page 5]=20 =0C =20 Port Restricted IP address assignment January 2009=20 =20 =20 2. Port Randomization=20 =20 It is well documented that attackers can perform "blind" attacks=20 against transport protocols. The consequences of these attacks range=20 from throughput-reduction to broken connections or data corruption.=20 These attacks rely on the attacker's ability to guess or know the=20 five-tuple (Protocol, Source Address, Destination Address, Source=20 Port, Destination Port) that identifies the transport protocol=20 instance to be attacked. Most of these attacks can be prevented by=20 randomly selecting the client source port number such that the=20 possibility of an attacker guessing the exact value is reduced.=20 [RANDOMPORT] defines a few algorithms which can select a random port=20 from the available port range. Clients usually have the (1024,=20 65535) port range at their disposal to select a random, not yet used=20 port.=20 =20 When an IP address is allocated to multiple clients, the source port=20 range has to be divided between the clients. The smaller the port=20 range, the easier is for an attacker to guess the next port the=20 client is going to use. Therefore, it is imperative to divide the=20 port range between clients sharing the same IP address in such a way=20 that random selection is preserved. This document proposes two=20 different methods for port allocation, which preserves partly or=20 completely the randomness of the source ports:=20 =20 o The first mechanism uses a port mask with a bit locator to=20 communicate a range or multiple ranges of ports to a client.=20 Randomness is preserved when the client is able to select a=20 port randomly across all the available port ranges. The=20 algorithms described in [RANDOMPORT] can be used to select a=20 random port from one port range, but implementations may find=20 it difficult to select random ports across port ranges. =20 =20 o The second mechanism uses a cryptographic function to=20 preallocate random ports from the entire port range. The key=20 and other input parameters are communicated to the client,=20 which can calculate the ports it can use. The 'side effect' of=20 this mechanism is that the client is forced to use random=20 ports, as a number of random ports allowed to be used by the=20 client are preallocated by the server. When this mode is used,=20 the network equipments in charge of routing the inbound packets=20 towards the clients may require more processing resources.=20 =20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =20 Bajko Expires August 3, 2009 [Page 6]=20 =0C =20 Port Restricted IP address assignment January 2009=20 =20 3. DHCPv4 Option for allocating port restricted public IPv4 address =20 =20 This section defines new DHCPv4 option, which allows allocation of=20 port restricted IPv4 addresses. =20 =20 The option layout is depicted below: =20 =20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Option Code | length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Sub-Option 1 |=20 . .=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | ... |=20 . .=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Sub-Option n |=20 . .=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Option Code =20 Option Code =20 OPTION-IPv4-PRA (TBD) - 1 byte =20 =20 Length=20 An 8-bit field indicating the length of the option excluding=20 the 'Option Code' and the 'Length' fields =20 =20 Sub-options =20 A series of DHCPv4 sub-options. =20 =20 The sub-option layout is depicted below:=20 =20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Sub-opt Type | length | DATA .=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 . DATA |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 The sub-option types defined in this document are:=20 1 port mask=20 2 random port delegation function=20 =20 These two options are exclusive with each other (if one is used, the=20 other one is not).=20 =20 Length=20 An 8-bit field indicating the length of the sub-option=20 excluding the 'Sub-opt Type' and the 'Length' fields. The value=20 =0A= =20 Bajko Expires August 3, 2009 [Page 7]=20 =0C =20 Port Restricted IP address assignment January 2009=20 =20 of the length field is 8 when the Sub-opt Type equals 1 and 26=20 when the sub-opt Type equals 2.=20 The format of the DATA field when the sub-opt type indicates port=20 mask (value =3D 1):=20 =20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | IPv4 address |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Port Range Value | Port Range Mask |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 IPv4 address=20 Public IPv4 address=20 =20 Port Range Value and Port Range Mask=20 Port Range Value indicates the value of the mask to be applied=20 and Port Range Mask indicates the position of the bits which=20 are used to build the mask.=20 =20 Section 4 describes how the client derives the allocated port range=20 from the Port Range Value and Port Range Mask values.=20 =20 The format of the DATA field when the sub-opt type indicates random=20 port delegation function (value =3D 2):=20 =20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | IPv4 address |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | function | starting point |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | number of delegated ports | key K ...=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 ... ...=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 ... ...=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 ... ...=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 ... key K |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 IP address =20 Public IPv4 address =20 =20 Function=20 A 16bit field whose value is associated with predefined=20 encryption functions. This specification associates value 1=20 with the predefined function described in section 5.=20 =20 =20 Bajko Expires August 3, 2009 [Page 8]=20 =0C =20 Port Restricted IP address assignment January 2009=20 =20 Starting Point=20 A 16bit value used as an input to the specified function=20 =20 =20 Number of delegated ports=20 A 16bit value specifying the number of ports delegated to the=20 client for use as source port values=20 =20 Key K=20 A 128 bit key used as input to the predefined function for=20 delegated port calculation=20 =20 4. Port Mask sub-option usage=20 =20 The port mask sub-option is used to specify one or multiple range of=20 ports pertaining to the given IP address. =20 =20 Concretely, this option is used to notify a remote DHCP client about=20 the Port Mask to be applied when selecting a port value as a source=20 port. The Port Mask option is used to infer a set of allowed port=20 values. A Port Mask defines a set of ports that all have in common a=20 subset of pre-positioned bits. This ports set is also called Port=20 Range. Two port numbers are said to belong to the same Port Range if=20 and only if, they have the same Port Mask.=20 =20 A Port Mask contains two fields: Port Range Value and Port Range=20 Mask. =20 =20 - The 'Port Range Value' field indicates the value of the=20 significant bits of the Port Mask. The .Port Range Value. is coded=20 as follows: =20 - The significant bits are those where "1" values are set in=20 the Port Range Mask. These bits may take a value of "0" or "1 ". =20 - All the other bits (non significant ones) are set to "0".=20 =20 - The 'Port Range Mask' field indicates the position of the=20 significant bits identified by the bit(s) set to "1".=20 =20 The Port Range Value field indicates the value of the mask to be=20 applied and the Port Range Mask field indicates the position of the=20 bits which are used to build the mask. The "1" values in the Port=20 Range Mask field indicate by their position the significant bits of=20 the Port Range Value (the pattern of the Port Range Value).=20 =20 For example:=20 - A Port Range Mask field equal to 1000000000000000 indicates=20 that the first bit (the most significant one) is used as a=20 pattern of the Port Range Value field;=20 =20 - A Port Range Mask field equal to 0000101000000000 indicates=20 that the 5th and the 7th most significant bits are used as a=20 pattern of the Port Range Value.=20 =20 Bajko Expires August 3, 2009 [Page 9]=20 =0C =20 Port Restricted IP address assignment January 2009=20 =20 =20 The pattern of the Port Range Value is all the fixed bits in the=20 Port Range Value. All the ports the CPE is allowed to use as source=20 ports must have their number in accordance with the pattern.=20 =20 The Port Range Value is coded as follows:=20 - The pattern bits of the Port Range Value are those where "1"=20 values are set in the Port Range Mask. These bits may take a=20 value of 0 or 1.=20 - All the other bits are set to "0".=20 =20 4.1 Illustration Examples=20 =20 In each of the three examples below allocation of 2048 ports is done=20 differently. In all examples it is possible for 32 hosts to share=20 the same public IPv4 address. The 4th example illustrates the=20 ability of the procedure to enforce a balanced distribution of port=20 numbers including the well-known-port values.=20 =20 a) the following Port Range Mask and Port Range Value are conveyed=20 using DHCP to assign a Port Range (from 2048 to 4095) to a given=20 device:=20 - Port Range Value: 0000100000000000 (2048)=20 - Port Range Mask: 1111100000000000 (63488)=20 =20 b) Unlike the previous example, this one illustrates the case where=20 a non Continuous Port Range is assigned to a given customer's=20 device. In this example, the Port Range Value defines 128 Continuous=20 Port Ranges, each one with a length of 16 port values. Note that=20 the two first Port Ranges are both in the well-known ports span=20 (i.e. 0-1023) but these two ranges are not adjacent.=20 =20 The following Port Range Mask and Port Range Value are conveyed in=20 DHCP messages:=20 - Port Range Value : 0000000001010000 (80)=20 - Port Range Mask : 0000000111110000 (496)=20 =20 This means that the 128 following Continuous Port Ranges are=20 assigned to the same device:=20 - from 80 to 95=20 - from 592 to 607=20 - ...=20 - from 65104 to 65119=20 =20 c) In this example, the Port Range Value defines two Continuous Port=20 Ranges, each one being 1024 ports long:=20 =20 - Port Range Value : 0000000000000000 (0)=20 - Port Range Mask : 1111010000000000 (62464)=20 =20 This means that the two following Continuous Port Ranges are=20 assigned to the same device:=20 =20 Bajko Expires August 3, 2009 [Page 10]=20 =0C =20 Port Restricted IP address assignment January 2009=20 =20 - from 0 to 1023, and=20 - from 2048 to 3071=20 =20 d) In this example, 64 continuous Port Ranges are allocated to each=20 CPE (among a set of 4 CPEs sharing the same IPv4 address).=20 =20 Among the 64 continuous Port Ranges to each CPE, there is always one=20 within the span of the first 1024 well-known port values. Hereafter=20 is given the Port Range Value and Port Range Mask assigned to 2 CPEs=20 (CPE#0 and CPE#3, CPE#1 and CPE#2 being not represented here):=20 =20 1. CPE#0=20 =20 - Port Range Value: 0000000000000000 (0)=20 - Port Range Mask: 0000001100000000 (768)=20 =20 The CPE#0 has therefore the 64 following Continuous Port Ranges:=20 - 1st range: 0-255=20 - ...=20 - 64th range: 64512-64767=20 =20 2. CPE#3=20 =20 - Port Range Value: 0000001100000000 (768)=20 - Port Range Mask: 0000001100000000 (768)=20 =20 The CPE#2 has therefore the 64 following Continuous Port Ranges:=20 - 1st range: 768-1023=20 - ...=20 - 64th range: 65280-65535=20 =20 5. Random Port delegation function=20 =20 Delegating random ports can be achieved by defining a function which=20 takes as input a key 'k' and an integer 'x' within the range (1024,=20 65535) and produces an output 'y' also within the range (1024,=20 65535). =20 =20 The server uses a cryptographical mechanism (described below) to=20 select the random ports for each host. Instead of assigning a range=20 of ports using port mask to the client, the server sends the inputs=20 of a predefined cryptographic mechanism: a key, an initial value,=20 and the number of ports assigned to this host. The client can then=20 calculate the full list of assigned ports itself.=20 =20 The cryptographical mechanism ensures that the entire 64k port range=20 can be efficiently distributed to multiple hosts in a way that when=20 hosts calculate the ports, the results will never overlap with ports=20 other hosts have calculated (property of permutation), and ports in=20 the reserved range (smaller than 1024) are not used. As the=20 randomization is done crypthographically, an attacker seeing a host=20 =0A= =20 Bajko Expires August 3, 2009 [Page 11]=20 =0C =20 Port Restricted IP address assignment January 2009=20 =20 using some port X cannot determine which other ports the host may be=20 using (as the attacker does not know the key).=20 =20 Calculation of the random port list is done as follows: =20 =20 The cryptographic mechanism uses an encryption function y =3D E(K,x)=20 that takes as input a key K (for example, 128 bits) and an integer x=20 (the plaintext) in range (1024, 65535), and produces an output y=20 (the ciphertext), also an integer in range (1024, 65535). This=20 section describes one such encryption function, but others are also=20 possible.=20 =20 The server will select the key K. When server wants to allocate e.g.=20 2048 random ports, it selects a starting point 'a' (1024 <=3D a <=3D=20 65536-2048) in a way that the range (a, a+2048) does not overlap=20 with any other active client, and calculates the values E(K,a),=20 E(K,a+1), E(K,a+2), ..., E(K,a+2046), E(K,a+2047). These are the=20 port numbers allocated for this host. Instead of sending the port=20 numbers individually, the server just sends the values 'K', ' a',=20 and '2048'. The client will then repeat the same calculation.=20 =20 The server SHOULD use different K for each IPv4 address it allocates=20 to make attacks as difficult as possible. This way, learning the K=20 used in IPv4 address IP1 would not help in attacking IPv4 address=20 IP2 that is allocated by the same server to different hosts.=20 =20 With typical encryption functions (such as AES and DES), the input=20 (plaintext) and output (ciphertext) are blocks of some fixed size;=20 for example, 128 bits for AES, and 64 bits for DES. For port=20 randomization, we need an encryption function whose input and output=20 is an integer in range (1024, 65535).=20 =20 One possible way to do this is to use the 'Generalized-Feistel=20 Cipher' [CIPHERS] construction by Black and Rogaway, with AES as the=20 underlying round function.=20 =20 This would look as follows (using pseudo-code): =20 =20 def E(k, x):=20 y =3D Feistel16(k, x)=20 if y >=3D 1024:=20 return y=20 else:=20 return E(k, y)=20 =20 Note that although E(k,x) is recursive, it is guaranteed to=20 terminate. The average number of iterations is just slightly over 1.=20 =20 Feistel16 is a 16-bit block cipher:=20 =20 def Feistel16(k, x):=20 left =3D x & 0xff=20 =20 Bajko Expires August 3, 2009 [Page 12]=20 =0C =20 Port Restricted IP address assignment January 2009=20 =20 right =3D x >> 8=20 for round =3D 1 to 3:=20 temp =3D (left + FeistelRound(k, round, right)) & 0xff=20 left =3D right=20 right =3D temp=20 return (right << 8) | left=20 =20 The Feistel round function uses:=20 =20 def FeistelRound(k, round, x):=20 msg[0] =3D round=20 msg[1] =3D x >> 8=20 msg[2] =3D x & 0xff=20 msg[3...15] =3D 0=20 return AES(k, msg)=20 =20 Performance: To generate list of 2048 port numbers, about 6000 calls=20 to AES are required (i.e., encrypting 96 kilobytes). Thus, it will=20 not be a problem for any device that can do, for example, HTTPS (web=20 browsing over SSL/TLS).=20 =20 Other port generator functions may be predefined in Standards Track=20 documents and allocated a not yet allocated 'function' value within=20 the corresponding sub-option type field.=20 =20 6. Option Usage =20 =20 6.1 Client Behaviour =20 =20 A DHCP client which supports the option defined in this document=20 MUST support both sub-option types.=20 =20 A DHCP client which supports the extensions defined in this=20 document, SHOULD insert the option OPTION-IPv4-PRA with both sub- option types into DHCPDISCOVER message to explicitly let the server=20 know that it supports port restricted IPv4 addresses.=20 o In the port mask sub-option type, the client SHALL set the IPv4=20 address and Mask Locator fields to all zeros. The client MAY=20 indicate the number of desired ports in Port Range Value-field,=20 or set that to all zeroes.=20 o In the random port delegation sub-option type, the client SHALL=20 set the IPv4 address field, key field and starting point field=20 to all zeros. The client MAY indicate in function field which=20 encryption function it prefers, and in the number of delegated=20 ports field the number of ports the client would desire.=20 =20 When a client, which supports the option defined in this document,=20 receives a DHCPOFFER with the 'yiaddr' (client IP address) field set=20 to 0.0.0.0, it SHOULD check for the presence of OPTION-IPv4-PRA=20 option. If such an option is present, the client MAY send a=20 DHCPREQUEST message and insert the option OPTION-IPv4-PRA with the=20 corresponding sub-options received in the OPTION-IPv4-PRA option of=20 =20 Bajko Expires August 3, 2009 [Page 13]=20 =0C =20 Port Restricted IP address assignment January 2009=20 =20 the previous DHCPOFFER. The client MUST NOT include a 'Requested IP=20 Address' DHCP option (code 50) into this DHCPREQUEST. =20 =20 The client MUST NOT insert the IP address received in OPTION-IPv4- PRA into the 'Requested IP Address' DHCP option (code 50). When the=20 client receives a DHCPACK message with an OPTION-IPv4-PRA option, it=20 MAY start using the specified IP address in conjunction with the=20 source ports specified by the mechanism chosen by DHCP server. The=20 client MUST NOT use the IP address with different source port=20 numbers, as that may result in a conflict, since the same IP address=20 with a different source port group may be assigned to a different=20 client. Furthermore, the client MUST notice the situation where an=20 outgoing IP packet has the same IP address as destination address=20 than the client itself has, but the port number is not belonging to=20 the allocated set. In this case the client MUST detect that the=20 packet is not destined for itself, and it MUST send it forward. =20 =20 In case the initial port set received by the client from the server=20 is exhausted and the client needs additional ports, it MAY request=20 so by sending a new DHCPDISCOVER message. =20 =20 In some deployment scenarios the DHCP client may also act as a DHCP=20 server for a network behind it, in which case the host may further=20 split the allocated set for other hosts. =20 =20 6.2 Server Behaviour =20 =20 When a server, which supports the option defined in this document,=20 receives a DHCPDISCOVER message, it SHOULD check the presence of the=20 OPTION-IPv4-PRA option. =20 =20 If OPTION-IPv4-PRA is not present in DHCPDISCOVER, the server SHOULD=20 allocate full unrestricted public or private [RFC1918] IPv4 address=20 to the client, if available, by generating a DHCPOFFER as described=20 in [RFC2131]. =20 =20 The server SHOULD offer the port restricted IPv4 address when the=20 server has support the extensions specified in this document and=20 when: =20 o DHCP client has included OPTION-IPv4-PRA option and server.s=20 policy indicates saving unrestricted IPv4 addresses for clients=20 that do not support the extensions defined in this document=20 o server receives a DHCPDISCOVER message and server can only=20 offer port restricted IP address to the client =20 o server receives a DHCPDISCOVER message from a client without=20 the OPTION-IPv4-PRA, but knows by means outside the scope of=20 this document that the client supports the usage of port- restricted IPv4 addresses (or it is only entitled to be=20 provisioned with such addresses)=20 =20 When server chooses to offer port restricted IPv4 address for=20 clients with OPTION-IPv4-PRA, it MUST:=20 =20 Bajko Expires August 3, 2009 [Page 14]=20 =0C =20 Port Restricted IP address assignment January 2009=20 =20 o set the 'yiaddr' (client IP address) field of the DHCPOFFER=20 message to 0.0.0.0=20 o choose the port allocation mechanisms, if it is not statically=20 configured=20 o select a port restricted IPv4 address to be allocated for the=20 client=20 o generate parameters required for the chosen port allocation=20 mechanism in case of using sub-option type '1', or including=20 the key K for random port generation in case of using the sub- option type '2'=20 =20 When the server receives a DHCPREQUEST message from the client with=20 an OPTION-IPv4-PRA option field containing the IP address and port=20 allocation mechanism parameters it has previously offered to the=20 client, the server MUST send a DHCPACK, where the 'yiaddr' (client=20 IP address) field is set to 0.0.0.0 and the OPTION-IPv4-PRA option=20 including the IPv4 address and parameters required for the used=20 allocation mechanism.=20 =20 When the server receives a DHCPREQUEST message from the client with=20 an OPTION-IPv4-PRA option field containing an IPv4 address and port=20 set it has previously not offered to the client, the server MUST=20 send a DHCPNAK to the client. =20 =20 When the server detects that a client (by eg having a specific=20 hardware address), has already been allocated with a port restricted=20 IPv4 address, sent another DHCPDISCOVER, it MAY, based on local=20 policy, offer the client with additional port restricted IPv4=20 address. =20 =20 If the server is deployed in a cascaded DHCP server scenario, the=20 host MAY both act as a DHCP client for another server and DHCP=20 server for other DHCP clients.=20 =20 A server SHOULD ensure the client is residing on an access link=20 where usage of port-restricted addresses is not causing problems,=20 before allocating it a port restricted IPv4 address.=20 =20 7. Applicability=20 =20 The multiplexing of IP flows in gateway is based on the port numbers=20 used by transport layer protocols such as TCP, UDP, SCTP, and DCCP.=20 However, the protocols not containing port numbers need special=20 handling in order to be multiplexed correctly.=20 =20 =20 =20 =20 =20 7.1 ICMP=20 =20 =0A= =20 Bajko Expires August 3, 2009 [Page 15]=20 =0C =20 Port Restricted IP address assignment January 2009=20 =20 Those ICMP messages that embed the IP packet that triggered sending=20 of ICMP message, such as ICMP error, can be multiplexed based on the=20 port number present in the embedded original packet.=20 =20 ICMP messages not containing embedded packets, like ICMP echo, are=20 TBD.=20 =20 7.2 6to4=20 =20 A host utilizing 6to4 [RFC3056] with port restricted IPv4 addresses=20 MUST pick the 16-bit .SLA ID. value for the 6to4 prefix(es)=20 construction from the pool of allocated port values. The=20 multiplexing gateway MUST then multiplex 6to4 traffic based on .SLA=20 ID. value as it would multiplex plain IPv4 traffic based on port=20 values. I.e. for incoming packets the gateway shall look at the=20 destination IPv4 address and the .SLA ID.-field from tunneled IPv6=20 packet.s destination IPv6 address, and then select the right route=20 as it would have picked the port number from a transport layer=20 header.=20 =20 7.3 Protocols not supported by multiplexing gateway=20 =20 The case where port range router is not able to multiplex a protocol=20 is similar to a case where middle box, such as firewall or NAT,=20 blocks traffic it is not able or willing to pass trough. The=20 application is recommended to fallback to UDP encapsulation often=20 used for NAT traversal, for which gateway is able to perform=20 multiplexing.=20 =20 8. IANA considerations=20 =20 This document defines new DHCPv4 option as described in section 3:=20 Port Restricted IP Address Option for DHCPv4 (OPTION-IPv4-PRA) TBD. =20 =20 9. Security considerations=20 =20 The solution is generally vulnerable to DoS when used in shared=20 medium or when access network authentication is not a prerequisite=20 to IP address assignment. The solution SHOULD only be used on point- to-point links, tunnels, and/or in environments where authentication=20 at link layer is performed before IP address assignment, and not=20 shared medium. =20 =20 The cryptographically random port delegation mechanism is vulnerable=20 for blind attacks initiated by hosts located in the same=20 administrative domain, served by the same DHCP server, and that are=20 sharing the same public IPv4 address, and therefore have knowledge=20 of the cryptographic key used for that particular public IPv4=20 address. =20 =20 10. Normative References=20 =20 =20 Bajko Expires August 3, 2009 [Page 16]=20 =0C =20 Port Restricted IP address assignment January 2009=20 =20 [RFC2119] Bradner, S., .Key words for use in RFCs to Indicate=20 Requirement Levels., March 1997=20 =20 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", =20 RFC2131, March 1997=20 =20 [RFC3056] Carpenter, B., Moore, K., .Connection of IPv6 Domains=20 via IPv4 Clouds., February 2001=20 =20 =20 =20 11. Informative References=20 =20 [ARKK2008] Arkko, J., Townsley, M., "IPv4 Run-Out and IPv4-IPv6 =20 Co-Existence Scenarios", September 2008, draft-arkko-=20 townsley-coexistence-00=20 =20 [WING2008] Wing, D., Ward, D., Durand, A., "A Comparison of =20 Proposals to Replace NAT-PT", September 2008, draft-=20 wing-nat-pt-replacement-comparison=20 =20 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., J. de =20 Groot, G., Lear, E., "Address Allocation for Private =20 Internets", RFC1918, February 1996 =20 =20 [MAEN2008] Maennel, O., Bush, R., Cittadini, L., Bellovin, S., "A =20 Better Approach than Carrier-Grade-NAT", 2008, =20 Technical Report CUCS-041-08 =20 =20 [RANDOMPORT] Larsen, M., Gont, F., .Port Randomization., August=20 2008, draft-ietf-tsvwg-port-randomization-02=20 =20 [CIPHERS] John Black and Phillip Rogaway: .Ciphers with Arbitrary=20 Finite Domains., Topics in Cryptology - CT-RSA 2002,=20 Lecture Notes in Computer Science vol. 2271, 2002=20 =20 [DSLITE] A. Durand et al .Dual-stack lite broadband deployments=20 post IPv4 exhaustion., November 2008, draft-durand- softwire-dual-stack-lite=20 =20 [BOUCADAIR] Boucadair, M, Ed., Grimault, J-L., Levis, P.,=20 Villefranque, A., .DHCP Options for Conveying Port Mask=20 and Port Range Router IP Address., October 2008, draft- boucadair-dhc-port-range=20 =20 [BOUCADAIRARCH] Boucadair, M., Ed., Levis, P., Bajko, G.,=20 Savolainen, T., .IPv4 Connectivity Access in the=20 Context of IPv4 Address Exhaustion., January 2009,=20 draft-boucadair-port-range=20 =20 =0A= =0A= =20 Bajko Expires August 3, 2009 [Page 17]=20 =0C =20 Port Restricted IP address assignment January 2009=20 =20 [APLUSP] Maennel, O., Bush, R., Cittadini, L., Bellovin, S., "The = A+P Approach to the IPv4 Address Shortage", January=20 2009, draft-ymbk-aplusp=20 =20 12. Contributors=20 =20 The port range allocation using Port Range Value / Port Range Mask=20 comes from [BOUCADAIR], authored by Mohamed Boucadair, Jean Luc=20 Grimault and Pierre Lewis.=20 =20 The encryption function from section 5 was provided by Pasi Eronen. =20 =20 The text on 6to4 handling was proposed by Dave Thaler.=20 =20 The rest of the document was written and edited by Gabor Bajko and=20 Teemu Savolainen.=20 =20 The authors would also like to thank Lars Eggert, Olaf Maenel, Randy=20 Bush, Alain Durand, Jean-Luc Grimault, Alain Villefranque for their=20 valuable comments.=20 =20 =20 13. Authors' Addresses=20 =20 Gabor Bajko=20 gabor(dot)bajko(at)nokia(dot)com=20 =20 =20 Teemu Savolainen=20 Nokia=20 Hermiankatu 12 D=20 FI-33720 TAMPERE=20 Finland=20 =20 Email: teemu.Savolainen@nokia.com=20 =20 =20 Mohamed Boucadair=20 France Telecom=20 42 rue des Coutures=20 BP 6243=20 Caen Cedex 4 14066=20 France=20 =20 Email: mohamed.boucadair@orange-ftgroup.com=20 =20 =20 Pierre Levis=20 France Telecom=20 42 rue des Coutures=20 BP 6243=20 Caen Cedex 4 14066=20 =20 Bajko Expires August 3, 2009 [Page 18]=20 =0C =20 Port Restricted IP address assignment January 2009=20 =20 France=20 =20 Email: pierre.levis@orange-ftgroup.com=20 =20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =20 Bajko Expires August 3, 2009 [Page 19]=20 =0C ------=_NextPart_000_0075_01C987EB.208DD480 Content-Type: text/plain; name="ATT00001.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00001.txt" _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara ------=_NextPart_000_0075_01C987EB.208DD480-- From pierre.levis@orange-ftgroup.com Thu Feb 5 23:55:15 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@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: [BEHAVE] [shara] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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 remi.despres@free.fr Fri Feb 6 01:42:39 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@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 Cc: behave@ietf.org, shara@ietf.org Subject: Re: [BEHAVE] TR: I-D Action:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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 mohamed.boucadair@orange-ftgroup.com Fri Feb 6 02:27:56 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@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: [BEHAVE] TR: I-D Action:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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: behave@core3.amsl.com Delivered-To: behave@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: [BEHAVE] [shara] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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 Gabor.Bajko@nokia.com Thu Feb 5 23:37:47 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@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 X-Mailman-Approved-At: Fri, 06 Feb 2009 08:08:58 -0800 Cc: behave@ietf.org, shara@ietf.org Subject: Re: [BEHAVE] [shara] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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 randy@psg.com Thu Feb 5 15:35:12 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@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 X-Mailman-Approved-At: Fri, 06 Feb 2009 08:09:10 -0800 Cc: behave@ietf.org, mohamed.boucadair@orange-ftgroup.com, shara@ietf.org Subject: Re: [BEHAVE] [shara] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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 randy@psg.com Thu Feb 5 22:11:51 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@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 X-Mailman-Approved-At: Fri, 06 Feb 2009 08:09:10 -0800 Cc: "behave@ietf.org" , "shara@ietf.org" , Dan Wing Subject: Re: [BEHAVE] [shara] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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 randy@psg.com Thu Feb 5 22:40:37 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@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 X-Mailman-Approved-At: Fri, 06 Feb 2009 08:09:10 -0800 Cc: behave@ietf.org, shara@ietf.org, dwing@cisco.com, dthaler@windows.microsoft.com Subject: Re: [BEHAVE] [shara]TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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 dthaler@windows.microsoft.com Fri Feb 6 16:57:54 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3D003A695D; Fri, 6 Feb 2009 16:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.515 X-Spam-Level: X-Spam-Status: No, score=-110.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 RvPfHShA1wWv; Fri, 6 Feb 2009 16:57:51 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id C7EBD3A680F; Fri, 6 Feb 2009 16:57:51 -0800 (PST) Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Fri, 6 Feb 2009 16:57:54 -0800 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.18.32) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) with Microsoft SMTP Server id 8.2.99.4; Fri, 6 Feb 2009 16:57:54 -0800 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::75be:c82f:ae04:55bf]) by tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.32]) with mapi; Fri, 6 Feb 2009 16:59:38 -0800 From: Dave Thaler To: "nat66@ietf.org" , "behave@ietf.org" Date: Fri, 6 Feb 2009 16:57:53 -0800 Thread-Topic: I-D posted: draft-thaler-ipv6-saf-01.txt Thread-Index: AcmIvxsE9Pyw3isCS8ehvr97Yv3Sjg== Message-ID: 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_E9CACA3D8417CE409FE3669AAE1E5A4F118EC37CC9NAEXMSGW601wi_" MIME-Version: 1.0 Subject: [BEHAVE] I-D posted: draft-thaler-ipv6-saf-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 00:57:55 -0000 --_000_E9CACA3D8417CE409FE3669AAE1E5A4F118EC37CC9NAEXMSGW601wi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've just posted http://www.ietf.org/internet-drafts/draft-thaler-ipv6-saf-01.txt This topic is definitely relevant to NAT66, and potentially to some use cases of NAT-PT replacements, so I'm putting this up for discussion. Abstract: There are various recent proposals that would result in IPv6 translation becoming permanent. RFC 3424 discusses UNilateral Self- Address Fixing (UNSAF) mechanisms which are required for applications to work with most translation schemes, points out a number of problems with them, and requires an exit strategy for any UNSAF mechanism. This document discusses an alternative to UNSAF mechanisms should IPv6 translation become permanent. -Dave Thaler --_000_E9CACA3D8417CE409FE3669AAE1E5A4F118EC37CC9NAEXMSGW601wi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve just posted

h= ttp://www.ietf.org/internet-drafts/draft-thaler-ipv6-saf-01.txt

 

This topic is definitely relevant to NAT66, and potent= ially to some

use cases of NAT-PT  replacements, so I’m p= utting this up for discussion.

 

Abstract:

   There are various recent proposals that w= ould result in IPv6

   translation becoming permanent.  RFC= 3424 discusses UNilateral Self-

   Address Fixing (UNSAF) mechanisms which a= re required for applications

   to work with most translation schemes, po= ints out a number of

   problems with them, and requires an exit strategy for any UNSAF

   mechanism.  This document discusses = an alternative to UNSAF

   mechanisms should IPv6 translation become permanent.

 

-Dave Thaler

 

--_000_E9CACA3D8417CE409FE3669AAE1E5A4F118EC37CC9NAEXMSGW601wi_-- From randy@psg.com Fri Feb 6 21:20:46 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@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, mohamed.boucadair@orange-ftgroup.com, shara@ietf.org, dthaler@windows.microsoft.com Subject: Re: [BEHAVE] [shara]TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 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 simon.perreault@viagenie.ca Sun Feb 8 06:17:42 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31C2A3A6A24 for ; Sun, 8 Feb 2009 06:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, NO_RELAYS=-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 g-oS4SGVkWwM for ; Sun, 8 Feb 2009 06:17:41 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 1CCFC3A68D1 for ; Sun, 8 Feb 2009 06:17:41 -0800 (PST) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 1D87529E1556; Sun, 8 Feb 2009 09:17:45 -0500 (EST) Received: from balaise.nomis80.org (unknown [IPv6:2001:5c0:1100:cf00:218:f3ff:fe3d:1af4]) by jazz.viagenie.ca (Postfix) with ESMTP id F2ABA29E151D; Sun, 8 Feb 2009 09:17:44 -0500 (EST) To: "Derek C. MacDonald" , "Bruce B. Lowekamp" Content-Disposition: inline From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= Date: Sun, 8 Feb 2009 09:17:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200902080917.43961.simon.perreault@viagenie.ca> Cc: behave@ietf.org Subject: [BEHAVE] RESPONSE-ORIGIN format X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 14:17:42 -0000 Hello, In [draft-ietf-behave-nat-behavior-discovery-05], is RESPONSE-ORIGIN XOR'ed with the transaction ID? I suppose it wouldn't make much sense to do so, but the text isn't explicit. Thanks, Simon -- Please try Numb, a STUN/TURN server implementation. Free access at http://numb.viagenie.ca/. From stig.venaas@uninett.no Mon Feb 9 04:26:26 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01B743A687C for ; Mon, 9 Feb 2009 04:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79JbBHwyUaP0 for ; Mon, 9 Feb 2009 04:26:25 -0800 (PST) Received: from tyholt.uninett.no (tyholt.uninett.no [IPv6:2001:700:1::eecb]) by core3.amsl.com (Postfix) with ESMTP id BF4523A6B97 for ; Mon, 9 Feb 2009 04:26:23 -0800 (PST) Received: from [IPv6?2001?700?1?0?215?f2ff?fe35?307d] (sverresborg.uninett.no [IPv6:2001:700:1:0:215:f2ff:fe35:307d]) by tyholt.uninett.no (Postfix) with ESMTP id 512102BADDD; Mon, 9 Feb 2009 13:26:25 +0100 (CET) Message-ID: <499020F1.4000002@uninett.no> Date: Mon, 09 Feb 2009 13:26:25 +0100 From: Stig Venaas User-Agent: Thunderbird 2.0.0.18 (X11/20081127) MIME-Version: 1.0 To: Dan Wing References: <4975A368.4040302@uninett.no> <0a2c01c9818a$4ab44d50$c2f0200a@cisco.com> In-Reply-To: <0a2c01c9818a$4ab44d50$c2f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] Multicast translation draft X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 12:26:26 -0000 Dan Wing wrote: >> -----Original Message----- >> From: behave-bounces@ietf.org >> [mailto:behave-bounces@ietf.org] On Behalf Of Stig Venaas >> Sent: Tuesday, January 20, 2009 2:12 AM >> To: behave@ietf.org >> Subject: [BEHAVE] Multicast translation draft >> >> A while ago I submitted the draft draft-venaas-behave-mcast46-00 >> describing an IPv4 - IPv6 multicast translator solution. >> >> I would appreciate any feedback on the draft, > > This draft feels quite complete. Good to hear. I wouldn't mind improving the draft with whatever is lacking though. > I wrote draft-wing-behave-learn-prefix-00.txt which was > primarily aimed at the following problem: I imagine it could > be common for the multicast application running on the IPv6-only > host to only learn an IPv4 multicast address (via an > electronic program guide, SDP, or whatever other means it > might learn of multicast addresses). But the draft requires > the IPv6-only host join the IPv6 multicast group which requires > the IPv6-only host somehow know the IPv6 prefix associated > with that IPv4 address and the SSM/ASM mapping between IPv6 > and IPv4. If I'm on track with my imagination then a discussion > of this might be helpful. This is an interesting problem. It should perhaps be noted in my draft, but I think it's good to do this in a separate document. > > BEHAVE working group: is there interest in this draft? I think it's good. It seems to address the problem for unicast, which I think is useful. If I understand you correctly, you are saying we need this also for multicast, and I agree with that. One issue with multicast, is that we may need two prefixes (one for ASM and another for SSM) in addition to the unicast one. I can see some possible ways the multicast prefixes could be derived from the unicast one though. I can think of a number of questions related to this. I'll try to list the questions and some of my thoughts below. First of all, one could consider not telling hosts and applications about any prefix, and where they don't know translation is taking place. This could kind of work as long as users or applications somehow are told to use the appropriate IPv6 address, e.g. by rewriting SDP. There are several issues with this, I don't want to go into detail here and now. Another way is to have a well-known prefix that can be hard coded in applications or stacks whatever. But I see benefits in not having a single fixed prefix, which I won't try to list here. The last option then, is to have a prefix (or one for ASM and one for SSM) that can be site dependent, which I think leaves us with a way for applications or hosts to learn the prefix. I think we need this, and hence I am interested in your draft. I have some thoughts regarding how the prefix should be learned. One choice is that applications learn the prefix. They can then know that translation is taking place, and they can know which IPv6 groups to join, corresponding to the IPv4 groups they have learned from SDP or other sources. This seems like a good idea, the only issue I see is that applications need to be modified. Another possibility, could be to hide it from applications and do some magic in the host stack. You could imagine that the host stack learns the prefix. Then when an application joins an IPv4 group (signals the stack), the stack could choose to treat it as an IPv6 join and send the corresponding MLD report. When the stacks receive translated IPv6 multicast, it could rewrite the packets to IPv4 (from the translated IPv6 datagram it knows the original IPv4 source and destination addresses and ports, and of course payload), and deliver it as IPv4 to the application. I'm sure there are lots of issues with this, the main advantage is hiding it from the application. Finally, about DNS vs DHCP. They both could work, but a problem with DHCP, is that you cannot really do DHCP requests directly from the application, and if the host runs a stand-alone DHCP client, there is no standardized way for how to provide this info to the application. Hence, this would need to be specified as well. DNS is of course simple for the application. If the prefix only needs to be known to the stack, then DHCP becomes easier (about as easy as DNS). I tried not to go into details here. Perhaps it's worth writing them down though. Stig From remi.despres@free.fr Mon Feb 9 05:56:56 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F3F53A6AFE; Mon, 9 Feb 2009 05:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.258 X-Spam-Level: X-Spam-Status: No, score=-1.258 tagged_above=-999 required=5 tests=[AWL=0.691, 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 Efc7ZYlsM30V; Mon, 9 Feb 2009 05:56:55 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id A9AE23A6AED; Mon, 9 Feb 2009 05:56:53 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 4202AD481BA; Mon, 9 Feb 2009 14:56:53 +0100 (CET) Received: from RD-Mac.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp5-g21.free.fr (Postfix) with ESMTP id 2F91BD48157; Mon, 9 Feb 2009 14:56:51 +0100 (CET) Message-ID: <499035A4.2030008@free.fr> Date: Mon, 09 Feb 2009 14:54:44 +0100 From: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Dave Thaler References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" , "nat66@ietf.org" Subject: Re: [BEHAVE] I-D posted: draft-thaler-ipv6-saf-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 13:56:56 -0000 Dave Thaler - le (m/j/a) 2/7/09 1:57 AM: > I've just posted > http://www.ietf.org/internet-drafts/draft-thaler-ipv6-saf-01.txt > The notion of Self-Address Finding (SAF) is IMO important. Knowing one's global address(es) even if the local address space is different, is BTW a key feature of what I am trying to propose with SAM. Minor point: In the Fate-Sharing item in 3.2, It seems to me that what is important is to have SAF working "as long as translators do access networks behind them" (i.e. not depending on some servers behind them being also operational)" . This should be more in line with the explanation on Fate sharing given in 3.1. (Or did I miss something?) Regards, RD From stig.venaas@uninett.no Mon Feb 9 07:06:36 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10DCE3A687C for ; Mon, 9 Feb 2009 07:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEHW4KzPcqTM for ; Mon, 9 Feb 2009 07:06:35 -0800 (PST) Received: from tyholt.uninett.no (smtp.uninett.no [IPv6:2001:700:1::eecb]) by core3.amsl.com (Postfix) with ESMTP id 0AECF3A67AF for ; Mon, 9 Feb 2009 07:06:34 -0800 (PST) Received: from [IPv6?2001?700?1?0?215?f2ff?fe35?307d] (sverresborg.uninett.no [IPv6:2001:700:1:0:215:f2ff:fe35:307d]) by tyholt.uninett.no (Postfix) with ESMTP id E196E2BAE25; Mon, 9 Feb 2009 16:06:37 +0100 (CET) Message-ID: <4990467D.3040107@uninett.no> Date: Mon, 09 Feb 2009 16:06:37 +0100 From: Stig Venaas User-Agent: Thunderbird 2.0.0.18 (X11/20081127) MIME-Version: 1.0 To: H.Miyata@jp.yokogawa.com References: <4975A368.4040302@uninett.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] Multicast translation draft X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 15:06:36 -0000 Hi H.Miyata@jp.yokogawa.com wrote: > Hi Stig, > > Sorry, I have not read it yet, but is it different idea of mine? > > http://www.ietf.org/internet-drafts/draft-miyata-v6ops-snatpt-02.txt There are some similarities, but my draft goes more into the details. One thing you suggest that I don't, is to allow specific mappings other than just inclusion of IPv4 groups into IPv6 space. It might be good to discuss whether that is needed or not. Maybe it is. I think the main new contribution with my draft, is how a translator should interact with PIM. This is important if you for instance have a routed network behind the translator and cannot just rely on IGMP proxying. It also allows for knowing whether there are listeners (both IPv4 and IPv6) and only doing translation and forwarding when needed. Sorry for the late answer, Stig > See, > > 11.8 Multicast Translation > > Regards, > > ------------------------------------ > Hiroshi Miyata, > Ubiquitous Field Computing Research Center, > Corporate R&D Headquaters, > Yokogawa Electric Corp. From dwing@cisco.com Mon Feb 9 09:51:04 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 351D73A67D4 for ; Mon, 9 Feb 2009 09:51:04 -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 h2le5hcYOaOK for ; Mon, 9 Feb 2009 09:51:03 -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 615013A6911 for ; Mon, 9 Feb 2009 09:51:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,406,1231113600"; d="scan'208";a="130069562" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 09 Feb 2009 17:51:05 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n19Hp5MW012736; Mon, 9 Feb 2009 09:51:05 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n19Hp5rN003568; Mon, 9 Feb 2009 17:51:05 GMT From: "Dan Wing" To: References: Date: Mon, 9 Feb 2009 09:51:05 -0800 Message-ID: <026601c98ade$fb048500$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: Acl9gyoFqJQHahqfQE++MKFFnjVLlwJcKdtAAPrAKUA= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1978; t=1234201865; x=1235065865; 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=20WGLC,=20draft-ietf-behave-nat-icmp-12 |Sender:=20; bh=BAnJOZ/6rK4dJNCphavE4CR4//y5dcvJmStyyoG5h2I=; b=dHro1b6ifK82z+5avpc0+eA6YoY5XQo/BTQhec5SqGwBqi2DxtsE8xPQOa dvU07df9R7t1mmA5n2dxBP9I9GwOt/uUGJ76a+23XQIl/r36RT0nm//2Jbko icoYOID3tne1bcT/dBEAMT61pZyZUlJ/qTaSHVie/Fq0jV9C+erAc=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: behave-chairs@tools.ietf.org, draft-ietf-behave-nat-icmp@tools.ietf.org Subject: Re: [BEHAVE] WGLC, draft-ietf-behave-nat-icmp-12 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 17:51:04 -0000 No comments were received, so the document is now ready to announce and forward to the RFC editor. Thanks, everyone! -d > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Wednesday, February 04, 2009 10:11 AM > To: 'behave@ietf.org' > Cc: 'draft-ietf-behave-nat-icmp@tools.ietf.org'; > 'behave-chairs@tools.ietf.org' > Subject: RE: WGLC, draft-ietf-behave-nat-icmp-12 > > A reminder: There are two days left in this re-WGLC for > draft-ietf-behave-nat-icmp-12. > > -d > > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Friday, January 23, 2009 9:51 AM > > To: 'behave@ietf.org' > > Cc: 'draft-ietf-behave-nat-icmp@tools.ietf.org'; > > 'behave-chairs@tools.ietf.org' > > Subject: WGLC, draft-ietf-behave-nat-icmp-12 > > > > Over a year ago we finished WGLC and forwarded > > draft-ietf-behave-nat-icmp-04 to the IESG for publication. > > It has now finished IESG review. During IESG review the > > document underwent a lot of revisions and we would like to > > make sure the BEHAVE working group is comfortable with > these changes. > > > > The most recent version is available at: > > http://tools.ietf.org/html/draft-ietf-behave-nat-icmp-12 > > > > Side-by-side diffs from -04 (which went through WGLC) to -12 are at: > > http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/dr > > aft-ietf-behave-nat-icmp-04.txt&url2=http://tools.ietf.org/id/ > > draft-ietf-behave-nat-icmp-12.txt > > > > The IESG tracker of activity is at: > > https://datatracker.ietf.org/idtracker/draft-ietf-behave-nat-icmp/ > > > > > > We will hold this document for two weeks for further > > comments, after which we will release this document to the > > RFC editor. Please send comments to the BEHAVE mailing list > > and also CC the authors at > > draft-ietf-behave-nat-icmp@tools.ietf.org by FEBRUARY 6. > > > > Thanks, > > -d > > > From dwing@cisco.com Mon Feb 9 16:40:15 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A23928C2A8 for ; Mon, 9 Feb 2009 16:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 RN-KE+xj4DN5 for ; Mon, 9 Feb 2009 16:40:14 -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 7030828C2B7 for ; Mon, 9 Feb 2009 16:40:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,407,1231113600"; d="scan'208";a="246173055" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 10 Feb 2009 00:40:17 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1A0eHn1022274; Mon, 9 Feb 2009 16:40:17 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n1A0eFkB019893; Tue, 10 Feb 2009 00:40:16 GMT From: "Dan Wing" To: "Behave WG" Date: Mon, 9 Feb 2009 16:40:16 -0800 Message-ID: <04b401c98b18$25c5dd50$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 Thread-Index: AcmLGCSP3p2vLQh+T4G/fqgsU6laWA== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2028; t=1234226417; x=1235090417; 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:=20TURN-TCP=20status |Sender:=20; bh=wcvzvoGfdb6nUZ/sSqzN7ukY3eUSNM4UsB2UOVUAd1k=; b=Kb3QvgZIyWTNAfk0rFTTLlhX1R2Zg3VrKdIdH+mcUm0J5YZDguGEPfaoUi Q/VHF0wtICYCNxM9egO1J/8dosx8eKPvJJwEip7t8QZM6kwVcST1e1QX6WsO nDUadBCslV; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: draft-ietf-behave-turn-tcp@tools.ietf.org, BEHAVE Chairs Subject: [BEHAVE] TURN-TCP status X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 00:40:15 -0000 The working group needs a new primary editor/author for turn-tcp. Philip Matthews, who has helped with TURN, does not have sufficient time to work on TURN-TCP. Rohan, the other co-author, also said he has insufficient time. That would leave Jonathan as the sole author and unfortunately he is stretched too thin. Our current milestone is March 2009 to submit the document to IESG but we won't make that date. TURN-TCP's model is similar to TURN (with a separate separate TCP connection per peer) which is expected to work well with a mix of slow and fast TCP peers. The document still needs a significant amount of work, including: * describe the TURN server behavior * finish description of TURN client behavior * IAB considerations section, including why TURN-TCP is necessary (versus SOCKS or other already-defined approaches) * Security considerations Related to TURN-TCP is ICE-TCP. Namely, if ICE-TCP can successfully establish a peer-to-peer TCP connection then TURN-TCP is unnecessary. However, research [1] indicates that the techniques considered by ICE-TCP will be successful approximately 80% of the time in establishing a direct peer-to-peer connection. The other 20% will simply fail, need to utilize a TURN-TCP relay, or use UDP (with the potential to lose TCP friendliness). There is a suggestion that ICE-TCP should encourage additional candidate gathering (Teredo, UPnP IGD, SOCKS) [2] which will help ICE-TCP establish direct peer-to-peer TCP connections, but the amount of improvement is not yet known. Is anyone planning to implement TURN-TCP client? TURN-TCP server? Or should we abandon TURN-TCP due to lack of need? And the $64 million question: if you can volunteer to take over editing TURN-TCP, please drop the chairs an email. Or should we abandon TURN-TCP due to lack of editor? -d [1] http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat/ [2] http://tools.ietf.org/html/draft-lowekamp-mmusic-ice-tcp-framework-00 From philip_matthews@magma.ca Mon Feb 9 17:39:58 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E54A53A6BCE for ; Mon, 9 Feb 2009 17:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 TpYMLK2sFtfM for ; Mon, 9 Feb 2009 17:39:57 -0800 (PST) Received: from mail-06.primus.ca (mail5.primus.ca [216.254.141.172]) by core3.amsl.com (Postfix) with ESMTP id 287AC3A6B1E for ; Mon, 9 Feb 2009 17:39:56 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1LWhbQ-0005Fz-1q for behave@ietf.org; Mon, 09 Feb 2009 20:39:58 -0500 Message-Id: <48771572-B013-4E20-98C3-C475B3A22E92@magma.ca> From: Philip Matthews To: Behave WG In-Reply-To: <4975B691.2040009@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 9 Feb 2009 20:39:59 -0500 References: <4975B691.2040009@it.uc3m.es> X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 01:39:59 -0000 [Catching up on a backlog of NAT64-related e-mails...] Personally, I don't think we are going to make referrals work, for a variety of reasons. One of the main things we have learned from the whole STUN/TURN/ICE development process is that, in the presence of NATs, a node does not have just one IP address, but multiple IP addresses: one of these address may work from one location and a different address may work from a different location. Furthermore, it is almost impossible to provide an easy rule to predict which address will work from which location (We tried creating easy rules with the first version of STUN (as described in RFC 3489), but it proved unreliable and thus ICE was invented). This is the reason why an ICE endpoint gathers all the addresses ("candidates") it can find and sends them all to the other endpoint, and then all pair-wise combinations are tried. Furthermore, as Dan has pointed out, almost all NATs today have filtering rules that prevent packets from the "outside" from passing through the NAT unless a packet from the "inside" has previously been sent out. Dan has suggested that NAT64s could implement "endpoint- independent filtering", but I think this is very unlikely since by far the most common rule today is some form of "endpoint-dependent filtering" For these reasons, the only reliable way to do a referral is to pass some sort of symbolic name for the referred-to node, and use some form of rendezvous server to establish a direct connection. In the terms used by Marcelo below, Node A passes to Node C a symbolic name for Node B, and then Node C contacts a rendezvous server and uses ICE to establish a direct connection with node B. Which rendezvous server node C uses depends on the context. It may be that Node A can act as the rendezvous server -- this is the technique being used in the P2PSIP working group to add a peer to a peer-to-peer network. It may also be that there is some generic rendezvous server --- the HIP group has done some investigations along this line. Thus I think we should drop the referral criterion when considering the nature of the Pref64. - Philip On Tue, 20-Jan-09, at 06:33 , marcelo bagnulo braun wrote: > The topic of this mail is the impact of the prefix type selected for > representing the IPv4 addresses in the IPv6 Internet (from now > called Pref64::/N) in the referral operations. > > A referral operation is when a host A passes the IP address of a > Host B to a third Host C as application data. The host Host C will > then initiate a communication towards the Host B using the IP > address received. I understand this is not a rare operation in VoIP > type of applications, but Dan will correct me if this is just a IP > area legend (that, by the way, is used, sometimes, as an argument to > build overly complex solutions :-) > > There are several referrals scenarios as described in this table: > > | Host A | Host B | Host C | > --------------------------------------- > Scenario 1 | v6 | v6 | v4 | > --------------------------------------- > Scenario 2 | v6 | v4 | v6 | > --------------------------------------- > Scenario 3 | v4 | v6 | v6 | > --------------------------------------- > Scenario 4 | v6 | v4 | v4 | > --------------------------------------- > Scenario 5 | v4 | v6 | v4 | > --------------------------------------- > Scenario 6 | v4 | v4 | v6 | > --------------------------------------- > > Now, all the scenarios where Host A and Host C are in different IP > version, they require a specific ALG, since the IP address > information contained as application data must be translated, in > order to be meaningful a the receiver (these are scenarios 1, 3, 4 > and 6). > > OTOH, scenarios 2 and 5 could work without ALG. > > In addition, scenarios 1 and 5 where Host C is IPv4 and Host B is > IPv6 will need some form of static NAT configuration (either the > stateless mode of IVI or the manual configuration of bindings) to > work cause they imply an IPv4 node initiating a communication > towards and IPv6 node. > > > So, let's consider the scenario 2, which should work in the dynamic > binding case without ALGs first: > > **Scenario 2 is as follows > > > +-----------------------------------------+ > | IPv4 Internet | > | +--------+ | > | | Host B | | > | | IPB | | > | +--------+ | > +-----------------------------------------+ > | | > | | > +--|----------------------------------|---+ > |+-|--------+ +-------+ +--------|--+| > || Pref64_1 | | | | Pref64_2 || > || | | | | || > || +------+ | | | | +-------+ || > || |Host A| |----| |---| |Host C | || > || +------+ | | | | +-------+ || > || Site1 | +-------+ | Site2 || > |+----------+ +-----------+| > | | > | IPv6 Internet | > +-----------------------------------------+ > > So, in this case, Host A will be sending Host B's address to Host C > as application data. > Now, in the eyes of Host A, Host B's address is Pref64_1:IPB:suffix > (the suffix is optional, depending whether Pref64_1 is 96 bit long > or shorter. > > Host C will receive then Pref64_1:IPB:suffix and will try to > initiate a communication toward host B using that address. > > We now have two options depending if the prefix Pref64_1 is a single > well known prefix or is allocated from the site's address block. > > - Case where the Pref64_1 is allocated from the site's address block > (FWIW this what all drafts do as currently described) > Host C sends a packet towards Pref64_1:IPB:suffix. > The packet is routed towards Site 1 since Pref64_1 is part of site's > 1 address block. > Now Site 1 has 3 options, as discussed yesterday with Xing. Either > forwards the packet to the IPv4 internet or drops it (it can drop it > at the ingress or in the translator box). Now, as i understand it, > it doens't make economical sense for site 1 to forward the packet > towards the v4 internet, cause if it did so, it would be providing > free v6 to v4 transit. So, as i understand it, it makes sense for > site 1 to drop the packet (which is what i understand CERNET does > (in their case it is a bit more complicated, cause they also have a > the IVI addresses that they handle differently, but i think this > applies in their case as well, modulo those addresses)) > > Now, if site1 drops packets addressed to Pref64_1 coming from the > outside, referrals break. > > - Case where the Pref64_1 is a single well know prefix. > In this case Pref64_1=Pref64_2=Pref64 > So, HostA sends Pref64:IPB_suffix to Host C > Host C now sends a packet to Pref64:IPB:suffix. > In this case, the packet will flow through whatever route Site2 has > to connect to the IPv4 Internet. In our scheme, site2 has its own > translator, that then would announce a route towards Pref64, so the > packet will flow through the direct route Site2 has to the IPv4 > Internet. > > So, from this analysis, it seems that in this case, referrals would > work if a single well know prefix is used. > > > So, let's think a bit about the scenarios that require al ALG next. > > > ** Scenarios 1, 3, 4 and 6 > > A general observation about these scenarios is that in the case a > single well know prefix is used, it would be possible for the ALG to > identify the IPv6 addresses containing an embedded IPv4 address > and translate it, cause they could identify the well know prefix and > know that are not general use IPv6 addresses. If the Pref64 is taken > from the site's address block, it may be possible for the ALG to > translate the address in the referral, as long as the translator is > configured to know that this specific prefix is unsed to map IPv4 > addresses. This basically implies that the translator must be in > Site1 in the figure above, i.e. the site of the host sending the > referral information. > > So, we can say that a single well known prefix is more likely to > work with referral in the case that ALG is needed than the case of > the prefix taken from the site's address block. > > *** So, we have scenario 5 to go > > Host A is v4, host B is v6 and host C is v4 > > In this case, we need a representation of Host B in the v4 world. In > this case, the Pref64 seems hardly relevant. > > So, i think it is reasonable to say that a single well know prefix > would result in better referral support. > I wonder if this cannot be generalized for other applications. I > mean after all the better support is simply due to the fact that > using a single well know prefix results in a unique representation > of the v4 addresses in v6 land, and allows to identify that > irrespectivly where the translation is performed, the result is the > same in terms of the address. > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From philip_matthews@magma.ca Mon Feb 9 17:40:34 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20A4B3A6BCE for ; Mon, 9 Feb 2009 17:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.162, 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 8vaJdcQLunPG for ; Mon, 9 Feb 2009 17:40:30 -0800 (PST) Received: from mail-06.primus.ca (mail5.primus.ca [216.254.141.172]) by core3.amsl.com (Postfix) with ESMTP id 348A93A6919 for ; Mon, 9 Feb 2009 17:40:30 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1LWhby-0005Fz-0T for behave@ietf.org; Mon, 09 Feb 2009 20:40:32 -0500 Message-Id: <130D5FEE-1C74-4740-8467-062682960BA2@magma.ca> From: Philip Matthews To: Behave WG Content-Type: multipart/alternative; boundary=Apple-Mail-1-372276958 Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 9 Feb 2009 20:40:30 -0500 X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] Subject: [BEHAVE] TURN: Clarifications around nonce usage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 01:40:34 -0000 --Apple-Mail-1-372276958 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Brian Carpenter, in his Gen-ART review of TURN, asked: >>> 17.1.5. Impersonating a Server >> ... >>> This attack is prevented through the digest authentication >> mechanism, >>> which provides message integrity for responses in addition to >>> verifying that they came from the server. >> >> I'm no expert, but is this subject to the sort of vulnerability >> discussed in RFC4169, if an attacker has observed previous traffic >> and is capable of spoofing the server's IP address? After some private e-mail discussions, it seems that the attack that Brian mentioned is mitigated by choosing the nonce value appropriately and rotating it frequently. However, Brian's comment caused us to realize that there is no explicit text about this in the TURN document (there is some discussion of this in the STUN spec, but it is pretty general). Dan Wing suggested adding some specific recommendations on this point. His proposal, slightly modified by me, is to add the following to section 4 in the paragraph that discusses the use of STUN's Long-Term Credential mechanism: For each allocation, the server SHOULD generate a new random nonce when the allocation is first attempted following the randomness recommendations in [RFC4086] and SHOULD expire the nonce at least once every hour during the lifetime of the allocation. I am proposing to put these requirements at the SHOULD level since they do not affect interoperability, since this is being added rather late in the process, and since the choice of "at least once every hour" is somewhat arbitrary and is based more on what seems right rather than hard evidence. Comments? - Philip --Apple-Mail-1-372276958 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Brian Carpenter, in his = Gen-ART review of TURN, asked:

17.1.5.  Impersonating = a Server
...
  This attack is = prevented through the digest = authentication
mechanism,
  which provides = message integrity for responses in addition = to
  verifying that = they came from the = server.

I'm no expert, but is this subject to the sort of = vulnerability
discussed in RFC4169, if an attacker has observed = previous traffic
and is capable of spoofing the server's IP = address?

After some = private e-mail discussions, it seems that the attack that Brian = mentioned is mitigated by choosing the nonce value appropriately and = rotating it frequently. However, Brian's comment caused us to realize = that there is no explicit text about this in the TURN document (there is = some discussion of this in the STUN spec, but it is pretty = general). 

Dan Wing suggested adding some = specific recommendations on this point. His proposal, slightly modified = by me, is to add the following to section 4 in the paragraph that = discusses the use of STUN's Long-Term Credential = mechanism:

    For each = allocation, the server SHOULD generate a new random = nonce 
    when the allocation is first = attempted following the randomness
   =  recommendations in [RFC4086] and SHOULD expire the nonce at = least
    once every hour during the lifetime = of the allocation.

I am proposing to put these = requirements at the SHOULD level since they do not affect = interoperability, since this is being added rather late in the process, = and since the choice of "at least once every hour" is somewhat arbitrary = and is based more on what seems right rather than hard = evidence.

Comments?

- = Philip
= --Apple-Mail-1-372276958-- From xing@cernet.edu.cn Mon Feb 9 23:39:40 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A05E93A6897 for ; Mon, 9 Feb 2009 23:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696] 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 ZUwUyE4yQc7W for ; Mon, 9 Feb 2009 23:39:40 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 6870028C15D for ; Mon, 9 Feb 2009 23:39:38 -0800 (PST) Received: from [127.0.0.1]([119.41.129.28]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm7499153c2; Tue, 10 Feb 2009 15:39:39 +0800 Message-ID: <49912F37.6030608@cernet.edu.cn> Date: Tue, 10 Feb 2009 15:39:35 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Behave WG References: <4975B691.2040009@it.uc3m.es> <48771572-B013-4E20-98C3-C475B3A22E92@magma.ca> In-Reply-To: <48771572-B013-4E20-98C3-C475B3A22E92@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: p97Nn6VB Subject: [BEHAVE] (no subject) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 07:39:40 -0000 Hi, All, We have uploaded a new version of "IP/ICMP Translation Algorithm", please comment. Thanks. http://www.ietf.org/internet-drafts/draft-baker-behave-v4v6-translation-01.txt xing From xing@cernet.edu.cn Mon Feb 9 23:55:09 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E6983A68FD for ; Mon, 9 Feb 2009 23:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696] 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 dIgeBegov7TA for ; Mon, 9 Feb 2009 23:55:08 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id DA2E23A684B for ; Mon, 9 Feb 2009 23:55:07 -0800 (PST) Received: from [127.0.0.1]([119.41.129.28]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm1d49915763; Tue, 10 Feb 2009 15:55:09 +0800 Message-ID: <499132DC.2000309@cernet.edu.cn> Date: Tue, 10 Feb 2009 15:55:08 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: pq72n6VB Subject: [BEHAVE] IP/ICMP Translation Algorithm version 01 uploaded X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 07:55:09 -0000 Hi, All, We have uploaded a new version of "IP/ICMP Translation Algorithm", please comment. Thanks. http://www.ietf.org/internet-drafts/draft-baker-behave-v4v6-translation-01.txt xing From marcelo@it.uc3m.es Tue Feb 10 01:13:37 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A49583A6A5C for ; Tue, 10 Feb 2009 01:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.442 X-Spam-Level: X-Spam-Status: No, score=-5.442 tagged_above=-999 required=5 tests=[AWL=1.157, 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 YcOGKHN5rjUy for ; Tue, 10 Feb 2009 01:13:36 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id C8D3D3A699D for ; Tue, 10 Feb 2009 01:13:35 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (146.pool85-53-135.dynamic.orange.es [85.53.135.146]) by smtp02.uc3m.es (Postfix) with ESMTP id E84666B9E74; Tue, 10 Feb 2009 10:13:33 +0100 (CET) Message-ID: <4991453D.7020900@it.uc3m.es> Date: Tue, 10 Feb 2009 10:13:33 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Philip Matthews References: <4975B691.2040009@it.uc3m.es> <48771572-B013-4E20-98C3-C475B3A22E92@magma.ca> In-Reply-To: <48771572-B013-4E20-98C3-C475B3A22E92@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16454.006 Cc: Behave WG Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 09:13:37 -0000 Philip Matthews escribió: > [Catching up on a backlog of NAT64-related e-mails...] > > Personally, I don't think we are going to make referrals work, for a > variety of reasons. > > One of the main things we have learned from the whole STUN/TURN/ICE > development process is that, in the presence of NATs, a node does not > have just one IP address, but multiple IP addresses: one of these > address may work from one location and a different address may work > from a different location. I understand that what you are saying i correct for IPv4 NATs, but it dones' have to be for NAT64, in the following sense. In IPv4 NATs, it is clear that the binding between the public transport address and the private transport address has a very limited lifetime. SO, the public transport address is clearly not a stable name, that can can hardly be used for referrals. Now, in NAT64 this will certainly be the case when you use an IPv4 address for the referral, since the binding between the general IPv6 address and the public IPv4 address will have the same limited lifetime. However, i don't applies to the IPv6 addresses that represent IPv4 addresses, since the binding is automatically created, hence it does not longer has this limited lifetime nature. I mean, if an app uses an IPv4 address that has been assigned by a NAT a couple of hours later, it is likely that the binding will not exsit, and hence the referral won't work. If an app uses an IPv6 address representing an IPv4 address a couple of hours later, if the binding does not exsits, it can be created again, and the referal will work. So, it is my take that the analogy with the IPv4 case does not applies here (With this automatic binding creation we get rid of the time dependency and the argument for using the well known prefix is that we get rid of the topological dependency) > Furthermore, it is almost impossible to provide an easy rule to > predict which address will work from which location (We tried creating > easy rules with the first version of STUN (as described in RFC 3489), > but it proved unreliable and thus ICE was invented). This is the > reason why an ICE endpoint gathers all the addresses ("candidates") it > can find and sends them all to the other endpoint, and then all > pair-wise combinations are tried. > > Furthermore, as Dan has pointed out, almost all NATs today have > filtering rules that prevent packets from the "outside" from passing > through the NAT unless a packet from the "inside" has previously been > sent out. Dan has suggested that NAT64s could implement > "endpoint-independent filtering", but I think this is very unlikely > since by far the most common rule today is some form of > "endpoint-dependent filtering" > First, i think that the main reasons why referals don't work is cause the binding have expired rather than cause they are filtered. Second, one thing is to administratively fliter referals and anohter compeltelly different is to design a solution that simply is much less likely to make them work. In the first case we can disable the filter if we want in the second case, we need to change the technology > For these reasons, the only reliable way to do a referral is to pass > some sort of symbolic name for the referred-to node, and use some form > of rendezvous server to establish a direct connection. In the terms > used by Marcelo below, Node A passes to Node C a symbolic name for > Node B, and then Node C contacts a rendezvous server and uses ICE to > establish a direct connection with node B. > exactly, the name could be the IPv6 address that represents the IPv4 address usingt he well know prefix, since it will be a universal representation of the IPv4 address in IPv6 land Regards, marcelo > Which rendezvous server node C uses depends on the context. It may be > that Node A can act as the rendezvous server -- this is the technique > being used in the P2PSIP working group to add a peer to a peer-to-peer > network. It may also be that there is some generic rendezvous server > --- the HIP group has done some investigations along this line. > > Thus I think we should drop the referral criterion when considering > the nature of the Pref64. > > - Philip > > > > On Tue, 20-Jan-09, at 06:33 , marcelo bagnulo braun wrote: > >> The topic of this mail is the impact of the prefix type selected for >> representing the IPv4 addresses in the IPv6 Internet (from now called >> Pref64::/N) in the referral operations. >> >> A referral operation is when a host A passes the IP address of a Host >> B to a third Host C as application data. The host Host C will then >> initiate a communication towards the Host B using the IP address >> received. I understand this is not a rare operation in VoIP type of >> applications, but Dan will correct me if this is just a IP area >> legend (that, by the way, is used, sometimes, as an argument to build >> overly complex solutions :-) >> >> There are several referrals scenarios as described in this table: >> >> | Host A | Host B | Host C | >> --------------------------------------- >> Scenario 1 | v6 | v6 | v4 | >> --------------------------------------- >> Scenario 2 | v6 | v4 | v6 | >> --------------------------------------- >> Scenario 3 | v4 | v6 | v6 | >> --------------------------------------- >> Scenario 4 | v6 | v4 | v4 | >> --------------------------------------- >> Scenario 5 | v4 | v6 | v4 | >> --------------------------------------- >> Scenario 6 | v4 | v4 | v6 | >> --------------------------------------- >> >> Now, all the scenarios where Host A and Host C are in different IP >> version, they require a specific ALG, since the IP address >> information contained as application data must be translated, in >> order to be meaningful a the receiver (these are scenarios 1, 3, 4 >> and 6). >> >> OTOH, scenarios 2 and 5 could work without ALG. >> >> In addition, scenarios 1 and 5 where Host C is IPv4 and Host B is >> IPv6 will need some form of static NAT configuration (either the >> stateless mode of IVI or the manual configuration of bindings) to >> work cause they imply an IPv4 node initiating a communication towards >> and IPv6 node. >> >> >> So, let's consider the scenario 2, which should work in the dynamic >> binding case without ALGs first: >> >> **Scenario 2 is as follows >> >> >> +-----------------------------------------+ >> | IPv4 Internet | >> | +--------+ | >> | | Host B | | >> | | IPB | | >> | +--------+ | >> +-----------------------------------------+ >> | | >> | | >> +--|----------------------------------|---+ >> |+-|--------+ +-------+ +--------|--+| >> || Pref64_1 | | | | Pref64_2 || >> || | | | | || >> || +------+ | | | | +-------+ || >> || |Host A| |----| |---| |Host C | || >> || +------+ | | | | +-------+ || >> || Site1 | +-------+ | Site2 || >> |+----------+ +-----------+| >> | | >> | IPv6 Internet | >> +-----------------------------------------+ >> >> So, in this case, Host A will be sending Host B's address to Host C >> as application data. >> Now, in the eyes of Host A, Host B's address is Pref64_1:IPB:suffix >> (the suffix is optional, depending whether Pref64_1 is 96 bit long or >> shorter. >> >> Host C will receive then Pref64_1:IPB:suffix and will try to initiate >> a communication toward host B using that address. >> >> We now have two options depending if the prefix Pref64_1 is a single >> well known prefix or is allocated from the site's address block. >> >> - Case where the Pref64_1 is allocated from the site's address block >> (FWIW this what all drafts do as currently described) >> Host C sends a packet towards Pref64_1:IPB:suffix. >> The packet is routed towards Site 1 since Pref64_1 is part of site's >> 1 address block. >> Now Site 1 has 3 options, as discussed yesterday with Xing. Either >> forwards the packet to the IPv4 internet or drops it (it can drop it >> at the ingress or in the translator box). Now, as i understand it, it >> doens't make economical sense for site 1 to forward the packet >> towards the v4 internet, cause if it did so, it would be providing >> free v6 to v4 transit. So, as i understand it, it makes sense for >> site 1 to drop the packet (which is what i understand CERNET does (in >> their case it is a bit more complicated, cause they also have a the >> IVI addresses that they handle differently, but i think this applies >> in their case as well, modulo those addresses)) >> >> Now, if site1 drops packets addressed to Pref64_1 coming from the >> outside, referrals break. >> >> - Case where the Pref64_1 is a single well know prefix. >> In this case Pref64_1=Pref64_2=Pref64 >> So, HostA sends Pref64:IPB_suffix to Host C >> Host C now sends a packet to Pref64:IPB:suffix. >> In this case, the packet will flow through whatever route Site2 has >> to connect to the IPv4 Internet. In our scheme, site2 has its own >> translator, that then would announce a route towards Pref64, so the >> packet will flow through the direct route Site2 has to the IPv4 >> Internet. >> >> So, from this analysis, it seems that in this case, referrals would >> work if a single well know prefix is used. >> >> >> So, let's think a bit about the scenarios that require al ALG next. >> >> >> ** Scenarios 1, 3, 4 and 6 >> >> A general observation about these scenarios is that in the case a >> single well know prefix is used, it would be possible for the ALG to >> identify the IPv6 addresses containing an embedded IPv4 address and >> translate it, cause they could identify the well know prefix and know >> that are not general use IPv6 addresses. If the Pref64 is taken from >> the site's address block, it may be possible for the ALG to translate >> the address in the referral, as long as the translator is configured >> to know that this specific prefix is unsed to map IPv4 addresses. >> This basically implies that the translator must be in Site1 in the >> figure above, i.e. the site of the host sending the referral >> information. >> >> So, we can say that a single well known prefix is more likely to work >> with referral in the case that ALG is needed than the case of the >> prefix taken from the site's address block. >> >> *** So, we have scenario 5 to go >> >> Host A is v4, host B is v6 and host C is v4 >> >> In this case, we need a representation of Host B in the v4 world. In >> this case, the Pref64 seems hardly relevant. >> >> So, i think it is reasonable to say that a single well know prefix >> would result in better referral support. >> I wonder if this cannot be generalized for other applications. I mean >> after all the better support is simply due to the fact that using a >> single well know prefix results in a unique representation of the v4 >> addresses in v6 land, and allows to identify that irrespectivly where >> the translation is performed, the result is the same in terms of the >> address. >> >> _______________________________________________ >> 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 vincent@clarinet.u-strasbg.fr Tue Feb 10 01:56:08 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35C9428C1A1 for ; Tue, 10 Feb 2009 01:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 cM-ZSAhvzGZY for ; Tue, 10 Feb 2009 01:55:48 -0800 (PST) Received: from mailhost.u-strasbg.fr (mailhost.u-strasbg.fr [130.79.200.156]) by core3.amsl.com (Postfix) with ESMTP id F31FD3A6BEB for ; Tue, 10 Feb 2009 01:55:47 -0800 (PST) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.91.200]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id n1A9sTrE070158 ; Tue, 10 Feb 2009 10:54:29 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 2AF418E8D72; Tue, 10 Feb 2009 10:54:29 +0100 (CET) Received: from clarinet.u-strasbg.fr ([127.0.0.1]) by localhost (clarinet.u-strasbg.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ic8VjCAJj-VG; Tue, 10 Feb 2009 10:54:28 +0100 (CET) Received: from [130.79.91.216] (kitchenet.u-strasbg.fr [130.79.91.216]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: vincent) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 61EB78E8D63; Tue, 10 Feb 2009 10:54:28 +0100 (CET) Message-ID: <49914ECC.9010503@clarinet.u-strasbg.fr> Date: Tue, 10 Feb 2009 10:54:20 +0100 From: Sebastien Vincent User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Dan Wing References: <04b401c98b18$25c5dd50$c2f0200a@cisco.com> In-Reply-To: <04b401c98b18$25c5dd50$c2f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mailhost.u-strasbg.fr [130.79.200.156]); Tue, 10 Feb 2009 10:54:30 +0100 (CET) X-Virus-Scanned: ClamAV 0.94.2/8970/Tue Feb 10 03:52:04 2009 on mr6.u-strasbg.fr X-Virus-Status: Clean Cc: draft-ietf-behave-turn-tcp@tools.ietf.org, Behave WG , BEHAVE Chairs Subject: Re: [BEHAVE] TURN-TCP status X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 09:56:08 -0000 Dan Wing a écrit : > The working group needs a new primary editor/author for turn-tcp. > > Philip Matthews, who has helped with TURN, does not have sufficient time > to work on TURN-TCP. Rohan, the other co-author, also said he has > insufficient time. That would leave Jonathan as the sole author > and unfortunately he is stretched too thin. > > Our current milestone is March 2009 to submit the document to IESG but > we won't make that date. TURN-TCP's model is similar to TURN (with a > separate separate TCP connection per peer) which is expected to work > well with a mix of slow and fast TCP peers. > > The document still needs a significant amount of work, including: > > * describe the TURN server behavior > * finish description of TURN client behavior > * IAB considerations section, including why TURN-TCP is necessary > (versus SOCKS or other already-defined approaches) > * Security considerations > > > Related to TURN-TCP is ICE-TCP. Namely, if ICE-TCP can successfully > establish a peer-to-peer TCP connection then TURN-TCP is unnecessary. > However, research [1] indicates that the techniques considered by > ICE-TCP will be successful approximately 80% of the time in establishing > a direct peer-to-peer connection. The other 20% will simply fail, > need to utilize a TURN-TCP relay, or use UDP (with the potential > to lose TCP friendliness). There is a suggestion that ICE-TCP > should encourage additional candidate gathering (Teredo, UPnP IGD, > SOCKS) [2] which will help ICE-TCP establish direct peer-to-peer > TCP connections, but the amount of improvement is not yet known. > > > Is anyone planning to implement TURN-TCP client? TURN-TCP server? > Or should we abandon TURN-TCP due to lack of need? > I plan to implement TURN-TCP in TurnServer (http://www.turnserver.org/) if any. -- Sebastien Vincent > And the $64 million question: if you can volunteer to take over > editing TURN-TCP, please drop the chairs an email. Or should we > abandon TURN-TCP due to lack of editor? > > -d > > [1] http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat/ > [2] http://tools.ietf.org/html/draft-lowekamp-mmusic-ice-tcp-framework-00 > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From Remi.Denis-Courmont@nokia.com Tue Feb 10 03:45:26 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F03A3A6B31 for ; Tue, 10 Feb 2009 03:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.238 X-Spam-Level: X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 0Ck9XYjdF42t for ; Tue, 10 Feb 2009 03:45:25 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 4A01A3A6A05 for ; Tue, 10 Feb 2009 03:45:25 -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 n1ABiwW2008023; Tue, 10 Feb 2009 05:45:13 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Feb 2009 13:45:06 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Feb 2009 13:45:06 +0200 Received: from leon.remlab.net (esdhcp041160.research.nokia.com [172.21.41.160]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id n1ABj47s026252; Tue, 10 Feb 2009 13:45:04 +0200 From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Maemo Software - Nokia Devices R&D To: behave@ietf.org Date: Tue, 10 Feb 2009 13:45:04 +0200 User-Agent: KMail/1.10.3 (Linux/2.6.27.15; KDE/4.1.3; i686; ; ) References: <04b401c98b18$25c5dd50$c2f0200a@cisco.com> <49914ECC.9010503@clarinet.u-strasbg.fr> In-Reply-To: <49914ECC.9010503@clarinet.u-strasbg.fr> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200902101345.05304.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 10 Feb 2009 11:45:06.0145 (UTC) FILETIME=[049AAD10:01C98B75] X-Nokia-AV: Clean Cc: ext Sebastien Vincent , "draft-ietf-behave-turn-tcp@tools.ietf.org" , Dan Wing Subject: Re: [BEHAVE] TURN-TCP status X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 11:45:26 -0000 On Tuesday 10 February 2009 11:54:20 ext Sebastien Vincent, you wrote: > > Is anyone planning to implement TURN-TCP client? TURN-TCP server? > > Or should we abandon TURN-TCP due to lack of need? > > I plan to implement TURN-TCP in TurnServer (http://www.turnserver.org/) > if any. No offense intended, but this is "just" a university software project. I th= ink=20 it's great that we have motivated students doing implementations of IETF=20 protocols. On top of that, your implementation is not just a reference; you= =20 seem clearly focused on performance and security (I did that sort of things= =20 too when I was a little younger). I think other people on this=20 list are also intending to implement TURN servers, and likely TURN client=20 libraries. *But*, that does not mean it is going to be deployed/used to any= =20 meaningful extent. It does not even mean that a real application is intendi= ng=20 to use it. Compared to TURN-UDP, TURN-TCP has some additionnal challenges. For low=20 bandwidth TCP use cases, such as instant messaging, there is no need for=20 relays. Data cab go inband all the time. This is also simpler. In other wor= ds,=20 TCP is for bulk (bandwidth-heavy) transfers rather than real-time bandwidth- limited media (SIP, XMPP, RTSP, etc). TCP NAT traversal needs a relay in mo= re=20 cases than UDP NAT traversal, which further aggravates the bandwidth proble= m.=20 Last, ICE-TCP would be much more complicated to implement than ICE-UDP, whi= ch=20 is itself not quite simple; this is just another roadblock. Between ALG-based (SBCs) in the "telco" track, and UDP encapsulation (such = as=20 Teredo) in the "net" track, and the pre-existing SOCKS in the "corporate"=20 track, there is little room for TURN-TCP. If only file transfer of SIP actually did "work", there would be demand for= =20 TURN-TCP. But even MSRP, if it ever works, has gone a different way (MSRP=20 relays and now SBCs). Truth is that we have no real use case for COMEDIA in= =20 SIP, and hence no use case for TURN-TCP either. If it were up to me, I woul= d=20 ditch MSRP, specify file transfer directly over COMEDIA (one file =3D one S= IP=20 session), and then maybe specify TURN-TCP. Not happening though. I would say we should first understand what (if any) are the use cases. =2D-=20 R=E9mi Denis-Courmont Maemo Software, Nokia Devices R&D From simon.perreault@viagenie.ca Tue Feb 10 05:38:11 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2A6F3A6B51 for ; Tue, 10 Feb 2009 05:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, NO_RELAYS=-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 JW3Z37PCcLMn for ; Tue, 10 Feb 2009 05:38:08 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id CFEFE3A6B76 for ; Tue, 10 Feb 2009 05:38:07 -0800 (PST) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 3C51A14A0002; Tue, 10 Feb 2009 08:38:10 -0500 (EST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 3256714A0001; Tue, 10 Feb 2009 08:38:10 -0500 (EST) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: behave@ietf.org Date: Tue, 10 Feb 2009 08:38:09 -0500 User-Agent: KMail/1.10.4 (Linux/2.6.27.12-170.2.5.fc10.x86_64; KDE/4.1.4; x86_64; ; ) References: <04b401c98b18$25c5dd50$c2f0200a@cisco.com> <49914ECC.9010503@clarinet.u-strasbg.fr> <200902101345.05304.remi.denis-courmont@nokia.com> In-Reply-To: <200902101345.05304.remi.denis-courmont@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200902100838.10011.simon.perreault@viagenie.ca> Cc: ext Sebastien Vincent , "draft-ietf-behave-turn-tcp@tools.ietf.org" , Dan Wing Subject: Re: [BEHAVE] TURN-TCP status X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 13:38:12 -0000 On Tuesday 10 February 2009 06:45:04 R=E9mi Denis-Courmont wrote: > I would say we should first understand what (if any) are the use cases. I suppose multi-player games use TCP for communication, and I suppose they= =20 would benefit from ICE. I'm just guessing here, I have no experience in tha= t=20 field...=20 =2D-=20 Please try Numb, a STUN/TURN server implementation. =46ree access at http://numb.viagenie.ca/. From marc.blanchet@viagenie.ca Tue Feb 10 05:45:18 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FD0228C1BA for ; Tue, 10 Feb 2009 05:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, 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 REO5oaDRMaSh for ; Tue, 10 Feb 2009 05:45:17 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 8337328C1B8 for ; Tue, 10 Feb 2009 05:45:17 -0800 (PST) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 7B9DA14A0005; Tue, 10 Feb 2009 08:45:20 -0500 (EST) Received: from h103.viagenie.ca (h103.viagenie.ca [206.123.31.103]) by jazz.viagenie.ca (Postfix) with ESMTP id 6FE4514A0001; Tue, 10 Feb 2009 08:45:20 -0500 (EST) Message-ID: <499184EF.8070105@viagenie.ca> Date: Tue, 10 Feb 2009 08:45:19 -0500 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= References: <04b401c98b18$25c5dd50$c2f0200a@cisco.com> <49914ECC.9010503@clarinet.u-strasbg.fr> <200902101345.05304.remi.denis-courmont@nokia.com> In-Reply-To: <200902101345.05304.remi.denis-courmont@nokia.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: ext Sebastien Vincent , "draft-ietf-behave-turn-tcp@tools.ietf.org" , behave@ietf.org, Dan Wing Subject: Re: [BEHAVE] TURN-TCP status X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 13:45:18 -0000 Rémi Denis-Courmont a écrit : > > I would say we should first understand what (if any) are the use cases. > in several typical firewall configurations, udp is not permitted to pass through (except port 53) while tcp is more opened to pass through. (for good or bad reasons). therefore, for an application where tcp would be ok for transport, then tcp is a better choice than udp. Marc. -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca From marcelo@it.uc3m.es Thu Feb 12 08:23:25 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39B9328C11C for ; Thu, 12 Feb 2009 08:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_TOOL=2.3, 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 aXjELQQkmIdH for ; Thu, 12 Feb 2009 08:23:23 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 2894A28C21B for ; Thu, 12 Feb 2009 08:23:22 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (225.pool85-53-139.dynamic.orange.es [85.53.139.225]) by smtp01.uc3m.es (Postfix) with ESMTP id BC0EAB9FDFC; Thu, 12 Feb 2009 17:23:24 +0100 (CET) Message-ID: <49944CFC.20001@it.uc3m.es> Date: Thu, 12 Feb 2009 17:23:24 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Matthijs Mekking References: <492D7AB0.2010306@nlnetlabs.nl> In-Reply-To: <492D7AB0.2010306@nlnetlabs.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16458.007 Cc: behave@ietf.org Subject: Re: [BEHAVE] dns64 review X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 16:23:25 -0000 Hi Matthijs, thank you very much for your thorough review. some replies below... Matthijs Mekking escribió: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Upon request, I have looked at the draft-bagnulo-behave-{dns,nat}64. I > have found some nits and some feedback primarly on the DNS64 algorithm > with respect to DNSSEC. Since, I did not follow this from the beginning, > I might repeat some issues that were raised in the past. If so, I would > be grateful if someone gave me a pointer. > > First of all, some general comments/questions about the nat64 document. > > - - On page 4, in section 1.2, it is stated that in order to perform IPv6 > to IPv4 translation, NAT64 requires state. Is there any analysis of its > scalability? > I understand that this would have the same scalability properties than a IPv4 NAT, which also holds state per flow. Do you see the scalability issues being worse in nat64 than in normal IPv4 nat? > - - Somewhere round page 8, I was wondering if it is required for DNS64 to > be dual stack. If it does not do IPv4, how would it otherwise contact > the authoritative nameserver in the IPv4-only network? > > I understand that the protocol used for transport and the type of RR obtained are orthogonal. I mean, a resolver can retrieve AAAA RR over IPv4 and retrieve A RR over IPv6, right? We haven't mentioned anything about the version used for the transport of the RR information cause we ddin't see any special issue with this.... do you have some concrete issue that you think needs to be mentioned and addressed? > - - On page 8, in step 2: Shouldn't the ports be chosen by the source > node, in this case H1? > right > - - Page 9, step 6. The translated packet is sent out the IPv6 interface > to H2. Shouldn't that be H1? > > > right > > > > That was it with respect to NAT64. DNS64 next. > - - Personally, I think putting the DNS64 functionality in the end hosts > is a cleaner solution. You don't need to worry about breaking the DNSSEC > at the end-host, since synthesizing occurs after validation. But since > it requires upgrading all end-hosts in the IPv6-only network, and this > is against the requirements for NAT64, a different solution should be > adapted. > agree > - - I don't understand the situation in section 1.2.3. Are you suggesting > that after receiving a dynamic update, the authoritative name server > should store synthesized AAAA records? upon the reception of a dynamic update, the authoritaive server will create a A RR, right? At the same time, the authoritive server could create an AAAA RR and publish it along the new A RR, would that make sense? (the IPv6 address would be the IPv6 represenation of the IPv4 address contained in the A RR) > Isn't it possible for other IPv6 > networks to contact the authoritative DNS64 name server? I don't understnad this question, could you expand? > If so, should > it configure all possible IPv6 prefixes in order to synthesize AAAA > records for different IPv6 networks? but the prefix used is the prefix being used to represent IPv4 addresses in the IPv6 address space. There is still an open disucssion whether this will be a single well knwon prefix or will be a prefix out fo the site's address space, but in any case, the site must have a prefix used for this i.e. representing v4 addresses in v6 land. It may be possible that more than one prefix is used for this (i.e. if we want to assign different prefixes to different NAT64 boxes) In that case, multiple AAAA RR should be published, one pre prefix. Not clear to me how common would this be, but as i said we should wrap up the prefix disucssion before figuring out what prefix to include here > This section leaves me filled with > questions. > > - - The second option, generating the synthesized AAAA records upon a > query seems a bad idea. This means that in order to allow the recursive > nameserver on the other side to do validation, the authoritative name > server should not only generate synthesized AAAA records, but also > create new signatures for the AAAA RRset and adjust the NSEC bitmap > values. This will increase the load on the authoritative nameserver and > the time window on the resolver. Creating signatures on the fly is > something that should be avoided in the DNS, imho. I prefer this > proposal not to be mentioned at all, instead of tagging it not > recommended but possible. > i agree with that, but some other people express their interest on this. I may leave this for one more version, to gather more feedback > - - Should synthesized records be cached? RFC 2672 introduced the DNAME > record, including synthesized CNAME records. It defines that the TTL of > the synthesized record MUST be set to 0. However, the RFC is under > revision and the new text tells us to keep the CNAME RR as long as > needed, so it should be equal to the DNAME TTL. This allows non-aware > clients to cache the CNAMEs and thus lightens the load on authoritative > servers. I think a similar approach is possible for synthesized AAAA RRs. > > I have changed to the TTL of the original A RR, would that make sense to you? > - - We had some discussion on the Jabber during the behave meeting and at > our office, how resolvers should handle synthesized AAAA RRs with > respect to DNSSEC. Synthesizing and DNSSEC can go along, just like with > DNAME/CNAME. > right the new versio of the draft includes two ways of handling DNSSEC, the old one and the new one DNAME/CNAME style. It is open for disucssion which way to go, please read the next versio fo the draft ad speak your mind on which one you preffer > Two problems came to mind with the current solution, in the case the > end-host is transition-oblivious (no DNS64 implemented), but DNSSEC-aware. > > 1. How does the stub resolver know no *real* AAAA records were available? > 2. How can the stub resolver verify the prefix is correct? > > The first problem can be solved quite easily. When the response for AAAA > records returned in no error and no data, keep the received DNSSEC data. > This includes one or two NSEC records that proof there was no data at > the QNAME. With this data, the end-host can verify the proof of > synthesis. The answer might look like > ; the synthesized record > ipv4.example.com IN AAAA ::ffff:1.2.3.4 > ; these are needed to determine security status of data > ipv4.example.com. IN A 1.2.3.4 > ipv4.example.com. IN RRSIG A [valid sig] > ; the following two records are needed for proof of synthesis > ipv4.example.com. IN NSEC A ; no AAAA bitmap set > ipv4.example.com. IN RRSIG NSEC [valid sig] > > Now the end-host can verify the need for synthesis. right we could include some text about this, once it is clear which option for supporting dnssec we will adopt > The only part that > can be faked now is the prefix. Have not yet figured it out how this can > be securely learned. Maybe the draft-wing-behave-learn-prefix may > facilitate in that. But if you can figure that out, I think you can > continue with NAT64 without the need to update end-hosts and withouth > breaking DNSSEC. > > right learning the prefix is critical for dnssec. one very easy option would be to use a well known prefix that can be hardcoded in the implementations. That would do the trick If not, we need to do some way to learn the prefix, i agree > - - In 4.3.2., not only would you need to create signatures for the AAAA > RRset, you would also need to adjust the NSEC data. right > The end-host must > also have the public key configured of the DNS64 node, in order to > validate the synthetic AAAA RRset. i am not sure what you mean here... what public key? > I don't understand why you want to > generate synthesized AAAA RRs when a Dynamic Update is done (when the > DNS64 is located in the IPv6 network). > > I personally agree with you People have claimed that there are arguments for doing it this way. For instance, what happens if the host is a dual stack host and it will create the AAAA RR using Dyn DNS as well?. In this case, if the dual stack host creates the A RR first, the automatic creation of the AAAA RR would collide with the future real AAAA RR created by the host itself. If we create the synthetic AAAA RR upon the reception fo the query, we are sure that we synthesize only if there are not real AAAA RR. Again, this could be solved in other ways (i.e. deleting the synthetic AAAA RR when a real AAAA RR is created, but this is one of the arguments presented by the people defending this option) > - - In the case that multiple prefixes are known to the DNS64, which is > discussed in section 4.5, providing all possible synthesized AAAA > records when a DNS64 box is configured with multiple prefixes seems to > be the cleanest solution imho. It reflects the most to how it is done > with real address records. > > right the problem with that, as pointed by Dan lately is that if the host uses different prefixes, will end up using different nat64 boxes and hence will use different public IPv4 address in the eyes of an external host, which seems not the best behaviour. > - - By the way, why were the rules about adding synthetic AAAA records to > the answer section removed when transitioning the draft from version 00 > to 01? > > > mmm, not sure what you mean, could you be more specific about the text you are referring to? I deleted all the stuff related to the ENDS0 option cause doesn't seem the best option so far.... not sure if this is what you are referring to > > > > Finally the nits. Some of them are linguistic, and my proposed > correction may be only correct within my own judgement. Nevertheless, I > would like to share them. > done > In the nat64 document: > - - p4, 1. Introduction. It states that no changes are required to the > IPv6 client nor the IPv6 server. This probably needs to be IPv4 > server. > - - p4, 1.2. Overview. NAT64 mechanism is implemented... -> A NAT64 > mechanism... > - - p12, 2. Terminology. For a detailed understand -> For a detailed > understanding > > In the dns64 document: > - - p5, 1.2. Walkthough -> Walkthrough > - - p11, 2. Terminology. For a detailed understand -> For a detailed > understanding > - - p13, 4.1. Tagging synthetic RR. "when a semantics of an existent > protocol is changed" -> "when the semantics of an existent protocol > has changed" > - - p14. 4.1. Tagging synthetic RR. ENDS0 -> EDNS0 > - - p20. 4.5. Supporting multiple ...: sever -> server > - - and: Note that is the NAT64... -> Note that it is the NAT64 that > failed, ... > > > > > > > Kind regards, > > Matthijs Mekking > NLnet Labs > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFJLXqvIXqNzxRs6egRAvWQAJ9OzkdmJFCu9naSWzn/c3Y6viLBcQCghRsu > 2wdfhWJZf9U+34M4d9afp2Y= > =rc7h > -----END PGP SIGNATURE----- > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From philip_matthews@magma.ca Thu Feb 12 17:16:11 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61BAC3A6830 for ; Thu, 12 Feb 2009 17:16:11 -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 x8ADET-Dmzww for ; Thu, 12 Feb 2009 17:16:09 -0800 (PST) Received: from mail-06.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 7FE403A6886 for ; Thu, 12 Feb 2009 17:16:09 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1LXmf8-0007wI-1r; Thu, 12 Feb 2009 20:16:15 -0500 Message-Id: From: Philip Matthews To: marcelo bagnulo braun In-Reply-To: <4991453D.7020900@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 12 Feb 2009 17:44:26 -0500 References: <4975B691.2040009@it.uc3m.es> <48771572-B013-4E20-98C3-C475B3A22E92@magma.ca> <4991453D.7020900@it.uc3m.es> X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] Cc: Behave WG Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 01:16:11 -0000 Hi Marcelo: There are three things that can break referrals in the presence of NATs: * The binding lifetime * Filtering * Topology or whether the binding ever existing or could exist Regarding filtering, most NATs today do either address-dependent or =20 address-and-port dependent filtering, and this is seen as a selling =20 point. People want to put their hosts behind some sort of filtering =20 NAT or firewall to block attacks, and I don't think this is going to =20 change. So even in a pure IPv6 network, referrals will not necessarily =20= work. Regarding topology, if multiple NATs are involved, then referrals can =20= break. Consider, for example, the following case: Host C (IPv6 network) NAT64 IPv4 Internet NAT64 (IPv6 network) Host A Host B Here all three hosts are located in IPv6 networks, but if Host A =20 passes to Host C the address of Host B, C will be unable to contact B. =20= (You can complain that there should be a pure IPv6 path between the =20 two IPv6 networks, but if NAT64 is successful, I am sure this case =20 will happen often). More fundamentally, referrals to hosts don't work today in the IPv4 =20 Internet because of NAT44s and firewalls, and application designers =20 (especially those designing VoIP and p2p apps) are developing =20 mechanisms (like STUN/TURN/ICE) to adapt. Any successful application in the mixed IPv4/IPv6 world will need to =20 handle the existing IPv4 Internet situation. Given that, I think we =20 simply need to make sure that these mechanisms still work. - Philip On Tue, 10-Feb-09, at 04:13 , marcelo bagnulo braun wrote: > Philip Matthews escribi=F3: >> [Catching up on a backlog of NAT64-related e-mails...] >> >> Personally, I don't think we are going to make referrals work, for =20= >> a variety of reasons. >> >> One of the main things we have learned from the whole STUN/TURN/ICE =20= >> development process is that, in the presence of NATs, a node does =20 >> not have just one IP address, but multiple IP addresses: one of =20 >> these address may work from one location and a different address =20 >> may work from a different location. > > I understand that what you are saying i correct for IPv4 NATs, but =20 > it dones' have to be for NAT64, in the following sense. In IPv4 =20 > NATs, it is clear that the binding between the public transport =20 > address and the private transport address has a very limited =20 > lifetime. SO, the public transport address is clearly not a stable =20 > name, that can can hardly be used for referrals. > Now, in NAT64 this will certainly be the case when you use an IPv4 =20 > address for the referral, since the binding between the general IPv6 =20= > address and the public IPv4 address will have the same limited =20 > lifetime. > However, i don't applies to the IPv6 addresses that represent IPv4 =20 > addresses, since the binding is automatically created, hence it does =20= > not longer has this limited lifetime nature. > > I mean, if an app uses an IPv4 address that has been assigned by a =20 > NAT a couple of hours later, it is likely that the binding will not =20= > exsit, and hence the referral won't work. If an app uses an IPv6 =20 > address representing an IPv4 address a couple of hours later, if the =20= > binding does not exsits, it can be created again, and the referal =20 > will work. > > So, it is my take that the analogy with the IPv4 case does not =20 > applies here > > (With this automatic binding creation we get rid of the time =20 > dependency and the argument for using the well known prefix is that =20= > we get rid of the topological dependency) >> Furthermore, it is almost impossible to provide an easy rule to =20 >> predict which address will work from which location (We tried =20 >> creating easy rules with the first version of STUN (as described in =20= >> RFC 3489), but it proved unreliable and thus ICE was invented). =20 >> This is the reason why an ICE endpoint gathers all the addresses =20 >> ("candidates") it can find and sends them all to the other =20 >> endpoint, and then all pair-wise combinations are tried. >> >> Furthermore, as Dan has pointed out, almost all NATs today have =20 >> filtering rules that prevent packets from the "outside" from =20 >> passing through the NAT unless a packet from the "inside" has =20 >> previously been sent out. Dan has suggested that NAT64s could =20 >> implement "endpoint-independent filtering", but I think this is =20 >> very unlikely since by far the most common rule today is some form =20= >> of "endpoint-dependent filtering" >> > First, i think that the main reasons why referals don't work is =20 > cause the binding have expired rather than cause they are filtered. > Second, one thing is to administratively fliter referals and anohter =20= > compeltelly different is to design a solution that simply is much =20 > less likely to make them work. > In the first case we can disable the filter if we want in the second =20= > case, we need to change the technology > >> For these reasons, the only reliable way to do a referral is to =20 >> pass some sort of symbolic name for the referred-to node, and use =20 >> some form of rendezvous server to establish a direct connection. In =20= >> the terms used by Marcelo below, Node A passes to Node C a symbolic =20= >> name for Node B, and then Node C contacts a rendezvous server and =20 >> uses ICE to establish a direct connection with node B. >> > exactly, the name could be the IPv6 address that represents the IPv4 =20= > address usingt he well know prefix, since it will be a universal =20 > representation of the IPv4 address in IPv6 land > > Regards, marcelo > > >> Which rendezvous server node C uses depends on the context. It may =20= >> be that Node A can act as the rendezvous server -- this is the =20 >> technique being used in the P2PSIP working group to add a peer to a =20= >> peer-to-peer network. It may also be that there is some generic =20 >> rendezvous server --- the HIP group has done some investigations =20 >> along this line. >> >> Thus I think we should drop the referral criterion when considering =20= >> the nature of the Pref64. >> >> - Philip >> >> >> >> On Tue, 20-Jan-09, at 06:33 , marcelo bagnulo braun wrote: >> >>> The topic of this mail is the impact of the prefix type selected =20 >>> for representing the IPv4 addresses in the IPv6 Internet (from now =20= >>> called Pref64::/N) in the referral operations. >>> >>> A referral operation is when a host A passes the IP address of a =20 >>> Host B to a third Host C as application data. The host Host C will =20= >>> then initiate a communication towards the Host B using the IP =20 >>> address received. I understand this is not a rare operation in =20 >>> VoIP type of applications, but Dan will correct me if this is just =20= >>> a IP area legend (that, by the way, is used, sometimes, as an =20 >>> argument to build overly complex solutions :-) >>> >>> There are several referrals scenarios as described in this table: >>> >>> | Host A | Host B | Host C | >>> --------------------------------------- >>> Scenario 1 | v6 | v6 | v4 | >>> --------------------------------------- >>> Scenario 2 | v6 | v4 | v6 | >>> --------------------------------------- >>> Scenario 3 | v4 | v6 | v6 | >>> --------------------------------------- >>> Scenario 4 | v6 | v4 | v4 | >>> --------------------------------------- >>> Scenario 5 | v4 | v6 | v4 | >>> --------------------------------------- >>> Scenario 6 | v4 | v4 | v6 | >>> --------------------------------------- >>> >>> Now, all the scenarios where Host A and Host C are in different IP =20= >>> version, they require a specific ALG, since the IP address =20 >>> information contained as application data must be translated, in =20 >>> order to be meaningful a the receiver (these are scenarios 1, 3, 4 =20= >>> and 6). >>> >>> OTOH, scenarios 2 and 5 could work without ALG. >>> >>> In addition, scenarios 1 and 5 where Host C is IPv4 and Host B is =20= >>> IPv6 will need some form of static NAT configuration (either the =20 >>> stateless mode of IVI or the manual configuration of bindings) to =20= >>> work cause they imply an IPv4 node initiating a communication =20 >>> towards and IPv6 node. >>> >>> >>> So, let's consider the scenario 2, which should work in the =20 >>> dynamic binding case without ALGs first: >>> >>> **Scenario 2 is as follows >>> >>> >>> +-----------------------------------------+ >>> | IPv4 Internet | >>> | +--------+ | >>> | | Host B | | >>> | | IPB | | >>> | +--------+ | >>> +-----------------------------------------+ >>> | | >>> | | >>> +--|----------------------------------|---+ >>> |+-|--------+ +-------+ +--------|--+| >>> || Pref64_1 | | | | Pref64_2 || >>> || | | | | || >>> || +------+ | | | | +-------+ || >>> || |Host A| |----| |---| |Host C | || >>> || +------+ | | | | +-------+ || >>> || Site1 | +-------+ | Site2 || >>> |+----------+ +-----------+| >>> | | >>> | IPv6 Internet | >>> +-----------------------------------------+ >>> >>> So, in this case, Host A will be sending Host B's address to Host =20= >>> C as application data. >>> Now, in the eyes of Host A, Host B's address is =20 >>> Pref64_1:IPB:suffix (the suffix is optional, depending whether =20 >>> Pref64_1 is 96 bit long or shorter. >>> >>> Host C will receive then Pref64_1:IPB:suffix and will try to =20 >>> initiate a communication toward host B using that address. >>> >>> We now have two options depending if the prefix Pref64_1 is a =20 >>> single well known prefix or is allocated from the site's address =20 >>> block. >>> >>> - Case where the Pref64_1 is allocated from the site's address =20 >>> block (FWIW this what all drafts do as currently described) >>> Host C sends a packet towards Pref64_1:IPB:suffix. >>> The packet is routed towards Site 1 since Pref64_1 is part of =20 >>> site's 1 address block. >>> Now Site 1 has 3 options, as discussed yesterday with Xing. Either =20= >>> forwards the packet to the IPv4 internet or drops it (it can drop =20= >>> it at the ingress or in the translator box). Now, as i understand =20= >>> it, it doens't make economical sense for site 1 to forward the =20 >>> packet towards the v4 internet, cause if it did so, it would be =20 >>> providing free v6 to v4 transit. So, as i understand it, it makes =20= >>> sense for site 1 to drop the packet (which is what i understand =20 >>> CERNET does (in their case it is a bit more complicated, cause =20 >>> they also have a the IVI addresses that they handle differently, =20 >>> but i think this applies in their case as well, modulo those =20 >>> addresses)) >>> >>> Now, if site1 drops packets addressed to Pref64_1 coming from the =20= >>> outside, referrals break. >>> >>> - Case where the Pref64_1 is a single well know prefix. >>> In this case Pref64_1=3DPref64_2=3DPref64 >>> So, HostA sends Pref64:IPB_suffix to Host C >>> Host C now sends a packet to Pref64:IPB:suffix. >>> In this case, the packet will flow through whatever route Site2 =20 >>> has to connect to the IPv4 Internet. In our scheme, site2 has its =20= >>> own translator, that then would announce a route towards Pref64, =20 >>> so the packet will flow through the direct route Site2 has to the =20= >>> IPv4 Internet. >>> >>> So, from this analysis, it seems that in this case, referrals =20 >>> would work if a single well know prefix is used. >>> >>> >>> So, let's think a bit about the scenarios that require al ALG next. >>> >>> >>> ** Scenarios 1, 3, 4 and 6 >>> >>> A general observation about these scenarios is that in the case a =20= >>> single well know prefix is used, it would be possible for the ALG =20= >>> to identify the IPv6 addresses containing an embedded IPv4 =20 >>> address and translate it, cause they could identify the well know =20= >>> prefix and know that are not general use IPv6 addresses. If the =20 >>> Pref64 is taken from the site's address block, it may be possible =20= >>> for the ALG to translate the address in the referral, as long as =20 >>> the translator is configured to know that this specific prefix is =20= >>> unsed to map IPv4 addresses. This basically implies that the =20 >>> translator must be in Site1 in the figure above, i.e. the site of =20= >>> the host sending the referral information. >>> >>> So, we can say that a single well known prefix is more likely to =20 >>> work with referral in the case that ALG is needed than the case =20 >>> of the prefix taken from the site's address block. >>> >>> *** So, we have scenario 5 to go >>> >>> Host A is v4, host B is v6 and host C is v4 >>> >>> In this case, we need a representation of Host B in the v4 world. =20= >>> In this case, the Pref64 seems hardly relevant. >>> >>> So, i think it is reasonable to say that a single well know prefix =20= >>> would result in better referral support. >>> I wonder if this cannot be generalized for other applications. I =20 >>> mean after all the better support is simply due to the fact that =20 >>> using a single well know prefix results in a unique representation =20= >>> of the v4 addresses in v6 land, and allows to identify that =20 >>> irrespectivly where the translation is performed, the result is =20 >>> the same in terms of the address. >>> >>> _______________________________________________ >>> 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 root@core3.amsl.com Mon Feb 16 06:30:02 2009 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2B1E43A6A8B; Mon, 16 Feb 2009 06:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090216143002.2B1E43A6A8B@core3.amsl.com> Date: Mon, 16 Feb 2009 06:30:02 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-sctpnat-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 14:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Stream Control Transmission Protocol (SCTP) Network Address Translation Author(s) : R. Stewart, et al. Filename : draft-ietf-behave-sctpnat-01.txt Pages : 24 Date : 2009-02-16 Stream Control Transmission Protocol [RFC4960] provides a reliable communications channel between two end-hosts in many ways similar to TCP [RFC0793]. With the widespread deployment of Network Address Translators (NAT), specialized code has been added to NAT for TCP that allows multiple hosts to reside behind a NAT and yet use only a single globally unique IPv4 address, even when two hosts (behind a NAT) choose the same port numbers for their connection. This additional code is sometimes classified as Network Address and Port Translation or NAPT. To date, specialized code for SCTP has NOT yet been added to most NATs so that only pure NAT is available. The end result of this is that only one SCTP capable host can be behind a NAT. This document describes an SCTP specific variant of NAT which provides similar features of NAPT in the single point and multi-point traversal scenario. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-sctpnat-01.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 Content-Type: Message/External-body; name="draft-ietf-behave-sctpnat-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-16062218.I-D@ietf.org> --NextPart-- From marcelo@it.uc3m.es Tue Feb 17 02:49:46 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B65128C130 for ; Tue, 17 Feb 2009 02:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.78 X-Spam-Level: X-Spam-Status: No, score=-5.78 tagged_above=-999 required=5 tests=[AWL=0.819, 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 gzO1u5tKiejz for ; Tue, 17 Feb 2009 02:49:44 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id F3A2328C115 for ; Tue, 17 Feb 2009 02:49:43 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (206.pool85-53-136.dynamic.orange.es [85.53.136.206]) by smtp02.uc3m.es (Postfix) with ESMTP id C76C56BA82F; Tue, 17 Feb 2009 11:49:51 +0100 (CET) Message-ID: <499A964F.9070707@it.uc3m.es> Date: Tue, 17 Feb 2009 11:49:51 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Philip Matthews References: <4975B691.2040009@it.uc3m.es> <48771572-B013-4E20-98C3-C475B3A22E92@magma.ca> <4991453D.7020900@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16468.005 Cc: Behave WG Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 10:49:46 -0000 Hi Phillip, sorry for the delay, replies below... Philip Matthews escribió: > Hi Marcelo: > > There are three things that can break referrals in the presence of NATs: > * The binding lifetime > * Filtering > * Topology or whether the binding ever existing or could exist > > Regarding filtering, most NATs today do either address-dependent or > address-and-port dependent filtering, and this is seen as a selling > point. People want to put their hosts behind some sort of filtering > NAT or firewall to block attacks, and I don't think this is going to > change. So even in a pure IPv6 network, referrals will not necessarily > work. > right This would also apply to firewalls. Now, i can understand that people can have security policy that prevents this from working and i am fine with that. the thing about security policy is that other sits can have a different policy and referrals would work for them. It is actually an operation choice of the site and that is good. IMHO it is a completelly different thing to make a technology that by design breaks referrals, i simply don't think this is a good idea > Regarding topology, if multiple NATs are involved, then referrals can > break. Consider, for example, the following case: > > Host C > (IPv6 network) > > NAT64 > > IPv4 Internet > > NAT64 > > (IPv6 network) > Host A Host B > > Here all three hosts are located in IPv6 networks, but if Host A > passes to Host C the address of Host B, C will be unable to contact B. > (You can complain that there should be a pure IPv6 path between the > two IPv6 networks, but if NAT64 is successful, I am sure this case > will happen often). it depends, right? I mean, if the binding is still alive, it would be able to contact If the binding has expired, it won't But if the binding has expired, then Host C wouldn't be able to receive any incoming communication and not because this is not supported in this scenarion, you would argue that supporting incoming communication is not needed in general, right? Bottom line is that we have challenging scenarios, and we should try to design a solution that works in the highest number of scenarios that we can > > > More fundamentally, referrals to hosts don't work today in the IPv4 > Internet because of NAT44s and firewalls, i think this is a bit too assertive for my taste. > and application designers (especially those designing VoIP and p2p > apps) are developing mechanisms (like STUN/TURN/ICE) to adapt. > but this is not a valid reason to design a solution that by design does not support them by design > Any successful application in the mixed IPv4/IPv6 world will need to > handle the existing IPv4 Internet situation. i agree this doesn't imply that we cannot try to design a protocol that can work if the scenario is appropriate regards, marcelo > Given that, I think we simply need to make sure that these mechanisms > still work. > > - Philip > > > > On Tue, 10-Feb-09, at 04:13 , marcelo bagnulo braun wrote: > >> Philip Matthews escribió: >>> [Catching up on a backlog of NAT64-related e-mails...] >>> >>> Personally, I don't think we are going to make referrals work, for a >>> variety of reasons. >>> >>> One of the main things we have learned from the whole STUN/TURN/ICE >>> development process is that, in the presence of NATs, a node does >>> not have just one IP address, but multiple IP addresses: one of >>> these address may work from one location and a different address may >>> work from a different location. >> >> I understand that what you are saying i correct for IPv4 NATs, but it >> dones' have to be for NAT64, in the following sense. In IPv4 NATs, it >> is clear that the binding between the public transport address and >> the private transport address has a very limited lifetime. SO, the >> public transport address is clearly not a stable name, that can can >> hardly be used for referrals. >> Now, in NAT64 this will certainly be the case when you use an IPv4 >> address for the referral, since the binding between the general IPv6 >> address and the public IPv4 address will have the same limited lifetime. >> However, i don't applies to the IPv6 addresses that represent IPv4 >> addresses, since the binding is automatically created, hence it does >> not longer has this limited lifetime nature. >> >> I mean, if an app uses an IPv4 address that has been assigned by a >> NAT a couple of hours later, it is likely that the binding will not >> exsit, and hence the referral won't work. If an app uses an IPv6 >> address representing an IPv4 address a couple of hours later, if the >> binding does not exsits, it can be created again, and the referal >> will work. >> >> So, it is my take that the analogy with the IPv4 case does not >> applies here >> >> (With this automatic binding creation we get rid of the time >> dependency and the argument for using the well known prefix is that >> we get rid of the topological dependency) >>> Furthermore, it is almost impossible to provide an easy rule to >>> predict which address will work from which location (We tried >>> creating easy rules with the first version of STUN (as described in >>> RFC 3489), but it proved unreliable and thus ICE was invented). This >>> is the reason why an ICE endpoint gathers all the addresses >>> ("candidates") it can find and sends them all to the other endpoint, >>> and then all pair-wise combinations are tried. >>> >>> Furthermore, as Dan has pointed out, almost all NATs today have >>> filtering rules that prevent packets from the "outside" from passing >>> through the NAT unless a packet from the "inside" has previously >>> been sent out. Dan has suggested that NAT64s could implement >>> "endpoint-independent filtering", but I think this is very unlikely >>> since by far the most common rule today is some form of >>> "endpoint-dependent filtering" >>> >> First, i think that the main reasons why referals don't work is cause >> the binding have expired rather than cause they are filtered. >> Second, one thing is to administratively fliter referals and anohter >> compeltelly different is to design a solution that simply is much >> less likely to make them work. >> In the first case we can disable the filter if we want in the second >> case, we need to change the technology >> >>> For these reasons, the only reliable way to do a referral is to pass >>> some sort of symbolic name for the referred-to node, and use some >>> form of rendezvous server to establish a direct connection. In the >>> terms used by Marcelo below, Node A passes to Node C a symbolic name >>> for Node B, and then Node C contacts a rendezvous server and uses >>> ICE to establish a direct connection with node B. >>> >> exactly, the name could be the IPv6 address that represents the IPv4 >> address usingt he well know prefix, since it will be a universal >> representation of the IPv4 address in IPv6 land >> >> Regards, marcelo >> >> >>> Which rendezvous server node C uses depends on the context. It may >>> be that Node A can act as the rendezvous server -- this is the >>> technique being used in the P2PSIP working group to add a peer to a >>> peer-to-peer network. It may also be that there is some generic >>> rendezvous server --- the HIP group has done some investigations >>> along this line. >>> >>> Thus I think we should drop the referral criterion when considering >>> the nature of the Pref64. >>> >>> - Philip >>> >>> >>> >>> On Tue, 20-Jan-09, at 06:33 , marcelo bagnulo braun wrote: >>> >>>> The topic of this mail is the impact of the prefix type selected >>>> for representing the IPv4 addresses in the IPv6 Internet (from now >>>> called Pref64::/N) in the referral operations. >>>> >>>> A referral operation is when a host A passes the IP address of a >>>> Host B to a third Host C as application data. The host Host C will >>>> then initiate a communication towards the Host B using the IP >>>> address received. I understand this is not a rare operation in VoIP >>>> type of applications, but Dan will correct me if this is just a IP >>>> area legend (that, by the way, is used, sometimes, as an argument >>>> to build overly complex solutions :-) >>>> >>>> There are several referrals scenarios as described in this table: >>>> >>>> | Host A | Host B | Host C | >>>> --------------------------------------- >>>> Scenario 1 | v6 | v6 | v4 | >>>> --------------------------------------- >>>> Scenario 2 | v6 | v4 | v6 | >>>> --------------------------------------- >>>> Scenario 3 | v4 | v6 | v6 | >>>> --------------------------------------- >>>> Scenario 4 | v6 | v4 | v4 | >>>> --------------------------------------- >>>> Scenario 5 | v4 | v6 | v4 | >>>> --------------------------------------- >>>> Scenario 6 | v4 | v4 | v6 | >>>> --------------------------------------- >>>> >>>> Now, all the scenarios where Host A and Host C are in different IP >>>> version, they require a specific ALG, since the IP address >>>> information contained as application data must be translated, in >>>> order to be meaningful a the receiver (these are scenarios 1, 3, 4 >>>> and 6). >>>> >>>> OTOH, scenarios 2 and 5 could work without ALG. >>>> >>>> In addition, scenarios 1 and 5 where Host C is IPv4 and Host B is >>>> IPv6 will need some form of static NAT configuration (either the >>>> stateless mode of IVI or the manual configuration of bindings) to >>>> work cause they imply an IPv4 node initiating a communication >>>> towards and IPv6 node. >>>> >>>> >>>> So, let's consider the scenario 2, which should work in the dynamic >>>> binding case without ALGs first: >>>> >>>> **Scenario 2 is as follows >>>> >>>> >>>> +-----------------------------------------+ >>>> | IPv4 Internet | >>>> | +--------+ | >>>> | | Host B | | >>>> | | IPB | | >>>> | +--------+ | >>>> +-----------------------------------------+ >>>> | | >>>> | | >>>> +--|----------------------------------|---+ >>>> |+-|--------+ +-------+ +--------|--+| >>>> || Pref64_1 | | | | Pref64_2 || >>>> || | | | | || >>>> || +------+ | | | | +-------+ || >>>> || |Host A| |----| |---| |Host C | || >>>> || +------+ | | | | +-------+ || >>>> || Site1 | +-------+ | Site2 || >>>> |+----------+ +-----------+| >>>> | | >>>> | IPv6 Internet | >>>> +-----------------------------------------+ >>>> >>>> So, in this case, Host A will be sending Host B's address to Host C >>>> as application data. >>>> Now, in the eyes of Host A, Host B's address is Pref64_1:IPB:suffix >>>> (the suffix is optional, depending whether Pref64_1 is 96 bit long >>>> or shorter. >>>> >>>> Host C will receive then Pref64_1:IPB:suffix and will try to >>>> initiate a communication toward host B using that address. >>>> >>>> We now have two options depending if the prefix Pref64_1 is a >>>> single well known prefix or is allocated from the site's address >>>> block. >>>> >>>> - Case where the Pref64_1 is allocated from the site's address >>>> block (FWIW this what all drafts do as currently described) >>>> Host C sends a packet towards Pref64_1:IPB:suffix. >>>> The packet is routed towards Site 1 since Pref64_1 is part of >>>> site's 1 address block. >>>> Now Site 1 has 3 options, as discussed yesterday with Xing. Either >>>> forwards the packet to the IPv4 internet or drops it (it can drop >>>> it at the ingress or in the translator box). Now, as i understand >>>> it, it doens't make economical sense for site 1 to forward the >>>> packet towards the v4 internet, cause if it did so, it would be >>>> providing free v6 to v4 transit. So, as i understand it, it makes >>>> sense for site 1 to drop the packet (which is what i understand >>>> CERNET does (in their case it is a bit more complicated, cause they >>>> also have a the IVI addresses that they handle differently, but i >>>> think this applies in their case as well, modulo those addresses)) >>>> >>>> Now, if site1 drops packets addressed to Pref64_1 coming from the >>>> outside, referrals break. >>>> >>>> - Case where the Pref64_1 is a single well know prefix. >>>> In this case Pref64_1=Pref64_2=Pref64 >>>> So, HostA sends Pref64:IPB_suffix to Host C >>>> Host C now sends a packet to Pref64:IPB:suffix. >>>> In this case, the packet will flow through whatever route Site2 has >>>> to connect to the IPv4 Internet. In our scheme, site2 has its own >>>> translator, that then would announce a route towards Pref64, so the >>>> packet will flow through the direct route Site2 has to the IPv4 >>>> Internet. >>>> >>>> So, from this analysis, it seems that in this case, referrals would >>>> work if a single well know prefix is used. >>>> >>>> >>>> So, let's think a bit about the scenarios that require al ALG next. >>>> >>>> >>>> ** Scenarios 1, 3, 4 and 6 >>>> >>>> A general observation about these scenarios is that in the case a >>>> single well know prefix is used, it would be possible for the ALG >>>> to identify the IPv6 addresses containing an embedded IPv4 >>>> address and translate it, cause they could identify the well know >>>> prefix and know that are not general use IPv6 addresses. If the >>>> Pref64 is taken from the site's address block, it may be possible >>>> for the ALG to translate the address in the referral, as long as >>>> the translator is configured to know that this specific prefix is >>>> unsed to map IPv4 addresses. This basically implies that the >>>> translator must be in Site1 in the figure above, i.e. the site of >>>> the host sending the referral information. >>>> >>>> So, we can say that a single well known prefix is more likely to >>>> work with referral in the case that ALG is needed than the case of >>>> the prefix taken from the site's address block. >>>> >>>> *** So, we have scenario 5 to go >>>> >>>> Host A is v4, host B is v6 and host C is v4 >>>> >>>> In this case, we need a representation of Host B in the v4 world. >>>> In this case, the Pref64 seems hardly relevant. >>>> >>>> So, i think it is reasonable to say that a single well know prefix >>>> would result in better referral support. >>>> I wonder if this cannot be generalized for other applications. I >>>> mean after all the better support is simply due to the fact that >>>> using a single well know prefix results in a unique representation >>>> of the v4 addresses in v6 land, and allows to identify that >>>> irrespectivly where the translation is performed, the result is the >>>> same in terms of the address. >>>> >>>> _______________________________________________ >>>> 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 wwwrun@core3.amsl.com Tue Feb 17 07:53:10 2009 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 55F693A6BEF; Tue, 17 Feb 2009 07:53:10 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090217155310.55F693A6BEF@core3.amsl.com> Date: Tue, 17 Feb 2009 07:53:10 -0800 (PST) Cc: Internet Architecture Board , behave mailing list , behave chair , RFC Editor Subject: [BEHAVE] Protocol Action: 'NAT Behavioral Requirements for ICMP protocol' to BCP X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 15:53:10 -0000 The IESG has approved the following document: - 'NAT Behavioral Requirements for ICMP protocol ' as a BCP This document is the product of the Behavior Engineering for Hindrance Avoidance Working Group. The IESG contact persons are Magnus Westerlund and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-icmp-12.txt Technical Summary This document specifies the behavioral properties required of the Network Address Translator (NAT) devices in conjunction with the ICMP protocol. The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices. Companion documents provide behavioral recommendations specific to TCP, UDP and other protocols. Working Group Summary There was consensus in the WG to publish this document. Document Quality This is a BCP document, and describes current good practice in existing NATs, and describes some improvements to current practice. Personnel Document shepherd: Dan Wing, dwing@cisco.com Responsible AD: Magnus Westerlund, magnus.westerlund@ericsson.com From dwing@cisco.com Tue Feb 17 10:39:43 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BD083A694E for ; Tue, 17 Feb 2009 10:39:43 -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 nrTAsQHTiFVz for ; Tue, 17 Feb 2009 10:39:42 -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 52ABC3A6840 for ; Tue, 17 Feb 2009 10:39:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,224,1233532800"; d="scan'208";a="143568995" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 17 Feb 2009 18:39:41 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1HIdc3R008252 for ; Tue, 17 Feb 2009 10:39:41 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n1HIdcPF002065 for ; Tue, 17 Feb 2009 18:39:38 GMT From: "Dan Wing" To: "'behave mailing list'" References: <20090217155310.55F693A6BEF@core3.amsl.com> Date: Tue, 17 Feb 2009 10:39:38 -0800 Message-ID: <05ec01c9912f$16ba5350$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090217155310.55F693A6BEF@core3.amsl.com> Thread-Index: AcmRF+DiyRz3XCAfQyC5DY6AKHRR4AAFw5Ig X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1698; t=1234895981; x=1235759981; 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=20Protocol=20Action=3A=20'NAT=20Behaviora l=20Requirements=20for=20ICMP=20protocol'=20to=20BCP=20 |Sender:=20; bh=OT/jjP30fw23b6qu2S3O7XynrV27g4e5Wt8uVeCHlnk=; b=K4fhwSph2bwcjXnU50u8wt9djvzBjIrFSuF/SOdrcCGSCBBkmKeXijgrAs WY01cZp5IV7uY2x/fvbLK4PW2BB05jmQnCdt9kR4r48KbRhfbiyVBH03tx2i zZfOfLwrj7; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [BEHAVE] Protocol Action: 'NAT Behavioral Requirements for ICMP protocol' to BCP X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 18:39:43 -0000 Thanks to everyone, especially Suresh, for seeing this one through! -d > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: Tuesday, February 17, 2009 7:53 AM > To: IETF-Announce > Cc: Internet Architecture Board; RFC Editor; behave mailing > list; behave chair > Subject: Protocol Action: 'NAT Behavioral Requirements for > ICMP protocol' to BCP > > The IESG has approved the following document: > > - 'NAT Behavioral Requirements for ICMP protocol ' > as a BCP > > This document is the product of the Behavior Engineering for > Hindrance > Avoidance Working Group. > > The IESG contact persons are Magnus Westerlund and Lars Eggert. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-icmp-12.txt > > Technical Summary > > This document specifies the behavioral properties required of the > Network Address Translator (NAT) devices in conjunction with the > ICMP protocol. The objective of this memo is to make NAT devices > more predictable and compatible with diverse application protocols > that traverse the devices. Companion documents provide behavioral > recommendations specific to TCP, UDP and other protocols. > > Working Group Summary > > There was consensus in the WG to publish this document. > > Document Quality > > This is a BCP document, and describes current good practice > in existing > NATs, and describes some improvements to current practice. > > Personnel > > Document shepherd: Dan Wing, dwing@cisco.com > Responsible AD: Magnus Westerlund, magnus.westerlund@ericsson.com > From philip_matthews@magma.ca Thu Feb 19 03:32:52 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 149E43A6A36 for ; Thu, 19 Feb 2009 03:32:52 -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 DqfgJCcoKQ3C for ; Thu, 19 Feb 2009 03:32:51 -0800 (PST) Received: from mail-02.primus.ca (mail8.primus.ca [216.254.141.175]) by core3.amsl.com (Postfix) with ESMTP id 4FD603A6A38 for ; Thu, 19 Feb 2009 03:32:51 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1La79M-0001jk-0b; Thu, 19 Feb 2009 06:33:04 -0500 Message-Id: <350C67BE-31BA-4ACE-8BDF-047FE0AE4F68@magma.ca> From: Philip Matthews To: Behave WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 19 Feb 2009 06:33:04 -0500 X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] Cc: Scott Godin Subject: [BEHAVE] TURN: Change channel lifetime to 5 minutes? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 11:32:52 -0000 Folks: There has been a recent proposal that the channel lifetime, currently at 10 minutes, be changed to match the permission lifetime of 5 minutes. I consider this a significant change to make at this late date, and would thus like to see WG support before I make it. Please comment on whether you would like to see this change. - Philip From paul.mackell@tandberg.com Thu Feb 19 04:08:59 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 357693A6A71 for ; Thu, 19 Feb 2009 04:08:59 -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=[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 45TgsUQIQrcu for ; Thu, 19 Feb 2009 04:08:58 -0800 (PST) Received: from mail178.messagelabs.com (mail178.messagelabs.com [85.158.139.19]) by core3.amsl.com (Postfix) with SMTP id C5D643A67ED for ; Thu, 19 Feb 2009 04:08:57 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: paul.mackell@tandberg.com X-Msg-Ref: server-13.tower-178.messagelabs.com!1235045348!16153045!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [62.70.2.252] Received: (qmail 5968 invoked from network); 19 Feb 2009 12:09:08 -0000 Received: from unknown (HELO OSLEXCP11.eu.tandberg.int) (62.70.2.252) by server-13.tower-178.messagelabs.com with SMTP; 19 Feb 2009 12:09:08 -0000 Received: from oslexcp2.eu.tandberg.int ([10.47.136.30]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Feb 2009 13:09:08 +0100 Received: from 10.47.5.139 ([10.47.5.139]) by oslexcp2.eu.tandberg.int ([10.47.136.30]) with Microsoft Exchange Server HTTP-DAV ; Thu, 19 Feb 2009 12:09:07 +0000 Received: from PTMackellR60 by oslexcp2.eu.tandberg.int; 19 Feb 2009 13:09:44 +0100 From: Paul Mackell To: Behave WG In-Reply-To: <350C67BE-31BA-4ACE-8BDF-047FE0AE4F68@magma.ca> References: <350C67BE-31BA-4ACE-8BDF-047FE0AE4F68@magma.ca> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 19 Feb 2009 13:09:44 +0100 Message-Id: <1235045384.3446.17.camel@PTMackellR60.rd.tandberg.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-OriginalArrivalTime: 19 Feb 2009 12:09:08.0479 (UTC) FILETIME=[DE0520F0:01C9928A] Subject: Re: [BEHAVE] TURN: Change channel lifetime to 5 minutes? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 12:08:59 -0000 I am for this change. Sending a channel bind also refreshes a permission therefore it should have the same timeout. Paul On Thu, 2009-02-19 at 06:33 -0500, Philip Matthews wrote: > Folks: > > There has been a recent proposal that the channel lifetime, currently > at 10 minutes, be changed to match the permission lifetime of 5 minutes. > > I consider this a significant change to make at this late date, and > would thus like to see WG support before I make it. Please comment on > whether you would like to see this change. > > - Philip > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From petithug@acm.org Thu Feb 19 04:48:48 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68CD428C1D6 for ; Thu, 19 Feb 2009 04:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 E2JHysrIzxZb for ; Thu, 19 Feb 2009 04:48:47 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id AF2AE28C122 for ; Thu, 19 Feb 2009 04:48:47 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 356C5DC4404A; Thu, 19 Feb 2009 12:49:00 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTP id 54196DC44006; Thu, 19 Feb 2009 12:48:50 +0000 (UTC) Message-ID: <499D5530.9010904@acm.org> Date: Thu, 19 Feb 2009 04:48:48 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Philip Matthews References: <350C67BE-31BA-4ACE-8BDF-047FE0AE4F68@magma.ca> In-Reply-To: <350C67BE-31BA-4ACE-8BDF-047FE0AE4F68@magma.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Scott Godin , Behave WG Subject: Re: [BEHAVE] TURN: Change channel lifetime to 5 minutes? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 12:48:48 -0000 Philip Matthews wrote: > Folks: > > There has been a recent proposal that the channel lifetime, currently at > 10 minutes, be changed to match the permission lifetime of 5 minutes. > > I consider this a significant change to make at this late date, and > would thus like to see WG support before I make it. Please comment on > whether you would like to see this change. > Note that we already talked about this in 2008, and decided against it: http://www.ietf.org/mail-archive/web/behave/current/msg04374.html http://www.ietf.org/mail-archive/web/behave/current/msg04396.html What changed since? I remember vaguely that there was concerns about this at the Ad-hoc meeting in Dublin, so it would be great if the people who spoke against this at the time could explain why. Personally I do not see a reason to have different timers but I could have missed something. I would say that if there is a doubt we should keep them separated, even if it is more painful for the developers. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From dthaler@windows.microsoft.com Thu Feb 19 13:41:53 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17D6C28C127 for ; Thu, 19 Feb 2009 13:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.691 X-Spam-Level: X-Spam-Status: No, score=-109.691 tagged_above=-999 required=5 tests=[AWL=-0.582, BAYES_05=-1.11, HTML_MESSAGE=0.001, 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 M4IqUONVHNeZ for ; Thu, 19 Feb 2009 13:41:51 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id CEAF63A696A for ; Thu, 19 Feb 2009 13:41:51 -0800 (PST) Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Thu, 19 Feb 2009 13:41:59 -0800 Received: from TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com (157.54.18.79) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) with Microsoft SMTP Server id 8.2.99.4; Thu, 19 Feb 2009 13:39:50 -0800 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::75be:c82f:ae04:55bf]) by TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.79]) with mapi; Thu, 19 Feb 2009 13:39:49 -0800 From: Dave Thaler To: "behave@ietf.org" Date: Thu, 19 Feb 2009 13:39:49 -0800 Thread-Topic: Prioritization of the translation cases Thread-Index: AcmS2pc+uerkfrT2Qxus7P2IYXVUsg== Message-ID: 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_E9CACA3D8417CE409FE3669AAE1E5A4F118EF85AABNAEXMSGW601wi_" MIME-Version: 1.0 Subject: [BEHAVE] Prioritization of the translation cases X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 21:41:53 -0000 --_000_E9CACA3D8417CE409FE3669AAE1E5A4F118EF85AABNAEXMSGW601wi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On our WG charter we have a milestone to "Determine relative prioritization of the four translation cases." As the first step in doing this, we would like to get a sense of the energy/importance/urgency of each of the cases. To do this, we would like to ask three questions per scenario: 1) Are you already doing this today with the deprecated NAT-PT? 2) Have you or are you planning to implement code for this scenario? 3) Have you or are you planning to deploying this scenario in a real environment (not just a test lab)? The first question is intended to get a sense of what NAT-PT is being used for today, which we'd like to replace. The other two questions are intended to get a sense of interest among those creating solutions, and those trying to deploy solutions. We have set up a doodle poll at: http://www.doodle.com/9qsdgt8r6kqk6zty which may appear a bit complicated, but it's just the three questions above applied to each scenario. For completeness we are asking about six scenarios. The first four are in our charter and the last two are not listed in our charter, but were discussed as part of IVI, and also we would like to get a sense of how much deployment of NAT-PT there is already in those scenarios. The scenarios are: 1. An IPv6 network to IPv4 Internet 2. IPv6 Internet to an IPv4 network 3. An IPv4 network to IPv6 Internet 4. IPv4 Internet to an IPv6 network 5. IPv6 to IPv4 within the same organization 6. IPv4 to IPv6 within the same organization If you care to provide additional information, then you can do so in email to the list in addition to the doodle. Thanks, -Dave Thaler & Dan Wing --_000_E9CACA3D8417CE409FE3669AAE1E5A4F118EF85AABNAEXMSGW601wi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

On our WG charter we have a milestone to "Dete= rmine relative

prioritization of the four translation cases."=

 

As the first step in doing this, we would like to g= et a sense

of the energy/importance/urgency of each of the cas= es.  To do

this, we would like to ask three questions per scen= ario:

 

1) Are you already doing this today with the deprec= ated NAT-PT?

2) Have you or are you planning to implement code f= or this scenario?

3) Have you or are you planning to deploying this scenario in a real

   environment (not just a test lab)?

 

The first question is intended to get a sense of wh= at NAT-PT is being

used for today, which we'd like to replace.  T= he other two questions

are intended to get a sense of interest among those creating solutions,

and those trying to deploy solutions.

 

We have set up a doodle poll at:

= http://www.doodle.com/9qsdgt8r6kqk6zty

which may appear a bit complicated, but it's just t= he three

questions above applied to each scenario.

 

For completeness we are asking about six scenarios.=   The first

four are in our charter and the last two are not li= sted

in our charter, but were discussed as part of IVI, = and also we

would like to get a sense of how much deployment of NAT-PT there

is already in those scenarios.  The scenarios = are:

 

   1. An IPv6 network to IPv4 Internet

   2. IPv6 Internet to an IPv4 network

   3. An IPv4 network to IPv6 Internet

   4. IPv4 Internet to an IPv6 network

   5. IPv6 to IPv4 within the same organi= zation

   6. IPv4 to IPv6 within the same organi= zation

 

If you care to provide additional information, then= you can

do so in email to the list in addition to the doodl= e.

 

Thanks,

-Dave Thaler & Dan Wing

 

--_000_E9CACA3D8417CE409FE3669AAE1E5A4F118EF85AABNAEXMSGW601wi_-- From miyata@tahi.org Fri Feb 20 01:13:05 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 483A23A67C1 for ; Fri, 20 Feb 2009 01:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.018 X-Spam-Level: X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.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 6A2hXBG6E22i for ; Fri, 20 Feb 2009 01:13:04 -0800 (PST) Received: from ns.64translator.com (70.145.221.202.bf.2iij.net [202.221.145.70]) by core3.amsl.com (Postfix) with ESMTP id 1D8AB3A6765 for ; Fri, 20 Feb 2009 01:13:03 -0800 (PST) Received: from bahamas.64translator.com (bahamas.64translator.com [10.21.32.3]) by ns.64translator.com (8.14.2/8.14.2) with ESMTP id n1K9C0kb089471; Fri, 20 Feb 2009 18:12:01 +0900 (JST) (envelope-from miyata@tahi.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by bahamas.64translator.com (8.13.6/8.13.6) with ESMTP id n1K9Bkok024748; Fri, 20 Feb 2009 18:11:48 +0900 (JST) (envelope-from miyata@tahi.org) Message-Id: From: Hiroshi MIYATA To: Dave Thaler In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 20 Feb 2009 18:11:46 +0900 References: X-Mailer: Apple Mail (2.929.2) Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Prioritization of the translation cases X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 09:13:05 -0000 Hi Dave, I added my record. But let me note that we are not using original(deprecated) NAT-PT, though I marked the deprecated NAT-PT. We are using modified NAT-PT. It is almost same as NAT64+DNS64, which is currently discussed. Thanks, ....hiroshi miyata On 2009/02/20, at 6:39, Dave Thaler wrote: > On our WG charter we have a milestone to "Determine relative > prioritization of the four translation cases." > > As the first step in doing this, we would like to get a sense > of the energy/importance/urgency of each of the cases. To do > this, we would like to ask three questions per scenario: > > 1) Are you already doing this today with the deprecated NAT-PT? > 2) Have you or are you planning to implement code for this scenario? > 3) Have you or are you planning to deploying this scenario in a real > environment (not just a test lab)? > > The first question is intended to get a sense of what NAT-PT is being > used for today, which we'd like to replace. The other two questions > are intended to get a sense of interest among those creating > solutions, > and those trying to deploy solutions. > > We have set up a doodle poll at: > http://www.doodle.com/9qsdgt8r6kqk6zty > which may appear a bit complicated, but it's just the three > questions above applied to each scenario. > > For completeness we are asking about six scenarios. The first > four are in our charter and the last two are not listed > in our charter, but were discussed as part of IVI, and also we > would like to get a sense of how much deployment of NAT-PT there > is already in those scenarios. The scenarios are: > > 1. An IPv6 network to IPv4 Internet > 2. IPv6 Internet to an IPv4 network > 3. An IPv4 network to IPv6 Internet > 4. IPv4 Internet to an IPv6 network > 5. IPv6 to IPv4 within the same organization > 6. IPv4 to IPv6 within the same organization > > If you care to provide additional information, then you can > do so in email to the list in addition to the doodle. > > Thanks, > -Dave Thaler & Dan Wing > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From jari.arkko@piuha.net Fri Feb 20 10:29:44 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45ABF3A6969 for ; Fri, 20 Feb 2009 10:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.052, 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 NZRnHyAuRWcv for ; Fri, 20 Feb 2009 10:29:43 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 4B3783A680E for ; Fri, 20 Feb 2009 10:29:43 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id F16A519876C; Fri, 20 Feb 2009 20:29:56 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id A2A101986EF; Fri, 20 Feb 2009 20:29:56 +0200 (EET) Message-ID: <499EF6A4.70204@piuha.net> Date: Fri, 20 Feb 2009 20:29:56 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: marcelo bagnulo braun References: <4975B691.2040009@it.uc3m.es> <48771572-B013-4E20-98C3-C475B3A22E92@magma.ca> <4991453D.7020900@it.uc3m.es> <499A964F.9070707@it.uc3m.es> In-Reply-To: <499A964F.9070707@it.uc3m.es> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Behave WG , Philip Matthews Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 18:29:44 -0000 Marcelo, > Now, i can understand that people can have security policy that > prevents this from working and i am fine with that. > the thing about security policy is that other sits can have a > different policy and referrals would work for them. It is actually an > operation choice of the site and that is good. > IMHO it is a completelly different thing to make a technology that by > design breaks referrals, i simply don't think this is a good idea That's right. We do need to attempt to keep as much of the end-to-end functionality intact as is possible. Of course people can add rules to allow and disallow various kinds of traffic flows, but it is in everyone's best interests to keep the translation component and firewall components as separate as possible. Jari From dwing@cisco.com Fri Feb 20 11:12:25 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93E1628C14B for ; Fri, 20 Feb 2009 11:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 Je2l4Uah5Ubw for ; Fri, 20 Feb 2009 11:12:24 -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 A14873A68BB for ; Fri, 20 Feb 2009 11:12:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,242,1233532800"; d="scan'208";a="145295854" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 20 Feb 2009 19:12:39 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n1KJCdCk022082; Fri, 20 Feb 2009 11:12:39 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n1KJCcYT003944; Fri, 20 Feb 2009 19:12:38 GMT From: "Dan Wing" To: "'Jari Arkko'" , "'marcelo bagnulo braun'" References: <4975B691.2040009@it.uc3m.es> <48771572-B013-4E20-98C3-C475B3A22E92@magma.ca> <4991453D.7020900@it.uc3m.es> <499A964F.9070707@it.uc3m.es> <499EF6A4.70204@piuha.net> Date: Fri, 20 Feb 2009 11:12:38 -0800 Message-ID: <0a1901c9938f$3286c7f0$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 Thread-Index: AcmTiUHEbJxBnQX3TQCSAyGi5VvM0AAAJcQA In-Reply-To: <499EF6A4.70204@piuha.net> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1409; t=1235157159; x=1236021159; c=relaxed/simple; s=sjdkim3002; 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]=20Pref64=20nature=20and=20refe rral=20support. |Sender:=20; bh=XJBUMoYboO0O1sNE4+aG/Wu/RjzXk8SJ7fqU2W5UDt4=; b=Tl5bnap4P5J82uk02VPewA9lZ18ibB3muxku1fOL7wNo+N4BW3APCY9afi Cjac6Z7DLq0bMypaHLLT9a5BqmHGnP8r+Hiuc45pHy6wF4pTxXYS3GQvXi5z gkNTvU5qxs; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'Behave WG' , 'Philip Matthews' Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 19:12:25 -0000 Jari Arkko wrote: > Marcelo, > > > Now, i can understand that people can have security policy that > > prevents this from working and i am fine with that. > > the thing about security policy is that other sits can have a > > different policy and referrals would work for them. It is > > actually an > > operation choice of the site and that is good. > > IMHO it is a completelly different thing to make a > > technology that by > > design breaks referrals, i simply don't think this is a good idea > > That's right. We do need to attempt to keep as much of the end-to-end > functionality intact as is possible. Of course people can add > rules to allow and disallow various kinds of traffic flows, but > it is in everyone's best interests to keep the translation > component and firewall components as separate as possible. Referrals across a translator seem difficult at best though: at least two applications that commonly do referrals (SIP and BitTorrent) only use IP addresses, but referring a synthetic IPv6 address to an IPv4 host will never work. Referring a synthetic IPv6 address to an IPv6 host belonging to another ISP will not work (an ISP is unlikely to operate NAT64 devices for the benefit of any IPv6 host on the Internet that wants to use it). I have more details written up on this topic and will write an I-D to present in San Francisco. -d From jari.arkko@piuha.net Fri Feb 20 11:32:59 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D2553A6BEC for ; Fri, 20 Feb 2009 11:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 vJMy9N-UshQw for ; Fri, 20 Feb 2009 11:32:58 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 3852B3A688F for ; Fri, 20 Feb 2009 11:32:58 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id E21C2198770; Fri, 20 Feb 2009 21:33:11 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 7B1561986EF; Fri, 20 Feb 2009 21:33:11 +0200 (EET) Message-ID: <499F0577.3000003@piuha.net> Date: Fri, 20 Feb 2009 21:33:11 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Dan Wing References: <4975B691.2040009@it.uc3m.es> <48771572-B013-4E20-98C3-C475B3A22E92@magma.ca> <4991453D.7020900@it.uc3m.es> <499A964F.9070707@it.uc3m.es> <499EF6A4.70204@piuha.net> <0a1901c9938f$3286c7f0$c2f0200a@cisco.com> In-Reply-To: <0a1901c9938f$3286c7f0$c2f0200a@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: 'Behave WG' , 'Philip Matthews' Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 19:32:59 -0000 Dan, > Referrals across a translator seem difficult at best though: > at least two applications that commonly do referrals (SIP and > BitTorrent) only use IP addresses, but referring a synthetic > IPv6 address to an IPv4 host will never work. Referring a > synthetic IPv6 address to an IPv6 host belonging to another > ISP will not work (an ISP is unlikely to operate NAT64 devices > for the benefit of any IPv6 host on the Internet that wants to > use it). > There are a few different cases depending on what version is used on the node that gives out the reference, where it is received, and where it points to. It seems that there are a few cases that would potentially work, though I do agree that there are many work that would not. For instance, lets say you and I are both in IPv6-only networks at different sites and I pass you Marcelo's address. Marcelo is in the IPv4 space, so I give you prefix64::marcelo. If you and I happen to use the same prefix64 to represent IPv4 space, then it seems possible for you to contact Marcelo. > I have more details written up on this topic and will write > an I-D to present in San Francisco. > Good -- looking forward to that. I guess Marcelo's draft on prefixes will also be relevant here. Jari From dwing@cisco.com Fri Feb 20 12:06:44 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84E63A67BD for ; Fri, 20 Feb 2009 12:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 EvD64fsp6sMg for ; Fri, 20 Feb 2009 12:06:43 -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 B80B43A6858 for ; Fri, 20 Feb 2009 12:06:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,242,1233532800"; d="scan'208";a="253711725" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 20 Feb 2009 20:06:58 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1KK6wAr006181; Fri, 20 Feb 2009 12:06:58 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n1KK6wtA000234; Fri, 20 Feb 2009 20:06:58 GMT From: "Dan Wing" To: "'Jari Arkko'" References: <4975B691.2040009@it.uc3m.es> <48771572-B013-4E20-98C3-C475B3A22E92@magma.ca> <4991453D.7020900@it.uc3m.es> <499A964F.9070707@it.uc3m.es><499EF6A4.70204@piuha.net><0a1901c9938f$3286c7f0$c2f0200a@cisco.com> <499F0577.3000003@piuha.net> Date: Fri, 20 Feb 2009 12:06:58 -0800 Message-ID: <0a4f01c99396$c92fa490$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 Thread-Index: AcmTkhcrOPI+XFW+Sp6g1WshOQxehgAAorJw In-Reply-To: <499F0577.3000003@piuha.net> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2357; t=1235160418; x=1236024418; 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[BEHAVE]=20Pref64=20nature=20and=20refe rral=20support. |Sender:=20; bh=aRBPwFleBUc2ixlwr84WmW5jwJSIInD3WM4ZCi8UY+E=; b=kt6fW0TXSL7iEjkAjS7scJABqhzc8e1YG7INZDBaIEScOdMpZGjg6ivHL5 dAjwrhJ/O4AQYL75y5JTs2h8e/vQbvzfFrTDEFX5qdeGtrKpkKCddTeSqLKD Fo9kXwPNsf; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'Behave WG' , 'Philip Matthews' Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 20:06:44 -0000 > > Referrals across a translator seem difficult at best though: > > at least two applications that commonly do referrals (SIP and > > BitTorrent) only use IP addresses, but referring a synthetic > > IPv6 address to an IPv4 host will never work. Referring a > > synthetic IPv6 address to an IPv6 host belonging to another > > ISP will not work (an ISP is unlikely to operate NAT64 devices > > for the benefit of any IPv6 host on the Internet that wants to > > use it). > > There are a few different cases depending on what version is > used on the > node that gives out the reference, where it is received, and where it > points to. It seems that there are a few cases that would potentially > work, though I do agree that there are many work that would not. > > For instance, lets say you and I are both in IPv6-only networks at > different sites and I pass you Marcelo's address. Marcelo is > in the IPv4 > space, so I give you prefix64::marcelo. If you and I happen > to use the > same prefix64 to represent IPv4 space, then it seems possible > for you to contact Marcelo. Yes, that case works because both of our ISPs have deployed NAT64 devices and both use the same well-known prefix. But if I am IPv4-only, that IPv6 address won't be useful to me. If I am dual-stack, that IPv6 address won't work -- at least, not until my ISP provides me with a NAT64 device using that same well-known prefix. Considering today's Internet users are somewhere around ~95% IPv4-only and 5% dual-stack this means that initial deployments of NAT64 will break referrals across the translator. It is only after NAT64 has been deployed in both my network and in your network, and both using a well-known prefix, that we could have IPv6 referrals work between IPv4 and IPv6. Question: what applications do referrals? BitTorrent and SIP come to my mind, and both do referrals using IP addresses (not DNS names). (To be precise, SIP's use of SDP does referrals using IP addresses; SIP's message routing usually uses DNS names). Are there others that we could characterize? > > I have more details written up on this topic and will write > > an I-D to present in San Francisco. > > Good -- looking forward to that. I guess Marcelo's draft on prefixes > will also be relevant here. Yes. -d From charliep@wichorus.com Fri Feb 20 13:21:19 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B2613A6A6D for ; Fri, 20 Feb 2009 13:21:19 -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 b8fkfhW4JOyf for ; Fri, 20 Feb 2009 13:21:18 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 00E4D3A6960 for ; Fri, 20 Feb 2009 13:21:17 -0800 (PST) Received: from [99.51.129.145] (helo=[10.166.254.13]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LacoM-00021S-Hf for behave@ietf.org; Fri, 20 Feb 2009 16:21:30 -0500 Message-ID: <499F1ED9.9010006@wichorus.com> Date: Fri, 20 Feb 2009 13:21:29 -0800 From: "Charles E. Perkins" Organization: WiChorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: behave@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52b9c87ed59cda5c9048b8e71a2fc8524a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Subject: [BEHAVE] Source-IP NAT proposal, updated X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 21:21:19 -0000 Hello folks, Just before the last IETF, I started to make a proposal for enabling incoming traffic flows from the Internet to traverse a NAT boundary for delivery to IPv6-only destinations. I really think this is crucial to really enable transition to IPv6, because I don't see how a sensible business owner or webmaster could expect to manage their clients and customers without enabling service to such incoming data flows. I have updated the proposal and put some related files on my website: General-source_IP-NAT.ppt draft-perkins-sourceIPnat-00.txt run_bigtest.sh variations.Timeouts (many, many grep commands) I'll submit the Internet Draft later today. The performance results I have gotten vary across a wide range, which just means that for some situations the approach isn't very sensible. For instance, if you have only a single NAT interface address and hundreds of DNS Requests arriving every minute, my algorithm ends up having to reject most of the incoming flows. Or if you only have one destination, you don't really need to have a big bank of NAT addresses undergoing dynamic random allocations. But, for reasonable flow request rates and other parameter choices, the results are very good. And this is pretty bare-bones, without some potential optimizations that I have started to design. As it turns out, the most important factor affecting performance is the rate of arrival of DNS Requests, which in my simulation I treat as requests for flow allocation. Anyway, I would appreciate any comments on the evolved approach and draft. One thing I would like to emphasize: I expect that this approach is compatible with all proposals for managing outgoing flows. So this does not really have to compete with such existing proposals. Regards, Charlie P. From charliep@wichorus.com Fri Feb 20 13:23:56 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC40C28C1FA for ; Fri, 20 Feb 2009 13:23:56 -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 yDunTaPqcDe2 for ; Fri, 20 Feb 2009 13:23:55 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 8267D3A6A6D for ; Fri, 20 Feb 2009 13:23:55 -0800 (PST) Received: from [99.51.129.145] (helo=[10.166.254.13]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Lacqu-00011q-8B for behave@ietf.org; Fri, 20 Feb 2009 16:24:08 -0500 Message-ID: <499F1F77.3030806@wichorus.com> Date: Fri, 20 Feb 2009 13:24:07 -0800 From: "Charles E. Perkins" Organization: WiChorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: behave@ietf.org References: <499F1ED9.9010006@wichorus.com> In-Reply-To: <499F1ED9.9010006@wichorus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f520d23a3a072f22f89ed9b11faa3ddca83350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Subject: Re: [BEHAVE] Source-IP NAT proposal, updated X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 21:23:56 -0000 Hello again folks, I forgot to mention: the directory for the files listed below is as follows: http://www.psg.com/~charliep/txt/ietf74/ Sorry about the omission! Regards, Charlie P. Charles E. Perkins wrote: > > Hello folks, > > Just before the last IETF, I started to make a proposal for > enabling incoming traffic flows from the Internet to traverse > a NAT boundary for delivery to IPv6-only destinations. > I really think this is crucial to really enable transition to IPv6, > because I don't see how a sensible business owner or > webmaster could expect to manage their clients and > customers without enabling service to such incoming data > flows. > > I have updated the proposal and put some related files on > my website: > General-source_IP-NAT.ppt > draft-perkins-sourceIPnat-00.txt > run_bigtest.sh > variations.Timeouts (many, many grep commands) > > I'll submit the Internet Draft later today. The performance > results I have gotten vary across a wide range, which just > means that for some situations the approach isn't very > sensible. For instance, if you have only a single NAT > interface address and hundreds of DNS Requests arriving > every minute, my algorithm ends up having to reject most > of the incoming flows. Or if you only have one destination, > you don't really need to have a big bank of NAT addresses > undergoing dynamic random allocations. But, for reasonable > flow request rates and other parameter choices, the results > are very good. And this is pretty bare-bones, without some > potential optimizations that I have started to design. As it > turns out, the most important factor affecting performance > is the rate of arrival of DNS Requests, which in my > simulation I treat as requests for flow allocation. > > Anyway, I would appreciate any comments on the > evolved approach and draft. One thing I would like > to emphasize: I expect that this approach is compatible > with all proposals for managing outgoing flows. So this > does not really have to compete with such existing > proposals. > > Regards, > Charlie P. > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dthaler@windows.microsoft.com Fri Feb 20 15:46:41 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75E783A68F8 for ; Fri, 20 Feb 2009 15:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.394 X-Spam-Level: X-Spam-Status: No, score=-110.394 tagged_above=-999 required=5 tests=[AWL=0.205, 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 gY3oNfnTbwTI for ; Fri, 20 Feb 2009 15:46:40 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 45F7F3A6875 for ; Fri, 20 Feb 2009 15:46:40 -0800 (PST) Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.18.48) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.99.4; Fri, 20 Feb 2009 15:46:54 -0800 Received: from TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com (157.54.18.79) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.18.48) with Microsoft SMTP Server id 8.2.99.4; Fri, 20 Feb 2009 15:46:54 -0800 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::75be:c82f:ae04:55bf]) by TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.79]) with mapi; Fri, 20 Feb 2009 15:46:53 -0800 From: Dave Thaler To: "Charles E. Perkins" Date: Fri, 20 Feb 2009 15:46:53 -0800 Thread-Topic: [BEHAVE] Source-IP NAT proposal, updated Thread-Index: AcmToemFRjW4D0imTEKx0LDtyCXlogADeaOQ Message-ID: References: <499F1ED9.9010006@wichorus.com> <499F1F77.3030806@wichorus.com> In-Reply-To: <499F1F77.3030806@wichorus.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Source-IP NAT proposal, updated X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 23:46:41 -0000 Some comments on the draft: * As with any other v4/6 translation draft, I would recommend having some discussion on which issues discussed in RFC 4966 still apply to this proposal and which don't. * Regarding setting the cache time to 0 or 1, we've heard anecdotally that there are DNS servers that don't honor cache lifetimes of less than 30 seconds or so. I think someone was doing a study to see how common this is in the Internet and I hope to see some stats by IETF. If this is a problem you might need a way to establish multiple remote IPs within 30 seconds for the same allocation. * One issue is if the same IPv4-only host wants to talk to multiple IPv6-only hosts. When generating the DNS responses you have to ensure that you allocate different v6dev-IPv4 addresses. However the problem is that you have to pick the address at the time of the DNS response but you don't see the IPv4 host's address until later and hence you cannot reliably pick a different v6dev-IPv4 address. As a result the scenario where the same IPv4-only host tries to resolve multiple names can fail randomly. Note I didn't follow the discussion of source ports on page 7 since they're not available at the time of the DNS query. -Dave > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Charles E. Perkins > Sent: Friday, February 20, 2009 1:24 PM > To: behave@ietf.org > Subject: Re: [BEHAVE] Source-IP NAT proposal, updated > > > Hello again folks, > > I forgot to mention: the directory for the files > listed below is as follows: > http://www.psg.com/~charliep/txt/ietf74/ > > Sorry about the omission! > > Regards, > Charlie P. > > > Charles E. Perkins wrote: > > > > Hello folks, > > > > Just before the last IETF, I started to make a proposal for > > enabling incoming traffic flows from the Internet to traverse > > a NAT boundary for delivery to IPv6-only destinations. > > I really think this is crucial to really enable transition to IPv6, > > because I don't see how a sensible business owner or > > webmaster could expect to manage their clients and > > customers without enabling service to such incoming data > > flows. > > > > I have updated the proposal and put some related files on > > my website: > > General-source_IP-NAT.ppt > > draft-perkins-sourceIPnat-00.txt > > run_bigtest.sh > > variations.Timeouts (many, many grep commands) > > > > I'll submit the Internet Draft later today. The performance > > results I have gotten vary across a wide range, which just > > means that for some situations the approach isn't very > > sensible. For instance, if you have only a single NAT > > interface address and hundreds of DNS Requests arriving > > every minute, my algorithm ends up having to reject most > > of the incoming flows. Or if you only have one destination, > > you don't really need to have a big bank of NAT addresses > > undergoing dynamic random allocations. But, for reasonable > > flow request rates and other parameter choices, the results > > are very good. And this is pretty bare-bones, without some > > potential optimizations that I have started to design. As it > > turns out, the most important factor affecting performance > > is the rate of arrival of DNS Requests, which in my > > simulation I treat as requests for flow allocation. > > > > Anyway, I would appreciate any comments on the > > evolved approach and draft. One thing I would like > > to emphasize: I expect that this approach is compatible > > with all proposals for managing outgoing flows. So this > > does not really have to compete with such existing > > proposals. > > > > Regards, > > Charlie P. > > > > _______________________________________________ > > 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 charliep@wichorus.com Fri Feb 20 16:08:09 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BA5428C199 for ; Fri, 20 Feb 2009 16:08:09 -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 zzzctVN11BT2 for ; Fri, 20 Feb 2009 16:08:08 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 6A1A328C16D for ; Fri, 20 Feb 2009 16:08:08 -0800 (PST) Received: from [99.51.129.145] (helo=[10.166.254.13]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LafPq-0004O3-Uy; Fri, 20 Feb 2009 19:08:23 -0500 Message-ID: <499F45F4.3060701@wichorus.com> Date: Fri, 20 Feb 2009 16:08:20 -0800 From: "Charles E. Perkins" Organization: WiChorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dave Thaler References: <499F1ED9.9010006@wichorus.com> <499F1F77.3030806@wichorus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f526a5fdf7e9adf7521c43f74b37fa4206b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Source-IP NAT proposal, updated X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 00:08:09 -0000 Hello Dave, Thanks for your quick review. I have a few comments, below. But first I'd like to ask whether you agree with my basic contention. Namely, that it is really quite important to enable incoming flows, since otherwise IPv6-only websites would be unlikely to thrive. Dave Thaler wrote: > Some comments on the draft: > > * As with any other v4/6 translation draft, I would recommend > having some discussion on which issues discussed in RFC 4966 > still apply to this proposal and which don't. > This is a good idea. I'll do that for the next revision. > * Regarding setting the cache time to 0 or 1, we've heard > anecdotally that there are DNS servers that don't honor cache > lifetimes of less than 30 seconds or so. I think someone was > doing a study to see how common this is in the Internet > and I hope to see some stats by IETF. If this is a problem > you might need a way to establish multiple remote IPs within > 30 seconds for the same allocation. > Actually, I don't think 30 seconds will be a problem. 15 minutes or an hour might be a problem. > * One issue is if the same IPv4-only host wants to talk to > multiple IPv6-only hosts. When generating the DNS responses > you have to ensure that you allocate different v6dev-IPv4 > addresses. However the problem is that you have to pick > the address at the time of the DNS response but you don't > see the IPv4 host's address until later and hence you cannot > reliably pick a different v6dev-IPv4 address. As a result > the scenario where the same IPv4-only host tries to resolve > multiple names can fail randomly. This is a problem, and the best solution I have for it is to encourage such IPv6 destinations to be allocated from different NATv4 interface addresses. I think that is doable. On the data I have tested, this situation arises only infrequently, but it does happen. I wonder if the source address of the DNS Request would be at all useful as a very coarse indicator of IP address of the actual source. If so, then perhaps that could be exploited beneficially. > Note I didn't follow > the discussion of source ports on page 7 since they're > not available at the time of the DNS query. > No, I just meant that the source port, if it exists, should be stored along with the source IP address so that two sources from behind a NAT box would have a chance of both establishing flows through the same NATv4 interface address. Regards, Charlie P. From dthaler@windows.microsoft.com Fri Feb 20 16:22:41 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5411428C18A for ; Fri, 20 Feb 2009 16:22:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.413 X-Spam-Level: X-Spam-Status: No, score=-110.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 a4RuX47DfS7J for ; Fri, 20 Feb 2009 16:22:40 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id A52523A6806 for ; Fri, 20 Feb 2009 16:22:40 -0800 (PST) Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Fri, 20 Feb 2009 16:22:49 -0800 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.18.32) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) with Microsoft SMTP Server id 8.2.99.4; Fri, 20 Feb 2009 16:22:49 -0800 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::75be:c82f:ae04:55bf]) by tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.32]) with mapi; Fri, 20 Feb 2009 16:24:40 -0800 From: Dave Thaler To: "Charles E. Perkins" Date: Fri, 20 Feb 2009 16:22:48 -0800 Thread-Topic: [BEHAVE] Source-IP NAT proposal, updated Thread-Index: AcmTuN92sp7evT5MSxqJWpFQMV4aPwAAEppA Message-ID: References: <499F1ED9.9010006@wichorus.com> <499F1F77.3030806@wichorus.com> <499F45F4.3060701@wichorus.com> In-Reply-To: <499F45F4.3060701@wichorus.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Source-IP NAT proposal, updated X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 00:22:41 -0000 Charlie Perkins wrote: > But first I'd like to ask whether you agree with my basic contention. > Namely, that it is really quite important to enable incoming flows, > since otherwise IPv6-only websites would be unlikely to thrive. I think all the scenarios are important, although some are more urgent than others. I am glad to see proposals addressing this case, so thanks for doing this. It would be great if you could fill out the prioritization doodle I recently sent to the list, since you're clearly a Yes for the question "IPv4 Internet to an IPv6 network: I have or am planning to implement code = for this scenario" -Dave From Mark_Andrews@isc.org Fri Feb 20 16:53:47 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91CAD3A6806 for ; Fri, 20 Feb 2009 16:53:47 -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 PFqx9Luv74TS for ; Fri, 20 Feb 2009 16:53:46 -0800 (PST) Received: from mx.isc.org (mx.isc.org [IPv6:2001:4f8:0:2::1c]) by core3.amsl.com (Postfix) with ESMTP id 5D64E3A657C for ; Fri, 20 Feb 2009 16:53:45 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id BAB2F11401E; Sat, 21 Feb 2009 00:53:47 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 15FEFE6072; Sat, 21 Feb 2009 00:53:46 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n1L0rWRO061664; Sat, 21 Feb 2009 11:53:43 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200902210053.n1L0rWRO061664@drugs.dv.isc.org> To: Dave Thaler From: Mark Andrews In-reply-to: Your message of "Fri, 20 Feb 2009 15:46:53 -0800." Date: Sat, 21 Feb 2009 11:53:32 +1100 Sender: Mark_Andrews@isc.org Cc: "Charles E. Perkins" , "behave@ietf.org" Subject: Re: [BEHAVE] Source-IP NAT proposal, updated X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 00:53:47 -0000 In message , Dave Thaler writes: > Some comments on the draft: > > * As with any other v4/6 translation draft, I would recommend > having some discussion on which issues discussed in RFC 4966 > still apply to this proposal and which don't. > > * Regarding setting the cache time to 0 or 1, we've heard > anecdotally that there are DNS servers that don't honor cache > lifetimes of less than 30 seconds or so. I think someone was > doing a study to see how common this is in the Internet > and I hope to see some stats by IETF. If this is a problem > you might need a way to establish multiple remote IPs within > 30 seconds for the same allocation. I keep hearing people say this but I've yet to see anyone name a DNS server that does this. I think this can be classes as a urban legend until proved otherwise. There are lots of applications that don't honour the ttls but there is not a lot we can do about them. The ttl should be set to the lesser of the ttl of the AAAA record and the time the nat box waits for the first connection. The latter time should be returned to the DNS server as part of the address assignment. This later time also needs to be the hold time after boot for the NAT box if it doesn't maintain state in a non-volitile memory. This allows the DNS caches to do their jobs. I've seen DNS caches get pounded into the ground with early NAT-PT implementations which set the synthesised address ttl to 0. Similarly for DNAME synthesis. We had people requesting that we add a minimum ttl setting to our caches to work around this. We refused and said they should get their NAT-PT box fixed. > * One issue is if the same IPv4-only host wants to talk to > multiple IPv6-only hosts. When generating the DNS responses > you have to ensure that you allocate different v6dev-IPv4 > addresses. However the problem is that you have to pick > the address at the time of the DNS response but you don't > see the IPv4 host's address until later and hence you cannot > reliably pick a different v6dev-IPv4 address. As a result > the scenario where the same IPv4-only host tries to resolve > multiple names can fail randomly. Note I didn't follow > the discussion of source ports on page 7 since they're > not available at the time of the DNS query. > > -Dave I also don't see how overloading can work. DNS responses are not one-to-one. They are one-to-many. Mark > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of Charles E. Perkins > > Sent: Friday, February 20, 2009 1:24 PM > > To: behave@ietf.org > > Subject: Re: [BEHAVE] Source-IP NAT proposal, updated > > > > > > Hello again folks, > > > > I forgot to mention: the directory for the files > > listed below is as follows: > > http://www.psg.com/~charliep/txt/ietf74/ > > > > Sorry about the omission! > > > > Regards, > > Charlie P. > > > > > > Charles E. Perkins wrote: > > > > > > Hello folks, > > > > > > Just before the last IETF, I started to make a proposal for > > > enabling incoming traffic flows from the Internet to traverse > > > a NAT boundary for delivery to IPv6-only destinations. > > > I really think this is crucial to really enable transition to IPv6, > > > because I don't see how a sensible business owner or > > > webmaster could expect to manage their clients and > > > customers without enabling service to such incoming data > > > flows. > > > > > > I have updated the proposal and put some related files on > > > my website: > > > General-source_IP-NAT.ppt > > > draft-perkins-sourceIPnat-00.txt > > > run_bigtest.sh > > > variations.Timeouts (many, many grep commands) > > > > > > I'll submit the Internet Draft later today. The performance > > > results I have gotten vary across a wide range, which just > > > means that for some situations the approach isn't very > > > sensible. For instance, if you have only a single NAT > > > interface address and hundreds of DNS Requests arriving > > > every minute, my algorithm ends up having to reject most > > > of the incoming flows. Or if you only have one destination, > > > you don't really need to have a big bank of NAT addresses > > > undergoing dynamic random allocations. But, for reasonable > > > flow request rates and other parameter choices, the results > > > are very good. And this is pretty bare-bones, without some > > > potential optimizations that I have started to design. As it > > > turns out, the most important factor affecting performance > > > is the rate of arrival of DNS Requests, which in my > > > simulation I treat as requests for flow allocation. > > > > > > Anyway, I would appreciate any comments on the > > > evolved approach and draft. One thing I would like > > > to emphasize: I expect that this approach is compatible > > > with all proposals for managing outgoing flows. So this > > > does not really have to compete with such existing > > > proposals. > > > > > > Regards, > > > Charlie P. > > > > > > _______________________________________________ > > > 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 > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From charliep@wichorus.com Fri Feb 20 17:46:57 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFAD23A6816 for ; Fri, 20 Feb 2009 17:46:57 -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=[AWL=0.000, 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 k0GU6yNs-4qR for ; Fri, 20 Feb 2009 17:46:57 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 1CF1E3A67A5 for ; Fri, 20 Feb 2009 17:46:57 -0800 (PST) Received: from [99.51.74.16] (helo=[192.168.1.108]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LagxT-0004rK-IU; Fri, 20 Feb 2009 20:47:12 -0500 Message-ID: <499F5D1E.4050803@wichorus.com> Date: Fri, 20 Feb 2009 17:47:10 -0800 From: "Charles E. Perkins" Organization: WiChorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Mark Andrews References: <200902210053.n1L0rWRO061664@drugs.dv.isc.org> In-Reply-To: <200902210053.n1L0rWRO061664@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5288ea1f3ac4155bb4d83e8cdd091fc7fd350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Source-IP NAT proposal, updated X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 01:46:57 -0000 Hello Mark, Mark Andrews wrote: >> * One issue is if the same IPv4-only host wants to talk to >> multiple IPv6-only hosts. When generating the DNS responses >> you have to ensure that you allocate different v6dev-IPv4 >> addresses. ... > I also don't see how overloading can work. DNS responses > are not one-to-one. They are one-to-many. > Do you mean that some source hosts would get the response without having issued a DNS Request? Regards, Charlie P. From dthaler@windows.microsoft.com Fri Feb 20 18:03:28 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E2C3A67A5 for ; Fri, 20 Feb 2009 18:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.441 X-Spam-Level: X-Spam-Status: No, score=-110.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 vYRCq0MMf3kU for ; Fri, 20 Feb 2009 18:03:28 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id E9E003A6403 for ; Fri, 20 Feb 2009 18:03:27 -0800 (PST) Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.99.4; Fri, 20 Feb 2009 18:03:42 -0800 Received: from TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com (157.54.18.79) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) with Microsoft SMTP Server id 8.2.99.4; Fri, 20 Feb 2009 18:03:42 -0800 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::75be:c82f:ae04:55bf]) by TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.79]) with mapi; Fri, 20 Feb 2009 18:03:42 -0800 From: Dave Thaler To: "Charles E. Perkins" , Mark Andrews Date: Fri, 20 Feb 2009 18:03:41 -0800 Thread-Topic: [BEHAVE] Source-IP NAT proposal, updated Thread-Index: AcmTxpm1xBoE6X7WT8OvkzL6iom19AAAddIA Message-ID: References: <200902210053.n1L0rWRO061664@drugs.dv.isc.org> <499F5D1E.4050803@wichorus.com> In-Reply-To: <499F5D1E.4050803@wichorus.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Source-IP NAT proposal, updated X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 02:03:28 -0000 Charlie Perkins wrote: > Mark Andrews wrote: > >> * One issue is if the same IPv4-only host wants to talk to > >> multiple IPv6-only hosts. When generating the DNS responses > >> you have to ensure that you allocate different v6dev-IPv4 > >> addresses. ... > > I also don't see how overloading can work. DNS responses > > are not one-to-one. They are one-to-many. > > > > Do you mean that some source hosts would > get the response without having issued a DNS Request? if there is caching, then certainly without the authoritative server seeing the request. -Dave From Mark_Andrews@isc.org Fri Feb 20 19:02:10 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF4FF3A6885 for ; Fri, 20 Feb 2009 19:02:10 -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 tvpZpTDZDte2 for ; Fri, 20 Feb 2009 19:02:10 -0800 (PST) Received: from mx.isc.org (mx.isc.org [IPv6:2001:4f8:0:2::1c]) by core3.amsl.com (Postfix) with ESMTP id 3538A3A68DB for ; Fri, 20 Feb 2009 19:02:08 -0800 (PST) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id 85D68114090; Sat, 21 Feb 2009 03:02:20 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id BBB77E6074; Sat, 21 Feb 2009 03:02:19 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n1L32FRM062640; Sat, 21 Feb 2009 14:02:15 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200902210302.n1L32FRM062640@drugs.dv.isc.org> To: Dave Thaler From: Mark Andrews In-reply-to: Your message of "Fri, 20 Feb 2009 18:03:41 -0800." Date: Sat, 21 Feb 2009 14:02:15 +1100 Sender: Mark_Andrews@isc.org Cc: "Charles E. Perkins" , "behave@ietf.org" Subject: Re: [BEHAVE] Source-IP NAT proposal, updated X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 03:02:10 -0000 In message , Dave Thaler writes: > Charlie Perkins wrote: > > Mark Andrews wrote: > > >> * One issue is if the same IPv4-only host wants to talk to > > >> multiple IPv6-only hosts. When generating the DNS responses > > >> you have to ensure that you allocate different v6dev-IPv4 > > >> addresses. ... > > > I also don't see how overloading can work. DNS responses > > > are not one-to-one. They are one-to-many. > > > > > > > Do you mean that some source hosts would > > get the response without having issued a DNS Request? > > if there is caching, then certainly without the authoritative server > seeing the request. > > -Dave Even with 0 ttl they can be one-to-many. Caching nameservers match new queries with those that are in the process of being answered then send the response to multiple clients. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From fred@cisco.com Sat Feb 21 17:23:03 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A7263A6985 for ; Sat, 21 Feb 2009 17:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.484 X-Spam-Level: X-Spam-Status: No, score=-106.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 meopOeJ9XtaD for ; Sat, 21 Feb 2009 17:23:02 -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 21F143A677E for ; Sat, 21 Feb 2009 17:23:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,247,1233532800"; d="scan'208";a="254328157" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 22 Feb 2009 01:23:18 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n1M1NIhf020942 for ; Sat, 21 Feb 2009 17:23:18 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n1M1NIB3022628 for ; Sun, 22 Feb 2009 01:23:18 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Feb 2009 17:23:18 -0800 Received: from stealth-10-32-244-221.cisco.com ([10.32.244.221]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Feb 2009 17:23:18 -0800 Message-Id: <788EFA73-C516-435D-A156-A0614E9ECA7B@cisco.com> From: Fred Baker To: "behave@ietf.org WG" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 21 Feb 2009 17:23:17 -0800 References: <20090222012026.621A33A69B2@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 22 Feb 2009 01:23:18.0286 (UTC) FILETIME=[24582AE0:01C9948C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2973; t=1235265798; x=1236129798; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Fwd=3A=20New=20Version=20Notification=20for=20= 20draft-baker-behave-v4v6-translation-02=20 |Sender:=20; bh=xUGUog7ob5R5EewHMZn1Icoc3jtxF1oM9Zff5LXtEEo=; b=NQ7yh2eUFX5h+tC8joA0o8pEXtU8xpp6s4jTCQ1By3XPDeLgcg39COAM8F 3hFjh4uM04efKbii7vtI4a2F03Sb8SdWMvcmpB2pH29cD/vwy3PqhMhiP3GE cmCntv0aeY; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [BEHAVE] Fwd: New Version Notification for draft-baker-behave-v4v6-translation-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 01:23:03 -0000 Looking for comments, obviously. Begin forwarded message: > From: IETF I-D Submission Tool > Date: February 21, 2009 5:20:26 PM PST > To: fred@cisco.com > Subject: New Version Notification for draft-baker-behave-v4v6- > translation-02 > > > A new version of I-D, draft-baker-behave-v4v6-translation-02.txt has > been successfuly submitted by Fred Baker and posted to the IETF > repository. > > Filename: draft-baker-behave-v4v6-translation > Revision: 02 > Title: IP/ICMP Translation Algorithm > Creation_date: 2009-02-21 > WG ID: Independent Submission > Number_of_pages: 23 > > Abstract: > This document specifies an update to the Stateless IP/ICMP > Translation Algorithm (SIIT) described in RFC 2765. The algorithm > translates between IPv4 and IPv6 packet headers (including ICMP > headers). > > This specification addresses both a stateless and a stateful mode. > In the stateless mode, translation information is carried in the > address itself, permitting both IPv4->IPv6 and IPv6->IPv4 session > establishment with neither state nor configuration in the IP/ICMP > translator. In the stateful mode, translation state is maintained > between IPv4 address/transport_port tuples and IPv6 address/ > transport_port tuples, enabling IPv6 systems to open sessions with > IPv4 systems. The choice of operational mode is made by the operator > deploying the network and is critical to the operation of the > applications using it. > > Significant issues exist in the stateless and stateful modes that are > not addressed in this document, related to the address assignment and > the maintenance of the translation tables, respectively. This > document confines itself to the actual translation. > > Acknowledgement of previous work > > This document is a product of the 2008-2009 effort to define a > replacement for NAT-PT. It is an update to and directly derivative > from Erik Nordmark's [RFC2765], which similarly provides both > stateless and stateful translation between IPv4 [RFC0791] and IPv6 > [RFC2460], and between ICMPv4 [RFC0792] and ICMPv6 [RFC4443]. The > original document was a product of the NGTRANS working group. > > The changes in this document reflect five components: > > 1. Redescribing the network model to map to present and projected > > usage. > > 2. Moving the address format to the framework document, to > > coordinate with other drafts on the topic. > > 3. Description of both stateful and stateless operation. > > 4. Some changes in ICMP. > > 5. Updating references.Requirements > > The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, > SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this > document, are to be interpreted as described in [RFC2119]. > > > Comment: > Please help us to post this draft as an idividual submission. > Thanks. Xing Li > > The IETF Secretariat. > > From fred@cisco.com Sat Feb 21 17:23:20 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA4173A6A79 for ; Sat, 21 Feb 2009 17:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.491 X-Spam-Level: X-Spam-Status: No, score=-106.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 gy+ZjGWWpzQK for ; Sat, 21 Feb 2009 17:23:20 -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 10D0B3A6985 for ; Sat, 21 Feb 2009 17:23:20 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,247,1233532800"; d="scan'208";a="254328195" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 22 Feb 2009 01:23:36 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1M1NabQ006518 for ; Sat, 21 Feb 2009 17:23:36 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n1M1NaOk016154 for ; Sun, 22 Feb 2009 01:23:36 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Feb 2009 17:23:36 -0800 Received: from stealth-10-32-244-221.cisco.com ([10.32.244.221]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Feb 2009 17:23:35 -0800 Message-Id: <7F1100A2-0EA4-403D-9329-06BA2CC6EAE5@cisco.com> From: Fred Baker To: "behave@ietf.org WG" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 21 Feb 2009 17:23:35 -0800 References: <20090222012031.23ABE3A6781@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 22 Feb 2009 01:23:36.0114 (UTC) FILETIME=[2EF88120:01C9948C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1065; t=1235265816; x=1236129816; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Fwd=3A=20New=20Version=20Notification=20for=20= 20draft-baker-behave-v4v6-framework-01=20 |Sender:=20; bh=SMLvhaeeU6kdT2R8+2dCQn+BTBjSaCzY27+IUEKNrFI=; b=Ulh3WlzXQvSdQ1dAgEK4Ppf8aIFrxOpODmgIUSXZqIdUFjRvbb6BqRzrfe bLWbdX1RrV2f567P0nLLfrVTrEsprgzL7hIAi6kwmbwVgyS3FoA/kT9zFiKh cu52hIENMYOmh/Hw4b6Zb5IrmMbd36pKB/wo/wulbbwmPmag0eYiw=; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [BEHAVE] Fwd: New Version Notification for draft-baker-behave-v4v6-framework-01 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 01:23:20 -0000 Looking for comments, obviously. Begin forwarded message: > From: IETF I-D Submission Tool > Date: February 21, 2009 5:20:31 PM PST > To: fred@cisco.com > Subject: New Version Notification for draft-baker-behave-v4v6- > framework-01 > > > A new version of I-D, draft-baker-behave-v4v6-framework-01.txt has > been successfuly submitted by Fred Baker and posted to the IETF > repository. > > Filename: draft-baker-behave-v4v6-framework > Revision: 01 > Title: Framework for IPv4/IPv6 Translation > Creation_date: 2009-02-21 > WG ID: Independent Submission > Number_of_pages: 32 > > Abstract: > This note describes a framework for IPv4/IPv6 translation. This is > in the context of replacing NAT-PT, which was deprecated by RFC 4966, > and to enable networks to have IPv4 and IPv6 coexist in a somewhat > rational manner while transitioning to an IPv6 network. > > > Comment: > Please help us to post this draft as an idividual submission. > Thanks. Xing Li > > The IETF Secretariat. > > From dwing@cisco.com Sat Feb 21 22:22:33 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 388453A685B for ; Sat, 21 Feb 2009 22:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 C1vLkaMx9NgU for ; Sat, 21 Feb 2009 22:22:31 -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 CABBD3A682D for ; Sat, 21 Feb 2009 22:22:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,248,1233532800"; d="scan'208";a="254392943" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 22 Feb 2009 06:22:48 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n1M6Mmsc007534; Sat, 21 Feb 2009 22:22:48 -0800 Received: from dwingwxp01 ([10.21.86.51]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n1M6Mkhk011158; Sun, 22 Feb 2009 06:22:47 GMT From: "Dan Wing" To: "'Behave WG'" Date: Sat, 21 Feb 2009 22:22:43 -0800 Message-ID: <0c6301c994b5$f9d7ca30$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 Thread-Index: AcmUtfhyJ9puOoFtTXKgBM38ZHvo4Q== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1936; t=1235283768; x=1236147768; c=relaxed/simple; s=sjdkim3002; 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:=20BEHAVE=20status=20update |Sender:=20; bh=ClRWlS7vpGB14s9TD8cI73sRj3hdffAU+AVHvogJ5MU=; b=R7WB0Qm2zOlR/UdZosbAZtO82adeWYddCHFuqPN37gSDn5mOkUixZ8IxJI 9tFnvdcl/x/7tGeH6WJ5qsjTAdcR7jGROIYmKhQatO62YR3yu3QOkQUc/JL4 5KZnw8dz1d; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: behave-chairs@tools.ietf.org Subject: [BEHAVE] BEHAVE status update X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 06:22:33 -0000 An update on some of BEHAVE's activities -- IPv4/IPv6 translation, TURN, and TURN-TCP: IPv4/IPv6 Translation: - Dave recently sent a Doodle poll to help prioritize documents to adopt. However, as of Saturday night only 5 people have replied to this poll. We will meet our milestone "Determine relative prioritization of the four translation cases" at the San Francisco BEHAVE meeting. - Based on the result of the Doodle poll and the San Francisco meeting, we will work with Magnus on the next milestone which is "Determine what solutions(s) and components are needed to solve each of the four cases. Create new milestones for the solution(s) and the components." - WG documents have been submitted for the Framework document (with updated text) and the Translation document. We will accept them when we adopt new milestones for those items. - There has been substantial forward progress on the DNS64 document and feedback from DNS experts. The NAT64 document is also maturing. We will accept them when we adopt new milestones for those items. - Marcelo is now a co-author of draft-miyata-behave-prefix64 and has added text from the author's conference call and from some off-list discussions. I expect the new version will be published soon. - There has been substantial off-list discussion of Prefix64 around how referrals work (or break) depending on LIR or well-known prefix. This is likely to be discussed on San Francisco. TURN: - Philip is continuing to close issues raised during IETF last call with the working group. Once that completes the document will be ready for IESG review. TURN-TCP: - Simon Perreault, simon.perreault@viagenie.ca, has agreed to be the new editor of TURN-TCP. Thanks, Simon! -d From dwing@cisco.com Sat Feb 21 23:07:05 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85A603A691E for ; Sat, 21 Feb 2009 23:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 q9j+JRXVtz4r for ; Sat, 21 Feb 2009 23:07:04 -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 A2DE53A68C6 for ; Sat, 21 Feb 2009 23:07:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,248,1233532800"; d="scan'208";a="254405898" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 22 Feb 2009 07:07:21 +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 n1M77LVM002176; Sat, 21 Feb 2009 23:07:21 -0800 Received: from dwingwxp01 ([10.21.86.51]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n1M77Hxd025343; Sun, 22 Feb 2009 07:07:18 GMT From: "Dan Wing" To: "Behave WG" Date: Sat, 21 Feb 2009 23:07:14 -0800 Message-ID: <0c6601c994bc$3307ee10$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 Thread-Index: AcmUvDBc2CBXydr5Rnq+FSmMkqbXQg== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=563; t=1235286441; x=1236150441; 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:=20call=20for=20BEHAVE=20agenda=20items |Sender:=20; bh=WI2pWupSVe+02m37p4KFgrzRvn1IM/7t+AeIKk4b9uU=; b=EyGXf+jzrYzF0HarpK3+Bfjo8VfFPIGHiiVu8LPSLUw+HDdSi6+M5l1V3N EDIpduTopwng0/sCBTlxvbVr97gU2sFyoUUN336NOp1ScvJchyYhVUyEWkja XUg3YMNy2c; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: behave-chairs@tools.ietf.org Subject: [BEHAVE] call for BEHAVE agenda items X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 07:07:05 -0000 BEHAVE has a total of five hours at IETF74 (San Francisco). If you would like a slot to present please send the name(s) of the Internet-Drafts and the requested duration to the chairs. As a reminder there are two BoFs that cover topics that were discussed in BEHAVE's IETF73 (Minneapolis) meeting: SHARA (shared ports) and 6AI (IPv6 Address Independence, "NAT66"). Thus, BEHAVE will not cover those topics. We are working to resove the scheduling conflict between BEHAVE and 6AI that exists in the currently-posted draft agenda. -Dan and Dave From brian.e.carpenter@gmail.com Sun Feb 22 01:22:01 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 170FC28C188 for ; Sun, 22 Feb 2009 01:22:01 -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 n-kVrj+TY7nF for ; Sun, 22 Feb 2009 01:22:00 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by core3.amsl.com (Postfix) with ESMTP id 0350428C0E6 for ; Sun, 22 Feb 2009 01:21:59 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id 11so1032493tim.25 for ; Sun, 22 Feb 2009 01:22:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=o+Nkz+i/FcuHztmF3V8N0TifOBXpQcvvsnlsk06Xjvw=; b=A4PuYV1PwFMCIfVXHp4UroJK3gMXiqG0yJYGFmp8DJndJ9+226PZBgb0TilQ6gXv+B hwa57wMP2cAHcLYE9ul3Oq4+vpdW0kr2Y1XraVg6gQr91lg5GXetqO9CbWCGdw2yCPJU VNBLIXy8FYmyTbWlMPslu4fD6qpl9dOknJK/g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=We6rRRN4lf9jE/o/zeHOd4+QdHA0qSAY7pbW3d1CRLUJ4bIlRAWVee7RrHkrcGuCnT umHWFGsB6T4iU1wUwxvHWtc84iOAfS//DEMdjRGQuuiarmt0xyqPgPeZXMW6pwRgfjQm jNHdlwxDv4H574pbjPSm/yDA5ZDWCTs5QoNKk= Received: by 10.110.3.15 with SMTP id 15mr3976759tic.43.1235294534452; Sun, 22 Feb 2009 01:22:14 -0800 (PST) Received: from ?192.168.5.78? (koruout.airnz.co.nz [162.112.38.5]) by mx.google.com with ESMTPS id 22sm3857891tim.4.2009.02.22.01.22.11 (version=SSLv3 cipher=RC4-MD5); Sun, 22 Feb 2009 01:22:13 -0800 (PST) Message-ID: <49A11943.5070205@gmail.com> Date: Sun, 22 Feb 2009 22:22:11 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dan Wing References: <0c6301c994b5$f9d7ca30$c2f0200a@cisco.com> In-Reply-To: <0c6301c994b5$f9d7ca30$c2f0200a@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'Behave WG' , behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] BEHAVE status update X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 09:22:01 -0000 Hi Dan, Thanks for the clarity. I do have a couple of questions: On 2009-02-22 19:22, Dan Wing wrote: > An update on some of BEHAVE's activities -- IPv4/IPv6 translation, TURN, and > TURN-TCP: > > IPv4/IPv6 Translation: > > - Dave recently sent a Doodle poll to help prioritize documents > to adopt. However, as of Saturday night only 5 people have > replied to this poll. I read it as being addressed very specifically to implementors and operators, which will cut down the response rate. If you want responses from more people, Q3 ("Have you or are you planning to deploy...?") would need to be phrased somewhat differently. Or add a Q4 such as "Do you see a clear operational requirement for...?". > > We will meet our milestone "Determine relative > prioritization of the four translation cases" at the > San Francisco BEHAVE meeting. I have the impression that we don't have a current analysis document about these four scenarios, and reaching a decision just on the basis of the paragraphs in the charter and a doodle poll seems a bit casual. Section 1.5 of draft-baker-behave-v4v6-framework-01 does discuss two cases, with placeholders for two others, but they don't seem to be quite identical to the cases in the charter. Have I missed a document? Thanks Brian From philip_matthews@magma.ca Sun Feb 22 10:56:46 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7F563A684B for ; Sun, 22 Feb 2009 10:56:46 -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 XGavkZGbQrM9 for ; Sun, 22 Feb 2009 10:56:45 -0800 (PST) Received: from mail-05.primus.ca (mail8.primus.ca [216.254.141.175]) by core3.amsl.com (Postfix) with ESMTP id 947E13A67A8 for ; Sun, 22 Feb 2009 10:56:45 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1LbJVd-0007yh-2V; Sun, 22 Feb 2009 13:57:02 -0500 Message-Id: From: Philip Matthews To: Behave WG In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 22 Feb 2009 13:56:59 -0500 References: X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] Subject: Re: [BEHAVE] TURN: Magnus's ICMP proposal X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 18:56:46 -0000 In private e-mail exchanges, Magnus and I agreed that there didn't seem to be any WG support for this, so the proposal to add ICMP relaying to TURN has been dropped. - Philip On Wed, 4-Feb-09, at 16:15 , Philip Matthews wrote: > In his message to the mailing list on Jan 19, Magnus proposed to add > the following to the _preferred_ fragmentation behavior: > > If the server goes to send a packet with the DF bit set, either > because it was copied from the incoming packet (when this is > possible) or because the incoming packet included the DONT-FRAGMENT > attribute, and if the outgoing link's MTU will not permit the packet > to be transmitted without fragmentation, then the server sends an > ICMP message (Type=3, Code=4 (Fragmentation needed and DF set)) back > towards the sender of the incoming packet. > > Note that Magnus proposes to add this only to the preferred behavior > -- the alternate behavior would not include this. > > This preferred behavior would most likely require OS support -- I > don't know of any OSes that allow applications to send ICMP messages. > > > > Here are my thoughts on this proposal: > This proposes that the server generate an ICMP message when the > outgoing packet is too large, but does not propose that the server > relay ICMP messages. However, in order for the client to use an > ICMP-based Path MTU Discovery algorithm, I think the server would > have to do both. > > Consider a client that uses an ICMP-based Path MTU Discovery > algorithm. If the client uses a server that does NOT do this > proposal, then the client can only discover the MTU along the path > to the server. If the client uses a server that DOES do this > proposal, then the client can discover the MTU along the path to the > server, plus the server's outgoing link. However, in neither case > can the client discover the MTU along the rest of the path. > > By contrast, a client that uses a Path MTU Discovery algorithm that > is based on packet loss can detect the MTU along the entire path to > the peer (by using the DONT-FRAGMENT attribute). Furthermore, that > algorithm will also work through NATs that filter out ICMP messages > -- recall that the client is using TURN in the first place because > it is behind a "nasty" NAT, and I am speculating that "nasty" NATs > often don't relay ICMP message. > > (Cullen: Do you have any stats on the percentage of symmetric NATs > that relay ICMP messages?) > > For these reasons, I am wondering how useful this proposal would be. > > Does anyone else have any comments or insights? > > - Philip > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From marcelo@it.uc3m.es Sun Feb 22 12:45:57 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93AD128C128 for ; Sun, 22 Feb 2009 12:45:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.883 X-Spam-Level: X-Spam-Status: No, score=-5.883 tagged_above=-999 required=5 tests=[AWL=0.716, 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 P4-0JfndTgMo for ; Sun, 22 Feb 2009 12:45:56 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 32FA528C119 for ; Sun, 22 Feb 2009 12:45:55 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (140.pool85-53-153.dynamic.orange.es [85.53.153.140]) by smtp02.uc3m.es (Postfix) with ESMTP id 089F3659D52; Sun, 22 Feb 2009 21:46:10 +0100 (CET) Message-ID: <49A1B992.3070809@it.uc3m.es> Date: Sun, 22 Feb 2009 21:46:10 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Dan Wing References: <4975B691.2040009@it.uc3m.es> <48771572-B013-4E20-98C3-C475B3A22E92@magma.ca> <4991453D.7020900@it.uc3m.es> <499A964F.9070707@it.uc3m.es> <499EF6A4.70204@piuha.net> <0a1901c9938f$3286c7f0$c2f0200a@cisco.com> In-Reply-To: <0a1901c9938f$3286c7f0$c2f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16480.002 Cc: 'Behave WG' , 'Jari Arkko' , 'Philip Matthews' Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 20:45:57 -0000 Dan Wing escribió: > Jari Arkko wrote: > >> Marcelo, >> >> >>> Now, i can understand that people can have security policy that >>> prevents this from working and i am fine with that. >>> the thing about security policy is that other sits can have a >>> different policy and referrals would work for them. It is >>> actually an >>> operation choice of the site and that is good. >>> IMHO it is a completelly different thing to make a >>> technology that by >>> design breaks referrals, i simply don't think this is a good idea >>> >> That's right. We do need to attempt to keep as much of the end-to-end >> functionality intact as is possible. Of course people can add >> rules to allow and disallow various kinds of traffic flows, but >> it is in everyone's best interests to keep the translation >> component and firewall components as separate as possible. >> > > Referrals across a translator seem difficult at best though: > at least two applications that commonly do referrals (SIP and > BitTorrent) only use IP addresses, but referring a synthetic > IPv6 address to an IPv4 host will never work. mmm, but if you have a SIP ALG it could work, right? and using a well know prefix would make the life of the ALG much simpler, since it would be able to recognize an IPv6 represetnation of an IPv4 address and translate it into the embedded IPv4 address > Referring a > synthetic IPv6 address to an IPv6 host belonging to another > ISP will not work (an ISP is unlikely to operate NAT64 devices > for the benefit of any IPv6 host on the Internet that wants to > use it). > but, if you use the well know prefix this owuld work, cause the traffic would flow through the NAT64 located in each ISP, right? regards, marcelo > I have more details written up on this topic and will write > an I-D to present in San Francisco. > > -d > > > From huitema@windows.microsoft.com Sun Feb 22 16:51:37 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 016B83A6B17 for ; Sun, 22 Feb 2009 16:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPIdtb7bQmnk for ; Sun, 22 Feb 2009 16:51:36 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 413183A68F5 for ; Sun, 22 Feb 2009 16:51:36 -0800 (PST) Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Sun, 22 Feb 2009 16:51:48 -0800 Received: from TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com (157.54.18.79) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) with Microsoft SMTP Server id 8.2.99.4; Sun, 22 Feb 2009 16:51:48 -0800 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::75be:c82f:ae04:55bf]) by TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.79]) with mapi; Sun, 22 Feb 2009 16:51:48 -0800 From: Christian Huitema To: marcelo bagnulo braun , Dan Wing Date: Sun, 22 Feb 2009 16:51:43 -0800 Thread-Topic: [BEHAVE] Pref64 nature and referral support. Thread-Index: AcmVLwqfBSbyUDjCTcaiKoUCznsxywAISdjw Message-ID: <8EFB68EAE061884A8517F2A755E8B60A19DAFCB042@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <4975B691.2040009@it.uc3m.es> <48771572-B013-4E20-98C3-C475B3A22E92@magma.ca> <4991453D.7020900@it.uc3m.es> <499A964F.9070707@it.uc3m.es> <499EF6A4.70204@piuha.net> <0a1901c9938f$3286c7f0$c2f0200a@cisco.com> <49A1B992.3070809@it.uc3m.es> In-Reply-To: <49A1B992.3070809@it.uc3m.es> 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: 'Jari Arkko' , 'Behave WG' , 'Philip Matthews' Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 00:51:37 -0000 > > Referrals across a translator seem difficult at best though: > > at least two applications that commonly do referrals (SIP and > > BitTorrent) only use IP addresses, but referring a synthetic > > IPv6 address to an IPv4 host will never work. > mmm, but if you have a SIP ALG it could work, right? and using a well > know prefix would make the life of the ALG much simpler, since it would > be able to recognize an IPv6 represetnation of an IPv4 address and > translate it into the embedded IPv4 address Nope. It might work in some limited scenarios, but it will not work in the = general case. First, there is no guarantee that the translator will see the= SIP traffic. The traffic is send by the clients to the server, while the m= edia, for which the translation is negotiated, is sent on a direct path to = the clients. How would a translator apply an ALG to traffic that it does no= t see? Then, even if the SIP traffic did flow through the translator, in ma= ny case the traffic is sent over an encrypted TLS channel. The translator w= ill not even know it is SIP. And then, even if the traffic was sent in clea= r text through the translator, the SDP payload can well be signed or otherw= ise protected, so no chance for an ALG here either. There is a reason STUN, TURN and ICE are being developed. -- Christian Huitema From marcelo@it.uc3m.es Mon Feb 23 00:29:41 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8133B28C14A for ; Mon, 23 Feb 2009 00:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.934 X-Spam-Level: X-Spam-Status: No, score=-5.934 tagged_above=-999 required=5 tests=[AWL=0.665, 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 lvQlnpjkuZ3h for ; Mon, 23 Feb 2009 00:29:40 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 637BD3A690A for ; Mon, 23 Feb 2009 00:29:40 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (140.pool85-53-153.dynamic.orange.es [85.53.153.140]) by smtp03.uc3m.es (Postfix) with ESMTP id 1ED2B731D01; Mon, 23 Feb 2009 09:29:53 +0100 (CET) Message-ID: <49A25E80.1050302@it.uc3m.es> Date: Mon, 23 Feb 2009 09:29:52 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Christian Huitema References: <4975B691.2040009@it.uc3m.es> <48771572-B013-4E20-98C3-C475B3A22E92@magma.ca> <4991453D.7020900@it.uc3m.es> <499A964F.9070707@it.uc3m.es> <499EF6A4.70204@piuha.net> <0a1901c9938f$3286c7f0$c2f0200a@cisco.com> <49A1B992.3070809@it.uc3m.es> <8EFB68EAE061884A8517F2A755E8B60A19DAFCB042@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A19DAFCB042@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16480.006 Cc: 'Jari Arkko' , 'Behave WG' , 'Philip Matthews' , Dan Wing Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 08:29:41 -0000 Christian Huitema escribió: >>> Referrals across a translator seem difficult at best though: >>> at least two applications that commonly do referrals (SIP and >>> BitTorrent) only use IP addresses, but referring a synthetic >>> IPv6 address to an IPv4 host will never work. >>> >> mmm, but if you have a SIP ALG it could work, right? and using a well >> know prefix would make the life of the ALG much simpler, since it would >> be able to recognize an IPv6 represetnation of an IPv4 address and >> translate it into the embedded IPv4 address >> > > Nope. It might work in some limited scenarios, but it will not work in the general case. First, there is no guarantee that the translator will see the SIP traffic. The traffic is send by the clients to the server, while the media, for which the translation is negotiated, is sent on a direct path to the clients. How would a translator apply an ALG to traffic that it does not see? but in this case there should be another translator along the media path, right? (i mean, assuming you are trying to communicate a v4 node and a v6 node) > Then, even if the SIP traffic did flow through the translator, in many case the traffic is sent over an encrypted TLS channel. right, but this is a completelly different scenario imho If you are using TLS or even worse, IPSec, then translators are very unlikely to work in general cases. I mean, bottom line is that i understand that the argument here is how to make translators so that referrals, in the general case, SIP being an example, are more likely to work. In particular, when we need to select a prefix to represent IPv4 addresses in the IPv6 internet, whether using a single well known prefix or that each sites uses a sub prefix of their own prefixes makes life easier for referrals. This doesn't implies that referrals will work in every case, i know, but that the are more likely to work Regards, marcelo > The translator will not even know it is SIP. And then, even if the traffic was sent in clear text through the translator, the SDP payload can well be signed or otherwise protected, so no chance for an ALG here either. > > There is a reason STUN, TURN and ICE are being developed. > > -- Christian Huitema > > > > From dwing@cisco.com Mon Feb 23 12:23:42 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C52828C13E for ; Mon, 23 Feb 2009 12:23:42 -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=[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 EYGxWR5bB8yz for ; Mon, 23 Feb 2009 12:23:41 -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 2F7D728C145 for ; Mon, 23 Feb 2009 12:23:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,255,1233532800"; d="scan'208";a="146215393" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 23 Feb 2009 20:23:59 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1NKNxWS017020; Mon, 23 Feb 2009 12:23:59 -0800 Received: from dwingwxp01 (dhcp-128-107-163-55.cisco.com [128.107.163.55]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1NKNxvH013648; Mon, 23 Feb 2009 20:23:59 GMT From: "Dan Wing" To: "'marcelo bagnulo braun'" References: <4975B691.2040009@it.uc3m.es> <48771572-B013-4E20-98C3-C475B3A22E92@magma.ca> <4991453D.7020900@it.uc3m.es> <499A964F.9070707@it.uc3m.es> <499EF6A4.70204@piuha.net> <0a1901c9938f$3286c7f0$c2f0200a@cisco.com> <49A1B992.3070809@it.uc3m.es> Date: Mon, 23 Feb 2009 12:23:59 -0800 Message-ID: <0f0001c995f4$a8fa61f0$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: AcmVLpnprUC72NNGTwKTQnyqmZ2hDQAxP/FA In-Reply-To: <49A1B992.3070809@it.uc3m.es> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3074; t=1235420639; x=1236284639; 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[BEHAVE]=20Pref64=20nature=20and=20refe rral=20support. |Sender:=20; bh=AUenFNvCrtTAcUsaLdVqYrCkP+BAv4ySSpaqH0E+zrw=; b=VbEaMb2tm1gFsw/IrVxu33FtO4/As8yd1VU1tUPsqvq4OQiyOuKf2RsrQb VkK2Iw2k2X5eyOqIaTpuwdzSe0zcmryu7xfY0UsVc9bEmJnHvNaF3wMIMtCU 4PF2dzne98; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'Behave WG' , 'Jari Arkko' , 'Philip Matthews' Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 20:23:42 -0000 =20 > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > Sent: Sunday, February 22, 2009 12:46 PM > To: Dan Wing > Cc: 'Jari Arkko'; 'Behave WG'; 'Philip Matthews' > Subject: Re: [BEHAVE] Pref64 nature and referral support. >=20 > Dan Wing escribi=F3: > > Jari Arkko wrote: > > =20 > >> Marcelo, > >> > >> =20 > >>> Now, i can understand that people can have security policy that=20 > >>> prevents this from working and i am fine with that. > >>> the thing about security policy is that other sits can have a=20 > >>> different policy and referrals would work for them. It is=20 > >>> actually an=20 > >>> operation choice of the site and that is good. > >>> IMHO it is a completelly different thing to make a=20 > >>> technology that by=20 > >>> design breaks referrals, i simply don't think this is a good idea > >>> =20 > >> That's right. We do need to attempt to keep as much of the=20 > end-to-end=20 > >> functionality intact as is possible. Of course people can add=20 > >> rules to allow and disallow various kinds of traffic flows, but=20 > >> it is in everyone's best interests to keep the translation=20 > >> component and firewall components as separate as possible. > >> =20 > > > > Referrals across a translator seem difficult at best though: > > at least two applications that commonly do referrals (SIP and > > BitTorrent) only use IP addresses, but referring a synthetic > > IPv6 address to an IPv4 host will never work.=20 > mmm, but if you have a SIP ALG it could work, right? and using a well=20 > know prefix would make the life of the ALG much simpler,=20 > since it would=20 > be able to recognize an IPv6 represetnation of an IPv4 address and=20 > translate it into the embedded IPv4 address An ALG has to interact with the NAT and create state for the media traffic in the NAT. For a SIP ALG to work, the SIP traffic would have=20 to traverse the same NAT as the media traffic and the SIP traffic would have to be un-encrypted and not integrity protected. With those restrictions I do not think SIP ALGs are the answer. > > Referring a=20 > > synthetic IPv6 address to an IPv6 host belonging to another > > ISP will not work (an ISP is unlikely to operate NAT64 devices > > for the benefit of any IPv6 host on the Internet that wants to > > use it). > > =20 > but, if you use the well know prefix this owuld work, cause=20 > the traffic=20 > would flow through the NAT64 located in each ISP, right? If that ISP operates a NAT64, yes. So, referrals in that case work once an ISP installs a NAT64 (or the subscriber has some way to use someone else's NAT64, perhaps via a tunnel and a=20 per-month fee, for example). But my point is that existing IPv6 hosts and existing dual-stack hosts, in another ISP, cannot=20 utilize a synthetic address. -d > regards, marcelo >=20 > > I have more details written up on this topic and will write > > an I-D to present in San Francisco. > > > > -d > > > > > > =20 >=20 From dwing@cisco.com Mon Feb 23 12:31:05 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FFD028C156 for ; Mon, 23 Feb 2009 12:31:05 -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=[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 XTnWuIC0lCzs for ; Mon, 23 Feb 2009 12:31:04 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 3DDBB28C13E for ; Mon, 23 Feb 2009 12:31:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,255,1233532800"; d="scan'208";a="64576521" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 23 Feb 2009 20:31:22 +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 n1NKVMf3009034; Mon, 23 Feb 2009 12:31:22 -0800 Received: from dwingwxp01 (dhcp-128-107-163-55.cisco.com [128.107.163.55]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n1NKVMSY023664; Mon, 23 Feb 2009 20:31:22 GMT From: "Dan Wing" To: "'marcelo bagnulo braun'" , "'Christian Huitema'" References: <4975B691.2040009@it.uc3m.es> <48771572-B013-4E20-98C3-C475B3A22E92@magma.ca> <4991453D.7020900@it.uc3m.es> <499A964F.9070707@it.uc3m.es> <499EF6A4.70204@piuha.net> <0a1901c9938f$3286c7f0$c2f0200a@cisco.com> <49A1B992.3070809@it.uc3m.es> <8EFB68EAE061884A8517F2A755E8B60A19DAFCB042@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <49A25E80.1050302@it.uc3m.es> Date: Mon, 23 Feb 2009 12:31:22 -0800 Message-ID: <0f0801c995f5$b11158c0$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 Thread-Index: AcmVkOn4TIRjXSTpQO2J68o6aql8cQAZHaVg In-Reply-To: <49A25E80.1050302@it.uc3m.es> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1674; t=1235421082; x=1236285082; 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]=20Pref64=20nature=20and=20refe rral=20support. |Sender:=20; bh=uwJ+COUfHT8lqa5d8OaagPXRnLsBVqUT3pKGlibBgq4=; b=sDZeRTRix66CklGBvsnJb0vde3QSFfqNJyOXP4TPA2AqRGsNqti10igP6u tktA53TL/HgY4oO1YNEbXGA811fVMG1368pwlDrlyscW1MKRl64jNEyNG9rW /drTzzECFQ; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'Jari Arkko' , 'Behave WG' , 'Philip Matthews' Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 20:31:05 -0000 ... > If you are using TLS or even worse, IPSec, then translators are very > unlikely to work in general cases. I keep hearing that, but I haven't seen details. I am especially interested in how TLS would fail because if we can't get HTTPS to work across a translator, this will be deemed to have failed. As for IPsec failing, I vaguely recall a summary of the problem posted to the list about the IP address inside of the IPsec tunnel, but I don't recall who posted that summary. I don't recall anything in an I-D. > I mean, bottom line is that i understand that the argument > here is how to make translators so that referrals, in the general > case, SIP being an example, are more likely to work. > > In particular, when we need to select a prefix to represent IPv4 > addresses in the IPv6 internet, whether using a single well > known prefix > or that each sites uses a sub prefix of their own prefixes makes life > easier for referrals. > > This doesn't implies that referrals will work in every case, > i know, but that the are more likely to work We could require a SIP session border controller operate in the translator. That would make referrals work in every case. But, I don't think we want to go there, either.. -d > Regards, marcelo > > > > The translator will not even know it is SIP. And then, > even if the traffic was sent in clear text through the > translator, the SDP payload can well be signed or otherwise > protected, so no chance for an ALG here either. > > > > There is a reason STUN, TURN and ICE are being developed. > > > > -- Christian Huitema > > > > > > > > > From marcelo@it.uc3m.es Mon Feb 23 12:44:10 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0A8C3A6897 for ; Mon, 23 Feb 2009 12:44:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.017 X-Spam-Level: X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[AWL=0.582, 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 nEwG7Otcdfzx for ; Mon, 23 Feb 2009 12:44:10 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id A6C883A67E2 for ; Mon, 23 Feb 2009 12:44:08 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (195.pool85-53-140.dynamic.orange.es [85.53.140.195]) by smtp03.uc3m.es (Postfix) with ESMTP id DC27F731FA5; Mon, 23 Feb 2009 21:44:21 +0100 (CET) Message-ID: <49A30AA5.4080101@it.uc3m.es> Date: Mon, 23 Feb 2009 21:44:21 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Dan Wing References: <4975B691.2040009@it.uc3m.es> <48771572-B013-4E20-98C3-C475B3A22E92@magma.ca> <4991453D.7020900@it.uc3m.es> <499A964F.9070707@it.uc3m.es> <499EF6A4.70204@piuha.net> <0a1901c9938f$3286c7f0$c2f0200a@cisco.com> <49A1B992.3070809@it.uc3m.es> <0f0001c995f4$a8fa61f0$c2f0200a@cisco.com> In-Reply-To: <0f0001c995f4$a8fa61f0$c2f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16482.002 Cc: 'Behave WG' , 'Jari Arkko' , 'Philip Matthews' Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 20:44:11 -0000 Dan Wing escribió: > >>> Referring a >>> synthetic IPv6 address to an IPv6 host belonging to another >>> ISP will not work (an ISP is unlikely to operate NAT64 devices >>> for the benefit of any IPv6 host on the Internet that wants to >>> use it). >>> >>> >> but, if you use the well know prefix this owuld work, cause >> the traffic >> would flow through the NAT64 located in each ISP, right? >> > > If that ISP operates a NAT64, yes. So, referrals in that case > work once an ISP installs a NAT64 (or the subscriber has some > way to use someone else's NAT64, perhaps via a tunnel and a > per-month fee, for example). But my point is that existing IPv6 > hosts and existing dual-stack hosts, in another ISP, cannot > utilize a synthetic address. > > but that makes sense, right? I mean this stuff doesn't work when your IPv6 ISP doesn't provide their customer with IPv4 Internet access (i.e it doesn't provide a NAT64) and the cleint itself doesn't pay to any other NAT64 provider. So, if the client doesn't have access to the IPv4 Internet, not only referrals to the IPv4 internet break, any communication towards the IPv4 internet break, cause he is not paying for that service So, i think this is as much as he can for the money he pays, right? In other words, this is not problem of the technology, but it is a porblem of the clietn that is not buying the service Regards, marcelo > -d > > > >> regards, marcelo >> >> >>> I have more details written up on this topic and will write >>> an I-D to present in San Francisco. >>> >>> -d >>> >>> >>> >>> > > > From dwing@cisco.com Mon Feb 23 13:06:26 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CA433A68A6 for ; Mon, 23 Feb 2009 13:06:26 -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=[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 3DLVvcgtGNzc for ; Mon, 23 Feb 2009 13:06:25 -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 3165A3A689C for ; Mon, 23 Feb 2009 13:06:25 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,255,1233532800"; d="scan'208";a="146232823" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 23 Feb 2009 21:06:43 +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 n1NL6hti008188; Mon, 23 Feb 2009 13:06:43 -0800 Received: from dwingwxp01 (dhcp-128-107-163-55.cisco.com [128.107.163.55]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n1NL6h87024700; Mon, 23 Feb 2009 21:06:43 GMT From: "Dan Wing" To: "'marcelo bagnulo braun'" References: <4975B691.2040009@it.uc3m.es> <48771572-B013-4E20-98C3-C475B3A22E92@magma.ca> <4991453D.7020900@it.uc3m.es> <499A964F.9070707@it.uc3m.es> <499EF6A4.70204@piuha.net> <0a1901c9938f$3286c7f0$c2f0200a@cisco.com> <49A1B992.3070809@it.uc3m.es> <0f0001c995f4$a8fa61f0$c2f0200a@cisco.com> <49A30AA5.4080101@it.uc3m.es> Date: Mon, 23 Feb 2009 13:06:43 -0800 Message-ID: <0f4501c995fa$a1424fd0$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: AcmV94buNW0UEO0eTHWs0RmOSe6OgAAAsDfw In-Reply-To: <49A30AA5.4080101@it.uc3m.es> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2597; t=1235423203; x=1236287203; 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]=20Pref64=20nature=20and=20refe rral=20support. |Sender:=20; bh=e9l6gPmnoVCurazh1abIOVhnBlrTNsuUJds7R9Jb3GQ=; b=dYROZ95W9oFX3gJ2jD5kBer5zIH+Uq5O4uZisRdr7cEF9xNli/CtKVlLMo eAIGFK94bE06RL46zRcNQsSSdpT78rNw4BkSvb/4AHpYxLzcr3+LkjyRZqLz 2e4ZBMGlRt; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'Behave WG' , 'Jari Arkko' , 'Philip Matthews' Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:06:26 -0000 =20 > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > Sent: Monday, February 23, 2009 12:44 PM > To: Dan Wing > Cc: 'Jari Arkko'; 'Behave WG'; 'Philip Matthews' > Subject: Re: [BEHAVE] Pref64 nature and referral support. >=20 > Dan Wing escribi=F3: >=20 >=20 > > =20 > >>> Referring a=20 > >>> synthetic IPv6 address to an IPv6 host belonging to another > >>> ISP will not work (an ISP is unlikely to operate NAT64 devices > >>> for the benefit of any IPv6 host on the Internet that wants to > >>> use it). > >>> =20 > >>> =20 > >> but, if you use the well know prefix this owuld work, cause=20 > >> the traffic=20 > >> would flow through the NAT64 located in each ISP, right? > >> =20 > > > > If that ISP operates a NAT64, yes. So, referrals in that case > > work once an ISP installs a NAT64 (or the subscriber has some > > way to use someone else's NAT64, perhaps via a tunnel and a=20 > > per-month fee, for example). But my point is that existing IPv6 > > hosts and existing dual-stack hosts, in another ISP, cannot=20 > > utilize a synthetic address. > > > > =20 >=20 > but that makes sense, right? >=20 >=20 > I mean this stuff doesn't work when your IPv6 ISP doesn't=20 > provide their=20 > customer with IPv4 Internet access (i.e it doesn't provide a=20 > NAT64) and=20 > the cleint itself doesn't pay to any other NAT64 provider. >=20 > So, if the client doesn't have access to the IPv4 Internet, not only=20 > referrals to the IPv4 internet break, any communication=20 > towards the IPv4=20 > internet break, cause he is not paying for that service The same referral of a synthetic IPv6 address also breaks to a=20 dual-stack host, until/unless that dual-stack host's ISP operates a NAT64. And that will not make sense to someone operating a dual-stack host -- they will expect referrals to work because they are doing The Right Thing: namely, operating a dual-stack=20 host. I'll write this all up into an I-D which will hopefully make more sense. -d > So, i think this is as much as he can for the money he pays, right? >=20 > In other words, this is not problem of the technology, but it is a=20 > porblem of the clietn that is not buying the service >=20 > Regards, marcelo >=20 >=20 > > -d > > > > > > =20 > >> regards, marcelo > >> > >> =20 > >>> I have more details written up on this topic and will write > >>> an I-D to present in San Francisco. > >>> > >>> -d > >>> > >>> > >>> =20 > >>> =20 > > > > > > =20 >=20 From marcelo@it.uc3m.es Mon Feb 23 14:18:34 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 016453A68F4 for ; Mon, 23 Feb 2009 14:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.051 X-Spam-Level: X-Spam-Status: No, score=-6.051 tagged_above=-999 required=5 tests=[AWL=0.548, 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 qWPcj4UlF8TQ for ; Mon, 23 Feb 2009 14:18:33 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id AC3AE3A63D3 for ; Mon, 23 Feb 2009 14:18:32 -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 E95B4B4D152; Mon, 23 Feb 2009 23:18:47 +0100 (CET) Message-ID: <49A320C7.8030004@it.uc3m.es> Date: Mon, 23 Feb 2009 23:18:47 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Dan Wing References: <4975B691.2040009@it.uc3m.es> <48771572-B013-4E20-98C3-C475B3A22E92@magma.ca> <4991453D.7020900@it.uc3m.es> <499A964F.9070707@it.uc3m.es> <499EF6A4.70204@piuha.net> <0a1901c9938f$3286c7f0$c2f0200a@cisco.com> <49A1B992.3070809@it.uc3m.es> <0f0001c995f4$a8fa61f0$c2f0200a@cisco.com> <49A30AA5.4080101@it.uc3m.es> <0f4501c995fa$a1424fd0$c2f0200a@cisco.com> In-Reply-To: <0f4501c995fa$a1424fd0$c2f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16482.002 Cc: 'Behave WG' , 'Jari Arkko' , 'Philip Matthews' Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 22:18:34 -0000 Dan Wing escribió: > > > >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: Monday, February 23, 2009 12:44 PM >> To: Dan Wing >> Cc: 'Jari Arkko'; 'Behave WG'; 'Philip Matthews' >> Subject: Re: [BEHAVE] Pref64 nature and referral support. >> >> Dan Wing escribió: >> >> >> >>> >>> >>>>> Referring a >>>>> synthetic IPv6 address to an IPv6 host belonging to another >>>>> ISP will not work (an ISP is unlikely to operate NAT64 devices >>>>> for the benefit of any IPv6 host on the Internet that wants to >>>>> use it). >>>>> >>>>> >>>>> >>>> but, if you use the well know prefix this owuld work, cause >>>> the traffic >>>> would flow through the NAT64 located in each ISP, right? >>>> >>>> >>> If that ISP operates a NAT64, yes. So, referrals in that case >>> work once an ISP installs a NAT64 (or the subscriber has some >>> way to use someone else's NAT64, perhaps via a tunnel and a >>> per-month fee, for example). But my point is that existing IPv6 >>> hosts and existing dual-stack hosts, in another ISP, cannot >>> utilize a synthetic address. >>> >>> >>> >> but that makes sense, right? >> >> >> I mean this stuff doesn't work when your IPv6 ISP doesn't >> provide their >> customer with IPv4 Internet access (i.e it doesn't provide a >> NAT64) and >> the cleint itself doesn't pay to any other NAT64 provider. >> >> So, if the client doesn't have access to the IPv4 Internet, not only >> referrals to the IPv4 internet break, any communication >> towards the IPv4 >> internet break, cause he is not paying for that service >> > > The same referral of a synthetic IPv6 address also breaks to a > dual-stack host, until/unless that dual-stack host's ISP operates > a NAT64. And that will not make sense to someone operating > a dual-stack host -- they will expect referrals to work because > they are doing The Right Thing: namely, operating a dual-stack > host. > > I'll write this all up into an I-D which will hopefully make > more sense. > > So, the case you are considering is: Host A is IPv6-only Host B is dual stack Host C is IPv4-only Host B is obtaining service from an IPv6-only ISP that has not access to the IPv4 internet Host A do get IPv6 Internet access through a translator So, host A passes the IPv6 representation of Host C IPv4 address to Host B. Host B could access to Host C if it used the IPv4 address, but it cannot reach host C using the IPv6 representation cause its ISP is not providing NAT64 services, is that what you had in mind? But, in this case, the Host B should be able to recognize, if a well known prefix is used, that the IPv6 address it has received is an IPv6 representation of an IPv4 address and use IPv4 connectivity directly. I mean, the bottom line here, is that when you pass IPv6 address that represent IPv4 addresses around, the well know prefix seems to behave much better, cause you can easily recognize that this is a represenation of an IPv4 address Regards, marcelo > -d > > > >> So, i think this is as much as he can for the money he pays, right? >> >> In other words, this is not problem of the technology, but it is a >> porblem of the clietn that is not buying the service >> >> Regards, marcelo >> >> >> >>> -d >>> >>> >>> >>> >>>> regards, marcelo >>>> >>>> >>>> >>>>> I have more details written up on this topic and will write >>>>> an I-D to present in San Francisco. >>>>> >>>>> -d >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> > > > From dwing@cisco.com Mon Feb 23 15:15:45 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A42228C23C for ; Mon, 23 Feb 2009 15:15:45 -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=[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 w4BYLWbyd5Gj for ; Mon, 23 Feb 2009 15:15:44 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 513203A68FE for ; Mon, 23 Feb 2009 15:15:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,256,1233532800"; d="scan'208";a="64591912" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 23 Feb 2009 23:16:02 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n1NNG2dd011617; Mon, 23 Feb 2009 15:16:02 -0800 Received: from dwingwxp01 (dhcp-128-107-163-55.cisco.com [128.107.163.55]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n1NNG2UU006871; Mon, 23 Feb 2009 23:16:02 GMT From: "Dan Wing" To: "'marcelo bagnulo braun'" References: <4975B691.2040009@it.uc3m.es> <48771572-B013-4E20-98C3-C475B3A22E92@magma.ca> <4991453D.7020900@it.uc3m.es> <499A964F.9070707@it.uc3m.es><499EF6A4.70204@piuha.net><0a1901c9938f$3286c7f0$c2f0200a@cisco.com><49A1B992.3070809@it.uc3m.es><0f0001c995f4$a8fa61f0$c2f0200a@cisco.com><49A30AA5.4080101@it.uc3m.es><0f4501c995fa$a1424fd0$c2f0200a@cisco.com> <49A320C7.8030004@it.uc3m.es> Date: Mon, 23 Feb 2009 15:16:02 -0800 Message-ID: <100e01c9960c$b2254250$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: AcmWBLi5xb2gAP+9QyS2q/XCAYGDVwABTiaQ In-Reply-To: <49A320C7.8030004@it.uc3m.es> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6587; t=1235430963; x=1236294963; c=relaxed/simple; s=sjdkim3002; 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]=20Pref64=20nature=20and=20refe rral=20support. |Sender:=20; bh=OOJRV+0VCONySqA92AWoTTLOSqtuy/MIjqfIcpSHpmk=; b=LdW8ehf47NN4lkGgSK25Au2mpAMFk94KMPpRrpWuUVGXO6WmD13J59I8wM dtzOyeYjsdjnJwGTp1oWIKZX+BDYFTa5deZrvKsWGjTA9vs1D31lhibYUxDR 7ZO63Jtth4; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'Jari Arkko' , 'Behave WG' , 'Philip Matthews' Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 23:15:45 -0000 =20 > -----Original Message----- > From: behave-bounces@ietf.org=20 > [mailto:behave-bounces@ietf.org] On Behalf Of marcelo bagnulo braun > Sent: Monday, February 23, 2009 2:19 PM > To: Dan Wing > Cc: 'Behave WG'; 'Jari Arkko'; 'Philip Matthews' > Subject: Re: [BEHAVE] Pref64 nature and referral support. >=20 > Dan Wing escribi=F3: > > =20 > > > > =20 > >> -----Original Message----- > >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > >> Sent: Monday, February 23, 2009 12:44 PM > >> To: Dan Wing > >> Cc: 'Jari Arkko'; 'Behave WG'; 'Philip Matthews' > >> Subject: Re: [BEHAVE] Pref64 nature and referral support. > >> > >> Dan Wing escribi=F3: > >> > >> > >> =20 > >>> =20 > >>> =20 > >>>>> Referring a=20 > >>>>> synthetic IPv6 address to an IPv6 host belonging to another > >>>>> ISP will not work (an ISP is unlikely to operate NAT64 devices > >>>>> for the benefit of any IPv6 host on the Internet that wants to > >>>>> use it). > >>>>> =20 > >>>>> =20 > >>>>> =20 > >>>> but, if you use the well know prefix this owuld work, cause=20 > >>>> the traffic=20 > >>>> would flow through the NAT64 located in each ISP, right? > >>>> =20 > >>>> =20 > >>> If that ISP operates a NAT64, yes. So, referrals in that case > >>> work once an ISP installs a NAT64 (or the subscriber has some > >>> way to use someone else's NAT64, perhaps via a tunnel and a=20 > >>> per-month fee, for example). But my point is that existing IPv6 > >>> hosts and existing dual-stack hosts, in another ISP, cannot=20 > >>> utilize a synthetic address. > >>> > >>> =20 > >>> =20 > >> but that makes sense, right? > >> > >> > >> I mean this stuff doesn't work when your IPv6 ISP doesn't=20 > >> provide their=20 > >> customer with IPv4 Internet access (i.e it doesn't provide a=20 > >> NAT64) and=20 > >> the cleint itself doesn't pay to any other NAT64 provider. > >> > >> So, if the client doesn't have access to the IPv4=20 > Internet, not only=20 > >> referrals to the IPv4 internet break, any communication=20 > >> towards the IPv4=20 > >> internet break, cause he is not paying for that service > >> =20 > > > > The same referral of a synthetic IPv6 address also breaks to a=20 > > dual-stack host, until/unless that dual-stack host's ISP operates > > a NAT64. And that will not make sense to someone operating > > a dual-stack host -- they will expect referrals to work because > > they are doing The Right Thing: namely, operating a dual-stack=20 > > host. > > > > I'll write this all up into an I-D which will hopefully make > > more sense. > > > > =20 > So, the case you are considering is: >=20 > Host A is IPv6-only > Host B is dual stack > Host C is IPv4-only >=20 > Host B is obtaining service from an IPv6-only ISP that has=20 > not access to the IPv4 internet No; Host B is dual-stack and fully-functioning (can access both the v6 and v4 Internet). However, Host B's ISP has not installed a NAT64 device -- at least, not "yet". Perhaps Host B's ISP never will, because Host B's ISP believes that dual-stack hosts are the right answer. Perhaps Host B's ISP will only ever install a NAT44 (in order to continue expanding their business after IPv4 exhaustion). Whatever the reason, Host B's ISP does not operate a NAT64. Host B is running today's dual-stack OS (pick your favorite) and some dual- stack capable stack. If Host B (dual-stack) is referred to the=20 synthetic IPv6 address for Host C (IPv4-only), Host B can't do=20 anything useful -- it cannot communicate with Host C. "One Would=20 Expect" that Host B could communicate with Host C, though --=20 afterall, both of them are accessible over IPv4. Resolutions include: 1. tell Host B to run new software that is aware of the synthetic prefix, and strip that synthetic prefix. This allows Host B to connect to Host C using IPv4. 2. tell Host A to run new software that is aware of the synethric prefix, and strip that synthetic prefix before referring Host C's IPv4 address. This allows Host B to connect to Host C using IPv4. There is another interesting scenario, though, using=20 another host, Host D with is IPv4 only. If the referral is to Host D (IPv4 only), we cannot hope=20 to refer an IPv6 address to Host D. We can only successful refer an IPv4 address to an IPv4 only host. To my analysis, if we want referrals to work across a NAT64, we need to do (2), above -- namely, the host behind a NAT64 has to remove the synthetic IPv6 address prior to referring the address. Otherwise as soon as an IPv6-only host behind a NAT64 host sends a referral to either an IPv4-only host or=20 to a dual-stack host, the referral fails. I will write this up into an I-D. -d > Host A do get IPv6 Internet access through a translator >=20 > So, host A passes the IPv6 representation of Host C IPv4=20 > address to Host B. > Host B could access to Host C if it used the IPv4 address,=20 > but it cannot=20 > reach host C using the IPv6 representation cause its ISP is not=20 > providing NAT64 services, is that what you had in mind? >=20 > But, in this case, the Host B should be able to recognize, if a well=20 > known prefix is used, that the IPv6 address it has received=20 > is an IPv6=20 > representation of an IPv4 address and use IPv4 connectivity directly. > > I mean, the bottom line here, is that when you pass IPv6 address that=20 > represent IPv4 addresses around, the well know prefix seems to behave=20 > much better, cause you can easily recognize that this is a=20 > represenation=20 > of an IPv4 address >=20 > Regards, marcelo >=20 >=20 >=20 > > -d > > > > > > =20 > >> So, i think this is as much as he can for the money he pays, right? > >> > >> In other words, this is not problem of the technology, but it is a=20 > >> porblem of the clietn that is not buying the service > >> > >> Regards, marcelo > >> > >> > >> =20 > >>> -d > >>> > >>> > >>> =20 > >>> =20 > >>>> regards, marcelo > >>>> > >>>> =20 > >>>> =20 > >>>>> I have more details written up on this topic and will write > >>>>> an I-D to present in San Francisco. > >>>>> > >>>>> -d > >>>>> > >>>>> > >>>>> =20 > >>>>> =20 > >>>>> =20 > >>> =20 > >>> =20 > > > > > > =20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From H.Miyata@jp.yokogawa.com Mon Feb 23 16:34:30 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEAEB28C23B for ; Mon, 23 Feb 2009 16:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.504 X-Spam-Level: * X-Spam-Status: No, score=1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_72=0.6, RELAY_IS_203=0.994] 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 xPMAjKfSCLgO for ; Mon, 23 Feb 2009 16:34:29 -0800 (PST) Received: from zns001-0m9003.yokogawa.co.jp (zns001-0m9003.yokogawa.co.jp [203.174.79.161]) by core3.amsl.com (Postfix) with ESMTP id 524C928C265 for ; Mon, 23 Feb 2009 16:33:28 -0800 (PST) Received: from zns001-0m9003.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9003.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id n1O0XiaB023992; Tue, 24 Feb 2009 09:33:44 +0900 (JST) Received: from zex001-0m9027.jp.ykgw.net (zex001-0m9027.jp.ykgw.net [10.0.11.46]) by zns001-0m9003.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id n1O0Xg39023961; Tue, 24 Feb 2009 09:33:42 +0900 (JST) Received: from EXMAIL01.jp.ykgw.net ([10.0.11.27]) by zex001-0m9027.jp.ykgw.net ([10.0.11.46]) with mapi; Tue, 24 Feb 2009 09:33:42 +0900 From: To: , Date: Tue, 24 Feb 2009 09:33:39 +0900 Thread-Topic: [BEHAVE] Pref64 nature and referral support. Thread-Index: AcmWBLi5xb2gAP+9QyS2q/XCAYGDVwABTiaQAAIJoCA= Message-ID: References: <4975B691.2040009@it.uc3m.es> <48771572-B013-4E20-98C3-C475B3A22E92@magma.ca> <4991453D.7020900@it.uc3m.es> <499A964F.9070707@it.uc3m.es><499EF6A4.70204@piuha.net><0a1901c9938f$3286c7f0$c2f0200a@cisco.com><49A1B992.3070809@it.uc3m.es><0f0001c995f4$a8fa61f0$c2f0200a@cisco.com><49A30AA5.4080101@it.uc3m.es><0f4501c995fa$a1424fd0$c2f0200a@cisco.com> <49A320C7.8030004@it.uc3m.es> <100e01c9960c$b2254250$c2f0200a@cisco.com> In-Reply-To: <100e01c9960c$b2254250$c2f0200a@cisco.com> Accept-Language: ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: ja-JP Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: behave@ietf.org, jari.arkko@piuha.net, philip_matthews@magma.ca Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 00:34:30 -0000 Dan and Marcelo, My suggestion is that we should not mix-up the two features of well-known p= refix. As you know well-known prefix has two aspects. - Sythetic address identifier - Routable Prefix (Common prefix to lead the packets to the translators on somewhere) The former aspect is useful, of course. The latter aspect is a bit dangerous that would cause some problems. It means some people outside my routing realm can=20 control the traffic to lead to a translator. The behavior may or may not fit my routing policy. So, the routing information and identification should be discussed separate= ly. And I have another concern on well-known prefix. Is it routable prefix in global internet? I don't believe so. ;-) Comment on referrals. If a user in ISP-B contacts to SIP service of ISP-A and got synthetic addre= ss with the local prefix of ISP-A, the user should send the packet to the tran= slator=20 of ISP-A. Because the user is already authorized by SIP service of ISP-A d= irectly or indirectly.=20 Yes, ISP-A may charge for the traffic, but it is already accepted. In general, I think the synthetic address builder(in this case ISP-A) shoul= d take=20 responsibility on the packet sent to the address. If ISP-A and ISP-B collaborate to integrate the translation service, they m= ay choose=20 a common pref64 to optimize the traffic. In this case both are taking the r= esponsibility. Best Regards, ------------------------------------ Hiroshi Miyata, Ubiquitous Field Computing Research Center, Corporate R&D Headquaters, Yokogawa Electric Corp. =20 > -----Original Message----- > From: behave-bounces@ietf.org=20 > [mailto:behave-bounces@ietf.org] On Behalf Of Dan Wing > Sent: Tuesday, February 24, 2009 8:16 AM > To: 'marcelo bagnulo braun' > Cc: 'Jari Arkko'; 'Behave WG'; 'Philip Matthews' > Subject: Re: [BEHAVE] Pref64 nature and referral support. >=20 > =20 >=20 > > -----Original Message----- > > From: behave-bounces@ietf.org > > [mailto:behave-bounces@ietf.org] On Behalf Of marcelo bagnulo braun > > Sent: Monday, February 23, 2009 2:19 PM > > To: Dan Wing > > Cc: 'Behave WG'; 'Jari Arkko'; 'Philip Matthews' > > Subject: Re: [BEHAVE] Pref64 nature and referral support. > >=20 > > Dan Wing escribi=F3: > > > =20 > > > > > > =20 > > >> -----Original Message----- > > >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > > >> Sent: Monday, February 23, 2009 12:44 PM > > >> To: Dan Wing > > >> Cc: 'Jari Arkko'; 'Behave WG'; 'Philip Matthews' > > >> Subject: Re: [BEHAVE] Pref64 nature and referral support. > > >> > > >> Dan Wing escribi=F3: > > >> > > >> > > >> =20 > > >>> =20 > > >>> =20 > > >>>>> Referring a > > >>>>> synthetic IPv6 address to an IPv6 host belonging to=20 > another ISP=20 > > >>>>> will not work (an ISP is unlikely to operate NAT64=20 > devices for=20 > > >>>>> the benefit of any IPv6 host on the Internet that=20 > wants to use=20 > > >>>>> it). > > >>>>> =20 > > >>>>> =20 > > >>>>> =20 > > >>>> but, if you use the well know prefix this owuld work,=20 > cause the=20 > > >>>> traffic would flow through the NAT64 located in each=20 > ISP, right? > > >>>> =20 > > >>>> =20 > > >>> If that ISP operates a NAT64, yes. So, referrals in that case=20 > > >>> work once an ISP installs a NAT64 (or the subscriber=20 > has some way=20 > > >>> to use someone else's NAT64, perhaps via a tunnel and a=20 > per-month=20 > > >>> fee, for example). But my point is that existing IPv6=20 > hosts and=20 > > >>> existing dual-stack hosts, in another ISP, cannot utilize a=20 > > >>> synthetic address. > > >>> > > >>> =20 > > >>> =20 > > >> but that makes sense, right? > > >> > > >> > > >> I mean this stuff doesn't work when your IPv6 ISP=20 > doesn't provide=20 > > >> their customer with IPv4 Internet access (i.e it doesn't=20 > provide a > > >> NAT64) and > > >> the cleint itself doesn't pay to any other NAT64 provider. > > >> > > >> So, if the client doesn't have access to the IPv4 > > Internet, not only > > >> referrals to the IPv4 internet break, any communication=20 > towards the=20 > > >> IPv4 internet break, cause he is not paying for that service > > >> =20 > > > > > > The same referral of a synthetic IPv6 address also breaks to a=20 > > > dual-stack host, until/unless that dual-stack host's ISP=20 > operates a=20 > > > NAT64. And that will not make sense to someone operating a=20 > > > dual-stack host -- they will expect referrals to work=20 > because they=20 > > > are doing The Right Thing: namely, operating a dual-stack host. > > > > > > I'll write this all up into an I-D which will hopefully make more=20 > > > sense. > > > > > > =20 > > So, the case you are considering is: > >=20 > > Host A is IPv6-only > > Host B is dual stack > > Host C is IPv4-only > >=20 > > Host B is obtaining service from an IPv6-only ISP that has=20 > not access=20 > > to the IPv4 internet >=20 > No; Host B is dual-stack and fully-functioning (can access=20 > both the v6 and v4 Internet). However, Host B's ISP has not=20 > installed a NAT64 device -- at least, not "yet". Perhaps=20 > Host B's ISP never will, because Host B's ISP believes that=20 > dual-stack hosts are the right answer. Perhaps Host B's ISP=20 > will only ever install a NAT44 (in order to continue=20 > expanding their business after IPv4 exhaustion). Whatever=20 > the reason, Host B's ISP does not operate a NAT64. Host B is=20 > running today's dual-stack OS (pick your favorite) and some=20 > dual- stack capable stack. If Host B (dual-stack) is=20 > referred to the synthetic IPv6 address for Host C=20 > (IPv4-only), Host B can't do anything useful -- it cannot=20 > communicate with Host C. "One Would Expect" that Host B=20 > could communicate with Host C, though -- afterall, both of=20 > them are accessible over IPv4. >=20 > Resolutions include: > 1. tell Host B to run new software that is aware of the > synthetic prefix, and strip that synthetic prefix. > This allows Host B to connect to Host C using IPv4. > 2. tell Host A to run new software that is aware of the > synethric prefix, and strip that synthetic prefix > before referring Host C's IPv4 address. This allows > Host B to connect to Host C using IPv4. >=20 > There is another interesting scenario, though, using another=20 > host, Host D with is IPv4 only. >=20 > If the referral is to Host D (IPv4 only), we cannot hope to=20 > refer an IPv6 address to Host D. We can only successful=20 > refer an IPv4 address to an IPv4 only host. >=20 > To my analysis, if we want referrals to work across a NAT64,=20 > we need to do (2), above -- namely, the host behind a NAT64=20 > has to remove the synthetic IPv6 address prior to referring=20 > the address. Otherwise as soon as an IPv6-only host behind a > NAT64 host sends a referral to either an IPv4-only host or to=20 > a dual-stack host, the referral fails. >=20 >=20 > I will write this up into an I-D. >=20 > -d >=20 >=20 > > Host A do get IPv6 Internet access through a translator > >=20 > > So, host A passes the IPv6 representation of Host C IPv4=20 > > address to Host B. > > Host B could access to Host C if it used the IPv4 address,=20 > > but it cannot=20 > > reach host C using the IPv6 representation cause its ISP is not=20 > > providing NAT64 services, is that what you had in mind? > >=20 > > But, in this case, the Host B should be able to recognize,=20 > if a well=20 > > known prefix is used, that the IPv6 address it has received=20 > > is an IPv6=20 > > representation of an IPv4 address and use IPv4 connectivity=20 > directly. > > > > I mean, the bottom line here, is that when you pass IPv6=20 > address that=20 > > represent IPv4 addresses around, the well know prefix seems=20 > to behave=20 > > much better, cause you can easily recognize that this is a=20 > > represenation=20 > > of an IPv4 address > >=20 > > Regards, marcelo > >=20 > >=20 > >=20 > > > -d > > > > > > > > > =20 > > >> So, i think this is as much as he can for the money he=20 > pays, right? > > >> > > >> In other words, this is not problem of the technology,=20 > but it is a=20 > > >> porblem of the clietn that is not buying the service > > >> > > >> Regards, marcelo > > >> > > >> > > >> =20 > > >>> -d > > >>> > > >>> > > >>> =20 > > >>> =20 > > >>>> regards, marcelo > > >>>> > > >>>> =20 > > >>>> =20 > > >>>>> I have more details written up on this topic and will write > > >>>>> an I-D to present in San Francisco. > > >>>>> > > >>>>> -d > > >>>>> > > >>>>> > > >>>>> =20 > > >>>>> =20 > > >>>>> =20 > > >>> =20 > > >>> =20 > > > > > > > > > =20 > >=20 > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > = From dwing@cisco.com Mon Feb 23 16:50:33 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F80D28C26C for ; Mon, 23 Feb 2009 16:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.253 X-Spam-Level: X-Spam-Status: No, score=-6.253 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, J_CHICKENPOX_72=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 55ZFHbDeW4X7 for ; Mon, 23 Feb 2009 16:50:31 -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 CEAD028C26A for ; Mon, 23 Feb 2009 16:50:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,256,1233532800"; d="scan'208";a="134540443" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 24 Feb 2009 00:50:50 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n1O0oofn023953; Mon, 23 Feb 2009 16:50:50 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n1O0onmL004268; Tue, 24 Feb 2009 00:50:49 GMT From: "Dan Wing" To: , References: <4975B691.2040009@it.uc3m.es><48771572-B013-4E20-98C3-C475B3A22E92@magma.ca><4991453D.7020900@it.uc3m.es><499A964F.9070707@it.uc3m.es><499EF6A4.70204@piuha.net><0a1901c9938f$3286c7f0$c2f0200a@cisco.com><49A1B992.3070809@it.uc3m.es><0f0001c995f4$a8fa61f0$c2f0200a@cisco.com><49A30AA5.4080101@it.uc3m.es><0f4501c995fa$a1424fd0$c2f0200a@cisco.com><49A320C7.8030004@it.uc3m.es> <100e01c9960c$b2254250$c2f0200a@cisco.com> Date: Mon, 23 Feb 2009 16:50:49 -0800 Message-ID: <108701c99619$f0462f10$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: AcmWBLi5xb2gAP+9QyS2q/XCAYGDVwABTiaQAAIJoCAAAdbGAA== In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10560; t=1235436650; x=1236300650; c=relaxed/simple; s=sjdkim3002; 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]=20Pref64=20nature=20and=20refe rral=20support. |Sender:=20; bh=QGOuMyyMXrZ2u8o5GKuzHyRWa2K//7G9Ip4QHQ8OTbM=; b=J3KqMdHaL3MJ1sCgKtbMxV/ERH19NFXexyhkWyfBSLLnjI2dVEjJoaJY6L 5/XZ4TCL/n9mfaF7PszUKAp6FiSVwrDXo89oVjA96VgxKdA2Vn0i1znLIBAm H64pN4jDI5; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: behave@ietf.org, jari.arkko@piuha.net, philip_matthews@magma.ca Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 00:50:33 -0000 =20 > -----Original Message----- > From: H.Miyata@jp.yokogawa.com [mailto:H.Miyata@jp.yokogawa.com]=20 > Sent: Monday, February 23, 2009 4:34 PM > To: dwing@cisco.com; marcelo@it.uc3m.es > Cc: jari.arkko@piuha.net; behave@ietf.org; philip_matthews@magma.ca > Subject: RE: [BEHAVE] Pref64 nature and referral support. >=20 > Dan and Marcelo, >=20 > My suggestion is that we should not mix-up the two features=20 > of well-known prefix. >=20 > As you know well-known prefix has two aspects. > - Sythetic address identifier > - Routable Prefix > (Common prefix to lead the packets to the translators=20 > on somewhere) >=20 > The former aspect is useful, of course. > The latter aspect is a bit dangerous that would cause some problems. > It means some people outside my routing realm can=20 > control the traffic to lead to a translator. > The behavior may or may not fit my routing policy. >=20 > So, the routing information and identification should be=20 > discussed separately. >=20 > And I have another concern on well-known prefix. > Is it routable prefix in global internet? I don't believe so. ;-) >=20 >=20 >=20 > Comment on referrals. > If a user in ISP-B contacts to SIP service of ISP-A and got=20 > synthetic address > with the local prefix of ISP-A, the user should send the=20 > packet to the translator=20 > of ISP-A. Because the user is already authorized by SIP=20 > service of ISP-A directly or indirectly.=20 > Yes, ISP-A may charge for the traffic, but it is already accepted. That would require some sort of interface between the ISP-A's NAT64=20 device and the its SIP proxy/B2BUA/SBC, in order to authorize the referral. We could do that, I suppose. But what of referrals where some other ISP's SIP service is being utilized -- for example, Vonage? In that case, Vonage's SIP proxies will not be able to tell ISP-A's NAT64 to allow the packets through. > In general, I think the synthetic address builder(in this=20 > case ISP-A) should take=20 > responsibility on the packet sent to the address. > If ISP-A and ISP-B collaborate to integrate the translation=20 > service, they may choose=20 > a common pref64 to optimize the traffic. In this case both=20 > are taking the responsibility. -d > Best Regards, >=20 > ------------------------------------ > Hiroshi Miyata, > Ubiquitous Field Computing Research Center, > Corporate R&D Headquaters, > Yokogawa Electric Corp. >=20 > =20 >=20 > > -----Original Message----- > > From: behave-bounces@ietf.org=20 > > [mailto:behave-bounces@ietf.org] On Behalf Of Dan Wing > > Sent: Tuesday, February 24, 2009 8:16 AM > > To: 'marcelo bagnulo braun' > > Cc: 'Jari Arkko'; 'Behave WG'; 'Philip Matthews' > > Subject: Re: [BEHAVE] Pref64 nature and referral support. > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: behave-bounces@ietf.org > > > [mailto:behave-bounces@ietf.org] On Behalf Of marcelo=20 > bagnulo braun > > > Sent: Monday, February 23, 2009 2:19 PM > > > To: Dan Wing > > > Cc: 'Behave WG'; 'Jari Arkko'; 'Philip Matthews' > > > Subject: Re: [BEHAVE] Pref64 nature and referral support. > > >=20 > > > Dan Wing escribi=F3: > > > > =20 > > > > > > > > =20 > > > >> -----Original Message----- > > > >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > > > >> Sent: Monday, February 23, 2009 12:44 PM > > > >> To: Dan Wing > > > >> Cc: 'Jari Arkko'; 'Behave WG'; 'Philip Matthews' > > > >> Subject: Re: [BEHAVE] Pref64 nature and referral support. > > > >> > > > >> Dan Wing escribi=F3: > > > >> > > > >> > > > >> =20 > > > >>> =20 > > > >>> =20 > > > >>>>> Referring a > > > >>>>> synthetic IPv6 address to an IPv6 host belonging to=20 > > another ISP=20 > > > >>>>> will not work (an ISP is unlikely to operate NAT64=20 > > devices for=20 > > > >>>>> the benefit of any IPv6 host on the Internet that=20 > > wants to use=20 > > > >>>>> it). > > > >>>>> =20 > > > >>>>> =20 > > > >>>>> =20 > > > >>>> but, if you use the well know prefix this owuld work,=20 > > cause the=20 > > > >>>> traffic would flow through the NAT64 located in each=20 > > ISP, right? > > > >>>> =20 > > > >>>> =20 > > > >>> If that ISP operates a NAT64, yes. So, referrals in=20 > that case=20 > > > >>> work once an ISP installs a NAT64 (or the subscriber=20 > > has some way=20 > > > >>> to use someone else's NAT64, perhaps via a tunnel and a=20 > > per-month=20 > > > >>> fee, for example). But my point is that existing IPv6=20 > > hosts and=20 > > > >>> existing dual-stack hosts, in another ISP, cannot utilize a=20 > > > >>> synthetic address. > > > >>> > > > >>> =20 > > > >>> =20 > > > >> but that makes sense, right? > > > >> > > > >> > > > >> I mean this stuff doesn't work when your IPv6 ISP=20 > > doesn't provide=20 > > > >> their customer with IPv4 Internet access (i.e it doesn't=20 > > provide a > > > >> NAT64) and > > > >> the cleint itself doesn't pay to any other NAT64 provider. > > > >> > > > >> So, if the client doesn't have access to the IPv4 > > > Internet, not only > > > >> referrals to the IPv4 internet break, any communication=20 > > towards the=20 > > > >> IPv4 internet break, cause he is not paying for that service > > > >> =20 > > > > > > > > The same referral of a synthetic IPv6 address also breaks to a=20 > > > > dual-stack host, until/unless that dual-stack host's ISP=20 > > operates a=20 > > > > NAT64. And that will not make sense to someone operating a=20 > > > > dual-stack host -- they will expect referrals to work=20 > > because they=20 > > > > are doing The Right Thing: namely, operating a dual-stack host. > > > > > > > > I'll write this all up into an I-D which will hopefully=20 > make more=20 > > > > sense. > > > > > > > > =20 > > > So, the case you are considering is: > > >=20 > > > Host A is IPv6-only > > > Host B is dual stack > > > Host C is IPv4-only > > >=20 > > > Host B is obtaining service from an IPv6-only ISP that has=20 > > not access=20 > > > to the IPv4 internet > >=20 > > No; Host B is dual-stack and fully-functioning (can access=20 > > both the v6 and v4 Internet). However, Host B's ISP has not=20 > > installed a NAT64 device -- at least, not "yet". Perhaps=20 > > Host B's ISP never will, because Host B's ISP believes that=20 > > dual-stack hosts are the right answer. Perhaps Host B's ISP=20 > > will only ever install a NAT44 (in order to continue=20 > > expanding their business after IPv4 exhaustion). Whatever=20 > > the reason, Host B's ISP does not operate a NAT64. Host B is=20 > > running today's dual-stack OS (pick your favorite) and some=20 > > dual- stack capable stack. If Host B (dual-stack) is=20 > > referred to the synthetic IPv6 address for Host C=20 > > (IPv4-only), Host B can't do anything useful -- it cannot=20 > > communicate with Host C. "One Would Expect" that Host B=20 > > could communicate with Host C, though -- afterall, both of=20 > > them are accessible over IPv4. > >=20 > > Resolutions include: > > 1. tell Host B to run new software that is aware of the > > synthetic prefix, and strip that synthetic prefix. > > This allows Host B to connect to Host C using IPv4. > > 2. tell Host A to run new software that is aware of the > > synethric prefix, and strip that synthetic prefix > > before referring Host C's IPv4 address. This allows > > Host B to connect to Host C using IPv4. > >=20 > > There is another interesting scenario, though, using another=20 > > host, Host D with is IPv4 only. > >=20 > > If the referral is to Host D (IPv4 only), we cannot hope to=20 > > refer an IPv6 address to Host D. We can only successful=20 > > refer an IPv4 address to an IPv4 only host. > >=20 > > To my analysis, if we want referrals to work across a NAT64,=20 > > we need to do (2), above -- namely, the host behind a NAT64=20 > > has to remove the synthetic IPv6 address prior to referring=20 > > the address. Otherwise as soon as an IPv6-only host behind a > > NAT64 host sends a referral to either an IPv4-only host or to=20 > > a dual-stack host, the referral fails. > >=20 > >=20 > > I will write this up into an I-D. > >=20 > > -d > >=20 > >=20 > > > Host A do get IPv6 Internet access through a translator > > >=20 > > > So, host A passes the IPv6 representation of Host C IPv4=20 > > > address to Host B. > > > Host B could access to Host C if it used the IPv4 address,=20 > > > but it cannot=20 > > > reach host C using the IPv6 representation cause its ISP is not=20 > > > providing NAT64 services, is that what you had in mind? > > >=20 > > > But, in this case, the Host B should be able to recognize,=20 > > if a well=20 > > > known prefix is used, that the IPv6 address it has received=20 > > > is an IPv6=20 > > > representation of an IPv4 address and use IPv4 connectivity=20 > > directly. > > > > > > I mean, the bottom line here, is that when you pass IPv6=20 > > address that=20 > > > represent IPv4 addresses around, the well know prefix seems=20 > > to behave=20 > > > much better, cause you can easily recognize that this is a=20 > > > represenation=20 > > > of an IPv4 address > > >=20 > > > Regards, marcelo > > >=20 > > >=20 > > >=20 > > > > -d > > > > > > > > > > > > =20 > > > >> So, i think this is as much as he can for the money he=20 > > pays, right? > > > >> > > > >> In other words, this is not problem of the technology,=20 > > but it is a=20 > > > >> porblem of the clietn that is not buying the service > > > >> > > > >> Regards, marcelo > > > >> > > > >> > > > >> =20 > > > >>> -d > > > >>> > > > >>> > > > >>> =20 > > > >>> =20 > > > >>>> regards, marcelo > > > >>>> > > > >>>> =20 > > > >>>> =20 > > > >>>>> I have more details written up on this topic and will write > > > >>>>> an I-D to present in San Francisco. > > > >>>>> > > > >>>>> -d > > > >>>>> > > > >>>>> > > > >>>>> =20 > > > >>>>> =20 > > > >>>>> =20 > > > >>> =20 > > > >>> =20 > > > > > > > > > > > > =20 > > >=20 > > > _______________________________________________ > > > Behave mailing list > > > Behave@ietf.org > > > https://www.ietf.org/mailman/listinfo/behave > >=20 > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > =3D From H.Miyata@jp.yokogawa.com Mon Feb 23 17:54:49 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22E6A3A68D1 for ; Mon, 23 Feb 2009 17:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.504 X-Spam-Level: * X-Spam-Status: No, score=1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_72=0.6, RELAY_IS_203=0.994] 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 aXqxqfpnoh6p for ; Mon, 23 Feb 2009 17:54:47 -0800 (PST) Received: from zns001-0m9004.yokogawa.co.jp (zns001-0m9004.yokogawa.co.jp [203.174.79.162]) by core3.amsl.com (Postfix) with ESMTP id ACCC73A657C for ; Mon, 23 Feb 2009 17:54:47 -0800 (PST) Received: from zns001-0m9004.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9004.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id n1O1t2se028376; Tue, 24 Feb 2009 10:55:02 +0900 (JST) Received: from zex001-0m9027.jp.ykgw.net (zex001-0m9027.jp.ykgw.net [10.0.11.46]) by zns001-0m9004.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id n1O1t1At028349; Tue, 24 Feb 2009 10:55:01 +0900 (JST) Received: from EXMAIL01.jp.ykgw.net ([10.0.11.27]) by zex001-0m9027.jp.ykgw.net ([10.0.11.46]) with mapi; Tue, 24 Feb 2009 10:55:01 +0900 From: To: , Date: Tue, 24 Feb 2009 10:54:59 +0900 Thread-Topic: [BEHAVE] Pref64 nature and referral support. Thread-Index: AcmWBLi5xb2gAP+9QyS2q/XCAYGDVwABTiaQAAIJoCAAAdbGAAABcdhA Message-ID: References: <4975B691.2040009@it.uc3m.es><48771572-B013-4E20-98C3-C475B3A22E92@magma.ca><4991453D.7020900@it.uc3m.es><499A964F.9070707@it.uc3m.es><499EF6A4.70204@piuha.net><0a1901c9938f$3286c7f0$c2f0200a@cisco.com><49A1B992.3070809@it.uc3m.es><0f0001c995f4$a8fa61f0$c2f0200a@cisco.com><49A30AA5.4080101@it.uc3m.es><0f4501c995fa$a1424fd0$c2f0200a@cisco.com><49A320C7.8030004@it.uc3m.es> <100e01c9960c$b2254250$c2f0200a@cisco.com> <108701c99619$f0462f10$c2f0200a@cisco.com> In-Reply-To: <108701c99619$f0462f10$c2f0200a@cisco.com> Accept-Language: ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: ja-JP Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: behave@ietf.org, jari.arkko@piuha.net, philip_matthews@magma.ca Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 01:54:49 -0000 Dan, > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: Tuesday, February 24, 2009 9:51 AM > To: Miyata, Hiroshi (H.Miyata@jp.yokogawa.com); marcelo@it.uc3m.es > Cc: jari.arkko@piuha.net; behave@ietf.org; philip_matthews@magma.ca > Subject: RE: [BEHAVE] Pref64 nature and referral support. >=20 > =20 >=20 > > -----Original Message----- > > From: H.Miyata@jp.yokogawa.com [mailto:H.Miyata@jp.yokogawa.com] > > Sent: Monday, February 23, 2009 4:34 PM > > To: dwing@cisco.com; marcelo@it.uc3m.es > > Cc: jari.arkko@piuha.net; behave@ietf.org; philip_matthews@magma.ca > > Subject: RE: [BEHAVE] Pref64 nature and referral support. > >=20 > > Dan and Marcelo, > >=20 > > My suggestion is that we should not mix-up the two features of=20 > > well-known prefix. > >=20 > > As you know well-known prefix has two aspects. > > - Sythetic address identifier > > - Routable Prefix > > (Common prefix to lead the packets to the translators=20 > on somewhere) > >=20 > > The former aspect is useful, of course. > > The latter aspect is a bit dangerous that would cause some problems. > > It means some people outside my routing realm can=20 > > control the traffic to lead to a translator. > > The behavior may or may not fit my routing policy. > >=20 > > So, the routing information and identification should be discussed=20 > > separately. > >=20 > > And I have another concern on well-known prefix. > > Is it routable prefix in global internet? I don't believe so. ;-) > >=20 > >=20 > >=20 > > Comment on referrals. > > If a user in ISP-B contacts to SIP service of ISP-A and got=20 > synthetic=20 > > address with the local prefix of ISP-A, the user should send the=20 > > packet to the translator of ISP-A. Because the user is already=20 > > authorized by SIP service of ISP-A directly or indirectly. > > Yes, ISP-A may charge for the traffic, but it is already accepted. >=20 > That would require some sort of interface between the ISP-A's=20 > NAT64 device and the its SIP proxy/B2BUA/SBC, in order to=20 > authorize the referral. We could do that, I suppose. =20 > But=20 > what of referrals where some other ISP's SIP service is being=20 > utilized -- for example, Vonage? In that case, Vonage's SIP=20 > proxies will not be able to tell ISP-A's NAT64 to allow the=20 > packets through. >=20 Actually, my point is it works if the ISP designed to make it work. As you mentioned the interface definition is required in most case. So, I would like to say, this case can not be the reason to promote=20 well-known address. To answer to your question, the asspmption come from original referral discussion with my understanding, maybe a long time ago. In most case SIP sevice would not work with deep cooperation. So, the case "referal works but traffic is dropped" unlikely happen in SIP service, I think. Sorry for your confusion. Regards, ....hiroshi miyata > > In general, I think the synthetic address builder(in this=20 > case ISP-A)=20 > > should take responsibility on the packet sent to the address. > > If ISP-A and ISP-B collaborate to integrate the translation=20 > service,=20 > > they may choose a common pref64 to optimize the traffic. In=20 > this case=20 > > both are taking the responsibility. >=20 > -d >=20 > > Best Regards, > >=20 > > ------------------------------------ > > Hiroshi Miyata, > > Ubiquitous Field Computing Research Center, Corporate R&D=20 > Headquaters,=20 > > Yokogawa Electric Corp. > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: behave-bounces@ietf.org > > > [mailto:behave-bounces@ietf.org] On Behalf Of Dan Wing > > > Sent: Tuesday, February 24, 2009 8:16 AM > > > To: 'marcelo bagnulo braun' > > > Cc: 'Jari Arkko'; 'Behave WG'; 'Philip Matthews' > > > Subject: Re: [BEHAVE] Pref64 nature and referral support. > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: behave-bounces@ietf.org > > > > [mailto:behave-bounces@ietf.org] On Behalf Of marcelo > > bagnulo braun > > > > Sent: Monday, February 23, 2009 2:19 PM > > > > To: Dan Wing > > > > Cc: 'Behave WG'; 'Jari Arkko'; 'Philip Matthews' > > > > Subject: Re: [BEHAVE] Pref64 nature and referral support. > > > >=20 > > > > Dan Wing escribi=F3: > > > > > =20 > > > > > > > > > > =20 > > > > >> -----Original Message----- > > > > >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > > > > >> Sent: Monday, February 23, 2009 12:44 PM > > > > >> To: Dan Wing > > > > >> Cc: 'Jari Arkko'; 'Behave WG'; 'Philip Matthews' > > > > >> Subject: Re: [BEHAVE] Pref64 nature and referral support. > > > > >> > > > > >> Dan Wing escribi=F3: > > > > >> > > > > >> > > > > >> =20 > > > > >>> =20 > > > > >>> =20 > > > > >>>>> Referring a > > > > >>>>> synthetic IPv6 address to an IPv6 host belonging to > > > another ISP > > > > >>>>> will not work (an ISP is unlikely to operate NAT64 > > > devices for > > > > >>>>> the benefit of any IPv6 host on the Internet that > > > wants to use > > > > >>>>> it). > > > > >>>>> =20 > > > > >>>>> =20 > > > > >>>>> =20 > > > > >>>> but, if you use the well know prefix this owuld work, > > > cause the > > > > >>>> traffic would flow through the NAT64 located in each > > > ISP, right? > > > > >>>> =20 > > > > >>>> =20 > > > > >>> If that ISP operates a NAT64, yes. So, referrals in > > that case > > > > >>> work once an ISP installs a NAT64 (or the subscriber > > > has some way > > > > >>> to use someone else's NAT64, perhaps via a tunnel and a > > > per-month > > > > >>> fee, for example). But my point is that existing IPv6 > > > hosts and > > > > >>> existing dual-stack hosts, in another ISP, cannot utilize a=20 > > > > >>> synthetic address. > > > > >>> > > > > >>> =20 > > > > >>> =20 > > > > >> but that makes sense, right? > > > > >> > > > > >> > > > > >> I mean this stuff doesn't work when your IPv6 ISP > > > doesn't provide > > > > >> their customer with IPv4 Internet access (i.e it doesn't > > > provide a > > > > >> NAT64) and > > > > >> the cleint itself doesn't pay to any other NAT64 provider. > > > > >> > > > > >> So, if the client doesn't have access to the IPv4 > > > > Internet, not only > > > > >> referrals to the IPv4 internet break, any communication > > > towards the > > > > >> IPv4 internet break, cause he is not paying for that service > > > > >> =20 > > > > > > > > > > The same referral of a synthetic IPv6 address also=20 > breaks to a=20 > > > > > dual-stack host, until/unless that dual-stack host's ISP > > > operates a > > > > > NAT64. And that will not make sense to someone operating a=20 > > > > > dual-stack host -- they will expect referrals to work > > > because they > > > > > are doing The Right Thing: namely, operating a=20 > dual-stack host. > > > > > > > > > > I'll write this all up into an I-D which will hopefully > > make more > > > > > sense. > > > > > > > > > > =20 > > > > So, the case you are considering is: > > > >=20 > > > > Host A is IPv6-only > > > > Host B is dual stack > > > > Host C is IPv4-only > > > >=20 > > > > Host B is obtaining service from an IPv6-only ISP that has > > > not access > > > > to the IPv4 internet > > >=20 > > > No; Host B is dual-stack and fully-functioning (can=20 > access both the=20 > > > v6 and v4 Internet). However, Host B's ISP has not installed a=20 > > > NAT64 device -- at least, not "yet". Perhaps Host B's ISP never=20 > > > will, because Host B's ISP believes that dual-stack hosts are the=20 > > > right answer. Perhaps Host B's ISP will only ever=20 > install a NAT44=20 > > > (in order to continue expanding their business after IPv4=20 > > > exhaustion). Whatever the reason, Host B's ISP does not=20 > operate a=20 > > > NAT64. Host B is running today's dual-stack OS (pick=20 > your favorite)=20 > > > and some > > > dual- stack capable stack. If Host B (dual-stack) is referred to=20 > > > the synthetic IPv6 address for Host C (IPv4-only), Host B=20 > can't do=20 > > > anything useful -- it cannot communicate with Host C. "One Would=20 > > > Expect" that Host B could communicate with Host C, though --=20 > > > afterall, both of them are accessible over IPv4. > > >=20 > > > Resolutions include: > > > 1. tell Host B to run new software that is aware of the > > > synthetic prefix, and strip that synthetic prefix. > > > This allows Host B to connect to Host C using IPv4. > > > 2. tell Host A to run new software that is aware of the > > > synethric prefix, and strip that synthetic prefix > > > before referring Host C's IPv4 address. This allows > > > Host B to connect to Host C using IPv4. > > >=20 > > > There is another interesting scenario, though, using=20 > another host,=20 > > > Host D with is IPv4 only. > > >=20 > > > If the referral is to Host D (IPv4 only), we cannot hope=20 > to refer an=20 > > > IPv6 address to Host D. We can only successful refer an IPv4=20 > > > address to an IPv4 only host. > > >=20 > > > To my analysis, if we want referrals to work across a=20 > NAT64, we need=20 > > > to do (2), above -- namely, the host behind a NAT64 has to remove=20 > > > the synthetic IPv6 address prior to referring the address. =20 > > > Otherwise as soon as an IPv6-only host behind a > > > NAT64 host sends a referral to either an IPv4-only host or to a=20 > > > dual-stack host, the referral fails. > > >=20 > > >=20 > > > I will write this up into an I-D. > > >=20 > > > -d > > >=20 > > >=20 > > > > Host A do get IPv6 Internet access through a translator > > > >=20 > > > > So, host A passes the IPv6 representation of Host C=20 > IPv4 address=20 > > > > to Host B. > > > > Host B could access to Host C if it used the IPv4=20 > address, but it=20 > > > > cannot reach host C using the IPv6 representation cause=20 > its ISP is=20 > > > > not providing NAT64 services, is that what you had in mind? > > > >=20 > > > > But, in this case, the Host B should be able to recognize, > > > if a well > > > > known prefix is used, that the IPv6 address it has=20 > received is an=20 > > > > IPv6 representation of an IPv4 address and use IPv4 connectivity > > > directly. > > > > > > > > I mean, the bottom line here, is that when you pass IPv6 > > > address that > > > > represent IPv4 addresses around, the well know prefix seems > > > to behave > > > > much better, cause you can easily recognize that this is a=20 > > > > represenation of an IPv4 address > > > >=20 > > > > Regards, marcelo > > > >=20 > > > >=20 > > > >=20 > > > > > -d > > > > > > > > > > > > > > > =20 > > > > >> So, i think this is as much as he can for the money he > > > pays, right? > > > > >> > > > > >> In other words, this is not problem of the technology, > > > but it is a > > > > >> porblem of the clietn that is not buying the service > > > > >> > > > > >> Regards, marcelo > > > > >> > > > > >> > > > > >> =20 > > > > >>> -d > > > > >>> > > > > >>> > > > > >>> =20 > > > > >>> =20 > > > > >>>> regards, marcelo > > > > >>>> > > > > >>>> =20 > > > > >>>> =20 > > > > >>>>> I have more details written up on this topic and=20 > will write=20 > > > > >>>>> an I-D to present in San Francisco. > > > > >>>>> > > > > >>>>> -d > > > > >>>>> > > > > >>>>> > > > > >>>>> =20 > > > > >>>>> =20 > > > > >>>>> =20 > > > > >>> =20 > > > > >>> =20 > > > > > > > > > > > > > > > =20 > > > >=20 > > > > _______________________________________________ > > > > Behave mailing list > > > > Behave@ietf.org > > > > https://www.ietf.org/mailman/listinfo/behave > > >=20 > > > _______________________________________________ > > > Behave mailing list > > > Behave@ietf.org > > > https://www.ietf.org/mailman/listinfo/behave > > > =3D >=20 > = From dwing@cisco.com Mon Feb 23 18:05:33 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69F2528C1D2 for ; Mon, 23 Feb 2009 18:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.219 X-Spam-Level: X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, J_CHICKENPOX_72=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 wjBj4pt9RjUs for ; Mon, 23 Feb 2009 18:05:32 -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 EDC4B28C229 for ; Mon, 23 Feb 2009 18:05:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,256,1233532800"; d="scan'208";a="146363956" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 24 Feb 2009 02:05:50 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1O25oYp032150; Mon, 23 Feb 2009 18:05:50 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n1O25o16002052; Tue, 24 Feb 2009 02:05:50 GMT From: "Dan Wing" To: , References: <4975B691.2040009@it.uc3m.es><48771572-B013-4E20-98C3-C475B3A22E92@magma.ca><4991453D.7020900@it.uc3m.es><499A964F.9070707@it.uc3m.es><499EF6A4.70204@piuha.net><0a1901c9938f$3286c7f0$c2f0200a@cisco.com><49A1B992.3070809@it.uc3m.es><0f0001c995f4$a8fa61f0$c2f0200a@cisco.com><49A30AA5.4080101@it.uc3m.es><0f4501c995fa$a1424fd0$c2f0200a@cisco.com><49A320C7.8030004@it.uc3m.es> <100e01c9960c$b2254250$c2f0200a@cisco.com> <108701c99619$f0462f10$c2f0200a@cisco.com> Date: Mon, 23 Feb 2009 18:05:50 -0800 Message-ID: <10cb01c99624$6a9f65b0$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: AcmWBLi5xb2gAP+9QyS2q/XCAYGDVwABTiaQAAIJoCAAAdbGAAABcdhAAAEz21A= In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13220; t=1235441150; x=1236305150; 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[BEHAVE]=20Pref64=20nature=20and=20refe rral=20support. |Sender:=20; bh=5CDJAZsrwuekYRyXATFJDH6pjMnkWoJk5r9z45mLTTY=; b=BENEB6Wh3ftj66PfY1q3nMB2MS1EzmleIPIla+GaX+Ew/OOPlhVr16KkAf VpNzolp4ivHdj+gU13UPQJDYIyM0ezhvpoOep8xzcHAzTnDWc2Sc4K/pxvrv AUoxWAmun0; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: behave@ietf.org, jari.arkko@piuha.net, philip_matthews@magma.ca Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 02:05:33 -0000 =20 > -----Original Message----- > From: H.Miyata@jp.yokogawa.com [mailto:H.Miyata@jp.yokogawa.com]=20 > Sent: Monday, February 23, 2009 5:55 PM > To: dwing@cisco.com; marcelo@it.uc3m.es > Cc: jari.arkko@piuha.net; behave@ietf.org; philip_matthews@magma.ca > Subject: RE: [BEHAVE] Pref64 nature and referral support. >=20 > Dan, >=20 >=20 > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com]=20 > > Sent: Tuesday, February 24, 2009 9:51 AM > > To: Miyata, Hiroshi (H.Miyata@jp.yokogawa.com); marcelo@it.uc3m.es > > Cc: jari.arkko@piuha.net; behave@ietf.org; philip_matthews@magma.ca > > Subject: RE: [BEHAVE] Pref64 nature and referral support. > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: H.Miyata@jp.yokogawa.com [mailto:H.Miyata@jp.yokogawa.com] > > > Sent: Monday, February 23, 2009 4:34 PM > > > To: dwing@cisco.com; marcelo@it.uc3m.es > > > Cc: jari.arkko@piuha.net; behave@ietf.org;=20 > philip_matthews@magma.ca > > > Subject: RE: [BEHAVE] Pref64 nature and referral support. > > >=20 > > > Dan and Marcelo, > > >=20 > > > My suggestion is that we should not mix-up the two features of=20 > > > well-known prefix. > > >=20 > > > As you know well-known prefix has two aspects. > > > - Sythetic address identifier > > > - Routable Prefix > > > (Common prefix to lead the packets to the translators=20 > > on somewhere) > > >=20 > > > The former aspect is useful, of course. > > > The latter aspect is a bit dangerous that would cause=20 > some problems. > > > It means some people outside my routing realm can=20 > > > control the traffic to lead to a translator. > > > The behavior may or may not fit my routing policy. > > >=20 > > > So, the routing information and identification should be=20 > discussed=20 > > > separately. > > >=20 > > > And I have another concern on well-known prefix. > > > Is it routable prefix in global internet? I don't believe so. ;-) > > >=20 > > >=20 > > >=20 > > > Comment on referrals. > > > If a user in ISP-B contacts to SIP service of ISP-A and got=20 > > synthetic=20 > > > address with the local prefix of ISP-A, the user should send the=20 > > > packet to the translator of ISP-A. Because the user is already=20 > > > authorized by SIP service of ISP-A directly or indirectly. > > > Yes, ISP-A may charge for the traffic, but it is already accepted. > >=20 > > That would require some sort of interface between the ISP-A's=20 > > NAT64 device and the its SIP proxy/B2BUA/SBC, in order to=20 > > authorize the referral. We could do that, I suppose. =20 > > But=20 > > what of referrals where some other ISP's SIP service is being=20 > > utilized -- for example, Vonage? In that case, Vonage's SIP=20 > > proxies will not be able to tell ISP-A's NAT64 to allow the=20 > > packets through. > >=20 >=20 > Actually, my point is it works if the ISP designed to make it work. > As you mentioned the interface definition is required in most case. > So, I would like to say, this case can not be the reason to promote=20 > well-known address. >=20 > To answer to your question, the asspmption come from original > referral discussion with my understanding, maybe a long time ago. > In most case SIP sevice would not work with deep cooperation. > So, the case "referal works but traffic is dropped" > unlikely happen in SIP service, I think. That is the conclusion I believe I am reaching as I write the I-D, too. -d > Sorry for your confusion. >=20 > Regards, >=20 > ....hiroshi miyata >=20 >=20 > > > In general, I think the synthetic address builder(in this=20 > > case ISP-A)=20 > > > should take responsibility on the packet sent to the address. > > > If ISP-A and ISP-B collaborate to integrate the translation=20 > > service,=20 > > > they may choose a common pref64 to optimize the traffic. In=20 > > this case=20 > > > both are taking the responsibility. > >=20 > > -d > >=20 > > > Best Regards, > > >=20 > > > ------------------------------------ > > > Hiroshi Miyata, > > > Ubiquitous Field Computing Research Center, Corporate R&D=20 > > Headquaters,=20 > > > Yokogawa Electric Corp. > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: behave-bounces@ietf.org > > > > [mailto:behave-bounces@ietf.org] On Behalf Of Dan Wing > > > > Sent: Tuesday, February 24, 2009 8:16 AM > > > > To: 'marcelo bagnulo braun' > > > > Cc: 'Jari Arkko'; 'Behave WG'; 'Philip Matthews' > > > > Subject: Re: [BEHAVE] Pref64 nature and referral support. > > > >=20 > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: behave-bounces@ietf.org > > > > > [mailto:behave-bounces@ietf.org] On Behalf Of marcelo > > > bagnulo braun > > > > > Sent: Monday, February 23, 2009 2:19 PM > > > > > To: Dan Wing > > > > > Cc: 'Behave WG'; 'Jari Arkko'; 'Philip Matthews' > > > > > Subject: Re: [BEHAVE] Pref64 nature and referral support. > > > > >=20 > > > > > Dan Wing escribi=F3: > > > > > > =20 > > > > > > > > > > > > =20 > > > > > >> -----Original Message----- > > > > > >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > > > > > >> Sent: Monday, February 23, 2009 12:44 PM > > > > > >> To: Dan Wing > > > > > >> Cc: 'Jari Arkko'; 'Behave WG'; 'Philip Matthews' > > > > > >> Subject: Re: [BEHAVE] Pref64 nature and referral support. > > > > > >> > > > > > >> Dan Wing escribi=F3: > > > > > >> > > > > > >> > > > > > >> =20 > > > > > >>> =20 > > > > > >>> =20 > > > > > >>>>> Referring a > > > > > >>>>> synthetic IPv6 address to an IPv6 host belonging to > > > > another ISP > > > > > >>>>> will not work (an ISP is unlikely to operate NAT64 > > > > devices for > > > > > >>>>> the benefit of any IPv6 host on the Internet that > > > > wants to use > > > > > >>>>> it). > > > > > >>>>> =20 > > > > > >>>>> =20 > > > > > >>>>> =20 > > > > > >>>> but, if you use the well know prefix this owuld work, > > > > cause the > > > > > >>>> traffic would flow through the NAT64 located in each > > > > ISP, right? > > > > > >>>> =20 > > > > > >>>> =20 > > > > > >>> If that ISP operates a NAT64, yes. So, referrals in > > > that case > > > > > >>> work once an ISP installs a NAT64 (or the subscriber > > > > has some way > > > > > >>> to use someone else's NAT64, perhaps via a tunnel and a > > > > per-month > > > > > >>> fee, for example). But my point is that existing IPv6 > > > > hosts and > > > > > >>> existing dual-stack hosts, in another ISP, cannot=20 > utilize a=20 > > > > > >>> synthetic address. > > > > > >>> > > > > > >>> =20 > > > > > >>> =20 > > > > > >> but that makes sense, right? > > > > > >> > > > > > >> > > > > > >> I mean this stuff doesn't work when your IPv6 ISP > > > > doesn't provide > > > > > >> their customer with IPv4 Internet access (i.e it doesn't > > > > provide a > > > > > >> NAT64) and > > > > > >> the cleint itself doesn't pay to any other NAT64 provider. > > > > > >> > > > > > >> So, if the client doesn't have access to the IPv4 > > > > > Internet, not only > > > > > >> referrals to the IPv4 internet break, any communication > > > > towards the > > > > > >> IPv4 internet break, cause he is not paying for=20 > that service > > > > > >> =20 > > > > > > > > > > > > The same referral of a synthetic IPv6 address also=20 > > breaks to a=20 > > > > > > dual-stack host, until/unless that dual-stack host's ISP > > > > operates a > > > > > > NAT64. And that will not make sense to someone operating a=20 > > > > > > dual-stack host -- they will expect referrals to work > > > > because they > > > > > > are doing The Right Thing: namely, operating a=20 > > dual-stack host. > > > > > > > > > > > > I'll write this all up into an I-D which will hopefully > > > make more > > > > > > sense. > > > > > > > > > > > > =20 > > > > > So, the case you are considering is: > > > > >=20 > > > > > Host A is IPv6-only > > > > > Host B is dual stack > > > > > Host C is IPv4-only > > > > >=20 > > > > > Host B is obtaining service from an IPv6-only ISP that has > > > > not access > > > > > to the IPv4 internet > > > >=20 > > > > No; Host B is dual-stack and fully-functioning (can=20 > > access both the=20 > > > > v6 and v4 Internet). However, Host B's ISP has not installed a=20 > > > > NAT64 device -- at least, not "yet". Perhaps Host B's=20 > ISP never=20 > > > > will, because Host B's ISP believes that dual-stack=20 > hosts are the=20 > > > > right answer. Perhaps Host B's ISP will only ever=20 > > install a NAT44=20 > > > > (in order to continue expanding their business after IPv4=20 > > > > exhaustion). Whatever the reason, Host B's ISP does not=20 > > operate a=20 > > > > NAT64. Host B is running today's dual-stack OS (pick=20 > > your favorite)=20 > > > > and some > > > > dual- stack capable stack. If Host B (dual-stack) is=20 > referred to=20 > > > > the synthetic IPv6 address for Host C (IPv4-only), Host B=20 > > can't do=20 > > > > anything useful -- it cannot communicate with Host C. =20 > "One Would=20 > > > > Expect" that Host B could communicate with Host C, though --=20 > > > > afterall, both of them are accessible over IPv4. > > > >=20 > > > > Resolutions include: > > > > 1. tell Host B to run new software that is aware of the > > > > synthetic prefix, and strip that synthetic prefix. > > > > This allows Host B to connect to Host C using IPv4. > > > > 2. tell Host A to run new software that is aware of the > > > > synethric prefix, and strip that synthetic prefix > > > > before referring Host C's IPv4 address. This allows > > > > Host B to connect to Host C using IPv4. > > > >=20 > > > > There is another interesting scenario, though, using=20 > > another host,=20 > > > > Host D with is IPv4 only. > > > >=20 > > > > If the referral is to Host D (IPv4 only), we cannot hope=20 > > to refer an=20 > > > > IPv6 address to Host D. We can only successful refer an IPv4=20 > > > > address to an IPv4 only host. > > > >=20 > > > > To my analysis, if we want referrals to work across a=20 > > NAT64, we need=20 > > > > to do (2), above -- namely, the host behind a NAT64 has=20 > to remove=20 > > > > the synthetic IPv6 address prior to referring the address. =20 > > > > Otherwise as soon as an IPv6-only host behind a > > > > NAT64 host sends a referral to either an IPv4-only host or to a=20 > > > > dual-stack host, the referral fails. > > > >=20 > > > >=20 > > > > I will write this up into an I-D. > > > >=20 > > > > -d > > > >=20 > > > >=20 > > > > > Host A do get IPv6 Internet access through a translator > > > > >=20 > > > > > So, host A passes the IPv6 representation of Host C=20 > > IPv4 address=20 > > > > > to Host B. > > > > > Host B could access to Host C if it used the IPv4=20 > > address, but it=20 > > > > > cannot reach host C using the IPv6 representation cause=20 > > its ISP is=20 > > > > > not providing NAT64 services, is that what you had in mind? > > > > >=20 > > > > > But, in this case, the Host B should be able to recognize, > > > > if a well > > > > > known prefix is used, that the IPv6 address it has=20 > > received is an=20 > > > > > IPv6 representation of an IPv4 address and use IPv4=20 > connectivity > > > > directly. > > > > > > > > > > I mean, the bottom line here, is that when you pass IPv6 > > > > address that > > > > > represent IPv4 addresses around, the well know prefix seems > > > > to behave > > > > > much better, cause you can easily recognize that this is a=20 > > > > > represenation of an IPv4 address > > > > >=20 > > > > > Regards, marcelo > > > > >=20 > > > > >=20 > > > > >=20 > > > > > > -d > > > > > > > > > > > > > > > > > > =20 > > > > > >> So, i think this is as much as he can for the money he > > > > pays, right? > > > > > >> > > > > > >> In other words, this is not problem of the technology, > > > > but it is a > > > > > >> porblem of the clietn that is not buying the service > > > > > >> > > > > > >> Regards, marcelo > > > > > >> > > > > > >> > > > > > >> =20 > > > > > >>> -d > > > > > >>> > > > > > >>> > > > > > >>> =20 > > > > > >>> =20 > > > > > >>>> regards, marcelo > > > > > >>>> > > > > > >>>> =20 > > > > > >>>> =20 > > > > > >>>>> I have more details written up on this topic and=20 > > will write=20 > > > > > >>>>> an I-D to present in San Francisco. > > > > > >>>>> > > > > > >>>>> -d > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> =20 > > > > > >>>>> =20 > > > > > >>>>> =20 > > > > > >>> =20 > > > > > >>> =20 > > > > > > > > > > > > > > > > > > =20 > > > > >=20 > > > > > _______________________________________________ > > > > > Behave mailing list > > > > > Behave@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/behave > > > >=20 > > > > _______________________________________________ > > > > Behave mailing list > > > > Behave@ietf.org > > > > https://www.ietf.org/mailman/listinfo/behave > > > > =3D > >=20 > > =3D From dthaler@windows.microsoft.com Mon Feb 23 18:23:10 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BED553A67E7 for ; Mon, 23 Feb 2009 18:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.479 X-Spam-Level: X-Spam-Status: No, score=-110.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 R5figDi6hPZb for ; Mon, 23 Feb 2009 18:23:09 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 1806B28C27B for ; Mon, 23 Feb 2009 18:23:01 -0800 (PST) Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Mon, 23 Feb 2009 18:23:19 -0800 Received: from TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com (157.54.18.79) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) with Microsoft SMTP Server id 8.2.99.4; Mon, 23 Feb 2009 18:23:19 -0800 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::75be:c82f:ae04:55bf]) by TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.79]) with mapi; Mon, 23 Feb 2009 18:23:19 -0800 From: Dave Thaler To: Brian E Carpenter , Dan Wing Date: Mon, 23 Feb 2009 18:23:16 -0800 Thread-Topic: [BEHAVE] BEHAVE status update Thread-Index: AcmUz2dEGpqIGTRJSIujn6/TMnd6HQBVoCyQ Message-ID: References: <0c6301c994b5$f9d7ca30$c2f0200a@cisco.com> <49A11943.5070205@gmail.com> In-Reply-To: <49A11943.5070205@gmail.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Behave WG' , "behave-chairs@tools.ietf.org" Subject: Re: [BEHAVE] BEHAVE status update X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 02:23:10 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Brian E Carpenter > Sent: Sunday, February 22, 2009 1:22 AM > To: Dan Wing > Cc: 'Behave WG'; behave-chairs@tools.ietf.org > Subject: Re: [BEHAVE] BEHAVE status update > > Hi Dan, > > Thanks for the clarity. I do have a couple of questions: > > On 2009-02-22 19:22, Dan Wing wrote: > > An update on some of BEHAVE's activities -- IPv4/IPv6 translation, > TURN, and > > TURN-TCP: > > > > IPv4/IPv6 Translation: > > > > - Dave recently sent a Doodle poll to help prioritize documents > > to adopt. However, as of Saturday night only 5 people have > > replied to this poll. > > I read it as being addressed very specifically to implementors > and operators, which will cut down the response rate. > If you want responses from more people, Q3 ("Have you or are > you planning to deploy...?") would need to be phrased somewhat > differently. Or add a Q4 such as "Do you see a clear operational > requirement for...?". Yes the questions were intentionally tailored to implementers, operators, and end users who might be already using NAT-PT as an end-user. I will remind folks of the note at the end of the poll email: > If you care to provide additional information, then you can > do so in email to the list in addition to the doodle. In other words, the doodle is not intended to be limiting. But there's enough questions there as is and the question like "do you see a clear operational requirement for" isn't quite boolean and I think is better judged from on-list discussion. However, I'm open to others views on that point. > > We will meet our milestone "Determine relative > > prioritization of the four translation cases" at the > > San Francisco BEHAVE meeting. > > I have the impression that we don't have a current analysis document > about these four scenarios, and reaching a decision just on the basis > of the paragraphs in the charter and a doodle poll seems a bit casual. > Section 1.5 of draft-baker-behave-v4v6-framework-01 does discuss two > cases, with placeholders for two others, but they don't seem to be > quite identical to the cases in the charter. Have I missed a document? Right now the doc you mention, and draft-arkko-townsley-coexistence-00.txt both contain a subset of the scenarios and analysis. It would be great if there were a single doc, it were complete. -Dave > Thanks > Brian > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dthaler@windows.microsoft.com Mon Feb 23 18:57:34 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B6863A67BD for ; Mon, 23 Feb 2009 18:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.485 X-Spam-Level: X-Spam-Status: No, score=-110.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 MHTnrNAJ9K1a for ; Mon, 23 Feb 2009 18:57:33 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 7C84D3A657C for ; Mon, 23 Feb 2009 18:57:33 -0800 (PST) Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Mon, 23 Feb 2009 18:57:35 -0800 Received: from TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com (157.54.18.79) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) with Microsoft SMTP Server id 8.2.99.4; Mon, 23 Feb 2009 18:57:35 -0800 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::75be:c82f:ae04:55bf]) by TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.79]) with mapi; Mon, 23 Feb 2009 18:57:35 -0800 From: Dave Thaler To: "behave@ietf.org" Date: Mon, 23 Feb 2009 18:57:33 -0800 Thread-Topic: Prioritization of the translation cases Thread-Index: AcmS2pc+uerkfrT2Qxus7P2IYXVUsgDTFYKg 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Prioritization of the translation cases X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 02:57:34 -0000 The doodle questions were tailored to a) End-users (or anyone really) already using NAT-PT b) Implementers c) Network admins So far 7 people have responded (most with multiple roles each): 1. An IPv6 network to IPv4 Internet a. 2 using NAT-PT b. 4 implementing c. 3 deploying 2. IPv6 Internet to an IPv4 network a. 3 using NAT-PT b. 4 implementing c. 4 deploying 3. An IPv4 network to IPv6 Internet a. 1 using NAT-PT b. 1 implementing c. 0 deploying 4. IPv4 Internet to an IPv6 network a. 1 using NAT-PT b. 5 implementing c. 5 deploying 5. IPv6 to IPv4 within the same organization a. 3 using NAT-PT b. 3 implementing c. 3 deploying 6. IPv4 to IPv6 within the same organization a. 1 using NAT-PT b. 2 implementing c. 2 deploying I would like to encourage anyone who would answer Yes to any question to respond if you haven't already. One goal of prioritization is to decide what order to focus efforts on, if we cannot do them all simultaneously with the same energy. Some tentative observations from the poll so far (we'll see if this changes based on any more responses) 1) all of the scenarios are important to someone 2) Scenario 3 seems the least urgent 3) Scenarios 1, 2, 4, and 5 are all fairly urgent. 4) Scenario 4 is the most popular scenario for IPv4-initiated communication 1, 2, and 5 all have the common property of being initiated from the IPv6 side (and hence some of the same solutions may apply). If others have strong feelings or data to point out, please do so (here on the list). If you want to comment on "Do you see a clear operational requirement for " this would be a good time to start if you haven't already. -Dave ----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf = Of Dave Thaler > Sent: Thursday, February 19, 2009 1:40 PM > To: behave@ietf.org > Subject: [BEHAVE] Prioritization of the translation cases > > On our WG charter we have a milestone to "Determine relative > prioritization of the four translation cases." > > As the first step in doing this, we would like to get a sense > of the energy/importance/urgency of each of the cases. To do > this, we would like to ask three questions per scenario: > > 1) Are you already doing this today with the deprecated NAT-PT? > 2) Have you or are you planning to implement code for this scenario? > 3) Have you or are you planning to deploying this scenario in a real >=A0=A0 environment (not just a test lab)? > > The first question is intended to get a sense of what NAT-PT is being > used for today, which we'd like to replace. The other two questions > are intended to get a sense of interest among those creating solutions, > and those trying to deploy solutions. > > We have set up a doodle poll at: > http://www.doodle.com/9qsdgt8r6kqk6zty > which may appear a bit complicated, but it's just the three > questions above applied to each scenario. > > For completeness we are asking about six scenarios. The first > four are in our charter and the last two are not listed > in our charter, but were discussed as part of IVI, and also we > would like to get a sense of how much deployment of NAT-PT there > is already in those scenarios. The scenarios are: > > 1. An IPv6 network to IPv4 Internet > 2. IPv6 Internet to an IPv4 network > 3. An IPv4 network to IPv6 Internet > 4. IPv4 Internet to an IPv6 network > 5. IPv6 to IPv4 within the same organization > 6. IPv4 to IPv6 within the same organization > > If you care to provide additional information, then you can > do so in email to the list in addition to the doodle. > > Thanks, > -Dave Thaler & Dan Wing From dwing@cisco.com Mon Feb 23 21:59:53 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 316C028C0ED for ; Mon, 23 Feb 2009 21:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 unvLQN2DxDFX for ; Mon, 23 Feb 2009 21:59:48 -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 A0A933A692A for ; Mon, 23 Feb 2009 21:59:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,257,1233532800"; d="scan'208";a="134604186" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 24 Feb 2009 06:00:07 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n1O607TW011958 for ; Mon, 23 Feb 2009 22:00:07 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1O607i4019804 for ; Tue, 24 Feb 2009 06:00:07 GMT From: "Dan Wing" To: Date: Mon, 23 Feb 2009 22:00:05 -0800 Message-ID: <112f01c99645$23da03d0$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 Thread-Index: AcmWBOTVmUru7T5rQYiIKxx0DQC2YwAP+a7w DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3103; t=1235455207; x=1236319207; 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:=20FW=3A=20Several=20ways=20you=20can=20publish=20 I-Ds=20with=20pre=205378=20content=20-=20TODAY |Sender:=20; bh=Hvv70jW4tFNjmmCYHuVjW1NS3BuQgIRYwvuHZOaAWc8=; b=lFMS+iHKbaL7pwk9VfqI3VCJUwcjuRXMBw7L7mmtofbusIRhhrzeHCvcPd PLObNRETr+g5RSbCbHzboE2KyKBqQv7pAEjA3TrLAZbPSU8WJUjY5jKS6XMx 3/UOmuRD8a; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [BEHAVE] FW: Several ways you can publish I-Ds with pre 5378 content - TODAY X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 05:59:53 -0000 In the event anyone has been holding publication due to the RFC5378 issue the summary (below) explains several mechanisms to publish a draft with the RFC5378 workaround text. (Forwarding to BEHAVE because I expect many don't follow the main IETF list.) -d -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Monday, February 23, 2009 2:19 PM To: Working Group Chairs; IETF discussion list Subject: Several ways you can publish I-Ds with pre 5378 content - TODAY Method 1: (Not recommended) Go read the BCP and Trust statement and edit your .txt to have the right text. Method 2: (Recommended for people using word template) Go look at a draft that did work, such as http://tools.ietf.org/html/draft-jennings-http-srv-01 And copy the Copyright Notice section into your draft Method 3: XML2RFC approach recommended for folks that run xml2rfc locally Get the very hacked version at http://svn.resiprocate.org/rep/ietf-drafts/xml2rfc/1.34pre2-fluffy/xml2rfc.tcl This will soon be obsoleted when the real xml2rfc tool gets updated. Don't worry, Julian, Bill, and Marshal are working on that. They will produce something much better than my hack of xml2rfc Set the ipr attribute in the element to ipr="pre5378Trust200902" and it will produce a txt file that id submission tool will accept. Method 4: XML2RFC approach for folks that run xml2rfc on the web Use the experimental version from http://xml.resource.org/experimental.html . You can download the zip or tgz file on this page or use the online version at this page. Make sure you have somewhere above the element. In the element, set the ipr attribute to ipr="trust200811" Change your abstract to use a note. Do this by changing This draft is about ... To This draft is about ... And before this not insert a note like This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. You can seen the XML for an example I-D that does this at http://svn.resiprocate.org/rep/ietf-drafts/fluffy/example.xml That should work - good luck _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From philip_matthews@magma.ca Tue Feb 24 18:14:27 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 609C83A68CE for ; Tue, 24 Feb 2009 18:14:27 -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=[AWL=0.000, 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 pvfHoSQwftXx for ; Tue, 24 Feb 2009 18:14:26 -0800 (PST) Received: from mail-01.primus.ca (mail8.primus.ca [216.254.141.175]) by core3.amsl.com (Postfix) with ESMTP id 4A4CB3A68B2 for ; Tue, 24 Feb 2009 18:14:26 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Lc9IK-00086o-3A for behave@ietf.org; Tue, 24 Feb 2009 21:14:45 -0500 Message-Id: <3975D16E-3CFB-40E0-B208-247A055A9BDB@magma.ca> From: Philip Matthews To: Behave WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 24 Feb 2009 21:14:39 -0500 X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] Subject: [BEHAVE] TURN-13 posted X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 02:14:27 -0000 I have just posted version 13 of the TURN specification (draft-ietf- behave-turn-13). This version addresses the comments received during IETF Last Call. Substantive changes from -12 to -13: * Added a new error code: 403 (Forbidden), and specified that this error code is returned when the server processes a CreatePermission or ChannelBind request and decides that it wishes to reject the supplied IP address and port combination for administrative reasons. Version -12 did not specify an error code to use in this situation, and none of the existing error codes seemed appropriate. (Thanks to Magnus and others for catching this) * In the IANA considerations section, added a request to IANA to establish a registry for channel numbers. This originally seemed unnecessary to me, given the nature of channel numbers, but enough people asked about this, so I went ahead and did it. * Clarified the usage of the nonce value in the Long-Term Credential Mechanism: a new random nonce SHOULD be selected for each Allocate attempt, and the nonce SHOULD be expired at least once every hour. Also referenced RFC 4086 for guidelines on selecting the nonce value. In addition to these technical changes, there are a number of editorial changes that either fixed typos or that cleaned up the presentation in various places. There were two notable proposed changes that did NOT make it into this version: * A request to add support for relaying ICMP messages, and * A request to change the lifetime of a channel binding from 10 minutes to 5 minutes. Neither change gathered enough WG support to be added. Many thanks to everyone who submitted comments. Submitting this version of TURN was a bit of a challenge, given all the IPR boilerplate and related tool issues. TURN is produced using Bill Fenner's xxe plug-in for XMLMind and the on-line conversion tool at xml.resource.org, neither one of which was updated at the time of submission. Thanks to Cullen for figuring out how to produce an I-D that includes the necessary clause about pre-Nov10 text and which passes the idnits tool, and to Dan for pointing me at Cullen's instructions. It is ironic that all this blew up for version -13, especially since this version is likely the one that will go to IESG evaluation. - Philip From root@core3.amsl.com Tue Feb 24 18:15:01 2009 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4553C3A6918; Tue, 24 Feb 2009 18:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090225021501.4553C3A6918@core3.amsl.com> Date: Tue, 24 Feb 2009 18:15:01 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-turn-13.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 02:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-behave-turn-13.txt Pages : 76 Date : 2009-02-24 If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it can be also used without ICE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-13.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 Content-Type: Message/External-body; name="draft-ietf-behave-turn-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-24180809.I-D@ietf.org> --NextPart-- From xing@cernet.edu.cn Wed Feb 25 22:08:21 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68EE628C1E7 for ; Wed, 25 Feb 2009 22:08:21 -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 BKz6bN8LhWTm for ; Wed, 25 Feb 2009 22:08:20 -0800 (PST) Received: from ocean.net.edu.cn (ocean.net.edu.cn [202.112.0.56]) by core3.amsl.com (Postfix) with ESMTP id 4792128C1DF for ; Wed, 25 Feb 2009 22:08:18 -0800 (PST) Received: from [127.0.0.1] (ocean.net.edu.cn [202.112.0.56]) by ocean.net.edu.cn with ESMTP id n1Q66phd007669; Thu, 26 Feb 2009 14:06:54 +0800 (CST) Message-ID: <49A6317B.2080502@cernet.edu.cn> Date: Thu, 26 Feb 2009 14:06:51 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dave Thaler References: <0c6301c994b5$f9d7ca30$c2f0200a@cisco.com> <49A11943.5070205@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Behave WG' , Dan Wing , "behave-chairs@tools.ietf.org" Subject: Re: [BEHAVE] BEHAVE status update X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 06:08:21 -0000 >>> E meeting. >>> >> I have the impression that we don't have a current analysis document >> about these four scenarios, and reaching a decision just on the basis >> of the paragraphs in the charter and a doodle poll seems a bit casual. >> Section 1.5 of draft-baker-behave-v4v6-framework-01 does discuss two >> cases, with placeholders for two others, but they don't seem to be >> quite identical to the cases in the charter. Have I missed a document? >> > > Right now the doc you mention, and draft-arkko-townsley-coexistence-00.txt > both contain a subset of the scenarios and analysis. It would be > great if there were a single doc, it were complete. > We try to summary the scenarios in http://www.ietf.org/internet-drafts/draft-baker-behave-v4v6-framework-02.txt please comment. xing > -Dave > > >> Thanks >> Brian >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > From dwing@cisco.com Thu Feb 26 12:04:11 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F8323A6818 for ; Thu, 26 Feb 2009 12:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 90dyEhhJywPK for ; Thu, 26 Feb 2009 12:04:10 -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 2C1C73A6902 for ; Thu, 26 Feb 2009 12:04:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,272,1233532800"; d="scan'208";a="147982581" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 26 Feb 2009 20:04:32 +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 n1QK4VHB015378 for ; Thu, 26 Feb 2009 12:04:31 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1QK4VmR029105 for ; Thu, 26 Feb 2009 20:04:31 GMT From: "Dan Wing" To: "'behave mailing list'" Date: Thu, 26 Feb 2009 12:04:31 -0800 Message-ID: <083001c9984d$702de710$63726b80@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 Thread-Index: AcmYSGqV8c+LMfxAQYO0S/t99g14fwABPbYA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1304; t=1235678671; x=1236542671; 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:=20FW=3A=20Initial=20Version=20I-D=20Submission=20 Deadline=20Extended=20to=20March=204,=202009 |Sender:=20; bh=I0eA4stZtujnMlSBPe1f9NfTWd70tQaRQseM6mTRivM=; b=cSoqPvzfYVH1Lq5OxJ0K3wrBpvDrdccI1RqnB9GBQHMDOQCbSMiMlzryQx Oy24PjtGMrWvKppYbIpnDH9nvnCFfiCuJRZThrTPr7XH7skKRySp8YwFF2Zb H4hobaWgKRZAGm+R+Vz2XJ3XNE84Oa11YFBGuNMMKPx19UnpyDavs=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [BEHAVE] FW: Initial Version I-D Submission Deadline Extended to March 4, 2009 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 20:04:11 -0000 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of Alexa Morris Sent: Thursday, February 26, 2009 11:28 AM To: ietf-announce@ietf.org; ietf@ietf.org; wgchairs@ietf.org Subject: Initial Version I-D Submission Deadline Extended to March 4, 2009 The IESG has extended the deadline for initial version (00) submissions of Internet Drafts by 2 days (48 hours). The new deadline is March 4, 2009 at 1700 Pacific (March 5, 2009 at 0100 UTC / GMT) and the extension is for IETF 74 only. The deadline has been extended due to the copyright legend text alternative being recently finalized, approved and implemented. Please note that the date for updated I-D versions has NOT been extended, and is still March 9, 2009. Regards, Alexa ----------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From rpenno@juniper.net Thu Feb 26 15:06:54 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0570328C225 for ; Thu, 26 Feb 2009 15:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.502 X-Spam-Level: X-Spam-Status: No, score=-4.502 tagged_above=-999 required=5 tests=[AWL=2.097, 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 ClXi1eIGghNJ for ; Thu, 26 Feb 2009 15:06:53 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 388493A6867 for ; Thu, 26 Feb 2009 15:06:47 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSacgnbT1KggiD2DbvbclCqbfwohQ58sK@postini.com; Thu, 26 Feb 2009 15:07:09 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 26 Feb 2009 15:03:35 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 15:03:35 -0800 Received: from antipi.jnpr.net ([10.10.2.34]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 15:03:35 -0800 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Feb 2009 18:03:34 -0500 Received: from 172.23.1.92 ([172.23.1.92]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 Feb 2009 23:03:33 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 26 Feb 2009 15:03:32 -0800 From: Reinaldo Penno To: Message-ID: Thread-Topic: Comments on nat64-02 Thread-Index: AcmYZeK+9g6kF6Om0U+vq1rJUxoUigAAI8Os In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2009 23:03:34.0430 (UTC) FILETIME=[733E03E0:01C99866] Subject: [BEHAVE] Comments on nat64-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 23:06:54 -0000 Hello, I've been going through nat64 and have a few comments/questions: 1) " 2. H1 sends a packet to H2. The packet is sent from a source transport address of (Y',y) to a destination transport address of (Pref64:X,x), where y and x are ports chosen by H2." How can H2 (the destination) choose the source port of both the packets used by the v6 host and the NAT64 on the IPv4 interface? Should it say H1? There are also recommendations on RFC4787 about how ports should be mapped from internal to external networks. I'm assuming those should apply also to NAT64. 2) " * The NAT64 includes (Y',y) as source transport address in the packet and (Pref64:X,x) as destination transport address in the packet. Note that X is extracted directly from the source IPv4 address of the received IPv4 packet that is being translated." Maybe you mean (Y', y) as the destination and (Pref64:X, x) as the source? 3) " If a NAT64 filters on its IPv4 interface, then an incoming packet is dropped unless a packet has been recently sent out the interface with a destination IP address equal to the source IP address of the incoming packet." Maybe substitute this wording by "address-dependent filtering according to RFC4787". Below you say " NAT64 filtering is consistent with the recommendations of RFC 4787.", but RFC4787 REQ-8 allows filtering depending on what is important for the NAT device: security vs. application transparency. Is the reason for address-dependent filtering security? 4) " NOTE: The transport protocol is always one of TCP or UDP, even if the IP packet contains an ICMP message." I'm assuming per your TBD this will go away when the draft has ICMP Query support? 5) " Assuming it otherwise has sufficient resources, a NAT64 MUST allow the fragments to arrive over a time interval of at least 10 seconds. A NAT64 MAY require that the UDP, TCP, or ICMP header be completely contained within the first fragment." Can you cite the reference for using for the time of at least 10 seconds as a "MUST"? 6) " 1. If the packet arrived on the IPv4 interface and the NAT64 filters on its IPv4 interface, then the NAT64 checks to see if the incoming packet is allowed according to the address-dependent filtering rule. To do this, it searches for a session table entry with a source IPv4 address equal to the source IPv4 address in the incoming 5-tuple. If such an entry is found (there may be more than one), packet processing continues. Otherwise, the packet is discarded. If the packet is discarded, then an ICMP message SHOULD be sent to the original sender of the packet, unless the discarded packet is itself an ICMP message. The ICMP message, if sent, has a type of 3 (Destination Unreachable) and a code of 13 (Communication Administratively Prohibited)." In general I find this section and similar ones very implementation specific, but regardless I have one comment. I think you mean "... searches for a session table entry with a source IPv4 address equal to the destination IPv4 address in the incoming 5-tuple", otherwise they will never match since the source IP address used by the NAT64 device will always be different from the source v4 address used by external hosts. So, you try to match the destination IPv4 address of a possibly unsolicited packet with a v4 session that already exists in the session table the opposite direction, right? This seems consistent with step 2. 7) " 3. The NAT64 sets or resets the timer in the session table entry to maximum session lifetime. By default, the maximum session lifetime is 5 minutes, but for specific destination ports in the Well-Known port range (0..1023), the NAT64 MAY use a smaller maximum lifetime." This seems to be at odds with REQ-5, REQ-5c of RFC4787 You use the word "maximum", but those requirements use " c) A default value of five minutes or more for the NAT UDP mapping timer is RECOMMENDED." In other words 5 minutes or more is rather different than a maximum of 5 minutes. Maybe you can reference REQ-5c here. Thanks, Reinaldo ------ End of Forwarded Message From huitema@windows.microsoft.com Thu Feb 26 23:41:47 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1F313A6A26 for ; Thu, 26 Feb 2009 23:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0KXil3dcJ0b for ; Thu, 26 Feb 2009 23:41:47 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 0650B3A68FE for ; Thu, 26 Feb 2009 23:41:46 -0800 (PST) Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Thu, 26 Feb 2009 23:41:57 -0800 Received: from TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com (157.54.18.79) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) with Microsoft SMTP Server id 8.2.99.4; Thu, 26 Feb 2009 23:41:47 -0800 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::75be:c82f:ae04:55bf]) by TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.79]) with mapi; Thu, 26 Feb 2009 23:41:47 -0800 From: Christian Huitema To: Philip Matthews Date: Thu, 26 Feb 2009 23:41:46 -0800 Thread-Topic: [BEHAVE] TURN-13 posted Thread-Index: AcmW71ctDqqlOhCMSdyoOiPPpBne2QBvoaBg Message-ID: <8EFB68EAE061884A8517F2A755E8B60A19DB1B29AC@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <3975D16E-3CFB-40E0-B208-247A055A9BDB@magma.ca> In-Reply-To: <3975D16E-3CFB-40E0-B208-247A055A9BDB@magma.ca> 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: "rohan@ekabal.com" , Behave WG Subject: Re: [BEHAVE] TURN-13 posted X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 07:41:47 -0000 Just a nit, but the coding of the "Even-Port" parameter is described as sin= gle byte in section 14.6. EVEN-PORT, page 45. Should I understand correctly= that the parameter's value should in fact be padded to a 32 bit word bound= ary, following STUN conventions? -- Christian Huitema From mohamed.boucadair@orange-ftgroup.com Thu Feb 26 23:51:50 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E38028C200 for ; Thu, 26 Feb 2009 23:51:50 -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 FFsbDTrkaWpW for ; Thu, 26 Feb 2009 23:51:49 -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 62FA328C1E8 for ; Thu, 26 Feb 2009 23:51:49 -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:09 +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:52:08 +0100 Message-ID: <6CF039C5B32037498B02251E11CDE6B007CDB05E@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+9jRJKbQABP1Mw From: To: X-OriginalArrivalTime: 27 Feb 2009 07:52:09.0452 (UTC) FILETIME=[4ADE52C0:01C998B0] Subject: [BEHAVE] TR: I-D Action:draft-boucadair-behave-ipv6-portrange-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 07:51:50 -0000 =20 Dear all, FYI, we have submited 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 rpenno@juniper.net Fri Feb 27 11:30:28 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51E313A67A3 for ; Fri, 27 Feb 2009 11:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.026 X-Spam-Level: X-Spam-Status: No, score=-5.026 tagged_above=-999 required=5 tests=[AWL=1.573, 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 LJsImwMeYlef for ; Fri, 27 Feb 2009 11:30:27 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 175F43A6966 for ; Fri, 27 Feb 2009 11:30:27 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSag/apqJYDBWtWVWVRefEW9Wb7HtRm+l@postini.com; Fri, 27 Feb 2009 11:30:50 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Fri, 27 Feb 2009 11:28:55 -0800 Received: from p-emsmtp03.jnpr.net ([66.129.254.54]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 11:28:55 -0800 Received: from antipi.jnpr.net ([10.10.2.34]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 11:28:55 -0800 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Feb 2009 14:28:54 -0500 Received: from 172.23.1.92 ([172.23.1.92]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Fri, 27 Feb 2009 19:28:53 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 27 Feb 2009 11:28:52 -0800 From: Reinaldo Penno To: Message-ID: Thread-Topic: [BEHAVE] Comments on nat64-02 Thread-Index: AcmYZeK+9g6kF6Om0U+vq1rJUxoUigAAI8OsACrLVck= In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Feb 2009 19:28:54.0024 (UTC) FILETIME=[A055C880:01C99911] Subject: Re: [BEHAVE] Comments on nat64-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 19:30:28 -0000 A few more comments as I go through: 7) " So, NAT64 implements by definition, at least, endpoint independent filtering, meaning that in order to enable any packet to flow from the IPv4 side to the IPv6 side, , there must have been a packet flowing from the IPv6 side to the IPv4 side the created the binding information to be used for packets in the other direction." I do not think one follows from the other as stated. Sending a packet from ipv6 to ipv4 only creates the binding. It does not enable packets to flow from ipv4 to ipv6. The mapping strategy might be different from the filtering strategy. I think (maybe I'm wrong) that the intent on RFC487 in separating mapping from filtering was to make these orthogonal issues and allow security to override things if needed. 8) " So, NAT64 implements by definition, at least, endpoint independent filtering, meaning that in order to enable any packet to flow from the IPv4 side to the IPv6 side," You mention endpoint independent but in section "1.2.3. Filtering" what you seem to describe is address-dependent filtering. 9) " It is possible to configure the NAT64 to implement more stringent security policy, if endpoint independent mapping is considered not secure enough" I think you mean "endpoint independent filtering" as opposed to endpoint independent mapping. Thanks, Reinaldo On 2/26/09 3:03 PM, "Reinaldo Penno" wrote: > > Hello, > > I've been going through nat64 and have a few comments/questions: > > 1) > > " 2. H1 sends a packet to H2. The packet is sent from a source > transport address of (Y',y) to a destination transport address of > (Pref64:X,x), where y and x are ports chosen by H2." > > How can H2 (the destination) choose the source port of both the packets used > by the v6 host and the NAT64 on the IPv4 interface? Should it say H1? > > There are also recommendations on RFC4787 about how ports should be mapped > from internal to external networks. I'm assuming those should apply also to > NAT64. > > > 2) > > " * The NAT64 includes (Y',y) as source transport address in the > packet and (Pref64:X,x) as destination transport address in > the packet. Note that X is extracted directly from the source > IPv4 address of the received IPv4 packet that is being > translated." > > Maybe you mean (Y', y) as the destination and (Pref64:X, x) as the source? > > 3) > " If a NAT64 filters on its IPv4 interface, then an incoming packet is > dropped unless a packet has been recently sent out the interface with > a destination IP address equal to the source IP address of the > incoming packet." > > Maybe substitute this wording by "address-dependent filtering according to > RFC4787". > > Below you say " NAT64 filtering is consistent with the recommendations of > RFC 4787.", but RFC4787 REQ-8 allows filtering depending on what is > important for the NAT device: security vs. application transparency. > > Is the reason for address-dependent filtering security? > > > 4) > > " NOTE: The transport protocol is always one of TCP or UDP, even if > the IP packet contains an ICMP message." > > I'm assuming per your TBD this will go away when the draft has ICMP Query > support? > > 5) > " Assuming it otherwise has sufficient resources, a NAT64 MUST allow > the fragments to arrive over a time interval of at least 10 seconds. > A NAT64 MAY require that the UDP, TCP, or ICMP header be completely > contained within the first fragment." > > Can you cite the reference for using for the time of at least 10 seconds as > a "MUST"? > > 6) > > " 1. If the packet arrived on the IPv4 interface and the NAT64 filters > on its IPv4 interface, then the NAT64 checks to see if the > incoming packet is allowed according to the address-dependent > filtering rule. To do this, it searches for a session table > entry with a source IPv4 address equal to the source IPv4 address > in the incoming 5-tuple. If such an entry is found (there may be > more than one), packet processing continues. Otherwise, the > packet is discarded. If the packet is discarded, then an ICMP > message SHOULD be sent to the original sender of the packet, > unless the discarded packet is itself an ICMP message. The ICMP > message, if sent, has a type of 3 (Destination Unreachable) and a > code of 13 (Communication Administratively Prohibited)." > > In general I find this section and similar ones very implementation > specific, but regardless I have one comment. > > I think you mean > > "... searches for a session table > entry with a source IPv4 address equal to the destination IPv4 > address in the incoming 5-tuple", > > otherwise they will never match since the source IP address used by the > NAT64 device will always be different from the source v4 address used by > external hosts. > > So, you try to match the destination IPv4 address of a possibly unsolicited > packet with a v4 session that already exists in the session table the > opposite direction, right? This seems consistent with step 2. > > 7) > > " 3. The NAT64 sets or resets the timer in the session table entry to > maximum session lifetime. By default, the maximum session > lifetime is 5 minutes, but for specific destination ports in the > Well-Known port range (0..1023), the NAT64 MAY use a smaller > maximum lifetime." > > This seems to be at odds with REQ-5, REQ-5c of RFC4787 > > You use the word "maximum", but those requirements use " c) A default > value of five minutes or more for the NAT UDP mapping > timer is RECOMMENDED." > > In other words 5 minutes or more is rather different than a maximum of 5 > minutes. > > Maybe you can reference REQ-5c here. > > > Thanks, > > Reinaldo > > > > > > > > ------ End of Forwarded Message > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From philip_matthews@magma.ca Fri Feb 27 17:38:43 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B306728C18E for ; Fri, 27 Feb 2009 17:38:43 -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=[AWL=0.000, 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 yZ9BvuqfEw7S for ; Fri, 27 Feb 2009 17:38:43 -0800 (PST) Received: from mail-05.primus.ca (mail9.primus.ca [216.254.141.176]) by core3.amsl.com (Postfix) with ESMTP id DA90528C144 for ; Fri, 27 Feb 2009 17:38:42 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1LdEAT-0005Pz-0w; Fri, 27 Feb 2009 20:39:05 -0500 Message-Id: From: Philip Matthews To: Christian Huitema In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A19DB1B29AC@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 27 Feb 2009 20:39:09 -0500 References: <3975D16E-3CFB-40E0-B208-247A055A9BDB@magma.ca> <8EFB68EAE061884A8517F2A755E8B60A19DB1B29AC@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] Cc: Rohan Mahy , Behave WG Subject: Re: [BEHAVE] TURN-13 posted X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 01:38:43 -0000 On Fri, 27-Feb-09, at 02:41 , Christian Huitema wrote: > Just a nit, but the coding of the "Even-Port" parameter is described > as single byte in section 14.6. EVEN-PORT, page 45. Should I > understand correctly that the parameter's value should in fact be > padded to a 32 bit word boundary, following STUN conventions? > > > -- Christian Huitema > Yes. The rules of section 15 of RFC5389 must be followed: The value in the length field MUST contain the length of the Value part of the attribute, prior to padding, measured in bytes. Since STUN aligns attributes on 32-bit boundaries, attributes whose content is not a multiple of 4 bytes are padded with 1, 2, or 3 bytes of padding so that its value contains a multiple of 4 bytes. The padding bits are ignored, and may be any value. The last bit applies to the EVEN-PORT and DATA attributes of TURN. I suppose we could include a sentence in the spec saying this explicitly, even though the TURN spec does say (section 4): TURN is an extension to STUN. All TURN messages, with the exception of the ChannelData message, are STUN-formatted messages. All the base processing rules described in [RFC5389] apply to STUN-formatted messages. This means that all the message-forming and -processing descriptions in this document are implicitly prefixed with the rules of [RFC5389]. - Philip