From dhankins@google.com Tue Feb 1 13:19:13 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 2E68B3A6C71 for ; Tue, 1 Feb 2011 13:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.376 X-Spam-Level: X-Spam-Status: No, score=-104.376 tagged_above=-999 required=5 tests=[AWL=-1.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 i8R35jwgvu6E for ; Tue, 1 Feb 2011 13:19:12 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 8218F3A6C72 for ; Tue, 1 Feb 2011 13:19:10 -0800 (PST) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p11LMQ20025447 for ; Tue, 1 Feb 2011 13:22:27 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296595347; bh=vUhx7NFDjmb5gXO7dZR99OrmqCk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=kc52FP9c15YBB0AITXFSWsiizdivjHtRmypHsC07Se4tkIe56GIaRoMG36BI3Awmr dGx0iXPyxaETdP2O3MetQ== Received: from ywe10 (ywe10.prod.google.com [10.192.5.10]) by wpaz29.hot.corp.google.com with ESMTP id p11LMJjK010243 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 1 Feb 2011 13:22:25 -0800 Received: by ywe10 with SMTP id 10so3247862ywe.24 for ; Tue, 01 Feb 2011 13:22:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PZcX62EvCjRiiLEBl2RcWAm/xKnpB4Rmikf14jPKnm4=; b=VJUdERD1qQPTKV8HMhg1XvE0xAkCPxJMpkqmUGekZYf9yXVVjaECnw3i+K6S4mdenm 2wd+EXiv186kn6AG3xdA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sOZqp3hE/IV4nxR6VAwaCFevoAIq7zKx0+ZtMoaqQmrVMAGOTPv0OSQLqsFg71dCUE 7sZnMjbjk9du3Zzva6vg== MIME-Version: 1.0 Received: by 10.100.45.2 with SMTP id s2mr5101845ans.218.1296595345433; Tue, 01 Feb 2011 13:22:25 -0800 (PST) Received: by 10.100.92.19 with HTTP; Tue, 1 Feb 2011 13:22:25 -0800 (PST) In-Reply-To: <26000_1296545330_4D47B632_26000_387791_1_94C682931C08B048B7A8645303FDC9F33C433B8971@PUEXCB1B.nanterre.francetelecom.fr> References: <20101210200002.5362.92301.idtracker@localhost> <88FF3B58-F802-4566-A66B-151B598FF007@juniper.net> <29123_1292226172_4D05CE7C_29123_53394_1_94C682931C08B048B7A8645303FDC9F3365A8233B4@PUEXCB1B.nanterre.francetelecom.fr> <26000_1296545330_4D47B632_26000_387791_1_94C682931C08B048B7A8645303FDC9F33C433B8971@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 1 Feb 2011 13:22:25 -0800 Message-ID: From: David Hankins To: mohamed.boucadair@orange-ftgroup.com Content-Type: multipart/alternative; boundary=0016e640d1acfb6637049b3f20c2 X-System-Of-Record: true Cc: "softwires@ietf.org list" , Softwire Chairs Subject: Re: [Softwires] WG last call on draft-ietf-softwire-ds-lite-tunnel-option-07 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 21:19:13 -0000 --0016e640d1acfb6637049b3f20c2 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 31, 2011 at 11:28 PM, wrote: > * I still vote for clear language without taking care of the current > implementations: since the aim is to convey one single option enclosing only > one name; then the client and the sever behaviours should be provided > accordingly (i.e., use of "must" instead of the "should"). > Thank you, I will wait a bit and see how Ted responds before making any changes. For the moment we have what is hopefully a compromise between a two-person consensus. * I see your point about the multi-interface text. This is fair. I would > just add a sentence like: > > "Means to bind a FQDN_NAME configuration to a given interface in a MIFed > device are out of scope of this document." > I think that's appropriate, I'll integrate this. -- David W. Hankins SRE Google, Inc. --0016e640d1acfb6637049b3f20c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 31, 2011 at 11:28 PM, <mohamed.bo= ucadair@orange-ftgroup.com> wrote:
*=A0I still vot= e for clear language without taking care=20 of the current implementations: since the=A0aim is to convey one single=20 option enclosing only one name; then the client and the sever behaviours sh= ould=20 be provided accordingly (i.e., use of "must" instead=20 of=A0the=A0"should").

Thank you, I will wait a bit and see how Ted responds before making= any changes. =A0For the moment we have what is hopefully a compromise betw= een a two-person consensus.

* I= see your point about the multi-interface text. This is=20 fair. I would just add a sentence like:
=A0
"Means to bind a FQDN_NAME configuration to a given= =20 interface in a MIFed device are out of scope of this document."=

I think that's appr= opriate, I'll integrate this.

--
David W. Hankins
SRE
Google, Inc.
--0016e640d1acfb6637049b3f20c2-- From Ted.Lemon@nominum.com Tue Feb 1 13:28:44 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 E56073A6C57 for ; Tue, 1 Feb 2011 13:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.595 X-Spam-Level: X-Spam-Status: No, score=-106.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 iuenvXCFpEMz for ; Tue, 1 Feb 2011 13:28:42 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 9F2EE3A6C4D for ; Tue, 1 Feb 2011 13:28:42 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTUh70KRtyfB4K+XYU7ll9tScILR+32Fq@postini.com; Tue, 01 Feb 2011 13:32:00 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 917F51B82E2 for ; Tue, 1 Feb 2011 13:31:15 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 72E00190047; Tue, 1 Feb 2011 13:31:15 -0800 (PST) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 1 Feb 2011 13:31:15 -0800 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Tue, 1 Feb 2011 16:31:11 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <0097636C-4D83-4AD1-A7CC-0918CF6EFC1A@nominum.com> References: <20101210200002.5362.92301.idtracker@localhost> <88FF3B58-F802-4566-A66B-151B598FF007@juniper.net> <29123_1292226172_4D05CE7C_29123_53394_1_94C682931C08B048B7A8645303FDC9F3365A8233B4@PUEXCB1B.nanterre.francetelecom.fr> <26000_1296545330_4D47B632_26000_387791_1_94C682931C08B048B7A8645303FDC9F33C433B8971@PUEXCB1B.nanterre.francetelecom.fr> To: David Hankins X-Mailer: Apple Mail (2.1082) Cc: "softwires@ietf.org list" , Softwire Chairs Subject: Re: [Softwires] WG last call on draft-ietf-softwire-ds-lite-tunnel-option-07 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 21:28:44 -0000 On Feb 1, 2011, at 4:22 PM, David Hankins wrote: > Thank you, I will wait a bit and see how Ted responds before making = any changes. For the moment we have what is hopefully a compromise = between a two-person consensus. You specify "MUST" when you want the implementation to enforce the = behavior. We do not want implementations to have to support = option-specific behavior. Hence, we should not use MUST. However, this is not to say that implementations receiving these options = should be required to deal with erroneous results; it's simply that the = server should be allowed to return extra data if it's configured to do = so; the consumer of the data (not the DHCP client, which is merely a = transport mechanism for the data) should be responsible for making sense = of it, or rejecting it if the server was configured to send something = bogus. From rdroms.ietf@gmail.com Fri Feb 4 11:58:46 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 A2C513A692E for ; Fri, 4 Feb 2011 11:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.436 X-Spam-Level: X-Spam-Status: No, score=-103.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 2JNM7zBqtYzP for ; Fri, 4 Feb 2011 11:58:45 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id F3BC53A68AF for ; Fri, 4 Feb 2011 11:58:44 -0800 (PST) Received: by vws7 with SMTP id 7so1821943vws.31 for ; Fri, 04 Feb 2011 12:02:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:cc:to:mime-version:x-mailer; bh=rVsjc/F3M2mL2Gk6IBSao61rMrUO5VCb7T6F8pUVRdY=; b=gBzXQY/l6/6/ehuhkBDuiEhVoNCnOpXoJKiz6zmlCFCkKk8APhG9+GxuYY3exYqDU/ 6qybyyteAhwtYLvqtx0BY72eCctlhxZYS+FMoVXWfS+ZTzUNHLwSwR8XIe3QxbEFQ9zU frG4vte33V8HqwVbI0QrLtxFMROau6UXT7lqY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=mRIDGXBreudLxw8p9yDtDxCZXkNWVyXpYg5LJL+cnFEuvvzBTBaspvIocoB322BOud 4wTxug7WxlPHRzt/zlHFJmRsQr+y02DnRZaNc4ynjWe7CEaLMR7/ho/g2NFsmfSPw9ge eUCit47koRIfikUDQ/7dFFFfDNEcf+uzVGmwY= Received: by 10.220.201.2 with SMTP id ey2mr3522196vcb.29.1296849730261; Fri, 04 Feb 2011 12:02:10 -0800 (PST) Received: from bxb-rdroms-87113.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id s6sm443530vch.23.2011.02.04.12.02.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Feb 2011 12:02:09 -0800 (PST) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Feb 2011 15:02:07 -0500 Message-Id: To: softwires@ietf.org, David Ward Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Cc: int-ads@tools.ietf.org Subject: [Softwires] softwire chairs 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, 04 Feb 2011 19:58:46 -0000 David Ward has let Jari and me know that he will be stepping down as = softwire WG co-chair. Thanks, dward, for all of your guidance, = technical contributions and day-to-day efforts in the WG. You've been a = major contributor to the successful completion of the important results = from the WG. Now we need to find a new co-chair. Jari and I are going to collect = names of candidates and select a new chair in the next few weeks. If you = would like to volunteer yourself or suggest someone else as a candidate, = please let us know. We expect to have a new co-chair in place for the = IETF meeting in Prague. - Jari and Ralph From zhou.xingyue@zte.com.cn Fri Feb 11 01:26:29 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 CDF0D3A683D for ; Fri, 11 Feb 2011 01:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.314 X-Spam-Level: X-Spam-Status: No, score=-97.314 tagged_above=-999 required=5 tests=[AWL=4.524, BAYES_00=-2.599, RCVD_DOUBLE_IP_LOOSE=0.76, 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 MiONSz-pSj5t for ; Fri, 11 Feb 2011 01:26:29 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id B8E823A67C1 for ; Fri, 11 Feb 2011 01:26:28 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 20595271095904; Fri, 11 Feb 2011 17:21:11 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 16200.271095904; Fri, 11 Feb 2011 17:18:08 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p1B9QMee088146 for ; Fri, 11 Feb 2011 17:26:22 +0800 (GMT-8) (envelope-from zhou.xingyue@zte.com.cn) To: softwires@ietf.org MIME-Version: 1.0 X-KeepSent: 372F2370:D628F800-48257834:0033C6E8; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.xingyue@zte.com.cn Date: Fri, 11 Feb 2011 17:26:10 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-02-11 17:26:23, Serialize complete at 2011-02-11 17:26:23 Content-Type: multipart/alternative; boundary="=_alternative 0033D9BF48257834_=" X-MAIL: mse01.zte.com.cn p1B9QMee088146 Subject: [Softwires] test (pls igore this mail) 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, 11 Feb 2011 09:26:29 -0000 This is a multipart message in MIME format. --=_alternative 0033D9BF48257834_= Content-Type: text/plain; charset="US-ASCII" --=_alternative 0033D9BF48257834_= Content-Type: text/html; charset="US-ASCII" --=_alternative 0033D9BF48257834_=-- From rpenno@juniper.net Sun Feb 13 11:23:35 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 6D7E83A6ACC for ; Sun, 13 Feb 2011 11:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKkpugP-5dHj for ; Sun, 13 Feb 2011 11:23:34 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 466803A6AC8 for ; Sun, 13 Feb 2011 11:23:33 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTVgvyuPOBn/ajyDU06hdqSQPEDgw+gb1@postini.com; Sun, 13 Feb 2011 11:23:55 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 13 Feb 2011 11:23:14 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Sun, 13 Feb 2011 14:23:32 -0500 From: Reinaldo Penno To: "softwires@ietf.org" Date: Sun, 13 Feb 2011 14:23:27 -0500 Thread-Topic: Question on draft-arkko-dual-stack-extra-lite-05 Thread-Index: AcvJzdBFozSHPPAHQn+Y1R4uC9McXwB5azpL Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Softwires] Question on draft-arkko-dual-stack-extra-lite-05 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 19:23:35 -0000 Hello Authors, Hopefully this is the right list for questions on this draft. Maybe BEHAVE? In general, is it possible to comments how the requirements of RFC4787, RFC5382 can be met with this kind of proposal? For example, do we just re-read RFC4787 substituting 'X' by 'interface' or there is more to it? Was this analysis done? Also in the context where the source IP (and port?) do not need to be stored as below? " For deployments where exactly one user device is connected with a separate tunnel interface and all tunnels use the same IPv4 address for the user devices, it is redundant to store this address in the mapping in addition to the internal interface identifier. When the internal interface identifier is shorter than a 32-bit IPv4 address, this may decrease the storage requirements of a mapping entry by a small measure, which may aid NAT scalability. For other deployments, it is likely necessary to store both the user device IPv4 address and the internal interface identifier, which slightly increases the size of the mapping entry. " Thanks, Reinaldo From yiu_lee@cable.comcast.com Mon Feb 21 18:13:02 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 526DC3A67DF for ; Mon, 21 Feb 2011 18:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.633 X-Spam-Level: X-Spam-Status: No, score=-105.633 tagged_above=-999 required=5 tests=[AWL=2.830, 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 VC6UKeBIJ3PP for ; Mon, 21 Feb 2011 18:13:01 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 1B8B33A67DA for ; Mon, 21 Feb 2011 18:13:00 -0800 (PST) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.114421353; Mon, 21 Feb 2011 21:13:39 -0500 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; Mon, 21 Feb 2011 21:13:39 -0500 From: "Lee, Yiu" To: Ralph Droms , "softwires@ietf.org" , David Ward Thread-Topic: [Softwires] softwire chairs Thread-Index: AQHL0jYeFZ2LHxokkk+fkaZUJ+pl5g== Date: Tue, 22 Feb 2011 02:13:38 +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: <137AAE8AE37CC64B8E5F0555DE84C8F8@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "int-ads@tools.ietf.org" Subject: Re: [Softwires] softwire chairs 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, 22 Feb 2011 02:13:02 -0000 Hi Jari and Ralph, I am interested in volunteering myself to co-chair. Thanks, Yiu On 2/4/11 3:02 PM, "Ralph Droms" wrote: >David Ward has let Jari and me know that he will be stepping down as >softwire WG co-chair. Thanks, dward, for all of your guidance, technical >contributions and day-to-day efforts in the WG. You've been a major >contributor to the successful completion of the important results from >the WG. > >Now we need to find a new co-chair. Jari and I are going to collect >names of candidates and select a new chair in the next few weeks. If you >would like to volunteer yourself or suggest someone else as a candidate, >please let us know. We expect to have a new co-chair in place for the >IETF meeting in Prague. > >- Jari and Ralph > > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From dwing@cisco.com Wed Feb 23 08:18:28 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 906353A68FE for ; Wed, 23 Feb 2011 08:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.583 X-Spam-Level: X-Spam-Status: No, score=-110.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEo3UZOR0cgh for ; Wed, 23 Feb 2011 08:18:27 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D06C03A67A1 for ; Wed, 23 Feb 2011 08:18:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1544; q=dns/txt; s=iport; t=1298477955; x=1299687555; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=4Oqi9ryhpmZosXiI3i+c6ZyKcs7GF0BzEv5W062OkmA=; b=UzFbqFw0a7Wok5b/Z52irQmIvnykvAnF9OkG/+dMYO8HlXcOCb6xoPwJ NfhfxibXqbvEJCUm0w4+PZyeOkKfhKzZI/4f/f21q7mUczuK9X+sDlnJe 8ZaQyM496tTekPQoORqwwTIRuicquGlNiLEGdHKkTf/CzxyrmvzgfHxqY 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4HAMvBZE2rR7Ht/2dsb2JhbACYDIEmjGdzoGKbeIVeBIUN X-IronPort-AV: E=Sophos;i="4.62,212,1297036800"; d="scan'208";a="314290753" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 23 Feb 2011 16:19:15 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1NGJEQv018378; Wed, 23 Feb 2011 16:19:15 GMT From: "Dan Wing" To: Date: Wed, 23 Feb 2011 08:19:14 -0800 Message-ID: <19e901cbd375$69d56c20$3d804460$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvTdWmUtTr97IytTgewiqrOo8O3HA== Content-Language: en-us Cc: draft-ietf-softwire-dual-stack-lite@tools.ietf.org Subject: [Softwires] ALG section in draft-ietf-softwire-dual-stack-lite-06 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, 23 Feb 2011 16:18:28 -0000 http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-06 says: 8.3. Application Level Gateways (ALG) The AFTR should only perform a minimum number of ALG for the classic applications such as FTP, RTSP/RTP, IPsec and PPTP VPN pass-through and enable the users to use their own ALG on statically or dynamically reserved ports instead. Comments: * To my knowledge, this would be the first time IETF suggests using an ALG in a NAT44 in a standards-track document. * Both IPsec and PPTP are protocols, not applications. IPsec is 50 (assuming you mean IPsec ESP, which I'm sure is what was intended) and PPTP uses protocol 47 (GRE). Thus, these do not belong in the Application Level Gateway section. Rather, IPsec and PPTP should be moved to the previous section (NAT Conformance) which already mentions other protocols like TCP and ICMP. * There aren't specifications describing an ALG for FTP, RTSP, RTP, IPsec, or PPTP VPN. * What is "RTSP/RTP"? Is this trying to say "RTSP, when it is using RTP", or is it trying to say "RTSP and other uses of RTP". Text needs to be clarified. * IPsec Passthru is pretty common on residential NATs. However, in a CGN, IPsec Passthru is difficult when multiple users connect to the same VPN concentrator. When that concentrator re-keys a session, the incoming IPsec SPI changes and there is no simple way to determine which user should receive that packet. There are several workarounds to this problem, including just ignoring it. -d From mohamed.boucadair@orange-ftgroup.com Wed Feb 23 08:19:01 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 553C53A6A28 for ; Wed, 23 Feb 2011 08:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.177 X-Spam-Level: X-Spam-Status: No, score=-3.177 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3grWWjT16TsQ for ; Wed, 23 Feb 2011 08:19:00 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 2C52D3A6A26 for ; Wed, 23 Feb 2011 08:19:00 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 3C74F18C467; Wed, 23 Feb 2011 17:19:46 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 1E184238055; Wed, 23 Feb 2011 17:19:46 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Wed, 23 Feb 2011 17:19:46 +0100 From: To: 'Alain Durand' , "Lee, Yiu" Date: Wed, 23 Feb 2011 17:19:45 +0100 Thread-Topic: DS-Lite I-D progress (was RE: [Softwires] dual-stack-lite-06 - Too biased against static port sharing) Thread-Index: Acs/DkvRmzD5iylRRe2E7UDqla6fgyUZrQqg Message-ID: <24061_1298477986_4D6533A2_24061_72547_1_94C682931C08B048B7A8645303FDC9F33C4BD04448@PUEXCB1B.nanterre.francetelecom.fr> References: Your message of Thu, 12 Aug 2010 10:22:30 +0200. <24280_1281601351_4C63AF47_24280_1087_1_94C682931C08B048B7A8645303FDC9F312F6F9EB2D@PUEXCB1B.nanterre.francetelecom.fr> <201008181948.o7IJm8EZ000868@givry.fdupont.fr> In-Reply-To: <201008181948.o7IJm8EZ000868@givry.fdupont.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.2.23.153317 Cc: Softwires , Ralph Droms Subject: [Softwires] DS-Lite I-D progress (was RE: dual-stack-lite-06 - Too biased against static port sharing) 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, 23 Feb 2011 16:19:01 -0000 Dear Alain, Yiu, Is there any plan to update the DS-Lite draft to take into account the comm= ents received so far and to make this document progress? Cheers, Med -----Message d'origine----- De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]=20 Envoy=E9 : mercredi 18 ao=FBt 2010 21:48 =C0 : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : R=E9mi Despr=E9s; Softwires; Ralph Droms Objet : Re: [Softwires] dual-stack-lite-06 - Too biased against static port= sharing=20 In your previous mail you wrote: We have raised this point during the last call which has been issued on version 03 of the draft and suggested to remove this section from the draft since it is not normative and also because this depends on the taste of each SP and their deployment context. A reference to http://tools.ietf.org/html/ draft-ietf-intarea-shared-addressing-issues-01#page-22 would be sufficient IMHO. "Dynamic vs. Static" and "Port set vs. Individual ports" discussion can be elaborated further in draft-intarea-shared-addressing-issues if required. =20=20=20 =3D> IMHO it is the best option (and to make the draft smaller is a good goal :-). Thanks Francis.Dupont@fdupont.fr ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** From townsley@cisco.com Wed Feb 23 08:28: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 8578F3A6A2B for ; Wed, 23 Feb 2011 08:28:47 -0800 (PST) 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, 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 v7ASzMnOxhAw for ; Wed, 23 Feb 2011 08:28:45 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id C11003A6A20 for ; Wed, 23 Feb 2011 08:28:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=townsley@cisco.com; l=2298; q=dns/txt; s=iport; t=1298478570; x=1299688170; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=2HUjy2YF/UFcojGu0/YErYDYySFOrQVYIztntJGzbbc=; b=ELx8IFlkxTtJdUb8IRyrOu0HlLRRw9gQ/KNrL1FA+fWjxnauYm95KV3H 3go+ubGIhmAy3hcF1Opd5HbPfoCIVdWyY/TgywegBchH0vQ63fVKMf8Mi IHPDNDWtv9eXe4oWlyJOm6gknRG+koHDTYgomS0pgFmyKces4qoeXN+iZ o=; X-IronPort-AV: E=Sophos;i="4.62,212,1297036800"; d="scan'208";a="19935502" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 23 Feb 2011 16:29:28 +0000 Received: from ams-townsley-8714.cisco.com (ams-townsley-8714.cisco.com [10.55.233.229]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p1NGTTmu005326; Wed, 23 Feb 2011 16:29:29 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <19e901cbd375$69d56c20$3d804460$@com> Date: Wed, 23 Feb 2011 17:29:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <19e901cbd375$69d56c20$3d804460$@com> To: "Dan Wing" X-Mailer: Apple Mail (2.1082) Cc: softwires@ietf.org, draft-ietf-softwire-dual-stack-lite@tools.ietf.org Subject: Re: [Softwires] ALG section in draft-ietf-softwire-dual-stack-lite-06 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, 23 Feb 2011 16:28:47 -0000 I'd like to see all softwire documents be as silent as possible on = specifics of NAT. The essential delta in ds-lite vs. a NAT44 CGN is that = the tunnel is embedded within the NAT binding. I think the softwire = documents should explain this, then point to behave for anything else = that has to do with operating a CGN. We are the tunneling folks here, = the translation folks are down the corridor. - Mark On Feb 23, 2011, at 5:19 PM, Dan Wing wrote: > http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-06 = says: >=20 > 8.3. Application Level Gateways (ALG) >=20 > The AFTR should only perform a minimum number of ALG for the classic > applications such as FTP, RTSP/RTP, IPsec and PPTP VPN pass-through > and enable the users to use their own ALG on statically or > dynamically reserved ports instead. >=20 > Comments: >=20 > * To my knowledge, this would be the first time IETF suggests using an = ALG > in a NAT44 in a standards-track document. >=20 > * Both IPsec and PPTP are protocols, not applications. IPsec is 50 > (assuming you mean IPsec ESP, which I'm sure is what was intended) and = PPTP > uses protocol 47 (GRE). Thus, these do not belong in the Application = Level > Gateway section. Rather, IPsec and PPTP should be moved to the = previous > section (NAT Conformance) which already mentions other protocols like = TCP > and ICMP. >=20 > * There aren't specifications describing an ALG for FTP, RTSP, RTP, = IPsec, > or PPTP VPN. >=20 > * What is "RTSP/RTP"? Is this trying to say "RTSP, when it is using = RTP", > or is it trying to say "RTSP and other uses of RTP". Text needs to be > clarified. >=20 > * IPsec Passthru is pretty common on residential NATs. However, in a = CGN, > IPsec Passthru is difficult when multiple users connect to the same = VPN > concentrator. When that concentrator re-keys a session, the incoming = IPsec > SPI changes and there is no simple way to determine which user should > receive that packet. There are several workarounds to this problem, > including just ignoring it. >=20 > -d >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From yiu_lee@cable.comcast.com Wed Feb 23 10:46:55 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 E9B093A6929 for ; Wed, 23 Feb 2011 10:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.784 X-Spam-Level: X-Spam-Status: No, score=-102.784 tagged_above=-999 required=5 tests=[AWL=-1.049, 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 lLS8Xvxo5yxs for ; Wed, 23 Feb 2011 10:46:55 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id F31513A6850 for ; Wed, 23 Feb 2011 10:46:54 -0800 (PST) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.27050829; Wed, 23 Feb 2011 11:59:21 -0700 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, 23 Feb 2011 13:47:37 -0500 From: "Lee, Yiu" To: Mark Townsley , Dan Wing Thread-Topic: [Softwires] ALG section in draft-ietf-softwire-dual-stack-lite-06 Thread-Index: AQHL04ojxCd5tUCKHEazxoRagYtHlg== Date: Wed, 23 Feb 2011 18:47:36 +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.12] Content-Type: text/plain; charset="us-ascii" Content-ID: <28460D473C7AD8499CB969DB4656C5DD@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" , "draft-ietf-softwire-dual-stack-lite@tools.ietf.org" Subject: Re: [Softwires] ALG section in draft-ietf-softwire-dual-stack-lite-06 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, 23 Feb 2011 18:46:56 -0000 Make sense. The authors will discuss this and send the response back to the working group.=20 On 2/23/11 11:29 AM, "Mark Townsley" wrote: > >I'd like to see all softwire documents be as silent as possible on >specifics of NAT. The essential delta in ds-lite vs. a NAT44 CGN is that >the tunnel is embedded within the NAT binding. I think the softwire >documents should explain this, then point to behave for anything else >that has to do with operating a CGN. We are the tunneling folks here, the >translation folks are down the corridor. > >- Mark > > >On Feb 23, 2011, at 5:19 PM, Dan Wing wrote: > >> http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-06 says: >>=20 >> 8.3. Application Level Gateways (ALG) >>=20 >> The AFTR should only perform a minimum number of ALG for the classic >> applications such as FTP, RTSP/RTP, IPsec and PPTP VPN pass-through >> and enable the users to use their own ALG on statically or >> dynamically reserved ports instead. >>=20 >> Comments: >>=20 >> * To my knowledge, this would be the first time IETF suggests using an >>ALG >> in a NAT44 in a standards-track document. >>=20 >> * Both IPsec and PPTP are protocols, not applications. IPsec is 50 >> (assuming you mean IPsec ESP, which I'm sure is what was intended) and >>PPTP >> uses protocol 47 (GRE). Thus, these do not belong in the Application >>Level >> Gateway section. Rather, IPsec and PPTP should be moved to the previous >> section (NAT Conformance) which already mentions other protocols like >>TCP >> and ICMP. >>=20 >> * There aren't specifications describing an ALG for FTP, RTSP, RTP, >>IPsec, >> or PPTP VPN. >>=20 >> * What is "RTSP/RTP"? Is this trying to say "RTSP, when it is using >>RTP", >> or is it trying to say "RTSP and other uses of RTP". Text needs to be >> clarified. >>=20 >> * IPsec Passthru is pretty common on residential NATs. However, in a >>CGN, >> IPsec Passthru is difficult when multiple users connect to the same VPN >> concentrator. When that concentrator re-keys a session, the incoming >>IPsec >> SPI changes and there is no simple way to determine which user should >> receive that packet. There are several workarounds to this problem, >> including just ignoring it. >>=20 >> -d >>=20 >>=20 >> _______________________________________________ >> 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 yiu_lee@cable.comcast.com Thu Feb 24 19:51: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 8236E3A67C2 for ; Thu, 24 Feb 2011 19:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.696 X-Spam-Level: X-Spam-Status: No, score=-102.696 tagged_above=-999 required=5 tests=[AWL=-0.961, 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 ylsZSJyfj3oO for ; Thu, 24 Feb 2011 19:50:59 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 954B13A68C5 for ; Thu, 24 Feb 2011 19:50:59 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.27266478; Thu, 24 Feb 2011 21:03:33 -0700 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; Thu, 24 Feb 2011 22:51:46 -0500 From: "Lee, Yiu" To: Mark Townsley , Dan Wing Thread-Topic: [Softwires] ALG section in draft-ietf-softwire-dual-stack-lite-06 Thread-Index: AQHL1J9STjQTkrRMkEiVy3NY6Q3WCw== Date: Fri, 25 Feb 2011 03:51:45 +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.14] Content-Type: text/plain; charset="us-ascii" Content-ID: <0CCA29DCE34BF14696D4D8FCF607348C@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" , "draft-ietf-softwire-dual-stack-lite@tools.ietf.org" Subject: Re: [Softwires] ALG section in draft-ietf-softwire-dual-stack-lite-06 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, 25 Feb 2011 03:51:00 -0000 This is a follow-up to the WG. We agreed with Dan and Mark, we will update the draft to reflect this change in next revision. Thanks, Yiu On 2/23/11 11:29 AM, "Mark Townsley" wrote: > >I'd like to see all softwire documents be as silent as possible on >specifics of NAT. The essential delta in ds-lite vs. a NAT44 CGN is that >the tunnel is embedded within the NAT binding. I think the softwire >documents should explain this, then point to behave for anything else >that has to do with operating a CGN. We are the tunneling folks here, the >translation folks are down the corridor. > >- Mark > > >On Feb 23, 2011, at 5:19 PM, Dan Wing wrote: > >> http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-06 says: >>=20 >> 8.3. Application Level Gateways (ALG) >>=20 >> The AFTR should only perform a minimum number of ALG for the classic >> applications such as FTP, RTSP/RTP, IPsec and PPTP VPN pass-through >> and enable the users to use their own ALG on statically or >> dynamically reserved ports instead. >>=20 >> Comments: >>=20 >> * To my knowledge, this would be the first time IETF suggests using an >>ALG >> in a NAT44 in a standards-track document. >>=20 >> * Both IPsec and PPTP are protocols, not applications. IPsec is 50 >> (assuming you mean IPsec ESP, which I'm sure is what was intended) and >>PPTP >> uses protocol 47 (GRE). Thus, these do not belong in the Application >>Level >> Gateway section. Rather, IPsec and PPTP should be moved to the previous >> section (NAT Conformance) which already mentions other protocols like >>TCP >> and ICMP. >>=20 >> * There aren't specifications describing an ALG for FTP, RTSP, RTP, >>IPsec, >> or PPTP VPN. >>=20 >> * What is "RTSP/RTP"? Is this trying to say "RTSP, when it is using >>RTP", >> or is it trying to say "RTSP and other uses of RTP". Text needs to be >> clarified. >>=20 >> * IPsec Passthru is pretty common on residential NATs. However, in a >>CGN, >> IPsec Passthru is difficult when multiple users connect to the same VPN >> concentrator. When that concentrator re-keys a session, the incoming >>IPsec >> SPI changes and there is no simple way to determine which user should >> receive that packet. There are several workarounds to this problem, >> including just ignoring it. >>=20 >> -d >>=20 >>=20 >> _______________________________________________ >> 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 dr@cluenet.de Fri Feb 25 00:51:31 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 057853A681C for ; Fri, 25 Feb 2011 00:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.671 X-Spam-Level: X-Spam-Status: No, score=-1.671 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3KRpZbWRSyz for ; Fri, 25 Feb 2011 00:51:30 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 250613A6928 for ; Fri, 25 Feb 2011 00:51:29 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id 10E7710813E; Fri, 25 Feb 2011 09:52:20 +0100 (CET) Date: Fri, 25 Feb 2011 09:52:20 +0100 From: Daniel Roesen To: softwires@ietf.org Message-ID: <20110225085220.GB29802@srv03.cluenet.de> Mail-Followup-To: softwires@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [Softwires] ALG section in draft-ietf-softwire-dual-stack-lite-06 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, 25 Feb 2011 08:51:31 -0000 On Fri, Feb 25, 2011 at 03:51:45AM +0000, Lee, Yiu wrote: > This is a follow-up to the WG. We agreed with Dan and Mark, we will update > the draft to reflect this change in next revision. Is there any timeline for a new revision, or actually the document becoming an RFC? Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From yiu_lee@cable.comcast.com Fri Feb 25 12:51:27 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 E30923A6A40 for ; Fri, 25 Feb 2011 12:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.622 X-Spam-Level: X-Spam-Status: No, score=-102.622 tagged_above=-999 required=5 tests=[AWL=-0.888, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, 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 jnV6aOh3Ig+3 for ; Fri, 25 Feb 2011 12:51:26 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 1D70D3A6A42 for ; Fri, 25 Feb 2011 12:51:26 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.27379332; Fri, 25 Feb 2011 14:03:59 -0700 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; Fri, 25 Feb 2011 15:52:11 -0500 From: "Lee, Yiu" To: Softwires , "Frank Brockners (fbrockne)" , Sri Gundavelli , "sebastian.speicher@telekom.de" , "dward@juniper.net" Thread-Topic: GI-DS-lite Review Thread-Index: AQHL1S3f8m5hO3FL6k2VxhVxw84Zsw== Date: Fri, 25 Feb 2011 20:52:10 +0000 Message-ID: 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.14] Content-Type: multipart/alternative; boundary="_000_C98D797F974Byiuleecablecomcastcom_" MIME-Version: 1.0 Subject: [Softwires] GI-DS-lite Review 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, 25 Feb 2011 20:51:28 -0000 --_000_C98D797F974Byiuleecablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi authors, I was asked to do a review on the GI-DS-lite draft, this is my review. The draft is well written and is ready to publish. P.3: If e.g., a GRE based encapsulation mechanisms is chosen, it allows the network between the access gateway and the "NAT" to be either IPv4 or IPv6 Suggest to change NAT to AFTR. P.4: AFTR: Address Family Transition Router (also known as "Large Sca= le NAT (LSN)" or "Dual-Stack lite Tunnel Concentrator", or "Carrier Grade NAT"). An AFTR combines IP-in-IP tunnel termination and IPv4-IPv4 NAT. Suggest to remove "(also known as "Large Scale NAT (LSN)" or "Dual-Stack lite Tunnel Concentrator", or "Carrier Grade NAT"). " P.4: TID: Access Tunnel Identifier. The interface identifier of the point-to-point access tunnel. In the GI-DS-lite context, my understanding is the GW is a L3 device, the T= ID (e.g. SID of the PPPoE) could be used to map to a CID. The two usages I = can think of in the draft is mapping the SID to the GRE-key and SID to the = IPv6-Flow-Label. But since MPLS-VPN and IP-in-IP are using AD's source IP a= ddress for the CID, the TID won't be used. In case of WiMAX, no TID will be= assigned to the AD. This isn't discussed clearly in the draft. Do you thin= k we should write a session to capture this? P.4: The combination of CID and SWID (potentially along with other traffic identifiers such as e.g. interface= , VLAN, port, etc.) serves as common context between Gateway and AFTR to uniquely identify flows associated with an access device. Suggest to rewrite to: "The combination of CID and SWID must be unique betw= een gateway and AFTR to identify the flows associated with an AD." P.5: The outer/ external IPv4 address of a NAT-binding at the AFTR is either assigned autonomously by the AFTR from a local address pool=85.. Suggest to rewrite to: "The NAT binding of the AD's address could be assign= ed autonomously by the AFTR from a local address pool=85.." P.8: Softwire identification is supplied by the endpoints of the GRE tunnel. The GRE-key serves as CID. Suggest to rewrite to "SWID is the source address of the GRE tunnel from th= e GW. The CID is the GRE-key assigned to the AD. P.7: MPLS VPN: Softwire identification is supplied by the VPN Identifier of the MPLS VPN. The IPv4-address serves as CID. The IPv4-address within a VPN has to be unique. Suggest to rewrite to "SWID is the MPLS VPN label. The AD's IPv4-address is= the CID. Give a MPLS VPN label, the AD's IPv4 address must be unique. P.7: Softwire identification is supplied by the endpoints of the IP-in-IP tunnel. Either the inner IPv4-address serves as CID (in which case the IPv4-address has to be unique) or the IPv6-Flow-Label serves as CID (which obviously only applies to cases where IPv6 transport is used). Note that when using the IP- Flow-Label as CID additional scaling considerations might apply given that the CID is to only 20 bits wide in this case. Also one should ensure sufficient randomization in this case to for example avoid interference with other uses of the IP-Flow-Label, such as ECMP. I think it would be more clear to separate the discussion for IPv4-in-IPv4 = and IPv4-in-IPv6. Suggest to rewrite to: "IPv4-in-IPv4: SWID is the outer IPv4 source address. The AD's IPv4 address= is the CID. Given an outer IPv4 source address, the AD's IPv4 address must= be unique. IPv4-in-IPv6: SWID is the outer IPv6 source address. If the AD's IPv4 addre= ss is the CID, the AD's IPv4 address must be unique. If the IPv6-Flow-Label= [RFC3697] is the CID, the AD's IPv4 address may be overlapped. IPv6-Flow-L= abel is 20-bit wide which is shorter than the recommended 32-bit CID. In ad= dition, one should ensure sufficient randomization to avoid possible inter= ference with other uses of the IP-Flow-Label, such as ECMP." P.9: May want to update Figure 3 to separate the two IP-in-IP cases. Regards, Yiu --_000_C98D797F974Byiuleecablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <13C3C8BB9995F243B2108C7A3971152B@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
Hi authors,

I was asked to do a review on the GI-DS-lite draft, this is my review.=

The draft is well written and is ready to publish.

P.3:  If e.g., a GRE based
   encapsulation mechanisms is chosen, it allows the network= between the
   access gateway and the "NAT" to be either IPv4 = or IPv6

Suggest to change NAT to AFTR.

P.4:       AFTR: Address Family Transition Ro= uter (also known as "Large Scale
      NAT (LSN)" or "Dual-Stack lite Tun= nel Concentrator", or "Carrier
      Grade NAT").  An AFTR combines IP-= in-IP tunnel termination and
      IPv4-IPv4 NAT.

Suggest to remove "(also known as "Large Scale
      NAT (LSN)" or "Dual-Stack lite Tun= nel Concentrator", or "Carrier
      Grade NAT"). "

P.4: TID: Access Tunnel Identifier.  The interface identifie= r of the
      point-to-point access tunnel.

In the GI-DS-lite context, my understanding is the GW is a L3 device, = the TID (e.g. SID of the PPPoE) could be used to map to a CID. The two usag= es I can think of in the draft is mapping the SID to the GRE-key and SID to= the IPv6-Flow-Label. But since MPLS-VPN and IP-in-IP are using AD's source IP address for the CID, the TI= D won't be used. In case of WiMAX, no TID will be assigned to the AD. This = isn't discussed clearly in the draft. Do you think we should write a sessio= n to capture this?

P.4: The combination of CID and SWID
   (potentially along with other traffic identifiers such as= e.g. interface, VLAN, port, etc.) serves as common context between Ga= teway
   and AFTR to uniquely identify flows associated with an ac= cess device.

Suggest to rewrite to: "The combination of CID and SWID must be u= nique between gateway and AFTR to identify the flows associated with an AD.= " 

P.5: The outer/
   external IPv4 address of a NAT-binding at the AFTR i= s either assigned
   autonomously by the AFTR from a local address pool=85..

Suggest to rewrite to: "The NAT binding of the AD's address could= be assigned autonomously by the AFTR from a local address pool=85.."<= /div>

P.8:  Softwire identification is supplied
      by the endpoints of the GRE tunnel.  Th= e GRE-key serves as CID.

Suggest to rewrite to "SWID is the source address of the GRE tunn= el from the GW.  The CID is the GRE-key assigned to the AD.

P.7: MPLS VPN: Softwire identification is supplied by the VPN
      Identifier of the MPLS VPN.  The IPv4-a= ddress serves as CID.  The
      IPv4-address within a VPN has to be unique.<= /div>

Suggest to rewrite to "SWID is the MPLS VPN label. The AD's = IPv4-address is the CID.  Give a MPLS VPN label, the AD's IPv4 address= must be unique.

P.7:  Softwire identification is supplied by the
      endpoints of the IP-in-IP tunnel.  Eith= er the inner IPv4-address
      serves as CID (in which case the IPv4-addres= s has to be unique) or
      the IPv6-Flow-Label serves as CID (which obv= iously only applies to
      cases where IPv6 transport is used).  N= ote that when using the IP-
      Flow-Label as CID additional scaling conside= rations might apply
      given that the CID is to only 20 bits wide i= n this case.  Also one
      should ensure sufficient randomization in th= is case to for example
      avoid interference with other uses of the IP= -Flow-Label, such as
      ECMP.

I think it would be more clear to separate the discussion for IPv4-in-= IPv4 and IPv4-in-IPv6.

Suggest to rewrite to:

"IPv4-in-IPv4: SWID is the outer IPv4 source address. The AD's IP= v4 address is the CID. Given an outer IPv4 source address, the AD's IPv4 ad= dress must be unique.

IPv4-in-IPv6: SWID is the outer IPv6 source address. If the AD's IPv4 = address is the CID, the AD's IPv4 address must be unique. If the IPv6-Flow-= Label [RFC3697] is the CID, the AD's IPv4 address may be overlapped. IPv6-F= low-Label is 20-bit wide which is shorter than the recommended 32-bit CID. In addition,  one shoul= d ensure sufficient randomization to avoid possible interference with other= uses of the IP-Flow-Label, such as ECMP."

P.9: May want to update Figure 3 to separate the two IP-in-IP cases.

Regards,
Yiu





--_000_C98D797F974Byiuleecablecomcastcom_-- From yiu_lee@cable.comcast.com Sat Feb 26 08:15:11 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 E5B193A6948 for ; Sat, 26 Feb 2011 08:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.923 X-Spam-Level: X-Spam-Status: No, score=-105.923 tagged_above=-999 required=5 tests=[AWL=2.540, 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 0WsiFenMd1fp for ; Sat, 26 Feb 2011 08:15:11 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id E4DFC3A682C for ; Sat, 26 Feb 2011 08:15:10 -0800 (PST) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.114887166; Sat, 26 Feb 2011 11:16:00 -0500 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; Sat, 26 Feb 2011 11:15:59 -0500 From: "Lee, Yiu" To: Daniel Roesen , "softwires@ietf.org" Thread-Topic: [Softwires] ALG section in draft-ietf-softwire-dual-stack-lite-06 Thread-Index: AQHL1dBz6wruPCQ/sE+1X75DKkOWRQ== Date: Sat, 26 Feb 2011 16:15:58 +0000 Message-ID: In-Reply-To: <20110225085220.GB29802@srv03.cluenet.de> 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.14] Content-Type: text/plain; charset="us-ascii" Content-ID: <9ACB53DDE893434EA5359AEE6EF142B8@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] ALG section in draft-ietf-softwire-dual-stack-lite-06 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, 26 Feb 2011 16:15:12 -0000 Hi Daniel, We were waiting for the dhcp option to be finalized. Since it has been resolved, our plan to release a revision next week. The draft is still under IESG review. Thanks for the patience. /Yiu On 2/25/11 3:52 AM, "Daniel Roesen" wrote: >On Fri, Feb 25, 2011 at 03:51:45AM +0000, Lee, Yiu wrote: >> This is a follow-up to the WG. We agreed with Dan and Mark, we will >>update >> the draft to reflect this change in next revision. > >Is there any timeline for a new revision, or actually the document >becoming an RFC? > >Best regards, >Daniel > >--=20 >CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires