From ext-felipe.m.costa@nokia.com Tue Jan 3 07:58: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 07E9621F8488 for ; Tue, 3 Jan 2012 07:58: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 faL3JzoeYlja for ; Tue, 3 Jan 2012 07:58:40 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id B2B2021F8487 for ; Tue, 3 Jan 2012 07:58:39 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q03FwYKL001547; Tue, 3 Jan 2012 17:58:34 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jan 2012 17:58:33 +0200 Received: from 008-AM1MPN1-013.mgdnok.nokia.com ([169.254.3.94]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0355.003; Tue, 3 Jan 2012 16:58:33 +0100 From: To: , Thread-Topic: On the State Diagram of pcp-base-19 Thread-Index: AczKMDVSiXhrn1XlRGawHgf5GZzvqg== Date: Tue, 3 Jan 2012 15:58:32 +0000 Message-ID: <0412136DF48FC94A9795E62ECFC014650E5F1231@008-AM1MPN1-013.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-headerinfofordlp: None x-titus-version: 3.3.8.1 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-tituslabs-classificationhash-30: aEUmLV3CI+tewwS7hd9znXyS9cMDc09hFeVh5WMgCc+P/xD6tjI4RU+mETQVuSEftwKQodlXe2mv0Xo+RE5czpUH1s0FCZ6B6ez4GFVvDlFPhUHtDrI3UjDfu9pbxLWeYI26VIwnPUKUYX+UoUnpEnfq4R5LlfrYu/luDjP4eeOOLiLUkvaedxFyB3IgU2MHZNWmSyU41PeO2TxKQXdDdGucj51l8KJHh7EvT77qwhXtV5Vhcyb4CHmNG8FKVWCg x-originating-ip: [189.2.128.130] Content-Type: multipart/alternative; boundary="_000_0412136DF48FC94A9795E62ECFC014650E5F1231008AM1MPN1013mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jan 2012 15:58:33.0994 (UTC) FILETIME=[8BD206A0:01CCCA30] X-Nokia-AV: Clean Subject: [pcp] On the State Diagram of pcp-base-19 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, 03 Jan 2012 15:58:42 -0000 --_000_0412136DF48FC94A9795E62ECFC014650E5F1231008AM1MPN1013mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Analyzing the current State-diagram in I-D v19 ( http://tools.ietf.org/html= /draft-ietf-pcp-base-19#section-14.5 ) CLOSE_MSGS or (NO_TRAFFIC and EXPIRY) +---------+ NO_TRAFFIC and EXPIRY +------------>| |<------------+ | |NO_ENTRY | | | +---------| |---------+ | | | +---------+ | | | | ^ | | | | | NO_TRAFFIC | | | | | | or | | | | | | CLOSE_MSGS | | | | | | | | | | | | P-R | | M-R | | | V | | V | +---------+ | | +---------+ +-->| | | | M-R | |<--+ P-R | | P |---------|--|-------->| M | | M-R or +---| | | | | |---+ P-R or +---------+ | | +---------+ CLOSE_MSGS | ^ | | ^ | | | P-R | | M-R | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | O-TRAFFIC | | | | | V | | | | +---------+ | | | +---------| |<--------+ | | | I | | +------------>| |<------------+ TRAFFIC and EXPIRY +---------+ TRAFFIC and EXPIRY I observed that, for example, if the mapping is in the M state and it expir= es, but the PCP-controlled device has incoming traffic going through this mapping, the mapping transit= from the M to the I state and continues to receive this incoming traffic, which means that the control of the mapping = is taken out from the PCP protocol and is given to the remote host, that is generating this incoming data. Considering many aspects of the PCP I-D, IMHO a better diagram state would = be: CLOSE_MSGS or EXPIRY +---------+ EXPIRY or M-D-R +------------>| |<------------+ | |NO_ENTRY | | | +---------| |---------+ | | | +---------+ | | | | ^ | | | | | NO_TRAFFIC | | | | | | or | | | | | | CLOSE_MSGS | | | | | | | | | | | | P-R | | M-R | | | V | | V | +---------+ | | +---------+ +-->| | | | M-R | |<--+ P-R | | P |---------|--|-------->| M | | M-R or +---| | | | | |---+ P-R or +---------+ | | +---------+ CLOSE_MSGS ^ | | ^ | P-R | | M-R | | | | | | | | | | | | | | | | | | | | O-TRAFFIC | | | V | | +---------+ | +---------| |<--------+ | I | | | +---------+ where: M-D-R is a MAP deletion request Observations: 1. TRAFFIC or NO_TRAFFIC shouldn't determine the transition from MAP (or PE= ER) mappings to other states. Instead, for keeping the protocol consistent,= EXPIRY should determine the transition from P and M to NO_ENTRY. A PEER or= MAP mapping in the PCP-controlled device should be oblivious to TRAFIC (in= bound or outbound): 1.1. MAP mapping: EXPIRY or a MAP Deletion Request should be the only causes of a MAP mapping= going to the NO_ENTRY state. I think the direct transition M -> I* should = not be possible. 1.2. PEER mapping: CLOSE_MSG or EXPIRY should be the only causes of a PEER mapping going to th= e NO_ENTRY state. The direct transition P -> I* should not be allowed. * The transitions M->I and P->I can happen if the mappings go through the i= ntermediate state NO_ENTRY and O-TRAFFIC is present. Of course that, if pos= sible, the PCP Controlled device should keep the same previous (M or P mapp= ing's) values of external address and external port in this new I mapping. Best Regards, Felipe Miranda Costa --_000_0412136DF48FC94A9795E62ECFC014650E5F1231008AM1MPN1013mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Analyzing the current State-diagram in I-D v19= ( http://tools.ietf.org/= html/draft-ietf-pcp-base-19#section-14.5 )

 

        =          CLOSE_MSGS or        = ;             

         (NO_TRAFFIC and EXPI= RY) +---------+  NO_TRAFFIC and EXPIRY=

           &nb= sp;       +------------>|  &= nbsp;      |<------------+

           &nb= sp;       |     &nbs= p;       |NO_ENTRY |    &= nbsp;        |

           &nb= sp;       |   +---------| =         |---------+   |

           &nb= sp;       |   |   &n= bsp;     +---------+    &nb= sp;    |   |

           &nb= sp;       |   |   &n= bsp;        ^  |   &= nbsp;         |   |

           &nb= sp;       |   | NO_TRAFFIC |  = |             |=    |

           &nb= sp;       |   |   &n= bsp;     or |  |     &nbs= p;       |   |

           &nb= sp;       |   | CLOSE_MSGS |  = |             |=    |

           &nb= sp;       |   |   &n= bsp;        |  |   &= nbsp;         |   |

           &nb= sp;       |   | P-R  &nbs= p;     |  |      &nb= sp;  M-R |   |

           &nb= sp;       |   V   &n= bsp;        |  |   &= nbsp;         V   |

           &nb= sp;    +---------+     &nbs= p;   |  |         &#= 43;---------+

            &#= 43;-->|         |  &nb= sp;      |  |    M-R  |&n= bsp;        |<--+

        P-R |   | &= nbsp;  P    |---------|--|-------->|  &nbs= p; M    |   | M-R or

            &#= 43;---|         |   =       |  |      = ;   |         |---+ P= -R or

           &nb= sp;    +---------+     &nbs= p;   |  |         &#= 43;---------+   CLOSE_MSGS

           &nb= sp;       |   ^   &n= bsp;        |  |   &= nbsp;         ^   | =              

           &nb= sp;       |   | P-R  &nbs= p;     |  |      &nb= sp;  M-R |   |

           &nb= sp;       |   |   &n= bsp;        |  |   &= nbsp;         |   |

           &nb= sp;       |   |   &n= bsp;        |  |   &= nbsp;         |   |

           &nb= sp;       |   |   &n= bsp;        |  |   &= nbsp;         |   |

           &nb= sp;       |   |   &n= bsp;        |  |   &= nbsp;         |   |

           &nb= sp;       |   |   &n= bsp;        |  | O-TRAFFIC &nb= sp; |   |

           &nb= sp;       |   |   &n= bsp;        |  V   &= nbsp;         |   | =       

           &nb= sp;       |   |   &n= bsp;     +---------+    &nb= sp;    |   |      &n= bsp;      

           &nb= sp;       |   +---------| =         |<--------+   |=

           &nb= sp;       |     &nbs= p;       |    I  &nb= sp; |           &nbs= p; |

           &nb= sp;       +------------>|  &= nbsp;      |<------------+

           &nb= sp;  TRAFFIC and EXPIRY +---------+  TRAFFIC and EXPIRY

 

 

I observed that, for example, if the mapping i= s in the M state and it expires, but the PCP-controlled 

device has incoming traffic going through this= mapping, the mapping transit from the M to the I state and continues to&nb= sp;

receive this incoming traffic, which means tha= t the control of the mapping is taken out from the PCP protocol and is = ;

given to the remote host, that is generating t= his incoming data.

 

 

Considering many aspects of the PCP I-D, IMHO = a better diagram state would be:

 

            &nbs= p;   

        =                      = ;           

           CLOSE_MSGS or EXPIRY &n= bsp;+---------+ EXPIRY or M-D-R

           &nb= sp;       +------------>|  &= nbsp;      |<------------+

           &nb= sp;       |     &nbs= p;       |NO_ENTRY |    &= nbsp;        |

           &nb= sp;       |   +---------| =         |---------+   |

           &nb= sp;       |   |   &n= bsp;     +---------+    &nb= sp;    |   |

           &nb= sp;       |   |   &n= bsp;        ^  |   &= nbsp;         |   |

           &nb= sp;       |   | NO_TRAFFIC |  = |             |=    |

           &nb= sp;       |   |   &n= bsp;     or |  |     &nbs= p;       |   |

           &nb= sp;       |   | CLOSE_MSGS |  = |             |=    |

           &nb= sp;       |   |   &n= bsp;        |  |   &= nbsp;         |   |

           &nb= sp;       |   | P-R  &nbs= p;     |  |      &nb= sp;  M-R |   |

           &nb= sp;       |   V   &n= bsp;        |  |   &= nbsp;         V   |

           &nb= sp;    +---------+     &nbs= p;   |  |         &#= 43;---------+

            &#= 43;-->|         |  &nb= sp;      |  |    M-R  |&n= bsp;        |<--+

        P-R |   | &= nbsp;  P    |---------|--|-------->|  &nbs= p; M    |   | M-R or

            &#= 43;---|         |   =       |  |      = ;   |         |---+ P= -R or

           &nb= sp;    +---------+     &nbs= p;   |  |         &#= 43;---------+   CLOSE_MSGS

                   =    ^          =   |  |          = ;   ^                &nbs= p;

                   =    | P-R        |  |&nbs= p;        M-R |   

                   =    |          =   |  |          = ;   |   

                   =    |          =   |  |          = ;   |   

                   =    |          =   |  |          = ;   |   

                   =    |          =   |  |          = ;   |   

                   =    |          =   |  | O-TRAFFIC   |   

                   =    |          =   |  V          = ;   |          <= /span>

                   =    |         +------= ---+         |     &n= bsp;          

                   =    +---------|       &nbs= p; |<--------+   

                   =              |    I = ;   |             

                   =              |       &nb= sp; |

                   =              +---------+  =

  &nb= sp;            =                           &nb= sp;                 

 

where:

M-D-R is a MAP deletion request

 

Observations:

 

1. TRAFFIC or NO_TRAFFIC shouldn't determine t= he transition from MAP (or PEER) mappings to other states. Instead, for kee= ping the protocol consistent, EXPIRY should determine the transition from P and M to NO_ENTRY. A PEER or MAP mapping in the PCP-cont= rolled device should be oblivious to TRAFIC (inbound or outbound):

 

1.1. MAP mapping:

EXPIRY or a MAP Deletion Request should be the= only causes of a MAP mapping going to the NO_ENTRY state. I think the dire= ct transition M -> I* should not be possible.

 

1.2. PEER mapping:

CLOSE_MSG or EXPIRY should be the only causes = of a PEER mapping going to the NO_ENTRY state. The direct transition P ->= ; I* should not be allowed.

 

* The transitions M->I and P->I can happ= en if the mappings go through the intermediate state NO_ENTRY and O-TRAFFIC= is present. Of course that, if possible, the PCP Controlled device should keep the same previous (M or P mapping’s) values of external = address and external port in this new I mapping.

 

Best Regards,

 

Felipe Miranda Costa

 

 

--_000_0412136DF48FC94A9795E62ECFC014650E5F1231008AM1MPN1013mg_-- From rangan@cisco.com Tue Jan 3 20:55:30 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 497D911E8086 for ; Tue, 3 Jan 2012 20:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3ckVzsBgVeU for ; Tue, 3 Jan 2012 20:55:27 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1087011E8081 for ; Tue, 3 Jan 2012 20:55:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rangan@cisco.com; l=64150; q=dns/txt; s=iport; t=1325652924; x=1326862524; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=7ciUTebTlm55qiFaG/pvcOQQqi7nnHEaf/FkpF3USGI=; b=SAEwkptg9cv+GGR8naQdqHJYdHnMXrmjdWHqtq+Z7VWDbM5Azs8QU+sH eOPygRh++/oYlTv5Esp/ZA9JvEeX/xU6vCNduKVr4Ft06qQ20cFsYEbFi Ii1d3TlkgMB6KydlFyyBnshn8l781jutICRQFhfw88To7UMzlwcw8mnek Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAEAGTbA09Io8UY/2dsb2JhbABDggVJqxiBcgEBAQQSAQkLBgNZAgEIEQQBAQsGEAEGAQYBRQkIAQEEAQoICBqHYJcuAZ4piyxjBIg1nwk X-IronPort-AV: E=Sophos;i="4.71,454,1320624000"; d="scan'208,217";a="2720412" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 04 Jan 2012 04:55:22 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q044tM3I025532; Wed, 4 Jan 2012 04:55:22 GMT Received: from xmb-bgl-413.cisco.com ([72.163.129.209]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Jan 2012 10:25:22 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: B467 F5MU GtQ5 H+p6 Jb2s LKNs LYSI Mj2J Mx0U PdjQ PzW2 QnVu Q+cQ RZwS R9nX UGE6; 2; ZQB4AHQALQBmAGUAbABpAHAAZQAuAG0ALgBjAG8AcwB0AGEAQABuAG8AawBpAGEALgBjAG8AbQA7AHAAYwBwAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {52FAECF5-A68C-4C06-B4A3-CA4267C89A03}; cgBhAG4AZwBhAG4AQABjAGkAcwBjAG8ALgBjAG8AbQA=; Wed, 04 Jan 2012 04:55:15 GMT; UgBFADoAIABPAG4AIAB0AGgAZQAgAFMAdABhAHQAZQAgAEQAaQBhAGcAcgBhAG0AIABvAGYAIABwAGMAcAAtAGIAYQBzAGUALQAxADkA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCCA9D.10309475" x-cr-puzzleid: {52FAECF5-A68C-4C06-B4A3-CA4267C89A03} Content-class: urn:content-classes:message Date: Wed, 4 Jan 2012 10:25:15 +0530 Message-ID: <0C34754A9045B3419FB531A8C716E24907091732@XMB-BGL-413.cisco.com> In-Reply-To: <0412136DF48FC94A9795E62ECFC014650E5F1231@008-AM1MPN1-013.mgdnok.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: On the State Diagram of pcp-base-19 Thread-Index: AczKMDVSiXhrn1XlRGawHgf5GZzvqgAaZjzg References: <0412136DF48FC94A9795E62ECFC014650E5F1231@008-AM1MPN1-013.mgdnok.nokia.com> From: "Ranganathan T S (rangan)" To: , X-OriginalArrivalTime: 04 Jan 2012 04:55:22.0124 (UTC) FILETIME=[106E44C0:01CCCA9D] Subject: Re: [pcp] On the State Diagram of pcp-base-19 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, 04 Jan 2012 04:55:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCCA9D.10309475 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Felipe Miranda Costa, =20 Thanks for the review.=20 =20 First point: =20 The I-D mention the following for PEER here : =20 If a PEER-created or PEER-managed mapping is not renewed using PEER, then it reverts to the NAT's usual behavior for implicit mappings, e.g., continued outbound traffic keeps the mapping alive, as per the NAT or firewall device's existing policy. =20 =20 Second point: =20 The I-D mention the following for MAP here : =20 Mappings created by PCP MAP requests are not special or different from mappings created in other ways. In particular, it is implementation-dependent if outgoing traffic extends the lifetime of such mappings beyond the PCP-assigned lifetime. PCP clients MUST NOT depend on this behavior to keep mappings active, and MUST explicitly renew their mappings as required by the Lifetime field in PCP response messages. =20 Third point: =20 The paradigm I used to create the diagram is: * Give precedence to traffic compared to expiry.=20 * That is if traffic is still flowing when expiry happens, do not drop the sessions and let it end gracefully. =20 The diagram added to I-Dv19 satisfies all the above three points. =20 Thanks, Rangan. =20 From: ext-felipe.m.costa@nokia.com [mailto:ext-felipe.m.costa@nokia.com] Sent: Tuesday, January 03, 2012 9:29 PM To: pcp@ietf.org; Ranganathan T S (rangan) Subject: On the State Diagram of pcp-base-19 =20 Analyzing the current State-diagram in I-D v19 ( http://tools.ietf.org/html/draft-ietf-pcp-base-19#section-14.5 ) =20 CLOSE_MSGS or =20 (NO_TRAFFIC and EXPIRY) +---------+ NO_TRAFFIC and EXPIRY +------------>| |<------------+ | |NO_ENTRY | | | +---------| |---------+ | | | +---------+ | | | | ^ | | | | | NO_TRAFFIC | | | | | | or | | | | | | CLOSE_MSGS | | | | | | | | | | | | P-R | | M-R | | | V | | V | +---------+ | | +---------+ +-->| | | | M-R | |<--+ P-R | | P |---------|--|-------->| M | | M-R or +---| | | | | |---+ P-R or +---------+ | | +---------+ CLOSE_MSGS | ^ | | ^ | =20 | | P-R | | M-R | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | O-TRAFFIC | | | | | V | | =20 | | +---------+ | | =20 | +---------| |<--------+ | | | I | | +------------>| |<------------+ TRAFFIC and EXPIRY +---------+ TRAFFIC and EXPIRY =20 =20 I observed that, for example, if the mapping is in the M state and it expires, but the PCP-controlled=20 device has incoming traffic going through this mapping, the mapping transit from the M to the I state and continues to=20 receive this incoming traffic, which means that the control of the mapping is taken out from the PCP protocol and is=20 given to the remote host, that is generating this incoming data. =20 =20 Considering many aspects of the PCP I-D, IMHO a better diagram state would be: =20 =20 =20 CLOSE_MSGS or EXPIRY +---------+ EXPIRY or M-D-R +------------>| |<------------+ | |NO_ENTRY | | | +---------| |---------+ | | | +---------+ | | | | ^ | | | | | NO_TRAFFIC | | | | | | or | | | | | | CLOSE_MSGS | | | | | | | | | | | | P-R | | M-R | | | V | | V | +---------+ | | +---------+ +-->| | | | M-R | |<--+ P-R | | P |---------|--|-------->| M | | M-R or +---| | | | | |---+ P-R or +---------+ | | +---------+ CLOSE_MSGS ^ | | ^ =20 | P-R | | M-R | =20 | | | | =20 | | | | =20 | | | | =20 | | | | =20 | | | O-TRAFFIC | =20 | | V | =20 | +---------+ | =20 +---------| |<--------+ =20 | I | =20 | | +---------+ =20 =20 =20 where: M-D-R is a MAP deletion request =20 Observations: =20 1. TRAFFIC or NO_TRAFFIC shouldn't determine the transition from MAP (or PEER) mappings to other states. Instead, for keeping the protocol consistent, EXPIRY should determine the transition from P and M to NO_ENTRY. A PEER or MAP mapping in the PCP-controlled device should be oblivious to TRAFIC (inbound or outbound): =20 1.1. MAP mapping: EXPIRY or a MAP Deletion Request should be the only causes of a MAP mapping going to the NO_ENTRY state. I think the direct transition M -> I* should not be possible. =20 1.2. PEER mapping: CLOSE_MSG or EXPIRY should be the only causes of a PEER mapping going to the NO_ENTRY state. The direct transition P -> I* should not be allowed. =20 * The transitions M->I and P->I can happen if the mappings go through the intermediate state NO_ENTRY and O-TRAFFIC is present. Of course that, if possible, the PCP Controlled device should keep the same previous (M or P mapping's) values of external address and external port in this new I mapping. =20 Best Regards, =20 Felipe Miranda Costa =20 =20 ------_=_NextPart_001_01CCCA9D.10309475 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Felipe Miranda Costa,

 

Thanks for the review.

 

First point:

 

The I-D mention the following for PEER h= ere:

 

   If a PEER-created or =
PEER-managed mapping is not renewed using PEER,

   then it reverts to the NAT's = usual behavior for implicit mappings,

   e.g., continued outbound traffic = keeps the mapping alive, as per the

   NAT or firewall device's = existing policy. 

 

Second point:

 

The I-D mention the following for MAP h= ere:

 

   Mappings created by PCP =
MAP requests are not
   special or different from =
mappings created in other ways.  In
   particular, it is =
implementation-dependent if outgoing traffic
   extends the lifetime of such =
mappings beyond the PCP-assigned
   lifetime.  PCP clients =
MUST NOT depend on this behavior to keep
   mappings active, and MUST =
explicitly renew their mappings as required
   by the Lifetime field in PCP =
response messages.

 

Third point:

 

The paradigm I used to create the diagram = is:

·         Give precedence to traffic compared to expiry. =

·         That is if traffic is still flowing when expiry happens, = do not drop the sessions and let it end gracefully.

 

The diagram added to I-Dv19 satisfies all the above three points.

 

Thanks,

Rangan.

 

From:= ext-felipe.m.costa@nokia.com [mailto:ext-felipe.m.costa@nokia.com]
Sent: Tuesday, January 03, 2012 9:29 PM
To: pcp@ietf.org; Ranganathan T S (rangan)
Subject: On the State Diagram of = pcp-base-19

 

Analyzing the current State-diagram in I-D v19 ( h= ttp://tools.ietf.org/html/draft-ietf-pcp-base-19#section-14.5 )<= o:p>

 <= /span>

   =                CLOSE_MSGS or   =                 =   =

         (NO_TRAFFIC and EXPIRY) +---------+  NO_TRAFFIC and = EXPIRY=

         &= nbsp;         +------------>|         |<------------+

         &= nbsp;         |            = |NO_ENTRY = |            = |=

         &= nbsp;         |   = +---------|         |---------+   |

         &= nbsp;         |   |         +---------+         = |   |=

         &= nbsp;         |   |            = ^  |            = |   |=

         &= nbsp;         |   | NO_TRAFFIC |  |            = |   |=

         &= nbsp;         |   |         or = |  |            = |   |=

         &= nbsp;         |   | CLOSE_MSGS |  |            = |   |=

         &= nbsp;         |   |            = |  |            = |   |=

         &= nbsp;         |   | P-R        |  |         M-R |   = |=

         &= nbsp;         |   V            = |  |            = V   |=

         &= nbsp;      +---------+         |  |         = +---------+=

         &= nbsp;  +-->|         |         |  = |    M-R  |         = |<--+=

        P-R |   |    P    |---------|--|-------->|    M    = |   | M-R or=

         &= nbsp;  +---|         |         |  |         = |         |---+ P-R or=

         &= nbsp;      +---------+         |  |         = +---------+   CLOSE_MSGS=

         &= nbsp;         |   ^            = |  |            = ^   |              =

         &= nbsp;         |   | P-R        |  |         M-R |   = |=

         &= nbsp;         |   |            = |  |            = |   |=

         &= nbsp;         |   |            = |  |            = |   |=

         &= nbsp;         |   |            = |  |            = |   |=

         &= nbsp;         |   |            = |  |            = |   |=

         &= nbsp;         |   |            = |  | O-TRAFFIC   |   |

         &= nbsp;         |   |            = |  V            = |   |       

         &= nbsp;         |   |         +---------+         = |   |            =  =

         &= nbsp;         |   +---------|         |<--------+   |

         &= nbsp;         |            = |    I    = |            = |=

         &= nbsp;         +------------>|         |<------------+

         &= nbsp;    TRAFFIC and EXPIRY +---------+  TRAFFIC and EXPIRY=

 <= /span>

 <= /span>

I observed that, for example, if the mapping is in the M state and it = expires, but the PCP-controlled 

device has incoming traffic going through this mapping, the mapping transit = from the M to the I state and continues to 

receive this incoming traffic, which means that the control of the mapping is = taken out from the PCP protocol and is 

given to the remote host, that is generating this incoming = data.

 <= /span>

 <= /span>

Considering many aspects of the PCP I-D, IMHO a better diagram state would = be:

 <= /span>

              =   

    =                       =               

           CLOSE_MSGS or EXPIRY =  +---------+ EXPIRY or M-D-R=

         &= nbsp;         +------------>|         |<------------+

         &= nbsp;         |            = |NO_ENTRY = |            = |=

         &= nbsp;         |   = +---------|         |---------+   |

         &= nbsp;         |   |         +---------+         = |   |=

         &= nbsp;         |   |            = ^  |            = |   |=

         &= nbsp;         |   | NO_TRAFFIC |  |            = |   |=

         &= nbsp;         |   |         or = |  |            = |   |=

         &= nbsp;         |   | CLOSE_MSGS |  |            = |   |=

         &= nbsp;         |   |            = |  |            = |   |=

         &= nbsp;         |   | P-R        |  |         M-R |   = |=

         &= nbsp;         |   V            = |  |            = V   |=

         &= nbsp;      +---------+         |  |         = +---------+=

         &= nbsp;  +-->|         |         |  = |    M-R  |         = |<--+=

        P-R |   |    P    = |---------|--|-------->|    M    |   | M-R or

         &= nbsp;  +---|         |         |  |         = |         |---+ P-R or=

         &= nbsp;      +---------+         |  |         = +---------+   CLOSE_MSGS=

                       ^           = |  |            = ^               =   =

                      =  | P-R        |  |         M-R | =   =

                       |           = |  |            = |   =

                       |           = |  |            = |   =

                       |           = |  |            = |   =

                       |           = |  |            = |   =

                       |           = |  | O-TRAFFIC   |   

                       |           = |  V            = |          

                       |         +---------+         |   =              

                       +---------|         |<--------+   

                      =            |    = I    |             

                      =            |         = |=

                      =            +---------+  =

         &n= bsp;           &nb= sp;           &n= bsp;       =                 =   

 <= /span>

where:<= /span>

M-D-R is a MAP deletion request

 <= /span>

Observations:=

 <= /span>

1. TRAFFIC or NO_TRAFFIC shouldn't determine the transition from MAP (or = PEER) mappings to other states. Instead, for keeping the protocol consistent, = EXPIRY should determine the transition from P and M to NO_ENTRY. A PEER or MAP = mapping in the PCP-controlled device should be oblivious to TRAFIC (inbound or outbound):

 <= /span>

1.1. MAP mapping:

EXPIRY or a MAP Deletion Request should be the only causes of a MAP mapping = going to the NO_ENTRY state. I think the direct transition M -> I* should not = be possible.

 <= /span>

1.2. PEER mapping:

CLOSE_MSG or EXPIRY should be the only causes of a PEER mapping going to the = NO_ENTRY state. The direct transition P -> I* should not be = allowed.

 <= /span>

* The transitions M->I and P->I can happen if the mappings go = through the intermediate state NO_ENTRY and O-TRAFFIC is present. Of course that, if possible, the PCP Controlled device should keep the same previous (M or = P mapping’s) values of external address and external port in this = new I mapping.

 <= /span>

Best Regards,

 <= /span>

Felipe Miranda Costa

 

 

------_=_NextPart_001_01CCCA9D.10309475-- From rpenno@juniper.net Fri Jan 6 13:51: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 F00B021F8603 for ; Fri, 6 Jan 2012 13:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mwBZzlvRT7D for ; Fri, 6 Jan 2012 13:51:34 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 47FFF21F85CD for ; Fri, 6 Jan 2012 13:51:34 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTwds5YWYzGj9zhzUvZTTANLd+x13seh+@postini.com; Fri, 06 Jan 2012 13:51:34 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 6 Jan 2012 13:49:04 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 6 Jan 2012 16:49:03 -0500 From: Reinaldo Penno To: "pcp@ietf.org" Date: Fri, 6 Jan 2012 16:49:01 -0500 Thread-Topic: Clarification on THIRD_PARTY option Thread-Index: AczKMDVSiXhrn1XlRGawHgf5GZzvqgCjMrOG Message-ID: In-Reply-To: <0412136DF48FC94A9795E62ECFC014650E5F1231@008-AM1MPN1-013.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.11.0.110726 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pcp] Clarification on THIRD_PARTY option 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, 06 Jan 2012 21:51:35 -0000 The text in 19 says " A PCP client can delete all PCP-created explicit dynamic inbound mappings (i.e., those created by PCP MAP requests) that it is authorized to delete by sending a PCP MAP request including a zero- length THIRD_PARTY Option, zero in the Internal Port field, and zero in the Protocol field. " So, if a PCP client that has installed many third_party mappings wants to delete them all, the packet should look like below (napt-44)? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version =3D 1 |0| MAP | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | PCP Client's IP address (128 bits) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ::ffff:0:0 | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Code=3D1 | Reserved | Option Length=3D0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In other words, since third_party option length is zero, there will _no_ 12= 8 bit address in the delete request, correct? How would a PCP client that has installed many third_party requests delete = a specific one? If option length is zero, nothing can follow, if it is not zero, it is not a delete. Thanks, Reinaldo From dwing@cisco.com Fri Jan 6 14:38:23 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 9F45911E80BB for ; Fri, 6 Jan 2012 14:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.567 X-Spam-Level: X-Spam-Status: No, score=-106.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 VfwLFNOCqbIR for ; Fri, 6 Jan 2012 14:38:23 -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 7891321F8614 for ; Fri, 6 Jan 2012 14:38:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2966; q=dns/txt; s=iport; t=1325889500; x=1327099100; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=86q06vPg0WoBsb86ixaiMu/iTNO/yB0Sp6yF9VocdVI=; b=Co0XSYBLCPilI088uSgBKnMsK2vVhOFPxs/IVD8VJtngkvVDp9rLV7jM sK8JKj/ky355kmVM4/KUvI0YQ3RS7BHx8AiaGd7q1RjTKyy+bdQRUeY3I C/VkGuZdR29VW+AOP19CYf4iga8DbI+/K1c9l0Kb/cWtVRBI4l7rgUSCG w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAP52B0+rRDoH/2dsb2JhbABDnW6OVIEFgXIBAQEDAQEBAQUKARcQNBAHAQMCCQ4BAgQBASgHGQ4VCgkIAQEEARILF4dYCJgSAZ4HBIwRBIg5hHkBkHCJOg X-IronPort-AV: E=Sophos;i="4.71,470,1320624000"; d="scan'208";a="22505175" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 06 Jan 2012 22:38:19 +0000 Received: from dwingWS ([10.32.240.197]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q06McJMD010344; Fri, 6 Jan 2012 22:38:19 GMT From: "Dan Wing" To: "'Reinaldo Penno'" , References: <0412136DF48FC94A9795E62ECFC014650E5F1231@008-AM1MPN1-013.mgdnok.nokia.com> In-Reply-To: Date: Fri, 6 Jan 2012 14:38:19 -0800 Message-ID: <01aa01ccccc3$e385fd80$aa91f880$@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: AczKMDVSiXhrn1XlRGawHgf5GZzvqgCjMrOGAAGTeoA= Content-Language: en-us Subject: Re: [pcp] Clarification on THIRD_PARTY option 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, 06 Jan 2012 22:38:23 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Reinaldo Penno > Sent: Friday, January 06, 2012 1:49 PM > To: pcp@ietf.org > Subject: [pcp] Clarification on THIRD_PARTY option > > The text in 19 says > > " A PCP client can delete all PCP-created explicit dynamic inbound > mappings (i.e., those created by PCP MAP requests) that it is > authorized to delete by sending a PCP MAP request including a zero- > length THIRD_PARTY Option, zero in the Internal Port field, and zero > in the Protocol field. > " > > So, if a PCP client that has installed many third_party mappings wants > to > delete them all, the packet should look like below (napt-44)? > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version = 1 |0| MAP | 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | PCP Client's IP address (128 bits) | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0 | 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0 | 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | ::ffff:0:0 | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Option Code=1 | Reserved | Option Length=0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > In other words, since third_party option length is zero, there will > _no_ 128 > bit address in the delete request, correct? Right. > How would a PCP client that has installed many third_party requests > delete a > specific one? The MAP request would have Lifetime = 0, and the THIRD_PARTY option would have length 16 and the Internal IP Address of the third party host. -d > If option length is zero, nothing can follow, if it is not > zero, it is not a delete. > > Thanks, > > Reinaldo > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From rpenno@juniper.net Fri Jan 6 15:12: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 A4E0F21F876C for ; Fri, 6 Jan 2012 15:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMOSsX56vK7H for ; Fri, 6 Jan 2012 15:12:12 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 809B821F8769 for ; Fri, 6 Jan 2012 15:12:11 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTwd/y8EPA/inZPUfI0ZkrvCZy/WaUuPt@postini.com; Fri, 06 Jan 2012 15:12:12 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 6 Jan 2012 15:07:57 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 6 Jan 2012 18:07:56 -0500 From: Reinaldo Penno To: Dan Wing Date: Fri, 6 Jan 2012 18:07:48 -0500 Thread-Topic: [pcp] Clarification on THIRD_PARTY option Thread-Index: AczMyAaZ4oLnXnHkSbSQZi1kWHcDCA== Message-ID: <664F5523-347C-4278-A00E-CF51090F0678@juniper.net> References: <0412136DF48FC94A9795E62ECFC014650E5F1231@008-AM1MPN1-013.mgdnok.nokia.com> <01aa01ccccc3$e385fd80$aa91f880$@com> In-Reply-To: <01aa01ccccc3$e385fd80$aa91f880$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Clarification on THIRD_PARTY option 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, 06 Jan 2012 23:12:13 -0000 Sent from my iPhone On Jan 6, 2012, at 14:38, "Dan Wing" wrote: >> -----Original Message----- >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of >> Reinaldo Penno >> Sent: Friday, January 06, 2012 1:49 PM >> To: pcp@ietf.org >> Subject: [pcp] Clarification on THIRD_PARTY option >>=20 >> The text in 19 says >>=20 >> " A PCP client can delete all PCP-created explicit dynamic inbound >> mappings (i.e., those created by PCP MAP requests) that it is >> authorized to delete by sending a PCP MAP request including a zero- >> length THIRD_PARTY Option, zero in the Internal Port field, and zero >> in the Protocol field. >> " >>=20 >> So, if a PCP client that has installed many third_party mappings wants >> to >> delete them all, the packet should look like below (napt-44)? >>=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Version =3D 1 |0| MAP | 0 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 0 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> | PCP Client's IP address (128 bits) | >> | | >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 0 | 0 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 0 | 0 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> | ::ffff:0:0 | >> | | >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Option Code=3D1 | Reserved | Option Length=3D0 = | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >>=20 >> In other words, since third_party option length is zero, there will >> _no_ 128 >> bit address in the delete request, correct? >=20 > Right. >=20 >> How would a PCP client that has installed many third_party requests >> delete a >> specific one?=20 >=20 > The MAP request would have Lifetime =3D 0, and the THIRD_PARTY option > would have length 16 and the Internal IP Address of the third party > host. Hummm.. Then why do we need option length zero? For consistency to delete a= ll mappings we should have option length 16 and the 'all ip addresses' in t= he internal ip address.=20 Anyway, not a big deal but there seems to be two ways to delete all mapping= s.=20 >=20 > -d >=20 >> If option length is zero, nothing can follow, if it is not >> zero, it is not a delete. >>=20 >> Thanks, >>=20 >> Reinaldo >>=20 >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >=20 From rangan@cisco.com Tue Jan 10 06:57: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 8C2BD21F8758 for ; Tue, 10 Jan 2012 06:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlBKKerpVSJP for ; Tue, 10 Jan 2012 06:57:44 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 93ED321F873B for ; Tue, 10 Jan 2012 06:57:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rangan@cisco.com; l=67626; q=dns/txt; s=iport; t=1326207463; x=1327417063; h=mime-version:subject:date:message-id:references:from:to: cc; bh=z0J4x0ZthYS7nEWdOMXX5f+Jumh0+YEwH4DkV9KVn6s=; b=KbkrMxXTmVdmnebewmGbJ910VNPVk8DhRHiPkRLU4LAonVZnHtIMMK6t irGhcbGNgAnCpAuEdLF/Z46qquRV1lf3enkLaFKVQYP17aihoyYZ8y59e DvRJtwT6CFkiatpheOPJF6GQLST3nIBF7KbB2O7DaNNbJsG0aRNCcD3HO A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAJRDE+tJXHB/2dsb2JhbABDgk6qDIEFgXIBAQEEEgEJCwYDSRACAQgRBAEBCwYQAQYBBgFFCQgBAQQLCAgah2CYWwGeMYswYwSIOJ8W X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; d="scan'208,217";a="50024326" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 10 Jan 2012 14:57:42 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q0AEvO4D004115; Tue, 10 Jan 2012 14:57:41 GMT Received: from xmb-bgl-413.cisco.com ([72.163.129.209]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jan 2012 20:27:39 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: Ao7f AqvT AxC6 BVFy DOyD F0o9 HzWn KL9P LJAe MaIL NvI3 Nwz+ OY3i Ocae OmKi OtvQ; 2; ZQB4AHQALQBmAGUAbABpAHAAZQAuAG0ALgBjAG8AcwB0AGEAQABuAG8AawBpAGEALgBjAG8AbQA7AHAAYwBwAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {DF5594CE-8115-436E-9186-29E84B5C0830}; cgBhAG4AZwBhAG4AQABjAGkAcwBjAG8ALgBjAG8AbQA=; Tue, 10 Jan 2012 14:57:31 GMT; UgBFADoAIABPAG4AIAB0AGgAZQAgAFMAdABhAHQAZQAgAEQAaQBhAGcAcgBhAG0AIABvAGYAIABwAGMAcAAtAGIAYQBzAGUALQAxADkA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCCFA8.326F052A" x-cr-puzzleid: {DF5594CE-8115-436E-9186-29E84B5C0830} Content-class: urn:content-classes:message Date: Tue, 10 Jan 2012 20:27:31 +0530 Message-ID: <0C34754A9045B3419FB531A8C716E249071CAC6F@XMB-BGL-413.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: On the State Diagram of pcp-base-19 Thread-Index: AczKMDVSiXhrn1XlRGawHgf5GZzvqgAaZjzgAUNgBjA= References: <0412136DF48FC94A9795E62ECFC014650E5F1231@008-AM1MPN1-013.mgdnok.nokia.com> From: "Ranganathan T S (rangan)" To: "Dan Wing (dwing)" X-OriginalArrivalTime: 10 Jan 2012 14:57:39.0656 (UTC) FILETIME=[328E8C80:01CCCFA8] Cc: pcp@ietf.org Subject: Re: [pcp] On the State Diagram of pcp-base-19 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, 10 Jan 2012 14:57:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCCFA8.326F052A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dan et al, =20 Felipe and I discussed more on this topic offline. We felt that it is good to have the following note to the diagram in the next version.=20 =20 Note: Transition from state M to state I is implementation dependent =20 This is to take care of the I-D 'Second point' below to its fullest extent. If this is fine with you can you please update the diagram notes. =20 Thanks, Rangan. =20 From: Ranganathan T S (rangan)=20 Sent: Wednesday, January 04, 2012 10:25 AM To: 'ext-felipe.m.costa@nokia.com'; pcp@ietf.org Subject: RE: On the State Diagram of pcp-base-19 =20 Hi Felipe Miranda Costa, =20 Thanks for the review.=20 =20 First point: =20 The I-D mention the following for PEER here : =20 If a PEER-created or PEER-managed mapping is not renewed using PEER, then it reverts to the NAT's usual behavior for implicit mappings, e.g., continued outbound traffic keeps the mapping alive, as per the NAT or firewall device's existing policy. =20 =20 Second point: =20 The I-D mention the following for MAP here : =20 Mappings created by PCP MAP requests are not special or different from mappings created in other ways. In particular, it is implementation-dependent if outgoing traffic extends the lifetime of such mappings beyond the PCP-assigned lifetime. PCP clients MUST NOT depend on this behavior to keep mappings active, and MUST explicitly renew their mappings as required by the Lifetime field in PCP response messages. =20 Third point: =20 The paradigm I used to create the diagram is: * Give precedence to traffic compared to expiry.=20 * That is if traffic is still flowing when expiry happens, do not drop the sessions and let it end gracefully. =20 The diagram added to I-Dv19 satisfies all the above three points. =20 Thanks, Rangan. =20 From: ext-felipe.m.costa@nokia.com [mailto:ext-felipe.m.costa@nokia.com] Sent: Tuesday, January 03, 2012 9:29 PM To: pcp@ietf.org; Ranganathan T S (rangan) Subject: On the State Diagram of pcp-base-19 =20 Analyzing the current State-diagram in I-D v19 ( http://tools.ietf.org/html/draft-ietf-pcp-base-19#section-14.5 ) =20 CLOSE_MSGS or =20 (NO_TRAFFIC and EXPIRY) +---------+ NO_TRAFFIC and EXPIRY +------------>| |<------------+ | |NO_ENTRY | | | +---------| |---------+ | | | +---------+ | | | | ^ | | | | | NO_TRAFFIC | | | | | | or | | | | | | CLOSE_MSGS | | | | | | | | | | | | P-R | | M-R | | | V | | V | +---------+ | | +---------+ +-->| | | | M-R | |<--+ P-R | | P |---------|--|-------->| M | | M-R or +---| | | | | |---+ P-R or +---------+ | | +---------+ CLOSE_MSGS | ^ | | ^ | =20 | | P-R | | M-R | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | O-TRAFFIC | | | | | V | | =20 | | +---------+ | | =20 | +---------| |<--------+ | | | I | | +------------>| |<------------+ TRAFFIC and EXPIRY +---------+ TRAFFIC and EXPIRY =20 =20 I observed that, for example, if the mapping is in the M state and it expires, but the PCP-controlled=20 device has incoming traffic going through this mapping, the mapping transit from the M to the I state and continues to=20 receive this incoming traffic, which means that the control of the mapping is taken out from the PCP protocol and is=20 given to the remote host, that is generating this incoming data. =20 =20 Considering many aspects of the PCP I-D, IMHO a better diagram state would be: =20 =20 =20 CLOSE_MSGS or EXPIRY +---------+ EXPIRY or M-D-R +------------>| |<------------+ | |NO_ENTRY | | | +---------| |---------+ | | | +---------+ | | | | ^ | | | | | NO_TRAFFIC | | | | | | or | | | | | | CLOSE_MSGS | | | | | | | | | | | | P-R | | M-R | | | V | | V | +---------+ | | +---------+ +-->| | | | M-R | |<--+ P-R | | P |---------|--|-------->| M | | M-R or +---| | | | | |---+ P-R or +---------+ | | +---------+ CLOSE_MSGS ^ | | ^ =20 | P-R | | M-R | =20 | | | | =20 | | | | =20 | | | | =20 | | | | =20 | | | O-TRAFFIC | =20 | | V | =20 | +---------+ | =20 +---------| |<--------+ =20 | I | =20 | | +---------+ =20 =20 =20 where: M-D-R is a MAP deletion request =20 Observations: =20 1. TRAFFIC or NO_TRAFFIC shouldn't determine the transition from MAP (or PEER) mappings to other states. Instead, for keeping the protocol consistent, EXPIRY should determine the transition from P and M to NO_ENTRY. A PEER or MAP mapping in the PCP-controlled device should be oblivious to TRAFIC (inbound or outbound): =20 1.1. MAP mapping: EXPIRY or a MAP Deletion Request should be the only causes of a MAP mapping going to the NO_ENTRY state. I think the direct transition M -> I* should not be possible. =20 1.2. PEER mapping: CLOSE_MSG or EXPIRY should be the only causes of a PEER mapping going to the NO_ENTRY state. The direct transition P -> I* should not be allowed. =20 * The transitions M->I and P->I can happen if the mappings go through the intermediate state NO_ENTRY and O-TRAFFIC is present. Of course that, if possible, the PCP Controlled device should keep the same previous (M or P mapping's) values of external address and external port in this new I mapping. =20 Best Regards, =20 Felipe Miranda Costa =20 =20 ------_=_NextPart_001_01CCCFA8.326F052A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dan et al,

 

Felipe and I discussed more on this topic offline. We = felt that it is good to have the following note to the diagram in the next = version.

 

Note: Transition from state M to state =
I is implementation dependent

 

This is to take care of the I-D ‘Second = point’ below to its fullest extent. If this is fine with you can you please update = the diagram notes.

 

Thanks,

Rangan.

 

From:= = Ranganathan T S (rangan)
Sent: Wednesday, January 04, 2012 10:25 AM
To: 'ext-felipe.m.costa@nokia.com'; pcp@ietf.org
Subject: RE: On the State Diagram of = pcp-base-19

 

Hi Felipe Miranda Costa,

 

Thanks for the review.

 

First point:

 

The I-D mention the following for PEER h= ere:

 

   If a PEER-created or =
PEER-managed mapping is not renewed using PEER,

   then it reverts to the NAT's = usual behavior for implicit mappings,

   e.g., continued outbound traffic = keeps the mapping alive, as per the

   NAT or firewall device's = existing policy. 

 

Second point:

 

The I-D mention the following for MAP h= ere:

 

   Mappings created by PCP =
MAP requests are not
   special or different from =
mappings created in other ways.  In
   particular, it is =
implementation-dependent if outgoing traffic
   extends the lifetime of such =
mappings beyond the PCP-assigned
   lifetime.  PCP clients =
MUST NOT depend on this behavior to keep
   mappings active, and MUST =
explicitly renew their mappings as required
   by the Lifetime field in PCP =
response messages.

 

Third point:

 

The paradigm I used to create the diagram = is:

·         Give precedence to traffic compared to expiry. =

·         That is if traffic is still flowing when expiry happens, = do not drop the sessions and let it end gracefully.

 

The diagram added to I-Dv19 satisfies all the above three points.

 

Thanks,

Rangan.

 

From:= = ext-felipe.m.costa@nokia.com [mailto:ext-felipe.m.costa@nokia.com]
Sent: Tuesday, January 03, 2012 9:29 PM
To: pcp@ietf.org; Ranganathan T S (rangan)
Subject: On the State Diagram of = pcp-base-19

 

Analyzing the current State-diagram in I-D v19 ( h= ttp://tools.ietf.org/html/draft-ietf-pcp-base-19#section-14.5 )<= o:p>

 <= /span>

   =                CLOSE_MSGS or   =                 =   =

         (NO_TRAFFIC and EXPIRY) +---------+  NO_TRAFFIC and = EXPIRY=

         &= nbsp;         +------------>|         |<------------+

         &= nbsp;         |            = |NO_ENTRY = |            = |=

         &= nbsp;         |   = +---------|         |---------+   |

         &= nbsp;         |   |         +---------+         = |   |=

         &= nbsp;         |   |            = ^  |            = |   |=

         &= nbsp;         |   | NO_TRAFFIC |  |            = |   |=

         &= nbsp;         |   |         or = |  |            = |   |=

         &= nbsp;         |   | CLOSE_MSGS |  |            = |   |=

         &= nbsp;         |   |            = |  |            = |   |=

         &= nbsp;         |   | P-R        |  |         M-R |   = |=

         &= nbsp;         |   V            = |  |            = V   |=

         &= nbsp;      +---------+         |  |         = +---------+=

         &= nbsp;  +-->|         |         |  = |    M-R  |         = |<--+=

        P-R |   |    P    |---------|--|-------->|    M    = |   | M-R or=

         &= nbsp;  +---|         |         |  |         = |         |---+ P-R or=

         &= nbsp;      +---------+         |  |         = +---------+   CLOSE_MSGS=

         &= nbsp;         |   = ^            |  |            = ^   |              =

         &= nbsp;         |   | P-R        |  |         M-R |   = |=

         &= nbsp;         |   |            = |  |            = |   |=

         &= nbsp;         |   |            = |  |            = |   |=

         &= nbsp;         |   = |            |  |            = |   |=

         &= nbsp;         |   |            = |  |            = |   |=

         &= nbsp;         |   |            = |  | O-TRAFFIC   |   |

         &= nbsp;         |   |            = |  V            = |   |       =

         &= nbsp;         |   |         +---------+         = |   |            =  =

         &= nbsp;         |   +---------|         |<--------+   |

         &= nbsp;         |            = |    I    = |            = |=

         &= nbsp;         +------------>|         |<------------+

         &= nbsp;    TRAFFIC and EXPIRY +---------+  TRAFFIC and EXPIRY=

 <= /span>

 <= /span>

I observed that, for example, if the mapping is in the M state and it = expires, but the PCP-controlled 

device has incoming traffic going through this mapping, the mapping transit = from the M to the I state and continues to 

receive this incoming traffic, which means that the control of the mapping is = taken out from the PCP protocol and is 

given to the remote host, that is generating this incoming = data.

 <= /span>

 <= /span>

Considering many aspects of the PCP I-D, IMHO a better diagram state would = be:

 <= /span>

              =   

    =                       =               

           CLOSE_MSGS or EXPIRY =  +---------+ EXPIRY or M-D-R=

         &= nbsp;         +------------>|         |<------------+

         &= nbsp;         |            = |NO_ENTRY = |            = |=

         &= nbsp;         |   = +---------|         |---------+   |

         &= nbsp;         |   |         +---------+         = |   |=

         &= nbsp;         |   |            = ^  |            = |   |=

         &= nbsp;         |   | NO_TRAFFIC |  |            = |   |=

         &= nbsp;         |   |         or = |  |            = |   |=

         &= nbsp;         |   | CLOSE_MSGS |  |            = |   |=

         &= nbsp;         |   |            = |  |            = |   |=

         &= nbsp;         |   | P-R        |  |         M-R |   = |=

         &= nbsp;         |   V            = |  |            = V   |=

         &= nbsp;      +---------+         |  |         = +---------+=

         &= nbsp;  +-->|         |         |  = |    M-R  |         = |<--+=

        P-R |   |    P    |---------|--|-------->|    M    = |   | M-R or=

         &= nbsp;  +---|         |         |  |         = |         |---+ P-R or=

         &= nbsp;      +---------+         |  |         = +---------+   CLOSE_MSGS=

                       ^           = |  |            = ^               =   =

                      =  | P-R        |  |         M-R | =   =

                       |           = |  = |            = |   =

                       |           = |  |            = |   =

                       |           = |  |            = |   =

                       |           = |  |            = |   =

                       |           = |  | O-TRAFFIC   |   

                       |           = |  V            = |          

                       |         +---------+         |   =              

                       +---------|         |<--------+   

                      =            |    = I    |             

                      =            |         = |=

                      =            +---------+  =

         &n= bsp;           &nb= sp;           &n= bsp;       =                 =   

 <= /span>

where:<= /span>

M-D-R is a MAP deletion request

 <= /span>

Observations:=

 <= /span>

1. TRAFFIC or NO_TRAFFIC shouldn't determine the transition from MAP (or = PEER) mappings to other states. Instead, for keeping the protocol consistent, = EXPIRY should determine the transition from P and M to NO_ENTRY. A PEER or MAP = mapping in the PCP-controlled device should be oblivious to TRAFIC (inbound or outbound):

 <= /span>

1.1. MAP mapping:

EXPIRY or a MAP Deletion Request should be the only causes of a MAP mapping = going to the NO_ENTRY state. I think the direct transition M -> I* should not = be possible.

 <= /span>

1.2. PEER mapping:

CLOSE_MSG or EXPIRY should be the only causes of a PEER mapping going to the = NO_ENTRY state. The direct transition P -> I* should not be = allowed.

 <= /span>

* The transitions M->I and P->I can happen if the mappings go = through the intermediate state NO_ENTRY and O-TRAFFIC is present. Of course that, if possible, the PCP Controlled device should keep the same previous (M or = P mapping’s) values of external address and external port in this = new I mapping.

 <= /span>

Best Regards,

 <= /span>

Felipe Miranda Costa

 

 

------_=_NextPart_001_01CCCFA8.326F052A-- From dwing@cisco.com Tue Jan 10 08:34:15 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 DC12F21F8569 for ; Tue, 10 Jan 2012 08:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 4wkpIAA8+E8T for ; Tue, 10 Jan 2012 08:34:15 -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 F0BF521F8533 for ; Tue, 10 Jan 2012 08:34:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=8736; q=dns/txt; s=iport; t=1326213255; x=1327422855; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=IULXh7csJRkUSQ6YitgOYMtwsDn6v9/UyMbPDCC/n+0=; b=Ytq4bEiv0yOTUaNgmjNAprU6yoLNtaZaVWUre4ZY9dzDXTg3qJb8qGho dpePEfe5zdBKz8ZhXJxbgYRnrG719ptK+yQT0mQ7HreZWuixvGsONTGrb r1cHNDecydUN+ey0cuu+7anclxBYjmvmEB3EG7kuU2TB+/WNIP94DIVaT Q=; X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; d="scan'208";a="24570529" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 10 Jan 2012 16:34:14 +0000 Received: from dwingWS (rcdn-vpn-client-10-89-1-228.cisco.com [10.89.1.228]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0AGYDOa020405; Tue, 10 Jan 2012 16:34:13 GMT From: "Dan Wing" To: "'Ranganathan T S \(rangan\)'" References: <0412136DF48FC94A9795E62ECFC014650E5F1231@008-AM1MPN1-013.mgdnok.nokia.com> <0C34754A9045B3419FB531A8C716E249071CAC6F@XMB-BGL-413.cisco.com> In-Reply-To: <0C34754A9045B3419FB531A8C716E249071CAC6F@XMB-BGL-413.cisco.com> Date: Tue, 10 Jan 2012 08:34:13 -0800 Message-ID: <053a01cccfb5$b059b100$110d1300$@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: AczKMDVSiXhrn1XlRGawHgf5GZzvqgAaZjzgAUNgBjAAA5gDEA== Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] On the State Diagram of pcp-base-19 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, 10 Jan 2012 16:34:16 -0000 Ok. -d > -----Original Message----- > From: Ranganathan T S (rangan) [mailto:rangan@cisco.com] > Sent: Tuesday, January 10, 2012 6:58 AM > To: Dan Wing (dwing) > Cc: ext-felipe.m.costa@nokia.com; pcp@ietf.org > Subject: RE: On the State Diagram of pcp-base-19 > > Hi Dan et al, > > > > Felipe and I discussed more on this topic offline. We felt that it is > good to have the following note to the diagram in the next version. > > > > Note: Transition from state M to state I is implementation dependent > > > > This is to take care of the I-D 'Second point' below to its fullest > extent. If this is fine with you can you please update the diagram > notes. > > > > Thanks, > > Rangan. > > > > From: Ranganathan T S (rangan) > Sent: Wednesday, January 04, 2012 10:25 AM > To: 'ext-felipe.m.costa@nokia.com'; pcp@ietf.org > Subject: RE: On the State Diagram of pcp-base-19 > > > > Hi Felipe Miranda Costa, > > > > Thanks for the review. > > > > First point: > > > > The I-D mention the following for PEER here > : > > > > If a PEER-created or PEER-managed mapping is not renewed using PEER, > > then it reverts to the NAT's usual behavior for implicit mappings, > > e.g., continued outbound traffic keeps the mapping alive, as per the > > NAT or firewall device's existing policy. > > > > Second point: > > > > The I-D mention the following for MAP here > : > > > > Mappings created by PCP MAP requests are not > special or different from mappings created in other ways. In > particular, it is implementation-dependent if outgoing traffic > extends the lifetime of such mappings beyond the PCP-assigned > lifetime. PCP clients MUST NOT depend on this behavior to keep > mappings active, and MUST explicitly renew their mappings as > required > by the Lifetime field in PCP response messages. > > > > Third point: > > > > The paradigm I used to create the diagram is: > > . Give precedence to traffic compared to expiry. > > . That is if traffic is still flowing when expiry happens, do > not drop the sessions and let it end gracefully. > > > > The diagram added to I-Dv19 satisfies all the above three points. > > > > Thanks, > > Rangan. > > > > From: ext-felipe.m.costa@nokia.com [mailto:ext- > felipe.m.costa@nokia.com] > Sent: Tuesday, January 03, 2012 9:29 PM > To: pcp@ietf.org; Ranganathan T S (rangan) > Subject: On the State Diagram of pcp-base-19 > > > > Analyzing the current State-diagram in I-D v19 ( > http://tools.ietf.org/html/draft-ietf-pcp-base-19#section-14.5 ) > > > > CLOSE_MSGS or > > (NO_TRAFFIC and EXPIRY) +---------+ NO_TRAFFIC and EXPIRY > > +------------>| |<------------+ > > | |NO_ENTRY | | > > | +---------| |---------+ | > > | | +---------+ | | > > | | ^ | | | > > | | NO_TRAFFIC | | | | > > | | or | | | | > > | | CLOSE_MSGS | | | | > > | | | | | | > > | | P-R | | M-R | | > > | V | | V | > > +---------+ | | +---------+ > > +-->| | | | M-R | |<--+ > > P-R | | P |---------|--|-------->| M | | M-R or > > +---| | | | | |---+ P-R or > > +---------+ | | +---------+ > CLOSE_MSGS > > | ^ | | ^ | > > | | P-R | | M-R | | > > | | | | | | > > | | | | | | > > | | | | | | > > | | | | | | > > | | | | O-TRAFFIC | | > > | | | V | | > > | | +---------+ | | > > | +---------| |<--------+ | > > | | I | | > > +------------>| |<------------+ > > TRAFFIC and EXPIRY +---------+ TRAFFIC and EXPIRY > > > > > > I observed that, for example, if the mapping is in the M state and it > expires, but the PCP-controlled > > device has incoming traffic going through this mapping, the mapping > transit from the M to the I state and continues to > > receive this incoming traffic, which means that the control of the > mapping is taken out from the PCP protocol and is > > given to the remote host, that is generating this incoming data. > > > > > > Considering many aspects of the PCP I-D, IMHO a better diagram state > would be: > > > > > > > > CLOSE_MSGS or EXPIRY +---------+ EXPIRY or M-D-R > > +------------>| |<------------+ > > | |NO_ENTRY | | > > | +---------| |---------+ | > > | | +---------+ | | > > | | ^ | | | > > | | NO_TRAFFIC | | | | > > | | or | | | | > > | | CLOSE_MSGS | | | | > > | | | | | | > > | | P-R | | M-R | | > > | V | | V | > > +---------+ | | +---------+ > > +-->| | | | M-R | |<--+ > > P-R | | P |---------|--|-------->| M | | M-R or > > +---| | | | | |---+ P-R or > > +---------+ | | +---------+ > CLOSE_MSGS > > ^ | | ^ > > | P-R | | M-R | > > | | | | > > | | | | > > | | | | > > | | | | > > | | | O-TRAFFIC | > > | | V | > > | +---------+ | > > +---------| |<--------+ > > | I | > > | | > > +---------+ > > > > > > where: > > M-D-R is a MAP deletion request > > > > Observations: > > > > 1. TRAFFIC or NO_TRAFFIC shouldn't determine the transition from MAP > (or PEER) mappings to other states. Instead, for keeping the protocol > consistent, EXPIRY should determine the transition from P and M to > NO_ENTRY. A PEER or MAP mapping in the PCP-controlled device should be > oblivious to TRAFIC (inbound or outbound): > > > > 1.1. MAP mapping: > > EXPIRY or a MAP Deletion Request should be the only causes of a MAP > mapping going to the NO_ENTRY state. I think the direct transition M -> > I* should not be possible. > > > > 1.2. PEER mapping: > > CLOSE_MSG or EXPIRY should be the only causes of a PEER mapping going > to the NO_ENTRY state. The direct transition P -> I* should not be > allowed. > > > > * The transitions M->I and P->I can happen if the mappings go through > the intermediate state NO_ENTRY and O-TRAFFIC is present. Of course > that, if possible, the PCP Controlled device should keep the same > previous (M or P mapping's) values of external address and external > port in this new I mapping. > > > > Best Regards, > > > > Felipe Miranda Costa > > > > From internet-drafts@ietf.org Tue Jan 10 09:23: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 6E91A21F87A2; Tue, 10 Jan 2012 09:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 wIqSBKES3lTA; Tue, 10 Jan 2012 09:23:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC0121F879C; Tue, 10 Jan 2012 09:23:09 -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: <20120110172309.8986.72109.idtracker@ietfa.amsl.com> Date: Tue, 10 Jan 2012 09:23:09 -0800 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-base-20.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: Tue, 10 Jan 2012 17:23:09 -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-20.txt Pages : 90 Date : 2012-01-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-20.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-20.txt From internet-drafts@ietf.org Thu Jan 12 16:47: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 03F2421F869F; Thu, 12 Jan 2012 16:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 xo1vwXWtE34M; Thu, 12 Jan 2012 16:47:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1E721F865F; Thu, 12 Jan 2012 16:47:08 -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: <20120113004708.3426.53628.idtracker@ietfa.amsl.com> Date: Thu, 12 Jan 2012 16:47:08 -0800 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-base-21.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, 13 Jan 2012 00:47:09 -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-21.txt Pages : 91 Date : 2012-01-12 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-21.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-21.txt From dwing@cisco.com Thu Jan 12 18:11: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 36F5321F8589 for ; Thu, 12 Jan 2012 18:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.57 X-Spam-Level: X-Spam-Status: No, score=-106.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 pV8wpEJRh31y for ; Thu, 12 Jan 2012 18:11:12 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id CC35021F854A for ; Thu, 12 Jan 2012 18:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=864; q=dns/txt; s=iport; t=1326420672; x=1327630272; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=eN9xAJUnQhlOIuz+aHgUM1zmwp427s5hI4/bfA5GW9A=; b=RRziXa6INRl2YbkCp7mU+6nrHEa0tod7ly4FWMPDLMyQaA4zNq1VEadw jXaW+pIUFphUOm2InQYSSwVAm50TbFA137cRQEswwjsKDLJYtBOWagvy7 YgGkoZLQpkWSWLLacAJ8Hd1MzHVOowHzaIEVviqE9N0+ZtJTj0INndbvN A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAJCRD0+rRDoI/2dsb2JhbABDnjmOV4EFgXkICgEXED8NBRhQIxwBBB4Xh2CZDAGeEYkBgxwEiDuEfpoy X-IronPort-AV: E=Sophos;i="4.71,502,1320624000"; d="scan'208";a="25190250" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 13 Jan 2012 02:11:09 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0D2B8YP027644; Fri, 13 Jan 2012 02:11:08 GMT From: "Dan Wing" To: Date: Thu, 12 Jan 2012 18:11:08 -0800 Message-ID: <022101ccd198$9d049860$d70dc920$@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: AczRmJy79syFl1+GRnK5mH8JlXawbw== Content-Language: en-us Cc: pcp-chairs@tools.ietf.org, draft-ietf-pcp-base@tools.ietf.org Subject: [pcp] draft-ietf-pcp-base-21 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, 13 Jan 2012 02:11:13 -0000 draft-ietf-pcp-base-21 integrates feedback we received during WGLC and the changes from -20 are summarized in http://tools.ietf.org/html/draft-ietf-pcp-base-21#appendix-B.1, B.1. Changes from draft-ietf-pcp-base-20 to -21 o To delete all mappings using THIRD_PARTY, use the all-zeros IP address (rather than previous text which used length=0). o added normative text for what PCP server does when it receives all-zeros IP address in THIRD_PARTY option. o PREFER_FAILURE allowed for use by web portal. o clarifications to mandatory option processing. o cleanup and wordsmithing of the THIRD_PARTY text. Side-by-side diffs between -20 and -21 are at http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcp-base-21.txt. The authors believe this version closes all open issues raised during WGLC. -d From mohamed.boucadair@orange.com Thu Jan 12 22:43:34 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 0197421F867B for ; Thu, 12 Jan 2012 22:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvOOc7PIVtw4 for ; Thu, 12 Jan 2012 22:43:33 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9545E21F84E4 for ; Thu, 12 Jan 2012 22:43:32 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 52DEB18C28D for ; Fri, 13 Jan 2012 07:43:31 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 80B234C024 for ; Fri, 13 Jan 2012 07:43:30 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Fri, 13 Jan 2012 07:43:30 +0100 From: To: "pcp@ietf.org" Date: Fri, 13 Jan 2012 07:43:29 +0100 Thread-Topic: Comments on draft-ietf-pcp-dhcp-01.txt Thread-Index: AcysdorgJ1/N04vFQYCYPpdA0PrYTgBNQpDAABD75DAAAAYS4AAdoazgABZFVCAAAD2V4AAbzlLQABb4V2AAH2c2UAhtY3gA Message-ID: <94C682931C08B048B7A8645303FDC9F35AAAFC4F35@PUEXCB1B.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B32F30F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F35A8CCD5155@PUEXCB1B.nanterre.francetelecom.fr> <9B57C850BB53634CACEC56EF4853FF653B330BAB@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F35A8D050A9A@PUEXCB1B.nanterre.francetelecom.fr> <9B57C850BB53634CACEC56EF4853FF653B3348CB@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B334967@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F35A8D050E84@PUEXCB1B.nanterre.francetelecom.fr> <9B57C850BB53634CACEC56EF4853FF653B336D8D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F35A8D051375@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F35A8D051375@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.1.12.220023 Subject: Re: [pcp] Comments on draft-ietf-pcp-dhcp-01.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, 13 Jan 2012 06:43:34 -0000 Dear all, Since no comment has been received about this text, I will implement the ch= anges. I will submit an updated version in few minutes. Cheers, Med=20 > -----Message d'origine----- > De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 > part de mohamed.boucadair@orange.com > Envoy=E9 : jeudi 1 d=E9cembre 2011 10:16 > =C0 : Dave Thaler > Cc : pcp@ietf.org > Objet : Re: [pcp] Comments on draft-ietf-pcp-dhcp-01.txt >=20 > Dear Dave, >=20 > Below the text I added to the draft. Please review it: >=20 >=20 > (1) added a new section: >=20 > 5. IP Address Selection >=20 > Resolving the Name conveyed in DHCP PCP Name options may return a > list of IP addresses. This section specifies the behavior to be > followed by the PCP Client to contact its PCP Server. >=20 > 1. If only one PCP Name option is returned in DHCP: the PCP Client > follows the procedure specified in Section 5.1 if a list of IP > addresses are returned as a result of resolving the=20 > name conveyed > in the PCP Name DHCP option. > 2. If several PCP Name options are returned in DHCP: the=20 > PCP Client > contacts in parallel all PCP Servers as defined in Section 5.2. > For each PCP Name option occurrence, the PCP Client=20 > resolves the > conveyed name; if more than one IP address are=20 > returned, the PCP > Client follows the procedure specified in Section 5.1. >=20 > 5.1. Serial Queries >=20 > The PCP Client initializes its retransmission timer,=20 > RETRY_TIMER, to > 2 seconds. The PCP Client sends its PCP message to the PCP Server > and waits 2 seconds for a response. If no response is received, it > doubles the value of RETRY_TIMER, sends another (identical) PCP > message and waits 2*RETRY_TIMER. This procedure is repeated three > (3) times, doubling the value of RETRY_TIMER each time. If no > response is received after four (4) attempts, the PCP Client tries > with the next IP address in its list of PCP Servers. If it has > exhausted its list, the procedure is repeated every fifteen minutes > until the PCP request is successfully answered. If, when=20 > sending PCP > requests the PCP Client receives an ICMP error (e.g., port > unreachable, network unreachable) it SHOULD immediately=20 > try the next > IP address in the list. Once the PCP Client has successfully > received a response from a PCP Server on that interface, it sends > subsequent PCP requests to that same server until that PCP Server > becomes non-responsive, which causes the PCP client to=20 > attempt to re- > iterate the procedure starting with the first PCP Server=20 > on its list. >=20 > 5.2. Parallel Queries >=20 > The PCP Client contacts in parallel all the PCP Servers in the IP > addresses list. For each IP address in the list, the PCP Client > follows the procedure specified in Section 7.1 of > [I-D.ietf-pcp-base]. >=20 >=20 >=20 > (2) I tweaked the Client text behavior: >=20 > NEW: >=20 > To discover a PCP Server [I-D.ietf-pcp-base], the DHCPv6=20 > client MUST > include an Option Request Option (ORO) requesting the DHCPv6 PCP > Server Name option as described in Section 22.7 of [RFC3315] (i.e., > include OPTION_PCP_SERVER on its OPTION_ORO). A client MAY also > include the OPTION_DNS_SERVERS option on its OPTION_ORO to=20 > retrieve a > DNS servers list. >=20 > If the DHCPv6 client receives more than one=20 > OPTION_PCP_SERVER option > from the DHCPv6 server, it extracts the Name conveyed in each > OPTION_PCP_SERVER option and proceeds to validating it. =20 > If more than > one Name is included in a OPTION_PCP_SERVER option occurrence, only > the first instance MUST be used. Then, The DHCPv6 client=20 > MUST verify > that the option length does not exceed 255 octets [RFC1035]). The > DHCPv6 client MUST verify the name is properly encoded as=20 > detailed in > Section 8 of [RFC3315]. >=20 > Once the name conveyed in each OPTION_PCP_SERVER option is=20 > validated, > the included Name is passed to the name resolution library (e.g., > Section 6.1.1 of [RFC1123] or [RFC6055]) to retrieve the > corresponding IP address(es) (IPv4 or IPv6). >=20 > Then, the PCP Client follows the procedure specified in=20 > Section 5 to > contact its PCP Server(s). >=20 > It is RECOMMENDED to associate a TTL with any address=20 > resulting from > resolving the Name conveyed in a OPTION_PCP_SERVER DHCPv6=20 > option when > stored in a local cache. Considerations on how to flush=20 > out a local > cache are out of the scope of this document. >=20 > A host may have multiple network interfaces (e.g, 3G, WiFi, etc.); > each configured differently. Each PCP Server learned MUST be > associated with the interface via which it was learned. When an > application issues a PCP request to a PCP Server, the=20 > source address > of the request MUST be among those assigned on the=20 > interface to which > the destination PCP Server is bound. Means to bind a PCP Name > configuration to a given interface in a multiple-interface host are > out of scope of this document. >=20 > OLD: >=20 > To discover a PCP Server [I-D.ietf-pcp-base], the DHCPv6=20 > client MUST > include an Option Request Option (ORO) requesting the DHCPv6 PCP > Server Name option as described in Section 22.7 of [RFC3315] (i.e., > include OPTION_PCP_SERVER on its OPTION_ORO). A client MAY also > include the OPTION_DNS_SERVERS option on its OPTION_ORO to=20 > retrieve a > DNS servers list. >=20 > If the DHCPv6 client receives more than one=20 > OPTION_PCP_SERVER option > from the DHCPv6 server, only the first instance of that option MUST > be used. >=20 > Upon receipt of an OPTION_PCP_SERVER option, the DHCPv6 client MUST > verify that the option length does not exceed 255 octets=20 > [RFC1035]). > The DHCPv6 client MUST verify the name is properly encoded as > detailed in Section 8 of [RFC3315]. >=20 > Once the name conveyed in a OPTION_PCP_SERVER option is validated, > the included Name is passed to the name resolution library (e.g., > Section 6.1.1 of [RFC1123] or [RFC6055]) to retrieve the > corresponding IP address (IPv4 or IPv6). If more than one=20 > IPv6/IPv4 > address are retrieved, the PCP Client MUST use the=20 > procedure defined > in Section 5.1 for address selection. >=20 > It is RECOMMENDED to associate a TTL with any address=20 > resulting from > resolving the Name conveyed in a OPTION_PCP_SERVER DHCPv6=20 > option when > stored in a local cache. Considerations on how to flush=20 > out a local > cache are out of the scope of this document. >=20 > A host may have multiple network interfaces (e.g, 3G, WiFi, etc.); > each configured differently. Each PCP Server learned MUST be > associated with the interface via which it was learned. When an > application issues a PCP request to a PCP Server, the=20 > source address > of the request MUST be among those assigned on the=20 > interface to which > the destination PCP Server is bound. Means to bind a PCP Name > configuration to a given interface in a multiple-interface host are > out of scope of this document. >=20 >=20 >=20 >=20 >=20 > =20 >=20 > > -----Message d'origine----- > > De : Dave Thaler [mailto:dthaler@microsoft.com]=20 > > Envoy=E9 : mercredi 30 novembre 2011 19:22 > > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP > > Cc : pcp@ietf.org > > Objet : RE: Comments on draft-ietf-pcp-dhcp-01.txt > >=20 > > > I don't see much difference between PEER and MAP for the=20 > PCP Server > > > discovery. As I said earlier, we have cases where you need=20 > > to try all servers > > > (e.g., FW, NAT64, NPTv6); this is orthogonal to MAP or PEER. > >=20 > > I don't follow. PEER is with respect to a specific=20 > > connection (5-tuple). > >=20 > > I'm having trouble finding which message you refer to as=20 > > "said earlier", > > so would be good if you could repeat when you'd want to send a PEER > > for a single 5-tuple to all servers. > >=20 > > (And proposing text to be added in the document would be even=20 > > better...) > >=20 > > -Dave > >=20 > >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > = From internet-drafts@ietf.org Thu Jan 12 22:48:12 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 EC44721F86C1; Thu, 12 Jan 2012 22:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 USImDXpG2KNp; Thu, 12 Jan 2012 22:48:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9178621F84EF; Thu, 12 Jan 2012 22:48:12 -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: <20120113064812.18020.87603.idtracker@ietfa.amsl.com> Date: Thu, 12 Jan 2012 22:48:12 -0800 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-dhcp-02.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, 13 Jan 2012 06:48:13 -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 : DHCP Options for the Port Control Protocol (PCP) Author(s) : Mohamed Boucadair Reinaldo Penno Dan Wing Filename : draft-ietf-pcp-dhcp-02.txt Pages : 11 Date : 2012-01-12 This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) Server addresses. The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenario. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcp-dhcp-02.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-dhcp-02.txt From mohamed.boucadair@orange.com Thu Jan 12 23:08: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 D3C6021F86AD for ; Thu, 12 Jan 2012 23:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8seS-Wv5fMvS for ; Thu, 12 Jan 2012 23:08:35 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 28AF721F85D7 for ; Thu, 12 Jan 2012 23:08:35 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 876832DC42E for ; Fri, 13 Jan 2012 08:08:34 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 6CA184C071 for ; Fri, 13 Jan 2012 08:08:34 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Fri, 13 Jan 2012 08:08:34 +0100 From: To: "pcp@ietf.org" Date: Fri, 13 Jan 2012 08:08:31 +0100 Thread-Topic: [pcp] I-D Action: draft-ietf-pcp-dhcp-02.txt Thread-Index: AczRv1zjTyyG9/78ToevIgfZepnMAAAAdTDQ Message-ID: <94C682931C08B048B7A8645303FDC9F35AAAFC4F3F@PUEXCB1B.nanterre.francetelecom.fr> References: <20120113064812.18020.87603.idtracker@ietfa.amsl.com> In-Reply-To: <20120113064812.18020.87603.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.30.163314 Subject: Re: [pcp] I-D Action: draft-ietf-pcp-dhcp-02.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, 13 Jan 2012 07:08:35 -0000 Dear WG members, This updated version integrates the comments received from D. Thaler: http:= //www.ietf.org/mail-archive/web/pcp/current/msg01793.html. * Clarify the meaning of "name" and remove any occurrence of FQDN * Specify how to select an IP address among a list * Add some text on multi-interface=20 * Correct some typos and minor editing A diff is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp= -dhcp-02. I think this version is ready for a WG LC. Cheers, Med > -----Message d'origine----- > De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 > part de internet-drafts@ietf.org > Envoy=E9 : vendredi 13 janvier 2012 07:48 > =C0 : i-d-announce@ietf.org > Cc : pcp@ietf.org > Objet : [pcp] I-D Action: draft-ietf-pcp-dhcp-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. This draft is a work item of the=20 > Port Control Protocol Working Group of the IETF. >=20 > Title : DHCP Options for the Port Control=20 > Protocol (PCP) > Author(s) : Mohamed Boucadair > Reinaldo Penno > Dan Wing > Filename : draft-ietf-pcp-dhcp-02.txt > Pages : 11 > Date : 2012-01-12 >=20 > This document specifies DHCP (IPv4 and IPv6) options to configure > hosts with Port Control Protocol (PCP) Server addresses. =20 > The use of > DHCPv4 or DHCPv6 depends on the PCP deployment scenario. >=20 >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pcp-dhcp-02.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcp-dhcp-02.txt >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > = From dthaler@microsoft.com Fri Jan 13 17:29:25 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 B801021F84B6 for ; Fri, 13 Jan 2012 17:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.883 X-Spam-Level: X-Spam-Status: No, score=-103.883 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCPWxivxsBoM for ; Fri, 13 Jan 2012 17:29:23 -0800 (PST) Received: from AM1EHSOBE002.bigfish.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id E106121F84B5 for ; Fri, 13 Jan 2012 17:29:22 -0800 (PST) Received: from mail65-am1-R.bigfish.com (10.3.201.249) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Sat, 14 Jan 2012 01:29:21 +0000 Received: from mail65-am1 (localhost [127.0.0.1]) by mail65-am1-R.bigfish.com (Postfix) with ESMTP id 975CA540168; Sat, 14 Jan 2012 01:29:21 +0000 (UTC) X-SpamScore: -6 X-BigFish: VS-6(zzc85fh1432Nzz1202hzz8275bh8275dhz2fhc1ahc1bhc1ahc1bh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-FB-SS: 0,0, Received-SPF: pass (mail65-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail65-am1 (localhost.localdomain [127.0.0.1]) by mail65-am1 (MessageSwitch) id 1326504561292242_30017; Sat, 14 Jan 2012 01:29:21 +0000 (UTC) Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.243]) by mail65-am1.bigfish.com (Postfix) with ESMTP id 3EC16180076; Sat, 14 Jan 2012 01:29:21 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 14 Jan 2012 01:29:21 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.2.247.5; Fri, 13 Jan 2012 17:29:19 -0800 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.90]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.01.0355.003; Fri, 13 Jan 2012 17:29:18 -0800 From: Dave Thaler To: Dan Wing Thread-Topic: Document shepherd re-review of draft-ietf-pcp-base-21 Thread-Index: AczSWv2FQpQmUSTARBS6IlnxG4355A== Date: Sat, 14 Jan 2012 01:29:18 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B38D97A@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF653B38D97ATK5EX14MBXW603w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "pcp@ietf.org" , "pcp-chairs@tools.ietf.org" , "draft-ietf-pcp-base@tools.ietf.org" Subject: [pcp] Document shepherd re-review of draft-ietf-pcp-base-21 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, 14 Jan 2012 01:29:25 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653B38D97ATK5EX14MBXW603w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I did a re-review of -21 since the doc shepherd has to sign off on reviewing "this version" (i.e. the final version submitted to the IESG) in the proto writeup... Section 9: > of this knowledge to decide to which of its PCP servers to send the > request (e.g., a PCP server on its IPv4 interface or its IPv6 > interface), The above implies an atypical model where IPv4 and IPv6 are on separate "interfaces". The normal (per various RFCs and implementations) model puts them both on the same interface. Suggest: > of this knowledge to decide to which of its PCP server addresses to send = the > request (e.g., an IPv4 address or an IPv6 address), Similarly in > If the PCP client has both > an IPv4 and IPv6 address, and only wants an IPv4 listener, it sends > one MAP request from its IPv4 interface (if the PCP server supports > NAT44 or IPv4 firewall) or one MAP request from its IPv6 interface > (if the PCP server supports NAT64)). s/interface/address/ (two occurrences) As worded it doesn't make sense to some readers. I hadn't noticed this before but in 12.3: > For IPv4 addresses, which are > represented using the IPv4-mapped address format (::FFFF:0:0/96), the > value of the Prefix Length pertains only to the IPv4 portion of the > address. Thus, a Prefix Length of 32 with an IPv4-mapped address > indicates "only this address". With IPv4-mapped addresses, the > minimum Prefix length value is 0 and the maximum is 32; for IPv6 > addresses the minimum value is 0 and the maximum is 128. I personally find the above *really* ugly. I had expected the change for I= Pv4-mapped addrs to also change the prefix length to be consistent with what one would= expect with IPv4-mapped addrs (max is 128 in both cases and starts from the beginn= ing of the field). I can't say the spec is "broken" though, just annoying to implement this wa= y and inconsistent with other RFCs, so maybe we have to just live with it? Section 16.3.1 typo: An attacker, on the path between the PCP client and PCP server, can drop PCP requests, drop PCP responses, or spoof a PCP error, all of which will effective deny service. Through such actions, the PCP client might not be aware the PCP server might have actually processed the PCP request. s/effective/effectively/ The last sentence quoted actually *vastly* understates the residual vulnera= bility. In an earlier review last year I stated "Another DOS vector is via spoofing a SERVER_OVERLOADED response and sending it to a victim." Now SERVER_OVERLOADED is called NO_RESOURCES, and the effect is (from 7.3): If the result code is NO_RESOURCES, PCP client SHOULD NOT send *any* further requests of any kind to that PCP server for the indicated error lifetime. So the effect is not just that the request might have succeeded unbeknownst to the client, but that an attacker can prevent the PCP client from sending *any* future requests at all to that server (the attacker can use the maximum lifetime which is well over 100 years). Suggest adding after the paragraph in 16.3.1 quoted above (the one with the typo): > The PCP client might also be unable to send any further requests of any > kind to that PCP server. Also fyi the RFC editor pass will make the following sort of changes... Section 2.2 uses non-well-known (as defined by the RFC style manual) acronyms like SCTP and DCCP and those will be expanded on first use, and probably informational references added. Optionally you could do these yourself before the RFC editor asks you to verify their changes. -Dave --_000_9B57C850BB53634CACEC56EF4853FF653B38D97ATK5EX14MBXW603w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I did a re-review of -21 since the doc shepherd h= as to sign off

on reviewing “this version” (i.e. the= final version submitted

to the IESG) in the proto writeup…

 

Section 9:

> of this knowledge to decide to which of its = PCP servers to send the 

> request (e.g., a PCP server on its IPv4 inte= rface or its IPv6 

> interface), 

 

The above implies an atypical model where IPv4 an= d IPv6 are on

separate "interfaces".  The normal= (per various RFCs and

implementations) model puts them both on the same= interface.

Suggest:

> of this knowledge to decide to which of its = PCP server addresses to send the 

> request (e.g., an IPv4 address or an IPv6 ad= dress),

 

Similarly in

> If the PCP client has both  =

> an IPv4 and IPv6 address, and only wants an = IPv4 listener, it sends 

> one MAP request from its IPv4 interface (if the PCP server supports 

> NAT44 or IPv4 firewall) or one MAP request f= rom its IPv6 interface&nbs= p;

> (if the PCP server supports NAT64)). &n= bsp;

 

s/interface/address/  (two occurrences)=

 

As worded it doesn’t make sense to some rea= ders.

 

I hadn’t noticed this before but in 12.3:

> For IPv4 addresses, which are

> represented using the IPv4-mapped address format (::FF= FF:0:0/96), the

> value of the Prefix Length pertains only to the IPv4 p= ortion of the

> address.  Thus, a Prefix Length of 32 with an IPv= 4-mapped address

> indicates "only this address".  With IP= v4-mapped addresses, the

> minimum Prefix length value is 0 and the maximum is 32= ; for IPv6

> addresses the minimum value is 0 and the maximum is= 128.

 

I personally find the above *really* ugly.=   I had expected the change for IPv4-mapped

addrs to also change the prefix length to be cons= istent with what one would expect

with IPv4-mapped addrs (max is 128 in both cases = and starts from the beginning

of the field).

 

I can’t say the spec is “broken”= ; though, just annoying to implement this way and

inconsistent with other RFCs, so maybe we have to= just live with it?

 

Section 16.3.1 typo:

   An attacker, on the path between the PCP client and PCP s=
erver, can
   drop PCP requests, drop PCP responses, or spoof a PCP err=
or, all of
   which will effective deny service.  Through such actions, the PCP=

   client might not be aware the PCP server might have actua=
lly
   processed the PCP request.

 

s/effective/effectively/

 

The last sentence quoted actually *vastly*= understates the residual vulnerability.

In an earlier review last year I stated “An= other DOS vector is via spoofing

a SERVER_OVERLOADED response and sending it to a = victim.”

Now SERVER_OVERLOADED is called NO_RESOURCES, and= the effect is (from 7.3):

   If the result code
   is NO_RESOURCES, PCP clie=
nt SHOULD NOT send *any* further requests of

   any kind to that PCP server for the indicat= ed error lifetime.

 

So the effect is not just that the request might = have succeeded unbeknownst

to the client, but that an attacker can prevent t= he PCP client from sending

*any* future requests at all to that serve= r (the attacker can use the

maximum lifetime which is well over 100 years).&n= bsp;  Suggest adding after the

paragraph in 16.3.1 quoted above (the one with th= e typo):

 

> The PCP client might also be unable to send any fur= ther requests of any

> kind to that PCP server.  

 

Also fyi the RFC editor pass will make the follow= ing sort of changes…

Section 2.2 uses non-well-known (as defined by th= e RFC style manual)

acronyms like SCTP and DCCP and those will be exp= anded on first use,

and probably informational references added. = ;  Optionally you could

do these yourself before the RFC editor asks you = to verify their changes.

 

-Dave

 

--_000_9B57C850BB53634CACEC56EF4853FF653B38D97ATK5EX14MBXW603w_-- From flaviofilho@hotmail.com Tue Jan 17 12:58:36 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 A686F11E80C3 for ; Tue, 17 Jan 2012 12:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.439 X-Spam-Level: X-Spam-Status: No, score=-0.439 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 eqBMdOxnCfPI for ; Tue, 17 Jan 2012 12:58:36 -0800 (PST) Received: from snt0-omc3-s50.snt0.hotmail.com (snt0-omc3-s50.snt0.hotmail.com [65.54.51.87]) by ietfa.amsl.com (Postfix) with ESMTP id E626821F8685 for ; Tue, 17 Jan 2012 12:58:35 -0800 (PST) Received: from SNT107-W4 ([65.55.90.136]) by snt0-omc3-s50.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Jan 2012 12:58:35 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_4b33a493-cd82-464d-89e1-98917fec0677_" X-Originating-IP: [189.2.128.130] From: =?iso-8859-1?B?RmzhdmlvIE1vbnRlbmVncm8gRmlsaG8=?= To: Date: Tue, 17 Jan 2012 17:58:34 -0300 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jan 2012 20:58:35.0007 (UTC) FILETIME=[C70B20F0:01CCD55A] Subject: [pcp] Protocols: 16-bit port number 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, 17 Jan 2012 20:58:36 -0000 --_4b33a493-cd82-464d-89e1-98917fec0677_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everyone! I am implementing a PCP Client and I have a doubt regarding the following p= art of the PCP I-D:=20 9.2 Generanting a MAP Request If the Protocol does not use 16-bit port numbers (e.g.=2C RSVP)=2C the port number MUST be 0. This will cause all traffic matching that protocol to be mapped. The document refers RSVP as an example of protocol which does not use 16-bi= t port number=2C but I am not sure about other protocols besides RSVP. Only TCP=2C UDP=2C UDP LITE=2C SCTP and DCCP [http://tools.ietf.org/html/rf= c6335#section-6] use 16-bit port numbers? Can anyone help me by pointing ot= her protocols which do not use 16-bit port numbers? Best Regards =20 Fl=E1vio Augusto Carvalho Montenegro Filho=20 flaviofilho@hotmail.com = --_4b33a493-cd82-464d-89e1-98917fec0677_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi everyone!

I am implementing a PCP Client and I have a doubt r= egarding the following part of the PCP I-D:

9.2 Generanting a MAP R= equest

   If the Protocol does not use 16-bit port numbers (e.g=
.=2C RSVP)=2C the
   port number MUST be 0.  This will cause all traffic matching that
   protocol to be mapped.

The document refers RSVP as an example of protocol which does not use 1= 6-bit port number=2C but I am not sure about other protocols besides RSVP.<= br>Only TCP=2C UDP=2C UDP LITE=2C SCTP and DCCP [http://tools.ietf.org/html= /rfc6335#section-6] use 16-bit port numbers? Can anyone help me by pointing= other protocols which do not use 16-bit port numbers?

Best Regards<= br>
 =3B
Fl=E1vio Augusto Carvalho Montenegro Filho
flaviofilho@hotmai= l.com
= --_4b33a493-cd82-464d-89e1-98917fec0677_-- From dwing@cisco.com Tue Jan 17 19:07: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 3CB5111E80A3 for ; Tue, 17 Jan 2012 19:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.423 X-Spam-Level: X-Spam-Status: No, score=-106.423 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 FC085gSEtcVq for ; Tue, 17 Jan 2012 19:07:31 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF8C11E8083 for ; Tue, 17 Jan 2012 19:07:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1918; q=dns/txt; s=iport; t=1326856051; x=1328065651; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=3D+dyrUXGb0CeNQr7u5a/KAfTh28q4Mhi0hgR1EGMtY=; b=A5wpStcAp3wQ2akHUVn/CHezBqNPk8frkPEVBsoMkpIfnWUWip1xn4qw zxw3s6dA8968kt9ebN6bD9jxtTBPlfeubWhemvksw8oSyQK+eQO/doUx1 vCxD6QIXTJqMgRvkO30wUnD1E7ZqeMVeF1i74QXyuU0rQaZfBwX/KcVk+ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAEY2Fk+rRDoH/2dsb2JhbABEnniNTIEGgQWBcgEBAQQICgEXWwEDAgkPAgQBASgHGSMKCQgBAQQBEgkCF4dgmQUBnl2Icw0BBAIBAQEDAQQBAQEKAgIBAQMFMwIBAQsPCgEbBxYQAQIBAQUDAQEBAQIBAQGDAlcWAQEBAoMqBIgIM4R/mjk X-IronPort-AV: E=Sophos;i="4.71,527,1320624000"; d="scan'208";a="25915412" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 18 Jan 2012 03:07:31 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q0I37VkO032262; Wed, 18 Jan 2012 03:07:31 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'Fl=E1vio_Montenegro_Filho'?=" , References: In-Reply-To: Date: Tue, 17 Jan 2012 19:07:30 -0800 Message-ID: <0f1501ccd58e$51260420$f3720c60$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczVWsoFdU+NvXiYQhKoNeDJqT/k1AAMqnaw Content-Language: en-us Subject: Re: [pcp] Protocols: 16-bit port number 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, 18 Jan 2012 03:07:32 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Fl=E1vio Montenegro Filho > Sent: Tuesday, January 17, 2012 12:59 PM > To: pcp@ietf.org > Subject: [pcp] Protocols: 16-bit port number >=20 >=20 > Hi everyone! >=20 > I am implementing a PCP Client and I have a doubt regarding the > following part of the PCP I-D: >=20 > 9.2 Generanting a MAP Request >=20 >=20 > If the Protocol does not use 16-bit port numbers (e.g., RSVP), the > port number MUST be 0. This will cause all traffic matching that > protocol to be mapped. >=20 > The document refers RSVP as an example of protocol which does not use > 16-bit port number, but I am not sure about other protocols besides > RSVP. > Only TCP, UDP, UDP LITE, SCTP and DCCP > [http://tools.ietf.org/html/rfc6335#section-6] use 16-bit port = numbers? > Can anyone help me by pointing other protocols which do not use 16-bit > port numbers? I looked at http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml and IPsec ESP, IPsec AH, IGMP, and GRE don't use port numbers. Probably many more don't use port numbers. For any protocol to work, the PCP client and the PCP server need to both support the specific protocol number. With that support would come a = mutual understanding of (a) if that specific protocol number uses ports (b) = where the port numbers are encoded in the protocol. I'm sure you noticed that PCP only supports 16 bit port numbers (because to our knowledge all of = the protocols registered at http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml that use ports have 16 bit port numbers). If we find a need, later, for longer port numbers for some protocol, PCP can be extended with a=20 mandatory-to-process Option that always accompanies requests for the protocol that uses longer port numbers. -d From mohta@necom830.hpcl.titech.ac.jp Tue Jan 17 20:41:33 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 6B4B621F851C for ; Tue, 17 Jan 2012 20:41:33 -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 ksrv45oXRl90 for ; Tue, 17 Jan 2012 20:41: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 64BDB21F84BD for ; Tue, 17 Jan 2012 20:41:32 -0800 (PST) Received: (qmail 64180 invoked from network); 18 Jan 2012 04:41:20 -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; 18 Jan 2012 04:41:20 -0000 Message-ID: <4F164BD5.1040809@necom830.hpcl.titech.ac.jp> Date: Wed, 18 Jan 2012 13:34:29 +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: <0f1501ccd58e$51260420$f3720c60$@com> In-Reply-To: <0f1501ccd58e$51260420$f3720c60$@com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [pcp] Protocols: 16-bit port number 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, 18 Jan 2012 04:41:33 -0000 Dan Wing wrote: >> The document refers RSVP as an example of protocol which does not use >> 16-bit port number, RSVP does use 16-bit port numbers in filter spec, though the port numbers are of other L4 protocols and not of RSVP. The port numbers of RSVP is in scope of NAT functions, that is, must be mapped by a gateway performing port mapping if the gateway also support RSVP, More practically, ICMP error packets also need mapping of port numbers of inner packets. > I looked at > http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml > and IPsec ESP, IPsec AH, IGMP, and GRE don't use port numbers. Probably > many > more don't use port numbers. As for IPsec, I wrote in draft-ohta-e2e-nat-00.txt: For example, ESP packets may be demultiplexed based on the lower 16 bit of SPI. To do so, a destination host must be able to control the lower 16 bit of SPI. For example, AH packets may be demultiplexed as if the lower 16 bit of SPI, located at the seventh and eighth bytes of a payload, is a destination port number. > If we find a need, later, for > longer port numbers for some protocol, PCP can be extended with a > mandatory-to-process Option that always accompanies requests for the > protocol that uses longer port numbers. Last year, I wrote a paper titled: TCP and UDP with Port Length Enhancement (TUPLE) -- A Scribbled Slate Approach for Internet Addressing and Routing -- ftp://chacha.hpcl.titech.ac.jp/iatuple.pdf ftp://chacha.hpcl.titech.ac.jp/iatuple.ppt to have TCP and UDP analog with 48bit port numbers, 32 bit of which is intended to be used to extend IPv4 address space. Masataka Ohta From dwing@cisco.com Wed Jan 18 11:39: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 1B66D21F85E5 for ; Wed, 18 Jan 2012 11:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.568 X-Spam-Level: X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 WkMrOy2VfxXR for ; Wed, 18 Jan 2012 11:39:04 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3815221F85E3 for ; Wed, 18 Jan 2012 11:39:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4000; q=dns/txt; s=iport; t=1326915544; x=1328125144; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=b23eWeI1SCJT8v27+z6APZcZpRAG+9IiD/6q79Fb4AI=; b=KXYZIylLAAzQCo3iKNPVw67l4UvarmgurJkimCBzRjWf32pGw9eF98YM HW2KS1Lqw2rpPi+QUb7RuSrrUdg45ubMPa5vFFLRXZAt8qmKJROfhzpPa zQf5/bmexiYtb7mI7XIKNinYgW7WrhM4TIx8gdlMdOrjlAVSIQ1J8HTib Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAHcfF0+rRDoI/2dsb2JhbABEDp5kjVSBAoEFgXIBAQECAQEBAQEFCgEXEDQQBwEDAgkOAQIEAQEBJwcZDhUKCQgBAQQBEgkCF4dYCJpKAZ5RiH0NAQQFAwUNAgIBCgEBMAIBAQsPCgEbBxYQAQIBAQgBAQEDAQEBgwJXFgEBAQKDKgSIO4UAmWdY X-IronPort-AV: E=Sophos;i="4.71,531,1320624000"; d="scan'208";a="26055377" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 18 Jan 2012 19:39:03 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0IJd3xx007245; Wed, 18 Jan 2012 19:39:03 GMT From: "Dan Wing" To: "'Masataka Ohta'" , References: <0f1501ccd58e$51260420$f3720c60$@com> <4F164BD5.1040809@necom830.hpcl.titech.ac.jp> In-Reply-To: <4F164BD5.1040809@necom830.hpcl.titech.ac.jp> Date: Wed, 18 Jan 2012 11:39:03 -0800 Message-ID: <020601ccd618$d5936e70$80ba4b50$@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: AczVm3ZmzOaGGOndRdWkFMycQg7NbQAe8xkQ Content-Language: en-us Subject: Re: [pcp] Protocols: 16-bit port number 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, 18 Jan 2012 19:39:05 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Masataka Ohta > Sent: Tuesday, January 17, 2012 8:34 PM > To: pcp@ietf.org > Subject: Re: [pcp] Protocols: 16-bit port number > > Dan Wing wrote: > > >> The document refers RSVP as an example of protocol which does not > use > >> 16-bit port number, > > RSVP does use 16-bit port numbers in filter spec, though > the port numbers are of other L4 protocols and not of RSVP. > > The port numbers of RSVP is in scope of NAT functions, that > is, must be mapped by a gateway performing port mapping if > the gateway also support RSVP, In my view, a NAT that has an RSVP-ALG function would rewrite those, as appropriate. I don't see that PCP can get involved with the ALG function, nor how PCP could instruct/inform the NAT about is happening with that. > More practically, ICMP error packets also need mapping of > port numbers of inner packets. Agreed. And PCP already requires that ICMP errors be mapped by a NAT, as a side effect of creating a transport mapping (TCP, UDP, SCTP, DCCP, etc.), http://tools.ietf.org/html/draft-ietf-pcp-base-21#section-10 says: As a side-effect of creating a mapping, ICMP messages associated with the mapping MUST be forwarded (and also translated, if appropriate) for the duration of the mapping's lifetime. This is done to ensure that ICMP messages can still be used by hosts, without application programmers or PCP client implementations needing to use PCP separately to create ICMP mappings for those flows. ICMP can be allowed/denied using PCP, for firewall purposes (e.g., to tell a firewall to allow a host to receive ICMP echo-requests). Right now, because ICMP does not use ports, PCP can only control ICMP with all-or-nothing semantics. If someone wants to describe a new PCP Option to allow more specific rules (e.g., allow just ICMP echo-request and deny other ICMP messages; allow just ICMP TTL exceeded and PTB and deny other ICMP messages), PCP can be extended in that way. I don't feel there is much interest in that at this time, however. > > I looked at > > http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml > > and IPsec ESP, IPsec AH, IGMP, and GRE don't use port numbers. > Probably > > many > > more don't use port numbers. > > As for IPsec, I wrote in draft-ohta-e2e-nat-00.txt: > > For example, ESP > packets may be demultiplexed based on the lower 16 bit of SPI. To do > so, a destination host must be able to control the lower 16 bit of > SPI. > > For example, AH packets may be demultiplexed as if the lower 16 bit > of SPI, located at the seventh and eighth bytes of a payload, is a > destination port number. Are you suggesting PCP can accommodate those ideas in some way? > > If we find a need, later, for > > longer port numbers for some protocol, PCP can be extended with a > > mandatory-to-process Option that always accompanies requests for the > > protocol that uses longer port numbers. > > Last year, I wrote a paper titled: > > TCP and UDP with Port Length Enhancement (TUPLE) > -- A Scribbled Slate Approach for Internet Addressing > and Routing -- > > ftp://chacha.hpcl.titech.ac.jp/iatuple.pdf > ftp://chacha.hpcl.titech.ac.jp/iatuple.ppt > > to have TCP and UDP analog with 48bit port numbers, 32 bit of > which is intended to be used to extend IPv4 address space. There is also draft-sunjianping-behave-nat-port-expand which is a similar idea. PCP could be extended to handle either of those ideas, should there be sufficient interest. (I admit that I only skimmed your TUPLE idea, and I felt TUPLE had architectural similarities to LISP http://tools.ietf.org/wg/lisp). -d > Masataka Ohta > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From Tina.Tsou.Zouting@huawei.com Wed Jan 18 16:41:30 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 3266921F84B4 for ; Wed, 18 Jan 2012 16:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wz+CBTZy3yte for ; Wed, 18 Jan 2012 16:41:29 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9325521F84B3 for ; Wed, 18 Jan 2012 16:41:29 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LY0003P0SL36R@szxga05-in.huawei.com> for pcp@ietf.org; Thu, 19 Jan 2012 08:41:27 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LY0009VUSL37O@szxga05-in.huawei.com> for pcp@ietf.org; Thu, 19 Jan 2012 08:41:27 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGK42241; Thu, 19 Jan 2012 08:41:26 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 19 Jan 2012 08:41:20 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.225]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Thu, 19 Jan 2012 08:41:10 +0800 Date: Thu, 19 Jan 2012 00:41:09 +0000 From: Tina TSOU X-Originating-IP: [10.193.34.124] To: "pcp@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: About PCP Client Thread-index: AczWQwb6z1WUfSTpRge2D55L3U4N8w== X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: 80M= AWRR Afjc BL2h DM6N FMhu FXi/ FrnJ Fzal GJn9 Gp+N G2Je H2hm Ibhf JhEt LkdT; 1; cABjAHAAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {36DD9647-65C9-4B9F-90F9-2B6E96C26886}; dABpAG4AYQAuAHQAcwBvAHUALgB6AG8AdQB0AGkAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Thu, 19 Jan 2012 00:41:06 GMT;QQBiAG8AdQB0ACAAUABDAFAAIABDAGwAaQBlAG4AdAA= x-cr-puzzleid: {36DD9647-65C9-4B9F-90F9-2B6E96C26886} X-CFilter-Loop: Reflected Subject: [pcp] About PCP Client 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, 19 Jan 2012 00:41:30 -0000 Hi, In http://tools.ietf.org/html/draft-ietf-pcp-base-04#page-19 8.4.1. Maintaining Same External IP Address If there are active mappings associated with a given subscriber (see Section 10.5) -- created via dynamic assignment, by PCP or any other means -- subsequent PCP mapping requests belonging to the same subscriber MUST use the same external IP address. This follows the intent of REQ-1 of [I-D.ietf-behave-lsn-requirements]. In http://tools.ietf.org/html/draft-ietf-pcp-base-05, there is only behavior description about server, not client. 10.1. Maintaining Same External IP Address It is REQUIRED that the PCP-controlled device assign the same external IP address PCP-created explicit dynamic mappings and to implicit dynamic mappings. It is RECOMMENDED that static mappings (e.g., those created by a command language interface on the PCP server or PCP-controlled device) also be assigned to the same IP address. >From the point of view of the client, you don't want to depend exclusively on the CGN to ensure that you always get the same external address. You want to signal it explicitly in the PCP messages to be even more certain that you get the same external address. New proposed texts are below. (from the client point of view) If there are active mappings associated with a given subscriber created via dynamic assignment, e.g. by PCP, subsequent PCP mapping requests belonging to the same subscriber SHOULD use the same external IP address. Best Regards, Tina TSOU From dwing@cisco.com Wed Jan 18 19:31: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 3405111E8079 for ; Wed, 18 Jan 2012 19:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 O8t9RN4nHFVv for ; Wed, 18 Jan 2012 19:31:55 -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 A118F11E8071 for ; Wed, 18 Jan 2012 19:31:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5995; q=dns/txt; s=iport; t=1326943915; x=1328153515; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Mejr//SqoQ6DKKyxe9tsUcLXUmd0zWqEofaGS9ABDXM=; b=gzM1d9d/2xFlnG3w6F8gTyF7ICegfV2yNGZFWMRSWuAKKQb+aeGb3ZGC 2OU74mREAq1ZNjsOkmGq9WioEcDXdWeKjDyVXXrVZk9kpIQQLdOkxq9y3 Wty/xEbOsKsv0y+0OOII3BlXxGyZSBaYa1mAmFL1kaPuiIKmOf/0gUf7O c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAKKNF0+rRDoI/2dsb2JhbABEnnqNDEmBA4EFgXIBAQEDAQgKARcQPwUHAQMCCQ4BAgQBASgHGSMKCQgBAQQTCxeHWJpZAZ5aiTgBATACAQELDwoBGwcWEAECAQEIAQEBBAEBgwJXFgEBAQKDKgSIO4UAmkI X-IronPort-AV: E=Sophos;i="4.71,533,1320624000"; d="scan'208";a="26098765" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 19 Jan 2012 03:31:55 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0J3Vtpe010369; Thu, 19 Jan 2012 03:31:55 GMT From: "Dan Wing" To: "'Dave Thaler'" References: <9B57C850BB53634CACEC56EF4853FF653B38D97A@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B38D97A@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 18 Jan 2012 19:31:55 -0800 Message-ID: <03ef01ccd65a$e45c59c0$ad150d40$@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: AczSWv2FQpQmUSTARBS6IlnxG4355AD+fAXA Content-Language: en-us Cc: pcp@ietf.org, pcp-chairs@tools.ietf.org, draft-ietf-pcp-base@tools.ietf.org Subject: Re: [pcp] Document shepherd re-review of draft-ietf-pcp-base-21 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, 19 Jan 2012 03:31:58 -0000 > -----Original Message----- > From: Dave Thaler [mailto:dthaler@microsoft.com] > Sent: Friday, January 13, 2012 5:29 PM > To: Dan Wing > Cc: pcp-chairs@tools.ietf.org; draft-ietf-pcp-base@tools.ietf.org; > pcp@ietf.org > Subject: Document shepherd re-review of draft-ietf-pcp-base-21 > > I did a re-review of -21 since the doc shepherd has to sign off > > on reviewing "this version" (i.e. the final version submitted > > to the IESG) in the proto writeup. > > > > Section 9: > > > of this knowledge to decide to which of its PCP servers to send the > > > request (e.g., a PCP server on its IPv4 interface or its IPv6 > > > interface), > > > > The above implies an atypical model where IPv4 and IPv6 are on > > separate "interfaces". The normal (per various RFCs and > > implementations) model puts them both on the same interface. > > Suggest: > > > of this knowledge to decide to which of its PCP server addresses to > send the > > > request (e.g., an IPv4 address or an IPv6 address), Thanks for the suggestion. Fixed in -22 with that wording. > > > Similarly in > > > If the PCP client has both > > > an IPv4 and IPv6 address, and only wants an IPv4 listener, it sends > > > one MAP request from its IPv4 interface (if the PCP server supports > > > NAT44 or IPv4 firewall) or one MAP request from its IPv6 interface > > > (if the PCP server supports NAT64)). > > > > s/interface/address/ (two occurrences) Fixed in -22. > As worded it doesn't make sense to some readers. > > > > I hadn't noticed this before but in 12.3: > > > For IPv4 addresses, which are > > > represented using the IPv4-mapped address format (::FFFF:0:0/96), the > > > value of the Prefix Length pertains only to the IPv4 portion of the > > > address. Thus, a Prefix Length of 32 with an IPv4-mapped address > > > indicates "only this address". With IPv4-mapped addresses, the > > > minimum Prefix length value is 0 and the maximum is 32; for IPv6 > > > addresses the minimum value is 0 and the maximum is 128. > > > > I personally find the above *really* ugly. I had expected the change > for IPv4-mapped > > addrs to also change the prefix length to be consistent with what one > would expect > > with IPv4-mapped addrs (max is 128 in both cases and starts from the > beginning > > of the field). > I can't say the spec is "broken" though, just annoying to implement > this way and > inconsistent with other RFCs, so maybe we have to just live with it? This appears to be a carryover from when we had separate OpCodes (MAP4/MAP6), which had 0-32 (for MAP4) and 0-128 (for MAP6). I agree it is ugly. Revised to: The Prefix Length indicates how many bits of the address are used for the filter. For IPv4 addresses (which are encoded using the IPv4-mapped address format (::FFFF:0:0/96)), this means valid prefix lengths are between 96 and 128 bits, inclusive. That is, add 96 to the IPv4 prefix length. For IPv6 addresses, valid prefix lengths are between 0 and 128 bits, inclusive. Values outside those ranges cause the PCP server to return the MALFORMED_OPTION result code. > > > > Section 16.3.1 typo: > > An attacker, on the path between the PCP client and PCP server, can > drop PCP requests, drop PCP responses, or spoof a PCP error, all of > which will effective deny service. Through such actions, the PCP > client might not be aware the PCP server might have actually > processed the PCP request. > > > > s/effective/effectively/ Thanks. > > > The last sentence quoted actually *vastly* understates the residual > vulnerability. > > In an earlier review last year I stated "Another DOS vector is via > spoofing a SERVER_OVERLOADED response and sending it to a victim." > > Now SERVER_OVERLOADED is called NO_RESOURCES, and the effect is (from > 7.3): > > If the result code > is NO_RESOURCES, PCP client SHOULD NOT send *any* further requests > of > any kind to that PCP server for the indicated error lifetime. > > > > So the effect is not just that the request might have succeeded > unbeknownst > > to the client, but that an attacker can prevent the PCP client from > sending > > *any* future requests at all to that server (the attacker can use the > > maximum lifetime which is well over 100 years). Suggest adding after > the > > paragraph in 16.3.1 quoted above (the one with the typo): > > > > > The PCP client might also be unable to send any further requests of > any > > > kind to that PCP server. I went with a closing sentence of: An attacker sending a NO_RESOURCES error can cause the PCP client to not send messages to that server for a while. Regarding that attack, -21 had the following text in the MAP section regarding Lifetime, which protects against excessively long Lifetimes in responses: The PCP client SHOULD impose an upper limit on this returned Assigned Lifetime value, and 24 hours is RECOMMENDED. This means if the PCP server returns an absurdly long Assigned Lifetime (e.g., 5 years), the PCP client will behave as if it received a more sane value (e.g., 24 hours). In -22, I will split this recommendation into 24 hours for MAP success responses and 30 minutes for MAP error responses. > Also fyi the RFC editor pass will make the following sort of changes. > > Section 2.2 uses non-well-known (as defined by the RFC style manual) > > acronyms like SCTP and DCCP and those will be expanded on first use, > > and probably informational references added. Optionally you could > > do these yourself before the RFC editor asks you to verify their > changes. Done. -22 will be posted shortly. -d > > > > -Dave > > From internet-drafts@ietf.org Wed Jan 18 21:48:30 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 7AE2F21F85C3; Wed, 18 Jan 2012 21:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 L11ot-+vorKw; Wed, 18 Jan 2012 21:48:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFEF21F85B8; Wed, 18 Jan 2012 21:48:29 -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: <20120119054829.15573.71923.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2012 21:48:29 -0800 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-base-22.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: Thu, 19 Jan 2012 05:48:30 -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-22.txt Pages : 92 Date : 2012-01-18 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-22.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-22.txt From dwing@cisco.com Wed Jan 18 21:52: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 10CBF21F8603 for ; Wed, 18 Jan 2012 21:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.57 X-Spam-Level: X-Spam-Status: No, score=-106.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 lgmzc-LnLJ+1 for ; Wed, 18 Jan 2012 21:52:02 -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 5B77921F85AD for ; Wed, 18 Jan 2012 21:52:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=929; q=dns/txt; s=iport; t=1326952322; x=1328161922; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=ftSzzCWoCSgMX8D25FZYRHQb5Yc9aUpB+Fbyks5r//M=; b=NjCWwQ5wlBvGn4iT8rFesoXsGRyVDeMT5cQX2cdioHaWxfZZ1pKk6pqe 9iw4n1Pv7pjVeHwTCq1saI30PL627uTVh/Xa3TwDm1UibaSVms/M1q8Oq KtT1jUsgEO/if9Iu9abcZ6FFDMRQq/klQONLtgi2FhbuZRECFdJrx6djJ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEmvF0+rRDoG/2dsb2JhbABEnnqNWoEEgQWBeQgKARcQPw0FGFAjHAEEHheHYpo9AZ5WiH0NCAIDAQQGCQIBAQMGAQEwAgEBCw8KARsHFhABAgEBAgMDAQEBAQIBAQGDAigEAgILAQk7gxwEiDuFAJpC X-IronPort-AV: E=Sophos;i="4.71,534,1320624000"; d="scan'208";a="24413335" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 19 Jan 2012 05:52:02 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0J5q1C2012312; Thu, 19 Jan 2012 05:52:01 GMT From: "Dan Wing" To: Date: Wed, 18 Jan 2012 21:52:01 -0800 Message-ID: <044401ccd66e$77265810$65730830$@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: AczWbnbQNOcQorekRsKe5d/oJ1IDjQ== Content-Language: en-us Cc: pcp-chairs@tools.ietf.org Subject: [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, 19 Jan 2012 05:52:04 -0000 draft-ietf-pcp-base-22 was just posted with changes as a result of Dave Thaler's review. Changes are: B.1. Changes from draft-ietf-pcp-base-21 to -22 o Removed paragraph discussing multiple addresses on the same (physical) interface; those will work with PCP. o The FILTER Option's Prefix Length field redefined to simply be a count of the relevant bits (rather than 0-32 for IPv4-mapped addresses). o Point out NO_RESOURCES attack vector in security considerations. o Tighten up recommendation for client handling long Lifetimes, and moved from the MAP-specific section to the General PCP Processing section. Client should normalize to 24 hours maximum for success and 30 minute maximum for errors. Side-by-side diffs at http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcp-base-22.txt -d From dwing@cisco.com Wed Jan 18 22:03:01 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 CA8EE21F854D for ; Wed, 18 Jan 2012 22:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.571 X-Spam-Level: X-Spam-Status: No, score=-106.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 VRq-uNO+0TZf for ; Wed, 18 Jan 2012 22:03:00 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id DA27421F850D for ; Wed, 18 Jan 2012 22:03:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2923; q=dns/txt; s=iport; t=1326952981; x=1328162581; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=vAUm9B/CXdiVh62XUTEtZRBH3WRPvIWX/2VYKlwr9GA=; b=kIN673NtRVZqogJeOkmqTU56RuYJtLJQAUpPlzd6EThQzCArUtL0LVzb LnQTJS4nR97atfQZTS1tfv4bDtRn+s4zhfmok/a8Bq1xTDP1jGRIlB/6S UE4QyPqrGev8+UidiGXfiRt5HBo9LoJtt2SJ7BFfdNOJxdvoWcmyRCt4r s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPOxF0+rRDoG/2dsb2JhbABEnnqNWoEEgQWBcgEBAQMBAQEBBQoBFxA0FwEDAgkPAgQBASgHGQ4VCgkIAQEEARILF4daCJo9AZ5ViRQXCwIBATACAQELDwoBGwcWEAECAQEIAQEBAQIBAQGDAlcWAQEBAoMqBIg7hQCaQg X-IronPort-AV: E=Sophos;i="4.71,534,1320624000"; d="scan'208";a="26137836" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 19 Jan 2012 06:02:44 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0J62ijD017655; Thu, 19 Jan 2012 06:02:44 GMT From: "Dan Wing" To: "'Tina TSOU'" , References: In-Reply-To: Date: Wed, 18 Jan 2012 22:02:44 -0800 Message-ID: <044801ccd66f$f60bbca0$e22335e0$@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: AczWQwb6z1WUfSTpRge2D55L3U4N8wALAK+Q Content-Language: en-us Subject: Re: [pcp] About PCP Client 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, 19 Jan 2012 06:03:01 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Tina TSOU > Sent: Wednesday, January 18, 2012 4:41 PM > To: pcp@ietf.org > Subject: [pcp] About PCP Client > > Hi, > In http://tools.ietf.org/html/draft-ietf-pcp-base-04#page-19 > 8.4.1. Maintaining Same External IP Address > > If there are active mappings associated with a given subscriber (see > Section 10.5) -- created via dynamic assignment, by PCP or any other > means -- subsequent PCP mapping requests belonging to the same > subscriber MUST use the same external IP address. This follows the > intent of REQ-1 of [I-D.ietf-behave-lsn-requirements]. > > In http://tools.ietf.org/html/draft-ietf-pcp-base-05, there is only > behavior description about server, not client. > 10.1. Maintaining Same External IP Address > > It is REQUIRED that the PCP-controlled device assign the same > external IP address PCP-created explicit dynamic mappings and to > implicit dynamic mappings. It is RECOMMENDED that static mappings > (e.g., those created by a command language interface on the PCP > server or PCP-controlled device) also be assigned to the same IP > address. > > From the point of view of the client, you don't want to depend > exclusively on the CGN to ensure that you always get the same external > address. You want to signal it explicitly in the PCP messages to be > even more certain that you get the same external address. > > New proposed texts are below. > > (from the client point of view) If there are active mappings associated > with a given subscriber created via dynamic assignment, e.g. by PCP, > subsequent PCP mapping requests belonging to the same subscriber SHOULD > use the same external IP address. http://tools.ietf.org/html/draft-ietf-pcp-base-22#section-10.2 (and several previous versions) already says: The request MAY contain values in the Suggested External Port and Suggested External IP Address fields. This allows the PCP client to attempt to rebuild lost state on the PCP server, which improves the chances of existing connections surviving, and helps the PCP client avoid having to change information maintained at its rendezvous server. Of course, due to other activity on the network (e.g., by other users or network renumbering), the PCP server may not be able to grant the suggested External IP Address and Port, and in that case it will assign a different External IP Address and Port. is there an interoperability problem that would be fixed/improved by adjusting that text to encourage providing the same Suggested External Address as existing mappings? -d > > > Best Regards, > Tina TSOU > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From Tina.Tsou.Zouting@huawei.com Wed Jan 18 23:37: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 61F8121F8599 for ; Wed, 18 Jan 2012 23:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAQWQvIGcM9n for ; Wed, 18 Jan 2012 23:37:04 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id D9B2C21F8597 for ; Wed, 18 Jan 2012 23:37:03 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LY100JDVBTHZ8@szxga03-in.huawei.com> for pcp@ietf.org; Thu, 19 Jan 2012 15:36:53 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LY100AG2BTCS7@szxga03-in.huawei.com> for pcp@ietf.org; Thu, 19 Jan 2012 15:36:53 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGK73583; Thu, 19 Jan 2012 15:36:53 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 19 Jan 2012 15:36:46 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.225]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 19 Jan 2012 15:36:34 +0800 Date: Thu, 19 Jan 2012 07:36:34 +0000 From: Tina TSOU In-reply-to: <044801ccd66f$f60bbca0$e22335e0$@com> X-Originating-IP: [10.212.244.141] To: Dan Wing , "pcp@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [pcp] About PCP Client Thread-index: AczWQwb6z1WUfSTpRge2D55L3U4N8wALAK+QAANoZeA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <044801ccd66f$f60bbca0$e22335e0$@com> Subject: Re: [pcp] About PCP Client 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, 19 Jan 2012 07:37:05 -0000 Tina > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Wednesday, January 18, 2012 10:03 PM > To: Tina TSOU; pcp@ietf.org > Subject: RE: [pcp] About PCP Client > > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > > Tina TSOU > > Sent: Wednesday, January 18, 2012 4:41 PM > > To: pcp@ietf.org > > Subject: [pcp] About PCP Client > > > > Hi, > > In http://tools.ietf.org/html/draft-ietf-pcp-base-04#page-19 > > 8.4.1. Maintaining Same External IP Address > > > > If there are active mappings associated with a given subscriber (see > > Section 10.5) -- created via dynamic assignment, by PCP or any other > > means -- subsequent PCP mapping requests belonging to the same > > subscriber MUST use the same external IP address. This follows the > > intent of REQ-1 of [I-D.ietf-behave-lsn-requirements]. > > > > In http://tools.ietf.org/html/draft-ietf-pcp-base-05, there is only > > behavior description about server, not client. > > 10.1. Maintaining Same External IP Address > > > > It is REQUIRED that the PCP-controlled device assign the same > > external IP address PCP-created explicit dynamic mappings and to > > implicit dynamic mappings. It is RECOMMENDED that static mappings > > (e.g., those created by a command language interface on the PCP > > server or PCP-controlled device) also be assigned to the same IP > > address. > > > > From the point of view of the client, you don't want to depend > > exclusively on the CGN to ensure that you always get the same external > > address. You want to signal it explicitly in the PCP messages to be > > even more certain that you get the same external address. > > > > New proposed texts are below. > > > > (from the client point of view) If there are active mappings associated > > with a given subscriber created via dynamic assignment, e.g. by PCP, > > subsequent PCP mapping requests belonging to the same subscriber SHOULD > > use the same external IP address. > > http://tools.ietf.org/html/draft-ietf-pcp-base-22#section-10.2 (and > several previous versions) already says: > > The request MAY contain values in the Suggested External Port and > Suggested External IP Address fields. This allows the PCP client to > attempt to rebuild lost state on the PCP server, which improves the > chances of existing connections surviving, and helps the PCP client > avoid having to change information maintained at its rendezvous > server. Of course, due to other activity on the network (e.g., by > other users or network renumbering), the PCP server may not be able > to grant the suggested External IP Address and Port, and in that case > it will assign a different External IP Address and Port. > > is there an interoperability problem that would be fixed/improved by > adjusting that text to encourage providing the same Suggested External > Address as existing mappings? When client and CGN state get out of sync for an unknown reason, it helps. > > -d > > > > > > > > Best Regards, > > Tina TSOU > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp From dwing@cisco.com Thu Jan 19 09:24:39 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 52DE821F86AF for ; Thu, 19 Jan 2012 09:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.572 X-Spam-Level: X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 2g5AL2l67a-K for ; Thu, 19 Jan 2012 09:24:38 -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 0F33521F86B4 for ; Thu, 19 Jan 2012 09:24:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4997; q=dns/txt; s=iport; t=1326993877; x=1328203477; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=PLW+PZfxE+PmfOGF9qfI6SDNNYTF5dbr4m7DsHxIGMI=; b=GFNijCSRzgq8pS/h1gtcj0c+Dg4wbVdNCf48Uzd6/xWR1Sq6l8IWv2oP x6n8HATZG183ZP5a6yrB8KeycNOJwSwubBgMZcy+3bzQjaBETeCGKHa4M zTLpcaf5bYLmZsuTc0HnnSJJesmoThdzm+3QbCFk8hSk5MRMVKrVbeLBA E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAONQGE+rRDoJ/2dsb2JhbABEnwCNX4EAgQWBcgEBAQQICgEXEA88AQMCCQ8CBAEBKAcZIwoJCAEBBAESCxeHYppGAZ5YiRQXDQEBMAIBAQsPCgEbBxYQAQIBAQgBAQEDAQEBgwJXFgEBAQKDKgSDBIU3hQOaRA X-IronPort-AV: E=Sophos;i="4.71,537,1320624000"; d="scan'208";a="24501321" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 19 Jan 2012 17:24:37 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0JHOa74021286; Thu, 19 Jan 2012 17:24:37 GMT From: "Dan Wing" To: "'Tina TSOU'" , References: <044801ccd66f$f60bbca0$e22335e0$@com> In-Reply-To: Date: Thu, 19 Jan 2012 09:24:37 -0800 Message-ID: <065d01ccd6cf$380be620$a823b260$@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: AczWQwb6z1WUfSTpRge2D55L3U4N8wALAK+QAANoZeAAFG2m4A== Content-Language: en-us Subject: Re: [pcp] About PCP Client 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, 19 Jan 2012 17:24:39 -0000 > -----Original Message----- > From: Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com] > Sent: Wednesday, January 18, 2012 11:37 PM > To: Dan Wing; pcp@ietf.org > Subject: RE: [pcp] About PCP Client > > > > Tina > > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Wednesday, January 18, 2012 10:03 PM > > To: Tina TSOU; pcp@ietf.org > > Subject: RE: [pcp] About PCP Client > > > > > -----Original Message----- > > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf > Of > > > Tina TSOU > > > Sent: Wednesday, January 18, 2012 4:41 PM > > > To: pcp@ietf.org > > > Subject: [pcp] About PCP Client > > > > > > Hi, > > > In http://tools.ietf.org/html/draft-ietf-pcp-base-04#page-19 > > > 8.4.1. Maintaining Same External IP Address > > > > > > If there are active mappings associated with a given subscriber > (see > > > Section 10.5) -- created via dynamic assignment, by PCP or any > other > > > means -- subsequent PCP mapping requests belonging to the same > > > subscriber MUST use the same external IP address. This follows > the > > > intent of REQ-1 of [I-D.ietf-behave-lsn-requirements]. > > > > > > In http://tools.ietf.org/html/draft-ietf-pcp-base-05, there is only > > > behavior description about server, not client. > > > 10.1. Maintaining Same External IP Address > > > > > > It is REQUIRED that the PCP-controlled device assign the same > > > external IP address PCP-created explicit dynamic mappings and to > > > implicit dynamic mappings. It is RECOMMENDED that static > mappings > > > (e.g., those created by a command language interface on the PCP > > > server or PCP-controlled device) also be assigned to the same IP > > > address. > > > > > > From the point of view of the client, you don't want to depend > > > exclusively on the CGN to ensure that you always get the same > external > > > address. You want to signal it explicitly in the PCP messages to be > > > even more certain that you get the same external address. > > > > > > New proposed texts are below. > > > > > > (from the client point of view) If there are active mappings > associated > > > with a given subscriber created via dynamic assignment, e.g. by > PCP, > > > subsequent PCP mapping requests belonging to the same subscriber > SHOULD > > > use the same external IP address. > > > > http://tools.ietf.org/html/draft-ietf-pcp-base-22#section-10.2 (and > > several previous versions) already says: > > > > The request MAY contain values in the Suggested External Port and > > Suggested External IP Address fields. This allows the PCP client > to > > attempt to rebuild lost state on the PCP server, which improves > the > > chances of existing connections surviving, and helps the PCP > client > > avoid having to change information maintained at its rendezvous > > server. Of course, due to other activity on the network (e.g., by > > other users or network renumbering), the PCP server may not be > able > > to grant the suggested External IP Address and Port, and in that > case > > it will assign a different External IP Address and Port. > > > > is there an interoperability problem that would be fixed/improved by > > adjusting that text to encourage providing the same Suggested > External > > Address as existing mappings? > When client and CGN state get out of sync for an unknown reason, it > helps. Ok, so let's imagine they are out of sync. Perhaps the NAT crashed, for example, and lost all its state. PCP Rapid Recovery, if present, will immediately inform the PCP client of the crash. The PCP client will then ask the NAT (in-home NAT or CGN works the same way) to re-create the mappings and request the same public IP address and public port. If PCP Rapid Recovery is not present, the PCP client won't be aware of the NAT losing state. There might or might not be other activity on the same host (e.g., a TCP connection to www.amazon.com:80). Whenever the PCP client sends a new request to the PCP server, the PCP client will notice the unexpectedly-lower Epoch value. This indicates to the PCP client that the NAT has lost state, and the PCP client will then re-create its mappings and request the same public IP address and public port. Of course, if there was already some non-PCP activity (e.g., that TCP connection to www.amazon.com:80) the NAT might have already assigned a different public IP address to the PCP client. Which means the connections cannot be assigned to that 'old' IP address; they have to be assigned to the new (different) IP address. All of the above is already in the document, and seems to cover the situation where the PCP client and the NAT/CGN are out of sync. If there is a problem where they get out of sync which doesn't work, please provide the steps that occur to create the sync problem. -d From Tina.Tsou.Zouting@huawei.com Thu Jan 19 09:58: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 BD1C721F86C6 for ; Thu, 19 Jan 2012 09:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lWTCoMKBtLo for ; Thu, 19 Jan 2012 09:58:04 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id AB7D821F86C1 for ; Thu, 19 Jan 2012 09:58:03 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LY20094Z4KQZH@szxga04-in.huawei.com> for pcp@ietf.org; Fri, 20 Jan 2012 01:58:03 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LY2003H94KQW1@szxga04-in.huawei.com> for pcp@ietf.org; Fri, 20 Jan 2012 01:58:02 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGL10449; Fri, 20 Jan 2012 01:58:02 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 20 Jan 2012 01:57:54 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.225]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Fri, 20 Jan 2012 01:57:40 +0800 Date: Thu, 19 Jan 2012 17:57:40 +0000 From: Tina TSOU In-reply-to: <065d01ccd6cf$380be620$a823b260$@com> X-Originating-IP: [10.212.244.236] To: Dan Wing , "pcp@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [pcp] About PCP Client Thread-index: AczWQwb6z1WUfSTpRge2D55L3U4N8wALAK+QAANoZeAAFG2m4AAA42Ug X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <044801ccd66f$f60bbca0$e22335e0$@com> <065d01ccd6cf$380be620$a823b260$@com> Subject: Re: [pcp] About PCP Client 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, 19 Jan 2012 17:58:04 -0000 Tina > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Thursday, January 19, 2012 9:25 AM > To: Tina TSOU; pcp@ietf.org > Subject: RE: [pcp] About PCP Client > > > -----Original Message----- > > From: Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com] > > Sent: Wednesday, January 18, 2012 11:37 PM > > To: Dan Wing; pcp@ietf.org > > Subject: RE: [pcp] About PCP Client > > > > > > > > Tina > > > > > > > -----Original Message----- > > > From: Dan Wing [mailto:dwing@cisco.com] > > > Sent: Wednesday, January 18, 2012 10:03 PM > > > To: Tina TSOU; pcp@ietf.org > > > Subject: RE: [pcp] About PCP Client > > > > > > > -----Original Message----- > > > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf > > Of > > > > Tina TSOU > > > > Sent: Wednesday, January 18, 2012 4:41 PM > > > > To: pcp@ietf.org > > > > Subject: [pcp] About PCP Client > > > > > > > > Hi, > > > > In http://tools.ietf.org/html/draft-ietf-pcp-base-04#page-19 > > > > 8.4.1. Maintaining Same External IP Address > > > > > > > > If there are active mappings associated with a given subscriber > > (see > > > > Section 10.5) -- created via dynamic assignment, by PCP or any > > other > > > > means -- subsequent PCP mapping requests belonging to the same > > > > subscriber MUST use the same external IP address. This follows > > the > > > > intent of REQ-1 of [I-D.ietf-behave-lsn-requirements]. > > > > > > > > In http://tools.ietf.org/html/draft-ietf-pcp-base-05, there is only > > > > behavior description about server, not client. > > > > 10.1. Maintaining Same External IP Address > > > > > > > > It is REQUIRED that the PCP-controlled device assign the same > > > > external IP address PCP-created explicit dynamic mappings and to > > > > implicit dynamic mappings. It is RECOMMENDED that static > > mappings > > > > (e.g., those created by a command language interface on the PCP > > > > server or PCP-controlled device) also be assigned to the same IP > > > > address. > > > > > > > > From the point of view of the client, you don't want to depend > > > > exclusively on the CGN to ensure that you always get the same > > external > > > > address. You want to signal it explicitly in the PCP messages to be > > > > even more certain that you get the same external address. > > > > > > > > New proposed texts are below. > > > > > > > > (from the client point of view) If there are active mappings > > associated > > > > with a given subscriber created via dynamic assignment, e.g. by > > PCP, > > > > subsequent PCP mapping requests belonging to the same subscriber > > SHOULD > > > > use the same external IP address. > > > > > > http://tools.ietf.org/html/draft-ietf-pcp-base-22#section-10.2 (and > > > several previous versions) already says: > > > > > > The request MAY contain values in the Suggested External Port and > > > Suggested External IP Address fields. This allows the PCP client > > to > > > attempt to rebuild lost state on the PCP server, which improves > > the > > > chances of existing connections surviving, and helps the PCP > > client > > > avoid having to change information maintained at its rendezvous > > > server. Of course, due to other activity on the network (e.g., by > > > other users or network renumbering), the PCP server may not be > > able > > > to grant the suggested External IP Address and Port, and in that > > case > > > it will assign a different External IP Address and Port. > > > > > > is there an interoperability problem that would be fixed/improved by > > > adjusting that text to encourage providing the same Suggested > > External > > > Address as existing mappings? > > When client and CGN state get out of sync for an unknown reason, it > > helps. > > Ok, so let's imagine they are out of sync. Perhaps the NAT crashed, > for example, and lost all its state. > > PCP Rapid Recovery, if present, will immediately inform the PCP > client of the crash. The PCP client will then ask the NAT (in-home > NAT or CGN works the same way) to re-create the mappings and > request the same public IP address and public port. > > If PCP Rapid Recovery is not present, the PCP client won't be > aware of the NAT losing state. There might or might not be > other activity on the same host (e.g., a TCP connection to > www.amazon.com:80). Whenever the PCP client sends a new > request to the PCP server, the PCP client will notice the > unexpectedly-lower Epoch value. This indicates to the PCP > client that the NAT has lost state, and the PCP client will > then re-create its mappings and request the same public IP > address and public port. Of course, if there was already > some non-PCP activity (e.g., that TCP connection to www.amazon.com:80) > the NAT might have already assigned a different public IP > address to the PCP client. Which means the connections > cannot be assigned to that 'old' IP address; they have to be > assigned to the new (different) IP address. > > > All of the above is already in the document, and seems to > cover the situation where the PCP client and the NAT/CGN > are out of sync. > > If there is a problem where they get out of sync which doesn't > work, please provide the steps that occur to create the sync > problem. I think there might be two cases that client and CGN state get out of sync: 1. Client has the mappings but CGN already delete them all for some kind of reason. 2. Client deletes all the local mappings but CGN still has the mappings. In the 1 case, first of all, the connections of applications that have mappings will be broken, I do not see an existing solution for this problem yet, maybe we can suggest that the CGN should send a notification to the client if mappings are deleted. In this case, if the client sends a request specifying the external address, it may fail. I agree this is a problem; it could be fixed together with other problems. In the 2 case, there is no problem with client; the client can request new mappings. > > -d > From dwing@cisco.com Thu Jan 19 10:13:31 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 8BB3621F85A0 for ; Thu, 19 Jan 2012 10:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.573 X-Spam-Level: X-Spam-Status: No, score=-106.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 hYHZxqbYMq7m for ; Thu, 19 Jan 2012 10:13:30 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id E020021F857A for ; Thu, 19 Jan 2012 10:13:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2144; q=dns/txt; s=iport; t=1326996811; x=1328206411; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=J0MrcQ8pTGU8vgLzE8lfN3sNs1gSiwc5U0kvba4h8Ww=; b=kRK7aqYLJWkDaCB8DjmAkKfkUFsDxAcJ7RyGNUZfk0QftY8TR8ubfK7R 6/jveVvqx4X+QfNVlPW/pkrFebGbZRYSnS7Q7MEhiqh0qkXyCBtsZjXoB dMSJzlxQC5kQllJIlTR/DlWwFBPtJTcH+FUx6Cns5qG+W10txVwaTFqS9 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABNdGE+rRDoH/2dsb2JhbABEnwCNX4EAgQWBcgEBAQMBCAoBFxBECAMCCQ83GSMbAQEEAR0QB4daCJpPAZ5RiQoIAgMBBA8CBQYBATACAQELDwoBGwcWEAECAQEIAQEBAQIBAQGDAoQcBIg7hQOaRA X-IronPort-AV: E=Sophos;i="4.71,537,1320624000"; d="scan'208";a="26233482" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 19 Jan 2012 18:13:30 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q0JIDUYt013632; Thu, 19 Jan 2012 18:13:30 GMT From: "Dan Wing" To: "'Tina TSOU'" , References: <044801ccd66f$f60bbca0$e22335e0$@com> <065d01ccd6cf$380be620$a823b260$@com> In-Reply-To: Date: Thu, 19 Jan 2012 10:13:30 -0800 Message-ID: <06b201ccd6d6$0c645870$252d0950$@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: AczWQwb6z1WUfSTpRge2D55L3U4N8wALAK+QAANoZeAAFG2m4AAA42UgAADkmyA= Content-Language: en-us Subject: Re: [pcp] About PCP Client 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, 19 Jan 2012 18:13:31 -0000 ... > > All of the above is already in the document, and seems to > > cover the situation where the PCP client and the NAT/CGN > > are out of sync. > > > > If there is a problem where they get out of sync which doesn't > > work, please provide the steps that occur to create the sync > > problem. > I think there might be two cases that client and CGN state get out of > sync: > 1. Client has the mappings but CGN already delete them all for some > kind of reason. > 2. Client deletes all the local mappings but CGN still has the > mappings. > > In the 1 case, first of all, the connections of applications that have > mappings will be broken, I do not see an existing solution for this > problem yet, maybe we can suggest that the CGN should send a > notification to the client if mappings are deleted. That's already in the document. Please see the ANNOUNCE Opcode, discussed in http://tools.ietf.org/html/draft-ietf-pcp-base-22#section-13 > In this case, if the client sends a request specifying the external > address, it may fail. It will only fail (return a PCP error response code) if the client includes the PREFER_FAILURE Option. But there isn't a good reason for the PCP client to include the PREFER_FAILURE Option for this case. That is, normal PCP clients have no reason to use the PREFER_FAILURE Option. > I agree this is a problem; it could be fixed together with other > problems. > In the 2 case, there is no problem with client; the client can request > new mappings. In the case where the client has deleted mappings but the CGN still has the mappings, that could only occur if the PCP client has sent delete requests (a MAP request with Lifetime=0) and not received responses. The PCP client is supposed to continue re-transmitting those requests (with a backoff) until it receives a response. Eventually, if the PCP server still never receives those Lifetime=0 requests (e.g., due to path failure), the PCP server will time out the mappings when the lifetime expires. I believe both of the cases are covered by the existing document. -d > > > > -d > > From rpenno@juniper.net Thu Jan 19 11:19:55 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 B5AB521F86A3 for ; Thu, 19 Jan 2012 11:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9nDC4xC8F3Q for ; Thu, 19 Jan 2012 11:19:55 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id F0A2D21F86A2 for ; Thu, 19 Jan 2012 11:19:54 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTxhszDSDg3DxVsaM8ERb6rtWGEebPg4k@postini.com; Thu, 19 Jan 2012 11:19:55 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 19 Jan 2012 11:17:31 -0800 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 19 Jan 2012 11:17:31 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 19 Jan 2012 14:17:26 -0500 From: Reinaldo Penno To: Tina TSOU , Dan Wing , "pcp@ietf.org" Date: Thu, 19 Jan 2012 14:17:24 -0500 Thread-Topic: [pcp] About PCP Client Thread-Index: AczWQwb6z1WUfSTpRge2D55L3U4N8wALAK+QAANoZeAAFG2m4AAA42UgAANCcxk= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.11.0.110726 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] About PCP Client 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, 19 Jan 2012 19:19:55 -0000 That is specifically allowed. Mapping updates (section 13) help when you want to inform that 'I could repair your mappings, here are the new ones'. If you want to inform error conditions that is also allowed. " A PCP client SHOULD be prepared to receive multiple responses from the PCP Server at any time after a single request is sent. This allows the PCP server to inform the client of mapping changes such as an update or deletion. For example, a PCP Server might send a SUCCESS response and, after a configuration change on the PCP Server, later send a NOT_AUTHORIZED response. " On 1/19/12 9:57 AM, "Tina TSOU" wrote: > I think there might be two cases that client and CGN state get out of syn= c: > 1. Client has the mappings but CGN already delete them all for some kind = of > reason. > 2. Client deletes all the local mappings but CGN still has the mappings. >=20 > In the 1 case, first of all, the connections of applications that have > mappings will be broken, I do not see an existing solution for this probl= em > yet, maybe we can suggest that the CGN should send a notification to the > client if mappings are deleted. From Tina.Tsou.Zouting@huawei.com Fri Jan 20 16:04:57 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 A9DE321F869D for ; Fri, 20 Jan 2012 16:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 RRkMJ4g0HNmc for ; Fri, 20 Jan 2012 16:04:57 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [58.251.152.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7EE21F8659 for ; Fri, 20 Jan 2012 16:04:57 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LY4004RBG81TR@szxga03-in.huawei.com> for pcp@ietf.org; Sat, 21 Jan 2012 08:04:49 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LY400CQEG81OI@szxga03-in.huawei.com> for pcp@ietf.org; Sat, 21 Jan 2012 08:04:49 +0800 (CST) Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGL71348; Sat, 21 Jan 2012 08:04:49 +0800 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 21 Jan 2012 08:04:36 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.225]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Sat, 21 Jan 2012 08:04:46 +0800 Date: Sat, 21 Jan 2012 00:04:22 +0000 From: Tina TSOU In-reply-to: X-Originating-IP: [10.193.34.124] To: Reinaldo Penno , Dan Wing , "pcp@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [pcp] About PCP Client Thread-index: AczWQwb6z1WUfSTpRge2D55L3U4N8wALAK+QAANoZeAAFG2m4AAA42UgAANCcxkAPECY8A== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: Re: [pcp] About PCP Client 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, 21 Jan 2012 00:04:57 -0000 Reinaldo, The main purpose of my proposed text is to make sure an application which requires multiple connections can always have the same external IP address, so I think both the client and the server should guarantee this. Tina > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Thursday, January 19, 2012 11:17 AM > To: Tina TSOU; Dan Wing; pcp@ietf.org > Subject: Re: [pcp] About PCP Client > > That is specifically allowed. Mapping updates (section 13) help when you > want to inform that 'I could repair your mappings, here are the new ones'. > If you want to inform error conditions that is also allowed. > > " A PCP client SHOULD be > prepared to receive multiple responses from the PCP Server at any > time after a single request is sent. This allows the PCP server to > inform the client of mapping changes such as an update or deletion. > For example, a PCP Server might send a SUCCESS response and, after a > configuration change on the PCP Server, later send a NOT_AUTHORIZED > response. > " > > > On 1/19/12 9:57 AM, "Tina TSOU" wrote: > > > I think there might be two cases that client and CGN state get out of > sync: > > 1. Client has the mappings but CGN already delete them all for some kind > of > > reason. > > 2. Client deletes all the local mappings but CGN still has the mappings. > > > > In the 1 case, first of all, the connections of applications that have > > mappings will be broken, I do not see an existing solution for this > problem > > yet, maybe we can suggest that the CGN should send a notification to the > > client if mappings are deleted. From fred@cisco.com Fri Jan 20 17:46:20 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 87A4311E8072 for ; Fri, 20 Jan 2012 17:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.438 X-Spam-Level: X-Spam-Status: No, score=-106.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 eURzgGBgAwKy for ; Fri, 20 Jan 2012 17:46:20 -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 0DD4311E8071 for ; Fri, 20 Jan 2012 17:46:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1498; q=dns/txt; s=iport; t=1327110380; x=1328319980; h=mime-version:subject:from:date:cc:message-id:references: to:content-transfer-encoding; bh=P+Z7M8co98hTdmN2iZHvs+1oX19vTOWp2LVI64eroYM=; b=YY2+w2f1lF4RTiEx7A3a93I02vuiy2bPKchMDZUPHwki30XK5bqJy+Oo Htr6Afd5eC9/oNZxyUHFU8cEG5rDozVkVRF84yF7Bb9/KS7yavgk/tCUq FCmpEwu2Wq51/ujzM46soZR/Yr5rndq62uqxJTrk7HqKDMYnni1eKKGzl 4=; X-IronPort-AV: E=Sophos;i="4.71,546,1320624000"; d="scan'208";a="26469966" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 21 Jan 2012 01:46:20 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q0L1kJo8009843; Sat, 21 Jan 2012 01:46:19 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Fri, 20 Jan 2012 17:46:19 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Fri, 20 Jan 2012 17:46:19 -0800 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker Date: Fri, 20 Jan 2012 17:46:07 -0800 Message-Id: <54CCDE50-3933-488E-BAAA-5FF446F6B49E@cisco.com> References: <20120121011843.4102.6878.idtracker@ietfa.amsl.com> To: pcp@ietf.org X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Ron Bonica Subject: [pcp] Fwd: I-D Action: draft-baker-pcp-nptv6-search-00.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: Sat, 21 Jan 2012 01:46:20 -0000 This comes out, in part, from the discussion of what is now section 5 of = RFC 6296. We'd appreciate your comments on it. Begin forwarded message: > From: internet-drafts@ietf.org > Date: January 20, 2012 5:18:43 PM PST > To: i-d-announce@ietf.org > Subject: I-D Action: draft-baker-pcp-nptv6-search-00.txt > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Using PCP to Find an External Address in an = NPTv6 Network > Author(s) : Fred Baker > Dan Wing > Filename : draft-baker-pcp-nptv6-search-00.txt > Pages : 8 > Date : 2012-01-20 >=20 > This note describes an approach to finding the set of External > Addresses associated with an Internal Address. >=20 > Requirements >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-baker-pcp-nptv6-search-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-baker-pcp-nptv6-search-00.txt >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From dthaler@microsoft.com Fri Jan 20 18:17: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 0C69C21F86B8; Fri, 20 Jan 2012 18:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.871 X-Spam-Level: X-Spam-Status: No, score=-103.871 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jUUQ7K8Ci82; Fri, 20 Jan 2012 18:17:45 -0800 (PST) Received: from VA3EHSOBE010.bigfish.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6E121F8637; Fri, 20 Jan 2012 18:17:45 -0800 (PST) Received: from mail190-va3-R.bigfish.com (10.7.14.238) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Sat, 21 Jan 2012 02:17:40 +0000 Received: from mail190-va3 (localhost [127.0.0.1]) by mail190-va3-R.bigfish.com (Postfix) with ESMTP id 9BDBE201DE; Sat, 21 Jan 2012 02:17:41 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzc85fhzz1202hzzz2fhc1bhc31hc1ahc1bhc31hc1ah2a8h668h839h34h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail190-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail190-va3 (localhost.localdomain [127.0.0.1]) by mail190-va3 (MessageSwitch) id 132711226129255_26028; Sat, 21 Jan 2012 02:17:41 +0000 (UTC) Received: from VA3EHSMHS012.bigfish.com (unknown [10.7.14.246]) by mail190-va3.bigfish.com (Postfix) with ESMTP id 020CF3A0220; Sat, 21 Jan 2012 02:17:41 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS012.bigfish.com (10.7.99.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 21 Jan 2012 02:17:37 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.247.5; Fri, 20 Jan 2012 18:17:39 -0800 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.90]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0355.003; Fri, 20 Jan 2012 18:17:39 -0800 From: Dave Thaler To: Jari Arkko , "iesg-secretary@ietf.org" Thread-Topic: Request to publish draft-ietf-pcp-base-22 Thread-Index: AczX4hzxd6a4FYQsR6edZuv0tJ5lPA== Date: Sat, 21 Jan 2012 02:17:38 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B3A0CF3@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: multipart/mixed; boundary="_002_9B57C850BB53634CACEC56EF4853FF653B3A0CF3TK5EX14MBXW603w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "pcp@ietf.org" Subject: [pcp] Request to publish 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, 21 Jan 2012 02:17:47 -0000 --_002_9B57C850BB53634CACEC56EF4853FF653B3A0CF3TK5EX14MBXW603w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jari, This is a request from the PCP WG to consider draft-ietf-pcp-base-22 for publication as a Proposed Standard. The PROTO writeup is attached. -Dave and Alain --_002_9B57C850BB53634CACEC56EF4853FF653B3A0CF3TK5EX14MBXW603w_ Content-Type: text/plain; name="pcp-base-proto.txt" Content-Description: pcp-base-proto.txt Content-Disposition: attachment; filename="pcp-base-proto.txt"; size=8672; creation-date="Thu, 19 Jan 2012 19:34:15 GMT"; modification-date="Thu, 19 Jan 2012 19:48:30 GMT" Content-Transfer-Encoding: base64 ICAoMS5hKSBXaG8gaXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIGZvciB0aGlzIGRvY3VtZW50PyAN Cg0KRGF2ZSBUaGFsZXIgPGR0aGFsZXJAbWljcm9zb2Z0LmNvbT4NCg0KICAgICAgICBIYXMgdGhl DQogICAgICAgIERvY3VtZW50IFNoZXBoZXJkIHBlcnNvbmFsbHkgcmV2aWV3ZWQgdGhpcyB2ZXJz aW9uIG9mIHRoZSANCiAgICAgICAgZG9jdW1lbnQgYW5kLCBpbiBwYXJ0aWN1bGFyLCBkb2VzIGhl IG9yIHNoZSBiZWxpZXZlIHRoaXMgDQogICAgICAgIHZlcnNpb24gaXMgcmVhZHkgZm9yIGZvcndh cmRpbmcgdG8gdGhlIElFU0cgZm9yIHB1YmxpY2F0aW9uPyANCg0KWWVzLg0KDQogICgxLmIpIEhh cyB0aGUgZG9jdW1lbnQgaGFkIGFkZXF1YXRlIHJldmlldyBib3RoIGZyb20ga2V5IFdHIG1lbWJl cnMgDQogICAgICAgIGFuZCBmcm9tIGtleSBub24tV0cgbWVtYmVycz8gDQoNClllcy4NCg0KICAg ICAgICBEb2VzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCBoYXZlIA0KICAgICAgICBhbnkgY29uY2Vy bnMgYWJvdXQgdGhlIGRlcHRoIG9yIGJyZWFkdGggb2YgdGhlIHJldmlld3MgdGhhdCANCiAgICAg ICAgaGF2ZSBiZWVuIHBlcmZvcm1lZD8gIA0KDQpObyBjb25jZXJucy4NCg0KICAoMS5jKSBEb2Vz IHRoZSBEb2N1bWVudCBTaGVwaGVyZCBoYXZlIGNvbmNlcm5zIHRoYXQgdGhlIGRvY3VtZW50IA0K ICAgICAgICBuZWVkcyBtb3JlIHJldmlldyBmcm9tIGEgcGFydGljdWxhciBvciBicm9hZGVyIHBl cnNwZWN0aXZlLCANCiAgICAgICAgZS5nLiwgc2VjdXJpdHksIG9wZXJhdGlvbmFsIGNvbXBsZXhp dHksIHNvbWVvbmUgZmFtaWxpYXIgd2l0aCANCiAgICAgICAgQUFBLCBpbnRlcm5hdGlvbmFsaXph dGlvbiBvciBYTUw/IA0KDQpObyBjb25jZXJucy4gIE1hcmdhcmV0IFdhc3Nlcm1hbiAod2l0aCBh c3Npc3RhbmNlIGZyb20gU2FtIEhhcnRtYW4pIA0KcmV2aWV3ZWQgZm9yIHNlY3VyaXR5IGFuZCBw cm92aWRlZCBtdWNoIG9mIHRoZSBzZWN1cml0eSB0ZXh0IHRoYXQgd2FzIA0KYWRkZWQgdG8gdGhl IGRvY3VtZW50Lg0KDQogICgxLmQpIERvZXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIGhhdmUgYW55 IHNwZWNpZmljIGNvbmNlcm5zIG9yIA0KICAgICAgICBpc3N1ZXMgd2l0aCB0aGlzIGRvY3VtZW50 IHRoYXQgdGhlIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3INCiAgICAgICAgYW5kL29yIHRoZSBJ RVNHIHNob3VsZCBiZSBhd2FyZSBvZj8gDQoNCk5vLg0KDQogICAgICAgIEZvciBleGFtcGxlLCBw ZXJoYXBzIGhlIA0KICAgICAgICBvciBzaGUgaXMgdW5jb21mb3J0YWJsZSB3aXRoIGNlcnRhaW4g cGFydHMgb2YgdGhlIGRvY3VtZW50LCBvciANCiAgICAgICAgaGFzIGNvbmNlcm5zIHdoZXRoZXIg dGhlcmUgcmVhbGx5IGlzIGEgbmVlZCBmb3IgaXQuIEluIGFueSANCiAgICAgICAgZXZlbnQsIGlm IHRoZSBXRyBoYXMgZGlzY3Vzc2VkIHRob3NlIGlzc3VlcyBhbmQgaGFzIGluZGljYXRlZCANCiAg ICAgICAgdGhhdCBpdCBzdGlsbCB3aXNoZXMgdG8gYWR2YW5jZSB0aGUgZG9jdW1lbnQsIGRldGFp bCB0aG9zZSANCiAgICAgICAgY29uY2VybnMgaGVyZS4gDQoNClRoZSBwYXJ0cyBvZiB0aGUgZG9j dW1lbnQgdGhhdCBkaWQgbm90IGhhdmUgY29uc2Vuc3VzIHRvIGJlIGluIHRoZSANCmJhc2Ugc3Bl YyB3ZXJlIGFscmVhZHkgcmVtb3ZlZCBhbmQgbGVmdCBmb3IgY29uc2lkZXJhdGlvbiBhcyBleHRl bnNpb25zLg0KDQogICAgICAgIEhhcyBhbiBJUFIgZGlzY2xvc3VyZSByZWxhdGVkIHRvIHRoaXMg ZG9jdW1lbnQgDQogICAgICAgIGJlZW4gZmlsZWQ/IElmIHNvLCBwbGVhc2UgaW5jbHVkZSBhIHJl ZmVyZW5jZSB0byB0aGUgDQogICAgICAgIGRpc2Nsb3N1cmUgYW5kIHN1bW1hcml6ZSB0aGUgV0cg ZGlzY3Vzc2lvbiBhbmQgY29uY2x1c2lvbiBvbiANCiAgICAgICAgdGhpcyBpc3N1ZS4gDQoNCk5v IElQUiBkaXNjbG9zdXJlcyBoYXZlIGJlZW4gZmlsZWQuDQoNCiAgKDEuZSkgSG93IHNvbGlkIGlz IHRoZSBXRyBjb25zZW5zdXMgYmVoaW5kIHRoaXMgZG9jdW1lbnQ/IERvZXMgaXQgDQogICAgICAg IHJlcHJlc2VudCB0aGUgc3Ryb25nIGNvbmN1cnJlbmNlIG9mIGEgZmV3IGluZGl2aWR1YWxzLCB3 aXRoIA0KICAgICAgICBvdGhlcnMgYmVpbmcgc2lsZW50LCBvciBkb2VzIHRoZSBXRyBhcyBhIHdo b2xlIHVuZGVyc3RhbmQgYW5kIA0KICAgICAgICBhZ3JlZSB3aXRoIGl0Pw0KDQpUaGVyZSBpcyBh IHN0cm9uZyBjb25jdXJyZW5jZSBvZiB0aGUgbW9zdCBhY3RpdmUgaW5kaXZpZHVhbHMsIGFuZCB0 aGUgDQpXRyBhcyBhIHdob2xlIGhhcyBjb25zZW5zdXMgb24gaXQuICBGb3IgZXhhbXBsZSwgbWFu eSBwZW9wbGUgcGFydGljaXBhdGVkIA0KaW4gcG9sbHMgb2YgdGhlIHJvb20gZHVyaW5nIGZhY2Ug dG8gZmFjZSBtZWV0aW5ncywgbm90IGp1c3QgYSBmZXcgaW5kaXZpZHVhbHMuDQoNCiAgKDEuZikg SGFzIGFueW9uZSB0aHJlYXRlbmVkIGFuIGFwcGVhbCBvciBvdGhlcndpc2UgaW5kaWNhdGVkIGV4 dHJlbWUgDQogICAgICAgIGRpc2NvbnRlbnQ/IElmIHNvLCBwbGVhc2Ugc3VtbWFyaXNlIHRoZSBh cmVhcyBvZiBjb25mbGljdCBpbiANCiAgICAgICAgc2VwYXJhdGUgZW1haWwgbWVzc2FnZXMgdG8g dGhlIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3IuIChJdCANCiAgICAgICAgc2hvdWxkIGJlIGlu IGEgc2VwYXJhdGUgZW1haWwgYmVjYXVzZSB0aGlzIHF1ZXN0aW9ubmFpcmUgaXMgDQogICAgICAg IGVudGVyZWQgaW50byB0aGUgSUQgVHJhY2tlci4pIA0KDQpOby4gIER1cmluZyB0aGUgZmlyc3Qg V0dMQywgdHdvIGluZGl2aWR1YWxzIG9iamVjdGVkIHRoYXQgYSBzZXBhcmF0ZSBkcmFmdA0KKG9u IHJhcGlkIHJlY292ZXJ5KSB3YXMgbm90IGZvbGRlZCBpbnRvIHRoZSBiYXNlIHNwZWMuICAgQXMg YSByZXN1bHQNCm9mIFdHIGRpc2N1c3Npb24sIGNvbnNlbnN1cyB3YXMgdG8gZm9sZCBpdCBpbiwg d2hpY2ggd2FzIGRvbmUuICBUaGUgV0dMQyANCndhcyByZXBlYXRlZCBhbmQgbm8gZnVydGhlciB0 aHJlYXRzIG9jY3VycmVkLg0KDQogICgxLmcpIEhhcyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgcGVy c29uYWxseSB2ZXJpZmllZCB0aGF0IHRoZSANCiAgICAgICAgZG9jdW1lbnQgc2F0aXNmaWVzIGFs bCBJRCBuaXRzPyAoU2VlIHRoZSBJbnRlcm5ldC1EcmFmdHMgQ2hlY2tsaXN0IA0KICAgICAgICBh bmQgaHR0cDovL3Rvb2xzLmlldGYub3JnL3Rvb2xzL2lkbml0cy8pLiBCb2lsZXJwbGF0ZSBjaGVj a3MgYXJlIA0KICAgICAgICBub3QgZW5vdWdoOyB0aGlzIGNoZWNrIG5lZWRzIHRvIGJlIHRob3Jv dWdoLiANCg0KWWVzLiAgVGhlIHNoZXBoZXJkIHJhbiBpZG5pdHMgaW4gdmVyYm9zZSBtb2RlIGFu ZCB2ZXJpZmllZCB0aGVyZSB3ZXJlIA0Kbm8gZXJyb3JzLiAgQWxsIHdhcm5pbmdzIGFyZSBmYWxz ZSBwb3NpdGl2ZXMuICBTcGVjaWZpY2FsbHkgaWRuaXRzDQp3YXJuczoNCg0KICAgICgxNTg1KTog TGluZSBoYXMgd2VpcmQgc3BhY2luZzogJy4uLm50ZXJuYWwgIGV4dGVyLi4uJw0KDQpUaGUgYWJv dmUgYXJlIHRhYmxlIGNvbHVtbiBoZWFkZXJzIGFuZCBhcmUgaW50ZW50aW9uYWwuDQoNCiAgICAo MjI1Nik6IEZvdW5kIHBvc3NpYmxlIElQdjQgYWRkcmVzcyAnMTI3LjAuMC4xJyBpbiBwb3NpdGlv biA3OyAuLi4NCiAgICAoMjgwMyk6IEZvdW5kIHBvc3NpYmxlIElQdjQgYWRkcmVzcyAnMTI3LjAu MC4xJyBpbiBwb3NpdGlvbiA0OyAuLi4NCg0KVGhlIGFib3ZlIHJlZmVyIHRvIHRoZSBsb29wYmFj ayBhZGRyZXNzIHNwZWNpZmljYWxseSwgYW5kIHRoaXMgdXNlIGlzIA0KaW50ZW50aW9uYWwuDQoN CiAgICAoMzM0NSk6IEZvdW5kIHBvc3NpYmxlIElQdjQgYWRkcmVzcyAnMjI0LjAuMC4xJyBpbiBw b3NpdGlvbiA0OyAuLi4NCiAgICAoMzM3Myk6IEZvdW5kIHBvc3NpYmxlIElQdjQgYWRkcmVzcyAn MjI0LjAuMC4xJyBpbiBwb3NpdGlvbiA0OyAuLi4NCg0KVGhlIGFib3ZlIHJlZmVyIHRvIHRoZSBz cGVjaWZpYyBtdWx0aWNhc3QgYWRkcmVzcyB1c2VkIGJ5IHRoZSBwcm90b2NvbCwgDQphbmQgdGhp cyB1c2UgaXMgaW50ZW50aW9uYWwuDQoNCiAgICAgICAgSGFzIHRoZSBkb2N1bWVudCANCiAgICAg ICAgbWV0IGFsbCBmb3JtYWwgcmV2aWV3IGNyaXRlcmlhIGl0IG5lZWRzIHRvLCBzdWNoIGFzIHRo ZSBNSUIgDQogICAgICAgIERvY3RvciwgbWVkaWEgdHlwZSBhbmQgVVJJIHR5cGUgcmV2aWV3cz8g DQoNCk4vQS4gIE5vIE1JQiwgbWVkaWEgdHlwZSwgVVJJIHR5cGUsIGV0Yy4gcHJlc2VudCBpbiB0 aGlzIGRvY3VtZW50Lg0KICAgIA0KICAoMS5oKSBIYXMgdGhlIGRvY3VtZW50IHNwbGl0IGl0cyBy ZWZlcmVuY2VzIGludG8gbm9ybWF0aXZlIGFuZCANCiAgICAgICAgaW5mb3JtYXRpdmU/IA0KDQpZ ZXMuDQoNCiAgICAgICAgQXJlIHRoZXJlIG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRvIGRvY3VtZW50 cyB0aGF0IA0KICAgICAgICBhcmUgbm90IHJlYWR5IGZvciBhZHZhbmNlbWVudCBvciBhcmUgb3Ro ZXJ3aXNlIGluIGFuIHVuY2xlYXIgDQogICAgICAgIHN0YXRlPyANCg0KTm8uDQoNCiAgICAgICAg SWYgc3VjaCBub3JtYXRpdmUgcmVmZXJlbmNlcyBleGlzdCwgd2hhdCBpcyB0aGUgDQogICAgICAg IHN0cmF0ZWd5IGZvciB0aGVpciBjb21wbGV0aW9uPyBBcmUgdGhlcmUgbm9ybWF0aXZlIHJlZmVy ZW5jZXMgDQogICAgICAgIHRoYXQgYXJlIGRvd253YXJkIHJlZmVyZW5jZXMsIGFzIGRlc2NyaWJl ZCBpbiBbUkZDMzk2N10/IElmIA0KICAgICAgICBzbywgbGlzdCB0aGVzZSBkb3dud2FyZCByZWZl cmVuY2VzIHRvIHN1cHBvcnQgdGhlIEFyZWEgDQogICAgICAgIERpcmVjdG9yIGluIHRoZSBMYXN0 IENhbGwgcHJvY2VkdXJlIGZvciB0aGVtIFtSRkMzOTY3XS4gDQoNCk5vLg0KDQogICgxLmkpIEhh cyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgdmVyaWZpZWQgdGhhdCB0aGUgZG9jdW1lbnQgSUFOQSAN CiAgICAgICAgY29uc2lkZXJhdGlvbiBzZWN0aW9uIGV4aXN0cyBhbmQgaXMgY29uc2lzdGVudCB3 aXRoIHRoZSBib2R5IA0KICAgICAgICBvZiB0aGUgZG9jdW1lbnQ/IA0KDQpZZXMuDQoNCiAgICAg ICAgSWYgdGhlIGRvY3VtZW50IHNwZWNpZmllcyBwcm90b2NvbCANCiAgICAgICAgZXh0ZW5zaW9u cywgYXJlIHJlc2VydmF0aW9ucyByZXF1ZXN0ZWQgaW4gYXBwcm9wcmlhdGUgSUFOQSANCiAgICAg ICAgcmVnaXN0cmllcz8gIEFyZSB0aGUgSUFOQSByZWdpc3RyaWVzIGNsZWFybHkgaWRlbnRpZmll ZD8gDQoNClllcyAoaW4gc2VjdGlvbiAxNy4xKS4NCg0KICAgICAgICBJZiB0aGUgZG9jdW1lbnQg Y3JlYXRlcyBhIG5ldyByZWdpc3RyeSwgZG9lcyBpdCBkZWZpbmUgdGhlIA0KICAgICAgICBwcm9w b3NlZCBpbml0aWFsIGNvbnRlbnRzIG9mIHRoZSByZWdpc3RyeSBhbmQgYW4gYWxsb2NhdGlvbiAN CiAgICAgICAgcHJvY2VkdXJlIGZvciBmdXR1cmUgcmVnaXN0cmF0aW9ucz8gDQoNClllcyAoaW4g c2VjdGlvbiAxNy4yKS4NCg0KICAgICAgICBEb2VzIGl0IHN1Z2dlc3QgYSANCiAgICAgICAgcmVh c29uYWJsZSBuYW1lIGZvciB0aGUgbmV3IHJlZ2lzdHJ5PyANCg0KDQpZZXMgKCJQQ1AgT3Bjb2Rl cyIpLg0KDQogICAgICAgIFNlZSBbUkZDNTIyNl0uIElmIHRoZSANCiAgICAgICAgZG9jdW1lbnQg ZGVzY3JpYmVzIGFuIEV4cGVydCBSZXZpZXcgcHJvY2VzcyBoYXMgU2hlcGhlcmQgDQogICAgICAg IGNvbmZlcnJlZCB3aXRoIHRoZSBSZXNwb25zaWJsZSBBcmVhIERpcmVjdG9yIHNvIHRoYXQgdGhl IElFU0cgDQogICAgICAgIGNhbiBhcHBvaW50IHRoZSBuZWVkZWQgRXhwZXJ0IGR1cmluZyB0aGUg SUVTRyBFdmFsdWF0aW9uPyANCg0KTi9BIChhbGxvY2F0aW9uIHByb2NlZHVyZSBpcyBub3QgRXhw ZXJ0IFJldmlldykuDQoNCiAgKDEuaikgSGFzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCB2ZXJpZmll ZCB0aGF0IHNlY3Rpb25zIG9mIHRoZSANCiAgICAgICAgZG9jdW1lbnQgdGhhdCBhcmUgd3JpdHRl biBpbiBhIGZvcm1hbCBsYW5ndWFnZSwgc3VjaCBhcyBYTUwgDQogICAgICAgIGNvZGUsIEJORiBy dWxlcywgTUlCIGRlZmluaXRpb25zLCBldGMuLCB2YWxpZGF0ZSBjb3JyZWN0bHkgaW4gDQogICAg ICAgIGFuIGF1dG9tYXRlZCBjaGVja2VyPw0KDQpOL0EgKG5vIGZvcm1hbCBsYW5ndWFnZSBzbmlw cGV0cyBwcmVzZW50KS4NCg0KICAoMS5rKSBUaGUgSUVTRyBhcHByb3ZhbCBhbm5vdW5jZW1lbnQg aW5jbHVkZXMgYSBEb2N1bWVudCANCiAgICAgICAgQW5ub3VuY2VtZW50IFdyaXRlLVVwLiBQbGVh c2UgcHJvdmlkZSBzdWNoIGEgRG9jdW1lbnQgDQogICAgICAgIEFubm91bmNlbWVudCBXcml0ZS1V cD8gUmVjZW50IGV4YW1wbGVzIGNhbiBiZSBmb3VuZCBpbiB0aGUNCiAgICAgICAgIkFjdGlvbiIg YW5ub3VuY2VtZW50cyBmb3IgYXBwcm92ZWQgZG9jdW1lbnRzLiBUaGUgYXBwcm92YWwgDQogICAg ICAgIGFubm91bmNlbWVudCBjb250YWlucyB0aGUgZm9sbG93aW5nIHNlY3Rpb25zOiANCiAgICAg VGVjaG5pY2FsIFN1bW1hcnkgDQogICAgICAgIFJlbGV2YW50IGNvbnRlbnQgY2FuIGZyZXF1ZW50 bHkgYmUgZm91bmQgaW4gdGhlIGFic3RyYWN0IA0KICAgICAgICBhbmQvb3IgaW50cm9kdWN0aW9u IG9mIHRoZSBkb2N1bWVudC4gSWYgbm90LCB0aGlzIG1heSBiZSANCiAgICAgICAgYW4gaW5kaWNh dGlvbiB0aGF0IHRoZXJlIGFyZSBkZWZpY2llbmNpZXMgaW4gdGhlIGFic3RyYWN0IA0KICAgICAg ICBvciBpbnRyb2R1Y3Rpb24uIA0KDQpUaGUgUG9ydCBDb250cm9sIFByb3RvY29sIGFsbG93cyBh biBJUHY2IG9yIElQdjQgaG9zdCB0byBjb250cm9sIGhvdyANCmluY29taW5nIElQdjYgb3IgSVB2 NCBwYWNrZXRzIGFyZSB0cmFuc2xhdGVkIGFuZCBmb3J3YXJkZWQgYnkgYSBuZXR3b3JrIA0KYWRk cmVzcyB0cmFuc2xhdG9yIChOQVQpIG9yIHNpbXBsZSBmaXJld2FsbCwgYW5kIGFsc28gYWxsb3dz IGEgaG9zdCB0byANCm9wdGltaXplIGl0cyBvdXRnb2luZyBOQVQga2VlcGFsaXZlIG1lc3NhZ2Vz Lg0KDQogICAgIFdvcmtpbmcgR3JvdXAgU3VtbWFyeSANCiAgICAgICAgV2FzIHRoZXJlIGFueXRo aW5nIGluIFdHIHByb2Nlc3MgdGhhdCBpcyB3b3J0aCBub3Rpbmc/IEZvciANCiAgICAgICAgZXhh bXBsZSwgd2FzIHRoZXJlIGNvbnRyb3ZlcnN5IGFib3V0IHBhcnRpY3VsYXIgcG9pbnRzIG9yIA0K ICAgICAgICB3ZXJlIHRoZXJlIGRlY2lzaW9ucyB3aGVyZSB0aGUgY29uc2Vuc3VzIHdhcyBwYXJ0 aWN1bGFybHkgDQogICAgICAgIHJvdWdoPyANCg0KQXQgdGhlIG91dHNldCwgdGhlIFdHIGxvb2tl ZCBhdCBtYW55IG90aGVyIHByb3RvY29scyB0aGF0IGhhdmUgYmVlbiANCnByb3Bvc2VkIGluIHRo ZSBwYXN0IGZvciBkb2luZyBzaW1pbGFyIHRoaW5ncywgYnV0IGFsbW9zdCBub25lIGhhdmUgDQpi ZWVuIHN1Y2Nlc3NmdWwgaW4gZ2V0dGluZyByZWFsIGRlcGxveW1lbnQuICBUaGUgZXhjZXB0aW9u cyBhcmUgTkFULVBNUCANCmFuZCBVUG5QLUlHRC4gIEJldHdlZW4gdGhlbSwgdGhlIFdHIGNvbmNs dWRlZCB0aGF0IE5BVC1QTVAgd2FzIG1vcmUgDQpjbG9zZWx5IGFsaWduZWQgd2l0aCB0aGUgaW50 ZW5kZWQgc2NlbmFyaW9zIGFuZCBoZW5jZSB1c2VkIE5BVC1QTVAgDQphcyB0aGUgc3RhcnRpbmcg cG9pbnQgZm9yIFBDUC4NCg0KICAgICBEb2N1bWVudCBRdWFsaXR5IA0KICAgICAgICBBcmUgdGhl cmUgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBwcm90b2NvbD8gSGF2ZSBhIA0KICAg ICAgICBzaWduaWZpY2FudCBudW1iZXIgb2YgdmVuZG9ycyBpbmRpY2F0ZWQgdGhlaXIgcGxhbiB0 byANCiAgICAgICAgaW1wbGVtZW50IHRoZSBzcGVjaWZpY2F0aW9uPyANCg0KU2V2ZXJhbCBQQ1Ag aW1wbGVtZW50YXRpb25zIGV4aXN0LCBhbmQgc29tZSBpbnRlcm9wZXJhYmlsaXR5IHRlc3Rpbmcg DQpoYXMgYWxyZWFkeSBiZWVuIGRvbmUuDQoNCiAgICAgICAgQXJlIHRoZXJlIGFueSByZXZpZXdl cnMgdGhhdCANCiAgICAgICAgbWVyaXQgc3BlY2lhbCBtZW50aW9uIGFzIGhhdmluZyBkb25lIGEg dGhvcm91Z2ggcmV2aWV3LCANCiAgICAgICAgZS5nLiwgb25lIHRoYXQgcmVzdWx0ZWQgaW4gaW1w b3J0YW50IGNoYW5nZXMgb3IgYSANCiAgICAgICAgY29uY2x1c2lvbiB0aGF0IHRoZSBkb2N1bWVu dCBoYWQgbm8gc3Vic3RhbnRpdmUgaXNzdWVzPyANCg0KTWFyZ2FyZXQgV2Fzc2VybWFuIGRpZCBh IHRob3JvdWdoIHNlY3VyaXR5IGFuYWx5c2lzIGFuZCB3cm90ZSB0aGUgDQpzZWN1cml0eSBjb25z aWRlcmF0aW9ucyBzZWN0aW9uLg0KDQpNYW55IG90aGVycyAoYmV5b25kIHRoZSBhdXRob3JzIHRo ZW1zZWx2ZXMpLCBpbmNsdWRpbmcgYSBudW1iZXIgb2YgDQppbXBsZW1lbnRlcnMsIGhhdmUgYWxz byBkb25lIHJldmlld3MgYW5kIGFyZSBhY2tub3dsZWRnZWQgaW4gdGhlIGRvY3VtZW50Lg0KDQog ICAgICAgIElmIA0KICAgICAgICB0aGVyZSB3YXMgYSBNSUIgRG9jdG9yLCBNZWRpYSBUeXBlIG9y IG90aGVyIGV4cGVydCByZXZpZXcsIA0KICAgICAgICB3aGF0IHdhcyBpdHMgY291cnNlIChicmll Zmx5KT8gSW4gdGhlIGNhc2Ugb2YgYSBNZWRpYSBUeXBlIA0KICAgICAgICByZXZpZXcsIG9uIHdo YXQgZGF0ZSB3YXMgdGhlIHJlcXVlc3QgcG9zdGVkPyANCg0KTi9BIChubyBNSUIgb3IgTWVkaWEg VHlwZSkuDQo= --_002_9B57C850BB53634CACEC56EF4853FF653B3A0CF3TK5EX14MBXW603w_-- From jari.arkko@piuha.net Sun Jan 22 14:34:16 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 26DED21F859B for ; Sun, 22 Jan 2012 14:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tGG9p3hT96V for ; Sun, 22 Jan 2012 14:34:15 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 874FE21F859A for ; Sun, 22 Jan 2012 14:34:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9617D2CC44; Mon, 23 Jan 2012 00:34:08 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Chspqaj-D_rX; Mon, 23 Jan 2012 00:34:08 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 7C8D92CC39; Mon, 23 Jan 2012 00:34:07 +0200 (EET) Message-ID: <4F1C8EDE.3020008@piuha.net> Date: Sun, 22 Jan 2012 23:34:06 +0100 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: Dave Thaler References: <9B57C850BB53634CACEC56EF4853FF653B3A0CF3@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B3A0CF3@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pcp@ietf.org" Subject: Re: [pcp] Request to publish 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, 22 Jan 2012 22:34:16 -0000 Great - thank you. I will do an AD review on this soon. Jari On 21.01.2012 03:17, Dave Thaler wrote: > Hi Jari, > > This is a request from the PCP WG to consider draft-ietf-pcp-base-22 > for publication as a Proposed Standard. The PROTO writeup is attached. > > -Dave and Alain > From ext-felipe.m.costa@nokia.com Tue Jan 24 15:15: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 17EFA11E809A for ; Tue, 24 Jan 2012 15:15:18 -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 cpUMdAZo8kpo for ; Tue, 24 Jan 2012 15:15:17 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6B611E8086 for ; Tue, 24 Jan 2012 15:15:17 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0ONEsN7012507 for ; Wed, 25 Jan 2012 01:15:14 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Jan 2012 01:15:06 +0200 Received: from 008-AM1MPN1-014.mgdnok.nokia.com ([169.254.4.203]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.01.0355.003; Wed, 25 Jan 2012 00:15:05 +0100 From: To: Thread-Topic: Doubt regarding port consumption protection Thread-Index: Acza7QNzro61/A6cT3yi+SktbYEMdg== Date: Tue, 24 Jan 2012 23:15:04 +0000 Message-ID: <0412136DF48FC94A9795E62ECFC014650E5F54DC@008-AM1MPN1-014.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-headerinfofordlp: None x-titus-version: 3.3.8.1 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-tituslabs-classificationhash-30: 3Z1aE72pwhYZdCxOu/Iwj30f8uU2+P3x3SSXR3HmucJ2fGdU7zBxjMUSGyG35D2kCsfoxhyKfojeorGImiX//pvhG00WeXpEOXw5Xwk+LDB1/JQ6KpvBQjfYzpTi38a8VGWeJRZSareLYtSgXPMMNxPbLtEncpa1eYvgIBDGWkqKpUXKoFAC27YkyopslLOm35B2Prz/dZWDqC//Wv72ry7Wx4ERXlmCw1sZcIOy9mYJXP97noQ1t9fO0ZiZCWSP x-originating-ip: [200.141.73.235] Content-Type: multipart/alternative; boundary="_000_0412136DF48FC94A9795E62ECFC014650E5F54DC008AM1MPN1014mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 24 Jan 2012 23:15:06.0181 (UTC) FILETIME=[02415750:01CCDAEE] X-Nokia-AV: Clean Subject: [pcp] Doubt regarding port consumption protection 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, 24 Jan 2012 23:15:18 -0000 --_000_0412136DF48FC94A9795E62ECFC014650E5F54DC008AM1MPN1014mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I have a doubt regarding the following aspect: (in chapter 10.5, page 44, 2= nd paragraph) PCP provides some protections against such port consumption: When a PCP client first acquires a new IP address (e.g., reboots or joins a new network), it SHOULD remove mappings that may already be instantiated for that new Internal Address. To do this, the PCP client sends a MAP request with protocol, internal port, and lifetime set to 0. Specifically thinking in the PCP Client side, does it mean that the PCP Cli= ent, in the aforementioned condition, should send a deletion request and wa= it for its response before it sends any additional request? Thanks in advance, Felipe --_000_0412136DF48FC94A9795E62ECFC014650E5F54DC008AM1MPN1014mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

I have a doubt regarding the following aspect: (in c= hapter 10.5, page 44, 2nd paragraph)

 =

 =

PCP provide= s some protections against such port

  = ; consumption: When a PCP client first acquires a new IP address (e.g.,

  = ; reboots or joins a new network), it SHOULD remove mappings that may<= /o:p>

  = ; already be instantiated for that new Internal Address.  To do this,<= o:p>

  = ; the PCP client sends a MAP request with protocol, internal port, and=

  = ; lifetime set to 0.

 

Specifically thinking in the PCP Client side, does i= t mean that the PCP Client, in the aforementioned condition, should send a = deletion request and wait for its response before it sends any additional r= equest?

 

Thanks in advance,

 

Felipe

 

--_000_0412136DF48FC94A9795E62ECFC014650E5F54DC008AM1MPN1014mg_-- From dwing@cisco.com Fri Jan 27 11:59:20 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 A5F4821F85D2; Fri, 27 Jan 2012 11:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.278 X-Spam-Level: X-Spam-Status: No, score=-106.278 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 9fZfDtM9zs4y; Fri, 27 Jan 2012 11:59:20 -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 059A621F85BD; Fri, 27 Jan 2012 11:59:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2191; q=dns/txt; s=iport; t=1327694360; x=1328903960; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=4iP71SayWxHTJ7P6QfTflKS0Rix2A/csyPPvgdKiMVE=; b=eIUSJMu4LhNj99AS+7DhdZ3Mu5BphSX4NSetX7U0sAFl8xeS8h3dqfkE LA/axy4YVvJGFNIgCtiVpxYrVmcWbY7x85CT8LkJ8QQ+Oz7m1tK+86IP0 2shIR/by4rP6zQJEKzypwEn53JAhEUbM3V5dZLoB3YSgcz7RurjvVy0+8 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOABI0+rRDoI/2dsb2JhbABEn12OdoEFgXkICgEXED8NBRhQIxwBBB4Xh2KZZAGeOwSJEAEkCycRAg4BhBM3gzsEiD+FBJpF X-IronPort-AV: E=Sophos;i="4.71,582,1320624000"; d="scan'208";a="27487979" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 27 Jan 2012 19:59:12 +0000 Received: from dwingWS ([10.32.240.197]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0RJxCHP006021; Fri, 27 Jan 2012 19:59:12 GMT From: "Dan Wing" To: "'v6ops'" Date: Fri, 27 Jan 2012 11:59:12 -0800 Message-ID: <169401ccdd2e$23b48910$6b1d9b30$@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: AczdLiNo+NvlTE2QQH2IlmZasEPwAg== Content-Language: en-us Cc: pcp@ietf.org, draft-ietf-v6ops-6204bis@tools.ietf.org Subject: [pcp] 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: Fri, 27 Jan 2012 19:59:20 -0000 v6ops, I was reading over draft-ietf-v6ops-6204bis today and have a suggestion. Background: RFC6092 is v6ops's Simple CPE Security document, which recommends that a protocol be used to allow a passive listener (e.g., web camera) to open a pinhole. In that document, James Woodyatt's ALD was suggested as a possible candidate protocol for that function. But I see that both the old RFC6204 and draft-ietf-v6ops-6204bis-05 say this (I added uppercase for emphasis): S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, the IPv6 CE router SHOULD support functionality sufficient for implementing the set of recommendations in [RFC6092], Section 4. This document takes no position on whether such functionality is enabled by default OR MECHANISMS BY WHICH USERS WOULD CONFIGURE IT. I would like draft-ietf-v6ops-6204bis to take the position that Port Control Protocol (PCP) be the protocol for the uppercased function. Stated more clearly, I would like the above paragraph to read: S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, the IPv6 CE router SHOULD support functionality sufficient for implementing the set of recommendations in [RFC6092], Section 4. This document takes no position on whether such functionality is enabled by default. The IPv6 CE router ...............................................^^^^^^^^^^^^^^^^^^ SHOULD implement a PCP server [I-D.ietf-pcp-base] so that .........^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ hosts can configure this functionality. .........^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If you need more background, please be sure to read both REQ-48 and REQ-49 of RFC6092. PCP would be a specific protocol that fulfills REQ-49. In anticipation of one of the earlier objections that making PCP a normative requirement would delay draft-ietf-v6ops-6204bis, https://datatracker.ietf.org/doc/draft-ietf-pcp-base shows the document status is Publication Requested because the PCP working group finished its WGLC on the document. -d From bs7652@att.com Fri Jan 27 12:18:26 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 8DC8421F8677; Fri, 27 Jan 2012 12:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 5-u80Qxmxxoi; Fri, 27 Jan 2012 12:18:25 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 8E08B21F8517; Fri, 27 Jan 2012 12:18:25 -0800 (PST) X-Env-Sender: bs7652@att.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1327695504!12743523!1 X-Originating-IP: [144.160.20.146] X-StarScan-Version: 6.4.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3051 invoked from network); 27 Jan 2012 20:18:24 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-5.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Jan 2012 20:18:24 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q0RKGrhD015847; Fri, 27 Jan 2012 15:16:53 -0500 Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q0RKGlYS015694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jan 2012 15:16:47 -0500 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (gaalpa1msghub9e.itservices.sbc.com [130.8.36.91]) by sflint03.pst.cso.att.com (RSA Interceptor); Fri, 27 Jan 2012 15:18:01 -0500 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.206]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.01.0355.002; Fri, 27 Jan 2012 15:18:01 -0500 From: "STARK, BARBARA H" To: "'dwing@cisco.com'" , "'v6ops@ietf.org'" Thread-Topic: [v6ops] PCP server in draft-ietf-v6ops-6204bis Thread-Index: AczdLiNo+NvlTE2QQH2IlmZasEPwAgAAqESi Date: Fri, 27 Jan 2012 20:18:01 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611025315@GAALPA1MSGUSR9N.ITServices.sbc.com> In-Reply-To: <169401ccdd2e$23b48910$6b1d9b30$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.8.36.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Mailman-Approved-At: Fri, 27 Jan 2012 12:21:44 -0800 Cc: "'pcp@ietf.org'" , "'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: Fri, 27 Jan 2012 20:18:26 -0000 I disagree.=20 I believe the marketplace should determine the winning technology in this c= ase, if there is to be a winning technology. RFC6204bis needs to continue t= o take no position.=20 Just because other solutions weren't created by IETF doesn't mean they are = any less good.=20 Barbara ----- Original Message ----- From: Dan Wing [mailto:dwing@cisco.com] Sent: Friday, January 27, 2012 02:59 PM=0A= To: 'v6ops' Cc: pcp@ietf.org ; draft-ietf-v6ops-6204bis@tools.ietf.org Subject: [v6ops] PCP server in draft-ietf-v6ops-6204bis v6ops, I was reading over draft-ietf-v6ops-6204bis today and have a=20 suggestion. Background: RFC6092 is v6ops's Simple CPE Security document, which=20 recommends that a protocol be used to allow a passive listener (e.g.,=20 web camera) to open a pinhole. In that document, James Woodyatt's=20 ALD was suggested as a possible candidate protocol for that function. But I see that both the old RFC6204 and draft-ietf-v6ops-6204bis-05 say this (I added uppercase for emphasis):=09 S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, the IPv6 CE router SHOULD support functionality sufficient for implementing the set of recommendations in [RFC6092], Section 4. This document takes no position on whether such functionality is enabled by default OR MECHANISMS BY WHICH=20 USERS WOULD CONFIGURE IT. I would like draft-ietf-v6ops-6204bis to take the position that=20 Port Control Protocol (PCP) be the protocol for the uppercased function. Stated more clearly, I would like the above paragraph to read: S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, the IPv6 CE router SHOULD support functionality sufficient for implementing the set of recommendations in [RFC6092], Section 4. This document takes no position on whether such functionality is enabled by default. The IPv6 CE router=20 ...............................................^^^^^^^^^^^^^^^^^^ SHOULD implement a PCP server [I-D.ietf-pcp-base] so that .........^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ hosts can configure this functionality. .........^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If you need more background, please be sure to read both REQ-48 and REQ-49 of RFC6092. PCP would be a specific protocol that fulfills REQ-49. In anticipation of one of the earlier objections that making PCP a normativ= e requirement would delay draft-ietf-v6ops-6204bis, https://datatracker.ietf.org/doc/draft-ietf-pcp-base shows the document status is Publication Requested because the PCP working group finished its WGLC on the document. -d _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From simon.perreault@viagenie.ca Fri Jan 27 12:49: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 5137521F86D5; Fri, 27 Jan 2012 12:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyqeZYb17ZPU; Fri, 27 Jan 2012 12:49:57 -0800 (PST) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id B7A9021F8664; Fri, 27 Jan 2012 12:49:57 -0800 (PST) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:d74:bb6d:ddaf:2764]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E742E21F82; Fri, 27 Jan 2012 15:49:56 -0500 (EST) Message-ID: <4F230DF4.4040808@viagenie.ca> Date: Fri, 27 Jan 2012 15:49:56 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: "STARK, BARBARA H" References: <2D09D61DDFA73D4C884805CC7865E611025315@GAALPA1MSGUSR9N.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611025315@GAALPA1MSGUSR9N.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'v6ops@ietf.org'" , "'pcp@ietf.org'" , "'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: Fri, 27 Jan 2012 20:49:58 -0000 On 2012-01-27 15:18, STARK, BARBARA H wrote: > Just because other solutions weren't created by IETF doesn't mean they are any less good. Right. They are less good because PCP is better. Sorry, couldn't resist. ;) Seriously: We already have consensus on a "SHOULD implement a PCP server" in draft-ietf-behave-lsn-requirements. I think we should also have it on the CPE. Having only one protocol to support would make it so much easier for application developers! Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From dwing@cisco.com Fri Jan 27 12:54:37 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 983A221F86E3; Fri, 27 Jan 2012 12:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.27 X-Spam-Level: X-Spam-Status: No, score=-106.27 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 oTXcHt2gbnJg; Fri, 27 Jan 2012 12:54:36 -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 CDE7821F86DD; Fri, 27 Jan 2012 12:54:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4108; q=dns/txt; s=iport; t=1327697676; x=1328907276; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=u8eOj26ml+RWa/4nS+vwmvOsZSJGSaYNweKGWnPOtzo=; b=DVX/gtR5bv6GSzVOUb1Qlnu7r5QAY/l0i20W0CI4BH7ZgSwcfoqmXEFO csXl3l22mDOuc2/b1wWuvBsdLCje1213h8JOIbDpU1SaDeyEjRb964kpI rNfpMdNur1EibuLZTu2lYH49fNrAp9DehvUlVqMkPHFpQn+bGsHaEJt7U k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAI4OI0+rRDoG/2dsb2JhbABEn16OdoEFgXIBAQEDAQEBAQUKARcQNAsFBwEDAgkPAgQBASgHGQ4VCgkIAQEEARILEAeHWgiZYAGeOASJEAEkCycRAg+EEzeDOwSIP4UEmkU X-IronPort-AV: E=Sophos;i="4.71,582,1320624000"; d="scan'208";a="25814058" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 27 Jan 2012 20:54:36 +0000 Received: from dwingWS ([10.32.240.197]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0RKsad7020154; Fri, 27 Jan 2012 20:54:36 GMT From: "Dan Wing" To: "'STARK, BARBARA H'" , References: <169401ccdd2e$23b48910$6b1d9b30$@com> <2D09D61DDFA73D4C884805CC7865E611025315@GAALPA1MSGUSR9N.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611025315@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Fri, 27 Jan 2012 12:54:36 -0800 Message-ID: <16ef01ccdd35$e0f5ebc0$a2e1c340$@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: AczdLiNo+NvlTE2QQH2IlmZasEPwAgAAqESiAAEndkA= Content-Language: en-us Cc: pcp@ietf.org, 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: Fri, 27 Jan 2012 20:54:37 -0000 > -----Original Message----- > From: STARK, BARBARA H [mailto:bs7652@att.com] > Sent: Friday, January 27, 2012 12:18 PM > To: 'dwing@cisco.com'; 'v6ops@ietf.org' > Cc: 'pcp@ietf.org'; 'draft-ietf-v6ops-6204bis@tools.ietf.org' > Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis > > I disagree. > I believe the marketplace should determine the winning technology in > this case, if there is to be a winning technology. RFC6204bis needs to > continue to take no position. > > Just because other solutions weren't created by IETF doesn't mean they > are any less good. I suppose you are referring to UPnP IGD 2, which added IPv6 firewall support (among other things of less interest to v6ops). If it said "or UPnP IGD 2", would you still object or would that be acceptable? Right now, the text allows any sorts of thing -- including a web portal operated by the ISP, Web UI on the CPE itself, CLI on the CPE (accessed via ssh or telnet), holding a little red button in the back for 3 seconds to allow port 80 or 30 seconds to allow port 443, or whatever someone wants to design and claim compliance. This sort of free-for-all seems incongruent with Internet and IPv6 going into billions of homes and businesses and a standards-making organization such as the IETF. -d > Barbara > > ----- Original Message ----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Friday, January 27, 2012 02:59 PM > To: 'v6ops' > Cc: pcp@ietf.org ; draft-ietf-v6ops- > 6204bis@tools.ietf.org > Subject: [v6ops] PCP server in draft-ietf-v6ops-6204bis > > v6ops, > > I was reading over draft-ietf-v6ops-6204bis today and have a > suggestion. > > Background: RFC6092 is v6ops's Simple CPE Security document, which > recommends that a protocol be used to allow a passive listener (e.g., > web camera) to open a pinhole. In that document, James Woodyatt's > ALD was suggested as a possible candidate protocol for that function. > > But I see that both the old RFC6204 and draft-ietf-v6ops-6204bis-05 > say this (I added uppercase for emphasis): > > S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, > the IPv6 CE router SHOULD support functionality sufficient for > implementing the set of recommendations in [RFC6092], > Section 4. This document takes no position on whether such > functionality is enabled by default OR MECHANISMS BY WHICH > USERS WOULD CONFIGURE IT. > > > I would like draft-ietf-v6ops-6204bis to take the position that > Port Control Protocol (PCP) be the protocol for the uppercased > function. > > Stated more clearly, I would like the above paragraph to read: > > S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, > the IPv6 CE router SHOULD support functionality sufficient for > implementing the set of recommendations in [RFC6092], > Section 4. This document takes no position on whether such > functionality is enabled by default. The IPv6 CE router > ...............................................^^^^^^^^^^^^^^^^^^ > SHOULD implement a PCP server [I-D.ietf-pcp-base] so that > .........^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > hosts can configure this functionality. > .........^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > If you need more background, please be sure to read both REQ-48 and > REQ-49 > of RFC6092. PCP would be a specific protocol that fulfills REQ-49. > > > In anticipation of one of the earlier objections that making PCP a > normative > requirement would delay draft-ietf-v6ops-6204bis, > https://datatracker.ietf.org/doc/draft-ietf-pcp-base shows the document > status is Publication Requested because the PCP working group finished > its > WGLC on the document. > > -d > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jhw@apple.com Sun Jan 29 09:51:54 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 64FC321F859B; Sun, 29 Jan 2012 09:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[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 P7c-GgRZghCi; Sun, 29 Jan 2012 09:51:53 -0800 (PST) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id E163221F858F; Sun, 29 Jan 2012 09:51:53 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_/EjFAwBgv5Eye98+843R4A)" Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0LYK00MMXMYEFM00@mail-out.apple.com>; Sun, 29 Jan 2012 09:51:53 -0800 (PST) X-AuditID: 1180711d-b7b41ae000004823-3f-4f258738334b Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 40.58.18467.937852F4; Sun, 29 Jan 2012 09:51:53 -0800 (PST) From: james woodyatt In-reply-to: <201201291608.q0TG8oCF098440@givry.fdupont.fr> Date: Sun, 29 Jan 2012 09:51:52 -0800 Message-id: <85BE2EBF-C8AC-45E1-BF93-1E3066AD3172@apple.com> References: <201201291608.q0TG8oCF098440@givry.fdupont.fr> To: Francis Dupont X-Mailer: Apple Mail (2.1251.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUieJDXQdeyXdXfoG2OmMXNqxdZLB5N28lq 0bbhFYvF5GO/WS1OH9vL7MDqMeX3RlaPd1P/sHosWfKTyePL5c9sASxRXDYpqTmZZalF+nYJ XBnHjh5hLfgsXfF+UkID42aJLkZODgkBE4l/d26wQdhiEhfurQeyuTiEBGYzSdyZfI8RJCEs YC2xt/0RK4jNK2AssebWOxYQm1kgQeLroyawOJuAisS3y3eZQGxOoPqzH3eB1bAIqEq03W9l hKivkFi9aTk7xBwbiUVth8HqhQSsJDY96QCLiwjoSby7epAd4iB5iZavd9gmMPLNQrJ6FpLV ELa2xLKFr5lnMXIA2ToSkxcyogpD2B/PH2FawMi2ilGwKDUnsdLQWC+xoCAnVS85P3cTIyio GwpldzDu/8l/iFGAg1GJh/fkUhV/IdbEsuLK3EOMEhzMSiK8jjOBQrwpiZVVqUX58UWlOanF hxilOViUxHk3WSv7CwmkJ5akZqemFqQWwWSZODilGhjj51qvnXvP8cDMFW4C/40emhtfvTL1 +aL42Sure+MUV1ycd5HJey0TP2/6P9W5WYlsGn+sDv/Q6JjaN+Vc78kdrLnbLfnkra5P19/J dfZI5uqHPi+P3iy4edDZdt3xw3bvKm2fM7me4E0uv79OMObZlpYKlg/Fm+8s+/DW9E3JapeU 3A9qvEt2KrEUZyQaajEXFScCAMd/JlRmAgAA Cc: v6ops@ietf.org, pcp@ietf.org, "Ole Troan \(otroan\)" , 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: Sun, 29 Jan 2012 17:51:54 -0000 --Boundary_(ID_/EjFAwBgv5Eye98+843R4A) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Jan 29, 2012, at 08:08 , Francis Dupont wrote: > > UPnP IGD v2 does the job, it was just published after the PCP effort beginning. Was it published under terms that permit IETF to cite it in a standards track document as a normative requirement? This has, in the past, been a problem with UPnP IGDv1. -- j h woodyatt --Boundary_(ID_/EjFAwBgv5Eye98+843R4A) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
UPnP IGD v2 = does the job, it was just published after the PCP = effort beginning.

Was it = published under terms that permit IETF to cite it in a standards track = document as a normative requirement?  This has, in the past, been a = problem with UPnP IGDv1.


--
j h woodyatt <jhw@apple.com>

= --Boundary_(ID_/EjFAwBgv5Eye98+843R4A)-- From jari.arkko@piuha.net Mon Jan 30 07:15:01 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 8461621F858B for ; Mon, 30 Jan 2012 07:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xm5FrXP3Z28B for ; Mon, 30 Jan 2012 07:15:00 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB9E21F84F7 for ; Mon, 30 Jan 2012 07:15:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 512C32CDC4; Mon, 30 Jan 2012 17:14:59 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42Tlmv8kQPdu; Mon, 30 Jan 2012 17:14:58 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 541B42CC39; Mon, 30 Jan 2012 17:14:58 +0200 (EET) Message-ID: <4F26B3F1.3040908@piuha.net> Date: Mon, 30 Jan 2012 17:14:57 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: draft-ietf-pcp-base@tools.ietf.org, "pcp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pcp] AD review of draft-ietf-pcp-base (part 1) 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, 30 Jan 2012 15:15:01 -0000 I have reviewed the first part of this draft, up until about page 30. Here are my comments: In general, I have found that the spec is very well written and I found no technical issues. It was a pleasure to read, and while I made some notes as I read it on, I was mostly able to delete my notes as I found the answers later. Thank you for writing this well. Technical: None Editorial: > Checking nits according to http://www.ietf.org/id-info/checklist : > ---------------------------------------------------------------------------- > > == There are 2 instances of lines with non-RFC5735-compliant IPv4 addresses > in the document. If these are example addresses, they should be changed. > > == There are 2 instances of lines with multicast IPv4 addresses in the > document. If these are generic example addresses, they should be changed > to use the 233.252.0.x range defined in RFC 5771 > > > Miscellaneous warnings: > ---------------------------------------------------------------------------- > > == Line 1260 has weird spacing: '...nternal exter...' Please check these. > Each error code below is classified as either a 'long > lifetime' error or a 'short lifetime' error, which provides guidance > to PCP server developers for the value of the Lifetime field for > these errors. It is RECOMMENDED that short lifetime errors use a 30 > second lifetime and long lifetime errors use a 30 minute lifetime. > > 0 SUCCESS: Success. > > 1 UNSUPP_VERSION: Unsupported protocol version. > > 2 NOT_AUTHORIZED: The requested operation is disabled for this PCP > client, or the PCP client requested an operation that cannot be > fulfilled by the PCP server's security policy. This is a long > lifetime error. > > 3 MALFORMED_REQUEST: The request could not be successfully parsed. > > 4 UNSUPP_OPCODE: Unsupported Opcode. > > 5 UNSUPP_OPTION: Unsupported Option. This error only occurs if the > Option is in the mandatory-to-process range. > > 6 MALFORMED_OPTION: Malformed Option (e.g., appears too many times, > invalid length). > > 7 NETWORK_FAILURE: The PCP server or the device it controls are > experiencing a network failure of some sort (e.g., has not > obtained an External IP address). This is a short lifetime error. > The error codes have not all been categorized to short/long. Please clarify. > 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 and the timer is doubled (to 4 seconds). The last part should be "... first to 4 seconds ...", I think. Jari From dthaler@microsoft.com Mon Jan 30 09:50:45 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 B414421F8607 for ; Mon, 30 Jan 2012 09:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.971 X-Spam-Level: X-Spam-Status: No, score=-103.971 tagged_above=-999 required=5 tests=[AWL=-0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3C+E+N5-8Gvc for ; Mon, 30 Jan 2012 09:50:43 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id C121D21F84AA for ; Mon, 30 Jan 2012 09:50:40 -0800 (PST) Received: from mail162-ch1-R.bigfish.com (10.43.68.230) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.23; Mon, 30 Jan 2012 17:50:40 +0000 Received: from mail162-ch1 (localhost [127.0.0.1]) by mail162-ch1-R.bigfish.com (Postfix) with ESMTP id 16DFC2A0187; Mon, 30 Jan 2012 17:50:40 +0000 (UTC) X-SpamScore: -20 X-BigFish: VS-20(z1725nz1432Nzz1202hzz1033IL8275dhz2fhc1bhc31hc1ah2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail162-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail162-ch1 (localhost.localdomain [127.0.0.1]) by mail162-ch1 (MessageSwitch) id 1327945838492757_22015; Mon, 30 Jan 2012 17:50:38 +0000 (UTC) Received: from CH1EHSMHS028.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.228]) by mail162-ch1.bigfish.com (Postfix) with ESMTP id 740164A0045; Mon, 30 Jan 2012 17:50:38 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS028.bigfish.com (10.43.70.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 30 Jan 2012 17:50:37 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.2.247.5; Mon, 30 Jan 2012 09:50:28 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) with Microsoft SMTP Server (TLS) id 14.1.355.3; Mon, 30 Jan 2012 09:50:26 -0800 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.234]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0355.003; Mon, 30 Jan 2012 09:50:26 -0800 From: Dave Thaler To: Jari Arkko , "draft-ietf-pcp-base@tools.ietf.org" , "pcp@ietf.org" Thread-Topic: [pcp] AD review of draft-ietf-pcp-base (part 1) Thread-Index: AQHM32H0ne75CYKnN0O/zxU99qNFT5YlMEIQ Date: Mon, 30 Jan 2012 17:50:25 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B3C77B1@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <4F26B3F1.3040908@piuha.net> In-Reply-To: <4F26B3F1.3040908@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [pcp] AD review of draft-ietf-pcp-base (part 1) 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, 30 Jan 2012 17:50:45 -0000 > > Checking nits according to http://www.ietf.org/id-info/checklist : > > --------------------------------------------------------------------= -------- > > > > =3D=3D There are 2 instances of lines with non-RFC5735-compliant IPv= 4 > addresses > > in the document. If these are example addresses, they should be = changed. > > > > =3D=3D There are 2 instances of lines with multicast IPv4 addresses = in the > > document. If these are generic example addresses, they should be= changed > > to use the 233.252.0.x range defined in RFC 5771 > > > > > > Miscellaneous warnings: > > --------------------------------------------------------------------= -------- > > > > =3D=3D Line 1260 has weird spacing: '...nternal exter...' >=20 > Please check these. Please see (1.g) of the PROTO writeup. -Dave From jhw@apple.com Mon Jan 30 11:16:52 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 BB82321F8540; Mon, 30 Jan 2012 11:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, SARE_BAYES_5x7=0.6, 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 IjMfWKc74yOm; Mon, 30 Jan 2012 11:16:52 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4E12221F853F; Mon, 30 Jan 2012 11:16:52 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from relay16.apple.com ([17.128.113.55]) 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 <0LYM00MQILIU3F91@mail-out.apple.com>; Mon, 30 Jan 2012 11:16:25 -0800 (PST) X-AuditID: 11807137-b7b2fae00000523c-42-4f26ec88585e Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id A8.7B.21052.98CE62F4; Mon, 30 Jan 2012 11:16:25 -0800 (PST) From: james woodyatt In-reply-to: <867F4B6A1672E541A94676D556793ACD0E91F41122@MOPESMBX01.eu.thmulti.com> Date: Mon, 30 Jan 2012 11:16:24 -0800 Content-transfer-encoding: quoted-printable Message-id: <0E34E6A5-ADB8-4634-9152-902C2D983EA8@apple.com> References: <201201291608.q0TG8oCF098440@givry.fdupont.fr> <85BE2EBF-C8AC-45E1-BF93-1E3066AD3172@apple.com> <867F4B6A1672E541A94676D556793ACD0E91F41122@MOPESMBX01.eu.thmulti.com> To: draft-ietf-v6ops-6204bis@tools.ietf.org X-Mailer: Apple Mail (2.1251.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUieJDXQbfzjZq/QctmAYubVy+yWEw+9pvV 4vSxvcwOzB5Llvxk8vhy+TNbAFMUl01Kak5mWWqRvl0CV8b25u8sBSs5Kna+ymlgPMLWxcjJ ISFgInFvxTlGCFtM4sK99UBxLg4hgdlMEhcam8CKhAWsJfa2P2IFsXkFjCXW3HrHAmIzC+hJ 7Lj+CyzOJqAi8e3yXaYuRg4OToFgiYU/80HCLAKqElOW7GGCKLeS2L7sOlSrtsSyha+ZIUba SFxaOpEdYu8mRokjd76DzRQBKpp29AQrxHHyEi1f77BNYOSfheSMWUjOmIVk7gJG5lWMgkWp OYmVhmZ6iQUFOal6yfm5mxhB4ddQaL6DcftfuUOMAhyMSjy8P3+r+guxJpYVV+YeYpTgYFYS 4X2zWs1fiDclsbIqtSg/vqg0J7X4EKM0B4uSOO82a2V/IYH0xJLU7NTUgtQimCwTB6dUA2P8 +y273k2UzT91gEfpsGSa08ce6YgOywnlPe0enBN4Nr/eW8b4tDLr311OZukpPWcCN5bYVH9U i/SVdV0R8eJ0XoJ++4UDai7fjzq6ny+68j9OYLkKt8NV/h0b1v+bPf/Pi2Cdsvx2iX//HmzS /VakaixtIcq7bKn4r2Ln9I4dRzbxSAde5FNiKc5INNRiLipOBACwJKeCOwIAAA== Cc: IPv6 Operations , PCP 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: Mon, 30 Jan 2012 19:16:52 -0000 On Jan 30, 2012, at 24:03 , Wuyts Carl wrote: > + 1 on Barbara=92s statement. V6ops should take no position to select = a mechanism here. PCP seems to get the most attention but it should not = make v6ops to decide to take it along explicitly in RFC6204bis. I vigorously disagree with the reasoning in these statements. If IETF cannot bring itself, in RFC 6204bis, to "require" its own = standard protocol, which was intended for meeting REC-48 in RFC 6092, = then I don't see why we should keep S-1 at all. Put another way: if we believe there should be no standard mechanism in = IPv6 CE routers for "host applications to solicit inbound traffic = without advance knowledge of the addresses of exterior nodes with which = they expect to communicate" then why do we believe that IPv6 CE routers = should implement RFC 6092? I am NOT just ranting here. This is a very serious question, and I = would like the working group to address it. I would very much like to = see serious answers given. -- j h woodyatt From jhw@apple.com Mon Jan 30 12:17:15 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 53AFC21F84F7; Mon, 30 Jan 2012 12:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.998 X-Spam-Level: X-Spam-Status: No, score=-109.998 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Su2YZ7O0+B69; Mon, 30 Jan 2012 12:17:14 -0800 (PST) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 92D9821F84C9; Mon, 30 Jan 2012 12:17:14 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_2E1OyrqytBL2F0MU9bXWkw)" 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 <0LYM00KCEOCFPUK1@mail-out.apple.com>; Mon, 30 Jan 2012 12:17:14 -0800 (PST) X-AuditID: 11807136-b7c60ae000007a90-bb-4f26fac93ef7 Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (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 B1.54.31376.9CAF62F4; Mon, 30 Jan 2012 12:17:13 -0800 (PST) From: james woodyatt In-reply-to: <2D09D61DDFA73D4C884805CC7865E611025B49@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Mon, 30 Jan 2012 12:17:13 -0800 Message-id: <4A687585-399D-4077-91AC-A1DC4F101E03@apple.com> 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> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1251.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUieJDXQffkLzV/g4YWa4tJf38yWty8epHF YvKx36wWp4/tZXZg8XjZP4fRY8mSn0weXy5/ZgtgjuKySUnNySxLLdK3S+DKODf7EkvBWa2K fe0bWRoYN6p0MXJySAiYSMx795ERwhaTuHBvPVsXIxeHkMBsJonbdxtYQBLCAtYSe9sfsYLY vALGEmtuvQOLMwskSPzsmcEMYrMJqEh8u3yXCcTmFIiQWDV7N1g9i4CqxPPX7awQ9akSG+9e Y4eYYyMxqec7E8Syy4wSve0/wYpEBNQlVk2bzgpxkbxEy9c7bBMY+WYh2T0LyW4IW1ti2cLX QDYHkK0jMXkhI6owhP3x/BGmBYxsqxgFi1JzEisNTfUSCwpyUvWS83M3MYKCuKHQbAfjjr9y hxgFOBiVeHh3vFfzF2JNLCuuzD3EKMHBrCTC+2Y1UIg3JbGyKrUoP76oNCe1+BCjNAeLkjjv VmtlfyGB9MSS1OzU1ILUIpgsEwenVAMjc9CqQzt5FK49W991lk+RN67RoXnzQ6a7EdHny4tK N5suU972K/NpEcOEY08S5j0NljqZ9OPxav1zfouWq3zN2p3udjzIzGY7i3rDHulwjytt8+Y0 9WbddPKoP+x185XuRFv5jb1Zr9YI3dikba229XBSnpF/XmsJl6fRivO3VAP3+TeeX6anxFKc kWioxVxUnAgAgJHXyF4CAAA= Cc: IPv6 Operations , PCP , 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: Mon, 30 Jan 2012 20:17:15 -0000 --Boundary_(ID_2E1OyrqytBL2F0MU9bXWkw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Jan 30, 2012, at 11:58 , STARK, BARBARA H wrote: > > To come at this from a procedural angle, then... > > With the advent of the homenet WG, I thought we agreed that we would not make any attempt to address new additional LAN technology recommendations in a 6204bis document. We said 6204bis would only try to deal with WAN-side transition technologies, and other "fix existing 6204 recommendations, because now we know better" changes. > > Recommending PCP as a LAN technology is, IMO, a homenet issue. It has no place in 6204bis. This reasoning applies just as well to the recommendation of RFC 6092 Simple Security, which is about protecting LAN hosts according to local network policy. If recommending a PCP server is for HOMENET to do, and it has no place in RFC 6204bis from V6OPS, then recommending RFC 6092 Simple Security neither has any place in RFC 6204bis and it should therefore be removed, and a notice inserted into RFC 6204bis to explain why the previous document was in error and to note that forthcoming documents from HOMENET will address the issue properly. I would very much like to get a better understanding of how you are reasoning on this issue. -- j h woodyatt --Boundary_(ID_2E1OyrqytBL2F0MU9bXWkw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
To come at = this from a procedural angle, then...

With the advent of the = homenet WG, I thought we agreed that we would not make any attempt to = address new additional LAN technology recommendations in a 6204bis = document. We said 6204bis would only try to deal with WAN-side = transition technologies, and other "fix existing 6204 recommendations, = because now we know better" changes.

Recommending PCP as a LAN = technology is, IMO, a homenet issue. It has no place in = 6204bis.

This reasoning = applies just as well to the recommendation of RFC 6092 Simple Security, = which is about protecting LAN hosts according to local network = policy.

If recommending a PCP server is for HOMENET = to do, and it has no place in RFC 6204bis from V6OPS, then recommending = RFC 6092 Simple Security neither has any place in RFC 6204bis and it = should therefore be removed, and a notice inserted into RFC 6204bis to = explain why the previous document was in error and to note that = forthcoming documents from HOMENET will address the issue = properly.

I = would very much like to get a better understanding of how you are = reasoning on this issue.


--
j h woodyatt <jhw@apple.com>

= --Boundary_(ID_2E1OyrqytBL2F0MU9bXWkw)-- From jhw@apple.com Mon Jan 30 14:08:55 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 4A0BA11E80B0; Mon, 30 Jan 2012 14:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.698 X-Spam-Level: X-Spam-Status: No, score=-109.698 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, SARE_BAYES_5x7=0.6, 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 OdJ0u+zoiIwO; Mon, 30 Jan 2012 14:08:54 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4A41B11E80A2; Mon, 30 Jan 2012 14:08:54 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_y3F4IlJ+dsPZjxsLfK1RxQ)" Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0LYM00KN0TEJPUR1@mail-out.apple.com>; Mon, 30 Jan 2012 14:08:54 -0800 (PST) X-AuditID: 11807134-b7b36ae0000046e8-1d-4f2714f56e96 Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id 8E.80.18152.5F4172F4; Mon, 30 Jan 2012 14:08:53 -0800 (PST) From: james woodyatt In-reply-to: <2D09D61DDFA73D4C884805CC7865E611025BFE@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Mon, 30 Jan 2012 14:08:53 -0800 Message-id: <30931DE1-9E57-4296-B0FE-FA98F840D78F@apple.com> 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> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1251.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUieJDXQferiLq/QfMiU4tJf38yWty8epHF YvKx36wWp4/tZXZg8XjZP4fRY8mSn0weXy5/ZgtgjuKySUnNySxLLdK3S+DKWPllI3vBhMiK yS/UGhg/e3UxcnJICJhIdLw6yQJhi0lcuLeerYuRi0NIYDaTxKTrc5lBEsIC1hJ72x+xgti8 AsYSa269A2rg4GAWSJBYOs0DJMwmoCLx7fJdJpAwp0CExOzdRiBhFgFVib4L/WDjmQVSJTbe vcYOMcVGYtvbt6wQqy4wSXzrXsEEkhARUJdYNW06K8Q98hItX++wTWDkm4Vk8yyEzbPAxmpL LFv4mhnCNpB42vmKFVNcX+LNuzlMCxjZVjEKFqXmJFYamuglFhTkpOol5+duYgSFb0OhyQ7G gz/5DzEKcDAq8fDufK/mL8SaWFZcmXuIUYKDWUmE981qoBBvSmJlVWpRfnxRaU5q8SFGaQ4W JXHeLdbK/kIC6YklqdmpqQWpRTBZJg5OqQZGpjctHo2O79T/iGVZ5iucOm2W6pdkrL/yXeDp iXq5TfuiIj75MC40uhwp7jyhW+R6+9+9k04c+RSh/cKSa1L1ipcc7z42F++fcqyodk+vnJ23 Q3OvmvSFk4KV+bnc++26BI9HmktpXnEKlOLpc44/sNhHlI2pgOFSATPftqLtLEmnD3/vr1Zi Kc5INNRiLipOBAC0dnWcWwIAAA== Cc: IPv6 Operations , PCP , 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: Mon, 30 Jan 2012 22:08:55 -0000 --Boundary_(ID_y3F4IlJ+dsPZjxsLfK1RxQ) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable On Jan 30, 2012, at 12:59 , STARK, BARBARA H wrote: > The reference to RFC 6092 is in RFC 6204, which was published prior to = homenet=92s creation. > =20 > Unless the reference to 6092 is truly an error, then we don=92t need = to be discussing changes to its recommendation (removal, updates, = enhancements) in 6204bis. It continues as it was. 6204bis has tried to = leave LAN elements of 6204 untouched. They were fully and appropriately = discussed with consensus agreement to include them, at the time of 6204. = And so they remain, unless there is a problem. > =20 > If you believe that inclusion of 6092 as a =93SHOULD=94 is truly an = error, then I would like to understand why you think that. If there = exists proof that it=92s harmful (I=92ve heard some people say that = having it enabled by default has caused some problems, so perhaps there = is such proof), then maybe we should reconsider its inclusion. If you=92re= suggesting its removal because the topic is no longer under the charter = of v6ops, then I disagree. We didn=92t say that we wanted to pull out = LAN elements when doing 6204bis. We said we didn=92t want to do anything = with them, at all (unless they have proven to be a true mistake). = Removing the reference to 6092 would be inconsistent with an attempt to = make no =93LAN functionality=94 changes to 6204, when creating 6204bis. = I would only support it if it were shown to be truly harmful. If I were to make a technical argument about the harmfulness of RFC = 6092, I would start with a lengthy review of its Security = Considerations, in section 6. I think it's a debatable question of procedure, whether it was an error = at the time for V6OPS to publish RFC 6204 with its S-1 "requirement" to = recommend implementation of RFC 6092. There was a clamor for the timely = publication of a document, and neither HOMENET nor PCP were remotely = close to usable when RFC 6204 was in WGLC. I do think it shouldn't be controversial *now* to say that HOMENET is = the venue where any further IETF recommendations about the = implementation of RFC 6092 in IPv6 CE routers should originate. If you = disagree, then once again, I have to ask for an explanation of your = reasoning. I'm very interested to know. If V6OPS wishes to continue stepping on HOMENET's charter, on the = grounds that it already has its footprints there from before HOMENET was = launched, then I suppose that's fine=97 but, if so, then I don't see why = V6OPS shouldn't also take this opportunity to revise RFC 6204 to = recommend a PCP server to meet REC-48 in RFC 6092. Again, as a purely = technical matter=97 I know, technical matters are so boring=97 IETF has = a standards-track protocol for ""host applications to solicit inbound = traffic without advance knowledge of the addresses of exterior nodes = with which they expect to communicate" as RFC 6092 recommends. We did = not have this protocol when either RFC 6092 or RFC 6204 were ready for = publication, but we do now. I fail to see any technical basis for = leaving this unspecified in RFC 6204bis. Is there one? Alternatively, if this is primarily a procedural dispute, then we could = open RFC6092bis in order to update REC-48 accordingly, then cite the = RFC6092bis in RFC6204bis with a publication in lockstep. Which would = you prefer? -- j h woodyatt --Boundary_(ID_y3F4IlJ+dsPZjxsLfK1RxQ) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable
On Jan 30, 2012, at 12:59 , STARK, = BARBARA H wrote:

The reference to RFC = 6092 is in RFC 6204, which was published prior to homenet=92s = creation.
If = you believe that inclusion of 6092 as a =93SHOULD=94 is truly an error, = then I would like to understand why you think that. If there exists = proof that it=92s harmful (I=92ve heard some people say that having it = enabled by default has caused some problems, so perhaps there is such = proof), then maybe we should reconsider its inclusion. If you=92re = suggesting its removal because the topic is no longer under the charter = of v6ops, then I disagree. We didn=92t say that we wanted to pull out = LAN elements when doing 6204bis. We said we didn=92t want to do anything = with them, at all (unless they have proven to be a true mistake). = Removing the reference to 6092 would be inconsistent with an attempt to = make no =93LAN functionality=94 changes to 6204, when creating 6204bis. = I would only support it if it were shown to be truly = harmful.

If I = were to make a technical argument about the harmfulness of RFC 6092, I = would start with a lengthy review of its Security Considerations, in = section 6.

I think it's a debatable question of = procedure, whether it was an error at the time for V6OPS to publish RFC = 6204 with its S-1 "requirement" to recommend implementation of RFC 6092. =  There was a clamor for the timely publication of a document, and = neither HOMENET nor PCP were remotely close to usable when RFC 6204 was = in WGLC.

I do think it shouldn't be = controversial *now* to say that HOMENET is the venue where any further = IETF recommendations about the implementation of RFC 6092 in IPv6 CE = routers should originate.  If you disagree, then once again, I have = to ask for an explanation of your reasoning.  I'm very interested = to know.

If V6OPS wishes to continue stepping = on HOMENET's charter, on the grounds that it already has its footprints = there from before HOMENET was launched, then I suppose that's fine=97 = but, if so, then I don't see why V6OPS shouldn't also take this = opportunity to revise RFC 6204 to recommend a PCP server to meet REC-48 = in RFC 6092.  Again, as a purely technical matter=97 I know, = technical matters are so boring=97 IETF has a standards-track protocol = for ""host applications to solicit inbound traffic without advance = knowledge of the addresses of exterior nodes with which they expect to = communicate" as RFC 6092 recommends.  We did not have this protocol = when either RFC 6092 or RFC 6204 were ready for publication, but we do = now.  I fail to see any technical basis for leaving this = unspecified in RFC 6204bis.  Is there = one?

Alternatively, if this is primarily a = procedural dispute, then we could open RFC6092bis in order to update = REC-48 accordingly, then cite the RFC6092bis in RFC6204bis with a = publication in lockstep.  Which would you prefer?


--
j h woodyatt <jhw@apple.com>

= --Boundary_(ID_y3F4IlJ+dsPZjxsLfK1RxQ)-- From jari.arkko@piuha.net Mon Jan 30 15:59:52 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 D49E721F84EB for ; Mon, 30 Jan 2012 15:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uKn2ZNGgAeB for ; Mon, 30 Jan 2012 15:59:52 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 42D6E21F84DA for ; Mon, 30 Jan 2012 15:59:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8F9362CDC4; Tue, 31 Jan 2012 01:59:51 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mMkUrl7FTJY; Tue, 31 Jan 2012 01:59:51 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 234B52CC39; Tue, 31 Jan 2012 01:59:51 +0200 (EET) Message-ID: <4F272EF6.6080006@piuha.net> Date: Tue, 31 Jan 2012 01:59:50 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: Dave Thaler References: <4F26B3F1.3040908@piuha.net> <9B57C850BB53634CACEC56EF4853FF653B3C77B1@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B3C77B1@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pcp@ietf.org" , "draft-ietf-pcp-base@tools.ietf.org" Subject: Re: [pcp] AD review of draft-ietf-pcp-base (part 1) 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, 30 Jan 2012 23:59:53 -0000 Dave, > Please see (1.g) of the PROTO writeup. > Ok, good. Jari From jari.arkko@piuha.net Mon Jan 30 17:20: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 E28AD11E80FF for ; Mon, 30 Jan 2012 17:20:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcgrZw3E1cFg for ; Mon, 30 Jan 2012 17:20:07 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 34E4D11E80D9 for ; Mon, 30 Jan 2012 17:20:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 824C42DA08; Tue, 31 Jan 2012 03:20:06 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9HOzyb1R4Qg; Tue, 31 Jan 2012 03:20:04 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 955BB2CDFB; Tue, 31 Jan 2012 03:20:04 +0200 (EET) Message-ID: <4F2741C4.5030002@piuha.net> Date: Tue, 31 Jan 2012 03:20:04 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: Dave Thaler References: <4F26B3F1.3040908@piuha.net> <9B57C850BB53634CACEC56EF4853FF653B3C77B1@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B3C77B1@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pcp@ietf.org" , "draft-ietf-pcp-base@tools.ietf.org" Subject: [pcp] AD review of draft-ietf-pcp-base (part 2) 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, 31 Jan 2012 01:20:08 -0000 I am continuing with my review, and have read until about page 50. I have no suggested improvements at this point. I will complete the last part of the review tomorrow. Jari