From yiu_lee@cable.comcast.com Fri Apr 1 00:13:58 2011 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 3563A3A69B5 for ; Fri, 1 Apr 2011 00:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.33 X-Spam-Level: X-Spam-Status: No, score=-106.33 tagged_above=-999 required=5 tests=[AWL=2.133, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7ywBIpsn6Os for ; Fri, 1 Apr 2011 00:13:57 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id BE3833A691A for ; Fri, 1 Apr 2011 00:13:56 -0700 (PDT) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.118336047; Fri, 01 Apr 2011 03:15:21 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Fri, 1 Apr 2011 03:15:21 -0400 From: "Lee, Yiu" To: Mark Townsley , Yong Cui Thread-Topic: [Softwires] Questions on: draft-cui-softwire-host-4over6 Thread-Index: AQHL8DyP9fooYa0f/km99wWz2Uz/dg== Date: Fri, 1 Apr 2011 07:15:21 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.11] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org list" Subject: Re: [Softwires] Questions on: draft-cui-softwire-host-4over6 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, 01 Apr 2011 07:13:58 -0000 Hi Mark, Absolutely. L2TP tunnels are widely use in many areas including 4over6. The motivation of this draft is to extend dslite to re-use the same framework to provision a public IP to the B4 element and the AFTR not to NAT. I agree RFC5571 can achieve the same objective, but this will make the deployment easier to do two functions on the AFTR. Does this make sense to you? Thanks, Yiu =20 On 4/1/11 1:17 AM, "Mark Townsley" wrote: >L2TP tunnels are absolutely in use today. > >- Mark From ichiroumakino@gmail.com Fri Apr 1 03:04:00 2011 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 F413F3A67A6 for ; Fri, 1 Apr 2011 03:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwYJKVgoIZnH for ; Fri, 1 Apr 2011 03:03:59 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 01C0B3A6783 for ; Fri, 1 Apr 2011 03:03:58 -0700 (PDT) Received: by wyb29 with SMTP id 29so3151959wyb.31 for ; Fri, 01 Apr 2011 03:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=2yWVZJsc+cu1d/GK+oG4lK1tgZixEyN7b/nMWHZsIrI=; b=vGXz99i/71xY7cxXqh8BPJcC4VHF8bxjbwA682yYKEksHZwJKKQOBA/DMJPmgjk4ze PLAMxTM6fi4DFi23egH0ziHbnvRJHxu42jAVIlSGy+H4k/WnNR0TRY/rBjzyRkNtAuPa d23BA/aJKrqPSwOU60IC82ONIuaV5Zr3dP4FA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=B1ECcDgOjjtkKBcZlrNfbOtw180i66v/jzmihh/C1oMKjGa4Iyg8Ckxs0FxfrVrg4N OlpbSH/vjr0RdrqK/+mIBXisQlA2KpqtWiU+3hyJpC2nPjMAzdg1V50B3SQ6kPOiYVIX zw2EHlmoi0wAXEwWUp9KoPJ67kBspHviiqNIM= Received: by 10.227.139.72 with SMTP id d8mr3933389wbu.168.1301652337947; Fri, 01 Apr 2011 03:05:37 -0700 (PDT) Received: from ams3-vpn-dhcp2122.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id u9sm1171306wbg.0.2011.04.01.03.05.33 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2011 03:05:36 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Fri, 1 Apr 2011 12:05:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1082) Cc: "softwires@ietf.org list" Subject: Re: [Softwires] Questions on: draft-cui-softwire-host-4over6 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, 01 Apr 2011 10:04:00 -0000 > Absolutely. L2TP tunnels are widely use in many areas including = 4over6. > The motivation of this draft is to extend dslite to re-use the same > framework to provision a public IP to the B4 element and the AFTR not = to > NAT. I agree RFC5571 can achieve the same objective, but this will = make > the deployment easier to do two functions on the AFTR. Does this make > sense to you? Yiu explained this to me during PCP, and I think I get it now. this is for the case where one has already deployed DS-lite to a = customer. for whatever reason DS-lite fails for this end user (e.g. some = application doesn't work through the CGN). 4over6 provides a solution for provisioning a non NATed non port = restricted public IPv4 address to this end user. seems to me a very valid use case and something we should measure all of = the 4 over 6 mechanisms (ds-lite, 4rd, divi...) against.=20 cheers, Ole From yiu_lee@cable.comcast.com Fri Apr 1 13:39:47 2011 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 BA83928C0D8 for ; Fri, 1 Apr 2011 13:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.02 X-Spam-Level: X-Spam-Status: No, score=-103.02 tagged_above=-999 required=5 tests=[AWL=-1.285, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 1kZOcoSXA5fm for ; Fri, 1 Apr 2011 13:39:47 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id D31AF28C0D6 for ; Fri, 1 Apr 2011 13:39:46 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.32057574; Fri, 01 Apr 2011 14:44:04 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Fri, 1 Apr 2011 16:41:18 -0400 From: "Lee, Yiu" To: Ole Troan Thread-Topic: [Softwires] Questions on: draft-cui-softwire-host-4over6 Thread-Index: AQHL8K0mWGeFS4eAF0mlWuligPBBfg== Date: Fri, 1 Apr 2011 20:41:17 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.13] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org list" Subject: Re: [Softwires] Questions on: draft-cui-softwire-host-4over6 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, 01 Apr 2011 20:39:47 -0000 Ole, Thanks for explain the use case to the list. This is exactly what we have in mind for this draft. /Yiu On 4/1/11 6:05 AM, "Ole Troan" wrote: >> Absolutely. L2TP tunnels are widely use in many areas including 4over6. >> The motivation of this draft is to extend dslite to re-use the same >> framework to provision a public IP to the B4 element and the AFTR not to >> NAT. I agree RFC5571 can achieve the same objective, but this will make >> the deployment easier to do two functions on the AFTR. Does this make >> sense to you? > >Yiu explained this to me during PCP, and I think I get it now. > >this is for the case where one has already deployed DS-lite to a customer. >for whatever reason DS-lite fails for this end user (e.g. some >application doesn't work through the CGN). > >4over6 provides a solution for provisioning a non NATed non port >restricted public IPv4 address to this end user. > >seems to me a very valid use case and something we should measure all of >the 4 over 6 mechanisms (ds-lite, 4rd, divi...) against. > >cheers, >Ole > From yiu_lee@cable.comcast.com Fri Apr 1 15:03:00 2011 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 C2C8B3A699A for ; Fri, 1 Apr 2011 15:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.352 X-Spam-Level: X-Spam-Status: No, score=-106.352 tagged_above=-999 required=5 tests=[AWL=2.111, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEJlpqIf86f0 for ; Fri, 1 Apr 2011 15:03:00 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 9F9733A6995 for ; Fri, 1 Apr 2011 15:02:59 -0700 (PDT) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.118431885; Fri, 01 Apr 2011 18:04:31 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Fri, 1 Apr 2011 18:04:31 -0400 From: "Lee, Yiu" To: Ole Troan Thread-Topic: [Softwires] Questions on: draft-cui-softwire-host-4over6 Thread-Index: AQHL8LjGu/Ioloim7kKWi8EgnMX9DQ== Date: Fri, 1 Apr 2011 22:04:31 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.13] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org list" Subject: Re: [Softwires] Questions on: draft-cui-softwire-host-4over6 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, 01 Apr 2011 22:03:00 -0000 Hi Ole, I read your 4rd draft. As far as I know, the current 4rd draft supports 3 models:=20 1. An IPv4 prefix 2. Full IPv4 address (No port sharing) 3. IPv4 address and a range of ports So case 2 is equal to 4over6. Is my understanding right? Thanks, Yiu On 4/1/11 6:05 AM, "Ole Troan" wrote: >> Absolutely. L2TP tunnels are widely use in many areas including 4over6. >> The motivation of this draft is to extend dslite to re-use the same >> framework to provision a public IP to the B4 element and the AFTR not to >> NAT. I agree RFC5571 can achieve the same objective, but this will make >> the deployment easier to do two functions on the AFTR. Does this make >> sense to you? > >Yiu explained this to me during PCP, and I think I get it now. > >this is for the case where one has already deployed DS-lite to a customer. >for whatever reason DS-lite fails for this end user (e.g. some >application doesn't work through the CGN). > >4over6 provides a solution for provisioning a non NATed non port >restricted public IPv4 address to this end user. > >seems to me a very valid use case and something we should measure all of >the 4 over 6 mechanisms (ds-lite, 4rd, divi...) against. > >cheers, >Ole > From yong@csnet1.cs.tsinghua.edu.cn Fri Apr 1 20:45:08 2011 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 1A77C28C104 for ; Fri, 1 Apr 2011 20:45:08 -0700 (PDT) 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 lHWWdmBYSVsu for ; Fri, 1 Apr 2011 20:45:06 -0700 (PDT) Received: from mail.jzland.com (unknown [211.151.89.50]) by core3.amsl.com (Postfix) with ESMTP id 5BE3328C0E3 for ; Fri, 1 Apr 2011 20:45:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.jzland.com (EMOS V1.4 (Postfix)) with ESMTP id B03D630B0B75; Sat, 2 Apr 2011 11:46:37 +0800 (CST) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Sat Apr 2 11:46:37 2011 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 1,4d969c1d39708559857920 X-DSPAM-Factors: 27, many, 0.01000, From+Ole, 0.01000, but, 0.01000, >cheers, 0.01000, me+a, 0.01000, just, 0.01000, >application, 0.01000, non, 0.01000, non, 0.01000, Date*Apr, 0.01000, measure, 0.01000, explained+this, 0.01000, end, 0.01000, end, 0.01000, >restricted+public, 0.01000, softwire, 0.01000, org, 0.01000, PCP+and, 0.01000, easier, 0.01000, Date*Sat+02, 0.01000, through+the, 0.01000, in+many, 0.01000, net>+Yong, 0.01000, not+to, 0.01000, to+DS, 0.01000, Thread-Topic*Questions, 0.01000, Yiu"+ To: Ole Troan , "Lee, Yiu" Message-ID: Thread-Topic: [Softwires] Questions on: draft-cui-softwire-host-4over6 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "softwires@ietf.org list" Subject: Re: [Softwires] Questions on: draft-cui-softwire-host-4over6 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, 02 Apr 2011 03:45:08 -0000 Thanks Ole for your explanation. So the public 4over6 is just a slight revision to DS-Lite: We need to remove NAT in DS-Lite and make the client get public IPv4 address. Yong -----Original Message----- From: Ole Troan Date: Fri, 1 Apr 2011 12:05:31 +0200 To: "Lee, Yiu" Cc: Mark Townsley , Yong Cui , "softwires@ietf.org list" Subject: Re: [Softwires] Questions on: draft-cui-softwire-host-4over6 >> Absolutely. L2TP tunnels are widely use in many areas including 4over6. >> The motivation of this draft is to extend dslite to re-use the same >> framework to provision a public IP to the B4 element and the AFTR not to >> NAT. I agree RFC5571 can achieve the same objective, but this will make >> the deployment easier to do two functions on the AFTR. Does this make >> sense to you? > >Yiu explained this to me during PCP, and I think I get it now. > >this is for the case where one has already deployed DS-lite to a customer. >for whatever reason DS-lite fails for this end user (e.g. some >application doesn't work through the CGN). > >4over6 provides a solution for provisioning a non NATed non port >restricted public IPv4 address to this end user. > >seems to me a very valid use case and something we should measure all of >the 4 over 6 mechanisms (ds-lite, 4rd, divi...) against. > >cheers, >Ole > From ichiroumakino@gmail.com Mon Apr 4 01:37:41 2011 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 5F9803A6940 for ; Mon, 4 Apr 2011 01:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ey957JUh0xc8 for ; Mon, 4 Apr 2011 01:37:40 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 6C23B3A6920 for ; Mon, 4 Apr 2011 01:37:40 -0700 (PDT) Received: by wyb29 with SMTP id 29so5024130wyb.31 for ; Mon, 04 Apr 2011 01:39:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=L0/+935FpgCLoGgcOYnF+UpIFnaUc2Qo/BSA1oHvV6c=; b=jOC7w8eDuvbhUUK7C9OuK+cgHY3vnTAX5Ifk9T7wjU8I+Sdc/P7YKonfJaBOpAfWNg Iy4s3Soo06dzFL9IOxBqdISWWBg/GqTxkDpF3yXHZJ9cnzteRTz+HaJMRVZD7wqZMbgf FTYbCMcTtFi+13VSKK9wK1AGx2xWHq4G83jyA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=cYPJmg34G5D2DipWGbh3iCFpTFyL5k0WK9nsR+bhcR3mY5AoY8IT8do48cBV47SjbV PipKfX0aHCFoyzeYVvXQfswuBYu0oRLwFonz+CeKmk8DxU1BFoYgKp0kE9gNi3lBK7u3 fXUefsekbEo9JZmn//ga9tElM8KtJl3WCio+A= Received: by 10.216.69.196 with SMTP id n46mr3588928wed.30.1301906361588; Mon, 04 Apr 2011 01:39:21 -0700 (PDT) Received: from dhcp-osl-vl300-64-103-53-234.cisco.com (dhcp-osl-vl300-64-103-53-234.cisco.com [64.103.53.234]) by mx.google.com with ESMTPS id r80sm2140684wei.15.2011.04.04.01.39.19 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2011 01:39:20 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Mon, 4 Apr 2011 10:39:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org list" Subject: Re: [Softwires] Questions on: draft-cui-softwire-host-4over6 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, 04 Apr 2011 08:37:41 -0000 Yiu, > I read your 4rd draft. As far as I know, the current 4rd draft = supports 3 > models:=20 >=20 > 1. An IPv4 prefix > 2. Full IPv4 address (No port sharing) > 3. IPv4 address and a range of ports >=20 > So case 2 is equal to 4over6. Is my understanding right? yes, the 'service' provided should be the same. I presume 4over6 also could do 1? the main differences between 4over6 and 4rd for case 2, would be how it = is provisioned and that 4over6 wouldn't have any dependency between the = tunnel endpoint addresses and the payload addresses. obviously 4rd could be made less dependent of that too, by assigning = specific IPv6 addresses for the mapping, independent of the delegated = IPv6 prefix used within the end user site. doing that you really keep = mapping state in the RIB. but that's definitely one deployment model of = 4rd. cheers, Ole >>> Absolutely. L2TP tunnels are widely use in many areas including = 4over6. >>> The motivation of this draft is to extend dslite to re-use the same >>> framework to provision a public IP to the B4 element and the AFTR = not to >>> NAT. I agree RFC5571 can achieve the same objective, but this will = make >>> the deployment easier to do two functions on the AFTR. Does this = make >>> sense to you? >>=20 >> Yiu explained this to me during PCP, and I think I get it now. >>=20 >> this is for the case where one has already deployed DS-lite to a = customer. >> for whatever reason DS-lite fails for this end user (e.g. some >> application doesn't work through the CGN). >>=20 >> 4over6 provides a solution for provisioning a non NATed non port >> restricted public IPv4 address to this end user. >>=20 >> seems to me a very valid use case and something we should measure all = of >> the 4 over 6 mechanisms (ds-lite, 4rd, divi...) against. >>=20 >> cheers, >> Ole >>=20 >=20 From yong@csnet1.cs.tsinghua.edu.cn Mon Apr 4 05:13:49 2011 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 2945628B23E for ; Mon, 4 Apr 2011 05:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 TWlQx4gy5ynp for ; Mon, 4 Apr 2011 05:13:48 -0700 (PDT) Received: from mail.jzland.com (unknown [211.151.89.50]) by core3.amsl.com (Postfix) with ESMTP id 3529C3A67A1 for ; Mon, 4 Apr 2011 05:13:46 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.jzland.com (EMOS V1.4 (Postfix)) with ESMTP id 1CAB430B0B66; Mon, 4 Apr 2011 20:15:25 +0800 (CST) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Mon Apr 4 20:15:24 2011 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 1,4d99b65c39701784671812 X-DSPAM-Factors: 27, need+the, 0.01000, many, 0.01000, could, 0.01000, could, 0.01000, but, 0.01000, but, 0.01000, >cheers, 0.01000, me+a, 0.01000, address+assignment, 0.01000, address+assignment, 0.01000, >>>+cheers, 0.01000, local+IPv6, 0.01000, non, 0.01000, non, 0.01000, Date*Apr, 0.01000, measure, 0.01000, you+really, 0.01000, made, 0.01000, explained+this, 0.01000, end, 0.01000, end, 0.01000, >>>>+the, 0.01000, IPv4+addresses, 0.01000, Received*4+Apr, 0.01000, Date*04+Apr, 0.01000, use+DHCPv4, 0.01000, PCP+and, 0.01000 X-Virus-Scanned: amavisd-new at jzland.com Received: from mail.jzland.com ([127.0.0.1]) by localhost (mail.jzland.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iamk+Uop4gal; Mon, 4 Apr 2011 20:15:24 +0800 (CST) Received: from [192.168.0.155] (unknown [219.143.144.249]) by mail.jzland.com (EMOS V1.4 (Postfix)) with ESMTPA id CCB5E30B0A37; Mon, 4 Apr 2011 20:15:22 +0800 (CST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Mon, 04 Apr 2011 20:15:13 +0800 From: Yong Cui To: Ole Troan , "Lee, Yiu" Message-ID: Thread-Topic: [Softwires] Questions on: draft-cui-softwire-host-4over6 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "softwires@ietf.org list" Subject: Re: [Softwires] Questions on: draft-cui-softwire-host-4over6 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, 04 Apr 2011 12:13:49 -0000 >> >>I read your 4rd draft. As far as I know, the current 4rd draft supports 3 >> models: >> >> 1. An IPv4 prefix >> 2. Full IPv4 address (No port sharing) >> 3. IPv4 address and a range of ports >> >> So case 2 is equal to 4over6. Is my understanding right? > >yes, the 'service' provided should be the same. >I presume 4over6 also could do 1? Currently, we only focus on 2 without 1. Because if we use DHCPv4 over IPv6 tunnel, DHCPv4 doesnot support prefix assignment, right? > >the main differences between 4over6 and 4rd for case 2, would be how it >is provisioned and that 4over6 wouldn't have any dependency between the >tunnel endpoint addresses and the payload addresses. >obviously 4rd could be made less dependent of that too, by assigning >specific IPv6 addresses for the mapping, independent of the delegated >IPv6 prefix used within the end user site. doing that you really keep >mapping state in the RIB. but that's definitely one deployment model of >4rd. Even for 2, the use cases are different between 4over6 and 4rd because of the independency of IPv4/IPv6 addresses. For example, 4over6 can assign the public IPv4 addresses to a few high-priority hosts distributed in a large-scale network withOUT changing the local network devices or the current policy of IPv6 address assignment. So we don't need the cooperation with the local IPv6 address assignment. That's quite important for our CERNET2. Yong > >cheers, >Ole > >>>> Absolutely. L2TP tunnels are widely use in many areas including >>>>4over6. >>>> The motivation of this draft is to extend dslite to re-use the same >>>> framework to provision a public IP to the B4 element and the AFTR not >>>>to >>>> NAT. I agree RFC5571 can achieve the same objective, but this will >>>>make >>>> the deployment easier to do two functions on the AFTR. Does this make >>>> sense to you? >>> >>> Yiu explained this to me during PCP, and I think I get it now. >>> >>> this is for the case where one has already deployed DS-lite to a >>>customer. >>> for whatever reason DS-lite fails for this end user (e.g. some >>> application doesn't work through the CGN). >>> >>> 4over6 provides a solution for provisioning a non NATed non port >>> restricted public IPv4 address to this end user. >>> >>> seems to me a very valid use case and something we should measure all >>>of >>> the 4 over 6 mechanisms (ds-lite, 4rd, divi...) against. >>> >>> cheers, >>> Ole >>> >> > From mark@townsley.net Mon Apr 4 05:30:10 2011 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 D508728C100 for ; Mon, 4 Apr 2011 05:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MW47XywjrHAM for ; Mon, 4 Apr 2011 05:30:10 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 4A4D63A69EA for ; Mon, 4 Apr 2011 05:30:07 -0700 (PDT) Received: by wyb29 with SMTP id 29so5194679wyb.31 for ; Mon, 04 Apr 2011 05:31:49 -0700 (PDT) Received: by 10.227.140.67 with SMTP id h3mr6954363wbu.80.1301920309121; Mon, 04 Apr 2011 05:31:49 -0700 (PDT) Received: from [192.168.1.109] (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id e13sm2895338wbi.6.2011.04.04.05.31.45 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2011 05:31:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Mon, 4 Apr 2011 05:31:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2AC6938F-BD09-4AFA-B02C-91C131D5A0F7@townsley.net> References: To: Yong Cui X-Mailer: Apple Mail (2.1082) Cc: "softwires@ietf.org list" , "Lee, Yiu" Subject: Re: [Softwires] Questions on: draft-cui-softwire-host-4over6 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, 04 Apr 2011 12:30:10 -0000 On Apr 4, 2011, at 5:15 AM, Yong Cui wrote: >>>=20 >>> I read your 4rd draft. As far as I know, the current 4rd draft = supports 3 >>> models:=20 >>>=20 >>> 1. An IPv4 prefix >>> 2. Full IPv4 address (No port sharing) >>> 3. IPv4 address and a range of ports >>>=20 >>> So case 2 is equal to 4over6. Is my understanding right? >>=20 >> yes, the 'service' provided should be the same. >> I presume 4over6 also could do 1? > Currently, we only focus on 2 without 1. Because if we use DHCPv4 over > IPv6 tunnel, DHCPv4 doesnot support prefix assignment, right? >>=20 >> the main differences between 4over6 and 4rd for case 2, would be how = it >> is provisioned and that 4over6 wouldn't have any dependency between = the >> tunnel endpoint addresses and the payload addresses. >> obviously 4rd could be made less dependent of that too, by assigning >> specific IPv6 addresses for the mapping, independent of the delegated >> IPv6 prefix used within the end user site. doing that you really keep >> mapping state in the RIB. but that's definitely one deployment model = of >> 4rd. > Even for 2, the use cases are different between 4over6 and 4rd because = of > the independency of IPv4/IPv6 addresses. For example, 4over6 can = assign > the public IPv4 addresses to a few high-priority hosts distributed in = a > large-scale network withOUT changing the local network devices or the > current policy of IPv6 address assignment. So we don't need the > cooperation with the local IPv6 address assignment. > That's quite important for our CERNET2. Classic stateful vs. stateless deployment alternative. I hear the same = for people who end up deploying L2TP for IPv6 over IPv4 instead of 6rd. = It all depends on how much control you need over the two addressing = families and their interaction.=20 - Mark >=20 > Yong >=20 >>=20 >> cheers, >> Ole >>=20 >>>>> Absolutely. L2TP tunnels are widely use in many areas including >>>>> 4over6. >>>>> The motivation of this draft is to extend dslite to re-use the = same >>>>> framework to provision a public IP to the B4 element and the AFTR = not >>>>> to >>>>> NAT. I agree RFC5571 can achieve the same objective, but this will >>>>> make >>>>> the deployment easier to do two functions on the AFTR. Does this = make >>>>> sense to you? >>>>=20 >>>> Yiu explained this to me during PCP, and I think I get it now. >>>>=20 >>>> this is for the case where one has already deployed DS-lite to a >>>> customer. >>>> for whatever reason DS-lite fails for this end user (e.g. some >>>> application doesn't work through the CGN). >>>>=20 >>>> 4over6 provides a solution for provisioning a non NATed non port >>>> restricted public IPv4 address to this end user. >>>>=20 >>>> seems to me a very valid use case and something we should measure = all >>>> of >>>> the 4 over 6 mechanisms (ds-lite, 4rd, divi...) against. >>>>=20 >>>> cheers, >>>> Ole >>>>=20 >>>=20 >>=20 >=20 >=20 From yong@csnet1.cs.tsinghua.edu.cn Mon Apr 4 05:37:05 2011 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 7CD1B28C107 for ; Mon, 4 Apr 2011 05:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.995 X-Spam-Level: X-Spam-Status: No, score=-0.995 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 duJxa+54D-gy for ; Mon, 4 Apr 2011 05:37:04 -0700 (PDT) Received: from mail.jzland.com (unknown [211.151.89.50]) by core3.amsl.com (Postfix) with ESMTP id CCAED3A697F for ; Mon, 4 Apr 2011 05:37:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.jzland.com (EMOS V1.4 (Postfix)) with ESMTP id CDAD330B0B66; Mon, 4 Apr 2011 20:38:43 +0800 (CST) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Mon Apr 4 20:38:43 2011 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 1,4d99bbd339701778185024 X-DSPAM-Factors: 27, need+the, 0.01000, could, 0.01000, could, 0.01000, but, 0.01000, address+assignment, 0.01000, address+assignment, 0.01000, >>+IPv6, 0.01000, local+IPv6, 0.01000, Date*Apr, 0.01000, you+really, 0.01000, made, 0.01000, end, 0.01000, end, 0.01000, IPv4+addresses, 0.01000, Received*4+Apr, 0.01000, Date*04+Apr, 0.01000, vs+stateless, 0.01000, dependent+of, 0.01000, 4rd+could, 0.01000, use+DHCPv4, 0.01000, hear, 0.01000, case+2, 0.01000, case+2, 0.01000, do+1?, 0.01000, be+the, 0.01000, is+equal, 0.01000, as+I, 0.01000 X-Virus-Scanned: amavisd-new at jzland.com Received: from mail.jzland.com ([127.0.0.1]) by localhost (mail.jzland.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsGZFKqyf1ER; Mon, 4 Apr 2011 20:38:43 +0800 (CST) Received: from [192.168.0.155] (unknown [219.143.144.249]) by mail.jzland.com (EMOS V1.4 (Postfix)) with ESMTPA id 7863530B0A37; Mon, 4 Apr 2011 20:38:41 +0800 (CST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Mon, 04 Apr 2011 20:38:35 +0800 From: Yong Cui To: Mark Townsley Message-ID: Thread-Topic: [Softwires] Questions on: draft-cui-softwire-host-4over6 In-Reply-To: <2AC6938F-BD09-4AFA-B02C-91C131D5A0F7@townsley.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "softwires@ietf.org list" , "Lee, Yiu" Subject: Re: [Softwires] Questions on: draft-cui-softwire-host-4over6 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, 04 Apr 2011 12:37:05 -0000 >>>> >>>>I read your 4rd draft. As far as I know, the current 4rd draft >>>>supports 3 >>>> models: >>>> >>>> 1. An IPv4 prefix >>>> 2. Full IPv4 address (No port sharing) >>>> 3. IPv4 address and a range of ports >>>> >>>> So case 2 is equal to 4over6. Is my understanding right? >>> >>> yes, the 'service' provided should be the same. >>> I presume 4over6 also could do 1? >> Currently, we only focus on 2 without 1. Because if we use DHCPv4 over >> IPv6 tunnel, DHCPv4 doesnot support prefix assignment, right? >>> >>> the main differences between 4over6 and 4rd for case 2, would be how it >>> is provisioned and that 4over6 wouldn't have any dependency between the >>> tunnel endpoint addresses and the payload addresses. >>> obviously 4rd could be made less dependent of that too, by assigning >>> specific IPv6 addresses for the mapping, independent of the delegated >>> IPv6 prefix used within the end user site. doing that you really keep >>> mapping state in the RIB. but that's definitely one deployment model of >>> 4rd. >> Even for 2, the use cases are different between 4over6 and 4rd because >>of >> the independency of IPv4/IPv6 addresses. For example, 4over6 can assign >> the public IPv4 addresses to a few high-priority hosts distributed in a >> large-scale network withOUT changing the local network devices or the >> current policy of IPv6 address assignment. So we don't need the >> cooperation with the local IPv6 address assignment. >> That's quite important for our CERNET2. > >Classic stateful vs. stateless deployment alternative. I hear the same >for people who end up deploying L2TP for IPv6 over IPv4 instead of 6rd. >It all depends on how much control you need over the two addressing >families and their interaction. You are right, Mark. So in order to encourage the deployment of IPv6 and make the deployment as simple as possible, we are looking forword to the 4over6 solution in CERNET2. Yong From yiu_lee@cable.comcast.com Tue Apr 5 09:53:10 2011 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 B6C163A6962 for ; Tue, 5 Apr 2011 09:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.04 X-Spam-Level: X-Spam-Status: No, score=-103.04 tagged_above=-999 required=5 tests=[AWL=-1.305, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 RokBwMWEimfY for ; Tue, 5 Apr 2011 09:53:10 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 77FFD3A6960 for ; Tue, 5 Apr 2011 09:53:09 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.32475000; Tue, 05 Apr 2011 10:57:34 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Tue, 5 Apr 2011 12:54:38 -0400 From: "Lee, Yiu" To: Mark Townsley , Yong Cui Thread-Topic: [Softwires] Questions on: draft-cui-softwire-host-4over6 Thread-Index: AQHL87IkvxrZY7hE/UaFxR+NFwcNEQ== Date: Tue, 5 Apr 2011 16:54:36 +0000 Message-ID: In-Reply-To: <2AC6938F-BD09-4AFA-B02C-91C131D5A0F7@townsley.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.13] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org list" Subject: Re: [Softwires] Questions on: draft-cui-softwire-host-4over6 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, 05 Apr 2011 16:53:10 -0000 100% agreed. On 4/4/11 8:31 AM, "Mark Townsley" wrote: >Classic stateful vs. stateless deployment alternative. I hear the same >for people who end up deploying L2TP for IPv6 over IPv4 instead of 6rd. >It all depends on how much control you need over the two addressing >families and their interaction. > >- Mark > From remi.despres@free.fr Wed Apr 6 05:55:41 2011 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 7366828C0EB for ; Wed, 6 Apr 2011 05:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[AWL=0.638, 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 3ya5ZB0nN0-R for ; Wed, 6 Apr 2011 05:55:40 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by core3.amsl.com (Postfix) with ESMTP id 9AB6128C0EA for ; Wed, 6 Apr 2011 05:55:40 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2402.sfr.fr (SMTP Server) with ESMTP id 64ADD7000089; Wed, 6 Apr 2011 14:57:23 +0200 (CEST) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2402.sfr.fr (SMTP Server) with ESMTP id 82DC27000098; Wed, 6 Apr 2011 14:57:18 +0200 (CEST) X-SFR-UUID: 20110406125722536.82DC27000098@msfrf2402.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 6 Apr 2011 14:57:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1BAE371E-55EE-47B2-8611-3ACE7D9835DF@free.fr> References: To: Yong Cui X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org list" , "Lee, Yiu" Subject: Re: [Softwires] Questions on: draft-cui-softwire-host-4over6 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, 06 Apr 2011 12:55:41 -0000 Le 4 avr. 2011 =E0 14:38, Yong Cui a =E9crit : ... >>> For example, 4over6 can assign >>> the public IPv4 addresses to a few high-priority hosts distributed = in a >>> large-scale network withOUT changing the local network devices or = the >>> current policy of IPv6 address assignment. This is a requirement for a customizable service. >>> So we don't need the >>> cooperation with the local IPv6 address assignment. >>> That's quite important for our CERNET2. >>=20 >> Classic stateful vs. stateless deployment alternative. I hear the = same >> for people who end up deploying L2TP for IPv6 over IPv4 instead of = 6rd. >> It all depends on how much control you need over the two addressing >> families and their interaction. Same view. It can also be viewed as a tradeoff between customizable services and = the triple [ease of operation, scalability, investment cost]. > You are right, Mark. So in order to encourage the deployment of IPv6 > and > make the deployment as simple as possible, we are looking forword to = the > 4over6 solution in CERNET2. With the customizable service you want, this is clearly a solution. But this of course doesn't prohibit others providers to prefer more = standardized services (for residual IPv4 connectivity across IPv6-only) = to privilege ease of operation, scalability, and investment costs. The tradeoff could then be summarized as: +----------------------------+--------------------+-----------------+ | | Stateful (4over6) | Stateless (4rd) | +----------------------------+--------------------+-----------------+ | Customizable services | + | - | | -------------------------- | ------------------ | --------------- | | Ease of operation | - | + | | -------------------------- | ------------------ | --------------- | | Scalability | - | + | | -------------------------- | ------------------ | --------------- | | Invetment cost | - | + | | minimization | | | +----------------------------+--------------------+-----------------+ Does this make sense to you? Regards, RD From weapon@csnet1.cs.tsinghua.edu.cn Wed Apr 6 06:25:43 2011 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 B103628C0F6 for ; Wed, 6 Apr 2011 06:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.174 X-Spam-Level: *** X-Spam-Status: No, score=3.174 tagged_above=-999 required=5 tests=[AWL=-2.453, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, FROM_EXCESS_BASE64=1.456, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_82=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Et2uy8Ds7Zm for ; Wed, 6 Apr 2011 06:25:43 -0700 (PDT) Received: from mail.jzland.com (unknown [211.151.89.50]) by core3.amsl.com (Postfix) with ESMTP id 2CF3728C0F5 for ; Wed, 6 Apr 2011 06:25:41 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.jzland.com (EMOS V1.4 (Postfix)) with ESMTP id 1DD5B30B0B76; Wed, 6 Apr 2011 21:27:21 +0800 (CST) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Apr 6 21:27:20 2011 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 1,4d9c6a3839701693295287 X-DSPAM-Factors: 27, China+Telecom, 0.01000, could, 0.01000, Received*6+Apr, 0.01000, be+separated, 0.01000, Cc*"Lee, 0.01000, |+|, 0.01000, |+|, 0.01000, Date*Apr, 0.01000, IPv4+&, 0.01000, an, 0.01000, their+IPv4, 0.01000, softwire, 0.01000, org, 0.01000, relationship, 0.01000, from, 0.01000, course+doesn't, 0.01000, X-Envelope-To*, 0.01000, University+Beijing, 0.01000, >>+and, 0.01000, v6ops+session, 0.01000, X-Envelope-To* To: "=?utf-8?B?UumWmWlfRGVzcHLplp8=?=" , "=?utf-8?B?WW9uZyBDdWk=?=" References: Message-ID: <201104062126522810063@csnet1.cs.tsinghua.edu.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: =?utf-8?B?c29mdHdpcmVzQGlldGYub3JnIGxpc3Q=?= , =?utf-8?B?TGVlLFlpdQ==?= Subject: Re: [Softwires] =?utf-8?q?Questions_on=3A_draft-cui-softwire-host-4ov?= =?utf-8?q?er6?= 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, 06 Apr 2011 13:25:43 -0000 SGkgUmVtaSwNCnBsZWFzZSBzZWUgaW5saW5lcw0KDQotLS0tLS0tLS0tLS0tLS0tLS0JCQkJIA0K UGVuZyBXdQ0KUGhEIGNhbmRpZGF0ZQ0KRGVwYXJ0bWVudCBvZiBDb21wdXRlciBTY2llbmNlICYg VGVjaG5vbG9neQ0KVHNpbmdodWEgVW5pdmVyc2l0eSwgQmVpamluZywgQ2hpbmENCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K RnJvbe+8mlLplplpX0Rlc3By6ZafDQpEYXRl77yaMjAxMS0wNC0wNiAyMDo1NzozNA0KVG/vvJpZ b25nIEN1aQ0KQ0PvvJpzb2Z0d2lyZXNAaWV0Zi5vcmcgbGlzdDsgTGVlLFlpdQ0KU3ViamVjdO+8 mlJlOiBbU29mdHdpcmVzXSBRdWVzdGlvbnMgb246IGRyYWZ0LWN1aS1zb2Z0d2lyZS1ob3N0LTRv dmVyNg0KDQo+PiBZb3UgYXJlIHJpZ2h0LCBNYXJrLiBTbyBpbiBvcmRlciB0byBlbmNvdXJhZ2Ug dGhlIGRlcGxveW1lbnQgb2YgSVB2Ng0KPj4gYW5kDQo+PiBtYWtlIHRoZSBkZXBsb3ltZW50IGFz IHNpbXBsZSBhcyBwb3NzaWJsZSwgd2UgYXJlIGxvb2tpbmcgZm9yd29yZCB0byB0aGUNCj4+IDRv dmVyNiBzb2x1dGlvbiBpbiBDRVJORVQyLg0KPg0KPldpdGggdGhlIGN1c3RvbWl6YWJsZSBzZXJ2 aWNlIHlvdSB3YW50LCB0aGlzIGlzIGNsZWFybHkgYSBzb2x1dGlvbi4NCj4NCj5CdXQgdGhpcyBv ZiBjb3Vyc2UgZG9lc24ndCBwcm9oaWJpdCBvdGhlcnMgcHJvdmlkZXJzIHRvIHByZWZlciBtb3Jl IHN0YW5kYXJkaXplZCBzZXJ2aWNlcyAoZm9yIHJlc2lkdWFsIElQdjQgY29ubmVjdGl2aXR5IGFj cm9zcyBJUHY2LW9ubHkpIHRvIHByaXZpbGVnZSBlYXNlIG9mIG9wZXJhdGlvbiwgc2NhbGFiaWxp dHksIGFuZCBpbnZlc3RtZW50IGNvc3RzLg0KRGVwZW5kcyBvbiB3aGF0IGtpbmQgb2Ygc2Vydmlj ZXMgYSBwcm92aWRlciByZWFsbHkgd2FudHMuIFRoZSBvdGhlciBkYXkgYXQgdjZvcHMgc2Vzc2lv biB0aGlzIHByZXNlbnRlciBmcm9tIENoaW5hIFRlbGVjb20gc2FpZCB0aGF0IHRoZSB3YW50IHRo ZWlyIElQdjQgJiBJUHY2IGFkZHJlc3NpbmcgJiByb3V0aW5nIGJlIHNlcGFyYXRlZCB3aGVuIHBy b3ZpZGVyIHRoaXMga2luZCBvZiBJUHY0LW92ZXItSVB2NiBzZXJ2aWNlLiBTbywgaXQncyBzdGls bCBhIHRyYWRlb2ZmIHRoaW5nIHJhdGhlciB0aGFuIHN0YW5kYXJkaXplZC9ub3Qgc3RhbmRhcmRp emVkLi4uDQo+VGhlIHRyYWRlb2ZmIGNvdWxkIHRoZW4gYmUgc3VtbWFyaXplZCBhczoNCj4gKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0rDQo+IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgU3RhdGVmdWwgKDRv dmVyNikgfCBTdGF0ZWxlc3MgKDRyZCkgfA0KPiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLSsNCj4gfCAgICBDdXN0b21p emFibGUgc2VydmljZXMgICB8ICAgICAgICAgICsgICAgICAgICB8ICAgICAgICAtICAgICAgICB8 DQo+IHwgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gfCAtLS0tLS0tLS0tLS0tLS0tLS0gfCAt LS0tLS0tLS0tLS0tLS0gfA0KPiB8ICAgICAgRWFzZSBvZiBvcGVyYXRpb24gICAgIHwgICAgICAg ICAgLSAgICAgICAgIHwgICAgICAgICsgICAgICAgIHwNCj4gfCAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSB8IC0tLS0tLS0tLS0tLS0tLS0tLSB8IC0tLS0tLS0tLS0tLS0tLSB8DQo+IHwgICAg ICAgICBTY2FsYWJpbGl0eSAgICAgICAgfCAgICAgICAgICAtICAgICAgICAgfCAgICAgICAgKyAg ICAgICAgfA0KPiB8IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIHwgLS0tLS0tLS0tLS0tLS0t LS0tIHwgLS0tLS0tLS0tLS0tLS0tIHwNCj4gfCAgICAgICBJbnZldG1lbnQgY29zdCAgICAgICB8 ICAgICAgICAgIC0gICAgICAgICB8ICAgICAgICArICAgICAgICB8DQo+IHwgICAgICAgIG1pbmlt aXphdGlvbiAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfA0K PiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLSsNCldlbGwsIGlmIHdlIHRhbGsgYWJvdXQgdGhlc2Uga2luZHMgb2YgcHJv cyAmIGNvbnMsIGtlZXAgaW4gbWluZCB0aGF0IDRvdmVyNiBpcyBhbiBleHRlbnNpb24gb2YgRHVh bC1zdGFjayBsaXRlLCB0aGV5IGNhbiBiZSBuYXR1cmFsbHkgY291cGxlZChzaGFyZWQgZGV2aWNl cyAmIHNlcnZpY2VzKS4gU28gSSB0aGluayB0aGUgIi0iIGl0ZW1zIGRvZXNudCd0IG1hdGNoLg0K DQpJTUhPLCB0aGVvcmV0aWNhbGx5IHRoZSByZWxhdGlvbnNoaXAgaXMgbGlrZSB0aGlzOiANCmlm IGRvbid0IGxpa2UgYWRkcmVzcyAmIHJvdXRpbmcgY291cGxpbmcsIHRoZW4gc3RhdGVmdWwob24g QUZUUikuIFVuZGVyIHRoaXMgZGlyZWN0aW9uLCBpZiBkZWRpY2F0ZWQgdjQgYWRkcmVzcywgdGhl biA0b3ZlcjY7IGlmIHN0YXRlZnVsIGFkZHJlc3Mgc2hhcmluZywgdGhlbiBEUy1saXRlOyBpZiBz dGF0ZWxlc3Mgc2hhcmluZywgdGhlbiBzb21lIHNvcnQgb2YgQStQIHRoaW5nOw0KaWYgY2FuIGFj Y2VwdCBhZGRyZXNzICYgcm91dGluZyBjb3VwbGluZywgdGhlbiBzdGF0ZWxlc3MuIGlmIGRlZGlj YXRlZCB2NCBhZGRyZXNzLCB0aGVuIDRyZDsgaWYgYWRkcmVzcyBzaGFyaW5nLCB0aGVuIDRyZCB3 aXRoIGFkZHJlc3MgbXVsdGlwbGV4aW5nDQo= From yiu_lee@cable.comcast.com Wed Apr 6 06:41:10 2011 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 63B363A6937 for ; Wed, 6 Apr 2011 06:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.859 X-Spam-Level: X-Spam-Status: No, score=-102.859 tagged_above=-999 required=5 tests=[AWL=-1.424, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, 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 02Teuz2HmwCw for ; Wed, 6 Apr 2011 06:41:10 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id BD50C3A67B2 for ; Wed, 6 Apr 2011 06:41:09 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.32608622; Wed, 06 Apr 2011 07:45:26 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Wed, 6 Apr 2011 09:42:33 -0400 From: "Lee, Yiu" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Yong Cui Thread-Topic: [Softwires] Questions on: draft-cui-softwire-host-4over6 Thread-Index: AQHL9GB7dIM3e3DiEk6IvKFS0Z8zQw== Date: Wed, 6 Apr 2011 13:42:33 +0000 Message-ID: In-Reply-To: <1BAE371E-55EE-47B2-8611-3ACE7D9835DF@free.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.13] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org list" Subject: Re: [Softwires] Questions on: draft-cui-softwire-host-4over6 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, 06 Apr 2011 13:41:10 -0000 Remi, > >The tradeoff could then be summarized as: > +----------------------------+--------------------+-----------------+ > | | Stateful (4over6) | Stateless (4rd) | > +----------------------------+--------------------+-----------------+ > | Customizable services | + | - | > | -------------------------- | ------------------ | --------------- | > | Ease of operation | - | + | > | -------------------------- | ------------------ | --------------- | > | Scalability | - | + | > | -------------------------- | ------------------ | --------------- | > | Invetment cost | - | + | > | minimization | | | > +----------------------------+--------------------+-----------------+ This choice of stateful or stateless are not so clear-cut. I guess we all agree that there are pros and cons in both camps. For example: stateful would yield better utilization of IPv4 addresses. It also decouples the IPv4 address from IPv6 address which makes the IPv4 address design a little easier. Your table is very much favor to stateless, I think this doesn't capture all the points. Regards, Yiu > From remi.despres@free.fr Wed Apr 6 07:02:37 2011 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 8DBF53A69C7 for ; Wed, 6 Apr 2011 07:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.324 X-Spam-Level: X-Spam-Status: No, score=-1.324 tagged_above=-999 required=5 tests=[AWL=0.625, 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 YecyzJdGG5sT for ; Wed, 6 Apr 2011 07:02:37 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by core3.amsl.com (Postfix) with ESMTP id BAFDC3A693E for ; Wed, 6 Apr 2011 07:02:36 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2303.sfr.fr (SMTP Server) with ESMTP id DE2647000081; Wed, 6 Apr 2011 16:04:19 +0200 (CEST) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2303.sfr.fr (SMTP Server) with ESMTP id B45A27000091; Wed, 6 Apr 2011 16:04:15 +0200 (CEST) X-SFR-UUID: 20110406140415738.B45A27000091@msfrf2303.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 6 Apr 2011 16:04:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <418CDF84-A2AC-441D-B229-852CA630954A@free.fr> References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org list" Subject: Re: [Softwires] Questions on: draft-cui-softwire-host-4over6 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, 06 Apr 2011 14:02:37 -0000 Le 6 avr. 2011 =E0 15:42, Lee, Yiu a =E9crit : > Remi, >=20 >=20 >>=20 >> The tradeoff could then be summarized as: >> +----------------------------+--------------------+-----------------+ >> | | Stateful (4over6) | Stateless (4rd) | >> +----------------------------+--------------------+-----------------+ >> | Customizable services | + | - | >> | -------------------------- | ------------------ | --------------- | >> | Ease of operation | - | + | >> | -------------------------- | ------------------ | --------------- | >> | Scalability | - | + | >> | -------------------------- | ------------------ | --------------- | >> | Invetment cost | - | + | >> | minimization | | | >> +----------------------------+--------------------+-----------------+ >=20 > This choice of stateful or stateless are not so clear-cut. I guess we = all > agree that there are pros and cons in both camps. For example: = stateful > would yield better utilization of IPv4 addresses. Agreed An additional line showing a + for stateful can cover the point. > It also decouples the > IPv4 address from IPv6 address which makes the IPv4 address design a > little easier. Partially agreed. - If all IPv6 customers are given the same number of IPv4 ports, 4rd = doesn't imply anything on Pv6 routing., - If there are several 4over6 concentrators, there are constraints on = the IPv6 routing to ensure satisfactory load sharing between them with = stable routes. - Furthermore, if these concentrators are far from one another, they = imply that the IPv4 backbone ensures symmetric routing so that all = return traffic from a concentrator comes back to it. > Your table is very much favor to stateless, I think this > doesn't capture all the points. Agreed, at least concerning the first point above. I view it as a convenient discussion tool. Regards, RD >=20 > Regards, > Yiu >=20 >>=20 >=20 From yiu_lee@cable.comcast.com Wed Apr 6 12:05:07 2011 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 8D6E43A6978 for ; Wed, 6 Apr 2011 12:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.826 X-Spam-Level: X-Spam-Status: No, score=-102.826 tagged_above=-999 required=5 tests=[AWL=-1.391, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, 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 FOuj2LA7uyNK for ; Wed, 6 Apr 2011 12:05:06 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 1CB123A6976 for ; Wed, 6 Apr 2011 12:05:06 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.32687251; Wed, 06 Apr 2011 13:09:35 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Wed, 6 Apr 2011 15:06:37 -0400 From: "Lee, Yiu" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Thread-Topic: [Softwires] Questions on: draft-cui-softwire-host-4over6 Thread-Index: AQHL9I3AhhkX7AaqaUaFyAHIE10suw== Date: Wed, 6 Apr 2011 19:06:36 +0000 Message-ID: In-Reply-To: <418CDF84-A2AC-441D-B229-852CA630954A@free.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.13] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org list" Subject: Re: [Softwires] Questions on: draft-cui-softwire-host-4over6 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, 06 Apr 2011 19:05:07 -0000 Hi Remi, On 4/6/11 10:04 AM, "R=E9mi Despr=E9s" wrote: >Partially agreed. >- If all IPv6 customers are given the same number of IPv4 ports, 4rd >doesn't imply anything on Pv6 routing., >- If there are several 4over6 concentrators, there are constraints on the >IPv6 routing to ensure satisfactory load sharing between them with stable >routes. >- Furthermore, if these concentrators are far from one another, they >imply that the IPv4 backbone ensures symmetric routing so that all return >traffic from a concentrator comes back to it. I think we are on the same page. What I meant is in the case of stateful 6to4, IPv6 address won't contain any IPv4 address in the prefix. That won't require coupling between the IPv4 and IPv6 prefixes. It may or may not be a problem for some operators. LB is a different issue. It doesn't relate to address coupling. That said, it isn't so straight forward for stateless approach because it depends on the placement of the BR and the v6 routing to the anycast address. For stateful 4to6, the outgoing and incoming v4 traffic are symmetric because all v4 traffic must traverse the concentrator. I don=B9t see why th= e backbone has to do something special for it. /Yiu From remi.despres@free.fr Wed Apr 6 14:18:04 2011 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 692D23A6956 for ; Wed, 6 Apr 2011 14:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.339 X-Spam-Level: X-Spam-Status: No, score=-1.339 tagged_above=-999 required=5 tests=[AWL=0.610, 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 oGYeBsHtXwVn for ; Wed, 6 Apr 2011 14:18:03 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by core3.amsl.com (Postfix) with ESMTP id 883FA3A67D3 for ; Wed, 6 Apr 2011 14:18:03 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2109.sfr.fr (SMTP Server) with ESMTP id 137637000091; Wed, 6 Apr 2011 23:19:47 +0200 (CEST) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2109.sfr.fr (SMTP Server) with ESMTP id 6149B7000090; Wed, 6 Apr 2011 23:19:45 +0200 (CEST) X-SFR-UUID: 20110406211945398.6149B7000090@msfrf2109.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 6 Apr 2011 23:19:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3BBE8349-70BC-4FBC-916A-7F2791CB0374@free.fr> References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org list" Subject: Re: [Softwires] Questions on: draft-cui-softwire-host-4over6 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, 06 Apr 2011 21:18:04 -0000 Yiu, I am not sure we completely understand each other here. Please tell me if what I write is insufficiently clear. Le 6 avr. 2011 =E0 21:06, Lee, Yiu a =E9crit : > Hi Remi, >=20 > On 4/6/11 10:04 AM, "R=E9mi Despr=E9s" wrote: >=20 >> Partially agreed. >> - If all IPv6 customers are given the same number of IPv4 ports, 4rd >> doesn't imply anything on Pv6 routing., >> - If there are several 4over6 concentrators, there are constraints on = the >> IPv6 routing to ensure satisfactory load sharing between them with = stable >> routes. >> - Furthermore, if these concentrators are far from one another, they >> imply that the IPv4 backbone ensures symmetric routing so that all = return >> traffic from a concentrator comes back to it. >=20 > I think we are on the same page. What I meant is in the case of = stateful > 6to4, IPv6 address won't contain any IPv4 address in the prefix. That > won't require coupling between the IPv4 and IPv6 prefixes. It may or = may > not be a problem for some operators. IPv6 prefixes of 6rd don't contain IPv4 embedded addresses (they differ = in this respect from the stateless A+P described in the aplusp draft). With 4rd, if all CE's get IPv6 prefixes having the same length, and are = assigned the same number of IPv4 ports, the IPv6 routing is taken as is. It is only after that that one or a few mapping rules, whose parameters = can be advertised in stateless DHCPv6, define how each CE derives its = shared IPv4 address and port set from its IPv6 prefix. > LB is a different issue. It doesn't relate to address coupling. That = said, > it isn't so straight forward for stateless approach because it depends = on > the placement of the BR and the v6 routing to the anycast address. Routing of the IPv6 network can be reconfigured at any time without = breaking connections. Load balancing can be performed without any concern for packets of each = connection having to go to the same BR, which makes it simpler.=20 > For stateful 4to6, the outgoing and incoming v4 traffic are symmetric > because all v4 traffic must traverse the concentrator. I don=B9t see = why the > backbone has to do something special for it. If there is only one concentrator, no problem. But if there are several widely separated concentrators, and they are = reachable at the same PI prefix at the border between the IPv6-only = network and the IPv4 backbone, then there is a return path problem.=20 RD PS: I may be able to continue tomorrow, but then will be unreachable = until April 25. From yiu_lee@cable.comcast.com Wed Apr 6 15:19:32 2011 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 5BEEA3A68DF for ; Wed, 6 Apr 2011 15:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.794 X-Spam-Level: X-Spam-Status: No, score=-102.794 tagged_above=-999 required=5 tests=[AWL=-1.359, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, 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 1LCfQJLTxekE for ; Wed, 6 Apr 2011 15:19:28 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 806383A68B9 for ; Wed, 6 Apr 2011 15:19:28 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.32730425; Wed, 06 Apr 2011 16:23:58 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Wed, 6 Apr 2011 18:20:59 -0400 From: "Lee, Yiu" To: =?windows-1254?Q?R=E9mi_Despr=E9s?= Thread-Topic: [Softwires] Questions on: draft-cui-softwire-host-4over6 Thread-Index: AQHL9Kjn6fW4V8AYiEeVjGTqzvp74g== Date: Wed, 6 Apr 2011 22:20:58 +0000 Message-ID: In-Reply-To: <3BBE8349-70BC-4FBC-916A-7F2791CB0374@free.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.11] Content-Type: text/plain; charset="windows-1254" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org list" Subject: Re: [Softwires] Questions on: draft-cui-softwire-host-4over6 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, 06 Apr 2011 22:19:32 -0000 Hi Remi, I think I mis-read Figure 1 in your draft. As I read this, I think the current design will completely rely on dhcp to manage the v4 prefix. Yes, this decouples the v4 and v6 addresses, but this will add additional operation effort on dhcp. Also, if an ISP has many small IPv4 prefixes they want to use in 4rd, it will require to provision all of them to the BR. This may be ok for some operators, but not all operators. In term of single or multiple 4over6 concentrators, I don't see people will advertise the same PI from two far away concentrators. So the return packet will also go back to the same (or close) concentrator. That said, I agree that stateless is always easier for HA. I have no disagreement on this. In the end, they have pros and cons. Based on the ISP's requirements, it is just a matter of choice. Cheers, /Yiu On 4/6/11 5:19 PM, "R=E9mi Despr=E9s" wrote: >Yiu, > >I am not sure we completely understand each other here. >Please tell me if what I write is insufficiently clear. > >Le 6 avr. 2011 =E0 21:06, Lee, Yiu a =E9crit : > >> Hi Remi, >>=20 >> On 4/6/11 10:04 AM, "R=E9mi Despr=E9s" wrote: >>=20 >>> Partially agreed. >>> - If all IPv6 customers are given the same number of IPv4 ports, 4rd >>> doesn't imply anything on Pv6 routing., >>> - If there are several 4over6 concentrators, there are constraints on >>>the >>> IPv6 routing to ensure satisfactory load sharing between them with >>>stable >>> routes. >>> - Furthermore, if these concentrators are far from one another, they >>> imply that the IPv4 backbone ensures symmetric routing so that all >>>return >>> traffic from a concentrator comes back to it. >>=20 >> I think we are on the same page. What I meant is in the case of stateful >> 6to4, IPv6 address won't contain any IPv4 address in the prefix. That >> won't require coupling between the IPv4 and IPv6 prefixes. It may or may >> not be a problem for some operators. > >IPv6 prefixes of 6rd don't contain IPv4 embedded addresses (they differ >in this respect from the stateless A+P described in the aplusp draft). >With 4rd, if all CE's get IPv6 prefixes having the same length, and are >assigned the same number of IPv4 ports, the IPv6 routing is taken as is. >It is only after that that one or a few mapping rules, whose parameters >can be advertised in stateless DHCPv6, define how each CE derives its >shared IPv4 address and port set from its IPv6 prefix. > >> LB is a different issue. It doesn't relate to address coupling. That >>said, >> it isn't so straight forward for stateless approach because it depends >>on >> the placement of the BR and the v6 routing to the anycast address. > >Routing of the IPv6 network can be reconfigured at any time without >breaking connections. >Load balancing can be performed without any concern for packets of each >connection having to go to the same BR, which makes it simpler. > > >> For stateful 4to6, the outgoing and incoming v4 traffic are symmetric >> because all v4 traffic must traverse the concentrator. I don=B9t see why >>the >> backbone has to do something special for it. > >If there is only one concentrator, no problem. >But if there are several widely separated concentrators, and they are >reachable at the same PI prefix at the border between the IPv6-only >network and the IPv4 backbone, then there is a return path problem. > >RD > >PS: I may be able to continue tomorrow, but then will be unreachable >until April 25. > > > > From matsuhira@jp.fujitsu.com Wed Apr 6 21:46:41 2011 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 150FC3A69F7 for ; Wed, 6 Apr 2011 21:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.202 X-Spam-Level: X-Spam-Status: No, score=-101.202 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 nEX5Z87FHexC for ; Wed, 6 Apr 2011 21:46:40 -0700 (PDT) Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by core3.amsl.com (Postfix) with ESMTP id EE2EB3A69F3 for ; Wed, 6 Apr 2011 21:46:39 -0700 (PDT) Received: from m1.gw.fujitsu.co.jp (unknown [10.0.50.71]) by fgwmail6.fujitsu.co.jp (Postfix) with ESMTP id 9FACA3EE0B5 for ; Thu, 7 Apr 2011 13:48:23 +0900 (JST) Received: from smail (m1 [127.0.0.1]) by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 884242AEA8D for ; Thu, 7 Apr 2011 13:48:23 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91]) by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 7119D1EF087 for ; Thu, 7 Apr 2011 13:48:23 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 6581B1DB804B for ; Thu, 7 Apr 2011 13:48:23 +0900 (JST) Received: from m000.s.css.fujitsu.com (m000.s.css.fujitsu.com [10.23.4.38]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 395DD1DB804D for ; Thu, 7 Apr 2011 13:48:23 +0900 (JST) Received: from m000.css.fujitsu.com (m000 [127.0.0.1]) by m000.s.css.fujitsu.com (Postfix) with ESMTP id 22D232DF9C8; Thu, 7 Apr 2011 13:48:23 +0900 (JST) Received: from [127.0.0.1] (fj86077803.sl046.dhcp.css.fujitsu.com [10.77.46.62]) by m000.s.css.fujitsu.com (Postfix) with ESMTP id E12AC2E00E5; Thu, 7 Apr 2011 13:48:22 +0900 (JST) X-SecurityPolicyCheck: OK by SHieldMailChecker v1.5.1 Message-ID: <4D9D416E.1040201@jp.fujitsu.com> Date: Thu, 07 Apr 2011 13:45:34 +0900 From: Naoki Matsuhira User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "softwires@ietf.org list" Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [Softwires] sa46t portal 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, 07 Apr 2011 04:46:41 -0000 For our convenience, I prepared a very very simple portal web page of sa46t. There are links for Internet drafts and presentation slides in that page. Some documents are Japanese only. Please visit. https://sites.google.com/site/sa46tnet/ Naoki Matsuhira From remi.despres@free.fr Wed Apr 6 22:16:52 2011 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 2B7173A69FE for ; Wed, 6 Apr 2011 22:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.35 X-Spam-Level: X-Spam-Status: No, score=-1.35 tagged_above=-999 required=5 tests=[AWL=0.599, 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 XQJAAgbcjHun for ; Wed, 6 Apr 2011 22:16:51 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.22]) by core3.amsl.com (Postfix) with ESMTP id 3D3DA3A69F9 for ; Wed, 6 Apr 2011 22:16:51 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2301.sfr.fr (SMTP Server) with ESMTP id CA2F1700008B; Thu, 7 Apr 2011 07:18:34 +0200 (CEST) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2301.sfr.fr (SMTP Server) with ESMTP id F13257000087; Thu, 7 Apr 2011 07:18:30 +0200 (CEST) X-SFR-UUID: 20110407051830988.F13257000087@msfrf2301.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 7 Apr 2011 07:18:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org list" Subject: Re: [Softwires] Questions on: draft-cui-softwire-host-4over6 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, 07 Apr 2011 05:16:52 -0000 Le 7 avr. 2011 =E0 00:20, Lee, Yiu a =E9crit : > Hi Remi, >=20 > I think I mis-read Figure 1 in your draft. As I read this, I think the > current design will completely rely on dhcp to manage the v4 prefix. = Yes, > this decouples the v4 and v6 addresses, but this will add additional > operation effort on dhcp. Also, if an ISP has many small IPv4 prefixes > they want to use in 4rd, it will require to provision all of them to = the > BR. This may be ok for some operators, but not all operators. >=20 > In term of single or multiple 4over6 concentrators, I don't see people > will advertise the same PI from two far away concentrators. So the = return > packet will also go back to the same (or close) concentrator. That = said, I > agree that stateless is always easier for HA. I have no disagreement = on > this. >=20 > In the end, they have pros and cons. Based on the ISP's requirements, = it > is just a matter of choice. We agree. Thanks. RD >=20 > Cheers, > /Yiu >=20 > On 4/6/11 5:19 PM, "R=E9mi Despr=E9s" wrote: >=20 >> Yiu, >>=20 >> I am not sure we completely understand each other here. >> Please tell me if what I write is insufficiently clear. >>=20 >> Le 6 avr. 2011 =E0 21:06, Lee, Yiu a =E9crit : >>=20 >>> Hi Remi, >>>=20 >>> On 4/6/11 10:04 AM, "R=E9mi Despr=E9s" wrote: >>>=20 >>>> Partially agreed. >>>> - If all IPv6 customers are given the same number of IPv4 ports, = 4rd >>>> doesn't imply anything on Pv6 routing., >>>> - If there are several 4over6 concentrators, there are constraints = on >>>> the >>>> IPv6 routing to ensure satisfactory load sharing between them with >>>> stable >>>> routes. >>>> - Furthermore, if these concentrators are far from one another, = they >>>> imply that the IPv4 backbone ensures symmetric routing so that all >>>> return >>>> traffic from a concentrator comes back to it. >>>=20 >>> I think we are on the same page. What I meant is in the case of = stateful >>> 6to4, IPv6 address won't contain any IPv4 address in the prefix. = That >>> won't require coupling between the IPv4 and IPv6 prefixes. It may or = may >>> not be a problem for some operators. >>=20 >> IPv6 prefixes of 6rd don't contain IPv4 embedded addresses (they = differ >> in this respect from the stateless A+P described in the aplusp = draft). >> With 4rd, if all CE's get IPv6 prefixes having the same length, and = are >> assigned the same number of IPv4 ports, the IPv6 routing is taken as = is. >> It is only after that that one or a few mapping rules, whose = parameters >> can be advertised in stateless DHCPv6, define how each CE derives its >> shared IPv4 address and port set from its IPv6 prefix. >>=20 >>> LB is a different issue. It doesn't relate to address coupling. That >>> said, >>> it isn't so straight forward for stateless approach because it = depends >>> on >>> the placement of the BR and the v6 routing to the anycast address. >>=20 >> Routing of the IPv6 network can be reconfigured at any time without >> breaking connections. >> Load balancing can be performed without any concern for packets of = each >> connection having to go to the same BR, which makes it simpler. >>=20 >>=20 >>> For stateful 4to6, the outgoing and incoming v4 traffic are = symmetric >>> because all v4 traffic must traverse the concentrator. I don=B9t see = why >>> the >>> backbone has to do something special for it. >>=20 >> If there is only one concentrator, no problem. >> But if there are several widely separated concentrators, and they are >> reachable at the same PI prefix at the border between the IPv6-only >> network and the IPv4 backbone, then there is a return path problem. >>=20 >> RD >>=20 >> PS: I may be able to continue tomorrow, but then will be unreachable >> until April 25. >>=20 >>=20 >>=20 >>=20 >=20 From xiaohong.deng@orange-ftgroup.com Wed Apr 6 22:30:23 2011 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 82E913A69F5 for ; Wed, 6 Apr 2011 22:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.242 X-Spam-Level: X-Spam-Status: No, score=-0.242 tagged_above=-999 required=5 tests=[AWL=-1.328, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqpalEro8P3D for ; Wed, 6 Apr 2011 22:30:15 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 216A13A6863 for ; Wed, 6 Apr 2011 22:30:03 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 09462FC4003 for ; Thu, 7 Apr 2011 07:31:54 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id ED4F8FC4001 for ; Thu, 7 Apr 2011 07:31:53 +0200 (CEST) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Apr 2011 07:31:46 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBF4E5.14569CDF" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 7 Apr 2011 13:31:42 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC0168525A@ch-mailsrv.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW:[Int-area] Stateless IPv4-in-IPv6 experiments && DS-Lite/NAT64 experiments Thread-Index: Acv0dqpjDSVsZIxJQe6Yllay01rTEgAXyLQgAAPMEyA= From: To: X-OriginalArrivalTime: 07 Apr 2011 05:31:46.0281 (UTC) FILETIME=[15EE2D90:01CBF4E5] Subject: [Softwires] FW:[Int-area] Stateless IPv4-in-IPv6 experiments && DS-Lite/NAT64 experiments 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, 07 Apr 2011 05:30:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBF4E5.14569CDF Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable We have tested how applications behave when it has both DS-Lite IPv4 and = NAT64 IPv6 (but not native IPv6). Firefox, IE, Skype, Google Earth = v5.2.1, Live Messenger, uTorrent, BitComet, were on our test list.=20 =20 Despres,regarding your question ( maybe not answering your question = exactly as we tested NAT64 IPv6 instead of native IPv6 ), uTorrent v2.2 = used IPv6 for login/authentication but IPv4 for the data exchange, for = IPv6 peer was not able to talk to IPv4 peer. Although BitComet v1.23 = issued both A and AAAA quires, it completely ignored AAAA RR and only = used IPv4 for communication. =20 Please also see some of other test results below. DS-Lite/NAT64 = experiments could be documented if it is of interests.=20 =20 Tested Apps IPv4/IPv6 portion Firefox (Non-vedio) v3.6.12 All IPv6 =20 video website Half/ half =20 IE (Non-vedio) v6.0 All IPv6 =20 Skype v5.0 Major IPv6 =20 Google Earth v5.2.1 Major IPv6 =20 Live Messenger 2009 Major IPv4 =20 uTorrent v2.2 Major IPv4 =20 BitComet v1.23 All IPv4 =20 =20 BR, Xiaohong opensource A+P: http://opensourceaplusp.weebly.com/ =20 ________________________________ =B7=A2=BC=FE=C8=CB: R=A8=A6mi Despr=A8=A6s = [mailto:remi.despres@free.fr]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C27=C8=D5 0:21 =CA=D5=BC=FE=C8=CB: DENG Xiaohong ESP/PEK =B3=AD=CB=CD: int-area@ietf.org =D6=F7=CC=E2: Re: [Int-area] Stateless IPv4-in-IPv6 experiments =09 =09 Thank you, Xiahong, for sharing this interesting information.=20 In the case of BitComet and uTorrent, I wonder what happens if the host = has both A+P IPv4 and IPv6, as opposed to just A+P IPv4. Did you try that? Regards, RD Le 6 avr. 2011 =A8=A4 10:57, = a =A8=A6crit : Dear all, =20 An I-D about stateless IPv4-in-IPv6 experiments has been submitted. A = URL for this Internet-Draft is: = http://tools.ietf.org/html/draft-deng-aplusp-experiment-results-00 = . =20 A website introducing the detail of experiment results is also = accessible via: http://opensourceaplusp.weebly.com/ = =20 =20 BR, Xiaohong _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area =09 ------_=_NextPart_001_01CBF4E5.14569CDF Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable
We=20 have=20 tested=20 how applications behave when it has both DS-Lite=20 IPv4=20 and NAT64 IPv6 (but not native IPv6).=20 Firefox,=20 IE, Skype, Google Earth v5.2.1, Live Messenger, uTorrent, = BitComet,=20 were on our test list. 

 

Despres,regarding your=20 question (=20 maybe not answering your question exactly as we tested NAT64=20 IPv6 instead of native IPv6 ), uTorrent v2.2 used IPv6 for=20 login/authentication but IPv4 for the data exchange, for IPv6 peer was = not able=20 to talk to IPv4 peer. Although BitComet v1.23 issued both A and AAAA = quires, it=20 completely ignored AAAA RR and only used IPv4 for=20 communication.

 

Please also see some of other test results below. DS-Lite/NAT64 experiments could be = documented if it is=20 of interests.

 

Tested Apps                   IPv4/IPv6 = portion

Firefox (Non-vedio) v3.6.12   All IPv6           &nbs= p;            = ;    =20

video website           &nbs= p;    =20 Half/ half          =20  

IE (Non-vedio) v6.0  =20      =    All IPv6           &nbs= p;            = ;   =20

Skype v5.0           =20        =20 Major IPv6          =20             &nbs= p; =20

Google Earth v5.2.1          =20 Major IPv6           &n= bsp; =20      =20

Live Messenger 2009          =20 Major IPv4           =20

uTorrent v2.2           &nbs= p;    =20 Major IPv4    =20

BitComet v1.23           &nbs= p;   =20 All IPv4      =20

 

BR,

Xiaohong

opensource A+P: http://opensourceaplusp.weeb= ly.com/

 

=B7=A2=BC=FE=C8=CB: = R=A8=A6mi Despr=A8=A6s [mailto:remi.despres@free.fr]=20
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C27=C8=D5 = 0:21
=CA=D5=BC=FE=C8=CB: DENG Xiaohong=20 ESP/PEK
=B3=AD=CB=CD: = int-area@ietf.org
=D6=F7=CC=E2: Re: [Int-area] Stateless=20 IPv4-in-IPv6 experiments

Thank you, Xiahong, for sharing this interesting = information.=20

In the case of BitComet and uTorrent, I wonder what happens if = the host=20 has both A+P IPv4 and IPv6, as opposed to just A+P IPv4.
Did you try that?

Regards,
RD

Le 6 avr. 2011 =A8=A4 10:57, <xiaohong.deng@orange-ftg= roup.com>=20 <xiaohong.deng@orange-ftg= roup.com>=20 a =A8=A6crit :

Dear=20 all,
 
An I-D about stateless = IPv4-in-IPv6 experiments has been submitted.=20 A URL = for this=20 Internet-Draft is: http://tools.ietf.org/html/draft-deng-aplusp-experiment-r= esults-00.
 
A website=20 introducing the detail of experiment results is also accessible = via: http://opensourceaplusp.weebly.com/
 
BR,
Xiaohong
______________________________= _________________
Int-area=20 mailing list
Int-area@ietf.org
https://www.ie= tf.org/mailman/listinfo/int-area

------_=_NextPart_001_01CBF4E5.14569CDF-- From yiu_lee@cable.comcast.com Thu Apr 7 07:20:48 2011 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 0974D28C0E1 for ; Thu, 7 Apr 2011 07:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.37 X-Spam-Level: X-Spam-Status: No, score=-100.37 tagged_above=-999 required=5 tests=[AWL=-3.723, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 7xXWBvh044ai for ; Thu, 7 Apr 2011 07:20:46 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id ED7A03A68C4 for ; Thu, 7 Apr 2011 07:20:44 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.32800168; Thu, 07 Apr 2011 08:14:00 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Thu, 7 Apr 2011 10:11:03 -0400 From: "Lee, Yiu" To: "xiaohong.deng@orange-ftgroup.com" , "softwires@ietf.org" Thread-Topic: [Softwires] FW:[Int-area] Stateless IPv4-in-IPv6 experiments && DS-Lite/NAT64 experiments Thread-Index: AQHL9S2gaZmTYn9G10S+T0Bdmfg6FQ== Date: Thu, 7 Apr 2011 14:11:02 +0000 Message-ID: In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC0168525A@ch-mailsrv.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.13] Content-Type: multipart/alternative; boundary="_000_C9C33E0AC522yiuleecablecomcastcom_" MIME-Version: 1.0 Subject: Re: [Softwires] FW:[Int-area] Stateless IPv4-in-IPv6 experiments && DS-Lite/NAT64 experiments 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, 07 Apr 2011 14:20:48 -0000 --_000_C9C33E0AC522yiuleecablecomcastcom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgWGlhb2hvbmcsDQoNCkkgYW0gcGVyc29uYWxseSB2ZXJ5IGludGVyZXN0ZWQgaW4gdGhlIGRh dGEuIERvIHlvdSBhbHNvIGRvY3VtZW50IHdoYXQgbWF5IGJyZWFrIHRoZSBhcHBsaWNhdGlvbnM/ DQoNClRoYW5rcywNCllpdQ0KDQpGcm9tOiA8eGlhb2hvbmcuZGVuZ0BvcmFuZ2UtZnRncm91cC5j b208bWFpbHRvOnhpYW9ob25nLmRlbmdAb3JhbmdlLWZ0Z3JvdXAuY29tPj4NCkRhdGU6IFRodSwg NyBBcHIgMjAxMSAxMzozMTo0MiArMDgwMA0KVG86IDxzb2Z0d2lyZXNAaWV0Zi5vcmc8bWFpbHRv OnNvZnR3aXJlc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBbU29mdHdpcmVzXSBGVzpbSW50LWFyZWFd IFN0YXRlbGVzcyBJUHY0LWluLUlQdjYgZXhwZXJpbWVudHMgJiYgRFMtTGl0ZS9OQVQ2NCBleHBl cmltZW50cw0KDQpXZSBoYXZlIHRlc3RlZCBob3cgYXBwbGljYXRpb25zIGJlaGF2ZSB3aGVuIGl0 IGhhcyBib3RoIERTLUxpdGUgSVB2NCBhbmQgTkFUNjQgSVB2NiAoYnV0IG5vdCBuYXRpdmUgSVB2 NikuIEZpcmVmb3gsIElFLCBTa3lwZSwgR29vZ2xlIEVhcnRoIHY1LjIuMSwgTGl2ZSBNZXNzZW5n ZXIsIHVUb3JyZW50LCBCaXRDb21ldCwgd2VyZSBvbiBvdXIgdGVzdCBsaXN0Lg0KDQpEZXNwcmVz LHJlZ2FyZGluZyB5b3VyIHF1ZXN0aW9uICggbWF5YmUgbm90IGFuc3dlcmluZyB5b3VyIHF1ZXN0 aW9uIGV4YWN0bHkgYXMgd2UgdGVzdGVkIE5BVDY0IElQdjYgaW5zdGVhZCBvZiBuYXRpdmUgSVB2 NiApLCB1VG9ycmVudCB2Mi4yIHVzZWQgSVB2NiBmb3IgbG9naW4vYXV0aGVudGljYXRpb24gYnV0 IElQdjQgZm9yIHRoZSBkYXRhIGV4Y2hhbmdlLCBmb3IgSVB2NiBwZWVyIHdhcyBub3QgYWJsZSB0 byB0YWxrIHRvIElQdjQgcGVlci4gQWx0aG91Z2ggQml0Q29tZXQgdjEuMjMgaXNzdWVkIGJvdGgg QSBhbmQgQUFBQSBxdWlyZXMsIGl0IGNvbXBsZXRlbHkgaWdub3JlZCBBQUFBIFJSIGFuZCBvbmx5 IHVzZWQgSVB2NCBmb3IgY29tbXVuaWNhdGlvbi4NCg0KUGxlYXNlIGFsc28gc2VlIHNvbWUgb2Yg b3RoZXIgdGVzdCByZXN1bHRzIGJlbG93LiBEUy1MaXRlL05BVDY0IGV4cGVyaW1lbnRzIGNvdWxk IGJlIGRvY3VtZW50ZWQgaWYgaXQgaXMgb2YgaW50ZXJlc3RzLg0KDQpUZXN0ZWQgQXBwcyAgICAg ICAgICAgICAgICAgICBJUHY0L0lQdjYgcG9ydGlvbg0KRmlyZWZveCAoTm9uLXZlZGlvKSB2My42 LjEyICAgQWxsIElQdjYNCnZpZGVvIHdlYnNpdGUgICAgICAgICAgICAgICAgIEhhbGYvIGhhbGYN CklFIChOb24tdmVkaW8pIHY2LjAgICAgICAgICAgIEFsbCBJUHY2DQpTa3lwZSB2NS4wICAgICAg ICAgICAgICAgICAgICBNYWpvciBJUHY2DQpHb29nbGUgRWFydGggdjUuMi4xICAgICAgICAgICBN YWpvciBJUHY2DQpMaXZlIE1lc3NlbmdlciAyMDA5ICAgICAgICAgICBNYWpvciBJUHY0DQp1VG9y cmVudCB2Mi4yICAgICAgICAgICAgICAgICBNYWpvciBJUHY0DQpCaXRDb21ldCB2MS4yMyAgICAg ICAgICAgICAgICBBbGwgSVB2NA0KDQpCUiwNClhpYW9ob25nDQpvcGVuc291cmNlIEErUDogaHR0 cDovL29wZW5zb3VyY2VhcGx1c3Aud2VlYmx5LmNvbS8NCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0Kt6K8/sjLOiBSqKZtaSBEZXNwcqimcyBbbWFpbHRvOnJlbWkuZGVzcHJl c0BmcmVlLmZyXQ0Kt6LLzcqxvOQ6IDIwMTHE6jTUwjfI1SAwOjIxDQrK1bz+yMs6IERFTkcgWGlh b2hvbmcgRVNQL1BFSw0Ks63LzTogaW50LWFyZWFAaWV0Zi5vcmc8bWFpbHRvOmludC1hcmVhQGll dGYub3JnPg0K1vfM4jogUmU6IFtJbnQtYXJlYV0gU3RhdGVsZXNzIElQdjQtaW4tSVB2NiBleHBl cmltZW50cw0KDQpUaGFuayB5b3UsIFhpYWhvbmcsIGZvciBzaGFyaW5nIHRoaXMgaW50ZXJlc3Rp bmcgaW5mb3JtYXRpb24uDQoNCkluIHRoZSBjYXNlIG9mIEJpdENvbWV0IGFuZCB1VG9ycmVudCwg SSB3b25kZXIgd2hhdCBoYXBwZW5zIGlmIHRoZSBob3N0IGhhcyBib3RoIEErUCBJUHY0IGFuZCBJ UHY2LCBhcyBvcHBvc2VkIHRvIGp1c3QgQStQIElQdjQuDQpEaWQgeW91IHRyeSB0aGF0Pw0KDQpS ZWdhcmRzLA0KUkQNCg0KTGUgNiBhdnIuIDIwMTEgqKQgMTA6NTcsIDx4aWFvaG9uZy5kZW5nQG9y YW5nZS1mdGdyb3VwLmNvbTxtYWlsdG86eGlhb2hvbmcuZGVuZ0BvcmFuZ2UtZnRncm91cC5jb20+ PiA8eGlhb2hvbmcuZGVuZ0BvcmFuZ2UtZnRncm91cC5jb208bWFpbHRvOnhpYW9ob25nLmRlbmdA b3JhbmdlLWZ0Z3JvdXAuY29tPj4gYSCopmNyaXQgOg0KDQpEZWFyIGFsbCwNCg0KQW4gSS1EIGFi b3V0IHN0YXRlbGVzcyBJUHY0LWluLUlQdjYgZXhwZXJpbWVudHMgaGFzIGJlZW4gc3VibWl0dGVk LiBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczogaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtZGVuZy1hcGx1c3AtZXhwZXJpbWVudC1yZXN1bHRzLTAwLg0KDQpBIHdlYnNp dGUgaW50cm9kdWNpbmcgdGhlIGRldGFpbCBvZiBleHBlcmltZW50IHJlc3VsdHMgaXMgYWxzbyBh Y2Nlc3NpYmxlIHZpYTogaHR0cDovL29wZW5zb3VyY2VhcGx1c3Aud2VlYmx5LmNvbS8NCg0KQlIs DQpYaWFvaG9uZw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkludC1hcmVhIG1haWxpbmcgbGlzdA0KSW50LWFyZWFAaWV0Zi5vcmc8bWFpbHRvOkludC1h cmVhQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnQt YXJlYQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBT b2Z0d2lyZXMgbWFpbGluZyBsaXN0IFNvZnR3aXJlc0BpZXRmLm9yZzxtYWlsdG86U29mdHdpcmVz QGlldGYub3JnPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJl cw0K --_000_C9C33E0AC522yiuleecablecomcastcom_ Content-Type: text/html; charset="gb2312" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Xiaohong,

I am personally very interested in the data. Do you also document what= may break the applications?

Thanks,
Yiu

From: <xiaohong.deng@orange-ftgroup.com>
Date: Thu, 7 Apr 2011 13:31:42 += ;0800
To: <softwires@ietf.org>
Subject: [Softwires] FW:[Int-area] = Stateless IPv4-in-IPv6 experiments && DS-Lite/NAT64 experiments

We have tested how applications behave when it has both DS-Li= te IPv4 and NAT64 IPv6 (but not native IPv6). Firefox, IE, Skype, Google Earth v5.2.1, Live Messeng= er, uTorrent, BitComet, were on our test list. 

 

Despres,regarding your question ( maybe not answering your question exactly as we&nbs= p;tested NAT64 IPv6 instead of native IPv6 ), uTorrent v2.2 use= d IPv6 for login/authentication but IPv4 for the data exchange, for IPv6 peer was not able to talk to IPv4 peer. Although BitCom= et v1.23 issued both A and AAAA quires, it completely ignored AAAA RR and o= nly used IPv4 for communication.

 

Please also see some of other test results below. DS-Lite/NAT64 experiments could be documented if it is of interests.

 

Tested Apps                   IPv4/IPv6 portion

Firefox (Non-vedio) v3.6.12   Al= l IPv6      =             &nb= sp;         

video website     &nbs= p;           Half/= half      =       

IE (Non-vedio) v6.0           All IPv6&n= bsp;            = ;            &n= bsp; 

Skype v5.0      &= nbsp;     &nbs= p;       Major IPv6    =             &n= bsp;        

Google Earth v5.2.1     = ;      Major IPv6           &= nbsp;       

Live Messenger 2009    &nb= sp;      Major IPv4           

uTorrent v2.2      &= nbsp;          Major IP= v4    

BitComet v1.23      =           All IPv4      

 

= BR,

Xiaohong

opensource A+P: http://opens= ourceaplusp.weebly.com/

 =

=B7=A2=BC=FE=C8=CB: R=A8=A6mi= Despr=A8=A6s [mailto:remi.despres@= free.fr]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C27=C8=D5 0:21
=CA=D5=BC=FE=C8=CB: DENG Xiaohong ESP/PEK
=B3=AD=CB=CD: int-area@ietf.org=
=D6=F7=CC=E2: Re: [Int-area] Stateless IPv4-in-IPv6 experiments

Thank you, Xiahong, for sharing this interesting information.

In the case of BitComet and uTorrent, I wonder what happens if the hos= t has both A+P IPv4 and IPv6, as opposed to just A+P IPv4.
Did you try that?

Regards,
RD

Le 6 avr. 2011 =A8=A4 10:57, <xiaohong.deng@orange-ftgroup.com> <xiaohong.deng@orange-ftgroup.com&g= t; a =A8=A6crit :

Dear all,
 
An I-D about stateless IPv4-in-IPv6 experiment= s has been submitted. A URL fo= r this Internet-Draft is: http://tools.ietf.org/html/draft-deng-aplusp-ex= periment-results-00.
 
A website introducing the detail of experiment results is also acc= essible via: htt= p://opensourceaplusp.weebly.com/
 
BR,
Xiaohong
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf= .org/mailman/listinfo/int-area

_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires --_000_C9C33E0AC522yiuleecablecomcastcom_-- From tena@huawei.com Thu Apr 7 11:13:52 2011 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 095723A6967 for ; Thu, 7 Apr 2011 11:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.06 X-Spam-Level: X-Spam-Status: No, score=-105.06 tagged_above=-999 required=5 tests=[AWL=-0.912, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, 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 ssbHjz0ip3OB for ; Thu, 7 Apr 2011 11:13:50 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 65DA03A695C for ; Thu, 7 Apr 2011 11:13:50 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJA00K9OO1XJJ@usaga02-in.huawei.com> for softwires@ietf.org; Thu, 07 Apr 2011 11:15:34 -0700 (PDT) Received: from TingZousc1 ([10.212.244.150]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJA00MMZO1WJW@usaga02-in.huawei.com> for softwires@ietf.org; Thu, 07 Apr 2011 11:15:33 -0700 (PDT) Date: Thu, 07 Apr 2011 11:15:31 -0700 From: Tina Tsou In-reply-to: <0962B0BEF842A24191AD9BE41A8DD2FC0168525A@ch-mailsrv.rd.francetelecom.fr> To: xiaohong.deng@orange-ftgroup.com, softwires@ietf.org Message-id: <011a01cbf54f$c8c13d80$5a43b880$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_NwMrDIIND9zyqU+O7ZjhrQ)" Content-language: en-us Thread-index: Acv0dqpjDSVsZIxJQe6Yllay01rTEgAXyLQgAAPMEyAAGqxBMA== References: <0962B0BEF842A24191AD9BE41A8DD2FC0168525A@ch-mailsrv.rd.francetelecom.fr> Subject: Re: [Softwires] FW:[Int-area] Stateless IPv4-in-IPv6 experiments && DS-Lite/NAT64 experiments 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, 07 Apr 2011 18:13:52 -0000 This is a multi-part message in MIME format. --Boundary_(ID_NwMrDIIND9zyqU+O7ZjhrQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi Xiao-hong, How many kinds of ALG should we support when using NAT64? =20 =20 We keep our promises with one another =A8C no matter what! =20 Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html =20 From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of xiaohong.deng@orange-ftgroup.com Sent: Wednesday, April 06, 2011 10:32 PM To: softwires@ietf.org Subject: [Softwires] FW:[Int-area] Stateless IPv4-in-IPv6 experiments && DS-Lite/NAT64 experiments =20 We have tested how applications behave when it has both DS-Lite IPv4 and NAT64 IPv6 (but not native IPv6). Firefox, IE, Skype, Google Earth = v5.2.1, Live Messenger, uTorrent, BitComet, were on our test list. =20 Despres,regarding your question ( maybe not answering your question = exactly as we tested NAT64 IPv6 instead of native IPv6 ), uTorrent v2.2 used = IPv6 for login/authentication but IPv4 for the data exchange, for IPv6 peer = was not able to talk to IPv4 peer. Although BitComet v1.23 issued both A and AAAA quires, it completely ignored AAAA RR and only used IPv4 for communication. =20 Please also see some of other test results below. DS-Lite/NAT64 = experiments could be documented if it is of interests.=20 =20 Tested Apps IPv4/IPv6 portion Firefox (Non-vedio) v3.6.12 All IPv6 =20 video website Half/ half =20 IE (Non-vedio) v6.0 All IPv6 =20 Skype v5.0 Major IPv6 =20 Google Earth v5.2.1 Major IPv6 =20 Live Messenger 2009 Major IPv4 =20 uTorrent v2.2 Major IPv4 =20 BitComet v1.23 All IPv4 =20 =20 BR, Xiaohong opensource A+P: http://opensourceaplusp.weebly.com/ =20 =20 _____ =20 =B7=A2=BC=FE=C8=CB: R=A8=A6mi Despr=A8=A6s [mailto:remi.despres@free.fr] = =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C27=C8=D5 0:21 =CA=D5=BC=FE=C8=CB: DENG Xiaohong ESP/PEK =B3=AD=CB=CD: int-area@ietf.org =D6=F7=CC=E2: Re: [Int-area] Stateless IPv4-in-IPv6 experiments Thank you, Xiahong, for sharing this interesting information.=20 =20 In the case of BitComet and uTorrent, I wonder what happens if the host = has both A+P IPv4 and IPv6, as opposed to just A+P IPv4. Did you try that? =20 Regards, RD =20 Le 6 avr. 2011 =A8=A4 10:57, a =A8=A6crit : Dear all, =20 An I-D about stateless IPv4-in-IPv6 experiments has been submitted. A = URL for this Internet-Draft is: http://tools.ietf.org/html/draft-deng-aplusp-experiment-results-00. =20 A website introducing the detail of experiment results is also = accessible via: http://opensourceaplusp.weebly.com/ =20 BR, Xiaohong _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area =20 --Boundary_(ID_NwMrDIIND9zyqU+O7ZjhrQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi Xiao-hong,

How many kinds of ALG should we support when using = NAT64?

 

 

We keep our promises with one = another =A8C no matter what!

 

Best = Regards,

Tina TSOU

http://tinatsou.weebly.com/contact= .html

 

From:= = softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On = Behalf Of xiaohong.deng@orange-ftgroup.com
Sent: = Wednesday, April 06, 2011 10:32 PM
To: = softwires@ietf.org
Subject: [Softwires] FW:[Int-area] = Stateless IPv4-in-IPv6 experiments && DS-Lite/NAT64 = experiments

 

We have tested how applications behave when it has = both DS-Lite IPv4 and NAT64 IPv6 (but not native IPv6). Firefox, IE, = Skype, Google Earth v5.2.1, Live Messenger, uTorrent, BitComet, were on = our test list.

 

Despres,regarding your question ( maybe not = answering your question exactly as we tested NAT64 IPv6 instead of native IPv6 ), uTorrent v2.2 used IPv6 = for login/authentication but IPv4 for the data exchange, for IPv6 peer = was not able to talk to IPv4 peer. Although BitComet v1.23 issued both A = and AAAA quires, it completely ignored AAAA RR and only used IPv4 for = communication.

 

Please also see some of other test results below. = DS-Lite/NAT64 experiments could be documented if it is of interests. =

 

Tested Apps            &nbs= p;       IPv4/IPv6 = portion

Firefox (Non-vedio) v3.6.12     All IPv6        = ;            =             =

video website        = ;           = Half/ half       &nbs= p;   

IE (Non-vedio) v6.0             = All IPv6        = ;            =             =

Skype v5.0        = ;              = Major IPv6       &nbs= p;            = ; 

Google Earth v5.2.1        = ;     Major IPv6       &nbs= p;              =

Live Messenger 2009        = ;     Major IPv4        = ;     

uTorrent v2.2        = ;           = Major IPv4      =

BitComet v1.23        = ;          All = IPv4        =

        =  

        = BR,

Xiaohong

opensource A+P: = http://opensourceaplusp.weeb= ly.com/

 

 

=B7=A2=BC=FE=C8=CB: = R=A8=A6mi Despr=A8=A6s [mailto:remi.despres@free.fr]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C27=C8=D5 0:21
=CA=D5=BC=FE=C8=CB: DENG Xiaohong = ESP/PEK
=B3=AD=CB=CD: = int-area@ietf.org
=D6=F7=CC=E2: Re: = [Int-area] Stateless IPv4-in-IPv6 experiments

Thank you, Xiahong, for sharing this interesting = information.

 

In the case of BitComet and uTorrent, I wonder what = happens if the host has both A+P IPv4 and IPv6, as opposed to just A+P = IPv4.

Did you try = that?

 

Regards,

RD

 

Le = 6 avr. 2011 =A8=A4 10:57, <xiaohong.deng@orange-ftg= roup.com> <xiaohong.deng@orange-ftg= roup.com> a =A8=A6crit :



=

Dear = all,

 

An I-D about = stateless IPv4-in-IPv6 experiments has been submitted. A URL for this = Internet-Draft is: http://tools.ietf.org/html/draft-deng-aplusp-experi= ment-results-00.

 

A website introducing = the detail of experiment results is also accessible via: http://opensourceaplusp.weebly.com/

 

BR,

Xiaohong

_______________________________________________
Int-= area mailing list
Int-area@ietf.org
https://www.ie= tf.org/mailman/listinfo/int-area

 

= --Boundary_(ID_NwMrDIIND9zyqU+O7ZjhrQ)-- From xiaohong.deng@orange-ftgroup.com Fri Apr 8 03:26:56 2011 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 EC2A73A69C0 for ; Fri, 8 Apr 2011 03:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.164 X-Spam-Level: X-Spam-Status: No, score=-0.164 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLtAWgSE8F8K for ; Fri, 8 Apr 2011 03:26:55 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id F1A723A69B8 for ; Fri, 8 Apr 2011 03:26:54 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0E485738004; Fri, 8 Apr 2011 12:29:13 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id F050F6C0006; Fri, 8 Apr 2011 12:29:12 +0200 (CEST) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Apr 2011 12:28:38 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBF5D7.B7805089" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 8 Apr 2011 18:28:34 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC016855FE@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Softwires] FW:[Int-area] Stateless IPv4-in-IPv6 experiments && DS-Lite/NAT64 experiments Thread-Index: AQHL9S2gaZmTYn9G10S+T0Bdmfg6FZRTwfXg References: <0962B0BEF842A24191AD9BE41A8DD2FC0168525A@ch-mailsrv.rd.francetelecom.fr> From: To: , X-OriginalArrivalTime: 08 Apr 2011 10:28:38.0248 (UTC) FILETIME=[B91A6680:01CBF5D7] Subject: Re: [Softwires] FW:[Int-area] Stateless IPv4-in-IPv6 experiments && DS-Lite/NAT64 experiments 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, 08 Apr 2011 10:26:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBF5D7.B7805089 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Hello Yiu, =20 Yes, some apps break by NAT64. We're going to document it. =20 BR, Xiaohong =20 opensource A+P: http://opensourceaplusp.weebly.com/ =20 ________________________________ =B7=A2=BC=FE=C8=CB: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C27=C8=D5 22:11 =CA=D5=BC=FE=C8=CB: DENG Xiaohong ESP/PEK; softwires@ietf.org =D6=F7=CC=E2: Re: [Softwires] FW:[Int-area] Stateless IPv4-in-IPv6 = experiments && DS-Lite/NAT64 experiments =09 =09 Hi Xiaohong, I am personally very interested in the data. Do you also document what = may break the applications? Thanks, Yiu =09 From: Date: Thu, 7 Apr 2011 13:31:42 +0800 To: Subject: [Softwires] FW:[Int-area] Stateless IPv4-in-IPv6 experiments = && DS-Lite/NAT64 experiments =09 We have tested how applications behave when it has both DS-Lite IPv4 = and NAT64 IPv6 (but not native IPv6). Firefox, IE, Skype, Google Earth = v5.2.1, Live Messenger, uTorrent, BitComet, were on our test list.=20 =09 =09 Despres,regarding your question ( maybe not answering your question = exactly as we tested NAT64 IPv6 instead of native IPv6 ), uTorrent v2.2 = used IPv6 for login/authentication but IPv4 for the data exchange, for = IPv6 peer was not able to talk to IPv4 peer. Although BitComet v1.23 = issued both A and AAAA quires, it completely ignored AAAA RR and only = used IPv4 for communication. =09 Please also see some of other test results below. DS-Lite/NAT64 = experiments could be documented if it is of interests.=20 =09 Tested Apps IPv4/IPv6 portion Firefox (Non-vedio) v3.6.12 All IPv6 =20 video website Half/ half =20 IE (Non-vedio) v6.0 All IPv6 =20 Skype v5.0 Major IPv6 =20 Google Earth v5.2.1 Major IPv6 =20 Live Messenger 2009 Major IPv4 =20 uTorrent v2.2 Major IPv4 =20 BitComet v1.23 All IPv4 =20 =20 BR, Xiaohong opensource A+P: http://opensourceaplusp.weebly.com/ =20 ________________________________ =B7=A2=BC=FE=C8=CB: R=A8=A6mi Despr=A8=A6s = [mailto:remi.despres@free.fr]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C27=C8=D5 0:21 =CA=D5=BC=FE=C8=CB: DENG Xiaohong ESP/PEK =B3=AD=CB=CD: int-area@ietf.org =D6=F7=CC=E2: Re: [Int-area] Stateless IPv4-in-IPv6 experiments =09 =09 Thank you, Xiahong, for sharing this interesting information.=20 In the case of BitComet and uTorrent, I wonder what happens if the = host has both A+P IPv4 and IPv6, as opposed to just A+P IPv4. Did you try that? Regards, RD Le 6 avr. 2011 =A8=A4 10:57, = a =A8=A6crit : Dear all, =20 An I-D about stateless IPv4-in-IPv6 experiments has been submitted. A = URL for this Internet-Draft is: = http://tools.ietf.org/html/draft-deng-aplusp-experiment-results-00 = . =20 A website introducing the detail of experiment results is also = accessible via: http://opensourceaplusp.weebly.com/ = =20 =20 BR, Xiaohong _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area =09 _______________________________________________ Softwires mailing list = Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires=20 ------_=_NextPart_001_01CBF5D7.B7805089 Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable
Hello=20 Yiu,
 
Yes, some=20 apps break by NAT64. We're going to document it.
 
BR,
Xiaohong
 
opensource = A+P: http://opensourceaplusp.weeb= ly.com/
 

=B7=A2=BC=FE=C8=CB: Lee, Yiu = [mailto:Yiu_Lee@Cable.Comcast.com]=20
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C27=C8=D5 = 22:11
=CA=D5=BC=FE=C8=CB: DENG Xiaohong ESP/PEK;=20 softwires@ietf.org
=D6=F7=CC=E2: Re: [Softwires] = FW:[Int-area] Stateless=20 IPv4-in-IPv6 experiments && DS-Lite/NAT64=20 experiments

Hi Xiaohong,

I am personally very interested in the data. Do you also document = what=20 may break the applications?

Thanks,
Yiu

From: <xiaohong.deng@orange-ftg= roup.com>
Date: Thu, 7 Apr 2011 13:31:42 = +0800
To: <softwires@ietf.org>
Subject: [Softwires] FW:[Int-area] = Stateless=20 IPv4-in-IPv6 experiments && DS-Lite/NAT64 = experiments

We=20 have=20 tested=20 how applications behave when it has both DS-Lite=20 IPv4=20 and NAT64 IPv6 (but not native IPv6).=20 Firefox,=20 IE, Skype, Google Earth v5.2.1, Live Messenger, uTorrent,=20 BitComet,=20 were on our test list. 

Despres,regarding your=20 question ( maybe not answering your question = exactly as=20 we tested NAT64 IPv6 instead of native IPv6 ), = uTorrent v2.2=20 used IPv6 for login/authentication but IPv4 for the data exchange, for = IPv6=20 peer was not able to talk to IPv4 peer. Although BitComet v1.23 issued = both A=20 and AAAA quires, it completely ignored AAAA RR and only used IPv4 for=20 communication.

Please also see some of other test results below. DS-Lite/NAT64 experiments could be = documented if it=20 is of interests.

Tested Apps                   IPv4/IPv6=20 portion

Firefox (Non-vedio) v3.6.12   All IPv6           &nbs= p;            = ;    =20

video website           &nbs= p;    =20 Half/ half          =20  

IE (Non-vedio) v6.0  =20      =    All IPv6           &nbs= p;            = ;   =20

Skype v5.0           =20         = Major IPv6          =20             &nbs= p; =20

Google Earth v5.2.1          =20 Major IPv6           &n= bsp; =20      =20

Live Messenger 2009          =20 Major IPv4           =20

uTorrent v2.2           &nbs= p;    =20 Major IPv4    =20

BitComet v1.23           &nbs= p;   =20 All IPv4      =20

 

BR,

Xiaohong

opensource A+P: http://opensourceaplusp.weeb= ly.com/

 

=B7=A2=BC=FE=C8=CB: = R=A8=A6mi Despr=A8=A6s [mailto:remi.despres@free.fr]=20
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C27=C8=D5 = 0:21
=CA=D5=BC=FE=C8=CB: DENG Xiaohong=20 ESP/PEK
=B3=AD=CB=CD: int-area@ietf.org
=D6=F7=CC=E2= : Re:=20 [Int-area] Stateless IPv4-in-IPv6 experiments

Thank you, Xiahong, for sharing this interesting = information.=20

In the case of BitComet and uTorrent, I wonder what happens if = the host=20 has both A+P IPv4 and IPv6, as opposed to just A+P IPv4.
Did you try that?

Regards,
RD

Le 6 avr. 2011 =A8=A4 10:57, <xiaohong.deng@orange-ftg= roup.com>=20 <xiaohong.deng@orange-ftg= roup.com>=20 a =A8=A6crit :

Dear=20 all,
 
An I-D about stateless = IPv4-in-IPv6 experiments has been submitted.=20 A = URL for this=20 Internet-Draft is: http://tools.ietf.org/html/draft-deng-aplusp-experiment-r= esults-00.
 
A website=20 introducing the detail of experiment results is also = accessible via:=20 http://opensourceaplusp.weebly.com/
 
BR,
Xiaohong
______________________________= _________________
Int-area=20 mailing list
Int-area@ietf.org
https://www.ietf.= org/mailman/listinfo/int-area

_______________________________________________=20 Softwires mailing list Softwires@ietf.org https://www.ietf= .org/mailman/listinfo/softwires=20
------_=_NextPart_001_01CBF5D7.B7805089-- From tena@huawei.com Fri Apr 8 13:28:30 2011 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 8664E3A6957; Fri, 8 Apr 2011 13:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.276 X-Spam-Level: X-Spam-Status: No, score=-106.276 tagged_above=-999 required=5 tests=[AWL=0.323, 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 ft3TJl24cW9k; Fri, 8 Apr 2011 13:28:22 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 5B0CC3A68CB; Fri, 8 Apr 2011 13:28:22 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJC00CCNOY7YV@usaga02-in.huawei.com>; Fri, 08 Apr 2011 13:30:07 -0700 (PDT) Received: from TingZousc1 ([10.212.246.132]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJC005F4OY58P@usaga02-in.huawei.com>; Fri, 08 Apr 2011 13:30:07 -0700 (PDT) Date: Fri, 08 Apr 2011 13:30:05 -0700 From: Tina Tsou To: 'MBONED WG' , pim@ietf.org, 'IPv6 Ops WG' , behave@ietf.org, softwires@ietf.org Message-id: <010001cbf62b$bfc24e40$3f46eac0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AQEvzYA9JGDJgObGWqAS/HlE5dNRbJWMr2vQgAAKSVA= Cc: multrans@ietf.org Subject: [Softwires] You are invited to subscribe to the multrans list 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, 08 Apr 2011 20:28:30 -0000 Hi all, You are invited to subscribe to the multrans list. https://www.ietf.org/mailman/listinfo/multrans You are invited to comment on https://datatracker.ietf.org/doc/draft-jaclee-behave-v4v6-mcast-ps/ to the multrans list. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: Steve Young [mailto:stevey@amsl.com] Sent: Friday, April 08, 2011 12:43 PM To: tena@huawei.com; tina.tsou.zouting@huawei.com Subject: Your new mailing list: multrans The mailing list `multrans' has just been created for you. The following is some basic information about your mailing list. Your mailing list password is: ... You need this password to configure your mailing list. You also need it to handle administrative requests, such as approving mail if you choose to run a moderated list. You can configure your mailing list at the following web page: https://www.ietf.org/mailman/admin/multrans The web page for users of your mailing list is: https://www.ietf.org/mailman/listinfo/multrans You can even customize these web pages from the list configuration page. However, you do need to know HTML to be able to do this. There is also an email-based interface for users (not administrators) of your list; you can get info about using it by sending a message with just the word `help' as subject or in the body, to: multrans-request@ietf.org To unsubscribe a user: from the mailing list 'listinfo' web page, click on or enter the user's email address as if you were that user. Where that user would put in their password to unsubscribe, put in your admin password. You can also use your password to change member's options, including digestification, delivery disabling, etc. Your mailing list is configured with a public archive which can be found at: http://www.ietf.org/mail-archive/web/multrans Please note: the archive will not be created until a message has been sent to the list and the archiving process has run (runs at 10, 30, 50 past each hour). Please address all questions to mailman-owner@ietf.org. From fbrockne@cisco.com Mon Apr 11 02:21:40 2011 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 1C4533A69E9 for ; Mon, 11 Apr 2011 02:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, 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 pB7DB+zUZ3XT for ; Mon, 11 Apr 2011 02:21:38 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3FFBE3A69E3 for ; Mon, 11 Apr 2011 02:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fbrockne@cisco.com; l=5466; q=dns/txt; s=iport; t=1302513698; x=1303723298; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=WCiyhEn/VJrabdPioQh1Flzf4wrmHy7Yfz0A25/xgTM=; b=mUvjuZrZp4yqakmGVu+7IVxhDtjiqhRn4SDRVoOql6SQjxoRiL5z7HBw 9Uu934F1N8jxX6o86MhZpWm1KNQqhAInNROUOxMxGYPdHWie17MvQdSTL CabgQq0XaRxPLyPYLHqGJVwdzzIbrIYrKa4y+PC8Jndj2PdgW/UrconI2 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAANfHok2Q/khNgWdsb2JhbACYQY1YFAEBFiYlpgibM4J+gnAEkUk X-IronPort-AV: E=Sophos;i="4.63,338,1299456000"; d="scan'208";a="83033376" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 11 Apr 2011 09:21:37 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3B9Lbgr007008; Mon, 11 Apr 2011 09:21:37 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Apr 2011 11:21:37 +0200 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: Mon, 11 Apr 2011 11:21:34 +0200 Message-ID: <0D212BD466921646B58854FB79092CEC052F2460@XMB-AMS-106.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: draft-ietf-softwire-gateway-init-ds-lite-03 thread-index: Acv2sGurHpn4i3wAQWadoZkbsJ8U1gBdmsyA References: From: "Frank Brockners (fbrockne)" To: "Paco Cortes" , X-OriginalArrivalTime: 11 Apr 2011 09:21:37.0455 (UTC) FILETIME=[DBC353F0:01CBF829] Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-lite-03 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, 11 Apr 2011 09:21:40 -0000 Hi Paco, thanks - and I agree with you that the description of the MPLS VPN variant is currently ambiguous and needs refinement. I agree with your suggested changes. One additional thought: Given that the SWID for MPLS VPNs can really be "something" which uniquely identifies the VPN, how about making the SWID at both ends of the softwire a=20 completely generic identifier, with the one quality of uniquely=20 identifying the VPN? We'd give the two embodiments you mention as examples, but wouldn't restrict things to just the two. For MPLS VPNs the SWID isn't really something which requires specification, hence we can leave it to the implementers to pick something=20 appropriate. Here's a proposal for a slightly modified SECOND CHANGE: o MPLS VPN: The SWID is a generic identifier which uniquely identifies the VPN at either the Gateway or AFTR. Depending on whether the Gateway=20 or AFTR are acting as CE or PE, the SWID could e.g. be an attachment=20 circuit identifier, an identifier representing the set of VPN route=20 labels pointing to the routes within the VPN, etc. The AD's=20 IPv4-address is the CID. For a given VPN, the AD's IPv4 address must=20 be unique. Thanks, Frank > -----Original Message----- > From: Paco Cortes [mailto:pacosaddress@googlemail.com] > Sent: Saturday, April 09, 2011 2:20 PM > To: softwires@ietf.org; Frank Brockners (fbrockne) > Subject: draft-ietf-softwire-gateway-init-ds-lite-03 >=20 > Hi all, >=20 > When reading the description of the MPLS VPN variant of GI-DS-lite, my > interpretation has always been that the gateway and the AFTR are > connected to the MPLS VPN [RFC4364] as CE devices. > In an off-line discussion with Frank, we realized that we had > different interpretations and that his intention had been to describe > both nodes as PE devices. > We then realized that the I-D is ambiguous, allowing both > interpretations, and we also agreed on that both of them are actually > sound possible implementations, as well as the combination of them > (i.e. the gateways acting as CE and the AFTR as PE, or the other way > around). >=20 > With this email I'd like to propose some small updates to the draft in > order to explicitly mention these possibilities, as well as to correct > other minor statements which I found confusing or misleading while > trying to read more deeply the MPLS VPN embodiement description. >=20 > VPN-ID is mentioned as SWID for the MPLS VPN case, without specifying > what the VPN-ID might be. It could be interpreted as the identifier of > an attachment circuit (if the Gateway or AFTR are CEs), a VRF-wide > MPLS label if an implementation uses it, or some other internal VRF > identifier, for instance an associated route distinguisher, if an > implementations uses route specific MPLS VPN route labels. > The term "MPLS VPN label" is used once, which is ambiguous/confusing. > A generic use of RFC 4364 would imply that this is a set of MPLS VPN > route labels which match routes within one VPN. Only an implementation > choosing a single MPLS label for an entire VRF (one of the > alternatives in RFC 4364 section 4.3.2) could correctly used the > singular form. But I doubt that it is the intention of this I-D to > mandate a specific implementation of RFC 4364. > I also think that if the gateway and the AFTR are acting as PEs, the > fact that the MPLS labels used by them are not the same deserves > explicit mention. I.e., that "the SWID does not need to be globally > unique, i.e. different SWIDs could be used to identify a softwire at > the different ends of a tunnel". (quoting Frank) >=20 > So, here are my proposed changes to draft-ietf-softwire-gateway-init- > ds-lite-03: >=20 > FIRST CHANGE > In section 3 of the I-D I would extend the sentence: > "The softwire is identified by a softwire identifier (SWID)" > to say > "The softwire is identified by a softwire identifier (SWID), which > does not need to be globally unique, i.e. different SWIDs could be > used to identify a softwire at the different ends of a softwire" >=20 > SECOND CHANGE > In section 6 of the I-D, I would modify the bullet: > " o MPLS VPN: SWID is the MPLS VPN label. The AD's IPv4-address is > the CID. For a given MPLS VPN label, the AD's IPv4 address must > be unique." > to say > "o MPLS VPN: depending on the gateway or the AFTR being connected as > CE or PE devices, the SWID is respectively an attachment circuit > identifier or a representation of the VPN route labels pointing to > routes within the VPN. The AD's IPv4-address is the CID. For a given > VPN, the AD's IPv4 address must be unique" >=20 > THIRD CHANGE > RFC 4364 should be added as reference. >=20 > END OF PROPOSED CHANGES >=20 > I didn't see the need for other changes. > On the one hand, the draft could benefit from more details on the > different cases (combinations of CEs and PEs) and advantages or > disadvantages. On the other hand, the draft does not go into any of > the implementations (GRE, IPv4 in IPv4, ...) in details, so that > adding more on the MPLS VPN variant could create an unbalance. >=20 > I'm also aware that it can be discussed if it is correct to say that a > gateway or AFTR acts as PE device, or if we should say that they act > as combined CE+PE devices. But I personally prefer the first wording > ;-). >=20 > Any opinions? >=20 > br, > Paco From Dmitry.Anipko@microsoft.com Mon Apr 11 17:12:23 2011 Return-Path: X-Original-To: softwires@ietfc.amsl.com Delivered-To: softwires@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B0188E06B0 for ; Mon, 11 Apr 2011 17:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGczh9eyArQj for ; Mon, 11 Apr 2011 17:12:21 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfc.amsl.com (Postfix) with ESMTP id 6CFF3E0715 for ; Mon, 11 Apr 2011 17:12:14 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 11 Apr 2011 17:12:10 -0700 Received: from tk5-exmlt-s701.segroup.winse.corp.microsoft.com (157.54.90.63) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.289.8; Mon, 11 Apr 2011 17:12:10 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s701.segroup.winse.corp.microsoft.com ([157.54.90.63]) with mapi; Mon, 11 Apr 2011 17:11:32 -0700 From: Dmitry Anipko To: "softwires@ietf.org" Date: Mon, 11 Apr 2011 17:11:29 -0700 Thread-Topic: sharing restricted addresses by hosts in 4rd (draft-despres-intarea-4rd-01) Thread-Index: Acv4pivaqL1V4ONzSNS37OqdjJGGfw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Softwires] sharing restricted addresses by hosts in 4rd (draft-despres-intarea-4rd-01) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 00:12:24 -0000 Hi, Since re-chartering to include 4rd has not been approved yet (as far as I k= now), I'm not sure if softwires is the right forum for this question, pleas= e let me know if intarea is a better one for the time being. Draft-despres-intarea-4rd-01 allows for configuration of end hosts (since i= t defines CE as "a host, a router or both") with shared addresses with rest= ricted port sets. My understanding is that usage by applications of such ad= dresses, assigned to interfaces, may have issues - for example, those are d= iscussed in http://tools.ietf.org/html/draft-dec-stateless-4v6-00 .=20 Should the draft include a recommendation to either avoid assigning such ad= dresses to interfaces, and use it only in the NAT function, even when CE is= a host, or, as draft-dec-stateless-4v6-00 suggests in section 3.1.2, modif= y the 4rd DHCP option to provide for CE ability to specify whether it is ca= pable to function with a shared address? (since 4rd can also distribute not= shared addresses / address ranges) Thank you, Dmitry From mark@townsley.net Tue Apr 12 13:04:04 2011 Return-Path: X-Original-To: softwires@ietfc.amsl.com Delivered-To: softwires@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 85DCBE08F5 for ; Tue, 12 Apr 2011 13:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBSiCgUNtp9S for ; Tue, 12 Apr 2011 13:04:03 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 9FD7AE0870 for ; Tue, 12 Apr 2011 13:04:03 -0700 (PDT) Received: by wyb29 with SMTP id 29so6641551wyb.31 for ; Tue, 12 Apr 2011 13:04:03 -0700 (PDT) Received: by 10.227.139.164 with SMTP id e36mr1851693wbu.94.1302638642874; Tue, 12 Apr 2011 13:04:02 -0700 (PDT) Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id y12sm4246696wby.59.2011.04.12.13.04.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Apr 2011 13:04:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Tue, 12 Apr 2011 22:03:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5C4F8A4C-A7AE-4E6E-960B-650DED19982F@townsley.net> References: To: Dmitry Anipko X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org" Subject: Re: [Softwires] sharing restricted addresses by hosts in 4rd (draft-despres-intarea-4rd-01) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 20:04:04 -0000 Hello Dmitry, My view is that 4rd is most easily understood if and only if it connects = to a CE function that is performing NAPT. The CE function may be in what = is traditionally considered a host, or in what is clearly a router. More specifically, a device that is forwarding packets from one = interface (virtual or otherwise) to another through a NAPT that has one = interface with IPv6 configured (via DHCPv6 or otherwise) as performing = 4rd (which enables dual-stack via a port-restricted IPv4 address for the = NAPT using IPv6 as the transport) then you a have a 4rd CE. That could = be a "host" in that it is a Windows PC with internet connection sharing = for IPv4 turned on and hence forwards packets between interfaces with a = NAPT due to the IPv4-enabled interface created when 4rd is configured.=20= I would avoid anything that requires the host forwarding table to be = altered to accommodate 4rd. Instead, the NAPT function that is already = present in a small router or host configured to look like a router is = modified to use a set of ports that it is allowed to use when 4rd is = enabled.=20 - Mark On Apr 12, 2011, at 2:11 AM, Dmitry Anipko wrote: > Hi, >=20 > Since re-chartering to include 4rd has not been approved yet (as far = as I know), I'm not sure if softwires is the right forum for this = question, please let me know if intarea is a better one for the time = being. >=20 > Draft-despres-intarea-4rd-01 allows for configuration of end hosts = (since it defines CE as "a host, a router or both") with shared = addresses with restricted port sets. My understanding is that usage by = applications of such addresses, assigned to interfaces, may have issues = - for example, those are discussed in = http://tools.ietf.org/html/draft-dec-stateless-4v6-00 .=20 >=20 > Should the draft include a recommendation to either avoid assigning = such addresses to interfaces, and use it only in the NAT function, even = when CE is a host, or, as draft-dec-stateless-4v6-00 suggests in section = 3.1.2, modify the 4rd DHCP option to provide for CE ability to specify = whether it is capable to function with a shared address? (since 4rd can = also distribute not shared addresses / address ranges) >=20 > Thank you, > Dmitry >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From Dmitry.Anipko@microsoft.com Wed Apr 13 14:23:38 2011 Return-Path: X-Original-To: softwires@ietfc.amsl.com Delivered-To: softwires@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2FADBE083D for ; Wed, 13 Apr 2011 14:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vPUGp66L95Q for ; Wed, 13 Apr 2011 14:23:37 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfc.amsl.com (Postfix) with ESMTP id DCCB1E0742 for ; Wed, 13 Apr 2011 14:23:36 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 13 Apr 2011 14:23:35 -0700 Received: from tk5-exmlt-s702.segroup.winse.corp.microsoft.com (157.54.90.70) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.289.8; Wed, 13 Apr 2011 14:23:35 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s702.segroup.winse.corp.microsoft.com ([157.54.90.70]) with mapi; Wed, 13 Apr 2011 14:23:33 -0700 From: Dmitry Anipko To: Mark Townsley Date: Wed, 13 Apr 2011 14:23:30 -0700 Thread-Topic: [Softwires] sharing restricted addresses by hosts in 4rd (draft-despres-intarea-4rd-01) Thread-Index: Acv5TMaCdWSJdP6dQiSBHNMXJ0QTDgA0Bkcw Message-ID: References: <5C4F8A4C-A7AE-4E6E-960B-650DED19982F@townsley.net> In-Reply-To: <5C4F8A4C-A7AE-4E6E-960B-650DED19982F@townsley.net> 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] sharing restricted addresses by hosts in 4rd (draft-despres-intarea-4rd-01) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 21:23:38 -0000 Hello Mark, I agree that if the 4rd IPv4 address is only used in such a way, that appli= cations cannot start use the address directly (such as e.g. perform binding= to the address assigned to an interface), then this issue doesn't apply. However I'm not sure that the current draft makes clear that this is the on= ly intended use. For example, it defines CE as "a node.. it may be a host..= ", instead of saying that CE is a function implemented in a host. Also, the= introduction in section 1 also does not include NAPT as a required element= of the solution (it says "The 4rd mechanism tunnels IPv4 over IPv6 using a= n algorithmic mapping..").=20 Some existing implementations may be assigning the address used for NAPT to= an interface (and as long as the address is for the host exclusive use, an= implementation is able ensure such usage doesn't cause problems) - that's = what Windows ICS you mentioned actually does. With the current language, I don't think it is unlikely that implementers w= ill be tempted to assign a 4rd IPv4 address to an interface (e.g. with inte= nt to enable wider set of apps to work without a NAPT in the middle), and i= f the spirit of the draft is that the IPv4 address assigned to the node by = 4rd should be only be used for CE function, performing NAPT, (or more speci= fically, should not be made available for applications to bind) then I thin= k it may be useful to state it as such to guide implementers. Thank you, Dmitry -----Original Message----- From: Mark Townsley [mailto:mark@townsley.net]=20 Sent: Tuesday, April 12, 2011 1:04 PM To: Dmitry Anipko Cc: softwires@ietf.org Subject: Re: [Softwires] sharing restricted addresses by hosts in 4rd (draf= t-despres-intarea-4rd-01) Hello Dmitry, My view is that 4rd is most easily understood if and only if it connects to= a CE function that is performing NAPT. The CE function may be in what is t= raditionally considered a host, or in what is clearly a router. More specifically, a device that is forwarding packets from one interface (= virtual or otherwise) to another through a NAPT that has one interface with= IPv6 configured (via DHCPv6 or otherwise) as performing 4rd (which enables= dual-stack via a port-restricted IPv4 address for the NAPT using IPv6 as t= he transport) then you a have a 4rd CE. That could be a "host" in that it i= s a Windows PC with internet connection sharing for IPv4 turned on and henc= e forwards packets between interfaces with a NAPT due to the IPv4-enabled i= nterface created when 4rd is configured.=20 I would avoid anything that requires the host forwarding table to be altere= d to accommodate 4rd. Instead, the NAPT function that is already present in= a small router or host configured to look like a router is modified to use= a set of ports that it is allowed to use when 4rd is enabled.=20 - Mark From mark@townsley.net Wed Apr 13 17:06:20 2011 Return-Path: X-Original-To: softwires@ietfc.amsl.com Delivered-To: softwires@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DB45FE06FC for ; Wed, 13 Apr 2011 17:06:20 -0700 (PDT) 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=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5GbNv5l71OJ for ; Wed, 13 Apr 2011 17:06:20 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id E03C9E0679 for ; Wed, 13 Apr 2011 17:06:19 -0700 (PDT) Received: by wyb29 with SMTP id 29so1050280wyb.31 for ; Wed, 13 Apr 2011 17:06:19 -0700 (PDT) Received: by 10.216.121.130 with SMTP id r2mr65729weh.96.1302739578950; Wed, 13 Apr 2011 17:06:18 -0700 (PDT) Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id k76sm524102wej.19.2011.04.13.17.06.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Apr 2011 17:06:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Thu, 14 Apr 2011 02:06:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8C7D369C-CBE6-4485-B148-DA8020734104@townsley.net> References: <5C4F8A4C-A7AE-4E6E-960B-650DED19982F@townsley.net> To: Dmitry Anipko X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org" Subject: Re: [Softwires] sharing restricted addresses by hosts in 4rd (draft-despres-intarea-4rd-01) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 00:06:21 -0000 On Apr 13, 2011, at 11:23 PM, Dmitry Anipko wrote: > Hello Mark, >=20 > I agree that if the 4rd IPv4 address is only used in such a way, that = applications cannot start use the address directly (such as e.g. perform = binding to the address assigned to an interface), then this issue = doesn't apply. >=20 > However I'm not sure that the current draft makes clear that this is = the only intended use. For example, it defines CE as "a node.. it may be = a host..", instead of saying that CE is a function implemented in a = host. Also, the introduction in section 1 also does not include NAPT as = a required element of the solution (it says "The 4rd mechanism tunnels = IPv4 over IPv6 using an algorithmic mapping..").=20 >=20 > Some existing implementations may be assigning the address used for = NAPT to an interface (and as long as the address is for the host = exclusive use, an implementation is able ensure such usage doesn't cause = problems) - that's what Windows ICS you mentioned actually does. >=20 > With the current language, I don't think it is unlikely that = implementers will be tempted to assign a 4rd IPv4 address to an = interface (e.g. with intent to enable wider set of apps to work without = a NAPT in the middle), and if the spirit of the draft is that the IPv4 = address assigned to the node by 4rd should be only be used for CE = function, performing NAPT, (or more specifically, should not be made = available for applications to bind) then I think it may be useful to = state it as such to guide implementers. Then at least you and I agree. If 4rd becomes a WG item, this is the = kind of change we should be able to affect in the draft with WG = consensus.=20 - Mark >=20 > Thank you, > Dmitry >=20 > -----Original Message----- > From: Mark Townsley [mailto:mark@townsley.net]=20 > Sent: Tuesday, April 12, 2011 1:04 PM > To: Dmitry Anipko > Cc: softwires@ietf.org > Subject: Re: [Softwires] sharing restricted addresses by hosts in 4rd = (draft-despres-intarea-4rd-01) >=20 >=20 > Hello Dmitry, >=20 > My view is that 4rd is most easily understood if and only if it = connects to a CE function that is performing NAPT. The CE function may = be in what is traditionally considered a host, or in what is clearly a = router. >=20 > More specifically, a device that is forwarding packets from one = interface (virtual or otherwise) to another through a NAPT that has one = interface with IPv6 configured (via DHCPv6 or otherwise) as performing = 4rd (which enables dual-stack via a port-restricted IPv4 address for the = NAPT using IPv6 as the transport) then you a have a 4rd CE. That could = be a "host" in that it is a Windows PC with internet connection sharing = for IPv4 turned on and hence forwards packets between interfaces with a = NAPT due to the IPv4-enabled interface created when 4rd is configured.=20= >=20 > I would avoid anything that requires the host forwarding table to be = altered to accommodate 4rd. Instead, the NAPT function that is already = present in a small router or host configured to look like a router is = modified to use a set of ports that it is allowed to use when 4rd is = enabled.=20 >=20 > - Mark >=20 From roberta.maglione@telecomitalia.it Thu Apr 14 00:45:28 2011 Return-Path: X-Original-To: softwires@ietfc.amsl.com Delivered-To: softwires@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0107DE07E7 for ; Thu, 14 Apr 2011 00:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.613 X-Spam-Level: ** X-Spam-Status: No, score=2.613 tagged_above=-999 required=5 tests=[AWL=-3.331, BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytfE1tsCD3ks for ; Thu, 14 Apr 2011 00:45:27 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfc.amsl.com (Postfix) with ESMTP id B86C2E06D1 for ; Thu, 14 Apr 2011 00:45:26 -0700 (PDT) Content-Type: multipart/mixed; boundary="_e90197c9-ae4c-4fa1-a8f0-a3626a096da1_" Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 14 Apr 2011 09:45:24 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Thu, 14 Apr 2011 09:45:24 +0200 From: Maglione Roberta To: '??' , "'softwires@ietf.org'" , 'Fred Baker' , 'xiechf' Date: Thu, 14 Apr 2011 09:45:18 +0200 Thread-Topic: [softwire] slides update for problem statement Thread-Index: Acv5i4HPvAgh+qorTYiN9XYIdpCgNwA7BsMg Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB2B8D6B5@GRFMBX704BA020.griffon.local> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Ullio Mario Subject: Re: [Softwires] [softwire] slides update for problem statement X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 07:45:28 -0000 --_e90197c9-ae4c-4fa1-a8f0-a3626a096da1_ Content-Type: multipart/alternative; boundary="_000_282BBE8A501E1F4DA9C775F964BB21FE3EB2B8D6B5GRFMBX704BA02_" --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB2B8D6B5GRFMBX704BA02_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB1cGRhdGluZyB0aGUgc2xpZGVzIGJhc2VkIG9uIHRoZSBkaXNjdXNzaW9uIHdl IGhhZCBvbiB0aGUgbWFpbGluZyBsaXN0Lg0KDQpCZXN0IHJlZ2FyZHMsDQpSb2JlcnRhDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiDL78ftIFttYWlsdG86YmluZ3h1 ZXJlQGdtYWlsLmNvbV0NClNlbnQ6IG1lcmNvbGVkqKwgMTMgYXByaWxlIDIwMTEgNS4zMw0KVG86 IHNvZnR3aXJlc0BpZXRmLm9yZzsgTWFnbGlvbmUgUm9iZXJ0YTsgRnJlZCBCYWtlcjsgeGllY2hm DQpTdWJqZWN0OiBbc29mdHdpcmVdIHNsaWRlcyB1cGRhdGUgZm9yIHByb2JsZW0gc3RhdGVtZW50 DQoNCkhpIGFsbCwNCg0KVGhpcyBpcyB0aGUgc2xpZGVzIHByZXNlbnRlZCBpbiB2Nm9wcyBkdXJp bmcgSUVURiA4MHRoLiBJIGhhdmUgdXBkYXRlZCB0aGUgc2xpZGVzIGFjY29yZGluZyB0byB0aGUg c3VnZ2VzdGlvbnMgYnkgUm9iZXJ0YSBhbmQgRnJlZC4gSXQgZGlzY3Vzc2VzIG91ciBjb25zaWRl cmF0aW9ucyBmcm9tIG9wZXJhdGlvbmFsIHZpZXdwb2ludCBhbmQgdGFrZSBhIGNvbXBhcmlzaW9u IGZvciBleGlzdGluZyBzb2x1dGlvbnMuIFdlIGhvcGUgaXQgd291bGQgYmUgaGVscGZ1bCB0byBz b21lIGV4dGVuZC4NCg0KQ29tbWVudHMgYXJlIHdlbGNvbWUuDQoNClRoYW5rcy4NCg0KUWlvbmcg U1VODQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkg ZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3Bp YSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkg cXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBh YmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNl bWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50 ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBl LW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWlu IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25s eS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxz ZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs IHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlz ZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4NCg0KW2NpZDowMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMUBUSS5EaXNjbGFpbWVyXVJpc3BldHRhIGwnYW1iaWVudGUu IE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gqKggbmVjZXNzYXJpby4NCg0K --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB2B8D6B5GRFMBX704BA02_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Thanks for updating the slides based o= n the discussion we had on the mailing list.

 

Best regards,=

Roberta

 

From: =CB=EF=C7=ED [mailto:bingxuere@gmail.com]
Sent: mercoled=A8=AC 13 apri= le 2011 5.33
To: softwires@ietf.org; Magl= ione Roberta; Fred Baker; xiechf
Subject: [softwire] slides u= pdate for problem statement

 

Hi all,

This is the slides presented in v6ops during IETF 80th. I have updated the = slides according to the suggestions by Roberta and F= red. It discusses our considerations from operational viewpoint and take a = comparision for existing solutions. We hope it would be helpful to some extend.

Comments are welcome.

Thanks.

Qiong SUN

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =A8=A8 necessario.

--_000_282BBE8A501E1F4DA9C775F964BB21FE3EB2B8D6B5GRFMBX704BA02_-- --_e90197c9-ae4c-4fa1-a8f0-a3626a096da1_ Content-Description: logo Ambiente_foglia.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000001@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_e90197c9-ae4c-4fa1-a8f0-a3626a096da1_-- From adurand@juniper.net Tue Apr 19 09:07:51 2011 Return-Path: X-Original-To: softwires@ietfc.amsl.com Delivered-To: softwires@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DC98FE07A0 for ; Tue, 19 Apr 2011 09:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.455 X-Spam-Level: X-Spam-Status: No, score=-106.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77c0wgVgXKrJ for ; Tue, 19 Apr 2011 09:07:51 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfc.amsl.com (Postfix) with ESMTP id 0C752E0799 for ; Tue, 19 Apr 2011 09:07:50 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTa2zVE3Pzn4DXA2LNszRF4Tt9Za6GA8V@postini.com; Tue, 19 Apr 2011 09:07:51 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 19 Apr 2011 09:04:00 -0700 From: Alain Durand To: Mark Townsley Date: Tue, 19 Apr 2011 09:06:04 -0700 Thread-Topic: [Softwires] sharing restricted addresses by hosts in 4rd (draft-despres-intarea-4rd-01) Thread-Index: Acv+q6+7trPbV/GGSzCqWjFL/bXilw== Message-ID: References: <5C4F8A4C-A7AE-4E6E-960B-650DED19982F@townsley.net> In-Reply-To: <5C4F8A4C-A7AE-4E6E-960B-650DED19982F@townsley.net> 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] sharing restricted addresses by hosts in 4rd (draft-despres-intarea-4rd-01) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 16:07:52 -0000 On Apr 12, 2011, at 4:03 PM, Mark Townsley wrote: >=20 > Hello Dmitry, >=20 > My view is that 4rd is most easily understood if and only if it connects = to a CE function that is performing NAPT. The CE function may be in what is= traditionally considered a host, or in what is clearly a router. >=20 > More specifically, a device that is forwarding packets from one interface= (virtual or otherwise) to another through a NAPT that has one interface wi= th IPv6 configured (via DHCPv6 or otherwise) as performing 4rd (which enabl= es dual-stack via a port-restricted IPv4 address for the NAPT using IPv6 as= the transport) then you a have a 4rd CE. That could be a "host" in that it= is a Windows PC with internet connection sharing for IPv4 turned on and he= nce forwards packets between interfaces with a NAPT due to the IPv4-enabled= interface created when 4rd is configured.=20 >=20 > I would avoid anything that requires the host forwarding table to be alte= red to accommodate 4rd. Instead, the NAPT function that is already present = in a small router or host configured to look like a router is modified to u= se a set of ports that it is allowed to use when 4rd is enabled.=20 Mark: How would an app running on a 4rd CPE communicate in IPv4 to another app ru= nning on another 4rd CPE? - Alain. From wwwrun@ietfc.amsl.com Tue Apr 19 09:36:54 2011 Return-Path: X-Original-To: softwires@ietf.org Delivered-To: softwires@ietfc.amsl.com Received: by ietfc.amsl.com (Postfix, from userid 30) id 09944E0764; Tue, 19 Apr 2011 09:36:54 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110419163654.09944E0764@ietfc.amsl.com> Date: Tue, 19 Apr 2011 09:36:54 -0700 (PDT) Cc: softwires@ietf.org, cuiyong@tsinghua.edu.cn Subject: [Softwires] WG Review: Recharter of Softwires (softwire) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: iesg@ietf.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 16:36:54 -0000 A modified charter has been submitted for the Softwires (softwire) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, April 26, 2011. Softwires (softwire) **DRAFT 2011-04-14** (v03) -------------------- Current Status: Active Chairs: Alain Durand Yong Cui Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: softwires@ietf.org To Subscribe: softwires-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/softwires/current/maillist.html Description of Working Group: The Softwires Working Group is specifying the standardization of discovery, control and encapsulation methods for connecting IPv4 networks across IPv6 networks and IPv6 networks across IPv4 networks in a way that will encourage multiple, inter-operable implementations. For various reasons, native IPv4 and/or IPv6 transport may not be available in all cases, and there is a need to tunnel IPv4 in IPv6 or IPv6 in IPv4 to cross a part of the network which is not IPv4 or IPv6 capable. The Softwire Problem Statement, RFC 4925, identifies two distinct topological scenarios that the WG will provide solutions for: "Hubs and Spokes" and "Mesh." In the former case, hosts or "stub" networks are attached via individual, point-to-point, IPv4 over IPv6 or IPv6 over IPv4 softwires to a centralized Softwire Concentrator. In the latter case (Mesh), network islands of one Address Family (IPv4 or IPv6) are connected over a network of another Address Family via point to multi-point softwires among Address family Border Routers (AFBRs). The WG will reuse existing technologies as much as possible and only when necessary, create additional protocol building blocks. For generality, all base Softwires encapsulation mechanisms should support all combinations of IP versions over one other (IPv4 over IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). IPv4 to IPv6 translation mechanisms (NAT-PT), new addressing schemes, and block address assignments are out of scope. DHCP options developed in this working group will be reviewed jointly with the DHC WG. RADIUS attributes developed in this working group will be reviewed jointly with the RADEXT WG. The MIB Doctors directorate will be asked to review any MIB modules developed in the SOFTWIRE working group. BGP and other routing and signaling protocols developed in this group will be reviewed jointly with the proper working groups and other workings that may take interest (e.g. IDR, L3VPN, PIM, LDP, SAAG, etc). The specific work areas for this working group are: 1. Developments for Mesh softwires topology; the Mesh topology work will be reviewed in the l3vpn and idr WGs - multicast - MIB module 2. Developments for 6rd: - multicast - operational specification - RADIUS option for 6rd server - MIB module 3. Developments for Dual-Stack Lite (DS-Lite): - multicast - operational specification - RADIUS option for AFTR - proxy extensions; GI-DS-Lite; DS-Lite with no NAT or NAT on the B4 element - MIB module 4. Developments for stateless legacy IPv4 carried over IPv6 - develop a solution motivation document to be published as an RFC - develop a protocol specification response to the solution motivation document; this work item will not be taken through WG last call until the solution motivation document has been published 5. Finalize discovery and configuration mechanisms for a gateway to use DS-Lite or 6rd; these discovery and configuration mechanisms must take into a account other operating environments such as dual-stack and tunneling mechanisms not defined by the softwire WG. Development of new mechanisms will involve the dhc and/or v6ops WGs as appropriate Other work items would require WG approval and rechartering. Goals and Milestones: Apr 2011 Submit DS-lite RADIUS option for Proposed Standard Apr 2011 Adopt DS-lite operational document as WG document Jul 2011 Submit 6rd RADIUS option for Proposed Standard Jul 2011 Submit GI DS-lite for Proposed Standard Jul 2011 Adopt B4NAT as WG document Aug 2011 Adopt 6rd operational document as WG document Aug 2011 Adopt Multicast extensions document as WG document Aug 2011 Submit DS-lite operational document for Informational Sep 2011 Submit B4NAT for Informational Nov 2011 Submit Multicast extensions document for Informational Nov 2011 Submit 6rd operational document for Informational Nov 2011 Adopt 6rd MIB module as WG document Nov 2011 Adopt DS-lite MIB module as WG document Nov 2011 Adopt Mesh topology MIB module as WG document Nov 2012 Submit 6rd MIB module for Proposed Standard Nov 2012 Submit DS-lite MIB module for Proposed Standard Nov 2012 Submit Mesh topology MIB module for Proposed Standard From tom111.taylor@bell.net Tue Apr 19 18:16:26 2011 Return-Path: X-Original-To: softwires@ietfc.amsl.com Delivered-To: softwires@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A753AE0817 for ; Tue, 19 Apr 2011 18:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.065 X-Spam-Level: X-Spam-Status: No, score=-101.065 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5T-tdGRjF5d for ; Tue, 19 Apr 2011 18:16:25 -0700 (PDT) Received: from blu0-omc4-s33.blu0.hotmail.com (blu0-omc4-s33.blu0.hotmail.com [65.55.111.172]) by ietfc.amsl.com (Postfix) with ESMTP id 928F3E0814 for ; Tue, 19 Apr 2011 18:16:25 -0700 (PDT) Received: from BLU0-SMTP45 ([65.55.111.135]) by blu0-omc4-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 18:16:25 -0700 X-Originating-IP: [64.231.151.226] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([64.231.151.226]) by BLU0-SMTP45.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 18:16:25 -0700 Date: Tue, 19 Apr 2011 21:16:23 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: softwires@ietf.org References: <20110419163654.09944E0764@ietfc.amsl.com> In-Reply-To: <20110419163654.09944E0764@ietfc.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Apr 2011 01:16:25.0618 (UTC) FILETIME=[91794720:01CBFEF8] Subject: Re: [Softwires] WG Review: Recharter of Softwires (softwire) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 01:16:27 -0000 Would Gateway-Initiated 6rd [draft-tsou-softwire-gwinit-6rd] fit within the charter or would it have to go the AD-sponsored route? On 19/04/2011 12:36 PM, IESG Secretary wrote: > A modified charter has been submitted for the Softwires (softwire) working > group in the Internet Area of the IETF. The IESG has not made any > determination as yet. The modified charter is provided below for > informational purposes only. Please send your comments to the IESG > mailing list (iesg@ietf.org) by Tuesday, April 26, 2011. > > > Softwires (softwire) > **DRAFT 2011-04-14** (v03) > -------------------- > Current Status: Active > > Chairs: > Alain Durand > Yong Cui > > Internet Area Directors: > Ralph Droms > Jari Arkko > > Internet Area Advisor: > Ralph Droms > > Mailing Lists: > General Discussion: softwires@ietf.org > To Subscribe: softwires-request@ietf.org > Archive: > http://www.ietf.org/mail-archive/web/softwires/current/maillist.html > > Description of Working Group: > > The Softwires Working Group is specifying the standardization of > discovery, control and encapsulation methods for connecting IPv4 > networks across IPv6 networks and IPv6 networks across IPv4 networks > in a way that will encourage multiple, inter-operable > implementations. > > For various reasons, native IPv4 and/or IPv6 transport may not be > available in all cases, and there is a need to tunnel IPv4 in IPv6 > or IPv6 in IPv4 to cross a part of the network which is not IPv4 or > IPv6 capable. The Softwire Problem Statement, RFC 4925, identifies > two distinct topological scenarios that the WG will provide > solutions for: "Hubs and Spokes" and "Mesh." In the former case, > hosts or "stub" networks are attached via individual, > point-to-point, IPv4 over IPv6 or IPv6 over IPv4 softwires to a > centralized Softwire Concentrator. In the latter case (Mesh), > network islands of one Address Family (IPv4 or IPv6) are connected > over a network of another Address Family via point to multi-point > softwires among Address family Border Routers (AFBRs). > > The WG will reuse existing technologies as much as possible and only > when necessary, create additional protocol building blocks. > > For generality, all base Softwires encapsulation mechanisms should > support all combinations of IP versions over one other (IPv4 over > IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). IPv4 to IPv6 > translation mechanisms (NAT-PT), new addressing schemes, and block > address assignments are out of scope. DHCP options developed in this > working group will be reviewed jointly with the DHC WG. RADIUS > attributes developed in this working group will be reviewed jointly > with the RADEXT WG. The MIB Doctors directorate will be asked to > review any MIB modules developed in the SOFTWIRE working group. BGP > and other routing and signaling protocols developed in this group > will be reviewed jointly with the proper working groups and other > workings that may take interest (e.g. IDR, L3VPN, PIM, LDP, SAAG, > etc). > > The specific work areas for this working group are: > > 1. Developments for Mesh softwires topology; the Mesh topology work > will be reviewed in the l3vpn and idr WGs > - multicast > - MIB module > > 2. Developments for 6rd: > - multicast > - operational specification > - RADIUS option for 6rd server > - MIB module > > 3. Developments for Dual-Stack Lite (DS-Lite): > - multicast > - operational specification > - RADIUS option for AFTR > - proxy extensions; GI-DS-Lite; DS-Lite with no NAT or NAT on the > B4 element > - MIB module > > 4. Developments for stateless legacy IPv4 carried over IPv6 > - develop a solution motivation document to be published as an > RFC > - develop a protocol specification response to the solution > motivation > document; this work item will not be taken through WG last call > until the solution motivation document has been published > > 5. Finalize discovery and configuration mechanisms for a gateway to > use DS-Lite or 6rd; these discovery and configuration mechanisms > must take into a account other operating environments such as > dual-stack and tunneling mechanisms not defined by the softwire > WG. Development of new mechanisms will involve the dhc and/or > v6ops WGs as appropriate > > Other work items would require WG approval and rechartering. > > Goals and Milestones: > Apr 2011 Submit DS-lite RADIUS option for Proposed Standard > Apr 2011 Adopt DS-lite operational document as WG document > Jul 2011 Submit 6rd RADIUS option for Proposed Standard > Jul 2011 Submit GI DS-lite for Proposed Standard > Jul 2011 Adopt B4NAT as WG document > Aug 2011 Adopt 6rd operational document as WG document > Aug 2011 Adopt Multicast extensions document as WG document > Aug 2011 Submit DS-lite operational document for Informational > Sep 2011 Submit B4NAT for Informational > Nov 2011 Submit Multicast extensions document for Informational > Nov 2011 Submit 6rd operational document for Informational > Nov 2011 Adopt 6rd MIB module as WG document > Nov 2011 Adopt DS-lite MIB module as WG document > Nov 2011 Adopt Mesh topology MIB module as WG document > Nov 2012 Submit 6rd MIB module for Proposed Standard > Nov 2012 Submit DS-lite MIB module for Proposed Standard > Nov 2012 Submit Mesh topology MIB module for Proposed Standard > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > From satoru.matsushima@gmail.com Tue Apr 19 23:33:21 2011 Return-Path: X-Original-To: softwires@ietfc.amsl.com Delivered-To: softwires@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 97F16E077E; Tue, 19 Apr 2011 23:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slw14CJPF+Xp; Tue, 19 Apr 2011 23:33:20 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfc.amsl.com (Postfix) with ESMTP id 66AE7E077B; Tue, 19 Apr 2011 23:33:20 -0700 (PDT) Received: by iye19 with SMTP id 19so450035iye.31 for ; Tue, 19 Apr 2011 23:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jOlpnXmRPmUeFeqCYcwNvxdd2T0M8BgAoZOA5TIUfZc=; b=etl/+5e1fMg3xkIHu/Asi5cRQBoP7lTXIjgoMlc9OBBPrkw+atlkUKd2c2REzAXKmm zjlB8absiClyUZi9dzfg3iDJbyPLSoJrBk6wtm2PrJW4Zjkll0q1r0NT637eQ6f9cJsy lZTaPfVmfFg+zg+tSNTrNVdsJPg6sxPoXR0u8= 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=csVCg2YgcmSCCbK8NyBXqZ6gmgTz7DLrsVO0m1gL+I1yHm7MptcgF221BgUeLkrUYp 01yFTOb69q6jjxjgMY/GQsEmgkoctDlSUMARBZb1XtnV4JJnA29L/h5/uNF6V0JXR5DS xwRPr08bUpPdls6Y4kcGYMJHaXwWDQklZ5+lI= MIME-Version: 1.0 Received: by 10.231.187.232 with SMTP id cx40mr1524967ibb.73.1303281200062; Tue, 19 Apr 2011 23:33:20 -0700 (PDT) Received: by 10.231.32.129 with HTTP; Tue, 19 Apr 2011 23:33:20 -0700 (PDT) In-Reply-To: <20110419163654.09944E0764@ietfc.amsl.com> References: <20110419163654.09944E0764@ietfc.amsl.com> Date: Wed, 20 Apr 2011 15:33:20 +0900 Message-ID: From: Satoru Matsushima To: iesg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org, cuiyong@tsinghua.edu.cn Subject: Re: [Softwires] WG Review: Recharter of Softwires (softwire) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 06:33:21 -0000 Hello, I have some comments for the recharter text. > =A04. Developments for stateless legacy IPv4 carried over IPv6 What does "legacy" mean? I think that no adjective needs to what IPv4 is. > =A0 =A0 - develop a solution motivation document to be published as an > =A0 =A0 =A0 RFC > =A0 =A0 - develop a protocol specification response to the solution > motivation > =A0 =A0 =A0 document; this work item will not be taken through WG last ca= ll > =A0 =A0 =A0 until the solution motivation document has been published It is unclear for the milestone to indicate this item. I think that the milestone should explicitly include the schedule for both solution motivation document and protocol specification for stateless solution. Here's one proposal: Jul 2011 Submit solution motivation document for Stateless IPv4 over IPv6 for Informational Jul 2011 Adopt Stateless IPv4 over IPv6 protocol specification as WG docume= nt Nov 2011 Submit Stateless IPv4 over IPv6 protocol specification for Proposed Standard > Sep 2011 Submit B4NAT for Informational I don't understand what B4NAT is. Is there any discussion about B4NAT in softwires WG so far? If not, it hasn't appropriate yet that the charter includes B4NAT as an ite= m. Best regards, --satoru 2011/4/20 IESG Secretary : > A modified charter has been submitted for the Softwires (softwire) workin= g > group in the Internet Area of the IETF. =A0The IESG has not made any > determination as yet. =A0The modified charter is provided below for > informational purposes only. =A0Please send your comments to the IESG > mailing list (iesg@ietf.org) by Tuesday, April 26, 2011. > > > Softwires (softwire) > **DRAFT 2011-04-14** (v03) > -------------------- > Current Status: Active > > =A0Chairs: > =A0 =A0 Alain Durand > =A0 =A0 Yong Cui > > =A0Internet Area Directors: > =A0 =A0 Ralph Droms > =A0 =A0 Jari Arkko > > =A0Internet Area Advisor: > =A0 =A0 Ralph Droms > > =A0Mailing Lists: > =A0 =A0 General Discussion: softwires@ietf.org > =A0 =A0 To Subscribe: =A0 =A0 =A0 softwires-request@ietf.org > =A0 =A0 Archive: > http://www.ietf.org/mail-archive/web/softwires/current/maillist.html > > Description of Working Group: > > =A0The Softwires Working Group is specifying the standardization of > =A0discovery, control and encapsulation methods for connecting IPv4 > =A0networks across IPv6 networks and IPv6 networks across IPv4 networks > =A0in a way that will encourage multiple, inter-operable > =A0implementations. > > =A0For various reasons, native IPv4 and/or IPv6 transport may not be > =A0available in all cases, and there is a need to tunnel IPv4 in IPv6 > =A0or IPv6 in IPv4 to cross a part of the network which is not IPv4 or > =A0IPv6 capable. The Softwire Problem Statement, RFC 4925, identifies > =A0two distinct topological scenarios that the WG will provide > =A0solutions for: "Hubs and Spokes" and "Mesh." In the former case, > =A0hosts or "stub" networks are attached via individual, > =A0point-to-point, IPv4 over IPv6 or IPv6 over IPv4 softwires to a > =A0centralized Softwire Concentrator. In the latter case (Mesh), > =A0network islands of one Address Family (IPv4 or IPv6) are connected > =A0over a network of another Address Family via point to multi-point > =A0softwires among Address family Border Routers (AFBRs). > > =A0The WG will reuse existing technologies as much as possible and only > =A0when necessary, create additional protocol building blocks. > > =A0For generality, all base Softwires encapsulation mechanisms should > =A0support all combinations of IP versions over one other (IPv4 over > =A0IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). IPv4 to IPv6 > =A0translation mechanisms (NAT-PT), new addressing schemes, and block > =A0address assignments are out of scope. DHCP options developed in this > =A0working group will be reviewed jointly with the DHC WG. =A0RADIUS > =A0attributes developed in this working group will be reviewed jointly > =A0with the RADEXT WG. =A0The MIB Doctors directorate will be asked to > =A0review any MIB modules developed in the SOFTWIRE working group. =A0BGP > =A0and other routing and signaling protocols developed in this group > =A0will be reviewed jointly with the proper working groups and other > =A0workings that may take interest (e.g. IDR, L3VPN, PIM, LDP, SAAG, > =A0etc). > > =A0The specific work areas for this working group are: > > =A01. Developments for Mesh softwires topology; the Mesh topology work > =A0 =A0 will be reviewed in the l3vpn and idr WGs > =A0 =A0 - multicast > =A0 =A0 - MIB module > > =A02. Developments for 6rd: > =A0 =A0 - multicast > =A0 =A0 - operational specification > =A0 =A0 - RADIUS option for 6rd server > =A0 =A0 - MIB module > > =A03. Developments for Dual-Stack Lite (DS-Lite): > =A0 =A0 - multicast > =A0 =A0 - operational specification > =A0 =A0 - RADIUS option for AFTR > =A0 =A0 - proxy extensions; GI-DS-Lite; DS-Lite with no NAT or NAT on the > =A0 =A0 =A0 B4 element > =A0 =A0 - MIB module > > =A04. Developments for stateless legacy IPv4 carried over IPv6 > =A0 =A0 - develop a solution motivation document to be published as an > =A0 =A0 =A0 RFC > =A0 =A0 - develop a protocol specification response to the solution > motivation > =A0 =A0 =A0 document; this work item will not be taken through WG last ca= ll > =A0 =A0 =A0 until the solution motivation document has been published > > =A05. Finalize discovery and configuration mechanisms for a gateway to > =A0 =A0 use DS-Lite or 6rd; these discovery and configuration mechanisms > =A0 =A0 must take into a account other operating environments such as > =A0 =A0 dual-stack and tunneling mechanisms not defined by the softwire > =A0 =A0 WG. =A0Development of new mechanisms will involve the dhc and/or > =A0 =A0 v6ops WGs as appropriate > > Other work items would require WG approval and rechartering. > > Goals and Milestones: > Apr 2011 Submit DS-lite RADIUS option for Proposed Standard > Apr 2011 Adopt DS-lite operational document as WG document > Jul 2011 Submit 6rd RADIUS option for Proposed Standard > Jul 2011 Submit GI DS-lite for Proposed Standard > Jul 2011 Adopt B4NAT as WG document > Aug 2011 Adopt 6rd operational document as WG document > Aug 2011 Adopt Multicast extensions document as WG document > Aug 2011 Submit DS-lite operational document for Informational > Sep 2011 Submit B4NAT for Informational > Nov 2011 Submit Multicast extensions document for Informational > Nov 2011 Submit 6rd operational document for Informational > Nov 2011 Adopt 6rd MIB module as WG document > Nov 2011 Adopt DS-lite MIB module as WG document > Nov 2011 Adopt Mesh topology MIB module as WG document > Nov 2012 Submit 6rd MIB module for Proposed Standard > Nov 2012 Submit DS-lite MIB module for Proposed Standard > Nov 2012 Submit Mesh topology MIB module for Proposed Standard > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From weapon@csnet1.cs.tsinghua.edu.cn Tue Apr 19 23:56:15 2011 Return-Path: X-Original-To: softwires@ietfc.amsl.com Delivered-To: softwires@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0B7ADE06BB; Tue, 19 Apr 2011 23:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.458 X-Spam-Level: ** X-Spam-Status: No, score=2.458 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, J_CHICKENPOX_24=0.6, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcG4veZ9LMCU; Tue, 19 Apr 2011 23:56:14 -0700 (PDT) Received: from mail.jzland.com (unknown [211.151.89.50]) by ietfc.amsl.com (Postfix) with ESMTP id 49693E0661; Tue, 19 Apr 2011 23:56:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.jzland.com (EMOS V1.4 (Postfix)) with ESMTP id 12AD930B0BAA; Wed, 20 Apr 2011 14:56:02 +0800 (CST) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Apr 20 14:56:01 2011 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 1,4dae838139731371817966 X-DSPAM-Factors: 27, there+and, 0.01000, >>+informational, 0.01000, China+From, 0.01000, scope+DHCP, 0.01000, 47, 0.01000, across+IPv4, 0.01000, Mesh+topology, 0.01000, Mesh+topology, 0.01000, IPv4+networks, 0.01000, >If, 0.01000, 20+14, 0.01000, a+need, 0.01000, made, 0.01000, Area+Directors, 0.01000, latter+case, 0.01000, as+yet, 0.01000, IESG, 0.01000, IESG, 0.01000, assignments, 0.01000, proper, 0.01000, Date*14+55, 0.01000, think+that, 0.01000, think+that, 0.01000, IDR+L3VPN, 0.01000, RADIUS+option, 0.01000, RADIUS+option, 0.01000, Subject*Review+Recharter, 0.01000 X-Virus-Scanned: amavisd-new at jzland.com Received: from mail.jzland.com ([127.0.0.1]) by localhost (mail.jzland.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7palaJ2AF0B; Wed, 20 Apr 2011 14:56:01 +0800 (CST) Received: from weapon-PC (unknown [166.111.68.231]) by mail.jzland.com (EMOS V1.4 (Postfix)) with ESMTPA id 16DC730B0B8D; Wed, 20 Apr 2011 14:56:01 +0800 (CST) Date: Wed, 20 Apr 2011 14:55:58 +0800 From: "Peng Wu" To: "Satoru Matsushima" , "iesg" References: <20110419163654.09944E0764@ietfc.amsl.com> Message-ID: <201104201455303763221@csnet1.cs.tsinghua.edu.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Cc: softwires , cuiyong Subject: Re: [Softwires] WG Review: Recharter of Softwires (softwire) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 06:56:15 -0000 SGkgU2F0b3J1LA0KDQpBYm91dCB0aGUgaXRlbSBEUy1MaXRlIHdpdGggbm8gTkFUIG9yIE5BVCBv biB0aGUgQjQsIGl0J3MgRFMtbGl0ZSB3aXRob3V0IENHTiBvbiB0aGUgQUZUUi4NCkdlbmVyYWxs eSBCNCB3aWxsIGdldCBwdWJsaWMgSVB2NCBhZGRyZXNzIGFsbG9jYXRlZCBmcm9tIHRoZSBJU1Ag YW5kIHVzZSBpdCBmb3IgSVB2NCBhY2Nlc3MuIFRoZSBBRlRSIHdpbGwgb25seSBuZWVkIHRvIG1h aW50YWluIElQdjYtSVB2NCBhZGRyZXNzIG1hcHBpbmcgd2l0aG91dCBwb3J0IGluZm9ybWF0aW9u LiANCkRvaW5nIHRoaXMgdGhlIGFkZHJlc3NpbmcgYW5kIHJvdXRpbmcgYmV0d2VlbiBJUHY2IGFu ZCBJUHY0IGFyZSBzdGlsbCBpbmRlcGVuZGVudC4gSXQncyBhIHByb3RvY29sIGV4dGVuc3Rpb24g dG8gRFMtbGl0ZSwgYW5kIGl0IGNhbiB3b3JrIGFsb25nIHdpdGggRFMtbGl0ZS4NCg0KV2UndmUg YWxyZWFkeSBwcmVzZW50IGl0IGluIGxhc3QgdGhyZWUgSUVURiBtZWV0aW5ncy4gU2VlIGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWN1aS1zb2Z0d2lyZS1ob3N0LTRvdmVyNi0wNC4g VGhlIGdlbmVyYWwgaWRlYSBpcyBvdXQgdGhlcmUsIGFuZCB0aGUgb25seSBjb25mdXNpb24gaXMg dGhhdCB0aGUgbWVjaGFuaXNtIG5hbWUgaGFzbid0IG1hdGNoZWQgeWV0Lg0KV2UnbGwgY29tZSB1 cCB3aXRoIGEgbmV3IHZlcnNpb24gd2l0aCBldm9sdmVtZW50IGJlZm9yZSBuZXh0IElFVEYgZm9y IFdHIGFkb3B0aW9uLiANCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0JCQkJIA0KUGVuZyBXdQ0KUGhE IGNhbmRpZGF0ZQ0KRGVwYXJ0bWVudCBvZiBDb21wdXRlciBTY2llbmNlICYgVGVjaG5vbG9neQ0K VHNpbmdodWEgVW5pdmVyc2l0eSwgQmVpamluZywgQ2hpbmENCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRnJvbTpTYXRvcnUg TWF0c3VzaGltYQ0KRGF0ZToyMDExLTA0LTIwIDE0OjMzOjQ3DQpUbzppZXNnDQpDQzpzb2Z0d2ly ZXM7IGN1aXlvbmcNClN1YmplY3Q6UmU6IFtTb2Z0d2lyZXNdIFdHIFJldmlldzogUmVjaGFydGVy IG9mIFNvZnR3aXJlcyAoc29mdHdpcmUpDQoNCj5IZWxsbywNCj4NCj5JIGhhdmUgc29tZSBjb21t ZW50cyBmb3IgdGhlIHJlY2hhcnRlciB0ZXh0Lg0KPg0KPj4goDQuIERldmVsb3BtZW50cyBmb3Ig c3RhdGVsZXNzIGxlZ2FjeSBJUHY0IGNhcnJpZWQgb3ZlciBJUHY2DQo+DQo+V2hhdCBkb2VzICJs ZWdhY3kiIG1lYW4/DQo+SSB0aGluayB0aGF0IG5vIGFkamVjdGl2ZSBuZWVkcyB0byB3aGF0IElQ djQgaXMuDQo+DQo+PiCgIKAgLSBkZXZlbG9wIGEgc29sdXRpb24gbW90aXZhdGlvbiBkb2N1bWVu dCB0byBiZSBwdWJsaXNoZWQgYXMgYW4NCj4+IKAgoCCgIFJGQw0KPj4goCCgIC0gZGV2ZWxvcCBh IHByb3RvY29sIHNwZWNpZmljYXRpb24gcmVzcG9uc2UgdG8gdGhlIHNvbHV0aW9uDQo+PiBtb3Rp dmF0aW9uDQo+PiCgIKAgoCBkb2N1bWVudDsgdGhpcyB3b3JrIGl0ZW0gd2lsbCBub3QgYmUgdGFr ZW4gdGhyb3VnaCBXRyBsYXN0IGNhbGwNCj4+IKAgoCCgIHVudGlsIHRoZSBzb2x1dGlvbiBtb3Rp dmF0aW9uIGRvY3VtZW50IGhhcyBiZWVuIHB1Ymxpc2hlZA0KPg0KPkl0IGlzIHVuY2xlYXIgZm9y IHRoZSBtaWxlc3RvbmUgdG8gaW5kaWNhdGUgdGhpcyBpdGVtLiBJIHRoaW5rIHRoYXQNCj50aGUg bWlsZXN0b25lIHNob3VsZCBleHBsaWNpdGx5IGluY2x1ZGUgdGhlIHNjaGVkdWxlIGZvciBib3Ro IHNvbHV0aW9uDQo+bW90aXZhdGlvbiBkb2N1bWVudCBhbmQgcHJvdG9jb2wgc3BlY2lmaWNhdGlv biBmb3Igc3RhdGVsZXNzIHNvbHV0aW9uLg0KPkhlcmUncyBvbmUgcHJvcG9zYWw6DQo+DQo+SnVs IDIwMTEgU3VibWl0IHNvbHV0aW9uIG1vdGl2YXRpb24gZG9jdW1lbnQgZm9yIFN0YXRlbGVzcyBJ UHY0IG92ZXINCj5JUHY2IGZvciBJbmZvcm1hdGlvbmFsDQo+SnVsIDIwMTEgQWRvcHQgU3RhdGVs ZXNzIElQdjQgb3ZlciBJUHY2IHByb3RvY29sIHNwZWNpZmljYXRpb24gYXMgV0cgZG9jdW1lbnQN Cj5Ob3YgMjAxMSBTdWJtaXQgU3RhdGVsZXNzIElQdjQgb3ZlciBJUHY2IHByb3RvY29sIHNwZWNp ZmljYXRpb24gZm9yDQo+UHJvcG9zZWQgU3RhbmRhcmQNCj4NCj4+IFNlcCAyMDExIFN1Ym1pdCBC NE5BVCBmb3IgSW5mb3JtYXRpb25hbA0KPg0KPkkgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IEI0TkFU IGlzLiBJcyB0aGVyZSBhbnkgZGlzY3Vzc2lvbiBhYm91dCBCNE5BVA0KPmluIHNvZnR3aXJlcyBX RyBzbyBmYXI/DQo+SWYgbm90LCBpdCBoYXNuJ3QgYXBwcm9wcmlhdGUgeWV0IHRoYXQgdGhlIGNo YXJ0ZXIgaW5jbHVkZXMgQjROQVQgYXMgYW4gaXRlbS4NCj4NCj4NCj5CZXN0IHJlZ2FyZHMsDQo+ LS1zYXRvcnUNCj4NCj4NCj4yMDExLzQvMjAgSUVTRyBTZWNyZXRhcnkgPGllc2ctc2VjcmV0YXJ5 QGlldGYub3JnPjoNCj4+IEEgbW9kaWZpZWQgY2hhcnRlciBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9y IHRoZSBTb2Z0d2lyZXMgKHNvZnR3aXJlKSB3b3JraW5nDQo+PiBncm91cCBpbiB0aGUgSW50ZXJu ZXQgQXJlYSBvZiB0aGUgSUVURi4goFRoZSBJRVNHIGhhcyBub3QgbWFkZSBhbnkNCj4+IGRldGVy bWluYXRpb24gYXMgeWV0LiCgVGhlIG1vZGlmaWVkIGNoYXJ0ZXIgaXMgcHJvdmlkZWQgYmVsb3cg Zm9yDQo+PiBpbmZvcm1hdGlvbmFsIHB1cnBvc2VzIG9ubHkuIKBQbGVhc2Ugc2VuZCB5b3VyIGNv bW1lbnRzIHRvIHRoZSBJRVNHDQo+PiBtYWlsaW5nIGxpc3QgKGllc2dAaWV0Zi5vcmcpIGJ5IFR1 ZXNkYXksIEFwcmlsIDI2LCAyMDExLg0KPj4NCj4+DQo+PiBTb2Z0d2lyZXMgKHNvZnR3aXJlKQ0K Pj4gKipEUkFGVCAyMDExLTA0LTE0KiogKHYwMykNCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ PiBDdXJyZW50IFN0YXR1czogQWN0aXZlDQo+Pg0KPj4goENoYWlyczoNCj4+IKAgoCBBbGFpbiBE dXJhbmQgPGFkdXJhbmRAanVuaXBlci5uZXQ+DQo+PiCgIKAgWW9uZyBDdWkgPGN1aXlvbmdAdHNp bmdodWEuZWR1LmNuPg0KPj4NCj4+IKBJbnRlcm5ldCBBcmVhIERpcmVjdG9yczoNCj4+IKAgoCBS YWxwaCBEcm9tcyA8cmRyb21zLmlldGZAZ21haWwuY29tPg0KPj4goCCgIEphcmkgQXJra28gPGph cmkuYXJra29AcGl1aGEubmV0Pg0KPj4NCj4+IKBJbnRlcm5ldCBBcmVhIEFkdmlzb3I6DQo+PiCg IKAgUmFscGggRHJvbXMgPHJkcm9tcy5pZXRmQGdtYWlsLmNvbT4NCj4+DQo+PiCgTWFpbGluZyBM aXN0czoNCj4+IKAgoCBHZW5lcmFsIERpc2N1c3Npb246IHNvZnR3aXJlc0BpZXRmLm9yZw0KPj4g oCCgIFRvIFN1YnNjcmliZTogoCCgIKAgc29mdHdpcmVzLXJlcXVlc3RAaWV0Zi5vcmcNCj4+IKAg oCBBcmNoaXZlOg0KPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NvZnR3 aXJlcy9jdXJyZW50L21haWxsaXN0Lmh0bWwNCj4+DQo+PiBEZXNjcmlwdGlvbiBvZiBXb3JraW5n IEdyb3VwOg0KPj4NCj4+IKBUaGUgU29mdHdpcmVzIFdvcmtpbmcgR3JvdXAgaXMgc3BlY2lmeWlu ZyB0aGUgc3RhbmRhcmRpemF0aW9uIG9mDQo+PiCgZGlzY292ZXJ5LCBjb250cm9sIGFuZCBlbmNh cHN1bGF0aW9uIG1ldGhvZHMgZm9yIGNvbm5lY3RpbmcgSVB2NA0KPj4goG5ldHdvcmtzIGFjcm9z cyBJUHY2IG5ldHdvcmtzIGFuZCBJUHY2IG5ldHdvcmtzIGFjcm9zcyBJUHY0IG5ldHdvcmtzDQo+ PiCgaW4gYSB3YXkgdGhhdCB3aWxsIGVuY291cmFnZSBtdWx0aXBsZSwgaW50ZXItb3BlcmFibGUN Cj4+IKBpbXBsZW1lbnRhdGlvbnMuDQo+Pg0KPj4goEZvciB2YXJpb3VzIHJlYXNvbnMsIG5hdGl2 ZSBJUHY0IGFuZC9vciBJUHY2IHRyYW5zcG9ydCBtYXkgbm90IGJlDQo+PiCgYXZhaWxhYmxlIGlu IGFsbCBjYXNlcywgYW5kIHRoZXJlIGlzIGEgbmVlZCB0byB0dW5uZWwgSVB2NCBpbiBJUHY2DQo+ PiCgb3IgSVB2NiBpbiBJUHY0IHRvIGNyb3NzIGEgcGFydCBvZiB0aGUgbmV0d29yayB3aGljaCBp cyBub3QgSVB2NCBvcg0KPj4goElQdjYgY2FwYWJsZS4gVGhlIFNvZnR3aXJlIFByb2JsZW0gU3Rh dGVtZW50LCBSRkMgNDkyNSwgaWRlbnRpZmllcw0KPj4goHR3byBkaXN0aW5jdCB0b3BvbG9naWNh bCBzY2VuYXJpb3MgdGhhdCB0aGUgV0cgd2lsbCBwcm92aWRlDQo+PiCgc29sdXRpb25zIGZvcjog Ikh1YnMgYW5kIFNwb2tlcyIgYW5kICJNZXNoLiIgSW4gdGhlIGZvcm1lciBjYXNlLA0KPj4goGhv c3RzIG9yICJzdHViIiBuZXR3b3JrcyBhcmUgYXR0YWNoZWQgdmlhIGluZGl2aWR1YWwsDQo+PiCg cG9pbnQtdG8tcG9pbnQsIElQdjQgb3ZlciBJUHY2IG9yIElQdjYgb3ZlciBJUHY0IHNvZnR3aXJl cyB0byBhDQo+PiCgY2VudHJhbGl6ZWQgU29mdHdpcmUgQ29uY2VudHJhdG9yLiBJbiB0aGUgbGF0 dGVyIGNhc2UgKE1lc2gpLA0KPj4goG5ldHdvcmsgaXNsYW5kcyBvZiBvbmUgQWRkcmVzcyBGYW1p bHkgKElQdjQgb3IgSVB2NikgYXJlIGNvbm5lY3RlZA0KPj4goG92ZXIgYSBuZXR3b3JrIG9mIGFu b3RoZXIgQWRkcmVzcyBGYW1pbHkgdmlhIHBvaW50IHRvIG11bHRpLXBvaW50DQo+PiCgc29mdHdp cmVzIGFtb25nIEFkZHJlc3MgZmFtaWx5IEJvcmRlciBSb3V0ZXJzIChBRkJScykuDQo+Pg0KPj4g oFRoZSBXRyB3aWxsIHJldXNlIGV4aXN0aW5nIHRlY2hub2xvZ2llcyBhcyBtdWNoIGFzIHBvc3Np YmxlIGFuZCBvbmx5DQo+PiCgd2hlbiBuZWNlc3NhcnksIGNyZWF0ZSBhZGRpdGlvbmFsIHByb3Rv Y29sIGJ1aWxkaW5nIGJsb2Nrcy4NCj4+DQo+PiCgRm9yIGdlbmVyYWxpdHksIGFsbCBiYXNlIFNv ZnR3aXJlcyBlbmNhcHN1bGF0aW9uIG1lY2hhbmlzbXMgc2hvdWxkDQo+PiCgc3VwcG9ydCBhbGwg Y29tYmluYXRpb25zIG9mIElQIHZlcnNpb25zIG92ZXIgb25lIG90aGVyIChJUHY0IG92ZXINCj4+ IKBJUHY2LCBJUHY2IG92ZXIgSVB2NCwgSVB2NCBvdmVyIElQdjQsIElQdjYgb3ZlciBJUHY2KS4g SVB2NCB0byBJUHY2DQo+PiCgdHJhbnNsYXRpb24gbWVjaGFuaXNtcyAoTkFULVBUKSwgbmV3IGFk ZHJlc3Npbmcgc2NoZW1lcywgYW5kIGJsb2NrDQo+PiCgYWRkcmVzcyBhc3NpZ25tZW50cyBhcmUg b3V0IG9mIHNjb3BlLiBESENQIG9wdGlvbnMgZGV2ZWxvcGVkIGluIHRoaXMNCj4+IKB3b3JraW5n IGdyb3VwIHdpbGwgYmUgcmV2aWV3ZWQgam9pbnRseSB3aXRoIHRoZSBESEMgV0cuIKBSQURJVVMN Cj4+IKBhdHRyaWJ1dGVzIGRldmVsb3BlZCBpbiB0aGlzIHdvcmtpbmcgZ3JvdXAgd2lsbCBiZSBy ZXZpZXdlZCBqb2ludGx5DQo+PiCgd2l0aCB0aGUgUkFERVhUIFdHLiCgVGhlIE1JQiBEb2N0b3Jz IGRpcmVjdG9yYXRlIHdpbGwgYmUgYXNrZWQgdG8NCj4+IKByZXZpZXcgYW55IE1JQiBtb2R1bGVz IGRldmVsb3BlZCBpbiB0aGUgU09GVFdJUkUgd29ya2luZyBncm91cC4goEJHUA0KPj4goGFuZCBv dGhlciByb3V0aW5nIGFuZCBzaWduYWxpbmcgcHJvdG9jb2xzIGRldmVsb3BlZCBpbiB0aGlzIGdy b3VwDQo+PiCgd2lsbCBiZSByZXZpZXdlZCBqb2ludGx5IHdpdGggdGhlIHByb3BlciB3b3JraW5n IGdyb3VwcyBhbmQgb3RoZXINCj4+IKB3b3JraW5ncyB0aGF0IG1heSB0YWtlIGludGVyZXN0IChl LmcuIElEUiwgTDNWUE4sIFBJTSwgTERQLCBTQUFHLA0KPj4goGV0YykuDQo+Pg0KPj4goFRoZSBz cGVjaWZpYyB3b3JrIGFyZWFzIGZvciB0aGlzIHdvcmtpbmcgZ3JvdXAgYXJlOg0KPj4NCj4+IKAx LiBEZXZlbG9wbWVudHMgZm9yIE1lc2ggc29mdHdpcmVzIHRvcG9sb2d5OyB0aGUgTWVzaCB0b3Bv bG9neSB3b3JrDQo+PiCgIKAgd2lsbCBiZSByZXZpZXdlZCBpbiB0aGUgbDN2cG4gYW5kIGlkciBX R3MNCj4+IKAgoCAtIG11bHRpY2FzdA0KPj4goCCgIC0gTUlCIG1vZHVsZQ0KPj4NCj4+IKAyLiBE ZXZlbG9wbWVudHMgZm9yIDZyZDoNCj4+IKAgoCAtIG11bHRpY2FzdA0KPj4goCCgIC0gb3BlcmF0 aW9uYWwgc3BlY2lmaWNhdGlvbg0KPj4goCCgIC0gUkFESVVTIG9wdGlvbiBmb3IgNnJkIHNlcnZl cg0KPj4goCCgIC0gTUlCIG1vZHVsZQ0KPj4NCj4+IKAzLiBEZXZlbG9wbWVudHMgZm9yIER1YWwt U3RhY2sgTGl0ZSAoRFMtTGl0ZSk6DQo+PiCgIKAgLSBtdWx0aWNhc3QNCj4+IKAgoCAtIG9wZXJh dGlvbmFsIHNwZWNpZmljYXRpb24NCj4+IKAgoCAtIFJBRElVUyBvcHRpb24gZm9yIEFGVFINCj4+ IKAgoCAtIHByb3h5IGV4dGVuc2lvbnM7IEdJLURTLUxpdGU7IERTLUxpdGUgd2l0aCBubyBOQVQg b3IgTkFUIG9uIHRoZQ0KPj4goCCgIKAgQjQgZWxlbWVudA0KPj4goCCgIC0gTUlCIG1vZHVsZQ0K Pj4NCj4+IKA0LiBEZXZlbG9wbWVudHMgZm9yIHN0YXRlbGVzcyBsZWdhY3kgSVB2NCBjYXJyaWVk IG92ZXIgSVB2Ng0KPj4goCCgIC0gZGV2ZWxvcCBhIHNvbHV0aW9uIG1vdGl2YXRpb24gZG9jdW1l bnQgdG8gYmUgcHVibGlzaGVkIGFzIGFuDQo+PiCgIKAgoCBSRkMNCj4+IKAgoCAtIGRldmVsb3Ag YSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIHJlc3BvbnNlIHRvIHRoZSBzb2x1dGlvbg0KPj4gbW90 aXZhdGlvbg0KPj4goCCgIKAgZG9jdW1lbnQ7IHRoaXMgd29yayBpdGVtIHdpbGwgbm90IGJlIHRh a2VuIHRocm91Z2ggV0cgbGFzdCBjYWxsDQo+PiCgIKAgoCB1bnRpbCB0aGUgc29sdXRpb24gbW90 aXZhdGlvbiBkb2N1bWVudCBoYXMgYmVlbiBwdWJsaXNoZWQNCj4+DQo+PiCgNS4gRmluYWxpemUg ZGlzY292ZXJ5IGFuZCBjb25maWd1cmF0aW9uIG1lY2hhbmlzbXMgZm9yIGEgZ2F0ZXdheSB0bw0K Pj4goCCgIHVzZSBEUy1MaXRlIG9yIDZyZDsgdGhlc2UgZGlzY292ZXJ5IGFuZCBjb25maWd1cmF0 aW9uIG1lY2hhbmlzbXMNCj4+IKAgoCBtdXN0IHRha2UgaW50byBhIGFjY291bnQgb3RoZXIgb3Bl cmF0aW5nIGVudmlyb25tZW50cyBzdWNoIGFzDQo+PiCgIKAgZHVhbC1zdGFjayBhbmQgdHVubmVs aW5nIG1lY2hhbmlzbXMgbm90IGRlZmluZWQgYnkgdGhlIHNvZnR3aXJlDQo+PiCgIKAgV0cuIKBE ZXZlbG9wbWVudCBvZiBuZXcgbWVjaGFuaXNtcyB3aWxsIGludm9sdmUgdGhlIGRoYyBhbmQvb3IN Cj4+IKAgoCB2Nm9wcyBXR3MgYXMgYXBwcm9wcmlhdGUNCj4+DQo+PiBPdGhlciB3b3JrIGl0ZW1z IHdvdWxkIHJlcXVpcmUgV0cgYXBwcm92YWwgYW5kIHJlY2hhcnRlcmluZy4NCj4+DQo+PiBHb2Fs cyBhbmQgTWlsZXN0b25lczoNCj4+IEFwciAyMDExIFN1Ym1pdCBEUy1saXRlIFJBRElVUyBvcHRp b24gZm9yIFByb3Bvc2VkIFN0YW5kYXJkDQo+PiBBcHIgMjAxMSBBZG9wdCBEUy1saXRlIG9wZXJh dGlvbmFsIGRvY3VtZW50IGFzIFdHIGRvY3VtZW50DQo+PiBKdWwgMjAxMSBTdWJtaXQgNnJkIFJB RElVUyBvcHRpb24gZm9yIFByb3Bvc2VkIFN0YW5kYXJkDQo+PiBKdWwgMjAxMSBTdWJtaXQgR0kg RFMtbGl0ZSBmb3IgUHJvcG9zZWQgU3RhbmRhcmQNCj4+IEp1bCAyMDExIEFkb3B0IEI0TkFUIGFz IFdHIGRvY3VtZW50DQo+PiBBdWcgMjAxMSBBZG9wdCA2cmQgb3BlcmF0aW9uYWwgZG9jdW1lbnQg YXMgV0cgZG9jdW1lbnQNCj4+IEF1ZyAyMDExIEFkb3B0IE11bHRpY2FzdCBleHRlbnNpb25zIGRv Y3VtZW50IGFzIFdHIGRvY3VtZW50DQo+PiBBdWcgMjAxMSBTdWJtaXQgRFMtbGl0ZSBvcGVyYXRp b25hbCBkb2N1bWVudCBmb3IgSW5mb3JtYXRpb25hbA0KPj4gU2VwIDIwMTEgU3VibWl0IEI0TkFU IGZvciBJbmZvcm1hdGlvbmFsDQo+PiBOb3YgMjAxMSBTdWJtaXQgTXVsdGljYXN0IGV4dGVuc2lv bnMgZG9jdW1lbnQgZm9yIEluZm9ybWF0aW9uYWwNCj4+IE5vdiAyMDExIFN1Ym1pdCA2cmQgb3Bl cmF0aW9uYWwgZG9jdW1lbnQgZm9yIEluZm9ybWF0aW9uYWwNCj4+IE5vdiAyMDExIEFkb3B0IDZy ZCBNSUIgbW9kdWxlIGFzIFdHIGRvY3VtZW50DQo+PiBOb3YgMjAxMSBBZG9wdCBEUy1saXRlIE1J QiBtb2R1bGUgYXMgV0cgZG9jdW1lbnQNCj4+IE5vdiAyMDExIEFkb3B0IE1lc2ggdG9wb2xvZ3kg TUlCIG1vZHVsZSBhcyBXRyBkb2N1bWVudA0KPj4gTm92IDIwMTIgU3VibWl0IDZyZCBNSUIgbW9k dWxlIGZvciBQcm9wb3NlZCBTdGFuZGFyZA0KPj4gTm92IDIwMTIgU3VibWl0IERTLWxpdGUgTUlC IG1vZHVsZSBmb3IgUHJvcG9zZWQgU3RhbmRhcmQNCj4+IE5vdiAyMDEyIFN1Ym1pdCBNZXNoIHRv cG9sb2d5IE1JQiBtb2R1bGUgZm9yIFByb3Bvc2VkIFN0YW5kYXJkDQo+Pg0KPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IFNvZnR3aXJlcyBtYWls aW5nIGxpc3QNCj4+IFNvZnR3aXJlc0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCj4+DQo+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj5Tb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+U29mdHdp cmVzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0 d2lyZXMNCg== From Internet-Drafts@ietf.org Wed Apr 20 01:45:03 2011 Return-Path: X-Original-To: softwires@ietfc.amsl.com Delivered-To: softwires@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 30B2DE077D; Wed, 20 Apr 2011 01:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.757 X-Spam-Level: X-Spam-Status: No, score=-102.757 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY6eS4tVseWf; Wed, 20 Apr 2011 01:45:02 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 693C5E0798; Wed, 20 Apr 2011 01:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110420084502.5798.71688.idtracker@ietfc.amsl.com> Date: Wed, 20 Apr 2011 01:45:02 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action:draft-ietf-softwire-6rd-radius-attrib-02.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 08:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : RADIUS Attribute for 6rd Author(s) : D. Guo, S. Jiang Filename : draft-ietf-softwire-6rd-radius-attrib-02.txt Pages : 9 Date : 2011-04-20 6rd is One of the most popular methods to provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The DHCP 6rd option has been defined to configure 6rd CPE. But in many networks, the configuration information may be stored in AAA servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHC protocol. This document defines a RADIUS attribute that carries 6rd configuration information from AAA server to BNG. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-6rd-radius-attrib-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-softwire-6rd-radius-attrib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-20014006.I-D@ietf.org> --NextPart-- From satoru.matsushima@gmail.com Wed Apr 20 01:52:40 2011 Return-Path: X-Original-To: softwires@ietfc.amsl.com Delivered-To: softwires@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6D255E067C; Wed, 20 Apr 2011 01:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpZUMZOjaJYD; Wed, 20 Apr 2011 01:52:39 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id 23C67E07A9; Wed, 20 Apr 2011 01:52:39 -0700 (PDT) Received: by iwn39 with SMTP id 39so551937iwn.31 for ; Wed, 20 Apr 2011 01:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CFXxmn46wUcQEE0lS+6JyNQCPvyNodI/P/E72e03Jeo=; b=W91MoeXRaaiWpSoujeyDgQN5H4OZ02VNZoghSJabdDMbznadhi/ClRf2sBafOLhZl3 qCxXD1doT2arQNPkuGZrfwqZ+PF1V5HmQF+olCYODn3fhW5Kad75+6Y546u0Bl8gBTAK GjCUATPMUq8piXQ5C6jSZiza3Jm+h37Qdh/ds= 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=BAiRtyzMBbjndkniS+Kp3yKLVVnkDan2UFw5X8f0scTD+Y6h2hqJSZC79Ko6Q4MD4Y DnqAZAU7enY9HiOgMrwhki88BGA6LEbG9f7orPeYE+0sV+I4Z5SMyoj9Krow06FsLYRV 48IC5iR+o9I84i5HR7HCSd1AIP9kTgwAsciho= MIME-Version: 1.0 Received: by 10.43.62.210 with SMTP id xb18mr9320730icb.349.1303289558294; Wed, 20 Apr 2011 01:52:38 -0700 (PDT) Received: by 10.231.32.129 with HTTP; Wed, 20 Apr 2011 01:52:38 -0700 (PDT) In-Reply-To: <201104201455303763221@csnet1.cs.tsinghua.edu.cn> References: <20110419163654.09944E0764@ietfc.amsl.com> <201104201455303763221@csnet1.cs.tsinghua.edu.cn> Date: Wed, 20 Apr 2011 17:52:38 +0900 Message-ID: From: Satoru Matsushima To: Peng Wu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires , cuiyong , iesg Subject: Re: [Softwires] WG Review: Recharter of Softwires (softwire) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 08:52:40 -0000 Hi Peng, 2011/4/20 Peng Wu : > Hi Satoru, > > About the item DS-Lite with no NAT or NAT on the B4, it's DS-lite without= CGN on the AFTR. > Generally B4 will get public IPv4 address allocated from the ISP and use = it for IPv4 access. The AFTR will only need to maintain IPv6-IPv4 address m= apping without port information. > Doing this the addressing and routing between IPv6 and IPv4 are still ind= ependent. It's a protocol extenstion to DS-lite, and it can work along with= DS-lite. So you mean that your 4over6 document is a B4NAT document, isn't it? But I don't find any B4NAT definition in your document though. On the other hand, I understand that you propose another 4over6 deployment model, which you don't need to use ds-lite terminology. You already define 4over6 initiator and concentrator, etc., So I think that using "B4NAT" makes confusion. > > We've already present it in last three IETF meetings. See http://tools.ie= tf.org/html/draft-cui-softwire-host-4over6-04. The general idea is out ther= e, and the only confusion is that the mechanism name hasn't matched yet. > We'll come up with a new version with evolvement before next IETF for WG = adoption. I'm confused because current ds-lite document clearly define as follow in section 4.2: "A DS-Lite CPE SHOULD NOT operate a NAT function between an internal interface and a B4 interface, as the NAT function will be performed by the AFTR in the service provider's network. That will avoid accidentally operating in a double NAT environment." And section 5.1 describes as follow: "5. B4 element 5.1. Definition The B4 element is a function implemented on a dual-stack capable node, either a directly connected device or a CPE, that creates a tunnel to an AFTR." These mean that B4 is equal to CPE, so that B4 cannot has NAT function. Is that correct? Best regards, --satoru > > > ------------------ > Peng Wu > PhD candidate > Department of Computer Science & Technology > Tsinghua University, Beijing, China > > ------------------------------------------------------------- > From:Satoru Matsushima > Date:2011-04-20 14:33:47 > To:iesg > CC:softwires; cuiyong > Subject:Re: [Softwires] WG Review: Recharter of Softwires (softwire) > >>Hello, >> >>I have some comments for the recharter text. >> >>> =A04. Developments for stateless legacy IPv4 carried over IPv6 >> >>What does "legacy" mean? >>I think that no adjective needs to what IPv4 is. >> >>> =A0 =A0 - develop a solution motivation document to be published as an >>> =A0 =A0 =A0 RFC >>> =A0 =A0 - develop a protocol specification response to the solution >>> motivation >>> =A0 =A0 =A0 document; this work item will not be taken through WG last = call >>> =A0 =A0 =A0 until the solution motivation document has been published >> >>It is unclear for the milestone to indicate this item. I think that >>the milestone should explicitly include the schedule for both solution >>motivation document and protocol specification for stateless solution. >>Here's one proposal: >> >>Jul 2011 Submit solution motivation document for Stateless IPv4 over >>IPv6 for Informational >>Jul 2011 Adopt Stateless IPv4 over IPv6 protocol specification as WG docu= ment >>Nov 2011 Submit Stateless IPv4 over IPv6 protocol specification for >>Proposed Standard >> >>> Sep 2011 Submit B4NAT for Informational >> >>I don't understand what B4NAT is. Is there any discussion about B4NAT >>in softwires WG so far? >>If not, it hasn't appropriate yet that the charter includes B4NAT as an i= tem. >> >> >>Best regards, >>--satoru >> >> >>2011/4/20 IESG Secretary : >>> A modified charter has been submitted for the Softwires (softwire) work= ing >>> group in the Internet Area of the IETF. =A0The IESG has not made any >>> determination as yet. =A0The modified charter is provided below for >>> informational purposes only. =A0Please send your comments to the IESG >>> mailing list (iesg@ietf.org) by Tuesday, April 26, 2011. >>> >>> >>> Softwires (softwire) >>> **DRAFT 2011-04-14** (v03) >>> -------------------- >>> Current Status: Active >>> >>> =A0Chairs: >>> =A0 =A0 Alain Durand >>> =A0 =A0 Yong Cui >>> >>> =A0Internet Area Directors: >>> =A0 =A0 Ralph Droms >>> =A0 =A0 Jari Arkko >>> >>> =A0Internet Area Advisor: >>> =A0 =A0 Ralph Droms >>> >>> =A0Mailing Lists: >>> =A0 =A0 General Discussion: softwires@ietf.org >>> =A0 =A0 To Subscribe: =A0 =A0 =A0 softwires-request@ietf.org >>> =A0 =A0 Archive: >>> http://www.ietf.org/mail-archive/web/softwires/current/maillist.html >>> >>> Description of Working Group: >>> >>> =A0The Softwires Working Group is specifying the standardization of >>> =A0discovery, control and encapsulation methods for connecting IPv4 >>> =A0networks across IPv6 networks and IPv6 networks across IPv4 networks >>> =A0in a way that will encourage multiple, inter-operable >>> =A0implementations. >>> >>> =A0For various reasons, native IPv4 and/or IPv6 transport may not be >>> =A0available in all cases, and there is a need to tunnel IPv4 in IPv6 >>> =A0or IPv6 in IPv4 to cross a part of the network which is not IPv4 or >>> =A0IPv6 capable. The Softwire Problem Statement, RFC 4925, identifies >>> =A0two distinct topological scenarios that the WG will provide >>> =A0solutions for: "Hubs and Spokes" and "Mesh." In the former case, >>> =A0hosts or "stub" networks are attached via individual, >>> =A0point-to-point, IPv4 over IPv6 or IPv6 over IPv4 softwires to a >>> =A0centralized Softwire Concentrator. In the latter case (Mesh), >>> =A0network islands of one Address Family (IPv4 or IPv6) are connected >>> =A0over a network of another Address Family via point to multi-point >>> =A0softwires among Address family Border Routers (AFBRs). >>> >>> =A0The WG will reuse existing technologies as much as possible and only >>> =A0when necessary, create additional protocol building blocks. >>> >>> =A0For generality, all base Softwires encapsulation mechanisms should >>> =A0support all combinations of IP versions over one other (IPv4 over >>> =A0IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). IPv4 to IPv6 >>> =A0translation mechanisms (NAT-PT), new addressing schemes, and block >>> =A0address assignments are out of scope. DHCP options developed in this >>> =A0working group will be reviewed jointly with the DHC WG. =A0RADIUS >>> =A0attributes developed in this working group will be reviewed jointly >>> =A0with the RADEXT WG. =A0The MIB Doctors directorate will be asked to >>> =A0review any MIB modules developed in the SOFTWIRE working group. =A0B= GP >>> =A0and other routing and signaling protocols developed in this group >>> =A0will be reviewed jointly with the proper working groups and other >>> =A0workings that may take interest (e.g. IDR, L3VPN, PIM, LDP, SAAG, >>> =A0etc). >>> >>> =A0The specific work areas for this working group are: >>> >>> =A01. Developments for Mesh softwires topology; the Mesh topology work >>> =A0 =A0 will be reviewed in the l3vpn and idr WGs >>> =A0 =A0 - multicast >>> =A0 =A0 - MIB module >>> >>> =A02. Developments for 6rd: >>> =A0 =A0 - multicast >>> =A0 =A0 - operational specification >>> =A0 =A0 - RADIUS option for 6rd server >>> =A0 =A0 - MIB module >>> >>> =A03. Developments for Dual-Stack Lite (DS-Lite): >>> =A0 =A0 - multicast >>> =A0 =A0 - operational specification >>> =A0 =A0 - RADIUS option for AFTR >>> =A0 =A0 - proxy extensions; GI-DS-Lite; DS-Lite with no NAT or NAT on t= he >>> =A0 =A0 =A0 B4 element >>> =A0 =A0 - MIB module >>> >>> =A04. Developments for stateless legacy IPv4 carried over IPv6 >>> =A0 =A0 - develop a solution motivation document to be published as an >>> =A0 =A0 =A0 RFC >>> =A0 =A0 - develop a protocol specification response to the solution >>> motivation >>> =A0 =A0 =A0 document; this work item will not be taken through WG last = call >>> =A0 =A0 =A0 until the solution motivation document has been published >>> >>> =A05. Finalize discovery and configuration mechanisms for a gateway to >>> =A0 =A0 use DS-Lite or 6rd; these discovery and configuration mechanism= s >>> =A0 =A0 must take into a account other operating environments such as >>> =A0 =A0 dual-stack and tunneling mechanisms not defined by the softwire >>> =A0 =A0 WG. =A0Development of new mechanisms will involve the dhc and/o= r >>> =A0 =A0 v6ops WGs as appropriate >>> >>> Other work items would require WG approval and rechartering. >>> >>> Goals and Milestones: >>> Apr 2011 Submit DS-lite RADIUS option for Proposed Standard >>> Apr 2011 Adopt DS-lite operational document as WG document >>> Jul 2011 Submit 6rd RADIUS option for Proposed Standard >>> Jul 2011 Submit GI DS-lite for Proposed Standard >>> Jul 2011 Adopt B4NAT as WG document >>> Aug 2011 Adopt 6rd operational document as WG document >>> Aug 2011 Adopt Multicast extensions document as WG document >>> Aug 2011 Submit DS-lite operational document for Informational >>> Sep 2011 Submit B4NAT for Informational >>> Nov 2011 Submit Multicast extensions document for Informational >>> Nov 2011 Submit 6rd operational document for Informational >>> Nov 2011 Adopt 6rd MIB module as WG document >>> Nov 2011 Adopt DS-lite MIB module as WG document >>> Nov 2011 Adopt Mesh topology MIB module as WG document >>> Nov 2012 Submit 6rd MIB module for Proposed Standard >>> Nov 2012 Submit DS-lite MIB module for Proposed Standard >>> Nov 2012 Submit Mesh topology MIB module for Proposed Standard >>> >>> _______________________________________________ >>> 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 weapon@csnet1.cs.tsinghua.edu.cn Wed Apr 20 02:15:05 2011 Return-Path: X-Original-To: softwires@ietfc.amsl.com Delivered-To: softwires@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AB093E0670; Wed, 20 Apr 2011 02:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.458 X-Spam-Level: ** X-Spam-Status: No, score=2.458 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, J_CHICKENPOX_52=0.6, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjLJ3MNPAaHN; Wed, 20 Apr 2011 02:15:04 -0700 (PDT) Received: from mail.jzland.com (unknown [211.151.89.50]) by ietfc.amsl.com (Postfix) with ESMTP id 2AE8EE06A4; Wed, 20 Apr 2011 02:15:01 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.jzland.com (EMOS V1.4 (Postfix)) with ESMTP id 6BE5C30B0BCE; Wed, 20 Apr 2011 17:14:58 +0800 (CST) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Apr 20 17:14:58 2011 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 1,4daea41239731123439393 X-DSPAM-Factors: 27, there+and, 0.01000, That, 0.01000, "5, 0.01000, terminology, 0.01000, terminology, 0.01000, Date*14+55, 0.01000, Subject*Review+Recharter, 0.01000, Like, 0.01000, implemented, 0.01000, provider's, 0.01000, an, 0.01000, an, 0.01000, X-Envelope-To*, 0.01000, To*"Satoru, 0.01000, B4+will, 0.01000, interface, 0.01000, interface, 0.01000, from, 0.01000, NAT+or, 0.01000, NAT+or, 0.01000, Url*4over6, 0.01000, References*<20110419163654.09944E0764, 0.01000, to+original, 0.01000, new+version, 0.01000, Definition, 0.01000, follow+>, 0.01000, is+equal, 0.01000 X-Virus-Scanned: amavisd-new at jzland.com Received: from mail.jzland.com ([127.0.0.1]) by localhost (mail.jzland.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0LPuewm7tpa; Wed, 20 Apr 2011 17:14:57 +0800 (CST) Received: from weapon-PC (unknown [166.111.68.231]) by mail.jzland.com (EMOS V1.4 (Postfix)) with ESMTPA id 915B830B0B86; Wed, 20 Apr 2011 17:14:57 +0800 (CST) Date: Wed, 20 Apr 2011 17:14:55 +0800 From: "Peng Wu" To: "Satoru Matsushima" References: <20110419163654.09944E0764@ietfc.amsl.com>, <201104201455303763221@csnet1.cs.tsinghua.edu.cn> Message-ID: <201104201714271360705@csnet1.cs.tsinghua.edu.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Cc: softwires , cuiyong , iesg Subject: Re: [Softwires] WG Review: Recharter of Softwires (softwire) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 09:15:05 -0000 SGkgU2F0b3J1LA0KDQotLS0tLS0tLS0tLS0tLS0tLS0JCQkJIA0KUGVuZyBXdQ0KUGhEIGNhbmRp ZGF0ZQ0KRGVwYXJ0bWVudCBvZiBDb21wdXRlciBTY2llbmNlICYgVGVjaG5vbG9neQ0KVHNpbmdo dWEgVW5pdmVyc2l0eSwgQmVpamluZywgQ2hpbmENCg0KDQo+SGkgUGVuZywNCj4NCj4NCj4yMDEx LzQvMjAgUGVuZyBXdSA8d2VhcG9uQGNzbmV0MS5jcy50c2luZ2h1YS5lZHUuY24+Og0KPj4gSGkg U2F0b3J1LA0KPj4NCj4+IEFib3V0IHRoZSBpdGVtIERTLUxpdGUgd2l0aCBubyBOQVQgb3IgTkFU IG9uIHRoZSBCNCwgaXQncyBEUy1saXRlIHdpdGhvdXQgQ0dOIG9uIHRoZSBBRlRSLg0KPj4gR2Vu ZXJhbGx5IEI0IHdpbGwgZ2V0IHB1YmxpYyBJUHY0IGFkZHJlc3MgYWxsb2NhdGVkIGZyb20gdGhl IElTUCBhbmQgdXNlIGl0IGZvciBJUHY0IGFjY2Vzcy4gVGhlIEFGVFIgd2lsbCBvbmx5IG5lZWQg dG8gbWFpbnRhaW4gSVB2Ni1JUHY0IGFkZHJlc3MgbWFwcGluZyB3aXRob3V0IHBvcnQgaW5mb3Jt YXRpb24uDQo+PiBEb2luZyB0aGlzIHRoZSBhZGRyZXNzaW5nIGFuZCByb3V0aW5nIGJldHdlZW4g SVB2NiBhbmQgSVB2NCBhcmUgc3RpbGwgaW5kZXBlbmRlbnQuIEl0J3MgYSBwcm90b2NvbCBleHRl bnN0aW9uIHRvIERTLWxpdGUsIGFuZCBpdCBjYW4gd29yayBhbG9uZyB3aXRoIERTLWxpdGUuDQo+ DQo+U28geW91IG1lYW4gdGhhdCB5b3VyIDRvdmVyNiBkb2N1bWVudCBpcyBhIEI0TkFUIGRvY3Vt ZW50LCBpc24ndCBpdD8NClllcy4gDQo+QnV0IEkgZG9uJ3QgZmluZCBhbnkgQjROQVQgZGVmaW5p dGlvbiBpbiB5b3VyIGRvY3VtZW50IHRob3VnaC4NCj5PbiB0aGUgb3RoZXIgaGFuZCwgSSB1bmRl cnN0YW5kIHRoYXQgeW91IHByb3Bvc2UgYW5vdGhlciA0b3ZlcjYNCj5kZXBsb3ltZW50IG1vZGVs LCB3aGljaCB5b3UgZG9uJ3QgbmVlZCB0byB1c2UgZHMtbGl0ZSB0ZXJtaW5vbG9neS4gWW91DQo+ YWxyZWFkeSBkZWZpbmUgNG92ZXI2IGluaXRpYXRvciBhbmQgY29uY2VudHJhdG9yLCBldGMuLCBT byBJIHRoaW5rDQo+dGhhdCB1c2luZyAiQjROQVQiIG1ha2VzIGNvbmZ1c2lvbi4NCkxpa2UgSSBz YWlkLCB0aGUgbmFtZXMgaGF2ZW4ndCBtYXRjaGVkIHlldC4gVGhhdCdzIHRoZSBjb25mdXNpb24u IElNSE8sIEI0TkFUIGlzbid0IGEgdmVyeSBmb3JtYWwgbmFtZSwgcmlnaHQ/IFRoZSBvcmlnaW5h bCB3b3JkcyBhcmUgIkRTLUxpdGUgd2l0aCBubyBOQVQgb3IgTkFUIG9uIHRoZSBCNCBlbGVtZW50 Iiwgd2hpY2ggY292ZXJzIHRoZSBmdWxsIHNlbWFudGljIGFuZCBob3dldmVyIGlzIHF1aXRlIGxv bmcuLi5UaGF0J3MgcGFydCBvZiB0aGUgcmVhc29uIHdlIHVzZSBhIG5ldyBuYW1lLiBJZiB5b3Ug aGF2ZSBhbnkgc3VnZ2VzdGlvbnMgb24gdGhlIG5hbWUsIGl0J2xsIGJlIGdvb2QuDQpBYm91dCA0 b3ZlcjYgVEkgYW5kIFRDLCB3ZSB1c2UgdGhlIHRlcm1pbm9sb2d5IGJlY2F1c2UgdGhlaXIgZnVu Y3Rpb25zIGFyZSBhIGxpdHRsZSBkaWZmZXJlbnQgdG8gb3JpZ2luYWwgRFMtbGl0ZSwgYW5kIHRo ZXJlJ3JlIGNhc2VzIHRoYXQgb25lIHdvdWxkIGxpa2UgdG8gZGVwbG95IDRvdmVyNiBpbmRlcGVu ZGVudGx5IHdpdGggbm8gRFMtTElURSBhZGRyZXNzIHNoYXJpbmcuIEFueWhvdyBpdCdzIGEgZGV0 YWlsZWQgaXNzdWUuDQo+DQo+Pg0KPj4gV2UndmUgYWxyZWFkeSBwcmVzZW50IGl0IGluIGxhc3Qg dGhyZWUgSUVURiBtZWV0aW5ncy4gU2VlIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWN1aS1zb2Z0d2lyZS1ob3N0LTRvdmVyNi0wNC4gVGhlIGdlbmVyYWwgaWRlYSBpcyBvdXQgdGhl cmUsIGFuZCB0aGUgb25seSBjb25mdXNpb24gaXMgdGhhdCB0aGUgbWVjaGFuaXNtIG5hbWUgaGFz bid0IG1hdGNoZWQgeWV0Lg0KPj4gV2UnbGwgY29tZSB1cCB3aXRoIGEgbmV3IHZlcnNpb24gd2l0 aCBldm9sdmVtZW50IGJlZm9yZSBuZXh0IElFVEYgZm9yIFdHIGFkb3B0aW9uLg0KPg0KPkknbSBj b25mdXNlZCBiZWNhdXNlIGN1cnJlbnQgZHMtbGl0ZSBkb2N1bWVudCBjbGVhcmx5IGRlZmluZSBh cyBmb2xsb3cNCj5pbiBzZWN0aW9uIDQuMjoNCj4NCj4gICJBIERTLUxpdGUgQ1BFIFNIT1VMRCBO T1Qgb3BlcmF0ZSBhIE5BVCBmdW5jdGlvbiBiZXR3ZWVuIGFuIGludGVybmFsDQo+ICAgaW50ZXJm YWNlIGFuZCBhIEI0IGludGVyZmFjZSwgYXMgdGhlIE5BVCBmdW5jdGlvbiB3aWxsIGJlIHBlcmZv cm1lZA0KPiAgIGJ5IHRoZSBBRlRSIGluIHRoZSBzZXJ2aWNlIHByb3ZpZGVyJ3MgbmV0d29yay4g IFRoYXQgd2lsbCBhdm9pZA0KPiAgIGFjY2lkZW50YWxseSBvcGVyYXRpbmcgaW4gYSBkb3VibGUg TkFUIGVudmlyb25tZW50LiINCj4NCj5BbmQgc2VjdGlvbiA1LjEgZGVzY3JpYmVzIGFzIGZvbGxv dzoNCj4NCj4gICI1LiAgQjQgZWxlbWVudA0KPiAgIDUuMS4gIERlZmluaXRpb24NCj4NCj4gICBU aGUgQjQgZWxlbWVudCBpcyBhIGZ1bmN0aW9uIGltcGxlbWVudGVkIG9uIGEgZHVhbC1zdGFjayBj YXBhYmxlDQo+ICAgbm9kZSwgZWl0aGVyIGEgZGlyZWN0bHkgY29ubmVjdGVkIGRldmljZSBvciBh IENQRSwgdGhhdCBjcmVhdGVzIGENCj4gICB0dW5uZWwgdG8gYW4gQUZUUi4iDQo+DQo+VGhlc2Ug bWVhbiB0aGF0IEI0IGlzIGVxdWFsIHRvIENQRSwgc28gdGhhdCBCNCBjYW5ub3QgaGFzIE5BVCBm dW5jdGlvbi4NCj5JcyB0aGF0IGNvcnJlY3Q/DQpXZWxsLCB0aGF0J3Mgd2h5IGl0J3MgYW4gk2V4 dGVuc2lvbpQgdG8gRFMtbGl0ZSwgSSBkb24ndCBzZWUgcHJvYmxlbXMgaGVyZS4NCkJUVywgaW4g cmVhbCB3b3JkLCBDUEVzIGxpa2UgaG9tZSBnYXRld2F5IHVzdWFsbHkgc3VwcG9ydCBOQVQgZnVu Y3Rpb25zIGFscmVhZHkuDQoNCg== From satoru.matsushima@gmail.com Wed Apr 20 02:23:31 2011 Return-Path: X-Original-To: softwires@ietfc.amsl.com Delivered-To: softwires@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AA115E06A9; Wed, 20 Apr 2011 02:23:31 -0700 (PDT) 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.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKUuz-Y14LjN; Wed, 20 Apr 2011 02:23:31 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id E4AC4E0689; Wed, 20 Apr 2011 02:23:30 -0700 (PDT) Received: by iwn39 with SMTP id 39so575681iwn.31 for ; Wed, 20 Apr 2011 02:23:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AIGLzymmn5zC3hC39v00fKTy5342912sT6Qb+Uxff80=; b=eVtgZ/8iCFuQh/8BNTGANJtmhHjUrid60K4JZi9IGIJkVrcdZIysqfdDXw6I5coEMc 40Id+B+HbRCuEyU872gkawSAyJO5LGnw2NVr85tlRSQy6Ntcyyht7LvWm8bTumtVLEk3 n1mNUZKky+1QmNLQIrKkvc6feEtN2h6MD1x2Q= 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=pKQ+ztq4FvT7CcUadLio3t0jzR/+o55yNVfHgHaixjBnm4Zc2rmins1JM/+p2D6lMH 4KS+LFOwE5g0H2e8QPQTvYjxuAcRGJyufXQ2cfB/pq6Uffbk3KHMqlxEqoKuosY9h5/0 2uYKBeDJYE225f5Rx+UFhiML8GCLXFuXGnpwY= MIME-Version: 1.0 Received: by 10.231.194.156 with SMTP id dy28mr1741313ibb.48.1303291409139; Wed, 20 Apr 2011 02:23:29 -0700 (PDT) Received: by 10.231.32.129 with HTTP; Wed, 20 Apr 2011 02:23:29 -0700 (PDT) In-Reply-To: <201104201714271360705@csnet1.cs.tsinghua.edu.cn> References: <20110419163654.09944E0764@ietfc.amsl.com> <201104201455303763221@csnet1.cs.tsinghua.edu.cn> <201104201714271360705@csnet1.cs.tsinghua.edu.cn> Date: Wed, 20 Apr 2011 18:23:29 +0900 Message-ID: From: Satoru Matsushima To: Peng Wu Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: softwires , cuiyong , iesg Subject: Re: [Softwires] WG Review: Recharter of Softwires (softwire) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 09:23:31 -0000 Hi Peng, > Like I said, the names haven't matched yet. That's the confusion. IMHO, B= 4NAT isn't a very formal name, > right? The original words are "DS-Lite with no NAT or NAT on the B4 eleme= nt", which covers the full > semantic and however is quite long...That's part of the reason we use a n= ew name. If you have any > suggestions on the name, it'll be good. As in a recharter discussion, this is a problem. At least the charter should clearly explain what each charter item is, and also what wg will do. My point is that using words which make clear understand for all people is quite important. So I think that using the word of "B4NAT" as a next charter item is not appropriate. Best regards, --satoru 2011/4/20 Peng Wu : > Hi Satoru, > > ------------------ > Peng Wu > PhD candidate > Department of Computer Science & Technology > Tsinghua University, Beijing, China > > >>Hi Peng, >> >> >>2011/4/20 Peng Wu : >>> Hi Satoru, >>> >>> About the item DS-Lite with no NAT or NAT on the B4, it's DS-lite witho= ut CGN on the AFTR. >>> Generally B4 will get public IPv4 address allocated from the ISP and us= e it for IPv4 access. The AFTR will only need to maintain IPv6-IPv4 address= mapping without port information. >>> Doing this the addressing and routing between IPv6 and IPv4 are still i= ndependent. It's a protocol extenstion to DS-lite, and it can work along wi= th DS-lite. >> >>So you mean that your 4over6 document is a B4NAT document, isn't it? > Yes. >>But I don't find any B4NAT definition in your document though. >>On the other hand, I understand that you propose another 4over6 >>deployment model, which you don't need to use ds-lite terminology. You >>already define 4over6 initiator and concentrator, etc., So I think >>that using "B4NAT" makes confusion. > Like I said, the names haven't matched yet. That's the confusion. IMHO, B= 4NAT isn't a very formal name, right? The original words are "DS-Lite with = no NAT or NAT on the B4 element", which covers the full semantic and howeve= r is quite long...That's part of the reason we use a new name. If you have = any suggestions on the name, it'll be good. > About 4over6 TI and TC, we use the terminology because their functions ar= e a little different to original DS-lite, and there're cases that one would= like to deploy 4over6 independently with no DS-LITE address sharing. Anyho= w it's a detailed issue. >> >>> >>> We've already present it in last three IETF meetings. See http://tools.= ietf.org/html/draft-cui-softwire-host-4over6-04. The general idea is out th= ere, and the only confusion is that the mechanism name hasn't matched yet. >>> We'll come up with a new version with evolvement before next IETF for W= G adoption. >> >>I'm confused because current ds-lite document clearly define as follow >>in section 4.2: >> >> =A0"A DS-Lite CPE SHOULD NOT operate a NAT function between an internal >> =A0 interface and a B4 interface, as the NAT function will be performed >> =A0 by the AFTR in the service provider's network. =A0That will avoid >> =A0 accidentally operating in a double NAT environment." >> >>And section 5.1 describes as follow: >> >> =A0"5. =A0B4 element >> =A0 5.1. =A0Definition >> >> =A0 The B4 element is a function implemented on a dual-stack capable >> =A0 node, either a directly connected device or a CPE, that creates a >> =A0 tunnel to an AFTR." >> >>These mean that B4 is equal to CPE, so that B4 cannot has NAT function. >>Is that correct? > Well, that's why it's an =93extension=94 to DS-lite, I don't see problems= here. > BTW, in real word, CPEs like home gateway usually support NAT functions a= lready. > > From mark@townsley.net Wed Apr 20 11:17:08 2011 Return-Path: X-Original-To: softwires@ietfc.amsl.com Delivered-To: softwires@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8BDE0E06A6 for ; Wed, 20 Apr 2011 11:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3So0kGGyoVV for ; Wed, 20 Apr 2011 11:17:07 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id B5214E067D for ; Wed, 20 Apr 2011 11:17:07 -0700 (PDT) Received: by wwa36 with SMTP id 36so826412wwa.13 for ; Wed, 20 Apr 2011 11:17:07 -0700 (PDT) Received: by 10.227.0.152 with SMTP id 24mr7806450wbb.126.1303323426932; Wed, 20 Apr 2011 11:17:06 -0700 (PDT) Received: from [192.168.1.85] (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id b20sm722253wbb.50.2011.04.20.11.17.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Apr 2011 11:17:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Wed, 20 Apr 2011 18:17:01 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5C4F8A4C-A7AE-4E6E-960B-650DED19982F@townsley.net> To: Alain Durand X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org" Subject: Re: [Softwires] sharing restricted addresses by hosts in 4rd (draft-despres-intarea-4rd-01) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 18:17:08 -0000 On Apr 19, 2011, at 4:06 PM, Alain Durand wrote: >=20 > On Apr 12, 2011, at 4:03 PM, Mark Townsley wrote: >=20 >>=20 >> Hello Dmitry, >>=20 >> My view is that 4rd is most easily understood if and only if it = connects to a CE function that is performing NAPT. The CE function may = be in what is traditionally considered a host, or in what is clearly a = router. >>=20 >> More specifically, a device that is forwarding packets from one = interface (virtual or otherwise) to another through a NAPT that has one = interface with IPv6 configured (via DHCPv6 or otherwise) as performing = 4rd (which enables dual-stack via a port-restricted IPv4 address for the = NAPT using IPv6 as the transport) then you a have a 4rd CE. That could = be a "host" in that it is a Windows PC with internet connection sharing = for IPv4 turned on and hence forwards packets between interfaces with a = NAPT due to the IPv4-enabled interface created when 4rd is configured.=20= >>=20 >> I would avoid anything that requires the host forwarding table to be = altered to accommodate 4rd. Instead, the NAPT function that is already = present in a small router or host configured to look like a router is = modified to use a set of ports that it is allowed to use when 4rd is = enabled.=20 >=20 >=20 > Mark: >=20 > How would an app running on a 4rd CPE communicate in IPv4 to another = app running on another 4rd CPE? First, by definition any 4rd CPE has IPv6. So, if your application works = with IPv6. 4rd-to-4rd is as easy as knowing two IPv6 addresses and not = having a simple-minded firewall between the two blocking traffic. For IPv4, in the model I describe above, all applications are sitting = behind the NAPT within the CPE bound to the 4rd tunnel. End-to-end looks = just about as desperate and ugly as it does today between any series of = NAPTs and firewalls. Skype will make its way through, I suspect with no = modifications.=20 - Mark >=20 > - Alain. >=20 From mark@townsley.net Wed Apr 20 11:58:39 2011 Return-Path: X-Original-To: softwires@ietfc.amsl.com Delivered-To: softwires@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7E55CE067D; Wed, 20 Apr 2011 11:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.179 X-Spam-Level: X-Spam-Status: No, score=-3.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQiztmrblNFu; Wed, 20 Apr 2011 11:58:38 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 067F9E066B; Wed, 20 Apr 2011 11:58:37 -0700 (PDT) Received: by wyb29 with SMTP id 29so975486wyb.31 for ; Wed, 20 Apr 2011 11:58:37 -0700 (PDT) Received: by 10.216.240.3 with SMTP id d3mr1143413wer.51.1303325917363; Wed, 20 Apr 2011 11:58:37 -0700 (PDT) Received: from [192.168.1.85] (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id u9sm741454wbg.51.2011.04.20.11.58.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Apr 2011 11:58:36 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <20110419163654.09944E0764@ietfc.amsl.com> Date: Wed, 20 Apr 2011 18:58:28 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <8FC9A55E-E12A-4191-83A3-5D40A9538CA5@townsley.net> References: <20110419163654.09944E0764@ietfc.amsl.com> To: iesg@ietf.org X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org, cuiyong@tsinghua.edu.cn, IETF Announcement list Subject: Re: [Softwires] WG Review: Recharter of Softwires (softwire) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 18:58:39 -0000 On Apr 19, 2011, at 4:36 PM, IESG Secretary wrote: > A modified charter has been submitted for the Softwires (softwire) = working > group in the Internet Area of the IETF. The IESG has not made any > determination as yet. The modified charter is provided below for > informational purposes only. Please send your comments to the IESG > mailing list (iesg@ietf.org) by Tuesday, April 26, 2011. >=20 >=20 > Softwires (softwire) > **DRAFT 2011-04-14** (v03) > -------------------- > Current Status: Active >=20 > Chairs: > Alain Durand > Yong Cui >=20 > Internet Area Directors: > Ralph Droms > Jari Arkko >=20 > Internet Area Advisor: > Ralph Droms >=20 > Mailing Lists: > General Discussion: softwires@ietf.org > To Subscribe: softwires-request@ietf.org > Archive: =20 > http://www.ietf.org/mail-archive/web/softwires/current/maillist.html >=20 > Description of Working Group: >=20 > The Softwires Working Group is specifying the standardization of > discovery, control and encapsulation methods for connecting IPv4 > networks across IPv6 networks and IPv6 networks across IPv4 networks > in a way that will encourage multiple, inter-operable > implementations. >=20 > For various reasons, native IPv4 and/or IPv6 transport may not be > available in all cases, and there is a need to tunnel IPv4 in IPv6 > or IPv6 in IPv4 to cross a part of the network which is not IPv4 or > IPv6 capable. The Softwire Problem Statement, RFC 4925, identifies > two distinct topological scenarios that the WG will provide > solutions for: "Hubs and Spokes" and "Mesh." In the former case, > hosts or "stub" networks are attached via individual, > point-to-point, IPv4 over IPv6 or IPv6 over IPv4 softwires to a > centralized Softwire Concentrator. In the latter case (Mesh), > network islands of one Address Family (IPv4 or IPv6) are connected > over a network of another Address Family via point to multi-point > softwires among Address family Border Routers (AFBRs). >=20 > The WG will reuse existing technologies as much as possible and only > when necessary, create additional protocol building blocks. >=20 > For generality, all base Softwires encapsulation mechanisms should > support all combinations of IP versions over one other (IPv4 over > IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). IPv4 to IPv6 > translation mechanisms (NAT-PT), new addressing schemes, and block > address assignments are out of scope. DHCP options developed in this > working group will be reviewed jointly with the DHC WG. RADIUS > attributes developed in this working group will be reviewed jointly > with the RADEXT WG. The MIB Doctors directorate will be asked to > review any MIB modules developed in the SOFTWIRE working group. BGP > and other routing and signaling protocols developed in this group > will be reviewed jointly with the proper working groups and other > workings that may take interest (e.g. IDR, L3VPN, PIM, LDP, SAAG, > etc). >=20 > The specific work areas for this working group are: >=20 > 1. Developments for Mesh softwires topology; the Mesh topology work > will be reviewed in the l3vpn and idr WGs > - multicast > - MIB module >=20 > 2. Developments for 6rd: > - multicast > - operational specification > - RADIUS option for 6rd server > - MIB module >=20 No chance to do a detailed review as I am peeking in while on = vacation.... But, I'd like to make two comments #3 and #4 both seem to be part of the "legacy IPv4 carried over IPv6" = problem space. > 3. Developments for Dual-Stack Lite (DS-Lite): > - multicast > - operational specification > - RADIUS option for AFTR > - proxy extensions; GI-DS-Lite; DS-Lite with no NAT or NAT on the > B4 element > - MIB module >=20 > 4. Developments for stateless legacy IPv4 carried over IPv6 > - develop a solution motivation document to be published as an > RFC > - develop a protocol specification response to the solution > motivation > document; this work item will not be taken through WG last call > until the solution motivation document has been published s/published/approved for publication by the IESG.=20 - Mark >=20 > 5. Finalize discovery and configuration mechanisms for a gateway to > use DS-Lite or 6rd; these discovery and configuration mechanisms > must take into a account other operating environments such as > dual-stack and tunneling mechanisms not defined by the softwire > WG. Development of new mechanisms will involve the dhc and/or > v6ops WGs as appropriate >=20 > Other work items would require WG approval and rechartering. >=20 > Goals and Milestones: > Apr 2011 Submit DS-lite RADIUS option for Proposed Standard > Apr 2011 Adopt DS-lite operational document as WG document > Jul 2011 Submit 6rd RADIUS option for Proposed Standard > Jul 2011 Submit GI DS-lite for Proposed Standard > Jul 2011 Adopt B4NAT as WG document > Aug 2011 Adopt 6rd operational document as WG document > Aug 2011 Adopt Multicast extensions document as WG document > Aug 2011 Submit DS-lite operational document for Informational > Sep 2011 Submit B4NAT for Informational > Nov 2011 Submit Multicast extensions document for Informational > Nov 2011 Submit 6rd operational document for Informational > Nov 2011 Adopt 6rd MIB module as WG document > Nov 2011 Adopt DS-lite MIB module as WG document > Nov 2011 Adopt Mesh topology MIB module as WG document > Nov 2012 Submit 6rd MIB module for Proposed Standard > Nov 2012 Submit DS-lite MIB module for Proposed Standard > Nov 2012 Submit Mesh topology MIB module for Proposed Standard >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From yiu_lee@cable.comcast.com Wed Apr 20 12:13:51 2011 Return-Path: X-Original-To: softwires@ietfc.amsl.com Delivered-To: softwires@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8DC89E06F4 for ; Wed, 20 Apr 2011 12:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.985 X-Spam-Level: X-Spam-Status: No, score=-99.985 tagged_above=-999 required=5 tests=[AWL=1.750, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HB941WOlpjKy for ; Wed, 20 Apr 2011 12:13:51 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfc.amsl.com (Postfix) with ESMTP id C9D83E06D9 for ; Wed, 20 Apr 2011 12:13:50 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.34889174; Wed, 20 Apr 2011 13:17:10 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0289.001; Wed, 20 Apr 2011 15:13:46 -0400 From: "Lee, Yiu" To: Mark Townsley , Alain Durand Thread-Topic: [Softwires] sharing restricted addresses by hosts in 4rd (draft-despres-intarea-4rd-01) Thread-Index: AQHL/48RFG4fwT8PBkCPWWJjcLnnYQ== Date: Wed, 20 Apr 2011 19:13:44 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [68.82.28.202] Content-Type: text/plain; charset="us-ascii" Content-ID: <4320EF4BD83FFD4FA6E12D80AC11F601@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] sharing restricted addresses by hosts in 4rd (draft-despres-intarea-4rd-01) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 19:13:51 -0000 I agree that any p2p application using relay would work on 4rd. For two 4rds using the same v4 address but different port-ranges, I guess the two 4rd devices would communicate directly w/o BR (Section 4.5.1) because 4rd CPE has mesh connectivity (over IPv6) to all other 4rds using the same 4rd prefix. /Yiu On 4/20/11 2:17 PM, "Mark Townsley" wrote: >For IPv4, in the model I describe above, all applications are sitting >behind the NAPT within the CPE bound to the 4rd tunnel. End-to-end looks >just about as desperate and ugly as it does today between any series of >NAPTs and firewalls. Skype will make its way through, I suspect with no >modifications. From tetsuya@ipinfusion.com Wed Apr 20 16:21:35 2011 Return-Path: X-Original-To: softwires@ietfc.amsl.com Delivered-To: softwires@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 77AD9E0724 for ; Wed, 20 Apr 2011 16:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrMs0AuL6pss for ; Wed, 20 Apr 2011 16:21:34 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfc.amsl.com (Postfix) with ESMTP id 6A356E0721 for ; Wed, 20 Apr 2011 16:21:34 -0700 (PDT) Received: by pwi5 with SMTP id 5so808157pwi.31 for ; Wed, 20 Apr 2011 16:21:33 -0700 (PDT) Received: by 10.68.29.234 with SMTP id n10mr10687759pbh.94.1303341693805; Wed, 20 Apr 2011 16:21:33 -0700 (PDT) Received: from [10.70.2.84] ([12.248.239.142]) by mx.google.com with ESMTPS id p7sm904140pbi.58.2011.04.20.16.21.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Apr 2011 16:21:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tetsuya Murakami In-Reply-To: Date: Wed, 20 Apr 2011 16:21:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <89D33FFC-B357-4F5A-8119-F33D95904E29@ipinfusion.com> References: <5C4F8A4C-A7AE-4E6E-960B-650DED19982F@townsley.net> To: Alain Durand X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org" Subject: Re: [Softwires] sharing restricted addresses by hosts in 4rd (draft-despres-intarea-4rd-01) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 23:21:35 -0000 Alain, On 2011/04/19, at 9:06, Alain Durand wrote: >=20 > On Apr 12, 2011, at 4:03 PM, Mark Townsley wrote: >=20 >>=20 >> Hello Dmitry, >>=20 >> My view is that 4rd is most easily understood if and only if it = connects to a CE function that is performing NAPT. The CE function may = be in what is traditionally considered a host, or in what is clearly a = router. >>=20 >> More specifically, a device that is forwarding packets from one = interface (virtual or otherwise) to another through a NAPT that has one = interface with IPv6 configured (via DHCPv6 or otherwise) as performing = 4rd (which enables dual-stack via a port-restricted IPv4 address for the = NAPT using IPv6 as the transport) then you a have a 4rd CE. That could = be a "host" in that it is a Windows PC with internet connection sharing = for IPv4 turned on and hence forwards packets between interfaces with a = NAPT due to the IPv4-enabled interface created when 4rd is configured.=20= >>=20 >> I would avoid anything that requires the host forwarding table to be = altered to accommodate 4rd. Instead, the NAPT function that is already = present in a small router or host configured to look like a router is = modified to use a set of ports that it is allowed to use when 4rd is = enabled.=20 >=20 >=20 > Mark: >=20 > How would an app running on a 4rd CPE communicate in IPv4 to another = app running on another 4rd CPE? IPv4 address generated from assigned IPv6 address can be used in only = 4rd CPE function. For example, this IPv4 address is used by only NAT44. = So, the application running on 4rd CPE box does not use this IPv4 = address generated from IPv6 address. If the application supports IPv6, the application can use the assigned = IPv6 address because each 4rd CPE has a unique IPv6 address. Also, if a = private IPv4 address is assigned to IPv4 interface on 4rd CPE box, the = application can use this private IPv4 address. Thanks, Tetsuya Murakami= From yong@csnet1.cs.tsinghua.edu.cn Wed Apr 20 18:23:20 2011 Return-Path: X-Original-To: softwires@ietfc.amsl.com Delivered-To: softwires@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 68A86E080B; Wed, 20 Apr 2011 18:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.105 X-Spam-Level: X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IoAa7iU6z89; Wed, 20 Apr 2011 18:23:19 -0700 (PDT) Received: from mail.jzland.com (unknown [211.151.89.50]) by ietfc.amsl.com (Postfix) with ESMTP id 2E409E0700; Wed, 20 Apr 2011 18:22:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.jzland.com (EMOS V1.4 (Postfix)) with ESMTP id 9F29B30B0BFA; Thu, 21 Apr 2011 09:22:12 +0800 (CST) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Thu Apr 21 09:22:12 2011 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 1,4daf86c439731684466136 X-DSPAM-Factors: 27, scope+DHCP, 0.01000, across+IPv4, 0.01000, document+Jul, 0.01000, Mesh+topology, 0.01000, Mesh+topology, 0.01000, IPv4+networks, 0.01000, should+>, 0.01000, a+need, 0.01000, 6rd+>, 0.01000, made, 0.01000, Area+Directors, 0.01000, latter+case, 0.01000, as+yet, 0.01000, IESG, 0.01000, IESG, 0.01000, assignments, 0.01000, proper, 0.01000, IDR+L3VPN, 0.01000, RADIUS+option, 0.01000, RADIUS+option, 0.01000, Subject*Review+Recharter, 0.01000, provide, 0.01000, Date*21+Apr, 0.01000, For+generality, 0.01000, the+softwire, 0.01000, methods, 0.01000, an, 0.01000 X-Virus-Scanned: amavisd-new at jzland.com Received: from mail.jzland.com ([127.0.0.1]) by localhost (mail.jzland.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLJ9pxcQ4Afb; Thu, 21 Apr 2011 09:22:11 +0800 (CST) Received: from [116.52.61.44] (unknown [116.52.61.44]) by mail.jzland.com (EMOS V1.4 (Postfix)) with ESMTPA id 339D730B0BFC; Thu, 21 Apr 2011 09:22:11 +0800 (CST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Thu, 21 Apr 2011 09:22:10 +0800 From: Yong Cui To: , IETF Announcement list Message-ID: Thread-Topic: [Softwires] WG Review: Recharter of Softwires (softwire) In-Reply-To: <20110419163654.09944E0764@ietfc.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] WG Review: Recharter of Softwires (softwire) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 01:23:20 -0000 A couple of comments below. -----Original Message----- From: IESG Secretary Reply-To: Date: Tue, 19 Apr 2011 09:36:54 -0700 (PDT) To: IETF Announcement list Cc: , Yong Cui Subject: [Softwires] WG Review: Recharter of Softwires (softwire) >A modified charter has been submitted for the Softwires (softwire) working >group in the Internet Area of the IETF. The IESG has not made any >determination as yet. The modified charter is provided below for >informational purposes only. Please send your comments to the IESG >mailing list (iesg@ietf.org) by Tuesday, April 26, 2011. > > >Softwires (softwire) >**DRAFT 2011-04-14** (v03) >-------------------- >Current Status: Active > > Chairs: > Alain Durand > Yong Cui > > Internet Area Directors: > Ralph Droms > Jari Arkko > > Internet Area Advisor: > Ralph Droms > > Mailing Lists: > General Discussion: softwires@ietf.org > To Subscribe: softwires-request@ietf.org > Archive: >http://www.ietf.org/mail-archive/web/softwires/current/maillist.html > >Description of Working Group: > > The Softwires Working Group is specifying the standardization of > discovery, control and encapsulation methods for connecting IPv4 > networks across IPv6 networks and IPv6 networks across IPv4 networks > in a way that will encourage multiple, inter-operable > implementations. > > For various reasons, native IPv4 and/or IPv6 transport may not be > available in all cases, and there is a need to tunnel IPv4 in IPv6 > or IPv6 in IPv4 to cross a part of the network which is not IPv4 or > IPv6 capable. The Softwire Problem Statement, RFC 4925, identifies > two distinct topological scenarios that the WG will provide > solutions for: "Hubs and Spokes" and "Mesh." In the former case, > hosts or "stub" networks are attached via individual, > point-to-point, IPv4 over IPv6 or IPv6 over IPv4 softwires to a > centralized Softwire Concentrator. In the latter case (Mesh), > network islands of one Address Family (IPv4 or IPv6) are connected > over a network of another Address Family via point to multi-point > softwires among Address family Border Routers (AFBRs). > > The WG will reuse existing technologies as much as possible and only > when necessary, create additional protocol building blocks. > > For generality, all base Softwires encapsulation mechanisms should > support all combinations of IP versions over one other (IPv4 over > IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). IPv4 to IPv6 > translation mechanisms (NAT-PT), new addressing schemes, and block > address assignments are out of scope. DHCP options developed in this > working group will be reviewed jointly with the DHC WG. RADIUS > attributes developed in this working group will be reviewed jointly > with the RADEXT WG. The MIB Doctors directorate will be asked to > review any MIB modules developed in the SOFTWIRE working group. BGP > and other routing and signaling protocols developed in this group > will be reviewed jointly with the proper working groups and other > workings that may take interest (e.g. IDR, L3VPN, PIM, LDP, SAAG, > etc). > > The specific work areas for this working group are: > > 1. Developments for Mesh softwires topology; the Mesh topology work > will be reviewed in the l3vpn and idr WGs > - multicast > - MIB module > > 2. Developments for 6rd: > - multicast > - operational specification > - RADIUS option for 6rd server > - MIB module > > 3. Developments for Dual-Stack Lite (DS-Lite): > - multicast > - operational specification > - RADIUS option for AFTR > - proxy extensions; GI-DS-Lite; DS-Lite with no NAT or NAT on the > B4 element Change "DS-Lite with no NAT or NAT on the B4 element" to "No NAT on AFTR" > - MIB module > > 4. Developments for stateless legacy IPv4 carried over IPv6 > - develop a solution motivation document to be published as an > RFC > - develop a protocol specification response to the solution >motivation > document; this work item will not be taken through WG last call > until the solution motivation document has been published > > 5. Finalize discovery and configuration mechanisms for a gateway to > use DS-Lite or 6rd; these discovery and configuration mechanisms > must take into a account other operating environments such as > dual-stack and tunneling mechanisms not defined by the softwire > WG. Development of new mechanisms will involve the dhc and/or > v6ops WGs as appropriate > >Other work items would require WG approval and rechartering. > >Goals and Milestones: >Apr 2011 Submit DS-lite RADIUS option for Proposed Standard >Apr 2011 Adopt DS-lite operational document as WG document >Jul 2011 Submit 6rd RADIUS option for Proposed Standard >Jul 2011 Submit GI DS-lite for Proposed Standard >Jul 2011 Adopt B4NAT as WG document Replace the item on B4NAT to the following two lines: Jul 2011 Adopt DS-Lite without NAT as WG document Jul 2011 Adopt DHCPv4 over tunnel as WG document >Aug 2011 Adopt 6rd operational document as WG document >Aug 2011 Adopt Multicast extensions document as WG document >Aug 2011 Submit DS-lite operational document for Informational >Sep 2011 Submit B4NAT for Informational Again, replace the item on B4NAT to the following two lines: Sep 2011 Submit DS-Lite without NAT for Informational Sep 2011 Adopt DHCPv4 over tunnel for Proposed Standard Thanks, Yong >Nov 2011 Submit Multicast extensions document for Informational >Nov 2011 Submit 6rd operational document for Informational >Nov 2011 Adopt 6rd MIB module as WG document >Nov 2011 Adopt DS-lite MIB module as WG document >Nov 2011 Adopt Mesh topology MIB module as WG document >Nov 2012 Submit 6rd MIB module for Proposed Standard >Nov 2012 Submit DS-lite MIB module for Proposed Standard >Nov 2012 Submit Mesh topology MIB module for Proposed Standard > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From satoru.matsushima@gmail.com Wed Apr 20 22:14:16 2011 Return-Path: X-Original-To: softwires@ietfc.amsl.com Delivered-To: softwires@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 672FAE078B for ; Wed, 20 Apr 2011 22:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Na3+BDRzjGgV for ; Wed, 20 Apr 2011 22:14:15 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id 94A6CE0791 for ; Wed, 20 Apr 2011 22:14:15 -0700 (PDT) Received: by iwn39 with SMTP id 39so1475740iwn.31 for ; Wed, 20 Apr 2011 22:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bVznluUWAi4dWpi3r7qyHc3IupQhMDHnuFyKJtW1wvo=; b=UnXsKQKBE84x2Ye/aU26+P2lBZ/Vgo/YFEynL7tKhf+w5W+p3mhiUD//1sPyzR0A51 Fd/MWPj3SGbtcDOD8SoXMRlKltMecW2dIIU8FYq74uBp+utTSgOUGbcj60vkrfDtEdyK B5KIgLx4EsW7U3VDEwH5QlGytkSwh8Az22Z0w= 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=YdZN6zUb44vZxokuYrZ9N65FOo1ys1Fl70b6DT5ekOmMHRkfzIX5hj5CTRQBDHrfPI ZXzs1fSpTXtoQQGrmAzNx826SfDdImbtwpjZf2XTtmbaDJ2ZNrcKOmaCJyVGNghc4VJZ CavA1N+rasVQXucCypPUAr4YSXLUJUmamRh+U= MIME-Version: 1.0 Received: by 10.231.194.156 with SMTP id dy28mr2500791ibb.48.1303362855139; Wed, 20 Apr 2011 22:14:15 -0700 (PDT) Received: by 10.231.32.129 with HTTP; Wed, 20 Apr 2011 22:14:15 -0700 (PDT) In-Reply-To: <89D33FFC-B357-4F5A-8119-F33D95904E29@ipinfusion.com> References: <5C4F8A4C-A7AE-4E6E-960B-650DED19982F@townsley.net> <89D33FFC-B357-4F5A-8119-F33D95904E29@ipinfusion.com> Date: Thu, 21 Apr 2011 14:14:15 +0900 Message-ID: From: Satoru Matsushima To: Tetsuya Murakami , adurand@juniper.net Content-Type: text/plain; charset=ISO-8859-1 Cc: "softwires@ietf.org" Subject: Re: [Softwires] sharing restricted addresses by hosts in 4rd (draft-despres-intarea-4rd-01) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 05:14:16 -0000 Hi Alain, Tetsuya, Just one supplement. 4rd "CPE" is equipment, which have 4rd "CE" function. Best regards, --satoru From satoru.matsushima@gmail.com Wed Apr 20 22:17:38 2011 Return-Path: X-Original-To: softwires@ietfc.amsl.com Delivered-To: softwires@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A8D49E0743 for ; Wed, 20 Apr 2011 22:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eON0gbdm9LG for ; Wed, 20 Apr 2011 22:17:38 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfc.amsl.com (Postfix) with ESMTP id ED887E0706 for ; Wed, 20 Apr 2011 22:17:37 -0700 (PDT) Received: by iye19 with SMTP id 19so1461617iye.31 for ; Wed, 20 Apr 2011 22:17:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vSVuNI/DGGYaTmoiq0p/ulC6s6NGq0mUYtpKdhRjA9A=; b=X0i2XPY3wKRgGnoqXdfbrUJSqIEQiZgrilhHogdoYonMzV2rkEpUlGlgmVXltsWWBw 4/eGYJ+JWwqH2eUPNzftM6yuRhNlyURC7jHg9fWqJ8m/G6ciXp2AZHIGhK3ZMMUieoRO PCT6YclWz+3lBnoxKG3PYIW/Axsv0YCg4/738= 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=HL9T/9/o59RjEPMxVxXliVtmIVQnzwi0IEbeBDwVIw6SfFV+PedybWY+CPzNNgm5xK v6qOxLRfU43lzuvPiJYFardXJVeFyD3ShEy5lqLwriO9wHG5uO0SbP8iSaYEgMEg7C87 nzFpfo14qCnFVdo7r0gTKNpTz9GrDSYfN2jxo= MIME-Version: 1.0 Received: by 10.231.194.156 with SMTP id dy28mr2502496ibb.48.1303363057597; Wed, 20 Apr 2011 22:17:37 -0700 (PDT) Received: by 10.231.32.129 with HTTP; Wed, 20 Apr 2011 22:17:37 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 Apr 2011 14:17:37 +0900 Message-ID: From: Satoru Matsushima To: "Lee, Yiu" Content-Type: text/plain; charset=ISO-8859-1 Cc: "softwires@ietf.org" Subject: Re: [Softwires] sharing restricted addresses by hosts in 4rd (draft-despres-intarea-4rd-01) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 05:17:38 -0000 Hi Yiu, 2011/4/21 Lee, Yiu : > I agree that any p2p application using relay would work on 4rd. > > For two 4rds using the same v4 address but different port-ranges, I guess > the two 4rd devices would communicate directly w/o BR (Section 4.5.1) > because 4rd CPE has mesh connectivity (over IPv6) to all other 4rds using > the same 4rd prefix. Correct, thanks. --satoru From adurand@juniper.net Fri Apr 22 10:24:18 2011 Return-Path: X-Original-To: softwires@ietfc.amsl.com Delivered-To: softwires@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 73D43E06A8 for ; Fri, 22 Apr 2011 10:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.464 X-Spam-Level: X-Spam-Status: No, score=-106.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHiqfRAjYfbp for ; Fri, 22 Apr 2011 10:24:17 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfc.amsl.com (Postfix) with ESMTP id 921B5E065A for ; Fri, 22 Apr 2011 10:24:17 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTbG5vgF4ku78THFZJVTV6HDxRy0gqAUr@postini.com; Fri, 22 Apr 2011 10:24:17 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 22 Apr 2011 10:20:14 -0700 From: Alain Durand To: Satoru Matsushima Date: Fri, 22 Apr 2011 10:20:12 -0700 Thread-Topic: [Softwires] sharing restricted addresses by hosts in 4rd (draft-despres-intarea-4rd-01) Thread-Index: AcwBEYqTJu+gjSMLQgiYCzgUNrCc9A== 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 Cc: "softwires@ietf.org" Subject: Re: [Softwires] sharing restricted addresses by hosts in 4rd (draft-despres-intarea-4rd-01) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 17:24:18 -0000 On Apr 21, 2011, at 1:17 AM, Satoru Matsushima wrote: > Hi Yiu, >=20 > 2011/4/21 Lee, Yiu : >> I agree that any p2p application using relay would work on 4rd. >>=20 >> For two 4rds using the same v4 address but different port-ranges, I gues= s >> the two 4rd devices would communicate directly w/o BR (Section 4.5.1) >> because 4rd CPE has mesh connectivity (over IPv6) to all other 4rds usin= g >> the same 4rd prefix. >=20 > Correct, thanks. >=20 > --satoru How would you accomplish that in IPv4 without changing the IPv4 forwarding = rules? - Alain.= From tetsuya@ipinfusion.com Fri Apr 22 14:47:43 2011 Return-Path: X-Original-To: softwires@ietfc.amsl.com Delivered-To: softwires@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F2632E0679 for ; Fri, 22 Apr 2011 14:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYHYtRWcGGi5 for ; Fri, 22 Apr 2011 14:47:42 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfc.amsl.com (Postfix) with ESMTP id B4D56E0613 for ; Fri, 22 Apr 2011 14:47:42 -0700 (PDT) Received: by pvh1 with SMTP id 1so621007pvh.31 for ; Fri, 22 Apr 2011 14:47:42 -0700 (PDT) Received: by 10.68.24.201 with SMTP id w9mr2283132pbf.117.1303508862008; Fri, 22 Apr 2011 14:47:42 -0700 (PDT) Received: from [10.70.2.119] ([12.248.239.142]) by mx.google.com with ESMTPS id o4sm1363111pbl.98.2011.04.22.14.47.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Apr 2011 14:47:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tetsuya Murakami In-Reply-To: Date: Fri, 22 Apr 2011 14:47:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <41E0CA10-D8C2-40A8-8D63-F502096CAA39@ipinfusion.com> References: To: Alain Durand X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org" Subject: Re: [Softwires] sharing restricted addresses by hosts in 4rd (draft-despres-intarea-4rd-01) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 21:47:44 -0000 Hi Alain, On 2011/04/22, at 10:20, Alain Durand wrote: >=20 > On Apr 21, 2011, at 1:17 AM, Satoru Matsushima wrote: >=20 >> Hi Yiu, >>=20 >> 2011/4/21 Lee, Yiu : >>> I agree that any p2p application using relay would work on 4rd. >>>=20 >>> For two 4rds using the same v4 address but different port-ranges, I = guess >>> the two 4rd devices would communicate directly w/o BR (Section = 4.5.1) >>> because 4rd CPE has mesh connectivity (over IPv6) to all other 4rds = using >>> the same 4rd prefix. >>=20 >> Correct, thanks. >>=20 >> --satoru >=20 >=20 > How would you accomplish that in IPv4 without changing the IPv4 = forwarding rules? As I mentioned before, the shared IPv4 address is used for only 4rd CE = function which is implemented in 4rd CPE box. This shared IPv4 address = can be used in only NAT44. For this, this shared IPv4 address does not = need to be assigned to any physical interfaces on 4rd CPE box. Any = applications running behind 4rd CPE box use a private IPv4 address and = then 4rd CE function in 4rd CPE box does NAT44 for the packets generated = by these applications. After that, all communications can be done by = using IPv6 between 4rd CPE boxes. So, I don't think IPv4 forwarding = rules does not need to be changed. Thanks, Tetsuya Murakami= From matsuhira@jp.fujitsu.com Sun Apr 24 20:03:39 2011 Return-Path: X-Original-To: softwires@ietfc.amsl.com Delivered-To: softwires@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8B7C7E0694; Sun, 24 Apr 2011 20:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.79 X-Spam-Level: X-Spam-Status: No, score=-101.79 tagged_above=-999 required=5 tests=[AWL=1.700, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2GO9XUmfO0d; Sun, 24 Apr 2011 20:03:38 -0700 (PDT) Received: from fgwmail5.fujitsu.co.jp (fgwmail5.fujitsu.co.jp [192.51.44.35]) by ietfc.amsl.com (Postfix) with ESMTP id 1B069E0689; Sun, 24 Apr 2011 20:03:37 -0700 (PDT) Received: from m1.gw.fujitsu.co.jp (unknown [10.0.50.71]) by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id 28D403EE0AE; Mon, 25 Apr 2011 12:03:35 +0900 (JST) Received: from smail (m1 [127.0.0.1]) by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 0BE1645DE5A; Mon, 25 Apr 2011 12:03:35 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91]) by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id E614545DE5D; Mon, 25 Apr 2011 12:03:34 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id D7A1FE08003; Mon, 25 Apr 2011 12:03:34 +0900 (JST) Received: from m004.s.css.fujitsu.com (m004.s.css.fujitsu.com [10.23.4.34]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id A8100E08001; Mon, 25 Apr 2011 12:03:34 +0900 (JST) Received: from m004.css.fujitsu.com (m004 [127.0.0.1]) by m004.s.css.fujitsu.com (Postfix) with ESMTP id 5A8642E04C2; Mon, 25 Apr 2011 12:03:34 +0900 (JST) Received: from [127.0.0.1] (fj86077803.sl046.dhcp.css.fujitsu.com [10.77.46.61]) by m004.s.css.fujitsu.com (Postfix) with ESMTP id C5DFB2E04D1; Mon, 25 Apr 2011 12:03:30 +0900 (JST) X-SecurityPolicyCheck: OK by SHieldMailChecker v1.5.1 Message-ID: <4DB4E3C8.1070608@jp.fujitsu.com> Date: Mon, 25 Apr 2011 12:00:24 +0900 From: Naoki Matsuhira User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: iesg@ietf.org References: <20110419163654.09944E0764@ietfc.amsl.com> In-Reply-To: <20110419163654.09944E0764@ietfc.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org, cuiyong@tsinghua.edu.cn, IESG Secretary , IETF Announcement list Subject: Re: [Softwires] WG Review: Recharter of Softwires (softwire) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 03:03:39 -0000 some comments in line. (2011/04/20 1:36), IESG Secretary wrote: > A modified charter has been submitted for the Softwires (softwire) working > group in the Internet Area of the IETF. The IESG has not made any > determination as yet. The modified charter is provided below for > informational purposes only. Please send your comments to the IESG > mailing list (iesg@ietf.org) by Tuesday, April 26, 2011. > > > Softwires (softwire) > **DRAFT 2011-04-14** (v03) > -------------------- > Current Status: Active s/Active/Active Working Group/ It seem "Working Group" dropped in editing. > > Chairs: > Alain Durand > Yong Cui > > Internet Area Directors: > Ralph Droms > Jari Arkko > > Internet Area Advisor: > Ralph Droms > > Mailing Lists: > General Discussion: softwires@ietf.org > To Subscribe: softwires-request@ietf.org > Archive: > http://www.ietf.org/mail-archive/web/softwires/current/maillist.html > > Description of Working Group: > > The Softwires Working Group is specifying the standardization of > discovery, control and encapsulation methods for connecting IPv4 > networks across IPv6 networks and IPv6 networks across IPv4 networks > in a way that will encourage multiple, inter-operable > implementations. > > For various reasons, native IPv4 and/or IPv6 transport may not be > available in all cases, and there is a need to tunnel IPv4 in IPv6 > or IPv6 in IPv4 to cross a part of the network which is not IPv4 or > IPv6 capable. The Softwire Problem Statement, RFC 4925, identifies > two distinct topological scenarios that the WG will provide > solutions for: "Hubs and Spokes" and "Mesh." In the former case, > hosts or "stub" networks are attached via individual, > point-to-point, IPv4 over IPv6 or IPv6 over IPv4 softwires to a > centralized Softwire Concentrator. In the latter case (Mesh), > network islands of one Address Family (IPv4 or IPv6) are connected > over a network of another Address Family via point to multi-point > softwires among Address family Border Routers (AFBRs). > > The WG will reuse existing technologies as much as possible and only > when necessary, create additional protocol building blocks. > > For generality, all base Softwires encapsulation mechanisms should > support all combinations of IP versions over one other (IPv4 over > IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). "should support all combinations" seem strong expression with specific work #4, that is "Developments for stateless legacy IPv4 carried over IPv6". Maybe specific work #2 (6rd) is the same. one of proposal below. For generality, all base Softwires encapsulation mechanisms prefer support all combinations of IP versions over one other (IPv4 over IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). However, all combinations may not be apply if it is useful. > IPv4 to IPv6 > translation mechanisms (NAT-PT), new addressing schemes, and block > address assignments are out of scope. DHCP options developed in this > working group will be reviewed jointly with the DHC WG. RADIUS > attributes developed in this working group will be reviewed jointly > with the RADEXT WG. The MIB Doctors directorate will be asked to > review any MIB modules developed in the SOFTWIRE working group. BGP > and other routing and signaling protocols developed in this group > will be reviewed jointly with the proper working groups and other > workings that may take interest (e.g. IDR, L3VPN, PIM, LDP, SAAG, > etc). > > The specific work areas for this working group are: > > 1. Developments for Mesh softwires topology; the Mesh topology work > will be reviewed in the l3vpn and idr WGs > - multicast > - MIB module > > 2. Developments for 6rd: > - multicast > - operational specification > - RADIUS option for 6rd server > - MIB module > > 3. Developments for Dual-Stack Lite (DS-Lite): > - multicast > - operational specification > - RADIUS option for AFTR > - proxy extensions; GI-DS-Lite; DS-Lite with no NAT or NAT on the > B4 element > - MIB module > > 4. Developments for stateless legacy IPv4 carried over IPv6 > - develop a solution motivation document to be published as an > RFC > - develop a protocol specification response to the solution > motivation > document; this work item will not be taken through WG last call > until the solution motivation document has been published > > 5. Finalize discovery and configuration mechanisms for a gateway to > use DS-Lite or 6rd; these discovery and configuration mechanisms > must take into a account other operating environments such as > dual-stack and tunneling mechanisms not defined by the softwire > WG. Development of new mechanisms will involve the dhc and/or > v6ops WGs as appropriate > > Other work items would require WG approval and rechartering. > > Goals and Milestones: > Apr 2011 Submit DS-lite RADIUS option for Proposed Standard > Apr 2011 Adopt DS-lite operational document as WG document > Jul 2011 Submit 6rd RADIUS option for Proposed Standard > Jul 2011 Submit GI DS-lite for Proposed Standard > Jul 2011 Adopt B4NAT as WG document > Aug 2011 Adopt 6rd operational document as WG document > Aug 2011 Adopt Multicast extensions document as WG document > Aug 2011 Submit DS-lite operational document for Informational > Sep 2011 Submit B4NAT for Informational > Nov 2011 Submit Multicast extensions document for Informational > Nov 2011 Submit 6rd operational document for Informational > Nov 2011 Adopt 6rd MIB module as WG document > Nov 2011 Adopt DS-lite MIB module as WG document > Nov 2011 Adopt Mesh topology MIB module as WG document > Nov 2012 Submit 6rd MIB module for Proposed Standard > Nov 2012 Submit DS-lite MIB module for Proposed Standard > Nov 2012 Submit Mesh topology MIB module for Proposed Standard > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > From satoru.matsushima@gmail.com Mon Apr 25 02:14:26 2011 Return-Path: X-Original-To: softwires@ietfc.amsl.com Delivered-To: softwires@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 48A0CE06D2; Mon, 25 Apr 2011 02:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyYB0bY5eUaA; Mon, 25 Apr 2011 02:14:25 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfc.amsl.com (Postfix) with ESMTP id B09A7E0693; Mon, 25 Apr 2011 02:14:24 -0700 (PDT) Received: by pxi20 with SMTP id 20so1510385pxi.27 for ; Mon, 25 Apr 2011 02:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=Hig68iVXBumdXh3bv4zIAdYlIIQI3JRmnuCx3lzK1OQ=; b=enkT2h9T4xyaNlczlEFeQDqgkk31t1xELCGcMPcevxuW3dfjRoKO8EfJyeQb6V6wIV 8KdqOgYcapF7eo9IHQQkZy5jnOCNXK9mzmF3HrQExdQ0pzJzeqwEkHynoIyL8fE3P7PP 6jkg5mALM7reMvKQLQX8sErkPaBsa0Q4Zk3HQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=exFjuST+j4MBpNIkWVlQqTSqpmMTWC3fbzGYEcLGlMJt8rwc7nd1BemeeapXhFjxJy 7R4UAjFyShWX9CTIj03iisobtjZMG7zR5i9/CYwPQ7Sck9HNdBR3vYfY6OW6daMRjaHd fVYuJ11kIrvsK+mZhdY6SJi5zyg8DpwbGuq5I= Received: by 10.68.6.99 with SMTP id z3mr6017154pbz.331.1303722863915; Mon, 25 Apr 2011 02:14:23 -0700 (PDT) Received: from [10.201.80.162] ([202.45.12.174]) by mx.google.com with ESMTPS id y8sm941471pba.51.2011.04.25.02.14.20 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Apr 2011 02:14:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: Date: Mon, 25 Apr 2011 18:14:19 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <0D0DE337-ACB9-49F1-B061-E5AD6C4B20B6@gmail.com> References: To: Yong Cui X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , Yong Cui , iesg@ietf.org Subject: Re: [Softwires] WG Review: Recharter of Softwires (softwire) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 09:14:26 -0000 I'm very confused to understand what DS-Lite is. On 2011/04/21, at 10:22, Yong Cui wrote: > Change "DS-Lite with no NAT or NAT on the B4 element" to "No NAT on = AFTR" However, "draft-ietf-softwire-dual-stack-lite-07" clearly express AFTR = is carrier grade NAT44,=20 and B4(CPE) should not operate a NAT function. So my question is what = does the DS-Lite function deployment model include. Current DS-Lite definition does not accept any extension for "DS-Lite = with no NAT or NAT on the B4 element" to "No NAT on AFTR". I think that to do this as a charter item, we need definition change of = DS-Lite, or use another terminology instead of DS-Lite. Best regards, --satoru On 2011/04/21, at 10:22, Yong Cui wrote: > A couple of comments below. >=20 > -----Original Message----- > From: IESG Secretary > Reply-To: > Date: Tue, 19 Apr 2011 09:36:54 -0700 (PDT) > To: IETF Announcement list > Cc: , Yong Cui > Subject: [Softwires] WG Review: Recharter of Softwires (softwire) >=20 >> A modified charter has been submitted for the Softwires (softwire) = working >> group in the Internet Area of the IETF. The IESG has not made any >> determination as yet. The modified charter is provided below for >> informational purposes only. Please send your comments to the IESG >> mailing list (iesg@ietf.org) by Tuesday, April 26, 2011. >>=20 >>=20 >> Softwires (softwire) >> **DRAFT 2011-04-14** (v03) >> -------------------- >> Current Status: Active >>=20 >> Chairs: >> Alain Durand >> Yong Cui >>=20 >> Internet Area Directors: >> Ralph Droms >> Jari Arkko >>=20 >> Internet Area Advisor: >> Ralph Droms >>=20 >> Mailing Lists: >> General Discussion: softwires@ietf.org >> To Subscribe: softwires-request@ietf.org >> Archive: =20 >> http://www.ietf.org/mail-archive/web/softwires/current/maillist.html >>=20 >> Description of Working Group: >>=20 >> The Softwires Working Group is specifying the standardization of >> discovery, control and encapsulation methods for connecting IPv4 >> networks across IPv6 networks and IPv6 networks across IPv4 networks >> in a way that will encourage multiple, inter-operable >> implementations. >>=20 >> For various reasons, native IPv4 and/or IPv6 transport may not be >> available in all cases, and there is a need to tunnel IPv4 in IPv6 >> or IPv6 in IPv4 to cross a part of the network which is not IPv4 or >> IPv6 capable. The Softwire Problem Statement, RFC 4925, identifies >> two distinct topological scenarios that the WG will provide >> solutions for: "Hubs and Spokes" and "Mesh." In the former case, >> hosts or "stub" networks are attached via individual, >> point-to-point, IPv4 over IPv6 or IPv6 over IPv4 softwires to a >> centralized Softwire Concentrator. In the latter case (Mesh), >> network islands of one Address Family (IPv4 or IPv6) are connected >> over a network of another Address Family via point to multi-point >> softwires among Address family Border Routers (AFBRs). >>=20 >> The WG will reuse existing technologies as much as possible and only >> when necessary, create additional protocol building blocks. >>=20 >> For generality, all base Softwires encapsulation mechanisms should >> support all combinations of IP versions over one other (IPv4 over >> IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). IPv4 to IPv6 >> translation mechanisms (NAT-PT), new addressing schemes, and block >> address assignments are out of scope. DHCP options developed in this >> working group will be reviewed jointly with the DHC WG. RADIUS >> attributes developed in this working group will be reviewed jointly >> with the RADEXT WG. The MIB Doctors directorate will be asked to >> review any MIB modules developed in the SOFTWIRE working group. BGP >> and other routing and signaling protocols developed in this group >> will be reviewed jointly with the proper working groups and other >> workings that may take interest (e.g. IDR, L3VPN, PIM, LDP, SAAG, >> etc). >>=20 >> The specific work areas for this working group are: >>=20 >> 1. Developments for Mesh softwires topology; the Mesh topology work >> will be reviewed in the l3vpn and idr WGs >> - multicast >> - MIB module >>=20 >> 2. Developments for 6rd: >> - multicast >> - operational specification >> - RADIUS option for 6rd server >> - MIB module >>=20 >> 3. Developments for Dual-Stack Lite (DS-Lite): >> - multicast >> - operational specification >> - RADIUS option for AFTR >> - proxy extensions; GI-DS-Lite; DS-Lite with no NAT or NAT on the >> B4 element >=20 > Change "DS-Lite with no NAT or NAT on the B4 element" to "No NAT on = AFTR" >=20 >> - MIB module >>=20 >> 4. Developments for stateless legacy IPv4 carried over IPv6 >> - develop a solution motivation document to be published as an >> RFC >> - develop a protocol specification response to the solution >> motivation >> document; this work item will not be taken through WG last call >> until the solution motivation document has been published >>=20 >> 5. Finalize discovery and configuration mechanisms for a gateway to >> use DS-Lite or 6rd; these discovery and configuration mechanisms >> must take into a account other operating environments such as >> dual-stack and tunneling mechanisms not defined by the softwire >> WG. Development of new mechanisms will involve the dhc and/or >> v6ops WGs as appropriate >>=20 >> Other work items would require WG approval and rechartering. >>=20 >> Goals and Milestones: >> Apr 2011 Submit DS-lite RADIUS option for Proposed Standard >> Apr 2011 Adopt DS-lite operational document as WG document >> Jul 2011 Submit 6rd RADIUS option for Proposed Standard >> Jul 2011 Submit GI DS-lite for Proposed Standard >> Jul 2011 Adopt B4NAT as WG document >=20 > Replace the item on B4NAT to the following two lines: > Jul 2011 Adopt DS-Lite without NAT as WG document > Jul 2011 Adopt DHCPv4 over tunnel as WG document >=20 >> Aug 2011 Adopt 6rd operational document as WG document >> Aug 2011 Adopt Multicast extensions document as WG document >> Aug 2011 Submit DS-lite operational document for Informational >> Sep 2011 Submit B4NAT for Informational >=20 > Again, replace the item on B4NAT to the following two lines: > Sep 2011 Submit DS-Lite without NAT for Informational > Sep 2011 Adopt DHCPv4 over tunnel for Proposed Standard >=20 >=20 > Thanks, >=20 > Yong >=20 >> Nov 2011 Submit Multicast extensions document for Informational >> Nov 2011 Submit 6rd operational document for Informational >> Nov 2011 Adopt 6rd MIB module as WG document >> Nov 2011 Adopt DS-lite MIB module as WG document >> Nov 2011 Adopt Mesh topology MIB module as WG document >> Nov 2012 Submit 6rd MIB module for Proposed Standard >> Nov 2012 Submit DS-lite MIB module for Proposed Standard >> Nov 2012 Submit Mesh topology MIB module for Proposed Standard >>=20 >> _______________________________________________ >> 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 jan@go6.si Fri Apr 29 07:28:15 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E3CE0773 for ; Fri, 29 Apr 2011 07:28:15 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0IctUxT9APv for ; Fri, 29 Apr 2011 07:28:15 -0700 (PDT) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD40E0772 for ; Fri, 29 Apr 2011 07:28:15 -0700 (PDT) Received: from jan-mac.local (unknown [IPv6:2001:470:d422:1:1293:e9ff:fe07:182c]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id 7062C237800A for ; Fri, 29 Apr 2011 16:28:10 +0200 (CEST) Message-ID: <4DBACC47.7090006@go6.si> Date: Fri, 29 Apr 2011 16:33:43 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: softwires@ietf.org References: <0D0DE337-ACB9-49F1-B061-E5AD6C4B20B6@gmail.com> In-Reply-To: <0D0DE337-ACB9-49F1-B061-E5AD6C4B20B6@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] WG Review: Recharter of Softwires (softwire) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 14:28:15 -0000 On 4/25/11 11:14 AM, Satoru Matsushima wrote: > I'm very confused to understand what DS-Lite is. > > On 2011/04/21, at 10:22, Yong Cui wrote: > >> Change "DS-Lite with no NAT or NAT on the B4 element" to "No NAT on AFTR" > > However, "draft-ietf-softwire-dual-stack-lite-07" clearly express AFTR is carrier grade NAT44, > and B4(CPE) should not operate a NAT function. So my question is what does the DS-Lite function deployment model include. > Current DS-Lite definition does not accept any extension for "DS-Lite with no NAT or NAT on the B4 element" to "No NAT on AFTR". > I think that to do this as a charter item, we need definition change of DS-Lite, or use another terminology instead of DS-Lite. "DS-Lite with no NAT or NAT on the B4 element" or "No NAT on AFTR" are fancy new names for A+P. A+P was defined in DS-Lite as possible way of doing it some versions ago but disappeared through the time. No idea why, but anyway. Basically DS-Lite and A+P are similar mechanisms with NAT at different places. See ymbk-aplusp draft, section "Overall architecture". Cheers, Jan Zorz