From christian.vogt@ericsson.com Wed Apr 1 19:47:30 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03B6D3A67CC; Wed, 1 Apr 2009 19:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 avFDBrYifImm; Wed, 1 Apr 2009 19:47:28 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 9DA423A6907; Wed, 1 Apr 2009 19:47:28 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n322uuYb014109; Wed, 1 Apr 2009 21:56:58 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 21:47:37 -0500 Received: from [155.53.229.46] ([155.53.229.46]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 21:47:36 -0500 Message-Id: <24C1BC72-3A21-4B70-968C-89ED909AABE7@ericsson.com> From: Christian Vogt To: Softwires Mailing List , Gen-ART Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 1 Apr 2009 19:47:37 -0700 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 02 Apr 2009 02:47:36.0446 (UTC) FILETIME=[615A61E0:01C9B33D] Cc: yokota@kddilabs.jp, shu@nict.go.jp, Florent.Parent@beon.ca Subject: [Softwires] Gen-ART Review of draft-ietf-softwire-security-requirements-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: Thu, 02 Apr 2009 02:47:30 -0000 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document..........: draft-ietf-softwire-security-requirements-07 Reviewer..........: Christian Vogt Review date.......: 2009-04-01 (no, not a joke) IESG Telechat date: 2009-04-02 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. The document analyzes potential security issues and resulting security requirements for scenarios where softwire methods are used for IPv4/IPv6 co-existence. I think this type of analysis is important given the expected widespread existence of these scenarios. Below are a few recommended modifications that should be applied to the document prior to publication: - The document is partly about the security for data packets, and it concludes by requiring authentication, integrity, and reply protection for data packets. Why should this be a requirement given that the purpose of softwires is simply to provide interworking between IPv4 and IPv6? Certainly, there will be /some/ scenarios where one would want data packet protection, but generally such protection would be independent of the use of IPv4/IPv6 co-existence methods. Consequently, I would suggest to reduce the security requirements for data packets, perhaps from "MUST" to "MAY/SHOULD". - The document talks about hosts being mobile or nomadic in several places. This might lead a reader into falsely concluding that the described scenarios or vulnerabilities do not apply to stationary hosts. I would therefore suggest to either remove the attributes "mobile" and "nomadic", or to make clear that mobility and nomadicness is only used in the document for exemplification. - On page 9, the document refers to related security analyses, which relate to softwires as well, such as those for PANA, NSIS, and routing protocols. You could add to this list the security analysis for Mobile IP [RFC 4225], which considers similar issues. The similarity becomes obvious if you replace the softwire initiator with the mobile host and the softwire concentrator with the home agent. - On page 10, the document claims that address spoofing causes a DoS attack. I would soften this statement a bit. It is true that address spoofing can be used as a tool in a DoS attack, yet address spoofing does not consistute a DoS attack by itself. - To prevent address spoofing, the document recommends the use of authentication. This should be elaborated on. Authentication alone does not prevent the authenticated entity from spoofing its address. What is needed in addition is a binding between the legitimate address and the authenticated identity. Hope this helps. Wish everyone involved a smooth publication process! - Christian From shu@nict.go.jp Wed Apr 1 22:00:42 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0636E3A682F; Wed, 1 Apr 2009 22:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.243 X-Spam-Level: X-Spam-Status: No, score=-0.243 tagged_above=-999 required=5 tests=[AWL=1.112, BAYES_00=-2.599, HELO_EQ_JP=1.244] 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 T31G1Tz44IOp; Wed, 1 Apr 2009 22:00:40 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id 0B5513A694D; Wed, 1 Apr 2009 22:00:39 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n3251Wp5024441; Thu, 2 Apr 2009 14:01:32 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n3251WRC010206; Thu, 2 Apr 2009 14:01:32 +0900 (JST) Received: from [127.0.0.1] (ssh.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp with ESMTP id n3251WUx010203; Thu, 2 Apr 2009 14:01:32 +0900 (JST) Message-ID: <49D446AC.90407@nict.go.jp> Date: Thu, 02 Apr 2009 14:01:32 +0900 From: Shu Yamamoto User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christian Vogt References: <24C1BC72-3A21-4B70-968C-89ED909AABE7@ericsson.com> In-Reply-To: <24C1BC72-3A21-4B70-968C-89ED909AABE7@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 02 Apr 2009 08:03:03 -0700 Cc: Softwires Mailing List , yokota@kddilabs.jp, Gen-ART Mailing List , Florent.Parent@beon.ca Subject: Re: [Softwires] Gen-ART Review of draft-ietf-softwire-security-requirements-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: Thu, 02 Apr 2009 05:00:42 -0000 Hello Christian; Thank you for reviewing the document and comments. We will shorly update the document but wait for posting it. Shu Yamamoto > > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > > Document..........: draft-ietf-softwire-security-requirements-07 > Reviewer..........: Christian Vogt > Review date.......: 2009-04-01 (no, not a joke) > IESG Telechat date: 2009-04-02 > > > Summary: This draft is basically ready for publication, but has nits > that should be fixed before publication. > > The document analyzes potential security issues and resulting security > requirements for scenarios where softwire methods are used for IPv4/IPv6 > co-existence. I think this type of analysis is important given the > expected widespread existence of these scenarios. Below are a few > recommended modifications that should be applied to the document prior > to publication: > > - The document is partly about the security for data packets, and it > concludes by requiring authentication, integrity, and reply > protection for data packets. Why should this be a requirement given > that the purpose of softwires is simply to provide interworking > between IPv4 and IPv6? Certainly, there will be /some/ scenarios > where one would want data packet protection, but generally such > protection would be independent of the use of IPv4/IPv6 co-existence > methods. Consequently, I would suggest to reduce the security > requirements for data packets, perhaps from "MUST" to "MAY/SHOULD". > > - The document talks about hosts being mobile or nomadic in several > places. This might lead a reader into falsely concluding that the > described scenarios or vulnerabilities do not apply to stationary > hosts. I would therefore suggest to either remove the attributes > "mobile" and "nomadic", or to make clear that mobility and > nomadicness is only used in the document for exemplification. > > - On page 9, the document refers to related security analyses, which > relate to softwires as well, such as those for PANA, NSIS, and > routing protocols. You could add to this list the security analysis > for Mobile IP [RFC 4225], which considers similar issues. The > similarity becomes obvious if you replace the softwire initiator > with the mobile host and the softwire concentrator with the home > agent. > > - On page 10, the document claims that address spoofing causes a DoS > attack. I would soften this statement a bit. It is true that > address spoofing can be used as a tool in a DoS attack, yet address > spoofing does not consistute a DoS attack by itself. > > - To prevent address spoofing, the document recommends the use of > authentication. This should be elaborated on. Authentication alone > does not prevent the authenticated entity from spoofing its address. > What is needed in addition is a binding between the legitimate > address and the authenticated identity. > > Hope this helps. Wish everyone involved a smooth publication process! > > - Christian > > > From root@core3.amsl.com Thu Apr 2 11:30:01 2009 Return-Path: X-Original-To: softwires@ietf.org Delivered-To: softwires@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 40C3F3A6BB4; Thu, 2 Apr 2009 11:30:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090402183001.40C3F3A6BB4@core3.amsl.com> Date: Thu, 2 Apr 2009 11:30:01 -0700 (PDT) Cc: softwires@ietf.org Subject: [Softwires] I-D Action:draft-ietf-softwire-lb-02.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 18:30:01 -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 : Load Balancing for Mesh Softwires Author(s) : C. Filsfils, et al. Filename : draft-ietf-softwire-lb-02.txt Pages : 7 Date : 2009-04-02 Payloads carried over a Softwire mesh service as defined by BGP Encapsulation Subsequent Address Family Identifier (SAFI) information exchange often carry a number of identifiable, distinct flows. It can in some circumstances be desirable to distribute these flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Currently, the payload of a packet entering the Softwire can only be interpreted by the ingress and egress routers. Thus the load balancing decision of a core router is only based on the encapsulating header, presenting much less entropy than available in the payload or the encapsulated header since the Softwire encapsulation acts in a tunneling fashion. This document describes a method for achieving comparable load balancing efficiency in a network carrying Softwire mesh service over Layer Two Tunneling Protocol - Version 3 (L2TPv3) over IP or Generic Routing Encapsulation (GRE) encapsulation to what would be achieved without such encapsulation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-lb-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-lb-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-02111859.I-D@ietf.org> --NextPart-- From Priyanka.RAWAT@telecom-bretagne.eu Sun Apr 5 16:39:36 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 928D83A6BBA for ; Sun, 5 Apr 2009 16:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[AWL=1.018, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSOMLI5rbX8c for ; Sun, 5 Apr 2009 16:39:35 -0700 (PDT) Received: from coliposte.enst-bretagne.fr (coliposte.enst-bretagne.fr [192.108.115.12]) by core3.amsl.com (Postfix) with ESMTP id 90D473A6BCE for ; Sun, 5 Apr 2009 16:39:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2006.08.14) with ESMTP id n35Nej8V006375; Mon, 6 Apr 2009 01:40:46 +0200 Received: from courrier.enst-bretagne.fr (smtps.enst-bretagne.fr [10.29.90.4]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2008.01.11) with ESMTP id n35NeeJ5006366; Mon, 6 Apr 2009 01:40:43 +0200 Received: from telecom-bretagne.eu (smtps.telecom-bretagne.eu [10.29.90.4]) by courrier.enst-bretagne.fr (8.13.8/8.13.8/2006.06.07) with ESMTP id n35NeWkq012642; Mon, 6 Apr 2009 01:40:32 +0200 Received: from srv-disi-b1-02.priv.enst-bretagne.fr (srv-disi-b1-02.priv.enst-bretagne.fr [10.29.96.3]) by webmail.telecom-bretagne.eu (Horde Framework) with HTTP; Mon, 06 Apr 2009 01:40:32 +0200 Message-ID: <20090406014032.918035kn05wixcw0@webmail.telecom-bretagne.eu> Date: Mon, 06 Apr 2009 01:40:32 +0200 From: Priyanka.RAWAT@telecom-bretagne.eu To: softwires@ietf.org References: <20090403175026.20034vavsbyxvam8@webmail.telecom-bretagne.eu> In-Reply-To: <20090403175026.20034vavsbyxvam8@webmail.telecom-bretagne.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) /ENSTB X-Originating-IP: 192.44.77.81 X-Virus-Scanned: amavisd-new at enst-bretagne.fr Cc: Priyanka.RAWAT@telecom-bretagne.eu Subject: [Softwires] Tunneling Header Compression 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, 05 Apr 2009 23:39:36 -0000 Hello All A new draft is available at http://tools.ietf.org/search/draft-rawat-hc-tunneling-00 This document specifies a method to compress L2TP encapsulation, which will be useful in reducing overhead due to L2TP encapsulation in wireless networks. It will be interesting for us to receive feedback on this draft. Regards Priyanka Rawat IT/TELECOM Bretagne From teemu.savolainen@nokia.com Mon Apr 6 02:51:01 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20D603A6C1A; Mon, 6 Apr 2009 02:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.666 X-Spam-Level: X-Spam-Status: No, score=-5.666 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] 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 ubakXnLQpz93; Mon, 6 Apr 2009 02:51:00 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 1FCEE3A6BB4; Mon, 6 Apr 2009 02:50:48 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n369pYbD021634; Mon, 6 Apr 2009 12:51:50 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 12:51:49 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 12:51:31 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 6 Apr 2009 11:51:31 +0200 From: To: , Date: Mon, 6 Apr 2009 11:50:55 +0200 Thread-Topic: About UPnP IGD:2 and AddAnyPortmapping() Thread-Index: Acm2nS37z1upCJWIQUKkT5Xf8mehGg== Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F27F29675A3@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_18034D4D7FE9AE48BF19AB1B0EF2729F27F29675A3NOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 06 Apr 2009 09:51:31.0691 (UTC) FILETIME=[4397C3B0:01C9B69D] X-Nokia-AV: Clean Subject: [Softwires] About UPnP IGD:2 and AddAnyPortmapping() 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, 06 Apr 2009 09:51:01 -0000 --_000_18034D4D7FE9AE48BF19AB1B0EF2729F27F29675A3NOKEUMSG01mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, There have been comments regarding UPnP IGD:2 during IETF meetings, mailing= list, and in some I-Ds. Please check out this presentation http://www.upnp.org/resources/documents/= UPnPIGD2vsIGD1d10032009.pdf "UPnP Gateway committee: IGD:2 improvements ov= er IGD:1". Best regards, Teemu --_000_18034D4D7FE9AE48BF19AB1B0EF2729F27F29675A3NOKEUMSG01mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
There have been comments regarding UPnP IGD:2 during IETF meetings, ma= iling list, and in some I-Ds.
 
Please check out this presentation htt= p://www.upnp.org/resources/documents/UPnPIGD2vsIGD1d10032009.pdf=   "UPnP Gateway committee: IGD:2 improvements over IGD:1".
 
Best regards,
 
        Teemu
 
 --_000_18034D4D7FE9AE48BF19AB1B0EF2729F27F29675A3NOKEUMSG01mgd_-- From root@core3.amsl.com Mon Apr 6 10:45:01 2009 Return-Path: X-Original-To: softwires@ietf.org Delivered-To: softwires@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 729E828C158; Mon, 6 Apr 2009 10:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090406174501.729E828C158@core3.amsl.com> Date: Mon, 6 Apr 2009 10:45:01 -0700 (PDT) Cc: softwires@ietf.org Subject: [Softwires] I-D Action:draft-ietf-softwire-encaps-ipsec-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 17:45:01 -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 : BGP IPsec Tunnel Encapsulation Attribute Author(s) : L. Berger, et al. Filename : draft-ietf-softwire-encaps-ipsec-03.txt Pages : 9 Date : 2009-04-06 The BGP Encapsulation Subsequence Address Family Identifiers (SAFI) provides a method for the dynamic exchange of encapsulation information, and the indication of encapsulation protocol types to be used for different next hops. Currently support for GRE, L2TPv3 and IP in IP tunnel types are defined. This document defines support for IPsec tunnel types. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-encaps-ipsec-03.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-encaps-ipsec-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-06104225.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Mon Apr 6 12:58:30 2009 Return-Path: X-Original-To: softwires@ietf.org Delivered-To: softwires@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 6AF3728C240; Mon, 6 Apr 2009 12:58:29 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090406195830.6AF3728C240@core3.amsl.com> Date: Mon, 6 Apr 2009 12:58:30 -0700 (PDT) Cc: softwire mailing list , Internet Architecture Board , softwire chair , RFC Editor Subject: [Softwires] Protocol Action: 'Softwire Mesh Framework' to Proposed Standard 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, 06 Apr 2009 19:58:30 -0000 The IESG has approved the following document: - 'Softwire Mesh Framework ' as a Proposed Standard This document is the product of the Softwires Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-mesh-framework-06.txt Technical Summary The Internet needs to be able to handle both IPv4 and IPv6 packets. However, it is expected that some constituent networks of the Internet will be "single protocol" networks. One kind of single protocol network can parse only IPv4 packets and can process only IPv4 routing information; another kind can parse only IPv6 packets and can process only IPv6 routing information. It is nevertheless required that either kind of single protocol network be able to provide transit service for the "other" protocol. This is done by passing the "other kind" of routing information from one edge of the single protocol network to the other, and by tunneling the "other kind" of data packet from one edge to the other. The tunnels are known as "Softwires". This framework document explains how the routing information and the data packets of one protocol are passed through a single protocol network of the other protocol. The document is careful to specify when this can be done with existing technology, and when it requires the development of new or modified technology. Working Group Summary The SOFTWIRE WG supports the development and advancement of this document. Protocol Quality This document was thoroughly reviewed by WG chairs and WG members, including those with expertise in IPv4 to IPv6 transitions and interworking. Dave Ward is the WG chair shepherd. From fx.lebail@yahoo.com Wed Apr 8 00:33:19 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FAA03A68B0 for ; Wed, 8 Apr 2009 00:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4f6UrTKa+45v for ; Wed, 8 Apr 2009 00:33:18 -0700 (PDT) Received: from web62505.mail.re1.yahoo.com (web62505.mail.re1.yahoo.com [69.147.75.97]) by core3.amsl.com (Postfix) with SMTP id 696983A659C for ; Wed, 8 Apr 2009 00:33:18 -0700 (PDT) Received: (qmail 34218 invoked by uid 60001); 8 Apr 2009 07:34:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1239176065; bh=zA+iD0oYe2JymPtQGZNzdMWjo4fVvQi1HJrrJHe8MzE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=eXDt9+phIXBr5l9zQiqZ8lK/WcZnN7+VlA36fdmLYk4mc1/qHFzmmbRCtdhh5VsAR2j3J86Ul2zNJ6Evif5LgJ9McXPkAWi3w90ZCaYL3xiAZ87/+e4Pvu076hhrELAvolA5eMZXNarjjRCZHTeyKP7ObkXGoMYjvJUPFEDlRGE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=TCORgnB9e0j0VzKz9Kuhs/GlsHrPNGADw+X3359j2/0IaW9+auPcPTf3SzQz780ZZWrpDLMEQTXGHzmwBLkooQdrXqweTHcl5bP/XcVKXoE3iIaO3/Y8E6CqhLcpP7B4VFtDf7Gy/AoFhKKVTUt5fN1XjmuxXbKolzf9vhhPw3w=; Message-ID: <289092.33945.qm@web62505.mail.re1.yahoo.com> X-YMail-OSG: rIzfzNkVM1mYsN5QFVEDdLEF9phGRUU.QdqBgTj5waFNye3lNnxFuB9D2ACB_gFSGKlvopyQgjUbJab1PDFj2Bi5oyp1nYy7MYvC0BIDVJDvkcK3M2P7LHUzTfDCxIWDPMV9y5jqiHGRb_1DZywnUJ6XoOYEvuEnUVPxFAyi6mmCG19V38xGJEZ6IFBMcUjGj0S8FxPxWkaH2I1AlAna9.pxRiXAbzNCg7bnm7j6iEl5TISSTsi2dn7iQD1p0rUW4xqwFq2ze5KqOccKFxGvtzPQSWzZtrHI_ErXwXmto5TSUPr66YNjs6nK0uw8sYNaSXCWUrg6E9Jj2QCPzf1jdQ-- Received: from [193.49.124.107] by web62505.mail.re1.yahoo.com via HTTP; Wed, 08 Apr 2009 00:34:25 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Wed, 8 Apr 2009 00:34:25 -0700 (PDT) From: Francois-Xavier Le Bail To: "David W. Hankins" In-Reply-To: <20090323165534.GC3145@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: softwires@ietf.org Subject: Re: [Softwires] draft-dhankins-softwire-tunnel-option-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: Wed, 08 Apr 2009 07:33:19 -0000 Hello, I suggest to had a reference to RFC 2473 "Generic Packet Tunneling in IPv6 Specification" for the default IPv4-over-IPv6 tunnel encapsulation. Best Regards, Francois-Xavier --- On Mon, 3/23/09, David W. Hankins wrote: > From: David W. Hankins > Subject: [Softwires] draft-dhankins-softwire-tunnel-option-03 > To: softwires@ietf.org > Date: Monday, March 23, 2009, 12:55 PM > I've just submitted > draft-dhankins-softwire-tunnel-option-03 with the > discussed name/reference changes. Minor rework of > OPTION_ORO hints > and a reference to RFC 3315's security section. > > > A new version of I-D, > draft-dhankins-softwire-tunnel-option-03.txt has > > been successfuly submitted by David Hankins and posted > to the IETF > > repository. > > > > Filename: draft-dhankins-softwire-tunnel-option > > Revision: 03 > > Title: Dynamic Host Configuration Protocol Option > for Dual-Stack Lite > > Creation_date: 2009-03-23 > > WG ID: Independent Submission > > Number_of_pages: 5 > > > > Abstract: > > This document describes how Dual-Stack Lite > configuration (the > > Softwire Concentrator (SC)'s address) can be > obtained by a Softwire > > Initiator (SI) via DHCPv6. > > -- > David W. Hankins "If you don't do it right the > first time, > Software Engineer you'll just have to do it > again." > Internet Systems Consortium, Inc. -- Jack T. Hankins > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From xuxh@huawei.com Thu Apr 9 05:46:58 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CD583A6B94 for ; Thu, 9 Apr 2009 05:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.563 X-Spam-Level: * X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[AWL=-0.381, BAYES_00=-2.599, CN_BODY_35=0.339, FRT_FOLLOW1=1.332, FRT_FOLLOW2=0.422, 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 7JpEoW7s5baB for ; Thu, 9 Apr 2009 05:46:57 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 7E5013A6881 for ; Thu, 9 Apr 2009 05:46:57 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHU0026S3H81F@szxga03-in.huawei.com> for softwires@ietf.org; Thu, 09 Apr 2009 20:46:20 +0800 (CST) Received: from x41208a ([10.111.12.94]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KHU00DD93H8K5@szxga03-in.huawei.com> for softwires@ietf.org; Thu, 09 Apr 2009 20:46:20 +0800 (CST) Date: Thu, 09 Apr 2009 20:46:20 +0800 From: Xu Xiaohu In-reply-to: <20090406195830.6AF3728C240@core3.amsl.com> To: 'softwire mailing list' Message-id: <000001c9b911$2eaf41f0$5e0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acm28j0W4Wm5YlkmRDOEE2s1v+ikIACHDHcg Subject: [Softwires] Concern about the inter-AS scenario in which the core transit network consists of multiple ASes//re: Protocol Action: 'Softwire Mesh Framework' to Proposed Standard 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, 09 Apr 2009 12:46:58 -0000 Hi all, I just found in the folliowing draft there is some consideration about = the inter-AS scenario in which the core transit network consists of multiple ASes. However, there seems no complete solution in current draft. I = wonder whether it is possible to convey the tunnel endpoint (the border IPv4/v6 router between IPv4 network and IPv6 network) address by an BGP extended community attribute rather than the nexthop attribute? In this way, the tunnel endpoint address could keep unchanged during travelling across = ASes, and it doesn't require every ASBR along the forwarding path to perform decap/encap operation. Any comment is welcomed. Xiaohu =20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: softwires-bounces@ietf.org=20 > [mailto:softwires-bounces@ietf.org] =B4=FA=B1=ED The IESG > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA4=D4=C27=C8=D5 3:59 > =CA=D5=BC=FE=C8=CB: IETF-Announce > =B3=AD=CB=CD: softwire mailing list; Internet Architecture Board;=20 > softwire chair; RFC Editor > =D6=F7=CC=E2: [Softwires] Protocol Action: 'Softwire Mesh Framework' = to=20 > Proposed Standard >=20 > The IESG has approved the following document: >=20 > - 'Softwire Mesh Framework ' > as a Proposed Standard >=20 > This document is the product of the Softwires Working Group.=20 >=20 > The IESG contact persons are Mark Townsley and Jari Arkko. >=20 > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-softwire-mesh-f > ramework-06.txt >=20 > Technical Summary >=20 > The Internet needs to be able to handle both IPv4 and IPv6 packets. > However, it is expected that some constituent networks of the=20 > Internet will be "single protocol" networks. One kind of=20 > single protocol network can parse only IPv4 packets and can=20 > process only > IPv4 routing information; another kind can parse only IPv6=20 > packets and can process only IPv6 routing information. It is=20 > nevertheless required that either kind of single protocol=20 > network be able to provide transit service for the "other"=20 > protocol. This is done by passing the "other kind" of routing=20 > information from one edge of the single protocol network to=20 > the other, and by tunneling the "other kind" of data packet=20 > from one edge to the other. The tunnels are known as=20 > "Softwires". This framework document explains how the routing=20 > information and the data packets of one protocol are passed=20 > through a single protocol network of the other protocol. The=20 > document is careful to specify when this can be done with=20 > existing technology, and when it requires the development of=20 > new or modified technology. >=20 >=20 > Working Group Summary >=20 > The SOFTWIRE WG supports the development and advancement of=20 > this document. >=20 >=20 > Protocol Quality >=20 > This document was thoroughly reviewed by WG chairs and WG=20 > members, including those with expertise in IPv4 to IPv6=20 > transitions and interworking. >=20 > Dave Ward is the WG chair shepherd. >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From touch@ISI.EDU Tue Apr 7 16:02:47 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4198B3A6A72; Tue, 7 Apr 2009 16:02:47 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7JSOjjho9f4; Tue, 7 Apr 2009 16:02:46 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 1F3E03A6A6D; Tue, 7 Apr 2009 16:02:46 -0700 (PDT) Received: from [75.215.125.96] (96.sub-75-215-125.myvzw.com [75.215.125.96]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n37MsheE003257; Tue, 7 Apr 2009 15:54:45 -0700 (PDT) Message-ID: <49DBD9AF.4040605@isi.edu> Date: Tue, 07 Apr 2009 15:54:39 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Magnus Westerlund References: <49CD09C2.40806@ericsson.com> In-Reply-To: <49CD09C2.40806@ericsson.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Thu, 09 Apr 2009 20:00:52 -0700 Cc: softwires@ietf.org, tcpm@ietf.org Subject: Re: [Softwires] [tcpm] TCP MSS clamping to try to deal with MTU issues in Dual-Stack Lite 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, 07 Apr 2009 23:02:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, The solution has a bug: if TCP traffic uses TCP MD5 or TCP-AO, then it needs to be handled like non-TCP traffic, since MSS revision would destroy the packet's integrity. IMO, this should be handled the simple way - remove the TCP case, and handle all traffic the non-TCP way. Finally, if a NAT ever refuses to reassemble anything, it MUST issue an ICMP too-big IMO. The whole idea of creating a problem (encapsulating, decreasing the effective MSS on a path) then not cleaning it up yourself, or deciding when to clean it up based on *current* assumptions of network traffic is a bad idea and shouldn't be supported. Joe Magnus Westerlund wrote: > Hi, > > There is a proposal to use TCP MSS clamping to deal with MTU issues that > comes from Dual-stack lite's tunnel encapsulation. > > I think it would be good if TCPM could provide some feedback on this > proposal. > > The relevant document and section: > http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-00 > > 7.4. MTU > > > Using an encapsulation (IP in IP or L2TP) to carry IPv4 traffic over > IPv6 will reduce the effective MTU of the datagrams. Unfortunately, > path MTU discovery is not a reliable method to deal with this. As > such a combination of solutions is suggested: > > o For TCP traffic, let the carrier-grade NAT rewrite the MSS in the > first SYN packet to a lower value. > > o For non-TCP traffic, perform fragmentation and reassembly over the > tunnel between the home gateway and the carrier grade NAT. In > practice, this means put the IPv4 packet into a large IPv6 packet > and fragment/reassemble the IPv6 packet at each endpoint of the > tunnel. There is a performance price to pay for this. > Fragmentation is not very expensive, but reassembly can be, > especially on the carrier-grade NAT that would have to keep track > of a lot of flows. However, such a carrier-grade NAT would only > have to perform reassembly for large UDP packets sourced by > customers, not for large UDP packets received by customers. In > other words, streaming video to a customer would not have a > significant impact on the performance of the carrier-grade NAT, > but will require more work on the home gateway side. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknb2a8ACgkQE5f5cImnZrs0ewCg7ScElkpLrz20zSpTMnXuRApa CPsAoIyhk9N9K2fPpEJTyShMKeZNLxD/ =9ob2 -----END PGP SIGNATURE----- From rfc-editor@rfc-editor.org Thu Apr 9 13:18:07 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 043913A6BA3; Thu, 9 Apr 2009 13:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.927 X-Spam-Level: X-Spam-Status: No, score=-16.927 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] 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 UxdVUaYJ3m7a; Thu, 9 Apr 2009 13:18:06 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 0CB833A6827; Thu, 9 Apr 2009 13:18:06 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 0B22B27A973; Thu, 9 Apr 2009 13:17:58 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090409201758.0B22B27A973@bosco.isi.edu> Date: Thu, 9 Apr 2009 13:17:58 -0700 (PDT) X-Mailman-Approved-At: Thu, 09 Apr 2009 20:01:04 -0700 Cc: softwires@ietf.org, rfc-editor@rfc-editor.org Subject: [Softwires] RFC 5512 on The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute 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, 09 Apr 2009 20:18:07 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5512 Title: The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute Author: P. Mohapatra, E. Rosen Status: Standards Track Date: April 2009 Mailbox: pmohapat@cisco.com, erosen@cisco.com Pages: 13 Characters: 30554 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-softwire-encaps-safi-05.txt URL: http://www.rfc-editor.org/rfc/rfc5512.txt In certain situations, transporting a packet from one Border Gateway Protocol (BGP) speaker to another (the BGP next hop) requires that the packet be encapsulated by the first BGP speaker and decapsulated by the second. To support these situations, there needs to be some agreement between the two BGP speakers with regard to the "encapsulation information", i.e., the format of the encapsulation header as well as the contents of various fields of the header. The encapsulation information need not be signaled for all encapsulation types. In cases where signaling is required (such as Layer Two Tunneling Protocol - Version 3 (L2TPv3) or Generic Routing Encapsulation (GRE) with key), this document specifies a method by which BGP speakers can signal encapsulation information to each other. The signaling is done by sending BGP updates using the Encapsulation Subsequent Address Family Identifier (SAFI) and the IPv4 or IPv6 Address Family Identifier (AFI). In cases where no encapsulation information needs to be signaled (such as GRE without key), this document specifies a BGP extended community that can be attached to BGP UPDATE messages that carry payload prefixes in order to indicate the encapsulation protocol type to be used. [STANDARDS TRACK] This document is a product of the Softwires Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From root@core3.amsl.com Mon Apr 13 08:15:01 2009 Return-Path: X-Original-To: softwires@ietf.org Delivered-To: softwires@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5A2D63A69F8; Mon, 13 Apr 2009 08:15:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090413151501.5A2D63A69F8@core3.amsl.com> Date: Mon, 13 Apr 2009 08:15:01 -0700 (PDT) Cc: softwires@ietf.org Subject: [Softwires] I-D Action:draft-ietf-softwire-hs-framework-l2tpv2-13.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 15:15:01 -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 : Softwire Hub & Spoke Deployment Framework with L2TPv2 Author(s) : B. Storer, et al. Filename : draft-ietf-softwire-hs-framework-l2tpv2-13.txt Pages : 42 Date : 2009-04-13 This document describes the framework of the Softwire "Hub and Spoke" solution with the Layer 2 Tunneling Protocol version 2 (L2TPv2). The implementation details specified in this document should be followed to achieve interoperability among different vendor implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-hs-framework-l2tpv2-13.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-hs-framework-l2tpv2-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-13080126.I-D@ietf.org> --NextPart-- From yiu_lee@cable.comcast.com Tue Apr 14 06:04:50 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 952F73A67E6; Tue, 14 Apr 2009 06:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.396 X-Spam-Level: X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJAVbAzWcQvV; Tue, 14 Apr 2009 06:04:49 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id EF14D3A6A37; Tue, 14 Apr 2009 06:04:48 -0700 (PDT) Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.33953122; Tue, 14 Apr 2009 09:02:28 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Apr 2009 09:02:28 -0400 Received: from 198.137.252.126 ([198.137.252.126]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([198.137.252.76]) with Microsoft Exchange Server HTTP-DAV ; Tue, 14 Apr 2009 13:02:13 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Tue, 14 Apr 2009 09:02:07 -0400 From: "Yiu L. Lee" To: Joe Touch , Magnus Westerlund Message-ID: Thread-Topic: [Softwires] [tcpm] TCP MSS clamping to try to deal with MTU issues in Dual-Stack Lite Thread-Index: Acm5iNT/rkjheLTqSaKKqnVN179ifQDeGHg8 In-Reply-To: <49DBD9AF.4040605@isi.edu> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 14 Apr 2009 13:02:28.0599 (UTC) FILETIME=[43BF3070:01C9BD01] Cc: softwires@ietf.org, tcpm@ietf.org Subject: Re: [Softwires] [tcpm] TCP MSS clamping to try to deal with MTU issues in Dual-Stack Lite 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, 14 Apr 2009 13:04:50 -0000 HI Joe, In RFC2385 - Section 2.0 Item 2, it says 2. the TCP header, excluding options, and assuming a checksum of zero Since TCP options are excluded, changing MSS won't affect the MD5 mechanism= , will it? In draft-ietf-tpcm-tcp-auth-opt-04.txt - Section 5 Item 2, it says 2. A TCP option flag. When 0, this flag allows default operation, i.e., TCP options are included in the MAC calculation, with TCP- AO's MAC field zeroed out. When 1, all options (excluding TCP-AO) are excluded from all MAC calculations (skipped over, not simply zeroed). The option flag applies to TCP options in both directions (incoming and outgoing segments). >> The TCP option flag MUST NOT change during a TCP connection. The TCP option flag cannot change during a connection because TCP state is coordinated during connection establishment. TCP lacks a handshake for modifying that state after a connection has been established. Changing MSS could be a problem when TCP option flag is set to 0. When the flag is set to 1, changing MSS is fine, isn't it? Thanks, Yiu=20 =20 On 4/7/09 6:54 PM, "Joe Touch" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi, all, >=20 > The solution has a bug: if TCP traffic uses TCP MD5 or TCP-AO, then it > needs to be handled like non-TCP traffic, since MSS revision would > destroy the packet's integrity. >=20 > IMO, this should be handled the simple way - remove the TCP case, and > handle all traffic the non-TCP way. >=20 > Finally, if a NAT ever refuses to reassemble anything, it MUST issue an > ICMP too-big IMO. The whole idea of creating a problem (encapsulating, > decreasing the effective MSS on a path) then not cleaning it up > yourself, or deciding when to clean it up based on *current* assumptions > of network traffic is a bad idea and shouldn't be supported. >=20 > Joe >=20 > Magnus Westerlund wrote: >> Hi, >>=20 >> There is a proposal to use TCP MSS clamping to deal with MTU issues that >> comes from Dual-stack lite's tunnel encapsulation. >>=20 >> I think it would be good if TCPM could provide some feedback on this >> proposal. >>=20 >> The relevant document and section: >> http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-00 >>=20 >> 7.4. MTU >>=20 >>=20 >> Using an encapsulation (IP in IP or L2TP) to carry IPv4 traffic over >> IPv6 will reduce the effective MTU of the datagrams. Unfortunately, >> path MTU discovery is not a reliable method to deal with this. As >> such a combination of solutions is suggested: >>=20 >> o For TCP traffic, let the carrier-grade NAT rewrite the MSS in the >> first SYN packet to a lower value. >>=20 >> o For non-TCP traffic, perform fragmentation and reassembly over the >> tunnel between the home gateway and the carrier grade NAT. In >> practice, this means put the IPv4 packet into a large IPv6 packet >> and fragment/reassemble the IPv6 packet at each endpoint of the >> tunnel. There is a performance price to pay for this. >> Fragmentation is not very expensive, but reassembly can be, >> especially on the carrier-grade NAT that would have to keep track >> of a lot of flows. However, such a carrier-grade NAT would only >> have to perform reassembly for large UDP packets sourced by >> customers, not for large UDP packets received by customers. In >> other words, streaming video to a customer would not have a >> significant impact on the performance of the carrier-grade NAT, >> but will require more work on the home gateway side. >>=20 >> Cheers >>=20 >> Magnus Westerlund >>=20 >> IETF Transport Area Director & TSVWG Chair >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >=20 > iEYEARECAAYFAknb2a8ACgkQE5f5cImnZrs0ewCg7ScElkpLrz20zSpTMnXuRApa > CPsAoIyhk9N9K2fPpEJTyShMKeZNLxD/ > =3D9ob2 > -----END PGP SIGNATURE----- > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 From touch@ISI.EDU Tue Apr 14 07:25:28 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A407B28C143; Tue, 14 Apr 2009 07:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gENXVAnQgmN8; Tue, 14 Apr 2009 07:25:17 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 7ABF028C102; Tue, 14 Apr 2009 07:25:12 -0700 (PDT) Received: from [192.168.1.44] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n3EEPqfj026073; Tue, 14 Apr 2009 07:25:54 -0700 (PDT) Message-ID: <49E49CF0.6070203@isi.edu> Date: Tue, 14 Apr 2009 07:25:52 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Yiu L. Lee" References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: softwires@ietf.org, tcpm@ietf.org Subject: Re: [Softwires] [tcpm] TCP MSS clamping to try to deal with MTU issues in Dual-Stack Lite 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, 14 Apr 2009 14:25:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yiu L. Lee wrote: > HI Joe, > > In RFC2385 - Section 2.0 Item 2, it says > > 2. the TCP header, excluding options, and assuming a checksum of > zero > > Since TCP options are excluded, changing MSS won't affect the MD5 mechanism, > will it? In TCP MD5, TCP options can be modified and the MD5 hash will not detect it. > In draft-ietf-tpcm-tcp-auth-opt-04.txt - Section 5 Item 2, it says > > 2. A TCP option flag. When 0, this flag allows default operation, > i.e., TCP options are included in the MAC calculation, with TCP- > AO's MAC field zeroed out. When 1, all options (excluding TCP-AO) > are excluded from all MAC calculations (skipped over, not simply > zeroed). The option flag applies to TCP options in both directions > (incoming and outgoing segments). > > >> The TCP option flag MUST NOT change during a TCP connection. > > The TCP option flag cannot change during a connection because TCP > state is coordinated during connection establishment. TCP lacks a > handshake for modifying that state after a connection has been > established. > > Changing MSS could be a problem when TCP option flag is set to 0. When the > flag is set to 1, changing MSS is fine, isn't it? Yes, these are correct. I would assume that the flag is 0, however - there are numerous reasons to want/need to protect other TCP options, e.g., timestamps, to protect the connection from attack. Joe > On 4/7/09 6:54 PM, "Joe Touch" wrote: > > Hi, all, > > The solution has a bug: if TCP traffic uses TCP MD5 or TCP-AO, then it > needs to be handled like non-TCP traffic, since MSS revision would > destroy the packet's integrity. > > IMO, this should be handled the simple way - remove the TCP case, and > handle all traffic the non-TCP way. > > Finally, if a NAT ever refuses to reassemble anything, it MUST issue an > ICMP too-big IMO. The whole idea of creating a problem (encapsulating, > decreasing the effective MSS on a path) then not cleaning it up > yourself, or deciding when to clean it up based on *current* assumptions > of network traffic is a bad idea and shouldn't be supported. > > Joe > > Magnus Westerlund wrote: >>>> Hi, >>>> >>>> There is a proposal to use TCP MSS clamping to deal with MTU issues that >>>> comes from Dual-stack lite's tunnel encapsulation. >>>> >>>> I think it would be good if TCPM could provide some feedback on this >>>> proposal. >>>> >>>> The relevant document and section: >>>> http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-00 >>>> >>>> 7.4. MTU >>>> >>>> >>>> Using an encapsulation (IP in IP or L2TP) to carry IPv4 traffic over >>>> IPv6 will reduce the effective MTU of the datagrams. Unfortunately, >>>> path MTU discovery is not a reliable method to deal with this. As >>>> such a combination of solutions is suggested: >>>> >>>> o For TCP traffic, let the carrier-grade NAT rewrite the MSS in the >>>> first SYN packet to a lower value. >>>> >>>> o For non-TCP traffic, perform fragmentation and reassembly over the >>>> tunnel between the home gateway and the carrier grade NAT. In >>>> practice, this means put the IPv4 packet into a large IPv6 packet >>>> and fragment/reassemble the IPv6 packet at each endpoint of the >>>> tunnel. There is a performance price to pay for this. >>>> Fragmentation is not very expensive, but reassembly can be, >>>> especially on the carrier-grade NAT that would have to keep track >>>> of a lot of flows. However, such a carrier-grade NAT would only >>>> have to perform reassembly for large UDP packets sourced by >>>> customers, not for large UDP packets received by customers. In >>>> other words, streaming video to a customer would not have a >>>> significant impact on the performance of the carrier-grade NAT, >>>> but will require more work on the home gateway side. >>>> >>>> Cheers >>>> >>>> Magnus Westerlund >>>> >>>> IETF Transport Area Director & TSVWG Chair >>>> ---------------------------------------------------------------------- >>>> Multimedia Technologies, Ericsson Research EAB/TVM >>>> ---------------------------------------------------------------------- >>>> Ericsson AB | Phone +46 10 7148287 >>>> Färögatan 6 | Mobile +46 73 0949079 >>>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >>>> ---------------------------------------------------------------------- >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknknO8ACgkQE5f5cImnZrv7owCghgf+Mq4n0Oth93iaA3mPLkO6 2jcAoKcufMum39GbkG3rMhG/WD5BlE1c =kvbr -----END PGP SIGNATURE----- From dward@cisco.com Thu Apr 23 14:06:06 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15CC13A7312; Thu, 23 Apr 2009 14:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VnoSDy0qf9M; Thu, 23 Apr 2009 14:06:05 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C3E063A72BE; Thu, 23 Apr 2009 14:06:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,237,1238976000"; d="scan'208,217";a="42590613" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 23 Apr 2009 21:07:22 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3NL7MYe006773; Thu, 23 Apr 2009 17:07:22 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3NL7MS4025418; Thu, 23 Apr 2009 21:07:22 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 17:07:22 -0400 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 17:07:21 -0400 Message-Id: <5EE53708-2D8B-4DFB-8365-27041AACB0BE@cisco.com> From: David Ward To: softwires@ietf.org, l3vpn@ietf.org, pwe3@ietf.org, Ralph Droms , Jari Arkko Content-Type: multipart/alternative; boundary=Apple-Mail-6-220634604 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 23 Apr 2009 16:07:19 -0500 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 23 Apr 2009 21:07:21.0896 (UTC) FILETIME=[7E6BC280:01C9C457] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1275; t=1240520842; x=1241384842; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20WG=20LC=20softwire-lb |Sender:=20 |To:=20softwires@ietf.org,=20l3vpn@ietf.org,=20pwe3@ietf.or g,=0A=20=20=20=20=20=20=20=20Ralph=20Droms=20,=20Jari=20Arkko=20; bh=YHBPf2MZluD4AJ4bzzOApyLxmi6XzDJ/2uuyDX1GuMw=; b=h5P3sauBsJ6RGQ0ukhh9v2mevtTYsMBSqZbXbUBD+Qd2SmIfmP06153evy J7sdgI2PeADwXT9cdQ33mz4CytTxnCMu8U+JwPZQdoYQshZl/I8DGeDItrw9 Nl8Lgmii1I; Authentication-Results: rtp-dkim-1; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Mailman-Approved-At: Fri, 24 Apr 2009 07:39:15 -0700 Cc: Alain Durand , Carlos Pignataro , Clarence Filsfils Subject: [Softwires] WG LC softwire-lb 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, 23 Apr 2009 21:06:06 -0000 --Apple-Mail-6-220634604 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit All - Following the last IETF meeting all comments have been addressed in: http://tools.ietf.org/html/draft-ietf-softwire-lb-02 The authors have requested a WG LC and I have added L3VPN and PWE3 that may be interested and have comments on the technology. Please send back all comments by May 7, 2009. Thanks DWard, Alain --Apple-Mail-6-220634604 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit All -
Following the last IETF meeting all comments have been addressed in:



The authors have requested a WG LC and I have added L3VPN and PWE3 that may be interested and have comments on the technology. Please send back all comments by May 7, 2009.

Thanks

DWard, Alain
--Apple-Mail-6-220634604-- From robert@raszuk.net Fri Apr 24 01:57:16 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CB133A6E95 for ; Fri, 24 Apr 2009 01:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYIIE7yHRtqF for ; Fri, 24 Apr 2009 01:57:15 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id F146A3A6EB5 for ; Fri, 24 Apr 2009 01:57:10 -0700 (PDT) Received: (qmail 3738 invoked by uid 399); 24 Apr 2009 08:31:48 -0000 Received: from unknown (HELO ?172.30.29.64?) (80.187.215.123) by mail37.opentransfer.com with SMTP; 24 Apr 2009 08:31:48 -0000 Message-ID: <49F178ED.2080905@raszuk.net> Date: Fri, 24 Apr 2009 01:31:41 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Ward References: <5EE53708-2D8B-4DFB-8365-27041AACB0BE@cisco.com> In-Reply-To: <5EE53708-2D8B-4DFB-8365-27041AACB0BE@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 24 Apr 2009 07:39:15 -0700 Cc: Carlos Pignataro , l3vpn@ietf.org, Clarence Filsfils , Ralph Droms , Alain Durand , softwires@ietf.org, pwe3@ietf.org Subject: Re: [Softwires] WG LC softwire-lb X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 08:57:16 -0000 Hi David, Perhaps I may have missed the discussion on this in the other WGs but I have two comments/questions ... * Why the decision on enhancing the load balancing capability of IP encapsulated packet has to be signaled as opposed to be a local matter of the ingress router performing encapsulation ? * Reg use of GRE key for the purpose of load balancing I must say that GRE key has already been proposed in number of solutions today. Therefor overloading more on it may be impractical. Did authors analyzed use of Sequence Numbers in GRE header instead for the purpose of increasing effectiveness of load-balancing by the transit nodes ? Cheers, R. > All - > Following the last IETF meeting all comments have been addressed in: > > http://tools.ietf.org/html/draft-ietf-softwire-lb-02 > > The authors have requested a WG LC and I have added L3VPN and PWE3 that > may be interested and have comments on the technology. Please send back > all comments by May 7, 2009. > > Thanks > > DWard, Alain From wwwrun@core3.amsl.com Tue Apr 28 13:09:07 2009 Return-Path: X-Original-To: softwires@ietf.org Delivered-To: softwires@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 7E8E93A6929; Tue, 28 Apr 2009 13:09:07 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090428200907.7E8E93A6929@core3.amsl.com> Date: Tue, 28 Apr 2009 13:09:07 -0700 (PDT) Cc: softwire mailing list , Internet Architecture Board , softwire chair , RFC Editor Subject: [Softwires] Protocol Action: 'BGP IPsec Tunnel Encapsulation Attribute' to Proposed Standard 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, 28 Apr 2009 20:09:07 -0000 The IESG has approved the following document: - 'BGP IPsec Tunnel Encapsulation Attribute ' as a Proposed Standard This document is the product of the Softwires Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-encaps-ipsec-03.txt Technical Summary The BGP Encapsulation Subsequence Address Family Identifiers (SAFI) provides a method for the dynamic exchange of encapsulation information, and the indication of encapsulation protocol types to be used for different next hops. Currently support for GRE and L2TPv3 tunnel types are defined. This document defines support for IPsec tunnel types. Working Group Summary The SOFTWIRE WG supports the development and advancement of this document. Protocol Quality This document was thoroughly reviewed by WG chairs and WG members, including those with expertise in IPv4 to IPv6 transitions and interworking. Dave Ward is the WG chair shepherd. Ralph Droms is the responsible Area director. From cpignata@cisco.com Wed Apr 29 08:22:18 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CCB03A67F3; Wed, 29 Apr 2009 08:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.262 X-Spam-Level: X-Spam-Status: No, score=-6.262 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tB1MBWoEcw4U; Wed, 29 Apr 2009 08:22:17 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 1E3063A715A; Wed, 29 Apr 2009 08:22:16 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n3TFNbX4025253; Wed, 29 Apr 2009 11:23:37 -0400 (EDT) Received: from [64.102.157.114] (dhcp-64-102-157-114.cisco.com [64.102.157.114]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n3TFNaJe023981; Wed, 29 Apr 2009 11:23:37 -0400 (EDT) Message-ID: <49F870F8.9070301@cisco.com> Date: Wed, 29 Apr 2009 11:23:36 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090302 Thunderbird/2.0.0.21 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: robert@raszuk.net References: <5EE53708-2D8B-4DFB-8365-27041AACB0BE@cisco.com> <49F178ED.2080905@raszuk.net> In-Reply-To: <49F178ED.2080905@raszuk.net> X-Enigmail-Version: 0.95.7 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: l3vpn@ietf.org, Clarence Filsfils , Ralph Droms , Alain Durand , pwe3@ietf.org, softwires@ietf.org Subject: Re: [Softwires] WG LC softwire-lb 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, 29 Apr 2009 15:22:18 -0000 Hi Robert, Thank you for your comments, please see inline. On 4/24/2009 4:31 AM, Robert Raszuk wrote: > Hi David, > > Perhaps I may have missed the discussion on this in the other WGs but I > have two comments/questions ... > > * Why the decision on enhancing the load balancing capability of IP > encapsulated packet has to be signaled as opposed to be a local matter > of the ingress router performing encapsulation ? This is because the load-balancing field is signaled (see RFC5512), so using for lb it needs signaling of a block to avoid collisions. Note also the context from the title, lb for Mesh Softwires. For the L2TPv3 case, and from , the only encapsulating header field that is always there is the Session ID (Cookie is optional), which is signaled; the case for GRE is equivalent, but also please see below. If it's only a local matter, the encapsulating header's fields could not be used and you would be limited to playing with e.g., the source IP address. > > * Reg use of GRE key for the purpose of load balancing I must say that > GRE key has already been proposed in number of solutions today. Therefor > overloading more on it may be impractical. Did authors analyzed use of > Sequence Numbers in GRE header instead for the purpose of increasing > effectiveness of load-balancing by the transit nodes ? Yes, it was considered, but we need a field that can be used for flow identification. From RFC2890, the seq # MUST be used by the receiver to establish packet transmission order, so it's incompatible with a per-flow use. The GRE Key's semantics from RFC2890 match this use, : The Key field contains a four octet number which was inserted by the encapsulator. The actual method by which this Key is obtained is beyond the scope of the document. The Key field is intended to be used for identifying an individual traffic flow within a tunnel. Thanks, -- Carlos. > > Cheers, > R. > > >> All - >> Following the last IETF meeting all comments have been addressed in: >> >> http://tools.ietf.org/html/draft-ietf-softwire-lb-02 >> >> The authors have requested a WG LC and I have added L3VPN and PWE3 that >> may be interested and have comments on the technology. Please send back >> all comments by May 7, 2009. >> >> Thanks >> >> DWard, Alain > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From robert@raszuk.net Wed Apr 29 11:39:03 2009 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE1933A6BCB for ; Wed, 29 Apr 2009 11:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xoaGGY7rulB for ; Wed, 29 Apr 2009 11:39:02 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 9A95C3A6C41 for ; Wed, 29 Apr 2009 11:39:02 -0700 (PDT) Received: (qmail 9969 invoked by uid 399); 29 Apr 2009 18:40:24 -0000 Received: from unknown (HELO ?192.168.1.53?) (83.24.6.88) by mail37.opentransfer.com with SMTP; 29 Apr 2009 18:40:24 -0000 Message-ID: <49F89F15.2000801@raszuk.net> Date: Wed, 29 Apr 2009 11:40:21 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Carlos Pignataro References: <5EE53708-2D8B-4DFB-8365-27041AACB0BE@cisco.com> <49F178ED.2080905@raszuk.net> <49F870F8.9070301@cisco.com> In-Reply-To: <49F870F8.9070301@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org Subject: Re: [Softwires] WG LC softwire-lb X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 18:39:03 -0000 Hi Carlos, Perhaps I was not very clear in the question. I understand that you are adding the ability for ingress where for L2TPv3 over IP - Session ID & for GRE - GRE key are distributed per egress as per RFC5512. This is great ! But what I was mainly asking about was the case where egress does not signal GRE key. Per 5512 is seems very well allowed as key is optional: "Note that the key is optional. Unless a key value is being advertised, the GRE encapsulation sub-TLV MUST NOT be present." Then if one would read carefully your draft is says there: "Needless to say, if an egress router does not support load balancing block sub-TLV, the Softwire continues to operate with a single load balancing field that all ingress routers encapsulate with." But since the whole purpose is to provide some additional field in the IP encapsulation header other then play with src address for core routers doing ECMP shouldn't we mention some text allowing for local ingress PE injection of random keys when such a keys are not required by application using 5512 for it's mesh tunnel setup ? As to my second question I agree. In fact your proposal allows for sort of overloading the GRE key semantics to serve both for given application as well as for core load-balancing. Many thx, R. > Hi Robert, > > Thank you for your comments, please see inline. > > On 4/24/2009 4:31 AM, Robert Raszuk wrote: >> Hi David, >> >> Perhaps I may have missed the discussion on this in the other WGs but I >> have two comments/questions ... >> >> * Why the decision on enhancing the load balancing capability of IP >> encapsulated packet has to be signaled as opposed to be a local matter >> of the ingress router performing encapsulation ? > > This is because the load-balancing field is signaled (see RFC5512), so > using for lb it needs signaling of a block to avoid collisions. Note > also the context from the title, lb for Mesh Softwires. For the L2TPv3 > case, and from , the > only encapsulating header field that is always there is the Session ID > (Cookie is optional), which is signaled; the case for GRE is equivalent, > but also please see below. If it's only a local matter, the > encapsulating header's fields could not be used and you would be limited > to playing with e.g., the source IP address. > >> * Reg use of GRE key for the purpose of load balancing I must say that >> GRE key has already been proposed in number of solutions today. Therefor >> overloading more on it may be impractical. Did authors analyzed use of >> Sequence Numbers in GRE header instead for the purpose of increasing >> effectiveness of load-balancing by the transit nodes ? > > Yes, it was considered, but we need a field that can be used for flow > identification. From RFC2890, the seq # MUST be used by the receiver to > establish packet transmission order, so it's incompatible with a > per-flow use. The GRE Key's semantics from RFC2890 match this use, > : > > The Key field contains a four octet number which was inserted by the > encapsulator. The actual method by which this Key is obtained is > beyond the scope of the document. The Key field is intended to be > used for identifying an individual traffic flow within a tunnel. > > Thanks, > > -- Carlos. > > > >> Cheers, >> R. >> >> >>> All - >>> Following the last IETF meeting all comments have been addressed in: >>> >>> http://tools.ietf.org/html/draft-ietf-softwire-lb-02 >>> >>> The authors have requested a WG LC and I have added L3VPN and PWE3 that >>> may be interested and have comments on the technology. Please send back >>> all comments by May 7, 2009. >>> >>> Thanks >>> >>> DWard, Alain >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > >