From mohta@necom830.hpcl.titech.ac.jp Sun Feb 5 14:41:43 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2FB21F8543 for ; Sun, 5 Feb 2012 14:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dIQqg7YQGob for ; Sun, 5 Feb 2012 14:41:41 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 6CE9221F84F9 for ; Sun, 5 Feb 2012 14:41:41 -0800 (PST) Received: (qmail 42007 invoked from network); 5 Feb 2012 22:53:45 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 5 Feb 2012 22:53:45 -0000 Message-ID: <4F2F057B.3050100@necom830.hpcl.titech.ac.jp> Date: Mon, 06 Feb 2012 07:40:59 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: pcp@ietf.org References: <044401ccd66e$77265810$65730830$@com> In-Reply-To: <044401ccd66e$77265810$65730830$@com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [pcp] draft-ietf-pcp-base-22 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 22:41:43 -0000 Dan Wing wrote: > draft-ietf-pcp-base-22 > was just posted with changes as a result of Dave Thaler's review. I have read the PCP draft for the first time (I noticed the presence of the WG just recently) to find it, sorry, extremely verbose and pedantic, which, seemingly, has hide several essential problems unnoticed by many. The followings are problems I noticed ordered less serious ones first. 1) though a minor problem, the same figure is represented in different ways as "4,294,967,295" and "4294967295", both of which are pedantic. The useful representation for most readers should be "2^32-1" or "2**32-1". 2) The draft seemingly assumes, like UPnP, a private network is a single subnet. A client use PCP, only when an address of its peer is located outside of the private network (some peer may not have outside address). But, there is no information of multiple prefixes which constitute the private network consisting from multiple subnets, which means the client must assume local subnet is the single prefix private network. 3) The following paragraph in 6.2 is self contradictory: Reserved: 96 reserved bits, MUST be sent as 0, MUST be ignored when received. This is set by the server. This padding exists so that for unrecognized requests, the server can blindly copy an entire request message into a response message and have that response make some kind of reasonable sense to the recipient. It says "MUST be sent as 0" and "the server can blindly copy". 4) PCP over UDP over IPv4 MUST use UDP checksum. IPv6 UDP of RFC2460 should also be referred. 5) In 7.1, there is a exponential back-off described and I can't understand why 15 minutes, not 1024 seconds, is the upper limit. Unlike "4294967295" of 1), "1024 seconds" is a lot more straight forward here to understand and to implement. 6) More seriously on exponential back-off, in case there are a lot of clients simultaneously sending requests, the initial request SHOULD (not "MUST", because there are cases we can expect clients not synchronized or 1 second is lengthy) be delayed randomly between 0 to 1 seconds and subsequent waiting MUST also be random, which SHOULD be between [1, 2], [2, 4], [4, 8], ... and [512, 1024] seconds. 7) In 6.2, it should be mentioned client must start decreasing lifetime not when a response packet is received but when a request packet corresponding to the response packet was sent. 8) Though there is verbose and pedantic discussion on idempotency in section 7, it does not make sense. We may send requests at times 0, 2, 6, 14 and receive a response at time 25, which may be a response to the request at time 0. Then, because of 7), 25 seconds of lifetime has already passed. Thus, we must be able to match requests and responses, which means packets needs something like sequence numbers, which must be copied from requests to responses, which makes the protocol not idempotent w.r.t. the sequence numbers. DHCP, for example, has a "secs" field. Having such correspondences, there is no point to blindly copy everything from requests to responses weakly expecting that we might be able to match requests and responses, removal of related descriptions could improve the draft a little. Masataka Ohta From dwing@cisco.com Thu Feb 9 01:07:35 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD6E21F8510 for ; Thu, 9 Feb 2012 01:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.551 X-Spam-Level: X-Spam-Status: No, score=-106.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6mlv-XU63gf for ; Thu, 9 Feb 2012 01:07:34 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3FA21F847D for ; Thu, 9 Feb 2012 01:07:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=6246; q=dns/txt; s=iport; t=1328778454; x=1329988054; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=nUIkUx3LMzAjZcy7R2Mv91P/Z9hgTk2TNRK8evtgqFU=; b=gqzC18C2kE0got1ltUFLCdaJLUFhHRT2+nGI3sRM88HAlaFYTVHnAIwf xRdzX7kx1KotNhnDYzJzbr5qSFwv0foBN6RttZvFVLjsFSXBzaWDcoM2u 1qNRM7Tu/MQh1LxXZnYCvK/QVEMiyeDQzPvN9Oq82GSx0amcgT6t3j28v s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFADKMM0+rRDoI/2dsb2JhbABEDqAcjnqBB4FyAQEBAwEBAQEFCgEXEDQQBwEDAgkOAQIEAQEBJwcZDhUKCQgBAQQBEgsXh1oJmkgBnmCLQwMIBAgFDQIKAwcEAQEGATsBAgQFBBsBhDSDQwSNTpoNOA X-IronPort-AV: E=Sophos;i="4.73,389,1325462400"; d="scan'208";a="29470068" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 09 Feb 2012 09:07:34 +0000 Received: from dwingWS (sjc-vpn3-146.cisco.com [10.21.64.146]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1997WE6019269; Thu, 9 Feb 2012 09:07:33 GMT From: "Dan Wing" To: "'Masataka Ohta'" , References: <044401ccd66e$77265810$65730830$@com> <4F2F057B.3050100@necom830.hpcl.titech.ac.jp> In-Reply-To: <4F2F057B.3050100@necom830.hpcl.titech.ac.jp> Date: Thu, 9 Feb 2012 10:07:32 +0100 Message-ID: <227d01cce70a$42925fc0$c7b71f40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczkV1n9MxHRIzoqRrWwB2/Ke01E4gCLMZ1A Content-Language: en-us Subject: Re: [pcp] draft-ietf-pcp-base-22 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 09:07:35 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Masataka Ohta > Sent: Sunday, February 05, 2012 11:41 PM > To: pcp@ietf.org > Subject: Re: [pcp] draft-ietf-pcp-base-22 > > Dan Wing wrote: > > > draft-ietf-pcp-base-22 base-22> > > was just posted with changes as a result of Dave Thaler's review. > > I have read the PCP draft for the first time (I noticed > the presence of the WG just recently) to find it, > sorry, extremely verbose and pedantic, which, seemingly, > has hide several essential problems unnoticed by many. > > The followings are problems I noticed ordered less > serious ones first. > > 1) though a minor problem, the same figure is represented > in different ways as "4,294,967,295" and "4294967295", > both of which are pedantic. The useful representation > for most readers should be "2^32-1" or "2**32-1". Adjusted all to 2^32-1. > 2) The draft seemingly assumes, like UPnP, a private network > is a single subnet. A client use PCP, only when an address of > its peer is located outside of the private network (some > peer may not have outside address). But, there is no > information of multiple prefixes which constitute the > private network consisting from multiple subnets, which > means the client must assume local subnet is the single > prefix private network. The draft assumes there is a default route to the Internet, which is where outbound packets (towards the Internet) will be sent (e.g., TCP SYN). That is the path "to the Internet", and PCP communications go to that same first hop towards the Internet. This is different from UPnP, which uses an advertisement method -- which can cause a UPnP IGD to be installed on a network which is not on the path to the Internet. > 3) The following paragraph in 6.2 is self contradictory: > > Reserved: 96 reserved bits, MUST be sent as 0, MUST be ignored when > received. This is set by the server. This padding exists so > that > for unrecognized requests, the server can blindly copy an entire > request message into a response message and have that response > make some kind of reasonable sense to the recipient. > > It says "MUST be sent as 0" and "the server can blindly copy". Fixed, thanks. > 4) PCP over UDP over IPv4 MUST use UDP checksum. IPv6 UDP of > RFC2460 should also be referred. For IPv4, if a host's UDP checksumming is disabled system-wide, an application implementing PCP may not be able to enable the host's UDP checksum for that socket. Is there value in making those deployments violate the PCP specification? For IPv6, all UDP packets have to be checksummed. I don't see a need to restate that in this document. I mean, the document also doesn't say that IP header checksum needs to be calculated. > 5) In 7.1, there is a exponential back-off described and I > can't understand why 15 minutes, not 1024 seconds, is the > upper limit. Changed from "15 minutes" to "1024 seconds". Thanks. > Unlike "4294967295" of 1), "1024 seconds" is a > lot more straight forward here to understand and to implement. > > 6) More seriously on exponential back-off, in case there are > a lot of clients simultaneously sending requests, the initial > request SHOULD (not "MUST", because there are cases we can > expect clients not synchronized or 1 second is lengthy) be > delayed randomly between 0 to 1 seconds and subsequent waiting > MUST also be random, which SHOULD be between [1, 2], [2, 4], > [4, 8], ... and [512, 1024] seconds. Ok, I went with: When attempting to contact a PCP server, the PCP client sends a PCP message to the first server in its list of PCP servers, and SHOULD initialize a timer to a random value between 2 and 3 seconds. For as long as the client still desires the indicated mapping, if no response is received before the timer expires then the request is re-transmitted. These re-transmissions are sent at a random value between 1.5 and 2.5 of the previous transmission interval. The randomization helps avoid client synchronization. This repeats until a maximum retransmission interval between 512 and 1024 seconds, at which point the retransmission continue at that interval, until a successful response is received or the client no longer desires the indicated mapping. > 7) In 6.2, it should be mentioned client must start > decreasing lifetime not when a response packet is received > but when a request packet corresponding to the response > packet was sent. Not sure how that would work. The client can request whatever time it wants (e.g., 20 seconds, 720 hours), but the server is what decides the actual lifetime -- which can be minimized against a value such as 60 seconds or maximized against a value such as 24 hours. > 8) Though there is verbose and pedantic discussion on > idempotency in section 7, it does not make sense. > > We may send requests at times 0, 2, 6, 14 and receive a > response at time 25, which may be a response to the > request at time 0. Then, because of 7), 25 seconds of > lifetime has already passed. > > Thus, we must be able to match requests and > responses, which means packets needs something like > sequence numbers, which must be copied from requests to > responses, which makes the protocol not idempotent > w.r.t. the sequence numbers. > > DHCP, for example, has a "secs" field. > > Having such correspondences, there is no point to > blindly copy everything from requests to responses > weakly expecting that we might be able to match > requests and responses, removal of related descriptions > could improve the draft a little. The PCP working group had a long discussion regarding the need for sequence numbers / transaction numbers, and decided they were unnecessary. -d > Masataka Ohta > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From internet-drafts@ietf.org Fri Feb 10 03:44:17 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC3021F86A5; Fri, 10 Feb 2012 03:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnTa+Y1kvJMu; Fri, 10 Feb 2012 03:44:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0533021F8666; Fri, 10 Feb 2012 03:44:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120210114417.13301.49253.idtracker@ietfa.amsl.com> Date: Fri, 10 Feb 2012 03:44:17 -0800 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-base-23.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 11:44:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Port Control Protocol Working Group o= f the IETF. Title : Port Control Protocol (PCP) Author(s) : Dan Wing Stuart Cheshire Mohamed Boucadair Reinaldo Penno Paul Selkirk Filename : draft-ietf-pcp-base-23.txt Pages : 93 Date : 2012-02-10 The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a network address translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-23.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcp-base-23.txt From dwing@cisco.com Fri Feb 10 03:44:49 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91CF21F869E for ; Fri, 10 Feb 2012 03:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.552 X-Spam-Level: X-Spam-Status: No, score=-106.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id og7d22eIO5I7 for ; Fri, 10 Feb 2012 03:44:49 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 14B9D21F8667 for ; Fri, 10 Feb 2012 03:44:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3019; q=dns/txt; s=iport; t=1328874289; x=1330083889; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=IcedkkbFVIQSFT/fKv6OGcDYwdOrZXrrT4UmWeqLt8I=; b=kQ8Abrx3A7xPKxtrYxtdVkVr99lh1/trW8z3v50RptQYxC9EMeoRbkjC CCvlY9kCnHoMnKbTrtkLjlh58aCEtEiF8EghnfsB5ILC1TlOf3xC8vExT tcnVJdKnhp7PHszpaYqomzfNR3E/XY/W8To1DDTzaxcFrdgFAK1S3m6GG c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOQCNU+rRDoG/2dsb2JhbABDoEqPJ4EHgXkICgEXED8NBRhQIxwBBB4Xh2OaMwGecYs2ChMRAgIFAQIIBAE7AQIEBQQbAYNXVwErgx0EjU+aRA X-IronPort-AV: E=Sophos;i="4.73,395,1325462400"; d="scan'208";a="28043665" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 10 Feb 2012 11:44:48 +0000 Received: from dwingWS ([10.21.73.28]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1ABij9L005237; Fri, 10 Feb 2012 11:44:45 GMT From: "Dan Wing" To: Date: Fri, 10 Feb 2012 12:44:40 +0100 Message-ID: <020101cce7e9$644aed50$2ce0c7f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aczn6V4vaGP+KGQ9Qh22eX8wuxs3Og== Content-Language: en-us Cc: draft-ietf-pcp-base@tools.ietf.org Subject: [pcp] pcp-base-23 posted X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 11:44:49 -0000 Version -23 was just posted. This includes feedback from Jari's AD review, Masataka Ohta, and tightening up some text suggested by co-authors. Please review the changes. Changes are summarized in Section B and copied below. Side-by-side differences between -22 and -23 are available at http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcp-base-23.txt -d B.1. Changes from draft-ietf-pcp-base-22 to -23 o Instead of returning error NO_RESOURCES when requesting a MAP for all protocols or for all ports, return UNSUPP_PROTOCOL. o Clarify that PEER-created mappings are treated as if it was implicit dynamic outbound mapping (Section 11.3). o Point out that PEER-created mappings may be very short until bi- directional traffic is seen by the PCP-managed device. o Clairification that an existing implicit mapping (created e.g., by TCP SYN) can become managed by a MAP request (Section 10.3. o Clarified the ANNOUNCE Opcode is being defined in Section 13.1, and that the length of requests (as well as responses) is zero. o Clarify that ANNOUNCE has Lifetime=0 for requests and responses. o Clarify ANNOUNCE can be sent unicast by the client (to solicit a response), or can be multicasted (unsolicited) by the server. o Allow ANNOUNCE to be sent unicast by the server, to accomodate case where PCP server fails but knows the IP address of a PCP client (e.g., web portal). o Clarified ports used for unicast and multicast unsolicited ANNOUNCE. o Tweaked NO_RESOURCES handling, to just disallow *new* mappings. o State diagram is now non-normative, because it overly simplifies that implicit mappings become MAP (when they actually still retain their previous behavior when the MAP expires). o In section Section 10.5, clarified that PEER cannot delete or shorten any lifetime, and that MAP can only shorten or delete lifetimes of MAP-created mappings. o Clarified handling of MAP when mapping already exists (4 steps). o 2^32-1 o Randomize retry interval (1.5-2.5), and maximum retry interval is now 1024 seconds (was 15 minutes). o Remove MUST be 0 for Reserved field when sending error responses for un-parseable message. o Whenever PCP client includes Suggested IP Address (in MAP or PEER), the PCP server should try to fulfill that request, even if creating a mapping on that IP address means the internal host will have mappings on different IP addresses and ports. o For NO_RESOURCES error, the PCP client can attempt to renew and attempt to delete mappings (as they can help shed load) -- it just can't try to create new ones. o Removed the overly simplistic normative text regarding honoring Suggested External Address from Section 9 in favor of the text in Section 10.3 which has significantly more detail. From mohta@necom830.hpcl.titech.ac.jp Sat Feb 11 01:25:17 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA7E21F8537 for ; Sat, 11 Feb 2012 01:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cg7iPtyK+0z3 for ; Sat, 11 Feb 2012 01:25:17 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id E248121F84D4 for ; Sat, 11 Feb 2012 01:25:16 -0800 (PST) Received: (qmail 10639 invoked from network); 11 Feb 2012 09:38:58 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 11 Feb 2012 09:38:58 -0000 Message-ID: <4F3633DE.7080505@necom830.hpcl.titech.ac.jp> Date: Sat, 11 Feb 2012 18:24:46 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Dan Wing References: <044401ccd66e$77265810$65730830$@com> <4F2F057B.3050100@necom830.hpcl.titech.ac.jp> <227d01cce70a$42925fc0$c7b71f40$@com> In-Reply-To: <227d01cce70a$42925fc0$c7b71f40$@com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base-22 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 09:25:18 -0000 Dan Wing wrote: >> 2) The draft seemingly assumes, like UPnP, a private network >> is a single subnet. A client use PCP, only when an address of >> its peer is located outside of the private network (some >> peer may not have outside address). But, there is no >> information of multiple prefixes which constitute the >> private network consisting from multiple subnets, which >> means the client must assume local subnet is the single >> prefix private network. > > The draft assumes there is a default route to the Internet, > which is where outbound packets (towards the Internet) will > be sent (e.g., TCP SYN). That is the path "to the Internet", > and PCP communications go to that same first hop towards > the Internet. This is different from UPnP, which uses > an advertisement method -- which can cause a UPnP IGD to > be installed on a network which is not on the path to the > Internet. You don't understand what the problem is. Try to implement a ftp client program using PORT command and PCP. Can you understand that client do not use PCP if a server is within some subnet of a private network? How can the client program know where the server is? >> 4) PCP over UDP over IPv4 MUST use UDP checksum. IPv6 UDP of >> RFC2460 should also be referred. > > For IPv4, if a host's UDP checksumming is disabled system-wide, That's a violation of Internet Standard of RFC1122: 4.1.3.4 UDP Checksums A host MUST implement the facility to generate and validate UDP checksums. An application MAY optionally be able to control whether a UDP checksum will be generated, but it MUST default to checksumming on. > For IPv6, all UDP packets have to be checksummed. I don't > see a need to restate that in this document. You shouldn't. Instead, you must give a reference to something not stated in RFC768. >> 6) More seriously on exponential back-off, in case there are >> a lot of clients simultaneously sending requests, the initial >> request SHOULD (not "MUST", because there are cases we can >> expect clients not synchronized or 1 second is lengthy) be >> delayed randomly between 0 to 1 seconds and subsequent waiting >> MUST also be random, which SHOULD be between [1, 2], [2, 4], >> [4, 8], ... and [512, 1024] seconds. > > Ok, I went with: You miss randomization before sending initial request. > a random value between 2 and 3 seconds. > a random value between 1.5 and 2.5 of the previous transmission > interval. > a maximum retransmission interval between 512 and 1024 seconds I'm afraid I can't understand how you calculated the seemingly inconsistent value pairs of [2, 3], [1.5, 2.5] and [512, 1024]. > at which point the retransmission continue at that interval Random interval should be recalculated on each retransmission, shouldn't it? >> 7) In 6.2, it should be mentioned client must start >> decreasing lifetime not when a response packet is received >> but when a request packet corresponding to the response >> packet was sent. > > Not sure how that would work. The client can request whatever > time it wants (e.g., 20 seconds, 720 hours), but the server is > what decides the actual lifetime -- which can be minimized > against a value such as 60 seconds or maximized against a value > such as 24 hours. Values in requests are irrelevant. If a response with lifetime of 60 seconds is received 5 seconds after a request, a client must interpret that 55 seconds of lifetime is left. After a server decided a lifetime of 5 seconds, it may take 5 seconds for the server transmit response, or for network relay the response. If a response with lifetime of 60 seconds is received 65 seconds after a request, a client must interpret that all the lifetime has already expired. See below for another example. >> We may send requests at times 0, 2, 6, 14 and receive a >> response at time 25, which may be a response to the >> request at time 0. Then, because of 7), 25 seconds of >> lifetime has already passed. > The PCP working group had a long discussion regarding the > need for sequence numbers / transaction numbers, and decided > they were unnecessary. The problem is commonly solved in many UDP applications and is not something need so much discussion. See so simple examples above. Masataka Ohta PS I recommend people here develop some simple (without being pedantic) specification of some simple client (ftp client using PORT command, for example), using PCP and test it in various common use cases (such as static UPnP port forwarding), before making PCP a PS. PPS I think version numbers of PCP not useful. Details will be mailed later. From iesg-secretary@ietf.org Mon Feb 13 06:42:09 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1710C21F8573; Mon, 13 Feb 2012 06:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cRtZk2zooqA; Mon, 13 Feb 2012 06:42:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B1F21F84D6; Mon, 13 Feb 2012 06:42:08 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120213144208.21185.46414.idtracker@ietfa.amsl.com> Date: Mon, 13 Feb 2012 06:42:08 -0800 Cc: pcp@ietf.org Subject: [pcp] Last Call: (Port Control Protocol (PCP)) to Proposed Standard X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 14:42:09 -0000 The IESG has received a request from the Port Control Protocol WG (pcp) to consider the following document: - 'Port Control Protocol (PCP)' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a network address translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pcp-base/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pcp-base/ No IPR declarations have been submitted directly on this I-D. From dwing@cisco.com Mon Feb 13 09:58:43 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71A321F8622 for ; Mon, 13 Feb 2012 09:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.553 X-Spam-Level: X-Spam-Status: No, score=-108.553 tagged_above=-999 required=5 tests=[AWL=2.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fG9P82FjBlJ for ; Mon, 13 Feb 2012 09:58:41 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9D18B21F84D7 for ; Mon, 13 Feb 2012 09:58:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=9769; q=dns/txt; s=iport; t=1329155921; x=1330365521; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=zkqAa7Q4kW0qYNUzgZLRep7Dnmu+ROKJxaQwFkqBdO0=; b=Vc0sad7fbl16idaZPAhYUcXCyXYKas+zplLPjX4j/UMq7Is0X/LQtP4a 9zzr5NJo2Cn9DjQBlS2CQMx0M9FnzDXK+RDb3Tt3UA1qDYCZLnNJWwzSO nM0H0T/e23ObkUq0bM2j9TAsHeqvu1m+SAipy1kvvNu0msgk9yS8FJ0LK A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAJBOOU+rRDoJ/2dsb2JhbABDDqBljyGBB4FyAQEBAgEBCAoBFxA/BQcBAwIJDgECBAEBAScHGSMKAwEFCAEBBBMJAheHWgmdLgGWc4s/AQQEBgcGBgcIAgICAQEDAQEBAwEBBwE1CQQFBBsBg1ddBoM9BIhKhQaaD1g X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208";a="30102438" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 13 Feb 2012 17:58:41 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1DHwf0P002598; Mon, 13 Feb 2012 17:58:41 GMT From: "Dan Wing" To: "'Masataka Ohta'" References: <044401ccd66e$77265810$65730830$@com> <4F2F057B.3050100@necom830.hpcl.titech.ac.jp> <227d01cce70a$42925fc0$c7b71f40$@com> <4F3633DE.7080505@necom830.hpcl.titech.ac.jp> In-Reply-To: <4F3633DE.7080505@necom830.hpcl.titech.ac.jp> Date: Mon, 13 Feb 2012 09:58:41 -0800 Message-ID: <082c01ccea79$1eb48070$5c1d8150$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aczonwd9p9uOVoKKTyqhzBhTnsOrrwBzR8Mg Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base-22 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 17:58:44 -0000 > -----Original Message----- > From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] > Sent: Saturday, February 11, 2012 1:25 AM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] draft-ietf-pcp-base-22 > > Dan Wing wrote: > > >> 2) The draft seemingly assumes, like UPnP, a private network > >> is a single subnet. A client use PCP, only when an address of > >> its peer is located outside of the private network (some > >> peer may not have outside address). But, there is no > >> information of multiple prefixes which constitute the > >> private network consisting from multiple subnets, which > >> means the client must assume local subnet is the single > >> prefix private network. > > > > The draft assumes there is a default route to the Internet, > > which is where outbound packets (towards the Internet) will > > be sent (e.g., TCP SYN). That is the path "to the Internet", > > and PCP communications go to that same first hop towards > > the Internet. This is different from UPnP, which uses > > an advertisement method -- which can cause a UPnP IGD to > > be installed on a network which is not on the path to the > > Internet. > > You don't understand what the problem is. > > Try to implement a ftp client program using PORT command and > PCP. > > Can you understand that client do not use PCP if a server is > within some subnet of a private network? Yes, I understand the problem you are describing. > How can the client program know where the server is? It can't. Protocols more modern than FTP, such as SIP, DNS, RSTP 2.0 and others, allow acquiring exchange multiple IP addresses which can be tried sequentially or tried (nearly) in parallel (e.g., ICE (RFC5245), draft-ietf-v6ops-happy-eyeballs). But to your question about FTP with the PORT command, it would work fine, although the FTP data traffic would hairpin through the NAPT device: {Internet} | 192.0.2.1 IPv4 NAPT with PCP server | +----------+--------+ | | FTP client FTP server 192.168.1.1 192.168.1.2 1. FTP client connects to FTP server and logs in 2. FTP client listens on a TCP port 3. FTP client issues PCP "MAP" Opcode to its default router (in this case, its IPv4 NAPT), asking for a mapping to its listenting TCP port. The MAP response indicates the WAN address and TCP port of the NAPT, 192.0.2.1/12345 4. FTP client sends the command "PORT 192,0,2,1,48,57" to the FTP server, which was the IP address and port returned in step 3. 5. FTP client issues the LIST command 6. FTP server connects to 192.0.2.1/12345 and starts sending the directory listing. Yes, I agree the traffic path is not optimal (it goes through the NAT when it could have gone directly between the FTP client and FTP server). If the FTP client wanted an optimal path, it could use FTP passive-mode, or it could use a protocol that allows signaling multiple IP addresses. > >> 4) PCP over UDP over IPv4 MUST use UDP checksum. IPv6 UDP of > >> RFC2460 should also be referred. > > > > For IPv4, if a host's UDP checksumming is disabled system-wide, > > That's a violation of Internet Standard of RFC1122: > > 4.1.3.4 UDP Checksums > > A host MUST implement the facility to generate and validate > UDP checksums. An application MAY optionally be able to > control whether a UDP checksum will be generated, but it > MUST default to checksumming on. > > > For IPv6, all UDP packets have to be checksummed. I don't > > see a need to restate that in this document. > > You shouldn't. Instead, you must give a reference to something > not stated in RFC768. > > >> 6) More seriously on exponential back-off, in case there are > >> a lot of clients simultaneously sending requests, the initial > >> request SHOULD (not "MUST", because there are cases we can > >> expect clients not synchronized or 1 second is lengthy) be > >> delayed randomly between 0 to 1 seconds and subsequent waiting > >> MUST also be random, which SHOULD be between [1, 2], [2, 4], > >> [4, 8], ... and [512, 1024] seconds. > > > > Ok, I went with: > > You miss randomization before sending initial request. We would not want to delay the initial request. DHCP does the same sort of thing (initial message is sent when client wants to send it, retransmissions are slightly randomized). > > a random value between 2 and 3 seconds. > > > a random value between 1.5 and 2.5 of the previous transmission > > interval. > > > a maximum retransmission interval between 512 and 1024 seconds > > I'm afraid I can't understand how you calculated the seemingly > inconsistent value pairs of [2, 3], [1.5, 2.5] and [512, 1024]. > > > at which point the retransmission continue at that interval > > Random interval should be recalculated on each retransmission, > shouldn't it? Do you have text to suggest, perhaps from an existing RFC? I can lift the text straight from http://tools.ietf.org/html/rfc2131#page-24 unless you have some better source to suggest. > >> 7) In 6.2, it should be mentioned client must start > >> decreasing lifetime not when a response packet is received > >> but when a request packet corresponding to the response > >> packet was sent. > > > > Not sure how that would work. The client can request whatever > > time it wants (e.g., 20 seconds, 720 hours), but the server is > > what decides the actual lifetime -- which can be minimized > > against a value such as 60 seconds or maximized against a value > > such as 24 hours. > > Values in requests are irrelevant. > > If a response with lifetime of 60 seconds is received 5 > seconds after a request, a client must interpret that > 55 seconds of lifetime is left. > > > After a server decided a lifetime of 5 seconds, it may > take 5 seconds for the server transmit response, or > for network relay the response. > > If a response with lifetime of 60 seconds is received > 65 seconds after a request, a client must interpret that > all the lifetime has already expired. Thanks for the explanation. Added To accommodate network latency, PCP server processing latency, packet loss, and PCP client retransmissions, the PCP client MUST start decrementing its internally-maintained lifetime value when it sends its first request for a specific mapping. Once a PCP server has responded positively to a MAP request for a certain lifetime, the port mapping is active for the duration of the lifetime indicated in the response, minues the time between the PCP client's first request for that specific mapping and the reception of the positive response. > See below for another example. > > >> We may send requests at times 0, 2, 6, 14 and receive a > >> response at time 25, which may be a response to the > >> request at time 0. Then, because of 7), 25 seconds of > >> lifetime has already passed. > > > The PCP working group had a long discussion regarding the > > need for sequence numbers / transaction numbers, and decided > > they were unnecessary. > > The problem is commonly solved in many UDP applications and > is not something need so much discussion. The internal IP address (now always 128 bits) and port (16 bits) form a transaction ID. The same problems you outlined above would exist for retransmissions if the transaction ID were to stay the same for retransmissions -- which is also pretty typical of UDP applications. Minutes from the decision: http://www.ietf.org/proceedings/79/slides/pcp-4.pdf, slide 3 http://www.ietf.org/proceedings/79/minutes/pcp.txt ... 2. Transaction ID We already have a 48-bit transaction ID (internal addr + port) Proposed to reject Francis: argument is wrong in the case of DS-lite Stuart: What would ICE do? Outbound TCP SYN somehow manages to make a port mapping without a transaction ID Margaret: There's no answer to an outbound SYN haven't talked about flow control, flood restart until we talk about that, don't know if we need transaction ID Stuart: Simplicity in reporting a port mapping exists, without regard to how a mapping was created ... > See so simple examples above. > > Masataka Ohta > > PS > > I recommend people here develop some simple (without > being pedantic) specification of some simple client > (ftp client using PORT command, for example), using > PCP and test it in various common use cases (such as > static UPnP port forwarding), before making PCP a PS. PCP's semantics are very similar to NAT-PMP (draft-cheshire-nat-pmp) which has been deployed by Apple for several years and available on both OSX and in Windows after installing iTunes. Several applications, including uTorrent and dozens of others, use NAT-PMP today. There was a PCP demonstration and interop test at IETF81. > PPS > > I think version numbers of PCP not useful. Details > will be mailed later. The version number is currently used to disambiguate NAT-PMP from PCP, which can utilize the same port. NAT-PMP was never an IETF protocol, but did have an IANA-assigned port which we hope to reclaim for PCP. The version handling works (code was written to prove it works), and is valuable. Running the two protocols on the same port helps avoid unnecessary timeouts to discover which protocols are supported on a network. -d From mohta@necom830.hpcl.titech.ac.jp Mon Feb 13 16:37:18 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF0721E8047 for ; Mon, 13 Feb 2012 16:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.071 X-Spam-Level: X-Spam-Status: No, score=-0.071 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPrxS8IYNhRb for ; Mon, 13 Feb 2012 16:37:17 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 4C41821E8044 for ; Mon, 13 Feb 2012 16:37:17 -0800 (PST) Received: (qmail 41667 invoked from network); 14 Feb 2012 00:51:54 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 14 Feb 2012 00:51:54 -0000 Message-ID: <4F39ACA9.7070609@necom830.hpcl.titech.ac.jp> Date: Tue, 14 Feb 2012 09:36:57 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Dan Wing References: <044401ccd66e$77265810$65730830$@com> <4F2F057B.3050100@necom830.hpcl.titech.ac.jp> <227d01cce70a$42925fc0$c7b71f40$@com> <4F3633DE.7080505@necom830.hpcl.titech.ac.jp> <082c01ccea79$1eb48070$5c1d8150$@com> In-Reply-To: <082c01ccea79$1eb48070$5c1d8150$@com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base-22 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 00:37:18 -0000 Dan Wing wrote: >> Can you understand that client do not use PCP if a server is >> within some subnet of a private network? > Yes, I understand the problem you are describing. Not very well. Complicated solutions sometimes work. Though it is not easy to find cases they don't work, it does not mean they always work. > But to your question about FTP with the PORT command, it would > work fine, although the FTP data traffic would hairpin through > the NAPT device: > > {Internet} > | > 192.0.2.1 > IPv4 NAPT with PCP server > | > +----------+--------+ > | | > FTP client FTP server > 192.168.1.1 192.168.1.2 > > 1. FTP client connects to FTP server and logs in > 2. FTP client listens on a TCP port > 3. FTP client issues PCP "MAP" Opcode to its default router (in > this case, its IPv4 NAPT), asking for a mapping to its listenting > TCP port. The MAP response indicates the WAN address and > TCP port of the NAPT, 192.0.2.1/12345 Though it does not work with typical UPnP capable NAT with static port forwarding and dynamic outgoing port mapping, let's not discuss here (see discussions on version later). > 4. FTP client sends the command "PORT 192,0,2,1,48,57" to the FTP > server, which was the IP address and port returned in step 3. Then, it is quite likely that the ftp server in the private network denies the request including addresses outside of the private network. The ftp server may not have any route other than private ones. There are reasons, such as security, why the ftp server is located within the private network. That local ftp clients can fetch contents of the ftp server and somehow relay them globally does not loosen security policy of the ftp server. Don't try to solve a simple problem in complicated ways only to make the problem unsolvable in some simple cases. > If the FTP client wanted an optimal path, it could > use FTP passive-mode, or it could use a protocol that allows > signaling multiple IP addresses. I appreciate incredible pedantism here only to make the originally simple problem even more unsolvable. >>> For IPv4, if a host's UDP checksumming is disabled system-wide, >> >> That's a violation of Internet Standard of RFC1122: Have you fixed it? >> You miss randomization before sending initial request. > > We would not want to delay the initial request. DHCP does > the same sort of thing (initial message is sent when client > wants to send it, retransmissions are slightly randomized). DHCPv6 does randomize: The first Solicit message from the client on the interface MUST be delayed by a random amount of time between 0 and SOL_MAX_DELAY. The problem of DHCPv6 is that it is not "SHOULD" but "MUST". E.g., initial randomization of PCP initiated by DHCPv6 is a waste of time. > Do you have text to suggest, perhaps from an existing RFC? I can > lift the text straight from > http://tools.ietf.org/html/rfc2131#page-24 unless you have > some better source to suggest. Page 27 of RFC3315 might be helpful. >> The problem is commonly solved in many UDP applications and >> is not something need so much discussion. > > The internal IP address (now always 128 bits) and port (16 bits) > form a transaction ID. No, not at all. It merely identifies a (half) connection. Multiple transactions on a connection must be identified with additional information. > The same problems you outlined above > would exist for retransmissions if the transaction ID were > to stay the same for retransmissions -- which is also pretty > typical of UDP applications. OK, to be a little pedantic, a single transaction may use retransmissions, in which case, the same transaction ID must be used by all the retransmissions. However, if another transaction, which may be of the same type as the original, is performed, new transaction ID must be used. Each request of PCP is independent transaction because of lifetime problem of 7). > Minutes from the decision: > http://www.ietf.org/proceedings/79/slides/pcp-4.pdf, slide 3 > http://www.ietf.org/proceedings/79/minutes/pcp.txt The decision does not affect the reality of transactions. >> I recommend people here develop some simple (without >> being pedantic) specification of some simple client >> (ftp client using PORT command, for example), using >> PCP and test it in various common use cases (such as >> static UPnP port forwarding), before making PCP a PS. > > PCP's semantics are very similar to NAT-PMP > (draft-cheshire-nat-pmp) which has been deployed by Apple > for several years and available on both OSX and in Windows > after installing iTunes. Several applications, including > uTorrent and dozens of others, use NAT-PMP today. > > There was a PCP demonstration and interop test at IETF81. It means that you need someone else, not me, having some experience with yet another perspective. >> I think version numbers of PCP not useful. Details >> will be mailed later. > > The version number is currently used to disambiguate > NAT-PMP from PCP, which can utilize the same port. NAT-PMP > was never an IETF protocol, but did have an IANA-assigned > port which we hope to reclaim for PCP. The version handling > works (code was written to prove it works), and is valuable. > Running the two protocols on the same port helps avoid > unnecessary timeouts to discover which protocols are > supported on a network. As servers of the same version behaves very differently, the version number does not help clients guess servers' capability. Client must check whether some opcode and/or option work on its servers anyway (as is exemplified with ftp case), which means version number negotiation is a waste of time. New opcode and/or options are enough, which is what DHCP, extended from BOOTP, is doing with options. Masataka Ohta From dwing@cisco.com Wed Feb 15 15:35:04 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6083021E8086 for ; Wed, 15 Feb 2012 15:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.026 X-Spam-Level: X-Spam-Status: No, score=-108.026 tagged_above=-999 required=5 tests=[AWL=1.373, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fXoO65ECpIP for ; Wed, 15 Feb 2012 15:34:59 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id D5B9621E801D for ; Wed, 15 Feb 2012 15:34:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=10997; q=dns/txt; s=iport; t=1329348899; x=1330558499; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Jkho8IHavPGSA+nPTpLHN6rogDF0KqajSCUGIH14aXE=; b=Wo3oIV7NHEHNy66E7eJ9FS1R+qphSfh1hhHJDZhF/jEPrCBPnvjaOv9d J52hU2uUUp4lFzxzmchU0zzKUWtncbqUrtlnZUe4O/Uqemg2oqJybmpgF +ECjKetbmHzSkHvzSvs4bdLOwn5WayatE7uX5YVaVmawyU9dPjqHOhuJw A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAAFAPE+rRDoH/2dsb2JhbABCDqEjjzSBB4FyAQEBAgEBCAoBFxA/BQcBAwIJDgECBAEBAScHGSMKCQgBAQQTCQIQB4ddCZsDAZ5Pi1sDAQIBAQEFAgEEAQwFBgQJAQEGAQgIAQIwARcBAQGDPisJAgMDAQkJB4MqBIhNhQeaE1g X-IronPort-AV: E=Sophos;i="4.73,426,1325462400"; d="scan'208";a="30657398" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 15 Feb 2012 23:34:59 +0000 Received: from dwingWS ([10.154.160.194]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1FNYxFa028734; Wed, 15 Feb 2012 23:34:59 GMT From: "Dan Wing" To: "'Masataka Ohta'" References: <044401ccd66e$77265810$65730830$@com> <4F2F057B.3050100@necom830.hpcl.titech.ac.jp> <227d01cce70a$42925fc0$c7b71f40$@com> <4F3633DE.7080505@necom830.hpcl.titech.ac.jp> <082c01ccea79$1eb48070$5c1d8150$@com> <4F39ACA9.7070609@necom830.hpcl.titech.ac.jp> In-Reply-To: <4F39ACA9.7070609@necom830.hpcl.titech.ac.jp> Date: Wed, 15 Feb 2012 15:34:59 -0800 Message-ID: <077a01ccec3a$6e9c5820$4bd50860$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczqsMeNzio2LP89RgCaTOPMqELHQgABOGiA Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base-22 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 23:35:04 -0000 > -----Original Message----- > From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] > Sent: Monday, February 13, 2012 4:37 PM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] draft-ietf-pcp-base-22 > > Dan Wing wrote: > > >> Can you understand that client do not use PCP if a server is > >> within some subnet of a private network? > > > Yes, I understand the problem you are describing. > > Not very well. > > Complicated solutions sometimes work. Though it is not easy to > find cases they don't work, it does not mean they always work. > > > But to your question about FTP with the PORT command, it would > > work fine, although the FTP data traffic would hairpin through > > the NAPT device: > > > > > {Internet} > > | > > 192.0.2.1 > > IPv4 NAPT with PCP server > > | > > +----------+--------+ > > | | > > FTP client FTP server > > 192.168.1.1 192.168.1.2 > > > > 1. FTP client connects to FTP server and logs in > > 2. FTP client listens on a TCP port > > 3. FTP client issues PCP "MAP" Opcode to its default router (in > > this case, its IPv4 NAPT), asking for a mapping to its listenting > > TCP port. The MAP response indicates the WAN address and > > TCP port of the NAPT, 192.0.2.1/12345 > > Though it does not work with typical UPnP capable NAT with > static port forwarding and dynamic outgoing port mapping, > let's not discuss here (see discussions on version later). > > > 4. FTP client sends the command "PORT 192,0,2,1,48,57" to the FTP > > server, which was the IP address and port returned in step 3. > > Then, it is quite likely that the ftp server in the private > network denies the request including addresses outside of the > private network. The ftp server may not have any route other > than private ones. > > There are reasons, such as security, why the ftp server is > located within the private network. That local ftp clients > can fetch contents of the ftp server and somehow relay them > globally does not loosen security policy of the ftp server. > > Don't try to solve a simple problem in complicated ways > only to make the problem unsolvable in some simple cases. > > > If the FTP client wanted an optimal path, it could > > use FTP passive-mode, or it could use a protocol that allows > > signaling multiple IP addresses. > > I appreciate incredible pedantism here only to make the > originally simple problem even more unsolvable. What do you suggest be done. > >>> For IPv4, if a host's UDP checksumming is disabled system-wide, > >> > >> That's a violation of Internet Standard of RFC1122: > > Have you fixed it? No, the document is still silent on UDP checksum. > >> You miss randomization before sending initial request. > > > > We would not want to delay the initial request. DHCP does > > the same sort of thing (initial message is sent when client > > wants to send it, retransmissions are slightly randomized). > > DHCPv6 does randomize: > > The first Solicit message from the client on the interface MUST be > delayed by a random amount of time between 0 and SOL_MAX_DELAY. Sure, but DHCPv4 does not randomize. > The problem of DHCPv6 is that it is not "SHOULD" but "MUST". > E.g., initial randomization of PCP initiated by DHCPv6 is > a waste of time. > > > Do you have text to suggest, perhaps from an existing RFC? I can > > lift the text straight from > > http://tools.ietf.org/html/rfc2131#page-24 unless you have > > some better source to suggest. > > Page 27 of RFC3315 might be helpful. Thanks. I removed the old retransmission text and now have this: 7.1.1. PCP Client Retransmission PCP clients are responsible for reliable delivery of PCP request messages. If a PCP client fails to receive an expected response from a server, the client must retransmit its message. The client begins the message exchange by transmitting a message to the server. The message exchange terminates when either the client successfully receives the appropriate response or responses from the server, or when the message exchange is considered to have failed according to the retransmission mechanism described below. The client retransmission behavior is controlled and described by the following variables: RT Retransmission timeout, calculated as described below IRT Initial retransmission time, SHOULD be 2 seconds MRC Maximum retransmission count, SHOULD be 0 (0 indicates no maximum) MRT Maximum retransmission time, SHOULD be 1024 seconds MRD Maximum retransmission duration, SHOULD be 0 (0 indicates no maximum) RAND Randomization factor, calculated as described below With each message transmission or retransmission, the client sets RT according to the rules given below. If RT expires before a response is received, the client recomputes RT and retransmits the request. Each of the computations of a new RT include a new randomization factor (RAND), which is a random number chosen with a uniform distribution between -0.1 and +0.1. The randomization factor is included to minimize synchronization of messages transmitted by PCP clients. The algorithm for choosing a random number does not need to be cryptographically sound. The algorithm SHOULD produce a different sequence of random numbers from each invocation of the PCP client. The RT value is initialized based on IRT: RT = IRT + RAND*IRT RT for each subsequent message transmission is based on the previous value of RT: RT = 2*RTprev + RAND*RTprev MRT specifies an upper bound on the value of RT (disregarding the randomization added by the use of RAND). If MRT has a value of 0, there is no upper limit on the value of RT. Otherwise: if (RT > MRT) RT = MRT + RAND*MRT MRC specifies an upper bound on the number of times a client may retransmit a message. Unless MRC is zero, the message exchange fails once the client has transmitted the message MRC times. MRD specifies an upper bound on the length of time a client may retransmit a message. Unless MRD is zero, the message exchange fails once MRD seconds have elapsed since the client first transmitted the message. If both MRC and MRD are non-zero, the message exchange fails whenever either of the conditions specified in the previous two paragraphs are met. If both MRC and MRD are zero, the client continues to transmit the message until it receives a response. Once a PCP client has successfully received a response from a PCP server on that interface, it resets RT to its initial value and sends subsequent PCP requests to that same server. > >> The problem is commonly solved in many UDP applications and > >> is not something need so much discussion. > > > > The internal IP address (now always 128 bits) and port (16 bits) > > form a transaction ID. > > No, not at all. It merely identifies a (half) connection. > > Multiple transactions on a connection must be identified > with additional information. > > > The same problems you outlined above > > would exist for retransmissions if the transaction ID were > > to stay the same for retransmissions -- which is also pretty > > typical of UDP applications. > > OK, to be a little pedantic, a single transaction may > use retransmissions, in which case, the same transaction > ID must be used by all the retransmissions. > > However, if another transaction, which may be of the > same type as the original, is performed, new transaction > ID must be used. Yes, the protocol can support multiple transactions in flight of the same type -- that is, there can be multiple requests for a mapping to different ports on the network at the same time. There can be a request for an IPv6 mapping and an IPv4 mapping to the same port at the same time, as well. All that works. There is sufficient information in the request and response packets to differentiate those requests and responses, and the document describes how the packets are matched. > Each request of PCP is independent transaction because > of lifetime problem of 7). > > > Minutes from the decision: > > http://www.ietf.org/proceedings/79/slides/pcp-4.pdf, slide 3 > > http://www.ietf.org/proceedings/79/minutes/pcp.txt > > The decision does not affect the reality of transactions. > > >> I recommend people here develop some simple (without > >> being pedantic) specification of some simple client > >> (ftp client using PORT command, for example), using > >> PCP and test it in various common use cases (such as > >> static UPnP port forwarding), before making PCP a PS. > > > > PCP's semantics are very similar to NAT-PMP > > (draft-cheshire-nat-pmp) which has been deployed by Apple > > for several years and available on both OSX and in Windows > > after installing iTunes. Several applications, including > > uTorrent and dozens of others, use NAT-PMP today. > > > > There was a PCP demonstration and interop test at IETF81. > > It means that you need someone else, not me, having > some experience with yet another perspective. > > >> I think version numbers of PCP not useful. Details > >> will be mailed later. > > > > The version number is currently used to disambiguate > > NAT-PMP from PCP, which can utilize the same port. NAT-PMP > > was never an IETF protocol, but did have an IANA-assigned > > port which we hope to reclaim for PCP. The version handling > > works (code was written to prove it works), and is valuable. > > Running the two protocols on the same port helps avoid > > unnecessary timeouts to discover which protocols are > > supported on a network. > > As servers of the same version behaves very differently, > the version number does not help clients guess servers' > capability. > > Client must check whether some opcode and/or option work > on its servers anyway (as is exemplified with ftp case), > which means version number negotiation is a waste of time. > > New opcode and/or options are enough, which is what DHCP, > extended from BOOTP, is doing with options. The version negotiation was used once already (NAT-PMP to PCP), and the existence of the version number allowed changing the packet layout between those versions. In the future, other engineers may well find a need for PCPv2 (or whatever they call it) with yet a different packet layout, which can leverage the version number. The document is currently in IETF last call so I am deferring publishing an update until after IETF last call. -d From dxhbupt@gmail.com Mon Feb 20 00:05:42 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881D521F86BA for ; Mon, 20 Feb 2012 00:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pr1rVw+WEV12 for ; Mon, 20 Feb 2012 00:05:41 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0621E21F86BB for ; Mon, 20 Feb 2012 00:05:39 -0800 (PST) Received: by wibhm9 with SMTP id hm9so3447539wib.31 for ; Mon, 20 Feb 2012 00:05:39 -0800 (PST) Received-SPF: pass (google.com: domain of dxhbupt@gmail.com designates 10.216.134.37 as permitted sender) client-ip=10.216.134.37; Authentication-Results: mr.google.com; spf=pass (google.com: domain of dxhbupt@gmail.com designates 10.216.134.37 as permitted sender) smtp.mail=dxhbupt@gmail.com; dkim=pass header.i=dxhbupt@gmail.com Received: from mr.google.com ([10.216.134.37]) by 10.216.134.37 with SMTP id r37mr3777809wei.38.1329725139246 (num_hops = 1); Mon, 20 Feb 2012 00:05:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=PWC6rg9pMvIRVSEeGo0f5vSRm5Zgz6oC4Pkjw4xX6qA=; b=HN2RBOrqk/QRXBHnKL3RlVznlaAEnxbWZ0xFyRbtQWcE3aHjR8kKV/s4I3D4NOBi0f h0OmU5bq+FoJpScXTQqasrUJiJJC6qPCUUD/m58ezFpIAS/xITw28P97eEGnpg3NzrAa SKLkRpJJqV+MFMlU7VmmqpWwlpzpr5W2G5yZY= MIME-Version: 1.0 Received: by 10.216.134.37 with SMTP id r37mr3129899wei.38.1329725139195; Mon, 20 Feb 2012 00:05:39 -0800 (PST) Received: by 10.180.98.103 with HTTP; Mon, 20 Feb 2012 00:05:39 -0800 (PST) Date: Mon, 20 Feb 2012 16:05:39 +0800 Message-ID: From: Xiaohong Deng To: pcp@ietf.org, dwing@cisco.com Content-Type: multipart/alternative; boundary=0016e6d7e97892181d04b960c2cb Subject: [pcp] Do it differently when PCP response would have exceeded the maximum PCP message size? X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 08:05:42 -0000 --0016e6d7e97892181d04b960c2cb Content-Type: text/plain; charset=ISO-8859-1 In the -23, it suggests in page 17 that: If a PCP response would have exceeded the maximum PCP message size, the PCP server SHOULD respond with MALFORMED_REQUEST. While MALFORMED_REQUEST means the request could not be successfully parsed, yet the scenario that text here is trying to describe (explained by Dan): 1. a request arrives, and has two fancy new PCP Options, one says "tell me the human-assigned name for this mapping", and the other says "tell me the manufacturer and version of the PCP server" 2. the human-assigned name is 1000 bytes, and the manufacturer name is 50 bytes. 3. the response is built but its length exceeds the 1024 maximum size allowed. How about do something differently than MALFORMED_REQUEST? For example, define a new error code for the sake of accuracy or simply truncate the response at 1024 bytes to fit? Cheers, Xiaohong --0016e6d7e97892181d04b960c2cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

In the -23, it suggests in page 17 that:


If a PCP response would have exceeded the maximum PCP message size,

the PCP server SHOULD respond with MALFORMED_REQUEST.


While MALFORMED_REQUEST means the request could not be successfully parsed, yet the scenario that t= ext here is trying to describe (explained by Dan):

=

1. a request arrives, and has two fancy new PCP Options, one says "tell me =

=A0=A0 the human-assigned name for this mapping", and the other says "tell

=A0=A0 me the manufacturer and version of the PCP server"

2. the human-assigned name is 1000 bytes, and the manufacturer name is

=A0=A0 50 bytes.

3. the response is built but its length exceeds the 1024 maximum

=A0=A0 size allowed.

=

How about do something differently than MALFORMED_REQUEST? For example, define a new err= or code for the sake of accuracy or simply truncate the

response at 1024 bytes to fit?



Cheers,

Xiaohong

--0016e6d7e97892181d04b960c2cb-- From jhw@apple.com Mon Feb 20 16:29:47 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4733A21E802E; Mon, 20 Feb 2012 16:29: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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guBosixztZsV; Mon, 20 Feb 2012 16:29:46 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1813421E8016; Mon, 20 Feb 2012 16:29:46 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_joStrLDg7w+TI2x4CMgxtQ)" Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0LZP009JBW024DX1@mail-out.apple.com>; Mon, 20 Feb 2012 16:29:45 -0800 (PST) X-AuditID: 11807136-b7b1aae0000062d9-80-4f42e578d107 Received: from [17.153.48.205] (Unknown_Domain [17.153.48.205]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 37.A2.25305.975E24F4; Mon, 20 Feb 2012 16:29:45 -0800 (PST) From: james woodyatt In-reply-to: <5B6B2B64C9FE2A489045EEEADDAFF2C3040761AD@XMB-RCD-109.cisco.com> Date: Mon, 20 Feb 2012 16:29:44 -0800 Message-id: References: "29 Jan 2012 09:51:52 PST." <85BE2EBF-C8AC-45E1-BF93-1E3066AD3172@apple.com> <201201301936.q0UJaEft000156@givry.fdupont.fr> <2D09D61DDFA73D4C884805CC7865E611025B49@GAALPA1MSGUSR9N.ITServices.sbc.com> <4A687585-399D-4077-91AC-A1DC4F101E03@apple.com> <2D09D61DDFA73D4C884805CC7865E611025BFE@GAALPA1MSGUSR9N.ITServices.sbc.com> <30931DE1-9E57-4296-B0FE-FA98F840D78F@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3040761AD@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1257) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUiONPgrG7lUyd/g9VbBSwm/f3JaHHz6kUW i8nHfrNa3Pp1jc3i9LG9zA6sHi/75zB6TPm9kdVjyZKfTB5fLn9mC2CJ4rJJSc3JLEst0rdL 4Mo48n0Ja8ETvYofs+cwNTAu0ehi5OSQEDCRuH5sARuELSZx4d56IJuLQ0hgKpNE85l5LCAJ YQFrib3tj1hBbF4BQ4mZr9rBbGaBBImPl96D1bAJqEh8u3yXCcTmFPCVmL+9FyzOIqAqMe/B L2aQocwCPYwS/QdmQw2ykXgw6SQTxLZDzBLX+6cxgiREBPQkHu98wApxkqzE7YP7mSYw8s1C snwWkuUQtrbEsoWvmSFsA4mnna9YMcX1Jd68m8O0gJFtFaNgUWpOYqWhqV5iQUFOql5yfu4m RlBwNxSa7WDc8VfuEKMAB6MSD29iuZO/EGtiWXFl7iFGCQ5mJRHesqVAId6UxMqq1KL8+KLS nNTiQ4zSHCxK4ry8hkApgfTEktTs1NSC1CKYLBMHp1QDY8edm++Pt1lPyU/6zbdk8YxJhddm lO5bpH27uDJLxu/n4g05qzjZ2q5lqfo/YZknlBV+tX7R9MAbc1ew/zmnu29J6w9Th/+ySwR1 3df2S8y+eF9HkKVWpubf6tsKzfzid+aLmJ3bFGiuLlDwim/nh4K+/cJLCgJObVKysOhYs2dC 23GtTRqT9iuxFGckGmoxFxUnAgDNzuKtagIAAA== Cc: IPv6 Operations , PCP , "STARK, BARBARA H" , draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [pcp] [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 00:29:47 -0000 --Boundary_(ID_joStrLDg7w+TI2x4CMgxtQ) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable On Feb 20, 2012, at 14:28 , Hemant Singh (shemant) wrote: > =20 > Sorry for the delay. Along the lines of what Barbara already said, I = would like to add that major host OS=92s such as Microsoft Windows nor = MAC OS (?) support a PCP client yet? At least till a few months back - = vendors can keep me honest. If a host does not support a PCP client, = what host will issue PCP requests to a PCP server in the IPv6 CPE = router? Thus it makes sense to let the homenet WG deal with the PCP = server req on the CPE router LAN and we ship rfc6204bis with the PCP = client req that Alain Durand agreed with for DS-Lite use. Thanks to = Dave Thaler who helped prepare text for the specific PCP client req in = the CPE. In other words, you're telling me there's no point in implementing a PCP = client for IPv6 simple security in a host operating system, because none = of the IPv6 Ready CE routers will have PCP servers. Good to know. -- james woodyatt member of technical staff, core os networking --Boundary_(ID_joStrLDg7w+TI2x4CMgxtQ) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable
On Feb 20, 2012, at 14:28 , Hemant Singh = (shemant) wrote:
Sorry = for the delay.   Along the lines of what Barbara already said, = I would like to add that major host OS=92s  such as Microsoft = Windows nor MAC OS (?) support a PCP client yet?  At least till a = few months back -  vendors can keep me honest.   If a = host does not support a PCP client, what host will issue PCP requests to = a PCP server in the IPv6 CPE router?   Thus it makes sense to = let the homenet WG deal with the PCP server req on the CPE router LAN = and we ship rfc6204bis with the PCP client req that Alain Durand agreed = with for DS-Lite use.  Thanks to Dave Thaler who helped prepare = text for the specific PCP client req in the = CPE.

In other = words, you're telling me there's no point in implementing a PCP client = for IPv6 simple security in a host operating system, because none of the = IPv6 Ready CE routers will have PCP servers.  Good to = know.


--
james woodyatt <jhw@apple.com>
member of technical staff, core os = networking



= --Boundary_(ID_joStrLDg7w+TI2x4CMgxtQ)-- From mohta@necom830.hpcl.titech.ac.jp Thu Feb 23 03:49:59 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F71F21F85E6 for ; Thu, 23 Feb 2012 03:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.043 X-Spam-Level: X-Spam-Status: No, score=-0.043 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSnoDj3xAvrk for ; Thu, 23 Feb 2012 03:49:59 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 8F4F321F85E4 for ; Thu, 23 Feb 2012 03:49:58 -0800 (PST) Received: (qmail 87896 invoked from network); 23 Feb 2012 12:07:28 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 23 Feb 2012 12:07:28 -0000 Message-ID: <4F4627C2.60509@necom830.hpcl.titech.ac.jp> Date: Thu, 23 Feb 2012 20:49:22 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Dan Wing References: <044401ccd66e$77265810$65730830$@com> <4F2F057B.3050100@necom830.hpcl.titech.ac.jp> <227d01cce70a$42925fc0$c7b71f40$@com> <4F3633DE.7080505@necom830.hpcl.titech.ac.jp> <082c01ccea79$1eb48070$5c1d8150$@com> <4F39ACA9.7070609@necom830.hpcl.titech.ac.jp> <077a01ccec3a$6e9c5820$4bd50860$@com> In-Reply-To: <077a01ccec3a$6e9c5820$4bd50860$@com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: pcp@ietf.org Subject: [pcp] GETLOCALNETS (was Re: draft-ietf-pcp-base-22) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 11:49:59 -0000 Dan Wing wrote: >>> If the FTP client wanted an optimal path, it could >>> use FTP passive-mode, or it could use a protocol that allows >>> signaling multiple IP addresses. >> >> I appreciate incredible pedantism here only to make the >> originally simple problem even more unsolvable. > > What do you suggest be done. I suggest to have a standard request LOCALNETS response for which returns local subnets with their netmasks. Reasoning follows. Making programs PCP capable is good to enable better communication between local hosts within private networks and public networks. However, PCP is a new protocol not necessarily deployed by many. To make PCP deployed widely, it must be guaranteed that PCP capable programs do no harm without any configuration efforts. For the guarantee, it is necessary that PCP enhanced programs must communicate *identically* with nodes within local networks. No complicated tricks such as hairpining acceptable here, because their elaboration changes communication patterns a lot. It is not acceptable, either, to require users configure what are local networks. We SHOULD (or MUST?) make PCP deployed by default and SHOULD NOT make PCP deployed only with additional effort of some configuration changes. To do so, it is necessary that the programs can know whether their peers are within their local networks or not. Masataka Ohta From mohta@necom830.hpcl.titech.ac.jp Thu Feb 23 04:20:50 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3726C21F86DF for ; Thu, 23 Feb 2012 04:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.045 X-Spam-Level: X-Spam-Status: No, score=-0.045 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmLK1quokRvx for ; Thu, 23 Feb 2012 04:20:49 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 4AEBD21F86DC for ; Thu, 23 Feb 2012 04:20:49 -0800 (PST) Received: (qmail 88182 invoked from network); 23 Feb 2012 12:38:10 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 23 Feb 2012 12:38:10 -0000 Message-ID: <4F462EF3.2080004@necom830.hpcl.titech.ac.jp> Date: Thu, 23 Feb 2012 21:20:03 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Dan Wing References: <044401ccd66e$77265810$65730830$@com> <4F2F057B.3050100@necom830.hpcl.titech.ac.jp> <227d01cce70a$42925fc0$c7b71f40$@com> <4F3633DE.7080505@necom830.hpcl.titech.ac.jp> <082c01ccea79$1eb48070$5c1d8150$@com> <4F39ACA9.7070609@necom830.hpcl.titech.ac.jp> <077a01ccec3a$6e9c5820$4bd50860$@com> In-Reply-To: <077a01ccec3a$6e9c5820$4bd50860$@com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base-22 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 12:20:50 -0000 Dan Wing wrote: >>>>> For IPv4, if a host's UDP checksumming is disabled system-wide, >>>> >>>> That's a violation of Internet Standard of RFC1122: >> >> Have you fixed it? > > No, the document is still silent on UDP checksum. Why? >>>> You miss randomization before sending initial request. >>> >>> We would not want to delay the initial request. DHCP does >>> the same sort of thing (initial message is sent when client >>> wants to send it, retransmissions are slightly randomized). >> >> DHCPv6 does randomize: >> >> The first Solicit message from the client on the interface MUST be >> delayed by a random amount of time between 0 and SOL_MAX_DELAY. > > Sure, but DHCPv4 does not randomize. RFC2131 says: : 4.4.1 Initialization and allocation of network address : : The client begins in INIT state and forms a DHCPDISCOVER message. : The client SHOULD wait a random time between one and ten seconds to : desynchronize the use of DHCP at startup. >> No, not at all. It merely identifies a (half) connection. >> >> Multiple transactions on a connection must be identified >> with additional information. > Yes, the protocol can support multiple transactions in > flight of the same type -- that is, there can be multiple > requests for a mapping to different ports on the network > at the same time. They are different connections. > There can be a request for an IPv6 > mapping and an IPv4 mapping to the same port at the same > There is sufficient information > in the request and response packets to differentiate those > requests and responses, and the document describes how the > packets are matched.> time, as well. All that works. The problem is that different transactions on a single connection can not be distinguished. You can have a transaction to establish a connection. You, then, can have a transaction to renew the connection, which can be distinguished from the previous transaction because request types are different. However, if you initiate the second renewal of the connection, there must be different transaction ID, which does not present in the current PCP specification, is necessary. Or, you can only guess that a response to the second renewal request could actually be a response to the first renewal request, which means the connection could have been expired its lifetime. You don't recognize the logical consequences of: >> Each request of PCP is independent transaction because >> of lifetime problem of 7). > The version negotiation was used once already (NAT-PMP to > PCP), Not yet, because PCP is not yet PS. Moreover, > and the existence of the version number allowed > changing the packet layout between those versions. as packet layouts of NAT-PMP depends on OPCODEs, new OPCODEs are enough to change packet layouts. Masataka Ohta From dwing@cisco.com Thu Feb 23 07:14:24 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DD321F84E7 for ; Thu, 23 Feb 2012 07:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.711 X-Spam-Level: X-Spam-Status: No, score=-108.711 tagged_above=-999 required=5 tests=[AWL=1.888, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY4SAVH3gv6H for ; Thu, 23 Feb 2012 07:14:23 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3248121F84D9 for ; Thu, 23 Feb 2012 07:14:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3816; q=dns/txt; s=iport; t=1330010063; x=1331219663; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=IR7TMYwGD2aljTdjScmB1oaXxfIA80Lp0Rv22bYbYSU=; b=groRCv5Bljz0SgMmCLzzEW2qfkB8jmfQ/BulrM124UePmdU2xtsH8WwO H/nz95Jbjw468hyAbNkGhnR66U7GG1qU6zU/UXEPjV2i4EkZRdgW2iP5o QVVSt+7upHJF7Ads0gugZnGpm6eSQQw0i9Kt+HC21CMC2MVQ5mCcLC+aD M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFABRXRk+rRDoJ/2dsb2JhbABEDqMBj0GBB4FzAQEBAwEICgEXED8FBwEDAgkOAQIEAQEBJwcZIwoJCAEBBBMLF4dfoBkBlwuMeQ0GCRwBAkMDBAoKAQEBhR9JFYM8BIhPhQeaGFg X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="31864353" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 23 Feb 2012 15:14:23 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1NFEMeP003125; Thu, 23 Feb 2012 15:14:22 GMT From: "Dan Wing" To: "'Masataka Ohta'" References: <044401ccd66e$77265810$65730830$@com> <4F2F057B.3050100@necom830.hpcl.titech.ac.jp> <227d01cce70a$42925fc0$c7b71f40$@com> <4F3633DE.7080505@necom830.hpcl.titech.ac.jp> <082c01ccea79$1eb48070$5c1d8150$@com> <4F39ACA9.7070609@necom830.hpcl.titech.ac.jp> <077a01ccec3a$6e9c5820$4bd50860$@com> <4F462EF3.2080004@necom830.hpcl.titech.ac.jp> In-Reply-To: <4F462EF3.2080004@necom830.hpcl.titech.ac.jp> Date: Thu, 23 Feb 2012 07:14:20 -0800 Message-ID: <081d01ccf23d$d2b47370$781d5a50$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczyJYoBMOdRxIzQTO2cKx/FCiTG5QAF2OTQ Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base-22 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 15:14:24 -0000 > -----Original Message----- > From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] > Sent: Thursday, February 23, 2012 4:20 AM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] draft-ietf-pcp-base-22 > > Dan Wing wrote: > > >>>>> For IPv4, if a host's UDP checksumming is disabled system-wide, > >>>> > >>>> That's a violation of Internet Standard of RFC1122: > >> > >> Have you fixed it? > > > > No, the document is still silent on UDP checksum. > > Why? UDP is a lower layer, covered adequately by other specifications. Much like IP checksum is covered by other specifications. > >>>> You miss randomization before sending initial request. > >>> > >>> We would not want to delay the initial request. DHCP does > >>> the same sort of thing (initial message is sent when client > >>> wants to send it, retransmissions are slightly randomized). > >> > >> DHCPv6 does randomize: > >> > >> The first Solicit message from the client on the interface MUST > be > >> delayed by a random amount of time between 0 and SOL_MAX_DELAY. > > > > Sure, but DHCPv4 does not randomize. > > RFC2131 says: > > : 4.4.1 Initialization and allocation of network address > : > : The client begins in INIT state and forms a DHCPDISCOVER message. > : The client SHOULD wait a random time between one and ten seconds > to > : desynchronize the use of DHCP at startup. I'm not seeing the need for PCP to randomize its initial message. > >> No, not at all. It merely identifies a (half) connection. > >> > >> Multiple transactions on a connection must be identified > >> with additional information. > > > Yes, the protocol can support multiple transactions in > > flight of the same type -- that is, there can be multiple > > requests for a mapping to different ports on the network > > at the same time. > > They are different connections. > > > There can be a request for an IPv6 > > mapping and an IPv4 mapping to the same port at the same > > There is sufficient information > > in the request and response packets to differentiate those > > requests and responses, and the document describes how the > > packets are matched.> time, as well. All that works. > > The problem is that different transactions on a single > connection can not be distinguished. > > You can have a transaction to establish a connection. > > You, then, can have a transaction to renew the connection, > which can be distinguished from the previous transaction > because request types are different. They don't need to be distinguished; there is nothing the PCP client or PCP server can do differently by having them distinguished. > However, if you initiate the second renewal of the connection, > there must be different transaction ID, which does not > present in the current PCP specification, is necessary. > > Or, you can only guess that a response to the second renewal > request could actually be a response to the first renewal > request, which means the connection could have been expired > its lifetime. > > You don't recognize the logical consequences of: > > >> Each request of PCP is independent transaction because > >> of lifetime problem of 7). > > > The version negotiation was used once already (NAT-PMP to > > PCP), > > Not yet, because PCP is not yet PS. I don't follow the argument that because PCP is not yet a proposed standard RFC, it does not need version negotiation. > Moreover, > > > and the existence of the version number allowed > > changing the packet layout between those versions. > > as packet layouts of NAT-PMP depends on OPCODEs, new OPCODEs > are enough to change packet layouts. We are using the version negotiation already. It needs to stay. -d From dwing@cisco.com Thu Feb 23 07:18:43 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B20521F87BA for ; Thu, 23 Feb 2012 07:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.742 X-Spam-Level: X-Spam-Status: No, score=-108.742 tagged_above=-999 required=5 tests=[AWL=1.857, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLpTGdbysuUQ for ; Thu, 23 Feb 2012 07:18:42 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6423C21F87B6 for ; Thu, 23 Feb 2012 07:18:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1905; q=dns/txt; s=iport; t=1330010322; x=1331219922; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=JD52B2uUj4S1u1gadi0KyutD3LjcKq48nDpm4qj6zSQ=; b=EOqxOQBFnLeCBm/7WlYX59S1Vr2h/X3cOpbu3pbg0a+zS/AiqiGG1/+g QXpgX0akNyy95gdGzG5/aasD4fFDghy02BEzLiSXlDCZOH8gSoCrUAPHg qOXA3KdvGkzEv/DsQMs7IY9tsKFqk2QqTwUp7gO/g7MFJN5iCNi55SFWf Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFACRYRk+rRDoH/2dsb2JhbABEDqJ9j0KBB4FzAQEBBAgKARcQPwwBAwIJDgECBAEBAScHGSMKCQgBAQQTCxehfQGec4lRgzMGDwYLBAMBAkMDBAoFAwIBAQGFH0kVgzwEiE+FB5oYWIE7 X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="31998082" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 23 Feb 2012 15:18:42 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1NFIf9T002409; Thu, 23 Feb 2012 15:18:42 GMT From: "Dan Wing" To: "'Masataka Ohta'" References: <044401ccd66e$77265810$65730830$@com> <4F2F057B.3050100@necom830.hpcl.titech.ac.jp> <227d01cce70a$42925fc0$c7b71f40$@com> <4F3633DE.7080505@necom830.hpcl.titech.ac.jp> <082c01ccea79$1eb48070$5c1d8150$@com> <4F39ACA9.7070609@necom830.hpcl.titech.ac.jp> <077a01ccec3a$6e9c5820$4bd50860$@com> <4F4627C2.60509@necom830.hpcl.titech.ac.jp> In-Reply-To: <4F4627C2.60509@necom830.hpcl.titech.ac.jp> Date: Thu, 23 Feb 2012 07:18:39 -0800 Message-ID: <082701ccf23e$6d3b03a0$47b10ae0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczyIUCvo+gTBbVcRdGOVS/st/vpRwAHQ2jw Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] GETLOCALNETS (was Re: draft-ietf-pcp-base-22) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 15:18:43 -0000 > -----Original Message----- > From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] > Sent: Thursday, February 23, 2012 3:49 AM > To: Dan Wing > Cc: pcp@ietf.org > Subject: GETLOCALNETS (was Re: [pcp] draft-ietf-pcp-base-22) > > Dan Wing wrote: > > >>> If the FTP client wanted an optimal path, it could > >>> use FTP passive-mode, or it could use a protocol that allows > >>> signaling multiple IP addresses. > >> > >> I appreciate incredible pedantism here only to make the > >> originally simple problem even more unsolvable. > > > > What do you suggest be done. > > I suggest to have a standard request LOCALNETS response for > which returns local subnets with their netmasks. > > Reasoning follows. > > Making programs PCP capable is good to enable better > communication between local hosts within private networks > and public networks. > > However, PCP is a new protocol not necessarily deployed by many. > > To make PCP deployed widely, it must be guaranteed that PCP capable > programs do no harm without any configuration efforts. > > For the guarantee, it is necessary that PCP enhanced programs > must communicate *identically* with nodes within local networks. > > No complicated tricks such as hairpining acceptable here, because > their elaboration changes communication patterns a lot. > > It is not acceptable, either, to require users configure what > are local networks. > > We SHOULD (or MUST?) make PCP deployed by default and SHOULD > NOT make PCP deployed only with additional effort of some > configuration changes. > > To do so, it is necessary that the programs can know whether > their peers are within their local networks or not. Could you explain in more detail how GETLOCALNETS would work, such as the example you proposed earlier of an FTP client accessing an FTP server on the local network. -d From mohta@necom830.hpcl.titech.ac.jp Thu Feb 23 15:17:48 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1678321F88C5 for ; Thu, 23 Feb 2012 15:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.046 X-Spam-Level: X-Spam-Status: No, score=-0.046 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJVJElIj3q9q for ; Thu, 23 Feb 2012 15:17:47 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id EF0D121F88C3 for ; Thu, 23 Feb 2012 15:17:46 -0800 (PST) Received: (qmail 94417 invoked from network); 23 Feb 2012 23:35:18 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 23 Feb 2012 23:35:18 -0000 Message-ID: <4F46C8C9.4070706@necom830.hpcl.titech.ac.jp> Date: Fri, 24 Feb 2012 08:16:25 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Dan Wing References: <044401ccd66e$77265810$65730830$@com> <4F2F057B.3050100@necom830.hpcl.titech.ac.jp> <227d01cce70a$42925fc0$c7b71f40$@com> <4F3633DE.7080505@necom830.hpcl.titech.ac.jp> <082c01ccea79$1eb48070$5c1d8150$@com> <4F39ACA9.7070609@necom830.hpcl.titech.ac.jp> <077a01ccec3a$6e9c5820$4bd50860$@com> <4F462EF3.2080004@necom830.hpcl.titech.ac.jp> <081d01ccf23d$d2b47370$781d5a50$@com> In-Reply-To: <081d01ccf23d$d2b47370$781d5a50$@com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base-22 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 23:17:48 -0000 Dan Wing wrote: >>> No, the document is still silent on UDP checksum. >> >> Why? > > UDP is a lower layer, covered adequately by other specifications. > Much like IP checksum is covered by other specifications. As is specified in RFC1122, UDP checksuming is controlled by applications: An application MAY optionally be able to control whether a UDP checksum will be generated, but it MUST default to checksumming on. which means it is a part of application specification whether an application turns on it or not. >>> Sure, but DHCPv4 does not randomize. >> >> RFC2131 says: >> >> : 4.4.1 Initialization and allocation of network address >> : >> : The client begins in INIT state and forms a DHCPDISCOVER message. >> : The client SHOULD wait a random time between one and ten seconds >> to >> : desynchronize the use of DHCP at startup. > > I'm not seeing the need for PCP to randomize its initial message. Then, there is no need to randomize subsequent retries nor exponential backoff. If initial messages are expected to be sent with well distributed timing, retries can be sent with fixed timing with no exponential backoff and the retries are still sent with well distributed timing. Worse, that's not a valid counter argument after you mention DHCPv4. > They don't need to be distinguished; there is nothing the > PCP client or PCP server can do differently by having them > distinguished. Hmmmmm, no one in this WG other than me understand how PCP works. If identical requests are sent at time 0, 5, 240, 245, 480 and 485 and identical responses with lifetime of 300 are received at time 10, 250 and 490, you can't be sure that the latest response is not a response for a request sent at time 0, in which case lifetime of the response has expired already 190 seconds ago. The only way to solve the problem is to let requests have different transaction IDs. Though requests at time 0 and 5 may have the same transaction ID, it is unnecessary complication that all the requests have unique transaction IDs. >>> The version negotiation was used once already (NAT-PMP to >>> PCP), >> >> Not yet, because PCP is not yet PS. > > I don't follow the argument that because PCP is not yet > a proposed standard RFC, it does not need version negotiation. Your statement of "The version negotiation was used" is invalidated as a reason to keep version numbers. > We are using the version negotiation already. It needs to > stay. You fail to state why "It needs to stay". Do you mean we must increment the version number to 2 if we change packet format to introduce transaction IDs? Masataka Ohta From mohta@necom830.hpcl.titech.ac.jp Thu Feb 23 15:26:08 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED6A21F878E for ; Thu, 23 Feb 2012 15:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.048 X-Spam-Level: X-Spam-Status: No, score=-0.048 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLsYPhf8QnNO for ; Thu, 23 Feb 2012 15:26:08 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 157B721F875D for ; Thu, 23 Feb 2012 15:26:07 -0800 (PST) Received: (qmail 94475 invoked from network); 23 Feb 2012 23:44:00 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 23 Feb 2012 23:44:00 -0000 Message-ID: <4F46CAD3.3010204@necom830.hpcl.titech.ac.jp> Date: Fri, 24 Feb 2012 08:25:07 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Dan Wing References: <044401ccd66e$77265810$65730830$@com> <4F2F057B.3050100@necom830.hpcl.titech.ac.jp> <227d01cce70a$42925fc0$c7b71f40$@com> <4F3633DE.7080505@necom830.hpcl.titech.ac.jp> <082c01ccea79$1eb48070$5c1d8150$@com> <4F39ACA9.7070609@necom830.hpcl.titech.ac.jp> <077a01ccec3a$6e9c5820$4bd50860$@com> <4F4627C2.60509@necom830.hpcl.titech.ac.jp> <082701ccf23e$6d3b03a0$47b10ae0$@com> In-Reply-To: <082701ccf23e$6d3b03a0$47b10ae0$@com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: pcp@ietf.org Subject: Re: [pcp] GETLOCALNETS (was Re: draft-ietf-pcp-base-22) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 23:26:08 -0000 Dan Wing wrote: > Could you explain in more detail how GETLOCALNETS would work, > such as the example you proposed earlier of an FTP client > accessing an FTP server on the local network. The first thing for an FTP client, which is also an PCP client, is to issue LOCALNETS request to a PCP server. Its response should contain local net information as a list of prefixes with their mask lengths, such as 10.0.0.0/16 and 10.2.0.0/24. Then, the FTP client further use PCP only if an address of an FTP server is outside of 10.0.0.0/16 and 10.2.0.0/24. Thus, it is guaranteed that local FTP servers, local firewalls and other local equipments see identical behavior of local FTP clients to access local FTP servers regardless of whether the clients are PCP capable or not. Masataka Ohta From dwing@cisco.com Fri Feb 24 16:40:44 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092B021E8021 for ; Fri, 24 Feb 2012 16:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.773 X-Spam-Level: X-Spam-Status: No, score=-108.773 tagged_above=-999 required=5 tests=[AWL=1.826, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGHTI4RtbtMy for ; Fri, 24 Feb 2012 16:40:43 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1A04721E8019 for ; Fri, 24 Feb 2012 16:40:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3840; q=dns/txt; s=iport; t=1330130443; x=1331340043; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=XgKKXtU5hakZ/hQEX5USrmTak2220EUA2QhGrmRFjdQ=; b=eu9J/KWB6Qn3lbKfhoXwzRN2frK/APzJ+SdiwP8HJI8es3ogi8fix5ws zO42g7u0bp4x1HHvprVrMhQGJIK7Q0a4qpEgR+6ygbWfsnWCGtYlYv81P mTnoXGpr7aSBMl+N32hStc41g3D1bSoFIPwtMHtes/JrembsUMcmoZ7sT s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAktSE+rRDoG/2dsb2JhbABEDqMkj2+BB4FzAQEBAwEICgEXED8FBwEDAgkOAQIEAQEBJwcZIwoJCAEBBBMLF4dfBKBRAZZvjQADBAQBAQEOBAkPAQJDAwQKCgEBAYVoFYM8BIhPhQeaHVg X-IronPort-AV: E=Sophos;i="4.73,478,1325462400"; d="scan'208";a="32410311" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 25 Feb 2012 00:40:38 +0000 Received: from dwingWS (sjc-vpn7-561.cisco.com [10.21.146.49]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1P0ebxn023438; Sat, 25 Feb 2012 00:40:37 GMT From: "Dan Wing" To: "'Masataka Ohta'" References: <044401ccd66e$77265810$65730830$@com> <4F2F057B.3050100@necom830.hpcl.titech.ac.jp> <227d01cce70a$42925fc0$c7b71f40$@com> <4F3633DE.7080505@necom830.hpcl.titech.ac.jp> <082c01ccea79$1eb48070$5c1d8150$@com> <4F39ACA9.7070609@necom830.hpcl.titech.ac.jp> <077a01ccec3a$6e9c5820$4bd50860$@com> <4F462EF3.2080004@necom830.hpcl.titech.ac.jp> <081d01ccf23d$d2b47370$781d5a50$@com> <4F46C8C9.4070706@necom830.hpcl.titech.ac.jp> In-Reply-To: <4F46C8C9.4070706@necom830.hpcl.titech.ac.jp> Date: Fri, 24 Feb 2012 16:40:37 -0800 Message-ID: <0f0c01ccf356$17d1e370$4775aa50$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczygVNZQaGrzbgKSRO0+0YOZU4z7gA02uNQ Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base-22 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 00:40:44 -0000 > -----Original Message----- > From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] > Sent: Thursday, February 23, 2012 3:16 PM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] draft-ietf-pcp-base-22 > > Dan Wing wrote: > > >>> No, the document is still silent on UDP checksum. > >> > >> Why? > > > > UDP is a lower layer, covered adequately by other specifications. > > Much like IP checksum is covered by other specifications. > > As is specified in RFC1122, UDP checksuming is controlled by > applications: > > An application MAY optionally be able to > control whether a UDP checksum will be generated, but it > MUST default to checksumming on. > > which means it is a part of application specification whether > an application turns on it or not. I don't interpret the text in RFC1122 the same. > >>> Sure, but DHCPv4 does not randomize. > >> > >> RFC2131 says: > >> > >> : 4.4.1 Initialization and allocation of network address > >> : > >> : The client begins in INIT state and forms a DHCPDISCOVER > message. > >> : The client SHOULD wait a random time between one and ten > seconds > >> to > >> : desynchronize the use of DHCP at startup. > > > > I'm not seeing the need for PCP to randomize its initial message. > > Then, there is no need to randomize subsequent retries nor > exponential backoff. > > If initial messages are expected to be sent with well > distributed timing, retries can be sent with fixed timing > with no exponential backoff and the retries are still sent > with well distributed timing. > > Worse, that's not a valid counter argument after you mention > DHCPv4. > > > They don't need to be distinguished; there is nothing the > > PCP client or PCP server can do differently by having them > > distinguished. > > Hmmmmm, no one in this WG other than me understand how > PCP works. > > If identical requests are sent at time 0, 5, 240, 245, 480 > and 485 and identical responses with lifetime of 300 are > received at time 10, 250 and 490, you can't be sure that > the latest response is not a response for a request sent > at time 0, in which case lifetime of the response has > expired already 190 seconds ago. I adjusted the text, on your earlier suggestion, that the PCP client start its internal countdown based on when it sends its first request. The PCP client can't do anything with the mapping until it gets a response. And the scenario above requires the PCP server and/or the network to queue PCP messages for dozens or hundreds of seconds. > The only way to solve the problem is to let requests > have different transaction IDs. Though requests at time > 0 and 5 may have the same transaction ID, it is unnecessary > complication that all the requests have unique transaction > IDs. Transaction IDs are an unnecessary complication. The packets are sufficiently self describing that the problem described in your message does not occur. > >>> The version negotiation was used once already (NAT-PMP to > >>> PCP), > >> > >> Not yet, because PCP is not yet PS. > > > > I don't follow the argument that because PCP is not yet > > a proposed standard RFC, it does not need version negotiation. > > Your statement of "The version negotiation was used" is > invalidated as a reason to keep version numbers. > > > We are using the version negotiation already. It needs to > > stay. > > You fail to state why "It needs to stay". > > Do you mean we must increment the version number to 2 if > we change packet format to introduce transaction IDs? Changes to the PCP header layout, which are incompatible with the current version of the PCP header layout, would necessitate increasing the version number. -d From dwing@cisco.com Fri Feb 24 16:43:58 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CD921E8021 for ; Fri, 24 Feb 2012 16:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.802 X-Spam-Level: X-Spam-Status: No, score=-108.802 tagged_above=-999 required=5 tests=[AWL=1.797, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HagGUHFGnaeP for ; Fri, 24 Feb 2012 16:43:57 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 45D5D21E8019 for ; Fri, 24 Feb 2012 16:43:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1174; q=dns/txt; s=iport; t=1330130637; x=1331340237; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=h53fG6U+SuQ30sclwrCsHc+3PAThv3dECfhen6bVgdw=; b=QoFpVvuC8/sMaEjx5QTCq6nBFoA79RLS1BWwGRv68rZXBNFxanjYBcfv KwbrvCvUmIagAJYbByBJxHdoyh9jxSNpOwJAC++zPFT2QO2XbGOkJe8Xe Jut668mQu4i2RJCt9XzRyIC5gTJz4HQJ8VpPRkcy/KPJpkQbDxXh0tWkx o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADYuSE+rRDoJ/2dsb2JhbABEDqMkj2+BB4FzAQEBBAgKARcQPwwBAwIJDgECBAEBAScHGSMKCQgBAQQTCxeHY6BVAZZviWKDHhEgBwECQwMECgUDAgEBAYVoFYM8BIhPhQeaHViBOw X-IronPort-AV: E=Sophos;i="4.73,479,1325462400"; d="scan'208";a="32277764" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 25 Feb 2012 00:43:57 +0000 Received: from dwingWS (sjc-vpn7-561.cisco.com [10.21.146.49]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1P0huUv006319; Sat, 25 Feb 2012 00:43:56 GMT From: "Dan Wing" To: "'Masataka Ohta'" References: <044401ccd66e$77265810$65730830$@com> <4F2F057B.3050100@necom830.hpcl.titech.ac.jp> <227d01cce70a$42925fc0$c7b71f40$@com> <4F3633DE.7080505@necom830.hpcl.titech.ac.jp> <082c01ccea79$1eb48070$5c1d8150$@com> <4F39ACA9.7070609@necom830.hpcl.titech.ac.jp> <077a01ccec3a$6e9c5820$4bd50860$@com> <4F4627C2.60509@necom830.hpcl.titech.ac.jp> <082701ccf23e$6d3b03a0$47b10ae0$@com> <4F46CAD3.3010204@necom830.hpcl.titech.ac.jp> In-Reply-To: <4F46CAD3.3010204@necom830.hpcl.titech.ac.jp> Date: Fri, 24 Feb 2012 16:43:56 -0800 Message-ID: <0f1901ccf356$8e7b15f0$ab7141d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczygoW3MtHS7jGXRR6vVEZomqXeMQA0/skw Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] GETLOCALNETS (was Re: draft-ietf-pcp-base-22) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 00:43:58 -0000 > -----Original Message----- > From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] > Sent: Thursday, February 23, 2012 3:25 PM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: GETLOCALNETS (was Re: [pcp] draft-ietf-pcp-base-22) > > Dan Wing wrote: > > > Could you explain in more detail how GETLOCALNETS would work, > > such as the example you proposed earlier of an FTP client > > accessing an FTP server on the local network. > > The first thing for an FTP client, which is also an PCP client, > is to issue LOCALNETS request to a PCP server. Its response > should contain local net information as a list of prefixes > with their mask lengths, such as 10.0.0.0/16 and 10.2.0.0/24. > > Then, the FTP client further use PCP only if an address of an > FTP server is outside of 10.0.0.0/16 and 10.2.0.0/24. > > Thus, it is guaranteed that local FTP servers, local firewalls > and other local equipments see identical behavior of local FTP > clients to access local FTP servers regardless of whether the > clients are PCP capable or not. So, in other words: only use PCP to create a mapping when going off the local network. -d From dxhbupt@gmail.com Sun Feb 26 23:47:13 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DFF21E8019 for ; Sun, 26 Feb 2012 23:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOBGepl84UBY for ; Sun, 26 Feb 2012 23:47:12 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 35D5121E8015 for ; Sun, 26 Feb 2012 23:47:12 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so966487wgb.13 for ; Sun, 26 Feb 2012 23:47:11 -0800 (PST) Received-SPF: pass (google.com: domain of dxhbupt@gmail.com designates 10.180.80.35 as permitted sender) client-ip=10.180.80.35; Authentication-Results: mr.google.com; spf=pass (google.com: domain of dxhbupt@gmail.com designates 10.180.80.35 as permitted sender) smtp.mail=dxhbupt@gmail.com; dkim=pass header.i=dxhbupt@gmail.com Received: from mr.google.com ([10.180.80.35]) by 10.180.80.35 with SMTP id o3mr25592365wix.5.1330328831463 (num_hops = 1); Sun, 26 Feb 2012 23:47:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Zs/DEPJUScPGAntDFmTCNoGxeVzL5OZ6DNTHoyIJMas=; b=X1+GAvIOiss/Iec+zBm7U/kKkvSA0iKchb2SUuQ+KqmLo4NhMU8TBXOLah5FcoAExD TQDHcFPhKKecRRN7GzogSXohZgw53NfsYpGAWXvyimdax6cYP6mFvB+bTxeOK20Qn+ZE 8HbTKvQnK98e8g9E+Kl61L+JYWQ1SlXZjqR/E= MIME-Version: 1.0 Received: by 10.180.80.35 with SMTP id o3mr20305800wix.5.1330328831411; Sun, 26 Feb 2012 23:47:11 -0800 (PST) Received: by 10.180.98.103 with HTTP; Sun, 26 Feb 2012 23:47:11 -0800 (PST) In-Reply-To: <0f0c01ccf356$17d1e370$4775aa50$@com> References: <044401ccd66e$77265810$65730830$@com> <4F2F057B.3050100@necom830.hpcl.titech.ac.jp> <227d01cce70a$42925fc0$c7b71f40$@com> <4F3633DE.7080505@necom830.hpcl.titech.ac.jp> <082c01ccea79$1eb48070$5c1d8150$@com> <4F39ACA9.7070609@necom830.hpcl.titech.ac.jp> <077a01ccec3a$6e9c5820$4bd50860$@com> <4F462EF3.2080004@necom830.hpcl.titech.ac.jp> <081d01ccf23d$d2b47370$781d5a50$@com> <4F46C8C9.4070706@necom830.hpcl.titech.ac.jp> <0f0c01ccf356$17d1e370$4775aa50$@com> Date: Mon, 27 Feb 2012 15:47:11 +0800 Message-ID: From: Xiaohong Deng To: Dan Wing Content-Type: multipart/alternative; boundary=f46d044287f26e462304b9ed5164 Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base-22 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 07:47:13 -0000 --f46d044287f26e462304b9ed5164 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > > > > > If identical requests are sent at time 0, 5, 240, 245, 480 > > and 485 and identical responses with lifetime of 300 are > > received at time 10, 250 and 490, you can't be sure that > > the latest response is not a response for a request sent > > at time 0, in which case lifetime of the response has > > expired already 190 seconds ago. > If the first request issued at time 0 was responded at time 10, why would the client resend request again at time 5 and so on? In case the multiple requests are occurred due to network layer re-transmitting, as long as the first response assured the Client that the mapping was established, later responses wouldn=92t bother the client anyway. > > I adjusted the text, on your earlier suggestion, that the > PCP client start its internal countdown based on when it > sends its first request. > > The PCP client can't do anything with the mapping until it > gets a response. And the scenario above requires the PCP > server and/or the network to queue PCP messages for dozens > or hundreds of seconds. > > > The only way to solve the problem is to let requests > > have different transaction IDs. Though requests at time > > 0 and 5 may have the same transaction ID, it is unnecessary > > complication that all the requests have unique transaction > > IDs. > > Transaction IDs are an unnecessary complication. The packets > are sufficiently self describing that the problem described > in your message does not occur. > Aggreed. Cheers, Xiaohong --f46d044287f26e462304b9ed5164 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
>
> If identical requests are sent at time 0, 5, 240, 245, 480
> and 485 and identical responses with lifetime of 300 are
> received at time 10, 250 and 490, you can't be sure that
> the latest response is not a response for a request sent
> at time 0, in which case lifetime of the response has
> expired already 190 seconds ago.

If the first request issued at time 0 was responded at time 10, why would the clie= nt resend request again at time 5 and so on? In case the multiple requests are= occurred due to network layer re-transmitting, as long as the first response assured= the Client that the mapping was established, later responses wouldn=92t bother = the client anyway.


=A0

I adjusted the text, on your earlier suggestion, that the
PCP client start its internal countdown based on when it
sends its first request.

The PCP client can't do anything with the mapping until it
gets a response. =A0And the scenario above requires the PCP
server and/or the network to queue PCP messages for dozens
or hundreds of seconds.

> The only way to solve the problem is to let requests
> have different transaction IDs. Though requests at time
> 0 and 5 may have the same transaction ID, it is unnecessary
> complication that all the requests have unique transaction
> IDs.

Transaction IDs are an unnecessary complication. =A0The packets
are sufficiently self describing that the problem described
in your message does not occur.

Aggreed.
=A0Cheers,
Xiaohong

--f46d044287f26e462304b9ed5164-- From mohta@necom830.hpcl.titech.ac.jp Mon Feb 27 04:27:32 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6081221F8693 for ; Mon, 27 Feb 2012 04:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7iRW9g3wwbH for ; Mon, 27 Feb 2012 04:27:32 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 94D0C21F86B8 for ; Mon, 27 Feb 2012 04:27:30 -0800 (PST) Received: (qmail 95171 invoked from network); 27 Feb 2012 12:46:05 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 27 Feb 2012 12:46:05 -0000 Message-ID: <4F4B7682.7030101@necom830.hpcl.titech.ac.jp> Date: Mon, 27 Feb 2012 21:26:42 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Xiaohong Deng References: <044401ccd66e$77265810$65730830$@com> <4F2F057B.3050100@necom830.hpcl.titech.ac.jp> <227d01cce70a$42925fc0$c7b71f40$@com> <4F3633DE.7080505@necom830.hpcl.titech.ac.jp> <082c01ccea79$1eb48070$5c1d8150$@com> <4F39ACA9.7070609@necom830.hpcl.titech.ac.jp> <077a01ccec3a$6e9c5820$4bd50860$@com> <4F462EF3.2080004@necom830.hpcl.titech.ac.jp> <081d01ccf23d$d2b47370$781d5a50$@com> <4F46C8C9.4070706@necom830.hpcl.titech.ac.jp> <0f0c01ccf356$17d1e370$4775aa50$@com> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base-22 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 12:27:32 -0000 Xiaohong Deng wrote: > If the first request issued at time 0 was responded at time 10, why would > the client resend request again at time 5 Huh? Please don't demonstrate that you don't have any expertise on protocols at all, please. Masataka Ohta From dxhbupt@gmail.com Mon Feb 27 04:45:59 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B3B21F86F1 for ; Mon, 27 Feb 2012 04:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpR4dJxmI+IV for ; Mon, 27 Feb 2012 04:45:59 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id E7F4F21F86B6 for ; Mon, 27 Feb 2012 04:45:58 -0800 (PST) Received: by wgbdt10 with SMTP id dt10so1278046wgb.1 for ; Mon, 27 Feb 2012 04:45:58 -0800 (PST) Received-SPF: pass (google.com: domain of dxhbupt@gmail.com designates 10.180.80.35 as permitted sender) client-ip=10.180.80.35; Authentication-Results: mr.google.com; spf=pass (google.com: domain of dxhbupt@gmail.com designates 10.180.80.35 as permitted sender) smtp.mail=dxhbupt@gmail.com; dkim=pass header.i=dxhbupt@gmail.com Received: from mr.google.com ([10.180.80.35]) by 10.180.80.35 with SMTP id o3mr27943913wix.5.1330346758049 (num_hops = 1); Mon, 27 Feb 2012 04:45:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gbR8hqd0tBGYqBhW8TdK4QoI/FtkbkuQP4xPQZ7p7hY=; b=fSca/Ts1heMBoGGEXTym1sc9/zByrVBSlbmCv8y6J7sDKzq4F63IHyOYpDFggdjlWu BrecJCmcusvB1E1ud6ocrXmzCXIWrsEDym4fUW5ZPixXc7t0zY/Xz8MDHdHDy2nnE0Ne DYTr17IrpnO9QbGUYF2IJ2qLYeBzUD/9YNUQk= MIME-Version: 1.0 Received: by 10.180.80.35 with SMTP id o3mr22162858wix.5.1330346758004; Mon, 27 Feb 2012 04:45:58 -0800 (PST) Received: by 10.180.98.103 with HTTP; Mon, 27 Feb 2012 04:45:57 -0800 (PST) In-Reply-To: <4F4B7682.7030101@necom830.hpcl.titech.ac.jp> References: <044401ccd66e$77265810$65730830$@com> <4F2F057B.3050100@necom830.hpcl.titech.ac.jp> <227d01cce70a$42925fc0$c7b71f40$@com> <4F3633DE.7080505@necom830.hpcl.titech.ac.jp> <082c01ccea79$1eb48070$5c1d8150$@com> <4F39ACA9.7070609@necom830.hpcl.titech.ac.jp> <077a01ccec3a$6e9c5820$4bd50860$@com> <4F462EF3.2080004@necom830.hpcl.titech.ac.jp> <081d01ccf23d$d2b47370$781d5a50$@com> <4F46C8C9.4070706@necom830.hpcl.titech.ac.jp> <0f0c01ccf356$17d1e370$4775aa50$@com> <4F4B7682.7030101@necom830.hpcl.titech.ac.jp> Date: Mon, 27 Feb 2012 20:45:57 +0800 Message-ID: From: Xiaohong Deng To: Masataka Ohta Content-Type: multipart/alternative; boundary=f46d044287f2f05ecc04b9f17dca Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base-22 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 12:45:59 -0000 --f46d044287f2f05ecc04b9f17dca Content-Type: text/plain; charset=ISO-8859-1 2012/2/27 Masataka Ohta > Xiaohong Deng wrote: > > > If the first request issued at time 0 was responded at time 10, why would > > the client resend request again at time 5 > > Huh? > > Please don't demonstrate that you don't have any expertise on > protocols at all, please. > Please specify your technical disagreement than your personal feeling which is of no help. Xiaohong > > Masataka Ohta > --f46d044287f2f05ecc04b9f17dca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/2/27 Masataka Ohta <mohta@necom830.hp= cl.titech.ac.jp>
Xiaohong Deng wrote:

> If the first request issued at time 0 was responded at time 10, why wo= uld
> the client resend request again at time 5

Huh?

Please don't demonstrate that you don't have any expertise on
protocols at all, please.

Please specify your tech= nical disagreement than your personal feeling which is of no help.

= Xiaohong
=A0

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0Masataka Ohta

--f46d044287f2f05ecc04b9f17dca-- From mohta@necom830.hpcl.titech.ac.jp Mon Feb 27 05:27:05 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5313F21F86E3 for ; Mon, 27 Feb 2012 05:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.015 X-Spam-Level: X-Spam-Status: No, score=-0.015 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxT5TLNjbZg9 for ; Mon, 27 Feb 2012 05:27:05 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 89DC121F86E2 for ; Mon, 27 Feb 2012 05:27:04 -0800 (PST) Received: (qmail 96878 invoked from network); 27 Feb 2012 13:45:49 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 27 Feb 2012 13:45:49 -0000 Message-ID: <4F4B847F.10304@necom830.hpcl.titech.ac.jp> Date: Mon, 27 Feb 2012 22:26:23 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Xiaohong Deng References: <044401ccd66e$77265810$65730830$@com> <4F2F057B.3050100@necom830.hpcl.titech.ac.jp> <227d01cce70a$42925fc0$c7b71f40$@com> <4F3633DE.7080505@necom830.hpcl.titech.ac.jp> <082c01ccea79$1eb48070$5c1d8150$@com> <4F39ACA9.7070609@necom830.hpcl.titech.ac.jp> <077a01ccec3a$6e9c5820$4bd50860$@com> <4F462EF3.2080004@necom830.hpcl.titech.ac.jp> <081d01ccf23d$d2b47370$781d5a50$@com> <4F46C8C9.4070706@necom830.hpcl.titech.ac.jp> <0f0c01ccf356$17d1e370$4775aa50$@com> <4F4B7682.7030101@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base-22 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 13:27:05 -0000 Xiaohong Deng wrote: >>> If the first request issued at time 0 was responded at time 10, why would >>> the client resend request again at time 5 >> >> Huh? >> >> Please don't demonstrate that you don't have any expertise on >> protocols at all, please. > Please specify your technical disagreement than your personal feeling which > is of no help. I'm afraid you can have no help being incapable to have any technical opinion. Or, feel free to have a time machine or two to resend a request at time 5 *AFTER* you receive a response at time 10. Masataka Ohta