From alain_durand@cable.comcast.com Mon Nov 2 06:43:21 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 464FA28C12C for ; Mon, 2 Nov 2009 06:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XvcK5YpDVfE for ; Mon, 2 Nov 2009 06:43:20 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 3610E28C0FC for ; Mon, 2 Nov 2009 06:43:20 -0800 (PST) Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.59276344; Mon, 02 Nov 2009 09:43:35 -0500 Received: from PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 09:43:36 -0500 Received: from 147.191.223.149 ([147.191.223.149]) by PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) with Microsoft Exchange Server HTTP-DAV ; Mon, 2 Nov 2009 14:43:35 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 02 Nov 2009 09:43:34 -0500 From: "Durand, Alain" To: Message-ID: Thread-Topic: Agenda so far Thread-Index: AcpbytpzH5OWKreW2UepdbVtSuxhgA== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3339999814_6557728" X-OriginalArrivalTime: 02 Nov 2009 14:43:36.0220 (UTC) FILETIME=[DBC62DC0:01CA5BCA] Subject: [Softwires] Agenda so far X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 14:43:21 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3339999814_6557728 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Here is the agenda so far. Please email correction/addition ASAP. Note to speakers: we need to receive your slides by Friday, 5pm, Japan time. - Alain. --B_3339999814_6557728 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Agenda so far Here is the agenda so far. Please email correction/addition ASAP.

Note to speakers: we need to receive your slides by Friday, 5pm, Japan time= .

   - Alain. --B_3339999814_6557728-- From alain_durand@cable.comcast.com Mon Nov 2 07:37:23 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E09928C14F for ; Mon, 2 Nov 2009 07:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[AWL=1.280, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_BASE64_BLANKS=0.041, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoBGv3fjTJ8l for ; Mon, 2 Nov 2009 07:37:22 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 67C1028C14A for ; Mon, 2 Nov 2009 07:37:22 -0800 (PST) Received: from ([24.40.15.118]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.59286649; Mon, 02 Nov 2009 10:37:38 -0500 Received: from PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 10:37:39 -0500 Received: from 147.191.223.149 ([147.191.223.149]) by PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) with Microsoft Exchange Server HTTP-DAV ; Mon, 2 Nov 2009 15:37:38 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 02 Nov 2009 10:37:35 -0500 From: "Durand, Alain" To: Alain Durand , Message-ID: Thread-Topic: [Softwires] Agenda so far Thread-Index: AcpbytpzH5OWKreW2UepdbVtSuxhgAAB4vJR In-Reply-To: Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3340003057_6648050" X-OriginalArrivalTime: 02 Nov 2009 15:37:39.0191 (UTC) FILETIME=[68BC4870:01CA5BD2] Subject: Re: [Softwires] Agenda so far X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 15:37:23 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3340003057_6648050 Content-type: multipart/alternative; boundary="B_3340003057_6678107" --B_3340003057_6678107 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit > Resent with actual agenda attached. > > - Alain. > --B_3340003057_6678107 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [Softwires] Agenda so far
Resent with actual agenda attached.

  - Alain.

--B_3340003057_6678107-- --B_3340003057_6648050 Content-type: application/octet-stream; name="agenda.txt" Content-disposition: attachment; filename="agenda.txt" Content-transfer-encoding: base64 TWF0IEZvcmQsIHNoYXJlZCBhZGRyZXNzIGlzc3VlcywgaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtZm9yZC1zaGFyZWQtYWRkcmVzc2luZy1pc3N1ZXMtMDEKWW9uZyBvciBN ZXR6LCBTb2Z0d2lyZSBNZXNoIE11bHRpY2FzdApSZW1pIERlcHJlcywgU0FNLCBkcmFmdC1k ZXNwcmVzLXNvZnR3aXJlLW1lc2gtc2FtLTAxIApQaWVycmUgRGF2aXMsIERlcGxweWluZyBE Uy1saXRlLCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3VjYWRhaXItZHNs aXRlLWludGVyY28tdjR2Ni0wMgpNYXJrIFRvd25zbGV5LDZyZCB1cGRhdGUKWWl1IExlZSwg NnJkLVVEUCwgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGVlLXNvZnR3aXJl LTZyZC11ZHAtMDAKWWl1IExlZSwgRFMtbGl0ZSwgZHJhZnQtaWV0Zi1kdWFsLXN0YWNrLWxp dGUtMDIKRGF2aWQgSGFua2lucywgRHMtbGl0ZSBESENQIG9wdGlvbiwgaHR0cDovL3d3dy5p ZXRmLm9yZy9pZC9kcmFmdC1kaGFua2lucy1zb2Z0d2lyZS10dW5uZWwtb3B0aW9uLTA0LnR4 dApYdSBYaWFvaHUsIFR1bm5lbCBlbmQgcG9pbnQgaW4gQkdQLCBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaWQvZHJhZnQteHUtc29mdHdpcmUtdHVubmVsLWVuZHBvaW50LTAwLnR4dApTaGVu ZyBKaWFuZywgRGlzY292ZXJ5LCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1n dW8tc29mdHdpcmUtYXV0by1ncmUtMDAgLCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1ndW8tc29mdHdpcmUtc2MtZGlzY292ZXJ5ClNyaSBHdW5kYXZlbGxpLCBEUy1saXRl IGluIG1vYmlsaXR5LCBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWd1bmRhdmVsbGkt c29mdHdpcmUtZ2F0ZXdheS1pbml0LWRzLWxpdGUtMDAudHh0Cg== --B_3340003057_6648050-- From christian.vogt@ericsson.com Wed Nov 4 20:18:33 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83E4228C0FA for ; Wed, 4 Nov 2009 20:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glmv01GjeyIG for ; Wed, 4 Nov 2009 20:18:32 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id B6DB03A67D7 for ; Wed, 4 Nov 2009 20:18:31 -0800 (PST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id nA54I7ow003854; Wed, 4 Nov 2009 22:18:07 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 22:17:04 -0600 Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 22:17:04 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.35]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 4 Nov 2009 23:17:04 -0500 From: Christian Vogt To: "Frank Brockners (fbrockne)" , Sri Gundavelli Date: Wed, 4 Nov 2009 23:16:41 -0500 Thread-Topic: [Softwires] Thoughts on new I-D?: Gateway Initiated Dual-stack lite Deployment Thread-Index: AcpdztOs+QjHgs4HTL6IzBzWpxbBuQ== Message-ID: <042DDCF3-5C03-473E-9E24-2AF9FB5D76F6@ericsson.com> References: <0D212BD466921646B58854FB79092CEC76182C@XMB-AMS-106.cisco.com> In-Reply-To: <0D212BD466921646B58854FB79092CEC76182C@XMB-AMS-106.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Nov 2009 04:17:04.0673 (UTC) FILETIME=[D4B49110:01CA5DCE] Cc: "" Subject: Re: [Softwires] Thoughts on new I-D?: Gateway Initiated Dual-stack lite Deployment X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 04:18:33 -0000 Frank and Sri - I think you should add a motivation for your proposal to the document. This motivation should answer the questions: Why does the NAT need to be de-coupled from the gateway that terminates the existing tunnel? Why not co-locate the NAT with the gateway? This would explain why you want to extend the existing tunnel towards the NAT using your proposal. I see one motivation, which applies to networks with multiple gateways: In those networks, by de-coupling the NAT from the gateways, the global IPv4 addresses on the external side of the NAT can be shared more efficiently compared to co-locating a separate NAT with every gateway. Are there other motivations for your proposal? - Christian On Oct 15, 2009, Frank Brockners wrote: > FYI. We just wanted to draw your attention to a new draft "Gateway > Initiated Dual-stack lite" - which outlines a modified deployment > approach of the original dual-stack lite. The approach applies to =20 > those > network architectures which already employ some form of tunneling > technology in the access network. The key idea is to leverage the > existing access tunnel (which means that architectural changes within > the access network are limited to the gateway terminating access =20 > tunnel) > and stitch it together with a softwire connecting to the CGN. While > largely targeted at mobility architectures, the solution could be > applied to broadband environments as well. > > A copy of the draft is available at: > http://www.ietf.org/id/draft-gundavelli-softwire-gateway-init-ds-lite-00 > .txt > > > We appreciate your thoughts and comments. > > Thanks & regards, Sri & Frank From sgundave@cisco.com Wed Nov 4 21:49:29 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FB1E3A693E for ; Wed, 4 Nov 2009 21:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbsSzbJhX5YA for ; Wed, 4 Nov 2009 21:49:28 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2C05A3A686E for ; Wed, 4 Nov 2009 21:49:28 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABv28UqrR7H+/2dsb2JhbADGVpdZhD0EgWY X-IronPort-AV: E=Sophos;i="4.44,684,1249257600"; d="scan'208";a="425224920" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 05 Nov 2009 05:49:50 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA55noOJ011950; Thu, 5 Nov 2009 05:49:50 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 21:49:50 -0800 Received: from 10.32.243.113 ([10.32.243.113]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Thu, 5 Nov 2009 05:49:49 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 04 Nov 2009 21:51:01 -0800 From: Sri Gundavelli To: Christian Vogt , "Frank Brockners (fbrockne)" Message-ID: Thread-Topic: [Softwires] Thoughts on new I-D?: Gateway Initiated Dual-stack lite Deployment Thread-Index: AcpdztOs+QjHgs4HTL6IzBzWpxbBuQADSCJW In-Reply-To: <042DDCF3-5C03-473E-9E24-2AF9FB5D76F6@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Nov 2009 05:49:50.0371 (UTC) FILETIME=[CA1EAF30:01CA5DDB] Cc: "" Subject: Re: [Softwires] Thoughts on new I-D?: Gateway Initiated Dual-stack lite Deployment X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 05:49:29 -0000 Hi Christian, Thanks for the review. We can surely add some text on the placement of the CGN. Based on the topology and network design considerations, operators may choose to place the CGN in the PDN gateway, or at the edge of the IPv4 network with the fixed and mobile networks within the CGN scope. As you pointed out, the collocation of the both the functions on the PDN, do require management of the shared address space. However, the spec does not mandate the placement of the CGN function, as that is a typical deployment and network topology consideration and its up to the operator. We can surely add some text on this aspect. Regards Sri On 11/4/09 8:16 PM, "Christian Vogt" wrote: > Frank and Sri - > > I think you should add a motivation for your proposal to the document. > This motivation should answer the questions: Why does the NAT need to > be de-coupled from the gateway that terminates the existing tunnel? Why > not co-locate the NAT with the gateway? This would explain why you want > to extend the existing tunnel towards the NAT using your proposal. > > I see one motivation, which applies to networks with multiple gateways: > In those networks, by de-coupling the NAT from the gateways, the global > IPv4 addresses on the external side of the NAT can be shared more > efficiently compared to co-locating a separate NAT with every gateway. > > Are there other motivations for your proposal? > > - Christian > > > > On Oct 15, 2009, Frank Brockners wrote: > >> FYI. We just wanted to draw your attention to a new draft "Gateway >> Initiated Dual-stack lite" - which outlines a modified deployment >> approach of the original dual-stack lite. The approach applies to >> those >> network architectures which already employ some form of tunneling >> technology in the access network. The key idea is to leverage the >> existing access tunnel (which means that architectural changes within >> the access network are limited to the gateway terminating access >> tunnel) >> and stitch it together with a softwire connecting to the CGN. While >> largely targeted at mobility architectures, the solution could be >> applied to broadband environments as well. >> >> A copy of the draft is available at: >> http://www.ietf.org/id/draft-gundavelli-softwire-gateway-init-ds-lite-00 >> .txt >> >> >> We appreciate your thoughts and comments. >> >> Thanks & regards, Sri & Frank > > > From christian.vogt@ericsson.com Wed Nov 4 22:49:43 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77CDB3A684E for ; Wed, 4 Nov 2009 22:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBphOEKv07fb for ; Wed, 4 Nov 2009 22:49:42 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 81FC53A682F for ; Wed, 4 Nov 2009 22:49:42 -0800 (PST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id nA56nbQt026911; Thu, 5 Nov 2009 00:49:38 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Nov 2009 00:48:36 -0600 Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Nov 2009 00:48:36 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.35]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 5 Nov 2009 01:48:35 -0500 From: Christian Vogt To: Sri Gundavelli Date: Thu, 5 Nov 2009 01:49:09 -0500 Thread-Topic: [Softwires] Thoughts on new I-D?: Gateway Initiated Dual-stack lite Deployment Thread-Index: Acpd4/9fvQzSNWnMTTu/AjYQcqj4dg== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Nov 2009 06:48:36.0439 (UTC) FILETIME=[FFD1F670:01CA5DE3] Cc: "" Subject: Re: [Softwires] Thoughts on new I-D?: Gateway Initiated Dual-stack lite Deployment X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 06:49:43 -0000 Sri - To clarify: In addition to saying that an operator COULD decouple the NAT from the gateway, it would be good to identify the scenarios where the NAT MUST be decoupled from the gateway. It is these and only these scenarios that motivate your proposal. But then again, there is at least one motivating scenario: higher efficiency of IPv4 address sharing in networks with multiple gateways. - Christian On Nov 5, 2009, Sri Gundavelli wrote: > Hi Christian, > > Thanks for the review. We can surely add some text on the placement =20 > of the > CGN. Based on the topology and network design considerations, =20 > operators may > choose to place the CGN in the PDN gateway, or at the edge of the IPv4 > network with the fixed and mobile networks within the CGN scope. As =20 > you > pointed out, the collocation of the both the functions on the PDN, do > require management of the shared address space. However, the spec =20 > does not > mandate the placement of the CGN function, as that is a typical =20 > deployment > and network topology consideration and its up to the operator. We =20 > can surely > add some text on this aspect. > > Regards > Sri From sgundave@cisco.com Wed Nov 4 23:10:55 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95B043A69E0 for ; Wed, 4 Nov 2009 23:10: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJRnlzLCd+73 for ; Wed, 4 Nov 2009 23:10:54 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 40C683A684A for ; Wed, 4 Nov 2009 23:10:54 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAI8J8kqrR7Ht/2dsb2JhbADHCZdcgjiCBQSBZg X-IronPort-AV: E=Sophos;i="4.44,685,1249257600"; d="scan'208";a="48138348" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 05 Nov 2009 07:11:16 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA57BGuY010426; Thu, 5 Nov 2009 07:11:16 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 23:11:16 -0800 Received: from 10.32.243.61 ([10.32.243.61]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Thu, 5 Nov 2009 07:11:15 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 04 Nov 2009 23:12:26 -0800 From: Sri Gundavelli To: Christian Vogt Message-ID: Thread-Topic: [Softwires] Thoughts on new I-D?: Gateway Initiated Dual-stack lite Deployment Thread-Index: Acpd4/9fvQzSNWnMTTu/AjYQcqj4dgAA1SIu In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Nov 2009 07:11:16.0454 (UTC) FILETIME=[2A73C860:01CA5DE7] Cc: "" Subject: Re: [Softwires] Thoughts on new I-D?: Gateway Initiated Dual-stack lite Deployment X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 07:10:55 -0000 Hi Christian, On 11/4/09 10:49 PM, "Christian Vogt" wrote: > Sri - > > To clarify: In addition to saying that an operator COULD decouple the > NAT from the gateway, it would be good to identify the scenarios where > the NAT MUST be decoupled from the gateway. It is these and only these > scenarios that motivate your proposal. > > But then again, there is at least one motivating scenario: higher > efficiency of IPv4 address sharing in networks with multiple gateways. > Sure, we can certainly add the motivation for that configuration. It is to be noted that the spec is also supporting the allocation of the same IP address for all UE's. Its solving this in a consistent way for all mobility architectures (MIPv6, GTP & PMIPv6), by applying dual-stack lite approach in the gateway initiated mode. Now, if the GGSN and CGN are collocated in a given scenario, still there is some context sharing between those two elements that allows the GGSN to route the packet to the UE correctly, it may be internal to a given implementation. The resulting side-affect of this is a simple migration approach, with minimal changes to the PDN. - Solves the IPv4 exhaust issue - UE can be a legacy IPv4-only node or a dual-stack node - There is no need for IPv6-only bearer, or IPv6-only transport for UE - CGN and PDN can be collocated or decoupled. When they are decoupled, allows the network to be IPv4 or IPv6 - There is no change to the EPC, or to the address assignment procedures - No changes to the UE architecture This in essence provides a IPv6 migration approach for mobile operators and the solution is valid for other architectures as well. Sri > - Christian > > > > On Nov 5, 2009, Sri Gundavelli wrote: > >> Hi Christian, >> >> Thanks for the review. We can surely add some text on the placement >> of the >> CGN. Based on the topology and network design considerations, >> operators may >> choose to place the CGN in the PDN gateway, or at the edge of the IPv4 >> network with the fixed and mobile networks within the CGN scope. As >> you >> pointed out, the collocation of the both the functions on the PDN, do >> require management of the shared address space. However, the spec >> does not >> mandate the placement of the CGN function, as that is a typical >> deployment >> and network topology consideration and its up to the operator. We >> can surely >> add some text on this aspect. >> >> Regards >> Sri > > > From brian.e.carpenter@gmail.com Thu Nov 5 18:17:39 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34EDC3A6833 for ; Thu, 5 Nov 2009 18:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKSsaP8irhIA for ; Thu, 5 Nov 2009 18:17:38 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 0EB273A67DA for ; Thu, 5 Nov 2009 18:17:37 -0800 (PST) Received: by pwi4 with SMTP id 4so401941pwi.29 for ; Thu, 05 Nov 2009 18:17:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=lMZxaEdTeCVlKEQRWuLPIhVYnNBdxUVM1MUz8lt+m9E=; b=VqI6xEzL1uxL+oAj4lm0YjIPJvLh5DqbNlSWYFTQrhKjr3uVCOhOV4VsO9KdlEIhF0 KDDYCO47WyC+uIc+skM/qvvHuU9swturk4Ar4/Vp4SkSvTj+fzUJqC10VhxWypZWah8m 31JFeyM82p2w98PGLe5dTqr8pSprfDapJ5xAg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; b=XmEn/9vwJzej26diKnvjtWwcps/zX2XXgkUldEwCIcwNipKHCwridy7U+CJ/as1wdS C3YAXqKEmbLJgG7yu+f1W7WbEyK2bBZD1QaJxsoQjDP7r89A+TRdy9UIcsbN2Gadsis+ 1culFXGySeyYiX322VZqQEQW3pqlMLu9hNqWs= Received: by 10.114.138.10 with SMTP id l10mr5780596wad.3.1257473877033; Thu, 05 Nov 2009 18:17:57 -0800 (PST) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 23sm1496808pzk.4.2009.11.05.18.17.56 (version=SSLv3 cipher=RC4-MD5); Thu, 05 Nov 2009 18:17:56 -0800 (PST) Message-ID: <4AF38760.4060100@gmail.com> Date: Fri, 06 Nov 2009 15:18:08 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: softwires@ietf.org References: <20091018200001.DFD963A67FF@core3.amsl.com> In-Reply-To: <20091018200001.DFD963A67FF@core3.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] I-D Action:draft-lee-softwire-6rd-udp-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 02:17:39 -0000 I like this idea in principle, but I am quite concerned by two issues that seem to make it unattractive in practice: 1. No defined method for discovering the Subscriber IPv4 Address (section 3.3) and no universal method of discovering the SP-BR prefix (requires RADIUS or DIAMETER, section 5.2, but some ISPs don't use either of them). 2. Does not support IPv6 server ports (section 7.1, no externally initiated sessions). That's just as bad as traditional NAT. One detail in section 4.1: > o this specification does not introduce new requirement to the IPv4 > UDP Length and Checksum. Does that mean that the UDP checksum is optional? Brian From yiu_lee@cable.comcast.com Thu Nov 5 18:34:34 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EAAD3A6937 for ; Thu, 5 Nov 2009 18:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vF6XJdhE7jV for ; Thu, 5 Nov 2009 18:34:29 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 812923A6A25 for ; Thu, 5 Nov 2009 18:34:27 -0800 (PST) Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.59820079; Thu, 05 Nov 2009 21:34:45 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Nov 2009 21:34:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 198.137.252.126 ([198.137.252.126]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([198.137.252.77]) with Microsoft Exchange Server HTTP-DAV ; Fri, 6 Nov 2009 02:34:44 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3340301677_9941982" Date: Thu, 5 Nov 2009 21:34:36 -0500 Message-ID: In-Reply-To: <4AF38760.4060100@gmail.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Softwires] I-D Action:draft-lee-softwire-6rd-udp-00.txt Thread-Index: Acpeh3DUsfWgh58kQVq896GhPz46zgAAj1lv From: "Lee, Yiu" To: "Brian E Carpenter" , X-OriginalArrivalTime: 06 Nov 2009 02:34:45.0153 (UTC) FILETIME=[B3ADE910:01CA5E89] Subject: Re: [Softwires] I-D Action:draft-lee-softwire-6rd-udp-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 02:34:34 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3340301677_9941982 Content-type: multipart/alternative; boundary="B_3340301676_9954831" --B_3340301676_9954831 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Brian. I would like to use DHCP to discover the SP-BR. Problem is that the NAT is the DHCP server for the hosts which won=B9t understand the new DHCP option. Another way to work around this is to define a new light-weight discovery protocol. Do you have any better idea to share? For server model, we can define a port-forwarding rule in the NAT. For host model, things are more tricky. Unfortunately, hosts are behind a NAT and will suffer from all the NAT limitations. Thanks, Yiu On 11/5/09 9:18 PM, "Brian E Carpenter" wrote= : > I like this idea in principle, but I am quite concerned by > two issues that seem to make it unattractive in practice: >=20 > 1. No defined method for discovering the Subscriber IPv4 Address > (section 3.3) and no universal method of discovering the SP-BR > prefix (requires RADIUS or DIAMETER, section 5.2, but some ISPs > don't use either of them). >=20 > 2. Does not support IPv6 server ports (section 7.1, no > externally initiated sessions). That's just as bad as traditional > NAT. >=20 > One detail in section 4.1: >=20 >> > o this specification does not introduce new requirement to the IPv= 4 >> > UDP Length and Checksum. >=20 > Does that mean that the UDP checksum is optional? >=20 > Brian >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 --B_3340301676_9954831 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Softwires] I-D Action:draft-lee-softwire-6rd-udp-00.txt Hi Brian.

I would like to use DHCP to discover the SP-BR. Problem is that the NAT is = the DHCP server for the hosts which won’t understand the new DHCP opti= on. Another way to work around this is to define a new light-weight discover= y protocol. Do you have any better idea to share?

For server model, we can define a port-forwarding rule in the NAT. For host= model, things are more tricky. Unfortunately, hosts are behind a NAT and wi= ll suffer from all the NAT limitations.

Thanks,
Yiu

On 11/5/09 9:18 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>I like this idea in principle, but I am quite co= ncerned by
two issues that seem to make it unattractive in practice:

1. No defined method for discovering the Subscriber IPv4 Address
(section 3.3) and no universal method of discovering the SP-BR
prefix (requires RADIUS or DIAMETER, section 5.2, but some ISPs
don't use either of them).

2. Does not support IPv6 server ports (section 7.1, no
externally initiated sessions). That's just as bad as traditional
NAT.

One detail in section 4.1:

>    o  this specification does not introduce new re= quirement to the IPv4
>       UDP Length and Checksum.

Does that mean that the UDP checksum is optional?

    Brian

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.= org/mailman/listinfo/softwires

--B_3340301676_9954831-- --B_3340301677_9941982 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIN2AYJKoZIhvcNAQcCoIINyTCCDcUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC C6QwggMPMIICeKADAgECAhBQgSObXgIsEiVC/GebCmGTMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA4MDgwODQw MDJaFw0xMDA4MDgwODQwMDJaMEsxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx KDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCscC6PT5lvsXUq4lOfCGh5DV7ZnHkaKTZrdclNBGwIUu1H njC0937hsVMKSuyKXMiuGc2VS1sjvEzqtqcSiGBkX2ZhGszLppMjiNwb3McBc4slgNxK1OfX Q+g/C/Fi/pZbg3KU/V50QGQQsM0yO1HOK7FGyvOH023fNvQ7E0syH6NAbkmf4mQoHLFUMkjD mfdbtrnYeGvNjrX6hLMmUuo0Y6MAyJQdBDH8p+6V0/hjvYOA2yAW+ptxxEbPYGrm1/f2TYp2 o43bA9ri/P8Rtli6kaKQvC5HhReyNJLWWG2z8JjbqcQd1sP443WI1voiBbqOLNpu3KWnBRzC 3+n6eYhfAgMBAAGjWTBXMA4GA1UdDwEB/wQEAwID+DARBglghkgBhvhCAQEEBAMCBaAwJAYD VR0RBB0wG4EZeWl1X2xlZUBjYWJsZS5jb21jYXN0LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAF+NiG7zCDaZsRKq54bnGbGi1nFyzFa4sL72O+J2vRZoyVU8tFpl9Xz/ BnTMU+olVJ+Q4wmnwuSJZ6rTblLTlKRVnkd3PBcnWYYVYSvwhKuTTmTX99RZHvGSTGJomy7M PuOLo/XqZgHgA/oZ38QQp76e9EPeM2nfFJHc9bTK0RlOMIIDPzCCAqigAwIBAgIBDTANBgkq hkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcC Y1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNv bmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQD ExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/ r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCU YsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzCCBUowggQyoAMCAQICEEsVRXwTaRSoi7d3sapu92EwDQYJKoZIhvcNAQEFBQAwgd0x CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMjAeFw0wOTExMDUwMDAwMDBaFw0xMDExMDUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRAwDgYDVQQDFAdZaXUg TGVlMSgwJgYJKoZIhvcNAQkBFhl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArfUYyB1WddeTV1whaQNaHKstvQcFnloN37ZayFeM H8D3vKzrImHg6WIFOm7+kA5GsW+cO5au9HNL5fKSf1jYb4/EMuaEITqBpBK41nBok7jP3FiD KPt4TtsJsnqDRLaS2SS3YBSTZOzgdLU4mTjveMYmyFdeRbNsrO2v8bWkcQLE/zf5wSdGS6rF nDF8MXw70BkHmZte1eY+EYoi694+0ukeg9eKw5JFlmBrYAoE1oDxMHXXIV2ju/zC9kpK5DZC AVtofp+hL5A+pgnLxOsfPrRpcrkQeM1ryhujXCij/jdHMMdNS3+z97QSw8cNfG3PBF8KnBp6 67jVylTR/d3LCwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhF AQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1Ud DwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2g O4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFs SUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAxhdnbwrUOuIrJBrZ+T2mMOJJOT8gJp9gvzwJP HXevZ6DtqgrD0oNhI5bpXbgvIYjFHS9zgGi264F7qLxPYYwFF0qt0IQxUp3S72rrNtpTrBTS FoPjfuKzfK/6zv5NEExfChalzDKxKUrdymfCT3/eRPkAGRMBaADDpb1RRrmpLHDU4RZkiX48 LwLlTDFz+Yot/DO7YZCNpV38IKHN6mNfYzOUKL6zoFnY8Dd1q4dTO8d4lRU2bZUQ/i36WsXH pr9YsPKPd3dOsbO7EVIFUCZzUYPly1jZqG5Ns6KW5e26l/E2mMi5bkgq8ppqbjO0kpfZDcLO IpVMJvkYPT/6Jqx5MYIB/DCCAfgCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFCBI5teAiwSJUL8Z5sKYZMwCQYFKw4DAhoFAKBdMCMGCSqG SIb3DQEJBDEWBBRk/yqgkbJPdZTa4QJJam0nKCpqsjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wOTExMDYwMjM0MzZaMA0GCSqGSIb3DQEBAQUABIIBAGQj XqecfipbuYtlpN35Hsgyk+aApIITv9fWnW7oh5b5aMu4huNPFxZdNuDzfirlkKEMZCR/2QNg 5R9mDK+n2ZYq3HG36xex7mRl9IChIDTp0h6NLIcYaEmV+YMblL+FFqjoAo+BnYXRM+P1G7UV 8EWIoLi2w2qAfxk5BqBumHc7XKBIEC9msORsYcEVMIGoH+P4rB/QJRWXPHkzkjao6ri+GTl+ ifuzo2UveoYbNeaew6nPcRdOfJXbI2rTdJoIa+bVpcyUgZsq+CsSwQQsL7qiEtVeMQfiWuqm w0jgSt+c+cbRfjvpN6TXGmAYvITB8UfTP7lhIHuYG8wrA1JGOe4= --B_3340301677_9941982-- From ipng@69706e6720323030352d30312d31340a.nosense.org Sat Nov 7 01:46:39 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0CB28C134 for ; Sat, 7 Nov 2009 01:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.283 X-Spam-Level: X-Spam-Status: No, score=-1.283 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBDyDxO7Qx6v for ; Sat, 7 Nov 2009 01:46:38 -0800 (PST) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by core3.amsl.com (Postfix) with ESMTP id 915C128C131 for ; Sat, 7 Nov 2009 01:46:38 -0800 (PST) Received: from 114-30-107-143.ip.adam.com.au ([114.30.107.143] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1N6hsn-0001b9-PZ; Sat, 07 Nov 2009 20:16:58 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 16436492E3; Sat, 7 Nov 2009 20:16:55 +1030 (CST) Date: Sat, 7 Nov 2009 20:16:54 +1030 From: Mark Smith To: Ole Troan Message-ID: <20091107201654.0d5b8f3c@opy.nosense.org> In-Reply-To: <2bbba3c10909240043g1f1f42ddm537d2732b752cf23@mail.gmail.com> References: <4ABB1FE9.5090909@linux-ipv6.org> <2bbba3c10909240043g1f1f42ddm537d2732b752cf23@mail.gmail.com> X-Mailer: Claws Mail 3.7.3 (GTK+ 2.18.3; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org Subject: Re: [Softwires] Comments on draft-ietf-softwire-ipv6-6rd-00 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 09:46:39 -0000 Hi, On Thu, 24 Sep 2009 09:43:51 +0200 Ole Troan wrote: > Yoshifuji, >=20 > > Some comments on 6rd document. > > > > |4. =A06rd Prefix Delegation > > | > > | =A0 In 6rd, a customer site's IPv6 Delegated Prefix is derived from 2 > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0~~~ > > | =A0 elements: > > | > > | =A0 1. =A0An IPv6 Prefix selected by the SP to be the common 6rd SP P= refix > > | =A0 =A0 =A0 for the given 6rd deployment (an SP can have multiple 6rd > > | =A0 =A0 =A0 deployments called domains). > > | > > | =A0 2. =A0An assigned IPv4 address for the subscriber. =A0This IPv4 a= ddress > > | =A0 =A0 =A0 may be a global IPv4 address, or a Private RFC 1918 [RFC1= 918] > > | =A0 =A0 =A0 IPv4 address. > > | > > | =A0 From these three items, the 6rd Delegated Prefix is automatically > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 ~~~~~two? >=20 > thanks, updated! >=20 > > | =A0 created for the customer site when IPv4 service is obtained. =A0F= rom > > | =A0 the perspective of the 6rd CE LAN-Side functionality, this IPv6 > > | =A0 delegated prefix is used in the same manner as a prefix obtained = via > > | =A0 DHCPv6 Prefix Delegation [RFC3633]. > > > > |6.1. =A06rd DHCP option > > : > > | =A0 The 6rd CE router MUST install a default route to the relay. =A0It > > | =A0 should also install a sink route for the delegated prefix. =A0As = an > > | =A0 example using a subscriber IPv4 address of 10.100.100.1, a 6rd IP= v4 > > | =A0 relay address of 10.0.0.1, a v4suffix-length of 24 and 2001:ABC0:= :/28 > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2001:0DB8::/32 > > | =A0 as the SP 6rd IPv6 prefix, the RIB will look like: > > | > > | =A0 =A0 =A0::/0 -> 2001:ABC0:0000:0100:: =A0 (default route) > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 2001:0DB8:0000:0100:: > > | =A0 =A0 =A02001:ABC0:6464:0100::/56 -> Null0 (6rd prefix sink route) > > =A0 =A0 =A0 2001:0DB8:6464:0100::/56 > > > > Note: With 2001:ABC0::/28 and 24 bit suffix, the results should > > be 2001:ABC0:0000:1000:: and 2001:ABC6:4640:1000::/52. >=20 > well, spotted. left-over from when we explicitly encoded the domain id. > fixed. >=20 That explains it. I read through this draft recently, and felt there was either not enough information about encoding the domain id, or alternatively a bit too much commentary about a domain id. If it is preferred to not explicitly encode the domain id, then I'd suggest something like simple and single paragraph describing how multiple domains can be created using different shorter 6rd prefixes, and that they could come out of a shorter aggregate IPv6 prefix if it suits the network/routing topology. I'd then suggest through out the rest of the draft that there is minimal mention of 6rd domains, unless there are specific issues relating to multiple 6rd domains. HTH, Mark. > cheers, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From dthaler@microsoft.com Sun Nov 8 01:26:16 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE1F23A672F for ; Sun, 8 Nov 2009 01:26:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.553 X-Spam-Level: X-Spam-Status: No, score=-10.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vx5aQWUlAyIc for ; Sun, 8 Nov 2009 01:26:10 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id D962D3A67E3 for ; Sun, 8 Nov 2009 01:26:10 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 8 Nov 2009 01:26:52 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server id 14.0.639.20; Sun, 8 Nov 2009 01:26:36 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Sun, 8 Nov 2009 01:26:36 -0800 From: Dave Thaler To: "softwires@ietf.org" Thread-Topic: Comments on draft-townsley-ipv6-6rd-01.txt Thread-Index: AcpgVY/03sw20GskSAeQ2jjf8QBoLQ== Date: Sun, 8 Nov 2009 09:26:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E4561B14EE2A3E4E9D478EBFB5416E1B29B35A69TK5EX14MBXW653w_" MIME-Version: 1.0 Subject: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 09:26:16 -0000 --_000_E4561B14EE2A3E4E9D478EBFB5416E1B29B35A69TK5EX14MBXW653w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable While this draft is a good start (and is arguably as good as the 6to4 spec = was), I think it still needs a bunch of work, as we've learned from the 6to4 expe= rience. First the draft needs to discuss the properties of IPv6 on the 6rd interfac= e: 1) What's the link model? Presumably it's an NBMA interface like 6to4= , in which case multicast isn't supported. But the document needs to discuss this. 2) One of the problems with 6to4 is that it violates the IPv6 RFCs by not having a link-local address (see RFC 4291 section 2.1, section paragrap= h, for example). Will 6rd repeat that violation or not? Can packets be sent with a link-local address? 3) The use of Neighbor Discovery on the interface needs to be discussed. Are unicast RS/RA legal? Presumably normal router discovery and address resolution are not used since it's NBMA. As RFC 4861 says: > Unless specified otherwise (in a document that covers operating IP > over a particular link type) this document applies to all link types. > However, because ND uses link-layer multicast for some of its > services, it is possible that on some link types (e.g., Non-Broadcast > Multi-Access (NBMA) links), alternative protocols or mechanisms to > implement those services will be specified (in the appropriate > document covering the operation of IP over a particular link type). > The services described in this document that are not directly > dependent on multicast, such as Redirects, Next-hop determination, > Neighbor Unreachability Detection, etc., are expected to be provided > as specified in this document. Since 6rd doesn't specify otherwise, I assume that redirects, next-hop determination, NUD, etc are provided as specified in RFC 4861, correct? Compare how ISATAP addresses these in RFC 5214 section 8, and 6RD needs to have a similar level of coverage. My second major concern with the current draft is that it is too limited in scope compared to 6to4 where I believe it should be able to be used in place of 6to4 (other than having private relays with a network-specific prefix, instead of public relays with a well-known prefix). Specifically there are two limitations introduced without good reason, that need to be removed: 1) The draft says a CE must have 1 or more LAN interface. 6to4 can be used even when you don't have a LAN interface (up). Remove this limitation, as it's not necessary and doesn't affect anything else. 2) The DHCP option format for configuring a CPE is only capable of holding a single BR address. To be able to replace 6to4, this must be capable of passing a list. Today many 6to4 gateways are capable of using a list, and adding one default route for each relay address, and this can facilitate load-spreading, failover, etc. There's no reason given to make 6rd less capable in this respect. If a SP doesn't want that, they don't have to provide more than 1 address, but we should not prevent an SP from providing service equivalent to what can be done with 6to4 today. -Dave --_000_E4561B14EE2A3E4E9D478EBFB5416E1B29B35A69TK5EX14MBXW653w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

While this draft is a good start (and is arguably as g= ood as the 6to4 spec was),

I think it still needs a bunch of work, as we’ve learned from the 6to4 experience.

 

First the draft needs to discuss the properties of IPv= 6 on the 6rd interface:

1)&n= bsp;     What’s the link model?  Presumably it= 217;s an NBMA interface like 6to4,

in which case multicast isn’t supported.  B= ut the document needs to

discuss this.

2)&n= bsp;     One of the problems with 6to4 is that it violates t= he IPv6 RFCs by

not having a link-local address (see RFC 4291 section = 2.1, section paragraph,

for example).    Will 6rd repeat that violation or not?

Can packets be sent with a link-local address?

3)&n= bsp;     The use of Neighbor Discovery on the interface need= s to be

discussed.  Are unicast RS/RA legal?  Presum= ably normal router discovery

and address resolution are not used since it’s NBMA.  As RFC 4861 says:

> Unless specified otherwise (in a document that co= vers operating IP

> over a particular link type) this document applie= s to all link types.

> However, because ND uses link-layer multicast for= some of its

> services, it is possible that on some link types = (e.g., Non-Broadcast

> Multi-Access (NBMA) links), alternative protocols= or mechanisms to

> implement those services will be specified (in th= e appropriate

> document covering the operation of IP over a part= icular link type).

> The services described in this document that are = not directly

> dependent on multicast, such as Redirects, Next-h= op determination,

> Neighbor Unreachability Detection, etc., are expe= cted to be provided

> as specified in this document.

Since 6rd doesn’t specify otherwise, I assume th= at redirects, next-hop

determination, NUD, etc are provided as specified in R= FC 4861, correct?

 

Compare how ISATAP addresses these in RFC 5214 section= 8, and 6RD

needs to have a similar level of coverage.<= /p>

 

My second major concern with the current draft is that= it is too limited

in scope compared to 6to4 where I believe it should be= able to be used

in place of 6to4 (other than having private relays wit= h a network-specific

prefix, instead of public relays with a well-known prefix).  Specifically

there are two limitations introduced without good reas= on, that need

to be removed:

1)&n= bsp;     The draft says a CE must have 1 or more LAN interface.  6to4

can be used even when you don’t have a LAN inter= face (up). 

Remove this limitation, as it’s not necessary an= d doesn’t affect anything

else.

2)&n= bsp;     The DHCP option format for configuring a CPE is onl= y capable

of holding a single BR address.  To be able to re= place 6to4, this must

be capable of passing a list.  Today many 6to4 ga= teways are capable

of using a list, and adding one default route for each= relay address,

and this can facilitate load-spreading, failover, etc.=   There’s no

reason given to make 6rd less capable in this respect.=   If a SP doesn’t

want that, they don’t have to provide more than = 1 address, but

we should not prevent an SP from providing service equivalent to

what can be done with 6to4 today.

 

-Dave

 

--_000_E4561B14EE2A3E4E9D478EBFB5416E1B29B35A69TK5EX14MBXW653w_-- From alain_durand@cable.comcast.com Sun Nov 8 03:39:10 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C910528C0EB for ; Sun, 8 Nov 2009 03:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.859 X-Spam-Level: X-Spam-Status: No, score=-5.859 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49YwzHMYcIsF for ; Sun, 8 Nov 2009 03:39:10 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id D46C928C0DF for ; Sun, 8 Nov 2009 03:39:09 -0800 (PST) Received: from ([24.40.15.118]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.60034086; Sun, 08 Nov 2009 06:39:31 -0500 Received: from PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 06:39:32 -0500 Received: from 10.17.2.237 ([10.17.2.237]) by PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) with Microsoft Exchange Server HTTP-DAV ; Sun, 8 Nov 2009 11:39:31 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Sun, 08 Nov 2009 06:39:29 -0500 From: "Durand, Alain" To: "softwires@ietf.org" Message-ID: Thread-Topic: Meeting in Hiroshima Thread-Index: AcpgaCGYnW3SdXo+wEeGw/M1s0sJgQ== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3340507169_338877" X-OriginalArrivalTime: 08 Nov 2009 11:39:32.0728 (UTC) FILETIME=[23D18780:01CA6068] Subject: [Softwires] Meeting in Hiroshima X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 11:39:10 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3340507169_338877 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Please note that the meeting is at 9am on Monday... We will need a minute taker and a Jabber scribe. Here is the agenda: WG items Mark Townsley, 6rd update 17 Yiu Lee, basic DS-lite architecture 17 New items Mat Ford, shared address issues 15 Yiu Lee, 6rd-UDP 13 Sheng Jiang, GRE + Discovery 7 Sri Gundavelli, DS-lite in mobility 7 Pierre Levis, Deploying DS-lite 7 Yong, Softwire Mesh Multicast 7 Xu Xiaohu, Tunnel end point in BGP 7 Remi Depres, SAM 7 - Alain. --B_3340507169_338877 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Meeting in Hiroshima Please note that the meeting is at 9am on Monday...
We will need a minute taker and a Jabber scribe.

Here is the agenda:

WG items
  Mark Townsley, 6rd update   17
  Yiu Lee, basic DS-lite architecture  17

New items
  Mat Ford, shared address issues  15
  Yiu Lee, 6rd-UDP   13
  Sheng Jiang, GRE + Discovery 7
  Sri Gundavelli, DS-lite in mobility 7
  Pierre Levis, Deploying DS-lite 7
  Yong, Softwire Mesh Multicast 7
  Xu Xiaohu, Tunnel end point in BGP 7
  Remi Depres, SAM 7


  - Alain. --B_3340507169_338877-- From townsley@cisco.com Sun Nov 8 09:30:29 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9CAE3A67F2 for ; Sun, 8 Nov 2009 09:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5G52Ht5SAEP for ; Sun, 8 Nov 2009 09:30:28 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A528F3A67A6 for ; Sun, 8 Nov 2009 09:30:28 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAKuO9kqrR7Ht/2dsb2JhbACBTcEglj+CP4F/BIFoeA X-IronPort-AV: E=Sophos;i="4.44,704,1249257600"; d="scan'208";a="267929667" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 08 Nov 2009 17:30:54 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA8HUsSs029427; Sun, 8 Nov 2009 17:30:54 GMT Received: from host-113-121.meeting.ietf.org (tky-vpn-client-230-74.cisco.com [10.70.230.74]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id nA8HUrW28457; Sun, 8 Nov 2009 09:30:53 -0800 (PST) Message-ID: <4AF7004A.8080508@cisco.com> Date: Mon, 09 Nov 2009 02:30:50 +0900 From: Mark Townsley User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dave Thaler References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "softwires@ietf.org" Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 17:30:29 -0000 Dave - fyi draft-ietf-softwire-ipv6-6rd-01.txt is the latest spec, the draft-townsley version is retired. Thanks for the review, jetlagged comments inline... Dave Thaler wrote: > > While this draft is a good start (and is arguably as good as the 6to4 > spec was), > > I think it still needs a bunch of work, as we’ve learned from the 6to4 > experience. > > First the draft needs to discuss the properties of IPv6 on the 6rd > interface: > > 1) What’s the link model? Presumably it’s an NBMA interface like 6to4, > > in which case multicast isn’t supported. But the document needs to > > discuss this. > Yes, it is, and perhaps we are relying too much on the 6to4 basis here. I don't want to rewrite RFC3056 completely in this document, but we can certainly try to be more clear here on the link-model. > > 2) One of the problems with 6to4 is that it violates the IPv6 RFCs by > > not having a link-local address (see RFC 4291 section 2.1, section > paragraph, > > for example). Will 6rd repeat that violation or not? > > Can packets be sent with a link-local address? > Offhand, I see no need for a link-local here, but I think the right thing to do would be to use the associated IPv4 address to create an fe80:: link-local ala ISATAP. > > 3) The use of Neighbor Discovery on the interface needs to be > > discussed. Are unicast RS/RA legal? > > Presumably normal router discovery > > and address resolution are not used since it’s NBMA. > Right, neighbor discovery inside the tunnel is not required. > > As RFC 4861 says: > > > Unless specified otherwise (in a document that covers operating IP > > > over a particular link type) this document applies to all link types. > > > However, because ND uses link-layer multicast for some of its > > > services, it is possible that on some link types (e.g., Non-Broadcast > > > Multi-Access (NBMA) links), alternative protocols or mechanisms to > > > implement those services will be specified (in the appropriate > > > document covering the operation of IP over a particular link type). > > > The services described in this document that are not directly > > > dependent on multicast, such as Redirects, Next-hop determination, > > > Neighbor Unreachability Detection, etc., are expected to be provided > > > as specified in this document. > > Since 6rd doesn’t specify otherwise, I assume that redirects, next-hop > > determination, NUD, etc are provided as specified in RFC 4861, correct? > > Compare how ISATAP addresses these in RFC 5214 section 8, and 6RD > > needs to have a similar level of coverage. > So far this hasn't been important for the implementations we have, but for completeness I agree we should specify this fully in the spec. > > My second major concern with the current draft is that it is too limited > > in scope compared to 6to4 where I believe it should be able to be used > > in place of 6to4 (other than having private relays with a network-specific > > prefix, instead of public relays with a well-known prefix). Specifically > > there are two limitations introduced without good reason, that need > > to be removed: > > 1) The draft says a CE must have 1 or more LAN interface. 6to4 > > can be used even when you don’t have a LAN interface (up). > > Remove this limitation, as it’s not necessary and doesn’t affect anything > > else. > Yes, of course, the CE could always be a host. > > 2) The DHCP option format for configuring a CPE is only capable > > of holding a single BR address. To be able to replace 6to4, this must > > be capable of passing a list. Today many 6to4 gateways are capable > > of using a list, and adding one default route for each relay address, > > and this can facilitate load-spreading, failover, etc. There’s no > > reason given to make 6rd less capable in this respect. If a SP doesn’t > > want that, they don’t have to provide more than 1 address, but > > we should not prevent an SP from providing service equivalent to > > what can be done with 6to4 today. > IPv4 anycast is an important part of the design here as it eliminates the complexity associated with the CE keeping track of which BR to use. It might seem trivial for a CE to have multiple BR addresses, but this comes with responsibility and associated complexity of knowing which are up, down, loaded or not, etc. 6rd is designed to operate in an SP network utilizing as much IPv4 infrastructure as possible, that includes load-balancing, failover, etc. provided by using a single IPv4 anycast address. - Mark > > -Dave > > ------------------------------------------------------------------------ > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From dthaler@microsoft.com Sun Nov 8 12:09:55 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3D073A6881 for ; Sun, 8 Nov 2009 12:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9AMxk9Sp5Xx for ; Sun, 8 Nov 2009 12:09:55 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 0B1E33A67EB for ; Sun, 8 Nov 2009 12:09:55 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 8 Nov 2009 12:10:37 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server id 14.0.639.20; Sun, 8 Nov 2009 12:10:20 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Sun, 8 Nov 2009 12:10:19 -0800 From: Dave Thaler To: Mark Townsley Thread-Topic: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt Thread-Index: AQHKYJk/oFPStRqnO0yZ+yxr6I/NWZEsnU3Q Date: Sun, 8 Nov 2009 20:10:18 +0000 Message-ID: References: <4AF7004A.8080508@cisco.com> In-Reply-To: <4AF7004A.8080508@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 20:09:55 -0000 Mark Townley wrote: [...] > > 2) The DHCP option format for configuring a CPE is only capable > > > > of holding a single BR address. To be able to replace 6to4, this must > > > > be capable of passing a list. Today many 6to4 gateways are capable > > > > of using a list, and adding one default route for each relay address, > > > > and this can facilitate load-spreading, failover, etc. There's no > > > > reason given to make 6rd less capable in this respect. If a SP > doesn't > > > > want that, they don't have to provide more than 1 address, but > > > > we should not prevent an SP from providing service equivalent to > > > > what can be done with 6to4 today. > > > IPv4 anycast is an important part of the design here as it eliminates > the complexity associated with the CE keeping track of which BR to use. > It might seem trivial for a CE to have multiple BR addresses, but this > comes with responsibility and associated complexity of knowing which > are > up, down, loaded or not, etc. 6rd is designed to operate in an SP > network utilizing as much IPv4 infrastructure as possible, that > includes > load-balancing, failover, etc. provided by using a single IPv4 anycast > address. That is not justification for preventing the use of multiple addresses. I agree that use of an anycast is good, but we should not force this on anyone. There are also cases where use of multiple addresses can provide much better load-splitting and failover than anycast can. -Dave From Fred.L.Templin@boeing.com Sun Nov 8 12:31:23 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC6E53A67B8 for ; Sun, 8 Nov 2009 12:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQDhHbx5fSTK for ; Sun, 8 Nov 2009 12:31:22 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 990743A6768 for ; Sun, 8 Nov 2009 12:31:22 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id nA8KVgjW019054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 8 Nov 2009 12:31:43 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id nA8KVgQb020781; Sun, 8 Nov 2009 14:31:42 -0600 (CST) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id nA8KVfPa020777 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Sun, 8 Nov 2009 14:31:42 -0600 (CST) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Sun, 8 Nov 2009 12:31:41 -0800 From: "Templin, Fred L" To: Mark Townsley , Dave Thaler Date: Sun, 8 Nov 2009 12:31:38 -0800 Thread-Topic: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt Thread-Index: AcpgmTzpvzZpAaoiQEauug7Rku8bwQAFi4xQ Message-ID: <12F4112206976147A34FEC0277597CCF27A5229F07@XCH-NW-15V.nw.nos.boeing.com> References: <4AF7004A.8080508@cisco.com> In-Reply-To: <4AF7004A.8080508@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 20:31:23 -0000 In addition to Dave's comments, other concerns are: - 6rd requires that CPE routers always assign a static IPv4 address in order to avoid IPv6 renumbering, i.e., IPv6 prefix is inseparable from the IPv4 address. Hence, it is not compatible with dynamic IPv4 address autoconfig. - Use of anycast does not allow the CPE router to select between multiple available exit routers. Instead, exit router selection is through IPv4 routing in the ISP network, which is non-deterministic from the CPE router's point of view. - Non-use of IPv6 ND does not allow for dynamic configuration of lifetimes for default and more-specific routes. Also, no NUD mechanism. - Tunnel path MTU is left to chance of the ISP operator's link deployment practices. Under-provisioned or mis-configured links will show up as sources of IP fragmentation. - Reducing tunnel MTU to account for the encapsulation header (e.g., to 1480) ensures that hosts behind the CPE router will see unnecessarily excessive path MTU interactions. - No means for migration to larger MTUs (e.g. 9KB) as links in the ISP network incrementally deploy larger MTUs. Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On B= ehalf Of Mark Townsley > Sent: Sunday, November 08, 2009 9:31 AM > To: Dave Thaler > Cc: softwires@ietf.org > Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt >=20 >=20 > Dave - fyi draft-ietf-softwire-ipv6-6rd-01.txt is the latest spec, the > draft-townsley version is retired. Thanks for the review, jetlagged comme= nts > inline... >=20 > Dave Thaler wrote: > > > > While this draft is a good start (and is arguably as good as the 6to4 > > spec was), > > > > I think it still needs a bunch of work, as we've learned from the 6to4 > > experience. > > > > First the draft needs to discuss the properties of IPv6 on the 6rd > > interface: > > > > 1) What's the link model? Presumably it's an NBMA interface like 6to4, > > > > in which case multicast isn't supported. But the document needs to > > > > discuss this. > > >=20 > Yes, it is, and perhaps we are relying too much on the 6to4 basis here. > I don't want to rewrite RFC3056 completely in this document, but we can > certainly try to be more clear here on the link-model. >=20 > > > > 2) One of the problems with 6to4 is that it violates the IPv6 RFCs by > > > > not having a link-local address (see RFC 4291 section 2.1, section > > paragraph, > > > > for example). Will 6rd repeat that violation or not? > > > > Can packets be sent with a link-local address? > > > Offhand, I see no need for a link-local here, but I think the right > thing to do would be to use the associated IPv4 address to create an > fe80:: link-local ala ISATAP. > > > > 3) The use of Neighbor Discovery on the interface needs to be > > > > discussed. Are unicast RS/RA legal? > > > > Presumably normal router discovery > > > > and address resolution are not used since it's NBMA. > > > Right, neighbor discovery inside the tunnel is not required. > > > > As RFC 4861 says: > > > > > Unless specified otherwise (in a document that covers operating IP > > > > > over a particular link type) this document applies to all link types. > > > > > However, because ND uses link-layer multicast for some of its > > > > > services, it is possible that on some link types (e.g., Non-Broadcast > > > > > Multi-Access (NBMA) links), alternative protocols or mechanisms to > > > > > implement those services will be specified (in the appropriate > > > > > document covering the operation of IP over a particular link type). > > > > > The services described in this document that are not directly > > > > > dependent on multicast, such as Redirects, Next-hop determination, > > > > > Neighbor Unreachability Detection, etc., are expected to be provided > > > > > as specified in this document. > > > > Since 6rd doesn't specify otherwise, I assume that redirects, next-hop > > > > determination, NUD, etc are provided as specified in RFC 4861, correct? > > > > Compare how ISATAP addresses these in RFC 5214 section 8, and 6RD > > > > needs to have a similar level of coverage. > > > So far this hasn't been important for the implementations we have, but > for completeness I agree we should specify this fully in the spec. > > > > My second major concern with the current draft is that it is too limite= d > > > > in scope compared to 6to4 where I believe it should be able to be used > > > > in place of 6to4 (other than having private relays with a network-speci= fic > > > > prefix, instead of public relays with a well-known prefix). Specificall= y > > > > there are two limitations introduced without good reason, that need > > > > to be removed: > > > > 1) The draft says a CE must have 1 or more LAN interface. 6to4 > > > > can be used even when you don't have a LAN interface (up). > > > > Remove this limitation, as it's not necessary and doesn't affect anythi= ng > > > > else. > > > Yes, of course, the CE could always be a host. > > > > 2) The DHCP option format for configuring a CPE is only capable > > > > of holding a single BR address. To be able to replace 6to4, this must > > > > be capable of passing a list. Today many 6to4 gateways are capable > > > > of using a list, and adding one default route for each relay address, > > > > and this can facilitate load-spreading, failover, etc. There's no > > > > reason given to make 6rd less capable in this respect. If a SP doesn't > > > > want that, they don't have to provide more than 1 address, but > > > > we should not prevent an SP from providing service equivalent to > > > > what can be done with 6to4 today. > > > IPv4 anycast is an important part of the design here as it eliminates > the complexity associated with the CE keeping track of which BR to use. > It might seem trivial for a CE to have multiple BR addresses, but this > comes with responsibility and associated complexity of knowing which are > up, down, loaded or not, etc. 6rd is designed to operate in an SP > network utilizing as much IPv4 infrastructure as possible, that includes > load-balancing, failover, etc. provided by using a single IPv4 anycast > address. >=20 > - Mark > > > > -Dave > > > > -----------------------------------------------------------------------= - > > > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > > >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From jhw@apple.com Sun Nov 8 13:38:43 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CC4F28C0D0 for ; Sun, 8 Nov 2009 13:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.547 X-Spam-Level: X-Spam-Status: No, score=-105.547 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40Lgn5b52i7q for ; Sun, 8 Nov 2009 13:38:42 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 738CD3A69BC for ; Sun, 8 Nov 2009 13:38:42 -0800 (PST) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id 5A9F578E9669 for ; Sun, 8 Nov 2009 13:39:08 -0800 (PST) X-AuditID: 1180711d-b7b18ae000001001-02-4af73a7b1c3b Received: from [17.151.90.55] (Unknown_Domain [17.151.90.55]) (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 70.AF.04097.C7A37FA4; Sun, 8 Nov 2009 13:39:08 -0800 (PST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v1076) From: james woodyatt In-Reply-To: <12F4112206976147A34FEC0277597CCF27A5229F07@XCH-NW-15V.nw.nos.boeing.com> Date: Sun, 8 Nov 2009 13:39:07 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <4AF7004A.8080508@cisco.com> <12F4112206976147A34FEC0277597CCF27A5229F07@XCH-NW-15V.nw.nos.boeing.com> To: softwires@ietf.org X-Mailer: Apple Mail (2.1076) X-Brightmail-Tracker: AAAAAQAAAZE= Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 21:38:43 -0000 On Nov 8, 2009, at 12:31 , Templin, Fred L wrote: > > - 6rd requires that CPE routers always assign a static > IPv4 address in order to avoid IPv6 renumbering, i.e., > IPv6 prefix is inseparable from the IPv4 address. Hence, > it is not compatible with dynamic IPv4 address autoconfig. Not exactly. It's true that 6RD couples IPv4 address assignment with IPv6 prefix assignment. If the IPv4 address assignment is dynamic, it just means that the CPE router will have to renumber the local IPv6 prefix whenever the IPv4 address changes. This isn't supposed to be a crisis event with IPv6, like it seems to have become with IPv4, and experience with 6to4 router implementations as residential gateways shows that dynamic IPv6 prefix renumbering isn't enough of a problem to make 6RD inappropriate for IPv6 transition engineering. > - Use of anycast does not allow the CPE router to select > between multiple available exit routers. Instead, exit > router selection is through IPv4 routing in the ISP > network, which is non-deterministic from the CPE router's > point of view. Having a fair amount of experience with implementing residential CPE dual-stack IPv4/IPv6 gateway routers, I hope I have some authority with which to declare this as a FEATURE and not a problem. Not having to burden the residential user with having to choose an IPv6 relay endpoint on their own, when this is really something the service provider should be handling transparently to the subscriber, seems like a desirable quality in a protocol for our purposes here. > - Non-use of IPv6 ND does not allow for dynamic configuration > of lifetimes for default and more-specific routes. Also, > no NUD mechanism. What? Seriously, I don't understand the concern behind this comment. Could you elaborate? > - Tunnel path MTU is left to chance of the ISP operator's > link deployment practices. Under-provisioned or > mis-configured links will show up as sources of IP > fragmentation. I suppose it would help if the specification made explicit the need for IPv4 path MTU discovery to work, i.e. there must be a clear path for ICMP4 errors to pass on the same path as the proto 41 packets, and both tunnel endpoints need to cope with the path MTU discovery problem appropriately. > - Reducing tunnel MTU to account for the encapsulation header > (e.g., to 1480) ensures that hosts behind the CPE router > will see unnecessarily excessive path MTU interactions. Depends on your expectations for the necessity of path MTU discovery. I don't see how there is a problem: the CPE router and the 6RD relay negotiate the path MTU shortly after the CPE router obtains its 6RD configuration, and one would expect the path MTU to be relatively stable over time in a real-world deployment. > - No means for migration to larger MTUs (e.g. 9KB) as links > in the ISP network incrementally deploy larger MTUs. The migration path is to go native IPv6, if you ask me. Again, I view this as a feature: it provides for a natural sunset provision. -- james woodyatt member of technical staff, communications engineering From Fred.L.Templin@boeing.com Sun Nov 8 14:43:46 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 654793A6839 for ; Sun, 8 Nov 2009 14:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UszOk3Z-gk2y for ; Sun, 8 Nov 2009 14:43:45 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 5C9363A67F2 for ; Sun, 8 Nov 2009 14:43:45 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id nA8Mi6iH002374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 8 Nov 2009 14:44:07 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id nA8Mi6d1024390; Sun, 8 Nov 2009 14:44:06 -0800 (PST) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id nA8Mi61S024387 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Sun, 8 Nov 2009 14:44:06 -0800 (PST) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Sun, 8 Nov 2009 14:44:06 -0800 From: "Templin, Fred L" To: james woodyatt , "softwires@ietf.org" Date: Sun, 8 Nov 2009 14:44:03 -0800 Thread-Topic: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt Thread-Index: Acpgu+jOYD9MWdubSyyd0LVNCJLB1wABmMYg Message-ID: <12F4112206976147A34FEC0277597CCF27A5229F0B@XCH-NW-15V.nw.nos.boeing.com> References: <4AF7004A.8080508@cisco.com><12F41122069761 47A34FEC0277597CCF27A5229F07@XCH-NW-15V.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 22:43:46 -0000 > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On B= ehalf Of james woodyatt > Sent: Sunday, November 08, 2009 1:39 PM > To: softwires@ietf.org > Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt >=20 > On Nov 8, 2009, at 12:31 , Templin, Fred L wrote: > > > > - 6rd requires that CPE routers always assign a static > > IPv4 address in order to avoid IPv6 renumbering, i.e., > > IPv6 prefix is inseparable from the IPv4 address. Hence, > > it is not compatible with dynamic IPv4 address autoconfig. >=20 > Not exactly. I'm not sure how you mean "not exactly"? > It's true that 6RD couples IPv4 address assignment with > IPv6 prefix assignment. That is exactly what I am saying. > If the IPv4 address assignment is dynamic, it > just means that the CPE router will have to renumber the local IPv6 > prefix whenever the IPv4 address changes. You mean renumber the global IPv6 prefix, right? This renumbering has to percolate all the way down through the customer premises. > This isn't supposed to be a > crisis event with IPv6, like it seems to have become with IPv4, and > experience with 6to4 router implementations as residential gateways > shows that dynamic IPv6 prefix renumbering isn't enough of a problem > to make 6RD inappropriate for IPv6 transition engineering. We have seen evidence that "renumbering still needs work", even in IPv6. > > - Use of anycast does not allow the CPE router to select > > between multiple available exit routers. Instead, exit > > router selection is through IPv4 routing in the ISP > > network, which is non-deterministic from the CPE router's > > point of view. >=20 > Having a fair amount of experience with implementing residential CPE > dual-stack IPv4/IPv6 gateway routers, I hope I have some authority > with which to declare this as a FEATURE and not a problem. Not having > to burden the residential user with having to choose an IPv6 relay > endpoint on their own, when this is really something the service > provider should be handling transparently to the subscriber, seems > like a desirable quality in a protocol for our purposes here. You may have missed an aspect of my point, or I may not have expressed it fully. When the CPE router discovers addresses of ISP border routers and performs neighbor discovery exchanges with them, the ISP is still the one that informs the CPE routers of best choices. So, this is not a "burden" on the CPE router, and the ISP still has the means to engineer the traffic. It simply gives the CPE router the means to make the best choices based on what the ISP tells it. > > - Non-use of IPv6 ND does not allow for dynamic configuration > > of lifetimes for default and more-specific routes. Also, > > no NUD mechanism. >=20 > What? Seriously, I don't understand the concern behind this comment. > Could you elaborate? Like when an RA advertises a PIO or an RIO they have lifetimes that the CPE router learns. These lifetimes influence router selection and router reachability in a way that is not available without them.=20 > > - Tunnel path MTU is left to chance of the ISP operator's > > link deployment practices. Under-provisioned or > > mis-configured links will show up as sources of IP > > fragmentation. >=20 > I suppose it would help if the specification made explicit the need > for IPv4 path MTU discovery to work, i.e. there must be a clear path > for ICMP4 errors to pass on the same path as the proto 41 packets, and > both tunnel endpoints need to cope with the path MTU discovery problem > appropriately. The only way to ensure this is to ensure that there will be no ICMP filtering and to ensure that there can be no source address spoofing inside of the ISP network. Then, if you want to leverage IPv4 path MTU discovery instead of defer to IPv4 fragmentation the CPE routers will need to maintain a neighbor cache with per-neighbor MTU values, which adds state to an otherwise stateless model. =20 > > - Reducing tunnel MTU to account for the encapsulation header > > (e.g., to 1480) ensures that hosts behind the CPE router > > will see unnecessarily excessive path MTU interactions. >=20 > Depends on your expectations for the necessity of path MTU discovery. > I don't see how there is a problem: the CPE router and the 6RD relay > negotiate the path MTU shortly after the CPE router obtains its 6RD > configuration, and one would expect the path MTU to be relatively > stable over time in a real-world deployment. When applications start up on hosts that connect to a 1500 link, they will often want to send 1500 packets. Even if the CPE router were to cache smaller per neighbor MTUs (state), the hosts will often be disappointed to see their 1500 packets dropped and need to ratchet down their path MTU estimates. But for hosts, path MTU is per-destination (not per- neighbor) so they will try again with 1500s for each distinct destination even if they keep getting denied by the CPE. This is the way path MTU discovery works, but the optimum condition is to not invoke path MTU discovery at all if possible. > > - No means for migration to larger MTUs (e.g. 9KB) as links > > in the ISP network incrementally deploy larger MTUs. >=20 > The migration path is to go native IPv6, if you ask me. Again, I view > this as a feature: it provides for a natural sunset provision. This is obviously a matter for debate. Native IPv6 at the edges is a yes for sure; IPv6 in the middle is a matter for open debate since a well-deployed tunneling scenario may make it unnecessary. Fred fred.l.templin@boeing.com > -- > james woodyatt > member of technical staff, communications engineering >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From alain_durand@cable.comcast.com Sun Nov 8 15:01:44 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 132703A67B6 for ; Sun, 8 Nov 2009 15:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[AWL=1.051, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fowb4XeM3orh for ; Sun, 8 Nov 2009 15:01:43 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 0CDFB3A6819 for ; Sun, 8 Nov 2009 15:01:42 -0800 (PST) Received: from ([24.40.15.118]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.60064721; Sun, 08 Nov 2009 18:02:07 -0500 Received: from PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 18:02:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA60C7.7E9DE94E" Date: Sun, 8 Nov 2009 18:02:07 -0500 Message-ID: <7EA88CE98846094792D27A1561141A0C01CD47B0@PACORPEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Meeting in Hiroshima Thread-Index: AcpgaCGYnW3SdXo+wEeGw/M1s0sJgQAX110t From: "Durand, Alain" To: X-OriginalArrivalTime: 08 Nov 2009 23:02:07.0663 (UTC) FILETIME=[7EDCABF0:01CA60C7] Subject: Re: [Softwires] Meeting in Hiroshima X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 23:01:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA60C7.7E9DE94E Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIG5vdGUgdGhhdCB0aGUgbWVldGluZyB3aWxsIGJlIGluIE9yY2hpZCB3ZXN0DQoNCi0g QWxhaW4uDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRnJvbTogc29m dHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmcgPHNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnPiANClRv OiBzb2Z0d2lyZXNAaWV0Zi5vcmcgPHNvZnR3aXJlc0BpZXRmLm9yZz4gDQpTZW50OiBTdW4gTm92 IDA4IDA2OjM5OjI5IDIwMDkNClN1YmplY3Q6IFtTb2Z0d2lyZXNdIE1lZXRpbmcgaW4gSGlyb3No aW1hIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgdGhlIG1lZXRpbmcgaXMgYXQgOWFtIG9uIE1vbmRh eS4uLg0KV2Ugd2lsbCBuZWVkIGEgbWludXRlIHRha2VyIGFuZCBhIEphYmJlciBzY3JpYmUuDQoN CkhlcmUgaXMgdGhlIGFnZW5kYToNCg0KV0cgaXRlbXMNCiAgTWFyayBUb3duc2xleSwgNnJkIHVw ZGF0ZSAgIDE3DQogIFlpdSBMZWUsIGJhc2ljIERTLWxpdGUgYXJjaGl0ZWN0dXJlICAxNw0KDQpO ZXcgaXRlbXMNCiAgTWF0IEZvcmQsIHNoYXJlZCBhZGRyZXNzIGlzc3VlcyAgMTUNCiAgWWl1IExl ZSwgNnJkLVVEUCAgIDEzDQogIFNoZW5nIEppYW5nLCBHUkUgKyBEaXNjb3ZlcnkgNw0KICBTcmkg R3VuZGF2ZWxsaSwgRFMtbGl0ZSBpbiBtb2JpbGl0eSA3DQogIFBpZXJyZSBMZXZpcywgRGVwbG95 aW5nIERTLWxpdGUgNw0KICBZb25nLCBTb2Z0d2lyZSBNZXNoIE11bHRpY2FzdCA3DQogIFh1IFhp YW9odSwgVHVubmVsIGVuZCBwb2ludCBpbiBCR1AgNw0KICBSZW1pIERlcHJlcywgU0FNIDcNCg0K DQogIC0gQWxhaW4uIA0K ------_=_NextPart_001_01CA60C7.7E9DE94E Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PEhUTUw+DQo8SEVBRD4NCjxUSVRMRT5NZWV0aW5nIGluIEhpcm9zaGltYTwvVElUTEU+DQo8L0hF QUQ+DQo8Qk9EWT48ZGl2Pjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+DQpQbGVh c2Ugbm90ZSB0aGF0IHRoZSBtZWV0aW5nIHdpbGwgYmUgaW4gT3JjaGlkIHdlc3Q8YnI+PGJyPiAg LSBBbGFpbi48YnI+PC9mb250PjwvZGl2Pg0KPGJyPjxkaXY+PGhyIHNpemU9MiB3aWR0aD0iMTAw JSIgYWxpZ249Y2VudGVyIHRhYmluZGV4PS0xPg0KPGZvbnQgZmFjZT1UYWhvbWEgc2l6ZT0yPg0K PGI+RnJvbTwvYj46IHNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnICZsdDtzb2Z0d2lyZXMtYm91 bmNlc0BpZXRmLm9yZyZndDsNPGJyPjxiPlRvPC9iPjogc29mdHdpcmVzQGlldGYub3JnICZsdDtz b2Z0d2lyZXNAaWV0Zi5vcmcmZ3Q7DTxicj48Yj5TZW50PC9iPjogU3VuIE5vdiAwOCAwNjozOToy OSAyMDA5PGJyPjxiPlN1YmplY3Q8L2I+OiBbU29mdHdpcmVzXSBNZWV0aW5nIGluIEhpcm9zaGlt YQ08YnI+PC9mb250Pjxicj48L2Rpdj4NCg0KPEZPTlQgRkFDRT0iQ2FsaWJyaSwgVmVyZGFuYSwg SGVsdmV0aWNhLCBBcmlhbCI+PFNQQU4gU1RZTEU9J2ZvbnQtc2l6ZToxMXB0Jz5QbGVhc2Ugbm90 ZSB0aGF0IHRoZSBtZWV0aW5nIGlzIGF0IDlhbSBvbiBNb25kYXkuLi48QlI+DQpXZSB3aWxsIG5l ZWQgYSBtaW51dGUgdGFrZXIgYW5kIGEgSmFiYmVyIHNjcmliZS48QlI+DQo8QlI+DQpIZXJlIGlz IHRoZSBhZ2VuZGE6PEJSPg0KPEJSPg0KV0cgaXRlbXM8QlI+DQombmJzcDsmbmJzcDtNYXJrIFRv d25zbGV5LCA2cmQgdXBkYXRlICZuYnNwOyZuYnNwOzE3PEJSPg0KJm5ic3A7Jm5ic3A7WWl1IExl ZSwgYmFzaWMgRFMtbGl0ZSBhcmNoaXRlY3R1cmUgJm5ic3A7MTc8QlI+DQo8QlI+DQpOZXcgaXRl bXM8QlI+DQombmJzcDsmbmJzcDtNYXQgRm9yZCwgc2hhcmVkIGFkZHJlc3MgaXNzdWVzICZuYnNw OzE1PEJSPg0KJm5ic3A7Jm5ic3A7WWl1IExlZSwgNnJkLVVEUCAmbmJzcDsmbmJzcDsxMzxCUj4N CiZuYnNwOyZuYnNwO1NoZW5nIEppYW5nLCBHUkUgKyBEaXNjb3ZlcnkgNzxCUj4NCiZuYnNwOyZu YnNwO1NyaSBHdW5kYXZlbGxpLCBEUy1saXRlIGluIG1vYmlsaXR5IDc8QlI+DQombmJzcDsmbmJz cDtQaWVycmUgTGV2aXMsIERlcGxveWluZyBEUy1saXRlIDc8QlI+DQombmJzcDsmbmJzcDtZb25n LCBTb2Z0d2lyZSBNZXNoIE11bHRpY2FzdCA3PEJSPg0KJm5ic3A7Jm5ic3A7WHUgWGlhb2h1LCBU dW5uZWwgZW5kIHBvaW50IGluIEJHUCA3PEJSPg0KJm5ic3A7Jm5ic3A7UmVtaSBEZXByZXMsIFNB TSA3PEJSPg0KPEJSPg0KPEJSPg0KJm5ic3A7Jm5ic3A7LSBBbGFpbi48L1NQQU4+PC9GT05UPg0K PC9CT0RZPg0KPC9IVE1MPg0KDQo= ------_=_NextPart_001_01CA60C7.7E9DE94E-- From brian.e.carpenter@gmail.com Sun Nov 8 16:27:46 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2F3F3A6A36 for ; Sun, 8 Nov 2009 16:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8N5HYgncErSz for ; Sun, 8 Nov 2009 16:27:46 -0800 (PST) Received: from mail-gx0-f212.google.com (mail-gx0-f212.google.com [209.85.217.212]) by core3.amsl.com (Postfix) with ESMTP id 0A89B3A6A35 for ; Sun, 8 Nov 2009 16:27:45 -0800 (PST) Received: by gxk4 with SMTP id 4so2616532gxk.8 for ; Sun, 08 Nov 2009 16:28:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=uifY1ubpSV1cmhoOLxAhHzpqAoDfK7YS10a4dvmVFKA=; b=BnVFSj4AJOH3F9ULy1n8Z6kSHH2QgaYEVPwJl6NGp5lS1YrcIaJnbLzSQgwvOk0tm3 cZJ4LmxJQOAlyRTF8ZWjbd8TUaTbe2gKFivDsfQLebKpf2ZS2S350t2yDJK68/Mr9lzl RM5ZEWSJp1SnC0yT9p5xuWVdOz9ZOJbM1nO2M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; b=FG75Q/qIGUZg7QQ05xH+vhWZ2bO+3myBpC892x2xxHf5f7ioeDUAXzXfQsaWT1PZUF 2hWVB6+qI3G+lxWpOiich4mseMBClctFE+f7vgcje7SKBxxoXEekjdgY2Y6/GWv0otkC HFNMTjPYcPylyAN0wpy4moT3l6nlro0Brh4Kw= Received: by 10.151.1.3 with SMTP id d3mr12001375ybi.305.1257726488258; Sun, 08 Nov 2009 16:28:08 -0800 (PST) Received: from ?133.93.16.203? (host-16-203.meeting.ietf.org [133.93.16.203]) by mx.google.com with ESMTPS id 15sm1180755gxk.12.2009.11.08.16.28.06 (version=SSLv3 cipher=RC4-MD5); Sun, 08 Nov 2009 16:28:07 -0800 (PST) Message-ID: <4AF76212.60903@gmail.com> Date: Mon, 09 Nov 2009 13:28:02 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: softwires@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Softwires] MTU issue for 6RD (and 6to4) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 00:27:47 -0000 Strangely, I only realised yesterday that Teredo has a recommended MTU of 1280, whereas 6to4 doesn't, and simply refers to the general discussion of MTU in the basic transition tunnel specs. 6RD follows the 6to4 approach. The reason I realised this difference was a comment on an IPv6 list we run in NZ; here is an out of context extract: > On 2009-11-08 15:37, TreeNet Admin wrote: >> > Donald Neal wrote: > > ... >>> >> The step-wise progression of the graphs for these larger packets seems >>> >> to reflect the way in which packets are fitted into the available MTU. A >>> >> reduction in MTU from 1500 to 1280 with a resulting throughput >>> >> loss of 13% wouldn't be undertaken lightly. The 4.9% throughput >>> >> improvement gained by taking MTU up to a level where 4096 bytes of >>> >> payload will fit inside the MTU might be more attractive. >> > >> > Interesting things to note here: >> > >> > Default MTU of teredo: 1280 >> > Default MTU of 6to4: 1500 >> > (requires manual reduction to ~1400 for trouble evasion) Note the last line. Should we be specifying a default MTU of 1280 for 6RD too? (The same question applies retroactively to 6to4, of course.) Brian From Fred.L.Templin@boeing.com Sun Nov 8 16:36:16 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 724CC3A6A35 for ; Sun, 8 Nov 2009 16:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZjVoA9humdE for ; Sun, 8 Nov 2009 16:36:15 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 982723A6909 for ; Sun, 8 Nov 2009 16:36:15 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id nA90ac5S001164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 8 Nov 2009 18:36:38 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id nA90abpN008511 for ; Sun, 8 Nov 2009 16:36:37 -0800 (PST) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id nA90abKA008503 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Sun, 8 Nov 2009 16:36:37 -0800 (PST) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Sun, 8 Nov 2009 16:36:37 -0800 From: "Templin, Fred L" To: "softwires@ietf.org" Date: Sun, 8 Nov 2009 16:36:35 -0800 Thread-Topic: Router-to-router tunneling in ISATAP Thread-Index: Acpgu+jOYD9MWdubSyyd0LVNCJLB1wABmMYgAAQLhfA= Message-ID: <12F4112206976147A34FEC0277597CCF27A5229F11@XCH-NW-15V.nw.nos.boeing.com> References: <4AF7004A.8080508@cisco.com><12F41122069761 47A34FEC0277597CCF27A5229F07@XCH-NW-15V.nw.nos.boeing.com> <12F4112206976147A34FEC0277597CCF27A5229F0B@XCH-NW-15V.nw.nos.boeing.com> In-Reply-To: <12F4112206976147A34FEC0277597CCF27A5229F0B@XCH-NW-15V.nw.nos.boeing.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 Subject: [Softwires] Router-to-router tunneling in ISATAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 00:36:16 -0000 It has not been talked about much, but ISATAP is capable of supporting router-to-router tunneling. When an ISATAP router receives a packet that appears to have come through another router, it can check its local forwarding table using an RPF check to see if there is a corresponding IPv6 route. If there is a route, it accepts the packet. Routes can get into the ISATAP router's IPv6 forwarding table in a couple of ways. First, the router can run a dynamic IPv6 routing protocol with other routers as neighbors on the ISATAP interface. Second, the router can receive and exchange Route Information Options in IPv6 ND RA messages with other ISATAP routers. Other methods are also possible. Given router-to-router tunneling, ISATAP fits the same use case scenario as 6rd. It moreover fits other use case domains that might not be such a good fit for 6rd, including enterprise networks, MANETs, etc. I have router-to-router tunneling support coded and tested in the linux kernel. Fred fred.l.templin@boeing.com From jhw@apple.com Sun Nov 8 16:57:00 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 073673A6A35 for ; Sun, 8 Nov 2009 16:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.073 X-Spam-Level: X-Spam-Status: No, score=-106.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aS4yKF3iFiCB for ; Sun, 8 Nov 2009 16:56:59 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 59CFA3A67A2 for ; Sun, 8 Nov 2009 16:56:59 -0800 (PST) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id 785AA78ED443 for ; Sun, 8 Nov 2009 16:57:24 -0800 (PST) X-AuditID: 1180711d-b7b18ae000001001-70-4af768f31e50 Received: from [17.151.110.148] (Unknown_Domain [17.151.110.148]) (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 2C.5C.04097.4F867FA4; Sun, 8 Nov 2009 16:57:24 -0800 (PST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v1076) From: james woodyatt In-Reply-To: <4AF76212.60903@gmail.com> Date: Sun, 8 Nov 2009 16:57:23 -0800 Content-Transfer-Encoding: 7bit Message-Id: <9BD5B8C4-EBC1-43F5-BE7D-10BCDEDB2015@apple.com> References: <4AF76212.60903@gmail.com> To: softwires@ietf.org X-Mailer: Apple Mail (2.1076) X-Brightmail-Tracker: AAAAAQAAAZE= Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 00:57:00 -0000 On Nov 8, 2009, at 16:28 , Brian E Carpenter wrote: > > Should we be specifying a default MTU of 1280 for 6RD too? > (The same question applies retroactively to 6to4, of course.) They're not the same, of course. In the 6to4 case, I've found that setting the MTU to 1280, despite what the RFC says, is the only sensible way to keep the various accidental and deliberate path MTU discovery obstacles on public IPv4 networks from causing mysterious connectivity problems. In the 6RD case, because the relay is bidirectional, clamping the MTU at 1280 might be overkill. -- james woodyatt member of technical staff, communications engineering From Fred.L.Templin@boeing.com Sun Nov 8 17:00:59 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A03D93A6823 for ; Sun, 8 Nov 2009 17:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acpDWKLVU24R for ; Sun, 8 Nov 2009 17:00:58 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id A26CF3A6A35 for ; Sun, 8 Nov 2009 17:00:58 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id nA911NSj016008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Nov 2009 17:01:23 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id nA911Nxr020060; Sun, 8 Nov 2009 17:01:23 -0800 (PST) Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id nA911MsJ020054 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Sun, 8 Nov 2009 17:01:23 -0800 (PST) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Sun, 8 Nov 2009 17:01:22 -0800 From: "Templin, Fred L" To: james woodyatt , "softwires@ietf.org" Date: Sun, 8 Nov 2009 17:01:21 -0800 Thread-Topic: [Softwires] MTU issue for 6RD (and 6to4) Thread-Index: Acpg16RmZxRAFdQRQu2o7qounJD+ogAAD+uA Message-ID: <12F4112206976147A34FEC0277597CCF27A5229F12@XCH-NW-15V.nw.nos.boeing.com> References: <4AF76212.60903@gmail.com> <9BD5B8C4-EBC1-43F5-BE7D-10BCDEDB2015@apple.com> In-Reply-To: <9BD5B8C4-EBC1-43F5-BE7D-10BCDEDB2015@apple.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 Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 01:00:59 -0000 > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On B= ehalf Of james woodyatt > Sent: Sunday, November 08, 2009 4:57 PM > To: softwires@ietf.org > Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) >=20 > On Nov 8, 2009, at 16:28 , Brian E Carpenter wrote: > > > > Should we be specifying a default MTU of 1280 for 6RD too? > > (The same question applies retroactively to 6to4, of course.) >=20 > They're not the same, of course. In the 6to4 case, I've found that > setting the MTU to 1280, despite what the RFC says, is the only > sensible way to keep the various accidental and deliberate path MTU > discovery obstacles on public IPv4 networks from causing mysterious > connectivity problems. In the 6RD case, because the relay is > bidirectional, clamping the MTU at 1280 might be overkill. I don't get the "because the relay is bidirectional" part; path MTU is by nature a unidirectional consideration. Fred fred.l.templin@boeing.com > -- > james woodyatt > member of technical staff, communications engineering >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From ichiroumakino@gmail.com Sun Nov 8 17:07:06 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1E463A67D3 for ; Sun, 8 Nov 2009 17:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jR4GMUde-MX for ; Sun, 8 Nov 2009 17:07:05 -0800 (PST) Received: from mail-gx0-f212.google.com (mail-gx0-f212.google.com [209.85.217.212]) by core3.amsl.com (Postfix) with ESMTP id 068103A67A2 for ; Sun, 8 Nov 2009 17:07:04 -0800 (PST) Received: by gxk4 with SMTP id 4so2636189gxk.8 for ; Sun, 08 Nov 2009 17:07:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=RT0TWpZNy7tQoB9hv3p1wsT1VppqbLKJ5fLyU7eMaP8=; b=k6LD/Mge0kwFrDnwnLwx/Rf0qrYn1iK61A41bMXhRqkKLsxw7QeeVrSQP9u+l1VJLR Fyd2y+LwMkiRCZmPyCmfBNRpj34aooyB5XeSsfaY6lLfsBq28BYmEjwrr/qJBzlzn6Yp zKqAnpb2UwdCczP4WtVmRC75LDucAsmB6lvxE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type:mime-version :subject:date:references:x-mailer; b=wsJG0b2qhOqqxPXrQKTU61+xAsO0arDLi/ZlBjWFIpniEMF2XzrNruprwXyoy01SiP v8PSJ2eG4qho7HfE3eTvJSe8Q5o6KDd+/VypNihXiJHzmX2fDscmLRZlL7AVgSHiqJzM U6sejBsKPXHFONzXDuDG8iVHA17f3F/TYKhZ0= Received: by 10.91.50.2 with SMTP id c2mr1413893agk.5.1257728847091; Sun, 08 Nov 2009 17:07:27 -0800 (PST) Received: from host-24-177.meeting.ietf.org (64-104-46-217.cisco.com [64.104.46.217]) by mx.google.com with ESMTPS id 22sm1008692yxe.57.2009.11.08.17.07.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 08 Nov 2009 17:07:25 -0800 (PST) Sender: Ole Troan Message-Id: <82655A96-11C6-4069-BE01-2D7705261DB8@employees.org> From: Ole Troan To: "Templin, Fred L" In-Reply-To: <12F4112206976147A34FEC0277597CCF27A5229F11@XCH-NW-15V.nw.nos.boeing.com> Content-Type: multipart/signed; boundary=Apple-Mail-1-248767696; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 10:07:21 +0900 References: <4AF7004A.8080508@cisco.com><12F41122069761 47A34FEC0277597CCF27A5229F07@XCH-NW-15V.nw.nos.boeing.com> <12F4112206976147A34FEC0277597CCF27A5229F0B@XCH-NW-15V.nw.nos.boeing.com> <12F4112206976147A34FEC0277597CCF27A5229F11@XCH-NW-15V.nw.nos.boeing.com> X-Mailer: Apple Mail (2.936) Cc: "softwires@ietf.org" Subject: Re: [Softwires] Router-to-router tunneling in ISATAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 01:07:06 -0000 --Apple-Mail-1-248767696 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Fred, > It has not been talked about much, but ISATAP is capable > of supporting router-to-router tunneling. When an ISATAP > router receives a packet that appears to have come through > another router, it can check its local forwarding table > using an RPF check to see if there is a corresponding > IPv6 route. If there is a route, it accepts the packet. > > Routes can get into the ISATAP router's IPv6 forwarding > table in a couple of ways. First, the router can run > a dynamic IPv6 routing protocol with other routers as > neighbors on the ISATAP interface. Second, the router > can receive and exchange Route Information Options in > IPv6 ND RA messages with other ISATAP routers. Other > methods are also possible. > > Given router-to-router tunneling, ISATAP fits the > same use case scenario as 6rd. It moreover fits other > use case domains that might not be such a good fit > for 6rd, including enterprise networks, MANETs, etc. > I have router-to-router tunneling support coded and > tested in the linux kernel. I don't quite understand how this would work. are you suggesting doing DHCP PD and then advertise the delegated prefix in a dynamic routing protocol? one big difference from 6rd would in that case be the amount of state required. if you think this is a worthwhile idea then a draft would be good. I at least can't read this deployment model out of the ISATAP RFC. cheers, Ole --Apple-Mail-1-248767696 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDVDCCA1Aw ggI4oAMCAQICAQEwCwYJKoZIhvcNAQEFMEYxEjAQBgNVBAMMCU9sZSBUcm9hbjELMAkGA1UEBhMC R0IxIzAhBgkqhkiG9w0BCQEWFG90cm9hbkBlbXBsb3llZXMub3JnMB4XDTA4MDUwNzAwMDAxMVoX DTA5MDUwNzAwMDAxMVowRjESMBAGA1UEAwwJT2xlIFRyb2FuMQswCQYDVQQGEwJHQjEjMCEGCSqG SIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCqhwqYY9JywwGzpwmC3kFCf8/TzdM3AHZAvr1Z2cei/PbCaAqTBQ1kiwFpNxAgqcofM2LP xKq3EhHfUs4oukBOYqhrlmJtAclNBf8ctZDoWnz3ETsCYb77bMvdMRJqoJr1+YpySGl/leDqdIq8 ee0LYj0DcOQA9YFPQw7XUA107tyozy6+F7LfAzx10j2uuyfyxp55dVMfcVe8ROAv1c4LcUUCtgqp SceHH0WMuXf2j0TdAsPQ/Hd1Ak6rOx8lCVwJ7b0AKbbCVIIBlqGyVlXW6bcjwmxGGjVDgY/5CIAg KC44/6BsN/QDXnHwlU2pJlJM4mvgy1CMjy+7Y/ldvJkVAgMBAAGjSzBJMA4GA1UdDwEB/wQEAwIH gDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAfBgNVHREEGDAWgRRvdHJvYW5AZW1wbG95ZWVzLm9y ZzANBgkqhkiG9w0BAQUFAAOCAQEAWMQKZJ9OSQP2BIEjq47jG6PxfzcUhmgLHGIn7X1E6SAjmjma UmA4K3V3Ydxksb+JOXshfu6YgxCzfhdcV/wh8WA0ld2sxueRpdG8hmxQyI5sRFNvPbZdplCA105H 2UwjVVNVIQu6MAa3siYUB4g7eFGEjIqcXO80wa+xgKbnflbPFq0iXKwjQn9jbho3zlbsZhIV3yNp sOVMwdqyRaUrXKB6ycOFEbeNTVfFok+1Xx5bbk4aZz1WlbVkhUlXuSMxZFgD7PmPR57Q16ADDEZ6 1X28mvv0z/WzClrH6LV6bxtnbQzPnZgUMw5Of5+mFl1RvGkZfYfeIF5fXfo6HpV5ETGCAo0wggKJ AgEBMEswRjESMBAGA1UEAwwJT2xlIFRyb2FuMQswCQYDVQQGEwJHQjEjMCEGCSqGSIb3DQEJARYU b3Ryb2FuQGVtcGxveWVlcy5vcmcCAQEwCQYFKw4DAhoFAKCCARcwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMTA5MDEwNzIyWjAjBgkqhkiG9w0BCQQxFgQUUmbq fvNdABHHNi1g0Jpvmr1wdAswWgYJKwYBBAGCNxAEMU0wSzBGMRIwEAYDVQQDDAlPbGUgVHJvYW4x CzAJBgNVBAYTAkdCMSMwIQYJKoZIhvcNAQkBFhRvdHJvYW5AZW1wbG95ZWVzLm9yZwIBATBcBgsq hkiG9w0BCRACCzFNoEswRjESMBAGA1UEAwwJT2xlIFRyb2FuMQswCQYDVQQGEwJHQjEjMCEGCSqG SIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcCAQEwDQYJKoZIhvcNAQEBBQAEggEAE7rdsNy3 vQlwDTTy5fZ63zCXphB9aoGFX6fejH8BA4HHUxHrhmKwhiKt1jLdT1zFAbThbGFItDlIjPLC3IM/ ivQe8yGnwedTSsj+GoOKfi6FLLgR+hhrSUkQYPRATxPI2mNimyu8xbWUc1ZtmzCHokzDLssIXVrr iCCRaq4eHGpzr0iDLaF7KXGYnR7Pm3pjLXew18qFRh8cyIYhvHsqtA3A3xjFgz776kgpwYGTZ3dm T3Y5EoZv+x8LDLyAVyAJLEscTKnzghxaxkqro13axQfxGvMaSLzv+W/KI2TbLoVUy15EFbHG69bf 7KEOr73Gkpk58LuXU8dR+GIHcZLcDAAAAAAAAA== --Apple-Mail-1-248767696-- From yiu_lee@cable.comcast.com Sun Nov 8 17:08:56 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D47273A6823 for ; Sun, 8 Nov 2009 17:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.604 X-Spam-Level: * X-Spam-Status: No, score=1.604 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SN03gybS7DDn for ; Sun, 8 Nov 2009 17:08:56 -0800 (PST) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id D968E3A6909 for ; Sun, 8 Nov 2009 17:08:55 -0800 (PST) Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.72397770; Sun, 08 Nov 2009 20:09:06 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 20:09:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 133.93.18.206 ([133.93.18.206]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Mon, 9 Nov 2009 01:09:06 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3340555743_296560" Date: Sun, 8 Nov 2009 20:09:02 -0500 Message-ID: In-Reply-To: <9BD5B8C4-EBC1-43F5-BE7D-10BCDEDB2015@apple.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Softwire] MTU issue for 6RD (and 6to4) Thread-Index: Acpg2TlcmnLSHhs40kCRZUPzZpn8bg== From: "Lee, Yiu" To: "james woodyatt" , X-OriginalArrivalTime: 09 Nov 2009 01:09:07.0315 (UTC) FILETIME=[3C874C30:01CA60D9] Subject: Re: [Softwires] [Softwire] MTU issue for 6RD (and 6to4) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 01:08:56 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3340555743_296560 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit James has a point. My question is if the the 6rd CE receives ICMP Packet Too BIG, should it translate to ICMPv6 Packet too BIG to the host behind the 6rd CE? On 11/8/09 7:57 PM, "james woodyatt" wrote: > On Nov 8, 2009, at 16:28 , Brian E Carpenter wrote: >> >> Should we be specifying a default MTU of 1280 for 6RD too? >> (The same question applies retroactively to 6to4, of course.) > > They're not the same, of course. In the 6to4 case, I've found that > setting the MTU to 1280, despite what the RFC says, is the only > sensible way to keep the various accidental and deliberate path MTU > discovery obstacles on public IPv4 networks from causing mysterious > connectivity problems. In the 6RD case, because the relay is > bidirectional, clamping the MTU at 1280 might be overkill. > > > -- > james woodyatt > member of technical staff, communications engineering > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --B_3340555743_296560 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIN2AYJKoZIhvcNAQcCoIINyTCCDcUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC C6QwggMPMIICeKADAgECAhBQgSObXgIsEiVC/GebCmGTMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA4MDgwODQw MDJaFw0xMDA4MDgwODQwMDJaMEsxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx KDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCscC6PT5lvsXUq4lOfCGh5DV7ZnHkaKTZrdclNBGwIUu1H njC0937hsVMKSuyKXMiuGc2VS1sjvEzqtqcSiGBkX2ZhGszLppMjiNwb3McBc4slgNxK1OfX Q+g/C/Fi/pZbg3KU/V50QGQQsM0yO1HOK7FGyvOH023fNvQ7E0syH6NAbkmf4mQoHLFUMkjD mfdbtrnYeGvNjrX6hLMmUuo0Y6MAyJQdBDH8p+6V0/hjvYOA2yAW+ptxxEbPYGrm1/f2TYp2 o43bA9ri/P8Rtli6kaKQvC5HhReyNJLWWG2z8JjbqcQd1sP443WI1voiBbqOLNpu3KWnBRzC 3+n6eYhfAgMBAAGjWTBXMA4GA1UdDwEB/wQEAwID+DARBglghkgBhvhCAQEEBAMCBaAwJAYD VR0RBB0wG4EZeWl1X2xlZUBjYWJsZS5jb21jYXN0LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAF+NiG7zCDaZsRKq54bnGbGi1nFyzFa4sL72O+J2vRZoyVU8tFpl9Xz/ BnTMU+olVJ+Q4wmnwuSJZ6rTblLTlKRVnkd3PBcnWYYVYSvwhKuTTmTX99RZHvGSTGJomy7M PuOLo/XqZgHgA/oZ38QQp76e9EPeM2nfFJHc9bTK0RlOMIIDPzCCAqigAwIBAgIBDTANBgkq hkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcC Y1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNv bmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQD ExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/ r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCU YsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzCCBUowggQyoAMCAQICEEsVRXwTaRSoi7d3sapu92EwDQYJKoZIhvcNAQEFBQAwgd0x CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMjAeFw0wOTExMDUwMDAwMDBaFw0xMDExMDUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRAwDgYDVQQDFAdZaXUg TGVlMSgwJgYJKoZIhvcNAQkBFhl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArfUYyB1WddeTV1whaQNaHKstvQcFnloN37ZayFeM H8D3vKzrImHg6WIFOm7+kA5GsW+cO5au9HNL5fKSf1jYb4/EMuaEITqBpBK41nBok7jP3FiD KPt4TtsJsnqDRLaS2SS3YBSTZOzgdLU4mTjveMYmyFdeRbNsrO2v8bWkcQLE/zf5wSdGS6rF nDF8MXw70BkHmZte1eY+EYoi694+0ukeg9eKw5JFlmBrYAoE1oDxMHXXIV2ju/zC9kpK5DZC AVtofp+hL5A+pgnLxOsfPrRpcrkQeM1ryhujXCij/jdHMMdNS3+z97QSw8cNfG3PBF8KnBp6 67jVylTR/d3LCwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhF AQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1Ud DwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2g O4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFs SUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAxhdnbwrUOuIrJBrZ+T2mMOJJOT8gJp9gvzwJP HXevZ6DtqgrD0oNhI5bpXbgvIYjFHS9zgGi264F7qLxPYYwFF0qt0IQxUp3S72rrNtpTrBTS FoPjfuKzfK/6zv5NEExfChalzDKxKUrdymfCT3/eRPkAGRMBaADDpb1RRrmpLHDU4RZkiX48 LwLlTDFz+Yot/DO7YZCNpV38IKHN6mNfYzOUKL6zoFnY8Dd1q4dTO8d4lRU2bZUQ/i36WsXH pr9YsPKPd3dOsbO7EVIFUCZzUYPly1jZqG5Ns6KW5e26l/E2mMi5bkgq8ppqbjO0kpfZDcLO IpVMJvkYPT/6Jqx5MYIB/DCCAfgCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFCBI5teAiwSJUL8Z5sKYZMwCQYFKw4DAhoFAKBdMCMGCSqG SIb3DQEJBDEWBBR8kEx3e3R1K8SA8DBEXDKFYaIHpzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wOTExMDkwMTA5MDJaMA0GCSqGSIb3DQEBAQUABIIBAIxg dKpjDEMZ1kts+ImG3UbgM482osxH6fUSw9FAaD5ZW4n4pR+XiHqRq4FcFCWyTVZtc4UdkLpZ anE1h+78RPZYyS+RtbiqCqIvtlqmjhof9uyWc5MPntP7lWexx1hD1ULB/bth7IxK3VziyF7X HABYvJsRmgtqDWJnTywxXZ5/nn0vL/ThNJlxOuDk4PHizaK5LcFGh5TvjV2UDPuCuAAkPSLr D9HcVGjQNR5l9Fg/Bl3iLxiDmqKYbj7vmTYCO9GQwBracAHo2IEdVt9BSYrHducGVbl9X5UE ezF6WOUCFyEbSvgbYDS5sp6NIbgcdGaRTHz2lFW1e3XLLEjPnkI= --B_3340555743_296560-- From ichiroumakino@gmail.com Sun Nov 8 17:12:07 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E04823A67A2 for ; Sun, 8 Nov 2009 17:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUQlAweSQqev for ; Sun, 8 Nov 2009 17:12:06 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 713D83A67D3 for ; Sun, 8 Nov 2009 17:12:06 -0800 (PST) Received: by yxe30 with SMTP id 30so2809442yxe.29 for ; Sun, 08 Nov 2009 17:12:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=SEs7K7yGPQVwOuKcr2MaB3Dzqio3zZkNakWKN18UejU=; b=wHUNLRh6r/3jPoQ0XWl1JlVlXBvIguNRdCzrRGYSY4UjeC03O5bRJgl8y6FS1hd+Mu HUOsUdPTvqKjpct2uVugVyXVDM5tWbbLZhwk3FqIZPRf6bPuiTpJrK+BgweRU2RUCnbB j2RF5p+WzTt2qkX5GTyzp9K3zHwb3YIl5ss5I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type:mime-version :subject:date:references:x-mailer; b=MalyRbyLf8dX90i+7KZ0Bam9sF96XBuKBGXDqhcFk+6Y56QuydPXTn1h38fnzErU2x Vec2y7ggcejGJQ0FTdX3kp7Np6XnBCm7g02rM5RshGftHbdLXVQAK630g38oIQ8ZFUkD tLIyRi284PaGgdXoqyyhGx361xVizA6jigpmQ= Received: by 10.90.61.31 with SMTP id j31mr13351284aga.3.1257729147783; Sun, 08 Nov 2009 17:12:27 -0800 (PST) Received: from host-24-177.meeting.ietf.org (64-104-46-217.cisco.com [64.104.46.217]) by mx.google.com with ESMTPS id 5sm1011799yxg.64.2009.11.08.17.12.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 08 Nov 2009 17:12:26 -0800 (PST) Sender: Ole Troan Message-Id: <01054E2B-BB74-4E27-A779-C86D35ECD08E@employees.org> From: Ole Troan To: Brian E Carpenter In-Reply-To: <4AF76212.60903@gmail.com> Content-Type: multipart/signed; boundary=Apple-Mail-2-249068754; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 10:12:22 +0900 References: <4AF76212.60903@gmail.com> X-Mailer: Apple Mail (2.936) Cc: softwires@ietf.org Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 01:12:08 -0000 --Apple-Mail-2-249068754 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit > Should we be specifying a default MTU of 1280 for 6RD too? > > (The same question applies retroactively to 6to4, of course.) this is what the draft says: "6rd's scope is limited to a service provider network. If the MTU is well-managed such that the IPv4 MTU on the 6rd CE WAN interface is set so that no fragmentation occurs within the boundary of the SP, then the IPv6 MTU should be set to the IPv4 MTU minus the size of the encapsulating IPv4 header (20 bytes)." the assumption being that the service provider maintains a consistent MTU across its network. there is more reason for 6to4 to have a default MTU of 1280 though. cheers, Ole --Apple-Mail-2-249068754 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDVDCCA1Aw ggI4oAMCAQICAQEwCwYJKoZIhvcNAQEFMEYxEjAQBgNVBAMMCU9sZSBUcm9hbjELMAkGA1UEBhMC R0IxIzAhBgkqhkiG9w0BCQEWFG90cm9hbkBlbXBsb3llZXMub3JnMB4XDTA4MDUwNzAwMDAxMVoX DTA5MDUwNzAwMDAxMVowRjESMBAGA1UEAwwJT2xlIFRyb2FuMQswCQYDVQQGEwJHQjEjMCEGCSqG SIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCqhwqYY9JywwGzpwmC3kFCf8/TzdM3AHZAvr1Z2cei/PbCaAqTBQ1kiwFpNxAgqcofM2LP xKq3EhHfUs4oukBOYqhrlmJtAclNBf8ctZDoWnz3ETsCYb77bMvdMRJqoJr1+YpySGl/leDqdIq8 ee0LYj0DcOQA9YFPQw7XUA107tyozy6+F7LfAzx10j2uuyfyxp55dVMfcVe8ROAv1c4LcUUCtgqp SceHH0WMuXf2j0TdAsPQ/Hd1Ak6rOx8lCVwJ7b0AKbbCVIIBlqGyVlXW6bcjwmxGGjVDgY/5CIAg KC44/6BsN/QDXnHwlU2pJlJM4mvgy1CMjy+7Y/ldvJkVAgMBAAGjSzBJMA4GA1UdDwEB/wQEAwIH gDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAfBgNVHREEGDAWgRRvdHJvYW5AZW1wbG95ZWVzLm9y ZzANBgkqhkiG9w0BAQUFAAOCAQEAWMQKZJ9OSQP2BIEjq47jG6PxfzcUhmgLHGIn7X1E6SAjmjma UmA4K3V3Ydxksb+JOXshfu6YgxCzfhdcV/wh8WA0ld2sxueRpdG8hmxQyI5sRFNvPbZdplCA105H 2UwjVVNVIQu6MAa3siYUB4g7eFGEjIqcXO80wa+xgKbnflbPFq0iXKwjQn9jbho3zlbsZhIV3yNp sOVMwdqyRaUrXKB6ycOFEbeNTVfFok+1Xx5bbk4aZz1WlbVkhUlXuSMxZFgD7PmPR57Q16ADDEZ6 1X28mvv0z/WzClrH6LV6bxtnbQzPnZgUMw5Of5+mFl1RvGkZfYfeIF5fXfo6HpV5ETGCAo0wggKJ AgEBMEswRjESMBAGA1UEAwwJT2xlIFRyb2FuMQswCQYDVQQGEwJHQjEjMCEGCSqGSIb3DQEJARYU b3Ryb2FuQGVtcGxveWVlcy5vcmcCAQEwCQYFKw4DAhoFAKCCARcwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMTA5MDExMjIzWjAjBgkqhkiG9w0BCQQxFgQUvN+q /ZYfNhJg2jyPAjVrmwxlgrcwWgYJKwYBBAGCNxAEMU0wSzBGMRIwEAYDVQQDDAlPbGUgVHJvYW4x CzAJBgNVBAYTAkdCMSMwIQYJKoZIhvcNAQkBFhRvdHJvYW5AZW1wbG95ZWVzLm9yZwIBATBcBgsq hkiG9w0BCRACCzFNoEswRjESMBAGA1UEAwwJT2xlIFRyb2FuMQswCQYDVQQGEwJHQjEjMCEGCSqG SIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcCAQEwDQYJKoZIhvcNAQEBBQAEggEAApI7xTCa pQUC93xmfKDguql7NKgZJQGsrUPG18RAJ5ANY9A90IA+ex1VFhjGSWVEyFURkYJV4x1L4bz7i3u4 0MySwnTz8Bg+3M9gj+ro3vUCkjr1gUCcnD2R4AdG2KKrAmrFHT5aOalD4jnyJnUwwM2hBdkE9Hds Anu0MkB2wkw9RNXsyfEbxYWVDanc+0/tafKdWorLwGUlL9s2LSaNbTEZygmPOQsDjjP2e/z+h7zW CRKsx2wcUnMGIP17FjTH5lRyNItPXMASE3VGhNa4WFyb/RoHkL0HVIoPr1ZOfyL6KeSwOgmZTK5k qVZmDCpDwlw3F/R0COecjMQOztllSwAAAAAAAA== --Apple-Mail-2-249068754-- From Fred.L.Templin@boeing.com Sun Nov 8 17:13:47 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F10623A6809 for ; Sun, 8 Nov 2009 17:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raEL9EvTYJlO for ; Sun, 8 Nov 2009 17:13:46 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id F34C63A6823 for ; Sun, 8 Nov 2009 17:13:45 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id nA91Dj7E004857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Nov 2009 19:13:46 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id nA91DiuE025778; Sun, 8 Nov 2009 17:13:45 -0800 (PST) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id nA91Di5h025767 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Sun, 8 Nov 2009 17:13:44 -0800 (PST) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Sun, 8 Nov 2009 17:13:44 -0800 From: "Templin, Fred L" To: Ole Troan Date: Sun, 8 Nov 2009 17:13:43 -0800 Thread-Topic: [Softwires] Router-to-router tunneling in ISATAP Thread-Index: Acpg2QJWSPwycdyUQ1mWDm2Ur8eIUgAAB50w Message-ID: <12F4112206976147A34FEC0277597CCF27A5229F13@XCH-NW-15V.nw.nos.boeing.com> References: <4AF7004A.8080508@cisco.com><12F41122069761 47A34FEC0277597CCF27A5229F07@XCH-NW-15V.nw.nos.boeing.com> <12F4112206976147A34FEC0277597CCF27A5229F0B@XCH-NW-15V.nw.nos.boeing.com> <12F4112206976147A34FEC0277597CCF27A5229F11@XCH-NW-15V.nw.nos.boeing.com> <82655A96-11C6-4069-BE01-2D7705261DB8@employees.org> In-Reply-To: <82655A96-11C6-4069-BE01-2D7705261DB8@employees.org> 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: "softwires@ietf.org" Subject: Re: [Softwires] Router-to-router tunneling in ISATAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 01:13:47 -0000 Ole, > -----Original Message----- > From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan > Sent: Sunday, November 08, 2009 5:07 PM > To: Templin, Fred L > Cc: softwires@ietf.org > Subject: Re: [Softwires] Router-to-router tunneling in ISATAP >=20 > Fred, >=20 > > It has not been talked about much, but ISATAP is capable > > of supporting router-to-router tunneling. When an ISATAP > > router receives a packet that appears to have come through > > another router, it can check its local forwarding table > > using an RPF check to see if there is a corresponding > > IPv6 route. If there is a route, it accepts the packet. > > > > Routes can get into the ISATAP router's IPv6 forwarding > > table in a couple of ways. First, the router can run > > a dynamic IPv6 routing protocol with other routers as > > neighbors on the ISATAP interface. Second, the router > > can receive and exchange Route Information Options in > > IPv6 ND RA messages with other ISATAP routers. Other > > methods are also possible. > > > > Given router-to-router tunneling, ISATAP fits the > > same use case scenario as 6rd. It moreover fits other > > use case domains that might not be such a good fit > > for 6rd, including enterprise networks, MANETs, etc. > > I have router-to-router tunneling support coded and > > tested in the linux kernel. >=20 > I don't quite understand how this would work. are you suggesting doing > DHCP PD and then advertise the delegated prefix in a dynamic routing > protocol? one big difference from 6rd would in that case be the amount > of state required. DHCP PD is certainly one way an ISATAP router could receive an IPv6 prefix that it can sub-delegate to its downstream-attached links. Dynamic routing protocol is one way that the prefix can get disseminated to other ISATAP routers, but it is not the only way. The VET spec talks more about this. =20 > if you think this is a worthwhile idea then a draft would be good. I > at least can't read this deployment model out of the ISATAP RFC. The ISATAP spec only talks about the operation of neighbor discovery over an NBMA link manifested by tunneling, i.e., it is an IPv6-over-foo document. It is therefore not within scope for ISATAP to talk about higher layer considerations. Again, the VET spec talks about the higher layer considerations, but dynamic routing protocols can certainly treat the ISATAP link the same as for any IPv6 link. Fred fred.l.templin@boeing.com >=20 > cheers, > Ole From ichiroumakino@gmail.com Sun Nov 8 17:14:49 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF7CE3A69CF for ; Sun, 8 Nov 2009 17:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7qdiwKKDLT6 for ; Sun, 8 Nov 2009 17:14:40 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 134733A67D3 for ; Sun, 8 Nov 2009 17:14:33 -0800 (PST) Received: by yxe30 with SMTP id 30so2810956yxe.29 for ; Sun, 08 Nov 2009 17:14:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=TbqFkYdNCVEZECPwZtXAWtRYfTHGWNr+h2+ar+30K0M=; b=sb8RfHNAwGryuuprCHQtVwd/m5Frvi54fYLQ7sRLZePoMPfbDBVEc/HcdJqVbGDX9q A0fNDfx1ujXr3P5su6WM5gjt+3F20DCWQoXdb1AIPlzKb7bECXvNej7R3sAeIwVO+qlP GtxkYzjd0KecAUMOJErsAN8OsLvCSdX5ithHw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type:mime-version :subject:date:references:x-mailer; b=kmNPdWhWPV7rOlx/DYrD1BLpe371YTu+tJZFc5Wz4wGYcsxuxgCZg3jo14Tyhds3Kd haikf7aZ1WMTNXN+M2sCRqohzVt5ZMck/dyXlewECnBxVvyC0GVlc5D3bZlopx7sLp1x PEzC+1arIXgNLpjM4FgPEKVBfcNWYt5ddm3VI= Received: by 10.90.210.11 with SMTP id i11mr13754448agg.94.1257729296139; Sun, 08 Nov 2009 17:14:56 -0800 (PST) Received: from host-24-177.meeting.ietf.org (64-104-46-217.cisco.com [64.104.46.217]) by mx.google.com with ESMTPS id 7sm1014206yxg.32.2009.11.08.17.14.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 08 Nov 2009 17:14:55 -0800 (PST) Sender: Ole Troan Message-Id: From: Ole Troan To: "Lee, Yiu" In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-3-249216861; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 10:14:50 +0900 References: X-Mailer: Apple Mail (2.936) Cc: softwires@ietf.org Subject: Re: [Softwires] [Softwire] MTU issue for 6RD (and 6to4) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 01:14:49 -0000 --Apple-Mail-3-249216861 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit > James has a point. My question is if the the 6rd CE receives ICMP > Packet Too > BIG, should it translate to ICMPv6 Packet too BIG to the host behind > the 6rd > CE? yes, it should follow RFC4213, section 3.4 cheers, Ole > > > On 11/8/09 7:57 PM, "james woodyatt" wrote: > >> On Nov 8, 2009, at 16:28 , Brian E Carpenter wrote: >>> >>> Should we be specifying a default MTU of 1280 for 6RD too? >>> (The same question applies retroactively to 6to4, of course.) >> >> They're not the same, of course. In the 6to4 case, I've found that >> setting the MTU to 1280, despite what the RFC says, is the only >> sensible way to keep the various accidental and deliberate path MTU >> discovery obstacles on public IPv4 networks from causing mysterious >> connectivity problems. In the 6RD case, because the relay is >> bidirectional, clamping the MTU at 1280 might be overkill. >> >> >> -- >> james woodyatt >> member of technical staff, communications engineering >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-3-249216861 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDVDCCA1Aw ggI4oAMCAQICAQEwCwYJKoZIhvcNAQEFMEYxEjAQBgNVBAMMCU9sZSBUcm9hbjELMAkGA1UEBhMC R0IxIzAhBgkqhkiG9w0BCQEWFG90cm9hbkBlbXBsb3llZXMub3JnMB4XDTA4MDUwNzAwMDAxMVoX DTA5MDUwNzAwMDAxMVowRjESMBAGA1UEAwwJT2xlIFRyb2FuMQswCQYDVQQGEwJHQjEjMCEGCSqG SIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCqhwqYY9JywwGzpwmC3kFCf8/TzdM3AHZAvr1Z2cei/PbCaAqTBQ1kiwFpNxAgqcofM2LP xKq3EhHfUs4oukBOYqhrlmJtAclNBf8ctZDoWnz3ETsCYb77bMvdMRJqoJr1+YpySGl/leDqdIq8 ee0LYj0DcOQA9YFPQw7XUA107tyozy6+F7LfAzx10j2uuyfyxp55dVMfcVe8ROAv1c4LcUUCtgqp SceHH0WMuXf2j0TdAsPQ/Hd1Ak6rOx8lCVwJ7b0AKbbCVIIBlqGyVlXW6bcjwmxGGjVDgY/5CIAg KC44/6BsN/QDXnHwlU2pJlJM4mvgy1CMjy+7Y/ldvJkVAgMBAAGjSzBJMA4GA1UdDwEB/wQEAwIH gDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAfBgNVHREEGDAWgRRvdHJvYW5AZW1wbG95ZWVzLm9y ZzANBgkqhkiG9w0BAQUFAAOCAQEAWMQKZJ9OSQP2BIEjq47jG6PxfzcUhmgLHGIn7X1E6SAjmjma UmA4K3V3Ydxksb+JOXshfu6YgxCzfhdcV/wh8WA0ld2sxueRpdG8hmxQyI5sRFNvPbZdplCA105H 2UwjVVNVIQu6MAa3siYUB4g7eFGEjIqcXO80wa+xgKbnflbPFq0iXKwjQn9jbho3zlbsZhIV3yNp sOVMwdqyRaUrXKB6ycOFEbeNTVfFok+1Xx5bbk4aZz1WlbVkhUlXuSMxZFgD7PmPR57Q16ADDEZ6 1X28mvv0z/WzClrH6LV6bxtnbQzPnZgUMw5Of5+mFl1RvGkZfYfeIF5fXfo6HpV5ETGCAo0wggKJ AgEBMEswRjESMBAGA1UEAwwJT2xlIFRyb2FuMQswCQYDVQQGEwJHQjEjMCEGCSqGSIb3DQEJARYU b3Ryb2FuQGVtcGxveWVlcy5vcmcCAQEwCQYFKw4DAhoFAKCCARcwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMTA5MDExNDUxWjAjBgkqhkiG9w0BCQQxFgQU2vRo 3d24RFrUBDBCdl+4e2LLmyYwWgYJKwYBBAGCNxAEMU0wSzBGMRIwEAYDVQQDDAlPbGUgVHJvYW4x CzAJBgNVBAYTAkdCMSMwIQYJKoZIhvcNAQkBFhRvdHJvYW5AZW1wbG95ZWVzLm9yZwIBATBcBgsq hkiG9w0BCRACCzFNoEswRjESMBAGA1UEAwwJT2xlIFRyb2FuMQswCQYDVQQGEwJHQjEjMCEGCSqG SIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcCAQEwDQYJKoZIhvcNAQEBBQAEggEAVwS8NuNH 2MrDdzfm82h0j1FaaDMDV1xP9bRODiUsj8Vtjfw23vm0Kss7h56lURf5D8OoSGOnLD9PZJOlKnl6 fjPDCtfaaCnWJWNDAFlGn9zGglspLyUsw9IL9mLWjM/trqiAcSy3a5xhXki+9tg76aiTdbh0GGXF fKJKvrr1d9sa4qudEAhQ29QWnZc4dR3mp8s25Qo8o35emQdDjFNqQOoacMujOSjs7PVTN/n350F/ sFDXE4xnQjZKzQMmoOu1Ut7Pwk0pQcz8zJ6FiRXIfkpgp87G7U6fzVWqvLq1a2aFdjR+4MUbZ8v6 6Fhp2muEGTvoJqKtJtm4wfrnMXipkAAAAAAAAA== --Apple-Mail-3-249216861-- From Fred.L.Templin@boeing.com Sun Nov 8 17:27:19 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D136A3A687C for ; Sun, 8 Nov 2009 17:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwzFP0C-VMXF for ; Sun, 8 Nov 2009 17:27:18 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id A908E3A6A45 for ; Sun, 8 Nov 2009 17:27:18 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id nA91Qpbt018698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 8 Nov 2009 17:26:52 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id nA91Qp3e004348; Sun, 8 Nov 2009 17:26:51 -0800 (PST) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id nA91Qpnx004345 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Sun, 8 Nov 2009 17:26:51 -0800 (PST) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Sun, 8 Nov 2009 17:26:51 -0800 From: "Templin, Fred L" To: Ole Troan , "Lee, Yiu" Date: Sun, 8 Nov 2009 17:26:47 -0800 Thread-Topic: [Softwires] [Softwire] MTU issue for 6RD (and 6to4) Thread-Index: Acpg2hpugdZmdfuGR36sbGJlyybB7AAANvHw Message-ID: <12F4112206976147A34FEC0277597CCF27A5229F14@XCH-NW-15V.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] [Softwire] MTU issue for 6RD (and 6to4) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 01:27:19 -0000 > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On B= ehalf Of Ole Troan > Sent: Sunday, November 08, 2009 5:15 PM > To: Lee, Yiu > Cc: softwires@ietf.org > Subject: Re: [Softwires] [Softwire] MTU issue for 6RD (and 6to4) >=20 > > James has a point. My question is if the the 6rd CE receives ICMP > > Packet Too > > BIG, should it translate to ICMPv6 Packet too BIG to the host behind > > the 6rd > > CE? >=20 > yes, it should follow RFC4213, section 3.4 Two points about this. First, it requires that ICMPs be delivered without filtering and that ICMPs cannot be spoofed. This may be possible only within certain carefully controlled environments. Second, the translated ICMPs will always go through to the original source hosts that would repeatedly be inconvenienced by excessive interactions with path MTU discovery. (Note also that translation is not always guaranteed to be possible based on the amount of information conveyed in ICMPs.) Most importantly, dynamic path MTU discovery within the tunnel does not hide the effects of adding encapsulation. The overhead for encapsulation will be seen by the original sources in any case. Fred fred.l.templin@boeing.com >=20 > cheers, > Ole >=20 >=20 > > > > > > On 11/8/09 7:57 PM, "james woodyatt" wrote: > > > >> On Nov 8, 2009, at 16:28 , Brian E Carpenter wrote: > >>> > >>> Should we be specifying a default MTU of 1280 for 6RD too? > >>> (The same question applies retroactively to 6to4, of course.) > >> > >> They're not the same, of course. In the 6to4 case, I've found that > >> setting the MTU to 1280, despite what the RFC says, is the only > >> sensible way to keep the various accidental and deliberate path MTU > >> discovery obstacles on public IPv4 networks from causing mysterious > >> connectivity problems. In the 6RD case, because the relay is > >> bidirectional, clamping the MTU at 1280 might be overkill. > >> > >> > >> -- > >> james woodyatt > >> member of technical staff, communications engineering > >> > >> > >> _______________________________________________ > >> Softwires mailing list > >> Softwires@ietf.org > >> https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires From ichiroumakino@gmail.com Sun Nov 8 17:30:25 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3982028C0E0 for ; Sun, 8 Nov 2009 17:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xb75Tw68jnpV for ; Sun, 8 Nov 2009 17:30:24 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 36D6428C0E1 for ; Sun, 8 Nov 2009 17:30:24 -0800 (PST) Received: by yxe30 with SMTP id 30so2820668yxe.29 for ; Sun, 08 Nov 2009 17:30:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=R/5S1EhXl82Eyy6z7QP03dQpzmXnypTF3OLjoY+Xa5Y=; b=I5PMjMlbn/RwMQPp9SoUpw0dG4DqCZEMxQ1UBRmmZn6uauRA7QXsAT/7bFco8Cx3EY Cyo3Zo7hy4yKFSaMphr2o4+F7bbzidIYgzONzHakAZAOA9BE+O23vlQyLcIs5RB5oodY xEoAznaxvIapBiOE7HiruMTBanU8H/+2PXSDs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type:mime-version :subject:date:references:x-mailer; b=DTmWVVOmmumxduIGBZqDBBjgF517XJEgWv65ZCnPpxF4ffgRZnjl+dXLZwwIxkKgJQ hhGd7E9l9PBHTG84HCt5yaOEEzwAszYN9s5BobIIlcRRIN6JL4gnY3jnzr6wfZcvxJyo OwJEk/NYdBvtKdxxlwnW5t+FBRYURfvFRzkGc= Received: by 10.91.103.17 with SMTP id f17mr13391505agm.114.1257730247307; Sun, 08 Nov 2009 17:30:47 -0800 (PST) Received: from host-24-177.meeting.ietf.org (64-104-46-217.cisco.com [64.104.46.217]) by mx.google.com with ESMTPS id 8sm1024082yxb.25.2009.11.08.17.30.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 08 Nov 2009 17:30:46 -0800 (PST) Sender: Ole Troan Message-Id: <927E0EF7-9D25-4025-940A-6BF326C7233A@employees.org> From: Ole Troan To: "Templin, Fred L" In-Reply-To: <12F4112206976147A34FEC0277597CCF27A5229F0B@XCH-NW-15V.nw.nos.boeing.com> Content-Type: multipart/signed; boundary=Apple-Mail-4-250168106; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 10:30:42 +0900 References: <4AF7004A.8080508@cisco.com><12F41122069761 47A34FEC0277597CCF27A5229F07@XCH-NW-15V.nw.nos.boeing.com> <12F4112206976147A34FEC0277597CCF27A5229F0B@XCH-NW-15V.nw.nos.boeing.com> X-Mailer: Apple Mail (2.936) Cc: "softwires@ietf.org" Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 01:30:25 -0000 --Apple-Mail-4-250168106 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Fred, >>> - Use of anycast does not allow the CPE router to select >>> between multiple available exit routers. Instead, exit >>> router selection is through IPv4 routing in the ISP >>> network, which is non-deterministic from the CPE router's >>> point of view. >> >> Having a fair amount of experience with implementing residential CPE >> dual-stack IPv4/IPv6 gateway routers, I hope I have some authority >> with which to declare this as a FEATURE and not a problem. Not having >> to burden the residential user with having to choose an IPv6 relay >> endpoint on their own, when this is really something the service >> provider should be handling transparently to the subscriber, seems >> like a desirable quality in a protocol for our purposes here. > > You may have missed an aspect of my point, or I may not have > expressed it fully. When the CPE router discovers addresses > of ISP border routers and performs neighbor discovery > exchanges with them, the ISP is still the one that informs > the CPE routers of best choices. So, this is not a "burden" > on the CPE router, and the ISP still has the means to > engineer the traffic. It simply gives the CPE router the > means to make the best choices based on what the ISP > tells it. > >>> - Non-use of IPv6 ND does not allow for dynamic configuration >>> of lifetimes for default and more-specific routes. Also, >>> no NUD mechanism. >> >> What? Seriously, I don't understand the concern behind this comment. >> Could you elaborate? > > Like when an RA advertises a PIO or an RIO they have > lifetimes that the CPE router learns. These lifetimes > influence router selection and router reachability in > a way that is not available without them. we're talking about a router to router link here. you appear to be suggesting to use ND as a routing protocol. I don't think that is specified anywhere. for more specific routes you need to run a routing protocol between the BRs and the CEs. which routing protocol do you use? do you need to provide a way of automatically provisioning the routing protocol? for the multiple BR problem, this can also be solves with a dynamic routing protocol or one could use BFD. again, we wanted 6rd to be stateless. and possibly we were too lazy to try to solve all these issues... :-) cheers, Ole --Apple-Mail-4-250168106 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDVDCCA1Aw ggI4oAMCAQICAQEwCwYJKoZIhvcNAQEFMEYxEjAQBgNVBAMMCU9sZSBUcm9hbjELMAkGA1UEBhMC R0IxIzAhBgkqhkiG9w0BCQEWFG90cm9hbkBlbXBsb3llZXMub3JnMB4XDTA4MDUwNzAwMDAxMVoX DTA5MDUwNzAwMDAxMVowRjESMBAGA1UEAwwJT2xlIFRyb2FuMQswCQYDVQQGEwJHQjEjMCEGCSqG SIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCqhwqYY9JywwGzpwmC3kFCf8/TzdM3AHZAvr1Z2cei/PbCaAqTBQ1kiwFpNxAgqcofM2LP xKq3EhHfUs4oukBOYqhrlmJtAclNBf8ctZDoWnz3ETsCYb77bMvdMRJqoJr1+YpySGl/leDqdIq8 ee0LYj0DcOQA9YFPQw7XUA107tyozy6+F7LfAzx10j2uuyfyxp55dVMfcVe8ROAv1c4LcUUCtgqp SceHH0WMuXf2j0TdAsPQ/Hd1Ak6rOx8lCVwJ7b0AKbbCVIIBlqGyVlXW6bcjwmxGGjVDgY/5CIAg KC44/6BsN/QDXnHwlU2pJlJM4mvgy1CMjy+7Y/ldvJkVAgMBAAGjSzBJMA4GA1UdDwEB/wQEAwIH gDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAfBgNVHREEGDAWgRRvdHJvYW5AZW1wbG95ZWVzLm9y ZzANBgkqhkiG9w0BAQUFAAOCAQEAWMQKZJ9OSQP2BIEjq47jG6PxfzcUhmgLHGIn7X1E6SAjmjma UmA4K3V3Ydxksb+JOXshfu6YgxCzfhdcV/wh8WA0ld2sxueRpdG8hmxQyI5sRFNvPbZdplCA105H 2UwjVVNVIQu6MAa3siYUB4g7eFGEjIqcXO80wa+xgKbnflbPFq0iXKwjQn9jbho3zlbsZhIV3yNp sOVMwdqyRaUrXKB6ycOFEbeNTVfFok+1Xx5bbk4aZz1WlbVkhUlXuSMxZFgD7PmPR57Q16ADDEZ6 1X28mvv0z/WzClrH6LV6bxtnbQzPnZgUMw5Of5+mFl1RvGkZfYfeIF5fXfo6HpV5ETGCAo0wggKJ AgEBMEswRjESMBAGA1UEAwwJT2xlIFRyb2FuMQswCQYDVQQGEwJHQjEjMCEGCSqGSIb3DQEJARYU b3Ryb2FuQGVtcGxveWVlcy5vcmcCAQEwCQYFKw4DAhoFAKCCARcwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMTA5MDEzMDQyWjAjBgkqhkiG9w0BCQQxFgQU4SHq oMijtMptzBlnl4tPK255rTAwWgYJKwYBBAGCNxAEMU0wSzBGMRIwEAYDVQQDDAlPbGUgVHJvYW4x CzAJBgNVBAYTAkdCMSMwIQYJKoZIhvcNAQkBFhRvdHJvYW5AZW1wbG95ZWVzLm9yZwIBATBcBgsq hkiG9w0BCRACCzFNoEswRjESMBAGA1UEAwwJT2xlIFRyb2FuMQswCQYDVQQGEwJHQjEjMCEGCSqG SIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcCAQEwDQYJKoZIhvcNAQEBBQAEggEAkOapqQqD 3flyLVNv+6wZK+Yo/bViuAdHbMSq6NFM/rTIpo2ppTd4CQZ6nhuR+85GX8qf+NAZgmUN4OJ+hZL1 fjWp36FSl/9oiENRmWeCQnAVR6uzfF4C5PR8/eKkokxzQaxSJUxqrEbUHqOXwuVjoK8LTyB5zIT+ 4Ccicl0IwsstsMOUiRuE9YYZGaxnYx9QnWxEJhBm/mDQfWyXpAgjSgzQJxY3VKh0YQK+1ZzrJZeX 7BvLEE9G0ddLH5TaXB+4NmWBiutXGH9rZ2WJtEJ/Qf9uE+xaQlaWg9uLxp0BKw4dKkAOPLvEITbs qyQIy+hNYXHtEKHSev+e/nT+NzdjcgAAAAAAAA== --Apple-Mail-4-250168106-- From Fred.L.Templin@boeing.com Sun Nov 8 17:32:37 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E91128C0F0 for ; Sun, 8 Nov 2009 17:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvRH4SHPai2c for ; Sun, 8 Nov 2009 17:32:36 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 7ACAD28C0E1 for ; Sun, 8 Nov 2009 17:32:36 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id nA91WZN1007075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 8 Nov 2009 17:32:35 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id nA91WY2m007735; Sun, 8 Nov 2009 17:32:35 -0800 (PST) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id nA91WYfl007732 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Sun, 8 Nov 2009 17:32:34 -0800 (PST) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Sun, 8 Nov 2009 17:32:34 -0800 From: "Templin, Fred L" To: Ole Troan Date: Sun, 8 Nov 2009 17:32:31 -0800 Thread-Topic: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt Thread-Index: Acpg3ERU5D1GzIFLR3q1vi7J0mJ1YwAAB0Yw Message-ID: <12F4112206976147A34FEC0277597CCF27A5229F15@XCH-NW-15V.nw.nos.boeing.com> References: <4AF7004A.8080508@cisco.com><12F41122069761 47A34FEC0277597CCF27A5229F07@XCH-NW-15V.nw.nos.boeing.com> <12F4112206976147A34FEC0277597CCF27A5229F0B@XCH-NW-15V.nw.nos.boeing.com> <927E0EF7-9D25-4025-940A-6BF326C7233A@employees.org> In-Reply-To: <927E0EF7-9D25-4025-940A-6BF326C7233A@employees.org> 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: "softwires@ietf.org" Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 01:32:37 -0000 Ole, > -----Original Message----- > From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan > Sent: Sunday, November 08, 2009 5:31 PM > To: Templin, Fred L > Cc: james woodyatt; softwires@ietf.org > Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt >=20 > Fred, >=20 > >>> - Use of anycast does not allow the CPE router to select > >>> between multiple available exit routers. Instead, exit > >>> router selection is through IPv4 routing in the ISP > >>> network, which is non-deterministic from the CPE router's > >>> point of view. > >> > >> Having a fair amount of experience with implementing residential CPE > >> dual-stack IPv4/IPv6 gateway routers, I hope I have some authority > >> with which to declare this as a FEATURE and not a problem. Not having > >> to burden the residential user with having to choose an IPv6 relay > >> endpoint on their own, when this is really something the service > >> provider should be handling transparently to the subscriber, seems > >> like a desirable quality in a protocol for our purposes here. > > > > You may have missed an aspect of my point, or I may not have > > expressed it fully. When the CPE router discovers addresses > > of ISP border routers and performs neighbor discovery > > exchanges with them, the ISP is still the one that informs > > the CPE routers of best choices. So, this is not a "burden" > > on the CPE router, and the ISP still has the means to > > engineer the traffic. It simply gives the CPE router the > > means to make the best choices based on what the ISP > > tells it. > > > >>> - Non-use of IPv6 ND does not allow for dynamic configuration > >>> of lifetimes for default and more-specific routes. Also, > >>> no NUD mechanism. > >> > >> What? Seriously, I don't understand the concern behind this comment. > >> Could you elaborate? > > > > Like when an RA advertises a PIO or an RIO they have > > lifetimes that the CPE router learns. These lifetimes > > influence router selection and router reachability in > > a way that is not available without them. >=20 > we're talking about a router to router link here. you appear to be > suggesting to use ND as a routing protocol. I don't think that is > specified anywhere. Yes it is; it is specified in VET. Fred fred.l.templin@boeing.com > for more specific routes you need to run a routing protocol between > the BRs and the CEs. which routing protocol do you use? do you need to > provide a way of automatically provisioning the routing protocol? >=20 > for the multiple BR problem, this can also be solves with a dynamic > routing protocol or one could use BFD. >=20 > again, we wanted 6rd to be stateless. and possibly we were too lazy to > try to solve all these issues... :-) >=20 > cheers, > Ole From brian.e.carpenter@gmail.com Sun Nov 8 20:21:04 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71D7A28C0F5 for ; Sun, 8 Nov 2009 20:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zH9vW0wBne5w for ; Sun, 8 Nov 2009 20:21:03 -0800 (PST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 8559F3A692D for ; Sun, 8 Nov 2009 20:21:03 -0800 (PST) Received: by ywh13 with SMTP id 13so2920520ywh.29 for ; Sun, 08 Nov 2009 20:21:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=HnUuv42s3AyQ8z095KAaeSXaWQym2TsaTJZrQjWZw/A=; b=k9URpL9UdolplXExAI9s+SF4AZ1nljY1VljpODHQdkMbp0tUsdM/wJb5V3EcdsiyTN LbJ15nDWec1nR5UIky7gnApkeGh+7KfB234N8o2vYspWgIuBujSmq99ikOeWRspHebOx y9On6WnTJIeWIkHZrNbvRfc8j5j7+6w/gbf1c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=L02pyy5mszg97o5iBQmvbtqrMyOHbcd7O84Y7w7+ZlyuAvnxs/6Attc4ti+TnkyqS4 J19fVPj5AxJm3NUoFWrksKjL2TE7CoPbD+TdPoI+ZHWS+5Sgo353OYJWNLwPGZvW3bRT p4haZX56JILtMuib2+lI5PQewNL+M57bk8Z34= Received: by 10.150.111.26 with SMTP id j26mr3283824ybc.268.1257740482828; Sun, 08 Nov 2009 20:21:22 -0800 (PST) Received: from ?133.93.16.203? (host-16-203.meeting.ietf.org [133.93.16.203]) by mx.google.com with ESMTPS id 13sm1267245gxk.13.2009.11.08.20.21.21 (version=SSLv3 cipher=RC4-MD5); Sun, 08 Nov 2009 20:21:22 -0800 (PST) Message-ID: <4AF798BD.4090009@gmail.com> Date: Mon, 09 Nov 2009 17:21:17 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ole Troan References: <4AF76212.60903@gmail.com> <01054E2B-BB74-4E27-A779-C86D35ECD08E@employees.org> In-Reply-To: <01054E2B-BB74-4E27-A779-C86D35ECD08E@employees.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 04:21:04 -0000 On 2009-11-09 14:12, Ole Troan wrote: >> Should we be specifying a default MTU of 1280 for 6RD too? >> >> (The same question applies retroactively to 6to4, of course.) > > this is what the draft says: > > "6rd's scope is limited to a service provider network. If the MTU is > well-managed > such that the IPv4 MTU on the 6rd CE WAN interface is set so that no > fragmentation occurs within the boundary of the SP, then the IPv6 MTU > should be set to the IPv4 MTU minus the size of the encapsulating IPv4 > header (20 bytes)." > > the assumption being that the service provider maintains a consistent > MTU across its network. Sure. If the v4 MTU is 1500, set the 6rd MTU to 1480. But shouldn't we specify a default for shipped products, and shouldn't it be 1280 (as the least bad choice)? > there is more reason for 6to4 to have a default MTU of 1280 though. I agree, and I wish we had specified a default. All this is orthogonal to PMTUD and ICMP translation; we're talking about a default for when PMTUD fails to work at all. Brian From shemant@cisco.com Sun Nov 8 20:25:41 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B350328C144 for ; Sun, 8 Nov 2009 20:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.886 X-Spam-Level: X-Spam-Status: No, score=-5.886 tagged_above=-999 required=5 tests=[AWL=0.713, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gv5SUh4UfuCB for ; Sun, 8 Nov 2009 20:25:40 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A903328C143 for ; Sun, 8 Nov 2009 20:25:40 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGoo90qtJV2b/2dsb2JhbADDQpY/hD4EgWg X-IronPort-AV: E=Sophos;i="4.44,705,1249257600"; d="scan'208";a="67011708" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 09 Nov 2009 04:26:05 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id nA94Q52H015711; Mon, 9 Nov 2009 04:26:05 GMT Received: from xmb-rcd-114.cisco.com ([72.163.62.156]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 22:26:05 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Nov 2009 22:26:04 -0600 Message-ID: In-Reply-To: <4AF798BD.4090009@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] MTU issue for 6RD (and 6to4) Thread-Index: Acpg9CPHY7/id+OpS2eXWl9yw2V4CwAACS0A References: <4AF76212.60903@gmail.com><01054E2B-BB74-4E27-A779-C86D35ECD08E@employees.org> <4AF798BD.4090009@gmail.com> From: "Hemant Singh (shemant)" To: "Brian E Carpenter" , "Ole Troan" X-OriginalArrivalTime: 09 Nov 2009 04:26:05.0581 (UTC) FILETIME=[C0C393D0:01CA60F4] Cc: softwires@ietf.org Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 04:25:41 -0000 It's not as simple as that. What if the 6rd functionality is running on the access concentrator like a CMTS in cable? In a cable deployment, due to the added len from docsis headers, the MTU in cable between the home and the cable access concentrator is actually less than the typical MTU for Ethernet LANs. So do we really have to specify an MTU for the 6rd specification? Hemant -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Monday, November 09, 2009 1:21 PM To: Ole Troan Cc: softwires@ietf.org Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) On 2009-11-09 14:12, Ole Troan wrote: >> Should we be specifying a default MTU of 1280 for 6RD too? >> >> (The same question applies retroactively to 6to4, of course.) >=20 > this is what the draft says: >=20 > "6rd's scope is limited to a service provider network. If the MTU is > well-managed > such that the IPv4 MTU on the 6rd CE WAN interface is set so that no > fragmentation occurs within the boundary of the SP, then the IPv6 MTU > should be set to the IPv4 MTU minus the size of the encapsulating IPv4 > header (20 bytes)." >=20 > the assumption being that the service provider maintains a consistent > MTU across its network. Sure. If the v4 MTU is 1500, set the 6rd MTU to 1480. But shouldn't we specify a default for shipped products, and shouldn't it be 1280 (as the least bad choice)? > there is more reason for 6to4 to have a default MTU of 1280 though. I agree, and I wish we had specified a default. All this is orthogonal to PMTUD and ICMP translation; we're talking about a default for when PMTUD fails to work at all. Brian _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From dthaler@microsoft.com Sun Nov 8 20:30:13 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 251633A681F for ; Sun, 8 Nov 2009 20:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyQY5sXyR2qe for ; Sun, 8 Nov 2009 20:30:12 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 748533A67CF for ; Sun, 8 Nov 2009 20:30:12 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 8 Nov 2009 20:30:38 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server id 14.0.639.20; Sun, 8 Nov 2009 20:30:38 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Sun, 8 Nov 2009 20:30:36 -0800 From: Dave Thaler To: Brian E Carpenter , Ole Troan Thread-Topic: [Softwires] MTU issue for 6RD (and 6to4) Thread-Index: AQHKYNOdW2YAZTDqKUGprV1QOkBnUJEtd9YAgAA0yID//3vx8A== Date: Mon, 9 Nov 2009 04:30:35 +0000 Message-ID: References: <4AF76212.60903@gmail.com> <01054E2B-BB74-4E27-A779-C86D35ECD08E@employees.org> <4AF798BD.4090009@gmail.com> In-Reply-To: <4AF798BD.4090009@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 04:30:13 -0000 [...] > But shouldn't we specify a default for shipped products, > and shouldn't it be 1280 (as the least bad choice)? >=20 > > there is more reason for 6to4 to have a default MTU of 1280 though. >=20 > I agree, and I wish we had specified a default. FWIW, Windows defaults to 1280 for 6to4. -Dave From shemant@cisco.com Sun Nov 8 20:40:34 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4BF23A690F for ; Sun, 8 Nov 2009 20:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.934 X-Spam-Level: X-Spam-Status: No, score=-5.934 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbVwMCrnLZOn for ; Sun, 8 Nov 2009 20:40:33 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 9D05A3A679F for ; Sun, 8 Nov 2009 20:40:33 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMcr90qrR7Ht/2dsb2JhbADDV5ZAhD4E X-IronPort-AV: E=Sophos;i="4.44,705,1249257600"; d="scan'208";a="103015510" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 09 Nov 2009 04:41:00 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA94exGP026038; Mon, 9 Nov 2009 04:40:59 GMT Received: from xmb-rcd-114.cisco.com ([72.163.62.156]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 22:40:59 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Nov 2009 22:40:57 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] MTU issue for 6RD (and 6to4) Thread-Index: AQHKYNOdW2YAZTDqKUGprV1QOkBnUJEtd9YAgAA0yID//3vx8IAAAt6Q References: <4AF76212.60903@gmail.com><01054E2B-BB74-4E27-A779-C86D35ECD08E@employees.org><4AF798BD.4090009@gmail.com> From: "Hemant Singh (shemant)" To: "Dave Thaler" , "Brian E Carpenter" , "Ole Troan" X-OriginalArrivalTime: 09 Nov 2009 04:40:59.0175 (UTC) FILETIME=[D5633370:01CA60F6] Cc: softwires@ietf.org Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 04:40:34 -0000 Specifying a low default like 1280 sounds fine by me because after accounting for cable docsis headers this value will work if 6rd functionality is running in the cable access concentrator. Hemant -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Dave Thaler Sent: Monday, November 09, 2009 1:31 PM To: Brian E Carpenter; Ole Troan Cc: softwires@ietf.org Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) [...] > But shouldn't we specify a default for shipped products, > and shouldn't it be 1280 (as the least bad choice)? >=20 > > there is more reason for 6to4 to have a default MTU of 1280 though. >=20 > I agree, and I wish we had specified a default. FWIW, Windows defaults to 1280 for 6to4. -Dave _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From Fred.L.Templin@boeing.com Sun Nov 8 21:03:32 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B093428C0F5 for ; Sun, 8 Nov 2009 21:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.568 X-Spam-Level: X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1p8lPFPKb-IQ for ; Sun, 8 Nov 2009 21:03:31 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id BC5493A697F for ; Sun, 8 Nov 2009 21:03:31 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id nA953DPa028791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 8 Nov 2009 21:03:14 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id nA953Dnd001206; Sun, 8 Nov 2009 23:03:13 -0600 (CST) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id nA953CC9001189 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Sun, 8 Nov 2009 23:03:13 -0600 (CST) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Sun, 8 Nov 2009 21:03:12 -0800 From: "Templin, Fred L" To: "Hemant Singh (shemant)" , Dave Thaler , Brian E Carpenter , Ole Troan Date: Sun, 8 Nov 2009 21:03:10 -0800 Thread-Topic: [Softwires] MTU issue for 6RD (and 6to4) Thread-Index: AQHKYNOdW2YAZTDqKUGprV1QOkBnUJEtd9YAgAA0yID//3vx8IAAAt6QgAAFEXA= Message-ID: <12F4112206976147A34FEC0277597CCF27A5229F1C@XCH-NW-15V.nw.nos.boeing.com> References: <4AF76212.60903@gmail.com><01054E2B-BB74-4E27-A779-C86D35ECD08E@ employees.org><4AF798BD.4090009@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 05:03:32 -0000 If the tunnel endpoints want to avoid fragmentation and reassembly, then setting the lower MTU seems prudent. If the tunnel endpoints are willing to incur a little fragmentation and reassembly, then the MTU could possibly be pushed to 1500 or more. As far as I can see, there is no way to truly sweep the extra overhead for encapsulation under the carpet without invoking fragmentation and reassembly within the tunnel. Fred fred.l.templin@boeing.com > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On B= ehalf Of Hemant Singh > (shemant) > Sent: Sunday, November 08, 2009 8:41 PM > To: Dave Thaler; Brian E Carpenter; Ole Troan > Cc: softwires@ietf.org > Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) >=20 > Specifying a low default like 1280 sounds fine by me because after > accounting for cable docsis headers this value will work if 6rd > functionality is running in the cable access concentrator. >=20 > Hemant >=20 > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Dave Thaler > Sent: Monday, November 09, 2009 1:31 PM > To: Brian E Carpenter; Ole Troan > Cc: softwires@ietf.org > Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) >=20 > [...] > > But shouldn't we specify a default for shipped products, > > and shouldn't it be 1280 (as the least bad choice)? > > > > > there is more reason for 6to4 to have a default MTU of 1280 though. > > > > I agree, and I wish we had specified a default. >=20 > FWIW, Windows defaults to 1280 for 6to4. >=20 > -Dave > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From ichiroumakino@gmail.com Sun Nov 8 21:32:14 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 902213A6AF0 for ; Sun, 8 Nov 2009 21:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njNYD54++eg4 for ; Sun, 8 Nov 2009 21:32:13 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 38A343A6AF1 for ; Sun, 8 Nov 2009 21:32:13 -0800 (PST) Received: by yxe30 with SMTP id 30so2957015yxe.29 for ; Sun, 08 Nov 2009 21:32:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=8QQT/bRvq0hN9Z3nXgA3ZKLUOSDSVZg7orBJsWJfD6s=; b=lyp25r7SfmpKoBgCMVQm9cdL93k6Y5jWxSOnPxCS88cURg0c7zyc1EcEuucdX4BA2p y1B8YqoUgReIZrU14cpQoZgt19oRtMZhSfU7pE9SDGyhZR8xFv+4tA19vGClism80Mcf 7BbFx6p5qUlIhsheD0pf+ma5gf2avPb5zwy/s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type:mime-version :subject:date:references:x-mailer; b=YOwazBRvcAZvHtszyiewVIc6eFCwtT8Dc5oUxrFiIYrid33cIbH6mVDGwLZ2vREHh3 ve3Ecg1l1azt4lqBnVhqxjQ6DelwIsVqvvbJzMoIeNKzjxIbEzqjzoFRaDMO6Tato9eT D/WF+y+xkh1QyTYmhiBV5acM7xD0bVY1tFDo8= Received: by 10.91.203.25 with SMTP id f25mr13840046agq.13.1257744754275; Sun, 08 Nov 2009 21:32:34 -0800 (PST) Received: from host-24-177.meeting.ietf.org (64-104-46-217.cisco.com [64.104.46.217]) by mx.google.com with ESMTPS id 39sm1113422yxd.27.2009.11.08.21.32.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 08 Nov 2009 21:32:33 -0800 (PST) Sender: Ole Troan Message-Id: <072F3245-6B81-4BC1-A850-0F100DEB702D@employees.org> From: Ole Troan To: "Hemant Singh (shemant)" In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-6-264674971; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 14:32:29 +0900 References: <4AF76212.60903@gmail.com><01054E2B-BB74-4E27-A779-C86D35ECD08E@employees.org> <4AF798BD.4090009@gmail.com> X-Mailer: Apple Mail (2.936) Cc: softwires@ietf.org Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 05:32:14 -0000 --Apple-Mail-6-264674971 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hemant, > It's not as simple as that. What if the 6rd functionality is > running on > the access concentrator like a CMTS in cable? In a cable deployment, > due to the added len from docsis headers, the MTU in cable between the > home and the cable access concentrator is actually less than the > typical > MTU for Ethernet LANs. So do we really have to specify an MTU for the > 6rd specification? in that case the IPv4 MTU is wrong too right? the 6rd assumption is that the IPv4 WAN interface MTU is correct and the MTU in the SP network is well managed. I'd prefer that to be the default as opposed to a fixed value of 1280. with a default of 1280 it appears you would need 6rd specific provisioning if one wants a different value. cheers, Ole > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] > On > Behalf Of Brian E Carpenter > Sent: Monday, November 09, 2009 1:21 PM > To: Ole Troan > Cc: softwires@ietf.org > Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) > > On 2009-11-09 14:12, Ole Troan wrote: >>> Should we be specifying a default MTU of 1280 for 6RD too? >>> >>> (The same question applies retroactively to 6to4, of course.) >> >> this is what the draft says: >> >> "6rd's scope is limited to a service provider network. If the MTU is >> well-managed >> such that the IPv4 MTU on the 6rd CE WAN interface is set so that no >> fragmentation occurs within the boundary of the SP, then the IPv6 MTU >> should be set to the IPv4 MTU minus the size of the encapsulating >> IPv4 >> header (20 bytes)." >> >> the assumption being that the service provider maintains a consistent >> MTU across its network. > > Sure. If the v4 MTU is 1500, set the 6rd MTU to 1480. > > But shouldn't we specify a default for shipped products, > and shouldn't it be 1280 (as the least bad choice)? > >> there is more reason for 6to4 to have a default MTU of 1280 though. > > I agree, and I wish we had specified a default. > > All this is orthogonal to PMTUD and ICMP translation; we're talking > about a default for when PMTUD fails to work at all. > > Brian > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-6-264674971 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDVDCCA1Aw ggI4oAMCAQICAQEwCwYJKoZIhvcNAQEFMEYxEjAQBgNVBAMMCU9sZSBUcm9hbjELMAkGA1UEBhMC R0IxIzAhBgkqhkiG9w0BCQEWFG90cm9hbkBlbXBsb3llZXMub3JnMB4XDTA4MDUwNzAwMDAxMVoX DTA5MDUwNzAwMDAxMVowRjESMBAGA1UEAwwJT2xlIFRyb2FuMQswCQYDVQQGEwJHQjEjMCEGCSqG SIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCqhwqYY9JywwGzpwmC3kFCf8/TzdM3AHZAvr1Z2cei/PbCaAqTBQ1kiwFpNxAgqcofM2LP xKq3EhHfUs4oukBOYqhrlmJtAclNBf8ctZDoWnz3ETsCYb77bMvdMRJqoJr1+YpySGl/leDqdIq8 ee0LYj0DcOQA9YFPQw7XUA107tyozy6+F7LfAzx10j2uuyfyxp55dVMfcVe8ROAv1c4LcUUCtgqp SceHH0WMuXf2j0TdAsPQ/Hd1Ak6rOx8lCVwJ7b0AKbbCVIIBlqGyVlXW6bcjwmxGGjVDgY/5CIAg KC44/6BsN/QDXnHwlU2pJlJM4mvgy1CMjy+7Y/ldvJkVAgMBAAGjSzBJMA4GA1UdDwEB/wQEAwIH gDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAfBgNVHREEGDAWgRRvdHJvYW5AZW1wbG95ZWVzLm9y ZzANBgkqhkiG9w0BAQUFAAOCAQEAWMQKZJ9OSQP2BIEjq47jG6PxfzcUhmgLHGIn7X1E6SAjmjma UmA4K3V3Ydxksb+JOXshfu6YgxCzfhdcV/wh8WA0ld2sxueRpdG8hmxQyI5sRFNvPbZdplCA105H 2UwjVVNVIQu6MAa3siYUB4g7eFGEjIqcXO80wa+xgKbnflbPFq0iXKwjQn9jbho3zlbsZhIV3yNp sOVMwdqyRaUrXKB6ycOFEbeNTVfFok+1Xx5bbk4aZz1WlbVkhUlXuSMxZFgD7PmPR57Q16ADDEZ6 1X28mvv0z/WzClrH6LV6bxtnbQzPnZgUMw5Of5+mFl1RvGkZfYfeIF5fXfo6HpV5ETGCAo0wggKJ AgEBMEswRjESMBAGA1UEAwwJT2xlIFRyb2FuMQswCQYDVQQGEwJHQjEjMCEGCSqGSIb3DQEJARYU b3Ryb2FuQGVtcGxveWVlcy5vcmcCAQEwCQYFKw4DAhoFAKCCARcwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMTA5MDUzMjI5WjAjBgkqhkiG9w0BCQQxFgQUtaNU QCy/4E5Koc4zafzJ7XdKf3YwWgYJKwYBBAGCNxAEMU0wSzBGMRIwEAYDVQQDDAlPbGUgVHJvYW4x CzAJBgNVBAYTAkdCMSMwIQYJKoZIhvcNAQkBFhRvdHJvYW5AZW1wbG95ZWVzLm9yZwIBATBcBgsq hkiG9w0BCRACCzFNoEswRjESMBAGA1UEAwwJT2xlIFRyb2FuMQswCQYDVQQGEwJHQjEjMCEGCSqG SIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcCAQEwDQYJKoZIhvcNAQEBBQAEggEAQFTlJ436 0SW0oMAh8s4r3o0c4uLTH7Smupe+g5251pHzzrNpUwa4fyFGvMCFzb2S2k4MMiy/u7Dvj9ToftO1 Q2S6WW3/r6ZHVGIqaRy1kFviUqnhhEK7U0PK36lyVjvimboCmSU346AJkONjD1ZPe4TwaAN72BcX mwv0lqHqBhfUiyDP0AvXTZxcNaQ+djI4IDlfMdYV5MVG24RBFXMT6CXG8jg8o5AloJuFBfzi/moG 9twHuHWqraV/ecwd1wt6gaS9O2z+zRPSCcKit55c33G9/Z7evYUJvl2cQRB1gPoXqe54F6Aibd/w nq1mUYXTbBkbUkZztIYH4/fTK53jZgAAAAAAAA== --Apple-Mail-6-264674971-- From shemant@cisco.com Sun Nov 8 21:39:41 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0AE43A6AD0 for ; Sun, 8 Nov 2009 21:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.975 X-Spam-Level: X-Spam-Status: No, score=-5.975 tagged_above=-999 required=5 tests=[AWL=0.624, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rg9Vh0OflO95 for ; Sun, 8 Nov 2009 21:39:40 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 0ABD13A6ABF for ; Sun, 8 Nov 2009 21:39:39 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAP4590qtJV2a/2dsb2JhbADDO5Y/hD4EgWg X-IronPort-AV: E=Sophos;i="4.44,706,1249257600"; d="scan'208";a="67017057" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 09 Nov 2009 05:40:05 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id nA95e5qX011692; Mon, 9 Nov 2009 05:40:05 GMT Received: from xmb-rcd-114.cisco.com ([72.163.62.156]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 23:40:04 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Nov 2009 23:40:03 -0600 Message-ID: In-Reply-To: <072F3245-6B81-4BC1-A850-0F100DEB702D@employees.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] MTU issue for 6RD (and 6to4) Thread-Index: Acpg/gs8TM1ej/HsT1CWDxc8h5biywAACCAQ References: <4AF76212.60903@gmail.com><01054E2B-BB74-4E27-A779-C86D35ECD08E@employees.org> <4AF798BD.4090009@gmail.com> <072F3245-6B81-4BC1-A850-0F100DEB702D@employees.org> From: "Hemant Singh (shemant)" To: "Ole Troan" X-OriginalArrivalTime: 09 Nov 2009 05:40:04.0995 (UTC) FILETIME=[16DC6530:01CA60FF] Cc: softwires@ietf.org Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 05:39:41 -0000 >-----Original Message----- >From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan >Sent: Monday, November 09, 2009 2:32 PM >To: Hemant Singh (shemant) >Cc: Brian E Carpenter; softwires@ietf.org >Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) >Hemant, >> It's not as simple as that. What if the 6rd functionality is =20 >> running on >> the access concentrator like a CMTS in cable? In a cable deployment, >> due to the added len from docsis headers, the MTU in cable between the >> home and the cable access concentrator is actually less than the =20 >> typical >> MTU for Ethernet LANs. So do we really have to specify an MTU for the >> 6rd specification? >in that case the IPv4 MTU is wrong too right? Yes. >the 6rd assumption is that the IPv4 WAN interface MTU is correct and =20 >the MTU in the SP network is well managed. I'd prefer that to be the =20 >default as opposed to a fixed value of 1280. with a default of 1280 it >appears you would need 6rd specific provisioning if one wants a =20 >different value. Totally agree. That is why I said why even bother specifying any value for MTU default in the 6rd document when the default has to be equal to the IP4 MTU. Other documents have got to exist that define MTU values for tunnels.=20 Hemant From brian.e.carpenter@gmail.com Sun Nov 8 21:49:23 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A454228C0F5 for ; Sun, 8 Nov 2009 21:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1E7o6p7vWjgQ for ; Sun, 8 Nov 2009 21:49:22 -0800 (PST) Received: from mail-gx0-f212.google.com (mail-gx0-f212.google.com [209.85.217.212]) by core3.amsl.com (Postfix) with ESMTP id B63113A6899 for ; Sun, 8 Nov 2009 21:49:22 -0800 (PST) Received: by gxk4 with SMTP id 4so13531gxk.8 for ; Sun, 08 Nov 2009 21:49:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=SbW3C4BYz9S72h0Fqa4KhPdUFmYA8CfydMKXi4y4Iv4=; b=vdpJ3ekH4FDRd9tlc79v/jHP+nFAR4249fBerjmYcd5YLnEhUP2i/IVquCQ3Z+3PY+ xJfhYQN0v1JbpuyNAXHK4AvxaSD1eftK9v1gf5UUBFXyJp8k1TCJxyuiRX3l4Z4FV7dM MDC0hheiJvxaydkHL8RAC7oAnhgcD3lWdPjmg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=WTZgPQUpP9IWu+gMs5NEH3iNGT+0DO9kc59fzt/weF0er0VG1TJM2ioV0RIgvpUfO/ m7VB6GCjKWy2nJ4Q9VNVG1WcfwW0uDDKGvVFkfKEZH1aOB3ZVrtJa3Br3tsPa5IyBEdJ 3XSUPjNiuxN7DHxhiUtaDzgvcHPxa/DSdczd0= Received: by 10.150.87.4 with SMTP id k4mr12347242ybb.347.1257745783386; Sun, 08 Nov 2009 21:49:43 -0800 (PST) Received: from ?133.93.16.203? (host-16-203.meeting.ietf.org [133.93.16.203]) by mx.google.com with ESMTPS id 14sm1302531gxk.10.2009.11.08.21.49.41 (version=SSLv3 cipher=RC4-MD5); Sun, 08 Nov 2009 21:49:42 -0800 (PST) Message-ID: <4AF7AD71.20708@gmail.com> Date: Mon, 09 Nov 2009 18:49:37 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ole Troan References: <4AF76212.60903@gmail.com><01054E2B-BB74-4E27-A779-C86D35ECD08E@employees.org> <4AF798BD.4090009@gmail.com> <072F3245-6B81-4BC1-A850-0F100DEB702D@employees.org> In-Reply-To: <072F3245-6B81-4BC1-A850-0F100DEB702D@employees.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 05:49:23 -0000 Sure, (v4MTU - 20) is a reasonable formula once you know the value of v4MTU, as long as the result is at least 1280. But if you don't know v4MTU, you have to have *something* as the default, and I can't see anything better than 1280. Regards Brian Carpenter On 2009-11-09 18:32, Ole Troan wrote: > Hemant, > >> It's not as simple as that. What if the 6rd functionality is running on >> the access concentrator like a CMTS in cable? In a cable deployment, >> due to the added len from docsis headers, the MTU in cable between the >> home and the cable access concentrator is actually less than the typical >> MTU for Ethernet LANs. So do we really have to specify an MTU for the >> 6rd specification? > > in that case the IPv4 MTU is wrong too right? > the 6rd assumption is that the IPv4 WAN interface MTU is correct and the > MTU in the SP network is well managed. I'd prefer that to be the default > as opposed to a fixed value of 1280. with a default of 1280 it appears > you would need 6rd specific provisioning if one wants a different value. > > cheers, > Ole > > >> -----Original Message----- >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On >> Behalf Of Brian E Carpenter >> Sent: Monday, November 09, 2009 1:21 PM >> To: Ole Troan >> Cc: softwires@ietf.org >> Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) >> >> On 2009-11-09 14:12, Ole Troan wrote: >>>> Should we be specifying a default MTU of 1280 for 6RD too? >>>> >>>> (The same question applies retroactively to 6to4, of course.) >>> >>> this is what the draft says: >>> >>> "6rd's scope is limited to a service provider network. If the MTU is >>> well-managed >>> such that the IPv4 MTU on the 6rd CE WAN interface is set so that no >>> fragmentation occurs within the boundary of the SP, then the IPv6 MTU >>> should be set to the IPv4 MTU minus the size of the encapsulating IPv4 >>> header (20 bytes)." >>> >>> the assumption being that the service provider maintains a consistent >>> MTU across its network. >> >> Sure. If the v4 MTU is 1500, set the 6rd MTU to 1480. >> >> But shouldn't we specify a default for shipped products, >> and shouldn't it be 1280 (as the least bad choice)? >> >>> there is more reason for 6to4 to have a default MTU of 1280 though. >> >> I agree, and I wish we had specified a default. >> >> All this is orthogonal to PMTUD and ICMP translation; we're talking >> about a default for when PMTUD fails to work at all. >> >> Brian >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > From ichiroumakino@gmail.com Sun Nov 8 21:59:57 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B56A3A68FA for ; Sun, 8 Nov 2009 21:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7VMmw9xP513 for ; Sun, 8 Nov 2009 21:59:56 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 4823B3A6820 for ; Sun, 8 Nov 2009 21:59:56 -0800 (PST) Received: by yxe30 with SMTP id 30so2970606yxe.29 for ; Sun, 08 Nov 2009 22:00:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=V9jFl2ezdQ0T+C8tFIqXfPJ8pttQfVxr0iDyYCJeht0=; b=nHXVOfSzSwJ2avQvIhk1ckvgV5MgDDsyPd+h0QCPvCDDdQH7NvbObk4P5pJPizdCB7 W9UgUfN/IBobzXS0MV+AZI803sZFAIkh0Ws//QkMABEYxf4l+LfazLVoiUMe7NAk2Kur vLronXMTuMFmQXrGOCIQwKdL827efZuPB3+vo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type:mime-version :subject:date:references:x-mailer; b=GbAiiPKd2sWe4FIZNNZJp7xH6T8TOfWEhAg7E3mX1Ou3ZGUPEboO5QY9wk+uquRIXI ZUS+zCKcUB3b0Zb4SOCMieMC7uAZb//JsWf9Dyb4MySGhwjZjYBF+JvuwwKXa5vU6HCv GwU5uidTZNjQ5KBIgFrWhPBQC5ksNGuJriunk= Received: by 10.90.166.2 with SMTP id o2mr12658684age.93.1257746419492; Sun, 08 Nov 2009 22:00:19 -0800 (PST) Received: from host-24-177.meeting.ietf.org (64-104-46-217.cisco.com [64.104.46.217]) by mx.google.com with ESMTPS id 6sm1118605yxg.48.2009.11.08.22.00.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 08 Nov 2009 22:00:18 -0800 (PST) Sender: Ole Troan Message-Id: From: Ole Troan To: Brian E Carpenter In-Reply-To: <4AF7AD71.20708@gmail.com> Content-Type: multipart/signed; boundary=Apple-Mail-7-266340227; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 15:00:14 +0900 References: <4AF76212.60903@gmail.com><01054E2B-BB74-4E27-A779-C86D35ECD08E@employees.org> <4AF798BD.4090009@gmail.com> <072F3245-6B81-4BC1-A850-0F100DEB702D@employees.org> <4AF7AD71.20708@gmail.com> X-Mailer: Apple Mail (2.936) Cc: softwires@ietf.org Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 05:59:57 -0000 --Apple-Mail-7-266340227 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Brian, > Sure, (v4MTU - 20) is a reasonable formula once you > know the value of v4MTU, as long as the result is at > least 1280. But if you don't know v4MTU, you have to > have *something* as the default, and I can't see anything > better than 1280. agree, but in which cases would you not know the v4MTU? cheers, Ole >> Hemant, >> >>> It's not as simple as that. What if the 6rd functionality is >>> running on >>> the access concentrator like a CMTS in cable? In a cable >>> deployment, >>> due to the added len from docsis headers, the MTU in cable between >>> the >>> home and the cable access concentrator is actually less than the >>> typical >>> MTU for Ethernet LANs. So do we really have to specify an MTU for >>> the >>> 6rd specification? >> >> in that case the IPv4 MTU is wrong too right? >> the 6rd assumption is that the IPv4 WAN interface MTU is correct >> and the >> MTU in the SP network is well managed. I'd prefer that to be the >> default >> as opposed to a fixed value of 1280. with a default of 1280 it >> appears >> you would need 6rd specific provisioning if one wants a different >> value. >> >> cheers, >> Ole >> >> >>> -----Original Message----- >>> From: softwires-bounces@ietf.org [mailto:softwires- >>> bounces@ietf.org] On >>> Behalf Of Brian E Carpenter >>> Sent: Monday, November 09, 2009 1:21 PM >>> To: Ole Troan >>> Cc: softwires@ietf.org >>> Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) >>> >>> On 2009-11-09 14:12, Ole Troan wrote: >>>>> Should we be specifying a default MTU of 1280 for 6RD too? >>>>> >>>>> (The same question applies retroactively to 6to4, of course.) >>>> >>>> this is what the draft says: >>>> >>>> "6rd's scope is limited to a service provider network. If the MTU >>>> is >>>> well-managed >>>> such that the IPv4 MTU on the 6rd CE WAN interface is set so that >>>> no >>>> fragmentation occurs within the boundary of the SP, then the IPv6 >>>> MTU >>>> should be set to the IPv4 MTU minus the size of the encapsulating >>>> IPv4 >>>> header (20 bytes)." >>>> >>>> the assumption being that the service provider maintains a >>>> consistent >>>> MTU across its network. >>> >>> Sure. If the v4 MTU is 1500, set the 6rd MTU to 1480. >>> >>> But shouldn't we specify a default for shipped products, >>> and shouldn't it be 1280 (as the least bad choice)? >>> >>>> there is more reason for 6to4 to have a default MTU of 1280 though. >>> >>> I agree, and I wish we had specified a default. >>> >>> All this is orthogonal to PMTUD and ICMP translation; we're talking >>> about a default for when PMTUD fails to work at all. >>> >>> Brian >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >> --Apple-Mail-7-266340227 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDVDCCA1Aw ggI4oAMCAQICAQEwCwYJKoZIhvcNAQEFMEYxEjAQBgNVBAMMCU9sZSBUcm9hbjELMAkGA1UEBhMC R0IxIzAhBgkqhkiG9w0BCQEWFG90cm9hbkBlbXBsb3llZXMub3JnMB4XDTA4MDUwNzAwMDAxMVoX DTA5MDUwNzAwMDAxMVowRjESMBAGA1UEAwwJT2xlIFRyb2FuMQswCQYDVQQGEwJHQjEjMCEGCSqG SIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCqhwqYY9JywwGzpwmC3kFCf8/TzdM3AHZAvr1Z2cei/PbCaAqTBQ1kiwFpNxAgqcofM2LP xKq3EhHfUs4oukBOYqhrlmJtAclNBf8ctZDoWnz3ETsCYb77bMvdMRJqoJr1+YpySGl/leDqdIq8 ee0LYj0DcOQA9YFPQw7XUA107tyozy6+F7LfAzx10j2uuyfyxp55dVMfcVe8ROAv1c4LcUUCtgqp SceHH0WMuXf2j0TdAsPQ/Hd1Ak6rOx8lCVwJ7b0AKbbCVIIBlqGyVlXW6bcjwmxGGjVDgY/5CIAg KC44/6BsN/QDXnHwlU2pJlJM4mvgy1CMjy+7Y/ldvJkVAgMBAAGjSzBJMA4GA1UdDwEB/wQEAwIH gDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAfBgNVHREEGDAWgRRvdHJvYW5AZW1wbG95ZWVzLm9y ZzANBgkqhkiG9w0BAQUFAAOCAQEAWMQKZJ9OSQP2BIEjq47jG6PxfzcUhmgLHGIn7X1E6SAjmjma UmA4K3V3Ydxksb+JOXshfu6YgxCzfhdcV/wh8WA0ld2sxueRpdG8hmxQyI5sRFNvPbZdplCA105H 2UwjVVNVIQu6MAa3siYUB4g7eFGEjIqcXO80wa+xgKbnflbPFq0iXKwjQn9jbho3zlbsZhIV3yNp sOVMwdqyRaUrXKB6ycOFEbeNTVfFok+1Xx5bbk4aZz1WlbVkhUlXuSMxZFgD7PmPR57Q16ADDEZ6 1X28mvv0z/WzClrH6LV6bxtnbQzPnZgUMw5Of5+mFl1RvGkZfYfeIF5fXfo6HpV5ETGCAo0wggKJ AgEBMEswRjESMBAGA1UEAwwJT2xlIFRyb2FuMQswCQYDVQQGEwJHQjEjMCEGCSqGSIb3DQEJARYU b3Ryb2FuQGVtcGxveWVlcy5vcmcCAQEwCQYFKw4DAhoFAKCCARcwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMTA5MDYwMDE0WjAjBgkqhkiG9w0BCQQxFgQUF67G csOwbis/hRXVzSAbug6rl1IwWgYJKwYBBAGCNxAEMU0wSzBGMRIwEAYDVQQDDAlPbGUgVHJvYW4x CzAJBgNVBAYTAkdCMSMwIQYJKoZIhvcNAQkBFhRvdHJvYW5AZW1wbG95ZWVzLm9yZwIBATBcBgsq hkiG9w0BCRACCzFNoEswRjESMBAGA1UEAwwJT2xlIFRyb2FuMQswCQYDVQQGEwJHQjEjMCEGCSqG SIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcCAQEwDQYJKoZIhvcNAQEBBQAEggEAEor1/Eil C5gOkFwFcIaCaFjJ/Y0+YWcbp4ZDTmnBMoblt+24e5lexjXfbQ3Ut/TX3bVOgY8RqkTHD/vDi0Jf mdyp/F2agBkuxaE3BgGnvUYo21d+3bhKTiVfOCYNrGm0ZCnKXTHsksgQ6l/lYZiQwNz9hx/8bBQf mxTTMilTpcQQw+AMksN+78T4wX466xPrLwmVsOA1Drsg3WbV3OcLsUDRLsrlfm6KrWOcoM69NwK/ zv3S+BULYvwCQy3ddHH0IFH7oSZDpFgMC4HDQpdQZA0xpQWdDTjHQhesQO4cxGgvn9oyOkSda/BO V0VhodOtb05G3D+nA0mZrP/r3TAlNwAAAAAAAA== --Apple-Mail-7-266340227-- From jhw@apple.com Sun Nov 8 22:09:01 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A7ED3A6AEC for ; Sun, 8 Nov 2009 22:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.248 X-Spam-Level: X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiIlxoapHPn7 for ; Sun, 8 Nov 2009 22:08:59 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 108803A6AEA for ; Sun, 8 Nov 2009 22:08:59 -0800 (PST) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id 40F367EB6758 for ; Sun, 8 Nov 2009 22:09:25 -0800 (PST) X-AuditID: 11807134-b7cd9ae000001002-9c-4af7b214ee4b Received: from [17.151.110.148] (Unknown_Domain [17.151.110.148]) (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 3A.AD.04098.412B7FA4; Sun, 8 Nov 2009 22:09:25 -0800 (PST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v1076) From: james woodyatt In-Reply-To: <12F4112206976147A34FEC0277597CCF27A5229F1C@XCH-NW-15V.nw.nos.boeing.com> Date: Sun, 8 Nov 2009 22:09:24 -0800 Content-Transfer-Encoding: 7bit Message-Id: <236F77A8-F030-4602-A403-50055E28A286@apple.com> References: <4AF76212.60903@gmail.com> <4AF798BD.4090009@gmail.com> <"E4561B14EE2A3E4E9D478EBFB5416E1B 29B367B5"@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <12F4112206976147A34FEC0277597CCF27A5229F1C@XCH-NW-15V.nw.nos.boeing.com> To: softwires@ietf.org X-Mailer: Apple Mail (2.1076) X-Brightmail-Tracker: AAAAAQAAAZE= Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 06:09:01 -0000 On Nov 8, 2009, at 21:03 , Templin, Fred L wrote: > [...] As far as I can see, there is no way to truly sweep the extra > overhead for encapsulation under the carpet without invoking > fragmentation and reassembly within the tunnel. I'm confused. It was my impression that IPv4 showed us how expecting the network to handle fragmentation and reassembly on a hop-by-hop basis wasn't such a good idea after all, and that we lifted fragmentation and reassembly up to the level of destination option processing precisely to simplify the forwarding path in routers. Am I missing something? I mean, when I do the back of the envelope calculations about overhead, I don't see numbers that make a compelling argument for unburdening hosts from the need to do path MTU discovery, especially when the first-mile IPv6 link is tunneled over IPv4. You're always going to have an IPv4 header in every ~1500 octet packet. After that, you have two alternatives: A) the IPv6 host has discovered the path MTU including the IPv4 encapsulation, and there is an IPv6 header in every IPv4 packet; B) the IPv6 host has been saved from learning the smaller path MTU for the IPv4 tunnel and learns instead the larger path MTU, which is probably not going to be more than 1500 kB for at least as long as 6RD is expected to live, so here there are two subcases: 1) the IPv6 packet is small enough that it doesn't need fragmentation, e.g. empty TCP ACK packets, in which case there is an IPv6 header in the IPv4 packet, just like the first alternative; 2) the IPv6 packet is larger than the tunnel MTU, e.g. a full- size TCP segment for the IPv6 path MTU, and so there are two or more IPv4 packets and the IPv6 header is amortized between them. If the IPv4 path MTU between the 6RD CPE router and the 6RD relay is the typical 1500 octets, then you don't win anything by doing fragment reassembly at the tunnel endpoints unless the IPv6 path MTU is larger than 2960 octets. That's not happening any time soon for basically anyone in the intended user community for 6RD. It's going to be a long time before residential subscriber networks can be reasonably expected to support a link MTU large enough for this path MTU business to be important. People keep deploying heterogenous bridges between various link layers with different native MTU, e.g. Wi- Fi with 2304 and/or 4000 depending, Gig-E with 9000. Sadly, IPv6 neighbor discovery doesn't cope well with jumbo frames on such networks, so everyone uses 1500 octets for the same historical reasons we've always had. They're not going away. Until IPv6 neighbor discovery can cope with the issue of path MTU discovery on local links [*], I'm not getting excited about the encapsulation overhead for hosts behind 6RD gateways. -- james woodyatt member of technical staff, communications engineering [*] c.f. From ichiroumakino@gmail.com Sun Nov 8 22:24:02 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F2663A69BD for ; Sun, 8 Nov 2009 22:24:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZL-PAHqUXX0 for ; Sun, 8 Nov 2009 22:24:01 -0800 (PST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 265043A6AD9 for ; Sun, 8 Nov 2009 22:24:01 -0800 (PST) Received: by ywh13 with SMTP id 13so2982308ywh.29 for ; Sun, 08 Nov 2009 22:24:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=fUi2RkT57kL7Apl5V0ETW5J5Z2DBpIDYcNIoulWsu/8=; b=cMhVqmjnQebGXRrjqx9WKGhZtqxY+llUXU+z7TCHMnOBBUTWPu5XbSNzCiPfPNuSnb Qq1D3ILeEisrfNMzoEI872OoA9mdOSmYSVtCN2BfJABxHIdyqy9QTTG8B+PkJz7HLgLv /KM+dmrBiR7/IcyUFlewv1ojPNB9GfTEuLups= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type:mime-version :subject:date:references:x-mailer; b=lVnF2Qba7wYH8KRuDA2Qo2thadkdrhr5RgmuifBtN2CAlGdNqEVPwFuHtFs3Hve0oW 0WxvDydKdDS9nG/jFKprleQ1Iwg7OP9Mmgi8jPeEQ/n9CbDahkYycjpvI4CZVv/921an y4ehlhONY6X8g/wy6EvEDmxUuJTjWUvxbjaEI= Received: by 10.150.129.13 with SMTP id b13mr12458456ybd.314.1257747861654; Sun, 08 Nov 2009 22:24:21 -0800 (PST) Received: from host-24-177.meeting.ietf.org (host-24-177.meeting.ietf.org [133.93.24.177]) by mx.google.com with ESMTPS id 14sm1262764gxk.6.2009.11.08.22.24.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 08 Nov 2009 22:24:20 -0800 (PST) Sender: Ole Troan Message-Id: <38340497-B409-41F0-BEE4-2BDCEABA9981@employees.org> From: Ole Troan To: Brian E Carpenter In-Reply-To: <4AF7AD71.20708@gmail.com> Content-Type: multipart/signed; boundary=Apple-Mail-8-267780849; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 15:24:11 +0900 References: <4AF76212.60903@gmail.com><01054E2B-BB74-4E27-A779-C86D35ECD08E@employees.org> <4AF798BD.4090009@gmail.com> <072F3245-6B81-4BC1-A850-0F100DEB702D@employees.org> <4AF7AD71.20708@gmail.com> X-Mailer: Apple Mail (2.936) Cc: softwires@ietf.org Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 06:24:02 -0000 --Apple-Mail-8-267780849 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit > Sure, (v4MTU - 20) is a reasonable formula once you > know the value of v4MTU, as long as the result is at > least 1280. But if you don't know v4MTU, you have to > have *something* as the default, and I can't see anything > better than 1280. re-reading RFC4213 section 3.2. it does say that the tunnel MTU MUST be between 1280 and 1480 and it SHOULD be 1280 by default. this is a general problem and really shouldn't be solved in 6rd. if we think the MTU discussion in 4213 is missing something we should update that RFC instead. is the current text in the draft acceptable or should we say even less and just reference 4213: "MTU and fragmentation issues for IPv6 in IPv4 tunnelling is discussed in detail in section 3.2 of RFC4213 [RFC4213]. 6rd's scope is limited to a service provider network. If the MTU is well-managed such that the IPv4 MTU on the 6rd CE WAN interface is set so that no fragmentation occurs within the boundary of the SP, then the IPv6 MTU should be set to the IPv4 MTU minus the size of the encapsulating IPv4 header (20 bytes). IPv4 Path MTU discovery MAY be used to adjust the MTU of the tunnel as described in section 3.2.2 of RFC4213 [RFC4213] or the IPv6 tunnel MTU may be explicitly configured." cheers, Ole --Apple-Mail-8-267780849 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDVDCCA1Aw ggI4oAMCAQICAQEwCwYJKoZIhvcNAQEFMEYxEjAQBgNVBAMMCU9sZSBUcm9hbjELMAkGA1UEBhMC R0IxIzAhBgkqhkiG9w0BCQEWFG90cm9hbkBlbXBsb3llZXMub3JnMB4XDTA4MDUwNzAwMDAxMVoX DTA5MDUwNzAwMDAxMVowRjESMBAGA1UEAwwJT2xlIFRyb2FuMQswCQYDVQQGEwJHQjEjMCEGCSqG SIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCqhwqYY9JywwGzpwmC3kFCf8/TzdM3AHZAvr1Z2cei/PbCaAqTBQ1kiwFpNxAgqcofM2LP xKq3EhHfUs4oukBOYqhrlmJtAclNBf8ctZDoWnz3ETsCYb77bMvdMRJqoJr1+YpySGl/leDqdIq8 ee0LYj0DcOQA9YFPQw7XUA107tyozy6+F7LfAzx10j2uuyfyxp55dVMfcVe8ROAv1c4LcUUCtgqp SceHH0WMuXf2j0TdAsPQ/Hd1Ak6rOx8lCVwJ7b0AKbbCVIIBlqGyVlXW6bcjwmxGGjVDgY/5CIAg KC44/6BsN/QDXnHwlU2pJlJM4mvgy1CMjy+7Y/ldvJkVAgMBAAGjSzBJMA4GA1UdDwEB/wQEAwIH gDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAfBgNVHREEGDAWgRRvdHJvYW5AZW1wbG95ZWVzLm9y ZzANBgkqhkiG9w0BAQUFAAOCAQEAWMQKZJ9OSQP2BIEjq47jG6PxfzcUhmgLHGIn7X1E6SAjmjma UmA4K3V3Ydxksb+JOXshfu6YgxCzfhdcV/wh8WA0ld2sxueRpdG8hmxQyI5sRFNvPbZdplCA105H 2UwjVVNVIQu6MAa3siYUB4g7eFGEjIqcXO80wa+xgKbnflbPFq0iXKwjQn9jbho3zlbsZhIV3yNp sOVMwdqyRaUrXKB6ycOFEbeNTVfFok+1Xx5bbk4aZz1WlbVkhUlXuSMxZFgD7PmPR57Q16ADDEZ6 1X28mvv0z/WzClrH6LV6bxtnbQzPnZgUMw5Of5+mFl1RvGkZfYfeIF5fXfo6HpV5ETGCAo0wggKJ AgEBMEswRjESMBAGA1UEAwwJT2xlIFRyb2FuMQswCQYDVQQGEwJHQjEjMCEGCSqGSIb3DQEJARYU b3Ryb2FuQGVtcGxveWVlcy5vcmcCAQEwCQYFKw4DAhoFAKCCARcwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMTA5MDYyNDEyWjAjBgkqhkiG9w0BCQQxFgQUX1Xo dLYZACPMCHeGuQqh6faVRJMwWgYJKwYBBAGCNxAEMU0wSzBGMRIwEAYDVQQDDAlPbGUgVHJvYW4x CzAJBgNVBAYTAkdCMSMwIQYJKoZIhvcNAQkBFhRvdHJvYW5AZW1wbG95ZWVzLm9yZwIBATBcBgsq hkiG9w0BCRACCzFNoEswRjESMBAGA1UEAwwJT2xlIFRyb2FuMQswCQYDVQQGEwJHQjEjMCEGCSqG SIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcCAQEwDQYJKoZIhvcNAQEBBQAEggEAqWlBqyJt cTfWX5YpcsQbuZFq+cbRv6MSAQ+ij46zTiFHZUbgez71mE37z9i2aAG+/XPmun2lN8I47PCYtyRr 6GweUN8upHsudVAOWvayuW54J4Prbpko538mm1KzYfxuZPRXGu8SzxJeqXpkWSV8UllmgxUVy6A5 NAaF/GmOeHs89M/E7eSQjwj9h0DFqtlsA3NAKMhVcEjLHeCI8qfDRiKQPAUGflDFqK9qXJcnOVZS wQcawbcrhkA0dejzy0BoFoCHl+im1me31+MZdhM+ztUgxufEaHDvuDATTqpgbVfAf+F8t7Gwbx5O 8Z75EwWQ4crhg+lIy3nXWj2ARaerJAAAAAAAAA== --Apple-Mail-8-267780849-- From brian.e.carpenter@gmail.com Sun Nov 8 23:02:13 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E9F328C18A for ; Sun, 8 Nov 2009 23:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.129 X-Spam-Level: X-Spam-Status: No, score=-2.129 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPEzJK+bcIZu for ; Sun, 8 Nov 2009 23:02:09 -0800 (PST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 9D67F28C194 for ; Sun, 8 Nov 2009 23:02:09 -0800 (PST) Received: by ywh13 with SMTP id 13so3000269ywh.29 for ; Sun, 08 Nov 2009 23:02:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ilGb99dwgjOiSKgR2xtbSVww40xcEC296qSuLYe1zOE=; b=o12BgKR8HPTlOmVj+KdX7EMSQJBVaotwEBbK3CobnSVxhU1rl/3xDoxzfAQakJvhMf /2s7yX3GJjNDgihhqufw4nhOc76YOJmPsO3N+2FY9jcoEG6mmNgjzXSn6h+KcrlAypSP Sjj1HiLqTLGJJ6ivteJ/V3mU49oA1XNZkxlVY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=ViIMM17eGKCS8TzsRcUYlkeXbFX+zGDZkofuwwn+q4epr623y8yTjAC6NVdUUYrstR Z7qVL3XOOf4nNOezc1Pf/MDLJG6AL0LkESpOlAnTOjwPwyRHKEo+kukEJ0FweIXVr2FI YARro1BSbvYum/TK7c7b7WVR9bpLtfKfSBDQo= Received: by 10.151.29.8 with SMTP id g8mr12621306ybj.250.1257750150374; Sun, 08 Nov 2009 23:02:30 -0800 (PST) Received: from ?133.93.16.203? (host-16-203.meeting.ietf.org [133.93.16.203]) by mx.google.com with ESMTPS id 14sm1230496gxk.2.2009.11.08.23.02.28 (version=SSLv3 cipher=RC4-MD5); Sun, 08 Nov 2009 23:02:29 -0800 (PST) Message-ID: <4AF7BE7F.7060005@gmail.com> Date: Mon, 09 Nov 2009 20:02:23 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ole Troan References: <4AF76212.60903@gmail.com><01054E2B-BB74-4E27-A779-C86D35ECD08E@employees.org> <4AF798BD.4090009@gmail.com> <072F3245-6B81-4BC1-A850-0F100DEB702D@employees.org> <4AF7AD71.20708@gmail.com> <38340497-B409-41F0-BEE4-2BDCEABA9981@employees.org> In-Reply-To: <38340497-B409-41F0-BEE4-2BDCEABA9981@employees.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 07:02:13 -0000 I certainly agree this is nothing specific to 6RD. I also think that RFC4213 is correct (section 3.2.1., Static Tunnel MTU), but it seems as if at least some 6to4 implementations don't follow it (probably because they are old enough to have consulted RFC2893, or because they don't believe that the requirement applies). You also asked: > in which cases would you not know the v4MTU? I have no idea. Maybe some very strange implementation? Brian On 2009-11-09 19:24, Ole Troan wrote: >> Sure, (v4MTU - 20) is a reasonable formula once you >> know the value of v4MTU, as long as the result is at >> least 1280. But if you don't know v4MTU, you have to >> have *something* as the default, and I can't see anything >> better than 1280. > > re-reading RFC4213 section 3.2. > it does say that the tunnel MTU MUST be between 1280 and 1480 and it > SHOULD be 1280 by default. > this is a general problem and really shouldn't be solved in 6rd. if we > think the MTU discussion in 4213 is missing something we should update > that RFC instead. > > is the current text in the draft acceptable or should we say even less > and just reference 4213: > > "MTU and fragmentation issues for IPv6 in IPv4 tunnelling is discussed > in detail in section 3.2 of RFC4213 [RFC4213]. 6rd's scope is limited to > a service provider network. If the MTU is well-managed such that the > IPv4 MTU on the 6rd CE WAN interface is set so that no fragmentation > occurs within the boundary of the SP, then the IPv6 MTU should be set to > the IPv4 MTU minus the size of the encapsulating IPv4 header (20 bytes). > IPv4 Path MTU discovery MAY be used to adjust the MTU of the tunnel as > described in section 3.2.2 of RFC4213 [RFC4213] or the IPv6 tunnel MTU > may be explicitly configured." > > cheers, > Ole From Fred.L.Templin@boeing.com Sun Nov 8 23:02:36 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1200E28C18A for ; Sun, 8 Nov 2009 23:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwHjUmKoG7P1 for ; Sun, 8 Nov 2009 23:02:35 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 3279F28C19D for ; Sun, 8 Nov 2009 23:02:32 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id nA972nZB023232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 8 Nov 2009 23:02:50 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id nA972nJO009150; Mon, 9 Nov 2009 01:02:49 -0600 (CST) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id nA972nZg009147 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 9 Nov 2009 01:02:49 -0600 (CST) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Sun, 8 Nov 2009 23:02:48 -0800 From: "Templin, Fred L" To: james woodyatt , "softwires@ietf.org" Date: Sun, 8 Nov 2009 23:02:46 -0800 Thread-Topic: [Softwires] MTU issue for 6RD (and 6to4) Thread-Index: AcphAzQFDV587LIyQFKZ/J8GRt/AlAAA554g Message-ID: <12F4112206976147A34FEC0277597CCF27A5229F1E@XCH-NW-15V.nw.nos.boeing.com> References: <4AF76212.60903@gmail.com> <4AF798BD.4090009@gmail.com><"E4561B14EE2A3E4E9D478EBFB5416E1B29B367B5"@TK5 EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com><12F4112206976147A34FEC0277597CCF27A5229F1C@XCH-NW-15V.nw.nos.boeing.com> <236F77A8-F030-4602-A403-50055E28A286@apple.com> In-Reply-To: <236F77A8-F030-4602-A403-50055E28A286@apple.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 Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 07:02:36 -0000 James, > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On B= ehalf Of james woodyatt > Sent: Sunday, November 08, 2009 10:09 PM > To: softwires@ietf.org > Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) >=20 > On Nov 8, 2009, at 21:03 , Templin, Fred L wrote: >=20 > > [...] As far as I can see, there is no way to truly sweep the extra > > overhead for encapsulation under the carpet without invoking > > fragmentation and reassembly within the tunnel. >=20 > I'm confused. It was my impression that IPv4 showed us how expecting > the network to handle fragmentation and reassembly on a hop-by-hop > basis wasn't such a good idea after all, and that we lifted > fragmentation and reassembly up to the level of destination option > processing precisely to simplify the forwarding path in routers. Am I > missing something? Yes, you are missing something that I didn't explain well; I do not want outer IP fragmentation nor inner IP fragmentation. I am referring to a mid-layer segmentation and reassembly capability that is neither/nor. That is something that can be coordinated btw tunnel endpoints without incurring the harmful aspects of IP fragmentation and reassembly. > I mean, when I do the back of the envelope calculations about > overhead, I don't see numbers that make a compelling argument for > unburdening hosts from the need to do path MTU discovery, especially > when the first-mile IPv6 link is tunneled over IPv4. You're always > going to have an IPv4 header in every ~1500 octet packet. After that, > you have two alternatives: Its not necessarily the first-mile IPv6 link and oftentimes will not be. There may be an arbitrarily complex IPv6 network stacked up behind the CPE router, for example. When hosts have to constantly participate=20 in path MTU discovery, there will always be packet loss and there will always be round-trip delays before the host can reduce its packet size and try again. It would be good to avoid this if possible. =20 > A) the IPv6 host has discovered the path MTU including the IPv4 > encapsulation, and there is an IPv6 header in every IPv4 packet; >=20 > B) the IPv6 host has been saved from learning the smaller path MTU > for the IPv4 tunnel and learns instead the larger path MTU, which is > probably not going to be more than 1500 kB for at least as long as 6RD > is expected to live, so here there are two subcases: Why do you say no more than 1500? As long as the tunnel egress is willing to reassemble larger (e.g., 9K) then the ingress can accommodate the larger packet size using segmentation and reassembly even if the physical links on the path only configure smaller MTUs (e.g., 1500). > 1) the IPv6 packet is small enough that it doesn't need > fragmentation, e.g. empty TCP ACK packets, in which case there is an > IPv6 header in the IPv4 packet, just like the first alternative; >=20 > 2) the IPv6 packet is larger than the tunnel MTU, e.g. a full- > size TCP segment for the IPv6 path MTU, and so there are two or more > IPv4 packets and the IPv6 header is amortized between them. If you mean the IPv6 header is amortized due to segmentation and reassembly between the tunnel endpoints, then that is good and I agree. > If the IPv4 path MTU between the 6RD CPE router and the 6RD relay is > the typical 1500 octets, then you don't win anything by doing fragment > reassembly at the tunnel endpoints unless the IPv6 path MTU is larger > than 2960 octets. That's not happening any time soon for basically > anyone in the intended user community for 6RD. As explained above, with segmentation and reassembly the tunnel MTU is really independent of the MTUs of the underlying links on the path. All that matters is the size the egress is willing to reassemble, so we can happily do 9KB across the tunnel even if the links in the path only support 1500. > It's going to be a long time before residential subscriber networks > can be reasonably expected to support a link MTU large enough for this > path MTU business to be important. People keep deploying heterogenous > bridges between various link layers with different native MTU, e.g. Wi- > Fi with 2304 and/or 4000 depending, Gig-E with 9000. Sadly, IPv6 > neighbor discovery doesn't cope well with jumbo frames on such > networks, so everyone uses 1500 octets for the same historical reasons > we've always had. They're not going away. Residential users don't need to move to larger MTUs before this becomes important; the benefits are there even at 1500. What matters is that the tunnel not unnecessarily reduce the size the hosts see on their native links regardless of what that size is.=20 > Until IPv6 neighbor discovery can cope with the issue of path MTU > discovery on local links [*], I'm not getting excited about the > encapsulation overhead for hosts behind 6RD gateways. Huh? This is all about supporting multiple MTUs on the same link. Using SEAL, multi-MTU handling occurs at a layer below IPv6 neighbor discovery, and ND never even needs to get involved. Multi-MTUs on the same link are to be expected and are naturally accommodated by SEAL. Fred fred.l.templin@boeing.com =20 > -- > james woodyatt > member of technical staff, communications engineering >=20 > [*] c.f. >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From ipng@69706e6720323030352d30312d31340a.nosense.org Mon Nov 9 01:48:02 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E904C3A6A03 for ; Mon, 9 Nov 2009 01:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VkCtDFl3pnj for ; Mon, 9 Nov 2009 01:48:02 -0800 (PST) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by core3.amsl.com (Postfix) with ESMTP id 9DDC53A693E for ; Mon, 9 Nov 2009 01:48:01 -0800 (PST) Received: from 114-30-105-152.ip.adam.com.au ([114.30.105.152] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1N7QrA-00084u-VP; Mon, 09 Nov 2009 20:18:17 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 32DB4492E3; Mon, 9 Nov 2009 20:18:15 +1030 (CST) Date: Mon, 9 Nov 2009 20:18:12 +1030 From: Mark Smith To: "Templin, Fred L" Message-ID: <20091109201812.7d762cbc@opy.nosense.org> In-Reply-To: <12F4112206976147A34FEC0277597CCF27A5229F0B@XCH-NW-15V.nw.nos.boeing.com> References: <4AF7004A.8080508@cisco.com> <12F41122069761 47A34FEC0277597CCF27A5229F07@XCH-NW-15V.nw.nos.boeing.com> <12F4112206976147A34FEC0277597CCF27A5229F0B@XCH-NW-15V.nw.nos.boeing.com> X-Mailer: Claws Mail 3.7.3 (GTK+ 2.18.3; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "softwires@ietf.org" Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 09:48:03 -0000 Hi, A few questions - On Sun, 8 Nov 2009 14:44:03 -0800 "Templin, Fred L" wrote: > > > > -----Original Message----- > > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of james woodyatt > > Sent: Sunday, November 08, 2009 1:39 PM > > To: softwires@ietf.org > > Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt > > > > On Nov 8, 2009, at 12:31 , Templin, Fred L wrote: > > > > > > - Use of anycast does not allow the CPE router to select > > > between multiple available exit routers. Instead, exit > > > router selection is through IPv4 routing in the ISP > > > network, which is non-deterministic from the CPE router's > > > point of view. > > > > Having a fair amount of experience with implementing residential CPE > > dual-stack IPv4/IPv6 gateway routers, I hope I have some authority > > with which to declare this as a FEATURE and not a problem. Not having > > to burden the residential user with having to choose an IPv6 relay > > endpoint on their own, when this is really something the service > > provider should be handling transparently to the subscriber, seems > > like a desirable quality in a protocol for our purposes here. > > You may have missed an aspect of my point, or I may not have > expressed it fully. When the CPE router discovers addresses > of ISP border routers and performs neighbor discovery > exchanges with them, the ISP is still the one that informs > the CPE routers of best choices. So, this is not a "burden" > on the CPE router, and the ISP still has the means to > engineer the traffic. It simply gives the CPE router the > means to make the best choices based on what the ISP > tells it. > If it's the IPv4 layer/BR address being talked about, I'm curious as to what mechanism is to be used to express the IPv4 Border Router address preferences, how their availability is to be tracked, and how the preferences are to be updated, if necessary? The only IPv4 mechanism I'm aware of that can achieve those sorts of functions are fully fledged routing protocols (as "fully fledged" as RIP might be). If the BR IPv4 address or addresses were somehow encoded in IPv6 link local addresses, then IPv6 RA router preferences might be able to be shoehorned into indicating BR IPv4 preference. > > > - Tunnel path MTU is left to chance of the ISP operator's > > > link deployment practices. Under-provisioned or > > > mis-configured links will show up as sources of IP > > > fragmentation. > > > > I suppose it would help if the specification made explicit the need > > for IPv4 path MTU discovery to work, i.e. there must be a clear path > > for ICMP4 errors to pass on the same path as the proto 41 packets, and > > both tunnel endpoints need to cope with the path MTU discovery problem > > appropriately. > > The only way to ensure this is to ensure that there will > be no ICMP filtering and to ensure that there can be no > source address spoofing inside of the ISP network. Then, > if you want to leverage IPv4 path MTU discovery instead > of defer to IPv4 fragmentation the CPE routers will need > to maintain a neighbor cache with per-neighbor MTU values, > which adds state to an otherwise stateless model. > > > > - Reducing tunnel MTU to account for the encapsulation header > > > (e.g., to 1480) ensures that hosts behind the CPE router > > > will see unnecessarily excessive path MTU interactions. > > > > Depends on your expectations for the necessity of path MTU discovery. > > I don't see how there is a problem: the CPE router and the 6RD relay > > negotiate the path MTU shortly after the CPE router obtains its 6RD > > configuration, and one would expect the path MTU to be relatively > > stable over time in a real-world deployment. > > When applications start up on hosts that connect to a > 1500 link, they will often want to send 1500 packets. > Even if the CPE router were to cache smaller per > neighbor MTUs (state), the hosts will often be > disappointed to see their 1500 packets dropped and > need to ratchet down their path MTU estimates. But > for hosts, path MTU is per-destination (not per- > neighbor) so they will try again with 1500s for each > distinct destination even if they keep getting denied > by the CPE. This is the way path MTU discovery works, > but the optimum condition is to not invoke path MTU > discovery at all if possible. > > > > - No means for migration to larger MTUs (e.g. 9KB) as links > > > in the ISP network incrementally deploy larger MTUs. > > > > The migration path is to go native IPv6, if you ask me. Again, I view > > this as a feature: it provides for a natural sunset provision. > > This is obviously a matter for debate. Native IPv6 at > the edges is a yes for sure; IPv6 in the middle is a > matter for open debate since a well-deployed tunneling > scenario may make it unnecessary. If 9K MTUs are migrated to, hiding the tunnel overhead, then the CPE could stop announcing an RA MTU that is smaller than the CPE's downstream LAN MTU. Regards, Mark. From remi.despres@free.fr Mon Nov 9 01:52:44 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3DB83A6876 for ; Mon, 9 Nov 2009 01:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQN9serdvSfU for ; Mon, 9 Nov 2009 01:52:44 -0800 (PST) Received: from smtp20.orange.fr (smtp20.orange.fr [193.252.22.31]) by core3.amsl.com (Postfix) with ESMTP id B46843A6903 for ; Mon, 9 Nov 2009 01:52:43 -0800 (PST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2019.orange.fr (SMTP Server) with ESMTP id F3F3C20007C2; Mon, 9 Nov 2009 10:53:04 +0100 (CET) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2019.orange.fr (SMTP Server) with ESMTP id E20642000F68; Mon, 9 Nov 2009 10:53:04 +0100 (CET) Received: from [133.93.128.96] (host-128-96.meeting.ietf.org [133.93.128.96]) by mwinf2019.orange.fr (SMTP Server) with ESMTP id 6D5E020007C2; Mon, 9 Nov 2009 10:53:01 +0100 (CET) X-ME-UUID: 20091109095301448.6D5E020007C2@mwinf2019.orange.fr In-Reply-To: <38340497-B409-41F0-BEE4-2BDCEABA9981@employees.org> References: <4AF76212.60903@gmail.com><01054E2B-BB74-4E27-A779-C86D35ECD08E@employees.org> <4AF798BD.4090009@gmail.com> <072F3245-6B81-4BC1-A850-0F100DEB702D@employees.org> <4AF7AD71.20708@gmail.com> <38340497-B409-41F0-BEE4-2BDCEABA9981@employees.org> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <8AF8690C-E511-4BA3-946C-9D1985D04D92@free.fr> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Date: Mon, 9 Nov 2009 18:52:57 +0900 To: Ole Troan X-Mailer: Apple Mail (2.753.1) Cc: softwires@ietf.org Subject: Re: [Softwires] MTU issue for 6RD (and 6to4) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 09:52:44 -0000 Le 9 nov. 09 =E0 15:24, Ole Troan a =E9crit : >> Sure, (v4MTU - 20) is a reasonable formula once you >> know the value of v4MTU, as long as the result is at >> least 1280. But if you don't know v4MTU, you have to >> have *something* as the default, and I can't see anything >> better than 1280. > > re-reading RFC4213 section 3.2. > it does say that the tunnel MTU MUST be between 1280 and 1480 and =20 > it SHOULD be 1280 by default. > this is a general problem and really shouldn't be solved in 6rd. if =20= > we think the MTU discussion in 4213 is missing something we should =20 > update that RFC instead. > > is the current text in the draft acceptable or should we say even =20 > less and just reference 4213: > > "MTU and fragmentation issues for IPv6 in IPv4 tunnelling is =20 > discussed in detail in section 3.2 of RFC4213 [RFC4213]. 6rd's =20 > scope is limited to a service provider network. If the MTU is well-=20 > managed such that the IPv4 MTU on the 6rd CE WAN interface is set =20 > so that no fragmentation occurs within the boundary of the SP, then =20= > the IPv6 MTU should be set to the IPv4 MTU minus the size of the =20 > encapsulating IPv4 header (20 bytes). IPv4 Path MTU discovery MAY =20 > be used to adjust the MTU of the tunnel as described in section =20 > 3.2.2 of RFC4213 [RFC4213] or the IPv6 tunnel MTU may be explicitly =20= > configured." After the second sentence, what about something in the following flavor: "SPs that use 6rd MUST ensure that IPv4 packets that encapsulate IPv6 =20= packets are not fragmented within each part of their network to which =20= they have assigned a 6rd SP prefix. For this, each such 6rd network part MUST have for all its possible =20 paths an IPv4 MTU of at least 1300 octets, i.e. 1280, the minimum =20 IPv6 MTU, plus 20 octets, the length of the encapsulating header. If a SP can guarantee, for a given a 6rd CPE or relay that the MTU of =20= all its paths betwen 6rd CPEs and relays is some value M larger than =20 1300 octets, then this node MAY set its IPv6 MTU to M - 20 octets. =20 For example, if a 6rd network part has MTUs of at least 1500 octets =20 everywhere, each of its 6rd CPE or relay may individually set its =20 accepted IPv6 MTU to 1480 octets." In my understanding, it covers what has been discussed, and expresses =20= more rigorously. The first paragraph is essential. The two others are =20= just clarifications. ` > > cheers, > Ole_______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From Fred.L.Templin@boeing.com Mon Nov 9 02:52:37 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9149428C0D6 for ; Mon, 9 Nov 2009 02:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NNvYsf4ZaUw for ; Mon, 9 Nov 2009 02:52:36 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 673A03A68A5 for ; Mon, 9 Nov 2009 02:52:36 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id nA9Aqt6R011600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Nov 2009 04:52:56 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id nA9Aqtgt006247; Mon, 9 Nov 2009 02:52:55 -0800 (PST) Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id nA9Aqt5h006244 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 9 Nov 2009 02:52:55 -0800 (PST) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Mon, 9 Nov 2009 02:52:55 -0800 From: "Templin, Fred L" To: Mark Smith Date: Mon, 9 Nov 2009 02:52:51 -0800 Thread-Topic: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt Thread-Index: AcphIck7EjkQnVENSmqzb0X7tSD0pQAB7vEg Message-ID: <12F4112206976147A34FEC0277597CCF27A5229F20@XCH-NW-15V.nw.nos.boeing.com> References: <4AF7004A.8080508@cisco.com><12F41122069761 47A34FEC0277597CCF27A5229F07@XCH-NW-15V.nw.nos.boeing.com><12F4112206976147A34FEC0277597CCF27A5229F0B@XCH-NW-15V.nw.nos.boeing.com> <20091109201812.7d762cbc@opy.nosense.org> In-Reply-To: <20091109201812.7d762cbc@opy.nosense.org> 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: "softwires@ietf.org" Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 10:52:37 -0000 Mark - brief answer below: > -----Original Message----- > From: Mark Smith [mailto:ipng@69706e6720323030352d30312d31340a.nosense.or= g] > Sent: Monday, November 09, 2009 1:48 AM > To: Templin, Fred L > Cc: james woodyatt; softwires@ietf.org > Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt >=20 > Hi, >=20 > A few questions - >=20 > On Sun, 8 Nov 2009 14:44:03 -0800 > "Templin, Fred L" wrote: >=20 > > > > > > > -----Original Message----- > > > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] = On Behalf Of james woodyatt > > > Sent: Sunday, November 08, 2009 1:39 PM > > > To: softwires@ietf.org > > > Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt > > > > > > On Nov 8, 2009, at 12:31 , Templin, Fred L wrote: > > > > >=20 > >=20 > > > > - Use of anycast does not allow the CPE router to select > > > > between multiple available exit routers. Instead, exit > > > > router selection is through IPv4 routing in the ISP > > > > network, which is non-deterministic from the CPE router's > > > > point of view. > > > > > > Having a fair amount of experience with implementing residential CPE > > > dual-stack IPv4/IPv6 gateway routers, I hope I have some authority > > > with which to declare this as a FEATURE and not a problem. Not having > > > to burden the residential user with having to choose an IPv6 relay > > > endpoint on their own, when this is really something the service > > > provider should be handling transparently to the subscriber, seems > > > like a desirable quality in a protocol for our purposes here. > > > > You may have missed an aspect of my point, or I may not have > > expressed it fully. When the CPE router discovers addresses > > of ISP border routers and performs neighbor discovery > > exchanges with them, the ISP is still the one that informs > > the CPE routers of best choices. So, this is not a "burden" > > on the CPE router, and the ISP still has the means to > > engineer the traffic. It simply gives the CPE router the > > means to make the best choices based on what the ISP > > tells it. > > >=20 > If it's the IPv4 layer/BR address being talked about, I'm curious as to > what mechanism is to be used to express the IPv4 Border Router address > preferences, how their availability is to be tracked, and how the > preferences are to be updated, if necessary? The only IPv4 mechanism > I'm aware of that can achieve those sorts of functions are fully > fledged routing protocols (as "fully fledged" as RIP might be). > > If the BR IPv4 address or addresses were somehow encoded in IPv6 link > local addresses, then IPv6 RA router preferences might be able to be > shoehorned into indicating BR IPv4 preference. ISATAP provides just such a mechanism, so I think you answered your own question. Fred fred.l.templin@boeing.com > > >=20 > > > > - Tunnel path MTU is left to chance of the ISP operator's > > > > link deployment practices. Under-provisioned or > > > > mis-configured links will show up as sources of IP > > > > fragmentation. > > > > > > I suppose it would help if the specification made explicit the need > > > for IPv4 path MTU discovery to work, i.e. there must be a clear path > > > for ICMP4 errors to pass on the same path as the proto 41 packets, an= d > > > both tunnel endpoints need to cope with the path MTU discovery proble= m > > > appropriately. > > > > The only way to ensure this is to ensure that there will > > be no ICMP filtering and to ensure that there can be no > > source address spoofing inside of the ISP network. Then, > > if you want to leverage IPv4 path MTU discovery instead > > of defer to IPv4 fragmentation the CPE routers will need > > to maintain a neighbor cache with per-neighbor MTU values, > > which adds state to an otherwise stateless model. > > > > > > - Reducing tunnel MTU to account for the encapsulation header > > > > (e.g., to 1480) ensures that hosts behind the CPE router > > > > will see unnecessarily excessive path MTU interactions. > > > > > > Depends on your expectations for the necessity of path MTU discovery. > > > I don't see how there is a problem: the CPE router and the 6RD relay > > > negotiate the path MTU shortly after the CPE router obtains its 6RD > > > configuration, and one would expect the path MTU to be relatively > > > stable over time in a real-world deployment. > > > > When applications start up on hosts that connect to a > > 1500 link, they will often want to send 1500 packets. > > Even if the CPE router were to cache smaller per > > neighbor MTUs (state), the hosts will often be > > disappointed to see their 1500 packets dropped and > > need to ratchet down their path MTU estimates. But > > for hosts, path MTU is per-destination (not per- > > neighbor) so they will try again with 1500s for each > > distinct destination even if they keep getting denied > > by the CPE. This is the way path MTU discovery works, > > but the optimum condition is to not invoke path MTU > > discovery at all if possible. > > > > > > - No means for migration to larger MTUs (e.g. 9KB) as links > > > > in the ISP network incrementally deploy larger MTUs. > > > > > > The migration path is to go native IPv6, if you ask me. Again, I vie= w > > > this as a feature: it provides for a natural sunset provision. > > > > This is obviously a matter for debate. Native IPv6 at > > the edges is a yes for sure; IPv6 in the middle is a > > matter for open debate since a well-deployed tunneling > > scenario may make it unnecessary. >=20 > If 9K MTUs are migrated to, hiding the tunnel overhead, then the CPE > could stop announcing an RA MTU that is smaller than the CPE's > downstream LAN MTU. >=20 > Regards, > Mark. From dthaler@microsoft.com Mon Nov 9 03:24:56 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15E7B28C209 for ; Mon, 9 Nov 2009 03:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.557 X-Spam-Level: X-Spam-Status: No, score=-10.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opmB8isuVMkj for ; Mon, 9 Nov 2009 03:24:55 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 208E43A6857 for ; Mon, 9 Nov 2009 03:24:55 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 9 Nov 2009 03:25:37 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server id 14.0.639.20; Mon, 9 Nov 2009 03:25:20 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Mon, 9 Nov 2009 03:25:22 -0800 From: Dave Thaler To: Ole Troan , "Templin, Fred L" Thread-Topic: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt Thread-Index: AQHKYJk/oFPStRqnO0yZ+yxr6I/NWZEtKdsAgAAS24CAABIkgIAALpAAgAAcrbA= Date: Mon, 9 Nov 2009 11:25:18 +0000 Message-ID: References: <4AF7004A.8080508@cisco.com><12F41122069761 47A34FEC0277597CCF27A5229F07@XCH-NW-15V.nw.nos.boeing.com> <12F4112206976147A34FEC0277597CCF27A5229F0B@XCH-NW-15V.nw.nos.boeing.com> <927E0EF7-9D25-4025-940A-6BF326C7233A@employees.org> In-Reply-To: <927E0EF7-9D25-4025-940A-6BF326C7233A@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 11:24:56 -0000 > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Ole Troan > Sent: Monday, November 09, 2009 10:31 AM > To: Templin, Fred L > Cc: softwires@ietf.org > Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt >=20 > Fred, >=20 > >>> - Use of anycast does not allow the CPE router to select between > >>> multiple available exit routers. Instead, exit router selection is > >>> through IPv4 routing in the ISP network, which is non-deterministic > >>> from the CPE router's point of view. > >> > >> Having a fair amount of experience with implementing residential CPE > >> dual-stack IPv4/IPv6 gateway routers, I hope I have some authority > >> with which to declare this as a FEATURE and not a problem. Not > having > >> to burden the residential user with having to choose an IPv6 relay > >> endpoint on their own, when this is really something the service > >> provider should be handling transparently to the subscriber, seems > >> like a desirable quality in a protocol for our purposes here. > > > > You may have missed an aspect of my point, or I may not have > expressed > > it fully. When the CPE router discovers addresses of ISP border > > routers and performs neighbor discovery exchanges with them, the ISP > > is still the one that informs the CPE routers of best choices. So, > > this is not a "burden" > > on the CPE router, and the ISP still has the means to engineer the > > traffic. It simply gives the CPE router the means to make the best > > choices based on what the ISP tells it. > > > >>> - Non-use of IPv6 ND does not allow for dynamic configuration of > >>> lifetimes for default and more-specific routes. Also, no NUD > >>> mechanism. > >> > >> What? Seriously, I don't understand the concern behind this > comment. > >> Could you elaborate? > > > > Like when an RA advertises a PIO or an RIO they have lifetimes that > > the CPE router learns. These lifetimes influence router selection and > > router reachability in a way that is not available without them. >=20 > we're talking about a router to router link here.=20 No we're not. We're talking about a link that can have _both routers and hosts_ on it. From Mark's email earlier in this thread responding=20 to me: > > 1) The draft says a CE must have 1 or more LAN interface. 6to4 > > can be used even when you don't have a LAN interface (up). > > > > Remove this limitation, as it's not necessary and doesn't affect=20 > > anything else. > > Yes, of course, the CE could always be a host. > you appear to be > suggesting to use ND as a routing protocol. I don't think that is > specified anywhere. ND is not a routing protocol. RD is not a routing protocol per se either, but it can distribute routing information to hosts. See RFC 4191 (which is optional) for more information. NUD is not a routing protocol, but it does allow nodes to obtain liveness information about another node on the link. And we have existing RFCs that say how hosts select among multiple routers on link. RFC 4861 talks about using liveness information (see 5.2). RFC 4311 (which is optional) talks about how a host can use multiple default gateways simultaneously. However nothing _requires_ the host to do any of the above, and a host could simply take the first address and ignore all the rest. So what James=20 wants (simplicity of implementation) is not precluded in any way by passing a list. However, not being capable of having a list precludes how 6to4 is used today in some environments,=20 even in the same scenario 6rd is designed for. Passing a list doesn't require defining anything new, nor does it require any complex implementation on hosts or routers. -Dave >=20 > for more specific routes you need to run a routing protocol between the > BRs and the CEs. which routing protocol do you use? do you need to > provide a way of automatically provisioning the routing protocol? >=20 > for the multiple BR problem, this can also be solves with a dynamic > routing protocol or one could use BFD. >=20 > again, we wanted 6rd to be stateless. and possibly we were too lazy to > try to solve all these issues... :-) >=20 > cheers, > Ole From ichiroumakino@gmail.com Mon Nov 9 18:36:58 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 004F43A68AB for ; Mon, 9 Nov 2009 18:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RI5cIPgZX-r0 for ; Mon, 9 Nov 2009 18:36:57 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id E8B063A6892 for ; Mon, 9 Nov 2009 18:36:56 -0800 (PST) Received: by yxe30 with SMTP id 30so3934921yxe.29 for ; Mon, 09 Nov 2009 18:37:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=6Pc6FRMjMSui3wAwKxeOpctMPcGXW/SAnGhTu6lSgwg=; b=srp9dD2YWbAP5sE31s9vVQiibALGNFo+s4UGwWFX/2PNoqi+dXjfswbYYn06MEUCx0 6tmpR1onrhu4rMiT3LJ5ddbD5debozuvhPKSZom2uOZVd80yzBnnsr+FAO/Ov4ExmZlS x/AeIZkHtMArlm3WLChKfyJTjZDayo4REy9eo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type:mime-version :subject:date:references:x-mailer; b=uSZJSexXNE91Pi/1YaPMKDR0WdgpE+rt4P9BgYdI5xO8ZN1gDrrWiuIFBCGDiuv4o9 XRycW6iMd+cY/8XWuRXnMe2/QpHNbE/BfdEDJ0VV+TW31kWmUltCTsWaXTLy4oJNkv5Y kwLfhowolE3kFTej9t14uWrktHrVK/Qdei8EE= Received: by 10.150.172.13 with SMTP id u13mr14855803ybe.104.1257820640843; Mon, 09 Nov 2009 18:37:20 -0800 (PST) Received: from host-24-177.meeting.ietf.org (64-104-46-217.cisco.com [64.104.46.217]) by mx.google.com with ESMTPS id 7sm121439ywc.36.2009.11.09.18.37.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 09 Nov 2009 18:37:19 -0800 (PST) Sender: Ole Troan Message-Id: <7E892C15-47CC-41DD-9A90-56D9AC7DE651@employees.org> From: Ole Troan To: Dave Thaler In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-9-340560676; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 10 Nov 2009 11:37:11 +0900 References: <4AF7004A.8080508@cisco.com><12F41122069761 47A34FEC0277597CCF27A5229F07@XCH-NW-15V.nw.nos.boeing.com> <12F4112206976147A34FEC0277597CCF27A5229F0B@XCH-NW-15V.nw.nos.boeing.com> <927E0EF7-9D25-4025-940A-6BF326C7233A@employees.org> X-Mailer: Apple Mail (2.936) Cc: "softwires@ietf.org" , "Templin, Fred L" Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 02:36:58 -0000 --Apple-Mail-9-340560676 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dave, [...] >>> Like when an RA advertises a PIO or an RIO they have lifetimes that >>> the CPE router learns. These lifetimes influence router selection >>> and >>> router reachability in a way that is not available without them. >> >> we're talking about a router to router link here. > > No we're not. We're talking about a link that can have _both routers > and hosts_ on it. From Mark's email earlier in this thread responding > to me: I don't see any reason why one couldn't implement 6rd in a host. the base specification does specify this only for routers though. just like rfc3056 does. > >>> 1) The draft says a CE must have 1 or more LAN interface. 6to4 >>> can be used even when you don't have a LAN interface (up). >>> >>> Remove this limitation, as it's not necessary and doesn't affect >>> anything else. >> >> Yes, of course, the CE could always be a host. > > > > >> you appear to be >> suggesting to use ND as a routing protocol. I don't think that is >> specified anywhere. > > ND is not a routing protocol. RD is not a routing protocol per se > either, but it can distribute routing information to hosts. > See RFC 4191 (which is optional) for more information. > NUD is not a routing protocol, but it does allow nodes to obtain > liveness information about another node on the link. > > And we have existing RFCs that say how hosts select among multiple > routers on link. RFC 4861 talks about using liveness information > (see 5.2). RFC 4311 (which is optional) talks about how a host > can use multiple default gateways simultaneously. However nothing > _requires_ the host to do any of the above, and a host could simply > take the first address and ignore all the rest. So what James > wants (simplicity of implementation) is not precluded in any way > by passing a list. However, not being capable of having a list > precludes how 6to4 is used today in some environments, > even in the same scenario 6rd is designed for. Passing a list > doesn't require defining anything new, nor does it require > any complex implementation on hosts or routers. we want as far as possible for implementors to be able to reuse existing 6to4 code. 6to4 doesn't specify how multiple relays are used either. rfc3068 specifies how a single anycast address is used to reach a relay. 6rd can be provisioned in multiple ways and there is nothing stopping one from deploying with multiple relays. we _could_ add a list of relays in the DHCP option in 6rd. my only concern is that would we then have to add text to describe how one should switch between them? e.g NUD or BFD to detect liveness... this would be new code in comparison to a vanilla 6to4 implementation. cheers, Ole --Apple-Mail-9-340560676 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDVDCCA1Aw ggI4oAMCAQICAQEwCwYJKoZIhvcNAQEFMEYxEjAQBgNVBAMMCU9sZSBUcm9hbjELMAkGA1UEBhMC R0IxIzAhBgkqhkiG9w0BCQEWFG90cm9hbkBlbXBsb3llZXMub3JnMB4XDTA4MDUwNzAwMDAxMVoX DTA5MDUwNzAwMDAxMVowRjESMBAGA1UEAwwJT2xlIFRyb2FuMQswCQYDVQQGEwJHQjEjMCEGCSqG SIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCqhwqYY9JywwGzpwmC3kFCf8/TzdM3AHZAvr1Z2cei/PbCaAqTBQ1kiwFpNxAgqcofM2LP xKq3EhHfUs4oukBOYqhrlmJtAclNBf8ctZDoWnz3ETsCYb77bMvdMRJqoJr1+YpySGl/leDqdIq8 ee0LYj0DcOQA9YFPQw7XUA107tyozy6+F7LfAzx10j2uuyfyxp55dVMfcVe8ROAv1c4LcUUCtgqp SceHH0WMuXf2j0TdAsPQ/Hd1Ak6rOx8lCVwJ7b0AKbbCVIIBlqGyVlXW6bcjwmxGGjVDgY/5CIAg KC44/6BsN/QDXnHwlU2pJlJM4mvgy1CMjy+7Y/ldvJkVAgMBAAGjSzBJMA4GA1UdDwEB/wQEAwIH gDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAfBgNVHREEGDAWgRRvdHJvYW5AZW1wbG95ZWVzLm9y ZzANBgkqhkiG9w0BAQUFAAOCAQEAWMQKZJ9OSQP2BIEjq47jG6PxfzcUhmgLHGIn7X1E6SAjmjma UmA4K3V3Ydxksb+JOXshfu6YgxCzfhdcV/wh8WA0ld2sxueRpdG8hmxQyI5sRFNvPbZdplCA105H 2UwjVVNVIQu6MAa3siYUB4g7eFGEjIqcXO80wa+xgKbnflbPFq0iXKwjQn9jbho3zlbsZhIV3yNp sOVMwdqyRaUrXKB6ycOFEbeNTVfFok+1Xx5bbk4aZz1WlbVkhUlXuSMxZFgD7PmPR57Q16ADDEZ6 1X28mvv0z/WzClrH6LV6bxtnbQzPnZgUMw5Of5+mFl1RvGkZfYfeIF5fXfo6HpV5ETGCAo0wggKJ AgEBMEswRjESMBAGA1UEAwwJT2xlIFRyb2FuMQswCQYDVQQGEwJHQjEjMCEGCSqGSIb3DQEJARYU b3Ryb2FuQGVtcGxveWVlcy5vcmcCAQEwCQYFKw4DAhoFAKCCARcwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMTEwMDIzNzExWjAjBgkqhkiG9w0BCQQxFgQUS5R/ TuuTMZAySQuzogT+DPkU08YwWgYJKwYBBAGCNxAEMU0wSzBGMRIwEAYDVQQDDAlPbGUgVHJvYW4x CzAJBgNVBAYTAkdCMSMwIQYJKoZIhvcNAQkBFhRvdHJvYW5AZW1wbG95ZWVzLm9yZwIBATBcBgsq hkiG9w0BCRACCzFNoEswRjESMBAGA1UEAwwJT2xlIFRyb2FuMQswCQYDVQQGEwJHQjEjMCEGCSqG SIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcCAQEwDQYJKoZIhvcNAQEBBQAEggEAJ8a2CZ8y IUdZydY+Pgvem+nZRp0G47KN2mHpKMi1GCatCFKlbLH7TPuuZWA+XuDi8P3j+Lh2/w4I2hVdc4fo q/fpoQkY2p1UnzyzTUyCZ02JfahGZqI4azxPmp8x9V3rI9XJXpHp9Jkt/FTAncnGa6O0U69vVLJI gzCK9AP/Kz20dHSJY2Z8pC2T0I9YZjY7PRt7j/Qk7kMvtrwaiWuGsJ+cA/jQ2ehDmv+6vY78yXJT AvtLMEgUXj9JuH1/B+NbaH19W+jeQVDBmkhTqSc1NFjs0BibEGbwQGjVFUQ1+VQ9olxoi1Zghzbw IFQ1SiMZR8JS3ZL/PBz8wd/2DWFT2QAAAAAAAA== --Apple-Mail-9-340560676-- From dthaler@microsoft.com Tue Nov 10 02:30:01 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33C4928C104 for ; Tue, 10 Nov 2009 02:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PU0kiCOHykvt for ; Tue, 10 Nov 2009 02:30:00 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 674A83A63EC for ; Tue, 10 Nov 2009 02:30:00 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 10 Nov 2009 02:30:27 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server id 14.0.639.20; Tue, 10 Nov 2009 02:30:27 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Tue, 10 Nov 2009 02:30:27 -0800 From: Dave Thaler To: Ole Troan Thread-Topic: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt Thread-Index: AQHKYJk/oFPStRqnO0yZ+yxr6I/NWZEtKdsAgAAS24CAABIkgIAALpAAgAAcrbCAAYg7gP//+nGw Date: Tue, 10 Nov 2009 10:30:25 +0000 Message-ID: References: <4AF7004A.8080508@cisco.com><12F41122069761 47A34FEC0277597CCF27A5229F07@XCH-NW-15V.nw.nos.boeing.com> In-Reply-To: <7E892C15-47CC-41DD-9A90-56D9AC7DE651@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 10:30:01 -0000 Ole Troan wrote: > >>> Like when an RA advertises a PIO or an RIO they have lifetimes that > >>> the CPE router learns. These lifetimes influence router selection > >>> and > >>> router reachability in a way that is not available without them. > >> > >> we're talking about a router to router link here. > > > > No we're not. We're talking about a link that can have _both routers > > and hosts_ on it. From Mark's email earlier in this thread > responding > > to me: >=20 > I don't see any reason why one couldn't implement 6rd in a host. the > base specification does specify this only for routers though. just > like rfc3056 does. In hindsight, I think RFC 3056 should have mentioned the host case too. I disagree that 3056 omitting it means we should omit it now too. Omitting it just leads people to believe "we're talking about a router to router link here" as you've illustrated :-) [...] > we want as far as possible for implementors to be able to reuse > existing 6to4 code. 6to4 doesn't specify how multiple relays are used > either. rfc3068 specifies how a single anycast address is used to > reach a relay. >=20 > 6rd can be provisioned in multiple ways and there is nothing stopping > one from deploying with multiple relays. we _could_ add a list of > relays in the DHCP option in 6rd. my only concern is that would we > then have to add text to describe how one should switch between them? [...] =09 No. However, someone pointed out to me that unlike a DHCPv6 option,=20 a DHCPv4 option can occur multiple times. Assuming that's correct,=20 you can already get a list, in which case this particular concern of mine goes away. However, while we're on the topic of "reuse existing 6to4 code", it probabl= y would have been better to call 6rd a "6to4 extension for private relays", rather than a new protocol name since we have enough names to teach people already and people just think "we have too many". If you actually=20 configured a 6RD node with a 6rd SP prefix of 2002::/16, you ought to=20 get behavior identical to 6to4 behavior. So our task would just be=20 updating 6to4 to allow for a configured prefix, and perhaps anything=20 else required. -Dave From brian.e.carpenter@gmail.com Tue Nov 10 04:40:15 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F26A33A6AAE for ; Tue, 10 Nov 2009 04:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxxh8lwmuof0 for ; Tue, 10 Nov 2009 04:40:14 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 1F4563A6AAC for ; Tue, 10 Nov 2009 04:40:14 -0800 (PST) Received: by yxe30 with SMTP id 30so4285921yxe.29 for ; Tue, 10 Nov 2009 04:40:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=aVlixVKkrDPPI1cQ6wFzJS8PEHnSbdFCR/HVLT3bOy4=; b=BMrnIeaFxvOZlvU3MeIQGRP6DzxeH3wayqMxjv6qsp7jXObCTSISVsuxZJczD0v3J+ buGYSsAPil9tS2K4gGtzPLWuu9dM5lrVSglVhIGGrphbEnXp4dY9cGgeVdqG9Cs4OOQa 7hP4WZmM48tKV1OBSdfqIlE4LsdR9TWfvPW9E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=xniOAcFt++aML9RCSxRD9RFb3iD8aAa8C9rQq6PlWV4LTocslJDfeHBXwdaPwh0Xtp SCuWSeR+LbbhBsZ6ELshRe4xTsfzGUBn56qY7nuVVNpYhak4CfefIxmQkTvZLkFh6v2L /6G7e63q99hr15cw2LT5RG2xWi5xsZFDIzHD0= Received: by 10.150.113.13 with SMTP id l13mr124493ybc.248.1257856838735; Tue, 10 Nov 2009 04:40:38 -0800 (PST) Received: from ?133.93.128.64? (host-128-64.meeting.ietf.org [133.93.128.64]) by mx.google.com with ESMTPS id 14sm348049gxk.14.2009.11.10.04.40.36 (version=SSLv3 cipher=RC4-MD5); Tue, 10 Nov 2009 04:40:38 -0800 (PST) Message-ID: <4AF95F3B.5070702@gmail.com> Date: Wed, 11 Nov 2009 01:40:27 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dave Thaler References: <4AF7004A.8080508@cisco.com><12F41122069761 47A34FEC0277597CCF27A5229F07@XCH-NW-15V.nw.nos.boeing.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "softwires@ietf.org" Subject: [Softwires] Host 6to4 [Comments on draft-townsley-ipv6-6rd-01.txt] X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 12:40:15 -0000 On 2009-11-10 23:30, Dave Thaler wrote: ... > In hindsight, I think RFC 3056 should have mentioned the host case too. > I disagree that 3056 omitting it means we should omit it now too. In defence of 3056, here's what it says: Although the mechanism is specified for an IPv6 site, it can equally be applied to an individual IPv6 host or very small site, as long as it has at least one globally unique IPv4 address. However, the latter case raises serious scaling issues which are the subject of further study [SCALE]. That reference is to [SCALE] Hain, T., "6to4-relay discovery and scaling", Work in Progress. (http://tools.ietf.org/html/draft-hain-6to4-scaling-01), which I fear went nowhere, or was overtaken by RFC3068. Brian From dthaler@microsoft.com Tue Nov 10 04:41:56 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B641A3A6AAC for ; Tue, 10 Nov 2009 04:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.535 X-Spam-Level: X-Spam-Status: No, score=-10.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uu-kM9qePXud for ; Tue, 10 Nov 2009 04:41:55 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id D9FC03A6903 for ; Tue, 10 Nov 2009 04:41:55 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 10 Nov 2009 04:42:23 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server id 14.0.639.20; Tue, 10 Nov 2009 04:42:22 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Tue, 10 Nov 2009 04:42:22 -0800 From: Dave Thaler To: Brian E Carpenter Thread-Topic: Host 6to4 [Comments on draft-townsley-ipv6-6rd-01.txt] Thread-Index: AQHKYgMKPFiukSx5AkiOORpUCHfN35EvQkHg Date: Tue, 10 Nov 2009 12:42:21 +0000 Message-ID: References: <4AF7004A.8080508@cisco.com><12F41122069761 47A34FEC0277597CCF27A5229F07@XCH-NW-15V.nw.nos.boeing.com> <4AF95F3B.5070702@gmail.com> In-Reply-To: <4AF95F3B.5070702@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Host 6to4 [Comments on draft-townsley-ipv6-6rd-01.txt] X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 12:41:56 -0000 VGhlIHRleHQNCiIgIEFsdGhvdWdoIHRoZSBtZWNoYW5pc20gaXMgc3BlY2lmaWVkIGZvciBhbiBJ UHY2IHNpdGUsIGl0IGNhbiBlcXVhbGx5DQogICBiZSBhcHBsaWVkIHRvIGFuIGluZGl2aWR1YWwg SVB2NiBob3N0IG9yIHZlcnkgc21hbGwgc2l0ZSwgYXMgbG9uZyBhcw0KICAgaXQgaGFzIGF0IGxl YXN0IG9uZSBnbG9iYWxseSB1bmlxdWUgSVB2NCBhZGRyZXNzLiINCmlzIGdvb2QuICBJIHdvdWxk IGxpa2UgdG8gc2VlIHN1Y2ggdGV4dCBhZGRlZCB0byB0aGUgNnJkIGRvYy4NCg0KVGhhbmtzIGZv ciB0aGUgZGVmZW5jZSBCcmlhbi4NCg0KLURhdmUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVudGVy QGdtYWlsLmNvbV0NCj4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTAsIDIwMDkgOTo0MCBQTQ0K PiBUbzogRGF2ZSBUaGFsZXINCj4gQ2M6IE9sZSBUcm9hbjsgc29mdHdpcmVzQGlldGYub3JnDQo+ IFN1YmplY3Q6IEhvc3QgNnRvNCBbQ29tbWVudHMgb24gZHJhZnQtdG93bnNsZXktaXB2Ni02cmQt MDEudHh0XQ0KPiANCj4gT24gMjAwOS0xMS0xMCAyMzozMCwgRGF2ZSBUaGFsZXIgd3JvdGU6DQo+ IC4uLg0KPiA+IEluIGhpbmRzaWdodCwgSSB0aGluayBSRkMgMzA1NiBzaG91bGQgaGF2ZSBtZW50 aW9uZWQgdGhlIGhvc3QgY2FzZQ0KPiB0b28uDQo+ID4gSSBkaXNhZ3JlZSB0aGF0IDMwNTYgb21p dHRpbmcgaXQgbWVhbnMgd2Ugc2hvdWxkIG9taXQgaXQgbm93IHRvby4NCj4gDQo+IEluIGRlZmVu Y2Ugb2YgMzA1NiwgaGVyZSdzIHdoYXQgaXQgc2F5czoNCj4gDQo+ICAgIEFsdGhvdWdoIHRoZSBt ZWNoYW5pc20gaXMgc3BlY2lmaWVkIGZvciBhbiBJUHY2IHNpdGUsIGl0IGNhbiBlcXVhbGx5DQo+ ICAgIGJlIGFwcGxpZWQgdG8gYW4gaW5kaXZpZHVhbCBJUHY2IGhvc3Qgb3IgdmVyeSBzbWFsbCBz aXRlLCBhcyBsb25nIGFzDQo+ICAgIGl0IGhhcyBhdCBsZWFzdCBvbmUgZ2xvYmFsbHkgdW5pcXVl IElQdjQgYWRkcmVzcy4gIEhvd2V2ZXIsIHRoZQ0KPiAgICBsYXR0ZXIgY2FzZSByYWlzZXMgc2Vy aW91cyBzY2FsaW5nIGlzc3VlcyB3aGljaCBhcmUgdGhlIHN1YmplY3Qgb2YNCj4gICAgZnVydGhl ciBzdHVkeSBbU0NBTEVdLg0KPiANCj4gVGhhdCByZWZlcmVuY2UgaXMgdG8NCj4gDQo+ICAgIFtT Q0FMRV0gICAgSGFpbiwgVC4sICI2dG80LXJlbGF5IGRpc2NvdmVyeSBhbmQgc2NhbGluZyIsIFdv cmsgaW4NCj4gICAgICAgICAgICAgICBQcm9ncmVzcy4NCj4gDQo+IChodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1oYWluLTZ0bzQtc2NhbGluZy0wMSksDQo+IHdoaWNoIEkgZmVhciB3 ZW50IG5vd2hlcmUsIG9yIHdhcyBvdmVydGFrZW4gYnkgUkZDMzA2OC4NCj4gDQo+ICAgIEJyaWFu DQoNCg== From pekkas@netcore.fi Tue Nov 10 05:12:49 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABACF3A672F for ; Tue, 10 Nov 2009 05:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyNq5EBg1nLO for ; Tue, 10 Nov 2009 05:12:48 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 3DB8728C19E for ; Tue, 10 Nov 2009 05:12:48 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id nAADCBrv021773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Nov 2009 15:12:11 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id nAADC7Xg021767; Tue, 10 Nov 2009 15:12:08 +0200 Date: Tue, 10 Nov 2009 15:12:07 +0200 (EET) From: Pekka Savola To: Dave Thaler In-Reply-To: Message-ID: References: <4AF7004A.8080508@cisco.com><12F41122069761 47A34FEC0277597CCF27A5229F07@XCH-NW-15V.nw.nos.boeing.com> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.95.3 at otso.netcore.fi X-Virus-Status: Clean Cc: "softwires@ietf.org" Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 13:12:49 -0000 On Tue, 10 Nov 2009, Dave Thaler wrote: > In hindsight, I think RFC 3056 should have mentioned the host case too. > I disagree that 3056 omitting it means we should omit it now too. RFC 3056 could be called a success because it has been (almost?) solely been used in ways not originally envisioned (or at least written to the spec). >From the current usage perspective, RFC 3056 as a specification is not very useful, and I would strongly urge us not to copy it. If 3056bis is ever written, I'd personally want to see it written very, very differently :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From Fred.L.Templin@boeing.com Tue Nov 10 05:35:50 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D4693A67FC for ; Tue, 10 Nov 2009 05:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lq8WV9ovd10 for ; Tue, 10 Nov 2009 05:35:49 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 707FD3A672F for ; Tue, 10 Nov 2009 05:35:49 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id nAADZiMd007213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Nov 2009 05:35:44 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id nAADZhOt023488; Tue, 10 Nov 2009 05:35:43 -0800 (PST) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id nAADZhWB023480 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 10 Nov 2009 05:35:43 -0800 (PST) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Tue, 10 Nov 2009 05:35:43 -0800 From: "Templin, Fred L" To: Dave Thaler , Ole Troan Date: Tue, 10 Nov 2009 05:35:41 -0800 Thread-Topic: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt Thread-Index: AQHKYJk/oFPStRqnO0yZ+yxr6I/NWZEtKdsAgAAS24CAABIkgIAALpAAgAAcrbCAAYg7gP//+nGwgAA09eA= Message-ID: <12F4112206976147A34FEC0277597CCF27A522A1D9@XCH-NW-15V.nw.nos.boeing.com> References: <4AF7004A.8080508@cisco.com><12F41122069761 47A34FEC0277597CCF27A5229F07@XCH-NW-15V.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 13:35:50 -0000 Dave and Ole, > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On B= ehalf Of Dave Thaler > Sent: Tuesday, November 10, 2009 2:30 AM > To: Ole Troan > Cc: softwires@ietf.org > Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt >=20 > Ole Troan wrote: > > >>> Like when an RA advertises a PIO or an RIO they have lifetimes that > > >>> the CPE router learns. These lifetimes influence router selection > > >>> and > > >>> router reachability in a way that is not available without them. > > >> > > >> we're talking about a router to router link here. > > > > > > No we're not. We're talking about a link that can have _both routers > > > and hosts_ on it. From Mark's email earlier in this thread > > responding > > > to me: > > > > I don't see any reason why one couldn't implement 6rd in a host. the > > base specification does specify this only for routers though. just > > like rfc3056 does. >=20 > In hindsight, I think RFC 3056 should have mentioned the host case too. > I disagree that 3056 omitting it means we should omit it now too. Host-based 6rd is certainly a possibility (as also confirmed by Brian's account of the 6to4 text). Also possible is to run 6rd to routers in the ISP network that are also configured as ISATAP routers. Then, hosts can use PRL router discovery and get IPv6 service via ISATAP using their pre-existing code. Fred fred.l.templin@boeing.com >=20 > Omitting it just leads people to believe > "we're talking about a router to router link here" > as you've illustrated :-) >=20 > [...] > > we want as far as possible for implementors to be able to reuse > > existing 6to4 code. 6to4 doesn't specify how multiple relays are used > > either. rfc3068 specifies how a single anycast address is used to > > reach a relay. > > > > 6rd can be provisioned in multiple ways and there is nothing stopping > > one from deploying with multiple relays. we _could_ add a list of > > relays in the DHCP option in 6rd. my only concern is that would we > > then have to add text to describe how one should switch between them? > [...] >=20 > No. However, someone pointed out to me that unlike a DHCPv6 option, > a DHCPv4 option can occur multiple times. Assuming that's correct, > you can already get a list, in which case this particular concern of > mine goes away. >=20 > However, while we're on the topic of "reuse existing 6to4 code", it proba= bly > would have been better to call 6rd a "6to4 extension for private relays", > rather than a new protocol name since we have enough names to teach > people already and people just think "we have too many". If you actually > configured a 6RD node with a 6rd SP prefix of 2002::/16, you ought to > get behavior identical to 6to4 behavior. So our task would just be > updating 6to4 to allow for a configured prefix, and perhaps anything > else required. >=20 > -Dave > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From xuxh@huawei.com Tue Nov 10 06:40:31 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7E0F3A67F5 for ; Tue, 10 Nov 2009 06:40:31 -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=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52S-83eAGi-E for ; Tue, 10 Nov 2009 06:40:31 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 294FC3A693E for ; Tue, 10 Nov 2009 06:40:31 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSW00AROE3ZQS@szxga01-in.huawei.com> for softwires@ietf.org; Tue, 10 Nov 2009 22:40:48 +0800 (CST) Received: from huawei.com ([172.17.1.36]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSW005KDE3ZCS@szxga01-in.huawei.com> for softwires@ietf.org; Tue, 10 Nov 2009 22:40:47 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [133.93.113.139]) by szxmc04-in.huawei.com (mshttpd); Tue, 10 Nov 2009 23:40:47 +0900 Date: Tue, 10 Nov 2009 23:40:47 +0900 From: xuxiaohu 41208 To: "softwires@ietf.org" Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal Subject: [Softwires] Comments on draft-xu-softwire-tunnel-endpoint-00 are welcomed. X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 14:40:32 -0000 Hi all, Due to time limitation of the meeting agenda, I have no time to ask for comments after the presentation. I would like to solicit comments before the WG mailing-list running into silent status after the IETF meeting. Do you believe the inter-AS softwire solution is not necessary or there should be a better solution to the inter-AS softwire scenario? Any comment or suggestion is always appreciated. Best regards, Xiaohu From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Nov 10 12:37:54 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A8A43A6900 for ; Tue, 10 Nov 2009 12:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7GFSETjhtp0 for ; Tue, 10 Nov 2009 12:37:53 -0800 (PST) Received: from smtp1.adam.net.au (smtp1.adam.net.au [202.136.110.253]) by core3.amsl.com (Postfix) with ESMTP id 07CDE3A68E7 for ; Tue, 10 Nov 2009 12:37:53 -0800 (PST) Received: from 114-30-105-152.ip.adam.com.au ([114.30.105.152] helo=opy.nosense.org) by smtp1.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1N7xTg-0007G4-Ig; Wed, 11 Nov 2009 07:08:12 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id AAF7C492E3; Wed, 11 Nov 2009 07:08:09 +1030 (CST) Date: Wed, 11 Nov 2009 07:08:09 +1030 From: Mark Smith To: "Templin, Fred L" Message-ID: <20091111070809.344b782f@opy.nosense.org> In-Reply-To: <12F4112206976147A34FEC0277597CCF27A522A1D9@XCH-NW-15V.nw.nos.boeing.com> References: <4AF7004A.8080508@cisco.com> <12F41122069761 47A34FEC0277597CCF27A5229F07@XCH-NW-15V.nw.nos.boeing.com> <12F4112206976147A34FEC0277597CCF27A522A1D9@XCH-NW-15V.nw.nos.boeing.com> X-Mailer: Claws Mail 3.7.3 (GTK+ 2.18.3; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "softwires@ietf.org" Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 20:37:54 -0000 On Tue, 10 Nov 2009 05:35:41 -0800 "Templin, Fred L" wrote: > Dave and Ole, > > > -----Original Message----- > > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Dave Thaler > > Sent: Tuesday, November 10, 2009 2:30 AM > > To: Ole Troan > > Cc: softwires@ietf.org > > Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt > > > > Ole Troan wrote: > > > >>> Like when an RA advertises a PIO or an RIO they have lifetimes that > > > >>> the CPE router learns. These lifetimes influence router selection > > > >>> and > > > >>> router reachability in a way that is not available without them. > > > >> > > > >> we're talking about a router to router link here. > > > > > > > > No we're not. We're talking about a link that can have _both routers > > > > and hosts_ on it. From Mark's email earlier in this thread > > > responding > > > > to me: > > > > > > I don't see any reason why one couldn't implement 6rd in a host. the > > > base specification does specify this only for routers though. just > > > like rfc3056 does. > > > > In hindsight, I think RFC 3056 should have mentioned the host case too. > > I disagree that 3056 omitting it means we should omit it now too. > > Host-based 6rd is certainly a possibility (as also > confirmed by Brian's account of the 6to4 text). Also > possible is to run 6rd to routers in the ISP network > that are also configured as ISATAP routers. Then, > hosts can use PRL router discovery and get IPv6 > service via ISATAP using their pre-existing code. > It seems to me that ISATAP might have more of the features that are the goal of 6rd when compared with 6to4, with the exception of that ISATAP is host-to-router rather than router-to-router, and there isn't currently a way to derive a delegatable prefix from an ISATAP node address. > Fred > fred.l.templin@boeing.com > > > > > Omitting it just leads people to believe > > "we're talking about a router to router link here" > > as you've illustrated :-) > > > > [...] > > > we want as far as possible for implementors to be able to reuse > > > existing 6to4 code. 6to4 doesn't specify how multiple relays are used > > > either. rfc3068 specifies how a single anycast address is used to > > > reach a relay. > > > > > > 6rd can be provisioned in multiple ways and there is nothing stopping > > > one from deploying with multiple relays. we _could_ add a list of > > > relays in the DHCP option in 6rd. my only concern is that would we > > > then have to add text to describe how one should switch between them? > > [...] > > > > No. However, someone pointed out to me that unlike a DHCPv6 option, > > a DHCPv4 option can occur multiple times. Assuming that's correct, > > you can already get a list, in which case this particular concern of > > mine goes away. > > > > However, while we're on the topic of "reuse existing 6to4 code", it probably > > would have been better to call 6rd a "6to4 extension for private relays", > > rather than a new protocol name since we have enough names to teach > > people already and people just think "we have too many". If you actually > > configured a 6RD node with a 6rd SP prefix of 2002::/16, you ought to > > get behavior identical to 6to4 behavior. So our task would just be > > updating 6to4 to allow for a configured prefix, and perhaps anything > > else required. > > > > -Dave > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From Fred.L.Templin@boeing.com Tue Nov 10 15:09:16 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B001B28C1F9 for ; Tue, 10 Nov 2009 15:09:16 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTER+gW0xJFK for ; Tue, 10 Nov 2009 15:09:15 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id A23FE28C0DD for ; Tue, 10 Nov 2009 15:09:15 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id nAAN8umn006681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Nov 2009 15:08:56 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id nAAN8tkV029486; Tue, 10 Nov 2009 15:08:55 -0800 (PST) Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id nAAN8tbM029477 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 10 Nov 2009 15:08:55 -0800 (PST) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Tue, 10 Nov 2009 15:08:55 -0800 From: "Templin, Fred L" To: Mark Smith Date: Tue, 10 Nov 2009 15:08:52 -0800 Thread-Topic: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt Thread-Index: AcpiRcISpsbuIjCnTD+UTo+yTlImmgAE0kSw Message-ID: <12F4112206976147A34FEC0277597CCF27A522A430@XCH-NW-15V.nw.nos.boeing.com> References: <4AF7004A.8080508@cisco.com><12F41122069761 47A34FEC0277597CCF27A5229F07@XCH-NW-15V.nw.nos.boeing.com><12F4112206976147A34FEC0277597CCF27A522A1D9@XCH-NW-15V.nw.nos.boeing.com> <20091111070809.344b782f@opy.nosense.org> In-Reply-To: <20091111070809.344b782f@opy.nosense.org> 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: "softwires@ietf.org" Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 23:09:16 -0000 > -----Original Message----- > From: Mark Smith [mailto:ipng@69706e6720323030352d30312d31340a.nosense.or= g] > Sent: Tuesday, November 10, 2009 12:38 PM > To: Templin, Fred L > Cc: Dave Thaler; Ole Troan; softwires@ietf.org > Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt >=20 > On Tue, 10 Nov 2009 05:35:41 -0800 > "Templin, Fred L" wrote: >=20 > > Dave and Ole, > > > > > -----Original Message----- > > > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] = On Behalf Of Dave Thaler > > > Sent: Tuesday, November 10, 2009 2:30 AM > > > To: Ole Troan > > > Cc: softwires@ietf.org > > > Subject: Re: [Softwires] Comments on draft-townsley-ipv6-6rd-01.txt > > > > > > Ole Troan wrote: > > > > >>> Like when an RA advertises a PIO or an RIO they have lifetimes = that > > > > >>> the CPE router learns. These lifetimes influence router selecti= on > > > > >>> and > > > > >>> router reachability in a way that is not available without them= . > > > > >> > > > > >> we're talking about a router to router link here. > > > > > > > > > > No we're not. We're talking about a link that can have _both rou= ters > > > > > and hosts_ on it. From Mark's email earlier in this thread > > > > responding > > > > > to me: > > > > > > > > I don't see any reason why one couldn't implement 6rd in a host. th= e > > > > base specification does specify this only for routers though. just > > > > like rfc3056 does. > > > > > > In hindsight, I think RFC 3056 should have mentioned the host case to= o. > > > I disagree that 3056 omitting it means we should omit it now too. > > > > Host-based 6rd is certainly a possibility (as also > > confirmed by Brian's account of the 6to4 text). Also > > possible is to run 6rd to routers in the ISP network > > that are also configured as ISATAP routers. Then, > > hosts can use PRL router discovery and get IPv6 > > service via ISATAP using their pre-existing code. > > >=20 > It seems to me that ISATAP might have more of the features that are the > goal of 6rd when compared with 6to4, with the exception of that ISATAP > is host-to-router rather than router-to-router, and there isn't > currently a way to derive a delegatable prefix from an ISATAP node > address. 6to4, ISATAP, Teredo and now 6rd are really just all members of the same family. 6to4 is the kindly single parent that works hard to support her children. ISATAP is the nerd that stays home reading physics textbooks while the other kids are out back playing stickball. Teredo is the prankster that throws snowballs at cars and soaps the neighbors windows. Now, 6rd is the shining new baby, full of potential. Welcome to the family, kid. Fred fred.l.templin@boeing.com=20 =20 > > Fred > > fred.l.templin@boeing.com > > > > > > > > Omitting it just leads people to believe > > > "we're talking about a router to router link here" > > > as you've illustrated :-) > > > > > > [...] > > > > we want as far as possible for implementors to be able to reuse > > > > existing 6to4 code. 6to4 doesn't specify how multiple relays are us= ed > > > > either. rfc3068 specifies how a single anycast address is used to > > > > reach a relay. > > > > > > > > 6rd can be provisioned in multiple ways and there is nothing stoppi= ng > > > > one from deploying with multiple relays. we _could_ add a list of > > > > relays in the DHCP option in 6rd. my only concern is that would we > > > > then have to add text to describe how one should switch between the= m? > > > [...] > > > > > > No. However, someone pointed out to me that unlike a DHCPv6 option, > > > a DHCPv4 option can occur multiple times. Assuming that's correct, > > > you can already get a list, in which case this particular concern of > > > mine goes away. > > > > > > However, while we're on the topic of "reuse existing 6to4 code", it p= robably > > > would have been better to call 6rd a "6to4 extension for private rela= ys", > > > rather than a new protocol name since we have enough names to teach > > > people already and people just think "we have too many". If you actu= ally > > > configured a 6RD node with a 6rd SP prefix of 2002::/16, you ought to > > > get behavior identical to 6to4 behavior. So our task would just be > > > updating 6to4 to allow for a configured prefix, and perhaps anything > > > else required. > > > > > > -Dave > > > _______________________________________________ > > > Softwires mailing list > > > Softwires@ietf.org > > > https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires From mohamed.boucadair@orange-ftgroup.com Mon Nov 16 05:33:44 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CF213A6AB5 for ; Mon, 16 Nov 2009 05:33:44 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body X-Spam-Flag: NO X-Spam-Score: -0.759 X-Spam-Level: X-Spam-Status: No, score=-0.759 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juWq0-OdIaTG for ; Mon, 16 Nov 2009 05:33:43 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 3A1353A689E for ; Mon, 16 Nov 2009 05:33:42 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id C2FD8190120 for ; Mon, 16 Nov 2009 14:33:40 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id AD44318003B for ; Mon, 16 Nov 2009 14:33:40 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Mon, 16 Nov 2009 14:33:40 +0100 From: To: "softwires@ietf.org" Date: Mon, 16 Nov 2009 14:33:39 +0100 Thread-Topic: Comment about draft-dhankins-softwire-tunnel-option Thread-Index: Acpj+I1d4rxBr+8DQ+uB5KacqsBNtwCxqf4w Message-ID: <8353_1258378420_4B0154B4_8353_29345_1_94C682931C08B048B7A8645303FDC9F307914E6907@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/mixed; boundary="_002_94C682931C08B048B7A8645303FDC9F307914E6907PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.11.16.131225 Subject: [Softwires] Comment about draft-dhankins-softwire-tunnel-option X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 13:33:44 -0000 --_002_94C682931C08B048B7A8645303FDC9F307914E6907PUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear authors, all, The current version of the draft defines a single option which is used to c= onvey one FQDN pointing to a DS-lite CGN. The use of FQDN may have several = advantages compared to a plain IPv6 address such as enabling DNS-based load= distribution among a set of CGN devices. Nevertheless, this should not pre= clude to define an option to convey a (list) of IPv6 address instead of FQD= N. It is up to the service providers to decide whether enclosing an IP addr= ess or a FQDN in the ds-lite DHCP option is more appropriate in their conte= xts. Is there any reason why the draft defines only the FQDN option? Cheers, Med ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** --_002_94C682931C08B048B7A8645303FDC9F307914E6907PUEXCB1Bnante_ Content-Type: message/external-body; name="draft-dhankins-softwire-tunnel-option-05.url" Content-Description: draft-dhankins-softwire-tunnel-option-05.url Content-Disposition: attachment; filename="draft-dhankins-softwire-tunnel-option-05.url"; size=105; creation-date="Fri, 13 Nov 2009 01:30:50 GMT"; modification-date="Fri, 13 Nov 2009 01:30:50 GMT" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1kaGFua2lucy1zb2Z0d2lyZS10dW5uZWwtb3B0aW9uLTA1LnR4dA0K --_002_94C682931C08B048B7A8645303FDC9F307914E6907PUEXCB1Bnante_-- From jordi.palet@consulintel.es Mon Nov 16 06:28:31 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B27E3A681D for ; Mon, 16 Nov 2009 06:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojEViSKVDxHH for ; Mon, 16 Nov 2009 06:28:30 -0800 (PST) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by core3.amsl.com (Postfix) with ESMTP id 68AAA3A6967 for ; Mon, 16 Nov 2009 06:28:29 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=nowsp; d=consulintel.es; s=MDaemon; t=1258385206; x=1258990006; i=jordi.palet@consulintel.es; q=dns; h=DomainKey-Signature:Received:User-Agent:Date:Subject:From:To: Message-ID:Thread-Topic:Thread-Index:Mime-version:Content-type: Content-transfer-encoding:Reply-To; b=LbA9jXIPtPgbmeFfFUqsTMgDWzB QOprbnvy6Q1o6w8x1ls40nap/HTXHNF87mKYvtbF5/ofOZGvcJ5OBoAcVtPnKwoB 5gzNbUU5650Lz7loyXcZN+2nQJJOxD6ipCYhgnIA3kXns2aED4cL5i3R6bKSVWCV RT4zmWnmbcZUg2IE= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=p2cfIW483AH+knT+RzKS07CB8zU8djQhcsV16xmv+LGkwA6o9Ug8jeIWNGCd0lzmU12exA0l7StzWSM7VFuY9If3Co8m+rhZR/oQyln7agAYsna9j4j5DU7uiA6TbvR63MjoInBp8BFhsfQ8G3ZCtinxnrk0TBi1JLxpt9sSA74=; Received: from [10.5.8.222] by consulintel.es (MDaemon.PRO.v8.1.5.R) with ESMTP id md50003461619.msg for ; Mon, 16 Nov 2009 15:26:41 +0100 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 16 Nov 2009 23:27:54 +0900 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: Tunnel discovery Thread-Index: AcpmyPvzLWTbXsfZQZqEQPotB3bVRg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:091116:softwires@ietf.org::9uKjD2A7NjH8gcxB:00000000000000000000000000000000000000000005AqS X-MDRemoteIP: 219.127.127.130 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: softwires@ietf.org X-Spam-Processed: consulintel.es, Mon, 16 Nov 2009 15:26:43 +0100 X-MDAV-Processed: consulintel.es, Mon, 16 Nov 2009 15:26:46 +0100 Subject: [Softwires] Tunnel discovery X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 14:28:31 -0000 Hi, Looking at the need for discovering a tunnel-endpoint for DSLINE, same as for other softwires protocols, I wonder if we should revive the work previously done at http://tools.ietf.org/id/draft-palet-v6ops-tun-auto-disc-03.txt I see that a DHCP option is being proposed, however, our previous study was showing that this is not the best alternative, and similar approaches where rejected before for softwires hubs&spoke TEP discovery by the DHCP WG. Regards, Jordi ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet@consulintel.es Mon Nov 16 06:35:18 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE78428B797 for ; Mon, 16 Nov 2009 06:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.001 X-Spam-Level: X-Spam-Status: No, score=-4.001 tagged_above=-999 required=5 tests=[AWL=0.602, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNEoWEH3IMHY for ; Mon, 16 Nov 2009 06:35:18 -0800 (PST) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by core3.amsl.com (Postfix) with ESMTP id 69EDA3A6AA3 for ; Mon, 16 Nov 2009 06:35:17 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=nowsp; d=consulintel.es; s=MDaemon; t=1258385614; x=1258990414; i=jordi.palet@consulintel.es; q=dns; h=DomainKey-Signature:Received:User-Agent:Date:Subject:From:To: Message-ID:Thread-Topic:Thread-Index:In-Reply-To:Mime-version: Content-type:Content-transfer-encoding:Reply-To; b=gWYrRcJdtoOSF/ UeWC3XUCBO3GiW1LnGECDBcIo98Njzr4ooz2wtnPiYIVYYobFBmzxIG0ObrkA7DE AtP1RAXiNOtKfZDJocsFx/P9fjXIx33uLXcgtLa1NhOn+jvwcoiPGhMtky4www/y HLwjiD5hJHcRi4L0Egibxu18iRh5A= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=dbxIZjsPcQfH9+AzCkyRoC0cl6hXGk09wL5X9dq1M5nEnZOG4hNwgZWK5aXQsg7lsMYNskcZrrxuVZ+VNo2hM8Qo+pR/hXaOAqiTriG17L4ujn1AwQwffZPfpnUOZ+a5jgjbNYger0e3jKhRm6ai4u61PjnL6ElMVTtvSknGZXY=; Received: from [10.5.8.222] by consulintel.es (MDaemon.PRO.v8.1.5.R) with ESMTP id md50003461632.msg for ; Mon, 16 Nov 2009 15:33:32 +0100 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 16 Nov 2009 23:35:04 +0900 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [Softwires] Tunnel discovery Thread-Index: AcpmyPvzLWTbXsfZQZqEQPotB3bVRgAAQBOb In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:091116:softwires@ietf.org::R0Cdb79K50UwpmDP:00000000000000000000000000000000000000000002Q9w X-MDRemoteIP: 219.127.127.130 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: softwires@ietf.org X-Spam-Processed: consulintel.es, Mon, 16 Nov 2009 15:33:33 +0100 X-MDAV-Processed: consulintel.es, Mon, 16 Nov 2009 15:33:34 +0100 Subject: Re: [Softwires] Tunnel discovery X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 14:35:19 -0000 By the way, there is one more document ... http://tools.ietf.org/id/draft-palet-v6ops-solution-tun-auto-disc-01.txt Regards, Jordi > De: Jordi Palet Mart=EDnez > Responder a: Jordi Palet Mart=EDnez > Fecha: Mon, 16 Nov 2009 23:27:54 +0900 > Para: > Asunto: [Softwires] Tunnel discovery >=20 > Hi, >=20 > Looking at the need for discovering a tunnel-endpoint for DSLINE, same as > for other softwires protocols, I wonder if we should revive the work > previously done at >=20 > http://tools.ietf.org/id/draft-palet-v6ops-tun-auto-disc-03.txt >=20 > I see that a DHCP option is being proposed, however, our previous study was > showing that this is not the best alternative, and similar approaches where > rejected before for softwires hubs&spoke TEP discovery by the DHCP WG. >=20 > Regards, > Jordi >=20 >=20 >=20 >=20 >=20 >=20 > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org >=20 > Bye 6Bone. Hi, IPv6 ! > http://www.ipv6day.org >=20 > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware that > any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org >=20 > Bye 6Bone. Hi, IPv6 ! > http://www.ipv6day.org >=20 > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware that > any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. >=20 >=20 ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From alain_durand@cable.comcast.com Mon Nov 16 07:16:23 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A9193A697F for ; Mon, 16 Nov 2009 07:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.201 X-Spam-Level: **** X-Spam-Status: No, score=4.201 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_45=0.6, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQ+z8KzdI1Tn for ; Mon, 16 Nov 2009 07:16:22 -0800 (PST) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 35B763A677E for ; Mon, 16 Nov 2009 07:16:22 -0800 (PST) Received: from ([24.40.15.118]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.82522564; Mon, 16 Nov 2009 10:16:02 -0500 Received: from PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 10:16:02 -0500 Received: from 147.191.223.149 ([147.191.223.149]) by PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) with Microsoft Exchange Server HTTP-DAV ; Mon, 16 Nov 2009 15:16:02 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 17 Nov 2009 00:15:59 +0900 From: "Durand, Alain" To: , Message-ID: Thread-Topic: [Softwires] Tunnel discovery Thread-Index: AcpmyPvzLWTbXsfZQZqEQPotB3bVRgABreZb In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3341261762_71191" X-OriginalArrivalTime: 16 Nov 2009 15:16:02.0901 (UTC) FILETIME=[B5DEA050:01CA66CF] Subject: Re: [Softwires] Tunnel discovery X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 15:16:23 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3341261762_71191 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Jordi, There is a fundamental difference wrt tunnel end-point discovery between softwire hub & spoke and dual-stack lite. It is that th dual-stack lite tunnel is originated by the home gateway itself. As such a DHCPv6 option will work just fine. It would not have in the more general hub&spoke case, where a) the tunnel could have been started by an IPv4 node behind the home gateway and b) the home gateway could have been an unmodified IPv4 gateway, ie, unaware of such option. - Alain On 11/16/09 11:27 PM, "JORDI PALET MARTINEZ" wrote: > Hi, > > Looking at the need for discovering a tunnel-endpoint for DSLINE, same as > for other softwires protocols, I wonder if we should revive the work > previously done at > > http://tools.ietf.org/id/draft-palet-v6ops-tun-auto-disc-03.txt > > I see that a DHCP option is being proposed, however, our previous study was > showing that this is not the best alternative, and similar approaches where > rejected before for softwires hubs&spoke TEP discovery by the DHCP WG. > > Regards, > Jordi > > > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Bye 6Bone. Hi, IPv6 ! > http://www.ipv6day.org > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware that > any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --B_3341261762_71191 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [Softwires] Tunnel discovery Jordi,

There is a fundamental difference wrt tunnel end-point discovery between so= ftwire hub & spoke and dual-stack lite. It is that th dual-stack lite tu= nnel is originated by the home gateway itself. As such a DHCPv6 option will = work just fine. It would not have in the more general hub&spoke case, wh= ere a) the tunnel could have been started by an IPv4 node behind the home ga= teway and b) the home gateway could have been an unmodified IPv4 gateway, ie= , unaware of such option.

  - Alain


On 11/16/09 11:27 PM, "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Hi,

Looking at the need for discovering a tunnel-endpoint for DSLINE, same as for other softwires protocols, I wonder if we should revive the work
previously done at

h= ttp://tools.ietf.org/id/draft-palet-v6ops-tun-auto-disc-03.txt

I see that a DHCP option is being proposed, however, our previous study was=
showing that this is not the best alternative, and similar approaches where=
rejected before for softwires hubs&spoke TEP discovery by the DHCP WG.<= BR>
Regards,
Jordi






**********************************************
The IPv6 Portal: http://www.ipv6tf.org<= BR>
Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(s= ) named above. If you are not the intended recipient be aware that any discl= osure, copying, distribution or use of the contents of this information, inc= luding attached files, is prohibited.



_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.= org/mailman/listinfo/softwires

--B_3341261762_71191-- From dthaler@microsoft.com Mon Nov 16 14:54:00 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACE993A6B2C for ; Mon, 16 Nov 2009 14:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.299 X-Spam-Level: X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4VDHXV8bTEB for ; Mon, 16 Nov 2009 14:54:00 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 02BC93A6B2B for ; Mon, 16 Nov 2009 14:54:00 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 16 Nov 2009 14:54:19 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server id 14.0.639.21; Mon, 16 Nov 2009 14:53:58 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Mon, 16 Nov 2009 14:53:58 -0800 From: Dave Thaler To: "mohamed.boucadair@orange-ftgroup.com" , "softwires@ietf.org" Thread-Topic: Comment about draft-dhankins-softwire-tunnel-option Thread-Index: Acpj+I1d4rxBr+8DQ+uB5KacqsBNtwCxqf4wABQWe/A= Date: Mon, 16 Nov 2009 22:53:57 +0000 Message-ID: References: <8353_1258378420_4B0154B4_8353_29345_1_94C682931C08B048B7A8645303FDC9F307914E6907@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <8353_1258378420_4B0154B4_8353_29345_1_94C682931C08B048B7A8645303FDC9F307914E6907@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] Comment about draft-dhankins-softwire-tunnel-option X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 22:54:00 -0000 You can resolve an FQDN to a list of IPv6 addresses, so it seems to already provide that ability just with an FQDN. -Dave > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of mohamed.boucadair@orange-ftgroup.com > Sent: Monday, November 16, 2009 5:34 AM > To: softwires@ietf.org > Subject: [Softwires] Comment about draft-dhankins-softwire-tunnel- > option >=20 >=20 > Dear authors, all, >=20 > The current version of the draft defines a single option which is used > to convey one FQDN pointing to a DS-lite CGN. The use of FQDN may have > several advantages compared to a plain IPv6 address such as enabling > DNS-based load distribution among a set of CGN devices. Nevertheless, > this should not preclude to define an option to convey a (list) of IPv6 > address instead of FQDN. It is up to the service providers to decide > whether enclosing an IP address or a FQDN in the ds-lite DHCP option is > more appropriate in their contexts. >=20 > Is there any reason why the draft defines only the FQDN option? >=20 > Cheers, > Med > ********************************* > This message and any attachments (the "message") are confidential and > intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if altered, > changed or falsified. > If you are not the intended addressee of this message, please cancel it > immediately and inform the sender. > ******************************** From mohamed.boucadair@orange-ftgroup.com Mon Nov 16 22:35:34 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B741A3A6359 for ; Mon, 16 Nov 2009 22:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.041 X-Spam-Level: X-Spam-Status: No, score=-1.041 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id youILxKDQo96 for ; Mon, 16 Nov 2009 22:35:33 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 8FFBB3A6A7F for ; Mon, 16 Nov 2009 22:35:33 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 764DA24823E; Tue, 17 Nov 2009 07:35:31 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 5F24A4C048; Tue, 17 Nov 2009 07:35:31 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Tue, 17 Nov 2009 07:35:31 +0100 From: To: Dave Thaler , "softwires@ietf.org" Date: Tue, 17 Nov 2009 07:35:30 +0100 Thread-Topic: Comment about draft-dhankins-softwire-tunnel-option Thread-Index: Acpj+I1d4rxBr+8DQ+uB5KacqsBNtwCxqf4wABQWe/AAD/inkA== Message-ID: <24717_1258439731_4B024433_24717_43144_1_94C682931C08B048B7A8645303FDC9F307918778CB@PUEXCB1B.nanterre.francetelecom.fr> References: <8353_1258378420_4B0154B4_8353_29345_1_94C682931C08B048B7A8645303FDC9F307914E6907@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: 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.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.11.17.60921 Subject: Re: [Softwires] Comment about draft-dhankins-softwire-tunnel-option X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 06:35:34 -0000 Dear Dave, all, I'm not talking about that, but when I don't want to add any entry to my DN= S due to some reasons (avoid extra configuration task of DNS for instance.) Cheers, Med =20 -----Message d'origine----- De : Dave Thaler [mailto:dthaler@microsoft.com]=20 Envoy=E9 : lundi 16 novembre 2009 23:54 =C0 : BOUCADAIR Mohamed NCPI/NAD/TIP; softwires@ietf.org Objet : RE: Comment about draft-dhankins-softwire-tunnel-option You can resolve an FQDN to a list of IPv6 addresses, so it seems to already provide that ability just with an FQDN. -Dave > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of mohamed.boucadair@orange-ftgroup.com > Sent: Monday, November 16, 2009 5:34 AM > To: softwires@ietf.org > Subject: [Softwires] Comment about draft-dhankins-softwire-tunnel- > option >=20 >=20 > Dear authors, all, >=20 > The current version of the draft defines a single option which is used > to convey one FQDN pointing to a DS-lite CGN. The use of FQDN may have > several advantages compared to a plain IPv6 address such as enabling > DNS-based load distribution among a set of CGN devices. Nevertheless, > this should not preclude to define an option to convey a (list) of IPv6 > address instead of FQDN. It is up to the service providers to decide > whether enclosing an IP address or a FQDN in the ds-lite DHCP option is > more appropriate in their contexts. >=20 > Is there any reason why the draft defines only the FQDN option? >=20 > Cheers, > Med > ********************************* > This message and any attachments (the "message") are confidential and > intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if altered, > changed or falsified. > If you are not the intended addressee of this message, please cancel it > immediately and inform the sender. > ******************************** ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From remi.despres@free.fr Tue Nov 17 02:50:40 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E581A3A69D4 for ; Tue, 17 Nov 2009 02:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWGy1mgql5vY for ; Tue, 17 Nov 2009 02:50:40 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 2771828C0EC for ; Tue, 17 Nov 2009 02:50:38 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 73E7BE081A4; Tue, 17 Nov 2009 11:50:32 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 8925EE080EF; Tue, 17 Nov 2009 11:50:30 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0A4D7242-7CBC-4068-9722-399C271659FC@free.fr> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Date: Tue, 17 Nov 2009 19:50:29 +0900 To: Dave Thaler X-Mailer: Apple Mail (2.753.1) Cc: softwires@ietf.org Subject: [Softwires] SRV and port 80 in MS-IE? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 10:50:41 -0000 Dave, draft-ford-shared-addressing-issues-01/sec 4.2.2 mentions port 80 in its example of SRV usage. I didn't find whether MS IE supports SRVs. Would you know the answer? RD From guoseu@huawei.com Tue Nov 17 23:14:19 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5C2E3A6B4B for ; Tue, 17 Nov 2009 23:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1t10XLZVo7tc for ; Tue, 17 Nov 2009 23:14:15 -0800 (PST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 75EF33A6881 for ; Tue, 17 Nov 2009 23:14:12 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTA005JSMRKYU@szxga02-in.huawei.com> for softwires@ietf.org; Wed, 18 Nov 2009 15:14:08 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTA00GD6MRJR0@szxga02-in.huawei.com> for softwires@ietf.org; Wed, 18 Nov 2009 15:14:08 +0800 (CST) Received: from g57775 ([10.111.12.203]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KTA005B3MRJ0M@szxml06-in.huawei.com> for softwires@ietf.org; Wed, 18 Nov 2009 15:14:07 +0800 (CST) Date: Wed, 18 Nov 2009 15:14:08 +0800 From: Dayong Guo In-reply-to: <24717_1258439731_4B024433_24717_43144_1_94C682931C08B048B7A8645303FDC9F307918778CB@PUEXCB1B.nanterre.francetelecom.fr> To: mohamed.boucadair@orange-ftgroup.com, 'Dave Thaler' , softwires@ietf.org Message-id: <002201ca681e$b89a0690$cb0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Thread-index: Acpj+I1d4rxBr+8DQ+uB5KacqsBNtwCxqf4wABQWe/AAD/inkAAyzUHg Subject: Re: [Softwires] Comment about draft-dhankins-softwire-tunnel-option X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 07:14:19 -0000 Yes, it seems that FQDN is NOT better thar IPv6 Address of DSlite CGN. = A CPE needs two operations (one DHCP, one DNS) to discover CGN too. DHCP has same load distribution function as DNS-based. Dayong Guo =20 > -----Original Message----- > From: softwires-bounces@ietf.org=20 > [mailto:softwires-bounces@ietf.org] On Behalf Of=20 > mohamed.boucadair@orange-ftgroup.com > Sent: Tuesday, November 17, 2009 2:36 PM > To: Dave Thaler; softwires@ietf.org > Subject: Re: [Softwires] Comment about=20 > draft-dhankins-softwire-tunnel-option >=20 >=20 > Dear Dave, all, >=20 > I'm not talking about that, but when I don't want to add any=20 > entry to my DNS due to some reasons (avoid extra=20 > configuration task of DNS for instance.) >=20 > Cheers, > Med > =20 >=20 > -----Message d'origine----- > De : Dave Thaler [mailto:dthaler@microsoft.com] Envoy=E9 :=20 > lundi 16 novembre 2009 23:54 =C0 : BOUCADAIR Mohamed=20 > NCPI/NAD/TIP; softwires@ietf.org Objet : RE: Comment about=20 > draft-dhankins-softwire-tunnel-option >=20 > You can resolve an FQDN to a list of IPv6 addresses, so it=20 > seems to already provide that ability just with an FQDN. >=20 > -Dave >=20 > > -----Original Message----- > > From: softwires-bounces@ietf.org=20 > [mailto:softwires-bounces@ietf.org]=20 > > On Behalf Of mohamed.boucadair@orange-ftgroup.com > > Sent: Monday, November 16, 2009 5:34 AM > > To: softwires@ietf.org > > Subject: [Softwires] Comment about draft-dhankins-softwire-tunnel-=20 > > option > >=20 > >=20 > > Dear authors, all, > >=20 > > The current version of the draft defines a single option=20 > which is used=20 > > to convey one FQDN pointing to a DS-lite CGN. The use of=20 > FQDN may have=20 > > several advantages compared to a plain IPv6 address such as=20 > enabling=20 > > DNS-based load distribution among a set of CGN devices.=20 > Nevertheless,=20 > > this should not preclude to define an option to convey a (list) of=20 > > IPv6 address instead of FQDN. It is up to the service providers to=20 > > decide whether enclosing an IP address or a FQDN in the=20 > ds-lite DHCP=20 > > option is more appropriate in their contexts. > >=20 > > Is there any reason why the draft defines only the FQDN option? > >=20 > > Cheers, > > Med From remi.despres@free.fr Thu Nov 19 04:56:19 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37F3E3A68DE; Thu, 19 Nov 2009 04:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQTLOOUKsxnl; Thu, 19 Nov 2009 04:56:18 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id B8B883A69F2; Thu, 19 Nov 2009 04:56:16 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 5CD99E081AA; Thu, 19 Nov 2009 13:56:09 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id D7516E08038; Thu, 19 Nov 2009 13:56:06 +0100 (CET) In-Reply-To: <4B05184F.3000703@necom830.hpcl.titech.ac.jp> References: <02773C0D-119D-4284-AF69-F86F5A1D4C8A@free.fr> <4B05184F.3000703@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Date: Thu, 19 Nov 2009 13:56:05 +0100 To: Masataka Ohta X-Mailer: Apple Mail (2.753.1) Cc: softwires@ietf.org, shara@ietf.org Subject: Re: [Softwires] [shara] "Issues in Port-Restricted IPs" and SAM.A+P X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 12:56:19 -0000 Le 19 nov. 09 =E0 11:05, Masataka Ohta a =E9crit : > Remi Despres wrote: > >> At the aplusp BOF, Dave Thaler presented a list of "issues in port >> restricted IPs". > > As almost all, if not all, points of his presentation are invalid, > it is a waste of time to discuss on it. > > Instead, if you or someone else find some of his points valid, let's > discuss on it. As you can note if you read what I wrote, I used Dave's point only as =20= a check list to show that, in the particular case of SAM.A+P I work =20 on, they are not valid. > Do you have some? I have none. > >> Imposed by the scope of the BOF, strictly limited to A+P for DS-lite, > > DS-lite? Dual-stack lite (for short in the IETF context). Sorry if you are a video-game fan. > FYI, a large ISP in Japan, maybe the world largest with regard to > the number of subscribers, use private IPv4 space of 10/8 for > its internal topology for years without any problem, which means > we have enough IPv4 address space for ISP internal use. Could you be more specific on how this relates to A+P ? Regards, RD From dthaler@microsoft.com Thu Nov 19 14:03:11 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 419553A635F; Thu, 19 Nov 2009 14:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.88 X-Spam-Level: X-Spam-Status: No, score=-9.88 tagged_above=-999 required=5 tests=[AWL=0.719, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcHWR-ou896b; Thu, 19 Nov 2009 14:03:10 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id D52883A689F; Thu, 19 Nov 2009 14:03:09 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 19 Nov 2009 14:03:28 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server id 14.0.639.20; Thu, 19 Nov 2009 14:03:07 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Thu, 19 Nov 2009 14:03:06 -0800 From: Dave Thaler To: "shara@ietf.org" , "softwires@ietf.org" Thread-Topic: [shara] "Issues in Port-Restricted IPs" and SAM.A+P Thread-Index: AQHKaFalErMc4w0eskKFwGwUcXtaRJE99jjg Date: Thu, 19 Nov 2009 22:03:05 +0000 Message-ID: References: <02773C0D-119D-4284-AF69-F86F5A1D4C8A@free.fr> In-Reply-To: <02773C0D-119D-4284-AF69-F86F5A1D4C8A@free.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] [shara] "Issues in Port-Restricted IPs" and SAM.A+P X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 22:03:11 -0000 The slides intentionally didn't mention specific proposals since they vary and the slides concentrate on summarizing the issues _in general_ with the notion of "port-restricted IPs", that have been raised by=20 various people on various lists and in various discussions, but were not all in one place. Several people have requested it be turned into an Internet Draft to make points easier to discuss, and I am willing to help do so. -Dave > -----Original Message----- > From: shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] On Behalf > Of R=E9mi Despr=E9s > Sent: Wednesday, November 18, 2009 5:52 AM > To: shara@ietf.org > Cc: softwires@ietf.org > Subject: [shara] "Issues in Port-Restricted IPs" and SAM.A+P >=20 > Hi all, >=20 > At the aplusp BOF, Dave Thaler presented a list of "issues in port > restricted IPs". > Imposed by the scope of the BOF, strictly limited to A+P for DS-lite, > it didn't concern other A+P scenarios. > I made the comment that this list, incidentally debatable even for A > +P/DS-lite, could be useful to analyze other variants of port-range > extension of IPv4 addresses. >=20 > Here are therefore my comments based on: > - Dave's slides, available at www.ietf.org/proceedings/09nov/slides/ > aplusp-3 - copy attached. > - my SAM.A+P proposal contained in in tools.ietf.org/id/draft-despres- > softwire-mesh-sam-01 - copy attached. >=20 > 1. (Slide 2 - Scope) > - SAM.A+P, because it applies to mesh topologies (like those of 6to4, > ISATAP and 6rd), was out of the BOF scope. > It has therefore been neither presented nor discussed. > - The analysis below is based on Dave's slides used as checklist. >=20 > 2. (Slide 3 - IP unicast model) > - True, an IPv4 address part of a SAM.A+P locator departs somewhat from > the classical IP-address model: instead of being the address of one and > only one interface, it is only used in combination with a port prefix, > and then identifies a pseudo-interface (as defined for > 6to4 in RFC 3056). > Since no such pseudo-interface participates in any ARP protocol, this > extension of the IP address model does not conflict with the one-and- > only-one rule of the IP-address model. > - Note that ND-proxies introduce a different extension of the IP model, > without this being a big issue: several interfaces, on different links, > advertise the same address as being theirs. > - Note also that that SAM.A+P, which on one hand extends the IP- > address model, restores on the other hand the E2E transparency which > had been broken by NATs. >=20 > 3. (Slide 4 - bullet 1 - Legacy hosts) > - SAM.A+P cannot, of course, be deployed on legacy hosts. > It provides additional connectivity, but only to hosts that support it. > (Support is backward compatible, and deployment is incremental). >=20 > 4. (Slide 4 - bullet 2 - port-specific applications) > - When customer sites can no longer have exclusive IPv4 addresses, no > application may rely on having any specific port. > This is common to all address sharing schemes. >=20 > 5. (Slide 5 - bullets 1 and 2 - multiple interfaces, simultaneous or > successive) > - Hosts that have several interfaces, or that roam from interface to > interface, cannot expect to have the same port if several such > interfaces access the Internet via CGNs. > This limitation, due to the IPv4 address shortage per se, is common to > all address sharing schemes. >=20 > 6. (Slide 5 bullet 3 - switching back & forth between SAM.A+P and non > SAM.A+P modes) > - The SAM DHCP option obtained or not for each interface indicates > clearly which interfaces are SAM.A+P capable and which are not. > - The lack of mobility support is common to all address sharing > schemes. >=20 > 7. (Slides 6 and 7 - Non-port-based protocols) > - The problem of incoming PINGs, and of other port-less protocols, is > common to all address sharing schemes. > - SAM.A+P hosts that have IPv6 (as they should) can be pinged in IPv6. > - Note that ICMP, which is not port based, has port numbers in its > error messages (which are the important ones in classical applications > across the Internet, in particular for MTU determination. >=20 > 8. (Slide 7 - "Pure-A+P hosts") > - To encapsulate A+P packets, a SAM.A+P host has always, in addition to > its shared IPv4 address, an interior address in a different address > family (typically IPv6). "Pure A+Ps" therefore don't exist. > Hosts always keep a legacy way to communicate, preferably IPv6. >=20 > 9. (Slide 8 - Provisioning system) > - SAM.A+P, which needs only a new DHCPv6 option, is neither complex nor > costly. > It is indeed more complex than 6rd, of which it is an extension, but > not much more, while 6rd is so simple that Free deployed it in 5 weeks. > - SAM.A+P, based on static port-prefix assignments, is not concerned > with problems of dynamic port range allocations. >=20 > 10. (Slide 9 - Training/education) > - As discussed above, the extension of the IP-address model is quite > limited, without interference with ARP. > - Training and education on SAM.A+P is marginal if combined with those > on CGNs. (Port-prefix extension of addresses, and stateless address > mappings and encapsulations, that are already familiar with 6to4, are > simple concepts; on the other hand, CGNs issues include endpoint > independent vs dependent mappings, hair-pinning, various ALGs, dynamic > port reservations with UPnP and/or NAT-PMP, port- reservation limits to > avoid DOS attacks, which are much less simple > matters.) >=20 > 11. (Slide 10 - Port randomization) > - If SAM.A+P coexists with CGNs, the SAM draft recommends that DNS > queries go to the CGN (precisely to have better port randomization, and > thus mitigate the danger of Kaminsky attacks). > - For maximum security, IPv6 should to be used, in particular to reach > DNS servers. >=20 > 12. (Slide 11 - Failure modes > - Discovering all failure modes of NATs and double NATs has been an > ordeal, as recent Teredo evolutions confirm, and it may not be > finished. > - Nothing comparable can be expected with the simple mapping and > encapsulation logic of SAM.A+P. >=20 >=20 > 13. (Slide 12 - Long term impact)) > - The fact that some people may propose to misuse a new useful new tool > shouldn't prevent this tool to be available for its normal purpose. > - Concerning NAT66, SAM is precisely a tool that makes NAT66 less > useful, if useful at all. In particular, it reconciles, in hosts that > support it, IPv6 private addressing of ULAs, multihoming, and E2E > transparency. >=20 > 12 (Slide 13 - Summary) > - SAM.A+P, which only marginally extends the IP model, is simple to > implement, to document, to deploy, and to maintain. > - While NATs, and cascades of NATs and CGNs, will inevitably continue > to be deployed, SAM.A+P can contribute to reserve their use to > scenarios where they are the less harmful. >=20 >=20 > Regards, >=20 > RD From pierre.levis@orange-ftgroup.com Thu Nov 19 23:06:18 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 319813A6A2C; Thu, 19 Nov 2009 23:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWvXLVPJ4ekV; Thu, 19 Nov 2009 23:06:17 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 816A03A6A55; Thu, 19 Nov 2009 23:06:16 -0800 (PST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 08:06:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Nov 2009 08:06:11 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [shara] "Issues in Port-Restricted IPs" and SAM.A+P Thread-Index: AQHKaFalErMc4w0eskKFwGwUcXtaRJE99jjggACURvA= References: <02773C0D-119D-4284-AF69-F86F5A1D4C8A@free.fr> From: To: , , X-OriginalArrivalTime: 20 Nov 2009 07:06:10.0758 (UTC) FILETIME=[F0708660:01CA69AF] Subject: Re: [Softwires] [shara] "Issues in Port-Restricted IPs" and SAM.A+P X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 07:06:18 -0000 This effort will really help, and it will be the opportunity to launch = an open discussion on the subject. Pierre=20 -----Message d'origine----- De : shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] De la part = de Dave Thaler Envoy=E9 : jeudi 19 novembre 2009 23:03 =C0 : shara@ietf.org; softwires@ietf.org Objet : Re: [shara] "Issues in Port-Restricted IPs" and SAM.A+P The slides intentionally didn't mention specific proposals since they vary and the slides concentrate on summarizing the issues _in general_ with the notion of "port-restricted IPs", that have been raised by=20 various people on various lists and in various discussions, but were not all in one place. Several people have requested it be turned into an Internet Draft to make points easier to discuss, and I am willing to help do so. -Dave > -----Original Message----- > From: shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] On Behalf > Of R=E9mi Despr=E9s > Sent: Wednesday, November 18, 2009 5:52 AM > To: shara@ietf.org > Cc: softwires@ietf.org > Subject: [shara] "Issues in Port-Restricted IPs" and SAM.A+P >=20 > Hi all, >=20 > At the aplusp BOF, Dave Thaler presented a list of "issues in port > restricted IPs". > Imposed by the scope of the BOF, strictly limited to A+P for DS-lite, > it didn't concern other A+P scenarios. > I made the comment that this list, incidentally debatable even for A > +P/DS-lite, could be useful to analyze other variants of port-range > extension of IPv4 addresses. >=20 > Here are therefore my comments based on: > - Dave's slides, available at www.ietf.org/proceedings/09nov/slides/ > aplusp-3 - copy attached. > - my SAM.A+P proposal contained in in tools.ietf.org/id/draft-despres- > softwire-mesh-sam-01 - copy attached. >=20 > 1. (Slide 2 - Scope) > - SAM.A+P, because it applies to mesh topologies (like those of 6to4, > ISATAP and 6rd), was out of the BOF scope. > It has therefore been neither presented nor discussed. > - The analysis below is based on Dave's slides used as checklist. >=20 > 2. (Slide 3 - IP unicast model) > - True, an IPv4 address part of a SAM.A+P locator departs somewhat = from > the classical IP-address model: instead of being the address of one = and > only one interface, it is only used in combination with a port prefix, > and then identifies a pseudo-interface (as defined for > 6to4 in RFC 3056). > Since no such pseudo-interface participates in any ARP protocol, this > extension of the IP address model does not conflict with the one-and- > only-one rule of the IP-address model. > - Note that ND-proxies introduce a different extension of the IP = model, > without this being a big issue: several interfaces, on different = links, > advertise the same address as being theirs. > - Note also that that SAM.A+P, which on one hand extends the IP- > address model, restores on the other hand the E2E transparency which > had been broken by NATs. >=20 > 3. (Slide 4 - bullet 1 - Legacy hosts) > - SAM.A+P cannot, of course, be deployed on legacy hosts. > It provides additional connectivity, but only to hosts that support = it. > (Support is backward compatible, and deployment is incremental). >=20 > 4. (Slide 4 - bullet 2 - port-specific applications) > - When customer sites can no longer have exclusive IPv4 addresses, no > application may rely on having any specific port. > This is common to all address sharing schemes. >=20 > 5. (Slide 5 - bullets 1 and 2 - multiple interfaces, simultaneous or > successive) > - Hosts that have several interfaces, or that roam from interface to > interface, cannot expect to have the same port if several such > interfaces access the Internet via CGNs. > This limitation, due to the IPv4 address shortage per se, is common to > all address sharing schemes. >=20 > 6. (Slide 5 bullet 3 - switching back & forth between SAM.A+P and non > SAM.A+P modes) > - The SAM DHCP option obtained or not for each interface indicates > clearly which interfaces are SAM.A+P capable and which are not. > - The lack of mobility support is common to all address sharing > schemes. >=20 > 7. (Slides 6 and 7 - Non-port-based protocols) > - The problem of incoming PINGs, and of other port-less protocols, is > common to all address sharing schemes. > - SAM.A+P hosts that have IPv6 (as they should) can be pinged in IPv6. > - Note that ICMP, which is not port based, has port numbers in its > error messages (which are the important ones in classical applications > across the Internet, in particular for MTU determination. >=20 > 8. (Slide 7 - "Pure-A+P hosts") > - To encapsulate A+P packets, a SAM.A+P host has always, in addition = to > its shared IPv4 address, an interior address in a different address > family (typically IPv6). "Pure A+Ps" therefore don't exist. > Hosts always keep a legacy way to communicate, preferably IPv6. >=20 > 9. (Slide 8 - Provisioning system) > - SAM.A+P, which needs only a new DHCPv6 option, is neither complex = nor > costly. > It is indeed more complex than 6rd, of which it is an extension, but > not much more, while 6rd is so simple that Free deployed it in 5 = weeks. > - SAM.A+P, based on static port-prefix assignments, is not concerned > with problems of dynamic port range allocations. >=20 > 10. (Slide 9 - Training/education) > - As discussed above, the extension of the IP-address model is quite > limited, without interference with ARP. > - Training and education on SAM.A+P is marginal if combined with those > on CGNs. (Port-prefix extension of addresses, and stateless address > mappings and encapsulations, that are already familiar with 6to4, are > simple concepts; on the other hand, CGNs issues include endpoint > independent vs dependent mappings, hair-pinning, various ALGs, dynamic > port reservations with UPnP and/or NAT-PMP, port- reservation limits = to > avoid DOS attacks, which are much less simple > matters.) >=20 > 11. (Slide 10 - Port randomization) > - If SAM.A+P coexists with CGNs, the SAM draft recommends that DNS > queries go to the CGN (precisely to have better port randomization, = and > thus mitigate the danger of Kaminsky attacks). > - For maximum security, IPv6 should to be used, in particular to reach > DNS servers. >=20 > 12. (Slide 11 - Failure modes > - Discovering all failure modes of NATs and double NATs has been an > ordeal, as recent Teredo evolutions confirm, and it may not be > finished. > - Nothing comparable can be expected with the simple mapping and > encapsulation logic of SAM.A+P. >=20 >=20 > 13. (Slide 12 - Long term impact)) > - The fact that some people may propose to misuse a new useful new = tool > shouldn't prevent this tool to be available for its normal purpose. > - Concerning NAT66, SAM is precisely a tool that makes NAT66 less > useful, if useful at all. In particular, it reconciles, in hosts that > support it, IPv6 private addressing of ULAs, multihoming, and E2E > transparency. >=20 > 12 (Slide 13 - Summary) > - SAM.A+P, which only marginally extends the IP model, is simple to > implement, to document, to deploy, and to maintain. > - While NATs, and cascades of NATs and CGNs, will inevitably continue > to be deployed, SAM.A+P can contribute to reserve their use to > scenarios where they are the less harmful. >=20 >=20 > Regards, >=20 > RD _______________________________________________ shara mailing list shara@ietf.org https://www.ietf.org/mailman/listinfo/shara From randy@psg.com Thu Nov 19 02:09:22 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B6F43A693E; Thu, 19 Nov 2009 02:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSlGvuDMTNhh; Thu, 19 Nov 2009 02:09:21 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id A61163A6831; Thu, 19 Nov 2009 02:09:21 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NB3wv-000Ppg-JY; Thu, 19 Nov 2009 10:09:13 +0000 Received: from host-40-47.meeting.ietf.org.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 1C9FF2C1F541; Thu, 19 Nov 2009 19:09:13 +0900 (JST) Date: Thu, 19 Nov 2009 19:09:13 +0900 Message-ID: From: Randy Bush To: Masataka Ohta In-Reply-To: <4B05184F.3000703@necom830.hpcl.titech.ac.jp> References: <02773C0D-119D-4284-AF69-F86F5A1D4C8A@free.fr> <4B05184F.3000703@necom830.hpcl.titech.ac.jp> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Fri, 20 Nov 2009 08:09:42 -0800 Cc: softwires@ietf.org, shara@ietf.org Subject: Re: [Softwires] [shara] "Issues in Port-Restricted IPs" and SAM.A+P X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 10:09:22 -0000 > FYI, a large ISP in Japan, maybe the world largest with regard to > the number of subscribers, use private IPv4 space of 10/8 for > its internal topology for years without any problem, which means > we have enough IPv4 address space for ISP internal use. then why are they asking for another /8 and pushing nat444? randy From mohta@necom830.hpcl.titech.ac.jp Thu Nov 19 02:12:32 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE9DA3A6831 for ; Thu, 19 Nov 2009 02:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.042 X-Spam-Level: *** X-Spam-Status: No, score=3.042 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAYx7LZdXx64 for ; Thu, 19 Nov 2009 02:12:28 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 20D893A6A74 for ; Thu, 19 Nov 2009 02:12:14 -0800 (PST) Received: (qmail 70471 invoked from network); 19 Nov 2009 10:39:12 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 19 Nov 2009 10:39:12 -0000 Message-ID: <4B05184F.3000703@necom830.hpcl.titech.ac.jp> Date: Thu, 19 Nov 2009 19:05:03 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: remi.despres@free.fr References: <02773C0D-119D-4284-AF69-F86F5A1D4C8A@free.fr> In-Reply-To: <02773C0D-119D-4284-AF69-F86F5A1D4C8A@free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 20 Nov 2009 08:09:42 -0800 Cc: softwires@ietf.org, shara@ietf.org Subject: Re: [Softwires] [shara] "Issues in Port-Restricted IPs" and SAM.A+P X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 10:12:33 -0000 Remi Despres wrote: > At the aplusp BOF, Dave Thaler presented a list of "issues in port > restricted IPs". As almost all, if not all, points of his presentation are invalid, it is a waste of time to discuss on it. Instead, if you or someone else find some of his points valid, let's discuss on it. Do you have some? I have none. > Imposed by the scope of the BOF, strictly limited to A+P for DS-lite, DS-lite? FYI, a large ISP in Japan, maybe the world largest with regard to the number of subscribers, use private IPv4 space of 10/8 for its internal topology for years without any problem, which means we have enough IPv4 address space for ISP internal use. Masataka Ohta From mohta@necom830.hpcl.titech.ac.jp Thu Nov 19 04:42:13 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 871943A69BA for ; Thu, 19 Nov 2009 04:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.042 X-Spam-Level: *** X-Spam-Status: No, score=3.042 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKp8TGVtIQzC for ; Thu, 19 Nov 2009 04:42:13 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 1364E3A6917 for ; Thu, 19 Nov 2009 04:42:12 -0800 (PST) Received: (qmail 80482 invoked from network); 19 Nov 2009 13:09:13 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 19 Nov 2009 13:09:13 -0000 Message-ID: <4B053B76.5080609@necom830.hpcl.titech.ac.jp> Date: Thu, 19 Nov 2009 21:35:02 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Randy Bush References: <02773C0D-119D-4284-AF69-F86F5A1D4C8A@free.fr> <4B05184F.3000703@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 20 Nov 2009 08:09:42 -0800 Cc: softwires@ietf.org, shara@ietf.org Subject: Re: [Softwires] [shara] "Issues in Port-Restricted IPs" and SAM.A+P X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 12:42:13 -0000 Randy Bush wrote: >>FYI, a large ISP in Japan, maybe the world largest with regard to >>the number of subscribers, use private IPv4 space of 10/8 for >>its internal topology for years without any problem, which means >>we have enough IPv4 address space for ISP internal use. > then why are they asking for another /8 and pushing nat444? Because it is, maybe, the largest ISP in the world and it needs a lot of IPv4 addresses for their subscribers, which was authorized by APNIC. The ISP is assigning two IP addresses for each subsciriber effeciently not in a way of /30 but two IP addresses from /24 or so. Anyway, /8 is too large for a single ISP that there is no worrying about on IPv4 addresses for ISP internal use. Masataka Ohta From mohta@necom830.hpcl.titech.ac.jp Thu Nov 19 14:08:36 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D5C3A67A5 for ; Thu, 19 Nov 2009 14:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.049 X-Spam-Level: ** X-Spam-Status: No, score=2.049 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvLdh5K1XhG4 for ; Thu, 19 Nov 2009 14:08:36 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id B13423A635F for ; Thu, 19 Nov 2009 14:08:35 -0800 (PST) Received: (qmail 22122 invoked from network); 19 Nov 2009 22:35:33 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 19 Nov 2009 22:35:33 -0000 Message-ID: <4B05C026.6040303@necom830.hpcl.titech.ac.jp> Date: Fri, 20 Nov 2009 07:01:10 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: remi.despres@free.fr References: <02773C0D-119D-4284-AF69-F86F5A1D4C8A@free.fr> <4B05184F.3000703@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 20 Nov 2009 08:09:42 -0800 Cc: softwires@ietf.org, shara@ietf.org Subject: Re: [Softwires] [shara] "Issues in Port-Restricted IPs" and SAM.A+P X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 22:08:36 -0000 Remi Despres wrote: > As you can note if you read what I wrote, I used Dave's point only as a > check list to show that, in the particular case of SAM.A+P I work on, > they are not valid. That's fine but so obvious. > Sorry if you are a video-game fan. My children are. >> FYI, a large ISP in Japan, maybe the world largest with regard to >> the number of subscribers, use private IPv4 space of 10/8 for >> its internal topology for years without any problem, which means >> we have enough IPv4 address space for ISP internal use. > Could you be more specific on how this relates to A+P ? Private IPv4 addresses for ISP internal use means there is no point of DS-lite to save public IPv4 addresses for ISP internal use. ISPs can internally use IPv4 addresses forever, even after public IPv4 addresses are exhausted. If we have enough IPv4 addresses for customers but not for ISP internal routers, we can still enjoy traditional IPv4 networking without port restriction. If we don't, with port restriction, we can still enjoy traditional IPv4 networking without any real problem. Masataka Ohta From behcetsarikaya@yahoo.com Fri Nov 20 12:33:35 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91F453A6848 for ; Fri, 20 Nov 2009 12:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKGVe9nhi5ES for ; Fri, 20 Nov 2009 12:33:34 -0800 (PST) Received: from web111408.mail.gq1.yahoo.com (web111408.mail.gq1.yahoo.com [67.195.15.174]) by core3.amsl.com (Postfix) with SMTP id 6CA9828C0E5 for ; Fri, 20 Nov 2009 12:33:34 -0800 (PST) Received: (qmail 50833 invoked by uid 60001); 20 Nov 2009 20:33:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1258749209; bh=ig3uv2QhbATL9Ghxb4zkNxvNeAWueMdWOiEQ2DqQUek=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ugcjw7THELO71pDnZYxnfXJ0wXP19q78ValkofUmzJKymjH3JDUSa5kHw/SczHEBSiwpfXiYGz23y5mwE2acv8UfLpAZJbzeGguNPPN9ZvF4KNouse5RZdzUIR0f4bUiXLp+ws6YuLuQK/BRfuLKzwIc6tHuxJ7Q/5+IftGfcDQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=MVHVttFLqbmUH206DIdy+H0MeaS6OJNCZolqIHDJ/0CPNCuZyZBMS2T+AMWoB8VPt14G7Om+ukswpcbmGtYmas3j1lwqIf9fKwB7/VKxH59BXw2bxN7wpgXwzFaVPa+9mkcRdDNAMk4vuMlXcVHOldBeCtc4IOVVyaVDxwA848M=; Message-ID: <324608.49303.qm@web111408.mail.gq1.yahoo.com> X-YMail-OSG: ojuO6YsVM1nJzPQyofPsUt2rZj.Dvrbm362lsyvzDgV90o2kRh86IKjhp6Y5gIvLPfZBfnVYLEQ0bp_U5Ah9plOoiLk46QOWFv5tI8sdvBo6wnejRdGHxHZZ.BJDphh__tayETkbdg63FO57ZzO7ANXtJgmBGnEbe3M0lopxd56M5CCYseHozouyarhIfbgMsT6r9gr_zHa8NC5pV7YKSivJIwczey_pUeEDb7pQeWSZR9ElJiomCWxV7JCJqFXKvl2z.9oRNfYgP4IXkF0IGC18wv_TQir6emv4G3cZW7sbn9zb.D_rJlC.y5s1dkIKJc7ofVWouuaHRoeNykOmMey7MJ68su0c6z_sxf.eu77rLn3m14JoQA-- Received: from [206.16.17.212] by web111408.mail.gq1.yahoo.com via HTTP; Fri, 20 Nov 2009 12:33:29 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.8.100.260964 References: <02773C0D-119D-4284-AF69-F86F5A1D4C8A@free.fr> Date: Fri, 20 Nov 2009 12:33:29 -0800 (PST) From: Behcet Sarikaya To: Dave Thaler , "shara@ietf.org" , "softwires@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Softwires] [shara] "Issues in Port-Restricted IPs" and SAM.A+P X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 20:33:35 -0000 Hi Dave,=0A=A0 After the meeting I talked to Dan. Our conclusion was what y= ou mentioned below, please publish your slides in draft format. In IETF we = can do drafts, and drafts only :).=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A---= -- Original Message ----=0A> From: Dave Thaler =0A> = To: "shara@ietf.org" ; "softwires@ietf.org" =0A> Sent: Thu, November 19, 2009 4:03:05 PM=0A> Subject: Re: [shara] = "Issues in Port-Restricted IPs" and SAM.A+P=0A> =0A> The slides intentional= ly didn't mention specific proposals since they=0A> vary and the slides con= centrate on summarizing the issues _in general_=0A> with the notion of "por= t-restricted IPs", that have been raised by =0A> various people on various = lists and in various discussions, but were=0A> not all in one place.=0A> = =0A> Several people have requested it be turned into an Internet Draft to= =0A> make points easier to discuss, and I am willing to help do so.=0A> =0A= > -Dave=0A> =0A> > -----Original Message-----=0A> > From: shara-bounces@iet= f.org [mailto:shara-bounces@ietf.org] On Behalf=0A> > Of R=E9mi Despr=E9s= =0A> > Sent: Wednesday, November 18, 2009 5:52 AM=0A> > To: shara@ietf.org= =0A> > Cc: softwires@ietf.org=0A> > Subject: [shara] "Issues in Port-Restri= cted IPs" and SAM.A+P=0A> > =0A> > Hi all,=0A> > =0A> > At the aplusp BOF, = Dave Thaler presented a list of "issues in port=0A> > restricted IPs".=0A> = > Imposed by the scope of the BOF, strictly limited to A+P for DS-lite,=0A>= > it didn't concern other A+P scenarios.=0A> > I made the comment that thi= s list, incidentally debatable even for A=0A> > +P/DS-lite, could be useful= to analyze other variants of port-range=0A> > extension of IPv4 addresses.= =0A> > =0A> > Here are therefore my comments based on:=0A> > - Dave's slide= s, available at www.ietf.org/proceedings/09nov/slides/=0A> > aplusp-3 - cop= y attached.=0A> > - my SAM.A+P proposal contained in in tools.ietf.org/id/d= raft-despres-=0A> > softwire-mesh-sam-01 - copy attached.=0A> > =0A> > 1. (= Slide 2 - Scope)=0A> > - SAM.A+P, because it applies to mesh topologies (li= ke those of 6to4,=0A> > ISATAP and 6rd), was out of the BOF scope.=0A> > It= has therefore been neither presented nor discussed.=0A> > - The analysis b= elow is based on Dave's slides used as checklist.=0A> > =0A> > 2. (Slide 3 = - IP unicast model)=0A> > - True, an IPv4 address part of a SAM.A+P locator= departs somewhat from=0A> > the classical IP-address model: instead of bei= ng the address of one and=0A> > only one interface, it is only used in comb= ination with a port prefix,=0A> > and then identifies a pseudo-interface (a= s defined for=0A> > 6to4 in RFC 3056).=0A> > Since no such pseudo-interface= participates in any ARP protocol, this=0A> > extension of the IP address m= odel does not conflict with the one-and-=0A> > only-one rule of the IP-addr= ess model.=0A> > - Note that ND-proxies introduce a different extension of = the IP model,=0A> > without this being a big issue: several interfaces, on = different links,=0A> > advertise the same address as being theirs.=0A> > - = Note also that that SAM.A+P, which on one hand extends the IP-=0A> > addres= s model, restores on the other hand the E2E transparency which=0A> > had be= en broken by NATs.=0A> > =0A> > 3. (Slide 4 - bullet 1 - Legacy hosts)=0A> = > - SAM.A+P cannot, of course, be deployed on legacy hosts.=0A> > It provid= es additional connectivity, but only to hosts that support it.=0A> > (Suppo= rt is backward compatible, and deployment is incremental).=0A> > =0A> > 4. = (Slide 4 - bullet 2 - port-specific applications)=0A> > - When customer sit= es can no longer have exclusive IPv4 addresses, no=0A> > application may re= ly on having any specific port.=0A> > This is common to all address sharing= schemes.=0A> > =0A> > 5. (Slide 5 - bullets 1 and 2 - multiple interfaces,= simultaneous or=0A> > successive)=0A> > - Hosts that have several interfac= es, or that roam from interface to=0A> > interface, cannot expect to have t= he same port if several such=0A> > interfaces access the Internet via CGNs.= =0A> > This limitation, due to the IPv4 address shortage per se, is common = to=0A> > all address sharing schemes.=0A> > =0A> > 6. (Slide 5 bullet 3 - s= witching back & forth between SAM.A+P and non=0A> > SAM.A+P modes)=0A> > - = The SAM DHCP option obtained or not for each interface indicates=0A> > clea= rly which interfaces are SAM.A+P capable and which are not.=0A> > - The lac= k of mobility support is common to all address sharing=0A> > schemes.=0A> >= =0A> > 7. (Slides 6 and 7 - Non-port-based protocols)=0A> > - The problem = of incoming PINGs, and of other port-less protocols, is=0A> > common to all= address sharing schemes.=0A> > - SAM.A+P hosts that have IPv6 (as they sho= uld) can be pinged in IPv6.=0A> > - Note that ICMP, which is not port based= , has port numbers in its=0A> > error messages (which are the important one= s in classical applications=0A> > across the Internet, in particular for MT= U determination.=0A> > =0A> > 8. (Slide 7 - "Pure-A+P hosts")=0A> > - To en= capsulate A+P packets, a SAM.A+P host has always, in addition to=0A> > its = shared IPv4 address, an interior address in a different address=0A> > famil= y (typically IPv6). "Pure A+Ps" therefore don't exist.=0A> > Hosts always k= eep a legacy way to communicate, preferably IPv6.=0A> > =0A> > 9. (Slide 8 = - Provisioning system)=0A> > - SAM.A+P, which needs only a new DHCPv6 optio= n, is neither complex nor=0A> > costly.=0A> > It is indeed more complex tha= n 6rd, of which it is an extension, but=0A> > not much more, while 6rd is s= o simple that Free deployed it in 5 weeks.=0A> > - SAM.A+P, based on static= port-prefix assignments, is not concerned=0A> > with problems of dynamic p= ort range allocations.=0A> > =0A> > 10. (Slide 9 - Training/education)=0A> = > - As discussed above, the extension of the IP-address model is quite=0A> = > limited, without interference with ARP.=0A> > - Training and education on= SAM.A+P is marginal if combined with those=0A> > on CGNs. (Port-prefix ext= ension of addresses, and stateless address=0A> > mappings and encapsulation= s, that are already familiar with 6to4, are=0A> > simple concepts; on the o= ther hand, CGNs issues include endpoint=0A> > independent vs dependent mapp= ings, hair-pinning, various ALGs, dynamic=0A> > port reservations with UPnP= and/or NAT-PMP, port- reservation limits to=0A> > avoid DOS attacks, which= are much less simple=0A> > matters.)=0A> > =0A> > 11. (Slide 10 -=A0 Port = randomization)=0A> > - If SAM.A+P coexists with CGNs, the SAM draft recomme= nds that DNS=0A> > queries go to the CGN (precisely to have better port ran= domization, and=0A> > thus mitigate the danger of Kaminsky attacks).=0A> > = - For maximum security, IPv6 should to be used, in particular to reach=0A> = > DNS servers.=0A> > =0A> > 12. (Slide 11 - Failure modes=0A> > - Discoveri= ng all failure modes of NATs and double NATs has been an=0A> > ordeal, as r= ecent Teredo evolutions confirm, and it may not be=0A> > finished.=0A> > - = Nothing comparable can be expected with the simple mapping and=0A> > encaps= ulation logic of SAM.A+P.=0A> > =0A> > =0A> > 13. (Slide 12 -=A0 Long term = impact))=0A> > - The fact that some people may propose to misuse a new usef= ul new tool=0A> > shouldn't prevent this tool to be available for its norma= l purpose.=0A> > - Concerning NAT66, SAM is precisely a tool that makes NAT= 66 less=0A> > useful, if useful at all. In particular, it reconciles, in ho= sts that=0A> > support it, IPv6 private addressing of ULAs, multihoming, an= d E2E=0A> > transparency.=0A> > =0A> > 12 (Slide 13 - Summary)=0A> > - SAM.= A+P, which only marginally extends the IP model, is simple to=0A> > impleme= nt, to document, to deploy, and to maintain.=0A> > - While NATs, and cascad= es of NATs and CGNs, will inevitably continue=0A> > to be deployed, SAM.A+P= can contribute to reserve their use to=0A> > scenarios where they are the = less harmful.=0A> > =0A> > =0A> > Regards,=0A> > =0A> > RD=0A> =0A> _______= ________________________________________=0A> shara mailing list=0A> shara@i= etf.org=0A> https://www.ietf.org/mailman/listinfo/shara=0A=0A=0A=0A From denghui02@gmail.com Sun Nov 22 23:19:15 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6A9D3A69FD for ; Sun, 22 Nov 2009 23:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jrzjzs4qG4nM for ; Sun, 22 Nov 2009 23:19:11 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 14CC93A69FC for ; Sun, 22 Nov 2009 23:19:11 -0800 (PST) Received: by pzk6 with SMTP id 6so3575231pzk.29 for ; Sun, 22 Nov 2009 23:19:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=G44gc8xa2ZelzoRUUkf9JbwcenonUXD4ds9gvFa/k7w=; b=L3dS4hwnDIXs63FwQm7VvMSUZ3/v5LVIrqWMuhIKOXJzq5XDRJ5YYF56U72aBfTiW6 KGzP7u559Q613deyEi0lcTvcVr0nzhG3XRt/oeA56YG8YFArVyT4Pr+nlSWCqOqyyWoT yv5VCMh3zHxNFOojaGFkKE9/6k9CY2//j5qvE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=Yik+JeTpjG/xF0D6xn5ETWw74EmSt3efIIZ0edA9bX1OqkwtGNDiYUsvyuCRKmtRq5 GBFP1HZSoLqSBm7mOAgtIulTNxpdMgGQCMFqVucUsRMyIjlnzFZv9H64RBfE87eE3z0M cx7grWgfvsqV/z7VakBnWfwBAiuNfNagXNQng= MIME-Version: 1.0 Received: by 10.140.225.9 with SMTP id x9mr263222rvg.175.1258960744797; Sun, 22 Nov 2009 23:19:04 -0800 (PST) Date: Mon, 23 Nov 2009 15:19:04 +0800 Message-ID: <1d38a3350911222319p20913cd7lb21a00fa1971cd61@mail.gmail.com> From: Hui Deng To: "Durand, Alain" , Sri Gundavelli , fengcao@chinamobile.com, "Cao,Zhen" Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 23 Nov 2009 06:39:34 -0800 Cc: =?GB2312?B?wfW088X0?= , =?GB2312?B?s8K41Q==?= , =?GB2312?B?1tyyqQ==?= , softwires@ietf.org Subject: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 07:19:15 -0000 Dear Alain and Sri, I guess that you two have already read below draft: http://tools.ietf.org/id/draft-cao-behave-hbt-req-00.txt This draft has been presented in detail during the last IETF meeting. During the meeting, you two have standed up and said that DS-Lite and GW-Init-DS-Lite could also meet the requirement of host to host direct communication. I really cann't understand it, could you help to elbaroate more here about details? Many thanks for your kind explanation. Best regards, -Hui Deng From alain_durand@cable.comcast.com Mon Nov 23 08:54:03 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEA613A682D for ; Mon, 23 Nov 2009 08:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.601 X-Spam-Level: *** X-Spam-Status: No, score=3.601 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6cUu6TMWALx for ; Mon, 23 Nov 2009 08:54:01 -0800 (PST) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id D8ADE28C0EF for ; Mon, 23 Nov 2009 08:54:00 -0800 (PST) Received: from ([24.40.15.118]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.82971144; Mon, 23 Nov 2009 11:53:42 -0500 Received: from PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 11:53:43 -0500 Received: from 198.137.252.126 ([198.137.252.126]) by PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) via Exchange Front-End Server webmail.comcast.com ([198.137.252.77]) with Microsoft Exchange Server HTTP-DAV ; Mon, 23 Nov 2009 16:53:43 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 23 Nov 2009 11:53:41 -0500 From: "Durand, Alain" To: Hui Deng , Sri Gundavelli , , "Cao,Zhen" Message-ID: Thread-Topic: Discussion on the requirements of Host Based Translation Thread-Index: AcpsXYJ1weRbvR5hHE2zXTV1Lcm9Ow== In-Reply-To: <1d38a3350911222319p20913cd7lb21a00fa1971cd61@mail.gmail.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3341822021_6328514" X-OriginalArrivalTime: 23 Nov 2009 16:53:43.0864 (UTC) FILETIME=[842ADB80:01CA6C5D] X-Mailman-Approved-At: Mon, 23 Nov 2009 08:55:02 -0800 Cc: liudapeng@chinamobile.com, chengang@chinamobile.com, zhouboyj@chinamobile.com, softwires@ietf.org Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 16:54:04 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3341822021_6328514 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hui, If I understand your requirements: 1. v6 only network=20 2. v4 apps=20 3. low encap overhead 4. direct =B3shortcut=B2 communications between 2 adjacent nodes 1 & 2 are already met by the current DS-lite 3 is a matter of opinion... Is an extra IPv4 header (20 byte) that much of = a deal? When we looked at softwire hub&spoke a few years back, the wg consensus was that the extra overhead of encapsulation was worth it. You can use some form of header compression to mitigate this overhead. How to use header compression in that case can be defined in softwire 4 could be a very straightforward extension of DS-lite. If you know the common IPv6 prefix shared by adjacent nodes, you can directly tunnel to them. In practice, you=B9ll have a default route to the AFTR and a subnet route for the =B3local=B2 prefix. - Alain. On 11/23/09 2:19 AM, "Hui Deng" wrote: > Dear Alain and Sri, >=20 > I guess that you two have already read below draft: > http://tools.ietf.org/id/draft-cao-behave-hbt-req-00.txt > This draft has been presented in detail during the last IETF meeting. >=20 > During the meeting, you two have standed up and said that > DS-Lite and GW-Init-DS-Lite could also meet the requirement of host to > host direct communication. > I really cann't understand it, could you help to elbaroate more here > about details? >=20 > Many thanks for your kind explanation. > Best regards, >=20 > -Hui Deng >=20 --B_3341822021_6328514 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: Discussion on the requirements of Host Based Translation Hui,

If I understand your requirements:
  1. v6 only network=20
  2. v4 apps=20
  3. low encap overhead=20
  4. direct “shortcut” communications between 2 a= djacent nodes

1 & 2 are already met by the current DS-lite
3 is a matter of opinion... Is an extra IPv4 header (20 byte) that much of = a deal?
When we looked at softwire hub&spoke a few years back, the wg consensus= was that the extra overhead of encapsulation was worth it.
You can use some form of header compression to mitigate this overhead. How = to use header compression in that case can be defined in softwire
4 could be a very straightforward extension of DS-lite. If you know the com= mon IPv6 prefix shared by adjacent nodes, you can directly tunnel to them. In practice, you’ll have a default route to the AFTR and a subnet rou= te for the “local” prefix.

  - Alain.



On 11/23/09 2:19 AM, "Hui Deng" <denghui02@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Dear Alain and Sri,

I guess that you two have already read below draft:
http://t= ools.ietf.org/id/draft-cao-behave-hbt-req-00.txt
This draft has been presented in detail during the last IETF meeting.

During the meeting, you two have standed up and said that
DS-Lite and GW-Init-DS-Lite could also meet the requirement of host to
host direct communication.
I really cann't understand it, could you help to elbaroate more here
about details?

Many thanks for your kind explanation.
Best regards,

-Hui Deng

--B_3341822021_6328514-- From dwing@cisco.com Mon Nov 23 09:17:25 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEA343A6830 for ; Mon, 23 Nov 2009 09:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.945 X-Spam-Level: X-Spam-Status: No, score=-5.945 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1uMVH18RbbJ for ; Mon, 23 Nov 2009 09:17:25 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0387B3A681E for ; Mon, 23 Nov 2009 09:17:25 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAOFSCkurRN+K/2dsb2JhbACKMrV+lnyEPAQ X-IronPort-AV: E=Sophos;i="4.47,273,1257120000"; d="scan'208";a="52907119" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 23 Nov 2009 17:17:09 +0000 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nANHH8pd017250; Mon, 23 Nov 2009 17:17:09 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Despr=E9s'?=" , "'Dave Thaler'" References: <0A4D7242-7CBC-4068-9722-399C271659FC@free.fr> Date: Mon, 23 Nov 2009 09:17:08 -0800 Message-ID: <02b101ca6c60$c99f9720$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acpnc84X9L7LGE/DRZKrwI/G68XIxAE7H+kA In-Reply-To: <0A4D7242-7CBC-4068-9722-399C271659FC@free.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: softwires@ietf.org, draft-ford-shared-addressing-issues@tools.ietf.org Subject: Re: [Softwires] SRV and port 80 in MS-IE? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 17:17:26 -0000 =20 > -----Original Message----- > From: softwires-bounces@ietf.org=20 > [mailto:softwires-bounces@ietf.org] On Behalf Of R=E9mi Despr=E9s > Sent: Tuesday, November 17, 2009 2:50 AM > To: Dave Thaler > Cc: softwires@ietf.org > Subject: [Softwires] SRV and port 80 in MS-IE? >=20 > Dave, >=20 > draft-ford-shared-addressing-issues-01/sec 4.2.2 mentions port 80 in =20 > its example of SRV usage. >=20 > I didn't find whether MS IE supports SRVs. > Would you know the answer? It doesn't. Please see http://tools.ietf.org/html/draft-jennings-http-srv-00 (yes, specifically the -00 version) and Ted Hardie's and John Klensin's response at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00095.html http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00096.html The authors of draft-ford-shared-addressing-issues may want to pull that reference from Section 4.2.2, or tighten it up. As is, the second paragraph in Section 4.2.2 implies that SRV could be used with HTTP; at this point in time, consensus appears to be that such use is dis-allowed. -d From remi.despres@free.fr Mon Nov 23 09:26:33 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A55803A6AB6 for ; Mon, 23 Nov 2009 09:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.529 X-Spam-Level: X-Spam-Status: No, score=-1.529 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuFY-QBFK9FJ for ; Mon, 23 Nov 2009 09:26:32 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id BB68D3A6AB1 for ; Mon, 23 Nov 2009 09:26:31 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id E503FE0819F for ; Mon, 23 Nov 2009 18:26:24 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 0F622E08243 for ; Mon, 23 Nov 2009 18:26:22 +0100 (CET) From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Nov 2009 18:26:20 +0100 Message-Id: <8635DB4D-4178-47C4-A59E-54B2B75B46AA@free.fr> To: softwires@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [Softwires] "Issues in Port-Restricted IPs" and SAM.A+P X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 17:26:33 -0000 Hi all, A mail on *"Issues in Port-Restricted IPs" and SAM.A+P* was sent = successfully sent to the Shara list but was too big for a copy to reach = the Softwire list. You can see it at=20 http://www.ietf.org/mail-archive/web/shara/current/msg00216.html Regards, RD= From jhw@apple.com Mon Nov 23 10:10:26 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74BB43A697E for ; Mon, 23 Nov 2009 10:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NlVJw8oU+6D for ; Mon, 23 Nov 2009 10:10:25 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id B29553A6969 for ; Mon, 23 Nov 2009 10:10:25 -0800 (PST) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id 3BF9B8056D73; Mon, 23 Nov 2009 10:10:21 -0800 (PST) X-AuditID: 11807134-b7cd9ae000001002-40-4b0ad00ddcaf Received: from il0602a-dhcp117.apple.com (il0602a-dhcp117.apple.com [17.206.23.245]) (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 B9.58.04098.D00DA0B4; Mon, 23 Nov 2009 10:10:21 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1077) From: james woodyatt In-Reply-To: Date: Mon, 23 Nov 2009 10:10:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Alain Durand , ietf softwire X-Mailer: Apple Mail (2.1077) X-Brightmail-Tracker: AAAAAQAAAZE= Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 18:10:26 -0000 On Nov 23, 2009, at 08:53, Durand, Alain wrote: >=20 > 4 could be a very straightforward extension of DS-lite. If you know = the common IPv6 prefix shared by adjacent nodes, you can directly tunnel = to them. > In practice, you=92ll have a default route to the AFTR and a subnet = route for the =93local=94 prefix. Also, to support the direct host-to-host tunneling, the DS-lite = extension would need to allow for many DS-lite subscribers to share a = single IPv4 private address realm. I think DS-lite currently requires = that each IPv6 subscriber is isolated within their own IPv4 private = address realm, and therefore a twice-NAT44 gateway is required for = IPv4-only applications to communicate between DS-lite subscribers. -- james woodyatt member of technical staff, communications engineering From alain_durand@cable.comcast.com Mon Nov 23 11:30:40 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CE3F3A69E9 for ; Mon, 23 Nov 2009 11:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3 X-Spam-Level: *** X-Spam-Status: No, score=3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDEFEy5N9jf6 for ; Mon, 23 Nov 2009 11:30:39 -0800 (PST) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 4787E28C1A0 for ; Mon, 23 Nov 2009 11:30:39 -0800 (PST) Received: from ([10.52.116.30]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.82986904; Mon, 23 Nov 2009 14:30:16 -0500 Received: from PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 14:30:16 -0500 Received: from 71.230.252.107 ([71.230.252.107]) by PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Mon, 23 Nov 2009 19:30:16 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 23 Nov 2009 14:30:13 -0500 From: "Durand, Alain" To: james woodyatt , ietf softwire Message-ID: Thread-Topic: [Softwires] Discussion on the requirements of Host Based Translation Thread-Index: Acpsc2CHf0sel/6YGUiylO1X9RuU1Q== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 23 Nov 2009 19:30:16.0525 (UTC) FILETIME=[62A12FD0:01CA6C73] Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 19:30:40 -0000 Yes... Whenever you do the shortcuts, you bump into the non trivial questions to know who you are talking to... Now, if v4 addresses are allocated via DHCPv4 over the IPv6 tunnel, this problem can be solved. Is it worth the effort or not depend on how much the shortcuts are going to save you... - Alain. On 11/23/09 1:10 PM, "james woodyatt" wrote: > On Nov 23, 2009, at 08:53, Durand, Alain wrote: >>=20 >> 4 could be a very straightforward extension of DS-lite. If you know the >> common IPv6 prefix shared by adjacent nodes, you can directly tunnel to = them. >> In practice, you=B9ll have a default route to the AFTR and a subnet route = for >> the =B3local=B2 prefix. >=20 > Also, to support the direct host-to-host tunneling, the DS-lite extension > would need to allow for many DS-lite subscribers to share a single IPv4 > private address realm. I think DS-lite currently requires that each IPv6 > subscriber is isolated within their own IPv4 private address realm, and > therefore a twice-NAT44 gateway is required for IPv4-only applications to > communicate between DS-lite subscribers. >=20 >=20 > -- > james woodyatt > member of technical staff, communications engineering >=20 >=20 From jan@go6.si Mon Nov 23 15:34:42 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 901AD3A6AEA for ; Mon, 23 Nov 2009 15:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PPaKH5d2Hgh for ; Mon, 23 Nov 2009 15:34:41 -0800 (PST) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by core3.amsl.com (Postfix) with ESMTP id BA9E93A6AF2 for ; Mon, 23 Nov 2009 15:34:38 -0800 (PST) Received: from [IPv6:2001:470:d422::219:e3ff:fed4:9252] (unknown [IPv6:2001:470:d422:0:219:e3ff:fed4:9252]) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id DD74922B4069 for ; Tue, 24 Nov 2009 00:34:30 +0100 (CET) Message-ID: <4B0B1C04.6080206@go6.si> Date: Tue, 24 Nov 2009 00:34:28 +0100 From: "Jan Zorz @ go6.si" Organization: go6.si User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: softwires@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 23:34:42 -0000 On 23.11.09 20:30, Durand, Alain wrote: > Yes... Whenever you do the shortcuts, you bump into the non trivial > questions to know who you are talking to... > Now, if v4 addresses are allocated via DHCPv4 over the IPv6 tunnel, this > problem can be solved. Is it worth the effort or not depend on how much the > shortcuts are going to save you... Agree. Bumped hard into that once... :) Jan Zorz From sgundave@cisco.com Mon Nov 23 16:20:03 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A0D528C0F0 for ; Mon, 23 Nov 2009 16:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26368HX9Wp86 for ; Mon, 23 Nov 2009 16:20:01 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id DEF7A28C0EC for ; Mon, 23 Nov 2009 16:20:01 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AokFAPe1CkurRN+J/2dsb2JhbACQRQGuY5dThDwEgXA X-IronPort-AV: E=Sophos;i="4.47,274,1257120000"; d="scan'208";a="108579113" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 24 Nov 2009 00:19:58 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nAO0JvdT028390; Tue, 24 Nov 2009 00:19:57 GMT Date: Mon, 23 Nov 2009 16:19:57 -0800 (PST) From: Sri Gundavelli To: Hui Deng Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: softwires@ietf.org Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation (fwd) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 00:20:03 -0000 Hi Hui, Adding to what Alain already said. When you projected the slide that compared various transition approaches, for the UE to UE bullet point, for the Gateway Initiated Dual-stack lite solution, you have marked it as "Unsupported or No". So, I asked the question, is it for over-lapping or a non-overlapping case and from our conversations offline and online both at Shanghai and at the IETF, you said it was about non-overlapping case. Now, for this case, in the proposal we have, any IPv4 traffic from the UE, always hits the GGSN over the mobility tunnel. At the GGSN, its a routing decision to forward the traffic to the internet via CGN, over the CGN tunnel, or local foward. If its a local forward, the packet is routed to the target UE/SGSN over a different mobility tunnel. The GGSN is the anchor and all traffic goes through that point and it can local forward. That's how we can support this scenario. For the case of overlapping IP, we talked to many operators and no one confirmed that they have a legacy application that are supported in this mode. So, the general thought was to have a sensible approach of using IPv6 transport for such applications. Now, if we argue that we need to support over IPv4 transport, we need to ask many questions, as how the application resolution happens, how the application server delivers that information and how it learns the NAT'd address of a UE ..etc. These are unresolved questions both as a requirement and even for PNAT if you pitch a solution based on host translation. As I see it, its a new requirement and as Alain/Dan Wing pointed out, there are potential ways to solve it. In simple terms, what ever you do on the host, we can infact solve it on the network. Now, moving to your other pointer and the motivation for the PNAT work, you have listed: a.) a need to support IPv6-only transport network b.) support IPv4 legacy applications, over a IPv6 transport c.) avoid airlink over-ahead d.) enable UE to UE comminication. For #a and #b, mobility architectures and the solution we have allow the case where the access network and the core network is either IPv4 or IPv6. There is no issue on this aspect. For #c, our solution does not introduce any air link over-ahead, as there is no tunnel from the UE. We dont have the host architecture, or touch the UE. For #d, the solution can support UE to UE over IPv4 or IPv6 transport, for the non-overlapping case. For overlapping case, we will plug in the feature as needed. Also, I'd like to remind that your slide missed number of other bullet points, for example, it should have had a bullet point, "Changes to host architecture", with a marking "Yes" to PNAT solution, and "No" to Gateway Initiated Dual-stack lite solution. Since, its not a trivial design point that you can ignore. Regards Sri On Mon, 23 Nov 2009, Hui Deng wrote: > Dear Alain and Sri, > > I guess that you two have already read below draft: > http://tools.ietf.org/id/draft-cao-behave-hbt-req-00.txt > This draft has been presented in detail during the last IETF meeting. > > During the meeting, you two have standed up and said that > DS-Lite and GW-Init-DS-Lite could also meet the requirement of host to > host direct communication. > I really cann't understand it, could you help to elbaroate more here > about details? > > Many thanks for your kind explanation. > Best regards, > > -Hui Deng > From Fred.L.Templin@boeing.com Mon Nov 23 16:47:32 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFA903A688B for ; Mon, 23 Nov 2009 16:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3RNvmCRpH+K for ; Mon, 23 Nov 2009 16:47:32 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 0491C3A6778 for ; Mon, 23 Nov 2009 16:47:31 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id nAO0lPqr005201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Nov 2009 16:47:25 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id nAO0lPG4012934 for ; Mon, 23 Nov 2009 16:47:25 -0800 (PST) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id nAO0lO7E012929 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Mon, 23 Nov 2009 16:47:25 -0800 (PST) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Mon, 23 Nov 2009 16:47:24 -0800 From: "Templin, Fred L" To: "softwires@ietf.org" Date: Mon, 23 Nov 2009 16:47:25 -0800 Thread-Topic: DHCP option and IPv4 Anycast for ISATAP Thread-Index: Acpsm+yhJkmi2SnlQe+dE+TVZNraiwAApR7g Message-ID: <12F4112206976147A34FEC0277597CCF27A5334CC0@XCH-NW-15V.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Softwires] DHCP option and IPv4 Anycast for ISATAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 00:47:32 -0000 Hi, I decided to renew my 6yr old expired draft on a DHCPv4 option for ISATAP: http://tools.ietf.org/html/draft-templin-isatap-dhcp-03 At the same time, I brought back the concept of IPv4 anycast for ISATAP router discover that was present in the initial ISATAP specs in the NGTRANS wg beginning with 'draft-ietf-ngtrans-isatap-00.txt'. This document could be compared for consistency with other softwires works on similar topics. For example, whether the border router should use the IPv4 anycast address or one of its unicast addresses as the source of ip-proto-41 packets is an interesting question. The answer may very well be: "it depends...". Fred fred.l.templin@boeing.com=20 From guoseu@huawei.com Tue Nov 24 00:10:56 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6C3A3A6B57 for ; Tue, 24 Nov 2009 00:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7hX8D0xQtPT for ; Tue, 24 Nov 2009 00:10:55 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 5FFC93A6841 for ; Tue, 24 Nov 2009 00:10:55 -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 <0KTL00A5RTDFK0@szxga04-in.huawei.com> for softwires@ietf.org; Tue, 24 Nov 2009 16:10:27 +0800 (CST) Received: from 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 <0KTL00DUTTDF6M@szxga04-in.huawei.com> for softwires@ietf.org; Tue, 24 Nov 2009 16:10:27 +0800 (CST) Received: from g57775 ([10.111.12.203]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KTL006ZCTDFJL@szxml06-in.huawei.com> for softwires@ietf.org; Tue, 24 Nov 2009 16:10:27 +0800 (CST) Date: Tue, 24 Nov 2009 16:10:27 +0800 From: Dayong Guo In-reply-to: <12F4112206976147A34FEC0277597CCF27A5334CC0@XCH-NW-15V.nw.nos.boeing.com> To: "'Templin, Fred L'" , softwires@ietf.org Message-id: <001501ca6cdd$94d35310$cb0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acpsm+yhJkmi2SnlQe+dE+TVZNraiwAApR7gAA92NPA= Subject: Re: [Softwires] DHCP option and IPv4 Anycast for ISATAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 08:10:56 -0000 Hi, Fred: Why do both IP address and FQDNs appear in ISATAP DHCP option? I think that one of them is enough. Dayong Guo > -----Original Message----- > From: softwires-bounces@ietf.org > [mailto:softwires-bounces@ietf.org] On Behalf Of Templin, Fred L > Sent: Tuesday, November 24, 2009 8:47 AM > To: softwires@ietf.org > Subject: [Softwires] DHCP option and IPv4 Anycast for ISATAP > > Hi, > > I decided to renew my 6yr old expired draft on a DHCPv4 > option for ISATAP: > > http://tools.ietf.org/html/draft-templin-isatap-dhcp-03 > > At the same time, I brought back the concept of IPv4 anycast > for ISATAP router discover that was present in the initial > ISATAP specs in the NGTRANS wg beginning with > 'draft-ietf-ngtrans-isatap-00.txt'. > > This document could be compared for consistency with other > softwires works on similar topics. For example, whether the > border router should use the IPv4 anycast address or one of > its unicast addresses as the source of ip-proto-41 packets is > an interesting question. > The answer may very well be: "it depends...". > > Fred > fred.l.templin@boeing.com > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From remi.despres@free.fr Mon Nov 23 09:06:41 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6225B3A6923 for ; Mon, 23 Nov 2009 09:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.571 X-Spam-Level: X-Spam-Status: No, score=0.571 tagged_above=-999 required=5 tests=[AWL=-2.520, BAYES_50=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtNx+rSpPsQQ for ; Mon, 23 Nov 2009 09:06:37 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 48C7128C13E for ; Mon, 23 Nov 2009 09:06:33 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 5F9ECE08208 for ; Mon, 23 Nov 2009 18:06:26 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 73096E08229 for ; Mon, 23 Nov 2009 18:06:22 +0100 (CET) From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: multipart/mixed; boundary=Apple-Mail-24--631577019 Date: Mon, 23 Nov 2009 18:06:20 +0100 References: <02773C0D-119D-4284-AF69-F86F5A1D4C8A@free.fr> To: softwires@ietf.org Message-Id: <2449924D-EA66-445B-BFC0-C3B52622CEA3@free.fr> Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-Mailman-Approved-At: Tue, 24 Nov 2009 08:28:18 -0800 Subject: [Softwires] Fwd: "Issues in Port-Restricted IPs" and SAM.A+P X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 17:06:41 -0000 --Apple-Mail-24--631577019 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Retransmission to Softwire. (The original, successfully transmitted to the Shara list but too big = for the Softwire list, has been reduced here by replacing a .doc = attachment by a .txt .) RD > De : R=E9mi Despr=E9s > Date : 18 novembre 2009 14:52:23 HNEC > =C0 : shara@ietf.org > Cc : softwires@ietf.org > Objet : "Issues in Port-Restricted IPs" and SAM.A+P >=20 > Hi all, >=20 > At the aplusp BOF, Dave Thaler presented a list of "issues in port = restricted IPs". > Imposed by the scope of the BOF, strictly limited to A+P for DS-lite, = it didn't concern other A+P scenarios. > I made the comment that this list, incidentally debatable even for = A+P/DS-lite, could be useful to analyze other variants of port-range = extension of IPv4 addresses. >=20 > Here are therefore my comments based on: > - Dave's slides, available at = www.ietf.org/proceedings/09nov/slides/aplusp-3 - copy attached. > - my SAM.A+P proposal contained in in = tools.ietf.org/id/draft-despres-softwire-mesh-sam-01 - copy attached. >=20 > 1. (Slide 2 - Scope) > - SAM.A+P, because it applies to mesh topologies (like those of 6to4, = ISATAP and 6rd), was out of the BOF scope. > It has therefore been neither presented nor discussed. > - The analysis below is based on Dave's slides used as checklist. >=20 > 2. (Slide 3 - IP unicast model) > - True, an IPv4 address part of a SAM.A+P locator departs somewhat = from the classical IP-address model: instead of being the address of one = and only one interface, it is only used in combination with a port = prefix, and then identifies a pseudo-interface (as defined for 6to4 in = RFC 3056). > Since no such pseudo-interface participates in any ARP protocol, this = extension of the IP address model does not conflict with the = one-and-only-one rule of the IP-address model. > - Note that ND-proxies introduce a different extension of the IP = model, without this being a big issue: several interfaces, on different = links, advertise the same address as being theirs. > - Note also that that SAM.A+P, which on one hand extends the = IP-address model, restores on the other hand the E2E transparency which = had been broken by NATs. >=20 > 3. (Slide 4 - bullet 1 - Legacy hosts) > - SAM.A+P cannot, of course, be deployed on legacy hosts. > It provides additional connectivity, but only to hosts that support = it. (Support is backward compatible, and deployment is incremental). >=20 > 4. (Slide 4 - bullet 2 - port-specific applications) > - When customer sites can no longer have exclusive IPv4 addresses, no = application may rely on having any specific port. > This is common to all address sharing schemes. >=20 > 5. (Slide 5 - bullets 1 and 2 - multiple interfaces, simultaneous or = successive) > - Hosts that have several interfaces, or that roam from interface to = interface, cannot expect to have the same port if several such = interfaces access the Internet via CGNs. > This limitation, due to the IPv4 address shortage per se, is common to = all address sharing schemes. >=20 > 6. (Slide 5 bullet 3 - switching back & forth between SAM.A+P and non = SAM.A+P modes) > - The SAM DHCP option obtained or not for each interface indicates = clearly which interfaces are SAM.A+P capable and which are not. > - The lack of mobility support is common to all address sharing = schemes. >=20 > 7. (Slides 6 and 7 - Non-port-based protocols) > - The problem of incoming PINGs, and of other port-less protocols, is = common to all address sharing schemes. > - SAM.A+P hosts that have IPv6 (as they should) can be pinged in IPv6. > - Note that ICMP, which is not port based, has port numbers in its = error messages (which are the important ones in classical applications = across the Internet, in particular for MTU determination. >=20 > 8. (Slide 7 - "Pure-A+P hosts") > - To encapsulate A+P packets, a SAM.A+P host has always, in addition = to its shared IPv4 address, an interior address in a different address = family (typically IPv6). "Pure A+Ps" therefore don't exist. Hosts always = keep a legacy way to communicate, preferably IPv6. >=20 > 9. (Slide 8 - Provisioning system) > - SAM.A+P, which needs only a new DHCPv6 option, is neither complex = nor costly. > It is indeed more complex than 6rd, of which it is an extension, but = not much more, while 6rd is so simple that Free deployed it in 5 weeks. > - SAM.A+P, based on static port-prefix assignments, is not concerned = with problems of dynamic port range allocations. >=20 > 10. (Slide 9 - Training/education) > - As discussed above, the extension of the IP-address model is quite = limited, without interference with ARP. > - Training and education on SAM.A+P is marginal if combined with those = on CGNs. (Port-prefix extension of addresses, and stateless address = mappings and encapsulations, that are already familiar with 6to4, are = simple concepts; on the other hand, CGNs issues include endpoint = independent vs dependent mappings, hair-pinning, various ALGs, dynamic = port reservations with UPnP and/or NAT-PMP, port-reservation limits to = avoid DOS attacks, which are much less simple matters.) >=20 > 11. (Slide 10 - Port randomization) > - If SAM.A+P coexists with CGNs, the SAM draft recommends that DNS = queries go to the CGN (precisely to have better port randomization, and = thus mitigate the danger of Kaminsky attacks). > - For maximum security, IPv6 should to be used, in particular to reach = DNS servers. >=20 > 12. (Slide 11 - Failure modes > - Discovering all failure modes of NATs and double NATs has been an = ordeal, as recent Teredo evolutions confirm, and it may not be finished. > - Nothing comparable can be expected with the simple mapping and = encapsulation logic of SAM.A+P. >=20 >=20 > 13. (Slide 12 - Long term impact)) > - The fact that some people may propose to misuse a new useful new = tool shouldn't prevent this tool to be available for its normal purpose. > - Concerning NAT66, SAM is precisely a tool that makes NAT66 less = useful, if useful at all. In particular, it reconciles, in hosts that = support it, IPv6 private addressing of ULAs, multihoming, and E2E = transparency. >=20 > 12 (Slide 13 - Summary) > - SAM.A+P, which only marginally extends the IP model, is simple to = implement, to document, to deploy, and to maintain. > - While NATs, and cascades of NATs and CGNs, will inevitably continue = to be deployed, SAM.A+P can contribute to reserve their use to scenarios = where they are the less harmful. >=20 >=20 > Regards, >=20 > RD >=20 --Apple-Mail-24--631577019 Content-Disposition: inline; filename="aplusp BOF - D Thaler's slides.pdf" Content-Type: application/pdf; x-unix-mode=0644; name="aplusp BOF - D Thaler's slides.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjIgMCBvYmoKPDwgL0xlbmd0aCA0IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeNorVAhUKATjQgUDBV1DBUMgZaBgZmikkJyroO+Wa6jgkg+U DwQAw+cJVwplbmRzdHJlYW0KZW5kb2JqCjQgMCBvYmoKNDMKZW5kb2JqCjEgMCBvYmoKPDwgL1R5 cGUgL1BhZ2UgL1BhcmVudCA3IDAgUiAvUmVzb3VyY2VzIDMgMCBSIC9Db250ZW50cyAyIDAgUiAv TWVkaWFCb3gKWzAgMCA3OTIgNjEyXSA+PgplbmRvYmoKMyAwIG9iago8PCAvUHJvY1NldCBbIC9Q REYgXSAvWE9iamVjdCA8PCAvRm0xIDUgMCBSID4+ID4+CmVuZG9iago1IDAgb2JqCjw8IC9MZW5n dGggOCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0Zvcm0gL0Zvcm1UeXBlIDEgL0JCb3gg WzAgMCA2MTIgNzkyXQovUmVzb3VyY2VzIDYgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0 cmVhbQp42q2Y224TMRCG7/0ULhRoS+PMweMDpwsQcF0pEjfcVRQJqUih7y8x29I02LtNdhqlSne3 3W9tz/z/jHftL/zacxp+JILPBP7PD//N//bLTzfoL2883n5uLv3yq174edP/99WZv3DrzQ1w+9m6 Ya33D5fuvi+v/ceV/o4xIDGxX+gRRL1COQVODin51bVffsEwPHl15U+OTv3ql/+8uh3tPBhnPacW +Gw20N0BPUoMjPmpQHc/Qo8Zg1SsLfH5vkTXzNljjSFz7Fbx2EwkTCFjNE+6BzKHWko36Rd2YuRQ SLpJv7QTswTK1M36lZ1YJDBDN8bvJzuQbiq/PQMEqPqHFnk6gXS7JOP1WiCW3aFx+2nQswYba6+Z sw3RzVO1Z0kBoGJLfH3qbD7hOVcNNm8npBuI51bn8awqTA+r6PYM9TQwQg0RMbtm0gs7kSiUGGtL DHZiVKOgRM5qPT0xlZBBknuyg2+IqsJaoCPaQ+NEVZh1Ndt8PDeXGVHHRSx28+nqjJASc+rMZ2m2 M9HzXBgPaGciNSg271u6druZFC2v1HcA0BDd3vmTQIWdUpkySDc7IxMqccRyj8x2lkh0jCKtnZ2Z VZNiCbFw62dbMoQgXCExjB5pPzj+RKaAMAh8oUe3T2QtvLF4xjI8uFkT3DWDaR6XAEzdKpOdKBy4 9h0C24kpB63mcXbrNk0s2hfVnGZ3WtPEitpySKeoaCZGSCEVkb2bmI2R3CN9h9QmJmaeEWv33xh7 oGaPTrrrWGWE6MZm3RO1VpLssDo3vYw9MJE2bshTVWjSmGiQuqjWFjTgIipHdV9H5Ac2lqZMFZDx SuEeyZkJXA219vsRzZcdhjmKY/3WMtGE1u02hnGaXkXA0lqvGGk1JKi19d1jGy2iFhroutJzG010 70G1qwnJRhv2wVCwpWUbrWpHhlsdmduzf5qgpUFz3UyXJtpgdwxcDhOFqM1D3n5n4u73QiYaZR1b fKzOz6GxGnvCQ40t6h5NuItpsdF0Dympzt+gjdNSHNVptdGyNk610oHyrUAoQOVAUahD0xNltk71 bqDhDc0CSU9FNG+TzzCEoYW9scE4F62AfRSOjDjdO1Ds7fKtFZd1T5c7h4tGXCWtgtyN7p0VV9R/ c5clL2y4CLp2qdfXeytOfWn7heE/3IcH3MVf+lmccAplbmRzdHJlYW0KZW5kb2JqCjggMCBvYmoK ODgxCmVuZG9iago2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNl IDw8IC9DczEgOSAwIFIgPj4gL0V4dEdTdGF0ZQo8PCAvR3MxIDEyIDAgUiA+PiAvRm9udCA8PCAv RjEuMSAxMSAwIFIgPj4gPj4KZW5kb2JqCjEyIDAgb2JqCjw8IC9UeXBlIC9FeHRHU3RhdGUgL09Q TSAxID4+CmVuZG9iagoxMyAwIG9iago8PCAvTGVuZ3RoIDE0IDAgUiAvTiAzIC9BbHRlcm5hdGUg L0RldmljZVJHQiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNp9kk9IFFEcx7+zJUKs BWUmUvBOtgdXBu1gHYzd9W/Ktqxrpgiyzr7ZHZ2dnd7MbiUeQoguQdYxuljRSTqGBw8dAg8RgmJd IugoGQSCl5DtNzO77ojagzfvM7//v997QF0obZp6gAF5wxbJ/ii7Oz7B6jdQhwYEQSutWGYkkRh2 mWxxZO19heScm+Hj9f9dDYISAhJVgMasx9ccnvZ4wOH7tmkTTzqs5NIZYpO4TaSSMeJXxGezPp72 cYZbCvEy8U3FFBQnkCIeKClZJ+YOsWxkNIPkl4m7MpaSJybfwFNnFl6Z9hDQfQU49bkmm7CA5XfA pdaaLNQMXBwDVjprst2kOx+pad1SOztckRSMAnU/yuXdVqD+BbD/vFz++7pc3n9DOb4DH3WlKEqV GUnSF8Drw12N/dzgQlOYc18JUVA1nftGerza69eLR/Ulq3QSezNxVxewRPcwdgYYegy8/AlcfQ9c +AAkGoDUdQQeobpt/sDNEyuYD4WWzdmsQ5Y7WNg5OlmEXghnsULeLNpcsEFDaW9jaV1nrqnFBLe4 KPFMO/J6sdrvOdpBboyO0EnzCqjc6q2wNJNJ99DdoJ14I8N7ep13Qbyoan2DzoXQ/qSKvlGPpfOa PZjyONBt6PHhCsMoxG97MbFj2tFkNb5VGumtymfStxJ0tpD8xmxhyLFpIt/QXC415rGUmsvF4hVe xTh0cGgw6GuAIYl+RBGGCYECVNJoZKGRlLs2gtjC7LGWOhI+ZqTfJp9t1+ceiuTteN1BNI6FtoMI TP4m/5a35CX5rfxrsaUYqmkWxJSmrD/7Q3GdzNW4FW2lJi++QnkjpNWRJWn+oCfLV6mvOtVYbKlF cnLwJ/E9X5fclymMaTfSrJup5Oos+kZ82U6aHtmuza8213JtnV6Z3AyuzR+aVeFIV/ygq8P/NTu/ P/8HzbABaAplbmRzdHJlYW0KZW5kb2JqCjE0IDAgb2JqCjcwNgplbmRvYmoKOSAwIG9iagpbIC9J Q0NCYXNlZCAxMyAwIFIgXQplbmRvYmoKMTYgMCBvYmoKPDwgL0xlbmd0aCAxOCAwIFIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjaK1QIVCgE40IFAwVdQwVDIGWgYGZopJCcq6Dvlmuk 4JIPlA8EAMPvCVgKZW5kc3RyZWFtCmVuZG9iagoxOCAwIG9iago0MwplbmRvYmoKMTUgMCBvYmoK PDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA3IDAgUiAvUmVzb3VyY2VzIDE3IDAgUiAvQ29udGVudHMg MTYgMCBSIC9NZWRpYUJveApbMCAwIDc5MiA2MTJdID4+CmVuZG9iagoxNyAwIG9iago8PCAvUHJv Y1NldCBbIC9QREYgXSAvWE9iamVjdCA8PCAvRm0yIDE5IDAgUiA+PiA+PgplbmRvYmoKMTkgMCBv YmoKPDwgL0xlbmd0aCAyMSAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0Zvcm0gL0Zvcm1U eXBlIDEgL0JCb3ggWzAgMCA2MTIgNzkyXQovUmVzb3VyY2VzIDIwIDAgUiAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PgpzdHJlYW0KeNqtnN+PHLcNx9/nr5g0cW3HsU4iKYlEf8SO68TpmwEDffGb0RQo kAKu/3+g5N6OfR3OeHe4goPc3dr+WCNR5JcUNR/nt/PHGZv9VynPHfL833/O/5j/M9+9+lTmD5/m cvr16cN894t+8K9P/k//9v38dvr4+S/k068Hf+Gj/n376P7/H36ff3qnX4lSAQScn+t3mez3S0/Y JiRIQPO73+e7n0uyf/zdb/OTH5/O7/49v353GvAxXoNEImVNvDtMnO6JM7JScq1r4rODxGkZ40yZ EvaMa+KLa4nT6qlngp5qAVkTv7tERNBny7VNz/W7e6LURDx3SXBP08/PtPdANQwsuS3EL+OjOA5K 6uLn8P3TC8hpQc4OiZxq73ztJE7rQXpipVSre+ofHHDafmoPbDV1wK8Mcfr6PHqiWncTB3xkwOmK hdkAcmKp/f+J0xO4dqkdEXS7QNXfWIjT3jReTSw1Ye7mdqbQdvFELAm4tGlrHoNETtQF1sQeJzZz GsRr4rdxIufE5o9WxHoDkXWtW10T3z+JIicQToJ+Wz8+TJzOg0R1ZRpnDrvvFXD6/NQ6hamQuBAT 97aIWX0Z9nEBAamlqgY5Ry3cEyumTj6wXlzrfReOauIEza31y7ALV8NJUrleWuzpahNH/dKpjXPh VDQUQnb2+IenU3AXEqjQkPZwjNNt3ozUP6IQrD3usziRWH04Ov/IcWLllEsf6MNJw7XGGjfGx3Fi BxV6QpNb6zCRKYla+ECiqBgVHxXicaYWE8zixhiP11X9I9aB01g1j2HMjvjTJSKY0QHT/Fw1vDT7 RN12UYXizAaCLP24ocgaJ0FcNf/V3ZN+E8RpwsbAfY17FcT1nkhV/HQ0L9jjia4zt37Y9LZxoNIh FynTxZTgOlyxtRAcNTqQxOoCB60FaJZKqrOPi7kdngkGKXzYQe/gWjbV1Q975z1cS61UGTV5mpjp BMqoh+WeWgYe5FMwF3V/4OYuB3Fmx1KG4Uz9kje84C5Dygl6GbTJNOwkyIiHY88OzjQG5TIK11sq tQ+yOmTQ0OONODo4wdR6GebcKZuG9HYS3BRkNSnKdZDZmWamnnmQfyLsiYf5dqqQiJxW/luQpkbc KuEgszOVrB87AfU6iGN1J9AG7X8SjYqVcZAcq+qJ27CFMKXNqmVHDU53hEAZFcSqfgwbeUDQnVQU S3NHbf9azdn52lUP4romZq3AILOrp7ostlFLoWkP1FIHzV1TT9ykjAqKrYiqHYZBD9ug6g/Nxdif gzg7vRGfkP0SxKmOxeLDDgVxHZP4qXtzkWbVZcuMwdJisEIFzIVaWioqxw6S7nG45qmMdUO7C7JE U8WMbt6exXCQxQopbnQYxEHWXAwDqd02DjXNLijHtck2jjQ7AeijRqeZHaAv5uUgTuUEAwYSxW1c Pz3scR22Q9MtgV6wvwriWBJCbqOeVdVJL8yDVkKzf1XYvkARNLtTnli4HI862zj1extmwkEa2mkv Rsod2zzSL+Kl3fMoTv1TyTLqaavOHXjxFPSe2ET9E9MoQ+mqFPX7UWYs2XKnPmophFPB49XnbRrp HmvFC8UrsuJtnkYehMKDNpmlsUz+aDy4smTFmOoL7cHIY3kseGUXtBNqlj55VRy0E8tjS+vDVoIx Ne591MNK02yMR+2xqikAN+6D7KQW9U+9j7KTCpKAedCWrajpDtUyCkeq5LM/cQsqFA1iqW4kFEGF UltLJZdyvESxjesqKdibXXCPVVbBo5+PmjuNFFB8sSi6siKpNhlld5Zmi1ft3wZpUNROehu0xRqq 2QGPqGRj0ZjD26eov8ZxdjwGI85RF6AdpWJrAwoBC1FTFdk4nL1hDlkTx0YjSimfiWLpVBlQnV2I msl3rCMOt85E0C+l+3OQNzcQRYOv79yIz6Oqb91GHccZOKi26tKOd27sE9XCSbP7EUfA98jJ2hgl N5pvnshpGaRuGmRyvcRHC7fTl8cW1KDiu9CvNshpPZGWSBdi136X40Q7rbq+2/kKIFpy7luyH8WJ mgHnxq6z7Y9xYlNFXeB4M/8+sTf1j8Bz9NDPE7lp3o9ljvpwT7SOrCwybq2t55AIYNxak+p1zrmM W+vTgScRzdHzU0+0Cxjqe453rO46SDKtrSLq6nsM00WfS41T4dwvrc10tRdXQZFa5bbXBDsdjgtk GkBTUb8Pp2CkqVnXpvK6ZfWHcOiqBfULu5bVeOjSJBITbLRrPY8TUZ14IxnQcrAQSXf2xjHGd3Gi aoBKvY7TpJZRUqORqqJ2OzKoON88kYuqqKyP/fDaSrB944uqqKLiPhc+fLdt16G1rDqFqwx0aE23 DbQmh29R7RP15yICl6TP9f6sqY0z8G70Ou7PGpnP9XdCvgn7s6a7Blqva4f2fXjX6KKk1k9efLp1 H1ZICNv59V0cpz9npjIiwT4TLcGuvunpxzix2SVBf07xIk5k3TA5UqjcJarcK+iLRvGVsbPtDP70 +HGcaFfwuj8F5TgRLF77muoNY8ScAH1Tyg3zSJZ+1CFFgIVo1wT9WVIoFJ6QE1TVzeh187NAKDwP soPVWPutKfv05bG7GqQGhjm6DSc3kdZbKqWPyAzviZjZcqQRieEZWDTIdJ90haL1Gak/t4pO9jwP ROszEVsqPvxfvPO8DyRVZiJ4+MLcPrFKklra4Qtz+8Se7eyK1sE6vgtnZHU+cLoTOt2q7M9EySlv dE8+voHY7LrlOP94asguPirc4M2srtB6gfnm8Lp4MzvQVuFc5xsvK3zxZkRNA42vSj0Kuwo71q6S 6xy9pLVBNPXok4/v48ROKvdABj617hlSGxpRdj0TRceYfcUnh4l2zN1JRhJV+GD31Zl4oNGAkErm IfXCM5FU2lOBETXNM9Fu6/ry9Q1AVfYixAMfmsFOW48Xcv2VeatlVnjwVpab3qFyplmrn2RoI96h ckYWTTW33qHy+PgF/M9ETsxXGM7Fd6gswNO1Gv7K+dHVF/A/E1ld43ah59g7VBagSh7h9UnKFLme vBCrpa3NvUPlUZxor6Lpp0Oz6cYr1AvRevaqv411FydawQzr8Q7vXSJYkxL5bpEXcSLU1BAGXG1f gGTypB1vy9onqvGgYB/wYoSFqMZTN6573LAw6mtrzni4Z2mfKKcjCh7wcpsz0d4b032f5ss4EOyO 8MiFQbCcteCI9+/cIye0W1bgo8zxtZ6WQdaWMvr87dHxF/AsxIaWbB3PrPeDK9o1muKV48s4kdWH N8Dwe4cckXJNSMID3hK0ENUi0b/PL654SKUo50wDXju0ECmrznPP/DoOrNn6Hpxa/jVObNbR7SXK mzjRmiax4MBpZLJuPTmca+0S1X1rrsVuZV7FiaVZPxPN0VDoiWiNPSjj5tHOWzOUOs4eq9njRv32 Lk5slGDjBO6BPeZUUXLDvPXd9OnDzj9Z9B9SBaQeWXPDrEPXlKTd396gzdrF1/T0Duz0Ig3viP90 qdq3h+uplA5rbX4xDdvBieaI8qCYdBbmf47iNEY8TIuv1fnbOMrFDiHXtL9EaafObVnj/hrDdZVT tT3oGDrj/v4F9/Z/UBKTQwplbmRzdHJlYW0KZW5kb2JqCjIxIDAgb2JqCjI2NzcKZW5kb2JqCjIw IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgOSAw IFIgPj4gL0V4dEdTdGF0ZQo8PCAvR3MxIDEyIDAgUiA+PiAvRm9udCA8PCAvRjEuMSAxMSAwIFIg L0YyLjAgMjIgMCBSID4+ID4+CmVuZG9iagoyNCAwIG9iago8PCAvTGVuZ3RoIDI2IDAgUiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNorVAhUKATjQgUDBV1DBUMgZaBgZmikkJyroO+W a6zgkg+UDwQAw/cJWQplbmRzdHJlYW0KZW5kb2JqCjI2IDAgb2JqCjQzCmVuZG9iagoyMyAwIG9i ago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDcgMCBSIC9SZXNvdXJjZXMgMjUgMCBSIC9Db250ZW50 cyAyNCAwIFIgL01lZGlhQm94ClswIDAgNzkyIDYxMl0gPj4KZW5kb2JqCjI1IDAgb2JqCjw8IC9Q cm9jU2V0IFsgL1BERiBdIC9YT2JqZWN0IDw8IC9GbTMgMjcgMCBSID4+ID4+CmVuZG9iagoyNyAw IG9iago8PCAvTGVuZ3RoIDI5IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvRm9ybSAvRm9y bVR5cGUgMSAvQkJveCBbMCAwIDYxMiA3OTJdCi9SZXNvdXJjZXMgMjggMCBSIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+CnN0cmVhbQp42q2dWY8ctxGA3/tXtHX4kkSRdfDIBcOS7RhJlChWkBe/CXGA AA6g6P8DqZrpXklT3bvTtQUJmp1d7bdks1gXq7jv5tfzuxmr/mXKc4M8/+9f8z/n/87PX7wv89v3 czn9ef92fv6DfOLf7+3//uXr+fX07uYb8unPR9/wTr5fP3X+9+2v87dv5JUoFUDA+Zl8lEm/XlrC OkGjNGB+8+v8/PuS9Ie/+WX+8k9fzW/+M3/35jTgQzzMkFqt5ZL46DBxOhNnBEoVmC+JLw4Sp3WM M1KTMXZwj3G6mLUs0UiNWr0kPvUTO6ecsV0SwU2kXPUr5jmyn1iE2IsZ42M/EYSInS6Jn/mJ2GSM 2cz6gZ/IlIiZAomtpIbZEB/6iUN29cDDAo6QSs5cp2fy0Rk4OFGf20jLdpHPL7SfgdgNLCKNZgMW Pw449QY1bsaFSupU+yWx+4lcEtdiVOMX9yD21KsVxRd+YuPUGozAMXZMuTUz65+/vAM5rcjZIAfK YlstsTfI6XKQhghZKN2Kz5ML4rQ3bUssPeVR6t7STHc9SEtEklmPYrXtdN3SWCLJ+/aJiE9bsz5A FIEcnZU4uTaNJdaeWs4wHbUx+0QR8T5avyT+2U/sI4kWNmN86CaiakfMbfJubEsE2YZirCfvxrZE zIlIjM8F8bmfqFYsNzNG8BNZVqaax/jAD2xqFZCmo9psFzlhh8RAx70oQ5zWQYo8NgCa7/kcp5tp U+YEGYzBzm6zQFBEU4wWSETRFGK7Dvvg+0TOKdcR51NQrfIeYfbKoyW2nriMGkgcWVxHA/zLXUAQ e1eg0/QMWpLvl89I9FIKbziOCNmJQ43cLsf2gxPGmEbL/bD3tIMTS8Vj9MP7eAcnZkr8pnbYE9vB 9ZJEWY/D+20HN0SSGY7vjW0clCziyBC0FKL7JKAiPOxz7vHE9cqDMWgtgNRyFj4cWuzhxOniWqNG x6IHAHrU0lYxwczlsFrewUkkmrsNeZy7DLpMlhCjlkIik8Ed74ojrsRhVue316BnhxKTiJUcQc9O E3Nt2AgZnDix34BWjL2jE2eSBx1P/OzgZFdwKRS0ybCKH8mNgxQetppqts/upRMnDmQv1A+nCndw YiyKIyW8TSOxFXlglAbQJCZxidLtojllU4QtrKYvCSpHWTKimlpvNWotak6tjBGkoKiJYeQMQdpY neNRrVfhVFA0IEkgZOT4uQ/HmRL0AUFLwaLcAYpDfWrqWAMB0CgAmkajp1ylK+F7puElrg6b7f3O yRJdx4XMRD934sRk19Yd+38HN1LplRwbdpMHucmyNuvKfuXkFVXtbQRNF4ATQj2u7bZpou1GqV4Z NjjCVIY1Y+610E2B3MLWomLqUB0aYBuniU2sLerpdZ0tjeMO1DZuiG5vNoX03IfDnGXb2rV44sQV TFCb2bbfOHF6HMVtBK0syr7o1R54fOvEiWuM3KO2mchIqhty99KJE59iADqczx2c+Hc25eaVEw0/ wR7L/+jEjZJqIYeHsomjLArPesbspXV5AePvvHLKCYnpGWg9lOTEoZ5ogLGMv3PixFgMyGbL/tWJ Y3G02cz1N05a7Xr2Zwb3NydOVHvOdot5RycuVAGbqnztw7EeNrCVE6/cCSrVWqJUAIN4eAiOmGcb J7qdqUQpYyaQTWYlhb24nkjEJchdZE25c4Ugf5FFt/NGjcbfnbgmwXaz7uczJ65rfgyiDBmLA4W5 BElxzZAk+GxB7lgV/ymPikGGrGrN30bKyPnoKmbRd/Y84I/HT8nEfknAE1gPtQA366G+9uM0DbVR x/PET0Tx8noZAcerK5GzOMnWl/JUBq3IWhLbEsdbNvC0czi/ApsEQZyvOr2Ybj/uX4kdEkG5NTSY risgWImjJxx2s5wCtelQScJC1OO43uDiOU6uKocVCUXc8I9cjumg+FiivK/55GJN96xouSGKg5rH CKhoWYli76hRiygXOSMnqJQKs78q4UO5yDrInsWhyf7ijg/lIitx1DRKq+6SFqMrMMusiz2B/cxP LPIVtr6DX+ci9CQq18z6Jz8RNVtvZ/3AT5RYHWppgSvDen4yaPZuGktsYq2ByuE0275dwF5TL9bJ huMVowuRxH8S43DnOc90ta6gosf4Yz+LMh1UPqRVC72z1RSTU52dC6I+cRonZzHmDbEl7KfS9ylG QZ5i5SwiPh3O0u7qXBJPvpPjqGZX53IWCwu27uCxW+dy7qnYTZPd25BBO4O2xMdNpCz21cYc3U8U gZSljiipvyE2mbU9Dn7hJzYRHug9cIziQhZ0VDftEwfogT/EjbGKgJdiU9b+AETWWQTccbK+T0RM w0YLfltYqWhqqMbZ6yoOZM2BYVwV48qlR8yZSdyd7cDVJYoLT8bZe8EQ678gZZ1r7T3C+i9EcaMK 9btD12vM/4Lkkfot9uB667/w6mm7mCE2h/VfiKIkWvnkKGVytjksRMgjVcimXYT9RFESmTgk3joR J4CmfWA437txYlrHiCyRh21J/MZh+xciy3s+nmjc3YRw6psAiLD9C7FxknCG4hQPaN8EUojtX4m6 BXuI7T8TtY+nEcekuBZk0YqwdmBlptu3DIp2pFwgIsW1ELX0smG5zc+bDm1rfYHetjtaJo+i0I7t Spd1NZMr17MQOyYoHx2XTt4g4YZ4riXCS/X4wE2kUsQSQgvoprshagtqNg1Rn/uJ4kS1zhTQqXZD 1JrxUQOtAomCbM06ZoeDzA9KnLSujTvF6TMSiRzdUZ21S9SwVaZd4rS4hq25tx6oIbUSstXrl+Zu d4/FYjPXO0Ph67091l5wzLt5uOmwkIvoyEvfOIHz+nsauIpzhpf+XnZvRD71ltn2YD+x5ibKAk0T 6lM/8ZSGMx6kX4tX1DzKgIAm1JVITQuRayBRg49uhviTHyjRx8DWAofYc6JCJcJ0nepVzpFrxAAX nAhObZUiTo8WorwHKmaMT/xEjVvZdtN/4ydW3lzoR35iL2kUCFxncetLtub/pZsIWrqPdkv7Jw1w bmoJcVFOyAlQbXVIX/k6SC3PboABfeUrkVGiQohoiF6JIo8928zMPYitb7Z9fOEndk7iO+LsFUhD 1Gposas9wtNbiBJmto20xyM/UeLMBjbtkf1EzolzSC5zBbbUwVZtupzRBald4TnIG12QIj4wCCO8 0TNRwv8Edb8gfDqsz7R2mGrd2NiTU0OSaMhBnwQzk/NykJWIVRud+dIbbX5i1Ust7CUrfrtATVu8 7CUrfmtIXbOPtsjF/xw1KOQyzIU62U8857gokChOOIj3ExEnLETihL0GOj4s0oM19ziXlBumji3C ySXUHMqp7nG6R93jJXDaPD4iPw5KaiNjRF5mmXJB0eCtRZzfrkQRnd4jnJ4VKLE/bVyI9thPFDdK gpkSOOkGohszBs5aNBm32gJnrSdcjfwOriGCVmWgPVj3jxEKa7/6CKi3WokgL6W2iBPXFakSnq/v a5ruVDwgyrFUe9rjqLdaiWpa2VZwvTzu9KxE0bq5lxJQcLUQMcsLMwYUXK3EIvr2fHHPvQuuViQ0 GSRFpClWovZiVYzIAaxEVvHJIyK+XkzN6QoPghJoalBCzbpRQfrIvbdxUKobnV5+/aOxwoBCAZW4 N8SRNlpHvvYDoWoXQOSkJXbtG40FzU/kkahEFPaswKb1PT0gul6B6kMW5jhh5Hw6h2sBdQorUYua Bo64lWbAxOP6SuEriNg37Yzf8TkdHlGLnLUeHpFd6x/9xCbOGWKc/6hFj4Pt9Y4v/cShR4+R/mPV ztVOFCc8FXKqRIFesxY9FrAnj6/8RK16bBUDn6N2ndqWAr80VglnxHDx7L2h1xK1BtdepeYpfFyJ EnyMjdDV8xi1kXXnjvU3fhxoBNdCHuJClJn3EZJaX4nUUtm4+d6TwV2RmhTu+Wqn7LZYZiFqWobp Tv/kmlhmIXbdgvbG3+yIZRbi0OhobNwTdDyWORNBlWMlUz7quBt8JUoonEfngNvGV6L2PCCMgKTe Sjz1PNg7rZ/6iWL9ZWUCh3g6q7fR1gs/UTvfIYcUXJ2RE4yTBh8Bp5nLIPU31fDGTcfdEb4txAIJ bWT01K3N9NJ26jaQeeInijjixpVYzU/UAoBqzdYrP7GR5qPi7CDqTVYlptF8RYqx3vAnPKd6C1FP zHq2KvyR2yiQ3s/aasSp3kpEUT0b+VG/UVDfB8cnTWbT/XSPXryDmWMSXAuyVnV8IE6H682URcLM iJTZQhT9mKs9esxuIhe9otZWmT30E6FLMIMloEJqJRIkiWVGoKHRK2pyHhDQ77EOsorO3biW64nb 0OhFNbDxCx5euFUkD/3VG2PEKd2qNQXZRgt+26WVmaVUDmgfXYna24M5ctYo23CjafZ7P5E51W51 7g9+otb1btzb/dGpa06MI1fMWx9N79/u/EjxfzJo/cyzAvKWtXKznrLasJ0vvq11YwemtpxsNPbb u0zQHk7ixXKZVZruPoHewZ1i+I/yxNOVd9Lt4bR4qJlLUx77cOcyn3ZJ+72Xpq37H6VAFtwffLiW axJNadpn/vEB9/r/z0FBJAplbmRzdHJlYW0KZW5kb2JqCjI5IDAgb2JqCjM0MTYKZW5kb2JqCjI4 IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgOSAw IFIgPj4gL0V4dEdTdGF0ZQo8PCAvR3MxIDEyIDAgUiA+PiAvRm9udCA8PCAvRjEuMSAxMSAwIFIg L0YyLjAgMjIgMCBSID4+ID4+CmVuZG9iagozMSAwIG9iago8PCAvTGVuZ3RoIDMzIDAgUiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNorVAhUKATjQgUDBV1DBUMgZaBgZmikkJyroO+W a6Lgkg+UDwQAw/8JWgplbmRzdHJlYW0KZW5kb2JqCjMzIDAgb2JqCjQzCmVuZG9iagozMCAwIG9i ago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDcgMCBSIC9SZXNvdXJjZXMgMzIgMCBSIC9Db250ZW50 cyAzMSAwIFIgL01lZGlhQm94ClswIDAgNzkyIDYxMl0gPj4KZW5kb2JqCjMyIDAgb2JqCjw8IC9Q cm9jU2V0IFsgL1BERiBdIC9YT2JqZWN0IDw8IC9GbTQgMzQgMCBSID4+ID4+CmVuZG9iagozNCAw IG9iago8PCAvTGVuZ3RoIDM2IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvRm9ybSAvRm9y bVR5cGUgMSAvQkJveCBbMCAwIDYxMiA3OTJdCi9SZXNvdXJjZXMgMzUgMCBSIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+CnN0cmVhbQp42q2da88dxZGAv59fcQIYYgzt7rp1dTa7gkAg5MNKIGtzWfYT SlaKlJVY/39pq+ac8Vpv92CfmhIRNi/xw/R017Wran6+fn/9+Yri/2Oq1w71+r9/u/7p+j/Xl1+9 btefXl/b9tfrn64vv7Uf/Pfr+f/990+v319+fvMH6vbXW3/gZ/vz/qPb33/65/V3r+xXotIAAa+f 2+8q+b9vvaBcGmHpcn31z+vLb1rx//irv19//avn11f/uP7+1fbAj/GYilZ4CuwPAy834LXpKEMG PyV+8SDxsj/iFRqW1mB6Rn5f4uXJoq8ARuz2kyfEj+JE4tJoaPg9zkStBVvHvGfECgWG9KfEr+JE 4EI4pmf88dfvQF6OzuMVqRao7SkRjoGXXzzgJo3NgLW/xzNe3k9mrtjZjjhMx+eTN8TLY1J4RZVS YX7IF88vMbm+Uh0FlN9+xstDmz0TEQqB+tZc3n7G38WJ9s9QRS5PVv0sTjRt1gTxKfHH52EFSd1+ qTLvTFRBcq2Fe51UxQdhBcn2ixL3h8XwWLLZNltqp/BDzkQaRRUmXfEsTmQjoo6nxN/HiR1diz8F /iYOHFyQZVJn/xEmSoOCytMz/jFORCq94fSMf3gXEXqp3KoRofu/VC107aZ2biQodT+HZh1DsFal tDGmxf4pRrP1sqo+bFHXNGz2GmeV/XWMtrl12h+we79EYyndtP9T2ssYTbQ0M/VPaV/GaO7XRPTA AU2MVvFhh3hNG1gA2rTST0M0s+el8ey3YozWRqHaJo385xgNsVRlzdkFQJP6irMBeh7DMZrWnDXS ixhNehHAx+3tmtZNGLQGbO0ap3ZGtGXtw/C4ZvQcaUBzVCq0HGFAC+IGZy0UwR5N5oXG9hSx2gkR SdpTNGng2pN0ObK53dKTdDkKFu2zhvshRutmnwEkaRtMl0ufMwfBIzLMg+3zewvqJDJXREFGzqaS KfOucygeMw1krshos08Yc2yIzGeVniSpxM1os6H5KkYTLtw4yTJQ913IMoKkXEbFpJV6lFgtCstZ KTcq5vuPJA3HYAYa5kDpkyDN9CU3SVqqe9J19i+D28AWWlt8nXNE2LTvWJit4ErNFQGas5gao5n2 NdGSpJW69kV8PAu8pIkp364wct6bQHPRmlb6WYxmzgPBvNKgaIk5D2Txcs42iOlypjl0ixlosbDS FFxL2tRezfWd7zJiFlXUAhqYE1YxN0kGFbOqmGNRuwWCqrMuf3RPwRMYcpgV4SCueV539n4/ieK0 yMJw9SDO7wN49kaiT0dSSOm8tO48ZuMxnz3EO07svBBj2uP1bjyhrLdnQibzldSLIG30Mgj7WUt9 x4Gd4zrmrMF4J87zoSxGo+2fzCkEO8a8SGRa3Pl+NHyKw764tv02CDOfWnRMIvaXIM68EpnTop8G aRYTVu4BP2KN01aI57uNl0HcsFfH840lxHBQt4RLe/wIr3F26PrCP4ziQC32qoEYYo0zVTy4RYKI A56WMUCTTgowFejTVnwXpInF+zInSj4K4sxX1w5ZS1Vf6ryxQeUEw9c65zSDa8Xqa52dpy+COHPX SebMIUdxUiIR2BrmqT6ZQ9cvgzi2WGJUzNoIgcK1jqRj4mUPdcw3EMFDjGqL1SFZWzH8RqNBku6k yubqtCzlRK15wnokHWJqFqz3ORILHhQyQ8GqgbvMNc6kQjv3JCO7pRDHnJkIugCmSwotbHZQZqlb +FR72kExj13ncpP3yFqvccPCpy6cJGRcwSyFwuP5hDXOXHYApiyPgsFWK4LBx3tDc58zLwK40ZYB wF9jLB6lgeLjUd2SJlQE5yPCMZpndSzkzKKZFuYEF/FGU0/8nXfWbzCzN0IJDuJGg7ottJ2XhBuu 2cPNUc7HMRjWoiznDfWNRliI5sP7WYxmtqHj7PX/EKOZwyQyX/I9C9LUbP583oIrtbiaOo6k8+aJ SaXA3cGSNtiM1hyPfBiiefyAo/bTRuZGa6Z4zd7nvDcEMzSsnHNCELk0lvPJjRttu7hNCPdvNO7L aD+mLdHMAtNcMh2kKXpFWtaeDq/dR8rZBQ8ckHqSIidT5Kh95Jh6ahaZzxEXxmAuCpVa0qOZKEAD zHpvZmVgcQvxZYzmZeXakuwCmftGUrNsPUm3KL/lSD1ZUF4H9KSVqslCnxMQQckyOeU+26yYlWGz Mub6jhwr4yX4DGn+G4MtVTBnTxltpTyrpB6jmV1A1p6je1mG2ayR5A2yBc+9a9KWemkm8qRC/vPB 6yls5rilFcbfaUd3wP8SxDXbhjFrXwzisHlsRGevz3cceeIRT5f07DjTv0BwuqZnxwl7GU5/PNha 45RM9M/XVu24UUsf7fyF9xueWf0Bcrqs8s7zSHUQJO2FF8kPHKerNHccgvlLQ5MOHpD9mEbaYtm8 YJkvlb4N4ixc7X3OUf0liFMwh07gbPn4jhum8ChLZrdWWOGkY4KeKQTSJA2ASIUg6wxbLGIRxHy9 /1kQ561FIfO/xllcCK1K1r52KQgqZ8vbd5xnSXhkLZaq12k3SdoKv1MyV4WTtBNtzdxVsxZrXqcq 6NkqtR3nDfZ1TC7FvwdxnjdcdC48i+K8A7dKksySSYXWubL3iyDOXIqxGE4QxZkLUMeApJ1lT5gA Zzk8bFLBDHK2EHTHgbkAmGYqGNncJ8Esd4yJjNcp6+WZWNQ5S/ciSDPPuHXqSQqKLYRCIDhbzLzj 1BvSW0tSAd7qbQFZS1KfUoeZnjl18uOPQZ4XvWuWChDP1mHPCvCE1AsaMUlmReoyXowKmYgrPMIk IZPuL08pSSzsxXmKWM82ou95CnONWzvfFOW3EeYSe6ICzm/EHeaOdj3d/bXTwESsN8laqckEL7Lr 3wVxXtKA563incY+sobPq+I7zm/5F314NYjzekY53/Sy48Y2YoDSjt1wCUNOOnfb5TxTS1qt5zxW pQMQxPnklxa56zjAqTnaY5w22ncc+VgjOW/H7jjBgoskxUdBnIWfXeayvJdBnIWfrUNL0gEwqOCY Q3eN4TyHInkaym/9+6LyLfjufEKAqZUs5e5Vw7ZgSTp3PuUMsY0kjYJMRerc5vdZEOdtqj1Pf2IH 42GWesfu7lhC3uOO86EvNOc9PozhqHavXjnd/7bjwJsk5txi0Kvwe/FGlKXwiL0oSVrSwfP2/jyZ Nd/OfB46nZW904Zn2zRLGdPohRudT4/dcFyx9EU1YhjnQzw1y0VhCy2qzsckaHkYzJBJwySPh9Ek FubOgeDO+gACXhScRbfC44A++8YPtjVi3+qPs4qad1xKW+MOO2hrfBbF2fvUOUcRXaoMnydzuhJr x3U2/yQiEmuceqvP3K4Sxo2ibd7Zj2I4i9mLgp6uhN1xrRZAGVlPB2AOQOeztYk7DsnHUp6tedpp XvuQUGa+41woFsFiUMa8YJp4bljTKM50nUjaOfFZbZ3G2TKqHeelFDJfBfQYDt3G9ipJW+GX0Lho 4/4miPOif6mcpNvR7yl0voKiIM79TgDKenfi+qlKkm5HcYdCTxew77guZhfTzolZiqpzBPBxEDe8 mGrOPj/csHbn+aW2aU9M0ncEaBGFjiTdTig+8Dzr3BH5Yrucrhp9w/PGS+W0zXD1nmZnqZM3XmYd ZJ/epotqTwjiPL5blD99EcN5QLbqlIzi/HJmUXYTfHfmARTlLAXFaK+uRZIKa5zX7gP1LBz7dRtj 1mKFCg/grJ0wl2csmp2Cp5i1FW5pToUPhRuLa+Ovg7hhDtng013wd5yYjLFSS/LvxGTMwjI9O0Fk x4G6u0hJOys+CGsRMEbfncUVZnqyjrFY7G5CFpg8fIDrHuGdnkm04zx2r4JZi/VBGJWy3EXRajI7 V8pFvQALAgov5hs+ulpy8TrK8TzsUuw0rgU5Uim3xrnnvviSzwdBXLdjDL1nvTr33CEy/HaN0+El 1XRW391xW1amaktarI+7txgKzgbvO87i2YT5SzsNfAg8Zx07H3jfiLOOnU/C4go9a2NNKOogSjp2 0H0+HI2sc+LXd4rnW+V2nvdpQZpQeH9L4ywNgJVLa/Ml+XdBnDezV6Ikqdi62RcfvOEgzqsCAU93 BO8483g6NshaLINfkenZ7ucdJ37NM0bW03Xv+Kycde7UZ/Vplr7zYfq0SCwENYr3yNc5r/BlkNa8 8rb3LIVC/mPUNJfHk0YCI0ssiKCYTwZZe8FUOvTTId6OEyl1ca8dPMd+h08Ns16d+WNjcdMbNNtk 0XFjpay1Du9cmOfsfBzDeYN7h4pJ/ph3uDcYSWbWZ/73xQcPg4eYTSawzefk68cuybchFHmTv3bc MoD6NAiz+Mm2gU/v6o4zz3ORbn8RxJm4nh/8ucMU/Yxw1rMNsTMC54X/htsmdsk474rdcSZec74j eOJ8YhckXC2+wflSz99n7Ti/0gZJ2la/0e6LOxQO4sSrAVnPDhnZcd3TbHJ+rM3OU/9+U4fTBnHH eWU7U9JeoDe49n56wt6Oaz4KoWcdY/ThAItPEQXf3fbx40X9c1AqcCsbaS1rsZ4uhpF28JDUVUqW oUDx8oLzE5Xe4KTAYqRSdGu7zy+ZrWIP4oYPUIQsu+g+jwUBmqTxyPzEseg0DBoyAos8F4m74Lsj O8dNmLOeji14WhQsBzUUCfkdj2RJmQ8TNkPLSWJhIbt/5fP05eKOM2ux+thJ9OkG+WdxTlcs3XHc asHOpyuWdpwXGdf5FpqCOPtlLDpmg++OqRVEliSFxyRFCTVJLPzL3ISUtlhx0whpUsYmZbroR3k8 wXPnqXkCQi1JR/Ho5lhQT3p74jO7+xy5R1drut1Wi1lhmV+TV+assEws2KaMOZI7z7+gNtL2wqL3 MebF/hDEifnbkGUbpaOpKM5KLYhCMR2ASTrFP8k2kLLcFIuOy1jc4L3biaql9q7dcPa7jehTo7fu hdiAvyOgjLlz/q9hmlfySOQL3UfArYEpktU+AILpqSpz+8fLMNAcAh6LmZzhNQM0754L1JEcAtk/ VqqPO8tHQPMLzB8N3JkdAb0pBwPjb4544oVCFCjIPQJarGY/bo/bj0Pg8KoyzdtkNQ0EiHnv0D89 ABioLT0Amp/rlW+UB2zbpRKnbQoCFAaGtE1B77ZT7Gnaxi+/pUpP22Xv/4M6x5ZhSTHTbqKsPQ8o PoS2Bu6EjoA+P4EifedHQEX3zHvesdHuH/nOM1LotxKLqqnwO9w+VM8D0kwK+QS0xai8ONBHgiwq WT8MA2lYMKyQdrB9QruOSmm+jeeJiOarrPCx8UTRyLTL5A2kgomy59ki0EhUfAT0ViPOc762Fo0W KTE8Ajb0ESaBKdpHQBO9vvhsZPwJ0YCcZ1K8VQNDJaSHwF5UIjUQR0D7e6M5gP8kDpQii5nQcUFh i7sJQt98OyLqNsAlz+yxD8Jd1FeErZR3ggzJNPXi9/HKidGe94MAJkqfgLhHF2hvPgIi2hOOPJXo 2bM+ep5H55MdFxWhYYUj7L7DDPw8DDTLPNKSQN5oQlzzkiLSLXZcfFkr/gL98wI8l0v/EAZ6MKqR WpMZ6GMAt7zX6tMWIUG+Ebt/tAtaxqm+AX3A4OJLgh/EgVpahRyjshHBQnqFuQko/IjQbLehYdo+ e8WT7YxmmPobEP1D0Zghe3eel7KGGhWOiGTuF6LmHW3/BsRi3n34ZHv5k841LR+Ged1nDjZIfIdq lNB8ykMgm0aslBFK3YD+PbnFUJT4E3pPyqIL95tvo0T0y22QwDiOIyD6LUuiFTApKbwYp/15GOgT SNrsfP1XGMhuSbnlLdk/69tQ0hSYt6iIYErC7wY0aYbFbOi4NG99KiiS4RLfgVuCbqRJM/o9V511 dvggevmWQNUMp/MONB97kYYNnxsyU79I3ISPjQ9hsSilZficNyD6bUCjNNEji3vqwhd5GQaS3wbM Dl3YMPukzcbz6IQeBnaf8z4wD6hebAaa5juQOcWSdFW4AX2qZVtcFYYFZUv4LTIE4WPjCb9GtaVp Lx/N0ilPX/u3JEmq5r1CQnOyc+6QbkD2jiDKOzRCJieSZ+ZZ7Fj3eXqEhoHdvwHTEg+Nbk57opyY ahjUIM3ksScdFi2ab0W3tTCOKlhXv7u8/ungv2imr4IPCvjcHrfaafIC361aaE6b/9n/a5dfePw1 DLvnxOYEx6+eX375bRzgLCCC6W7p8u5PgR7hLCxvbynJy3uGBge4AWWMty6q7rjfRnE+KeGtbtXL e0rjGudfZAN5qxP5jvvXKG771t6E+7f/x33/f9n3QhgKZW5kc3RyZWFtCmVuZG9iagozNiAwIG9i ago0Njg2CmVuZG9iagozNSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JT cGFjZSA8PCAvQ3MxIDkgMCBSID4+IC9FeHRHU3RhdGUKPDwgL0dzMSAxMiAwIFIgPj4gL0ZvbnQg PDwgL0YxLjEgMTEgMCBSIC9GMi4wIDIyIDAgUiA+PiA+PgplbmRvYmoKMzggMCBvYmoKPDwgL0xl bmd0aCA0MCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjaK1QIVCgE40IFAwVd QwVDIGWgYGZopJCcq6Dvlmuq4JIPlA8EAMQHCVsKZW5kc3RyZWFtCmVuZG9iago0MCAwIG9iago0 MwplbmRvYmoKMzcgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA3IDAgUiAvUmVzb3VyY2Vz IDM5IDAgUiAvQ29udGVudHMgMzggMCBSIC9NZWRpYUJveApbMCAwIDc5MiA2MTJdID4+CmVuZG9i agozOSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgXSAvWE9iamVjdCA8PCAvRm01IDQxIDAgUiA+ PiA+PgplbmRvYmoKNDEgMCBvYmoKPDwgL0xlbmd0aCA0MyAwIFIgL1R5cGUgL1hPYmplY3QgL1N1 YnR5cGUgL0Zvcm0gL0Zvcm1UeXBlIDEgL0JCb3ggWzAgMCA2MTIgNzkyXQovUmVzb3VyY2VzIDQy IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNqtnWuPFccRhr/Pr5hgwDYLvd1V 1TfFiZzgS8g3CErkOHIuKI4UyZYI/1/K2+ecgeXUjM+Z2hIWuyzeZ7unquvWVcPb+eX8duYy/ssS 50px/t+/57/MP8+3z9+l+c27OR1+vXsz336LL/znnf6/f3wyv5zevv+GePh15xve4vvHl46/v/lp /v1rfBQJiZh4fobPooy/TzVwmaiXUMv8+qf59psUxg9//eP82Q+fz6//O3/9+rDgXTwmCcS1nRNv dhOnI3FmqSFHyufEBzuJ07JGPFAJtVZF/Ntn1yKns23PXHuQ1Mm8SE2EYEqXdE58ZCZKBDFHJZqv 7cTUQy9qiX+0A4UCtaaIf7YTcw+candcY0uhiFKeP1wCMoUUYy7TM3x2BHYK0maozklv8PVFFUmy GZggaKWJf7XjeByXJOq4fH4BOS3IWSFzCjk3JRXaIE7ni9TEUkJPrV0809PWvjWy1lBi3DyB06Un qYkNT7LXqrc9XScbRaQYA9WPDPg0iC+ulbYmQstTy0N/pl0GfJsI/YmwZNPZrj+xE3MMsBJ12m3A t5ATFWhk4d3WVgGnZY2lYY2x7D412weRWg6laOt4YyZypJBxtne7rW1iyiFm3u9bt40FUw6VpV27 yMvGgrkF5kSXpH29rWDJIZM2P4/NtoKhP5JZmchPzbaCK55j/kh9pvudmplbgR3vcm4srldyhZTI gaW06d4n8T0xRRwbyefEaicyHCz72TPIOSSI55yY7cQSYc5cLaTUFEhY66PVQkptkEtVp/DLncTp w657xpkR5V/toRQSj3Fm1Cl8aCemBmvGyexpNBH2sXOsZsloIuMMZlG7fm4nwmMnIU+3kKHiDanm taK57BZyHTGkzl2fmt1Cbi3E1tUam9kt5F5Di+IXQZYE21M+8jMHr3Brtj2FSqjU6rlTeGgnIi2s kfpkDVM0MeeArFDZ8O8vEQkCTdRkfkYVue/4CsPUErLDHGg6T+OYopU4wSOslGZ+bech6RImZXn6 buK07DkjRulavb/aSZw+PEU4mRp1un71GiclF3iZWnPZbW+3iQjDE+sQl+zE3hCGM+/2hJtEwqmm SJ5E/LlxYr/nOPJCjrpm9sJOlAZP2PbHKNtE2AmJIrs94TaxwhOuJEjRThxVhWYokG4TEUe11B1l PRLNVHWsd9n/bxpcTsjYV4R9c8n/bxPhuJDDld1p4TYRbqdIUaL51SX//wvEDueqY5RvLgUA28SM gy1VBQB/N7tChhHvMaoS0rd2IuKolFQFKZmBEnPgJuJIJII6VpW3BjsR/r81lRTa5SIIAFqqKuix ywV5OsL6pgTzjZ3YxhlM6jH+w07sPfTMNFmNmSLmWAKsjyI2OzEJcpmiiDd2InWEFEVpz1M7EZaH o6Ews02UUc+U5rhr5ISCOHeyumtNrBmJgy5eP7MTG4dSe91d7Nkm9hgiZZUefXoPYkFgT47PscBb Jw18ZQcSh5Ype6gjtAaJ1jHfOufd2nnS4fy16tzYiQURc9deq9qJMLcVObEfkWI/1BN2V0e3iZB0 Tzr7f24nMvItSS4H5kQUGPDWyE97KJfQuq4yk52IzAMBadpfE95CTlSh4p1pvveDnJZFQiEjd5nv eWim99vmiA8rNbjL6jPu/Uctk0bhiDoy6uPNtem2/kjjc1zp+qr+CyOrxUCk0xcy4noKVZrsl+0G rgbodNldm1/H0SjMF13qf2DEJeSnRPsT3g1ahYvSnQPGRzcMYCSd6TYjDg6UdUnDulfOUBP96H5n xElBdBT7/vO/jss4X0XXRj4x4pDZtmy4vNnC1ZBWamq3RlzDEUv6otxoAKiPmyopRsN5jhv1Gqas nt2frvA/60BCDl+rlyIzjsVaofgrI07gHwrV3TeHG7iML1feX0Db4hUYvCReFo9LRWRK4rY8pF3C uiJ+ubFggzcu4hD2OUlDEFNEPxt6qEYlKk7OTJIgr+5edkCohNS6Wl014pD1c2evgyG5jgq9lyIL zkWLWpG/NOLq2Cx5uTOBhe9Nm+SnRhzSfIjC7dTmKDi1wk6yyEglG+tjYXx4mShw1Ksz+rPMSPm6 9rbWzQqi965DC+OhzYdar1a8bMXBvlNKXrhxyqi7KUppyHx0Q78x3s6VEfjk6qUoSGmhxex2yroE XumbMhrQMqrZVTclG21KSeM2Ul95GZOVQqOFQ6cXxmNRmMcwiVPAXWSUcr2CitGTUlauHw3NuIic fCcLTkCvyYIF5zhZsCD9JgsWouNkwYL0myxYiH6TBSei42TBQvSbLFiIfpMFC9FxsuCIdJwsWNbo OFmwIP0mC05Ex8mCheg4WbAg/SYLFqLfZMFC3JgseGq2FZxLqDGuhNVWW8EImErsylaQ+RyOfL2X ns9tRTUTR1IM7UnTvfvX3xMJITbrHtLndiK0p0pR1ucrOzFz6L2wwzTFQoQ5S13f79n9gtSR1CZ1 q/nQTkRA1XMujlZ8pLaFS98a8NlvxjNV+AWa77nr6f2uM6JRBJXJYVZhIeYecorsMAewECsCyK77 ex/ZiQ0fIOx5b1PTJrHEBH3Ua/zOTkTk01faAJ/YiYh8sqVDc4VYsDhaD+2f23HI2/AQs4cynog8 XEKqLv7/hDx0aPCOMz1tWYkTsCLquTKOmi7YnROx9SArcdTd7Hy60pIdiSOwL6IzpEMrzrTPNp6I iMxSOx8smCzjGQtx2EZuH7RnsrutE3GkmlxU8kF2IlIFxDzJw/2fiPgQIyu3Fe1EGMfak4f3PwE7 KLFVv01zrKGtPMYbO5EktJgdBcOCFK5T8XuOPCYVUqTJ6rU0sYx7EFKS+c5OhPIgnFBrfGInjlZc Fkd9lHi4QXfURzl0m+mOuId2IndoOItLNHpATgLbU7rufrFEo6dFjhQu9Tbf8xhOH7bd4y8mrvsj gBzHcJgedH1lJ6YxyK2H7B/YiYQUbiVk/n4/ccyt4xO/Iu4JuBrp/WDHjevh1IpD7Wghyuh30qOP j+3EkpEQ6maMR3YizkvKWs7RTmzDONbm9xwJgm5Smt+uKUlIKy8/ssTgCxLeupfcrq5m/kIRbkHC Xdesm0ce7i/CLcRcx9RVdijYL8SCba90Q2Hbu6twC7Jh2x93kUzGSGoh9hYKpXIeND8wE0cTWOzN wxUeiVCsBO/aPerryxqpj8C+bw3t7XCFC5FH72vzyP8XYmbbNO42saTRZOrhChdiHXetmR2NBTfY n1aKw+3eQkRImldKM7dmWyHjhQpJi+aV2VYIsuEismJ9rKZCRu+KUHIo2C9ERKR855p+MsfhCxDx VIr6BiDaiVCeqFOFR3YgkmF4xLJ7RGOTOCYLc9WvKvrSTqRRL9RDH/cgjkal0ovDyzgWYqaAQ+0n mDEGmJoupLyyE6vAt5bukGcuRChPjnqWy+6tS2wBxkfd9Ty2EzkFhs31k0wZk1daMJb3hZ38/+ia YdLXwjdm/18qISnUMwOPzf6/9IxkoRYPby0SynoKd30QpXBIg1tL7JF6HIE86o6R/TYMo9Nb8whO jjzET1J0A/djM7CWwK1nh5dwnYBjTHilTfoeUh59gzXv7n3b4hHsTcy9efShnIiHXLD6qQ2Nvyj6 RWYvzMBRt80ks9XlK+AY6U3EflKpNbSVC6NXZuB4Y1ZyPMuEkLvo11D/08obGWAu3N0WyKOGV9L+ FtZN4PB6PXc3+8pweggeukNt9QQsY+yuOFobhh5ydjQODPOVJGc3MUtM8AG6495sHCQ1pPm6seqh GYg0DTax+Ull/N6j7hEx+72RprWVhjf7noffa1n8gMPc5F4cehuOwHFpIFLJTRFHjoZYpDm0sJyA QuN9suzQwXICZmh20gbsiRk48qnWmt8zbKNpp/g55vGiTZbCbmozBiMQFzePG4MjENlZlOTnmEdy Rtz9dgwvFalkN7c3MrOYtQuwr7C10MTlZbxS++bl2rd2HCLi0nUu+p2diEyq6HuHJ3ZgrnBSPuHX iYiYWEjHX9VOHHdrrXr0t5+Ih7u1lX/7JNqJ44VGkV2ihxNxvCuw6hvFO3fRMWRGPMBx7bPp3ZuN H5nwg4hGpQOeP8I9yHjTSh3VS7X+f13qK1uHcT0Yo5VbmAtF7w1cG28vj/m8R+3i63S3cDWkdEeh TvVuMeKQY/XOqt/tCysO+Ua8I/hr2+fWcSNQpnLnQuyE+40VB8/amsL99gPu5f8BXfOj7gplbmRz dHJlYW0KZW5kb2JqCjQzIDAgb2JqCjMxNTEKZW5kb2JqCjQyIDAgb2JqCjw8IC9Qcm9jU2V0IFsg L1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgOSAwIFIgPj4gL0V4dEdTdGF0ZQo8PCAv R3MxIDEyIDAgUiA+PiAvRm9udCA8PCAvRjEuMSAxMSAwIFIgL0YyLjAgMjIgMCBSID4+ID4+CmVu ZG9iago0NSAwIG9iago8PCAvTGVuZ3RoIDQ3IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+Pgpz dHJlYW0KeNorVAhUKATjQgUDBV1DBUMgZaBgZmikkJyroO+Wa6bgkg+UDwQAxA8JXAplbmRzdHJl YW0KZW5kb2JqCjQ3IDAgb2JqCjQzCmVuZG9iago0NCAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFy ZW50IDcgMCBSIC9SZXNvdXJjZXMgNDYgMCBSIC9Db250ZW50cyA0NSAwIFIgL01lZGlhQm94Clsw IDAgNzkyIDYxMl0gPj4KZW5kb2JqCjQ2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiBdIC9YT2Jq ZWN0IDw8IC9GbTYgNDggMCBSID4+ID4+CmVuZG9iago0OCAwIG9iago8PCAvTGVuZ3RoIDUwIDAg UiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvRm9ybSAvRm9ybVR5cGUgMSAvQkJveCBbMCAwIDYx MiA3OTJdCi9SZXNvdXJjZXMgNDkgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4 2q2dW48dxRGA3+dXDLaBgHFvd9etW7lBTEL8QkRiJUHKGwqRIhGJ8P+lVJ2Lczg1x7tTpzDaNbvs tzPTde/qmh/Xb9YfV2D7l7Cu0uv633+uf1v/sz68/qmt3/20tsOfn75bH77SL/zrJ/9/f//p+s3y 47sfqIc/Fz/wo/68fen48bsf1t+91c+IpXXosL7Sv1W07zcpwEvvXPr69of14Q+t2O9++/36i+8+ Wd/+e/3928P17sMxlDGqXBP7buJyJK59UKm10jXx9U7icr7GFeooDaGFr3G5uusV+lRin9fEL+NE nGU2csQXcaK0MibBNVHCRKxcJnbJu0bso8zeW3itPZGaXiOOa+I/fvEIcrkl4isyF6nsBPJ3N4jL Y0qzooyCwwE/dMDlaVq44lAgNrcyn78jLvv0eqXWCg3Ea+LHnywxS7FSb4Wx8wVxiej1BVH/W8ZB wpddWgi1VGJZX8Hhe7MZVubBLiqpl3qWmo4UgjVVlb5cPbsPYqgGRbjhNe1PMZpaLmkEy14PsE0j KjBpXNM+jdGkqi8RWR7Vi6fRpEgnWvbav01ar60IVL6mPYvRdE2BxUlITHJ7l4KNW9K1gfo26Zyz CqpA6oWqk95H7fENnArclOYu7h+fxHDqI1mmk98eow0uVaZk3etUHNaRsxBQexky3JOrMVob6h7Y XdvLGA3QBNgJyesYjao6DHR3+pcgTQrJhKRFVa0vzF4fgosq+uDmcHbkRYw2plpz72liFhPNxk12 9vdNjGYRd0XJuVNEKNOrfUwXkKbFhz1nSS3aRLXBOSYJh7rUDkk2BIcJb3NL+nmIRtWcYJbxJY0J GafT+ocYTb+qynUN+3MMZnErM+TILtEoA/yNBg0SseJqlpchocIwnIT8PkYbqLQ2kh7cnIW6u7QZ gnEV9fVNciI41tyoo48ug9emWbUMgZwlZdAl7Uk6z5qeg/6zuLQyRhulqZDkxA0sUAZz1pJqSl6B 3JL+MUabUhqOeeeS9g4Fb2Sne0PoM0tFd1YfgvQYDbhAHS6VgRgNp8W89xreM42xiHjvF1wDSz2q jytfx2jqmaEJ3RmPn2hdPXNDaTl32ussc+C804KcaZ00HoeWdKfYCtbudP6zGE2t2yAfbe11zWcc q2qBf3CP5vVdE8cxe1tf2d+sYtbVUvLaGp31/qLGBb0GgUsDKcLV1W//tBu4nK6QLCH35dvnO4HL u1tmKoDIa/QZLtfPUCMc7I13F5hvEzXKaaM74sswUJ2FiqHsrvzfAnbN9lkvcXfh/yYQrLo83RV+ FgZiLdImrHst1m0gF5qyUf+OAqkXZNy/rXUTqIliA0y8QumlpUp2t+xzQ7LjlzhYQ7Q5du/k3QRq TqAWVvLu+bDZ2Kqk6Yqa5zK5O+WrYSBYVtXTVAVU92B6J/BBHMhlzgZhr+KArNZh8O5d75u8ofHR xo7gp2HgVGtDPNPWRGMajQfdBT6EeVbMU4udpnioYdyAMdLMIYJm99UvcvwRokYOg50ivwkD9eME LzVhy6ARuqVeeXcsVt7jlhY34BwFoXKa1FBTW9h8b0jYFlJHDUQqpK2Jhl2qyS1vUQg1F1A3leeh SCORNutMizdJY+zBLc96kQq2D70+CuNmtRygpd0wVyxVU5W08JWbJdzobM2fw0A1rxUI05aEwTQP 8haFUe21JlNpsSETqQPAxPCVGUtn8sHhJ2GiWtgJRBnLYqHweisBfxYGol6h6l+GrhyBrBl9HylO 5QgcGtpMn1S8CAOnOnrGnrYo1ivSeu9pV9ib2psJzqmMMLD3UuvsicBZZkdOE5uubo8mpVQIjkD1 elx9O2TIPByJKtnA7Ihfx4FWt5l5cihQBLwuvwkDhxSsPk15HgWCakoVlrxFgTo1rxBJe4iaRVnD XEqicgSqqsCgPFUBVZVKzIkP0erYLfMhkmYWG9r8EAayVSQn50miepU+JqY5UnVRBYfP9uKrgtU2 iX3EFBYcVLcym+9DDrtmtK3iAWl+D1FXmXzNNOwEUOVQhs8EwoKNDJoye1cfv0JRNyU+f4w/w6Fh cQdIUz20WhV7rxK+QlKTTTAkIxM4ApvdsjfZEAZ2KU1Q8m4Zq+Z7nFLTPQIJ1GJzmlwTTTXYmGZq SKzXi1qaFyX9OBvOvCWZUzMpfp8DaOejV9fkZWMPF2yfms+nCtYnnipYtjeET7BD38ZTy+yPoE6n Cp6yIMvtneozTWMa5Pmo/C3v3/c+0w5NIL4AdFk2XB7fRT/TqBYacjO9W562J/+OpiFwp82DNsuT N/jPMNWKBn4r5vljh2y2aWMU9W1Xj23Z28twpqk+dE3pro/rvAjRLIPVSOP/FnQJdZScabYlVi+K USfaVzEajJ/tlZxg38ZgaohBBfia9mmMdmjOJEp6bNaciRehwPLEGt42zVrS+riGvQzBoHUrO7nH FpNdsP6Zy72gE41iNP2qBlDuTmuMhmSHKK9hX8dgdOix5xz5sG3SftlRsMTal844qaZX7uL2Nhqe cXa6pvtliBkkrFbPlhx5w2aVoKwrswPa3HrOmqq6l3qxe7SE+m3fwQ5VPndpz2I0avqpjqQbJbXi czhT+TpGE7Qd/iTrhmPazi8m3akmYCJ+FWJmnNoo/XJnfwn1755poOkrDffcvojRUFWhz6SowXKk yuJWYcRorAE9Xxxdv0tCSKSMNHukC1Dg8qD+fc9tksZuFXMkhC3bHzXJvHHjgk1mjkWygxOa51OO IWc8yFvSmrJKr+qqo0GMxqJp8EjyC3ZyQiY6XXiI0dTR651yziqIVU1nu9vLaN43rzPwJdTIfkad Dk7cKx4nmhpeoAn3mqMTDVURNsQDYjRuRWi2e4XtTLOjxwj3huMn2kBLc+9W+RPN2kkrSc6a2sEJ IZYc0e3NOpq9cdsd3Z9w3VoWiXMe3OEcBnqBe4jRSKM38Ynu7szjhONZxmh3h5YnmhXkxxw52tBt m+myDnrXg1PZLQ0m5lwbaFo0GfnewOFEU4HTGBpzVkHDo1KlJ+kWqL2UWTFJt8CO+IoXuJgxtyEB 6gVb0q2OZrs1M8cJwhTb00xyDWh9edIhR0Swqfkd1a3ClzGaJuITJ+asAmItGsP1HNVCIotUkx6b VE1PqSfdqPUkN7i30nuCaSZTuzdI34Zo1oxcO/R7S70nWj+MUkp6bJaH66XNJA9I1hWIviYVM0jE mi6IL/xIjDbE5G3mBCJcuyrWvNtYzqp2bTtd+CyG0vDtcgM1uAInGFhzSnUa/zxGu5Et7PZ+J5x6 P++YX8RYtsPGPhIMrsEANUY+9fhrjKbWSH3f/VHqEdftbMRGQB6TEAvvZ6W7S70nGgwbHCPvk5B6 a3f91hFkO0JEfTkcal4zDjUvR+LNpuoP9h9CPhMRNXb1J9oC/bZnIqmB3+ic/PAOog2s8Eevv4oT D8rnezS+jRMH2yxISTh4dyZqxo6U0hF2InbNoQD8TNOP40TbXto43PwsTuwaxDeGxLvuGsiLP41c 40QNcSdiRhf9mUhWpqT3TEndTWQpyP48B8WJqjNIfsbuyzhxyKbOfBEnTk1PJySujFUKBnvbE5ee Q/UXkPMkHKAVDYETV8ZaAerwK/M6TlQbLgSUeNd8GMG1v7l8ueWwV1AR7/L0eRfLYyHAoTVgIvBj ir08Nag4tAfwxnG3R5vG3kPkgrNtdG8ve2evnIm9qnv9WS/asiuo2CBqCCCH3bQlJD6eaFUPPwSr xYFkSfd0M3F+GyfaRm4Td42v7iDadj84IsWJQmV2P6Tv4zhxHHaflvDpBBeH47SSVLwh14XhNh+S 0R/2/jochlvFZqvfMm4eNYhS4fGBfTykoD4Lj5YYPqo/KIR+ek/czRDO0v0ZhS/jQG4WR43EhdHI DNAfmXyIE2UUGCIJwwzORNWYwcJ5C2MH0wkE854jq8r06Q+Sv4kTu7oEpsTokYGtvSoxF2bsdvwh MR5lYv1UE6NHFjVmsyVGjzxsAGajxJWZXAakpJmau/HNyszLMJDU8IC3thAGMpQU0T7ShEuTlnEA 7gQcVKC2lrciUyEye8LwpzPwOCA9o8RzAFr1pLU60pbYDs8P8TPDfhMGgn0DE86Rn3hqvSipNngC quvbKA2+CQMt5t6Y1fE8DLSjDRvlp8hp2xNxoFqGlFEdJ+A0ew0Zs4uOQKhmrr11DRtDaGI1E0wz X3ZygqqfaPAsDEQ7y+Xfu/U6DCQsnbqT7L+EgTZqDonyBBHY5gVwniCC6kpn5Iyc5QgcNtjMy03Y S8EcpTKmCbadzxCveWEPgBrCanY6M3K0E3Bacail2QZ7wUXjOtNUGcmmjfY8KTyWXWpK6fwElDKn SN6iCBzmVueJzbCXI8DIWxTVk62ZNmFzSK2XRtTSrtC6WmplTvMAVszo1dfM40CkgjVliuIJqClF Fz/ZMmy9iNE6xzKmP52AogEsU15aZqURTesxLQkg1ZTekdKSAFJNIUrUZauLQPe6/Pcw0HzKxpy0 D+PAacOaWpqmMEy1Nr56Gg9t2PIKRsgoqR2BFn11P3D0IQy0SZQbU7uf+iKg5dgGg7PbCyt3DoN4 P2zXMIhHUDuGQTyB9sRhEE+kaXLchi9pPsRoKnEaZ+03zts0eyMINkp6bqMWDM0i38ZpvkngHdtn IVq389Kj7R8AvU1rNlu57ffi27QuGkoOSHpwHcSOTO+vx2zTEM3ztBxtsDeMwPTL8HmMpiFzq3X/ XtM2zeLlHohGt2ljWrBMa/BtTD+nHWoltWPOKoA6f8a6v867TdMYGTd6DYLiq8/MXl3HOQYTrPNb nLzNGIwOg7kkaRXYPnkJ+ShGs80PHC3HM8BU6RVJMr5o+9bdpxSxKMSqF6O3JIuE+tWfnfhf952q v6bNIgKcY5Hw8BKXwEsGtmkmb4EXe2zDRDSPrT1pEQaW6pORmCZQNS3tSWtgJQU1IiPJuumF2Tj8 NfryuisajNJAIOlW1dVP7knhIGkuw1KTjOWhH2KMLCdj8yoAfYwfXYdpI2xl5uiWvZtzUpJ907So yBgjJ/C1pLwN/5aSmF84ZOQwOemxkTWP9Kw7ZdsU6PeKr72gQ24ku29iqOu5C7GHdqZpejqqTwH3 KsIZR71QnXKnQXpHm7ZvO+80SGeaUKkI+zcptmmango1SJKPKXaovt0puyeatQzMMXMuzV6eNzrL nfH4mWZvzqN2b5h6pqF5BV8jkBhNmk02n0k0ey3DTLpRO2DQNwqDMU2wUQRzIx6PCQiA9bn6PZI/ xGhqQebwevVVjGYz/KaPt/Di3J46jVnZfsr/bbl5nk/Dwto78fqqdft9dPh9Um249GZnzfumq27D QEbp4F+d9MFjLfc3cOPwkm66nq/6y8ee7C2clNb86AMM4tTtzsv2khPuV1HcUEck+8cmbeMOs+sv u8NPuF9HcYdo1uEuWrC++R8k8wSoCmVuZHN0cmVhbQplbmRvYmoKNTAgMCBvYmoKNDA2OQplbmRv YmoKNDkgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0Nz MSA5IDAgUiA+PiAvRXh0R1N0YXRlCjw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8IC9GMS4xIDEx IDAgUiAvRjIuMCAyMiAwIFIgPj4gPj4KZW5kb2JqCjUyIDAgb2JqCjw8IC9MZW5ndGggNTQgMCBS IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42itUCFQoBONCBQMFXUMFQyBloGBmaKSQ nKug75ZrruCSD5QPBADEFwldCmVuZHN0cmVhbQplbmRvYmoKNTQgMCBvYmoKNDMKZW5kb2JqCjUx IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNTcgMCBSIC9SZXNvdXJjZXMgNTMgMCBSIC9D b250ZW50cyA1MiAwIFIgL01lZGlhQm94ClswIDAgNzkyIDYxMl0gPj4KZW5kb2JqCjUzIDAgb2Jq Cjw8IC9Qcm9jU2V0IFsgL1BERiBdIC9YT2JqZWN0IDw8IC9GbTcgNTUgMCBSID4+ID4+CmVuZG9i ago1NSAwIG9iago8PCAvTGVuZ3RoIDU4IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvRm9y bSAvRm9ybVR5cGUgMSAvQkJveCBbMCAwIDYxMiA3OTJdCi9SZXNvdXJjZXMgNTYgMCBSIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42q2db49VtxHG3/tTnAQSAgHj8fyxrbZRUkjTvKkU FaWt1Hc0qVQplSjfX+r47vUCd+7Zez3XIsqyLPzW59ieeR577H23/bS921D6f0xpKzlt//tl+9v2 3+3lq/ewvX2/weHX+7fbyx/0D/793v7tX59tP4V39/8gHX599A/e6b/vf3T3/7e/bX98ox+JImTM uL3Q3yXqX4cSUQIAxEzbm9+2l3+C2L/5m1+3r/71dHvzn+37N4cGz/EoRWwMp8R/fjWJDAO5AXME lmKQT69FhpNWblBqzK2Z537sJuaUYi61nhKf+4nAUZhPgV/4gZkjNZBT4is/kWoUJDwlfu0nFoi1 NVjYxsb6OZjR88JNxFQjFdMx3/qBCNoxpax7jcgUi9h57R+NWFIErDI9r8NeqNiwUmwp5WtHeLgU fDZsFCtLOyX+eEIM14azTQdObK2Zx85HYpgNkBthiwA29Hz+NPhC7kYsGnI/mYVhKphZooZHLNgH ZPi4jclN5ASRQSh4o5klauKighC809ASkaIAl+CdNJZILdYCLXgntiUW1GkoEm5Nrx8yNteiIbf6 g/g9MRwbKdo1IAb40q0AJDcNZ3bO+AOkMMaEZPIM+4mixJbRzusLRMwRUmIJL/R3d0RNWVS30uIx Nuqfj37OxG4gJIkm2pIflyGWlnBal4WB3AwSa+RS6rW6LJw20hI1EzJfkWPC+ae2QNGnpvaAigoP v0dL1GjLWLId3eG6nrHE/oEkn2aEdG1fG2KGHDPajPDYT8yaY3Jp0xlhn4gcOTOHnVztIHKKtVri 536iRgkUmxFuIBaOFSueEp/4iVVzDGXz1K/9xKZ93XKYFfW7QFRvBKWZJvqHY9fgoLPwlOifMqjm KAnkdQMc1QhnrnXdAO+qXqCWhW0sKphRcFqW7RNV1JeMdVpE7RJJ9YlgrtNCb5+Yc6yJHLJsDxkI UT9wm/athhhGI0ljTwbYbnzs8OGxNblSy23zTkOjKUgHJFKBdSqKqnaNpoZ547rf2w0jJ7p6reey SlFalCJGVDy5ZFz3iTrGW011T4SH6TGuqTUycTnzIr06hVEFaf7Er4fbwrhKvZjTh+ETbo3iLFXf 42HdI6yJkFzUricxeeEzP7HqNJRi4tkzN1HUridKsi4vSKoqIK1Meeknqv2oyS4A+LOhYOm+dZ1M 6S6z8dLXqO4DNKQtbOMhYdtVD396lb4KR7RCVKjlUAF+Z1zDrFXfx8EhfuOCRx5ETJEAVwydQaSi gSzVBSJ8ECVHxEQLNPMg9mXCM6rnuZ9YW6TiWCbcJzbRzGqAj9zArIOHBFZ4wkHMEhNbJ+zvmEz6 uUq9da8xU9NM3eq6AZ5FnxrKwkmYVem1LAsnYW4tFrCm8IWbiKmpiKptgT0aRB09iHbK+N8jqk/I Ku3XTeu+HUVQ8gp7dIcMKBxTq7zAHo1GFtJEiHJp8+gKezSIDdS5WsOV583MkUipxFRXuKMBBB2P XGiBgxvEvgqHdpc5+Ymq6RHsnvAXNxBbFLQVBd/6iSrqScOu21tbYi2R7TLz125g95ic5n3wA8S+ ClcFF7axf954futon0gcRRIsbKPqKJY2v3X0ALFvEyKum9asqRCplRVTpqij/mTvCOctq8Vl/SBj BuJNj3wkqnnDmmFhG9W9kU7DU+IjP7Evt+bUTomPbyCWWGGkQVzR0WriAIDXPfVh76hiWffUWbOW zmk8JX7pJ6qBK2VkLZzfRbFENXCNsK0bj1lIFXPihe+xgJrMauaMZ210IKs2km0jdzeFH1gcHciu wiuY8fNsfnH0SMTMsSbhvb6ZWBwdRIIewsH2zfTa6D2xxVTGAi7er416dP2RyCoeE9LdUibepOuP ROmSWY4+E29y10di7V8Zy4R4i+NCqL2ytVdRhBuqKE6B4WwVxVs/TjM2SyrbzcuY4fjEQFV9cDLS 8bt5IzOIopmQbW2LI8sMYs+EvHmduuWpWia0RZlfu4lZ5TKSLNk3Gsiul8lWt3wxHxoHUWWUtpGm Cx73iajzhfe39ML0BMx91zqXM/YtOKd0VgWuZqucbhtld5DIKqNKpRW7PIPYi1trNotRP7qJmDTF 1FYWFHrcE1uEhm3BGvMgZp00GXnBwuMgIkQhgAV1GYOo4ZFylQXLrYOoaZBSXlGXMYilFzzmsmDP YxA1QCaRtrBnGqmFI9PXX7qJvdgaarNVFE/d2bVXUbRig89jd3Yl1WWNAbcbV5k/ZFcSiQVrWZdd qWDXZbRg4XEQq6aFJiuWKI7EXhFeSi4LiaDB58zCzBM/MWvwObMw89pPRFFtZtOrX/kwYyyQVqzg DqKou75Lhreu4A5ilUglw7oRzk2furayUJ2JCj4qqV0rIS+rs16hoJG8XXrs69WZ5EN9NE8fR9kn Ug8VdgPAo85YNFWfqzIPvhB+5KnGbfWjZw7uDa5BVI2racaoveInCqsOtxuuj/3ECmpoluyE3xMP h/VWiL07YE46BwVlhew5EkGzDFn56NknvEMGjbUacKmuEADHRhL3I4rbjbInfHhqqbHmJcn6CFTv ARWbewHAElvVJMOyIoDfETFxbGBT6xM/ETBmsLGx+ok98iC0hU+NKUJuvPCpsUSVAGsS4RFJvVRv 5uBxeHha97p15nyVoAhXBQosfX/r4V29MBV6sAtcaueNQvAEM0p93eN0hAdPodAgqj+S9pHoCe4C l0FE1Tz1cPTok0z4Vz+RcmTKbWEIJ1W4SJS3m1PhCOEkSRsJJik8csdwKiVibkv80ZGoA7ImW279 2E1kHZDlCjk6QYTc3TWvS12sApe4LFkZPhI1XWvKns6F2pAEmknDi1xikw7UJAiyAfCZc5mYk5+o MbyY6PiLn9cPtyag6eG9TxSNPOgoHgkDuRlkUSfcgKcXw/eJtccJe0r44iGKB4g6B8/InleX7NYu se8qEJFM2619IqS+osCni+GfX9vZltgL6/EQy8LUXso+ESXymaXr4idy6+e354uZ94kqKdQT1mnD 9QCxaU6wdfA39ExLGsts7fFLNxGTxs3Msu49IvRq5vlC4X2gamaxRxSzH3g4wy/zx//2iRpwKxeY 3prZJ6pCUX89Xx29TywcU7Fu3T8asaqFa4nWzRhsXdbbQ0KXxeMeMlDfNTsjzC4vSJ0gw30rSUc4 cZ1fcd1Nr4T90ixbA+AXKf2sZ0ppXus9QNRoxvaCq+InFtCJjfNm+AGifiXbVeHXfmKD/tT+0WOI XYW3WmChlOp1uDptYJ2U6hsfJYkhfu+WUqxDPEOr03UF+8QexjkbW9jcUooZTtsYpoaPJfad4VxP DXvzA0u/KozNPRx/uYGojkvawijej6M2KvNXAOwTW4vS7MmeR26i9L3CzLhOA0juhY/M65RUP46q kWKhIhXqNU1WnP3gJ6pOkSLmqf/hJxbqS80wfZh5n6guDs6cC3O8R0LoTv3OsE8XPuzzuPTrI0wL f/YTpUZupS7Qj4N4cNc1L3yL2i89yUwfhN8nNoml2tOez9zE3K8ya9WMb/QTs3oFe673Gz8Qa794 jNd1TNYwQWyFffYT+wBvCRe4wkFUuy7YcLoubJ9YS1RXuDBMqO2Iku1ND6/dREwSKxKv6xnM/d5a u5DisVx3yIC5n66zN9fOZ8IwGkm9RtoWzn457+EGUbRrIM8fzbS6fhD7eibmBRZuAGs/Kuwomtkn NrUe7ndocKS2o5G9/df/DklHDla70/PKT+y3NILtFo/bGsi+HVXo6q2ecHEOkrqE3ACm64T2ib28 ntruU4fpOEE19cNHMH1J4T6xXxNSPylcC7fF215S2O+Ymb62dp+oQ7xKwXUyqvtggSLrsgyrGE3N LuH6FcXBB0uChTmBu0/IkLebX+TICVwOt5mbLPN3d05gDbjCdtHjz/N7j/04uNDCG1yPwLNnj37x 41SLaj/798EtsV//X88stzrKUQZSR2MqSRacmrkn1oPSuzQYr6jLHEQdjLkVnA+4+8i+ul7OXLj+ dL4y84jMKes4/2SAe69bG0SoGh+TibjP/USNj4uurrknln51TVlxquAOGTLT4e6a7eY7V8JoZEmH u2u2G28VCh8eW/06pVxW3PcwkJqxU6UFNS5HYLczmhkM8Wc/Efq+MC4oSBlApMhgC/a/9RM1nmGy D30DUTSeJWuP/HmmbxayzdZP/MB+CydIXnCxxyA20UwD63q63wpbKLWFqatfC6sW7ur3eDl1dYdU SWhd6iKSWNgeIX3lzlyk3rqXAE7/hIt9Yul3hTXzEy5+dicFqv0nXBxKexclLmrdri+5pvhI5MM+ sz1W+MhPxH6zV6IVxZnHVMj9/Ei21z09dqfCbhUS2MLH5+5U2DfNoNoKO3/iYk2uIriilHIQW1Il Zd9jcROlD58z5679EVK6T6oPVSmkyNiSYDr3u/D+7c53BP0+Ofee05yT1H/S3YpaPfOjyT67VJC9 A6v955xZF/G7S0FpD1ciQDHnnC7+NI0dXMuxNTRnnH7vxdXIHwuCcOXwPI/rNTRZTNn5H7y0flFT bae4b3y4cqch4YHW/fR/p/mBkAplbmRzdHJlYW0KZW5kb2JqCjU4IDAgb2JqCjM0MTMKZW5kb2Jq CjU2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEg OSAwIFIgPj4gL0V4dEdTdGF0ZQo8PCAvR3MxIDEyIDAgUiA+PiAvRm9udCA8PCAvRjMuMSA2MCAw IFIgL0YxLjEgMTEgMCBSIC9GMi4wIDIyIDAgUiA+Pgo+PgplbmRvYmoKNjIgMCBvYmoKPDwgL0xl bmd0aCA2NCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjaK1QIVCgE40IFAwVd QwVDIGWgYGZopJCcq6Dvlmuh4JIPlA8EAMQfCV4KZW5kc3RyZWFtCmVuZG9iago2NCAwIG9iago0 MwplbmRvYmoKNjEgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA1NyAwIFIgL1Jlc291cmNl cyA2MyAwIFIgL0NvbnRlbnRzIDYyIDAgUiAvTWVkaWFCb3gKWzAgMCA3OTIgNjEyXSA+PgplbmRv YmoKNjMgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIF0gL1hPYmplY3QgPDwgL0ZtOCA2NSAwIFIg Pj4gPj4KZW5kb2JqCjY1IDAgb2JqCjw8IC9MZW5ndGggNjcgMCBSIC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9Gb3JtIC9Gb3JtVHlwZSAxIC9CQm94IFswIDAgNjEyIDc5Ml0KL1Jlc291cmNlcyA2 NiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjarZxZr1S5Ecffz6c4YcmFYTB2 bS4rGwQSlJdERChRJJQXlIkUaSIRvr+Uci9w6XLT3XUsRlxo5v6ul6p/LfY5n9Z366cVpf/HlNcK ef3fv9a/r/9dX7z+XNaPn9ey+/X54/rirX3w78/+//7ph/Xd8unLN+Tdr3vf8Mm+v3+0//3jz+vv 39tXolQAAdfn9qdM/d9LTSgLFE2g6/uf1xd/LKn/8Pc/rU9+eLq+/8/6h/e7Ad/Go5Jyq3xK/PFm 4rInrsCSqNofTojPbiQuxzGuUFuqqHRKxGuJy8msV2gtSUU8Jd6FiZj7GItbxwdxItSUs/DEMaIR hTS8M54oOSE0N8bXcaKiWQ/AxFk3TIyZ5o2RinTrKafEN3Gi7QyROOLjOJGMmL1SxO2RhGzWtZ4S X8WJasSCdd4YOZekqo744ckF5HJOIFe2zTbzcVLx6AxxuSS5K6Mm1Oa2pp4Ql9NpY06Zpa7PcffT WulY08aDs0DKx+kC8Tewxa/hEFayJOd6v4uhSktNWc+v2zLe3DENKWlt56LUcs5SxjDi5LUfYyzW 1HIe69XyHRse04RTBXZa9eLp8n2PGNOqmqq0k1VbzpruBZrpKMA3qrdcpVFDGmT7VPJX81j2M30Z oxVbN2nllPZjjAbmBZAd7VmMRuaY1OopDWM0ZtPMe3u6XBkfxzQBsxB2M80xmtlb4XuetXxfKi/Q zN4y3ct/Nu2pKXii+3nucmWEHdOK5T3IOMd60ewtE86aKVp2YhI3x3qRu4VQmWO9KDbTQjjHerFC Umxupg9iNMtGuEmZNDb7QlBwzi5Qrgk4O69/HaMBpMZt0kwJrPJRv6fBsVHXN3B7+iZG4z62QnO8 nqR7VoM59kamlljZxYVXMZp9aSR1ztjY1LJmdDO9mEefwRXsJkJzAgODfluILOP8+UqaCRwL6BwT YTM40OzM95cxmmZLaxjmiIiJmwkcuZk+DNHMSdP9sugA4yCsWbGkMCcPkV4soEyK9ULFzI1gjr4J Ww2oMMkVxCKgBcA6iaYWZVTbnF2o2aJMq7BxF6zksATkpDINytGRZSU9aNnqVkcaQiol66R5otWT pLxxR480NuGFohuztyNNzD7arGVTNJcvslFAvtBaD3+TJgoW/rjUOXvQO/ZU8iQ/AOCulJM8AZAT 5FbmbCmwOT7qJE8AU0qtXsU/PI3hqu2pkttUiNFMKpuSbAwKB1ovTqX5Xc0xmgVT8t2LmGPhrhci MMcX0GJpKY3mWAiSWQj6CPM2RhPzBVJnIP+I0Sx1A6ouP7p4Utd7AdqgrM93XYH+CVu+a0GL7zV6 j76AkMNArJZc5rKc9BpLGGjBRpFOef8M86otLIKeAv8SBlrIaVR5ufX09CywWTLXaltuPbY5B+yB p1gNsbj+bxRYKJXW3Bo+CwOhq3J2I6xhINnvyM5sXoaB0gsThnlTrpxaFQd8HQZasiIkzvMeRYFo qTbZEKeNEC1DtmzPbcrlNGNA3PVxl2/1a92gX8ue+EXA1o0CthzHeFSwUyBcC1xOJm0ZsyQs2G4/ jzy3jqaKnHKldu0gl0s7Y7JYE7O/FvCnS+eRZ4mQiyUNJOfGuNxqPaZjvSFFg+sVS8wed3G6apHT 46xHUQu3ZFpMyXYHZMtNx9me2O9+4CHmLzN85kBczvnMx9u98DhGsSitWcJO89ULj8TaO3L59ksl 3g2PRLUkdnCGD3Fi01SLP/Z9EyZCyamxP+J+FCeahbfB5ZwaJxIlrjRxiFbj0eC8O77VUPt9NsYZ ivsF2ZKy4LWXc5aLfg3KqSJdHuRytVRAI0sB/Eo+u11yD0TMajmADIhLUM4QSq/X6FRyOSyQ/Yvu A81myRUb3FTF7cCzgvs2ILj7ETIkbV55Hgb0dg+0HIXcLucwzgrfkv3tpruASx+A9tcmt+dQ54nm KzqQ2vAQ+2UWvX+NYoOM7YFWtnHxSd6bMND+KgTuYtzfwkBLdmqROiOk7oHUrFIVWaOlrwNaYlLA pxFxoIWWIkRrtLB0QO3nVF6zH4aBlpVwZphmh1ggFX85PO56pqSpob/oehcHiiU5OHHKlBO3wOXe s8Au2JSdL/85DmwJ0V+wfxwGipWUrciMvG4PrDU18mu4wW4sCFj9V2525kNzdtk3Z8mEmuW6O7PX woZ3ZimGMu9QzC52Xn3kcYLDfnW53axXY5iZMYrefll7TJN+O9or1aMYzTY0F+WbPWJMs+zc8n2Y NNNW+4Umvfna/JAGxQiKk3YB+kUwyrcXS2dwiClDoTmbCmQiUqjeXL6OaRa8W2k6aeEUE7OvjWIG By0nbF7cIETDTKk2uvmBrjGs10O+7RbbUbRPCyrMWbV+z9XcdE5EQMs+WTPN0coeUP12xgwXtRnL 1xYvQzTK/fqAf/ghFvqolG8vq2wyD7KQr1T8wzsfYjhs5gcqc6yNqDd3Bef4KEm/KSG3Z61jWrXk iAI1/JjWIBH7UjG4bs1yreYdKxhiOFvuW32qGsyQGPphStM5Bmy5VmqD5wLvYjSzOBsazhFy5mpC 3nDOrrJgar74Dy5b1aTiO1oYo3XzxVlKLlkTyBy1FIulWfn2zt2YZp/WhjzJscTKXq3+yO4uSLOk tzWdtAlmbRx5ynhM69Uf1kn6Jr07WX0PJ7huZrwt+8O0WJZqBXMSrpvzLbRBnalzX8RQRVMD2uyj Bxpawss+33oQo5nscsl1s18dcNwv3RfdKiEHmnnCIEN6FYNZ2tAGD9UGzcNKIgWuWxOkA62Z7gJv dvk9rd8e0MGD5jlGA6sVoExat95IR26z7A2on+bkNmcbeg+9gneGv8Zolcx6cWvWcIBZXYR5e5dm T0NTzEa+S/M4SKupDu5EBPcUS7UEybv9XYwGZMHBn6fVGI00DULMrXu6u/Ixqy+7h03pyx5Qs/qy B9y4L3sXgxEmFNrsBwca9/5A3uwHB5qVuY1VJs1U1LwKddJM1XKkQe8zSLPEDQaH1A9DNNuAlLPv +cS8qnd5tSnN2dMe/aTI5pOYA40gIflD2mcxGmsqNcOkXaiWNVS/bjE5gv4sZ/andjlGaxbmS5nk p/35E6Aml26AXknr2b0V9XOsF9F2gcukifbDXVGdY7zItmzNnz3HjBelPwMLujUuH2itP17nk/uX IRqZIOmgXxmbKVkGIuJfDRRzU8t2E1baWikcYFauQfavH4t5Ke0OnTLN8QRSSTpNQTjbl7K9ijnS LBsnX8XEFGTXlh1c0HoVo6EmAZ2klUycSETm5A27tixEbkqMcVJTUdp8SnGgaemPTMKswbXS3R7n eINYes/sz540RivcX+k3KXMQLAnVvwySgzQ1TZKtDUvOdLaNl2MoMHnL/jz3VYyG5li1lY1CfqRx vyhRt3rCkSZsnuDL3BqjaUvcADeWRUfaLhWsvDGnOdDAhLwQzLG1/lq2Vn1UeBmjmVfJoF/5LEaj 2p/xl43Ha0ea6XgT3dzxOeKs1M2DcBrchkpJNfCO3zFN+9sTvfDGPKu/iXf0bt+Y1/frKkQ+OL+J 0XalLm+93nCk9Ydnsk7aUzR9Q5JJu9AvrFSSrddCjrQet+rm8PeFZqnl4LA55vbYuL/PAOeoZX8v W+Nc5+xCfy8bYJ4lIr1Di2Vz2/gLrd+xlEnqS2ySNHDUe26fe480S/8u/6fl88czP65AsvrN0qbn BfrPsx9U+1GoJH9X7N2ll7SOYVgtIcPmluIXl56MOoOzNBtcD2x58qtLK3sOZzVAqe79HxTE9SPp 5l9O+esorj+iUG9/R8wYR/1J4/uHGQfcb6K4/nYu/was337Fvfs/d3BrqQplbmRzdHJlYW0KZW5k b2JqCjY3IDAgb2JqCjI4NTYKZW5kb2JqCjY2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4 dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgOSAwIFIgPj4gL0V4dEdTdGF0ZQo8PCAvR3MxIDEyIDAg UiA+PiAvRm9udCA8PCAvRjEuMSAxMSAwIFIgL0YyLjAgMjIgMCBSID4+ID4+CmVuZG9iago2OSAw IG9iago8PCAvTGVuZ3RoIDcxIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNor VAhUKATjQgUDBV1DBUMgZaBgZmikkJyroO+Wa6ngkg+UDwQAxCcJXwplbmRzdHJlYW0KZW5kb2Jq CjcxIDAgb2JqCjQzCmVuZG9iago2OCAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDU3IDAg UiAvUmVzb3VyY2VzIDcwIDAgUiAvQ29udGVudHMgNjkgMCBSIC9NZWRpYUJveApbMCAwIDc5MiA2 MTJdID4+CmVuZG9iago3MCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgXSAvWE9iamVjdCA8PCAv Rm05IDcyIDAgUiA+PiA+PgplbmRvYmoKNzIgMCBvYmoKPDwgL0xlbmd0aCA3NCAwIFIgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0Zvcm0gL0Zvcm1UeXBlIDEgL0JCb3ggWzAgMCA2MTIgNzkyXQov UmVzb3VyY2VzIDczIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNqtnFtvXLcR gN/5K44dG7ETmSLnRhK9OVWaIC9tDQjti9+MpkCBFHD1/4EOV3ss5cye7HKWkOHV7kqfyMO5z5z9 vHxYPi8o/R9TWgqk5X//Wv65/He5vXvIy6eHJR++Hj4ttz/qC/9+sD/98zfLh/D5yy+kw9ezX/is v99fevz/0y/Ln+/1kShmQMDlnX6XqL+fS0QJAByBlvtfltsfcux//P7n5Q29Xe7/s/zl/rDgMR5J LEl4S7wZJoZH4gICMVWQLREGiWFd4wIVIyS7668vJYbNrhdoSpRUtsQ7NxGzREqI89aIIJFrlolr pBYLEGyJ3/uJJUVqxez6H35iLZHBHMwrN5BSi1jFCE/yExH0qFveEr/yE5kjc65b4q2fWPQdruBW QktsaniKWeLHN24i5xQTtjJPZRiU2ErbEr/1Ewn1AcaVUGUkp8QS3ul3j8SmYlOX0uLxVPT19SIC sRuYk0Rzzi/8uEzqYPLEHWdUCll9OSs6YUUuBkk5Vkx0qdcK20VaImNMCeCc6IS9bVuitNhyhj3D E85dSEusEqXVYg1PuOxoDBES6oM8X2O4yPDsE1VvEj+ddbhQp/eBQJEK9yUGlzxaogqPBikljLrB fSJLxKbmY0N87ScKqvNvbUt86ScWiSpAZo1f+Yn6oL6/hlGvtUtENWWsznpL/PjWi1QTogYcxBif 8aMJ6yIxRSEsw651QwxP29YYXN2PuNdoTC5y37W1Pbd+okisVYY96z5Qg/rSTN5R3MBDoCfJLPG9 n6gReCYT8vhdNaGaW7ZO5pWfqCG9LtNcxo8f3b6V1PQg4cUac963kmYJmhGXc9J4uW+lqgFbYrvt t27nyinF2tBqtde3smaEwLh1rX6/xSo9iRJvPaHfbzHVmEvKwSuPlih6MEQTPSGXHEmy8YTnE49d n6B5kQYACG5jZnwCt6YXEq72Mk8+QQ2ZWrPmyLd2bYVsQrNh52qJKpEVK8+zZ6L2rGab//tdoXCJ GRPOy5BEWA87myzzGz+x5ljIehrHrkF9VoPTSWHx4zSFK8Iz3P9KVNMjhWS4LLNP1GMhsTr4yk/U YyG0pSO+glj1oJNMPOjGsaEt9Ny4iZBUYSZeRdAIPFUyCnjvJ6IaiZLL4k1lLFETuFLaePV2n6iO MFXkiedSWOMJxokn0zQRBhuDv3QT1c7GkrjNk2/MKbY08zoi6PMy8zoiFn1oMqPAtSK7ecypTShw rURusVQ4m7ZeEISvRBXITMB7SjMQg69EDcyI5ERbZjgIX4kamCGTKXA56lFHolpvNRWVJtSjVqIa SBZuw/UoqDFl0KW8AxVA6a+oD0y9hqumImyLzAjJSwxZRbwYAc9+HlNsGceV0BDDumepsRIb2cFB Yni6it39M4N7jcGcizprrIWHA4pdIiQNzNAWo771E3sjs9JwFWUf2Mv/GeddRSB9IKZhl7BPVGms zYa3L8eJmA7KfdDA5QoNtMSTGvgnP49T5CrjQdQ+US8motXA935iTT10nElsFEueoi9HIqSmaQfl CdK4EnOLuk4aDyesuV2R+g6zVZmzNb19IqrmoDXg78+FE/tEOgQou4YiXO5kVqJoNJqt+NycCyf2 iQU1QKG2DSdejjvClVgpohxa/8ElkJbYa1EZTFHvzk3EjLFKnknUd6g5Co/7RNLQEYCD17U+I2Kb GUEdcAfjvV3b35wwhii63+C1YRucFA1KSGacbsdpDJ8ySvD60g2uYUycKHjd1K9xvbghpdEkMYHc y90s48XpHV5PBZKY1jQ4cagJBglPOlrgHKUxT9utZD1bmSIqRSYnPo/EncTnhZ9HGmqSDYdpPPFZ 98zq2z0lc5v4rETRNRZHJ/VESHMkFg2Smq2Q3PiJtfXaVZsRyD0S+yxMqwkmJAF6vn2yrbnTgBOR 3BPzpET+bjySeyJyr3PDuQGtcImYP0ElxdJsG/nQ9A1DdRLN9foB7U7ODReHjsATTZLw5sfxOs6K A1Lz+KweFtz92ZXYC91wOJhwzajJMyJzVA8dvHVuCxQ4TJAF77igJfZzLmh84F/9xKoRDlin/9pP 1DRSqOQZTelHZIDEmlpUXK6dfQpfVgkAEdlW4x1djS/EFkVSntAxWIkat2u0yBM6Bl+ILSLahPyK XffuENujuWLXojKOVCbuWp2Y2nCa0KFdia3PAWUaLqjuElGD71pgRudlJWq8rKmLTOgOrcRe18iV 5p1Mz0whi3tc0AK5RC5Wre/8xNKLELaYk/zE3losqU68jK1GEnsw/uvYQ5V2wuL+5CeixjzIdZ4S Emm+emIyxK+EpA47F7tGvxJSqTFPNOBUWQ1PmagxfbavpCLzNIZz0YTGDlN95yf25+oXZjSRV6Ra HtXByye+wtnAR6OJKNl2Sr4e7yKvRCk9Yah7ZxOGgzP11KrX9qa0792JQh/vU/Gp27KvP4Ds431Q iOdF9gK5VwXHK1u/Qax9tMiUZ278REoxZ1vMe+Uncs/dbfHyiuvY502JTJEr+Ym1arBnC/LfuYkl QazV3nnhkUddHB/nBWdkhUdc7nVMOwZ85yeqa6Wc64xbQx6RIatvza35w9GnMeB1kYLqW68YVnqW wh2JPTKjKcNKK7GliNkOfd25iYeBQTvd75lUXonqXUu1kdlrPxFY35EZOeER2G8CzrZaeMVlpN72 LWXiptU4cmacEUgdiWoca2GYkSgciX0i9sRYmp+IiTU9SjMmYldi1vyfYJ4Ooj4vWWBGQeFIJJXv BjKRqFmmSJsnjdi7CiIzl1hKv1Npxg0NK7FRv1mA52lMvyuNWqJ50kiQusbAPFtGvYx/4iMS/LaM eperYPuNT5pIkbElwXTqu/DwaedP5p4lQfeUGfQpa0BU+udQ1BOfivLiXKthB1azwtKJFsuZ/GEP 1+fpi2k0nO347eD6XbcNTZfh916cHlh69rkO4UI9P42j1O+tLlvaH7y0PppQ2xb3Rx+u9NuLn1ev j7i/P+E+/B+PjIaECmVuZHN0cmVhbQplbmRvYmoKNzQgMCBvYmoKMjI0NAplbmRvYmoKNzMgMCBv YmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA5IDAgUiA+ PiAvRXh0R1N0YXRlCjw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8IC9GMS4xIDExIDAgUiAvRjIu MCAyMiAwIFIgPj4gPj4KZW5kb2JqCjc2IDAgb2JqCjw8IC9MZW5ndGggNzggMCBSIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42itUCFQoBONCBQMFXUMFQyBloGBmaKSQnKug75ZraKDg kg9UEAgAzQkJhwplbmRzdHJlYW0KZW5kb2JqCjc4IDAgb2JqCjQ0CmVuZG9iago3NSAwIG9iago8 PCAvVHlwZSAvUGFnZSAvUGFyZW50IDU3IDAgUiAvUmVzb3VyY2VzIDc3IDAgUiAvQ29udGVudHMg NzYgMCBSIC9NZWRpYUJveApbMCAwIDc5MiA2MTJdID4+CmVuZG9iago3NyAwIG9iago8PCAvUHJv Y1NldCBbIC9QREYgXSAvWE9iamVjdCA8PCAvRm0xMCA3OSAwIFIgPj4gPj4KZW5kb2JqCjc5IDAg b2JqCjw8IC9MZW5ndGggODEgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9Gb3JtIC9Gb3Jt VHlwZSAxIC9CQm94IFswIDAgNjEyIDc5Ml0KL1Jlc291cmNlcyA4MCAwIFIgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4Kc3RyZWFtCnjarZxbj1S5Ecff/SnOhmUHFvDYrovtXCGQRHlEQsrLvqGwUqSN RPj+Uqp62jND1znTfaqtQcx0N/PDPi5X/at8+bp8XL4uwPqHMC21pOV//17+tfx3uX3/LS+fvy35 8PXt83L7D3nj12/2X3/5efkYvt7/Qjp8PfqFr/L7+tbd359/W/76Sb4jxlygwPJGfkqon+cagYO8 F1tbPv223P49R/3PP31ZXvzl5fLpP8vfPh0avI+nn0DPp8QfdxPDHVG6zzHnRqfE253EMNq4QMNY C/ZT4rNLieGk1wumGhtXPiW+9hNlXAqCGZkbPxEg5lZOgb+88BOxxo5QT5HvzhGhxJwScXgjP90R O0VsS+3x2EB5fzSwILmBOXE0Xf7Zjysl1lqM5bzyE6FHbrnvtpxtIqXYyI7K2YEOA7kYJOdIYGbg 821g+K6NK8AWK5SL5ktY67Uliun0hHhKLI+I4annaInyrTDCKfG9EsMFI2OIJctryidzOrxIl461 JZYWO/WHXoed9miJSOLJmhLD415XP7HmiIBhryN7AqjG08op8Yuf2HMEqByeMJ59RBC/03KlsNvb biEDiNPF3vZHBEMMo5EFY0vgdmZHYHjoNebYoKzOGJcvA2qRc8cdnucckUkHxv0QLbBqoM6m07/z ExvFmmud2OleYs8Ei9e+DRFTi9CpzGsjZorUS5v3HFGcY+JedkvRbeJBAAHulqLbRKqRk1Vlz/zE ijoydZ6gQLFH4krz5gyKPbaa20SJQgkiWQt/55YoEqdjSdgusfDLJAoV+ZaKsZ7qlihEOaaNiOBS KEQ6rUs5VSj+sLUQ95j7I/EYro3/VFmCwsE/fidRPviJEv8rVpgX/1kSwpxqnhj/pcuxtgbz4j+L QaZeaJ4AYJTXKdNuBaCuOpeG4U2RnJL1HclgssQEmw9CSU4cyBM0OYcXRiVC25+3bdBYHmm2sao4 cVVcNtkqTHPimsS9io7awQavg6QEVj288eFKEuuoeffE2KK1iLnulw0buCJ2gp1mPbsC4qty4klD WzDFUohnDQVKboYZpvVWApI8QdytCjdwGozATjNw4prGjWa01k8+HCTBdfPsPjhp4jzFF8OkkdVC Mduq0lsnDWRcmfPu0LOBI5C3GSd5YxBvXJF5lhVDLWLFNqPzDkVLsTFM621PknnZoXXGHkwSLABm aQAUHV6bFSnOsK1VcMyZJxkeir/LbMu31YmrSWSUNbwbL461HmMShC9OXKuStpVZIoXE3UGeJioo p8gVZskAErmdcodJhkIatrnzhNqYRp02c63kCFxdK4l+nAaMlPOE8ssgQo9UbZKf/ETiKM6+TSi/ DGKFmMkWVW/9xMYi+ChPKL8MYsdV0/bbYpG51xK33dJlm1g4yvszKr+DKJ6/EC7ujNwStRy4UnT6 5eX+MtZAsjxItAa5NWnCdtlgECuvFbztcwzn6hADqMlgxieUYLi0snEkQlLrsXHl1cuwt1YyiFor yd/FlrCrCGqJ4tYfF1+Cv54ziOrNGE3R6bmfiDLULffgLaFbIvUI1Ewb3/qJYo4ZqU0otQ1iz5F0 eno9riFiksypJrNk+aOfWLK8Rp431rq4UbDAvOeIqPG6mGVV8BMlec8AeWIbJbpihwlryQMoqVTt 1XSariBKp8U/zuv0YWmjWeI//cSSRPa0Pq/XJFpXxfe8KUNqjis1ef+UIUqix7HPqMnfIQNxlkY6 yhi2Jj8aWVsksmrv+f6a/CDqcrKMz4TF3yNRVH2U4Doxl2FJ8lNJeYLaA7HtspHMFD9OHLgtkr71 86BFQLumegWRSOStAZIfyEXXEMqEvOOe2FfrVrd+YpN4UNrMge5abmp5xtL0EVmSCL1mN7Hc7Nf0 g3ioTdiK3anbCecd2SBKctSLdRJjSofLXeMgiretOa3sENkt6u+JNfZU26moP5tuPYGsGLkfMrhw ZbAexJ5iFnc7QYMfiZBKZMoztOM9sUsg7KaN7/1EydZb5Toh/A8iltgomWD9wU9U82lphjAbRFGj gAlmCIo7ZNCt6alknrDIPxqpexsLteVKWR/uu63pUSNuEwp7g1h03+DE6I+ly2NsPGEz2SDiIcuc 2GcxR6w2vPqDIdZDkjmhljmAWu8Hu5vjtZ/YZVwS4DxNQaLzIFWeGK/F14qjsNuq3rnjtRb/Jefi cwZ+ebwm0Y915TTHjTteE2phZm13mjdek9hjTSZcv3X7W2q6G/igccOVaesgdoo99zqhoHAksiTr pUCfUI0aRDFHUaR1Xtxi/QQbT4xbuvGry+yeF7dY9GMhzBM2pw0i15jZhpn3bufDkn50SlPCDEu+ ihMX9Y7A1TwY/biiW1TSlCWPgRRXRrW2GenRkahnWNoFO/LPLnkMIDWJ1e2JxaiLlzwGkSly5ZVF vf3e9kisReUtnLpbT+JxJOq+bxH1p+72CqIk14lslfCZm1gySiqTeEbicSRCih2wzUi3BlHL4GXG CahBFANHsOmWf2QOuXW2I3NFr8XCc06mjdVP7LrBg2cseRyJekorE5tEOPmJBWJimGiPukyYoE60 R10mLEDmbNpPfqJuq+RkiK/8xMZ6dscQX/uJveo5LZg3Z1Drer3WeWONRT1umTfUKK9119E814OY YqpgzLFdQeyqb2f2mjSBs2vMLn17QAZkPXxh95jvrj2Gh1Y2lMFGnlFSuCNSSpHQJq6v/cQscm8l cb2ijbpQ2C87VnUhETC2lVMsN36iJDO5c50n64lQl0cndppz7D3NWNQbxFojrOQy7/3ErleB2KWU d24ipxaZ+0Tj4UziKirOWIc7EtXlVppwQ8QAot4QgfMmNeseM6Ippy91szd/l2XiPe+H/WcvBy7L ONdxQQs+OQHPnL0cRBA1mobl4GrmceHZy0GkLM52bIPD713jvsOXgyhzGmo/6XXwBMJBlDndMj70 OriV3iB2vUTmsI05PO71jZtYJGhhH4ICr1Gjg5gPV1jUU6In/N8hQ5HXkIBPB9sT/kcrscksHNca 4TWX0wwiiR4Fa+Ov/ERxGG2sKOA1rmcAG8RSR0jAyw/CbBO7qMdxyAkv37Zud+mjFsB55pnTQVw9 dpr9PBETkqvDhAOKg8hii2jvDCA/sYq/7fZczBVtbJJjFnsG9YObqMdGAaxwLH6i2E6tZf8e8zCQ i0FKSihjvX/zyDYRsi488u7NI9tE/fZEWT08/RgtTwRKhb6q8sIF47IClNw/czfXGry8dKgtUjeu IfXd1xo8QWwyZUo+Lbf+6CbqzhGZMvuLKNtEyQcb4f61qG2i2Hfpdmf0FW0UqZeKLeDe+olYdTeB 3TjqNp8AovVW1jze7QaG0Ua99mVl39rzncTw0GvdGo0zjiLeA6teN1EmHAw9ElEPTBfHEcJtf4ti 4RIY4NJ067y/xaILCudv2bjc36JYeEv2kFA6t/i/TSQR4ZBXbsQMzjmDLLOQUz9djvLPQpRkJrG5 R8bvHrHLwPQKu9e3Nol6orVn3F/KfILYRDCXHLw3DFiifAKZcZ4LJ5RZuLKKcsVzpKLlsuA+GWz8 rTQvJsDs1qPG4ZIo3M72gGJyO1w6nMMncLtw4x+pVy3Ww4RLG45E1oLwint85ScWjkiFJ1xmMIjA etFtmxgVGCkyw1OX0yXNvRNDevgpPLz37fNGL/RK0MP9K28kjKVDoVhyxapFETz1nb8/90i2YBzF /k8d568+GlQ9eJbMlaM/OHGio8ujeXmk/cFLq5KJPEq2w4UbXjZwem+ivV31j15ai+LPzRnS5z6c ih9JbEzr/uTFVb3PyuD+/ID7+H+WprjkCmVuZHN0cmVhbQplbmRvYmoKODEgMCBvYmoKMjg1NQpl bmRvYmoKODAgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwg L0NzMSA5IDAgUiA+PiAvRXh0R1N0YXRlCjw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8IC9GNC4x IDgzIDAgUiAvRjEuMSAxMSAwIFIgL0YyLjAgMjIgMCBSID4+Cj4+CmVuZG9iago4NSAwIG9iago8 PCAvTGVuZ3RoIDg3IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNorVAhUKATj QgUDBV1DBUMgZaBgZmikkJyroO+Wa2io4JIPVBAIAM0RCYgKZW5kc3RyZWFtCmVuZG9iago4NyAw IG9iago0NAplbmRvYmoKODQgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA1NyAwIFIgL1Jl c291cmNlcyA4NiAwIFIgL0NvbnRlbnRzIDg1IDAgUiAvTWVkaWFCb3gKWzAgMCA3OTIgNjEyXSA+ PgplbmRvYmoKODYgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIF0gL1hPYmplY3QgPDwgL0ZtMTEg ODggMCBSID4+ID4+CmVuZG9iago4OCAwIG9iago8PCAvTGVuZ3RoIDkwIDAgUiAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvRm9ybSAvRm9ybVR5cGUgMSAvQkJveCBbMCAwIDYxMiA3OTJdCi9SZXNv dXJjZXMgODkgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42q2cW48VxxHH3/tT jAEb25imuy59SZwoDvElj3aQIkW8oThSJEcifH8pVWdnCJya2bNTlLC8nIX9MTNdXfWvS8/b5efl 7YJN/2MqS4ey/Pefy9+X/ywvXr6ry5t3S738evdmefGjfONf7+zf/vXr5ef09v0PlMuvD37grfy8 fuvu/29+W/78Sr4S5QoIuDyX3xXSP689Y0vQZmZYXv22vPihZv3HX/26fPntV8urfy/fv7pc8Dne mLn3Wa+JcJqY7ogL1pLHHOOa+PQkMW3XuCCUPLmba+SHEtPVXS+INZfKeE187Cey/Ambm/7GD9SF RjI3/cRPnDVzRb4mfu4mUqmZejHm2P1EbLlh79fEZ34izzwL0DWx+IkD5TMHrgwXkmskszKPbhER ci2FW3ouv7sjTs40lj7zuiry/ZX2GojdwFpaNuv8Dz8OSdxOpdPP8JjIJXfidtq67yH2PAnxtGs8 JnbMWBBOO7Jj4ii5lU6n/c4xUbyEBASIWxkoPXdxZXHPEQDynHZlip+IEgZHMf77Oz9RAgJW4Dh7 hKb+u9TTQeuY2Eem2s2eeeknyhcE6xv9KyPPMNed5+i3R4SRy2gjbs+gWA/waHH+G1l2oQ3Vr7/0 ExvIWrdAbyZhWjxFgzjrwUm5DWxx1kNV9sysNW4XUh3iKYZRKF/4iSRrXdHY4+uvbiDThlwMkkdu UB+82On6Ii1RQtccFW5aZDq6b4scstrt2EOmW0/SEiV2jWY95PgqPWxtDJFF4XL/SJmlU7vGEkXy FSaNhulUenRMBIk04n2SV1VYoqRHfcBIXn9miaJ4gSck7z60RPGQIvfMNX7hJ3bKst4znU1cj4lD 7LG0mtxu/BqZ5BnuCr6bzuIamd5fZSszi+cdcT6y1SZe1+7sH/xE7Bkk8bom/ugnMku+YBUf+Ym9 ZkQba/wqQGJhnmAX27EygJjHQRoHfhyIe4yQjxsPR0bqHCAANqIsMzAHPkHVUQwt8BI1WScbtZ75 iVNWuc2ITGElipbIkigY1fNXPxFmno1qQC68EdVHtBFRU9iIjLIy0OKsB1rJRLZi9oOfKDGmzFYD PONGnDPzGBzgGVciVhbrsSXhR34iaO5hC+E3V0ZzvwqD0nMhzKbf6eJrlyqXaCtmCMUNFGu0mXV3 48RwyqB+2ncfAkXQi3I877wPgWPkyjZ5+84LhFLkCWIPW2MtRAHVfl47HRIl/o1ezperD4Fa/4Ya ZjaiuXNpti/xxA3sWnob50XOIVA1TqUZt8qzZLnKEbZTsKDk59BP14sOgRJMiWCGLYp6Q+y2neV+ hihetiNC3DOkLhEATwf7Q55EZq62Su1fk6ahfnLcmnTJ81sNNEOxa0lPzwvPIyAVicponZfbYYtr 3U2p3GZIQBmqrbX5b1nyCwmicf6a1A533OFjN7BdMqB6WmgfAoc47N5q2NajMdV7YdhOYfGv2K20 ee4GVpFwteBpkX0IRBFftoX8o5tHkp8hna89HAIvTe4GcWsi6nDgiHM2klBkap3DfANPymMns79d WzsitkIZRSyFOYdWRXyxbTS5H2KTsNwGx8WUpmEZuAW0PXVIByIHD1bgbsXqaz8OQBJHq72e+Yk4 ZVHqDGgnbkQuebBNfG6a9k5DaENq79j2E+9xsemgDr0Be83Atmi1d9fp/sr2RpRARVDvVcXpYbXy jTgllu6URi65SjpVfV+JoLNt/bqwnVwF/Q0pKSThB92/dNJ8LBG1RXDZ1J/aYXpP1PAyTWfkhZ8o uokk5kd0Ru6QCZpO4PF0l//eE9N2kaOoQAZ3qff/rZaNOJskuz2ioLgSUYJW3Zlk/MxP1IGLnajl 97k6cCEu19z13/xEbLkPe9eP/ESSwNVqD1wZbplEpSzedqIlNq19Wi/+0k/U8TGbbHjGTDbirBnZ Zgf+aEgFtFBZ4yI2iS4TlxsxpLQRxR6RSgtouGzES+vBJpYv/MTW8qgwA9ojG1Eidh+9xu0ZzS3n TpXbLx9pdvkyAvUeV/G4s89AdaYTHGNn5vLR+XGdjYhdtuHtvmd6cMTWCQ5mWxJ8dn5aZyOKJqUG EDCtsxFFlEp0NdM6jikT5KGd7Y+zj+SXPStOPE9vl8Q/uazRErVh0NGMwXQ/sUEWwUfXxD/5iZIU FmgzYEBpI46moxZmnOiJmwgSZbCwuevXr73IBFVsx5r3U4ceXa8RtGXXICRcr0ikDMWWZb7zE0nE Hk6ICAorkTlPbDNg4nIj9pFHs6nmUz9RDLK2VkOCworUXKGdmPRKN41cG0+j3+61pQdvG5TstXQ7 6fXYERVWokSuOazETc6NrQez+seFx0tM+MXtKvRkFpZL3yS5ZLglivWUMcycoD8sqGies9eA6ciN CLILxZ0lb/JhiSTyscweMBO6EVnr9B2vid9/AnHqRDGE1CnuwgL1kpkqL5+82FtcoNEl0yz+IbcP 6hQrUQfxRd4vXlVhHCSrQqvYI3T4SkStXdu2/CM/kUSd1RnpxFnnvUp5cGf+tg/n1uUijYO06iw9 0MR56Ngz39P5Tic3TSty093We565nXjTc5Ljo3ZU+jRN2kT41Lu2aIrRpI0knRkF4zRpY93XxBEO 8iIm7tKZ5B3/tbjL+G9ERFh56/hv8qpRS2S4ZNYRcXAlds6jUORTnEIR64m7ayic22STFP7kJ1YW PzZ6nCnqGc4OzWyX4SfKZ6LS41YGqMtalxZwImQjSi5TC42IVHglNi2PTmM9j/1ESdexNrMLv/ET pwSEMUJc4x0RxZFRgxZnj5obtR2l1/1ElOdIdhc+8xNZ3DfbrlnxE7u+ywAgcGXGzEXcWfIOiC7v ZxR0WqvdTWanT5jMvgKm/clscuP0IBpW8k8Vr8T0/o6bpIOtnO8c2TGPFdjFM5bWAoZ2V+DAjIAU MM2zAS9DFHi6xnMEhCJafmeyxf0MtZpXdoQ3u4GgB7IjeSOPQRC2JoCsp19q3BWKQuZhD/H514SG nqU1qcsvbqCka91OvT1x8zppskZxj1BP+zTigJndFTgl7O0MX7qtBiX5KwhxG09DPe4cHnrpBmrN svRxurV6CEQJotUxAXYI1MoYAYTZoQqH1q3ZgBvYS66VKCyioBo21sBbniQfkcMMW192JaZDYWZD ojhhp/DyzA3Uj8wjbFEu4/IdesSM7UoUj407o43+S+SZoZfAZW56LnzEWTZ12XuN46Kevn+s7gjO v7iBU7upM87Dci3y0fEKwGNgl5TUNq6GGwicA4UIazq08yoct2/QaQtJATDMYTP3zMXO6/rXWHKK Co5i+TFRQgDNEqc3eXRZZPvKI7dY0sI2txaS9sjjg4NDwi/cOJIsihyjcofARvpqEAo4j7oCR9MW Cyxnh0uOgKBReadTBW5gpbyjNr9x84Ay1xFxXGoFiikSl4ijOSuQJZ7M2cOsWg8dt27t2uUa7oht ijocPcyw9dRxHzPulqfoYbIzKt/7gUPLkSElmwsQy8zcO4VtFATNenqId70DIue287abn9xAfeEq OV7+dgjkIhFq1jB3iHqanuyr3x67gRLyeOfwO7uBU4/nz7itTEWynmGj/FM/cIpgt1HeHVL01PHe aXr3MyQsuUPlsBBAYtiSUYwwwybW92HXHnfLrPPHfcbdsp43m1YQoxs4RGHXOeKucGr2HVMuvQD1 rdASBigsBLB2UmrIS3NWoPb/+/FM+HmgnqMAW7QZbqDslL1zzP5blp1SZ+OAs+UrUKcJsWDA4fIV OFjny+7pb0kSg7M0LHu/S+/eHPyDeqoetKXyvIJ85MtgpYSwke3R+M9uHbE8gEkKCDvnaH5/a3Lo CNezeDW4Pq55s9d3gJuX107z9XmAb724ISl5Nyc/P/fhtD4JH7yhbaX9wUu7TFzNa9wffbiuI2H4 wUjYivudF9ckEa/34X7+H3KPJjMKZW5kc3RyZWFtCmVuZG9iago5MCAwIG9iagoyOTQwCmVuZG9i ago4OSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3Mx IDkgMCBSID4+IC9FeHRHU3RhdGUKPDwgL0dzMSAxMiAwIFIgPj4gL0ZvbnQgPDwgL0YxLjEgMTEg MCBSIC9GMi4wIDIyIDAgUiA+PiA+PgplbmRvYmoKOTIgMCBvYmoKPDwgL0xlbmd0aCA5NCAwIFIg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjaK1QIVCgE40IFAwVdQwVDIGWgYGZopJCc q6DvlgtkuOQDFQQCAM0ZCYkKZW5kc3RyZWFtCmVuZG9iago5NCAwIG9iago0MwplbmRvYmoKOTEg MCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA1NyAwIFIgL1Jlc291cmNlcyA5MyAwIFIgL0Nv bnRlbnRzIDkyIDAgUiAvTWVkaWFCb3gKWzAgMCA3OTIgNjEyXSA+PgplbmRvYmoKOTMgMCBvYmoK PDwgL1Byb2NTZXQgWyAvUERGIF0gL1hPYmplY3QgPDwgL0ZtMTIgOTUgMCBSID4+ID4+CmVuZG9i ago5NSAwIG9iago8PCAvTGVuZ3RoIDk3IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvRm9y bSAvRm9ybVR5cGUgMSAvQkJveCBbMCAwIDYxMiA3OTJdCi9SZXNvdXJjZXMgOTYgMCBSIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42q2cbY9VtxHH3/tTuARCCMHY82S7DygNaSJVQRUN ElGUd6hpVSmVKN9fynj3nAXO3MO9Z64FYnfvsr+1j8cz/xmP79v4Mr6NKOMvU44Vcvz/v+Lr+L/4 9Pm7Et+8i+Xmz7s38en3+sK/39n//euX8WV4e/cD+ebPBz/wVn9+vHT775vf4jev9CNRKoCA8Yl+ lml8v9SEEgAlQYuvfotPvytp/PJXv8YvXj+Kr/4b//bqZsDHeEypUjHEx4eJ4ZYYobaUs8iW+Pwg MaxjjJiVQh22xG8vJYbNrCNCSR3AEJ/4icgJmXlL/OWLM8iwtzQROSf9tGyR93eI4dxiR6yQchcz yK82xHCp+URsNVGFuiXWhRiOGmQkgCSUzawfPAo+E4+EkLjLhyYeBvGhd9PoN3SMzGOM4dSsHcRa UwPgsJn1124i55x0qWFLBD9RVyY36lviUz+RcpJeMBzdNLqBU8mZJT7Rz26RnRO1UHtadrW+vuKA +DAw3AJjyZKMn/jHQVxYxxf1QSRAlMP+diWGzYxj0YdYCI77230iS+pot+A9P1F6YhCHd9xb6Fha TpCrCVxwzjvuE/UDS63nHmS41BgjFFDvyLA77XDUviMM+6n2SZ51j/tEzDpIKlv3mL17MALVBFJk 6x7v+4kydg23sBNmHMTWUsuFDrvHXSJmUmVmndlzP1FVSpZmZu1fGcSaehUTFB74icQJOpqg0PxE ZtWPzYzxsZ9YVe2Vaohf+YkNNRT2iY+xqzdrUrfEP1xBbAnBPsYv3UQqlHouWyD6gdCTirMt8Cc/ UI1RsOK8dSGG1Nlqnl8euRUKaSysBBSv9jyrRKHG+h3VV0eF2a5KITUeEZt6/NOtALioB8+Z5mkK Bl3sKi16F9sS9etWiSaqFCZMmhVeLPfOqxQWDddCcm7al6sU1TypNpsM33OLFB7ajJsZo+4ar0rh XvVrMSrFHxVELbKfSOI+9xNRUmvWQ/rdj4yEqVajAD7zE9V8emM8nGjuEzV1rRXaxFmrP8s9m2T4 oZ/YIWGnOk+b1dxT0U0zYdaaDqrZ3CaaE+L/itNoDVRkQvxfiZootEI0QQCsRI3XKiCNMT47R4SW coFG8QmooJXxStVl0Unz+gw/SP8RshMYigrmavzYD24caR6cbVz9+TAwLBOulJClX1oj3AOGuyeo eRE0W2v98VJg2C6J7hcQ6PGo+N4DguZZvSO4p2yApaUOzIeFxC5QlQk0NDriMzeQcsoIx8XTLpBH ZtknPkMZSVsxOyW7gbWrlM8yb1E0qPTWjpeg9ol9eK9+vJS3B8Siy9x7nzZnLJKIbY3soRsIqpAz zXuGOGKDsHGIL44DUX1/W0JAvCIEWOJ1McDyrg0ClnhtFLDEnTDwwE/slITsrD93E0EVjvTChxPp faJ+p2DBw6X0fSKB2k7G4ymllRArknXL6NwvXZqwL0ruiC1R7ecHGc7rnBWpOWUj6yken8sp94lt nOLlerjw/Qmixn36KEsNh2KWIWLWbL9WU/h+7CeWUcWrxyuN+0TQXdO4B29MsEQsQ50Ed1DYEgOq 3sGOJV4967COkTQ1t87n8BjD+1mzqM+FEg9XBnedxahTl1zKPDeOI5NG5HluHHtJhH0h0uWJ6i6R MozOiS3wiueoWW+qnA3yqZ+ILTXc8vyhi9TjcrEe9wpiVaJgnRcMSVe6NWs7f3UTWTM36vbs+8Xx ii1KThKvPezf8k6e9b9204qmMGBVGbiBqJlvsxXvy9slDHEcmEg77nF2gVJU5dmjiHtuoErbUlqd OOemTxEmnBosuA6jS0vchy9bIGRdk3bF+ZABjmPkmWsyqnd8Yk3cVgOaEVGHPm1RQIOzdFs9eOgG CqauYnFCk80CbPnkoYt/yqpmTxUPvvYCRz9DaxUndCotQLXD2gWnLQqC+n/IPG1RhkrMeaJ/HSKx ZRvnv3EDZdScoE0zm9ESymSf4XduYMeExa7y914gFdUhuZkpkxuosgTtRnnm5hGmCoQTgKQChGfq mgV4Utj87MepEKnVliDu+4ms7pBYJtj1HVHFJyFGb/OUJaoUqZjbBIe4ElViC/YZUWUhQm5J7RsP H9/sE0cNueEMn7gSdf8VsfvFv9ag9ohS+uF0ap+o1gOtTtBgK7COtnabDFyx1G10T83pVlmQmPNo s6yHS4ufIFYdJDpKi/vI0nSQJLuFlwP9KisSOWWwtZyHx9tVViJBIvooCoZDmtsSeaQtNzctwpUN BytRRiE544Q2iztiVzFBPKHNYiU2SYgzuixWoMoToS4TGi0WIuUyjiHKhEaLlTgsXGb0WaxA/bp2 Dl6B8gGQhxu7EShhxi2LBRiuEygWd61Aed9jucx4CBQBK1B+PN5jeUdsmufbwyZ0RISFWDFBAZgh yxZiG11OwjNC9ULsuqEbGVfLbqJ6MH2OVqH4Zw1luDF7owb8xFG5y8DR24FuiSNVrYQz9MRC1HDQ xN4EveI51lE1lxkKfAF21k2INM8cMeukoZQpImpBFrVHsPW73QONcNbdIubE0M/edQoXO/BxbaO1 XmfcTFqRrLGmlgkXk1agaF7NRkL9xx21xvka3R5Khyu7aVfiaJM4cTx7z00kleANaMqVyCUYjgIK 5ytyaxMMh0BpgBCvnPb7YEhYEvQ+0eWq+lYJ0I8fX+0TpSQsBSbUL++IKgEK0zwnPq6CULaV9G/d xHGPmBEmSgDWnLCeuF76g58ISnFdvt/dh6wG2fnEWZvfizO1VInO1r8v9+KsLreI7Wm853biOuNU NT+a58W5curykf0Eb5a5EJvKXBGTCfudLquuUC014+LGQhTVFZ1ynXCJcSWqKO3S24zceiHiaJOw t+XYTxzXVdShBa/PtcTRKNERJ66MqD2WPOPC6kqsw3oYJq51H+8vQTMurK4JuyZJDWTGY+zjNHna bZUVN++2ykqcd1tlJe7cVvnJT1RFwZzNrF/4iW30U+dlZfCOmPzE3kcFjrZEv+mMEwUNCIbotx6V okn3zBbo0sw3xAC61nxXXMcrUoWwjlHT63r3tkh4zSXdlVhz6h0M0XPqsRBvrGdVj3hVCWAlqvVI NmPMbuJIrwHFjPGBnzjeACN3Qyx+Io1Oh7VbBE+9vdQQ1T0L5lOfhXdvdn5lgXFQMYxB85CsApDG 1QSsmoaaLOJmP4VPjH8H1jQVI9s786dzEnAPV0d/1CZrCueP73dwGhp7/6ArMdyO7s9eXBt3MdoW 98CHG2cBIHVL+4uXVhO21re4Zz5c1UyO8IMce8H90YsbZwvF4P7+Hvfyd7FjALoKZW5kc3RyZWFt CmVuZG9iago5NyAwIG9iagoyNDcyCmVuZG9iago5NiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYg L1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDkgMCBSID4+IC9FeHRHU3RhdGUKPDwgL0dzMSAx MiAwIFIgPj4gL0ZvbnQgPDwgL0YzLjEgNjAgMCBSIC9GMi4wIDIyIDAgUiAvRjEuMSAxMSAwIFIg L0Y0LjEKODMgMCBSID4+ID4+CmVuZG9iago5OSAwIG9iago8PCAvTGVuZ3RoIDEwMSAwIFIgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjaK1QIVCgE40IFAwVdQwVDIGWgYGZopJCcq6Dv lmtorOCSD1QQCADNIQmKCmVuZHN0cmVhbQplbmRvYmoKMTAxIDAgb2JqCjQ0CmVuZG9iago5OCAw IG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDEwNCAwIFIgL1Jlc291cmNlcyAxMDAgMCBSIC9D b250ZW50cyA5OSAwIFIKL01lZGlhQm94IFswIDAgNzkyIDYxMl0gPj4KZW5kb2JqCjEwMCAwIG9i ago8PCAvUHJvY1NldCBbIC9QREYgXSAvWE9iamVjdCA8PCAvRm0xMyAxMDIgMCBSID4+ID4+CmVu ZG9iagoxMDIgMCBvYmoKPDwgL0xlbmd0aCAxMDUgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9Gb3JtIC9Gb3JtVHlwZSAxIC9CQm94ClswIDAgNjEyIDc5Ml0gL1Jlc291cmNlcyAxMDMgMCBS IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42q2cWY8ctxHH3/kp2tZ9UWSdZA7Hjnwg LwEUbOAXvQlxgAAKoOj7AynOTu+up6Y1QzYhw7va8f7cJItV/yoW+/Pyfvm8oLR/mNKikJb//Wv5 dfnv8vbdl7x8/LLkw58vH5e3v9gP/v3F/9e/vVzeh893v5AOfx78wmf7/faj239//LT89ca+EsUM CLi8se8Stc+zRpSAOcUKy82n5e3PObb/+c1vy/O/vFhu/rP8dHN44D4eGkXrKfBRNzDcAhdkighZ T4naSQzrIy5YaqTiB301MZwMeiGgyChySoRxInEUFjolvh4nSo4JgU+JP1wiIsScEkt4Y9/dEivb BC5a43EO7edH2gcgHgbmJNGtystxHEBUBWeLr8aJWKOUXLtXZZvIKRZGZ90fnl9AhhW5OKQtNKNb 5zfbwPC7Z/RAzRE45WtGHc6N2hMLRAI/j48fEMPX5tETa4lYxT3jt40YrlgZRwRzjEVP90u4vDJf QUKOhFjukKHTfDzR/i7tg5tP4eGwn+0g1lhTreFkIt+OExkjKWnoNfFNZAAxL8f8Vfu5jhjWhywp ZkzO+6ROYrgfdpVYs7qY8GTYV2CyUWfGU+I348Rsn7CUeT4XoURzuXJ2H44RKVv8nzmNVCKDd7kw ThSMpXiXOx4WUDkmZho2cE+sFv7PLMyOeTSXC6Awbx4pY+Sied4zEqSohXR4W3siamQFmLfWZPZY vNLbMY3mHcH8+Lw9SCpRU8KJKoWKqdKSnT1uRa5wMc5QJRNnPiicRq5wdeTiVJrw0S17DN2xkLN9 oYL+GcNgdGWoMWV8uGfCYWleDAdsttyjpMOww5BFeqJJUouwcioB3o0TtcRkUvyU+OM4sWLMVZ1M eTxMlFQtFc5OSj0ZJ2axVK7yRCkloBZpvI2/GpZSQhgrV112DvteSgmb+aj2u59tjyZmkZWLcz8X t822RxNtflw6QvaFvEvMoRXymvRJf94F2BTK+QT7m37/uOKyBRryPvxlv39ciWhJVybyQ+72j3dE cxQZTt2j9m+YFWhij1VdyvVqnGi5B5nlhJ25xwNiVdswlCf4siMRTJoBFTolXiz2wGH6Cy1vzNGY /LSfmLYlsx2OEE6rRwhpEBiyCTOfbf06jKMaLf5Tt190wHAccFNlXEq/EzshhrspVIySa+nWeSsw nK5JOV/GfDIMrLadK/HwJJ4CIXEUIqfxyjAwt0pCrdOGDJZxcNay9NZPNoG2EynlOm8OSW3IgN3l 702g1Ejq4v33wzwzQ4tUy6ircTyzQmKfsj0eBbZCDBby4uHDMNGEHafrs6HLQADTDrrD2zii2SFC qd3nBx6I5vvLMQQsO0KAJ+6LAZ63Nwh44mgUCD5QrcjOMBC2Q99KvDIOhMvBdCVeCATh+vB8JG5H gtAb8FeiDwWhKxR4osUCwcMmDEOe0RPRtoxICb3Vp20iUaxVnVR8NU7kanmQOqn4t3GiUqQqPEF8 rkST3IWgP9nfJlqypuoeUYeBmE3D27YOo+rOE+2TjD7PGDdwxLYw5Eb9j3GiiRMkrt2Vom1iy/T9 wozbN6rYF8ZT4tNxYjViqTJv0JSzqdDiiH/fQSy21ADzjKc1TRQTPaG38L1NtFwfJpqOLXJMWLvz 8m2gaDzjvXfMoXnGfGa7jEcYKsUiNc8LMFRL1DPbZXwDckYzRZZ5AYabZwSSeabIZBvQ9MnEZ2SJ uSLNC4IsEIX9Wv8wTtQmT6rOM3AuOQqozIurklp5GmiePYq5xgIwUZSJfcJ+y4yok2Y1MrPadkvc KLe9HOcxtMOSvOwec1jHLPYl4e4KXrifxXK+WWug0rESD5V+KBNqHUcipGzGWCfUOlagmY5KxgkV spUIttTZ918+HSeSEcU3YDzbQbQdmPwh1o6FYWo6tE4kSuuMgTxxZZo+ccb44zivbZjij7t3WGM7 EwNfHByqn9wiD21VJV99XhkuetvWU81YL1bzwtX+u9UHS+HtslHoDgkIEk3y1O6jtm3ioRmRymkB 5elw2EILCkI1nxZQXo8TTfOg1inR/0hUNe3oNc+7cWLNUbnohN4Gsmhg37RO7bCjU/sUGM4eJNM4 DmzE9Ux/0Yv+noHjkNu5L6svgD/rbxlYia0tpsCErqoVyJZSa6EJ7W4rUTiK+i5oGCeWdmuAZ3S8 r8QKEdLAAdkmsZWCVWFKL8eKNIkixbe8D3Sn3RFrrIUu97CEq3c1UIoivNlxErr9BJgDEqxlQnva StRkq/27o7Iw2rG0Ig+i4mCSoeuK0TaxmuxRn1q/HiZiKq1GCGF0I3oikE0k5+70f5uILbWuOKE9 7Y5YYjVJMeHuwEo0AcA5+7sDL4ZjDYoFw1rHfeR9w9v6kIVaHWXZ2dx4H7vaFyLhZVQAOBdJ7XxZ ZUI7+Qq0vzMnnBe7CGtU8jcHxwM2UWtthDwvYhNX06OFJ45a2mGCj9iPxokFTT2iDJujI3KydIZ8 aWYHsV1JhKLz7JERIyao81QFk7RjzJnPKK0nI9d59tjqrZhnalJLO0yJk8xTkK3empl4noKU3G4E C0zoRCEyNyYzO1FW4tny6MdxnliGZMl1t5/YJqpELJUn1KNWYoGoyDqjNrMiLVlIVbRbh3+FaHmh eEfxfX9t5khsrbG55s3CXkdp5o5YI2M5UwvvLs2sRGx3MBNP6G25I9ZY4JC8hp3HUSvRHG7WKYdw K9HCtcl6mnDAtRIVogFlwsnMSiwSQb1mfj1OrBJTUpjQOHIkYpJY/YnZuPFg6yYv/mbMq3Fi+wR9 e0IZJ6JJZlKYOGrCmMCncD+PEw/vdChuHn8ZJ2p7WYSvZtI4sV089VcRdkyjZevoL6g/GwaSKRQl vy7jG4ZMoYhMNB0Cm8TsBz3uG6m1brFf6HH/TZRiSTzRkxG3cxQ/j+Petl2NJSk8cR5tw9TkL8ak caJpHkadGLU4ccykMs8eufWXJeYJ7S0rESz6I01cGW4va6mE81aGD68iwon7miW1F8pMtHBWcz0Z ecJx1EosNQIBzwvWcniRhe/UezROzK3JLJcwenTtidguiPbXHbeAQUzeir9o1N+RGdYnZIyioMtO awz3YzZrTDhwuL6dE4rUQwG3/2xme2Xa9SBKMi8nlHq4gHnxBsX1OaGm3N4xIt1vDjhD1NtOobMF hWcDGeGRR4dLVu5i7IjoORKZTd7i6cuNnowDW39LSbX7PQTbRD10j+gMiXIktqsynGf4nSPQ1K2y P5V5NEyEbDlrKTgjsh6JwC33hxnR/0ikdkXPJ1u8g9hyVpyioo7EVvxnH1nHDRzEMvWcacJNgpVY pL03SGfEaj12RzVVL/N2zG1zlOCMbOtIbK9VY/zabfdDP1YSTGe/+/Jx49UMtnOSGbssbzLYX5v+ 05YjFxNE176F6y78bMBKNpiPZn+89JKHLZyatNKLvTkulG3gLBep1TdW/unSi/q2cK2r0vd+XAyL 53HtPAB8cfjPl975t0VrbyTyF1y/uxRjz+PUNg65JsDw/A+X7HwLJyYsHtwQPobXf97j3v8fvft2 IwplbmRzdHJlYW0KZW5kb2JqCjEwNSAwIG9iagoyNjQ4CmVuZG9iagoxMDMgMCBvYmoKPDwgL1By b2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA5IDAgUiA+PiAvRXh0R1N0 YXRlCjw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8IC9GMS4xIDExIDAgUiAvRjIuMCAyMiAwIFIg Pj4gPj4KZW5kb2JqCjcgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9QYXJlbnQgMTA2IDAgUiAvQ291 bnQgNiAvS2lkcyBbIDEgMCBSIDE1IDAgUiAyMyAwIFIKMzAgMCBSIDM3IDAgUiA0NCAwIFIgXSA+ PgplbmRvYmoKNTcgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9QYXJlbnQgMTA2IDAgUiAvQ291bnQg NiAvS2lkcyBbIDUxIDAgUiA2MSAwIFIgNjggMCBSCjc1IDAgUiA4NCAwIFIgOTEgMCBSIF0gPj4K ZW5kb2JqCjEwNCAwIG9iago8PCAvVHlwZSAvUGFnZXMgL1BhcmVudCAxMDYgMCBSIC9Db3VudCAx IC9LaWRzIFsgOTggMCBSIF0gPj4KZW5kb2JqCjEwNiAwIG9iago8PCAvVHlwZSAvUGFnZXMgL01l ZGlhQm94IFswIDAgNjEyIDc5Ml0gL0NvdW50IDEzIC9LaWRzIFsgNyAwIFIgNTcgMCBSCjEwNCAw IFIgXSA+PgplbmRvYmoKMTA3IDAgb2JqCjw8IC9UeXBlIC9DYXRhbG9nIC9QYWdlcyAxMDYgMCBS ID4+CmVuZG9iagoxMDggMCBvYmoKPDwgL0xlbmd0aCAxMDkgMCBSIC9MZW5ndGgxIDE0NjY4IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42u2beWBTVfb4730v+542adqmaZOmSZe0STe6 QGlfV7pQtjbaAIWWAoKK1EJZqiCOozBV1HEddRR0HB2tSpqiBnFBRdRR1FHcxUHFUdQq7oq2/Z77 TlLKMr+Z3/yW7x+/X5qTzzvnnrudc+99L6UQSghRk02EJ7ldKzq7yRJyF1geBSnpWrPa7v7aNx+u vyNE+t3S7rNW3P5Z1X2EyD4lRBl71rnrl26Nb+UI0f9KSGz8siWdi79d+4qMEKcJ6hQtA4N2j+wr 0KeDnrZsxep1lZ9JC0DvBr3+3JVdnb5XPVtAD4PuXtG5rlsTpP2gHwLdfl7niiXnB744CFVBJa7u niXdxqd+gvGlZRBiTgUbJWz8hGiIjGQDHcRIJERPVGBXEx2REi3hiJIooFwOczQSA/gS+W2EjF5L jr8uhp8/kgHyIHmEPEn+Sl4j31IV6SCXkifIR+Qz8g35BbqSUzNNopnkf9tr9BLpCqLl98DoLISM HRs7MnrP2BGItW6C5VrQLBL3cctYzNjwybbRa0fDoy/J1MQg1jVwL4D1KB0eO8ZVMH2siOncZnYt 1jgqv210x+i2E4bTTXpIL1lH1pM+cgHZQDaSi8gl5DKymWwhv4NYXATXl5MryFZyJbmKXE1+T64h 15LryPXkBnIj+QO5idxMboE43kpuI9siZUy/DX5uEEtZyR2wwu4h9wH/RO4kfyZ3k7+Afi9E/z7y ANjQgvr9YNlObgfrXWBlXsy2A36CZJCEyBDZCTlDPaqFyR7yEHkYuAuyuRvW8mPkccjjHsjsU6KN WaL6P/fEz6fJXvIM2UeeJc+R52FlvEBeJPvJS+Tl/6jkmXEL014hfyOvwlo7QF4nb5A3ydvkXfI+ +Ts5RD6EVffFKeVvgcc74HMw4vUBeH1MjoDnMHiiH/q8J5Z+KrZwAOoeIoepgnxPOfILGYMrlr0b xAzdJOaRZY9l504xziwfO0BnGbp7PDf3Q4zvh3wyjV3fHMnGA+A7CBGMxu/0UXspkh2M96Pgw2LB SvZHYvFsJBOsncfH674gloXEek+Nt3o8ojjD1ydE570JMfyY/EOMDEYPS49Hj3kcBh8WZdbGibH9 EOpi9FldZp9Yh5W9A/oROB2+gEgzfi5m4nPyyfj1J5HyYfIl+Yp8L34eJV/DefItnKnfkx/AchS0 U60nW36En5/Iz+QYZPBXMjJBGzmpZISMQo4JpZSjPBk9fnXcKoqESqkMzjQFVVIV1VAt1VE9NYDl xBL1eInxlBLNacqUoiWGxlITnJcWGk8TqRXOTRtNpinUQVMnlCWMl9ihxEnTqCtSFifWTBivmwIe lgm+mTSXroVPD/VSH1zn0UI6iRbTUrDkgJ4P+mQoyxVZJdQtXNA+f97cQJu/tWXO7FkzZzRPb2ps qJ9WV1tTXVUpVJRPLZsyubSkuGiSz5uTneF2pTlTU+JNRoNeq1YpFXKZVMJzlGTXOus67EF3R1Di dtbX5zDd2QmGzgmGjqAdTHUn+gTtHaKb/URPATyXnuQpoKcw7kkN9jJSlpNtr3Xag/trnPYwnTu7 Da631jgD9uCweN0sXkvcoqIFxeGAGvba+GU19iDtsNcG69Ys66/tqIH2BtWqamf1ElVONhlUqeFS DVfBDGf3IM0op+IFl1E7eZAjCi3rNsi7ajsXB2fNbqutsTocAdFGqsW2grLqoFxsy76cjZlcbh/M 3tN/RdhAFnV4NIudizvntwX5TqjUz9f2928OGj3BTGdNMLPvcDxMeUkw21lTG/Q4obGmOeMd0KDU ZXDa+78nMHjn8BcnWjojFpnL8D1hl2yK42GC8ug1gbHBCGF+Dgcby+VhgSwCJbhpdhvqdrLIGiKC zxMIch2sZE+0xOxnJZuiJePVO5wOlqrajsh7zbL44KZF9pxsiL74dsEbyu1B3t2xqGsZY+eSfmdN DcattS0o1MCF0BmZa+1grg/8OztgEstZGGa3BX3O7qDJWYUOYLCzHCxvaROrRKoFTdVB0tEVqRX0 1dawcdlr+ztqcICsLefstl2kYOzQYKHdOlRACkmAjSMYVw1Jcdf2ty1eGkzpsC6G9bnU3mZ1BIUA hC/gbFsSYFlyGoKZh6A7h9ijWAvmdpJ31JnNXO5S2Ns4Kx9g2QKDvQ4+nFVlUGCAdIkqy2hVmb2N WknUDXqJeLCrE9oBhXdV17MinlWtrrc6Ag58/Q+GZI2MSeoKKia0ZQDD+Jiwn386NPRmA8q01y6p mTDAExqVRgYYae304+RYLCIdQw0FS2d9tIh3wc4FGwfNiCaWxXh7kMyytzmXOANOWEPCrDY2NxZr Mb9NLc6m2XPbxGxHVknrCRqWl6AWJA4ojipcNazBOo81mlZRnybq42r9ScUN0WJ7v8LZ1NLPGndG GiR22EEwaZm7ofPykphC2Jp1cLo56zqddoO9rr8zPLZpUf+gIPR313Ysm8zacDYs7ne2tJVZxbHO adtg7WNdxZAm2tRalZMNZ0/VoJNumT0o0C0tc9t2wXOrfUtrW4ijXHVHVWAwDcradtkJEUQrx6zM yBQ7U1hLc0BRiP7WXQIhm8RSiWgQ9a4wJaJNEbVR0hXm0GaI2jiwSdAmiDb2giTFL4MQw3Fba1/M 0nNhYFl/R4BtLhIHqYQ3DVJnOQlyzvJBysk0QZVzSVVQ7axi9gpmr0C7jNnlsDDgvgfBYWdSf4cT zilYUG3ESnEp8qxJe3hsrLXNsd86HHDAUpsPMrctqPTA2S91NYLfNCYdYJ4W3NTVycZB/G2srtzV 0BWAZRttEFwagkpoQRlpATzqxDpsOUKlLsgNJFCsvwmU4KZAMOBhnbYtD4jL2RAk9c7JkHZsU+pm HfkC/THOfHFvwlZQuTYzKGFspKUNLVZQobMABkmugZF3OaGoq8MO0ZaQrhZY6niWqqxoWQJHosS9 RBSVNVJI2LR4l1qrCiq90CC82bXay7ak1CUPBHDworY54gB9G4JqGJF7QigjFSA6UNTAxgLvzTBU 5voka2Z2mMxxroOThQ1abEkOxUGtq6ETDn+srwaLsyRaWcHOCHWkjb1olbOZayDuvKs1PHa3c71j wisn28luDmxhEusuWNgk0H+yITjPk5OtONmqFc39/Qrt6StgvBTacYIRvmbCN9BV/LvwjZGHb8el pJnMIK2PEi29Fb5WTqYv7KypUeTIHweVI3b6AnyLpvRWIVbCaa3WCuck2RX8bGNDhfwKrpVUjLx/ cB987I8p9e2nvoPDbwwbRvYZS33DB4bzcqnRYRTFpOPkcpnMmerlJqW7iwoK8su5SYVuZ6qOE22F RcXlfEF+MsebopZyjumUf/fXmXztSBq33jGlJU9KPS5LSqxCwacka10Fdn1Ts7MoI1EqUch4qUKe XlTl9K9tTH1JFZ+eZEuPVwFtScCRp6S6Y99Idb+cKan55VHu09K28jTZeq2akyoVt2Ykm9PykqY2 afVaqc5qSUySK4w6VVZ958hNiS6LSmVxJSa5WFuukSkQkWljR/g1/JukgAg0E7Zxtb8tpLQUhrl5 O0l6Opkc5moFg5G30G8t1BLWFNJfC2lheGyPoNRo6fTCQm9lVpjGC9ZDqZTfkLo1lRNSZ6V2pPL6 1JRUTiNJTZXYwmOHBJ1GT6fb4g202XbM2zg1PPapoARl6mFB0ywh8b6KxOZhT8WwxwORh2fc9vaF 7cNGuPa0nz/cfj71De8t9RmG80vzcq2C/r95NHm5AZeJpd/tnjQpsgxYggsmFXq544ugXMJSbpYz i9kUV5BfVMyvMXmycjKNxVvPmLb2zNyp63euPdOYXplb0TW9wKA2qmWqpLoFK6csv74j+8eOqWcU JUyrmBTwpugMcrlBN21Klavh3PoZq5rSirIqskxJqUm6RLclJc3mTI7N9F82/52YtAJHiVBUSCCv TZDXF6UriBt2xPWRvKqtpbu5BbCpfFyPoIp11KlL060SXRbMf6caIgKxaxCU8Y2F8UwrBG2noGuW TifxFdGIxFhKKyjbDpgK5X/ahhjDSKQmxjA/zmKMbBYz73Zj7JI5tsOK+RdV8ZnJ9owEde2N85du DWQULLpmYVNfmdqW63LlJmmOFXUV5U3zmGMyawoT8wqK7KlqvUoiUenVXY1zZl421LX28cvqp06h H6kMaplMbVCNFNbU581ZMqnk7JZ8fWpxBotbI8TtIdgPHlJIpRi3odhYR3aYqw55CiVhFjkHnx2b zVmzn5awpWfR0mYiMUi46bMkHRJuuyQo4SSSJB9EZEhPmxkFO/j4Drsb438gOoOOM/I6ZbyGNivj wUH5s5DUDOFJbB7xeA7AchuOrLz28xe0e4YXtEO88w8Og0GM+P/dviFP1CRzOiI5EPNi0skmHmrm 9CIxT3L+ocy0kQ+sU9orqxY35OqVGgXPSRTayXNXV60dWjelfM09Z3dvW5r7HT9vYe40XwJHj3mz S9srU2MtsfIYR0JcSpxeF28xlvU9smHtE5fWVfVuX2A/e33a1BYfPM5sHDvGvyrtJvlkBWZlF1Fz C0P5WaYw1zGUnJVgiK5AQ5g2C0ohpzGtLmE6LjxcejGlLJLsJLeG/j3/iavUKG5umdx43BCZv7Go CNfrq5qkvDRXXpImNq3UnbtokkZcmDZNlJWbG+ZtaE5NVelVUil80JHKxkm2uuqRHVGL1Bldm6Ox QkXZssu72Jo8Z+wY3SqdQczEQWpx9k+QOO4JkkTMXAdRkRR6wYNCgqEBR/8GDJ7iLQvunqeWnTir yCRiTexAg1sXbEHad/LIY8tb/VOm+lvLxsfO98G+gpHCLHKnTy5pmD6lVPxNNsvTbshTIVkUHWke jDGVaOAzjji5h4ZycuJUYe5hQSeQuFS1NKMhqc44HviYUsjSARglLEK4+eYfZotefTq3CdNIp6fJ CsV7sNkkk1MaF8fvVtvyMzILHDHy0TdPnh9VKEyOPLerIEWj14/+Qr0atUOlV0olSoOWvjGacWp+ fv2admliRKtanxo7+tZojsmG86d9MH8zqcD5C3qtmarVVK2iWkLVEgLr9UFBZajDqVCfmBHxLtNu HYqaT5ujU/OSeurAcAwyJZxhs8gAjmGwLjbMLRxKTs6HwC8MzSpP3w3ZyCeGCVsg1NSYFt0SaWxL 6ITKxvK6nJKGnOkJE+MePcZhiZUeGGYPR6XiQvtfauxf7LR/tvXMuPUskVTLlJqkXJc716Y2Oie5 cuYXQZzSWJyMqUVp3vnjG1KVmJliz7KoGq+dVdxWm2/MaG5qSg/0NdnH48kZc07amqda+AujV2fN mmXxlLk85emxZWf1N0f3wauQg3xycSQHWbEs6MnisUWS4fg5OqSmzeIxpIkeQ2o4hrIS0hrGYxSD EYJgHxg2jAf6f6bmv3eGmf/VGTYespta/sUZdkJYIBydhJ1h9WNHJBKIRyxJJ+dHTwYT1wuFyfCp IgmR5ZIQpomCUt/oFB8gnGGaFBKkeI+KLrvIyfbv1hDvYSc+iEsjT2rRZwuJpKwvfMHa4OqSqX0P X7AuuKpkdMSc31JR0lpkjctrLS9tLUqkR3oe3dJYtTG8puexzY2VG8MXV62c482cuXIaMCdzxsro +cftFp+nuyN5d+thxwsakqhXpah8Kl7Lq9jtGTKoCtMWQSV4Gt16s73BLOYtuicWsvv+3kjGVf/a f8IkxZvxaVIsbhIZtxvuySqFKSE5xpyVA4k+KcHO8pKSJG2yPV4tlXB8U5o3USVXyI1pZdkjB05N 8cr8SreelytVGnOWOP+GsSPcNzD/BnIkep+u5LwPpuWn5WusYa5GgDuBxEu9h4vhQFR9YiwW2FIu thdzfLGx2BinL6NlsDUEK8tl2eFKqzSzMc7Anu5JHDVI4r4ZTy1EyMOmP+xpN5aW+nwL2z2G4XZ4 s70SwyxsmQj2/8O9HQ+8JLq68PugVxbRZeYJiYEVJ+O+KV12ZUv+vPrcOI1EoVGqPYK/KHVSusk1 tXl281RX/oLNrVkzhexYhYTn5RqF0l3alJuabze4y2fOnlnupsnTV89I11vizTnZNqdZnpCcqEvM SEz22JNSs4W5FcI507M0MWa93pxisaaa5OZ4sy7RaUrJsic5soWAmCfL2BfclZJBMplci3l62GjU Tskkzhx2h7Boc6LHd06Ypgw5623aqEELhpClPi9Mp4UEeSQ8sM32i5uzYCR/b74RH1Z3kZz/pBE8 sSS4esWHEvxyFV3Hkbu602lk36rQyl2pjnH6ipOazqtPPSfWxJbm2WobnmRPscVqin3aO8VkTzDK ZWqZtC/bFwuPL+6Z6+bQ533FtgyL6lm4gUqlcAN9VmXJsBX7RtsbGuRKudycJsYrDs7zIX4fySb+ yLcpgyMlzP32IcHssMsczjDXLmgEYndkNDjUiQ3qyOasoAm+xPiD4vNMouFg4jB7qLQ+fJJTZA3J qY7Hx5njJ5Ul1lIcG/ltwhDlpZLR76TG9OqiSdVuo3T0O3i2USfluTLzbRrJCzLZc7w2yed2+RJV /Dapzhin+/Vto1kjkWrMBj7dZNfJIBQSqdKoGTk/IYG7SmOERxyVns3POXZM+hrMr5bcGFkPSbYY b3a2IQu++Qhqm6FEZ5DwkycbysKcR9AKvKGyoaDBkKvW108Oj70yBMwGCjp2MdnAW1wNlunKyK3I UurxeCpYLOLx0S7BF1MKmynecEBUSktj8Js9a/M0tSswQjI5HwkQn3780u0+TawmXEpfkym+lBoc U/Pyyp0GyQ0c1y/Rp5Xn5U8F7QulFJaJKyM/Sc0PctxdvDbR53J5rWo+xHP3cuxxwuWzqvjtanvy 8VhyyUrlyIfHI2tzqOFpEb5qssBqNCywLMx61ci56ogmUepx3/EF9C7pOmIlpkEDPAteORSjtkwj FfvhvrYvLxd/t4RTK44d/73RXYqYJPNlcmN8aqItzUClfYbUQpcz36GX6tIrJxfb9qh0Yvdqaro1 Ncsil1uyxL8podKUdS8GhIX6su9JgkL884hn7cLYcY6ukilhNJQo4R6NL6gnI6OE7lVd8Kt+tFP5 WeSvU46/YiQ6cHuZEP5bMk3SRJokctII3Eh/JOfA2c+4UfYbspHZJM2knnuLbOTzSAO3D+b/PImT /gBfBAzsrz7YX1XQfs4N94xufp+kTrJF2ih9VVYn2ye/WZGvuEN5hvIKHBOJIfcTKbmPyGGkBuIj HYRoksbGiARnCuU4Thk8Y5A5ddMDZ1Z6qjvPXb6oZ3l21cpzF0PRoJIPcz+Hkm2wc38KJXsAP4aS swE/IL5HfIdl36L2DeJrxFHEV4gv0XMY8QUaP0d8hjiC+BTxCeIfiI8Rh0PJSsBHqH2I+CBkiwEc CtkSAH8P2XyA9xEHEe8h3kWXd1B7G/EW4k3EG4jXEQcQryFeRfwN8QriZcRLOIj9iBcRLyD+it0+ j57PIZ5F7EM8g9iLeBrxFOJJxB7EE9jm44jH0PgoYjfiEcQuRBjxMOIhxIOInYghRAgxGErKBwQR O0JJBYAHEPcj7kMMIO4NJeUB7kH8BevdjbgL8WfEnYg/Ie7A6rcjtiO2IW5D3Ir4IzZ9C+JmrH4T 4g+IGxE3IK7HetchrkVcg/g94mrEVYgrsemtWP0KxOWIfsTvEFuwwmbEZYhLEb9FXIL4TchaCLgY sQlxEWIjYgPiQsQFiD7EesQ6xFrEGkQvYjViFaIHcT6iG7EylDgJcB5iBeJcxDmIsxHLEcsQZyGW IpYgFiO6EIsQnYgOxELEAkQ7Yj5iHmIuIhBKKAa0Ic5EnIHwI1oRLYg5iNmIWYiZiBmIZsR0RBOi EdGAqEdMQ9QhahE1iGpEFaISISAqEOWIqYgyxBTEZERpKL4UUIIoRhQhJiEKEQWIfEQeIhfhQ3gR OYhshAeRhchEZCDSEW6EK2SZAkhDOEMWtpJTQ5bJAAca7YgURDLChkhCWBGJiAREPMKCiEOYsQcT 9hCLxhiEEWFA6BE6hBahQagRKoQS21Qg5GiUIaQICYJHcAiKICLoGGIUMYL4FfEL4hjiZ8RPiB/F bukP4ozo92j8DvEt4hvE14ijiK8QXyKGEV8gPkd8hjiC+BTxCfb3j1CcE/Ax4nAoDlYW/QjxYSiu BPAB4lAorhrw91BcDeB9xEHEe6G4WsC7obg6wDuItxFvYdNvIt7Axl7Hxg4gXkO8io39Deu9gngZ 8RJiP+JFxAtY76/Y9POI53DwzyL2YX/PhOKqAHuxwtPY0VM46iexsT2IJxCPIx5DPIrYjXgEm96F TYex6Yex6YcQDyJ2YkdDiBBiELsNInYgHsCm70fchxhA3Iu4J2SGA5f+JWSuBNyNuCtkbgb8OWSe AbgzZJ4J+FPIPAdwR8gsAG5Hl+3osg1dbkOXW7Hsj+h5C2o3o+dNiD9ghRsRN4TMswDXY/XrENci rsEh/R49r0bPqxBXhsyzAVvR8wrE5Yj+kKkN8LuQKQDYEjLNB2wOmdoBl4VMjYBLQ6Z5gN9i2SXo +Rt0uVjYATyqr035SlefckgzI+UpkCdB9oA8oT4jJQQyCBIE2QHyAMj9IPeBDIDcC3IPyF9A7ga5 C+TPIHeC/AnkDpDbQbaDbAO5TbUs5WaQm0D+AHIjyA0g14NcB3ItyDUgvwe5Wrks5SqQK0G2glwB EqYXhWLZ7tsYimEraTViVcjIVlIP4nxEN2Il4jzECsS5iHMQZyPKEFNCBobJiFJECaIYUYSYhChE FCDyQ3q2LPMQuYgYhBFhQOgROoQ2BDkIUw1CjVAhlAgFQh7SsszKhHnAL0GGQb4A+RzkM5AjkL2/ g7wPchDkPZB3Qd4BeRuy8BbImyCPgzwG8ijIbpBHQG6FyP9RxSK9CSPdFzKyFb4eg7MOsRaxBtGL qEZUYRwqEQKiAlGOmIpTNiNMiFjEBdhtC2Z2DvY+GzELMRMxA9GMmI5oQjQiGhD1iGmIOkQtogaR inDgAO2IFEQywoZIQlgRiYgERDzOwYKIE24BjoD8CvILyDGQnyGJP4H8CPIDyPcg34F8C5n7BuRr kE9A/gHyMchhkI9APgT5ADK4H+RFkBdA/gryPMhzIM+C7AN5BmQvyNMgYZCHIasPgTwIshNkCOQW McMbMMYXIpaHjF7AMsRZGI+liCWIxYguxCJEJ6IDsRCxANGOmI+Yh5iLCCDaEGcizkD4Ea0IH8KL Mc5BZCM8iCxEJiIDkY5wI1yYlDSEEyFFSBA8gkNQ3G5EuAM4BjIK8ilE9A2Q10EOgLwG8irI30Be AXkZ5CWI8C6QS3lXym95b8ol1Jvym/pN/osHNvkvqt/g3ziwwa/eMGVD0wZevcEKuGDDwIZ3N8gu rO/zXzDQ55f0mfo41fr6tf51A2v96rVUs6a+19/ae7j3u17e1Nvau7h3de91vQfAIL+zd2fv3l6e /VN6TG/JlLpNvVf3ciYo50gv1TOzo1etq1td3+NfNdDjl/QU9nBTDvfQV3ooZ++hQs+sHg68hnrS MuqY91hPXGId6bH35Pbw59ev9HcPrPSfV7/C//IKeg5M5WyY0nLvWf5lA2f5l3oX+5cMLPZ3eRf5 O70d/oXedv+CgXb/fO9c/7yBuf6At81/Jvif4W31+wda/S3e2f45A7P9M70z/DPA3uxt8k8faPI3 euv9DQP1/ln1dJq3zl/LF6WQFEqS4d2dvCn5aLJE3WHrtnHdtkO2oza+O+loEneRleoTL0q8KpHX wweHHwkpCVclbEvYkSDVixe8pjtmUwzXbdxk5HKNgvEV4yGjhBi3Gzn9Vfpt+h16fqZ+of4r/Zhe skNPd+ie0L2sEzr4mbqFupU6Xq9jFt4g6Lx5dXptitan5ct82grtTC1/lZYKWm9+naBNS6+r0MzU LNTw2zRU0Lgz675Sjak4QQUFXynHlNyYkhKe2ikl1ADgFRDlndScUsc/Kv6vKSmh9OrB1haPpyks H5vTFFTOmhekW4KuFvYpzJ4blG0JEv/ceW2DlF4ZYL/abA2a2B99ivqlW7cSW1VT0NbSFuK3b7dV BZqCm9i1IIjXY+yagEvAs2BV76pVqz2rPPABsmAVWFb3wlsEhU9g72pWsnoVARfPP3mtQlnVu7AX 6oKyYNUq1mqvh2lMWA//776o5/+//nte8QsXEPJf86BzegplbmRzdHJlYW0KZW5kb2JqCjEwOSAw IG9iago3NTg2CmVuZG9iagoxMTAgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Bc2Nl bnQgNzUwIC9DYXBIZWlnaHQgNjY3IC9EZXNjZW50IC0yNTAgL0ZsYWdzCjUgL0ZvbnRCQm94IFsg LTQ5MyAtMTk0IDEyNDAgOTUzIF0gL0ZvbnROYW1lIC9SRkxZV0ErQ2FsaWJyaSxCb2xkIC9JdGFs aWNBbmdsZQowIC9TdGVtViAwIC9MZWFkaW5nIDIyMSAvTWF4V2lkdGggMTMxMCAvWEhlaWdodCA1 MDAgL0ZvbnRGaWxlMiAxMDggMCBSCj4+CmVuZG9iagoxMTEgMCBvYmoKWyA1MDMgNDczIDUzNyAy MjYgNTM4IDM0NyA1MzcgMzk5IDQ5NCA4MTMgMjQ2IDI0NiA0ODAgNTM3IDI1OCA3NDUgMzU1Cl0K ZW5kb2JqCjExMiAwIG9iago8PCAvTGVuZ3RoIDExMyAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4Kc3RyZWFtCnjaXZDPasQgEMbvPsUct4dFk15FKFsWcugfmvYBjI5B2KhMzCFvX7XpFnoYYeb7 fsPn8MvwPASfgb9TNCNmcD5YwjVuZBAmnH1gXQ/Wm3x07TWLTowXeNzXjMsQXAQpGQD/KPKaaYfT k40TPtTZG1kkH2Y4fV3GNhm3lG64YMggmFJg0ZV1Lzq96gWBN/Q82KL7vJ8L9ef43BNC3/ruJ5KJ FtekDZIOMzIphJLXq2IY7D/pACZ3OPtOycdSToiu+X+VitYv3iOZjaikaXdoMWoAH/B+qhRTpVp9 A37jcEgKZW5kc3RyZWFtCmVuZG9iagoxMTMgMCBvYmoKMjIzCmVuZG9iago2MCAwIG9iago8PCAv VHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9SRkxZV0ErQ2FsaWJyaSxC b2xkIC9Gb250RGVzY3JpcHRvcgoxMTAgMCBSIC9XaWR0aHMgMTExIDAgUiAvRmlyc3RDaGFyIDMz IC9MYXN0Q2hhciA0OSAvVG9Vbmljb2RlIDExMiAwIFIKPj4KZW5kb2JqCjExNCAwIG9iago8PCAv TGVuZ3RoIDExNSAwIFIgL0xlbmd0aDEgNDg1NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJl YW0KeNq9V3twVOUVP+c+djcJKRsEs3ks966XzTuGoFAgaXITdkNCSAwEnV3ksZtkYxITiRC3AkJ3 FBQ2gbFFqIKjpq1WEpHLhuoNjDQyOOr4qI9qq/6h1FfryFitONZIbs93E1Jio+UPxvvNud957fnO 9/vO7n4HEACmQAR4UBs7gp0wF2eQ5kWimxrDXfKuf5R0AWAxAN/W3HlDR/+Tn5wBEB4FsPXd0L6x 2flF2SmAxBXk/21LKNj0Rc+LgwA/qSN5Xgsppt4s3knyDpJntXR03ZpoQzfJj7FV29c1BqEBYiTr JNs6grd22lbH3UPyEMnyTcGOUNWmno0kv0fyFZ3rNnQZn2MywFSB5KzO9aFO4Y40C8l5lN8LpENg +2E7slBkgIchb0xzqR8OQBwCu/gUZIkRSBUKQAIw3iJ6m80j1xofic+CfaTD+JwvIv9BRtxIaTEM wS44AIcpw0eJz4I1cC88j20wiKvgKLyJM+FKOg8BdFgKL6JhvArN8Dvy74KTsBeO0N6yoANmkHU3 uo1NJKvEN8A24zcwC+bDnfAULKCou+GMcdAYIOtyuBb6oJ8+/wIq3BHhMuNx4wOwwTKKuY0srxpL jcMwjbAqhzrSboMT6ObfNlrAAUWU3f3wIPTC0/Ap3o5HjRYjbLxinCYEHJAO9TS24FE8zR8W7jTu Nz4xRgiJLMihVQOwB35L8Q/TGKKj8eKN2IV7cC+ncrdzR4XtYvLIOcIhGxbTqIR1sIMQGIRT8AX8 Gz/jHLyd7+KfMeYa/4IEqKZdsp2EIEzjLhq7aU/H0YKzcRHW4Ra8B/fi61wOdy3n437O3cp9xNfy q/iN/OvCBiEm9oj3WhJGzhrHjWeNNyAZnHA9rIettLuT8Ap8Cd8gT7HS0Y1FWI5raETwADeIvTjI 1eEQvsL14bv4Pn6Gw5zITeFmcLlcF7eH6+dOci/zrfxe/j7+Xf6sUCJyYq/4ocVtfWekYWTnyMtG kXHa+Jq+YTZw0cmUQy2shSDtthOuhl/QLg7ROEyndgqegefN8T6mwxn4mlAAnIapOAdraNTiNdiM rfgAHqNxwszlK44OgovjkrhkLp2r5xq4Di7CvcFF+DQ+h1/Cr+QP03iOf5Mf5ocFUbhMmCEsFqqg R+gQ9tN4RHhUiAl/EheIJWKteJ0YEXeKPXyj+Kr4pmWrZbclZvnM8k9rlnWpdZ21h07nearZpyd8 EwScRdnPgZugET3YAPvoNHoxCFGqribcQTl2Qpaxmt/KL+ZmUzWcgM1UrfthC+zkV0Gv8Ve+D/5C ldJOsSLwe6EcnOKv6XRuh9lURaMD1Oyc7KzMDPcs5QqXLM10pqelpjiSL58x/bJpSfbEKQnxcTar RRR4DiHPq1QEZC0joAkZSmVlPpOVICmCFygCmkyqiok+mhww3eSJnip5Nn/HUx31VMc90S4XQ3F+ nuxVZO0ljyLruHKZj/hdHsUva2dMvsbk7zb5ROJdLvqA7HW0eGQNA7JXqwi3RL0BD4UbVAmO+Pw8 9sOhQgILrMGi4JYWB03Mw6ulKh6vlqJ4TBvv9gabtLplPq8nzeXyk45Uy320Rn5eK8sTuqc0KU3d ugoNAcYFV/k0PujXuACLlZSrJSseLXnTh47/iuc5b88FRo1zVwRD0QqCoLtyVAwwKdhDUnW9TGG5 7X6fhtvHkmA5tnlG0w0pXqYKtMlanFKutETbAgQuLPfFUtVUrxL0+DWo88VS1BRTyM8bdGwtctHu B/PL8svYXORybB2dP75jVP/aUILpd+o9mquXjwOAbCWlivLU5EZzEYWSnc9eofkQbZxPbvT4kbbZ Svks0jiqGd6tie6qoBapP59Gi2c0uUCbJxaXksr2ECj3k38gal9Iy5C/XZGjZ4GOUDnz6URNcExj cdvPAmPZQY/XCtnP82ETGLacQ2lh5xv2jsmKw3uBgmQGDctZm67Nqa7zuTTZTwodcvOqdYir8x1B 3O3X0diug8c5CHHAr11D5jxWaq0eWp+E/DxS5LiIuzJPrqDAFaxW5KgcrWqKyhVyCxWT4DZnMoSi /gJCsN5HOMEKWlH1p42zIb9/IcUpYHEEM07UTxHaxiK0mREowDlymp1XTdvMqPMt82kRT5qmevx0 ClS+Q3U+bYgOzu8nr8LxTGne0uoYy3kO5VyYQ8xVo1HqKQaF8Eejo5Li0oai0bQo+46NyjrCdxXq mEIHMwAhqmOkzjRFFFeaiblLcVFafobp1VTS5ytKh7k/jPC8CxH+KWU7z0R4/iVCeMHFILzwohAu mhzhYsq5iCH8sx8P4ZIJCJf+MMLqhQiXUbaqiXD5JUJ40cUg7LkohL2TI1xBOXsZwot/PIQrJyBc 9cMIL7kQ4WrKdomJ8NJLhHDNxSBce1EIXzM5wnWU8zUM4WU/HsLLL0DY7A16qTsooN6AByuUqC7R UkAXE8FawEO8KBTwPJcaZ7EWIKTY4na4Gjc7cnNrvyyuOVdca/+quMZ+rhhKi88VMyqcfVWSKymT qFfYrX/7N/GpbxbpQs3wALt5Ibro7vcOf4xux/l0T8CSP4iJycmpnI4lA7aUKYlsdrXfZoavOVfr DXk+goKaM4WzgW5OFuWKjLlXz7uKW7NlSyBAxB+7LRDYujUQuI3FNobxjBDmWGfoVKdCOo+pIqQI 4huutd0s4Af2sVi8a4ZLFDYPb+cie+B8t1V6b2ra2qnFZyHJZsrPyqpxfjaGx9ABqrrz3RnNluyR bGrdcOTmYV/8n/+nb+Opn+rlXoKdwgYWge7ODXR7Z1483EiYt9P9mgM7jXoA699tfdRDoRl52lgs C9lgZbmn3leXWxlqD4e6WqkDNXs59hgh6i0me3iiuyBG351c+oUimkuUm1vmgAg+AncTPUTEQyt2 w0ainUT3EQnj3EGiQeyOCTb1GG6EVFyiJgjSiukpkiM+QXpNR8vRB6S3HO8fxxRIhNOYEkuEuLJ4 fAgfhCaQ8GFw4ybqkLJw/0B2uxQg00HoJIoQ8eYb8WBs5hzpBOaBW0D6TAbMFPAJ6ePCfOnDQp3D mHQyUxdoenomSepUacj5gPRH5w3SCaL+UVNfts4+c9DZLu2ZqeP+mPQrp45k+OXodIuTPvqE1JG9 T2oqNO1L9+lcf0xaQPbr1ARp3nyXNNf5gVSQqduQ5HznUimn8CVpltN0kymoW02S0p17pIVkmun0 Zi4kOo59eABy8EDMvUQ6Rixtd6Aqe/4+HTcPVGYVunXcpM6rzNqXXZnpzl4qubMrMjOJv+456zbr 9dYy6xxrLjUpGVaXNc063TbNZrf9xDbFFm+z2aw6PhYrlSzHsR9KCZb+AZvFJur4OCmF43jIVB56 0ibYOBvYpuvGe0dZzUzXsf+onXHEPGExOYuOhwZGVYdUSWCcYBrsHHtzo2XMoY2DJXT326VbYPvl 4VJH6bSSpAUVnu97BSa8c7//caBT20e/NFqf009XP2IMp3/cmPv/nq5b6BUqz82tXr5xINzZ1mxe ZRVviCigdYeptYg0yPKRts6xe3pGoKGxhc3BkNaphDxam+KRj4SbJzE3M3NY8RyBZu8K35FmNeSJ hdWweYsfaChfv3rCWjvH11pfPkmwchZsPVurYfUk5tXM3MDWWs3WWs3WalAbzLXYPr2t9eUbuqg6 6e+B/gKy6rWqZSt91NX5PTo+wv4zboH/AMoAGxAKZW5kc3RyZWFtCmVuZG9iagoxMTUgMCBvYmoK Mjc2MgplbmRvYmoKMTE2IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvQXNjZW50IDc3 MCAvQ2FwSGVpZ2h0IDcyNyAvRGVzY2VudCAtMjMwIC9GbGFncwozMiAvRm9udEJCb3ggWyAtMTk1 IC00NDQgMTQ0NiAxMjA3IF0gL0ZvbnROYW1lIC9aQkRTWFArSGVsdmV0aWNhIC9JdGFsaWNBbmds ZQowIC9TdGVtViAwIC9NYXhXaWR0aCAxNTAwIC9YSGVpZ2h0IDUzMSAvRm9udEZpbGUyIDExNCAw IFIgPj4KZW5kb2JqCjExNyAwIG9iagpbIDM1MCA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIg NzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIKNzIyIDcyMiA3MjIgNzIyIDcyMiA3 MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMgo3MjIgNzIyIDcy MiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA1NTYgXQplbmRvYmoKMjIgMCBvYmoKPDwgL1R5cGUg L0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvWkJEU1hQK0hlbHZldGljYSAvRm9u dERlc2NyaXB0b3IKMTE2IDAgUiAvV2lkdGhzIDExNyAwIFIgL0ZpcnN0Q2hhciAxNjUgL0xhc3RD aGFyIDIwOCAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2RpbmcKPj4KZW5kb2JqCjExOCAwIG9iago8 PCAvTGVuZ3RoIDExOSAwIFIgL0xlbmd0aDEgMzM3NTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4K c3RyZWFtCnja7b13eFTH9T88c+/2erc3bdNqd7VaSavekRb1CkhCIAECCdFNLwYDBmxcsR037MQl cYmDC44tiSZccULiOAmO7bik2bG/KS4Jjp04rmj1nrlzRwiM88v7fN9/3uf5Lfrs+czcopkzZ86c mblXIIwQ0qI9iEd5Q2sG18u/L38Jcp4CHBi6eHPg8VuPfYEQXoKQXLNs/fI1n37aoUNIsR4htXv5 6kuWXfkzbjVCxusR6vjziqWDSz5Jf6kdoX44jkpWQIb+MWUE0g9BOmPFms3bAkvT+iH9S7hn9up1 Q4N/uvOzzQgt/ByOf2fN4Lb1oQ/wPoQW3QTpwNrBNUt/K9uzFdLDJL1+49L1Ex/89W1IQxkztJCH ESk/QjqkQHeCDKJmpEFRFEMuOBJHXpSJ0pARhVAElSIBOZATyZENZSEzCqAqON+NClASrlaiRtSA TCgD5aB8lI48qBzpEYcqkB1NRypUhIpRHpLB/ZuQHxWiMKpFJaC5OtSCLCiBslErUqMyZEWVqB7K YwCN5qIa5CPFU34PodStaOpnFlqFNoHe96Cr0A3oVvQs+j1ajPYCuwPdiw6gh9Eweg69gN5A/x9+ UpfI1yAdfwzqa0Fo4suJ06kDgDG5YUrOrZCyyAJncyaEiQ/Py/swdeuEkBpTmJFGvFbPvQK5/8Lj E19yNSQ9UULS3NXAjeIVHyu/l3o89eB5OuhE89B8tAD1owE0CPVfglaglaCZi9BqtAatFVNr4dhy +F4GqUVw1hCcRfjZs9ah9YCNaDPagi6Gf+uBb5JS5NgGMb0FbYV/29AlaDvagXaiS6XvrWLOTjiy XUxvA+xCu6FlLkOXi4xJmrMXXYGuhFa7Gl2Drv2PqWsn2T50Hboe2vlb6MZv5Deck7oJ/t2MbgF7 2I9uQ7ej74Bd3IXuPi/322L+neh76B6wGXLsNsi5R2Tk6FPop+gIegw9jo6KuhwCrVGNML0sE3W4 HnSwE2q4d0qJqf62TmprF9Sd1G2fVNNtkH/5lCsulvRIztwLZ9K70HYgd7n0PE3cBHWg/GyNaOo2 sf5nc6dq5T/lMn3cPUUzd4kpws7P/SZ+O/ou9MD74JtolbD7gVN2j8in5n9v8tx7xfT30QPoB9AW D4qMSZpzAPiD6CHo24+gg+hR+HeWT2VUPoZ+KLbcMBpBo+gQOgwteRQdQ2Ni/n86dqH8Q1L+6GTO cfQEehIs5Bl0AjzNj+Afy3ka8p6Vck+KeTT9I/RjSJOzaOqn6HnwUD9Hv0C/RL9CP4HUi+L3zyD1 EnoF/Rq9gfXAXkbvw/c4ACWblixa2L9g/ry+3p7Z3V2ds2bO6Ghva21pbmpsqK+rnZ6sqZ5WVVlR XlZaUpzIzcnOjIQzQul+p9UkGPVajVqlVMhlPIdRdkOocSAwHBkYlkVCzc05JB0ahIzBKRkDwwHI ajz3nOHAgHha4Nwzk3DmsvPOTNIzk5NnYiFQhapysgMNocDwqfpQYAzP6+wFfkN9qC8wfFrkHSKX RcSEHhLBIFwRaHCuqA8M44FAw3DjxSv2NQzUw/1GtJq6UN1STU42GtFogWqBDWeG1o/gzGosEi6z oWKEQyo9+bXDfLhhcMnwrM7ehnpPMNgn5qE68V7DirphpXivwEpSZnRdYCT7xL7rxwS0eCCuWxJa Mrigd5gfhIv28Q379l09bIoPx0L1w7Htf3ZClZcOZ4fqG4bjIbhZW9fkL8DD8rAQCuz7N4LCh07/ /dycQSlHERb+jQglVZxUExxnHEHZoIRQv2CQlOW6sSRaDInhPZ29NB1Aiz2jKJmI9w1zA+TICXbE 1kOO7GFHJi8fCAVJUzUMSD8Xr3AO71kcyMkG7Ys/YfiB44FhPjKweGgFkYNL94Xq66neZvcOJ+uB JAelujaM5CXg/MEBqMRKoobO3uFEaP2wNVRLT4CMAGmDld294iXSZcPWumE0MCRdNZxoqCflCjTs G6inBST3CnX2HkeFE2+PFAU8hwohougj5Ri210GjRBr29S5ZNuwf8CwB+1wW6PUEh5N9oL6+UO/S PtJKIWE49jb8uqD4G8WroG7nnc1OJjVXhlWBXs7D95HWgoxAI3yFaqvggADNJSZJi9ZWBXqxB7HT 4LdIZxB2zn0gwYfrmskhnlxa1+wJ9gXp5z8UySOVSR4eVk25lwAZk2Wiv+cbi0bPJgWKBRqW1k8p 4Dk3lUsFlO524XJyRBfSL4YrVKQ5m9khPgw9F/I4uI2YRVrRGRhGswK9oaWhvhDYUHJWL6kb0bXY vm3dobbOeb1ia0tWMvucFD1eRlPDKAiHWYKrAxtsjHtYs4rpJjE9mWw+73ALOxzYpwq1de8jNw9J N0QB6EFQaUWkZfC6MnMRdM1G8G6hxsFQQAg07hscm9izeN9IMrlvfcPAigpyj1DLkn2h7t4qj1jW rt5LPdvJrzKjNtw2uzYnG3xP7UgIX9M5ksTXdM/rPS5ALH7N7N5RDnN1A7V9IxlwrPd4AJy7mMuR XJJJEgGSIHfqgoRKPN9zPInQHvGoTMwQ00NjGIl5KpaH0dAYR/MElsdBnozmJcU88oFGcq4AFYO7 bQgsIc2zs2/FvoE+0rmQHZoSfvAwDlWjYS5UPYI5hW5YE1paO6wN1ZL8GpJfQ/MVJF8JhoHtGJRD fNK+gRD4KTCoXuTB1BR5csvA2MTE7N7gKc/pviCY2gLAvN5hdRx8vzzcCuc1EQxAdtPwnqFBUg7U 00uuVYZbhvrAbNkN4ZSWYTXcQS3dAc5oFK8h5ggXDUHbQAOK1++BxPCevuG+OPmlvSv7RHMWhlFz qAKand5THiG/KNG3zxwqEPsmdAVN+Goi1FA21N1LczyQhF/WR5Wk1EHJh0JwaGggANqWoaFuMHXq SzUemrMUXKIsslSExiMdRKRafFir1wyrc+GG8EO4Npd0SXlY2ddHCy+mrpZOgN8tDGuhRJEpqpQu AO3AoRZSFvi5GopKTn2O3KZzDHWFtoFnIYUW76SEw8P6cMsgOH96vRZyQmXsYhXxEVrpHidprpLU XAd658OzxyYeDF0SnPLJyQ6RwYEYJvIcB8NGffvOzxieH8/JVp2fqxez9+1T6S98AdWXSj8pSWag AUYNOFEOM7RN/CtyMndUwvyzA81A859CetwFk9AKfOSIrb5elaN8BtdBRwjg2TAtxbguaZRx+mNu d03oWLHiBt7UMoZzDtcob+A4VDP+1viLifG3TpvLE6dx4s133npH+PhFU3mi8J1X38nPw6agSYTV wCmVVkUoPZcrjkZKCgsLqrniokgo3cCJeUUlpdV8YYGP460sp5ojacy/cmYeP3Ncwe0K1cwplPvc RqteIefSnOacqrDQPT9cletV8koFL1cpM0tr09tWN6T/Tmny2uxes0pl9tptXpNy/Pdyw5f/lBu+ qpOt/mo/r6hcUJPBf0ej4mQKxZjP6cqqDLbMMVoEmdYimOwqpdmky6xfMH6VLY3cI81mo/ca7wAd cig08aVsl9wKc/gI+u5xlDHx3mGdgNtDYxKJjE18dFgLRMuIBkjSTVhYIN968VsnficzcZgcztbi joxQJPyJTqtzpntDGj22y3RIJ+i4x0PPhn4V4kO6kM7s7TL3yHtQTU2Nubw8kejvNznKTUBNhcLp AlMh6DzeHxc/KB4P2+0KUelRPsgb+FB6JFJSiqmmHcoQH5RtUWEh7PeHLWrZuvG/ruI1llCaN2zE Kjwq07uivkCW2yDbgf+IfzTN7jHIeKVOjStTL6j1apnc4LHLRrUGFc+rjNobxncgsKpHEZJhsC8f iqMy9LOk2+8UcIdfMJIvPXw5dfAVgLr6x7jcZKbbloTjtiQct9m02eTkbHJyNjk5m5ycTU7OfoIr gFn+iSPAUaQQNH0IzgT50SGjJPWi/PSQTpTvHdISyQlJ/b3aE1pO645+kp+vzBjD6lGhs2gMa0eU s1HN6RrRcstxov8dUWkFr8Ypgex4vJxyUKrVIAsF0yPFpqKSwiBoz0Ys2sfjolwuFDIRc7acpTLs L5s5tKEl9ZgjFnPgyOb9QwX2+PSs4gUNmalxd9m81tGTdV0lrhnhpos6X/yysrcugjdNW95VnWXz R2WXR/3Zs7d35M5uKjNrirvWcjjRXpyW6g9Vzhx/s6K3yp8qSyvtgtFrcOIjmU7ug368+FAaqoxL WolLWgH5d6IVkB8SrcQlrcSf4QqRATlxAgVRBGePWrplT+IssvyEc0fUc6BTv3qaACdo9YXXT+bn ha0GxZSOqbBJHZV0YZvVx5F6E7OS6Ti5yppctKNl1y9u7Oi+/eXdZavmNXpUcl6m0qoMBTM3zJxz w5LS4qGb5nds6iwyKjUK/pjgNBussahn9gMff/e+M48vsAWyPAaL22xNs6ijiWjDVc/t3PH07umR RERh8ol9kNjZjWBnZuRHW5PemiC2ENuxENuxWKHWFjNU2eKE+lqeJLaD3FQ7bkk7bslm3JLNuCXt uJ/kTEgN2tGNGjo9YzgyIqd2wrTxKrOJfuLVzjEK5RQTuHHODz46kPpQNIDwQ+99t/NI0bpHrnp8 ZOcjG8u5Ox/66gddtKnnfv+9O1YeuaL1jKl6z3NIXHGEuvE7oW7Z6OIRd1Rq1ahU7qhU7qhU7qhU 7ugYZ0qq1ZaAJQDFd49hVVK/J4JPRPBLERyJKFxjUCN9ZxTEiGLS8vs3bISKJURXIkg9QGxr7mvW HgqazqP8TplGrxq/ldSRW6bSq+Ry+Eop8KgK3INMDXwGh1V6jazJ7DGraH1VZo/V7DGpUqvUQprF 7BaUqXyVySPWe+JLfjbUO4oWjCgtUr0tUr0tUr0tUr0tUr0tUO8jei/yeZVQtUMWi0sxhjMPpXe6 iJOUxqXESVP5ZO3w1yrDxhxWXX42VEyZAu0pofAiT6qsAbcz3aqCqjaKuSctaVCLZqXgsVk8JvX4 X5R6pVwOX7LHSC29tC3nT3wo2yYPoBp0f9KblmZ0Eit1Eit1Eg/n1OgIg3o4Sfvp0bNRHIgmowNR PmqUNGCUNGCU+rNR6s9GSQPGMa7gcKIIFznHsOZwenp5ovpJrIGxXoNjo+Xd1jGcPZKYQ1oc+rSJ KkTydq/295+cdHeSZs7p0yWlJmIHpM+L+jIRP3jWC8hk22QqnVJXtnDvvIseubimYfvDS6t2FKde NZlkahgp7tLazRpzxYLFS/Jv//v35/Q/fPqm1suXNrg1soUWr0UVyY3M2PfMup0nrqj3evEl6Rmg SJVKSDOnLO6IN92p63/0o/13fjk86A7F3OlIshHZLBh7E2jscE0+DukkJekkJekkM9FJZqKTlKQj 6k1zZGiJ/rVE/1qify3Rv5Z4CS0ZKxwoaYMBJmkhX4IJt6MkHEeOsYkTh+AAkUfhmCOrCwaS7KTx hA6/pMO6c0dl6FSnazCMHq8SxUpmd7Zz9YcnzW2q5VHvaYM8RmWzVNag0x2wqsYPAXMR61NZ052u oFXFdYj2CMwN+gez06m46vEfMS77HWPjX3IKxiX94V7Qnw3NOlbjmOl43MEjSYVIUiGSVIgkFSJJ hegJ8IyaiRPHQBMaoUusLlRz0h2Gv1YZ3MvKrbYFHa6ppT1bwrM+rw3K5UbNx5GNFsgmFcgmFcgm FcgmFcgGbXoYqY1dtjEcl5waTpxiBZrixSaVSzp3G3gm9fhJR4wpE79Ewpk2q8eiBh/1GCvYV/ep TWmSzhRx8EtV6NGkMFC9vprT5+U5EglNrtPpHvsvhxVif76MfJ1OQyxQQyxQQyxQQyxQQyxQQ/QL MU7SRZSdUdKpdTr0CWd+rsKf2envYQZWY4aArxAqyiIViPqESWYqn5YoLCRx4JT2CGES+0EUiEPn +DoxDMSFJCAU9aOIq6x+lyNoUXGpQl5r81ptPquWSzVhsDaXM2BRZntWBPIynGq8VY6v0rr9Edca o8eiO9usy7/ar9QoeRkM6xBq3zGZfyArQ+fO9JyZyx/wZbm0aovXNtmfd8lNaBq68lDUaLRK6hSl UZJ6UX5E1GmV1GkV1enT5OYWEHUWOI3kC04sEHSEwSkF5BQB+cq6NLnGqMxFRgRiI6ICifq+pr1E oWQ0VFeRSDRkt9suoDEf7yiMTLEr2S69za0vdUdDIVtqRWB6GsdxKovf6fSbVdnuLm/U7zXhCm9J Qb4Tw4Bo8bvsAbOqyQqzC623IMq9XX5pZfPtrWf+NTmEPJKZrnHE/OM/Kxoa6E/MPDiTewYibxhT dUokxj9DE6dl78mDyAKj5c6k20q0YCVGZSXBj5UEP1YnVVRhUh1AeeIOrE9Sr0+yVp80pPikIcUn qdf3JISIGuSCAcTYHSK9Sz7n3CCof0pkfM6ETYyBpsSEsvdab31r/y2vXVffuv+t/Te+ekPDkej8 76xf/51Fsci8b2/ccOfCTO72754ZWTT3wKf33vHl44vm/OBfD699+roZs69/cvnGE9d1zL7xKRLv QWzwPPTBNBRD20YyFFJFFFJFFFK3U0jdTiFVREGMwGHyEvV4iXq8gk6P271kTuGFcXMUmcIwah5S KHRQTe0hW6duSthATUQ4N3IInR8uyKaEffzzya0/3Har2hJ0Ec+S5ca2rI6Va9pjRyrn9mffc9eM 5Y0Z/K2Dd6+tSuVO9g1obKWjZsElc2euKjKMf5HZNETbmPQNLdS5BNWjm5M+IddUqoJyl5J6lIr1 KCX1KiXtXArtfCxG5lKxGhNRBjCTpByTpByTpByTpBwTKGc0LVeAWPHo+iROJh3TQAdHgp0OydWI ESKZHH1tblQu9RRxapnLf00pdoePl6ZIDovdjosi0UiEhcZahTXD5w5atbKttpzq2ZWbmLogVLbk T3e3bZoRDdUuKA8U5WRaNxtUqfH6Wa6awpsfqh+q9YOrUUE/gG6eXzS3JjT+20k1Qtgl5/Vlc9bV TV8+s8JqiFfNyE/9KcPLX9m+0qFUpNqDlbNEn9M0cZofgr7Tgt49jqbDpN0I0/DpkpKmS8qbLnmc 6ZKypo9x2cl4QdJixe0FSRPM1QsyCnQeJ7nWQxy5RxDIF1ziIQ3ieYLLJ978kEccQU8ccknSSuVR IwkvdLlP4igqhVAtktSaAqW4NKnV4XZooRNJDWGlplKTvQoi2yPTPfJYt30Mx6S+CI1w2kTi9ni8 XzgtEHM9G2+Y6YHzOqmMdVK6/JKr+IbJnIIfqtt6X//0dXMrHVoI8FSGwlkbWsv66zIKulauXdFV WLny5tnxuR1VFoWM4xVapTZR319RMqvIXdC9au2q7kJ80fxvwZQ3kO4M++1eszI9M+QrnVVYOqMy v7B69oaZnbvn5BhdfovW5LSYYY6XFvJ682rDJTOqCgqndW+ANjJCf38DbD8dLT3mTJJI2US0dpjE Jf915ycDqmnixBFi+wozmRZ4pf5dAIHLx6JyfhIXTsYnJwVnQzPm0sSQ4Q1xMrOfRTPApMkOf4U4 1RHnAl99b9IUF6tMaRYLXTSi8c00iCHehvimCi0/FKnCBWMTnyfrSAOHoSgqQjITOCyIOWGc7iQk lo6dAUJy8nFOHs7JwDkhXNqV1RXK0/JTQ04Yz2pgwIcPWfyR/oUnx3yesUikpGTKmD+F2e0KpXyv TEiL+fzxNIMs9TH3JW9wxwLB7DQjn3pEgU2RgD/DouRwCGMrr7aGfWlBq5rHMQ57eYUl5PWFBCyP GExklDIZ+JfPJBiXHXS4DTJeZdB+dVJWoTVC/1UZtV/9VFapAS43uB1URz7Rx1tRFuo7Dl3nvw9K ddCtHGKsfyKpI8F/uMujMHcpiHbM5WIsPtkTzjbxWXWAh3IUlpSUWpgquBYaG9pUqVu0cmM06Avb tfJDrgI358h3Hea1lnR3RkyQa/FnqRBrdfwm9ztSURlMD1PXF2+uLN9Qii/WGJSkinbw5wvA79Tw P0eFKImGkwFjrb82Uctr1Y4iHdSoiDiRIuI6igTiVIrG8GdJmAxHjQjrEPH5qELySRVSVFQhKYFI 0YlVjHGqpNXk+AkqEoq4yhNFGMG8sCh3etYY9iSNL6Xj9HSZ94Pc1ml/0HXIUIKtAojTwv4NC/vZ AH8yvrC/XFoRKABnvxCiSbKSCFFPseLsOlBhsTTaSzkyMRxSUjdiJ9NHvkZI87j9hsqbO5s2deZU b35o5U57/ozyaYMt+ToVhDRKT+2cZUWD18yOPHBD/ZJaf9+s6eumOXU6GJF182oaw43Lprevbw03 Fs0q9nhDXpXgMrq87pDXkt2za/ZJR05NrLG7tl4cL+8A/b4m3wD2A9HkEZicaIIlkrmUSOZTImmM pEWNlYzhz5MeW5wETPEAWS0jLRAn42pcEBfROE1SjWyakuKgTJ43huVHI62eRqG9HOiIvIN4YjJQ OsonI8qzWutnwVHU9vWJHu2ALFxSmux2MYB4rXDopv54S2NjVGX22CBEVCgtAacL4sXMtubmzMXX zc18zFY0JxmoTjZE63fWVfeWuvC7W568otEUqYitBWMEA9Sp5GXiOAlf43+JlYWEGXuHtzRcvmSa Oau2IHVH99yqoR1in5sHOgvwL6BidO1Imjg+0U73ttTZ3jtMOtkFFqE+PHfxaeIDuijFaZP6hAEb XO/6kxp9sx/mydxhSyv/t3zivdX65vzsMawYUXeQVcb4afFrcjni5OTy03lLjQo6OCmmLjTyAU6u dFW19SYGb19aPH3DHX3xzvpip1rBmfXGaFVPxdbdwWR/VfmcmriOTEnuN7lMelfYa07uOLTlyme3 VwrudKfB4jRH/cHM4LHH5u7tjWfEQyqLl9jSAOjlbvkaFEHl6Lqkv6YSaz3lpIeWk/laORnry4l9 lBNzKX8SfwHaTFCtJSRlJSRlJaRem5CUlSAmpbEEG7XlUY/MAF1TPupshe4uO2TokLeT4Uk0qJrz VhxFi5qc1E3thhBuTdoVH4lMDb9L+buVpjQr2choumP+0PVzMwsW37xo5t6k0uonVqU+UHdpfQ3Y ENjU9OC0ZGPUxUxoa8ecjr0jizc/eUVTQx2nZXOT8QawnsU7k/WXLwVrqsunsWo/6OsO8G1xVIQe S2YlSmpK1pXwFtKjLAGyfGcJZpPYKJvoiy7ui14OrOGLI/XxB+IcWbY+QnpckUwyP5lkZWJaK0rq 5mREg8Fg9vN7ZDfJuBMy/JIMy2RpiT9EWp0fDBjWGziD+oM00cT6p65z0o75Zpyam7jCL3ZSRSg4 xbBs55ofZ4uWiCpV8ndEXeOjvsb1ncklLQmdUqvgOV6pLZmzIbnuwY0VVRvuHVp120DOAf6SrdMW VKfDJDAabNs2J9fmtikNLrPeYtRpXU5L9fax7ZuPX9ZQv+muXsvl+3Pbl5bS8S888SV3lXwbxAhL Ru0C6YRi5/NIvsvDfJZHcmoeyaA8oMPRvKzw2MRLSTNZtQprTpc0uSOn85oD7UKzGMkXkLlb/GTh x7SfFZ48b7XPRmuumBrJh6SVv0K22sddJZOrFEqbL+YJFwUML6i0arnZ+IIKHJQzYFHtFgTicHaH mte0hmozdCpebrQ4DHK1Vu0s7KxYrDS5LRmBM39TaYln0qp4WyDD4jYp+xdePSemN+osHqIHHhWn buWv5X+GqtEMtAi9lLSZc5pIX2tSQaWbAoIFtzcV1kAERZRQI/UykG8fJYdqlDOBJvVGM26f6ZEZ 8/hCpZJYkCBq7ERSDySnUOnxKAtzZETLySKi5l7yK3oDAlzWmxVOakGGjXlKvqz1d7ru92y2gTL+ /armrEDtb8ta5/82MFNaQq+hS6qv0yEgXniKqNcB0TeJv02QKZyKw0+cfRG9g5btdjokRKIK8Gp2 hzRfYnZXCgNtUYn4Tfs3TKlwUWRyYCXbTZFo1MBLKf5ai/GyUFpB/54ZpUMes2N6yd/q1nflFl10 YMOaOxZnC8H8QH6iIOzPKFpwWXusyY8FkymVWtqf15RwLJ2f35xwdC/qfD8Qc6qvuLhtabWH3xzy Z8xNzNjWne21m3N9oVxOwwWn9VVWr+/JDyf7ioLVZYUuV3v2tIFIuL+2Y/vsHLUqmPp4wfJAWUtm 3zJ/afP4wooaTuXKiWXaptd586qpjd8BMd69MEYXoEsO1xThrLPL+JJxT1nfl9b7YYB2+OhCrbhk K67Wis5DS45p6BqtL8sFE1nFsZzWjEZXu+hGxQksTkhLlHRYLj93oVIcVZQXWIalkaGNv1dlpqOv M7clr3pnPSTFhTA2KDfd1DJvR3vQxWyaM3YsrM/o7Rm/juVMHYnbWqYtu3aQ+MsrJ77EnfIEsqEg uv5YTWhmaF2It0txnV3SgZi2iFI0X7tk63ZJafYnuQ0oDdm+aXlUUqkN1HRU4yd7rP4xXH3YJbSI +nn9dFzyidIIc+FVXAsZfok5gh3i6vMVYMmurIgTTKqAv0JJK6zEeRVZsXKAOEZMvJa6FS+BOmeg PHTVoZkFZN9bDBtA/pOUPMwcPNkQJ1UIj3HrR+M6JJ03JfinNZucBYAHTGpcLlSQS2qZC7U8lOlv scKYOiIXeyrU1VRYyKJbWl+orfycibHYlb6h4p2+5JKmQI5TLcO8Uq1UhBzBhM/AXB/RQla8sjLL uGTH7LhKozeZ9WRvS27NaW7hD15IIbQv7IS+UIRuS+pqSnAsH+cnzbgDQqWXxOrlSwNhPqm/TpTi QJj/JBeFmbFO0sI373lA93Dbc3IQUQrtJvZ0rTyzJa3RxLqIuRy6CAReEO2LY0PB28wSJk0hii/Q QaQJJAwZSoztdn6nCuZEnpDTqEhdcb6N4NkqswvmU+k2td6YegKv1WvFZRxeqVfjf6b0X+8qZ16B mZNezcPwqtY5hdQTqbDJJukMV4PObCgp7l+sE/cvLjw1PGsl+PPDGqFRrLFkAhfer/iadbu+XrRJ PyZ/CeKdWeiDpMdMNvDEveaIOIOPitP39V248eu7lXR1acqu5geTXs7ns5O1WF8B3RMQdwfEjQHR 2WnAxo/NIitPs6q/vvlLb/u1TeIn8efgagWsGG1rhVBckdRPb61uzClryWl3TbGAqUu75dIqn6mc 7e0Qn4kI+U+O85s8qU2aY0vmIn+JOlSLyppdn1u+qYH0IEfQorRn1+WWb570rwpzmsPuFZTtN7aU 9dXnCTmdbU0Zcy9u8Z/1tKHy8zzt13P4KyBE4Xm1VrW1Z6Y7MT0zvz7LAi64/exYBG1YgPYnjbQN yZc0LH303+0+k+mjTysIbHQStxan7Criz49JAxQZnpKanNYsV0YLUz6JHyZHKLbSLOk7/F8r95uH qUk1frvj/zBMnaMqUNEAjevJ/PAt0BHZZ3gomVYTw5lmHDPhiB5HdDiiwhElzhJXgS6wt/D2BfcW SPDuS2iwZsqmReDcTYsnOA1ZOz1mRB3roaFcYxiPGltDMJeUptxkzigpLTG5FdHPPv+nPQn+rYpN P9y47gdrS8o3PboJZOljnupVM1tW1gc9NatmNq+qD+C/rD1+VVvtrsMbQbaC3Nly+eLyokWXd7Re PlhetPByst6Q2s+/Broh6w17yHpDsEQj2YlGshMN80EaqfYaMZyx0aUGcdFBXEGmqw4XXGtoEWZ+ 41rDhZYaLmAl37zUcMvCzPrpyYwp5mK1eczKWHtHZ87ifWSpoVBcamiM1m+vq+4rdeP3L35qb5OQ XhRKVTOPKHsfrIbnwX4uyaqO2dqveHxLw2VLqiyxuvzUnd29VUt2UlsaAH3dLenrqqQHFObXxkmn iWt0bOFFdHVxMp/OQoXUcKY85fWB9JQXe/qLPeUF82lbuEU7Le6XCblkPu1uLSPzaaGDjP4Xnk+f o7ViE10jZRbjKP7m+bSadDW/VRlrbW6JEiUVDN28KLOxoSmLPCpoTTMpvzanTh1musKnYuUhI5tX m8KVsTVMeal/04k1XaYRJ9aij+IeFNcMhw6vL8YRo2RYZx/+kAzMKFmekRiYWXqEAQYLRCwNucHu wkl1vDVitAVabO1Icvvi0B+fjIynTgmV32RICu5BTqFWqRzeDJsrr7gidL6zCU+vKPfqgxlenYzH /GK7z6RWq1XW3PbS8eGvu5u9JfVRI6/SaNQGDx1bOydOcy9CnVvQi0ldoq2mbWbb7rbH2+RTtmg+ lbZmRMOYTpatLOdt3YhbNvgPST/dpxF3aIiZSds0ZNpMPI/nCfypuOmuISGSLqmVlpEjcL8a3eM6 Tpf7Zqnmb6ZZpgHTehNPt2N+T/ZiWu3v0S45uREjbcP0kyc/pmzDnI2t/99uw3AvFi68fEbe3IY8 u0ZGtlniNXPKsuoLPNHkrJ7OZDTWtaMro7kiZlPyEClpFOr0kpZEVjJmy0x29XQno9jQsBpa3OGy ZvgtEI16Ah5zqCQcKcr0p8er51QVD7Zk68w2QWe0CyaXoLS77JZQXlq0ODOQnlU1m7RFcOIf3BrZ D1EFWnA4hkyhHEnnOVJb5EhtkSN1yhzJLnOIGeoc+pzToWav/rSjOZ/E4krqvE8RwyuUVrVOnaRL frILLzqcuzRhZ4s03BqVEIjlOhqXJL27jGayF3MpC9reJevKZuO7pU2OjDSrSq6Wy+Z70wWDWhFu 2zSDM9BVh9fZhvrrdF0ipelfpNao5QYnqfd+sv7HPwWxwS1JP0QE2iixoCixoCjZhI2KjioqiMEX /uIo7Wt+SSt+SSsgPxd7JyGHxIdepe7ql2zUT2YuaktOS1Qrd7VAiCY/uwhIeijzWZMmdcFFwLNh OXtqa9J93a00e20Or0nRcbsYAiitdMbiSDTnVe9oUFr90HfN6snIYGvPjKrl1y7m0ln/HP9k5qK6 cG8Pt4XlEP2kQ+y0A/STjf50HIUmYEwjIa9f3MkK+7GPEh+2S/W0SdJ6NhAWpXlyL3rio2Qp2ciG 2MKEowLOlOP0TMiYlo4z0nGQ0JogzgjigJgbwBkBHDXii4M4SBa+1CZbczAAvRZS7yXVYIpBsu5I UqQlguT+OrgwmNkS1LpbtO1n94bEZ6X7xfghTn8wiSKo3sleWlx8fn3yIZopw4TFQTeNfBy/A3M8 lzol07szfb5Ml0GWelEmJw97OLwhi1qWkvFfcRpL0OPwmZT8PTK1Rqc88zB5elqmMmj4uTqzmocZ Igdf6nG3Tsf9Va1T8ZxKS31iMcw3rgB9N6C3jqMmcFDToHJlZEEsVoZLiQzn4kgQRwI44scRH454 cTQNZ8pwjMcVlbiyAlfm4CryfqENdwjSggKRSQ0YrBCAOwhGKZtIcSPNSLKN01vE84g6a4SZwjph tyATkmZ7s1DYEm6puCkbZ5Nj2cRvChZ78/LsrdlcA+Q62tVEza8RXfafrKk5BbqkGk9Qj4jEaG0y bqOqVkxqmo8qp+xdXkDpU6j8Cpk89Rmvd2T6/FkuHf80xz3O690xnz8KqdQXchnMNBxp6WYV/1uO e55Tm8Hw/WYV9waHX+fUlqDb6SUNo7QazzYLd4NaPb7pbCMZrUq1FtoI5q3jbrUa2kgPrpc8Zudk KU6lIe0Vg/7RBu2VQJclTYF8sseLO3KJu6jMxU4wxqNko8+JHZJjsLMsO1YTU80iE1hyTRXCZSFc osXaAJljkAbRavPzYi0hrcnbYpqcR5TXmMyYrmgjolNiudR4+8N2K3sL4OxLAFN2Pye3PTFfp7JE /b6QTSv7zRsyrS09zRs2YTV2pj5TYUs04A1ZNbJTL8k0Jr/HGzZz6tQX2QaLTg7TdCVemroLBC/X WQz4GH7QYNHLeIVGmRrBMxXkkTCt1ZhaKPoOiAN3gm4yUNdx5IHKFpN+78ExD3aKk2gnjhhKDFxU jd1kQK5wY1cZ0ZwL+1tcGkuLpk02E7VJk1ey8x2nXZZ03SBP61pqiUTAaoomd7wt4gqP3arkCrcp 8gvcAROn2KkW+NSzKiHD50u3quUY858rTOmBtAyTInVEMMl1VgMul5k1/AKb0yDnVUb9eC73ukUr h1HCLPbLPghs3+CPoTiqPI4EqIudPJcTEZ/OScDxInW9mlOHTTB1OeRqNkbFKQwUnSzIF0CscAr8 jjTVI48qimu/+JxHbsXHaDCh3BsKlUE1/rrNQ6wR35DaLVjIs4ycTGvSKUleags+oNKrFY0Wj0mZ Fkw32O0ugVsVDJshrTDYTQGD0+EWxm9XCh4ak1858Sk/V74QFaFmFEkaMjL8aushuTxPXV9BxiY8 ktdIhuw3yTs94ko33TeYfJmHj5CxmsYxX9sJPn8exs8tmLerQxmK2nxmlQKrzWlm+/QF5e5AcrC2 Ym4yplHCIKSwlncOFl1055K81Em1M+YLZLrUaldmwBdzqvk/9l4zUCL/2GgknQ7DuGZRxuoXFJQv aoi4fE6FyWt3uix+t3naiuvPVAbjHq3WEw8Gc1xarStHbK+s1Ft4E3obeZBmVOtIQ8Krp+ijTEol 9TSllslXjzYpDA7TtXK9xWUxOTRYdqXWmeF2ZTi0N/qLcnNcLyo1KrHzY8seT0BQKIQA1emTE5/h G/jbxDmzZwRZx7gdxzS+EMz5jc2o5lTNKRL8FHz90TnT+e8+3QD19gcywbc4MwN+qodz0nwgkE3q mB1IzyEyZzwzSDOg0jCIuHNInb8N5VkLddYixwh5eObEUfKQjJoHzwFFiT9HFDBlpXNtoroql2BN UyK3ASDqjd+CN8m3gd7UoLcmuJIZwn+vNnnEX5jIcb6o1IlOU40tu90Bs0JhlvR2Db+VzxV/RynS H1ak2wvg9xSeIpo6Z29EelVMeYFcsX8f0DpCTme6XavQO4Sr5TqzyyzYNVieclzgALg6WdMuqRxu XyE07CmVRknedFKlTn/DAVreOL+Ve3myvNqoo3CyvJOaiUSKzqpGfkGFcS+T4lwj05udpDj8FRpH yOUI2bWpO6ccgArIxCOk/PKoH8rjPKXSQnkgYMAm0KRJoTAF3N90gPwlm9S7vEb+DLIh1YggRwno yw6pMNJqrvIhmd7qtbmCZpmC65fpLT4bBNQy+cd6o0qm1Fv0ih16oxo0YNXD/RrwYS6Xm4aMyHAY KbWnZYg8NCntcAWpPYl+K9dsSi00wwffD95Jjr+I+vyRiE9hcpM+OfFF6lYZmnAiPTIeQUrN+zKy Yv/1G9llSDCdmWYym038jwVT6vVQwBdKTw+I/frK1IP4X/LrUAilJ208GWd5Mr3jRUfM2/zaK1FN AvodfQhIAfMJs2Py5bhcXrQgqgP8j0X9i+bLscHrMrstOr6kqyzNX95ViNVCmt2RJnDyxS+k+l5/ IzXvFzqTVs4pVPJlL//mzQ0b/vDbV5bLFAoY8wQas22HMr0LZQqiwuPITONfszR/IvIIKZtZfBhQ K87RaRnjBZPP7CnZcF1iLi7iohEpALKb8btpZZ0lvM7iNru9eixfsHDhQhknpDlsaSYVt3wL59rw 5m9eXiZXKTg5DA4/xw++8Tp+8AW1oIHyKWSnUjORDKa9H8r98lY0G60Q/6pKIqlp2VTk2+aapzSu HcP8kRkdsZixfAwrjtR3LPm7sZG9NSQup+TnWYjSqO4Kz74S56jmi8/O3WgeTEnEDU8ay4lChq3i qjAbN3i2wJLLwwl4tS+5vCWzPCxk9d+yoveynnhk9t7+9Flz52fD/EWnFPwuu98KUVu+L6cu4ddo zFqoqS7gtuYle8qz+lduqqvZMNBeDEGw0Z/jbxmq8thyG/OLWxL2zaH6ZXWxGU1JT9Hygb5wQV3M nHoH95QO9c/NLultbwhVb5hbGGkcmla5eMH8gljfvLmZnoaOWbEMjV4t45RGvats9fKFmRl5Ph2n crpcPqNGZQhV5aZXxBz2WPXMxTznKZvWGI81JJMZ3uKY05NTNZ5ZNKcmZPLGHDmDiwdzAzU1Sf5K ca8bTegV2+S5aL34l31WHdqw1xkew2uS+bk6Z04Z2uHscfagxqHN7/gz/fm7PjTN+3DWrDalbm/u hgy5yQ//Fk77cPUVnW3/WAidr+bV0+KKA7ROARmvxTdCyZLEcydJ9nPCy6+bysvfMZHHd7E045Za gw3ZjlIaMCl5BZlry6TmOefJG/qARIYYkStEvyaukcmkvehSrNhmilTP29oRaywJKzPbmhuC8drC DKfGECjr3tgeqCwpcJtkaRGzyyDn+oS8ulhtQbpdk9j47E0Xj12/pCHLrizc9ep9LRfPLdEo1HIO y5S68sHLZzyZGv9+s9Zf1rf7h3+84YF/3N0+/lRkVmFWfUHIri6ucRaU1US+OsPj+m9dtXVeoSWj PJxZniGYgnlVzVnxdRdv6Cs1BvKCvQaDTAlRadHc7lhj//LVBXO/u7WpqG/z3mt3r4+uG7uq1WQx KY0Ok8Fs1GmsVkPvA3/9VtHVd9zznauXVsy86VcnkvWx6V1zOv2ts0yh8ijfBePARROn+aflATGG uuM4aoVpkMPIdQy04viWGrysBtfV4KIanFGDa8a4uqRVl5am216MVxXjtmJcUYzjxbgYDhxdjzBx 02QSRp94fO8Y3Abl6bBubOLLpAYSuoqJvDx5ZAyjUUtf/Ri2jcgXTb7FCq6j/1WI9/vfEWdTZvIA n8jIW0fxKYtPsvMXm5TnrRCzdfKni1Yf2NC5c8G0sGDOnbn1wNpwezLboJRxWKlVayMlHYX9V/XE ePf0jjn5K2/qizzmKJlXG25tqHEHaxbWJBdWe/H3e+65pCWzdfW+BxZ2P/K965ZXqY1mrd5oMZjd gspgMrTveXiB0ec0li+9dqBiUW2G3uE3X/bYypy8zqWkf3SBbp+QBxF5SLoJX34clZAFFBN5cA8I caDFY1JOMcspYjlFLEdcQjadXUpuER/AhiZqwXnsnDy2NDM1R9xuzRvjXEmXNVMcSzLFhR+Jk9cI Msc4Z9LtM4Z8PvIWilX88ll9mjLxnDKyOGHzwmRdvFDKJBeWPcHVQf9/9RBp5LONPvmEuPQk3glp b/OE+DBQLZkcasg9avPgprWs0LWs0LVSoWuJqZk0ZP6kKZ4mzxl39TWMTxpL+eSLW6/SZY5zHhsH IUzZXyDWg+LSZ2rQ+nXnzxdNPqfnKCkhr0SzZ1RK+CeqNhy4aMn31lZktq1tqFqQDOYP3bFs8Y39 2eQxvaZ1bdHfeMu6i1ev85TPrVq6Oiu9YXl9zaJp/iuv2LMXt8/eOy83q2tbx7Rlc9rS/Q2dC0rq t/YWJjrX1hQunN0SCLX2LOIWZdXnuRb3ROuqyv1Fu8bvz22bPi3or65tyR5cdRH002awpefFd2bi 6IOk67yNrDDbyMoh6xhhYh05eMoWFdmbtZL1PytpPCt5Nd36JEdmFQG69BmQjCsg7VMEpEVAkO+R iDsjgANjXE5SrSGv4yQRL/5VADV5QlAzU8MhcRVLfC2MGsQJsccjDdLkZHvGsGbU2E3eVWGv4pDp vthaZJYPHX3qDqLYZP9hN0w2ZUtDxj+fWDN82fYHl8XzVg/v2QFy2OCJV3Xk9ayaZvdNX9pc1jMN 5hzcvts+HRmc+/Bn9+7/TJSPDt55cU+pa9b1T62++Rd7KjLqFm68Uox7HoOOe4/cgXLRX5IZGT6c 4cUZaTjkwRlunOHCZHrvwDFR+2ayqJEnPpVFFJ6HEVEuikmryTFJpTFpXTUmqTQmrZrEyOs9Bp+T XOTUkm+tSepJIMWeZZJ60pT8E9JLMKB8uOJeEzZZzGO45lCoKyaMYSV9k7CgZvyUuJZPPqfII3Ps fQHaHc6uWvVLs3f2wgDMtBV0tao0LO16m8TZ7z0KjV45vkCp0yoUar0KG74kT8fxCq0aZ8l0EOQ7 YbLxgcqglteT1Xql4LaY3SY1/5vbNDK9z2FyCjrFs7xMBuOhVvHVjWoxfAZ9bwR93w12XY32J/Wx Ehz34ZiXrAEmx9hQlMR2Ysl20fvYA+KCE5dztDAM/1C5pO3yJ7jdSEvVoyUrflqyl20qKw8EysEA c48W2hW53QIEhJlMR3TvI0EdCjiRU5MvkotaEtf2zlEPWa47b6lAMek/lOLLFnfL1Ub1eLHBZlTy GqPuq7kry81pxbOKxEfGlTCx4eQqZ2XfRZULb+jPtTddte4UV6gyauWt5E0SpeCzW30Ohx5rFtyy bXE83lGRnp6ZrjL7bEa7YLBlhJzFC7Y3VO+48fGNr6vN4nvny8Ev3AL668Xy42geqCyNqGwezleB UvJJ588X9ZZP9JY/xhUnNTO6IzNmOC24I0lWmyNwSoQsgSYhN5LkDR6VwPaXxCs9AfExTWq0HtD8 EXFtT3y+mvRxg2ScBsneDaThLNAMhkry6E5lUlxOqsSi8UpGTEeBSlOlyV4yhrUQu3dn/ysQkLeQ l4S0ky8JJU6XC5PvCYH7TlCfL/l78UFF8rCHufysr5cchkJcD5jcpaKvRdK9ma+v95xtRBuMArdU b37koukbeiuMKgVv0KuLu9fV1y6pT493X9KxA9pKqdAa1BtqV7ZE3UWdxRWD7QUasnQIcylLRc+6 5Lxr5ucEqudV1q2blYM39t24rNTm9RsMMDPNSAuEA+nVPQWlvcl06CA2i8uoTE/2lWa2lPhDmSG5 0WMnwZsF2jl39pamaSs7y7WcsngW8f95E1/yvxbfL8lFXyUryIJ5Do5m44wozojgcBqOeHBIdFFh Jw47cMSOIzYcseKIgKGJM+Q4Q4bjHiz6KzP1Vzl2JxB7QJCe0qNP5719jDy9l5abK4xNnEl64QyB dD+BWIRANpIEMpAIZJoqkL83EUUy6q1kMAiwR56TGvLMsywvEfXkig0siwcFQRPs0tD3WqDXFZ4u KJCWfePSfhp5ofUUe9Vc6oHnffC5j/lOdk181lvZcQgH+V9bzbewN3/HP9AJepjtapT4FbnFl+2D qZdwi8mWuo9LzccP4vXBSOojtomEBYXgc1p8LoeeN6vIg8Aw7z/z0xD3/ngF9VlLoc/dLjeAz3ou qY+W4miJ+DAJL/qso9RllUp+qVT8MzrkdUfysk8mKD8TcjNJz8g0zCxYV7C7gC+48CueT3CF4ptE 0oh6RHwOzjJGHi0hz5panCXkPX5ddsUnAfJujDy703lO5+k/TTpPIo6F16U+c7L/Vdp9qHqJfs/2 l3O2dUkgFDrnj2goQkHpwVL+9sY9I6urVs8uMSrkHK/SKjVZTSub69Z35kY7d86Z1htJc/q93DSV USO3mlPeUEveugPryvG9K+5fV2FyOQ06k9ts8phULq87UL+8tXpRjV/nDnPGYEANbjAjM3WbnCse 3AeVn2DzE06Bpom6H4J+8Djo3o/eOI5M4L80piBuNwmC9Groua+MvieNlp+L9rhZ3J4TxthVgkC3 kcSrBOkq8bCW7ABuEUjnUUibf0HWtkE8JcD9jRjY2qRxecrTq+9JL/+/fQSusclNYzjnkLtTO/kC nzgwi+0Ql3br2Kbd2f06ca9j6no6/zgvVytSuXKjI8OdHjFxCvzB+K0Wi1xjUHP/NNi0CtlJs9fj Mnz1os6o5hV6i17WmplhgbFFYU4T9SnNSUCf1eI6IEkfgPEjD9Wip5OWWC7OkuOYuPOWFcERDa4n DiNAKl4Pg4qejSfe7fm4PL8lf2U+H8/H+eQFUzUyGAJoPeLohIBODA4Tq60kowdcWkniFjO5fEsl LqlsrFxWyWdU4soxLp40JMI4nPxnIKAs+SSrGyxZNaKcM2V6KE4Mxdds+qW5YcFUOxYtWXb+Awql U180kV52Pvv3QfgD1rzOHQ+vj3dOz7aCurQqbea0rsLB63qzueL9A6tv7YsWrHpgY+elC5JR0+Pp tQM10xdUprnK5tW2Xc89MfvRe65bUakVzGa/2+42yI1mY9uuAwv8eZXLru+ec9fFjbGONfvua9zz +Oq8xMwlxZWL68M51H80otX8UZkdJZB1NCvDR/64jU5hRonCU+OnCv/T65zn/TGIowqNQZUaU5nS bFavCZhar1FAnKbCLSqT10qW04DptXIuafGYyZufWvLmJ7i41Sqzx0L+rg0wvVoup2+ImqVnWJai hfyYLAh9THfInCYoUOLUq2zJHE/GhxiTGVRJid1BHqEdkyk0ijP/0Apkncmg5a4c3603qjiZWtDy Vo2eqzZ5rFo+tZmsTTrS0m06OZ6GixVae8jr9uo5RWqTPIrEv1eO5f7nnnX9fpGx6t/IJa5Wo+cD yQkmJ15LbVK8LX8GkmowNfqB6xQohfBJzYwz+anr1Uelv3x+9tMmM8Bpv0JIdh8KyeahR2X1aFD2 d/Qo/x7gh+hRuQ7Nl51Bj3IySPejRxVvQF4WoB0NydLh/F7xvCb+r8io9KFpIH38a2iBrAjdwS9G 80AO8F+hfm4DCvMnUTHJx6+jK/EHE6/z3xf5HYol6A6SLysTzyd8gPs5XB9EndxjKAjp/fx3Ubp8 DBXzW1GMvwel8zHUxx+B+0ygLC4DPcnJ0bcJ5/vQNYA470CY24Qa+DMTX3Jr0JWA7fItCClBnVDn iwBdgGbAY4CNgOWAPMBS6fiQdE4XfwY1ApaCvu5H9+M8/FduCfcKPwNad0CO5O3yOxXNij8rFyhf V12unq1+SjND84x2rU6l26/P1r9o6DImjSeFauGnpgHTA+arLE7LAWu19Te2LrvTvt+R4fiD87Cr 1vWQW+Xe4x51f+lJ88zwHPCk0iJprWmr0456Fd6f+R7x9wZ2BQuCH6TvC+3KqM/4MsyF7w8/ElkS ORz5p9iqbeiHSI4eRUpofQH6EJQ25ATPJqPWg8xS2ysQtPi8xvrGrvZ43eDqlYs3rhxV8zCLveKw 2olbgexl5HJGLmNkDyO7GdnFyKWM7GRkByPbGbmEkW2MbGXkYka2MLKZkU2MbGBkPSPrGFnLyBpG VjNyESOrGFnJyApGljOyjJGljCxhZIiRxYwMMjLAyCJGFjLSz8gCRuYzMo+RPkZ6GZnLyBxGehiZ zUg3I12MdDIyi5GZjMxgpIORdkbaGGllpIWRZkaaGGlkpIGRekbqGKllZDojSUZqGKlmZBojVYxU MlLBSDkjZYyUMlLCSDEjRYwUMlLASD4jeYwkGMllJIeRbEbijGQxEmMkk5EoIxFGwoxkMBJiJJ2R ICMBRvyM+BjxMpLGiIcRNyMuRpyMOBixM2JjxMqIhREzIyZGBEaMjBgY0TOiY0TLiIYRNSMqRpSM KBiRMyJjhGeEYwQzgiSCJxhJMTLOyBlGvmLkS0a+YORzRj5j5FNG/s3IJ4z8i5F/MvIxIx8x8g9G PmTkNCN/Z+RvjHzAyPuMvMfIu4z8lZG/MPJnRv7EyP8w8g4jbzPyR0beYuRNRv7AyO8Z+R0jv2Xk N4y8wcjrjLzGyKuM/JqRVxh5mZGXGPkVIy8ycoqRXzLyC0Z+zsgLjPyMkecZ+SkjP2HkJCM/ZuRH jDzHyAlGnmXkGUaeZuQpRp5k5AlGjjMyxsgxRo4ycoSRw4wcYmSUkRFGhhl5nJHHGPkhI48ycpCR Rxh5mJGHGHmQkQOM/ICRBxj5PiP3M3IfI/cycg8j32Pku4zczchdjNzJyB2MfIeRbzNyOyO3MbKf kVsZuYWRmxm5iZEbGfkWIzcwcj0j1zGyj5FrGbmGkasZuYqRKxlhYQ9mYQ9mYQ9mYQ9mYQ9mYQ9m YQ9mYQ9mYQ9mYQ9mYQ9mYQ9mYQ9mYQ9mYQ9mYQ9mYQ9mYQ/eyAiLfzCLfzCLfzCLfzCLfzCLfzCL fzCLfzCLfzCLfzCLfzCLfzCLfzCLfzCLfzCLfzCLfzCLfzCLfzCLfzCLfzCLfzCLfzCLfzCLfzCL fzCLfzCLfzCLfzCLfzCLfzCLfzALezALezALezCLdjCLdjCLdjCLdjCLdjCLdjCLdjCLdjCLdnDd IUIgah71VfshZh712UBcTlOXjfoqQOyhqd1U7Br16UBcSlM7qdhBxXYqLhn1TgexbdRbB2IrFRdT sYUe20xTm6jYSDM3jHpr/eS9WlGso2ItPWUNFaupuGg0rQHEKipWUrGCiuVULBtNqwexlKaWUDFE xWIqBqkYoGIRFQvpdf00tYCK+VTMo6KPil4q5lIxh4oeKmZT0U1FFxWdVMyiYiYVM6jooKKdijYq Wkc9LSBaqGge9bSCaKKicdTTBqJh1NMOop6KOipq6bHp9LokFTX0umoqplFRRc+spKKCXl5ORRkV pVSUUFFMb1ZERSG9SwEV+VTk0ZslqMil1+VQkU1FnIosKmJUZFIRpbeOUBGm98ygIkRFOr11kIoA vc5PhY8KLxVpVHiogHnpDBAuKpyj7pkgHFTYaaaNCivNtFBhpsJEjwlUGGmmgQo9FTp6TEuFhgo1 PaaiQkmFYtQ1C4R81NUJQkYFTzM5msJUIFHgCSpS4il4nKbOUPEVFV/SY1/Q1OdUfEbFp1T8e9Q5 G8Qno85uEP+iqX9S8TEVH9Fj/6CpD6k4TcXf6bG/UfEBzXyfiveoeJeKv9JT/kJTf6apP9HU/1Dx DhVv02N/pOItmvkmFX+g4vdU/I6e8lua+g0Vb4w65oJ4fdQxB8RrVLxKM39NxStUvEzFS/SUX1Hx Is08RcUvqfgFFT+np7xAxc9o5vNU/JSKn1Bxkoof0zN/RFPPUXGCimfpsWeoeJpmPkXFk1Q8QcVx Ksbomcdo6igVR6g4TMWhUXsNiNFR+3wQI1QMU/E4FY9R8UMqHqXiIBWPjNrBX+OH6V0eouJBeuwA FT+g4gEqvk/F/VTcR8W9VNxDb/Y9epfvUnE3PXYXFXdScQcV36EXfJumbqfiNir202O30rvcQsXN 9NhNVNxIxbeouIGK6+mZ19HUPiqupeIaKq6m4qpR2yCIK0dti0FcQcXeUdsyEJdTcdmorQfEnlEb OGO8e9RWAmIXFZfSy3fS63ZQsX3UtgTEJfTybVRspeJiKrZQsZmKTfTWG+nlG6hYP2obArGO3mwt PXMNFaupuIiKVVSspNetoGI5LdkyevlSKpbQM4eoWEzFIBUDVCyiYiGtdD8t2QIq5tNKz6O37qO/ qJeKubS4c+gv6qF3mU1FNxVdVHSOWpMgZo1ayW+YOWol5j1j1LoXRMeoNQdEOz2ljYrWUSvEBbiF ppqpaKKZjaPWXSAaRq1Xg6gfte4GUTdq3QOidtTcCGI6FUkqaqioHjXD+I6n0VTVqKkPRCUVFaMm YhrlVJSNmppAlI6aekGUjJrmgSimx4qoKBw1ZYMooGfmj5pIxfJGTaRvJqjIpZfn0N+QTUWc3iyL ihi9WSYVUSoiVIRHTURLGVSE6D3T6T2D9GYBehc/FT56nZeKNCo8VLipcI0K/SCco8JCEI5RYREI OxU2KqxUWKgw0wtM9AKBZhqpMFChp0JHz9TSMzU0U02FigolFQp6ppyeKaOZPBUcFZgKlJwwLvYT pIxD/nHjEv8Z4F8BvgR8AXmfQ95ngE8B/wZ8Avn/AvwTjn0M6Y8A/wB8CDgN+X8H/A2OfQDp9wHv Ad4F/NWw3P8Xwwr/nwF/AvwP4B3IexvkHwFvAd6E9B9A/h7wO8BvAb/RX+R/Q5/vfx3ka/rV/lf1 Ef+vAa8Af1kf978E+BXgRTh+CvJ+qV/j/wXwnwN/AfjP9Kv8z+tX+n+qX+H/iX65/yRc+2O4348A zwGSEyfg+1nAM4CndRv8T+k2+p/UbfI/odvsPw4YAxyD/KOAI3DsMBw7BHmjgBHAMOBx7SX+x7Tb /T/U7vQ/qr3Uf1C7y/8I4GHAQ4AHAQcAP9Dm+B8A+X3A/XDNfSDv1V7kvwf494B/F3A38LvgXnfC ve6Ae30H8r4NuB1wG2A/4FbALXDdzXC/mzQz/DdqZvq/pVnuv0HzA//1mgf9V/Jh/xV8mX8vLvNf 3rOn57KDe3p291zas+vgpT3aS7H2Us+lbZfuuPTgpb+/NNmh0Ozs2d6z4+D2nkt6tvZsO7i15+KD W3pkW6xbNm/hP9mCD27B9Vtw3hbMoS3ClsAWXre5Z2PPpoMbe9DGWRv3bBzeKKsc3vj2Rg5txBqy obvR42skm587N+qFxg0963rWH1zXs3bZmp5VUKyVZct7Vhxc3rOsbEnP0oNLeobKFvcMlg30LCrr 71l4sL9nQdm8nvkH5/X0lfX2zIXz55TN7uk5OLunu6yzp+tgZ8/Mshk9MyC/o6ytp/1gW09rWXNP y8Hmnqayxp4GqDJKE9ICabxACjAjDUqCPLg2z5P0vO35yCNDnmHPCQ9vNrr9bi5mdOG6mS68zrXb daOLNzp/5eSSzlh2o9HxK8cfHf9wyCxJRyy3EdkFe8DOi5vV9o7ZjaKsqacyv1isa4c9FGk02rDR 5rdxDX4bRqa3TR+ZeNuzwq8EzmjERuOEkUsa4XSjwW/gyNeEgU8a8ksbjXq/niNfE3rentRDDrlj VDdrdqNR69dyPTXamVouqa2pa0xqc/IaEY8DGCMsgOBV5CFRbPM38k+J/22xHGF808js7ni8bUyF utqGVbPmD+NrhsPd5DvZOW9Ycc0w6pk3v3cE42/1jWCubvawlfxnb2L6yhtuQN7atmFvd+8of++9 3tq+tuE9hCeTIp8gHMEpffGFm7Zsisc3L4SvhZs2x8UfSOEtJBUnmeRn02ZIk39bxPTkI6UX/tDT QCzaBJ/NUt7m+P+vPzj+fz//y88IIv9H4fQJ7gq0hNsLuBxwGWAPYDdgF+BSwE7ADsB2wCWAbYCt gIsBWwCbAZsAGwDrAesAawFrAKsBFwFWAVYCVgCWA5YBlgKWAIYAiwGDgAHAIsBCQD9gAWA+YB6g D9ALmAuYA+gBzAZ0A7oAnYBZgJmAGYAOQDugDdAKaAE0A5oAjYAGQD2gDlALmA5IAmoA1YBpgCpA JaACUA4oA5QCSgDFgCJAIaAAkA/IAyQAuYAcQDYgDsgCxACZgCggAggDMgAhQDogCAgA/AAfwAtI A3gAboAL4AQ4AHaADWAFWABmgAkgAIwAA0AP0AG0AA1ADVABlAAFQA6QTZ+Abx7AATAAoSUY8nAK MA44A/gK8CXgC8DngM8AnwL+DfgE8C/APwEfAz4C/APwIeA04O+AvwE+ALwPeA/wLuCvgL8A/gz4 E+B/AO8A3gb8EfAW4E3AHwC/B/wO8FvAbwBvAF4HvAZ4FfBrwCuAlwEvAX4FeBFwCvBLwC8APwe8 APgZ4HnATwE/AZwE/BjwI8BzgBOAZwHPAJ4GPAV4EvAE4DhgDHAMcBRwBHAYcAgwChgBDAMeBzwG +CHgUcBBwCOAhwEPAR4EHAD8APAA4PuA+wH3Ae4F3AP4HuC7gLsBdwHuBNwB+A7g24DbAbcB9gNu BdwCuBlwE+BGwLcANwCuB1wH2Ae4FnAN4GrAVYAr0ZLpezD0fwz9H0P/x9D/MfR/DP0fQ//H0P8x 9H8M/R9D/8fQ/zH0fwz9H0P/x9D/MfR/DP0fbwSAD8DgAzD4AAw+AIMPwOADMPgADD4Agw/A4AMw +AAMPgCDD8DgAzD4AAw+AIMPwOADMPgADD4Agw/A4AMw+AAMPgCDD8DgAzD4AAw+AIMPwOADMPgA DD4AQ//H0P8x9H8MfR9D38fQ9zH0fQx9H0Pfx9D3MfR9DH0fQ9//vyPB/+rT939V8L/6OBctRP8P VkDTCgplbmRzdHJlYW0KZW5kb2JqCjExOSAwIG9iagoxOTA5MgplbmRvYmoKMTIwIDAgb2JqCjw8 IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvQXNjZW50IDc1MCAvQ2FwSGVpZ2h0IDY0OCAvRGVzY2Vu dCAtMjUwIC9GbGFncwo0IC9Gb250QkJveCBbIC00NzcgLTE5NCAxMjE0IDk1MyBdIC9Gb250TmFt ZSAvWkZERlJMK0NhbGlicmkgL0l0YWxpY0FuZ2xlCjAgL1N0ZW1WIDAgL0xlYWRpbmcgMjIxIC9N YXhXaWR0aCAxMjg4IC9YSGVpZ2h0IDUwMCAvRm9udEZpbGUyIDExOCAwIFIKPj4KZW5kb2JqCjEy MSAwIG9iagpbIDI1MiAzOTEgNTI1IDQ5OCAyMjYgNzE1IDIyOSAzMzUgNTI1IDUxNyA1MjcgMzQ5 IDMwNiA1NDMgNDIzIDUyNSA2MTUKNDc5IDQ1MiA0ODcgMjI5IDg5NCA3OTkgMzA1IDI1MiA1MDcg NDg4IDQ1OSA1MDcgNTA3IDQ1OSA1MjUgNDUzIDI2OAo1MjUgNDcxIDMwMyA2NDYgNTc5IDMwMyA1 MjUgNTA3IDYzMSA0MTggNDE4IDI1MCA1MzMgNTA3IDUwNyA0NTUgMjUwCjUyNSA1MDcgMzg2IDQy MCA1MDcgNDk4IDg5MCA0NjMgNDMzIDQ5OCA2MjMgNDk4IDQ4NyA2ODIgNTA3IDg1NSA2NjIKNTQ0 IDM5NSA1MDcgMjM5IF0KZW5kb2JqCjEyMiAwIG9iago8PCAvTGVuZ3RoIDEyMyAwIFIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjaXZDNasUgEIX3PsUsbxcXTRalCxHKLRey6A9N+wBG xyA0oxizyNtXbXoLXczAzDmfHIdfhqeBfAb+loIZMYPzZBOuYUsGYcLZE+t6sN7kY2rdLDoyXuBx XzMuA7kAUjIA/l7kNacdTo82THhXd6/JYvI0w+nzMrbNuMX4hQtSBsGUAouuPPes44teEHhDz4Mt us/7uVB/jo89IvRt7n4imWBxjdpg0jQjk0Ioeb0qhmT/SQcwucPZd0rePyjphOia/1epaP3iLZLZ Uipp2h1ajBrAE95OFUOsVKtvghpwUgplbmRzdHJlYW0KZW5kb2JqCjEyMyAwIG9iagoyMjUKZW5k b2JqCjExIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQg L1pGREZSTCtDYWxpYnJpIC9Gb250RGVzY3JpcHRvcgoxMjAgMCBSIC9XaWR0aHMgMTIxIDAgUiAv Rmlyc3RDaGFyIDMzIC9MYXN0Q2hhciAxMDQgL1RvVW5pY29kZSAxMjIgMCBSCj4+CmVuZG9iagox MjQgMCBvYmoKPDwgL0xlbmd0aCAxMjUgMCBSIC9MZW5ndGgxIDEyODkyIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+CnN0cmVhbQp42u2aeVxc1fXA73tv9n2fgQFmhoEJMOzbDAmEF5iZsIQAgUlmsrIm ZIWQYBaNUrdY4h6trXWtrUtxeTyjEmvVWtRuMWpt2l9bNVartS3V2vqr0QZ+570zQwJt/flb/vp9 fhPOfO8599z77j333PveCxCKEKImo4Qhxb07u4fIGnINWJ4CKe+9YK/72K0vHYfyh4RIdZuHtuy8 +/d1DxIiA5PSvGXHgc1PH7likBC9hRAjO9Df3feX1SdnCXF3gkPlABj0Dbpa0K8GPWtg5979wceZ 34POgc7uGOzt9h3LfAd06J9k7uzeP6S6kHqMEA/0R9y7unf2X/Z0xfugl4O+aGi4f6j/o6ks0NcT YjgLNooI4ydEA0PKAXqIHso6mI2eSIiUKMBOEy2RwxxV4KskRH4HITNHyfmfNrKN7IEYjJIrYfZH yTPkV6SHXAalr5G7yL3kAcKR75Efkp+T/8XPzAHpTqJhnoARmgmZ/XR2euZekEmp7jzLUdDMEvc5 y6xh9k8LbH+aOTprmJmUmYhKbKulXwXrX6izs5/StYI+Wyno9GEo68UWf5bfMfPIzH3zhtNEVpBO EiWrIQPipJWsBGkj7aSFbCCbSDfpJX2kn2wmW8gA2Qrx2k52kJ1kF8hmMkiGyG4yDDHcS0bIBVDe m7Cgvp8cIAfJoQQvJBdB+QB8HxRLF5NLIPJfmuOlczxnuYxcAXI5fF9JDpOryJeBwvd823xtjBwh V8N6Xkuumytf90+tQvl6cjPIDeRGWPWboPxVWPtbydfJbaL1KPkKuUXU7iTfgPqvzPMV6s75307u AK+7yN3geQ9kz30LfAXPO2GHfRdy6gXyNGTbM1B6jhyH8nPkTXKavEPeI78j71N+qpJaTj4ifyUn IfqbIepCzIfE763wvWUu4vsgtsnIXgwRmx+HCxJ1GM9LxTgl6/aB52FYjUvPazMmrlOyL8E72df5 8RLmJMzonA1neHTOcm7e81uh3/kxmx/BW0XL/NqFkT2/fPe/rLmHfAvkm/AtrMNCLVm6H3a4IN8m 4+RBKOH3OT1Zeog8TB6Bs2CCPEoeI4+TJ8jknH4MtHP1vGhJ+vxz+5PkO2IWPEOeFdf/+2RKtD0D peOJ2mcSNU+K5efIi3AK/Zj8hJwgz0PuvCjKj8lLkB+vkFfh1Po1eSORQafEDPJSfvIyeUXiI7+Q 6igp8yx5jl5J9oP+c/prsBKEjWzauGH9urXxWLSzY1V7W+vKlhXNTY0NyyPhUH3dMrZ2aU31ksVV wUBlRVFhQX6OLzvLm+lyWIwGvVatUirkMqmEoSmSH/ZGutycr4uT+LwNDQWC7u0GQ/d5hi7ODabI fB/O3SW6ued7suC5eYEni57snCdlcFeT6oJ8d9jr5k6EvO5Jam17DMrXhLxxNzctllvEssQnKlpQ PB5o4Q47BkJujupyh7nIBQNj4a4Q9DehVtV76/tVBflkQqWGohpKXI53aILKWUqJBTonvHiCJgqt cFmOyQ5393Ft7bFwyOnxxEUbqRf74mT1nFzsy71VGDM54p7If3bs6kkD6enya/q8fd3rYxzTDY3G mPDY2GHO6OdyvSEu9+A7DphyP5fvDYU5vxc6a141dwGKk2YbvO6xjwkM3jv9x/mW7oRFlm34mAhF YYpzYYL6ZJnA2GCEMD+PRxjLkUmW9IDCjbbHUHeTHidP2CJ/nKO7hJpnkzXWqFAzmqyZa97l9QhL Fe5K/Fww4OBGe9wF+RB98ScbfqDezTG+rp7eAYHd/WPeUAjj1hnj2BAU2O7EXMMTxUXg390Fk9gq hKE9xhV5hziLtw4dwOAW1mBrR0xskmjGWeo50tWbaMUVhUPCuNzhsa4QDlDoy9seO07KZk9PlLud j5aRchIXxsHZ6mFRfOGxWN9mztXl7IP83OyOOT0cG4fwxb2x/riwSl4Dl3saLucRryi2grkt8E46 CzOXZyvcMdrJxIXVAoM7Al/eumqoMMByiaqwonXV7hjlJEk3uErCQyjN6wcUJru+QahihKb1DU5P 3IOfzxmSMzEmaTanOK8vAxjmxoTX+ZdDQ29hQLnucH/ovAHO61SaGGCit38+TlqIReLC0EIhLGdD sorJhp0LNhq6EU3CKjrg8bHNHfP2e+NeyCG2LSbMTYi1uL7NHd7m9rUxcbUTWdI5T8P6IGoc8UB1 UqHrIQcjfmdyWUV9uajPqQ0LqhuT1e4xhbe5Y0zo3JvokLhhB8GkZb7G7iNBUzlszQicbt5It9dt cEfGuidnR3vGJlh2bCjcNbBY6MPb2Dfm7YhVO8Wxroodch4ULmUizVRzZ11BPpw9dRNe6qr2CZa6 qmNt7LgBHpWv6ozxNEXXd9XFJ7KgLnbcDWe7aKUFq2AUFLegCD2tAkUh+juPs4SMirUS0SDqvZMU EW2KpI0ivZM02gxJGw02CdpY0SZ8YJEcAxBiOG7D7j5heS6KD4x1xYXNRWywlPBDcZR3KeFo79IJ ipZpOJW3v45Te+sEe61gr0W7TLDLITEoGwXBEc6ksS4vnFOQUDHipDAVGaFL9+TsbGfMc8I5HfdA qq0HWRvjlH44+6XZTeC3XJAuMC/nRnu7hXGQaExoK89u7I1D2iY7BJdGTgk9KBM9gEdEbCOkIzTq hbWBBRTbj4LCjca5uF+4aGxrXExnA0cavIth2bFPqU+4UFF8zOQtFfcmbAVV9mEBShgb6YihxQkq XCyOQZJrYOS9Xqjq7XJDtCWktwNSHc9SlRMt/XAkSnz9oqiciUoiTIvJVmtVnLIQOoQfoawuFLak NFsej+PgRe1wwgGubeDUMCLfeaFMNIDoQFWjMBb4OQxDFVy/J3TTPklWeffDySIMWuxJDtWcNrux Gw5/bK8GizeYbKwQzgh1oo8ptMqFmWsg7kx25+Tsfd4DnvM+Bfle4eYgJCZxwusoS+JjCw3cOn9B vmKhVSuax8YU2n/eAOOl0M4RjPCqC29ne5hfSoX3SDlZIr4VtT5WYCuwKaqXqahp0kjkVB9kv5u6 Gl4xKaqPNUno7ICMaXdqjUPtVHtITneS2tffeH3DG6+fAJ6gil6fPjVtOHtq2lRVVVRUUkwZPUZR LDpaLpfJvJmFdCBQWVlWVrqUrigvpL2ZOhBfRflSOrCUKSvNoEVX9BSt4CxYmV/+fR3TelZGX+gK 71qZRbucOotGSrmlLruiprXQrPdU5OSwRS65SkZLFTJF7uJQZmjj4tSZxxi5Wq5y22ypOqlErlEo 3SnmFJ1kJiLVffqRVPdZvWTHZzcxJeVbVlVKv6pS0BKZ7CmnPXtJxJPid5v1ZoNGJzXbTDK52aT2 1TSdPaKwp9rlKpVcY1ApHQ6bQqmSaQxngxCo9tlp5i3mR8QH0bzmSfoSepTE/LDF66OxR5XpioxJ 6pFjvkW+JYpJ6uEniN5HmRlfySSdwdrNRLlkUbpPxnga886kNlV+wupamBU5fkdtbWrLdO10rcle RRVNvwaPsa9PlxnLDNPGqqqSYidr+wINS4rj2cnQ65hEYCVlpTZ7Irhyuc8HCyGxWjJoYWECTL4k K8+SaoButaENw0vati61W4uat10dj19Sapb4cixOg4T6adHOUOWa+hKXXu2q9AcGu5pMKUadRK5W ftu9gs0Lrt9bE7z2pqsH6xtq1xl0jEIj/2M4XNa5fXhXvjdc5a3ZcWNMeCenSQ3E7WXpblJA6sht 8+PGmtTG9AyX2xsIVqVVpZmqjCYiRCyt0KiqCmZK5GVnFjWlmYxqic4e0a2o/oSVtwizFyYvzL12 Wozca9NFRiFshw7rpvBjosT4pX7xXiCMkJsSyNZFYn76AhRmrJzRMXKxKJEnUlout9kgkhLmZVtJ 0/Yja9aOlproRTl5aRJKRSutnhRHhklCtUl1er3MEN6wK1i9ujrbonhIlR4orBzqajZ6inaEyjtD pR4jfXn1DUePbF8WYmNGnUEvDSo0CokEvmZ2pQYDJSZvc22euyLUsDzfGanOXbrz6Jp7w3XFbVt2 D4uxhZyUVEl3knxSSw4viK3KU1CbCRXKzIAQ01RrZj6zKAJGpYLIdMVn0poWL8wnIRiwtyEXp6qK ykrFeApxTPnCTf8hGyWYjRm03ZyIJ5VMRxtmYwGTlWdNNUhpt5iNS9YsybbKbcXN247E/CuWlls3 UyqLO8XhMknpmVOQlBXRUInbUNd4fkre72muzXWVhxubXIuvv+HI9jqzpzCFmpFr5VIpfJ3tCTeU rNq2e1dh95bqbTeuEWPXAnl5O+znQlK9MHaP55UGZBKinKR1rNJr1GQwFou3aJLWslbilT0dCORl GI2a0lfymjRvshlzyQTbtshoqiqaFlISaK+CnWwXM9H8BVphCtJer0yWCA7sYqtwYJ6/ryGC5T4x CwUP5nb2qtdu2iaX9g6ym5uLlUqlRKFVaGo6+0rjV8bzUypX77utp3OkOfOBtqZlfS0B4+at10S9 9G/hlM3zLHX2bTPbzFqNKi09VamxmzU5HRd1Lrv5xis3L82raw+U1Ras6A+mFlSL8aqbOSqef9Wk nRxbkGvasvLq6pr2tvS0mrSa5UK6+dS5JK28mqRJpIFGV3tNmSSLPVPclKP82GSyr/gkq8X+Fitt nYsBzJ9M+xNpJOzpsqKp6anEjjZSZSY8EDP/2z1CcKVCGOGE9iUDKeZfZeUXPTbTDct33dLV8eVc vZqSytUGpSarOr6scs2yXJUxU22IrN9V1TxQm4ap+w9H6er6Upce7mM+MW8L2/a35njsKrNeZrM5 zGprqs2WHypat9+T3Vy7qHTNvvBiOBd21p1/uJZ27Ng9WOBvKMuo2XEUc7h29lPqA2kRMZNcsm3+ mhzLdVky4DTtYdUqV0aGxZUryUrRT1LLH5eyWY0pia37Rsu0UYz3qdemhTMUgvzEf+IrpClGLHlP T2hzG/x9qTEtLyPdZ6KlMpMTStlmeuZvtMricaS4jFL6UdjRcEhCkZL8JM1nV6nsvrS07BSlMiX7 sxKFWjgB1QrmcjmehXIi/i+5MNc/w33ESpYvyD6DlahZFVFZ1RKpISLF4YqzSj1RVirkjfofK2Ea iYWfO+nfPTfE5EHuMkqolOSIzp3OifFI34P9sI7ct2A8VaGCgsIquy3TszJzHVkHF4dnAVUwU93R ZMw5wzY2BQth6YmtQJ25bmWoSle2tLFsRdqKxNjwnpTacnaqlioqKpqCpwJjWSmcEFOAF6AkLBLr +a/2JZzMyYWqrKxInCHM55gSUcGbH21HWC0yuXQLpbJ6HBAcGT0olZfUlG7vajK20Wg0yKhBubS0 umwbGpMhfYxSmtMtVqdeQmXqw+t3VlWvDqQylsj6HcH6tUGHQj4XZzo/vTyVXVGz/ejqmV3njBmL U2oa5xuZKyBHGGF/PJgJDyWeqtYi74raPF9drNwbyprLG4aDdVpMLlywTr6S1FSnT6JjiJ6yMHpd tvUMW9mU7dRJUvUlPoXb3+heoUwEEuMIJ/uUsCCwCHMrYfvPW4knu+y/EGyGU8h3Qwa6cZdAPMtr KgY3Nf/LeIY27q4Rokifgnmffelc0FyLbTXNnxu03PqYeJashPvhKxAnOykisfmRgrcN2sUqicPg oM2MI0s44NWa9I/NTblvn/cwNZ14iJ0WwqL6x+q5Z6zz72XiI1XylJUwr6RVxfbdsqHry7E85+I1 Yime97C1pDVY3dNSlW2ylawM1nQLJXpP063XXbwxUBgbbW+69dpLNgaKYqNrS9sCGf7GnsGRYGlb MMPf1DO0V/id2ew0/QeYW4Q8NH9mT8HSn4UH+nK40/ttS+Af8erLWWf4ZI5bWixlpYxUdZJtcp/J IXmGPFrD5BW9wToTUzr7GoHZ+qdroQAwio9OU8K7kWHaIAYh63/SV/J5IBOfOiFEEmtCX3ATg3ct 4TmLFvepjf6DTK1XajzF9YX5oUJHRduG1orAlhvXFnXUF2sVclomvt9kBlbVBFrLU8pb17dWlG+6 ot23vDpfrWZ2qDxum9lhSfEHMnIq8nKXdNRGDqwp0dmcGoVRo7A5bCa10+V0FlR78ir8eVUdbN3u jkKNyaZW4X7bPfsB/bzkIRImYwv2W25lvj/gr1MolymXBZR+f3HAHrCT4rqGwLJqRf7bSr+nskH/ CeuZyxgIwnTpiaoqOAhPCGGFFwR8zp+aMhzGR1PzF2idzDsv86+frGALJt5Uy8oCyc0IXvTztEyl 1inf7ZfI/MXOnHSbQqGUwt5RuPOK7MFVQSctlTL9h9QamcasvdhPqS3iySil/O/qVcxRpdVmM6pm VNZyY1mRUqVU67WuDIdcrlPLHGUtlZp0t1tHfao167LdtlNyjVIiUWrkp2wQxyHYj79hnoLnrZEF ccxUO0hJdWmJNyvFQdSOrJIUb3WpEp6KMhrzP2ENLdJzz+V4G4S74NQUHFdG8SHK/gXanHe3mHs8 qpw7pcQ4Jh6L5mz5lMqUbrU49VLaA289g1WhDVUpSvlg4rYAEdklk6mdflfFYFezqZVSJ80pEE2J 8PL+QGYzm5O9LF7hCXvp8uQhdfbV1GB6RkmWpWbHzTHq2qRZzLUG6hhdRdfAM4H9MaI2va3ISYbK LzyFnygpFhfek4nbxQPrWUXJFGpYkQ1aDQ3rCM9y9+jUdJrMYrdbNCaT1GyHxzGT+Dt5SurqeOGR 6U366o9JikL8FfOLbnb2HGf2SN+DJxKaKEHwQwl/WTBDqCnVyr+XnH1L+biCULfO+y21QaIDt5OE SNJJO0iNQOZV0gKso06RWkFknaQW9FqJk6xk0omSfpjsBn2I3kMaoI/7yf1UiPqIvp7JYT6SDEg4 6eUyh+xKebX8tGJYcReOgxjIa0RKOCKH0RngVO8iRPn+7CyR4OyIKfGXBzKIH4nEVreEQv767h1b e4a35jfuhUIvmVAyk/RBPmOpa5I+gNjPZ6gB+xAX8BmLASOIveiyh89YAhjmM6oBuxFDiEE+owaw C7ETG+xAbOfTlwG2Ibby6XWAAT69HrAFsRnRj+hD9GKDHmzQjejCuk2IjXxaGLABsR6xDrEWEUfE EGsQqxFRRCdiFaId0YZoRazk00KAFtRWIJoRTYhGRANiOSKCCCNCvLMRUM87mwB1iGUIlnc2A2oR S3nnCkANohqxBLEY0YGowj6DiAB2VomoQJRjn2WIUmxXgihGFCEKEQXYWT4292O7PKzLReQgFqGn D5GNDbIQXmyXiZ4ehBvhQmQg0vnUlYA0hJNPbQWkIlIQDqyzI2xotCIsCDPWmRBGNBpQ0yN0aNQi NAg1QoVQ8iltAAWf0g6QI2QIKUKCLgxqNIJCEBHULGIGcVZsQP0dtc8QnyLOID5B/A3x77yjA/Ax 4q+8oxPwF8RHiD8jPkSXDxB/QuM04o+IPyB+jy7vI36HeA/r3kX8FvEO4m10+Q3iLTSeRryJeAPx Om9fDfg14le8fQ3gl4h/Q+MvED9H4ynEzxCvIX6KLq+i9gpqLyNOovElxAnETxA/RvwIPX+I+AEa X0S8gHgeMcXb4Fyivs/bagHPIb7H29YBnkU8g3ga8V3EU4jvIJ7EdscRk2h8AvE44jHEMcSjCB4x ge04HMsjqD2MeAhdHkSMI76NeABxP7a7Dxvci8ZvIb6JuAfxDcTdiLsQdyLu4K09gNsRt/HWXsDX eWsf4Fbe2g/4Gm/dDPgq4hbEVxA3I25CHEXcyFu7ATdgn9djn9dhn9cirsGur8YGRxBj6PlldLmK t0YBh7GzK7GzKxCXo+dl2Mul2PxLiFHEJYiLEYcQFyEuRBzkrXAmUwfwCvux632IC/AKIziWvYg9 eL1hbL4bMYQYROxC7ETsQGzHqWzD621FDPDWSsAWxGbecimgn7cIudvHWy4B9PIWoV0PGrt5Cwvo QuMmNG7kLRcDNvCWywDrecsVgHW8GW7C1FrenAGII2K8WQVYg1jNm+E2T0V5M9zfqU5EB2IVb4bb PNXOm+HGTrUhWnmTMOqVvCkCaEGsQGMzogmNjYgGxHLeBPdNKoIuYTSGEPW8cTmgjjcKm3IZb4wB WN4YB9TyxrWApYga3ihkazViCWIxooo3+gFB3pgPCPDGKkAlooI3ChcqxwuVIUp5oxDBEkQxbxQC WYQoxLEUIPJxSH4cUh4iF4eUg1iEg/AhshFZCC82yERPDw7JjYNw4fUyEOnomYZwYvNURArCgZ52 hA0HaEVYcJxmvJAJYcR2BoQeoUNo0UWDmpo3bACoeMNGgJI3bAIoEHKEDCFFTwl6MmikERSCsLPA WfCbAZ4F+TvIZyCfgu0MNPwEyn8D+XeQj0H+qu9x/QXkI32v68/6PteHIB+A/AlkGux/BPkD1P0e 9PdBfgfyHsi7YP8tyDtQfhv4G5C3wO806G+CvAHyOsivQX4F8kvdFte/6QZcvwD5OcgpkJ+B7TXg T0FeBXkF9JeBJ0FeAjkB8hOQH4P8COSHID/Qbne9qN3hekGb53oeOKXNd30fbM9B+XvanS529lnt Ntcz2q2up7UDru9CzVPaEtd3QJ4EOa7Z7ZrUDLue0OxxPa7Z63oM5BjIo6DzwAnw4UAeAXkY5CGQ B0HGQb4N8oD6Ytf96oOu+9QHXPcCv6W+yPVN9SHXPWD/BsjdIHeB3AlyB8jtILeBfB3kVnWB62sg X1Xd57pF9S3XV4A3g9wEchTkRtWA6wbVpa7rVV93Xae63XWt6k7XNWC/GuQKJtt1ORN0XUYFXZdG R6NfGh+NXhI9FL14/FBUfYhSH3Ieaj504aHxQ786xLbIVBdFD0YvHD8YPRDdF90/vi96wfhIVDJi Gdk7wvx1hBofoUIjVPEIRZMRw4h7hNHsjQ5H94wPR8lw2/DoMDcsWcINnx6myTClmpx99tFhZ0YE yF40rDVEdkcHo0Pjg9Fdm3dGt8Gwtga3RAfGt0Q3B/ui/eN90d5gT7Q72BXdFNwQ3Ti+Ibo+uDa6 bnxtNB6MRdeA/+pgZzQ63hntCLZHV423R1uDK6Mrwd4SbI6uGG+ONgUboo3jDdHlwUg0DFMmaYY0 dxpjEAawMg1GQpxUHbxxO087P3RKiJNzPutkTPpUVyqdq0+h6ltTqMGUS1KuS2H0jpMOmnXk5kf0 9pP2N+0f2CVm1p5bGCE2g81tY6zC3GwtnRGRtSFkSYU41xab1xfRWym91WWlwy4rRYynjR8aGesz hpMGWq+n9PpZPc3qwV2vc+lo4WtWx7C6kkBEr3VpaeFrVsvYWC1YhB4Xado6I3q1S01Ha9WtappV 19ZHWHVBcYQwlJuiCGUAMArwPUZZXRHmKfGv2KWEoq6f6Ozw+5sn5bOrmjll2zqOuorL7hC+2fa1 nOwqjkTXrotNUNS1ceG/Mzo5i/DHRqJ+xTXXkPS6Zi69I8Yzd92VXhdv5kaFMsuK5VmhTMAl7t+4 Z2SP3793I3xt3LPXL/6ARo0Iml8wCj979oIu/BsRdeL/3A+6ATbtgc/ehG2v///mh/L//+fzPo5N Gwkh/wHt+iw1CmVuZHN0cmVhbQplbmRvYmoKMTI1IDAgb2JqCjcxMTcKZW5kb2JqCjEyNiAwIG9i ago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0FzY2VudCA3NTAgL0NhcEhlaWdodCA2NjcgL0Rl c2NlbnQgLTI1MCAvRmxhZ3MKNjkgL0ZvbnRCQm94IFsgLTQ3NyAtMTk0IDEyMTQgOTUzIF0gL0Zv bnROYW1lIC9GWFZNREQrQ2FsaWJyaSxJdGFsaWMKL0l0YWxpY0FuZ2xlIDE1IC9TdGVtViAwIC9M ZWFkaW5nIDIyMSAvTWF4V2lkdGggMTI4OCAvWEhlaWdodCA1MDAgL0ZvbnRGaWxlMgoxMjQgMCBS ID4+CmVuZG9iagoxMjcgMCBvYmoKWyAzODkgNTE0IDUxNCAzMDYgNTE0IDQ3OCAyMjkgNTE0IDUx NCAzMzUgMjI5IDUxMyA1MTQgMjI2IDc5MSBdCmVuZG9iagoxMjggMCBvYmoKPDwgL0xlbmd0aCAx MjkgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42l2QwWrEIBCG7z7FHHcPiyZn EcqWhRzaLk37AEbHIDSjGHPI21dtuoUeZmDm/z/5HX4dngfyGfg9BTNiBufJJlzDlgzChLMn1vVg vcnH1LpZdGS8wOO+ZlwGcgGkZAD8vchrTjucnmyY8Fx3b8li8jTD6fM6ts24xfiFC1IGwZQCi648 96Ljq14QeEMvgy26z/ulUH+Ojz0i9G3ufiKZYHGN2mDSNCOTQih5uymGZP9JBzC5w9l3SvZOSSdE 1/y/SkXrFx+RzJZSSdPu0GLUAJ7wcaoYYqVafQOPinB8CmVuZHN0cmVhbQplbmRvYmoKMTI5IDAg b2JqCjIyMwplbmRvYmoKODMgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBl IC9CYXNlRm9udCAvRlhWTUREK0NhbGlicmksSXRhbGljCi9Gb250RGVzY3JpcHRvciAxMjYgMCBS IC9XaWR0aHMgMTI3IDAgUiAvRmlyc3RDaGFyIDMzIC9MYXN0Q2hhciA0NwovVG9Vbmljb2RlIDEy OCAwIFIgPj4KZW5kb2JqCjEzMCAwIG9iago8PCAvQXV0aG9yIChkd2luZykgL0NyZWF0b3IgKFBT Y3JpcHQ1LmRsbCBWZXJzaW9uIDUuMi4yKSAvQ3JlYXRpb25EYXRlCihEOjIwMDkxMTExMTkyMjU1 KzA5JzAwJykgL01vZERhdGUgKEQ6MjAwOTExMTExOTIyNTUrMDknMDAnKSAvUHJvZHVjZXIKKE1h YyBPUyBYIDEwLjQuMTEgUXVhcnR6IFBERkNvbnRleHQpID4+CmVuZG9iagp4cmVmCjAgMTMxCjAw MDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAwMDE1NyAwMDAwMCBuIAowMDAwMDAwMDIyIDAwMDAwIG4g CjAwMDAwMDAyNjEgMDAwMDAgbiAKMDAwMDAwMDEzOSAwMDAwMCBuIAowMDAwMDAwMzI2IDAwMDAw IG4gCjAwMDAwMDEzNzkgMDAwMDAgbiAKMDAwMDA0NzQ5NCAwMDAwMCBuIAowMDAwMDAxMzYwIDAw MDAwIG4gCjAwMDAwMDIzODIgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDgwMDMy IDAwMDAwIG4gCjAwMDAwMDE1MDcgMDAwMDAgbiAKMDAwMDAwMTU1MyAwMDAwMCBuIAowMDAwMDAy MzYyIDAwMDAwIG4gCjAwMDAwMDI1NTYgMDAwMDAgbiAKMDAwMDAwMjQxOCAwMDAwMCBuIAowMDAw MDAyNjYzIDAwMDAwIG4gCjAwMDAwMDI1MzcgMDAwMDAgbiAKMDAwMDAwMjczMCAwMDAwMCBuIAow MDAwMDA1NTg0IDAwMDAwIG4gCjAwMDAwMDU1NjMgMDAwMDAgbiAKMDAwMDA1OTc3NSAwMDAwMCBu IAowMDAwMDA1ODY0IDAwMDAwIG4gCjAwMDAwMDU3MjYgMDAwMDAgbiAKMDAwMDAwNTk3MSAwMDAw MCBuIAowMDAwMDA1ODQ1IDAwMDAwIG4gCjAwMDAwMDYwMzggMDAwMDAgbiAKMDAwMDAwOTYzMSAw MDAwMCBuIAowMDAwMDA5NjEwIDAwMDAwIG4gCjAwMDAwMDk5MTEgMDAwMDAgbiAKMDAwMDAwOTc3 MyAwMDAwMCBuIAowMDAwMDEwMDE4IDAwMDAwIG4gCjAwMDAwMDk4OTIgMDAwMDAgbiAKMDAwMDAx MDA4NSAwMDAwMCBuIAowMDAwMDE0OTQ4IDAwMDAwIG4gCjAwMDAwMTQ5MjcgMDAwMDAgbiAKMDAw MDAxNTIyOCAwMDAwMCBuIAowMDAwMDE1MDkwIDAwMDAwIG4gCjAwMDAwMTUzMzUgMDAwMDAgbiAK MDAwMDAxNTIwOSAwMDAwMCBuIAowMDAwMDE1NDAyIDAwMDAwIG4gCjAwMDAwMTg3MzAgMDAwMDAg biAKMDAwMDAxODcwOSAwMDAwMCBuIAowMDAwMDE5MDEwIDAwMDAwIG4gCjAwMDAwMTg4NzIgMDAw MDAgbiAKMDAwMDAxOTExNyAwMDAwMCBuIAowMDAwMDE4OTkxIDAwMDAwIG4gCjAwMDAwMTkxODQg MDAwMDAgbiAKMDAwMDAyMzQzMCAwMDAwMCBuIAowMDAwMDIzNDA5IDAwMDAwIG4gCjAwMDAwMjM3 MTAgMDAwMDAgbiAKMDAwMDAyMzU3MiAwMDAwMCBuIAowMDAwMDIzODE4IDAwMDAwIG4gCjAwMDAw MjM2OTEgMDAwMDAgbiAKMDAwMDAyMzg4NSAwMDAwMCBuIAowMDAwMDI3NDc1IDAwMDAwIG4gCjAw MDAwNDc2MDQgMDAwMDAgbiAKMDAwMDAyNzQ1NCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4g CjAwMDAwNTYzMDMgMDAwMDAgbiAKMDAwMDAyNzc2OCAwMDAwMCBuIAowMDAwMDI3NjMwIDAwMDAw IG4gCjAwMDAwMjc4NzYgMDAwMDAgbiAKMDAwMDAyNzc0OSAwMDAwMCBuIAowMDAwMDI3OTQzIDAw MDAwIG4gCjAwMDAwMzA5NzYgMDAwMDAgbiAKMDAwMDAzMDk1NSAwMDAwMCBuIAowMDAwMDMxMjU2 IDAwMDAwIG4gCjAwMDAwMzExMTggMDAwMDAgbiAKMDAwMDAzMTM2NCAwMDAwMCBuIAowMDAwMDMx MjM3IDAwMDAwIG4gCjAwMDAwMzE0MzEgMDAwMDAgbiAKMDAwMDAzMzg1MiAwMDAwMCBuIAowMDAw MDMzODMxIDAwMDAwIG4gCjAwMDAwMzQxMzMgMDAwMDAgbiAKMDAwMDAzMzk5NCAwMDAwMCBuIAow MDAwMDM0MjQxIDAwMDAwIG4gCjAwMDAwMzQxMTQgMDAwMDAgbiAKMDAwMDAzNDMwOSAwMDAwMCBu IAowMDAwMDM3MzQxIDAwMDAwIG4gCjAwMDAwMzczMjAgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAw MCBuIAowMDAwMDg4MDgwIDAwMDAwIG4gCjAwMDAwMzc2MzUgMDAwMDAgbiAKMDAwMDAzNzQ5NiAw MDAwMCBuIAowMDAwMDM3NzQzIDAwMDAwIG4gCjAwMDAwMzc2MTYgMDAwMDAgbiAKMDAwMDAzNzgx MSAwMDAwMCBuIAowMDAwMDQwOTI4IDAwMDAwIG4gCjAwMDAwNDA5MDcgMDAwMDAgbiAKMDAwMDA0 MTIwOCAwMDAwMCBuIAowMDAwMDQxMDcwIDAwMDAwIG4gCjAwMDAwNDEzMTYgMDAwMDAgbiAKMDAw MDA0MTE4OSAwMDAwMCBuIAowMDAwMDQxMzg0IDAwMDAwIG4gCjAwMDAwNDQwMzMgMDAwMDAgbiAK MDAwMDA0NDAxMiAwMDAwMCBuIAowMDAwMDQ0MzQyIDAwMDAwIG4gCjAwMDAwNDQyMDEgMDAwMDAg biAKMDAwMDA0NDQ1MiAwMDAwMCBuIAowMDAwMDQ0MzIyIDAwMDAwIG4gCjAwMDAwNDQ1MjIgMDAw MDAgbiAKMDAwMDA0NzM1MSAwMDAwMCBuIAowMDAwMDQ3NzE2IDAwMDAwIG4gCjAwMDAwNDczMjkg MDAwMDAgbiAKMDAwMDA0Nzc5NCAwMDAwMCBuIAowMDAwMDQ3ODk1IDAwMDAwIG4gCjAwMDAwNDc5 NDggMDAwMDAgbiAKMDAwMDA1NTYyNyAwMDAwMCBuIAowMDAwMDU1NjQ5IDAwMDAwIG4gCjAwMDAw NTU4OTIgMDAwMDAgbiAKMDAwMDA1NTk4MSAwMDAwMCBuIAowMDAwMDU2MjgyIDAwMDAwIG4gCjAw MDAwNTY0NzMgMDAwMDAgbiAKMDAwMDA1OTMyNyAwMDAwMCBuIAowMDAwMDU5MzQ5IDAwMDAwIG4g CjAwMDAwNTk1NzggMDAwMDAgbiAKMDAwMDA1OTk1MyAwMDAwMCBuIAowMDAwMDc5MTM4IDAwMDAw IG4gCjAwMDAwNzkxNjEgMDAwMDAgbiAKMDAwMDA3OTM5OSAwMDAwMCBuIAowMDAwMDc5NzA4IDAw MDAwIG4gCjAwMDAwODAwMTEgMDAwMDAgbiAKMDAwMDA4MDE5OCAwMDAwMCBuIAowMDAwMDg3NDA4 IDAwMDAwIG4gCjAwMDAwODc0MzAgMDAwMDAgbiAKMDAwMDA4NzY3NyAwMDAwMCBuIAowMDAwMDg3 NzU4IDAwMDAwIG4gCjAwMDAwODgwNTkgMDAwMDAgbiAKMDAwMDA4ODI1MiAwMDAwMCBuIAp0cmFp bGVyCjw8IC9TaXplIDEzMSAvUm9vdCAxMDcgMCBSIC9JbmZvIDEzMCAwIFIgL0lEIFsgPDhkNTgw YjFhNDhjY2MzY2RhNjBmY2E3YmFiMzkxMDY2Pgo8OGQ1ODBiMWE0OGNjYzNjZGE2MGZjYTdiYWIz OTEwNjY+IF0gPj4Kc3RhcnR4cmVmCjg4NDUxCiUlRU9GCg== --Apple-Mail-24--631577019 Content-Disposition: attachment; filename=draft-despres-softwire-mesh-sam-01.txt Content-Type: text/plain; name="draft-despres-softwire-mesh-sam-01.txt" Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force R. Despres Internet-Draft October 26, 2009 Intended status: Standards Track Expires: April 29, 2010 Stateless Address Mapping (SAM) - Mesh Softwires without e-BGP draft-despres-softwire-mesh-sam-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 29, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract SAM is a generic and simple mechanism for packets having addresses in a family IPvX to traverse routing domains where this address family is not directly routed. Despres Expires April 29, 2010 [Page 1] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 SAM topological scenarios are those of Mesh Softwire, i.e. with point to multipoint tunnels between border nodes of interior routing domains. In the mesh-softwire context, SAM differs from RFC 5565 in that SAM uses no protocol between border nodes of the domain, and in that customer border nodes don't need to maintain states for all other border nodes. (RFC 5565 is based on an Exterior Border-Gateway Protocol e-BGP between border nodes, with dynamic routing tables to be maintained in all of them). SAM's address mappings are stateless, based on only a few domain parameters. SAM is thus suitable to small to medium enterprises, and small to medium ISPs, that cannot afford e-BGP in all their border nodes. All combinations of IPv4 and IPv6, global or private, are supported. Also, to mitigate consequences of the IPv4 address shortage, SAM supports port-extended IPv4 addresses (A+P). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 5 2.1. A small ISP lacking enough global IPv4 addresses . . . . . 5 2.2. A small customer site having only a port-restricted IPv4 address . . . . . . . . . . . . . . . . . . . . . . . 7 3. The SAM Model and its Terminology . . . . . . . . . . . . . . 9 4. SAM functional sub-modules and their parameters . . . . . . . 10 5. Mapping between SAM Interior Addresses and SAM interior IDs . 13 5.1. SAM-interior-address Formats . . . . . . . . . . . . . . . 13 5.2. SAM Interior Addresses and SAM Interior IDs in IPv6 . . . 14 5.3. SAM Interior Addresses and SAM Interior IDs in IPv4 . . . 15 6. SAM Prefixes and SAM Raw Prefixes . . . . . . . . . . . . . . 16 7. Derivation of Sub-delegated prefixes from Delegated Prefixes and Interior IDs . . . . . . . . . . . . . . . . . . 19 8. Mapping from Source and Destination Endpoint Locators to Source and Destination Interior Addresses . . . . . . . . . . 20 8.1. Encapsulation Function . . . . . . . . . . . . . . . . . . 20 8.2. Decapsulation Function . . . . . . . . . . . . . . . . . . 21 9. Detailed Prefixes for the Example Scenarios . . . . . . . . . 22 10. Applicability to other scenarios . . . . . . . . . . . . . . . 24 11. Security considerations . . . . . . . . . . . . . . . . . . . 24 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 14.1. Normative References . . . . . . . . . . . . . . . . . . . 25 14.2. Informative References . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 Despres Expires April 29, 2010 [Page 2] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 1. Introduction The Softwires Working Group standardizes discovery, control, and encapsulation methods, for connecting IPv4 networks across IPv6 networks and IPv6 networks across IPv4 networks. Two topological scenarios have been identified for this in [RFC4925]: Hubs and Spokes and Mesh. o Hubs and Spokes targets carriers, or large enterprise networks acting as carriers, that deploy Centralized Softwire Concentrators. o The particular mesh framework described in [RFC5565] targets carriers or large-enterprises whose networks support, in all their border nodes, a common exterior Border Gateway Protocol (e-BGP). Stateless Address Mapping (SAM) targets small to medium enterprises, or small to medium Internets service providers (ISPs), that don't operate centralized software concentrators, and in whose networks a common e-BGP in all border nodes in not practicable. (In SAM, stateless means that border nodes are not obliged to maintain states for all other border nodes - a meaning similar to that used in Stateless DHCP of [RFC3736]). SAM principles are an extension of those already in practice with 6to4 [RFC3056], ISATAP [RFC5214], and 6rd [Free's IPv6 in 2007] [RFC5569] [6rd], which support IPv6 across IPv4 routing domains, encapsulate exterior packets into interior packets, and statelessly map from exterior addresses to interior addresses. SAM unifies and generalizes their scopes in the following directions: o Other encapsulations than just global IPv6 in global or private IPv4 are supported, with all combinations of IPv6 and IPv4, including with the IPv4 private addresses of [RFC1918] and the IPv6 private addresses of [RFC4193] for interior routing. o Provisions are made so that, despite the IPv4 address shortage [Ipv4Shortage], the end-to-end transparency of [RFC2775] can be restored in IPv4. o Stateless autoconfiguration of sub-delegated prefixes [PrefSubDeleg] is made possible in addition to the IPv6 stateless address autoconfiguration of [RFC2462]. o Support of multihoming is generalized [RFC3582] [RFC4219], with compatibility with ingress filtering in ISP networks [RFC3704]. Despres Expires April 29, 2010 [Page 3] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 SAM's design has some commonalities with various earlier proposals, like ENCAPS (RFC 1955 in 1996), GSE (draft-ipng-gseaddr-00 in 1997), DSTM (draft-ietf-ngtrans-dstm in 1999-2002), LISP (draft-farinacci-lisp in 2007-2009), RANGERS (draft-templin-ranger in 2008-2009), IVIT (draft-xu-behave-ivit in July 2009). But it has a significantly different scope from all of them. In particular, LISP introduces an Endpoint Identifier space different from the Routing Locator space. Tunnels across the Internet core are consequently always necessary. On the contrary, SAM's endpoint identifiers are based on routable IPv4 and IPv6 address spaces. Tunnels across the Internet core are therefore not necessary, which is important for incremental deployability [RFC5218]. Compared to protocols such as SCTP [RFC4960] and Shim6 [RFC5533], which specify how to use to multiple addresses in host endpoints, SAM is complementary. It introduces new ways to assign multiple addresses to hosts so that they can be used by SCTP or Shim6. This SAM specification is an evolution from [-SAM-02] and [-SAM-03]. The former was focused on how NATs might be totally dispensed with if SAM would be generalized (somewhat theoretical); the latter was limited to how SAM supports multihoming in sites using private IPv6 addresses (practical, but too restrictive). This one is focused on what SAM can provide, in a reasonable short term, in many configurations (more practical, not restrctive). It also introduces some technical improvements and, the author believes, substantial clarifications. The proposed specification is intended to be complete enough now to permit compatible independent implementations, by developers skilled in the art, with administratively configured parameters. (DHCP- option formats have yet to be specified). Being new, this specification is likely to have remaining inadequacies and even, the devil being in details, sheer bugs. Many improvements and corrections are therefore expected to be necessary after more work, but the approach is believed to sound. Implementation of a subset of this specification is under way at Telecom Bretagne, in view of a first experimentation. Despres Expires April 29, 2010 [Page 4] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 2. Example Scenarios To mitigate consequences of the IPv4 address shortage during the transition-to-IPv6 period, diverse solutions have been identified for different scenarios: [Frmwk-trans] and [DSlite] are based on ISP provisioned NATs (CGNs); [PRR] and [A+P], which can coexist with CGNs or in some cases make them unnecessary, target hubs-and-spokes configurations. They support dynamic reservations of port ranges (with stateful mappings). The two example scenarios below are similar to the latter (coexistence with CGNs, with possibilities to bypass them), but concerns mesh configurations, and is based on static port-range assignments (stateless mappings). SAM's applicability is much larger than described in these two examples. They have been been chosen to insist on SAM's potential to face the more and more pressing IPv4 address shortage problem. 2.1. A small ISP lacking enough global IPv4 addresses Figure 1 shows the configuration of this first scenario. The considered small ISP offers native IPv6 to its customers. Because it has a /32 IPv6 prefix and assigns /48s to its customers, it can support up to 64K of them. Now, due to the IPv4 address shortage, it has only a /20 IPv4 prefix (a maximum of 4K global IPv4 addresses). This not being enough to assign one IPv4 address to each customer, IPv4 address have to be shared. This can be done both dynamically, for an optimized multiplexing efficiency but at a cost of non-transparent NAT traversal, and statically, to avoid NAT traversals and so that assigned addresses and ports can be safely advertised outside (typically for server or peer-to-peer applications that need incoming connections). To support IPv4-only legacy hosts, and to offer dynamic port sharing to all hosts including SAM-capable ones, the ISP of this scenario operates a CGN for IPv4-to-IPv4 address translations (NAT44). To use it, customers are assigned private IPv4 addresses of [RFC1918]. These addresses are obtained by customer-edge routers (CEs) in DHCPv4 [RFC2131]. The ISP assigns ports 0 to 32K - 1 of all its global IPv4 addresses to its CGN, and ports 32K to 64K - 1 to SAM for its port-extended IPv4 addressing. Despres Expires April 29, 2010 [Page 5] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 INTERNET IPv6-SubnetPrefix/64 (RA) BACKBONES IPv6-Add (autoconf) | PrivIPv4-Add (DHCPv4) IPv6-Pref/32 | | | V CUSTOMER-EDGE | | NODES (CEs) | +-------------------------+ | +--------- | | | ISP NETWORK | | | V | | IPv6 & private IPv4 |<=3D=3D=3D | +------------+<=3D=3D=3D | +-------+ = IPV6 | dual stack |<--- | | | | only +------+ | | | | | | +--------- +------------+ | | | | +------------+ | +-------+ | dual stack | | | CGN | +--------- | +------+------+ | NAT44 | | | | SAM |<=3D=3D=3D | | | | | |<=3D=3D=3D |<--- | +-------+-------+ = IPV4 | | | | | | | |<=3D=3D=3D | +-----+--|---+ | | | SAM | | | | | | | | | +--------- | | +-----------------+-------+ | | | | IPv6-SubnetPrefix/64 (RA) | | IPv6-Add (autoconf) IPv4-Pref/20 | PrivIPv4-Add (DHCPv4) | IPv6-Pref/48 IPv4-Add:(PortPref/5) Number of customer sites: 64K NAT44 external ports : 2K / customer site IPv4 assigned ports : 2K / customer site AN ISP EXAMPLE WITH LESS IPv4 ADDRESSES THAN IPV6 /48 PREFIXES Figure 1 With SAM, in a way that will be explained in subsequent sections, and detailed for this example in Section 2.1, each dual-stack CE, in addition to its possibility to use shared ports of the CGN like any IPv4-capable CE, is statically assigned 2K reserved ports on a shared global IPv4 address. Despres Expires April 29, 2010 [Page 6] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 Each CE has freedom to use these reserved ports its own way to take advantage of the end-to-end Internet transparency they make possible. In the next-section scenario, we describe how a particular CE uses its reserved ports. 2.2. A small customer site having only a port-restricted IPv4 address Figure 2 shows a possible scenario for a customer site whose ISP is that of the previous section. The considered customer site is residential or is that of a small- office/home-office. It has up to 16 hosts on a single LAN. (This LAN may include a switch between different physical media, like copper wires, Wifi, power-lines, etc.). For IPv4-only legacy hosts, the CE supports a NAT44, and a DHCP server which assigns private IPv4 addresses. This NAT uses ports 4K to 64K - 1 of the site private-IPv4 address. It also uses 1K ports among the 2K reserved ports of the site global-IPv4 address. (With these ports, it can support administratively configured port forwarding, and dynamic reservation protocol such as NAT-PMP or UPnP.) In addition to IPv6 possibilities of all dual-stack hosts, SAM- capable hosts are statically assigned IPv6 /52 prefixes. They may use these prefixes freely, for example to run small LANs behind them, e.g. in Bluetooth, with global-IPv6 addresses assignable to hosts of these LANs. In IPv4, each SAM-capable host is automatically assigned, besides its private IPv4 address, 64 reserved ports of the site global IPv4 address. It can use them its own way, in particular to advertise outside its ports on which it has server and/or peer-to peer applications. It can also further distribute some of these reserved ports to SAM-capable hosts on a LAN behind it. Some protocols are known to traverse NATs without problem, like that of Web requests (remote port 80) and that of DNS queries (remote port 53). In order to save ports of the site global IPv4 address for other usages, outgoing connections having these protocols can use the site private address and traverse both the site NAT44 and the CGN. Note that, in the case of DNS queries, a known advantage of traversing NATs is that used external ports are less predictable. This is a known precaution to prevent the DNS attack identified by Dan Kaminsky [DnsAttack]. Despres Expires April 29, 2010 [Page 7] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 IPv6-SubnetPrefix/64 (RA) IPv6-Add (autoconf) PrivIPv4-Add (DHCPv4) HOSTS | IPv6-SubnetPrefix/64 (RA) | | LAN IPv6-Add (autoconf) | | IPv6 & private IPv4 PrivIPv4-Add (DHCPv4) v | | | +------------+ | | CUSTOMER-EDGE ROUTER (CE) | | dual stack |<=3D=3D=3D | +--------------------+ | | only |<--- | | | | | |<--- | | +-------+ | | | +-------------+ | | | | <=3D=3D=3D | | | | | NAT44 | | <--- +------------+ | | | | | <--- +-------+ +-------+-------+--------- +------------+ | | | SAM | SAM | | dual stack | | | | |<=3D=3D=3D | | +-----+-------------+ | | | | | | | SAM |<=3D=3D=3D | +----+-------+--|----+ | |<=3D=3D=3D |<--- | | | | | |<--- | IPv6-Pref/48 +------+--|--+ | | IPv4-Add:(PortPref/5) | | | | | IPv6-SubnetPrefix/64 (RA) | IPv6-Add (autoconf) | PrivIPv4-Add (DHCPv4) | IPv6-Pref/52 IPv4-Add:(PortPref/9) Number of SAM hosts: 16 NAT44 external ports via ISP NAT44 : 60K =3D ~ 4K / host NAT44 external ports on its public address: 512 =3D 64 / host IPv4 assigned ports : 64 / host A SMALL CUSTOMER SITE HAVING A PORT-RESTRICTED IPV4 ADDRESS Figure 2 Despres Expires April 29, 2010 [Page 8] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 3. The SAM Model and its Terminology Th SAM model is illustrated in Figure 3. SAM functional modules, or "SAMs" for short, are located in "border nodes" of the SAM interior routing domain (or "SAM domain" for short). These modules encapsulate packets they receive from "exterior" domains, and forward them across the SAM "interior" domain. In the other direction, they decapsulate packets received from the interior to forward them on their exterior domain. .--------------- EXTERIOR --------------. / \ ------'----> <---- INTERIOR ----> <----'------- <--- CONSUMER SIDE --- --- PROVIDER SIDE ---> SUB-DELEGATED DELEGATED prefixes prefixes | interior | endpoint | ADDRESSES | LOCATOR endpoint | / \ | | LOCATOR | / \ +--|------|------- | | +---/-----------\---+ | | | -----|----+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +--|----+ | | +-------+ | | | | | | | | | | | | +--+ | | | | | | | | | | +--+ | +<--- |<=3D=3D=3D |<--- --->| |<=3D=3D=3D = --->+ | +--+ | SAM | | SAM | +--+ ENDPOINT | | SAM DOMAIN | | ENDPOINT +-------+ +-------+ | | with defined | | | ^ | INTERIOR ADDRESS | ^ | -----------+ : | FORMAT(S) | : | : +-------------------+ : | : : +----------- : : <-------> <-------> in a BORDER NODE in a BORDER NODE (host or router) (router) SAM TERMINOLOGY Figure 3 Despres Expires April 29, 2010 [Page 9] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 An endpoint "locator" can be a global-IPv4 or global-IPv6 address or, if its endpoint is in a domain where port-extended IPv4 addressing is used, an address-plus-port couple (A+P). (In domains using port- extended addressing, endpoints exist only for applications that use ports, i.e. all applications using TCP, UDP, DCCP, or SCTP. ICMP error messages returned when packets of such connections are discarded, because they contain the port numbers of discarded packets, can reach such endpoints.) With SAM, port-extended-addressing applies not only to IPv4, to deal with the IPv4 address shortage, but also to IPv6. This not only maintains orthogonality of features (avoidance of restrictions for which there is no identified reason), but has also identified applications. In particular, if a LAN is deployed behind a host having a global IPv6 address but no IPv6 prefix, and if this LAN has a frame format such that bridging in the host is not possible, then port-extended IPv6 addressing on this LAN is a useful tool to provide global IPv6 reachability to hosts on this LAN. If one or several delegated prefixes are received from the exterior side of a SAM (in DHCP or otherwise), these prefixes are called "delegated prefixes" of the SAM domain, and the exterior side of this SAM is called a "provider side" of the SAM domain. If, conversely, a SAM delegates one or several prefixes to its exterior domain, these prefixes are called "sub-delegated prefixes" of the SAM, and the exterior side of this SAM is called a "consumer side" of the SAM domain. As detailed in Section 7, prefixes that are sub-delegated by a SAM are derived from the delegated prefixes of the SAM domain and the "interior ID" of this SAM. Delegated and sub-delegated prefixes, are prefixes of endpoint locators. As such, they can be port-extended (up to 48 bits in IPv4 and 144 in IPv6). 4. SAM functional sub-modules and their parameters Sub-modules of SAMs, both customer-side and provider-side, are shown in Figure 4. Despres Expires April 29, 2010 [Page 10] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 customer-side SAM <- exterior interior -> +-----------------+ | +-------------+ | | SAM PARAMETERS | | DHCP client | |<=3D=3D=3D | (obtained from a provider-side = SAM) | +-------------+ | | | SAM | | | | stateless | | | | autoconf | | | +-------------+ | | | SAM | | provider-side SAM | | map & encap | | <-- interior exterior --> | +-------------+ | +-------------------+ +-----------------+ | +---------------+ | | | stateless | | SAM PARAMETERS | <=3D=3D=3D=3D| | DHCP = server | | (provided to consumer-side SAMs) | | +---------------+ | * Interior parameters | | | SAM | | - SAM interior-address format(s) | | | map & encap | | * Exterior parameters | | +---------------+ | - provider-SAM interior address(es) | | |SAM-parameter | | - their delegated prefix(es) | | | gatherer | | | +---------------+ | SAM PARAMETERS | | | DHCP | | (obtained from other provider SAMs) | =3D=3D=3D>| | multiple = | | | | client | | Configured parameters: | +---------------+ | * SAM interior-address format(s) |---.->| | * interior addresses of provider SAMs | / +-------------------+ \ '----- delegated prefixes of this SAM SAM FUNCTIONAL MODULES AND THEIR PARAMETERS Figure 4 A customer-side SAM has a DHCP client to obtain SAM parameters that apply to its SAM domain. The DHCPv6 of [RFC3736] is used if IPv6 interior addresses are available, the DHCPv4 of [RFC2131] otherwise. The SAM stateless autoconfiguration sub-module is, in a customer-side SAM, in charge of building its "SAM interior address". This address conforms to one of the SAM interior-address formats of the SAM domain. This format is such that the interior ID of the SAM, shorter than an address, can be derived from its SAM interior address. For the IPv6 stateless address autoconfiguration of [RFC2462] to still work with legacy hosts that may be on the same links, SAM interior- Despres Expires April 29, 2010 [Page 11] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 addresses must have a different format from all possible addresses of such hosts. For this, SAM interior addresses have a SAM tag that distinguishes them, as detailed in Section 5.2. In IPv4, the autoconfiguration is based on [RFC3927], applied to interior addresses of Section 5.3. IPv4 SAM interior addresses, having no place for a SAM tag, have to be distinguished from other interior addresses by means of distinct subnet prefixes. The SAM map&encap sub-module is present in all SAMs, customer-side as well as provider-side. It checks that source and destination locators received by a SAM from either of its sides are authorized. It also has to check that, in packets received from its interior side, source and destination interior addresses of encapsulating packets are consistent with source and destination endpoint locators of encapsulated packets. If these checks don't fail, packets are in the exterior-to-interior direction encapsulated as specified in [RFC4213], and are in the interior-to-exterior direction decapsulated. The DHCP-server sub-module is, as far as SAM parameters are concerned, stateless (no need to maintain states about customer-side SAMs). It is in charge of transmitting SAM parameters of the SAM domain to customer-side SAMs from which it receives queries. These parameters are those that have been collected by the SAM-parameter gatherer sub-module. In a node that already needs a DHCP server for other purposes, the SAM DHCP-server sub-module can be this DHCP server. The SAM-parameter gatherer sub-module makes a synthesis of: o delegated prefixes received from the exterior side of the SAM; o the interior address of the SAM. o parameters that are administratively configured for this SAM (i.e. formats of SAM interior addresses and, if the SAM domain is multi- homed, the list of interior addresses of other provider-side SAMs); o parameters that are obtained from other provider-side SAMs by the DHCP multiple client sub-module; The interior address of a provider-side SAM must be distinguishable from that of a customer-side SAM for routing-loop-attack prevention as explained in Section 8. It has therefore to be obtained as a classical IPv6 address (whose format is different from that of SAM interior addresses that customer-side SAMs obtain as detailed in Section 5). Despres Expires April 29, 2010 [Page 12] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 The SAM-parameter gatherer module queries stateless DHCP servers of other provider-side SAMs. It merges all parameters it thus receives with those received locally. It checks that SAM interior-address formats are consistent (identical if they have the same format ID, as specified in Section 5). All SAM functions being stateless, each SAM can be duplicated to sustain traffic loads that exceed a single processor capacity. All instances must have the same SAM interior address (routed as an anycast address in the SAM domain). 5. Mapping between SAM Interior Addresses and SAM interior IDs 5.1. SAM-interior-address Formats A SAM interior-address format has the following sub-parameters: o A "format ID" F. Having several formats in a SAM domain permits to have in a SAM domain link subnets having different lengths, and to sub-delegate prefixes having different lengths. If a SAM domain has only one SAM interior-address format, the format ID is not needed. Its length can then be set to 0. If there are several non-null-length formats, their IDs must be non overlapping prefixes so that they can be recognized in locators. (For example, 0, 100, 1O1, 110, 1110, and 1111, are compatible format IDs, but not 01 and 011). o A "common prefix" C. In SAM domains that use private address spaces, C can for example be in IPv4 10.0.0.0/8 [RFC1918]. In IPv6, it can be a /48 randomly selected prefix of [RFC4193], used to build Unique Local IPv6 addresses in the SAM domain. In one of the provider-side SAMs of the domain, C can be administratively specified to be a received delegated prefix of the SAM (as short as possible if there are several) rather than a given constant. In this case the interior address space is a global, as in examples of Section 9. o The "subnet-ID" length s. If a SAM domain has several links having different subnet prefixes, it needs several formats. Subnet IDs are the fields that appear after Cs to distinguish subnet prefixes. In a site with only one link, subnet IDs are not needed, and s can be set to 0. o The "host-ID" length h. In a SAM interior address, the host ID is in the lower part of the address. Two consumer SAMs that are on a common link have different host IDs, obtained by autoconfiguration. Despres Expires April 29, 2010 [Page 13] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 5.2. SAM Interior Addresses and SAM Interior IDs in IPv6 Figure 5 shows the reversible mapping between SAM interior address and interior ID in IPv6. A SAM tag is necessary, in the stateless address autoconfiguration of [RFC2462], to distinguish SAM interior addresses from other IPv6 addresses on the same link. It is enough for this that the two lower bits of addresses 9th octet be set to 0b11 (a value which differs from that of all currently IPv6 addresses specified in [RFC4291]). Other bits of the octet are proposed to be all set to 1 to keep an escape mechanism for future new IPv6 address formats. SAM INTERIOR ADDRESS - IPv6 common prefix subnet ID SAM format ID host ID | (s may be 0) tag | (f may be 0) | | | | | | V V V V V <----------c---------><--s-> <-8-> <--h---> <------------- 64 -------------><------------- 64 -------------> +---------------------+-----+---+----+---+--------------+------+ | C |XXXXX| 0 |0xFF| F | 0 |XXXXXX| +---------------------+-----+---+----+---+--------------+------+ | | / / / / Format /\ |_____|______/ / / / Parameters || / __|_________/ / / F, C, s, h || /| / | _____________________/ / || / | / | / _____________________/ \/ / |/ |/ / +---+-----+------+ |"F"|XXXXX|XXXXXX| +---+-----+------+ <---- f+s+h ----> SAM INTERIOR ID MAPPING BETWEEN SAM INTERIOR ADDRESSES AND SAM INTERIOR IDs IN IPv6 Figure 5 Despres Expires April 29, 2010 [Page 14] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 5.3. SAM Interior Addresses and SAM Interior IDs in IPv4 Figure 6 shows the reversible mapping between SAM interior addresses and SAM interior IDs in IPv4. In IPv4 SAM interior addresses, there is not, like in IPv6, a place to have different format IDs without interfering with routable subnet prefixes. If there are several links in a SAM domain, there should then be only one format. SAM interior IDs have then the same length for all consumer-side SAMs of the SAM domain. If on the other hand there is only one link in the SAM domain, different format IDs can be used to have several host-ID lengths, which permits several sub- delegated-prefix lengths. SAM INTERIOR ADDRESS - IPv4 format constant ID prefix (optional) host ID | | | | | subnet | | | ID | | | (s may be 0) | | | | | V V V V <------c-----><-s-> <-h-> <--------------- 32 ---------------> +-------------+---+----+-------+----+ | C |"F"|XXXX| 0 |XXXX| +-------------+---+----+-------+----+ Format /\ | | | / / Parameters || | | | ___/ / F, C, s, h || | | | / ___/ \/ | | |/ / +---+----+----+ |"F"|XXXX|XXXX| +---+----+----+ <---- s+h ----> SAM INTERIOR ID MAPPING BETWEEN SAM INTERIOR ADDRESSES AND SAM INTERIOR IDs IN IPv4 Despres Expires April 29, 2010 [Page 15] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 Figure 6 Because of this lack of flexibility of IPv4 SAM interior addresses, IPv6 should be used for SAM interior addresses if both IPv6 and IPv4 are possible. 6. SAM Prefixes and SAM Raw Prefixes An important feature of SAM is that the free hierarchical structure of addresses, which has been advantageously introduced in IPv4 with the classless inter-domain routing of [RFC1519] (CIDR), is generalized: in IPv4, where it currently applies only to the 32-bits of IPv4 addresses, it is extended to 48 bits with port-extended IPv4 addresses; in IPv6, where it currently applies only to the first 64 bits of IPv6 addresses, it is first extended to their full 128 bits, and then to 144 bits with port-extended IPv6 addresses. This flexibility in prefix lengths considerably extends the possibility to organize routing domains in a hierarchical setup. Each domain receives delegated prefixes from its provider-side domains, and assigns sub-delegated prefixes to its customer-side domains. Some precautions are however necessary, due to format constraints which exist on IPv6 addresses [RFC4291] and on port numbers [RFC1700]. Concerning IPv6 address formats, there is an ongoing debate about accepting, or not, that subnet prefixes of IPv6 addresses that never appear directly as destinations on IPv6 links might be extended beyond 64 bits, with any value in 9th octet. (For example, ISATAP addresses of [RFC5214] are such IPv6 addresses. They do comply with the 9th octet constraint of [RFC4291] but, with the freedom under discussion, they could have been specified without it). The only technical reason known by the author against this new freedom on IPv6 address formats relates routing-loop-attack prevention. (These attacks have been found to be possible with some ISATAP and 6to4-relay routers. It was first documented on July 16 2009 by Gabi Nakibly in an e-mail to the v6ops mailing list. It is still unclear whether the 9th octet constraint is useful to prevent some of these attacks or not). By precaution, we assume in this draft that the 9th octet constraint still holds. If it can be relaxed, some of the complexity introduced below to distinguish SAM raw prefixes from SAM prefixes can disappear. Despres Expires April 29, 2010 [Page 16] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 Concerning port-number prefixes used as address extensions, they must exclude the well-known-ports range 0-1023 of [RFC1700] because it has specific interpretations in firewalls and in hosts. For this reason, ports prefixes used for address extension will have their first bit always set to 1. IPv6 SAM PREFIX up to 64 bits +------------+-------------------+ |XXXXXXXXXXXX|...................| IPv6 ADDRESS +------------+-------------------+ (128 bits) : : +------------+ |XXXXXXXXXXXX| +------------+ IPv6 SAM RAW PREFIX up to 64 bits IPv6 SAM PREFIX up to 128 bits <----- 64 -----><8><----> +---------------+--+-----+-------+ |XXXXXXXXXXXXXXX|FF|XXXXX|.......| IPv6 ADDRESS +---------------+--+-----+-------+ (128 bits) : : / / : :/ / +---------------+-----+ |XXXXXXXXXXXXXX |XXXXX| +---------------+-----+ IPv6 SAM RAW PREFIX up to 120 bits IPv6 SAM PREFIX up to 144 bits <----- 64 -----><8><--- 56 ----><1><> +---------------+--+-------------+-+--+---+ IPv6 ADDRESS |XXXXXXXXXXXXXXX|FF|XXXXXXXXXXXXX|1|XX|...| + PORT +---------------+--+-------------+-+--+---+ (144 bits) : : / / / / : :/ / / / : : : / / : : :/ / +---------------+-------------+--+ |XXXXXXXXXXXXXXX|XXXXXXXXXXXXX|XX| +---------------+-------------+--+ IPv6 SAM RAW PREFIX up to 135 bits 1:1 MAPPING BETWEEN SAM PREFIXES AND SAM RAW PREFIXES IN IPv6 Despres Expires April 29, 2010 [Page 17] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 Figure 7 To deal with the above format constraints, a distinction is made between "SAM raw prefixes", and "SAM prefixes": o SAM raw prefixes are fully hierarchical, like classical CIDR prefixes, with all their bits permitted to have any values. o SAM prefixes, which may span all bits of A+P locators, have some fixed fields to be complied with if they are long enough to reach these fixed fields. Detailed mappings between SAM prefixes and SAM raw prefixes are shown in Figure 7 and Figure 8, for IPv6 and IPv4 respectively. IPv4 SAM PREFIX up to 32 bits +------------+-----+ |XXXXXXXXXXXX|.....| IPv4 ADDRESS +------------+-----+ (32 bits) : : +------------+ |XXXXXXXXXXXX| +------------+ IPv4 SAM RAW PREFIX up to 32 bits IPv4 SAM PREFIX up to 48 bits <------- 32 ------><1><-> +------------------+-+---+--+ IPv4 ADDRESS |XXXXXXXXXXXXXXXXXX|1|XXX|..| + PORT +------------------+-+---+--+ (48 bits) : :/ / : : / : : : : : : +------------------+--+ |XXXXXXXXXXXXXXXXXX|XX| +------------------+--+ IPv4 SAM RAW PREFIX up to 47 bits 1:1 MAPPING BETWEEN SAM PREFIXES AND SAM RAW PREFIXES IN IPv4 Figure 8 Despres Expires April 29, 2010 [Page 18] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 7. Derivation of Sub-delegated prefixes from Delegated Prefixes and Interior IDs Raw sub-delegated prefixes are built, in each SAM domain, according to the CIDR principle: each domain in the hierarchy adds its SAM interior ID to its raw delegated prefixes. Actual sub-delegated prefixes are then derived from raw sub-delegated prefixes as detailed in Section 6. Figure 9 shows successive steps of sub-delegated- prefix constructions. IPv4 or IPv6 +--------------+ | INTERIOR ID | +--------------+ IPv4 or IPv6 | || : +------------------------+ || : | a DELEGATED PREFIX | || : +------------------------+ || : : || : || : : \/ : || : +------------------------+ || : | its derived RAW PREFIX | || : +------------------------+ || : : || : || : : \/ : \/ : +---------------------------------------+ | the derived SUB-DELEGATED RAW PREFIX | +---------------------------------------+ : || : : \/ : +---------------------------------------+ | the derived SUB-DELEGATED PREFIX | +---------------------------------------+ IPv4 or IPv6 1:N MAPPING BETWEEN INTERIOR IDs AND DELEGATED PREFIXES Figure 9 Despres Expires April 29, 2010 [Page 19] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 8. Mapping from Source and Destination Endpoint Locators to Source and Destination Interior Addresses 8.1. Encapsulation Function In the encapsulation function of a SAM, the following rules govern how source and destination addresses of encapsulating packets are derived from source and destination locators found in packets to be encapsulated: PROVIDER-SIDE-SAM ENCAPSULATION 1. The source locator MUST NOT match any delegated prefix of this SAM (spoofing prevention), and the destination locator MUST match one of them (there is upstream a routing-configuration error if it doesn't). 2. In the destination locator, an interior ID MUST be extractible from bits that follow the prefix of this SAM that is matched. The destination interior address is then derived from this interior ID, and the source interior address is the interior address of this SAM. CUSTOMER-SIDE-SAM ENCAPSULATION 1. The source locator MUST match a sub-delegated prefix of this SAM (spoofing prevention), and the destination locator MUST NOT match any of them (there is upstream a routing-configuration error does match). 2. If the destination locator matches a delegated prefix of the SAM domain, an interior ID MUST be extractible from bits that, in this destination locator, follow the matched delegated prefix. The destination interior address is then derived from this interior ID, and the source interior address is the SAM interior address of this SAM. 3. If the destination locator doesn't match any delegated prefix of the SAM domain, the destination interior address is that of the provider-side SAM that has, among its delegated prefixes, one that matches the source locator. The source interior address is the interior address of this provider-side SAM. Despres Expires April 29, 2010 [Page 20] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 8.2. Decapsulation Function In the decapsulation function of a SAM, the following rules have be complied with to ensure that source and destination addresses of encapsulating packets and source and destination locators of encapsulated packet are valid. (They have to be consistent both among themselves and with parameters of the SAM.) PROVIDER-SIDE-SAM DECAPSULATION 1. The source locator MUST match a delegated prefix of this SAM (spoofing prevention), and the destination locator MUST NOT match any of them (there is upstream a routing-configuration error if it does match). 2. An interior ID MUST be extractible, in the source locator, from its bits that follow the matched delegated prefix. The source interior address MUST be the SAM interior address which is derived from this interior ID. (This check makes it impossible that a packet coming from another provider-side SAM be accepted, the interior address of this other SAM being different from any SAM interior address. Routing-loop attacks are thus prevented). The destination interior address MUST be this SAM's interior address. CUSTOMER-SIDE-SAM DECAPSULATION 1. The source locator MUST NOT match any sub-delegated prefix of this SAM (spoofing prevention), and the destination locator MUST match one of them (there is upstream a routing-configuration error if it doesn't). 2. If the source locator matches a delegated prefix of the SAM domain, an interior ID MUST be extractible from this source locator in bits that follow the matched delegated prefix. The source interior address MUST be that which is derived from this interior ID, and the destination interior address MUST be the interior address of this SAM. 3. If the source locator doesn't match any delegated prefix of the SAM domain, the destination locator MUST match one of the sub- delegated prefixes of the SAM, and the source interior address MUST be that of a provider-side SAM whose delegated prefix is at the beginning of this sub-delegated prefix. The destination interior address MUST be the interior address of this SAM. Despres Expires April 29, 2010 [Page 21] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 9. Detailed Prefixes for the Example Scenarios We now return to the two scenarios of Section 2 to show how the described SAM mechanisms can deliver what was claimed. INTERNET ISP NETWORK BACKBONES | 2001:a::/32 | V | V +-------------------------+ | +--------- | IPv6 & private IPv4 | | | | |<=3D=3D=3D | | 0::/0 =3D=3D=3D>+-------+ = IPV6 | | | | | | CUSTOMER-EDGE | | +--------- NODES | link 5 | | | 2001:a:50000::/64 (198.0.0.0/20):(0/1) V | 10.0.0x50.0x44 | / +------------+ | | +-------+ / | dual stack | | | | |/ +--------- | +------+------+--+ 0../0 =3D=3D=3D>| NAT44 / | | | SAM |<--- | | | /| | | |<=3D=3D=3D |<--- | | +-------+-------+ = IPV4 | | | | | | | |<=3D=3D=3D | +-----+--|---+ | | --->| SAM | | | | | | | | | | +--------- | | +---------------|-+-------+ | | | \ | | 2001:a:5000:0:ff00::222 | | | (SAM autoconf on link 5) | 198.0.0.0/20 | 10.0x52.0x22.0 (DHCPv4) | | | | | 2001:a:5222::/48 2001:a:0000:0: 198.0.1.0x22:(0b10010/5) (autoconf on link 0) SAM interior-address format: C=3D2001:a::/32; F=3D0/0; s=3D4; h=3D12 Number of customer sites: 64K NAT44 external ports : 2K / customer site IPv4 assigned ports : 2K / customer site (IPv6 assigned ports : 64K / customer site) EXAMPLE OF DETAILED ADDRESSES FOR APPLICATION 1 Despres Expires April 29, 2010 [Page 22] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 Figure 10 Figure 10 and Figure 11 respectively deal with the small ISP scenario of Section 2.1 and with the customer site scenario of Section 2.2. LAN 10.0.0x54.0x44 2001:a:5222:0::/64 198.0.1.0x22:(0b100100/6) 192.168.0.0/24 | | | | CUSTOMER-EDGE ROUTER | | +---------------|----+ SAM | | +-------+ | | HOSTS | | | | / | | | | =3D=3D>| NAT44 |/ | V | | | | | +-------+ +-------+-------+--------- +------------+ | --->| | | ISP |<--- | dual stack | | =3D=3D=3D>|--->| SAM | SAM |<--- | +-----+-------------+ | | | |<=3D=3D=3D | | | | SAM |<=3D=3D=3D | | +----+-------+--|----+ | | |<=3D=3D=3D |<--- | | | \ | | | |<--- | | | | +------+--|--+ | | 2001:a:5222::/48 | | | | 198.0.1.0x22:(0b10010/5) | | | | | | | 2001:a:1222:0: /64 | | | (autoconf) | | | 0.0.0.0/0 | | | | | 2001:a:5222:0::/64 (RA) | | 2001:a:5222:0:ff00::3 2001:a:5000:0:ff00::222 | (SAM autoconf) (SAM autoconf) | 192.168.0.x (DHCPv4) 10.0.0x54.0x44 (DHCPv4) | 2001:a:1222:3000::/51 198.0.1.0x22:(0b1001010011/10) SAM interior-address format: C=3D2001:a:5222::/48; F=3D0/0; s=3D0; = h=3D4 Number of SAM hosts : 16 NAT44 shared external ports via ISP-NAT : 4K / host NAT44 shared external ports on a global add : 64 / host IPv4 assigned ports : 64 / host EXAMPLE OF DETAILED ADDRESSES FOR APPLICATION 2 Figure 11 Despres Expires April 29, 2010 [Page 23] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 10. Applicability to other scenarios SAM can be used across ISP networks that route exclusively in IPv6 like those of in [IVI]. With SAM, IPv4 end-to-end transparency, port extended or not, can be offered as an additional possibility to IVI customers that are SAM-capable (with IPv4 packets encapsulated in IPv6 packets). Other SAM scenarios, which are numerous, are beyond the scope of this particular version of the draft. Some should be added in later versions. 11. Security considerations Provided all address checks of Section 8 are performed, as required by this specification, no new security risk has been identified. 12. IANA Considerations The SAM tag in the 9th octet of IPv6 addresses, used to distinguish SAM interior addresses from other IPv6 addresses, should in due time be registered by IANA. Also, if an when detailed formats for SAM-specific DHCP options are agreed on, they will have to be submitted to IANA. 13. Acknowledgments This specification is mostly the result of a personal effort of the author, in continuation with what he did for 6rd [Free's IPv6 in 2007], but high recognition is due to Mark Townsley who listened to intermediate stage presentations, provided useful reactions, and was a convincing advocate for a Cisco Research Grant to be allocated to Telecom Bretagne, for a validation of a subset of SAM. Special thanks are also due to Laurent Toutain. After having seen SAM's potential, he planned an experiment with students at Telecom Bretagne. Dave Thaler made a precious detailed review of an earlier draft. Beyond this, the open discussion environment of IETF in general has been a continuous encouragement. Despres Expires April 29, 2010 [Page 24] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 14. References 14.1. Normative References [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. 14.2. Informative References [-SAM-02] Despres, R., "Stateless Address Mapping (SAM) - Avoiding NATs and restoring the end-to-end model in IPv6", March 2009. [-SAM-03] Despres, R., "Scalable Multihoming across IPv6 Local- Address Routing Zones - Global-Prefix/Local-Address Stateless Address Mapping (SAM)", July 2009. [6rd] Townsley, M. and O. Troan, "IPv6 via IPv4 Service Provider Networks, draft-ietf-softwire-ipv6-6rd", August 2009. [A+P] Bush, R., "The A+P Approach to the IPv4 Address Shortage - draft-ymbk-aplusp-04", July 2009. [DSlite] Durand, A., "Dual-stack lite broadband deployments post IPv4 exhaustion - draft-ietf-softwire-dual-stack-lite-01", July 2009. [DnsAttack] Friedl, S., "An Illustrated Guide to the Kaminsky DNS Vulnerability - http://unixwiz.net/techtips/ iguide-kaminsky-dns-vuln.html", August 2008. [Free's IPv6 in 2007] Despres, R., "IPv6 Rapid Deployment on IPv4 infrastructures (6rd) - draft-despres-6rd-03", April 2009. Despres Expires April 29, 2010 [Page 25] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 [Frmwk-trans] Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6 Translation - raft-baker-behave-v4v6-framework-02", February 2009. [IVI] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The CERNET IVI Translation Design and Deployment for the IPv4/ IPv6 - Coexistence and Transition - draft-xli-behave-ivi-02", June 2009. [Ipv4Shortage] Levis, P., Boucadair, M., Grimault, JL., and A. Villefranque, "IPv4 Shortage: Needs and Open Issues - draft-levis-behave-ipv4-shortage-framework-01", March 2009. [PRR] Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, "Pv4 Connectivity Access in the Context of IPv4 Address Exhaustion: Port Range based IP Architecture - draft-boucadair-port-range-02", July 2009. [PrefSubDeleg] Baker, F., "Prefix Sub-delegation in a SOHO/SMB Environment - draft-baker-ipv6-prefix-subdelegation-00", July 2009. [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC1955] Hinden, R., "New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. Despres Expires April 29, 2010 [Page 26] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- Multihoming Architectures", RFC 3582, August 2003. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6) Developers Should Think About", RFC 4219, October 2005. [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008. [RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful Protocol?", RFC 5218, July 2008. [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009. [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, June 2009. [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 infrastructures (6rd) - Publication delayed since May 2009 for a reason common to all independent-submission RFCs". Despres Expires April 29, 2010 [Page 27] =0C Internet-Draft SAM - Mesh Softwires without e-BGP October 2009 Author's Address Remi Despres 3 rue du President Wilson Levallois, France Email: remi.despres@free.fr Despres Expires April 29, 2010 [Page 28] =0C --Apple-Mail-24--631577019 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > --Apple-Mail-24--631577019-- From sgundave@cisco.com Mon Nov 23 16:18:29 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5619E28C0E1 for ; Mon, 23 Nov 2009 16:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0XIHxqeRl9v for ; Mon, 23 Nov 2009 16:18:28 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 5E9423A67B5 for ; Mon, 23 Nov 2009 16:18:28 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.47,274,1257120000"; d="scan'208";a="53106246" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 24 Nov 2009 00:18:24 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nAO0IO9J008761; Tue, 24 Nov 2009 00:18:24 GMT Date: Mon, 23 Nov 2009 16:18:24 -0800 (PST) From: Sri Gundavelli To: Hui Deng In-Reply-To: <1d38a3350911222319p20913cd7lb21a00fa1971cd61@mail.gmail.com> Message-ID: References: <1d38a3350911222319p20913cd7lb21a00fa1971cd61@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 24 Nov 2009 08:28:18 -0800 Cc: fengcao@chinamobile.com, =?GB2312?B?wfW088X0?= , =?GB2312?B?s8K41Q==?= , =?GB2312?B?1tyyqQ==?= , "Cao, Zhen" , softwires@ietf.org Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 00:18:29 -0000 Hi Hui, Adding to what Alain already said. When you projected the slide that compared various transition approaches, for the UE to UE bullet point, for the Gateway Initiated Dual-stack lite solution, you have marked it as "Unsupported or No". So, I asked the question, is it for over-lapping or a non-overlapping case and from our conversations offline and online both at Shanghai and at the IETF, you said it was about non-overlapping case. Now, for this case, in the proposal we have, any IPv4 traffic from the UE, always hits the GGSN over the mobility tunnel. At the GGSN, its a routing decision to forward the traffic to the internet via CGN, over the CGN tunnel, or local foward. If its a local forward, the packet is routed to the target UE/SGSN over a different mobility tunnel. The GGSN is the anchor and all traffic goes through that point and it can local forward. That's how we can support this scenario. For the case of overlapping IP, we talked to many operators and no one confirmed that they have a legacy application that are supported in this mode. So, the general thought was to have a sensible approach of using IPv6 transport for such applications. Now, if we argue that we need to support over IPv4 transport, we need to ask many questions, as how the application resolution happens, how the application server delivers that information and how it learns the NAT'd address of a UE ..etc. These are unresolved questions both as a requirement and even for PNAT if you pitch a solution based on host translation. As I see it, its a new requirement and as Alain/Dan Wing pointed out, there are potential ways to solve it. In simple terms, what ever you do on the host, we can infact solve it on the network. Now, moving to your other pointer and the motivation for the PNAT work, you have listed: a.) a need to support IPv6-only transport network b.) support IPv4 legacy applications, over a IPv6 transport c.) avoid airlink over-ahead d.) enable UE to UE comminication. For #a and #b, mobility architectures and the solution we have allow the case where the access network and the core network is either IPv4 or IPv6. There is no issue on this aspect. For #c, our solution does not introduce any air link over-ahead, as there is no tunnel from the UE. We dont have the host architecture, or touch the UE. For #d, the solution can support UE to UE over IPv4 or IPv6 transport, for the non-overlapping case. For overlapping case, we will plug in the feature as needed. Also, I'd like to remind that your slide missed number of other bullet points, for example, it should have had a bullet point, "Changes to host architecture", with a marking "Yes" to PNAT solution, and "No" to Gateway Initiated Dual-stack lite solution. Since, its not a trivial design point that you can ignore. Regards Sri On Mon, 23 Nov 2009, Hui Deng wrote: > Dear Alain and Sri, > > I guess that you two have already read below draft: > http://tools.ietf.org/id/draft-cao-behave-hbt-req-00.txt > This draft has been presented in detail during the last IETF meeting. > > During the meeting, you two have standed up and said that > DS-Lite and GW-Init-DS-Lite could also meet the requirement of host to > host direct communication. > I really cann't understand it, could you help to elbaroate more here > about details? > > Many thanks for your kind explanation. > Best regards, > > -Hui Deng > From denghui02@gmail.com Tue Nov 24 08:25:50 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 989683A694C for ; Tue, 24 Nov 2009 08:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zatZ57rJB9H for ; Tue, 24 Nov 2009 08:25:49 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id CC0A328C10D for ; Tue, 24 Nov 2009 08:25:49 -0800 (PST) Received: by pwi6 with SMTP id 6so4592697pwi.29 for ; Tue, 24 Nov 2009 08:25:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DISvZeJf3urcEDfGeYALtSMNLz4N6kXFsDmkwVT4GjU=; b=YKguSbL1WrV9WqIWPwMXMjaPpa1rjrZIIkC4JLKULNoLsmVslEQKGyV0y1ovrLJ0mY T2ZhrG/8/mXItLmlRy7d8Xiuwz3CPiLG78neOWAVqFML9ctze+2ROcZnesBzhqwsvodD v0KCKXu2llEMmJRoJkmkOwO5labi4XylDPEu0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=scERpRYnWWcsRQiKB752OnB2LekieBKsDo4ioH7TaIY10BvtTZWM8g6kkqK8LGmr2R ELqK9RLabfxdzrEAzQ5rE3t/08FslSUuy67sT1OjLtgCiNEwv2tHjoF3NhZHC4x5rY1U ZIXViOie0/TxOjD+AYy79mLnJ0Yd7OQeJvmAc= MIME-Version: 1.0 Received: by 10.141.48.8 with SMTP id a8mr365843rvk.54.1259079935300; Tue, 24 Nov 2009 08:25:35 -0800 (PST) In-Reply-To: References: <1d38a3350911222319p20913cd7lb21a00fa1971cd61@mail.gmail.com> Date: Wed, 25 Nov 2009 00:25:35 +0800 Message-ID: <1d38a3350911240825r5f3d54e7i96cdedb7a64fb430@mail.gmail.com> From: Hui Deng To: "Durand, Alain" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 24 Nov 2009 08:28:18 -0800 Cc: fengcao@chinamobile.com, liudapeng@chinamobile.com, chengang@chinamobile.com, zhouboyj@chinamobile.com, "Cao, Zhen" , softwires@ietf.org Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 16:25:50 -0000 Alain, Thanks for your explanation, let me try to figure out what you are proposing here: 2009/11/24 Durand, Alain : > Hui, > > If I understand your requirements: > > v6 only network > v4 apps > low encap overhead > direct =93shortcut=94 communications between 2 adjacent nodes > > 1 & 2 are already met by the current DS-lite > 3 is a matter of opinion... Is an extra IPv4 header (20 byte) that much o= f a > deal? > When we looked at softwire hub&spoke a few years back, the wg consensus w= as > that the extra overhead of encapsulation was worth it. some mobile operators like us have different opinion on it > You can use some form of header compression to mitigate this overhead. Ho= w > to use header compression in that case can be defined in softwire it is not that easy to do backward compatibility, and it's really hard to use it today > 4 could be a very straightforward extension of DS-lite. If you know the > common IPv6 prefix shared by adjacent nodes, you can directly tunnel to > them. I don't understand here, are you suggesting all DS-Lite host has common IPv= 6 prefix? what kind of direct tunnel could be established? > In practice, you=92ll have a default route to the AFTR and a subnet route= for > the =93local=94 prefix. I don't understand here either, you are saying there are IPv4 subnet route in the IPv6 only network? Many thanks for the discussion -Hui > > =A0=A0- Alain. > > > > On 11/23/09 2:19 AM, "Hui Deng" wrote: > > Dear Alain and Sri, > > I guess that you two have already read below draft: > http://tools.ietf.org/id/draft-cao-behave-hbt-req-00.txt > This draft has been presented in detail during the last IETF meeting. > > During the meeting, you two have standed up and said that > DS-Lite and GW-Init-DS-Lite could also meet the requirement of host to > host direct communication. > I really cann't understand it, could you help to elbaroate more here > about details? > > Many thanks for your kind explanation. > Best regards, > > -Hui Deng > > From denghui02@gmail.com Tue Nov 24 08:29:20 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DEE33A694C for ; Tue, 24 Nov 2009 08:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZMDPdUd85jy for ; Tue, 24 Nov 2009 08:29:19 -0800 (PST) Received: from mail-px0-f186.google.com (mail-px0-f186.google.com [209.85.216.186]) by core3.amsl.com (Postfix) with ESMTP id 6EFA03A689A for ; Tue, 24 Nov 2009 08:29:19 -0800 (PST) Received: by pxi16 with SMTP id 16so4798009pxi.29 for ; Tue, 24 Nov 2009 08:29:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uLeWJSjJiiEr1YMNH7qBDsmzMIk1tYouQ+BTTUbh3Xo=; b=xF7cWzMV1gOOBMOgum1BWZTsoM3h+lt3xIDIgp1lwnVkucRNMQSlaqc3d9/Fg1Jkk7 pMbPwoJqBK+gLTj7rwni/GWoPs4tRdJokroj6+oT1NDrpff0hii+Opp+rvDCcSwJkokB pdLrJXmXY56KYE9uCvu0NbJnEu9BxDrpQvPHQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FNAqQO0kCoyzqfBW+sB0hW7cM6cvXeAq0vIYqZ6v6S62FkM8eHkkfAopktErjzHhTs lxlCFEzmhzS9uLQcppgvAZtZ+U1+k39eNOkXGuWgqgOiwKZv37AYWi3HsFGWHE0lIasV mYOoKgs2xkCAHy+RDA3oPpTYMhHPIDfdj4W6c= MIME-Version: 1.0 Received: by 10.140.148.9 with SMTP id v9mr375321rvd.247.1259080151080; Tue, 24 Nov 2009 08:29:11 -0800 (PST) In-Reply-To: References: Date: Wed, 25 Nov 2009 00:29:10 +0800 Message-ID: <1d38a3350911240829o58f0b3a8v2ee541e0e05052f7@mail.gmail.com> From: Hui Deng To: james woodyatt Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Alain Durand , ietf softwire Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 16:29:20 -0000 so DS-Lite need double translations of NAT44 to support host to host communication? -Hui 2009/11/24 james woodyatt : > On Nov 23, 2009, at 08:53, Durand, Alain wrote: >> >> 4 could be a very straightforward extension of DS-lite. If you know the = common IPv6 prefix shared by adjacent nodes, you can directly tunnel to the= m. >> In practice, you=92ll have a default route to the AFTR and a subnet rout= e for the =93local=94 prefix. > > Also, to support the direct host-to-host tunneling, the DS-lite extension= would need to allow for many DS-lite subscribers to share a single IPv4 pr= ivate address realm. =A0I think DS-lite currently requires that each IPv6 s= ubscriber is isolated within their own IPv4 private address realm, and ther= efore a twice-NAT44 gateway is required for IPv4-only applications to commu= nicate between DS-lite subscribers. > > > -- > james woodyatt > member of technical staff, communications engineering > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From denghui02@gmail.com Tue Nov 24 08:31:22 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21F7E3A6A60 for ; Tue, 24 Nov 2009 08:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssBef2QDzIcL for ; Tue, 24 Nov 2009 08:31:20 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id C411D3A694C for ; Tue, 24 Nov 2009 08:31:20 -0800 (PST) Received: by pzk6 with SMTP id 6so4662793pzk.29 for ; Tue, 24 Nov 2009 08:31:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RWWt0/BaVs6zJaRw0fl/+thtyG49/jLMNsudoykypHg=; b=WbS58cltRGJb2MaOTDUjjVAAW0CMOuYgn0Vm1OVHrMhajeEdA2CbKLaRBkVexgwMUm 1FXW63U1u01lnsbzSmiBcL0YI50U5nhPBFG/91sSLk3SbSH4q/BvZN9EI/o5l5vhqVlu K1jWrxd9WQywoyFR0WURsr3fcxxWwqPKmcQbQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Si3e8gtqDpqyNlRDayX0nfZXFGSV3RKSoPDLuQRWKpbYNQodlJ2OtwLdR9T+JmSH10 0CVDc6xr8HttbuAnWqZGJqE//aUsxUzTptR9a50QgFxLmnjtXONnCmTHNoqU7BJzRl9Q sHAAUesLkowmwwX2zScCZs0uEK4fHdWW2hQng= MIME-Version: 1.0 Received: by 10.140.136.21 with SMTP id j21mr371565rvd.271.1259080273810; Tue, 24 Nov 2009 08:31:13 -0800 (PST) In-Reply-To: References: Date: Wed, 25 Nov 2009 00:31:13 +0800 Message-ID: <1d38a3350911240831p3c447d64t79a0c429639e147d@mail.gmail.com> From: Hui Deng To: "Durand, Alain" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf softwire Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 16:31:22 -0000 so you are proposing assign different IPv4 address to the DS-Lite host, is this public or private? I still don't understand how this tunneling could be setup between hosts? thanks -Hui 2009/11/24 Durand, Alain : > Yes... Whenever you do the shortcuts, you bump into the non trivial > questions to know who you are talking to... > Now, if v4 addresses are allocated via DHCPv4 over the IPv6 tunnel, this > problem can be solved. Is it worth the effort or not depend on how much t= he > shortcuts are going to save you... > > =A0- Alain. > > > On 11/23/09 1:10 PM, "james woodyatt" wrote: > >> On Nov 23, 2009, at 08:53, Durand, Alain wrote: >>> >>> 4 could be a very straightforward extension of DS-lite. If you know the >>> common IPv6 prefix shared by adjacent nodes, you can directly tunnel to= them. >>> In practice, you=B9ll have a default route to the AFTR and a subnet rou= te for >>> the =B3local=B2 prefix. >> >> Also, to support the direct host-to-host tunneling, the DS-lite extensio= n >> would need to allow for many DS-lite subscribers to share a single IPv4 >> private address realm. =A0I think DS-lite currently requires that each I= Pv6 >> subscriber is isolated within their own IPv4 private address realm, and >> therefore a twice-NAT44 gateway is required for IPv4-only applications t= o >> communicate between DS-lite subscribers. >> >> >> -- >> james woodyatt >> member of technical staff, communications engineering >> >> > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From alain_durand@cable.comcast.com Tue Nov 24 08:34:06 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC41C3A694C for ; Tue, 24 Nov 2009 08:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VENOXGxSgbTZ for ; Tue, 24 Nov 2009 08:34:06 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id AA0C33A67E9 for ; Tue, 24 Nov 2009 08:34:05 -0800 (PST) Received: from ([24.40.15.92]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.61970233; Tue, 24 Nov 2009 11:33:56 -0500 Received: from PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 11:33:57 -0500 Received: from 71.230.252.107 ([71.230.252.107]) by PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 Nov 2009 16:33:56 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Tue, 24 Nov 2009 11:33:53 -0500 From: "Durand, Alain" To: Hui Deng , james woodyatt Message-ID: Thread-Topic: [Softwires] Discussion on the requirements of Host Based Translation Thread-Index: AcptI+jF5WdVeFlc3Em+zDoHKPuvew== In-Reply-To: <1d38a3350911240829o58f0b3a8v2ee541e0e05052f7@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 24 Nov 2009 16:33:57.0305 (UTC) FILETIME=[EB561290:01CA6D23] Cc: ietf softwire Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 16:34:07 -0000 This is only require if you do not have a unique IPv4 address per node. What I'm suggesting is to allocate/derive a unique v4 address to each node. It can be done either by running DHCPv4 over the DS-lite tunnel, or definin= g an IPv4 allocation option for DHCPv6 or defining a mechanism to automatically derive a unique v4 address from the DHCPv6 assigned v6 address. - Alain. On 11/24/09 11:29 AM, "Hui Deng" wrote: > so DS-Lite need double translations of NAT44 to support host to host > communication? >=20 > -Hui >=20 > 2009/11/24 james woodyatt : >> On Nov 23, 2009, at 08:53, Durand, Alain wrote: >>>=20 >>> 4 could be a very straightforward extension of DS-lite. If you know the >>> common IPv6 prefix shared by adjacent nodes, you can directly tunnel to >>> them. >>> In practice, you=B9ll have a default route to the AFTR and a subnet route= for >>> the =B3local=B2 prefix. >>=20 >> Also, to support the direct host-to-host tunneling, the DS-lite extensio= n >> would need to allow for many DS-lite subscribers to share a single IPv4 >> private address realm. =A0I think DS-lite currently requires that each IPv= 6 >> subscriber is isolated within their own IPv4 private address realm, and >> therefore a twice-NAT44 gateway is required for IPv4-only applications t= o >> communicate between DS-lite subscribers. >>=20 >>=20 >> -- >> james woodyatt >> member of technical staff, communications engineering >>=20 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From denghui02@gmail.com Tue Nov 24 08:37:43 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFC8828C0E3 for ; Tue, 24 Nov 2009 08:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cfh8olb10xIx for ; Tue, 24 Nov 2009 08:37:42 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id B4BE43A698A for ; Tue, 24 Nov 2009 08:37:42 -0800 (PST) Received: by pwi6 with SMTP id 6so4601052pwi.29 for ; Tue, 24 Nov 2009 08:37:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=0tlSYs+9BHJvwpIArS1XwKGZW+LrcjI/l5rKsQC0V64=; b=uzcaid/uBL1qG9rw7S0OotZH1cbPzvq5KkwJxJ+LbJKI6okMcfPHhwOU2PwHaPyy7E QiutHahLfvFNgiv/r4P0507QR6gMbRvJvci+p4kpupr5+ov2pNSsRxPRta+6hxYBUqQE lqhF6/2jMT74tdOW1nImF3KK17R1FP1T85HnY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=edyO1PsD5DxObJN6fryFLan1aBwVWNFNZQ055Zf+kom7q9vy/U3BRgHP7HW0iPlbGE Z0Xr6TOk4nldHw1gZH3kctQvn8XDdReR8n3XUd98TeLZQGeSqMmR3L+iWMBP8EaJiVZQ 5Mmb3+qIbebO1SAyLRfV0fsEw3ksDFEGNqWUo= MIME-Version: 1.0 Received: by 10.140.166.2 with SMTP id o2mr401942rve.275.1259080654840; Tue, 24 Nov 2009 08:37:34 -0800 (PST) In-Reply-To: References: <1d38a3350911222319p20913cd7lb21a00fa1971cd61@mail.gmail.com> Date: Wed, 25 Nov 2009 00:37:34 +0800 Message-ID: <1d38a3350911240837i1ae15cf7i5a49f4238729f54d@mail.gmail.com> From: Hui Deng To: Sri Gundavelli Content-Type: text/plain; charset=ISO-8859-1 Cc: fengcao@chinamobile.com, softwires@ietf.org Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 16:37:43 -0000 Hi, Sri, 1) Regarding overlapping case, I am assuming that GW-Init-DS-Lite assign the same Ipv4 address to the UE? 2) You are proposing add new bullet, but that is not our requirement, we are not compare the solution, just do requirement gap analysis, 3) I got your point that host to host communication will be done by Access router, you are assuming point to point to AR other than shared link. thanks for the discussion. -hui 2009/11/24 Sri Gundavelli : > Hi Hui, > > Adding to what Alain already said. > > When you projected the slide that compared various transition > approaches, for the UE to UE bullet point, for the Gateway > Initiated Dual-stack lite solution, you have marked it as > "Unsupported or No". So, I asked the question, is it for > over-lapping or a non-overlapping case and from our conversations > offline and online both at Shanghai and at the IETF, you said > it was about non-overlapping case. > > Now, for this case, in the proposal we have, any IPv4 traffic > from the UE, always hits the GGSN over the mobility tunnel. At > the GGSN, its a routing decision to forward the traffic to > the internet via CGN, over the CGN tunnel, or local foward. If > its a local forward, the packet is routed to the target UE/SGSN > over a different mobility tunnel. The GGSN is the anchor and > all traffic goes through that point and it can local forward. > That's how we can support this scenario. > > For the case of overlapping IP, we talked to many operators > and no one confirmed that they have a legacy application that > are supported in this mode. So, the general thought was to have a > sensible approach of using IPv6 transport for such applications. > Now, if we argue that we need to support over IPv4 transport, > we need to ask many questions, as how the application resolution > happens, how the application server delivers that information > and how it learns the NAT'd address of a UE ..etc. These are > unresolved questions both as a requirement and even for PNAT > if you pitch a solution based on host translation. As I see it, > its a new requirement and as Alain/Dan Wing pointed out, there > are potential ways to solve it. In simple terms, what ever you > do on the host, we can infact solve it on the network. > > Now, moving to your other pointer and the motivation for the PNAT > work, you have listed: > > a.) a need to support IPv6-only transport network > b.) support IPv4 legacy applications, over a IPv6 transport > c.) avoid airlink over-ahead > d.) enable UE to UE comminication. > > For #a and #b, mobility architectures and the solution we have allow > the case where the access network and the core network is either > IPv4 or IPv6. There is no issue on this aspect. > > For #c, our solution does not introduce any air link over-ahead, as > there is no tunnel from the UE. We dont have the host architecture, or > touch the UE. > > For #d, the solution can support UE to UE over IPv4 or IPv6 transport, > for the non-overlapping case. For overlapping case, we will plug in the > feature as needed. > > Also, I'd like to remind that your slide missed number of other bullet > points, for example, it should have had a bullet point, "Changes to > host architecture", with a marking "Yes" to PNAT solution, and "No" to > Gateway Initiated Dual-stack lite solution. Since, its not a trivial > design point that you can ignore. > > Regards > Sri > > > > > > > > > > > On Mon, 23 Nov 2009, Hui Deng wrote: > >> Dear Alain and Sri, >> >> I guess that you two have already read below draft: >> http://tools.ietf.org/id/draft-cao-behave-hbt-req-00.txt >> This draft has been presented in detail during the last IETF meeting. >> >> During the meeting, you two have standed up and said that >> DS-Lite and GW-Init-DS-Lite could also meet the requirement of host to >> host direct communication. >> I really cann't understand it, could you help to elbaroate more here >> about details? >> >> Many thanks for your kind explanation. >> Best regards, >> >> -Hui Deng >> > From denghui02@gmail.com Tue Nov 24 08:39:51 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEB903A68F9 for ; Tue, 24 Nov 2009 08:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeD+BxnsDfSA for ; Tue, 24 Nov 2009 08:39:51 -0800 (PST) Received: from mail-px0-f186.google.com (mail-px0-f186.google.com [209.85.216.186]) by core3.amsl.com (Postfix) with ESMTP id F35A23A67E9 for ; Tue, 24 Nov 2009 08:39:50 -0800 (PST) Received: by pxi16 with SMTP id 16so4805147pxi.29 for ; Tue, 24 Nov 2009 08:39:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mX+tUorhnN8pznJLJOU/odWFFVIqlAAYG4fFNaQZdNI=; b=NeJQtl+ysYuHx8BPt9KuN6wSujm+fgWnuSwyACQOe8nmiaOjiDdbp0fBHN36nTRGMc 13ZKvvmPPinCpRa1CSp0UGBeFdNAQKzbBc+fZWukf5RyLssB1dIVpSUM8qvZZ20QAETH 9xg0CDFQpuFL1NDLWea0Nj1xF4yc5x2qIvCE8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=f5YGg8UedszCC48X8savbf2tMo5vu3G95ElMbrHTML5kIF3cnCXx9/7wRZPamVwVyH Jip+5sb3ZicR0UGM2HcIi8x36l9Ca7+E1ZNbys8Ng7HzlwEkZnuZRrbjtbjh10Qmp6QJ bm90PkQqP6gWco7XJ+hr/Hyttj1yAzrSw3hCE= MIME-Version: 1.0 Received: by 10.141.48.8 with SMTP id a8mr366902rvk.54.1259080785182; Tue, 24 Nov 2009 08:39:45 -0800 (PST) In-Reply-To: References: <1d38a3350911240829o58f0b3a8v2ee541e0e05052f7@mail.gmail.com> Date: Wed, 25 Nov 2009 00:39:45 +0800 Message-ID: <1d38a3350911240839u1148ebe7k8e29df01173d1887@mail.gmail.com> From: Hui Deng To: "Durand, Alain" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf softwire Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 16:39:51 -0000 ok, suppose that you have such smart way to do IPv4 address assignment (that is not adopted by IETF, just a remindness) then how could you do host to host communication in the IPv6 only network? thanks for the discussion. -hui 2009/11/25 Durand, Alain : > This is only require if you do not have a unique IPv4 address per node. > What I'm suggesting is to allocate/derive a unique v4 address to each nod= e. > It can be done either by running DHCPv4 over the DS-lite tunnel, or defin= ing > an IPv4 allocation option for DHCPv6 or defining a mechanism to > automatically derive a unique v4 address from the DHCPv6 assigned v6 > address. > > =A0- Alain. > > > On 11/24/09 11:29 AM, "Hui Deng" wrote: > >> so DS-Lite need double translations of NAT44 to support host to host >> communication? >> >> -Hui >> >> 2009/11/24 james woodyatt : >>> On Nov 23, 2009, at 08:53, Durand, Alain wrote: >>>> >>>> 4 could be a very straightforward extension of DS-lite. If you know th= e >>>> common IPv6 prefix shared by adjacent nodes, you can directly tunnel t= o >>>> them. >>>> In practice, you=B9ll have a default route to the AFTR and a subnet ro= ute for >>>> the =B3local=B2 prefix. >>> >>> Also, to support the direct host-to-host tunneling, the DS-lite extensi= on >>> would need to allow for many DS-lite subscribers to share a single IPv4 >>> private address realm. =A0I think DS-lite currently requires that each = IPv6 >>> subscriber is isolated within their own IPv4 private address realm, and >>> therefore a twice-NAT44 gateway is required for IPv4-only applications = to >>> communicate between DS-lite subscribers. >>> >>> >>> -- >>> james woodyatt >>> member of technical staff, communications engineering >>> >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > > From alain_durand@cable.comcast.com Tue Nov 24 08:51:40 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 003693A6B51 for ; Tue, 24 Nov 2009 08:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.434 X-Spam-Level: * X-Spam-Status: No, score=1.434 tagged_above=-999 required=5 tests=[AWL=-1.566, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LM5RwSXtPYv for ; Tue, 24 Nov 2009 08:51:39 -0800 (PST) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 0E0D83A6B55 for ; Tue, 24 Nov 2009 08:51:38 -0800 (PST) Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.73403086; Tue, 24 Nov 2009 11:51:19 -0500 Received: from PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 11:51:20 -0500 Received: from 71.230.252.107 ([71.230.252.107]) by PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 Nov 2009 16:51:19 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Tue, 24 Nov 2009 11:51:17 -0500 From: "Durand, Alain" To: Hui Deng Message-ID: Thread-Topic: [Softwires] Discussion on the requirements of Host Based Translation Thread-Index: AcptJlcK8hNoNdmrZ0uaHQ4IqGVBxw== In-Reply-To: <1d38a3350911240839u1148ebe7k8e29df01173d1887@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 24 Nov 2009 16:51:20.0316 (UTC) FILETIME=[5904EBC0:01CA6D26] Cc: ietf softwire Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 16:51:40 -0000 Say you know both v4 & v6 prefixes associated to the scope. Say you want to communicate with node B with that v4 scope. You create a v6 address for B. That v6 address is reverse-derived from B's v4 address. Now, you encapsulate the v4 packet into a v6 packet. v6 src is yours, v6 dst is B's reverse-derived v6 address. - Alain. On 11/24/09 11:39 AM, "Hui Deng" wrote: > ok, suppose that you have such smart way to do IPv4 address assignment > (that is not adopted by IETF, just a remindness) > then how could you do host to host communication in the IPv6 only network= ? >=20 > thanks for the discussion. >=20 > -hui >=20 > 2009/11/25 Durand, Alain : >> This is only require if you do not have a unique IPv4 address per node. >> What I'm suggesting is to allocate/derive a unique v4 address to each no= de. >> It can be done either by running DHCPv4 over the DS-lite tunnel, or defi= ning >> an IPv4 allocation option for DHCPv6 or defining a mechanism to >> automatically derive a unique v4 address from the DHCPv6 assigned v6 >> address. >>=20 >> =A0- Alain. >>=20 >>=20 >> On 11/24/09 11:29 AM, "Hui Deng" wrote: >>=20 >>> so DS-Lite need double translations of NAT44 to support host to host >>> communication? >>>=20 >>> -Hui >>>=20 >>> 2009/11/24 james woodyatt : >>>> On Nov 23, 2009, at 08:53, Durand, Alain wrote: >>>>>=20 >>>>> 4 could be a very straightforward extension of DS-lite. If you know t= he >>>>> common IPv6 prefix shared by adjacent nodes, you can directly tunnel = to >>>>> them. >>>>> In practice, you=B9ll have a default route to the AFTR and a subnet rou= te >>>>> for >>>>> the =B3local=B2 prefix. >>>>=20 >>>> Also, to support the direct host-to-host tunneling, the DS-lite extens= ion >>>> would need to allow for many DS-lite subscribers to share a single IPv= 4 >>>> private address realm. =A0I think DS-lite currently requires that each I= Pv6 >>>> subscriber is isolated within their own IPv4 private address realm, an= d >>>> therefore a twice-NAT44 gateway is required for IPv4-only applications= to >>>> communicate between DS-lite subscribers. >>>>=20 >>>>=20 >>>> -- >>>> james woodyatt >>>> member of technical staff, communications engineering >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>=20 >>=20 From alain_durand@cable.comcast.com Tue Nov 24 08:46:42 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3ADE3A68CB for ; Tue, 24 Nov 2009 08:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.302 X-Spam-Level: X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[AWL=-1.302, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y47L1Iqa-4AT for ; Tue, 24 Nov 2009 08:46:41 -0800 (PST) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 5F25528C11B for ; Tue, 24 Nov 2009 08:46:39 -0800 (PST) Received: from ([10.195.246.152]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.73402280; Tue, 24 Nov 2009 11:46:18 -0500 Received: from PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 11:46:18 -0500 Received: from 71.230.252.107 ([71.230.252.107]) by PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 Nov 2009 16:46:18 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Tue, 24 Nov 2009 11:46:16 -0500 From: "Durand, Alain" To: Hui Deng Message-ID: Thread-Topic: Discussion on the requirements of Host Based Translation Thread-Index: AcptJaOhCzfVljO0RUOZg5n22Cb8WA== In-Reply-To: <1d38a3350911240825r5f3d54e7i96cdedb7a64fb430@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 24 Nov 2009 16:46:18.0890 (UTC) FILETIME=[A55AF6A0:01CA6D25] X-Mailman-Approved-At: Tue, 24 Nov 2009 08:53:06 -0800 Cc: fengcao@chinamobile.com, liudapeng@chinamobile.com, chengang@chinamobile.com, zhouboyj@chinamobile.com, "Cao, Zhen" , softwires@ietf.org Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 16:46:42 -0000 On 11/24/09 11:25 AM, "Hui Deng" wrote: >> You can use some form of header compression to mitigate this overhead. How >> to use header compression in that case can be defined in softwire > it is not that easy to do backward compatibility, and it's really hard > to use it today There are games we can play to "port" the relevant v4 header fields in the v6 header and remove the v4 header all together... As long as this is done on a link between two consenting nodes, this is fine. >> 4 could be a very straightforward extension of DS-lite. If you know the >> common IPv6 prefix shared by adjacent nodes, you can directly tunnel to >> them. > I don't understand here, are you suggesting all DS-Lite host has common IPv6 > prefix? what kind of direct tunnel could be established? What I'm suggesting is to define a 'scope' in which nodes can talk directly using the shortcuts. It makes little sense to 'short cut' with a node on the other side of the country, but I understand why you'd want to do this between two nodes that are behind the same base station. Within the scope, each node has a unique v6 address and a unique v4 address. (again, either derived from the v6 or assigned via DHCP). Net 10 should be big enough for that. You pass both v6 and v4 prefixes via DHCPv6 to all nodes within that scope. That way, when a node sees that the IPv4 address returned by (say split) DNS is within the v4 prefix, it can use the v6 prefix to 'tunnel/route' the packets. - Alain. From Fred.L.Templin@boeing.com Tue Nov 24 08:54:14 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DEE13A6B63 for ; Tue, 24 Nov 2009 08:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2K3ZbwjqA3Q for ; Tue, 24 Nov 2009 08:54:13 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 6B1733A6B61 for ; Tue, 24 Nov 2009 08:54:13 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id nAOGrt6U014021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 10:53:56 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id nAOGrtVY018418; Tue, 24 Nov 2009 08:53:55 -0800 (PST) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id nAOGrsTw018408 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 24 Nov 2009 08:53:54 -0800 (PST) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Tue, 24 Nov 2009 08:53:54 -0800 From: "Templin, Fred L" To: Dayong Guo , "softwires@ietf.org" Date: Tue, 24 Nov 2009 08:53:53 -0800 Thread-Topic: [Softwires] DHCP option and IPv4 Anycast for ISATAP Thread-Index: Acpsm+yhJkmi2SnlQe+dE+TVZNraiwAApR7gAA92NPAAEkH9YA== Message-ID: <12F4112206976147A34FEC0277597CCF27A5334DB0@XCH-NW-15V.nw.nos.boeing.com> References: <12F4112206976147A34FEC0277597CCF27A5334CC0@XCH-NW-15V.nw.nos.boeing.com> <001501ca6cdd$94d35310$cb0c6f0a@china.huawei.com> In-Reply-To: <001501ca6cdd$94d35310$cb0c6f0a@china.huawei.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 Subject: Re: [Softwires] DHCP option and IPv4 Anycast for ISATAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 16:54:14 -0000 Hi, > -----Original Message----- > From: Dayong Guo [mailto:guoseu@huawei.com] > Sent: Tuesday, November 24, 2009 12:10 AM > To: Templin, Fred L; softwires@ietf.org > Subject: RE: [Softwires] DHCP option and IPv4 Anycast for ISATAP >=20 > Hi, Fred: > Why do both IP address and FQDNs appear in ISATAP DHCP option? I th= ink > that one of them is enough. Thanks for the comment. The idea is to give maximum flexibility to the administrator who configures the DNS server. We have today an 'isatapd' daemon that accepts a mixed list of IPv4 addresses and FQDNs. It takes the union of all IPv4 literal addresses and IPv4 addresses obtained by resolving the FQDNs as the Potential Router List. I wanted to permit the same flexibility here. Does that seem OK to you? Fred fred.l.templin@boeing.com =20 > Dayong Guo >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: softwires-bounces@ietf.org > > [mailto:softwires-bounces@ietf.org] On Behalf Of Templin, Fred L > > Sent: Tuesday, November 24, 2009 8:47 AM > > To: softwires@ietf.org > > Subject: [Softwires] DHCP option and IPv4 Anycast for ISATAP > > > > Hi, > > > > I decided to renew my 6yr old expired draft on a DHCPv4 > > option for ISATAP: > > > > http://tools.ietf.org/html/draft-templin-isatap-dhcp-03 > > > > At the same time, I brought back the concept of IPv4 anycast > > for ISATAP router discover that was present in the initial > > ISATAP specs in the NGTRANS wg beginning with > > 'draft-ietf-ngtrans-isatap-00.txt'. > > > > This document could be compared for consistency with other > > softwires works on similar topics. For example, whether the > > border router should use the IPv4 anycast address or one of > > its unicast addresses as the source of ip-proto-41 packets is > > an interesting question. > > The answer may very well be: "it depends...". > > > > Fred > > fred.l.templin@boeing.com > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires From Fred.L.Templin@boeing.com Tue Nov 24 09:22:12 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 247163A67A6; Tue, 24 Nov 2009 09:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNg0iX9d+wUU; Tue, 24 Nov 2009 09:22:11 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 11F4A3A6359; Tue, 24 Nov 2009 09:22:11 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id nAOHLmpS000128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Nov 2009 09:21:49 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id nAOHLmCS020890; Tue, 24 Nov 2009 11:21:48 -0600 (CST) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id nAOHLkPe020867 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 24 Nov 2009 11:21:47 -0600 (CST) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Tue, 24 Nov 2009 09:21:46 -0800 From: "Templin, Fred L" To: Ted Lemon Date: Tue, 24 Nov 2009 09:21:45 -0800 Thread-Topic: [dhcwg] Comments on draft-templin-isatap-dhcp-03.txt Thread-Index: AcpswH5q5bLBwKjuQuCn40OIzgDqJwAZkgCQ Message-ID: <12F4112206976147A34FEC0277597CCF27A5334DC9@XCH-NW-15V.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" , dhc WG Subject: Re: [Softwires] [dhcwg] Comments on draft-templin-isatap-dhcp-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:22:12 -0000 Hi Ted, Thanks for the comments. There was a question on this on the softwires list also, so I'm cross-posting: > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of= Ted Lemon > Sent: Monday, November 23, 2009 8:42 PM > To: Fred Templin > Cc: dhc WG > Subject: [dhcwg] Comments on draft-templin-isatap-dhcp-03.txt >=20 > Section 1, Section 3: don't abbreviate "Potential Router List" as > "PRL" - it clashes violently with the existing DHCP "PRL", which is > the parameter request list. Better to just spell it out - it appears > four or five times in the document, which is a pain, but not too bad. Thanks for catching that; I'll fix it. > Put the IP address and FQDN counts right before the data being > counted, not at the beginning of the option - the way the draft > currently does it violates common practice and will require a special > code path in conforming implementations. So it should be option code, > len, anycast address, ip-addr-count, ip-addr-1, ..., ip-addr-n, > fqdn-count, fqdn-1, ..., fqdn-n. Got it, and I'll fix this. =20 > Why are you specifying both IP addresses and FQDNs? Standard practice > in DHCP is to just send FQDNs and let the DHCP server do name > resolution. Sending both makes the implementation more complex - is > there some reason why this complexity is necessary? It's going to be > difficult to specify in the DHCP server configuration, since most > existing DHCP servers accept FQDNs in any configuration field where an > IPv4 address is expected - how is the parser supposed to tell which > FQDNs to resolve and which to send to the client unresolved? The way ISATAP is currently specified, it expects to get a connection-specific DNS suffix from the DHCP server (i.e., from a domain name option) and then self-constructs an FQDN by prepending the well-known string "isatap" (e.g., as "isatap.example.com" when the suffix is "example.com"). The ISATAP client then resolves the FQDN itself by consulting the DNS. So, I want to preserve backward compatibility and maintain the same administrative profile whereby the client gets some information from DHCP and then consults the DNS on its own behalf. The client then uses the DNS TTLs as an indication of when it should re-resolve the FQDN. So administrative changes normally touch only the DNS resource records and only very rarely need to touch the DHCP config's, and clients discover the updates via DNS. > If you do actually need FQDNs for some reason, you need to specify how > they are encoded. The standard practice for DHCP options would be to > have some text similar to section 8 of RFC3315. RFC3315 cites Section 3.1 of RFC1035. That is the same normative reference I am citing in the current draft. (Actually, it looks like I cited RFC1035 twice; I'll fix that.) > The sample data for the FQDN option has a leading '.' fqdn before the > isatap.com fqdn, which makes the count wrong. Good catch; I'll fix this. > Why is this an informational draft? No particular reason; should I try for PS? Thanks - Fred fred.l.templin@boeing.com > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From sgundave@cisco.com Tue Nov 24 09:39:01 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 912613A68C4 for ; Tue, 24 Nov 2009 09:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vi8Bv3SUnTQj for ; Tue, 24 Nov 2009 09:39:00 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 81FBA3A6359 for ; Tue, 24 Nov 2009 09:39:00 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAD6pC0urRN+J/2dsb2JhbAC+NpgHhDkEgXA X-IronPort-AV: E=Sophos;i="4.47,280,1257120000"; d="scan'208";a="53497638" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 24 Nov 2009 17:38:56 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nAOHcuIA015190; Tue, 24 Nov 2009 17:38:56 GMT Date: Tue, 24 Nov 2009 09:38:55 -0800 (PST) From: Sri Gundavelli To: Hui Deng In-Reply-To: <1d38a3350911240837i1ae15cf7i5a49f4238729f54d@mail.gmail.com> Message-ID: References: <1d38a3350911222319p20913cd7lb21a00fa1971cd61@mail.gmail.com> <1d38a3350911240837i1ae15cf7i5a49f4238729f54d@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: softwires@ietf.org Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:39:01 -0000 Hi Hui, On Tue, 24 Nov 2009, Hui Deng wrote: > Hi, Sri, > > 1) Regarding overlapping case, I am assuming that GW-Init-DS-Lite > assign the same Ipv4 address to the UE? Sure, the same IPv4 address can be allocated as in DS lite base proposal. > 2) You are proposing add new bullet, but that is not our requirement, > we are not compare the solution, just do requirement gap analysis, Changes to the host is not a "requirement". But, its a cost for a specific solution. When you are comparing multiple solutions, its logical you present both the key positive and negative aspects of the solution. Minor aspects, you can hide or ignore. But, host change is a significant point of discussion, that you cant avoid to discuss. But, its your slide and your call. > 3) I got your point that host to host communication will be done by > Access router, you are assuming point to point to AR > other than shared link. > Mobile architectures, CDMA, LTE, or WiMAX or based on point to point link models on the access link. Mobile architectures is one of the key areas where the Gateway Initiated DS lite solution can be applied. For other architectures where shared links are in place, the access router maintains the association between the MAC/IP/GRE Key, so it can L2 forward the IP packet based on the state. Regards Sri > thanks for the discussion. > > -hui > > 2009/11/24 Sri Gundavelli : >> Hi Hui, >> >> Adding to what Alain already said. >> >> When you projected the slide that compared various transition >> approaches, for the UE to UE bullet point, for the Gateway >> Initiated Dual-stack lite solution, you have marked it as >> "Unsupported or No". So, I asked the question, is it for >> over-lapping or a non-overlapping case and from our conversations >> offline and online both at Shanghai and at the IETF, you said >> it was about non-overlapping case. >> >> Now, for this case, in the proposal we have, any IPv4 traffic >> from the UE, always hits the GGSN over the mobility tunnel. At >> the GGSN, its a routing decision to forward the traffic to >> the internet via CGN, over the CGN tunnel, or local foward. If >> its a local forward, the packet is routed to the target UE/SGSN >> over a different mobility tunnel. The GGSN is the anchor and >> all traffic goes through that point and it can local forward. >> That's how we can support this scenario. >> >> For the case of overlapping IP, we talked to many operators >> and no one confirmed that they have a legacy application that >> are supported in this mode. So, the general thought was to have a >> sensible approach of using IPv6 transport for such applications. >> Now, if we argue that we need to support over IPv4 transport, >> we need to ask many questions, as how the application resolution >> happens, how the application server delivers that information >> and how it learns the NAT'd address of a UE ..etc. These are >> unresolved questions both as a requirement and even for PNAT >> if you pitch a solution based on host translation. As I see it, >> its a new requirement and as Alain/Dan Wing pointed out, there >> are potential ways to solve it. In simple terms, what ever you >> do on the host, we can infact solve it on the network. >> >> Now, moving to your other pointer and the motivation for the PNAT >> work, you have listed: >> >> a.) a need to support IPv6-only transport network >> b.) support IPv4 legacy applications, over a IPv6 transport >> c.) avoid airlink over-ahead >> d.) enable UE to UE comminication. >> >> For #a and #b, mobility architectures and the solution we have allow >> the case where the access network and the core network is either >> IPv4 or IPv6. There is no issue on this aspect. >> >> For #c, our solution does not introduce any air link over-ahead, as >> there is no tunnel from the UE. We dont have the host architecture, or >> touch the UE. >> >> For #d, the solution can support UE to UE over IPv4 or IPv6 transport, >> for the non-overlapping case. For overlapping case, we will plug in the >> feature as needed. >> >> Also, I'd like to remind that your slide missed number of other bullet >> points, for example, it should have had a bullet point, "Changes to >> host architecture", with a marking "Yes" to PNAT solution, and "No" to >> Gateway Initiated Dual-stack lite solution. Since, its not a trivial >> design point that you can ignore. >> >> Regards >> Sri >> >> >> >> >> >> >> >> >> >> >> On Mon, 23 Nov 2009, Hui Deng wrote: >> >>> Dear Alain and Sri, >>> >>> I guess that you two have already read below draft: >>> http://tools.ietf.org/id/draft-cao-behave-hbt-req-00.txt >>> This draft has been presented in detail during the last IETF meeting. >>> >>> During the meeting, you two have standed up and said that >>> DS-Lite and GW-Init-DS-Lite could also meet the requirement of host to >>> host direct communication. >>> I really cann't understand it, could you help to elbaroate more here >>> about details? >>> >>> Many thanks for your kind explanation. >>> Best regards, >>> >>> -Hui Deng >>> >> > From Fred.L.Templin@boeing.com Tue Nov 24 10:13:43 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E17523A691C; Tue, 24 Nov 2009 10:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bN8xOQ5C8kjP; Tue, 24 Nov 2009 10:13:40 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id A134F3A6816; Tue, 24 Nov 2009 10:13:40 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id nAOIDBBg008984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Nov 2009 12:13:12 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id nAOIDBG0016101; Tue, 24 Nov 2009 10:13:11 -0800 (PST) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id nAOIDADq016094 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 24 Nov 2009 10:13:10 -0800 (PST) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Tue, 24 Nov 2009 10:13:11 -0800 From: "Templin, Fred L" To: Ted Lemon Date: Tue, 24 Nov 2009 10:13:09 -0800 Thread-Topic: [dhcwg] Comments on draft-templin-isatap-dhcp-03.txt Thread-Index: AcptLeoz+TW8h47dRwyQfQDeZsCM3AAAWvOA Message-ID: <12F4112206976147A34FEC0277597CCF27A5334DFD@XCH-NW-15V.nw.nos.boeing.com> References: <12F4112206976147A34FEC0277597CCF27A5334DC9@XCH-NW-15V.nw.nos.boeing.com> <6559FA66-6630-446B-A7A5-34702B1C370F@fugue.com> In-Reply-To: <6559FA66-6630-446B-A7A5-34702B1C370F@fugue.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: "softwires@ietf.org" , dhc WG Subject: Re: [Softwires] [dhcwg] Comments on draft-templin-isatap-dhcp-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 18:13:43 -0000 Hi Ted, > -----Original Message----- > From: Ted Lemon [mailto:mellon@fugue.com] > Sent: Tuesday, November 24, 2009 9:45 AM > To: Templin, Fred L > Cc: softwires@ietf.org; dhc WG > Subject: Re: [dhcwg] Comments on draft-templin-isatap-dhcp-03.txt >=20 > On Nov 24, 2009, at 12:21 PM, Templin, Fred L wrote: > > The way ISATAP is currently specified, it expects to get a > > connection-specific DNS suffix from the DHCP server (i.e., > > from a domain name option) and then self-constructs an FQDN > > by prepending the well-known string "isatap" (e.g., as > > "isatap.example.com" when the suffix is "example.com"). The > > ISATAP client then resolves the FQDN itself by consulting > > the DNS. >=20 > That makes sense. You might want to mention it in the draft... :') >=20 > However, I will reiterate that the DHCP server configuration never change= s if you just put FQDNs in > the configuration and let the DHCP server resolve them. The ISC server = resolves them synchronously > and caches them for an hour; the Nominum server resolves them asynchronou= sly and assumes that you > have a fast local DNS cache, so it doesn't cache them internally at all. = I don't know what other > DNS servers do specifically, but my understanding is that thebehavior is = similar. >=20 > So you get the same behavior whether you let the DHCP server resolve the = FQDN, or whether you make > the ISATAP implementation do it, unless you have really long leases or re= ally short TTLs, neither of > which I would expect to be common practice. > > So by sending FQDNs it seems like you're setting up an unnecessary wrestl= ing match between two styles > of doing things; I would argue that for a DHCP-based implementation, you = really ought not to do that, > if only because sending FQDNs tends to consume more DHCP packet space, wh= ich is a scarce resource. I think I understand what you are saying, but at the same time it seems like there may be some delicate tradeoffs involved. For example, wouldn't it be overloading the DHCP lease lifetime to expect it to also apply to the lifetime for ISATAP Potential Router List resolution? In other words, in my understanding the lease lifetime is primarily about how often one must refresh their IPv4 address delegation lifetimes - so, shouldn't that be decoupled from how often one must refresh their DNS FQDN resolutions? Someone pointed me to "Principles of Internet Host Configuration" [RFC5505] as a guide to understanding some of these tradeoffs. Maybe now would be a good time for me to go off and read that... Fred fred.l.templin@boeing.com PS We have a tool called "isatapd" that we will soon be announcing. It takes as command line arguments a list of both IPv4 addresses and FQDNs, and constructs the ISATAP Potential Router List as the union of all IPv4 addresses. So, it's not very hard for app's to deal with an assorted list of items. From Fred.L.Templin@boeing.com Tue Nov 24 10:14:38 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B35FE3A6929; Tue, 24 Nov 2009 10:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOYy85EKfzrL; Tue, 24 Nov 2009 10:14:37 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 235033A6816; Tue, 24 Nov 2009 10:14:37 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id nAOIEEJc006707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Nov 2009 10:14:16 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id nAOIEEux019311; Tue, 24 Nov 2009 10:14:14 -0800 (PST) Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id nAOIEELa019307 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 24 Nov 2009 10:14:14 -0800 (PST) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Tue, 24 Nov 2009 10:14:13 -0800 From: "Templin, Fred L" To: Ted Lemon Date: Tue, 24 Nov 2009 10:14:12 -0800 Thread-Topic: [dhcwg] Comments on draft-templin-isatap-dhcp-03.txt Thread-Index: AcptLgHkb2NxO6KNR9CY5GWV2xAhpgAA98Fw Message-ID: <12F4112206976147A34FEC0277597CCF27A5334E00@XCH-NW-15V.nw.nos.boeing.com> References: <12F411220697614 7A34FEC0277597CCF27A5334DC9@XCH-NW-15V.nw.nos.boeing.com> <552C5FDE-8D31-45CD-BB18-F9CF6DE4AF40@fugue.com> In-Reply-To: <552C5FDE-8D31-45CD-BB18-F9CF6DE4AF40@fugue.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: "softwires@ietf.org" , dhc WG Subject: Re: [Softwires] [dhcwg] Comments on draft-templin-isatap-dhcp-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 18:14:38 -0000 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of= Ted Lemon > Sent: Tuesday, November 24, 2009 9:46 AM > To: Templin, Fred L > Cc: softwires@ietf.org; dhc WG > Subject: Re: [dhcwg] Comments on draft-templin-isatap-dhcp-03.txt >=20 > On Nov 24, 2009, at 12:21 PM, Templin, Fred L wrote: > > No particular reason; should I try for PS? >=20 > Yes. OK; I'll fix that too. Fred fred.l.templin@boeing.com > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From jhw@apple.com Tue Nov 24 11:04:32 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5640B3A6906 for ; Tue, 24 Nov 2009 11:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YIvrzighrfl for ; Tue, 24 Nov 2009 11:04:31 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 8CC0D3A680C for ; Tue, 24 Nov 2009 11:04:31 -0800 (PST) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id AD9107AB04DE for ; Tue, 24 Nov 2009 11:04:26 -0800 (PST) X-AuditID: 11807130-b7b0aae00000102c-72-4b0c2e3aaffa Received: from il0602a-dhcp117.apple.com (il0602a-dhcp117.apple.com [17.206.23.245]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 19.11.04140.A3E2C0B4; Tue, 24 Nov 2009 11:04:26 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: james woodyatt In-Reply-To: Date: Tue, 24 Nov 2009 11:04:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: ietf softwire X-Mailer: Apple Mail (2.1077) X-Brightmail-Tracker: AAAAAQAAAZE= Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 19:04:32 -0000 On Nov 24, 2009, at 08:33, Durand, Alain wrote: >=20 > This is only require if you do not have a unique IPv4 address per = node. I think you meant to say "a unique IPv4 address *realm* per node" there. > What I'm suggesting is to allocate/derive a unique v4 address to each = node. A more flexible approach would be to derive a unique IPv4 private subnet = for each DS-lite node in a given private address realm with a bijective = mapping to its IPv6 address. > It can be done either by running DHCPv4 over the DS-lite tunnel, or = defining > an IPv4 allocation option for DHCPv6 or defining a mechanism to > automatically derive a unique v4 address from the DHCPv6 assigned v6 > address. I don't see a good reason to muck with DHCPv6 here. I'd suggest using DHCPv4 over the DS-lite tunnel. That way a DS-lite = gateway could use a DHCPv4 relay and serve addresses to its local IPv4 = links. The bijective mapping between IPv4 subnets and IPv6 addresses = would permit DS-lite hosts and gateways to tunnel directly over IPv6 = without passing through the service-provider NAT44 gateway. Of course, = DS-lite hosts and gateways could also use IPv4 stateful filtering for = local host and network protection. That's an orthogonal problem. -- james woodyatt member of technical staff, communications engineering From Fred.L.Templin@boeing.com Tue Nov 24 11:26:23 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CACEF3A68CF; Tue, 24 Nov 2009 11:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOg0Q2waJpJS; Tue, 24 Nov 2009 11:26:23 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id D82DA3A67C1; Tue, 24 Nov 2009 11:26:22 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id nAOJQ0IX026452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 13:26:04 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id nAOJPxx1005473; Tue, 24 Nov 2009 11:25:59 -0800 (PST) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id nAOJPxNR005458 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 24 Nov 2009 11:25:59 -0800 (PST) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Tue, 24 Nov 2009 11:25:59 -0800 From: "Templin, Fred L" To: Ted Lemon Date: Tue, 24 Nov 2009 11:25:57 -0800 Thread-Topic: [dhcwg] Comments on draft-templin-isatap-dhcp-03.txt Thread-Index: AcptNM2AGErlFiIrT6W+LQ3JHjhRfgABZORw Message-ID: <12F4112206976147A34FEC0277597CCF27A5334E3A@XCH-NW-15V.nw.nos.boeing.com> References: <12F4112206976147A34FEC0277597CCF27A5334DC9@XCH-NW-15V.nw.nos.boeing.com> <6559FA66-6630-446B-A7A5-34702B1C370F@fugue.com> <12F4112206976147A34FEC0277597CCF27A5334DFD@XCH-NW-15V.nw.nos.boeing.com> <5A004983-F949-4629-91D3-AA1DC0DD65B4@fugue.com> In-Reply-To: <5A004983-F949-4629-91D3-AA1DC0DD65B4@fugue.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: "softwires@ietf.org" , dhc WG Subject: Re: [Softwires] [dhcwg] Comments on draft-templin-isatap-dhcp-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 19:26:23 -0000 Hi Ted, > -----Original Message----- > From: Ted Lemon [mailto:mellon@fugue.com] > Sent: Tuesday, November 24, 2009 10:33 AM > To: Templin, Fred L > Cc: softwires@ietf.org; dhc WG > Subject: Re: [dhcwg] Comments on draft-templin-isatap-dhcp-03.txt >=20 > On Nov 24, 2009, at 1:13 PM, Templin, Fred L wrote: > > In other words, > > in my understanding the lease lifetime is primarily about > > how often one must refresh their IPv4 address delegation > > lifetimes - so, shouldn't that be decoupled from how > > often one must refresh their DNS FQDN resolutions? >=20 > In the abstract, sure, they should be decoupled. However, that is not t= he only value that needs to > be considered, and I think if you consider all the values, this one doesn= 't dominate. Bear in mind > that DNS TTLs don't specify a sharp edge when the data will be refreshed,= so you don't get much > benefit from relying on the DNS TTL rather than the lease time. If you = want to have a sharp edge, > you need a new protocol that leases ISATAP Potential Router List lifetime= s. >=20 > So given that you don't actually get that sharp edge from the DNS TTL, I = just don't think it adds > much value to prefer the DNS TTL over the lease time as a lifetime for th= e Potential Router List. > On a practical level, the network administrator is just going to have to = be aware that there is going > to be a period after changing the ISATAP router DNS entries when some cli= ents will have the old > addresses, and some clients will have the new addresses, and the network = infrastructure will have to > be configured to work correctly during that changeover period. OK, now memories are coming back to me. It's not that I want a sharp edge such that ISATAP clients would be updated immediately upon administrative change actions; I know that I won't get that in either the DHCP or DNS cases. But, the reason I want the flexibility of getting FQDNs is that some ISATAP sites might use a site-specific name service other than the DNS (e.g., mDNS or LLMNR) that may not even be accessible to the DHCP server. In some cases, the DHCP server may be located far away from the site (e.g., in a backhaul network and reachable only by a chain of one or several DHCP relays) while the Potential Router List for the site might be changing rather dynamically. In such cases, the ISATAP client can learn a rather static FQDN from the DHCP server (e.g., isatap.example.com) then give an mDNS/LLMNR shout-out to discover the list of ISATAP routers in the site. In highly-dynamic networks, the list may change rather frequently such that the ISATAP clients (and not the DHCP server) are in the best position to do the name resolution. Fred fred.l.templin@boeing.com From behcetsarikaya@yahoo.com Tue Nov 24 15:14:59 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B6F83A67C1 for ; Tue, 24 Nov 2009 15:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neoctkpVMnTP for ; Tue, 24 Nov 2009 15:14:58 -0800 (PST) Received: from web111402.mail.gq1.yahoo.com (web111402.mail.gq1.yahoo.com [67.195.15.138]) by core3.amsl.com (Postfix) with SMTP id B81DE3A67AF for ; Tue, 24 Nov 2009 15:14:58 -0800 (PST) Received: (qmail 75275 invoked by uid 60001); 24 Nov 2009 23:14:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1259104492; bh=UIrPElroSo5BKgF6n+Jus6OVgWL35MyUyFBd5wa39j0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=sOW5+7D7JlQKVB+DoNiVG0Cni6qK/b9M0d3i2mtjDNyiJKjskOWGmqwb4XOxXmcjwsVqvvn6orVvnHK7PVmm+IxVym5AZ0kv0PsBWnItH7DWAUcYz04LRmhN0ZJTfSiToURWbKjRnnrgrX3Xhkh53Q/NItr59AeYs7h/0x+y0UQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=B9nMO4MVvz4Bfy+Ba0Eb4f5iTH8a4gs8W0dHwgiyjA1gkVkblBQ2nx66U8KSqaJxdpiiEou0Np9p9IuNch0GTu/rrxV8t5tDfhYJYDeXBL3POYjgDKqYPmvf0ZjnRKbhrEiTBAQ47TV5Jar7JAhA471NGUJzY5PUw0/I84p6WNo=; Message-ID: <819114.75243.qm@web111402.mail.gq1.yahoo.com> X-YMail-OSG: Dpez2JAVM1nOXTvkjQNFzZK0.xmSQZqoix7Oy5z27DKysBHatei4lbNfRv.nXVbMu8OCb_DT2eT1EzMaxAnF6L9F4d.GubrhriDX6aq241FEavYNmutlL1hq2UcJ7NU8Wqyrtxhs9ilsuaenGsQfGMNXyQnD1K5IfQue.uAuo4U7c89zV.rnPb98fmNTN5X5VLRyFsa.1guLssew8UUZrUdpYoVL010ME9yMHdLedWCpYWx4h9sz9csTZd1lv8foc.uhmJkxxluFf9AUuuqLRHOwv405IWC4OePJYLNOCxvhaYlnst4YQ0YpOoCwdjezxBEvVh7THEGBx75UbLC2xij9Mw4Ku0qpvJbZ_3f6 Received: from [206.16.17.212] by web111402.mail.gq1.yahoo.com via HTTP; Tue, 24 Nov 2009 15:14:52 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.8.100.260964 References: <1d38a3350911222319p20913cd7lb21a00fa1971cd61@mail.gmail.com> <1d38a3350911240837i1ae15cf7i5a49f4238729f54d@mail.gmail.com> Date: Tue, 24 Nov 2009 15:14:52 -0800 (PST) From: Behcet Sarikaya To: Sri Gundavelli , Hui Deng In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 23:14:59 -0000 Hi Hui, Sri,=0A=0A=0A=0A----- Original Message ----=0A> From: Sri Gundavell= i =0A> To: Hui Deng =0A> Cc: softw= ires@ietf.org=0A> Sent: Tue, November 24, 2009 11:38:55 AM=0A> Subject: Re:= [Softwires] Discussion on the requirements of Host Based Translation=0A> = =0A> Hi Hui,=0A> =0A> =0A> On Tue, 24 Nov 2009, Hui Deng wrote:=0A> =0A> > = Hi, Sri,=0A> >=0A> > 1) Regarding overlapping case, I am assuming=A0 that G= W-Init-DS-Lite=0A> > assign the same Ipv4 address to the UE?=0A> =0A> Sure,= the same IPv4 address can be allocated as in DS lite base proposal.=0A> = =0A> > 2) You are proposing add new bullet, but that is not our requirement= ,=0A> > we are not compare the solution, just do requirement gap analysis,= =0A> =0A> Changes to the host is not a "requirement". But, its a cost for= =0A> a specific solution. When you are comparing multiple solutions,=0A> it= s logical you present both the key positive and negative aspects=0A> of the= solution. Minor aspects, you can hide or ignore. But, host=0A> change is a= significant point of discussion, that you cant avoid=0A> to discuss. But, = its your slide and your call.=0A> =0A> =0A> > 3) I got your point that host= to host communication will be done by=0A> > Access router, you are assumin= g point to point to AR=0A> > other than shared link.=0A> >=0A> =0A> Mobile = architectures, CDMA, LTE, or WiMAX or based on point to point=0A> link mode= ls on the access link. Mobile architectures is one of the=0A> key areas whe= re the Gateway Initiated DS lite solution can be applied.=0A> For other arc= hitectures where shared links are in place, the access=0A> router maintains= the association between the MAC/IP/GRE Key, so it can=0A> L2 forward the I= P packet based on the state.=0A> =0A=0AAbsolutely.=0A=0AI would even go as = far as to say that the packet should go upstream to an anchor node such as = GGSN/P-GW in 3GPP=A0or HA/LMA in WiMAX. Access router doing the host to hos= t communication is possible only for Simple IP case in WiMAX at ASN-GW.=0A= =0ARegards,=0A=0ABehcet=0A=0A=0A=0A From Washam.Fan@huaweisymantec.com Tue Nov 24 23:03:33 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 733843A69D6 for ; Tue, 24 Nov 2009 23:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.373 X-Spam-Level: X-Spam-Status: No, score=0.373 tagged_above=-999 required=5 tests=[AWL=-0.621, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSx6yAsSoY-c for ; Tue, 24 Nov 2009 23:03:32 -0800 (PST) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id B04423A67FC for ; Tue, 24 Nov 2009 23:03:32 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KTN004QUKXHH280@hstga01-in.huaweisymantec.com> for softwires@ietf.org; Wed, 25 Nov 2009 15:03:17 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KTN002WXKXHTX10@hstml01-in.huaweisymantec.com> for softwires@ietf.org; Wed, 25 Nov 2009 15:03:17 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 25 Nov 2009 15:03:17 +0800 From: WashamFan To: softwires@ietf.org Message-id: Date: Wed, 25 Nov 2009 15:03:17 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal Subject: [Softwires] 6rd SP prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 07:03:33 -0000 Hi, sec6.1: The 6rd IPv6 prefix includes the domain ID embedded within it, sizing the v6prefix-length accordingly to cover both the 6rd SP prefix size and domain ID for this 6rd route entry. Neither figure 1 nor other place illustrate how domain ID embedded in 6rd SP prefix. There is no domain ID definition either. Besides, v6prefix-length indicates the length of SP prefix (not 6rd SP prefix), right? if yes, how could 6rd CE extract 6rd SP prefix from SP 6rd IPv6 prefix field in the DHCP option (i.e. how to figure out the bit seperating the prefix and padding zeros?) 6rd SP prefix defined in terminology section, but SP 6rd prefix appears almost anywhere. Shouldn't it be consistent? washam From Washam.Fan@huaweisymantec.com Tue Nov 24 23:09:18 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B6F53A699D for ; Tue, 24 Nov 2009 23:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.136 X-Spam-Level: * X-Spam-Status: No, score=1.136 tagged_above=-999 required=5 tests=[AWL=-0.969, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHuFKRdx0GqL for ; Tue, 24 Nov 2009 23:09:17 -0800 (PST) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 59A863A681A for ; Tue, 24 Nov 2009 23:09:17 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Content-type: text/plain; charset=windows-1252 Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KTN004TTL72H280@hstga01-in.huaweisymantec.com> for softwires@ietf.org; Wed, 25 Nov 2009 15:09:02 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KTN002UEL72Q810@hstml01-in.huaweisymantec.com> for softwires@ietf.org; Wed, 25 Nov 2009 15:09:02 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 25 Nov 2009 15:09:02 +0800 From: WashamFan To: softwires@ietf.org Message-id: Date: Wed, 25 Nov 2009 15:09:02 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal Content-transfer-encoding: quoted-printable Subject: [Softwires] 6rd deployment vs. 6rd domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 07:09:18 -0000 Hi=2C Are they the same=3F according to the draft=2C my impression is yes=2E But according to the 6rd ppts presented in ietf75=2C page14=2C bullet 1=3A= An SP may subdivide a 6rd deployment into separate =936rd Domains=94 = in order to=3A It seemed a deployment spans multiple domains=2E Is it appropriate to add the terms to sec3=3F washam From townsley@cisco.com Wed Nov 25 03:56:34 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9F963A6910 for ; Wed, 25 Nov 2009 03:56: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6-V4JscVcAC for ; Wed, 25 Nov 2009 03:56:34 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 415B93A67A5 for ; Wed, 25 Nov 2009 03:56:34 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoGAFuqDEurR7Ht/2dsb2JhbACBTZdopGOYAIQyBIFx X-IronPort-AV: E=Sophos;i="4.47,285,1257120000"; d="scan'208";a="440272863" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 25 Nov 2009 11:56:29 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAPBuTkK007222; Wed, 25 Nov 2009 11:56:29 GMT Received: from Townsley-MacBook.local (ams-townsley-8714.cisco.com [10.55.233.229]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id nAPBuSW09223; Wed, 25 Nov 2009 03:56:29 -0800 (PST) Message-ID: <4B0D1B68.7010308@cisco.com> Date: Wed, 25 Nov 2009 12:56:24 +0100 From: Mark Townsley User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: WashamFan References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: softwires@ietf.org Subject: Re: [Softwires] 6rd deployment vs. 6rd domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 11:56:35 -0000 An SP may deploy 6rd a as a single 6rd domain, or may split the deployment into multiple domains. From the perspective of the protocol, each domain in standalone in nature whether there is a 1:1 relationship between a domain and an SP or an N:1 relationship among multiple domains and an SP. Operationally, there are differences to consider, in particular some of the looping issues we talked about at the last IETF meeting and on the list leading up to it. - Mark WashamFan wrote: > Hi, > > Are they the same? according to the draft, my impression is yes. > But according to the 6rd ppts presented in ietf75, page14, bullet 1: > > An SP may subdivide a 6rd deployment into separate “6rd Domains” > in order to: > > It seemed a deployment spans multiple domains. Is it appropriate > to add the terms to sec3? > > washam > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > From townsley@cisco.com Wed Nov 25 04:52:56 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDA8E3A6A25 for ; Wed, 25 Nov 2009 04:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVohbtw4GC0E for ; Wed, 25 Nov 2009 04:52:56 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 232DA3A6A24 for ; Wed, 25 Nov 2009 04:52:56 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgFAD+3DEurR7Hu/2dsb2JhbACZNaUAl36EMgSBcQ X-IronPort-AV: E=Sophos;i="4.47,286,1257120000"; d="scan'208";a="440306919" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 25 Nov 2009 12:52:51 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nAPCqpos016913; Wed, 25 Nov 2009 12:52:51 GMT Received: from ams-townsley-8714.cisco.com (ams-townsley-8714.cisco.com [10.55.233.229]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id nAPCqoW13246; Wed, 25 Nov 2009 04:52:50 -0800 (PST) Message-ID: <4B0D289E.5090303@cisco.com> Date: Wed, 25 Nov 2009 13:52:46 +0100 From: Mark Townsley User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: WashamFan References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org Subject: Re: [Softwires] 6rd SP prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 12:52:57 -0000 WashamFan wrote: > Hi, > > sec6.1: > > The 6rd IPv6 prefix includes the domain ID embedded within it, sizing > the v6prefix-length accordingly to cover both the 6rd SP prefix size > and domain ID for this 6rd route entry. > > Neither figure 1 nor other place illustrate how domain ID embedded in > 6rd SP prefix. There is no domain ID definition either. > In earlier versions of the document, identifying the domain ID specifically seemed helpful. However, after presenting 6rd many times and gaining feedback from reviewers, it actually seemed to cause more confusion than it was worth (...Particularly among implementors. Operationally, it was nice to see the domain ID specifically in the protocol, but as this is more of an implementation spec, it's probably better overall without it). It looks like this Domain ID reference is a bit of a holdover from that, and I think should be removed. Multiple domains are of course still supported, just via separate 6rd prefixes.... which works out to essentially the same thing. > Besides, v6prefix-length indicates the length of SP prefix (not 6rd SP > prefix), right? if yes, how could 6rd CE extract 6rd SP prefix from > SP 6rd IPv6 prefix field in the DHCP option (i.e. how to figure out > the bit seperating the prefix and padding zeros?) > v6prefix-length should refer to the "6rd Prefix" ... I can see that "SP 6rd Prefix" causes confusion. Perhaps just dropping "SP" here is the best thing to do. > 6rd SP prefix defined in terminology section, but SP 6rd prefix appears > almost anywhere. Shouldn't it be consistent? > Yes. Perhaps we should just drop "SP" entirely here. We'll get that in the next rev which should be out Real Soon Now! Thanks for the review! - Mark > washam > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > From denghui02@gmail.com Wed Nov 25 06:55:14 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F50D28C225 for ; Wed, 25 Nov 2009 06:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvD4DYNPrfF8 for ; Wed, 25 Nov 2009 06:55:13 -0800 (PST) Received: from mail-px0-f186.google.com (mail-px0-f186.google.com [209.85.216.186]) by core3.amsl.com (Postfix) with ESMTP id AB5853A691E for ; Wed, 25 Nov 2009 06:55:13 -0800 (PST) Received: by pxi16 with SMTP id 16so5520066pxi.29 for ; Wed, 25 Nov 2009 06:55:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=y2tYL/oDqX3oBXfdAqceYhAQcDznYfWXpDomQcuc6Gg=; b=NU40yhEVFcg+ame6XPTajxQ7KF0NvOQFznHond9S81LKTEpdtgAWSP5rZtkXIxGiZC 7c9JS7YJgOBNF4tSUeG5qQzs4teURjiw7Mx7Y8iBON1+DMAP+mlf0gs+90Ff8K8AVYkp qiTbi8vbpFjbMemPb83Cldb9gvrhPNQXSnWls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Mb/3wcvo2zHFc0CccLSZ6a0amuTWB6oIO16lPzqlcFabjCjZZPG7TZihVAbfEqLl7t VzcRPep2bsfQa3KXCe7QvPKoZdxc5/7BnsJ4NwaSC7ILxfhc0St5oaX4t3eA2l9OtOvO sQ7p7yz6E4fjURkAzpFmAp5YyUVu1qc38ffac= MIME-Version: 1.0 Received: by 10.140.164.20 with SMTP id m20mr439911rve.143.1259160905816; Wed, 25 Nov 2009 06:55:05 -0800 (PST) In-Reply-To: References: <1d38a3350911240839u1148ebe7k8e29df01173d1887@mail.gmail.com> Date: Wed, 25 Nov 2009 22:55:05 +0800 Message-ID: <1d38a3350911250655u561ddb85w3dbc32ee2bffb5af@mail.gmail.com> From: Hui Deng To: "Durand, Alain" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf softwire Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 14:55:14 -0000 Besides the above email questions, more below How this solution scale for huge number of subscriber? wouldn't such scope definition is too complex, not easy work for the operations? thanks -Hui 2009/11/25 Durand, Alain : > Say you know both v4 & v6 prefixes associated to the scope. > Say you want to communicate with node B with that v4 scope. > You create a v6 address for B. That v6 address is reverse-derived from B'= s > v4 address. Now, you encapsulate the v4 packet into a v6 packet. > v6 src is yours, v6 dst is B's reverse-derived v6 address. > > =A0- Alain. > > > On 11/24/09 11:39 AM, "Hui Deng" wrote: > >> ok, suppose that you have such smart way to do IPv4 address assignment >> (that is not adopted by IETF, just a remindness) >> then how could you do host to host communication in the IPv6 only networ= k? >> >> thanks for the discussion. >> >> -hui >> >> 2009/11/25 Durand, Alain : >>> This is only require if you do not have a unique IPv4 address per node. >>> What I'm suggesting is to allocate/derive a unique v4 address to each n= ode. >>> It can be done either by running DHCPv4 over the DS-lite tunnel, or def= ining >>> an IPv4 allocation option for DHCPv6 or defining a mechanism to >>> automatically derive a unique v4 address from the DHCPv6 assigned v6 >>> address. >>> >>> =A0- Alain. >>> >>> >>> On 11/24/09 11:29 AM, "Hui Deng" wrote: >>> >>>> so DS-Lite need double translations of NAT44 to support host to host >>>> communication? >>>> >>>> -Hui >>>> >>>> 2009/11/24 james woodyatt : >>>>> On Nov 23, 2009, at 08:53, Durand, Alain wrote: >>>>>> >>>>>> 4 could be a very straightforward extension of DS-lite. If you know = the >>>>>> common IPv6 prefix shared by adjacent nodes, you can directly tunnel= to >>>>>> them. >>>>>> In practice, you=B9ll have a default route to the AFTR and a subnet = route >>>>>> for >>>>>> the =B3local=B2 prefix. >>>>> >>>>> Also, to support the direct host-to-host tunneling, the DS-lite exten= sion >>>>> would need to allow for many DS-lite subscribers to share a single IP= v4 >>>>> private address realm. =A0I think DS-lite currently requires that eac= h IPv6 >>>>> subscriber is isolated within their own IPv4 private address realm, a= nd >>>>> therefore a twice-NAT44 gateway is required for IPv4-only application= s to >>>>> communicate between DS-lite subscribers. >>>>> >>>>> >>>>> -- >>>>> james woodyatt >>>>> member of technical staff, communications engineering >>>>> >>>>> >>>>> _______________________________________________ >>>>> Softwires mailing list >>>>> Softwires@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>> >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> > > From denghui02@gmail.com Wed Nov 25 06:58:48 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 752113A691E for ; Wed, 25 Nov 2009 06:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkGhZvvIfifC for ; Wed, 25 Nov 2009 06:58:47 -0800 (PST) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by core3.amsl.com (Postfix) with ESMTP id 67BFF3A68B4 for ; Wed, 25 Nov 2009 06:58:47 -0800 (PST) Received: by pzk4 with SMTP id 4so5263175pzk.32 for ; Wed, 25 Nov 2009 06:58:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Pb5Vv4qF6zlMdQGHFdoByT6IKIVvW5C64pDqHRtYR/4=; b=pPEQrIxJynN4Sh69qIGGjE2f5jJXzn/kTKkL7Gy7VuESVzu4faTnWdvRpKgHXTTnDj cSzcLfYNpNYOF7CZGGYH26e5OKL91T/qTSqTmAbF7poiv7A2855/08ZaIVQuqwYPcBff NfN0QZ6k6UPoCG63+3pjOB2cGv6mJbELU7byE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=frg1qtk9/GfCzuPYOal+08Re/G6g8KeiVwzVQ0ixLn79iAblzKe7iTtkYuR8kyylN2 eVMrmVgn2SSWUmK2OlftGJFD/y6o7DWB3iOF0s4mpryJzGjB/OTf2U7KahmgbxFO6dXF 1wBSGUfgw/jj4Nwypz2LQUaTCpn+2FmrkjKPE= MIME-Version: 1.0 Received: by 10.140.164.20 with SMTP id m20mr440139rve.143.1259161120288; Wed, 25 Nov 2009 06:58:40 -0800 (PST) In-Reply-To: References: <1d38a3350911222319p20913cd7lb21a00fa1971cd61@mail.gmail.com> <1d38a3350911240837i1ae15cf7i5a49f4238729f54d@mail.gmail.com> Date: Wed, 25 Nov 2009 22:58:40 +0800 Message-ID: <1d38a3350911250658s5ba068e3n6c905ce73262ffde@mail.gmail.com> From: Hui Deng To: Sri Gundavelli Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 14:58:48 -0000 Hi ,Sri, 2009/11/25 Sri Gundavelli : > Hi Hui, > > > On Tue, 24 Nov 2009, Hui Deng wrote: > >> Hi, Sri, >> >> 1) Regarding overlapping case, I am assuming =A0that GW-Init-DS-Lite >> assign the same Ipv4 address to the UE? > > Sure, the same IPv4 address can be allocated as in DS lite base proposal. if you have same IPv4 address, how could route packet directly each other? > >> 2) You are proposing add new bullet, but that is not our requirement, >> we are not compare the solution, just do requirement gap analysis, > > Changes to the host is not a "requirement". But, its a cost for > a specific solution. When you are comparing multiple solutions, > its logical you present both the key positive and negative aspects > of the solution. Minor aspects, you can hide or ignore. But, host > change is a significant point of discussion, that you cant avoid > to discuss. But, its your slide and your call. I guess that we are talking different things, you are always asking compari= sion. but I am talking about the requirements gap analysis. > > >> 3) I got your point that host to host communication will be done by >> Access router, you are assuming point to point to AR >> other than shared link. >> > > Mobile architectures, CDMA, LTE, or WiMAX or based on point to point > link models on the access link. Mobile architectures is one of the > key areas where the Gateway Initiated DS lite solution can be applied. > For other architectures where shared links are in place, the access > router maintains the association between the MAC/IP/GRE Key, so it can > L2 forward the IP packet based on the state. Let's discuss it step by step. for the same IP address, how access router directly route each other for the host? Regards, -Hui > > Regards > Sri > > > >> thanks for the discussion. >> >> -hui >> >> 2009/11/24 Sri Gundavelli : >>> >>> Hi Hui, >>> >>> Adding to what Alain already said. >>> >>> When you projected the slide that compared various transition >>> approaches, for the UE to UE bullet point, for the Gateway >>> Initiated Dual-stack lite solution, you have marked it as >>> "Unsupported or No". So, I asked the question, is it for >>> over-lapping or a non-overlapping case and from our conversations >>> offline and online both at Shanghai and at the IETF, you said >>> it was about non-overlapping case. >>> >>> Now, for this case, in the proposal we have, any IPv4 traffic >>> from the UE, always hits the GGSN over the mobility tunnel. At >>> the GGSN, its a routing decision to forward the traffic to >>> the internet via CGN, over the CGN tunnel, or local foward. If >>> its a local forward, the packet is routed to the target UE/SGSN >>> over a different mobility tunnel. The GGSN is the anchor and >>> all traffic goes through that point and it can local forward. >>> That's how we can support this scenario. >>> >>> For the case of overlapping IP, we talked to many operators >>> and no one confirmed that they have a legacy application that >>> are supported in this mode. So, the general thought was to have a >>> sensible approach of using IPv6 transport for such applications. >>> Now, if we argue that we need to support over IPv4 transport, >>> we need to ask many questions, as how the application resolution >>> happens, how the application server delivers that information >>> and how it learns the NAT'd address of a UE ..etc. These are >>> unresolved questions both as a requirement and even for PNAT >>> if you pitch a solution based on host translation. As I see it, >>> its a new requirement and as Alain/Dan Wing pointed out, there >>> are potential ways to solve it. In simple terms, what ever you >>> do on the host, we can infact solve it on the network. >>> >>> Now, moving to your other pointer and the motivation for the PNAT >>> work, you have listed: >>> >>> a.) a need to support IPv6-only transport network >>> b.) support IPv4 legacy applications, over a IPv6 transport >>> c.) avoid airlink over-ahead >>> d.) enable UE to UE comminication. >>> >>> For #a and #b, mobility architectures and the solution we have allow >>> the case where the access network and the core network is either >>> IPv4 or IPv6. There is no issue on this aspect. >>> >>> For #c, our solution does not introduce any air link over-ahead, as >>> there is no tunnel from the UE. We dont have the host architecture, or >>> touch the UE. >>> >>> For #d, the solution can support UE to UE over IPv4 or IPv6 transport, >>> for the non-overlapping case. For overlapping case, we will plug in the >>> feature as needed. >>> >>> Also, I'd like to remind that your slide missed number of other bullet >>> points, for example, it should have had a bullet point, "Changes to >>> host architecture", with a marking "Yes" to PNAT solution, and "No" to >>> Gateway Initiated Dual-stack lite solution. Since, its not a trivial >>> design point that you can ignore. >>> >>> Regards >>> Sri >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Mon, 23 Nov 2009, Hui Deng wrote: >>> >>>> Dear Alain and Sri, >>>> >>>> I guess that you two have already read below draft: >>>> http://tools.ietf.org/id/draft-cao-behave-hbt-req-00.txt >>>> This draft has been presented in detail during the last IETF meeting. >>>> >>>> During the meeting, you two have standed up and said that >>>> DS-Lite and GW-Init-DS-Lite could also meet the requirement of host to >>>> host direct communication. >>>> I really cann't understand it, could you help to elbaroate more here >>>> about details? >>>> >>>> Many thanks for your kind explanation. >>>> Best regards, >>>> >>>> -Hui Deng >>>> >>> >> > From denghui02@gmail.com Wed Nov 25 06:59:55 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BDD43A69A2 for ; Wed, 25 Nov 2009 06:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wE0HPzFXM5RQ for ; Wed, 25 Nov 2009 06:59:54 -0800 (PST) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by core3.amsl.com (Postfix) with ESMTP id A70CC3A691E for ; Wed, 25 Nov 2009 06:59:54 -0800 (PST) Received: by pzk4 with SMTP id 4so5263951pzk.32 for ; Wed, 25 Nov 2009 06:59:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Fg5hbkMn9wgmIIiEweHthANefLesySdE0UGNWP5edlo=; b=cThyDMMH0QvuZCr2NybpbTFaiuoBqemDq4TkczSdGO52Z1WAz81FfbLuntcV4KUfEK eSBQPRR5y2Fmydm8l0lKXDDCKEc+73JBktixVy2i72TdQ0d9nlUEpI+qQnMKCiYNsQ6t 9uZzs/Yw/VFD27JBkpo8tgBlEbjOCFfIZ6Rac= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=j3t4HATMZQkmnxEF8JC8n5aJR4YSV9+NBvBUBdEYr1fLV9DoHBSzfFEmdIpeipzSp3 zzzZcgzC+i1i++W+7Wu1VTAh+/SHQX3tzYNvRzh3s3ZdHAqueByJrJZLN97JDGV5UgkN /k28JOnCkXvep/oB6dNUqMXhk2mj0c3P2/ccI= MIME-Version: 1.0 Received: by 10.141.4.20 with SMTP id g20mr530617rvi.203.1259161180991; Wed, 25 Nov 2009 06:59:40 -0800 (PST) In-Reply-To: <819114.75243.qm@web111402.mail.gq1.yahoo.com> References: <1d38a3350911222319p20913cd7lb21a00fa1971cd61@mail.gmail.com> <1d38a3350911240837i1ae15cf7i5a49f4238729f54d@mail.gmail.com> <819114.75243.qm@web111402.mail.gq1.yahoo.com> Date: Wed, 25 Nov 2009 22:59:40 +0800 Message-ID: <1d38a3350911250659p2f88ee01lc4c75a05f8e7db54@mail.gmail.com> From: Hui Deng To: Behcet Sarikaya Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 14:59:55 -0000 Hi, Behcet, so there are most other cases, they don't support direct routing. thanks -Hui 2009/11/25 Behcet Sarikaya : > Hi Hui, Sri, > > > > ----- Original Message ---- >> From: Sri Gundavelli >> To: Hui Deng >> Cc: softwires@ietf.org >> Sent: Tue, November 24, 2009 11:38:55 AM >> Subject: Re: [Softwires] Discussion on the requirements of Host Based Tr= anslation >> >> Hi Hui, >> >> >> On Tue, 24 Nov 2009, Hui Deng wrote: >> >> > Hi, Sri, >> > >> > 1) Regarding overlapping case, I am assuming=A0 that GW-Init-DS-Lite >> > assign the same Ipv4 address to the UE? >> >> Sure, the same IPv4 address can be allocated as in DS lite base proposal= . >> >> > 2) You are proposing add new bullet, but that is not our requirement, >> > we are not compare the solution, just do requirement gap analysis, >> >> Changes to the host is not a "requirement". But, its a cost for >> a specific solution. When you are comparing multiple solutions, >> its logical you present both the key positive and negative aspects >> of the solution. Minor aspects, you can hide or ignore. But, host >> change is a significant point of discussion, that you cant avoid >> to discuss. But, its your slide and your call. >> >> >> > 3) I got your point that host to host communication will be done by >> > Access router, you are assuming point to point to AR >> > other than shared link. >> > >> >> Mobile architectures, CDMA, LTE, or WiMAX or based on point to point >> link models on the access link. Mobile architectures is one of the >> key areas where the Gateway Initiated DS lite solution can be applied. >> For other architectures where shared links are in place, the access >> router maintains the association between the MAC/IP/GRE Key, so it can >> L2 forward the IP packet based on the state. >> > > Absolutely. > > I would even go as far as to say that the packet should go upstream to an= anchor node such as GGSN/P-GW in 3GPP=A0or HA/LMA in WiMAX. Access router = doing the host to host communication is possible only for Simple IP case in= WiMAX at ASN-GW. > > Regards, > > Behcet > > > > > From alain_durand@cable.comcast.com Wed Nov 25 07:03:59 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E6D63A6A82 for ; Wed, 25 Nov 2009 07:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.601 X-Spam-Level: *** X-Spam-Status: No, score=3.601 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5Fm4hBbgCdz for ; Wed, 25 Nov 2009 07:03:52 -0800 (PST) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id E5C553A6784 for ; Wed, 25 Nov 2009 07:03:51 -0800 (PST) Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.73467500; Wed, 25 Nov 2009 10:03:33 -0500 Received: from PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 10:03:34 -0500 Received: from 147.191.223.83 ([147.191.223.83]) by PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Nov 2009 15:03:34 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Wed, 25 Nov 2009 10:03:31 -0500 From: "Durand, Alain" To: Hui Deng Message-ID: Thread-Topic: [Softwires] Discussion on the requirements of Host Based Translation Thread-Index: Acpt32VrJmbLoZZPSTSMfclk8rcEUwAAQ4BD In-Reply-To: <1d38a3350911250655u561ddb85w3dbc32ee2bffb5af@mail.gmail.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3341988212_10182833" X-OriginalArrivalTime: 25 Nov 2009 15:03:34.0656 (UTC) FILETIME=[75994000:01CA6DE0] Cc: ietf softwire Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 15:03:59 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3341988212_10182833 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable It is actually fairly easy to scale... Use a copy of Net 10 for each of you= r access router... In the end, this all depend on your access topology, where the first L3 nod= e is and where you intend to put the AFTR. If both are co-located, then solution like gateway initiated DS-lite or simply assigning a regular IPv4 address are really much simpler. If the AFTR is a little further inside the network, the complexity price t= o pay for shortcuts may not be justified. If the AFTR is way inside the network, then shortcuts may be useful. Note: The =8Cv4 scopes=B9 does not have to match the AFTR scope... It has to match the scope of the entity that proxy-manages IP address allocation, typically the first L3 router acting a= s DHCP-relay. - Alain. On 11/25/09 9:55 AM, "Hui Deng" wrote: > Besides the above email questions, more below > How this solution scale for huge number of subscriber? > wouldn't such scope definition is too complex, not easy work for the > operations? >=20 > thanks >=20 > -Hui >=20 > 2009/11/25 Durand, Alain : >> > Say you know both v4 & v6 prefixes associated to the scope. >> > Say you want to communicate with node B with that v4 scope. >> > You create a v6 address for B. That v6 address is reverse-derived from= B's >> > v4 address. Now, you encapsulate the v4 packet into a v6 packet. >> > v6 src is yours, v6 dst is B's reverse-derived v6 address. >> > >> > =A0- Alain. >> > >> > >> > On 11/24/09 11:39 AM, "Hui Deng" wrote: >> > >>> >> ok, suppose that you have such smart way to do IPv4 address assignme= nt >>> >> (that is not adopted by IETF, just a remindness) >>> >> then how could you do host to host communication in the IPv6 only >>> network? >>> >> >>> >> thanks for the discussion. >>> >> >>> >> -hui >>> >> >>> >> 2009/11/25 Durand, Alain : >>>> >>> This is only require if you do not have a unique IPv4 address per = node. >>>> >>> What I'm suggesting is to allocate/derive a unique v4 address to e= ach >>>> node. >>>> >>> It can be done either by running DHCPv4 over the DS-lite tunnel, o= r >>>> defining >>>> >>> an IPv4 allocation option for DHCPv6 or defining a mechanism to >>>> >>> automatically derive a unique v4 address from the DHCPv6 assigned = v6 >>>> >>> address. >>>> >>> >>>> >>> =A0- Alain. >>>> >>> >>>> >>> >>>> >>> On 11/24/09 11:29 AM, "Hui Deng" wrote: >>>> >>> >>>>> >>>> so DS-Lite need double translations of NAT44 to support host to = host >>>>> >>>> communication? >>>>> >>>> >>>>> >>>> -Hui >>>>> >>>> >>>>> >>>> 2009/11/24 james woodyatt : >>>>>> >>>>> On Nov 23, 2009, at 08:53, Durand, Alain wrote: >>>>>>> >>>>>> >>>>>>> >>>>>> 4 could be a very straightforward extension of DS-lite. If y= ou >>>>>>> know the >>>>>>> >>>>>> common IPv6 prefix shared by adjacent nodes, you can directl= y >>>>>>> tunnel to >>>>>>> >>>>>> them. >>>>>>> >>>>>> In practice, you=B9ll have a default route to the AFTR and a s= ubnet route >>>>>>> >>>>>> for >>>>>>> >>>>>> the =B3local=B2 prefix. >>>>>> >>>>> >>>>>> >>>>> Also, to support the direct host-to-host tunneling, the DS-lit= e >>>>>> extension >>>>>> >>>>> would need to allow for many DS-lite subscribers to share a si= ngle IPv4 >>>>>> >>>>> private address realm. =A0I think DS-lite currently requires tha= t >>>>>> each IPv6 >>>>>> >>>>> subscriber is isolated within their own IPv4 private address r= ealm, and >>>>>> >>>>> therefore a twice-NAT44 gateway is required for IPv4-only >>>>>> applications to >>>>>> >>>>> communicate between DS-lite subscribers. >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> -- >>>>>> >>>>> james woodyatt >>>>>> >>>>> member of technical staff, communications engineering >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> _______________________________________________ >>>>>> >>>>> Softwires mailing list >>>>>> >>>>> Softwires@ietf.org >>>>>> >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>> >>>>> >>>>> >>>> _______________________________________________ >>>>> >>>> Softwires mailing list >>>>> >>>> Softwires@ietf.org >>>>> >>>> https://www.ietf.org/mailman/listinfo/softwires >>>> >>> >>>> >>> >> > >> > >=20 --B_3341988212_10182833 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Softwires] Discussion on the requirements of Host Based Transla= tion It is actually fairly easy to scale... Use a copy of Net 10 for each of yo= ur access router...
In the end, this all depend on your access topology, where the first L3 nod= e is and where you intend to put the AFTR.
If both are co-located, then solution like gateway initiated DS-lite or sim= ply assigning a regular IPv4 address are really much simpler.
If the AFTR is a little further inside the network,  the complexity pr= ice to pay for shortcuts may not be justified. If the AFTR is way inside the= network, then shortcuts may be useful. Note: The ‘v4 scopes’ do= es not have to match the AFTR scope... It has to match the scope of the enti= ty that proxy-manages IP address allocation, typically the first L3 router a= cting as DHCP-relay.

  - Alain.


On 11/25/09 9:55 AM, "Hui Deng" <denghui02@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Besides the above email questions, more below How this solution scale for huge number of subscriber?
wouldn't such scope definition is too complex,  not easy work for the<= BR> operations?

thanks

-Hui

2009/11/25 Durand, Alain <alain= _durand@cable.comcast.com>:
> Say you know both v4 & v6 prefixes associated to the scope.
> Say you want to communicate with node B with that v4 scope.
> You create a v6 address for B. That v6 address is reverse-derived from= B's
> v4 address. Now, you encapsulate the v4 packet into a v6 packet.
> v6 src is yours, v6 dst is B's reverse-derived v6 address.
>
> =A0- Alain.
>
>
> On 11/24/09 11:39 AM, "Hui Deng" <denghui02@gmail.com> wrote:
>
>> ok, suppose that you have such smart way to do IPv4 address assign= ment
>> (that is not adopted by IETF, just a remindness)
>> then how could you do host to host communication in the IPv6 only = network?
>>
>> thanks for the discussion.
>>
>> -hui
>>
>> 2009/11/25 Durand, Alain <alain_durand@cable.comcast.com>:
>>> This is only require if you do not have a unique IPv4 address = per node.
>>> What I'm suggesting is to allocate/derive a unique v4 address = to each node.
>>> It can be done either by running DHCPv4 over the DS-lite tunne= l, or defining
>>> an IPv4 allocation option for DHCPv6 or defining a mechanism t= o
>>> automatically derive a unique v4 address from the DHCPv6 assig= ned v6
>>> address.
>>>
>>> =A0- Alain.
>>>
>>>
>>> On 11/24/09 11:29 AM, "Hui Deng" <denghui02@gmail.com> wrote:
>>>
>>>> so DS-Lite need double translations of NAT44 to support ho= st to host
>>>> communication?
>>>>
>>>> -Hui
>>>>
>>>> 2009/11/24 james woodyatt <jhw@= apple.com>:
>>>>> On Nov 23, 2009, at 08:53, Durand, Alain wrote:
>>>>>>
>>>>>> 4 could be a very straightforward extension of DS-= lite. If you know the
>>>>>> common IPv6 prefix shared by adjacent nodes, you c= an directly tunnel to
>>>>>> them.
>>>>>> In practice, you’ll have a default route to = the AFTR and a subnet route
>>>>>> for
>>>>>> the “local” prefix.
>>>>>
>>>>> Also, to support the direct host-to-host tunneling, th= e DS-lite extension
>>>>> would need to allow for many DS-lite subscribers to sh= are a single IPv4
>>>>> private address realm. =A0I think DS-lite currently requ= ires that each IPv6
>>>>> subscriber is isolated within their own IPv4 private a= ddress realm, and
>>>>> therefore a twice-NAT44 gateway is required for IPv4-o= nly applications to
>>>>> communicate between DS-lite subscribers.
>>>>>
>>>>>
>>>>> --
>>>>> james woodyatt <jhw@apple.c= om>
>>>>> member of technical staff, communications engineering<= BR> >>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Softwires mailing list
>>>>> Softwires@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>>>
>>>> _______________________________________________
>>>> Softwires mailing list
>>>> Softwires@ietf.org
>>>> = https://www.ietf.org/mailman/listinfo/softwires
>>>
>>>
>
>

--B_3341988212_10182833-- From mellon@fugue.com Tue Nov 24 09:45:16 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EE583A6911; Tue, 24 Nov 2009 09:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LV5WidiIkXku; Tue, 24 Nov 2009 09:45:15 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by core3.amsl.com (Postfix) with ESMTP id CF04A3A6889; Tue, 24 Nov 2009 09:45:15 -0800 (PST) Received: from [192.168.1.47] (pool-74-108-155-75.nycmny.east.verizon.net [74.108.155.75]) by toccata.fugue.com (Postfix) with ESMTPSA id DF48434E47E2; Tue, 24 Nov 2009 10:48:17 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ted Lemon In-Reply-To: <12F4112206976147A34FEC0277597CCF27A5334DC9@XCH-NW-15V.nw.nos.boeing.com> Date: Tue, 24 Nov 2009 12:45:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6559FA66-6630-446B-A7A5-34702B1C370F@fugue.com> References: <12F4112206976147A34FEC0277597CCF27A5334DC9@XCH-NW-15V.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1077) X-Mailman-Approved-At: Wed, 25 Nov 2009 07:08:25 -0800 Cc: "softwires@ietf.org" , dhc WG Subject: Re: [Softwires] [dhcwg] Comments on draft-templin-isatap-dhcp-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:45:16 -0000 On Nov 24, 2009, at 12:21 PM, Templin, Fred L wrote: > The way ISATAP is currently specified, it expects to get a > connection-specific DNS suffix from the DHCP server (i.e., > from a domain name option) and then self-constructs an FQDN > by prepending the well-known string "isatap" (e.g., as > "isatap.example.com" when the suffix is "example.com"). The > ISATAP client then resolves the FQDN itself by consulting > the DNS. That makes sense. You might want to mention it in the draft... :') However, I will reiterate that the DHCP server configuration never = changes if you just put FQDNs in the configuration and let the DHCP = server resolve them. The ISC server resolves them synchronously and = caches them for an hour; the Nominum server resolves them asynchronously = and assumes that you have a fast local DNS cache, so it doesn't cache = them internally at all. I don't know what other DNS servers do = specifically, but my understanding is that thebehavior is similar. So you get the same behavior whether you let the DHCP server resolve the = FQDN, or whether you make the ISATAP implementation do it, unless you = have really long leases or really short TTLs, neither of which I would = expect to be common practice. So by sending FQDNs it seems like you're setting up an unnecessary = wrestling match between two styles of doing things; I would argue that = for a DHCP-based implementation, you really ought not to do that, if = only because sending FQDNs tends to consume more DHCP packet space, = which is a scarce resource. From mellon@fugue.com Tue Nov 24 09:45:36 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA4333A688E; Tue, 24 Nov 2009 09:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vapqjyxf57P4; Tue, 24 Nov 2009 09:45:36 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by core3.amsl.com (Postfix) with ESMTP id 308B73A682D; Tue, 24 Nov 2009 09:45:36 -0800 (PST) Received: from [192.168.1.47] (pool-74-108-155-75.nycmny.east.verizon.net [74.108.155.75]) by toccata.fugue.com (Postfix) with ESMTPSA id A20A834E468B; Tue, 24 Nov 2009 10:48:38 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ted Lemon In-Reply-To: <12F4112206976147A34FEC0277597CCF27A5334DC9@XCH-NW-15V.nw.nos.boeing.com> Date: Tue, 24 Nov 2009 12:45:30 -0500 Content-Transfer-Encoding: 7bit Message-Id: <552C5FDE-8D31-45CD-BB18-F9CF6DE4AF40@fugue.com> References: <12F4112206976147A34FEC0277597CCF27A5334DC9@XCH-NW-15V.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1077) X-Mailman-Approved-At: Wed, 25 Nov 2009 07:08:25 -0800 Cc: "softwires@ietf.org" , dhc WG Subject: Re: [Softwires] [dhcwg] Comments on draft-templin-isatap-dhcp-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:45:36 -0000 On Nov 24, 2009, at 12:21 PM, Templin, Fred L wrote: > No particular reason; should I try for PS? Yes. From mellon@fugue.com Tue Nov 24 10:33:23 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE4AE3A67EA; Tue, 24 Nov 2009 10:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWocnpgC5Lcx; Tue, 24 Nov 2009 10:33:23 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by core3.amsl.com (Postfix) with ESMTP id 3FC8B3A67C1; Tue, 24 Nov 2009 10:33:23 -0800 (PST) Received: from [192.168.1.47] (pool-74-108-155-75.nycmny.east.verizon.net [74.108.155.75]) by toccata.fugue.com (Postfix) with ESMTPSA id 9C73A34E465F; Tue, 24 Nov 2009 11:36:25 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ted Lemon In-Reply-To: <12F4112206976147A34FEC0277597CCF27A5334DFD@XCH-NW-15V.nw.nos.boeing.com> Date: Tue, 24 Nov 2009 13:33:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5A004983-F949-4629-91D3-AA1DC0DD65B4@fugue.com> References: <12F4112206976147A34FEC0277597CCF27A5334DC9@XCH-NW-15V.nw.nos.boeing.com> <6559FA66-6630-446B-A7A5-34702B1C370F@fugue.com> <12F4112206976147A34FEC0277597CCF27A5334DFD@XCH-NW-15V.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1077) X-Mailman-Approved-At: Wed, 25 Nov 2009 07:08:25 -0800 Cc: "softwires@ietf.org" , dhc WG Subject: Re: [Softwires] [dhcwg] Comments on draft-templin-isatap-dhcp-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 18:33:24 -0000 On Nov 24, 2009, at 1:13 PM, Templin, Fred L wrote: > In other words, > in my understanding the lease lifetime is primarily about > how often one must refresh their IPv4 address delegation > lifetimes - so, shouldn't that be decoupled from how > often one must refresh their DNS FQDN resolutions? In the abstract, sure, they should be decoupled. However, that is not = the only value that needs to be considered, and I think if you consider = all the values, this one doesn't dominate. Bear in mind that DNS TTLs = don't specify a sharp edge when the data will be refreshed, so you don't = get much benefit from relying on the DNS TTL rather than the lease time. = If you want to have a sharp edge, you need a new protocol that leases = ISATAP Potential Router List lifetimes. So given that you don't actually get that sharp edge from the DNS TTL, I = just don't think it adds much value to prefer the DNS TTL over the lease = time as a lifetime for the Potential Router List. On a practical = level, the network administrator is just going to have to be aware that = there is going to be a period after changing the ISATAP router DNS = entries when some clients will have the old addresses, and some clients = will have the new addresses, and the network infrastructure will have to = be configured to work correctly during that changeover period. From mellon@fugue.com Tue Nov 24 13:11:56 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 745433A6852; Tue, 24 Nov 2009 13:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.98 X-Spam-Level: X-Spam-Status: No, score=-5.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zzrr-l4jzSXi; Tue, 24 Nov 2009 13:11:54 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by core3.amsl.com (Postfix) with ESMTP id 7845C3A6819; Tue, 24 Nov 2009 13:11:54 -0800 (PST) Received: from [192.168.1.43] (pool-173-68-246-74.nycmny.east.verizon.net [173.68.246.74]) by toccata.fugue.com (Postfix) with ESMTPSA id 578F634E47F5; Tue, 24 Nov 2009 14:14:56 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ted Lemon In-Reply-To: <12F4112206976147A34FEC0277597CCF27A5334E3A@XCH-NW-15V.nw.nos.boeing.com> Date: Tue, 24 Nov 2009 16:11:47 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <12F4112206976147A34FEC0277597CCF27A5334DC9@XCH-NW-15V.nw.nos.boeing.com> <6559FA66-6630-446B-A7A5-34702B1C370F@fugue.com> <12F4112206976147A34FEC0277597CCF27A5334DFD@XCH-NW-15V.nw.nos.boeing.com> <5A004983-F949-4629-91D3-AA1DC0DD65B4@fugue.com> <12F4112206976147A34FEC0277597CCF27A5334E3A@XCH-NW-15V.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1077) X-Mailman-Approved-At: Wed, 25 Nov 2009 07:08:25 -0800 Cc: "softwires@ietf.org" , dhc WG Subject: Re: [Softwires] [dhcwg] Comments on draft-templin-isatap-dhcp-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 21:11:56 -0000 On Nov 24, 2009, at 2:25 PM, Templin, Fred L wrote: > But, the reason I want the flexibility of getting > FQDNs is that some ISATAP sites might use a site-specific > name service other than the DNS (e.g., mDNS or LLMNR) > that may not even be accessible to the DHCP server. Bizarre. But sure, okay, that's a good reason. :') From denghui02@gmail.com Wed Nov 25 06:52:20 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 166A628C108 for ; Wed, 25 Nov 2009 06:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y622CIdd1D4f for ; Wed, 25 Nov 2009 06:52:19 -0800 (PST) Received: from mail-px0-f186.google.com (mail-px0-f186.google.com [209.85.216.186]) by core3.amsl.com (Postfix) with ESMTP id 3D6083A6851 for ; Wed, 25 Nov 2009 06:52:19 -0800 (PST) Received: by pxi16 with SMTP id 16so5518280pxi.29 for ; Wed, 25 Nov 2009 06:52:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EP/LzTGFVCuuU9dpigu4iJshh/Y/4V7vroMHuN86OU8=; b=YlMFBIyLfkAqZAJ8gW0jzrI/6TaR1RRo2eQRfqBjsbPj94bzTPIQWeYbdQhYT1xVaD QQjgSorSc7UEQisNvi/mzNxOVF2uaM32vK/RPePRlRpAyTkrNIRzEfxILoXnIxBBsjCC 3Vc76h+zTFV5EWB/wBrRy72THSoa+Lz/V19Ts= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=r+mVBs6wgVFW0Sj0d6KQh7ea8/yr9hy9ez+/ZHTfTlvbkWA2Y/sy5EdQfu0vYk2K8Q 5CmMFlATnHABBkEZ6XlEK7338XDPtMWDIDNOc8IBsOGu3vKCaDU1+vakv/+Kijh6/PwR IqhfMARA9VsPIqYTmNpBbz3t5otDh+x8j4NMk= MIME-Version: 1.0 Received: by 10.141.21.12 with SMTP id y12mr460933rvi.248.1259160730276; Wed, 25 Nov 2009 06:52:10 -0800 (PST) In-Reply-To: References: <1d38a3350911240825r5f3d54e7i96cdedb7a64fb430@mail.gmail.com> Date: Wed, 25 Nov 2009 22:52:10 +0800 Message-ID: <1d38a3350911250652o3009f06ay8675900711644ee3@mail.gmail.com> From: Hui Deng To: "Durand, Alain" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 25 Nov 2009 07:08:25 -0800 Cc: fengcao@chinamobile.com, liudapeng@chinamobile.com, chengang@chinamobile.com, zhouboyj@chinamobile.com, "Cao, Zhen" , softwires@ietf.org Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 14:52:20 -0000 Let's continue discuss and will summarize after 2009/11/25 Durand, Alain : > > > > On 11/24/09 11:25 AM, "Hui Deng" wrote: > >>> You can use some form of header compression to mitigate this overhead. = How >>> to use header compression in that case can be defined in softwire >> it is not that easy to do backward compatibility, and it's really hard >> to use it today > > There are games we can play to "port" the relevant v4 header fields in th= e > v6 header and remove the v4 header all together... As long as this is don= e > on a link between two consenting nodes, this is fine. =3D=3D> what u suggest here is still same as the header compression. > >>> 4 could be a very straightforward extension of DS-lite. If you know the >>> common IPv6 prefix shared by adjacent nodes, you can directly tunnel to >>> them. >> I don't understand here, are you suggesting all DS-Lite host has common = IPv6 >> prefix? what kind of direct tunnel could be established? > > What I'm suggesting is to define a 'scope' in which nodes can talk direct= ly > using the shortcuts. It makes little sense to 'short cut' with a node on = the > other side of the country, but I understand why you'd want to do this > between two nodes that are behind the same base station. > > Within the scope, each node has a unique v6 address and a unique v4 addre= ss. > (again, either derived from the v6 or assigned via DHCP). Net 10 should b= e > big enough for that. > > You pass both v6 and v4 prefixes via DHCPv6 to all nodes within that scop= e. > That way, when a node sees that the IPv4 address returned by (say split) = DNS > is within the v4 prefix, it can use the v6 prefix to 'tunnel/route' the > packets. if the application generate IPv4 packet, and finally you will be use IPv6 to transmit this packet, isn't this a translation? Secondly, when the receiver host got this packet, how could he know this is normal IPv6 packet or IPv4-translated-IPv6 packet? thanks again -Hui > > =A0 - Alain. > > From alain_durand@cable.comcast.com Wed Nov 25 07:10:45 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5288D28C225 for ; Wed, 25 Nov 2009 07:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.408 X-Spam-Level: **** X-Spam-Status: No, score=4.408 tagged_above=-999 required=5 tests=[AWL=-1.007, BAYES_40=-0.185, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXcelGDufmt0 for ; Wed, 25 Nov 2009 07:10:44 -0800 (PST) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id C74C63A6A8A for ; Wed, 25 Nov 2009 07:10:43 -0800 (PST) Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.73467996; Wed, 25 Nov 2009 10:10:24 -0500 Received: from PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 10:10:25 -0500 Received: from 147.191.223.83 ([147.191.223.83]) by PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Nov 2009 15:10:25 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Wed, 25 Nov 2009 10:10:23 -0500 From: "Durand, Alain" To: ietf softwire Message-ID: Thread-Topic: Mailing list maintenance Thread-Index: Acpt4Wj9d1MeeC5eak+pcCvXPjM95A== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3341988623_10242683" X-OriginalArrivalTime: 25 Nov 2009 15:10:25.0781 (UTC) FILETIME=[6AA5F250:01CA6DE1] Subject: [Softwires] Mailing list maintenance X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 15:10:45 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3341988623_10242683 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Please remember that this list has a policy to restrict posts to subscribers. There is also limit on the number of recipient (before it is considered spam) and on the size of the messages. Nothing out of the standard for IETF lists. - Alain. --B_3341988623_10242683 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Mailing list maintenance Please remember that this list has a policy to restrict posts to subscribe= rs. There is also  limit on the number of recipient (before it is consi= dered spam) and on the size of the messages. Nothing out of the standard for= IETF lists.

   - Alain. --B_3341988623_10242683-- From alain_durand@cable.comcast.com Wed Nov 25 07:08:14 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D4943A6A81 for ; Wed, 25 Nov 2009 07:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.301 X-Spam-Level: *** X-Spam-Status: No, score=3.301 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kq0wGfDwvj2V for ; Wed, 25 Nov 2009 07:08:13 -0800 (PST) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 9ED863A6851 for ; Wed, 25 Nov 2009 07:08:13 -0800 (PST) Received: from ([10.195.246.152]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.83104641; Wed, 25 Nov 2009 10:07:43 -0500 Received: from PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 10:07:43 -0500 Received: from 147.191.223.83 ([147.191.223.83]) by PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Nov 2009 15:07:43 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Wed, 25 Nov 2009 10:07:41 -0500 From: "Durand, Alain" To: Hui Deng Message-ID: Thread-Topic: Discussion on the requirements of Host Based Translation Thread-Index: Acpt3wWgOwTDut/KQhKaLxswlGKohgAAgLO9 In-Reply-To: <1d38a3350911250652o3009f06ay8675900711644ee3@mail.gmail.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3341988461_10242188" X-OriginalArrivalTime: 25 Nov 2009 15:07:43.0947 (UTC) FILETIME=[0A3009B0:01CA6DE1] X-Mailman-Approved-At: Wed, 25 Nov 2009 07:11:04 -0800 Cc: fengcao@chinamobile.com, liudapeng@chinamobile.com, chengang@chinamobile.com, zhouboyj@chinamobile.com, "Cao, Zhen" , softwires@ietf.org Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 15:08:14 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3341988461_10242188 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 11/25/09 9:52 AM, "Hui Deng" wrote: > > if the application generate IPv4 packet, and finally you will be use > IPv6 to transmit this packet, > isn't this a translation? > > --> No, this is tunneling. You preserver the v4 header. If header compression > removes it, it it put back in place on the receiving side > > Secondly, when the receiver host got this packet, how could he know > this is normal IPv6 packet > or IPv4-translated-IPv6 packet? > > --> This is not translated, but tunneled. The packet arrives to a tunnel > interface that will de-capsulate the v6 header and present the v4 packet to > the v4 app. Think about 6to4 or 6rd, but with the reverse encap. > > - Alain. > --B_3341988461_10242188 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: Discussion on the requirements of Host Based Translation


On 11/25/09 9:52 AM, "Hui Deng" <denghui02@gmail.com> wrote:
<= SPAN STYLE=3D'font-size:11pt'>
if the application generate IPv4 packet, and finally you will be use
IPv6 to transmit this packet,
isn't this a translation?

--> No, this is tunneling. You preserver the v4 header. If header compre= ssion removes it, it it put back in place on the receiving side

Secondly, when the receiver host got this packet, how could he know
this is normal IPv6 packet
or IPv4-translated-IPv6 packet?

--> This is not translated, but tunneled. The packet arrives to a tunnel= interface that will de-capsulate the v6 header and present the v4 packet to= the v4 app. Think about 6to4 or 6rd, but with the reverse encap.

    - Alain.

--B_3341988461_10242188-- From denghui02@gmail.com Wed Nov 25 07:42:29 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 064FE3A6A78 for ; Wed, 25 Nov 2009 07:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgiqFi5vLZHG for ; Wed, 25 Nov 2009 07:42:28 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 3EE533A6863 for ; Wed, 25 Nov 2009 07:42:27 -0800 (PST) Received: by pwi6 with SMTP id 6so5377859pwi.29 for ; Wed, 25 Nov 2009 07:42:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vazlSI9tinouUXIOb6einGvC+7U6QtAlaGkCKt0aFLA=; b=VYfWVq7t06vxe7JnOZbLgkOxatf5UGrRk1ZoB5IrMyubJqrmzSBcOka9b1oYP7715i oXbzlFW0ungPocil1vWJVJvIeoBcltPuz30nRoaRcb1cmn7BjQPWXkXdz1SU+1nTh8lp 9fdxitOoOwnUWpSbUNRzETF0JhllYP/RBMfQg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Cn4Zhh3owxripBVaPXVo7h1UNFOokogxXPSryqsUzq8Q5KLBDwtu+rq18fI7D2ySqr ehmVMoPwcaOz9afJWN912j9zagAutnKjE2AmLBazK1p70fE2Ne0IXuX8BNVaE4psGmcn CCh1A2MHou+Ii2Rm6WEoNCHdQodNi8xhcXGe4= MIME-Version: 1.0 Received: by 10.140.134.17 with SMTP id h17mr479836rvd.282.1259163739777; Wed, 25 Nov 2009 07:42:19 -0800 (PST) In-Reply-To: References: <1d38a3350911250652o3009f06ay8675900711644ee3@mail.gmail.com> Date: Wed, 25 Nov 2009 23:42:19 +0800 Message-ID: <1d38a3350911250742g39a19632td66ea3aeb67141f0@mail.gmail.com> From: Hui Deng To: "Durand, Alain" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: fengcao@chinamobile.com, softwires@ietf.org Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 15:42:29 -0000 inline please 2009/11/25 Durand, Alain : > > > > On 11/25/09 9:52 AM, "Hui Deng" wrote: > > if the application generate IPv4 packet, and finally you will be use > IPv6 to transmit this packet, > isn't this a translation? > > --> No, this is tunneling. You preserver the v4 header. If header > compression removes it, it it put back in place on the receiving side I don't know this is tunnleing, then how this tunneling is setup between two hosts directly? Are you assuming what kind of destination address the source host can get (IPv4 A record or IPv6 AAAA record)? > > Secondly, when the receiver host got this packet, how could he know > this is normal IPv6 packet > or IPv4-translated-IPv6 packet? > > --> This is not translated, but tunneled. The packet arrives to a tunnel > interface that will de-capsulate the v6 header and present the v4 packet = to > the v4 app. Think about 6to4 or 6rd, but with the reverse encap. Same questions above, are you assuming the destination have to support it as well? thanks -Hui > > =A0=A0=A0=A0- Alain. > > From denghui02@gmail.com Wed Nov 25 07:47:19 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86ECB3A6A5E for ; Wed, 25 Nov 2009 07:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MelcNi2b+2H for ; Wed, 25 Nov 2009 07:47:18 -0800 (PST) Received: from mail-px0-f186.google.com (mail-px0-f186.google.com [209.85.216.186]) by core3.amsl.com (Postfix) with ESMTP id 9CEF63A6A4E for ; Wed, 25 Nov 2009 07:47:18 -0800 (PST) Received: by pxi16 with SMTP id 16so5552421pxi.29 for ; Wed, 25 Nov 2009 07:47:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1MG2Wwj0YfjQlAaW1WmGVUyu/HE7XgK57CAuhVSw2zs=; b=d4satqcjvXGUsvwSGQPHUmaWX3gtFCnL8+k8O4rH3HpabDSwxti1hAh737opHsWlAh zMXTf1qwZsGWOsEeLR05DB+kCGjch+S5asnqofcRAu55DiqOEhKKdU3j+/Wwm2q+BKCf 0tIJgLupqq3Ek0Iy6I7MSIOFiqYq2lVlQPfSg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=iJs/jcdU1ECWfpxnXspVsyzoAS2252YeiYEHv3KEPrCSM+HXcFAw7ketZCjsUXBdKq XeKkaQu/oAr40eI9rAitJ7sCdmVZJJJQ3zxw+nX8JE/Ld7IDOFlaRSCHxtR6zWoZ7G2f JjrNcmm8ekg8m+IHWustKyRFts4IvuTarwe6M= MIME-Version: 1.0 Received: by 10.140.164.20 with SMTP id m20mr443268rve.143.1259164024917; Wed, 25 Nov 2009 07:47:04 -0800 (PST) In-Reply-To: References: <1d38a3350911250655u561ddb85w3dbc32ee2bffb5af@mail.gmail.com> Date: Wed, 25 Nov 2009 23:47:04 +0800 Message-ID: <1d38a3350911250747s48cfa5f2na4b2a1285e31f75c@mail.gmail.com> From: Hui Deng To: "Durand, Alain" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: ietf softwire Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 15:47:19 -0000 Inline please 2009/11/25 Durand, Alain : > It is actually fairly easy to scale... Use a copy of Net 10 for each of y= our > access router... then inter access router doesn't work > In the end, this all depend on your access topology, where the first L3 n= ode > is and where you intend to put the AFTR. exactly, for my knowledge, this L3 node is not the same location as NAT. > If both are co-located, then solution like gateway initiated DS-lite or > simply assigning a regular IPv4 address are really much simpler. > If the AFTR is a little further inside the network, =A0the complexity pri= ce to > pay for shortcuts may not be justified. If the AFTR is way inside the > network, then shortcuts may be useful. Note: The =91v4 scopes=92 does not= have > to match the AFTR scope... It has to match the scope of the entity that > proxy-manages IP address allocation, typically the first L3 router acting= as > DHCP-relay. isn't it sounds complexity network operation, it will be quite hard to support roaming. -Hui > > =A0=A0- Alain. > > > On 11/25/09 9:55 AM, "Hui Deng" wrote: > > Besides the above email questions, more below > How this solution scale for huge number of subscriber? > wouldn't such scope definition is too complex, =A0not easy work for the > operations? > > thanks > > -Hui > > 2009/11/25 Durand, Alain : >> Say you know both v4 & v6 prefixes associated to the scope. >> Say you want to communicate with node B with that v4 scope. >> You create a v6 address for B. That v6 address is reverse-derived from B= 's >> v4 address. Now, you encapsulate the v4 packet into a v6 packet. >> v6 src is yours, v6 dst is B's reverse-derived v6 address. >> >> =A0- Alain. >> >> >> On 11/24/09 11:39 AM, "Hui Deng" wrote: >> >>> ok, suppose that you have such smart way to do IPv4 address assignment >>> (that is not adopted by IETF, just a remindness) >>> then how could you do host to host communication in the IPv6 only >>> network? >>> >>> thanks for the discussion. >>> >>> -hui >>> >>> 2009/11/25 Durand, Alain : >>>> This is only require if you do not have a unique IPv4 address per node= . >>>> What I'm suggesting is to allocate/derive a unique v4 address to each >>>> node. >>>> It can be done either by running DHCPv4 over the DS-lite tunnel, or >>>> defining >>>> an IPv4 allocation option for DHCPv6 or defining a mechanism to >>>> automatically derive a unique v4 address from the DHCPv6 assigned v6 >>>> address. >>>> >>>> =A0- Alain. >>>> >>>> >>>> On 11/24/09 11:29 AM, "Hui Deng" wrote: >>>> >>>>> so DS-Lite need double translations of NAT44 to support host to host >>>>> communication? >>>>> >>>>> -Hui >>>>> >>>>> 2009/11/24 james woodyatt : >>>>>> On Nov 23, 2009, at 08:53, Durand, Alain wrote: >>>>>>> >>>>>>> 4 could be a very straightforward extension of DS-lite. If you know >>>>>>> the >>>>>>> common IPv6 prefix shared by adjacent nodes, you can directly tunne= l >>>>>>> to >>>>>>> them. >>>>>>> In practice, you=92ll have a default route to the AFTR and a subnet >>>>>>> route >>>>>>> for >>>>>>> the =93local=94 prefix. >>>>>> >>>>>> Also, to support the direct host-to-host tunneling, the DS-lite >>>>>> extension >>>>>> would need to allow for many DS-lite subscribers to share a single >>>>>> IPv4 >>>>>> private address realm. =A0I think DS-lite currently requires that ea= ch >>>>>> IPv6 >>>>>> subscriber is isolated within their own IPv4 private address realm, >>>>>> and >>>>>> therefore a twice-NAT44 gateway is required for IPv4-only applicatio= ns >>>>>> to >>>>>> communicate between DS-lite subscribers. >>>>>> >>>>>> >>>>>> -- >>>>>> james woodyatt >>>>>> member of technical staff, communications engineering >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Softwires mailing list >>>>>> Softwires@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>> >>>>> _______________________________________________ >>>>> Softwires mailing list >>>>> Softwires@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>> >>>> >> >> > > From sgundave@cisco.com Wed Nov 25 08:27:16 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B599A3A6920 for ; Wed, 25 Nov 2009 08:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwTYLZCZNdrk for ; Wed, 25 Nov 2009 08:27:15 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C8C2F3A6904 for ; Wed, 25 Nov 2009 08:27:15 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsFAKLpDEurR7H+/2dsb2JhbACaVKQDl2WCLYIFBIFx X-IronPort-AV: E=Sophos;i="4.47,286,1257120000"; d="scan'208";a="440437707" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 25 Nov 2009 16:27:11 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAPGR8Bc028505; Wed, 25 Nov 2009 16:27:11 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 08:27:09 -0800 Received: from 10.32.246.212 ([10.32.246.212]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Nov 2009 16:27:09 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 25 Nov 2009 08:27:17 -0800 From: Sri Gundavelli To: Hui Deng Message-ID: Thread-Topic: Discussion on the requirements of Host Based Translation Thread-Index: Acpt7Ccm9UDVgyqEI029+TFVHljhzQ== In-Reply-To: <1d38a3350911250658s5ba068e3n6c905ce73262ffde@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 25 Nov 2009 16:27:09.0642 (UTC) FILETIME=[22C362A0:01CA6DEC] Cc: softwires@ietf.org Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 16:27:16 -0000 Hi Hui, On 11/25/09 6:58 AM, "Hui Deng" wrote: > Hi ,Sri, >>>=20 >>> 1) Regarding overlapping case, I am assuming =A0that GW-Init-DS-Lite >>> assign the same Ipv4 address to the UE? >>=20 >> Sure, the same IPv4 address can be allocated as in DS lite base proposal= . > if you have same IPv4 address, how could route packet directly each other= ? >=20 You are talking about the UE to UE for the overlapping IPv4 case. As I explained in my long email earlier, we support the case for UE to UE non-overlapping case. For the case of overlapping there are no legacy applications that operate in that mode and there are no requirements either= . Our approach is to suggest IPv6 transport for such scenario. There are also other ways to solve the problem, such as implicit IPv6 tunnels as Alain/Dan's draft, or stateful mode on the gateway. But, I thought you always agreed, you are talking about the non-overlapping case only ? Departure from that stand and PNAT can now do that ? Fine. How does that work for PNAT ? - How does the application server learn the IPv4 address of the UE ? - How does the peer IP resolution happen ? - If the address is delivered inside the application payload, how do you handle that ? Where is the mapping state maintained ? - What new ALG's is this requiring ? - Can you give the flow ? And, why is this a legacy requirement ? >>=20 >>> 2) You are proposing add new bullet, but that is not our requirement, >>> we are not compare the solution, just do requirement gap analysis, >>=20 >> Changes to the host is not a "requirement". But, its a cost for >> a specific solution. When you are comparing multiple solutions, >> its logical you present both the key positive and negative aspects >> of the solution. Minor aspects, you can hide or ignore. But, host >> change is a significant point of discussion, that you cant avoid >> to discuss. But, its your slide and your call. > I guess that we are talking different things, you are always asking > comparision. > but I am talking about the requirements gap analysis. > :) No, we are talking about the slide that you compared and graded differen= t solutions. But, fine, I will let it go. But, all the features that we talke= d about other than non-overlapping UE to UE, we both support. For overlapping IP and UE to UE, we can identify the requirements first. =20 >>=20 >>=20 >>> 3) I got your point that host to host communication will be done by >>> Access router, you are assuming point to point to AR >>> other than shared link. >>>=20 >>=20 >> Mobile architectures, CDMA, LTE, or WiMAX or based on point to point >> link models on the access link. Mobile architectures is one of the >> key areas where the Gateway Initiated DS lite solution can be applied. >> For other architectures where shared links are in place, the access >> router maintains the association between the MAC/IP/GRE Key, so it can >> L2 forward the IP packet based on the state. > Let's discuss it step by step. for the same IP address, how access > router directly > route each other for the host? > Yes. See above, #1. Sri =20 From Washam.Fan@huaweisymantec.com Thu Nov 26 22:44:16 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D69F23A67FB for ; Thu, 26 Nov 2009 22:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.078 X-Spam-Level: X-Spam-Status: No, score=0.078 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGOaz7mqXuqC for ; Thu, 26 Nov 2009 22:44:16 -0800 (PST) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id C9C033A66B4 for ; Thu, 26 Nov 2009 22:44:15 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Content-type: text/plain; charset=windows-1252 Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KTR00F2X9DBRR80@hstga02-in.huaweisymantec.com> for softwires@ietf.org; Fri, 27 Nov 2009 14:44:00 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KTR00BIV9DB3710@hstml01-in.huaweisymantec.com> for softwires@ietf.org; Fri, 27 Nov 2009 14:43:59 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Fri, 27 Nov 2009 14:43:59 +0800 From: WashamFan To: Mark Townsley Message-id: Date: Fri, 27 Nov 2009 14:43:59 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <4B0D1B68.7010308@cisco.com> References: <4B0D1B68.7010308@cisco.com> Content-transfer-encoding: quoted-printable Cc: softwires@ietf.org Subject: Re: [Softwires] 6rd deployment vs. 6rd domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 06:44:16 -0000 Hi Mark=2C Thanks for the clarification=2E = When I looked at the looping issues in sec11=2E It is a little hard for = me to = understand how such attack launched=2E I can hardly find looping related= = discussions between the last 2 meetings in the mailist=2E I downloaded your presentation=2C but the attack illustration pages are broken (I am = not sure it is because the original one online was broken or my pdf software= has a compatibility problem)=2E Could you send me a copy=3F = Specifically=2C it is not clear about the sentence2=2C para3=2C sec11 If the attacker constructs= the packet accordingly=2C and can inject a packet with an IPv6 source address th= at looks as if it originates from within the 6rd domain of the second =5E=5E=5E=5E=5E=5E=5E=5E= =5E=5E=5E=5E=5E=5E=5E=5E=5E=5E border relay=2C =5B=2E=2E=2E=5D =5E=5E=5E=5E=5E=5E=5E Did you mean the 6rd domain the second border relay is serving=3F Does the second border relay serve the same domain as the first BR=3F (since a domain allows for multiple BRs=2C IMO) BTW=2C is it OK to define 6rd domain in sec3=3F I saw this term everywhe= re=2E Or you think the definition is too obvious to be explicitly stated=3F Thanks=2C washam ----- Original Message ----- From=3A Mark Townsley =3Ctownsley=40cisco=2Ecom=3E Date=3A Wednesday=2C November 25=2C 2009 7=3A56 pm Subject=3A Re=3A =5BSoftwires=5D 6rd deployment vs=2E 6rd domain To=3A WashamFan =3CWasham=2EFan=40huaweisymantec=2Ecom=3E Cc=3A softwires=40ietf=2Eorg =3E An SP may deploy 6rd a as a single 6rd domain=2C or may split the = =3E deployment into multiple domains=2E From the perspective of the = =3E protocol=2C = =3E each domain in standalone in nature whether there is a 1=3A1 = =3E relationship = =3E between a domain and an SP or an N=3A1 relationship among multiple = =3E domains = =3E and an SP=2E Operationally=2C there are differences to consider=2C = in = =3E particular some of the looping issues we talked about at the last = =3E IETF = =3E meeting and on the list leading up to it=2E =3E = =3E - Mark =3E = =3E WashamFan wrote=3A =3E =3E Hi=2C =3E =3E =3E =3E Are they the same=3F according to the draft=2C my impression is= yes=2E =3E =3E But according to the 6rd ppts presented in ietf75=2C page14=2C = bullet 1=3A =3E =3E =3E =3E An SP may subdivide a 6rd deployment into separate =936rd Do= mains=94 = =3E = =3E =3E in order to=3A =3E =3E =3E =3E It seemed a deployment spans multiple domains=2E Is it appropri= ate =3E =3E to add the terms to sec3=3F =3E =3E =3E =3E washam =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F =3E =3E Softwires mailing list =3E =3E Softwires=40ietf=2Eorg =3E =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/softwires =3E =3E =3E =3E = =3E = =3E From behcetsarikaya@yahoo.com Sat Nov 28 16:13:03 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 854D13A6885 for ; Sat, 28 Nov 2009 16:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50hHJIzPeoUI for ; Sat, 28 Nov 2009 16:13:02 -0800 (PST) Received: from web111414.mail.gq1.yahoo.com (web111414.mail.gq1.yahoo.com [67.195.15.210]) by core3.amsl.com (Postfix) with SMTP id 8BB7D3A687F for ; Sat, 28 Nov 2009 16:13:02 -0800 (PST) Received: (qmail 16057 invoked by uid 60001); 29 Nov 2009 00:12:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1259453573; bh=ZXFRQDQiJmctYhTbF62YUJe5MSOsRFWHlgxEKvNyrWE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=FOUuQWOmAEBW+Sbw90TaufyuZJWBVo2QrIr5dr7+IArpcMdG28zyio/aJHin2aKfagOL8u5zY3Nb0BGvDGcKqK7xGZqt12kKfnmzt3ObIP9bdtI5oPk8BGoG20udaJxpcHR2hjE9rw736C5XJwxTVQZ961VsqjuhCZrj8ArE1l8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=b/Fab/k0ydxfVXVKxsjfBVzgtJqX/EjeoIPaCIBtGSLloxf6m6ygKMPE4F3mqsvhV558iPUBBnqHZA55u9DV4hyBmefVFnaznFZWhs/2ZrpmzoMc92jBDDbd162uMERe12v3CmIGsYqmNIamurG09OfBnLO0JAD2tIbOyPsn/1E=; Message-ID: <588012.16034.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: UKGQzusVM1lR8dqjxhf7W3.vm8FZlAbVlM0z5pgVoXBGkNHb0u70NrXJjOKsSMizAFUFaauDuCHWZU4c._00H8_a8YJfemtmrUPI_G9QpBrMhP8pXtP9WbZaHQt4BGS7Iwky5JJypwVgfkQMvzmTR9syCe8wiKMHPHsDvjcGdhfWZ3RnskZ2o.9RTcBu64LcAvFZJ_NusId.Bwj.ZJS_N8Ab6Axh4rvsCLCm4Jbugp3D.zkjKxfjHtRSjzdjjHtXHbwF9Q2R5Q6rbDqLCPOM_s1Q5L5qcALnEP2fE9fyriBIb4R_nl_EgyI0X54It2fVsxGTjpyDrbr7H4JhhXPLzPPneTtqVKE.fNY5j5XrWFj5XsERyg-- Received: from [72.64.108.212] by web111414.mail.gq1.yahoo.com via HTTP; Sat, 28 Nov 2009 16:12:53 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.8.100.260964 References: Date: Sat, 28 Nov 2009 16:12:53 -0800 (PST) From: Behcet Sarikaya To: "Durand, Alain" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: softwires@ietf.org Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 00:13:03 -0000 Hi Alain, In the so-called access model, the host uses IPv4-in-IPv6 tunnel. My question is, can an unmodified host do this, i.e. send and receive encapsulated/decapsulated packets? Or do we need a "Softwire Client" at each host? --behcet > >From: "Durand, Alain" >To: Hui Deng >Cc: fengcao@chinamobile.com; liudapeng@chinamobile.com; chengang@chinamobile.com; zhouboyj@chinamobile.com; "Cao, Zhen" ; softwires@ietf.org >Sent: Wed, November 25, 2009 9:07:41 AM >Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation > >Re: Discussion on the requirements of Host Based Translation > > > >>On 11/25/09 9:52 AM, "Hui Deng" wrote: > > >>>>if the application generate IPv4 packet, and finally you will be use >>>>IPv6 to transmit this packet, >>>>isn't this a translation? >> >>>>--> No, this is tunneling. You preserver the v4 header. If header compression removes it, it it put back in place on the receiving side >> >>>>Secondly, when the receiver host got this packet, how could he know >>>>this is normal IPv6 packet >>>>or IPv4-translated-IPv6 packet? >> >>>>--> This is not translated, but tunneled. The packet arrives to a tunnel interface that will de-capsulate the v6 header and present the v4 packet to the v4 app. Think about 6to4 or 6rd, but with the reverse encap. >> >>>> - Alain. >> >> From behcetsarikaya@yahoo.com Sat Nov 28 16:19:02 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF4CE3A6821 for ; Sat, 28 Nov 2009 16:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.615 X-Spam-Level: X-Spam-Status: No, score=-1.615 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lNCUCyKQLT0 for ; Sat, 28 Nov 2009 16:19:02 -0800 (PST) Received: from web111406.mail.gq1.yahoo.com (web111406.mail.gq1.yahoo.com [67.195.15.162]) by core3.amsl.com (Postfix) with SMTP id F27453A67C0 for ; Sat, 28 Nov 2009 16:19:01 -0800 (PST) Received: (qmail 90112 invoked by uid 60001); 29 Nov 2009 00:18:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1259453936; bh=9oeFUpv/8SbQm13O5stj89EQrW7dtY4px0zTZT2KjMs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Nnn6RnIGibB8sAgW1vQukmTWOgQGP9RlUmH0aoZqtRGJm+nJotPIhJLZiu6JBeiy7Z2/R/ULMjuX01RWqxgcsEPAF9gcnM7i/rY9wzIfdtVg9XQkdJcE74D5kq/mPbLSVYaksevThD0CUMsKrCI0Cde7R7vP0ZpVWoofP2PNERs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=tUmASI+r07fxLWH4+X3QDQYoGGFJuz1inPSosh9Peaah/Y3at8C2IvJrJVbi8X5iw69Gc5YdRzN/JEciOX5Qvg86NzD4FgCzAzsdgT1Uy77gaxI/8jdPgVlBNgRR9kSg4bNx7RHQcUzBntm4EK5LHUeNE6Qv4wPG1Y//0gi4i2A=; Message-ID: <7666.89121.qm@web111406.mail.gq1.yahoo.com> X-YMail-OSG: A05lcqAVM1moN.VQobV1Lq3EYWf757SaEYX_m0Pqy45yW2AuXRpt5W.dpKreXgy4axOUvNUzOFh62iqGMWix1CpMQcAn3g8tUPgZFhNopNRhq5Np3taoJ_D4KpwW946F4dhYtnL3HtaP5cXV4IEo3UEiLIoq7jnCzzs.R4V2SJefBzUKpm4oFJ4s8b.buScYPfQUltWgsnAUyFJjJYOQAiTHseCEx5pRC2IvGLCWnKOt0cEoQkNjWqJj9HF2EtOypKlZWloQg1p3pMG0zWAGPKaLrA_VsVpHWTeXHwUr4Ye2Qya9Fl12NQa3wwUMg.7D8lwH9UL1v2RzUccR8nGp_0ZU8xvTCSNJHItIOHlB4DF8D6XicLxsrdVt9IJP.6lX_sI3y5lbgXhyVq9bY.MF8R8j Received: from [72.64.108.212] by web111406.mail.gq1.yahoo.com via HTTP; Sat, 28 Nov 2009 16:18:55 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.8.100.260964 References: <1d38a3350911250655u561ddb85w3dbc32ee2bffb5af@mail.gmail.com> <1d38a3350911250747s48cfa5f2na4b2a1285e31f75c@mail.gmail.com> Date: Sat, 28 Nov 2009 16:18:55 -0800 (PST) From: Behcet Sarikaya To: Hui Deng , "Durand, Alain" In-Reply-To: <1d38a3350911250747s48cfa5f2na4b2a1285e31f75c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: ietf softwire Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 00:19:02 -0000 Hi Hui,=0A=0A=0A=0A----- Original Message ----=0A> From: Hui Deng =0A> To: "Durand, Alain" =0A> C= c: ietf softwire =0A> Sent: Wed, November 25, 2009 9:47= :04 AM=0A> Subject: Re: [Softwires] Discussion on the requirements of Host = Based Translation=0A> =0A> Inline please=0A> =0A> 2009/11/25 Durand, Alain = :=0A> > It is actually fairly easy to scale... Use a copy of Net 10 for eac= h of your=0A> > access router...=0A> then inter access router doesn't work= =0A> =0A> > In the end, this all depend on your access topology, where the = first L3 node=0A> > is and where you intend to put the AFTR.=0A> exactly, f= or my knowledge, this L3 node is not the same location as NAT.=0A> =0A> > I= f both are co-located, then solution like gateway initiated DS-lite or=0A> = > simply assigning a regular IPv4 address are really much simpler.=0A> =0A>= > If the AFTR is a little further inside the network, the complexity pric= e to=0A> > pay for shortcuts may not be justified. If the AFTR is way insid= e the=0A> > network, then shortcuts may be useful. Note: The =E2=80=98v4 sc= opes=E2=80=99 does not have=0A> > to match the AFTR scope... It has to matc= h the scope of the entity that=0A> > proxy-manages IP address allocation, t= ypically the first L3 router acting as=0A> > DHCP-relay.=0A> isn't it sound= s complexity network operation, it will be quite hard to=0A> support roamin= g.=0A=0AIn general this is true. However by carefully placing AFTR we can h= andle mobility. In =0A=0Adraft-sarikaya-softwire-dslitemobility-01=0A=0Awe = have collocated AFTR with either HA or LMA. Also you need to coordinate NAT= operations with binding cache searches.=0A=0AIn fact DS-Lite becomes a goo= d match with PMIPv6 or DSMIP protocols.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A= =0A From denghui02@gmail.com Sun Nov 29 22:40:34 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B93633A6919 for ; Sun, 29 Nov 2009 22:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PERtOXIW98e7 for ; Sun, 29 Nov 2009 22:40:33 -0800 (PST) Received: from mail-px0-f204.google.com (mail-px0-f204.google.com [209.85.216.204]) by core3.amsl.com (Postfix) with ESMTP id BA4C63A6855 for ; Sun, 29 Nov 2009 22:40:33 -0800 (PST) Received: by pxi42 with SMTP id 42so2326480pxi.5 for ; Sun, 29 Nov 2009 22:40:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mTgzGZrz+NZ2r/tbP0jKgy/kHasguT29OFOjNKklkOA=; b=xr2FinyDniUVtQmh7/mL6XX1QNGZurO79iDyiCAFNTTlhQC5abPPzUMLzuStMKJR55 XOIry2vMdm+BmDgeKSSIrJSzkWlvAhSF+yroUr8c0J9Gkqx9mHIdgYoxJUNsOAAvRvWV FtDCpyJRMvZZXUNfhGynScn63bqQuHobgtllY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mF9TFJlsDZd+PuPDx8gdhHZaZRSIdb1UxhvyO5OZEB4R9xgt+1NWIE4vJD6M4qd5dl KpkkOPE9ctkUnQeln0drBuLMDMLl63WO/t30SnUql7+PgDEz2jdn4lozQskf8ZyU7DS8 6bL5fHcuL5bIhw4yZcPkZq1zRDW4QjLy99/PQ= MIME-Version: 1.0 Received: by 10.140.171.2 with SMTP id t2mr248353rve.3.1259563223423; Sun, 29 Nov 2009 22:40:23 -0800 (PST) In-Reply-To: References: <1d38a3350911250658s5ba068e3n6c905ce73262ffde@mail.gmail.com> Date: Mon, 30 Nov 2009 14:40:23 +0800 Message-ID: <1d38a3350911292240g1ff14191nc853d4b3333382d4@mail.gmail.com> From: Hui Deng To: Sri Gundavelli Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 06:40:34 -0000 Hi, Sri, Inline 2009/11/26 Sri Gundavelli : > Hi Hui, > > > > On 11/25/09 6:58 AM, "Hui Deng" wrote: > >> Hi ,Sri, >>>> >>>> 1) Regarding overlapping case, I am assuming =A0that GW-Init-DS-Lite >>>> assign the same Ipv4 address to the UE? >>> >>> Sure, the same IPv4 address can be allocated as in DS lite base proposa= l. >> if you have same IPv4 address, how could route packet directly each othe= r? >> > > You are talking about the UE to UE for the overlapping IPv4 case. As I > explained in my long email earlier, we support the case for UE to UE > non-overlapping case. For the case of overlapping there are no legacy > applications that operate in that mode and there are no requirements eith= er. > Our approach is to suggest IPv6 transport for such scenario. There are al= so > other ways to solve the problem, such as implicit IPv6 tunnels as > Alain/Dan's draft, or stateful mode on the gateway. For non-overlapping IPv4 case, how IPv4 address assgined to the UE, will it based on v6 only PDP or v4v6 PDP? could you help to point out Alain/Dan's draft, thanks, > > But, I thought you always agreed, you are talking about the non-overlappi= ng > case only ? Departure from that stand and PNAT can now do that ? Fine. Ho= w > does that work for PNAT ? > > - How does the application server learn the IPv4 address of the UE ? > - How does the peer IP resolution happen ? > - If the address is delivered inside the application payload, how do you > handle that ? Where is the mapping state maintained ? > - What new ALG's is this requiring ? > - Can you give the flow ? > > And, why is this a legacy requirement ? There are misunderstanding about what we require, I will point out in the seperate email. thanks -Hui > > >>> >>>> 2) You are proposing add new bullet, but that is not our requirement, >>>> we are not compare the solution, just do requirement gap analysis, >>> >>> Changes to the host is not a "requirement". But, its a cost for >>> a specific solution. When you are comparing multiple solutions, >>> its logical you present both the key positive and negative aspects >>> of the solution. Minor aspects, you can hide or ignore. But, host >>> change is a significant point of discussion, that you cant avoid >>> to discuss. But, its your slide and your call. >> I guess that we are talking different things, you are always asking >> comparision. >> but I am talking about the requirements gap analysis. >> > > :) No, we are talking about the slide that you compared and graded differ= ent > solutions. But, fine, I will let it go. But, all the features that we tal= ked > about other than non-overlapping UE to UE, we both support. For overlappi= ng > IP and UE to UE, we can identify the requirements first. > > > >>> >>> >>>> 3) I got your point that host to host communication will be done by >>>> Access router, you are assuming point to point to AR >>>> other than shared link. >>>> >>> >>> Mobile architectures, CDMA, LTE, or WiMAX or based on point to point >>> link models on the access link. Mobile architectures is one of the >>> key areas where the Gateway Initiated DS lite solution can be applied. >>> For other architectures where shared links are in place, the access >>> router maintains the association between the MAC/IP/GRE Key, so it can >>> L2 forward the IP packet based on the state. >> Let's discuss it step by step. for the same IP address, how access >> router directly >> route each other for the host? >> > > Yes. See above, #1. > > Sri > > > > From denghui02@gmail.com Sun Nov 29 22:47:23 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36DA43A67C1 for ; Sun, 29 Nov 2009 22:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbuYShw+j1-6 for ; Sun, 29 Nov 2009 22:47:22 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 46D0A3A67BD for ; Sun, 29 Nov 2009 22:47:22 -0800 (PST) Received: by pwi6 with SMTP id 6so2096149pwi.29 for ; Sun, 29 Nov 2009 22:47:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=OUQvKxpI/a38nM+KPMFkY+1tFJKMTPvXxrUrGxwAX78=; b=QGpRCJdJdf0TFDb1noH+ODk/Epy5FuCOhGU2BiQOWmEk0+0W7p1heJVocdU7nsg/Ve KgvRjm0WuGVzkJvHfWG1/WL3FhdTX1QXEi2SoAcqAXF9SuY6pd6ddx6q/3EUH1oHLbhh jpdDxOKc0lOYrKtmWiOexkd3L+dHUNoE3QqVQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=rz+W+d2DrnSWxdwLIcslonySXCszOba+TeFs2ArCe3pJyneDBwZQF2EqdGJFMtl+z7 UTS3CPZYtJvOpfQAu0BDbZtgygb8K5eBz0J80gBOJA8pWMQoJpaLQ6Fpd5eqvJls+OOz Fcvr9XVJmPsLTPa4G6EBNfzgiXF5w3HOGhLxE= MIME-Version: 1.0 Received: by 10.140.136.3 with SMTP id j3mr239427rvd.254.1259563632681; Sun, 29 Nov 2009 22:47:12 -0800 (PST) Date: Mon, 30 Nov 2009 14:47:12 +0800 Message-ID: <1d38a3350911292247r65e903ddk4b1592ccf2dcd6d1@mail.gmail.com> From: Hui Deng To: softwires@ietf.org Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Subject: [Softwires] Summary of the discussion Host based translation for v4-v4 within the same network. X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 06:47:23 -0000 Dear Alain and Sri, Please allow me try to summarize the discussion about v4-v4 communication within the same sub-network. In short, DS-Lite propose v4v6 tunnel between the hosts, GW-Init-DS-Lite propose GW routing the packet other than CGN For the convenience of the discussion, we give the terminology definition below: A is the source, A4 means A's IPv4 address, A6 means A's IPv6 address B is the destination, B4 means B's IPv4 address, B6 means B's IPv6 address +----------------------------------+ |IPv6 only network | | | | | | B4/B6 | | +---+ | | | B | | | +---+ | | \ | | \ +------+ | |+----+ \|Access| +------+ +-----+ +-----------+ || A |-- |Router|-- |IP GW |--- |AFTR |----|v4 Internet| |+----+ +------+ +------+ +-----+ +-----------+ | A4/A6 | | | +----+ | | | DNS| | | +----+ | | | +----------------------------------+ DS-Lite 1) definition of sub-network one example could be A: 10.1.1.2 and B: 10.1.1.3, then A knows he is in the same sub-network as B. 2) IPv4 address: DHCPv4 or embedded in DHCPv6 Issue 1: In case of DHCPv4, how host know the relationship between v4 and v6? Issue 2: In case of DHCPv6, it is not allowed in current DHCPv6. 3=A3=A9IPv6 prefix: either DHCPv6 or RA Issue: No 4) DNS: B must have both A and AAAA record, Issue: if A received A and AAAA record, when to use 6-6 communicatio= n? and when to use v4-v6 host to host tunnel? 5) Routing in the A: if B has both AAAA and A, and B4 is within same sub-network with A4, then host to host tunnel if B has only A, then DS-Lite tunnel Issue: how could B recoganize arrived IPv6 packet is host to host tunneled or not tunneled 6) Tunnel in A: Outer header: the source address is A6, the destination address is= B6 Inner Header: the source address is A4, the destination address is B4 7) Tunnel in B: 6) Host mdoification: (mapping table, DNS) A: setup tunnel mapping between IPv4 address and IPv6 address B: setup tunnel mapping between IPv4 address and IPv6 address Issue 1: when A and B setup the mapping table? mapping table is translation? A: once received DNS A and AAAA record? B: when received the first tunnel packet? Issue 2: modify the host to support DNS processing, isn't this same as BIS/BIA? Issue 3: isn't this same as PNAT in the host? 7) End to end routing: Based on IPv6 routing, no need go through AFTR and AR GW-Init-DS-Lite Several thing not yet clear, it depends on what kind of PDP (v6/v4v6)? 1) definition of sub-network one example could be A: 10.1.1.2 and B: 10.1.1.3, then A knows he is in the same sub-network as B. 2) IPv4 address: Layer 2/v6PDP/v4v6PDP Issue 1: In the IPv6 only network, how could it happen? 3=A3=A9IPv6 prefix: either DHCPv6 or RA Issue: No 4) DNS: B must have both A and AAAA record? Issue: if A received A and AAAA record, when to use 6-6 communicatio= n? and when to use v4-v6 host to host tunnel? 5) Routing in the A: unconformed? if B has both AAAA and A, and B4 is within same sub-network with A4, then host to host tunnel if B has only A record, and B4 is within same sub-network with A4, 6) Host mdoification: Not clear yet,unconformed (mapping table, DNS) A: setup tunnel mapping between IPv4 address and IPv6 address B: setup tunnel mapping between IPv4 address and IPv6 address Issue 1: when A and B setup the mapping table? mapping table is translation? A: once received DNS A and AAAA record? B: when received the first tunnel packet? Issue 2: modify the host to support DNS processing, isn't this same as BIS/BIA? Issue 3: isn't this same as PNAT in the host? 7) End to end routing: Need go through AR, but not AFTR. Thanks for your checking -Hui From sgundave@cisco.com Mon Nov 30 19:21:27 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E1C628C1A5 for ; Mon, 30 Nov 2009 19:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UALz4+nhAPIp for ; Mon, 30 Nov 2009 19:21:26 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 58BD928C17F for ; Mon, 30 Nov 2009 19:21:26 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAP8ZFEurR7Hu/2dsb2JhbACaPKVhl0iEMQSBcg X-IronPort-AV: E=Sophos;i="4.47,318,1257120000"; d="scan'208";a="55678901" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 01 Dec 2009 03:21:19 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nB13LJ11001423; Tue, 1 Dec 2009 03:21:19 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 19:21:19 -0800 Received: from 10.32.246.211 ([10.32.246.211]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Tue, 1 Dec 2009 03:21:18 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 30 Nov 2009 19:21:39 -0800 From: Sri Gundavelli To: Hui Deng Message-ID: Thread-Topic: Discussion on the requirements of Host Based Translation Thread-Index: AcpyNWUwQIy5mHsZcEOXyc2UyxjutQ== In-Reply-To: <1d38a3350911292240g1ff14191nc853d4b3333382d4@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Dec 2009 03:21:19.0379 (UTC) FILETIME=[597EB630:01CA7235] Cc: softwires@ietf.org Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 03:21:27 -0000 Hi Hui, Please see inline. On 11/29/09 10:40 PM, "Hui Deng" wrote: >> >> You are talking about the UE to UE for the overlapping IPv4 case. As I >> explained in my long email earlier, we support the case for UE to UE >> non-overlapping case. For the case of overlapping there are no legacy >> applications that operate in that mode and there are no requirements either. >> Our approach is to suggest IPv6 transport for such scenario. There are also >> other ways to solve the problem, such as implicit IPv6 tunnels as >> Alain/Dan's draft, or stateful mode on the gateway. > For non-overlapping IPv4 case, how IPv4 address assgined to the UE, > will it based on v6 only PDP or v4v6 PDP? > could you help to point out Alain/Dan's draft, thanks, > UE will be assigned a single Dual-stack PDN bearer, with PDP context of type v4v6. This will allow the network to carry both v4 and v6 UE packets. Now, the access network from SGSN to GGSN, or the core network from GGSN to CGN, can be IPv6-only. Only, the UE is dual-stack supported, with this we are logically restricting the use of IPv4 to UE and on the CGN, removing its traces any where else in the network. IPv4 essentially becomes a mere state on the CGN and on the UE with no IPv4 routing in the network, so it provides a simple migration path to IPv6-only network. I will let Alain and Dan provide the pointers to their draft, its not my work. >> >> But, I thought you always agreed, you are talking about the non-overlapping >> case only ? Departure from that stand and PNAT can now do that ? Fine. How >> does that work for PNAT ? >> >> - How does the application server learn the IPv4 address of the UE ? >> - How does the peer IP resolution happen ? >> - If the address is delivered inside the application payload, how do you >> handle that ? Where is the mapping state maintained ? >> - What new ALG's is this requiring ? >> - Can you give the flow ? >> >> And, why is this a legacy requirement ? > There are misunderstanding about what we require, I will point out in > the seperate email. > Ok. I will look for these answers in the other email :) Regards Sri From sgundave@cisco.com Mon Nov 30 19:38:55 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E693B28C199 for ; Mon, 30 Nov 2009 19:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2HngjOx0qvZ for ; Mon, 30 Nov 2009 19:38:54 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 41F4B3A681D for ; Mon, 30 Nov 2009 19:38:54 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGceFEurRN+J/2dsb2JhbADAHZdJhDEEgXI X-IronPort-AV: E=Sophos;i="4.47,318,1257120000"; d="scan'208";a="111758034" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 01 Dec 2009 03:38:45 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nB13cl1r006014; Tue, 1 Dec 2009 03:38:47 GMT Date: Mon, 30 Nov 2009 19:38:46 -0800 (PST) From: Sri Gundavelli To: Hui Deng In-Reply-To: <1d38a3350911292247r65e903ddk4b1592ccf2dcd6d1@mail.gmail.com> Message-ID: References: <1d38a3350911292247r65e903ddk4b1592ccf2dcd6d1@mail.gmail.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1903590565-1259638726=:13022" Cc: softwires@ietf.org Subject: Re: [Softwires] Summary of the discussion Host based translation forv4-v4 within the same network. X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 03:38:56 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1903590565-1259638726=:13022 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Hui: On Sun, 29 Nov 2009, Hui Deng wrote: > Dear Alain and Sri, > > Please allow me try to summarize the discussion about v4-v4 communication > within the same sub-network. > Please see below. > > GW-Init-DS-Lite > Several thing not yet clear, it depends on what kind of PDP (v6/v4v6)? > I dont see response to my specific questions in this email. Not sure, what scenario you are refering to. Overlapping or non-overlapping ? I already explained how it works for non-overlapping IP and about the use of IPv6 for UE to UE in general. 1. The UE is assigned a v4v6 PDP context. 2. The access network from SGSN to GGSN can be IPv6-only network. The network can carry both IPv4 and IPv6 UE traffic over this mobility tunnel. 3. The tunnel from GGSN and CGN can be IPv6-only transport. This leaves the access network and the core to IPv6-only, with traces of IPv4 only on the UE, CGN and GGSN. We just have a dual-stack UE and with the ability to carry the UE's IPv4 and IPv6 traffic on the IPv6 network. 4. Any UE to UE traffic, can always use IPv6. For legacy applications and when non-overlapping IPv4 addresses are in use, all the UE packets will hit the mobility tunnel and will arrive at the GGSN. For local destinations, the GGSN can simply tunnel them to the correct mobility tunnel, or to the CGN for internet destinations. 5. For UE to UE over IPv4 and when overlapping addresses are in use, there is no justification for this case. There is not a single legacy application that supports this case today. So, it makes more sense to use IPv6 for this case. Even otherwise, if there are clear requirements to support UE to UE over IPv4-only and the justification is valid, it can solved in couple of ways, per Alain's/Dan's draft, using implicit tunnels. > 1) definition of sub-network > one example could be A: 10.1.1.2 and B: 10.1.1.3, then A knows > he is in the same sub-network as B. > > 2) IPv4 address: Layer 2/v6PDP/v4v6PDP > Issue 1: In the IPv6 only network, how could it happen? > Your definition of the IPv6 network is the problem. When I say, IPv6 only network, the UE is dual-stacked and the radio link can carry both IPv4 and IPv6 packets, but the network from SGSN to GGSN or from GGSN to CGN is all IPv6. The 3GPP mobility architecture clearly allows the mobility tunnels to be IPv4 or IPv6, but still carrying the UE's IPv4 and IPv6 traffic. Note that the traditional dual-stack, router mode, the UE packets arrive as IPv4 to the first hop router, still the network is IPv6-only. Same logic here. Dont confuse IPv6-only network with air link or the dual-stack UE. We are talking about IPv4 in the routed network. > 3=A3=A9IPv6 prefix: either DHCPv6 or RA > Issue: No > Good > 4) DNS: B must have both A and AAAA record? > Issue: if A received A and AAAA record, when to use 6-6 communicati= on? > and when to use v4-v6 host to host tunnel? > The standard source address selection rules apply. If the target is reachable via IPv6, it will use the IPv6, else it will use IPv4. We are talking about IPv6-only network with IPv6 on all UE's. So, where ever IPv6 is supported just use it. Per your requirements, IPv6 is there always and on all UE's. For IPv4-only end points, NAT64 can also be used. > 5) Routing in the A: unconformed? > if B has both AAAA and A, and B4 is within same sub-network with > A4, then host to host tunnel > if B has only A record, and B4 is within same sub-network with A4, > Standard source address selection rules apply as above. > 6) Host mdoification: Not clear yet,unconformed (mapping table, DNS) > A: setup tunnel mapping between IPv4 address and IPv6 address > B: setup tunnel mapping between IPv4 address and IPv6 address > Issue 1: when A and B setup the mapping table? mapping table is > translation? > A: once received DNS A and AAAA record? > B: when received the first tunnel packet? > Issue 2: modify the host to support DNS processing, > isn't this same as BIS/BIA? > Issue 3: isn't this same as PNAT in the host? > No changes on the host. I'm not talking about UE to UE over overlapping IPv4 address scenario. So, dont assume I'm supporting that requirement, as I said, IPv6 should be used for such non-legacy cases and clearly when there is IPv6 available. If you want to solve that case, give a single reason why that is needed. I dont believe its a valid requirement. > 7) End to end routing: > Need go through AR, but not AFTR. > Yes. Local packets will not have to hit the CGN. Sri > Thanks for your checking > > -Hui > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > ---559023410-1903590565-1259638726=:13022--