From xing@cernet.edu.cn Thu Apr 1 01:58:45 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 013733A67E1 for ; Thu, 1 Apr 2010 01:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.082 X-Spam-Level: ** X-Spam-Status: No, score=2.082 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_HAS_XAIMC=2.696, 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 sEPb4YXXIgSD for ; Thu, 1 Apr 2010 01:58:44 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id E8DB93A672F for ; Thu, 1 Apr 2010 01:58:33 -0700 (PDT) Received: from [202.112.35.220]([202.112.35.220]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm64bb48573; Thu, 01 Apr 2010 16:58:59 +0800 Message-ID: <4BB46056.9000903@cernet.edu.cn> Date: Thu, 01 Apr 2010 16:59:02 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christian Huitema References: <02d001cad0f5$41ef7ee0$0600a8c0@china.huawei.com> <6B55F0F93C3E9D45AF283313B8D342BA6863C744@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF65139210A3@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <034501cad120$f96c8d80$0600a8c0@china.huawei.com> <6B55F0F93C3E9D45AF283313B8D342BA6863CDC6@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA6863CDC6@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: SztOQxXB Cc: "behave@ietf.org" , David Harrington , Dave Thaler Subject: Re: [BEHAVE] address-format secure configuration X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 08:58:45 -0000 Christian Huitema 写道: > Do you want to replace the security section by a simple statement that "This document only defines address formats and does not create any new security concerns?" > > We can certainly do that, but I would rather make sure that the concerns that we raise get documented somewhere. Clearly, address translation opens interesting opportunities for address spoofing and "interesting" configurations. > > Spoofing is mostly an issue with stateless address translation, which allows nodes to specify in an IPv6 address the IPv4 translation. We may want to move that text to the "stateless translation" draft. Prefix configuration is an issue with any time of translation, and should probably be addressed in the framework document. > The current framework document reads 7. Security Considerations "This document is the framework of IPv4/IPv6 translation. The security issues are addressed in individual IPv4/IPv6 translation documents, i.e. [I-D.ietf-behave-address-format], [I-D.ietf-behave-v6v4-xlate], [I-D.ietf-behave-v6v4-xlate-stateful], [I-D.ietf-behave-dns64], and [I-D.ietf-behave-ftp64]." The current xlate document reads 6. Security Considerations "There are potential issues that might arise by deriving an IPv4 address from an IPv6 address - particularly addresses like broadcast or loopback addresses and the non IPv4-translatable IPv6 addresses, etc. The [I-D.ietf-behave-address-format] addresses these issues." Should we change this format? regards, xing, congxiao > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Wednesday, March 31, 2010 3:25 PM > To: Dave Thaler > Cc: Christian Huitema; behave@ietf.org > Subject: RE: [BEHAVE] address-format secure configuration > > Hi, > > I raised the issue of secure configuration because the document does. > > I probably wouldn't really have noticed this section much except that > the section asserts that using a default prefix addresses security > concerns, and I disagree with that. > > I would be fine with pointers to other documents, such as > draft-carpenter-renum-needs-work, and maybe v6 autoconfig documents > and/or DHCP security. > I would be fine with a pointer to one of the behave documents that > addresses the concern, or > to a v6ops document that addresses the concern. > (I think but might change my mind) I would even be fine with a > statement that this document only defines address formats and does not > create any new security concerns. > > But to observe in the security considerations that multiple devices > and applications need to be configured consistently and securely, and > then not provide any guidance or pointers to guidance seems wrong to > me. > > dbh > > >> -----Original Message----- >> From: Dave Thaler [mailto:dthaler@microsoft.com] >> Sent: Wednesday, March 31, 2010 5:16 PM >> To: David Harrington >> Cc: Christian Huitema; behave@ietf.org >> Subject: RE: [BEHAVE] address-format secure configuration >> >> To second what Christian said, if you look at RFC 4291 it contains >> no discussion of secure configuration, it defines address formats. >> This draft is no different. >> >> Configuration mechanisms are outside the scope of this document. >> I don't believe the things you raise belong in this document. >> They could be in a separate document for which we could add a >> milestone as part of the rechartering. >> >> -Dave >> >> >>> -----Original Message----- >>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >>> Behalf Of Christian Huitema >>> Sent: Wednesday, March 31, 2010 1:57 PM >>> To: David Harrington; behave@ietf.org >>> Subject: Re: [BEHAVE] address-format secure configuration >>> >>> David, >>> >>> We do not describe configuration in this document, we >>> >> merely describe >> >>> address format. Configuration is indeed important, but do you >>> > really > >>> believe that it should be part of this document? What about >>> >> the other >> >>> documents in the working set, e.g. the description of stateful and >>> stateless address translation? Or the framework document? >>> >> The note in >> >>> the security section is meant to flag the issue, not to resolve >>> > it. > >>> -- Christian Huitema >>> >>> >>> -----Original Message----- >>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >>> Behalf Of David Harrington >>> Sent: Wednesday, March 31, 2010 10:12 AM >>> To: behave@ietf.org >>> Subject: [BEHAVE] address-format secure configuration >>> >>> Hi, >>> >>> I think section 4.2 Secure Configuration is inadequate. The >>> >> discussion >> >>> of configuration is inadequate, and the discussion of security is >>> inadequate. >>> >>> Configuration will require some synchronization if the values >>> > should > >>> change. Specifying a default prefix might provide an initial >>> synchronization, but does not address the difficult >>> >> operational issue >> >>> of synchronization of changes to the deployed prefixes and >>> > formats. > >>> The document does not discuss the operational and security >>> vulnerabilties exposed during the process of changing a prefix. >>> >>> Secure configuration of prefixes and formats across multiple >>> > devices > >>> and applications in a network will require some type of >>> >> authentication >> >>> and authorization, and protection from various possible >>> >> attacks, such >> >>> as man in the middle attacks. A default prefix does not address >>> > the > >>> security issues involved in secure configuration, as far as >>> >> I can see. >> >>> I think work needs to be done on this section. I recommend >>> >> addressing >> >>> the operational considerations of deploying a change of >>> >> prefix across >> >>> a network, and separately identifying and addressing the threats >>> involved in prefix configuration. >>> >>> >>> David Harrington >>> dbharrington@comcast.net >>> ietfdbh@comcast.net >>> dharrington@huawei.com >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >> > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > From brian.e.carpenter@gmail.com Thu Apr 1 05:27:43 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 774523A78D8 for ; Thu, 1 Apr 2010 05:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.136 X-Spam-Level: X-Spam-Status: No, score=-1.136 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 jMuoAC-5PDnZ for ; Thu, 1 Apr 2010 05:27:42 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 8A3463A6BFF for ; Thu, 1 Apr 2010 05:16:34 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so332413qwb.31 for ; Thu, 01 Apr 2010 05:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=578KbijOMXW9rzncMuigVu4Eup3w520WVOZgog0CWvM=; b=TKVRB37zfNcijs6sznnK7BBBnEEsa2iZykpF4ONu20i5JTk+QNxNKS5gdE3Kq3m2Hr y7IaOCqeBXIXViUvFXY/MwiXVf7GDdr4SzLRun0907v2L2j5eogNjGHbIjWEmHtD2GNT 8Ix/m5mieBowJbygTal7t5BG5TDBpY+nRYLj8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=csG7cRwQ/k5pGOLseggN3V7+jl5l73KfWeWGQzEyDQGkZNvvDgJPwBPizuPgyfNNlp PEb7s7YNbhtaLoHXsPb6rP/tyRaoKlJILKAXmjvT2tuCqjGtz8g3gMNLUCfE9/9Bn5qy NaeqS3o0OgIDUssxrIo0grAGLOgTmgtQHlSXo= Received: by 10.229.213.140 with SMTP id gw12mr1180722qcb.96.1270124185882; Thu, 01 Apr 2010 05:16:25 -0700 (PDT) Received: from [172.16.1.8] (12-50-201-66.att-inc.com [12.50.201.66]) by mx.google.com with ESMTPS id 2sm3173549qwi.29.2010.04.01.05.16.23 (version=SSLv3 cipher=RC4-MD5); Thu, 01 Apr 2010 05:16:25 -0700 (PDT) Message-ID: <4BB48E90.5030209@gmail.com> Date: Fri, 02 Apr 2010 01:16:16 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Xing Li References: <02d001cad0f5$41ef7ee0$0600a8c0@china.huawei.com> <6B55F0F93C3E9D45AF283313B8D342BA6863C744@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF65139210A3@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <034501cad120$f96c8d80$0600a8c0@china.huawei.com> <6B55F0F93C3E9D45AF283313B8D342BA6863CDC6@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <4BB46056.9000903@cernet.edu.cn> In-Reply-To: <4BB46056.9000903@cernet.edu.cn> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: David Harrington , "behave@ietf.org" , Dave Thaler Subject: Re: [BEHAVE] address-format secure configuration X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 12:27:43 -0000 I understood Dave to be commenting on a dangling reference in the specific text in the address format draft. That is a reasonable comment, since dangling references are always bad. My personal view (already expressed) is that the particular point is more of a v6ops question, but I didn't see Dave raising a general point about the whole set of documents. Regards Brian Carpenter On 2010-04-01 21:59, Xing Li wrote: > Christian Huitema =E5=86=99=E9=81=93: >> Do you want to replace the security section by a simple statement that= >> "This document only defines address formats and does not create any >> new security concerns?" >> >> We can certainly do that, but I would rather make sure that the >> concerns that we raise get documented somewhere. Clearly, address >> translation opens interesting opportunities for address spoofing and >> "interesting" configurations. >> Spoofing is mostly an issue with stateless address translation, which >> allows nodes to specify in an IPv6 address the IPv4 translation. We >> may want to move that text to the "stateless translation" draft. >> Prefix configuration is an issue with any time of translation, and >> should probably be addressed in the framework document. >> =20 >=20 > The current framework document reads >=20 > 7. Security Considerations >=20 > "This document is the framework of IPv4/IPv6 translation. The > security issues are addressed in individual IPv4/IPv6 translation > documents, i.e. [I-D.ietf-behave-address-format], > [I-D.ietf-behave-v6v4-xlate], [I-D.ietf-behave-v6v4-xlate-stateful], > [I-D.ietf-behave-dns64], and [I-D.ietf-behave-ftp64]." >=20 >=20 > The current xlate document reads >=20 > 6. Security Considerations >=20 > "There are potential issues that might arise by deriving an IPv4 > address from an IPv6 address - particularly addresses like broadcast > or loopback addresses and the non IPv4-translatable IPv6 addresses, > etc. The [I-D.ietf-behave-address-format] addresses these issues." >=20 > Should we change this format? >=20 > regards, >=20 > xing, congxiao >=20 >> -----Original Message----- >> From: David Harrington [mailto:ietfdbh@comcast.net] Sent: Wednesday, >> March 31, 2010 3:25 PM >> To: Dave Thaler >> Cc: Christian Huitema; behave@ietf.org >> Subject: RE: [BEHAVE] address-format secure configuration >> >> Hi, >> >> I raised the issue of secure configuration because the document does. >> >> I probably wouldn't really have noticed this section much except that >> the section asserts that using a default prefix addresses security >> concerns, and I disagree with that. >> >> I would be fine with pointers to other documents, such as >> draft-carpenter-renum-needs-work, and maybe v6 autoconfig documents >> and/or DHCP security. >> I would be fine with a pointer to one of the behave documents that >> addresses the concern, or >> to a v6ops document that addresses the concern. (I think but might >> change my mind) I would even be fine with a >> statement that this document only defines address formats and does not= >> create any new security concerns. >> >> But to observe in the security considerations that multiple devices >> and applications need to be configured consistently and securely, and >> then not provide any guidance or pointers to guidance seems wrong to >> me. >> >> dbh >> >> =20 >>> -----Original Message----- >>> From: Dave Thaler [mailto:dthaler@microsoft.com] Sent: Wednesday, >>> March 31, 2010 5:16 PM >>> To: David Harrington >>> Cc: Christian Huitema; behave@ietf.org >>> Subject: RE: [BEHAVE] address-format secure configuration >>> >>> To second what Christian said, if you look at RFC 4291 it contains >>> no discussion of secure configuration, it defines address formats. >>> This draft is no different. >>> >>> Configuration mechanisms are outside the scope of this document. >>> I don't believe the things you raise belong in this document. >>> They could be in a separate document for which we could add a >>> milestone as part of the rechartering. >>> >>> -Dave >>> >>> =20 >>>> -----Original Message----- >>>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >>>> Behalf Of Christian Huitema >>>> Sent: Wednesday, March 31, 2010 1:57 PM >>>> To: David Harrington; behave@ietf.org >>>> Subject: Re: [BEHAVE] address-format secure configuration >>>> >>>> David, >>>> >>>> We do not describe configuration in this document, we =20 >>> merely describe >>> =20 >>>> address format. Configuration is indeed important, but do you >>>> =20 >> really >> =20 >>>> believe that it should be part of this document? What about =20 >>> the other >>> =20 >>>> documents in the working set, e.g. the description of stateful and >>>> stateless address translation? Or the framework document? =20 >>> The note in >>> =20 >>>> the security section is meant to flag the issue, not to resolve >>>> =20 >> it. >> =20 >>>> -- Christian Huitema >>>> >>>> >>>> -----Original Message----- >>>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >>>> Behalf Of David Harrington >>>> Sent: Wednesday, March 31, 2010 10:12 AM >>>> To: behave@ietf.org >>>> Subject: [BEHAVE] address-format secure configuration >>>> >>>> Hi, >>>> >>>> I think section 4.2 Secure Configuration is inadequate. The =20 >>> discussion >>> =20 >>>> of configuration is inadequate, and the discussion of security is >>>> inadequate. >>>> >>>> Configuration will require some synchronization if the values >>>> =20 >> should >> =20 >>>> change. Specifying a default prefix might provide an initial >>>> synchronization, but does not address the difficult =20 >>> operational issue >>> =20 >>>> of synchronization of changes to the deployed prefixes and >>>> =20 >> formats. >> =20 >>>> The document does not discuss the operational and security >>>> vulnerabilties exposed during the process of changing a prefix. >>>> >>>> Secure configuration of prefixes and formats across multiple >>>> =20 >> devices >> =20 >>>> and applications in a network will require some type of =20 >>> authentication >>> =20 >>>> and authorization, and protection from various possible =20 >>> attacks, such >>> =20 >>>> as man in the middle attacks. A default prefix does not address >>>> =20 >> the >> =20 >>>> security issues involved in secure configuration, as far as =20 >>> I can see. >>> =20 >>>> I think work needs to be done on this section. I recommend =20 >>> addressing >>> =20 >>>> the operational considerations of deploying a change of =20 >>> prefix across >>> =20 >>>> a network, and separately identifying and addressing the threats >>>> involved in prefix configuration. >>>> >>>> >>>> David Harrington >>>> dbharrington@comcast.net >>>> ietfdbh@comcast.net >>>> dharrington@huawei.com >>>> >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >>>> >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >>>> =20 >>> =20 >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >> >> =20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From ietfdbh@comcast.net Thu Apr 1 06:21:37 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96B3D3A67FA for ; Thu, 1 Apr 2010 06:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.147 X-Spam-Level: X-Spam-Status: No, score=0.147 tagged_above=-999 required=5 tests=[AWL=1.016, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 KXD4arWDlv4S for ; Thu, 1 Apr 2010 06:21:35 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 192503A6808 for ; Thu, 1 Apr 2010 06:21:25 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta09.westchester.pa.mail.comcast.net with comcast id 0Aej1e00927AodY59DMtL5; Thu, 01 Apr 2010 13:21:53 +0000 Received: from Harrington73653 ([67.189.235.106]) by omta19.westchester.pa.mail.comcast.net with comcast id 0DRY1e00D2JQnJT3fDRYr6; Thu, 01 Apr 2010 13:25:32 +0000 From: "David Harrington" To: "'Christian Huitema'" , "'Dave Thaler'" References: <02d001cad0f5$41ef7ee0$0600a8c0@china.huawei.com> <6B55F0F93C3E9D45AF283313B8D342BA6863C744@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF65139210A3@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <034501cad120$f96c8d80$0600a8c0@china.huawei.com> <6B55F0F93C3E9D45AF283313B8D342BA6863CDC6@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 1 Apr 2010 09:21:51 -0400 Message-ID: <03e401cad19e$4adaed60$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcrQ9K6JpQsxSoblR0isFoLny4+YRQAH3U6QAAC7V+AAAgV/IAAESfKAABsoiaA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA6863CDC6@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> Cc: behave@ietf.org Subject: Re: [BEHAVE] address-format secure configuration X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 13:21:38 -0000 > We can certainly do that, but I would rather make sure that > the concerns that we raise get documented somewhere. I would like two things: 1) the statement that default prefixes solve this problem needs to be reworded, since it seems obvious that default prefixes alone do not provide secure or synchronized configuration, especially for prefix changes. I think the current section doesn't adequately identify the issues that should be considered, so the rewording should mention the synchronization and security issues in a **bit** more detail. 2) the secure configuration section of the current document should point to documents where the concerns raised by address translation get discussed in more detail, and preferably operational guidance is provided in those documents. The documents might be other behave documents or v6ops documents or other documents. I think those changes should be fairly simple. dbh > -----Original Message----- > From: Christian Huitema [mailto:huitema@microsoft.com] > Sent: Wednesday, March 31, 2010 8:24 PM > To: David Harrington; Dave Thaler > Cc: behave@ietf.org > Subject: RE: [BEHAVE] address-format secure configuration > > Do you want to replace the security section by a simple > statement that "This document only defines address formats > and does not create any new security concerns?" > > We can certainly do that, but I would rather make sure that > the concerns that we raise get documented somewhere. Clearly, > address translation opens interesting opportunities for > address spoofing and "interesting" configurations. > > Spoofing is mostly an issue with stateless address > translation, which allows nodes to specify in an IPv6 address > the IPv4 translation. We may want to move that text to the > "stateless translation" draft. Prefix configuration is an > issue with any time of translation, and should probably be > addressed in the framework document. > > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Wednesday, March 31, 2010 3:25 PM > To: Dave Thaler > Cc: Christian Huitema; behave@ietf.org > Subject: RE: [BEHAVE] address-format secure configuration > > Hi, > > I raised the issue of secure configuration because the document does. > > I probably wouldn't really have noticed this section much except that > the section asserts that using a default prefix addresses security > concerns, and I disagree with that. > > I would be fine with pointers to other documents, such as > draft-carpenter-renum-needs-work, and maybe v6 autoconfig documents > and/or DHCP security. > I would be fine with a pointer to one of the behave documents that > addresses the concern, or > to a v6ops document that addresses the concern. > (I think but might change my mind) I would even be fine with a > statement that this document only defines address formats and does not > create any new security concerns. > > But to observe in the security considerations that multiple devices > and applications need to be configured consistently and securely, and > then not provide any guidance or pointers to guidance seems wrong to > me. > > dbh > > > -----Original Message----- > > From: Dave Thaler [mailto:dthaler@microsoft.com] > > Sent: Wednesday, March 31, 2010 5:16 PM > > To: David Harrington > > Cc: Christian Huitema; behave@ietf.org > > Subject: RE: [BEHAVE] address-format secure configuration > > > > To second what Christian said, if you look at RFC 4291 it contains > > no discussion of secure configuration, it defines address formats. > > This draft is no different. > > > > Configuration mechanisms are outside the scope of this document. > > I don't believe the things you raise belong in this document. > > They could be in a separate document for which we could add a > > milestone as part of the rechartering. > > > > -Dave > > > > > -----Original Message----- > > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > > Behalf Of Christian Huitema > > > Sent: Wednesday, March 31, 2010 1:57 PM > > > To: David Harrington; behave@ietf.org > > > Subject: Re: [BEHAVE] address-format secure configuration > > > > > > David, > > > > > > We do not describe configuration in this document, we > > merely describe > > > address format. Configuration is indeed important, but do you > really > > > believe that it should be part of this document? What about > > the other > > > documents in the working set, e.g. the description of stateful and > > > stateless address translation? Or the framework document? > > The note in > > > the security section is meant to flag the issue, not to resolve > it. > > > > > > -- Christian Huitema > > > > > > > > > -----Original Message----- > > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > > Behalf Of David Harrington > > > Sent: Wednesday, March 31, 2010 10:12 AM > > > To: behave@ietf.org > > > Subject: [BEHAVE] address-format secure configuration > > > > > > Hi, > > > > > > I think section 4.2 Secure Configuration is inadequate. The > > discussion > > > of configuration is inadequate, and the discussion of security is > > > inadequate. > > > > > > Configuration will require some synchronization if the values > should > > > change. Specifying a default prefix might provide an initial > > > synchronization, but does not address the difficult > > operational issue > > > of synchronization of changes to the deployed prefixes and > formats. > > > The document does not discuss the operational and security > > > vulnerabilties exposed during the process of changing a prefix. > > > > > > Secure configuration of prefixes and formats across multiple > devices > > > and applications in a network will require some type of > > authentication > > > and authorization, and protection from various possible > > attacks, such > > > as man in the middle attacks. A default prefix does not address > the > > > security issues involved in secure configuration, as far as > > I can see. > > > > > > > > > I think work needs to be done on this section. I recommend > > addressing > > > the operational considerations of deploying a change of > > prefix across > > > a network, and separately identifying and addressing the threats > > > involved in prefix configuration. > > > > > > > > > David Harrington > > > dbharrington@comcast.net > > > ietfdbh@comcast.net > > > dharrington@huawei.com > > > > > > _______________________________________________ > > > Behave mailing list > > > Behave@ietf.org > > > https://www.ietf.org/mailman/listinfo/behave > > > > > > _______________________________________________ > > > Behave mailing list > > > Behave@ietf.org > > > https://www.ietf.org/mailman/listinfo/behave > > > > > > > From dbharrington@comcast.net Wed Mar 31 10:02:00 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CCEC3A6BD7 for ; Wed, 31 Mar 2010 10:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 JPWWMNDGXX7F for ; Wed, 31 Mar 2010 10:01:59 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id DF4103A6B4D for ; Wed, 31 Mar 2010 09:50:46 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta01.westchester.pa.mail.comcast.net with comcast id zm351d0041ap0As51srJZF; Wed, 31 Mar 2010 16:51:18 +0000 Received: from Harrington73653 ([67.189.235.106]) by omta22.westchester.pa.mail.comcast.net with comcast id zsts1d00a2JQnJT3istsai; Wed, 31 Mar 2010 16:53:55 +0000 From: "David B Harrington" To: , References: <02a601cac507$48ef5d90$0600a8c0@china.huawei.com> Date: Wed, 31 Mar 2010 12:51:14 -0400 Message-ID: <02cc01cad0f2$61b38b20$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcrEi9k8m90hkSH6Qo+EMDiYzqNugwMYLJsQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <02a601cac507$48ef5d90$0600a8c0@china.huawei.com> X-Mailman-Approved-At: Thu, 01 Apr 2010 10:09:11 -0700 Subject: [BEHAVE] review of draft-ietf-behave-address-format-06 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 17:02:00 -0000 Hi, These comments have not been addressed in -06-. Please address them. Thanks, dbh > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Tuesday, March 16, 2010 8:51 AM > To: behave@ietf.org > Subject: review of draft-ietf-behave-address-format-05 > > Hi, > > I reviewed draft-ietf-behave-address-format-05 and have comments. > > section 1.3 Terminology defines terms that are defined using different > words in the framework document. I recommend having one document > define the term and other documents only reference it (preferred), or > copy the text so the documents have exactly the same definition and > point to the other document as the authroitative definition. > > section 1.3 > > The format document uses "IPv4-Converted", while framework uses > "IPv4-converted". we should use consistent capitalization rules. > > the terms should be organized in alphabetical order. > > section 2.1 > > says to concatenate [...] the null suffix. But the suffix may in the > future be non-null. s/null suffix/suffix/ > > " o If the prefix length is less than 96 bits, remove the last > octet > and insert the null octet "u" at the appropriate position, as > documented in Figure 1." > > I find this ambiguous. "Remove the last octet" could refer to the last > octet of the prefix. It doesn't mention shifting the bits in position > 64-119 into positions 72-127. Specify the "appropriate position" > (which is a fixed position). > > o for the other prefix lengths, extract the "u" octet to obtain a > 120 bit sequence, then extract the 32 bits following the prefix. > > is equally ambiguous. When you extract the "u" octet, you do not > obtain a 120-bit sequence, you obtain the "u" octet. What you really > need to do is shift the bits in position 72-127 into positions 64-119 > and zero the bits in position 120-127 (to make sure the uninitialized > bits are not interpreted as being a non-null suffix). > > I describe shifting the bits; but if we expect to allow non-null > suffixes in the future, then you really need to extract the values of > portions of the address, and concatenate the extracted portions, so > that you preserve the original address format, including the suffix. > > section 2.2 > > in the first paragraph, the second sentence isn't needed. Its presence > raises questions of whether this is in addition to the formats > specified in rfc4291, or whether it is describing a specific example > of a format described in rfc4291. If you keep it, I recommend starting > the second second with "For example," and removing "Examples of" from > the third paragraph. > > section 3.1 > > The paragraphs would seem better ordered MUST-SHOULD-MAY rather than > MAY-SHOULD-MUST. In particular, the MAY is an exception to the SHOULD, > and should follow the description of SHOULD behavior. > > The second paragraph s/Translatable addresses/Translatable IPv6 > addresses/ > "Translatable addresses" is not defined in terminology. There may be > other types of translatable addresses besides those discussed in this > document. > > section 3.2 > > "owing to" is unclear. Please reword. > > Advertisement [...] SHOULD be controlled by upstream or downstream > providers. Assuming up and down stream are the only two options, this > means there are circumstances where advertisement of WKP does not need > to be controlled. When is this acceptable (i.e., why is control not a > MUST?) > > Is the ability to control mandatory to implement? If not, what if an > upstream provider doesn't implement support for control, and the > downstream provider doesn't implement support for control. This means > they cannot control because neither provider's device implemented it. > Should this be mandatory to implement, but administratively > configurable as to which provider provides the control? > > Shouldn't both ends be able to control advertisements? One should be > able to control sending the advertisements; the other should be able > to control receiving advertisements. Which has which responsibility > should be deployment-specific. > > s/induces/introduces/ > > " Administrators of BGP nodes SHOULD configure filters that discard > advertisements of embedded IPv6 prefixes longer than the Well-Known > Prefix." > Is this true for ALL embedded prefixes, or only those embedding the > WKP? > (also see the first sentence in the same paragraph) > > where is "hair-pinning" defined? needs a reference. > > "must be able to" > "may require" - please use different wording to avoid RFC2119 > confusion. > > s/require/REQUIRE/ (or reword to use MUST): > Routers MUST > check the validity of the IPv4-Translatable IPv6 source addresses > using some form of reverse path check, as detailed in Section 4 > Security considerations. > > the "small example" seems to cover multiple paragraphs. I am not sure > where the example ends. Can the example be put into a separate section > (or sub-section)? > > Where is "all-zeroes identifier" defined? needs a reference. > > " We propose here a compromise, based on using no more than 1/256th > of > an organization's allocation of IPv6 addresses for the IPv4/IPv6 > translation service. For example [...]" > Where exactly is the proposal? > Is this proposal a MUST, a SHOULD, or a MAY? Please use RFC2119 > language. > > This whole section seems to present a variety of proposals, and the > pros and cons of each approach. What is being standardized? Or are we > not standardizing the prefix usage and source checking? Can we put the > evaluation of propoals and pros and cons into a separate section from > the section that standardizes an approach? > > If different deployemnts use different approaches, what can be > expected in terms of security and operations? Does the decision of one > deployer potentially decrease the security assured to a neighboring > deployment? How can one deployemnt learn what decisions were made by > the neighbor? > > "The recommended prefix length" - please use RFC2119 language. > > " IPv4-Translatable IPv6 addresses SHOULD follow the IPv6 address > architecture and SHOULD be compatible with the IPv4 address > architecture." > Please include an explanation of when the SHOULDs do not apply. > > s/SHOULD not/SHOULD NOT/ > > "In addition, > the minimum IPv4 subnet can be used for hosts is /30 (the router > interface needs a valid address for the same subnet) and this rule > SHOULD also be applied to the corresponding subnet of the IPv4- > translatable addresses." > please use RFC2119 language (can be, needs, etc.), and explain when > SHOULD does not apply. > > section 3.4 > > please use RFC2119 language. > > s/using same prefix/using the same prefix/ > > "The Well-Known Prefix MUST NOT be used for scenario 3 [...] That > means a > Network-Specific Prefix MUST be used in that scenario, for > example > a /96 prefix compatible with the Well-Known prefix format." > Huh? I don't understand what a NSP compatible with the WKP format > means. I understood the paragraph up until the example. > > section 3.5 > > please use RFC2119 language, for example, s/recommends/RECOMMENDS/ > > This whole section talks about potential choices for non-null > suffixes. But starts by saying "section 2 RECOMMENDS a zero suffix". > Section 2 says "These bits are reserved for future extensions, and > SHOULD be set to zero." So why are we discussing potential future > extensions in this document? Let's leave that to future extension > documents, and simply say here "the suffix bits SHOULD be set to > zero." For implementations compatible with THIS document, there is no > choice of suffix. > > "because > checksum neutrality can also be achieved by an appropriate choice > of > the Network-Specific Prefix, as was done for example with the Well- > Known Prefix." > I don't understand how the example achieved checksum neutrality, so > the example doesn't actually help explain "an appropriate choice". > > In section 2.1, the suffix with bits all zeroed is called the "null > suffix", but here it is called the "zero suffix". Please be > consistent. > > section 3.6 > > This is not deployment guidelines. This is history of how the WG > reached its decisions. While this can be useful to preserve, it > probably belongs in an appendix (or in a "The Making of" movie.) For > implementations compatible with THIS document, there is no deployment > choice of WKP. > > section 4.1 > > s/By and large,// > > "the same mitigations" - can you provide some pointers to documents > thta discuss the risks and mitigations that apply? > > reverse path checks - can you provide a reference? > packets are coming from an authorized location - can you provide a > reference? > > section 4.2 > > s/to be the configured/to be configured/ > s/As such,// > s;learned/configured;learned and configured; > > The IETF has standardized a number of approaches to securely > configuring devices. Please add some suggestions of standardized > secure means of configuration. > David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From rpenno@juniper.net Thu Apr 1 11:42:18 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 990AE3A6AAA for ; Thu, 1 Apr 2010 11:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, 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 SBsJPuZmSswO for ; Thu, 1 Apr 2010 11:42:16 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 2226E3A67D7 for ; Thu, 1 Apr 2010 11:42:16 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKS7TpKLHhYcwdMTSBKHzppwVchdLVcTaI@postini.com; Thu, 01 Apr 2010 11:42:49 PDT 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.1.393.1; Thu, 1 Apr 2010 11:40:51 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 1 Apr 2010 14:40:50 -0400 From: Reinaldo Penno To: "behave@ietf.org" Date: Thu, 1 Apr 2010 14:40:48 -0400 Thread-Topic: Possible issue with Fragmentation text in draft-ietf-behave-v6v4-xlate-15 Thread-Index: AcrRytiJqaxwlkOA9k2KaI9IT29klQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] Possible issue with Fragmentation text in draft-ietf-behave-v6v4-xlate-15 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 18:42:18 -0000 Hello, It is not clear from the study referenced (the 43.46%) if the IPv6 hosts that do not comply: * do send fragment header and reduce packet size to 1280 or * do not send fragment header but reduce packet size to 1280 or * include a fragmented header but continue to send whatever packet size as before. This leads to the following question: Let's suppose you have three links: IPv6-A, MTU 1400 IPv4 (B-C), MTU 1480 IPv4 (D-E), MTU 1200 IPv4 Endhost A and B and the interfaces of a xlate in the IPv6 and IPv4 worlds respectively. Reading the text my interpretations is the following: If the IPv6 host does not include a fragmented header in response to 'ICMPv6 too big' and the packet is 1400 (as above), I should set DF=3D1 in the IPv4 packet and send = it out. Wouldn't that create a permanent issue (depending on the details of th= e study) since the packets would never traverse D-E? Thanks, Reinaldo From rpenno@juniper.net Thu Apr 1 11:53:45 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6900B3A697A for ; Thu, 1 Apr 2010 11:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.54 X-Spam-Level: X-Spam-Status: No, score=-4.54 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 SSuKiGTjS4Ew for ; Thu, 1 Apr 2010 11:53:44 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 60FEC3A6944 for ; Thu, 1 Apr 2010 11:53:44 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKS7Tr2CzmkgrDnUyY98DUHR2gOF3IV6ye@postini.com; Thu, 01 Apr 2010 11:54:17 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 1 Apr 2010 11:52:17 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 1 Apr 2010 14:52:16 -0400 From: Reinaldo Penno To: "behave@ietf.org" Date: Thu, 1 Apr 2010 14:52:14 -0400 Thread-Topic: Possible issue with Fragmentation text in draft-ietf-behave-v6v4-xlate-15 Thread-Index: AcrRytiJqaxwlkOA9k2KaI9IT29klQAAZjlx 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.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Possible issue with Fragmentation text in draft-ietf-behave-v6v4-xlate-15 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 18:53:45 -0000 First sentence should read * do not send fragment header and do not reduce packet size to 1280 or On 4/1/10 11:40 AM, "Reinaldo Penno" wrote: > Hello, >=20 > It is not clear from the study referenced (the 43.46%) if the IPv6 hosts > that do not comply: >=20 > * do send fragment header and reduce packet size to 1280 or > * do not send fragment header but reduce packet size to 1280 or > * include a fragmented header but continue to send whatever packet size a= s > before. >=20 > This leads to the following question: >=20 > Let's suppose you have three links: >=20 > IPv6-A, MTU 1400 > IPv4 (B-C), MTU 1480 > IPv4 (D-E), MTU 1200 > IPv4 Endhost >=20 > A and B and the interfaces of a xlate in the IPv6 and IPv4 worlds > respectively. >=20 > Reading the text my interpretations is the following: If the IPv6 host do= es > not include a fragmented header in response to 'ICMPv6 too big' and the > packet is 1400 (as above), I should set DF=3D1 in the IPv4 packet and sen= d it > out. Wouldn't that create a permanent issue (depending on the details of = the > study) since the packets would never traverse D-E? >=20 > Thanks, >=20 > Reinaldo >=20 >=20 From edward.jankiewicz@sri.com Thu Apr 1 13:16:22 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 090DA3A6A55; Thu, 1 Apr 2010 13:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.245 X-Spam-Level: * X-Spam-Status: No, score=1.245 tagged_above=-999 required=5 tests=[AWL=-0.439, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553] 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 o-P4qzcQhzZP; Thu, 1 Apr 2010 13:16:21 -0700 (PDT) Received: from mail1.sri.com (newmail.SRI.COM [128.18.30.17]) by core3.amsl.com (Postfix) with ESMTP id 5F0783A6A4C; Thu, 1 Apr 2010 13:16:18 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [192.168.1.2] ([unknown] [71.0.229.111]) by mail.sri.com (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0L07006JKSBZL3G0@mail.sri.com>; Thu, 01 Apr 2010 13:16:48 -0700 (PDT) Message-id: <4BB4FF36.7070308@sri.com> Date: Thu, 01 Apr 2010 16:16:54 -0400 From: Ed Jankiewicz User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) To: 6man , IPv6 Operations , Behave WG , softwires@ietf.org Subject: [BEHAVE] applicability of RFC 5841 in node requirements bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 20:16:22 -0000 Packets containing IPv6 traffic originating at an IPv6 host, routed by IPv6 routers and delivered to an IPv6 host without any intervening tunnels, protocol translation, NAT44, NAT64, NAT444, NAT666 or anything else besides native IPv6 SHOULD be marked as 'happy' using the TCP Packet Mood Option defined in RFC 5841. All other packets MAY be marked as 'sad', 'confused', 'surprised', 'silly', 'frustrated', 'angry', 'apathetic', 'sneaky' or 'evil' depending on your opinion of the intervening mechanism. (no need to explicitly reply to this posting, just mark your next packet to me as 'amused' or 'bored') -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com From edward.jankiewicz@sri.com Thu Apr 1 13:45:48 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 488433A696A; Thu, 1 Apr 2010 13:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.019 X-Spam-Level: X-Spam-Status: No, score=0.019 tagged_above=-999 required=5 tests=[AWL=0.934, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=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 DL7C059ACHlR; Thu, 1 Apr 2010 13:45:47 -0700 (PDT) Received: from mail1.sri.com (srimail.SRI.COM [128.18.30.17]) by core3.amsl.com (Postfix) with ESMTP id F302E3A692E; Thu, 1 Apr 2010 13:45:45 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_lWMSupw3zdPf6MR98w3tSw)" Received: from [192.168.1.2] ([unknown] [71.0.229.111]) by mail.sri.com (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0L0700640QX4L3D0@mail.sri.com>; Thu, 01 Apr 2010 12:46:17 -0700 (PDT) Message-id: <4BB4F80E.4020706@sri.com> Date: Thu, 01 Apr 2010 15:46:22 -0400 From: Ed Jankiewicz User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) To: 6man , IPv6 Operations , Behave WG , softwires@ietf.org Subject: [BEHAVE] applicability of RFC 5841 in node requirements bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 20:45:48 -0000 This is a multi-part message in MIME format. --Boundary_(ID_lWMSupw3zdPf6MR98w3tSw) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Packets containing IPv6 traffic originating at an IPv6 host, routed by IPv6 routers and delivered to an IPv6 host without any intervening tunnels, protocol translation, NAT44, NAT64, NAT444, NAT666 or anything else besides native IPv6 SHOULD be marked as 'happy' using the TCP Packet Mood Option defined in RFC 5841. All other packets MAY be marked as 'sad', 'confused', 'surprised', 'silly', 'frustrated', 'angry', 'apathetic', 'sneaky' or 'evil' depending on your opinion of the intervening mechanism. (no need to explicitly reply to this posting, just mark your next packet to me as 'amused' or 'bored') -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com --Boundary_(ID_lWMSupw3zdPf6MR98w3tSw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Packets containing IPv6 traffic originating at an IPv6 host, routed by IPv6 routers and delivered to an IPv6 host without any intervening tunnels, protocol translation, NAT44, NAT64, NAT444, NAT666 or anything else besides native IPv6 SHOULD be marked as 'happy' using the TCP Packet Mood Option defined in RFC 5841.

All other packets MAY be marked as 'sad', 'confused', 'surprised', 'silly', 'frustrated', 'angry', 'apathetic', 'sneaky' or 'evil' depending on your opinion of the intervening mechanism.

(no need to explicitly reply to this posting, just mark your next packet to me as 'amused' or 'bored')
-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research 
Supporting DISA Standards Engineering Branch
732-389-1003 or  ed.jankiewicz@sri.com
--Boundary_(ID_lWMSupw3zdPf6MR98w3tSw)-- From rpenno@juniper.net Thu Apr 1 14:17:05 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 393D93A69A2 for ; Thu, 1 Apr 2010 14:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.26 X-Spam-Level: X-Spam-Status: No, score=-4.26 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, 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 NWnyHup7Qx7t for ; Thu, 1 Apr 2010 14:17:04 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id CE1333A6950 for ; Thu, 1 Apr 2010 14:17:03 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKS7UNbpJQI0/tV61AjollKLzpo376NpHT@postini.com; Thu, 01 Apr 2010 14:17:37 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 1 Apr 2010 14:13:38 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 1 Apr 2010 17:13:37 -0400 From: Reinaldo Penno To: "behave@ietf.org" Date: Thu, 1 Apr 2010 17:13:35 -0400 Thread-Topic: Reconciliation of draft-ietf-intarea-ipv4-id-update-00 and BEHAVE Thread-Index: AcrR4DB/CxMGF/770kS+j5I1rPbHrg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Joe Touch Subject: [BEHAVE] Reconciliation of draft-ietf-intarea-ipv4-id-update-00 and BEHAVE X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 21:17:05 -0000 There was some discussion in IETF-77 about IP IDs regarding this draft but reading it in more detail, it seems a reconciliation is needed with NAT64 and Stateless XLATE. A few snippets: o >> Sources SHOULD set DF=3D1. o >> IPv4 fragmentation SHOULD be limited to the originating source, even when the DF field allows it. o >> Sources unable to meet the non-repeating IP ID requirement above MUST NOT emit non-atomic packets. =20 [Reinaldo] I think this means certain kinds of NATs (stateless) cannot fragment packets. o >> Sources emitting non-atomic IPv4 packets SHOULD NOT repeat ID field values within a given source IP, destination IP, and protocol tuple over the period that fragment reordering would affect reassembly. [Reinaldo] This of course is difficult for stateless NAT o >> Sources that cannot ensure safe IPv4 ID generation and that allow DF=3D0 SHOULD employ integrity checks that would detect mis- reassembled fragments, e.g, as in SEAL [RFC5320 ]. Applications SHOULD NOT use UDP without checksums [RFC793 ], and SHOULD be very careful in their use of UDP-Lite [RFC3828 ] in such environments. [Reinaldo] This also has a direct impact in BEHAVE xlate documents. o >> Overlapping packets MUST be silently ignored during reassembly. o >> IP-in-IP tunnels SHOULD emit only atomic packets. Note that this recommendation applies to all tunnels, but the focus of this document is IPv4 requirements, so its explicit requirements focus on IPv4 cases. [Reinaldo] I think this impacts softwire/DS-Lite. Need to follow up there. From xing@cernet.edu.cn Fri Apr 2 05:28:25 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47C403A6982 for ; Fri, 2 Apr 2010 05:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.765 X-Spam-Level: * X-Spam-Status: No, score=1.765 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_HAS_XAIMC=2.696] 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 vehKuAqBVtHe for ; Fri, 2 Apr 2010 05:28:24 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id B403A3A6972 for ; Fri, 2 Apr 2010 05:28:22 -0700 (PDT) Received: from [10.140.160.91]([117.136.0.190]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54bb65f96; Fri, 02 Apr 2010 20:28:52 +0800 Message-ID: <4BB5E303.1050106@cernet.edu.cn> Date: Fri, 02 Apr 2010 20:28:51 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------080504020209050103050900" X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: 0u8zfxXB Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Possible issue with Fragmentation text in draft-ietf-behave-v6v4-xlate-15 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 12:28:25 -0000 This is a multi-part message in MIME format. --------------080504020209050103050900 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, Reinaldo Penno 写道: > First sentence should read > > * do not send fragment header and do not reduce packet size to 1280 or > > > On 4/1/10 11:40 AM, "Reinaldo Penno" wrote: > > >> Hello, >> >> It is not clear from the study referenced (the 43.46%) if the IPv6 hosts >> that do not comply: >> >> * do send fragment header and reduce packet size to 1280 or >> * do not send fragment header but reduce packet size to 1280 or >> * include a fragmented header but continue to send whatever packet size as >> before. >> >> This leads to the following question: >> >> Let's suppose you have three links: >> >> IPv6-A, MTU 1400 >> IPv4 (B-C), MTU 1480 >> IPv4 (D-E), MTU 1200 >> IPv4 Endhost >> >> A and B and the interfaces of a xlate in the IPv6 and IPv4 worlds >> respectively. >> >> Reading the text my interpretations is the following: If the IPv6 host does >> not include a fragmented header in response to 'ICMPv6 too big' and the >> packet is 1400 (as above), I should set DF=1 in the IPv4 packet and send it >> out. Wouldn't that create a permanent issue (depending on the details of the >> study) since the packets would never traverse D-E? >> please see the attached file. the behavior of xlate follows the current specification. it should be no problem. regards, xing, congxiao >> Thanks, >> >> Reinaldo >> >> >> > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > --------------080504020209050103050900 Content-Type: application/pdf; name="case-20100402.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="case-20100402.pdf" JVBERi0xLjQNJeLjz9MNCjkgMCBvYmogPDwvTGluZWFyaXplZCAxL0wgMTI2OTIvTyAxMS9F IDYzODMvTiAyL1QgMTI0NjYvSCBbIDU1NiAxODNdPj4NZW5kb2JqDSAgICAgICAgICAgICAg ICAgICAgDQp4cmVmDQo5IDEzDQowMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDA3MzkgMDAw MDAgbg0KMDAwMDAwMDgxNiAwMDAwMCBuDQowMDAwMDAwOTUxIDAwMDAwIG4NCjAwMDAwMDEw NzIgMDAwMDAgbg0KMDAwMDAwMTU2NSAwMDAwMCBuDQowMDAwMDAxODAyIDAwMDAwIG4NCjAw MDAwMDE4MzYgMDAwMDAgbg0KMDAwMDAwMjA1NyAwMDAwMCBuDQowMDAwMDAyMjg0IDAwMDAw IG4NCjAwMDAwMDIzNjAgMDAwMDAgbg0KMDAwMDAwMzcxNCAwMDAwMCBuDQowMDAwMDAwNTU2 IDAwMDAwIG4NCnRyYWlsZXINCjw8L1NpemUgMjIvUHJldiAxMjQ1Ni9Sb290IDEwIDAgUi9J bmZvIDggMCBSL0lEWzxCMEU0MUIzNTQ0NkEwMEEzM0U4MjY4RUY4QjgzOTcxRj48NzhDNzE0 RDMwNTk2OTU0OTlBMjE4MkFDRTNCNDdGNUI+XT4+DQpzdGFydHhyZWYNCjANCiUlRU9GDQog ICAgICAgICAgICAgICANCjIxIDAgb2JqPDwvTGVuZ3RoIDk5L0ZpbHRlci9GbGF0ZURlY29k ZS9JIDExNS9MIDk5L1MgNTg+PnN0cmVhbQ0KeNpiYGBgZmBgqgSRHK4MPAwIwAMUYwFCjgfX FzD8AQqwBCVXAqkGoEqgCBLggmIGBiUGHraAcJkNpxkYdvMIaAV1eYOFWRgYFGqBNBMQWwAx BwODvgCQZgTihwABBgCHHQ4wDQplbmRzdHJlYW0NZW5kb2JqDTEwIDAgb2JqPDwvTWV0YWRh dGEgNyAwIFIvUGFnZXMgNiAwIFIvVHlwZS9DYXRhbG9nL1BhZ2VMYWJlbHMgNCAwIFI+Pg1l bmRvYmoNMTEgMCBvYmo8PC9Dcm9wQm94WzAgMCA1OTUuMjIgODQyXS9QYXJlbnQgNiAwIFIv Q29udGVudHMgMTkgMCBSL1JvdGF0ZSA5MC9NZWRpYUJveFswIDAgNTk1LjIyIDg0Ml0vUmVz b3VyY2VzIDEyIDAgUi9UeXBlL1BhZ2U+Pg1lbmRvYmoNMTIgMCBvYmo8PC9Db2xvclNwYWNl PDwvQ3M2IDE1IDAgUj4+L0ZvbnQ8PC9UVDIgMTMgMCBSL1RUNCAxNCAwIFI+Pi9Qcm9jU2V0 Wy9QREYvVGV4dF0vRXh0R1N0YXRlPDwvR1MxIDE4IDAgUj4+Pj4NZW5kb2JqDTEzIDAgb2Jq PDwvU3VidHlwZS9UcnVlVHlwZS9Gb250RGVzY3JpcHRvciAxNiAwIFIvTGFzdENoYXIgMTQ5 L1dpZHRoc1syNzggMCAwIDAgMCAwIDAgMTkxIDMzMyAzMzMgMCAwIDI3OCAzMzMgMjc4IDAg NTU2IDU1NiA1NTYgNTU2IDU1NiAwIDU1NiAwIDU1NiAwIDI3OCAwIDU4NCA1ODQgNTg0IDU1 NiAwIDY2NyA2NjcgNzIyIDcyMiA2NjcgNjExIDAgMCAyNzggMCAwIDAgODMzIDAgMCA2Njcg MCA3MjIgNjY3IDYxMSAwIDAgOTQ0IDAgMCAwIDAgMCAwIDAgMCAwIDU1NiA1NTYgNTAwIDU1 NiA1NTYgMjc4IDU1NiA1NTYgMjIyIDAgNTAwIDIyMiA4MzMgNTU2IDU1NiA1NTYgMCAzMzMg NTAwIDI3OCA1NTYgNTAwIDcyMiA1MDAgNTAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDM1MF0vQmFzZUZvbnQvQXJpYWxNVC9GaXJz dENoYXIgMzIvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1R5cGUvRm9udD4+DWVuZG9iag0x NCAwIG9iajw8L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgMTcgMCBSL0xhc3RD aGFyIDg4L1dpZHRoc1s1NTYgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNzIyIDAgMCAwIDY2 NyAwIDAgMCAwIDAgMCA2MTEgMCAwIDAgMCAwIDcyMiAwIDYxMSAwIDAgMCA2NjddL0Jhc2VG b250L0FyaWFsLUJvbGRNVC9GaXJzdENoYXIgNTIvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5n L1R5cGUvRm9udD4+DWVuZG9iag0xNSAwIG9ialsvSUNDQmFzZWQgMjAgMCBSXQ1lbmRvYmoN MTYgMCBvYmo8PC9TdGVtViA4OC9Gb250TmFtZS9BcmlhbE1UL0ZvbnRTdHJldGNoL05vcm1h bC9Gb250V2VpZ2h0IDQwMC9GbGFncyAzMi9EZXNjZW50IC0yMTEvRm9udEJCb3hbLTY2NSAt MzI1IDIwMDAgMTAwNl0vQXNjZW50IDkwNS9Gb250RmFtaWx5KEFyaWFsKS9DYXBIZWlnaHQg NzE4L1hIZWlnaHQgNTE1L1R5cGUvRm9udERlc2NyaXB0b3IvSXRhbGljQW5nbGUgMD4+DWVu ZG9iag0xNyAwIG9iajw8L1N0ZW1WIDEzOC9Gb250TmFtZS9BcmlhbC1Cb2xkTVQvRm9udFN0 cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQgNzAwL0ZsYWdzIDMyL0Rlc2NlbnQgLTIxMS9Gb250 QkJveFstNjI4IC0zNzYgMjAwMCAxMDEwXS9Bc2NlbnQgOTA1L0ZvbnRGYW1pbHkoQXJpYWwp L0NhcEhlaWdodCA3MTgvWEhlaWdodCA1MTUvVHlwZS9Gb250RGVzY3JpcHRvci9JdGFsaWNB bmdsZSAwPj4NZW5kb2JqDTE4IDAgb2JqPDwvT1BNIDEvT1AgZmFsc2Uvb3AgZmFsc2UvVHlw ZS9FeHRHU3RhdGUvU0EgZmFsc2UvU00gMC4wMj4+DWVuZG9iag0xOSAwIG9iajw8L0xlbmd0 aCAxMjg0L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiZxXS29eNRDd31/hZSoRx+O3 EUFqk4JUAarIt0Cquiq0pWpYkEX+Pmf8nHuTpqL5pFz5eDw+czwe2xdXd1G9u1NUf3fv/tku fr4h9eFus0n7rCJpQ6SCNypZo/79a3u/XfCYqxvYG22VUTdXv22kXqH9CUgK6l6RUb+qN2+N +hM9f6uNbNAhKx8C+kndbsHRbH3ebjajzPBUrLZekTeaqmkHQjbapWr84rRdnE4WE57eY6TN 2lh13j5ouqjB2BLGm6BOtzD5sBltDOzfoXG6387g3qhnp0/by1OLBxqAu8MfvjllX78FHlkU SmCjPDldCimXeKZC2uWmiEHkGRE/bTeI+0Gcii5ZnbcPN6M2EMlGndKeuU1M/eyPX56fXv5f 1taRZrkfsH6yu5L9EkUbvfZ0EDdWir975vfV5XEOcw8PY2mwKrmtynnUwRoEo07XgG1fLOjq XHbKalc8d5k67HkdErTzcNiGvKgQaZ/SgK66lfEDuZ5GwXdoqMvZSD2zP7V0HkncExE5jJBk YvZ+B3FcomUwAE7duWr1x4tkMTxH7C7wKBjU2z7ywvIgBpKvgC8DCLXdvHLbHvo5j3YeAPQp xgBuJuGQ24XEjHuDxfHz9hGIqxyo7+fOae5om5Lo/4xscz5yao10ux2AD5isxsGAR6Ch1ZwG pAaQG0DJO4vE+024SCKl5wAGrBMuGSASk+4tBE8O1nlXefjSo53ERriOu5aFiHeVvA4kg6Rw a2ZuB8mNgRgEe2nB4QkPLfrFosuDPNwLiL1RdhJLC8FSRJtM0jaJaBN2n00i2mHB0XqLDFk2 twNYSchAkmnKgM8ijxmw/mBB9uADwGLShzAQhE9uR7cm3fVnGcpHQK7RGKk8eE1JPCVpweG2 2hhrYWsfFLZErErICXOv2nhe67ether1zSUfPMcKfqwFPHV0tIoB18wgtyYDdm7+0IpqWMVg 388Ve+fB5DnHLB9oF7c81nYRU+4NBMtVDizOkOBWOVh7qJWD0f8VBV2Es6OCFKaCLpvv6nFw MS8v7SLCEnod86jmPM405a9/uqQuey/TqxDx/0X15lFqfF5FXoiMkvgotTdnr08vLsk+85rO sMbnJSWvi0Szefb29GqzuM+UEhWfRQnpDKbHJIF+7WzywMcJdtTBxm/SwYgjrtv2vTpLVQdW 0vR9tNKqb5KVd30n7i3IHnyQlfuq7/cAjeXuZYDktHuL7Hflqu/flXuT2ljRvn9l9o0AMdbK iAlsi5yagUiCHAOrOll/sCB78MES9FmWSACCjJiBuBN6ZyGYiogJ8eQkIsYZWYEZ8bD40n7z hBMfN+20u8w9yMUnCpaPQUZ4OwChQQxSIlyFktSQL5LxYOB269AAoWEbIhSqPoWEmFH2hv0a QL+YKokpXyc11eNCvxPvsEwYEspYpjGpYU3lvK3uCt7Tot1dpg+LG/suGSTQ08V8a0Ih3JCr PnEu0dCr++j9pre/kCsel5DHc6Xf/DlXWqpgsGvPBteeDR539sjPmv4gW2+X7Ipl9zguUvSp JlVz6tuLwPpeCXGqhpgUC4ALfHsWjL6AS40lzIfi7FsftQoKvxlELEYZUWlbEW0mzmpT8ABB pDmB7qy0nYGLkwGKGY03SYcfCJWsTngEJLyYplD8lpiRmVKfob0m37NwSv3IJf97NY4pw7FQ yWGxoTnK91E/XM5BY4f+J8AAAakkgAoNCmVuZHN0cmVhbQ1lbmRvYmoNMjAgMCBvYmo8PC9M ZW5ndGggMjU3NS9GaWx0ZXIvRmxhdGVEZWNvZGUvTiAzL0FsdGVybmF0ZS9EZXZpY2VSR0I+ PnN0cmVhbQ0KSImclnlUU3cWx39vyZ6QlbDDYw1bgLAGkDVsYZEdBFEISQgBEkJI2AVBRAUU RUSEqpUy1m10Rk9FnS6uY60O1n3q0gP1MOroOLQW146dFzhHnU5nptPvH+/3Ofd37+/d3733 nfMAoCelqrXVMAsAjdagz0qMxRYVFGKkCQADCiACEQAyea0uLTshB+CSxkuwWtwJ/IueXgeQ ab0iTMrAMPD/iS3X6Q0AQBk4ByiUtXKcO3GuqjfoTPYZnHmllSaGURPr8QRxtjSxap6953zm OdrECo1WgbMpZ51CozDxaZxX1xmVOCOpOHfVqZX1OF/F2aXKqFHj/NwUq1HKagFA6Sa7QSkv x9kPZ7o+J0uC8wIAyHTVO1z6DhuUDQbTpSTVuka9WlVuwNzlHpgoNFSMJSnrq5QGgzBDJq+U 6RWYpFqjk2kbAZi/85w4ptpieJGDRaHBwUJ/H9E7hfqvm79Qpt7O05PMuZ5B/AtvbT/nVz0K gHgWr836t7bSLQCMrwTA8uZbm8v7ADDxvh2++M59+KZ5KTcYdGG+vvX19T5qpdzHVNA3+p8O v0DvvM/HdNyb8mBxyjKZscqAmeomr66qNuqxWp1MrsSEPx3iXx3483l4ZynLlHqlFo/Iw6dM rVXh7dYq1AZ1tRZTa/9TE39l2E80P9e4uGOvAa/YB7Au8gDytwsA5dIAUrQN34He9C2Vkgcy 8DXf4d783M8J+vdT4T7To1atmouTZOVgcqO+bn7P9FkCAqACJuABK2APnIE7EAJ/EALCQTSI B8kgHeSAArAUyEE50AA9qActoB10gR6wHmwCw2A7GAO7wX5wEIyDj8EJ8EdwHnwJroFbYBJM g4dgBjwFryAIIkEMiAtZQQ6QK+QF+UNiKBKKh1KhLKgAKoFUkBYyQi3QCqgH6oeGoR3Qbuj3 0FHoBHQOugR9BU1BD6DvoJcwAtNhHmwHu8G+sBiOgVPgHHgJrIJr4Ca4E14HD8Gj8D74MHwC Pg9fgyfhh/AsAhAawkccESEiRiRIOlKIlCF6pBXpRgaRUWQ/cgw5i1xBJpFHyAuUiHJRDBWi 4WgSmovK0Rq0Fe1Fh9Fd6GH0NHoFnUJn0NcEBsGW4EUII0gJiwgqQj2hizBI2En4iHCGcI0w TXhKJBL5RAExhJhELCBWEJuJvcStxAPE48RLxLvEWRKJZEXyIkWQ0kkykoHURdpC2kf6jHSZ NE16TqaRHcj+5ARyIVlL7iAPkveQPyVfJt8jv6KwKK6UMEo6RUFppPRRxijHKBcp05RXVDZV QI2g5lArqO3UIep+6hnqbeoTGo3mRAulZdLUtOW0IdrvaJ/Tpmgv6By6J11CL6Ib6evoH9KP 07+iP2EwGG6MaEYhw8BYx9jNOMX4mvHcjGvmYyY1U5i1mY2YHTa7bPaYSWG6MmOYS5lNzEHm IeZF5iMWheXGkrBkrFbWCOso6wZrls1li9jpbA27l72HfY59n0PiuHHiOQpOJ+cDzinOXS7C deZKuHLuCu4Y9wx3mkfkCXhSXgWvh/db3gRvxpxjHmieZ95gPmL+ifkkH+G78aX8Kn4f/yD/ Ov+lhZ1FjIXSYo3FfovLFs8sbSyjLZWW3ZYHLK9ZvrTCrOKtKq02WI1b3bFGrT2tM63rrbdZ n7F+ZMOzCbeR23TbHLS5aQvbetpm2TbbfmB7wXbWzt4u0U5nt8XulN0je759tH2F/YD9p/YP HLgOkQ5qhwGHzxz+ipljMVgVNoSdxmYcbR2THI2OOxwnHF85CZxynTqcDjjdcaY6i53LnAec TzrPuDi4pLm0uOx1uelKcRW7lrtudj3r+sxN4Jbvtspt3O2+wFIgFTQJ9gpuuzPco9xr3Efd r3oQPcQelR5bPb70hD2DPMs9RzwvesFewV5qr61el7wJ3qHeWu9R7xtCujBGWCfcK5zy4fuk +nT4jPs89nXxLfTd4HvW97VfkF+V35jfLRFHlCzqEB0Tfefv6S/3H/G/GsAISAhoCzgS8G2g V6AycFvgn4O4QWlBq4JOBv0jOCRYH7w/+EGIS0hJyHshN8Q8cYa4V/x5KCE0NrQt9OPQF2HB YYawg2F/DxeGV4bvCb+/QLBAuWBswd0IpwhZxI6IyUgssiTy/cjJKMcoWdRo1DfRztGK6J3R 92I8Yipi9sU8jvWL1cd+FPtMEiZZJjkeh8QlxnXHTcRz4nPjh+O/TnBKUCXsTZhJDEpsTjye REhKSdqQdENqJ5VLd0tnkkOSlyWfTqGnZKcMp3yT6pmqTz2WBqclp21Mu73QdaF24Xg6SJem b0y/kyHIqMn4QyYxMyNzJPMvWaKslqyz2dzs4uw92U9zYnP6cm7luucac0/mMfOK8nbnPcuP y+/Pn1zku2jZovMF1gXqgiOFpMK8wp2Fs4vjF29aPF0UVNRVdH2JYEnDknNLrZdWLf2kmFks Kz5UQijJL9lT8oMsXTYqmy2Vlr5XOiOXyDfLHyqiFQOKB8oIZb/yXllEWX/ZfVWEaqPqQXlU +WD5I7VEPaz+tiKpYnvFs8r0yg8rf6zKrzqgIWtKNEe1HG2l9nS1fXVD9SWdl65LN1kTVrOp Zkafot9ZC9UuqT1i4OE/UxeM7saVxqm6yLqRuuf1efWHGtgN2oYLjZ6NaxrvNSU0/aYZbZY3 n2xxbGlvmVoWs2xHK9Ra2nqyzbmts216eeLyXe3U9sr2P3X4dfR3fL8if8WxTrvO5Z13Vyau 3Ntl1qXvurEqfNX21ehq9eqJNQFrtqx53a3o/qLHr2ew54deee8Xa0Vrh9b+uK5s3URfcN+2 9cT12vXXN0Rt2NXP7m/qv7sxbePhAWyge+D7TcWbzg0GDm7fTN1s3Dw5lPpPAKQBW/6YuJkk mZCZ/JpomtWbQpuvnByciZz3nWSd0p5Anq6fHZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTH pTilqaYapoum/adup+CoUqjEqTepqaocqo+rAqt1q+msXKzQrUStuK4trqGvFq+LsACwdbDq sWCx1rJLssKzOLOutCW0nLUTtYq2AbZ5tvC3aLfguFm40blKucK6O7q1uy67p7whvJu9Fb2P vgq+hL7/v3q/9cBwwOzBZ8Hjwl/C28NYw9TEUcTOxUvFyMZGxsPHQce/yD3IvMk6ybnKOMq3 yzbLtsw1zLXNNc21zjbOts83z7jQOdC60TzRvtI/0sHTRNPG1EnUy9VO1dHWVdbY11zX4Nhk 2OjZbNnx2nba+9uA3AXcit0Q3ZbeHN6i3ynfr+A24L3hROHM4lPi2+Nj4+vkc+T85YTmDeaW 5x/nqegy6LzpRunQ6lvq5etw6/vshu0R7ZzuKO6070DvzPBY8OXxcvH/8ozzGfOn9DT0wvVQ 9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9Kf26/kv+3P9t//8CDAD3hPP7Cg0KZW5kc3Ry ZWFtDWVuZG9iag0xIDAgb2JqPDwvQ3JvcEJveFswIDAgNTk1LjIyIDg0Ml0vUGFyZW50IDYg MCBSL0NvbnRlbnRzIDMgMCBSL1JvdGF0ZSA5MC9NZWRpYUJveFswIDAgNTk1LjIyIDg0Ml0v UmVzb3VyY2VzIDIgMCBSL1R5cGUvUGFnZT4+DWVuZG9iag0yIDAgb2JqPDwvQ29sb3JTcGFj ZTw8L0NzNiAxNSAwIFI+Pi9Gb250PDwvVFQyIDEzIDAgUi9UVDQgMTQgMCBSPj4vUHJvY1Nl dFsvUERGL1RleHRdL0V4dEdTdGF0ZTw8L0dTMSAxOCAwIFI+Pj4+DWVuZG9iag0zIDAgb2Jq PDwvTGVuZ3RoIDE3OTYvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJpFfbbhw3En2f r+Cbe4BMi3eyjVUWsexdONgEgTVAAth5mGhaF+9oRphu2cmH7P/mFG/NHtlaBJFgt1gsFk9V nSqSZxeDZVcDE+F3uNovzv59KdjNsJCu1Z5Z0XIhmNGcOcnZsV9cL85ozcUl9HkrGWeXFz8u BPse44+QOMM+M8HZD+z9r5xtMXPHFp1qlWVaubbrBLtfaG5aqYtgt7hccMazLa1by6SUrVGk HMdGKkAJqq/Wi7P1WmLD9TXWCc9W+Ic/nG07WPW67QQ3bH2P2ZsFbzmn0RVG68+LRmjO2XL9 cfFmHX2B/8Ct8IOvd16Hb8dlCIhAJKxkmnetBlbpW4W4yFbHaHB47eHt83oZtC6gVdsR7vDB UNvWe6aFa507ge4IevPLf75bv/nLqCVi4d1T1M9OB7Bfg6i4a4WaIK4IIyhCGN9pAvhcbpTR yGpaXfKClPiYkhW04Adbv4ZQpjwJ3Qo4ykAISTM8rPku6JvW0lRc8SqIRGtcElwkHWWLzuus Y23WymElAopE54+Rw4m5iXxEXPzhJzLGaeUAw1TzWUBsLckKv5QbKSRF0oquVQ6L0lhrrFW0 iAQO9aLxKQIdBVZkgZQnGuLEhMhbFH0aW1dZJIFT05ZzhQnkbnELiYkgVKrijKpUsSTuTxo7 EE1a1YrCs/s01kqFvrILY3IEAmmyIBhFZF0WOHuiQeGa2YAgb1KWkMCqyigJTL3tXENUJuCu 5RGIyO5mZMVda2uNyd2p0cWx5Z76YtnWIk689pYEokI+V6A01BaC8xOIFB50jnkAXeVaCHGt ISoTxVeL2gYbiqsWtR/ZET1N8+Sokrw1Pmvc5/FEwCCoGUqCRNnIYQVqdb7WgMDb2kYUFBhp hUVD4LVNEghT7TrXmHCSr0rGcBQaZ2AlHgpduNIgd2NDRMeS6Gfhw5lETtAKFFa7k36oOmpR 75ufLs9x2ixdqxq+/HX9/ax5n/YDApCKJAqkh7ul3AOhu6r+dRTormoIcw1xYkKUPaYOojya a91jIJCzLjTTqHBWPUF2vIKeKi3tE3tC1ng+mMq5WTBjBJWPEfyGhRielTtLvH9QCFHGxqd+ TgmQNibg9b+WKJzmXOTox4Y99aN0E5nwXn4ZHs4tCm8nnx5+Jdnr5QrF2bw6p5NruRL48a2e yX2kgdSt0kIxHHdSCkuoo6vSV2RZIbjSCx3dSgr2b8eiMHFiYK7e0reSYKJPKqyJX6lqJgam 4qw0YvVWNlJ9V4UWOwBRrqt7BAS63nauYfyseaWCnjhYoOWcpoKuOZgddF1g++SxFHlR8hgC WzcbEpi6gVUayePJRhKkXaYlEJiZUQhs3cHmGhXS2mNckX3dwkClIJg8ThpfqzqFBYYA4xbQ PdPD5P/tYXSxs3U443iKBMZ6FiuqKF1H0yi6IdYa8VivbETBFM20ZIpVMjpFM20707DzYBoX gZRgJiNTMI2oNTJ9qrRhkYbFemOMTb0vxlbW2JOCz7WQDPiKfnImyNTxVfX8RXLBW+1jv5NV olLIMrCogQt7FHyFOniVhXTNqfMFvnDWsVVHSxziiBMTAeepiU4vGa86SXZBdme1C6QKPMSK 8ESQOEjD1R1NTNLdvRV0hY8vhTxncWnEVX8lq0nhwyRH/CFa0SsiTdkwoXBXIImsLSpbdpM+ P0iS8EksDG77OLw8ulYJBT0lig86vD7poWTpCUpBYmxpm2/pRHjJ0JlxQnTN+RIHgm9EChte KaJz4XSIFWmLGZnN/IOW6CadHLYp1ky0pksSEJuA2UbMWpm2Y6CBOr28TGilidv8D4eZgr5r 3i0JVNNvtnf7Gzbe9mzsfx/Z/R/sbj/2x4ewF+5aIFF6cEWTE3JBJptjP27Gu8N+YHdDMHN9 2O0On2H0ZXwHCmxDythOciknS09CuSJwBqXZvL0Opt7+9Mmy28Mwsu2hH9j+MALc1e5x27MN uz5ubu57YN3Gg1jiuSZ1DdWVDboAld3C2/4IG+zYDw/ADKcPBBLVhoMpHbRR98Xbix9o+/Fw YL/d3byIzuCKqDSehSGh3nzJGRWd2ey3wYeHzdV/+5GCg/sjZx+a5QpPl2azFMjowDa/HT71 H5ZR+A17y4bbw+Nuy4Y+eoXbvO5mXpm5V++bETw5F+RViplerqRD3TRpb4Iy9Pjvbox3jVU2 W+Ukp/QqBeDwOLYpgSgJo5/mT2YgXM7zZ5ufl1CRDXmyfzEC12ZkV0dyUoFxI6XvoT/eb/bI H0IzPPYRGD1RcUpU7oribWLwh2bbP8AZYu0hurwFBe92A3mNrtEcrqMteWqrQuyisbB8GB+3 f8QUqIYNYFifwwReGO+ful5ywBOqKdMD+xwSuO8/9cFji12OGwzAtterN/9k+ej9U4ABACPm I10KDQplbmRzdHJlYW0NZW5kb2JqDTQgMCBvYmo8PC9OdW1zWzAgNSAwIFJdPj4NZW5kb2Jq DTUgMCBvYmo8PC9TL0Q+Pg1lbmRvYmoNNiAwIG9iajw8L0NvdW50IDIvVHlwZS9QYWdlcy9L aWRzWzExIDAgUiAxIDAgUl0+Pg1lbmRvYmoNNyAwIG9iajw8L1N1YnR5cGUvWE1ML0xlbmd0 aCAzNTQyL1R5cGUvTWV0YWRhdGE+PnN0cmVhbQ0KPD94cGFja2V0IGJlZ2luPSLvu78iIGlk PSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4KPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9i ZTpuczptZXRhLyIgeDp4bXB0az0iMy4xLTcwMSI+CiAgIDxyZGY6UkRGIHhtbG5zOnJkZj0i aHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+CiAgICAgIDxy ZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOnBkZj0iaHR0 cDovL25zLmFkb2JlLmNvbS9wZGYvMS4zLyI+CiAgICAgICAgIDxwZGY6UHJvZHVjZXI+QWNy b2JhdCBEaXN0aWxsZXIgNy4wIChXaW5kb3dzKTwvcGRmOlByb2R1Y2VyPgogICAgICA8L3Jk ZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAg ICAgICAgICAgeG1sbnM6eGFwPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIj4KICAg ICAgICAgPHhhcDpDcmVhdG9yVG9vbD5QU2NyaXB0NS5kbGwgVmVyc2lvbiA1LjI8L3hhcDpD cmVhdG9yVG9vbD4KICAgICAgICAgPHhhcDpNb2RpZnlEYXRlPjIwMTAtMDQtMDJUMjA6MjU6 MjUrMDg6MDA8L3hhcDpNb2RpZnlEYXRlPgogICAgICAgICA8eGFwOkNyZWF0ZURhdGU+MjAx MC0wNC0wMlQyMDoyNToyNSswODowMDwveGFwOkNyZWF0ZURhdGU+CiAgICAgIDwvcmRmOkRl c2NyaXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAg ICAgICB4bWxuczpkYz0iaHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8iPgogICAg ICAgICA8ZGM6Zm9ybWF0PmFwcGxpY2F0aW9uL3BkZjwvZGM6Zm9ybWF0PgogICAgICAgICA8 ZGM6dGl0bGU+CiAgICAgICAgICAgIDxyZGY6QWx0PgogICAgICAgICAgICAgICA8cmRmOmxp IHhtbDpsYW5nPSJ4LWRlZmF1bHQiPk1pY3Jvc29mdCBQb3dlclBvaW50IC0gY2FzZS0yMDEw MDQwMjwvcmRmOmxpPgogICAgICAgICAgICA8L3JkZjpBbHQ+CiAgICAgICAgIDwvZGM6dGl0 bGU+CiAgICAgICAgIDxkYzpjcmVhdG9yPgogICAgICAgICAgICA8cmRmOlNlcT4KICAgICAg ICAgICAgICAgPHJkZjpsaT54aW5nPC9yZGY6bGk+CiAgICAgICAgICAgIDwvcmRmOlNlcT4K ICAgICAgICAgPC9kYzpjcmVhdG9yPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAg PHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6eGFwTU09 Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8iPgogICAgICAgICA8eGFwTU06RG9j dW1lbnRJRD51dWlkOmYyMGU3MjYzLTlmZjQtNGI5NC04ZmE2LWI4ZDRjZWQwNmNiYzwveGFw TU06RG9jdW1lbnRJRD4KICAgICAgICAgPHhhcE1NOkluc3RhbmNlSUQ+dXVpZDpjMDNmNWM0 ZS1hMjg2LTQ5MDQtYWY5Zi1mMTA5NTdhNTAyMTY8L3hhcE1NOkluc3RhbmNlSUQ+CiAgICAg IDwvcmRmOkRlc2NyaXB0aW9uPgogICA8L3JkZjpSREY+CjwveDp4bXBtZXRhPgogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgCjw/eHBhY2tldCBl bmQ9InciPz4NCmVuZHN0cmVhbQ1lbmRvYmoNOCAwIG9iajw8L0NyZWF0aW9uRGF0ZShEOjIw MTAwNDAyMjAyNTI1KzA4JzAwJykvQXV0aG9yKHhpbmcpL0NyZWF0b3IoUFNjcmlwdDUuZGxs IFZlcnNpb24gNS4yKS9Qcm9kdWNlcihBY3JvYmF0IERpc3RpbGxlciA3LjAgXChXaW5kb3dz XCkpL01vZERhdGUoRDoyMDEwMDQwMjIwMjUyNSswOCcwMCcpL1RpdGxlKE1pY3Jvc29mdCBQ b3dlclBvaW50IC0gY2FzZS0yMDEwMDQwMik+Pg1lbmRvYmoNeHJlZg0KMCA5DQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDYzODMgMDAwMDAgbg0KMDAwMDAwNjUxNSAwMDAwMCBuDQow MDAwMDA2NjM1IDAwMDAwIG4NCjAwMDAwMDg1MDAgMDAwMDAgbg0KMDAwMDAwODUzMyAwMDAw MCBuDQowMDAwMDA4NTU2IDAwMDAwIG4NCjAwMDAwMDg2MTMgMDAwMDAgbg0KMDAwMDAxMjIz MSAwMDAwMCBuDQp0cmFpbGVyDQo8PC9TaXplIDk+Pg0Kc3RhcnR4cmVmDQoxMTYNCiUlRU9G DQo= --------------080504020209050103050900-- From rpenno@juniper.net Fri Apr 2 08:22:35 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBA0D3A6907 for ; Fri, 2 Apr 2010 08:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.911 X-Spam-Level: X-Spam-Status: No, score=-4.911 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 PeY3im8jZ1pA for ; Fri, 2 Apr 2010 08:22:34 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 9E20D3A677C for ; Fri, 2 Apr 2010 08:22:31 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKS7YL2YXakPtp/a6oIIEx7IyK9w9qjba5@postini.com; Fri, 02 Apr 2010 08:23:08 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 2 Apr 2010 08:20:06 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 2 Apr 2010 11:20:05 -0400 From: Reinaldo Penno To: Xing Li Date: Fri, 2 Apr 2010 11:20:00 -0400 Thread-Topic: [BEHAVE] Possible issue with Fragmentation text in draft-ietf-behave-v6v4-xlate-15 Thread-Index: AcrSYBV1JP7lA9ZyTCSOC3pUSgwdJgAF+BRU Message-ID: In-Reply-To: <4BB5E303.1050106@cernet.edu.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Possible issue with Fragmentation text in draft-ietf-behave-v6v4-xlate-15 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 15:22:36 -0000 Thanks for the great diagram. So, irrespective of the spec, what you are saying is that current implementations reduce the packet size to 1280 (although might not include a fragmentation header)? In other words, in the study clients actually reduce the packet size. That was not clear. I would suggest putting a reference to the study in the draft. On 4/2/10 5:28 AM, "Xing Li" wrote: > Hi, >=20 > Reinaldo Penno =1B$B> First sentence should read >>=20 >> * do not send fragment header and do not reduce packet size to 1280 or >>=20 >>=20 >> On 4/1/10 11:40 AM, "Reinaldo Penno" wrote: >>=20 >> =20 >>> Hello, >>>=20 >>> It is not clear from the study referenced (the 43.46%) if the IPv6 host= s >>> that do not comply: >>>=20 >>> * do send fragment header and reduce packet size to 1280 or >>> * do not send fragment header but reduce packet size to 1280 or >>> * include a fragmented header but continue to send whatever packet size= as >>> before. >>> =20 >>> This leads to the following question: >>>=20 >>> Let's suppose you have three links: >>>=20 >>> IPv6-A, MTU 1400 >>> IPv4 (B-C), MTU 1480 >>> IPv4 (D-E), MTU 1200 >>> IPv4 Endhost >>>=20 >>> A and B and the interfaces of a xlate in the IPv6 and IPv4 worlds >>> respectively. >>>=20 >>> Reading the text my interpretations is the following: If the IPv6 host = does >>> not include a fragmented header in response to 'ICMPv6 too big' and the >>> packet is 1400 (as above), I should set DF=3D1 in the IPv4 packet and s= end it >>> out. Wouldn't that create a permanent issue (depending on the details o= f the >>> study) since the packets would never traverse D-E? >>> =20 > please see the attached file. the behavior of xlate follows the current > specification. it should be no problem. >=20 > regards, >=20 > xing, congxiao >=20 >=20 >>> Thanks, >>>=20 >>> Reinaldo >>>=20 >>>=20 >>> =20 >>=20 >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >>=20 >>=20 >> =20 >=20 From xing@cernet.edu.cn Fri Apr 2 09:14:58 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30B713A67F7 for ; Fri, 2 Apr 2010 09:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.731 X-Spam-Level: * X-Spam-Status: No, score=1.731 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_HAS_XAIMC=2.696] 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 ELacea+HDJf0 for ; Fri, 2 Apr 2010 09:14:57 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 6CDD53A659A for ; Fri, 2 Apr 2010 09:14:55 -0700 (PDT) Received: from [192.168.1.100]([125.34.50.175]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54bb694b2; Sat, 03 Apr 2010 00:15:24 +0800 Message-ID: <4BB61820.8090902@cernet.edu.cn> Date: Sat, 03 Apr 2010 00:15:28 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: 0Xm6jxXB Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Possible issue with Fragmentation text in draft-ietf-behave-v6v4-xlate-15 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 16:14:58 -0000 Reinaldo Penno $B Thanks for the great diagram. So, irrespective of the spec, what you are > saying is that current implementations reduce the packet size to 1280 > (although might not include a fragmentation header)? > correct. > In other words, in the study clients actually reduce the packet size. That > was not clear. I would suggest putting a reference to the study in the > draft. > > actually, we have cited a reference [Stasiewicz http://www.ietf.org/mail-archive/web/behave/current/msg08093.html ] upto version 11 (http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-11). It was removed in version 12 according to the review comments. The reason is that the standard track RFC should not cite mailing-list as references. regards, xing, congxiao > On 4/2/10 5:28 AM, "Xing Li" wrote: > > >> Hi, >> >> Reinaldo Penno $B> >>> First sentence should read >>> >>> * do not send fragment header and do not reduce packet size to 1280 or >>> >>> >>> On 4/1/10 11:40 AM, "Reinaldo Penno" wrote: >>> >>> >>> >>>> Hello, >>>> >>>> It is not clear from the study referenced (the 43.46%) if the IPv6 hosts >>>> that do not comply: >>>> >>>> * do send fragment header and reduce packet size to 1280 or >>>> * do not send fragment header but reduce packet size to 1280 or >>>> * include a fragmented header but continue to send whatever packet size as >>>> before. >>>> >>>> This leads to the following question: >>>> >>>> Let's suppose you have three links: >>>> >>>> IPv6-A, MTU 1400 >>>> IPv4 (B-C), MTU 1480 >>>> IPv4 (D-E), MTU 1200 >>>> IPv4 Endhost >>>> >>>> A and B and the interfaces of a xlate in the IPv6 and IPv4 worlds >>>> respectively. >>>> >>>> Reading the text my interpretations is the following: If the IPv6 host does >>>> not include a fragmented header in response to 'ICMPv6 too big' and the >>>> packet is 1400 (as above), I should set DF=1 in the IPv4 packet and send it >>>> out. Wouldn't that create a permanent issue (depending on the details of the >>>> study) since the packets would never traverse D-E? >>>> >>>> >> please see the attached file. the behavior of xlate follows the current >> specification. it should be no problem. >> >> regards, >> >> xing, congxiao >> >> >> >>>> Thanks, >>>> >>>> Reinaldo >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >>> >>> >>> > > > From dwing@cisco.com Fri Apr 2 11:18:27 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3953E3A6911 for ; Fri, 2 Apr 2010 11:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.283 X-Spam-Level: X-Spam-Status: No, score=-9.283 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 lI+DPWS6ly1f for ; Fri, 2 Apr 2010 11:18:25 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 17D513A6B9B for ; Fri, 2 Apr 2010 10:56:54 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAIAFPMtUurR7Hu/2dsb2JhbACDEYRGgRSSXnGbU4hAAZAjgSiCbXAEgySLAw X-IronPort-AV: E=Sophos;i="4.51,354,1267401600"; d="scan'208";a="218432305" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 02 Apr 2010 17:57:28 +0000 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o32HvR2M004912; Fri, 2 Apr 2010 17:57:28 GMT From: "Dan Wing" To: "'Reinaldo Penno'" , "'Xing Li'" References: <4BB5E303.1050106@cernet.edu.cn> Date: Fri, 2 Apr 2010 10:57:27 -0700 Message-ID: <006f01cad28d$f55ee8a0$c6f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcrSYBV1JP7lA9ZyTCSOC3pUSgwdJgAF+BRUAAU48UA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: behave@ietf.org Subject: Re: [BEHAVE] Possible issue with Fragmentation text in draft-ietf-behave-v6v4-xlate-15 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 18:18:27 -0000 > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Reinaldo Penno > Sent: Friday, April 02, 2010 8:20 AM > To: Xing Li > Cc: behave@ietf.org > Subject: Re: [BEHAVE] Possible issue with Fragmentation text > in draft-ietf-behave-v6v4-xlate-15 > > Thanks for the great diagram. So, irrespective of the spec, > what you are > saying is that current implementations reduce the packet size to 1280 > (although might not include a fragmentation header)? Ben Stasiewicz did two studies -- one sent ICMP packet-too-big with an MTU of 1280, which was generally successful and the IPv6 hosts reduced their packets to 1280 bytes, http://listserver.internetnz.net.nz/pipermail/ipv6-techsig/2009-October/000708 .html. The other study sent ICMP packet-too-big with an MTU below 1280, which was generally unsuccessful; it is this second study that is is cited in draft-ietf-behave-v6v4-xlate. > In other words, in the study clients actually reduce the > packet size. That > was not clear. I would suggest putting a reference to the study in the > draft. -d > > On 4/2/10 5:28 AM, "Xing Li" wrote: > > > Hi, > > > > Reinaldo Penno $B >> First sentence should read > >> > >> * do not send fragment header and do not reduce packet > size to 1280 or > >> > >> > >> On 4/1/10 11:40 AM, "Reinaldo Penno" wrote: > >> > >> > >>> Hello, > >>> > >>> It is not clear from the study referenced (the 43.46%) if > the IPv6 hosts > >>> that do not comply: > >>> > >>> * do send fragment header and reduce packet size to 1280 or > >>> * do not send fragment header but reduce packet size to 1280 or > >>> * include a fragmented header but continue to send > whatever packet size as > >>> before. > >>> > >>> This leads to the following question: > >>> > >>> Let's suppose you have three links: > >>> > >>> IPv6-A, MTU 1400 > >>> IPv4 (B-C), MTU 1480 > >>> IPv4 (D-E), MTU 1200 > >>> IPv4 Endhost > >>> > >>> A and B and the interfaces of a xlate in the IPv6 and IPv4 worlds > >>> respectively. > >>> > >>> Reading the text my interpretations is the following: If > the IPv6 host does > >>> not include a fragmented header in response to 'ICMPv6 > too big' and the > >>> packet is 1400 (as above), I should set DF=1 in the IPv4 > packet and send it > >>> out. Wouldn't that create a permanent issue (depending on > the details of the > >>> study) since the packets would never traverse D-E? > >>> > > please see the attached file. the behavior of xlate follows > the current > > specification. it should be no problem. > > > > regards, > > > > xing, congxiao > > > > > >>> Thanks, > >>> > >>> Reinaldo > >>> > >>> > >>> > >> > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www.ietf.org/mailman/listinfo/behave > >> > >> > >> > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From rpenno@juniper.net Fri Apr 2 13:01:09 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 295DB3A6A9D for ; Fri, 2 Apr 2010 13:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.05 X-Spam-Level: X-Spam-Status: No, score=-5.05 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 OGZCQXHEKSO8 for ; Fri, 2 Apr 2010 13:01:08 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 463FA3A6A53 for ; Fri, 2 Apr 2010 12:27:36 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKS7ZFSrI4zjPCBDPle5UVMOoBbOrrB8tf@postini.com; Fri, 02 Apr 2010 12:28:12 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 2 Apr 2010 12:26:54 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 2 Apr 2010 15:26:53 -0400 From: Reinaldo Penno To: Xing Li Date: Fri, 2 Apr 2010 15:26:51 -0400 Thread-Topic: [BEHAVE] Possible issue with Fragmentation text in draft-ietf-behave-v6v4-xlate-15 Thread-Index: AcrSf7o9F/6Yc9E3SziZC3lkIU/Q4gAGreUH Message-ID: In-Reply-To: <4BB61820.8090902@cernet.edu.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Possible issue with Fragmentation text in draft-ietf-behave-v6v4-xlate-15 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 20:01:09 -0000 Xing, I had some discussions offline and would you mind if I suggest some changes to the draft specifically in the IPv6 to IPv4 translation? * First of all, the MTU, fragmentation discussions could use at least a section heading of its own. * Then the text (at least IMHO) is somewhat confusing as it tries to explai= n the assumption, but if the assumptions are not right do this and then there is this study which allows us to do that.... Maybe something crisp and to the point like: "The IPv6 to IPv4 translation assumes the following to work properly" * An IPv6 host when receiving an PTB with MTU < 1280 MUST adjust its packet size to 1280 * It MAY include a fragmentation header. If the IPv6 host does not adjust its packet size and the translator sets DF=3D1 for IPv4 packets > 1280, they might be dropped by an intermediate I= Pv4 link where MTU < 1280" Thanks, Reinaldo On 4/2/10 9:15 AM, "Xing Li" wrote: > Reinaldo Penno =1B$B=20 > thanks. >> Thanks for the great diagram. So, irrespective of the spec, what you are >> saying is that current implementations reduce the packet size to 1280 >> (although might not include a fragmentation header)? >> =20 >=20 > correct. >=20 >> In other words, in the study clients actually reduce the packet size. Th= at >> was not clear. I would suggest putting a reference to the study in the >> draft. >>=20 >> =20 >=20 > actually, we have cited a reference [Stasiewicz > http://www.ietf.org/mail-archive/web/behave/current/msg08093.html ] upto > version 11 (http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-11). > It was removed in version 12 according to the review comments. The > reason is that the standard track RFC should not cite mailing-list as > references. >=20 > regards, >=20 > xing, congxiao >=20 >> On 4/2/10 5:28 AM, "Xing Li" wrote: >>=20 >> =20 >>> Hi, >>>=20 >>> Reinaldo Penno =1B$B>> =20 >>>> First sentence should read >>>>=20 >>>> * do not send fragment header and do not reduce packet size to 1280 or >>>>=20 >>>>=20 >>>> On 4/1/10 11:40 AM, "Reinaldo Penno" wrote: >>>>=20 >>>> =20 >>>> =20 >>>>> Hello, >>>>>=20 >>>>> It is not clear from the study referenced (the 43.46%) if the IPv6 ho= sts >>>>> that do not comply: >>>>>=20 >>>>> * do send fragment header and reduce packet size to 1280 or >>>>> * do not send fragment header but reduce packet size to 1280 or >>>>> * include a fragmented header but continue to send whatever packet si= ze as >>>>> before. >>>>> =20 >>>>> This leads to the following question: >>>>>=20 >>>>> Let's suppose you have three links: >>>>>=20 >>>>> IPv6-A, MTU 1400 >>>>> IPv4 (B-C), MTU 1480 >>>>> IPv4 (D-E), MTU 1200 >>>>> IPv4 Endhost >>>>>=20 >>>>> A and B and the interfaces of a xlate in the IPv6 and IPv4 worlds >>>>> respectively. >>>>>=20 >>>>> Reading the text my interpretations is the following: If the IPv6 hos= t >>>>> does >>>>> not include a fragmented header in response to 'ICMPv6 too big' and t= he >>>>> packet is 1400 (as above), I should set DF=3D1 in the IPv4 packet and= send >>>>> it >>>>> out. Wouldn't that create a permanent issue (depending on the details= of >>>>> the >>>>> study) since the packets would never traverse D-E? >>>>> =20 >>>>> =20 >>> please see the attached file. the behavior of xlate follows the current >>> specification. it should be no problem. >>>=20 >>> regards, >>>=20 >>> xing, congxiao >>>=20 >>>=20 >>> =20 >>>>> Thanks, >>>>>=20 >>>>> Reinaldo >>>>>=20 >>>>>=20 >>>>> =20 >>>>> =20 >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >>>>=20 >>>>=20 >>>> =20 >>>> =20 >>=20 >>=20 >> =20 >=20 From xing@cernet.edu.cn Fri Apr 2 20:01:42 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E1C83A6812 for ; Fri, 2 Apr 2010 20:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.702 X-Spam-Level: * X-Spam-Status: No, score=1.702 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_HAS_XAIMC=2.696] 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 VptSq2KQtCrC for ; Fri, 2 Apr 2010 20:01:41 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 61A5D3A67CF for ; Fri, 2 Apr 2010 20:01:39 -0700 (PDT) Received: from [192.168.1.100]([123.112.66.192]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54bb6cf66; Sat, 03 Apr 2010 11:01:36 +0800 Message-ID: <4BB6AF89.4080704@cernet.edu.cn> Date: Sat, 03 Apr 2010 11:01:29 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: 2dIctxXB Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Possible issue with Fragmentation text in draft-ietf-behave-v6v4-xlate-15 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 03:01:42 -0000 Hi, Reinaldo, Reinaldo Penno $B Xing, > > I had some discussions offline and would you mind if I suggest some changes > to the draft specifically in the IPv6 to IPv4 translation? > > * First of all, the MTU, fragmentation discussions could use at least a > section heading of its own. > * Then the text (at least IMHO) is somewhat confusing as it tries to explain > the assumption, but if the assumptions are not right do this and then there > is this study which allows us to do that.... > > Maybe something crisp and to the point like: > > "The IPv6 to IPv4 translation assumes the following to work properly" > > * An IPv6 host when receiving an PTB with MTU < 1280 MUST adjust its packet > size to 1280 > * It MAY include a fragmentation header. > Yes, this implies that the IPv6 hosts follow the specifications defined in [RFC2460]. > If the IPv6 host does not adjust its packet size and the translator sets > DF=1 for IPv4 packets > 1280, they might be dropped by an intermediate IPv4 > link where MTU < 1280" > Thanks for this very important notice. We have added a configuration options in Section 3, which will help to solve the problem. * From IPv4 to IPv6 direction, the translator can be configured to adjust the MTU in PTB message from a value smaller than 1280 to 1280. So there is no requirement for the IPv6 hosts to do the adjustment for a "strange" MTU in PTB. Regards, xing, congxiao > Thanks, > > Reinaldo > > > > > On 4/2/10 9:15 AM, "Xing Li" wrote: > > >> Reinaldo Penno $B> >> thanks. >> >>> Thanks for the great diagram. So, irrespective of the spec, what you are >>> saying is that current implementations reduce the packet size to 1280 >>> (although might not include a fragmentation header)? >>> >>> >> correct. >> >> >>> In other words, in the study clients actually reduce the packet size. That >>> was not clear. I would suggest putting a reference to the study in the >>> draft. >>> >>> >>> >> actually, we have cited a reference [Stasiewicz >> http://www.ietf.org/mail-archive/web/behave/current/msg08093.html ] upto >> version 11 (http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-11). >> It was removed in version 12 according to the review comments. The >> reason is that the standard track RFC should not cite mailing-list as >> references. >> >> regards, >> >> xing, congxiao >> >> >>> On 4/2/10 5:28 AM, "Xing Li" wrote: >>> >>> >>> >>>> Hi, >>>> >>>> Reinaldo Penno $B>>> >>>> >>>>> First sentence should read >>>>> >>>>> * do not send fragment header and do not reduce packet size to 1280 or >>>>> >>>>> >>>>> On 4/1/10 11:40 AM, "Reinaldo Penno" wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Hello, >>>>>> >>>>>> It is not clear from the study referenced (the 43.46%) if the IPv6 hosts >>>>>> that do not comply: >>>>>> >>>>>> * do send fragment header and reduce packet size to 1280 or >>>>>> * do not send fragment header but reduce packet size to 1280 or >>>>>> * include a fragmented header but continue to send whatever packet size as >>>>>> before. >>>>>> >>>>>> This leads to the following question: >>>>>> >>>>>> Let's suppose you have three links: >>>>>> >>>>>> IPv6-A, MTU 1400 >>>>>> IPv4 (B-C), MTU 1480 >>>>>> IPv4 (D-E), MTU 1200 >>>>>> IPv4 Endhost >>>>>> >>>>>> A and B and the interfaces of a xlate in the IPv6 and IPv4 worlds >>>>>> respectively. >>>>>> >>>>>> Reading the text my interpretations is the following: If the IPv6 host >>>>>> does >>>>>> not include a fragmented header in response to 'ICMPv6 too big' and the >>>>>> packet is 1400 (as above), I should set DF=1 in the IPv4 packet and send >>>>>> it >>>>>> out. Wouldn't that create a permanent issue (depending on the details of >>>>>> the >>>>>> study) since the packets would never traverse D-E? >>>>>> >>>>>> >>>>>> >>>> please see the attached file. the behavior of xlate follows the current >>>> specification. it should be no problem. >>>> >>>> regards, >>>> >>>> xing, congxiao >>>> >>>> >>>> >>>> >>>>>> Thanks, >>>>>> >>>>>> Reinaldo >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Behave mailing list >>>>> Behave@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/behave >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> > > > From root@core3.amsl.com Fri Apr 2 20:15:03 2010 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 496D13A688B; Fri, 2 Apr 2010 20:15:02 -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: <20100403031503.496D13A688B@core3.amsl.com> Date: Fri, 2 Apr 2010 20:15:03 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-16.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 03:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : IP/ICMP Translation Algorithm Author(s) : X. Li, et al. Filename : draft-ietf-behave-v6v4-xlate-16.txt Pages : 31 Date : 2010-04-02 This document forms a replacement of the Stateless IP/ICMP Translation Algorithm (SIIT) described in RFC 2765. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-16.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-behave-v6v4-xlate-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-02200229.I-D@ietf.org> --NextPart-- From touch@ISI.EDU Sat Apr 3 10:34:14 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B9753A6964 for ; Sat, 3 Apr 2010 10:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 cUwGUfB+aayz for ; Sat, 3 Apr 2010 10:34:13 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 97D4F3A6951 for ; Sat, 3 Apr 2010 10:34:10 -0700 (PDT) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o33HWxvO018725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 3 Apr 2010 10:33:01 -0700 (PDT) Message-ID: <4BB77BCB.2080904@isi.edu> Date: Sat, 03 Apr 2010 10:32:59 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA785AAAD3EF0189919BED430" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Reconciliation of draft-ietf-intarea-ipv4-id-update-00 and BEHAVE X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 17:34:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA785AAAD3EF0189919BED430 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Reinaldo, Reinaldo Penno wrote: > There was some discussion in IETF-77 about IP IDs regarding this draft = but > reading it in more detail, it seems a reconciliation is needed with NAT= 64 > and Stateless XLATE. >=20 >=20 > A few snippets: >=20 > o >> Sources SHOULD set DF=3D1. >=20 > o >> IPv4 fragmentation SHOULD be limited to the originating source, > even when the DF field allows it. >=20 > o >> Sources unable to meet the non-repeating IP ID requirement > above MUST NOT emit non-atomic packets. > =20 > [Reinaldo] I think this means certain kinds of NATs (stateless) cannot > fragment packets. Yes. > o >> Sources emitting non-atomic IPv4 packets SHOULD NOT repeat ID > field values within a given source IP, destination IP, and > protocol tuple over the period that fragment reordering would > affect reassembly. >=20 > [Reinaldo] This of course is difficult for stateless NAT This has been a requirement since RFC 791. NATs have ignored it since their inception, but that doesn't mean that the requirement has been (or even can or should be) relaxed. Ignoring this requirement can result in incorrectly reassembled fragments. Such errors may not be detected, e.g., either because of the lack of a transport checksum (e.g., UDP) or due to weak checksums that don't detect some such errors (e.g., TCP). > o >> Sources that cannot ensure safe IPv4 ID generation and that > allow DF=3D0 SHOULD employ integrity checks that would detect mis= - > reassembled fragments, e.g, as in SEAL [RFC5320 > ]. Applications > SHOULD NOT use UDP without checksums [RFC793 > ], and SHOULD be very > careful in their use of UDP-Lite [RFC3828 > ] in such environments. >=20 > [Reinaldo] This also has a direct impact in BEHAVE xlate documents. I would think so. NATs that want to play nice need to start considering their impact on fragmentation and reassembly. > o >> Overlapping packets MUST be silently ignored during reassembly.= >=20 > o >> IP-in-IP tunnels SHOULD emit only atomic packets. >=20 > Note that this recommendation applies to all tunnels, but the focus > of this document is IPv4 requirements, so its explicit requirements > focus on IPv4 cases. >=20 > [Reinaldo] I think this impacts softwire/DS-Lite. Need to follow up the= re. Yes - we're planning on presenting this issue to the software WG in the next IETF, FWIW. Joe --------------enigA785AAAD3EF0189919BED430 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAku3e8sACgkQE5f5cImnZrtCGACg+kopFaCtnHrFowPA3KoWhpqW SCsAoPEEW9dyMOQ7B+Ng3BRz6saNjGmz =DBDb -----END PGP SIGNATURE----- --------------enigA785AAAD3EF0189919BED430-- From rpenno@juniper.net Tue Apr 6 12:00:45 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E96A3A6A5D for ; Tue, 6 Apr 2010 12:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 kGahJhwPWA1d for ; Tue, 6 Apr 2010 12:00:41 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 8D31028C118 for ; Tue, 6 Apr 2010 12:00:12 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKS7uEuV/Gfutb3qDZBuV6hWQfhdQ/jQ9c@postini.com; Tue, 06 Apr 2010 12:00:12 PDT 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.1.393.1; Tue, 6 Apr 2010 11:56:55 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 6 Apr 2010 14:56:55 -0400 From: Reinaldo Penno To: Xing Li Date: Tue, 6 Apr 2010 14:56:53 -0400 Thread-Topic: [BEHAVE] Possible issue with Fragmentation text in draft-ietf-behave-v6v4-xlate-15 Thread-Index: AcrS2f+fK6boRbUsTFqj5dtd+RyZOAC4Owp4 Message-ID: In-Reply-To: <4BB6AF89.4080704@cernet.edu.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.4.0.100208 acceptlanguage: en-US Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Possible issue with Fragmentation text in draft-ietf-behave-v6v4-xlate-15 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 19:00:45 -0000 Xing, Thanks for the change but I still find this text extremely confusing...mayb= e It is just me. Let me give an example: " There are some differences between IPv6 and IPv4 in the area of fragmentation and the minimum link MTU that affect the translation. An IPv6 link has to have an MTU of 1280 bytes or greater. The corresponding limit for IPv4 is 68 bytes. Thus, unless there were special measures, it would not be possible to do end-to-end path MTU discovery when the path includes a translator, since the IPv6 node might receive ICMPv6 "Packet Too Big" messages originated by an IPv4 router that report an MTU less than 1280. However, [RFC2460] section 5 requires that IPv6 nodes handle such an ICMPv6 "Packet Too Big" message by reducing the path MTU to 1280 and including an IPv6 fragment header with each packet. In this case, the translator SHOULD set DF to 0 and take the identification value from the IPv6 fragment header when a fragmentation header with (MF=3D0; Offset=3D0) is present or set DF to 1 otherwise. " [Reinaldo] the premise of this whole text above was that the PTB message reported a MTU below 1280. But then, the next sentence (below) says that 'this' will allow PMTU to work as long as the path in 1280 or greater...So, the discussion and conclusion are about different scenarios. " This allows end-to-end path MTU discovery across the translator as long as the path MTU is 1280 bytes or greater.=20 " On 4/2/10 8:01 PM, "Xing Li" wrote: > Hi, Reinaldo, >=20 > Reinaldo Penno =1B$B> Xing, >>=20 >> I had some discussions offline and would you mind if I suggest some chan= ges >> to the draft specifically in the IPv6 to IPv4 translation? >> =20 >> * First of all, the MTU, fragmentation discussions could use at least a >> section heading of its own. >> * Then the text (at least IMHO) is somewhat confusing as it tries to exp= lain >> the assumption, but if the assumptions are not right do this and then th= ere >> is this study which allows us to do that.... >>=20 >> Maybe something crisp and to the point like: >>=20 >> "The IPv6 to IPv4 translation assumes the following to work properly" >>=20 >> * An IPv6 host when receiving an PTB with MTU < 1280 MUST adjust its pac= ket >> size to 1280 >> * It MAY include a fragmentation header. >> =20 >=20 > Yes, this implies that the IPv6 hosts follow the specifications defined > in [RFC2460]. >> If the IPv6 host does not adjust its packet size and the translator sets >> DF=3D1 for IPv4 packets > 1280, they might be dropped by an intermediat= e IPv4 >> link where MTU < 1280" >> =20 > Thanks for this very important notice. We have added a configuration > options in > Section 3, which will help to solve the problem. >=20 > * From IPv4 to IPv6 direction, the translator can be configured to adjust= the > MTU in PTB message from a value smaller than 1280 to 1280. So there is no > requirement for the IPv6 hosts to do the adjustment for a "strange" MTU i= n > PTB. >=20 > Regards, >=20 > xing, congxiao >=20 >=20 >=20 >> Thanks, >>=20 >> Reinaldo >>=20 >>=20 >>=20 >>=20 >> On 4/2/10 9:15 AM, "Xing Li" wrote: >>=20 >> =20 >>> Reinaldo Penno =1B$B>>=20 >>> thanks. >>> =20 >>>> Thanks for the great diagram. So, irrespective of the spec, what you a= re >>>> saying is that current implementations reduce the packet size to 1280 >>>> (although might not include a fragmentation header)? >>>> =20 >>>> =20 >>> correct. >>>=20 >>> =20 >>>> In other words, in the study clients actually reduce the packet size. = That >>>> was not clear. I would suggest putting a reference to the study in the >>>> draft. >>>>=20 >>>> =20 >>>> =20 >>> actually, we have cited a reference [Stasiewicz >>> http://www.ietf.org/mail-archive/web/behave/current/msg08093.html ] upt= o >>> version 11 (http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-11)= . >>> It was removed in version 12 according to the review comments. The >>> reason is that the standard track RFC should not cite mailing-list as >>> references. >>>=20 >>> regards, >>>=20 >>> xing, congxiao >>>=20 >>> =20 >>>> On 4/2/10 5:28 AM, "Xing Li" wrote: >>>>=20 >>>> =20 >>>> =20 >>>>> Hi, >>>>>=20 >>>>> Reinaldo Penno =1B$B>>>> =20 >>>>> =20 >>>>>> First sentence should read >>>>>>=20 >>>>>> * do not send fragment header and do not reduce packet size to 1280 = or >>>>>>=20 >>>>>>=20 >>>>>> On 4/1/10 11:40 AM, "Reinaldo Penno" wrote: >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>>> Hello, >>>>>>>=20 >>>>>>> It is not clear from the study referenced (the 43.46%) if the IPv6 = hosts >>>>>>> that do not comply: >>>>>>>=20 >>>>>>> * do send fragment header and reduce packet size to 1280 or >>>>>>> * do not send fragment header but reduce packet size to 1280 or >>>>>>> * include a fragmented header but continue to send whatever packet = size >>>>>>> as >>>>>>> before. >>>>>>> =20 >>>>>>> This leads to the following question: >>>>>>>=20 >>>>>>> Let's suppose you have three links: >>>>>>>=20 >>>>>>> IPv6-A, MTU 1400 >>>>>>> IPv4 (B-C), MTU 1480 >>>>>>> IPv4 (D-E), MTU 1200 >>>>>>> IPv4 Endhost >>>>>>>=20 >>>>>>> A and B and the interfaces of a xlate in the IPv6 and IPv4 worlds >>>>>>> respectively. >>>>>>>=20 >>>>>>> Reading the text my interpretations is the following: If the IPv6 h= ost >>>>>>> does >>>>>>> not include a fragmented header in response to 'ICMPv6 too big' and= the >>>>>>> packet is 1400 (as above), I should set DF=3D1 in the IPv4 packet a= nd send >>>>>>> it >>>>>>> out. Wouldn't that create a permanent issue (depending on the detai= ls of >>>>>>> the >>>>>>> study) since the packets would never traverse D-E? >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>> please see the attached file. the behavior of xlate follows the curre= nt >>>>> specification. it should be no problem. >>>>>=20 >>>>> regards, >>>>>=20 >>>>> xing, congxiao >>>>>=20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>>>> Thanks, >>>>>>>=20 >>>>>>> Reinaldo >>>>>>>=20 >>>>>>>=20 >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>> _______________________________________________ >>>>>> Behave mailing list >>>>>> Behave@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/behave >>>>>>=20 >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>> =20 >>>> =20 >>=20 >>=20 >> =20 >=20 From dwing@cisco.com Tue Apr 6 15:29:25 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8D353A6856 for ; Tue, 6 Apr 2010 15:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.197 X-Spam-Level: X-Spam-Status: No, score=-10.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 X-OcPgwCDzEW for ; Tue, 6 Apr 2010 15:29:24 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 77DDE3A68E9 for ; Tue, 6 Apr 2010 15:29:24 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIKAMZSu0urRN+J/2dsb2JhbACDEoRGgRSSTnGhFohAAZBTgSmCb3EEgyQ X-IronPort-AV: E=Sophos;i="4.51,374,1267401600"; d="scan'208";a="178988239" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 06 Apr 2010 22:29:05 +0000 Received: from dwingwxp01 (sjc-vpn4-120.cisco.com [10.21.80.120]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o36MT4n8020294; Tue, 6 Apr 2010 22:29:04 GMT From: "Dan Wing" To: "'Reinaldo Penno'" References: <4BB6AF89.4080704@cernet.edu.cn> Date: Tue, 6 Apr 2010 15:29:04 -0700 Message-ID: <08f101cad5d8$90a19040$7893150a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcrS2f+fK6boRbUsTFqj5dtd+RyZOAC4Owp4AAdfNFA= In-Reply-To: Cc: 'Xing Li' , behave@ietf.org Subject: Re: [BEHAVE] Possible issue with Fragmentation text in draft-ietf-behave-v6v4-xlate-15 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 22:29:26 -0000 As the document has already been submitted to IESG, can you suggest specific text so this can be turned around quickly? -d > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Reinaldo Penno > Sent: Tuesday, April 06, 2010 11:57 AM > To: Xing Li > Cc: behave@ietf.org > Subject: Re: [BEHAVE] Possible issue with Fragmentation text > in draft-ietf-behave-v6v4-xlate-15 > > Xing, > > Thanks for the change but I still find this text extremely > confusing...maybe > It is just me. Let me give an example: > > " There are some differences between IPv6 and IPv4 in the area of > fragmentation and the minimum link MTU that affect the translation. > An IPv6 link has to have an MTU of 1280 bytes or greater. The > corresponding limit for IPv4 is 68 bytes. Thus, unless there were > special measures, it would not be possible to do > end-to-end path MTU > discovery when the path includes a translator, since the IPv6 node > might receive ICMPv6 "Packet Too Big" messages originated > by an IPv4 > router that report an MTU less than 1280. However, > [RFC2460] section > 5 requires that IPv6 nodes handle such an ICMPv6 "Packet Too Big" > message by reducing the path MTU to 1280 and including an IPv6 > fragment header with each packet. In this case, the translator > SHOULD set DF to 0 and take the identification value from the IPv6 > fragment header when a fragmentation header with (MF=0; > Offset=0) is > present or set DF to 1 otherwise. " > > [Reinaldo] the premise of this whole text above was that the > PTB message > reported a MTU below 1280. But then, the next sentence > (below) says that > 'this' will allow PMTU to work as long as the path in 1280 or > greater...So, > the discussion and conclusion are about different scenarios. > > " This allows end-to-end path MTU > discovery across the translator as long as the path MTU is > 1280 bytes > or greater. > " > > > On 4/2/10 8:01 PM, "Xing Li" wrote: > > > Hi, Reinaldo, > > > > Reinaldo Penno $B >> Xing, > >> > >> I had some discussions offline and would you mind if I > suggest some changes > >> to the draft specifically in the IPv6 to IPv4 translation? > >> > >> * First of all, the MTU, fragmentation discussions could > use at least a > >> section heading of its own. > >> * Then the text (at least IMHO) is somewhat confusing as > it tries to explain > >> the assumption, but if the assumptions are not right do > this and then there > >> is this study which allows us to do that.... > >> > >> Maybe something crisp and to the point like: > >> > >> "The IPv6 to IPv4 translation assumes the following to > work properly" > >> > >> * An IPv6 host when receiving an PTB with MTU < 1280 MUST > adjust its packet > >> size to 1280 > >> * It MAY include a fragmentation header. > >> > > > > Yes, this implies that the IPv6 hosts follow the > specifications defined > > in [RFC2460]. > >> If the IPv6 host does not adjust its packet size and the > translator sets > >> DF=1 for IPv4 packets > 1280, they might be dropped by an > intermediate IPv4 > >> link where MTU < 1280" > >> > > Thanks for this very important notice. We have added a configuration > > options in > > Section 3, which will help to solve the problem. > > > > * From IPv4 to IPv6 direction, the translator can be > configured to adjust the > > MTU in PTB message from a value smaller than 1280 to 1280. > So there is no > > requirement for the IPv6 hosts to do the adjustment for a > "strange" MTU in > > PTB. > > > > Regards, > > > > xing, congxiao > > > > > > > >> Thanks, > >> > >> Reinaldo > >> > >> > >> > >> > >> On 4/2/10 9:15 AM, "Xing Li" wrote: > >> > >> > >>> Reinaldo Penno $B >>> > >>> thanks. > >>> > >>>> Thanks for the great diagram. So, irrespective of the > spec, what you are > >>>> saying is that current implementations reduce the packet > size to 1280 > >>>> (although might not include a fragmentation header)? > >>>> > >>>> > >>> correct. > >>> > >>> > >>>> In other words, in the study clients actually reduce the > packet size. That > >>>> was not clear. I would suggest putting a reference to > the study in the > >>>> draft. > >>>> > >>>> > >>>> > >>> actually, we have cited a reference [Stasiewicz > >>> > http://www.ietf.org/mail-archive/web/behave/current/msg08093.h > tml ] upto > >>> version 11 > (http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-11). > >>> It was removed in version 12 according to the review comments. The > >>> reason is that the standard track RFC should not cite > mailing-list as > >>> references. > >>> > >>> regards, > >>> > >>> xing, congxiao > >>> > >>> > >>>> On 4/2/10 5:28 AM, "Xing Li" wrote: > >>>> > >>>> > >>>> > >>>>> Hi, > >>>>> > >>>>> Reinaldo Penno $B >>>>> > >>>>> > >>>>>> First sentence should read > >>>>>> > >>>>>> * do not send fragment header and do not reduce packet > size to 1280 or > >>>>>> > >>>>>> > >>>>>> On 4/1/10 11:40 AM, "Reinaldo Penno" > wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Hello, > >>>>>>> > >>>>>>> It is not clear from the study referenced (the > 43.46%) if the IPv6 hosts > >>>>>>> that do not comply: > >>>>>>> > >>>>>>> * do send fragment header and reduce packet size to 1280 or > >>>>>>> * do not send fragment header but reduce packet size > to 1280 or > >>>>>>> * include a fragmented header but continue to send > whatever packet size > >>>>>>> as > >>>>>>> before. > >>>>>>> > >>>>>>> This leads to the following question: > >>>>>>> > >>>>>>> Let's suppose you have three links: > >>>>>>> > >>>>>>> IPv6-A, MTU 1400 > >>>>>>> IPv4 (B-C), MTU 1480 > >>>>>>> IPv4 (D-E), MTU 1200 > >>>>>>> IPv4 Endhost > >>>>>>> > >>>>>>> A and B and the interfaces of a xlate in the IPv6 and > IPv4 worlds > >>>>>>> respectively. > >>>>>>> > >>>>>>> Reading the text my interpretations is the following: > If the IPv6 host > >>>>>>> does > >>>>>>> not include a fragmented header in response to > 'ICMPv6 too big' and the > >>>>>>> packet is 1400 (as above), I should set DF=1 in the > IPv4 packet and send > >>>>>>> it > >>>>>>> out. Wouldn't that create a permanent issue > (depending on the details of > >>>>>>> the > >>>>>>> study) since the packets would never traverse D-E? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> please see the attached file. the behavior of xlate > follows the current > >>>>> specification. it should be no problem. > >>>>> > >>>>> regards, > >>>>> > >>>>> xing, congxiao > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> Reinaldo > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> Behave mailing list > >>>>>> Behave@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/behave > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > >> > >> > >> > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From xing@cernet.edu.cn Tue Apr 6 16:36:26 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E2823A68A7 for ; Tue, 6 Apr 2010 16:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696] 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 1Ly9NjkK6bVx for ; Tue, 6 Apr 2010 16:36:24 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id E524F3A67E1 for ; Tue, 6 Apr 2010 16:36:23 -0700 (PDT) Received: from [192.168.1.100]([125.34.51.111]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54bbbd4d5; Wed, 07 Apr 2010 07:36:20 +0800 Message-ID: <4BBBC569.2060704@cernet.edu.cn> Date: Wed, 07 Apr 2010 07:36:09 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: 6XgTSzXB Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Possible issue with Fragmentation text in draft-ietf-behave-v6v4-xlate-15 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 23:36:26 -0000 Hi, Reinaldo Penno $B Xing, > > Thanks for the change but I still find this text extremely confusing...maybe > It is just me. Let me give an example: > > " There are some differences between IPv6 and IPv4 in the area of > fragmentation and the minimum link MTU that affect the translation. > An IPv6 link has to have an MTU of 1280 bytes or greater. The > corresponding limit for IPv4 is 68 bytes. Thus, unless there were > special measures, it would not be possible to do end-to-end path MTU > discovery when the path includes a translator, since the IPv6 node > might receive ICMPv6 "Packet Too Big" messages originated by an IPv4 > router that report an MTU less than 1280. However, [RFC2460] section > 5 requires that IPv6 nodes handle such an ICMPv6 "Packet Too Big" > message by reducing the path MTU to 1280 and including an IPv6 > fragment header with each packet. In this case, the translator > SHOULD set DF to 0 and take the identification value from the IPv6 > fragment header when a fragmentation header with (MF=0; Offset=0) is > present or set DF to 1 otherwise. " > > [Reinaldo] the premise of this whole text above was that the PTB message > reported a MTU below 1280. But then, the next sentence (below) says that > 'this' will allow PMTU to work as long as the path in 1280 or greater...So, > the discussion and conclusion are about different scenarios. > > " This allows end-to-end path MTU > discovery across the translator as long as the path MTU is 1280 bytes > or greater. > Actually this is the idea originally presented in RFC2460. The two sentences you have cited are consistent. They imply that For the packets from IPv6 to IPv4: (1) If the minimum MTU along the path is greater than 1280, the translation allows PMTU. (2) If the minimum MTU along the path is equal to or smaller than 1280, the translation cannot do PMTU. As Dan suggested, you may suggest some text. Regards, xing, congxiao > " > > > On 4/2/10 8:01 PM, "Xing Li" wrote: > > >> Hi, Reinaldo, >> >> Reinaldo Penno $B> >>> Xing, >>> >>> I had some discussions offline and would you mind if I suggest some changes >>> to the draft specifically in the IPv6 to IPv4 translation? >>> >>> * First of all, the MTU, fragmentation discussions could use at least a >>> section heading of its own. >>> * Then the text (at least IMHO) is somewhat confusing as it tries to explain >>> the assumption, but if the assumptions are not right do this and then there >>> is this study which allows us to do that.... >>> >>> Maybe something crisp and to the point like: >>> >>> "The IPv6 to IPv4 translation assumes the following to work properly" >>> >>> * An IPv6 host when receiving an PTB with MTU < 1280 MUST adjust its packet >>> size to 1280 >>> * It MAY include a fragmentation header. >>> >>> >> Yes, this implies that the IPv6 hosts follow the specifications defined >> in [RFC2460]. >> >>> If the IPv6 host does not adjust its packet size and the translator sets >>> DF=1 for IPv4 packets > 1280, they might be dropped by an intermediate IPv4 >>> link where MTU < 1280" >>> >>> >> Thanks for this very important notice. We have added a configuration >> options in >> Section 3, which will help to solve the problem. >> >> * From IPv4 to IPv6 direction, the translator can be configured to adjust the >> MTU in PTB message from a value smaller than 1280 to 1280. So there is no >> requirement for the IPv6 hosts to do the adjustment for a "strange" MTU in >> PTB. >> >> Regards, >> >> xing, congxiao >> >> >> >> >>> Thanks, >>> >>> Reinaldo >>> >>> >>> >>> >>> On 4/2/10 9:15 AM, "Xing Li" wrote: >>> >>> >>> >>>> Reinaldo Penno $B>>> >>>> thanks. >>>> >>>> >>>>> Thanks for the great diagram. So, irrespective of the spec, what you are >>>>> saying is that current implementations reduce the packet size to 1280 >>>>> (although might not include a fragmentation header)? >>>>> >>>>> >>>>> >>>> correct. >>>> >>>> >>>> >>>>> In other words, in the study clients actually reduce the packet size. That >>>>> was not clear. I would suggest putting a reference to the study in the >>>>> draft. >>>>> >>>>> >>>>> >>>>> >>>> actually, we have cited a reference [Stasiewicz >>>> http://www.ietf.org/mail-archive/web/behave/current/msg08093.html ] upto >>>> version 11 (http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-11). >>>> It was removed in version 12 according to the review comments. The >>>> reason is that the standard track RFC should not cite mailing-list as >>>> references. >>>> >>>> regards, >>>> >>>> xing, congxiao >>>> >>>> >>>> >>>>> On 4/2/10 5:28 AM, "Xing Li" wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> Reinaldo Penno $B>>>>> >>>>>> >>>>>> >>>>>>> First sentence should read >>>>>>> >>>>>>> * do not send fragment header and do not reduce packet size to 1280 or >>>>>>> >>>>>>> >>>>>>> On 4/1/10 11:40 AM, "Reinaldo Penno" wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> It is not clear from the study referenced (the 43.46%) if the IPv6 hosts >>>>>>>> that do not comply: >>>>>>>> >>>>>>>> * do send fragment header and reduce packet size to 1280 or >>>>>>>> * do not send fragment header but reduce packet size to 1280 or >>>>>>>> * include a fragmented header but continue to send whatever packet size >>>>>>>> as >>>>>>>> before. >>>>>>>> >>>>>>>> This leads to the following question: >>>>>>>> >>>>>>>> Let's suppose you have three links: >>>>>>>> >>>>>>>> IPv6-A, MTU 1400 >>>>>>>> IPv4 (B-C), MTU 1480 >>>>>>>> IPv4 (D-E), MTU 1200 >>>>>>>> IPv4 Endhost >>>>>>>> >>>>>>>> A and B and the interfaces of a xlate in the IPv6 and IPv4 worlds >>>>>>>> respectively. >>>>>>>> >>>>>>>> Reading the text my interpretations is the following: If the IPv6 host >>>>>>>> does >>>>>>>> not include a fragmented header in response to 'ICMPv6 too big' and the >>>>>>>> packet is 1400 (as above), I should set DF=1 in the IPv4 packet and send >>>>>>>> it >>>>>>>> out. Wouldn't that create a permanent issue (depending on the details of >>>>>>>> the >>>>>>>> study) since the packets would never traverse D-E? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> please see the attached file. the behavior of xlate follows the current >>>>>> specification. it should be no problem. >>>>>> >>>>>> regards, >>>>>> >>>>>> xing, congxiao >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Reinaldo >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Behave mailing list >>>>>>> Behave@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/behave >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>> >>> > > > From simon.perreault@viagenie.ca Tue Apr 6 17:27:55 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 669613A672F; Tue, 6 Apr 2010 17:27:55 -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 S5rgBMB3Rv4c; Tue, 6 Apr 2010 17:27:54 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id 2CD803A62C1; Tue, 6 Apr 2010 17:27:54 -0700 (PDT) Received: from balaise.nomis80.org (modemcable245.152-21-96.mc.videotron.ca [96.21.152.245]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 37B7E21C38; Tue, 6 Apr 2010 20:27:50 -0400 (EDT) Message-ID: <4BBBD185.7090606@viagenie.ca> Date: Tue, 06 Apr 2010 20:27:49 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3 MIME-Version: 1.0 To: Richard Barnes References: <188D3671-05E9-40A2-9498-24BAE91B269E@bbn.com> In-Reply-To: <188D3671-05E9-40A2-9498-24BAE91B269E@bbn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-behave-turn-ipv6@tools.ietf.org, "behave@ietf.org" , iesg@ietf.org, secdir@ietf.org Subject: Re: [BEHAVE] secdir review of draft-ietf-behave-turn-ipv6-09 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 00:27:55 -0000 On 03/29/2010 05:45 PM, Richard Barnes wrote: > My only significant concern that is not addressed in the > document is how this mechanism relates to the routing loop attacks > introduced by other forms of v4/v6 translation and tunneling, e.g., as > discussed in this paper: > > It's not immediately obvious to me that extending TURN in this way makes > these (currently non-TURN-related) attacks viable, but I would encourage > the authors to consider the issue and add some text to the document > explaining how the attacks do or do not apply here. (See bottom of this email.) > S.3, Paragraph "Assuming the request..." > The server doesn't "assume" that the request is authenticated. Suggest > rephrasing as "After the request has been successfully authenticated, ..." Agreed, fixed. > S4.1.1 > Why not just make this option one byte long? If you're already > anticipating a usage for the reserved space, you should just specify it. STUN attributes must be padded to a multiple of 4 bytes. (Reference: RFC 5389, section 15.) > S4.2, First paragraph > As above, suggest rephrasing as "Once a server has verified that the > request is authenticated and has not been tampered with, ..." Agreed, fixed. > S4.3 > Why is this a SHOULD NOT and not a MUST NOT? What's the exceptional case? I have no idea. I'll change it to a MUST NOT unless I receive more info from my co-authors. > Section 9, First para > It seems overly broad to say that "an IPv4-only client having access to > ... this specifictation is now able to access the IPv6 Internet". The > client can't just send/receive traffic with any node, right? Explain > the restrictions in place here. The client can indeed send/receive traffic with any node (as long as it is allowed by local security policy). Could you please explain the restrictions you have in mind? > Section 9, > Might some of the Teredo / 6to4 loop attacks apply as well? If not, why > not? > -- Spoof 4-to-6 allocate request from relay's v4 address > -- Spoof authorization relay's v6 address > -- Spoof packet from either of relay's addresses Sure, these are ways of spoofing IPv6 packets that are enabled by Teredo and 6to4. There are many others. Is there a reference we can cite? Would citing the Usenix paper be OK? > If there is some risk here, you might consider saying something like > "Server MUST NOT allocate 6to4 or Teredo addresses or accept them as > peers"? I have no idea if that would be right or not. Can somebody with a clue please weigh in? Thanks, Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From root@core3.amsl.com Wed Apr 7 01:00:01 2010 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 688F73A68E4; Wed, 7 Apr 2010 01:00: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: <20100407080001.688F73A68E4@core3.amsl.com> Date: Wed, 7 Apr 2010 01:00:01 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-17.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 08:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : IP/ICMP Translation Algorithm Author(s) : X. Li, et al. Filename : draft-ietf-behave-v6v4-xlate-17.txt Pages : 31 Date : 2010-04-07 This document forms a replacement of the Stateless IP/ICMP Translation Algorithm (SIIT) described in RFC 2765. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-17.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-behave-v6v4-xlate-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-07004936.I-D@ietf.org> --NextPart-- From rvaithia@cisco.com Wed Apr 7 01:55:46 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 938373A6830 for ; Wed, 7 Apr 2010 01:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vw2omVJb2PzJ for ; Wed, 7 Apr 2010 01:55:45 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C14753A682D for ; Wed, 7 Apr 2010 01:55:45 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAELlu0urR7Hu/2dsb2JhbACbPHGgVpkmhQkEgySLEw X-IronPort-AV: E=Sophos;i="4.51,377,1267401600"; d="scan'208";a="179267509" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 07 Apr 2010 08:55:43 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o378thTb027944; Wed, 7 Apr 2010 08:55:43 GMT Received: from xmb-sjc-231.amer.cisco.com ([128.107.191.73]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Apr 2010 01:55:43 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Apr 2010 01:55:42 -0700 Message-ID: In-Reply-To: <20100407080001.688F73A68E4@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-17.txt Thread-Index: AcrWKFdmfL66lWOQRR6JbrrZwBLNfQABxpeA References: <20100407080001.688F73A68E4@core3.amsl.com> From: "Ramji Vaithianathan (rvaithia)" To: "Xing Li" X-OriginalArrivalTime: 07 Apr 2010 08:55:43.0439 (UTC) FILETIME=[1B118DF0:01CAD630] Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-17.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 08:55:46 -0000 Hi, In the latest draft it is mentioned: The translator MUST provide a configuration function to adjust the MTU=09 from a value smaller than 1280 to 1280, which is required=09 for the workaround ([RFC2460] related issue) discussed in=09 Section 4.=20 What exactly does "configuration function" mean? Does it mean that there MUST be a CLI configurable option in the translator to adjust the value smaller than 1280 to 1280? Or does it just mean that the translator must have the functionality/capablity to adjust the MTU smaller than 1280 to 1280 always? Thanks, Ramji -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, April 07, 2010 1:30 PM To: i-d-announce@ietf.org Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-17.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : IP/ICMP Translation Algorithm Author(s) : X. Li, et al. Filename : draft-ietf-behave-v6v4-xlate-17.txt Pages : 31 Date : 2010-04-07 This document forms a replacement of the Stateless IP/ICMP Translation Algorithm (SIIT) described in RFC 2765. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-17.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. From xing@cernet.edu.cn Wed Apr 7 02:18:38 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D6FC3A686D for ; Wed, 7 Apr 2010 02:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696] 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 Gh01atXCqxIq for ; Wed, 7 Apr 2010 02:18:36 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 5E7CA3A67D4 for ; Wed, 7 Apr 2010 02:18:26 -0700 (PDT) Received: from [59.66.24.35]([59.66.24.35]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54bbc5d3f; Wed, 07 Apr 2010 17:18:21 +0800 Message-ID: <4BBC4CC2.9060108@cernet.edu.cn> Date: Wed, 07 Apr 2010 17:13:38 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Ramji Vaithianathan (rvaithia)" References: <20100407080001.688F73A68E4@core3.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: 6TvY1zXB Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-17.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 09:18:38 -0000 Ramji Vaithianathan (rvaithia) 写道: > Hi, > > In the latest draft it is mentioned: > > The translator MUST provide a configuration function to adjust the MTU > from a value smaller than 1280 to 1280, which is > required > for the workaround ([RFC2460] related issue) > discussed in > Section 4. > > What exactly does "configuration function" mean? > > Does it mean that there MUST be a CLI configurable option in the > translator to adjust the value smaller than 1280 to 1280? > > Or does it just mean that the translator must have the > functionality/capablity to adjust the MTU smaller than 1280 to 1280 > always? > Yes, the translator must have the functionality/capablity to adjust the MTU smaller than 1280 to 1280 always. Regards, xing > Thanks, > > Ramji > > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Internet-Drafts@ietf.org > Sent: Wednesday, April 07, 2010 1:30 PM > To: i-d-announce@ietf.org > Cc: behave@ietf.org > Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-17.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Behavior Engineering for Hindrance > Avoidance Working Group of the IETF. > > > Title : IP/ICMP Translation Algorithm > Author(s) : X. Li, et al. > Filename : draft-ietf-behave-v6v4-xlate-17.txt > Pages : 31 > Date : 2010-04-07 > > This document forms a replacement of the Stateless IP/ICMP Translation > Algorithm (SIIT) described in RFC 2765. The algorithm translates > between IPv4 and IPv6 packet headers (including ICMP headers). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-17.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. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > From simon.perreault@viagenie.ca Wed Apr 7 05:05:35 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C50D3A6912 for ; Wed, 7 Apr 2010 05:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 MDHjOLqMu9Rd for ; Wed, 7 Apr 2010 05:05:34 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id 6BB2C3A68FC for ; Wed, 7 Apr 2010 05:05:34 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EBBE0210F7 for ; Wed, 7 Apr 2010 08:05:30 -0400 (EDT) Message-ID: <4BBC750A.5020501@viagenie.ca> Date: Wed, 07 Apr 2010 08:05:30 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3 MIME-Version: 1.0 To: behave@ietf.org References: <20100407080001.688F73A68E4@core3.amsl.com> <4BBC4CC2.9060108@cernet.edu.cn> In-Reply-To: <4BBC4CC2.9060108@cernet.edu.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-17.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 12:05:35 -0000 On 2010-04-07 05:13, Xing Li wrote: >> What exactly does "configuration function" mean? >> >> Does it mean that there MUST be a CLI configurable option in the >> translator to adjust the value smaller than 1280 to 1280? >> >> Or does it just mean that the translator must have the >> functionality/capablity to adjust the MTU smaller than 1280 to 1280 >> always? > Yes, the translator must have the functionality/capablity to adjust the > MTU smaller than 1280 to 1280 always. As an implementor, let met say that I don't understand what this means. Does this mean the following? if (config->mtu_floor && ntohl(icmp6->icmp6_mtu) < 1280) icmp6->icmp6_mtu = htonl(1280); In this case, is there a recommended value for the configuration variable? Or does it really not matter? Thanks, Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From xing@cernet.edu.cn Wed Apr 7 07:05:11 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 522873A67AF for ; Wed, 7 Apr 2010 07:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696] 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 1qhWIFP97TnC for ; Wed, 7 Apr 2010 07:05:10 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 624133A67A6 for ; Wed, 7 Apr 2010 07:05:02 -0700 (PDT) Received: from [192.168.1.100]([123.112.64.245]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54bbca06b; Wed, 07 Apr 2010 22:04:57 +0800 Message-ID: <4BBC90F8.2050502@cernet.edu.cn> Date: Wed, 07 Apr 2010 22:04:40 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Simon Perreault References: <20100407080001.688F73A68E4@core3.amsl.com> <4BBC4CC2.9060108@cernet.edu.cn> <4BBC750A.5020501@viagenie.ca> In-Reply-To: <4BBC750A.5020501@viagenie.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: 6rRs5zXB Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-17.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 14:05:11 -0000 Simon Perreault 写道: > On 2010-04-07 05:13, Xing Li wrote: >>> What exactly does "configuration function" mean? >>> >>> Does it mean that there MUST be a CLI configurable option in the >>> translator to adjust the value smaller than 1280 to 1280? >>> >>> Or does it just mean that the translator must have the >>> functionality/capablity to adjust the MTU smaller than 1280 to 1280 >>> always? >> Yes, the translator must have the functionality/capablity to adjust the >> MTU smaller than 1280 to 1280 always. > > As an implementor, let met say that I don't understand what this means. > > Does this mean the following? > > if (config->mtu_floor && ntohl(icmp6->icmp6_mtu) < 1280) > icmp6->icmp6_mtu = htonl(1280); > > In this case, is there a recommended value for the configuration > variable? Or does it really not matter? Actually we mean: The translator can be configured to enable or disable the function { if (ntohl(icmp6->icmp6_mtu) < 1280) icmp6->icmp6_mtu = htonl(1280); } The detailed discussion is in Section 4 of the xlate draft. Could you kindly give us some suggestions to make the presentation clearer? Regards, xing > > Thanks, > Simon From simon.perreault@viagenie.ca Wed Apr 7 07:16:54 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F5263A6828 for ; Wed, 7 Apr 2010 07:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 UzxNwFMuhj-R for ; Wed, 7 Apr 2010 07:16:51 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id F0EF13A67A6 for ; Wed, 7 Apr 2010 07:16:48 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1CF1020F04; Wed, 7 Apr 2010 10:16:45 -0400 (EDT) Message-ID: <4BBC93CC.1020706@viagenie.ca> Date: Wed, 07 Apr 2010 10:16:44 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3 MIME-Version: 1.0 To: Xing Li References: <20100407080001.688F73A68E4@core3.amsl.com> <4BBC4CC2.9060108@cernet.edu.cn> <4BBC750A.5020501@viagenie.ca> <4BBC90F8.2050502@cernet.edu.cn> In-Reply-To: <4BBC90F8.2050502@cernet.edu.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-17.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 14:16:54 -0000 On 2010-04-07 10:04, Xing Li wrote: > Could you kindly give us some suggestions to make the presentation clearer? First, I would drop the idea of a "configuration function". This is not part of the protocol, it is part of the implementation, and therefore is out of scope for this document. Second, I would pick one alternative and make it a SHOULD. Do you think we should floor the MTU to 1280 nor not? Pick one to give guidance to the implementors. Third, make the reference more specific. Section 4 is vast. Is there a sub-section that would be more appropriate? Thanks, Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From brian.e.carpenter@gmail.com Wed Apr 7 14:41:57 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A33833A6985 for ; Wed, 7 Apr 2010 14:41:57 -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 o+S4VBnmWY8p for ; Wed, 7 Apr 2010 14:41:56 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id E359C3A69B3 for ; Wed, 7 Apr 2010 14:41:56 -0700 (PDT) Received: by pwj2 with SMTP id 2so1443648pwj.31 for ; Wed, 07 Apr 2010 14:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=JlnkJGCQTnsYYu9UkWzWC3fx1Ej6KuyYwxB/fu97YzI=; b=ND52p5FI7gUnIOQtB2+VmgriaWpb1aPYNUedrcD9Vw43vWMvbDnEnNo4FbgRi8pNlY Vh4QhChFQWV3zL9EVrnwuWSYwlJa5HzaclUcDFLwoRteEqZ6ae/w1gfB9c08xfYGMsqK bGgtOtsX4w9RswOpGjI1n1RolOj+ot7mBf56E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=hXMXK41406Zic+W+fhgJxLH3EkTw/SIAf3mgOzhXvtxuAAaup+kHEFULHjqQGK4HKS iTxMrTYZVzeBMNGW0ZjsP9xx1SSMbaeywQ3BTVRhEFZov3oGKNG2wsFFPGj5n0DDTc/J 5c6m5nA26Ub/J3ar0TM9tOF3dirMRzEy+C17o= Received: by 10.141.23.13 with SMTP id a13mr3168564rvj.92.1270676510579; Wed, 07 Apr 2010 14:41:50 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 23sm3994263pzk.2.2010.04.07.14.41.48 (version=SSLv3 cipher=RC4-MD5); Wed, 07 Apr 2010 14:41:49 -0700 (PDT) Message-ID: <4BBCFC1B.5080706@gmail.com> Date: Thu, 08 Apr 2010 09:41:47 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Simon Perreault References: <20100407080001.688F73A68E4@core3.amsl.com> <4BBC4CC2.9060108@cernet.edu.cn> <4BBC750A.5020501@viagenie.ca> <4BBC90F8.2050502@cernet.edu.cn> <4BBC93CC.1020706@viagenie.ca> In-Reply-To: <4BBC93CC.1020706@viagenie.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org, Xing Li Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-17.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 21:41:57 -0000 Simon, On 2010-04-08 02:16, Simon Perreault wrote: > On 2010-04-07 10:04, Xing Li wrote: >> Could you kindly give us some suggestions to make the presentation >> clearer? > > First, I would drop the idea of a "configuration function". This is not > part of the protocol, it is part of the implementation, and therefore is > out of scope for this document. Actually it is not unusual for a protocol spec to include a statement like "An implementation of this protocol MUST provide a method to configure , and the default setting of SHOULD be ." I think it's a good idea to include such rules. > > Second, I would pick one alternative and make it a SHOULD. Do you think > we should floor the MTU to 1280 nor not? Pick one to give guidance to > the implementors. Agreed, there should be a clear default behaviour. Brian > > Third, make the reference more specific. Section 4 is vast. Is there a > sub-section that would be more appropriate? > > Thanks, > Simon From xing@cernet.edu.cn Thu Apr 8 02:21:33 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B38D13A6832 for ; Thu, 8 Apr 2010 02:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696] 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 Fyk6VGhGKLga for ; Thu, 8 Apr 2010 02:21:31 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 377133A6407 for ; Thu, 8 Apr 2010 02:21:28 -0700 (PDT) Received: from [59.66.24.35]([59.66.24.35]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54bbddeb8; Thu, 08 Apr 2010 17:21:23 +0800 Message-ID: <4BBD991A.2010907@cernet.edu.cn> Date: Thu, 08 Apr 2010 16:51:38 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Brian E Carpenter References: <20100407080001.688F73A68E4@core3.amsl.com> <4BBC4CC2.9060108@cernet.edu.cn> <4BBC750A.5020501@viagenie.ca> <4BBC90F8.2050502@cernet.edu.cn> <4BBC93CC.1020706@viagenie.ca> <4BBCFC1B.5080706@gmail.com> In-Reply-To: <4BBCFC1B.5080706@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: fMZvnzXB Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-17.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 09:21:33 -0000 Brian E Carpenter 写道: > Simon, > > On 2010-04-08 02:16, Simon Perreault wrote: > >> On 2010-04-07 10:04, Xing Li wrote: >> >>> Could you kindly give us some suggestions to make the presentation >>> clearer? >>> >> First, I would drop the idea of a "configuration function". This is not >> part of the protocol, it is part of the implementation, and therefore is >> out of scope for this document. >> > > Actually it is not unusual for a protocol spec to include a statement like > "An implementation of this protocol MUST provide a method to configure > , and the default setting of SHOULD be ." > > I think it's a good idea to include such rules. > > >> Second, I would pick one alternative and make it a SHOULD. Do you think >> we should floor the MTU to 1280 nor not? Pick one to give guidance to >> the implementors. >> > > Agreed, there should be a clear default behaviour. > > Brian > > Thanks. We will incorporate your comments in the next update. regards, xing, congxiao >> Third, make the reference more specific. Section 4 is vast. Is there a >> sub-section that would be more appropriate? >> >> Thanks, >> Simon >> > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > From root@core3.amsl.com Thu Apr 8 17:15:01 2010 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id ED4AA3A67C2; Thu, 8 Apr 2010 17:15: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: <20100409001501.ED4AA3A67C2@core3.amsl.com> Date: Thu, 8 Apr 2010 17:15:01 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-address-format-07.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 00:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : IPv6 Addressing of IPv4/IPv6 Translators Author(s) : C. Bao, et al. Filename : draft-ietf-behave-address-format-07.txt Pages : 18 Date : 2010-04-08 This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-address-format-07.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-behave-address-format-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-08170040.I-D@ietf.org> --NextPart-- From Washam.Fan@huaweisymantec.com Thu Apr 8 23:39:45 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BADA3A67EA for ; Thu, 8 Apr 2010 23:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.105 X-Spam-Level: ** X-Spam-Status: No, score=2.105 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Au5PvhMbO+aD for ; Thu, 8 Apr 2010 23:39:44 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 01E873A6767 for ; Thu, 8 Apr 2010 23:39:43 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0L0L00GV0JTTGB70@hstga02-in.huaweisymantec.com> for behave@ietf.org; Fri, 09 Apr 2010 14:39:29 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0L0L00C3AJTS0W20@hstml02-in.huaweisymantec.com> for behave@ietf.org; Fri, 09 Apr 2010 14:39:28 +0800 (CST) Received: from [10.27.154.72] by hstml02-in.huaweisymantec.com (mshttpd); Fri, 09 Apr 2010 14:39:28 +0800 From: WashamFan To: behave@ietf.org Message-id: Date: Fri, 09 Apr 2010 14:39:28 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: References: <4BB6AF89.4080704@cernet.edu.cn> Subject: [BEHAVE] Potential black hole w.r.t fragmentation and MTU issues in xlate X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 06:39:45 -0000 Hi, > " There are some differences between IPv6 and IPv4 in the area of > fragmentation and the minimum link MTU that affect the translation. > An IPv6 link has to have an MTU of 1280 bytes or greater. The > corresponding limit for IPv4 is 68 bytes. Thus, unless there were > special measures, it would not be possible to do end-to-end path MTU > discovery when the path includes a translator, since the IPv6 node > might receive ICMPv6 "Packet Too Big" messages originated by an IPv4 > router that report an MTU less than 1280. However, [RFC2460] section > 5 requires that IPv6 nodes handle such an ICMPv6 "Packet Too Big" > message by reducing the path MTU to 1280 and including an IPv6 > fragment header with each packet. In this case, the translator > SHOULD set DF to 0 and take the identification value from the IPv6 > fragment header when a fragmentation header with (MF=0; Offset=0) > is > present or set DF to 1 otherwise. " Reading from the above text and relevant text in the latest xlate doc, it seems to me the translator would set DF=1 if the IPv6 fragment with MF=1 and the fragment size=1280 received. In this case, it might cause black hole if some place in IPv4 network has <1260 MTU. Am I missing something? THanks, washam From ietfdbh@comcast.net Fri Apr 9 05:56:18 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 439893A6A4B for ; Fri, 9 Apr 2010 05:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.811, 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 tkif5726XxyF for ; Fri, 9 Apr 2010 05:56:17 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id D9DDA28C0D0 for ; Fri, 9 Apr 2010 05:56:12 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta09.westchester.pa.mail.comcast.net with comcast id 3NGD1e00D17dt5G59Qw9eX; Fri, 09 Apr 2010 12:56:10 +0000 Received: from Harrington73653 ([67.189.235.106]) by omta13.westchester.pa.mail.comcast.net with comcast id 3Qw91e00B2JQnJT3ZQw9pk; Fri, 09 Apr 2010 12:56:09 +0000 From: "David Harrington" To: "'Brian E Carpenter'" , "'Simon Perreault'" References: <20100407080001.688F73A68E4@core3.amsl.com> <4BBC4CC2.9060108@cernet.edu.cn> <4BBC750A.5020501@viagenie.ca><4BBC90F8.2050502@cernet.edu.cn> <4BBC93CC.1020706@viagenie.ca> <4BBCFC1B.5080706@gmail.com> Date: Fri, 9 Apr 2010 08:56:08 -0400 Message-ID: <0ad101cad7e4$06069350$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcrWmyajhiMceJmeSCShkFu5QYSohABSM0sA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4BBCFC1B.5080706@gmail.com> Cc: 'Xing Li' , behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-17.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 12:56:18 -0000 +1 dbh > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Brian E Carpenter > Sent: Wednesday, April 07, 2010 5:42 PM > To: Simon Perreault > Cc: behave@ietf.org; Xing Li > Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-17.txt > > Simon, > > On 2010-04-08 02:16, Simon Perreault wrote: > > On 2010-04-07 10:04, Xing Li wrote: > >> Could you kindly give us some suggestions to make the presentation > >> clearer? > > > > First, I would drop the idea of a "configuration function". > This is not > > part of the protocol, it is part of the implementation, and > therefore is > > out of scope for this document. > > Actually it is not unusual for a protocol spec to include a > statement like > "An implementation of this protocol MUST provide a method to configure > , and the default setting of SHOULD be ." > > I think it's a good idea to include such rules. > > > > > Second, I would pick one alternative and make it a SHOULD. > Do you think > > we should floor the MTU to 1280 nor not? Pick one to give > guidance to > > the implementors. > > Agreed, there should be a clear default behaviour. > > Brian > > > > > Third, make the reference more specific. Section 4 is vast. > Is there a > > sub-section that would be more appropriate? > > > > Thanks, > > Simon > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From xing@cernet.edu.cn Sat Apr 10 19:54:57 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 327AA3A68A7 for ; Sat, 10 Apr 2010 19:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696] 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 ZhQw00ao-tNk for ; Sat, 10 Apr 2010 19:54:56 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id A3A253A681C for ; Sat, 10 Apr 2010 19:54:55 -0700 (PDT) Received: from [192.168.1.100]([125.34.52.188]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm04bc16759; Sun, 11 Apr 2010 10:54:49 +0800 Message-ID: <4BC139EB.6080704@cernet.edu.cn> Date: Sun, 11 Apr 2010 10:54:35 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: David Harrington References: <20100407080001.688F73A68E4@core3.amsl.com> <4BBC4CC2.9060108@cernet.edu.cn> <4BBC750A.5020501@viagenie.ca><4BBC90F8.2050502@cernet.edu.cn> <4BBC93CC.1020706@viagenie.ca> <4BBCFC1B.5080706@gmail.com> <0ad101cad7e4$06069350$0600a8c0@china.huawei.com> In-Reply-To: <0ad101cad7e4$06069350$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: WvxTnAYB Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-17.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 02:54:57 -0000 David Harrington 写道: > +1 > > dbh > Thanks for the comments and suggestions. We have uploaded version 18 to improve the document. Regards, xing, congxiao > >> -----Original Message----- >> From: behave-bounces@ietf.org >> [mailto:behave-bounces@ietf.org] On Behalf Of Brian E Carpenter >> Sent: Wednesday, April 07, 2010 5:42 PM >> To: Simon Perreault >> Cc: behave@ietf.org; Xing Li >> Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-17.txt >> >> Simon, >> >> On 2010-04-08 02:16, Simon Perreault wrote: >> >>> On 2010-04-07 10:04, Xing Li wrote: >>> >>>> Could you kindly give us some suggestions to make the >>>> > presentation > >>>> clearer? >>>> >>> First, I would drop the idea of a "configuration function". >>> >> This is not >> >>> part of the protocol, it is part of the implementation, and >>> >> therefore is >> >>> out of scope for this document. >>> >> Actually it is not unusual for a protocol spec to include a >> statement like >> "An implementation of this protocol MUST provide a method to >> > configure > >> , and the default setting of SHOULD be ." >> >> I think it's a good idea to include such rules. >> >> >>> Second, I would pick one alternative and make it a SHOULD. >>> >> Do you think >> >>> we should floor the MTU to 1280 nor not? Pick one to give >>> >> guidance to >> >>> the implementors. >>> >> Agreed, there should be a clear default behaviour. >> >> Brian >> >> >>> Third, make the reference more specific. Section 4 is vast. >>> >> Is there a >> >>> sub-section that would be more appropriate? >>> >>> Thanks, >>> Simon >>> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >> > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > From root@core3.amsl.com Sat Apr 10 20:00:01 2010 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C396E3A67B1; Sat, 10 Apr 2010 20:00: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: <20100411030001.C396E3A67B1@core3.amsl.com> Date: Sat, 10 Apr 2010 20:00:01 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-18.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 03:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : IP/ICMP Translation Algorithm Author(s) : X. Li, et al. Filename : draft-ietf-behave-v6v4-xlate-18.txt Pages : 31 Date : 2010-04-10 This document forms a replacement of the Stateless IP/ICMP Translation Algorithm (SIIT) described in RFC 2765. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-18.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-behave-v6v4-xlate-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-10195309.I-D@ietf.org> --NextPart-- From ssenthil@cisco.com Wed Apr 14 15:51:18 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C46663A6ABE for ; Wed, 14 Apr 2010 15:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a52Q2ny4OfEn for ; Wed, 14 Apr 2010 15:51:18 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id EFED43A6931 for ; Wed, 14 Apr 2010 15:51:13 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMGACzkxUurR7H+/2dsb2JhbACPcYtqcaNQmg6FDQSDKQ X-IronPort-AV: E=Sophos;i="4.52,208,1270425600"; d="scan'208";a="115390004" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 14 Apr 2010 22:51:08 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3EMp6nF008951 for ; Wed, 14 Apr 2010 22:51:08 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Apr 2010 15:51:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Apr 2010 15:51:00 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB09E2D224@xmb-sjc-236.amer.cisco.com> In-Reply-To: <4BC139EB.6080704@cernet.edu.cn> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 no next header to IPv4 Thread-Index: AcrZIl3nS1MpJcsmSbOXEoSrJnpIbQDAeFLg References: <20100407080001.688F73A68E4@core3.amsl.com> <4BBC4CC2.9060108@cernet.edu.cn> <4BBC750A.5020501@viagenie.ca><4BBC90F8.2050502@cernet.edu.cn> <4BBC93CC.1020706@viagenie.ca><4BBCFC1B.5080706@gmail.com><0ad101cad7e4$06069350$0600a8c0@china.huawei.com> <4BC139EB.6080704@cernet.edu.cn> From: "Senthil Sivakumar (ssenthil)" To: X-OriginalArrivalTime: 14 Apr 2010 22:51:03.0377 (UTC) FILETIME=[F5C56C10:01CADC24] Subject: [BEHAVE] IPv6 no next header to IPv4 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 22:51:18 -0000 IPv6 packets can have a valid next header value of No next header (value 55). According to the xlate draft if we simply copy over the next header value to the protocol of IPv4 then that would be interpreted incorrectly by the IPv4 side.=20 Protocol: For ICMPv6 (58) changed to ICMPv4 (1), otherwise skip extension headers, copy the Next Header field (ESP, transport protocol or undefined next header value) in the last known next header.=20 I am suggesting that we should drop the packet with a no next header, as I don't think we can correctly translate it to a protocol value. Maybe we could use a reserved protocol value not sure what it buys us. Any suggestions/opinions? Senthil From ssenthil@cisco.com Wed Apr 14 16:16:05 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 936F53A68AC for ; Wed, 14 Apr 2010 16:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 747yEkdQGUdt for ; Wed, 14 Apr 2010 16:16:04 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id AF2063A672E for ; Wed, 14 Apr 2010 16:16:04 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMGAMvpxUurRN+J/2dsb2JhbACBP44yi2pxo1yaBoUNBIMp X-IronPort-AV: E=Sophos;i="4.52,208,1270425600"; d="scan'208,217";a="515100654" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 14 Apr 2010 23:15:58 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o3ENFwbZ018013 for ; Wed, 14 Apr 2010 23:15:58 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Apr 2010 16:15:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CADC28.70EB7AFE" Date: Wed, 14 Apr 2010 16:15:57 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB09E2D250@xmb-sjc-236.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UDP checksum of zero. Thread-Index: AcrcKHB1RFDiHaBxTNuqWuj7NTzpsw== From: "Senthil Sivakumar (ssenthil)" To: X-OriginalArrivalTime: 14 Apr 2010 23:15:58.0738 (UTC) FILETIME=[71136720:01CADC28] Subject: [BEHAVE] UDP checksum of zero. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 23:16:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CADC28.70EB7AFE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "When a stateless translator receives the first fragment of a fragmented UDP IPv4 packet and the checksum field is zero, the translator SHOULD drop the packet and generate a system management event specifying at least the IP addresses and port numbers in the packet. When it receives fragments other than the first, it SHOULD silently drop the packet, since there is no port information to log." =20 The second sentence does not make sense. When a non-first fragment is received there is no UDP header and hence there is no UDP checksum. So you cannot determine if the checksum is zero or not and hence the second sentence must be removed. We would need to keep state to determine if the subsequent fragments belong to the same flow that had the UDP checksum of zero or not. That would not belong in this draft. =20 Senthil ------_=_NextPart_001_01CADC28.70EB7AFE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
"When =
a stateless translator receives the first fragment of a
   fragmented UDP IPv4 packet and the checksum field is zero, the
   translator SHOULD drop the packet and generate a system management
   event specifying at least the IP addresses and port numbers in the
   packet.  When it receives fragments other than the first, it SHOULD
   silently drop the packet, since there is no port information to =
log."
 
The second =
sentence does not make sense. When a non-first fragment
is =
received there is no UDP header and hence there is no UDP =
checksum.
So you cannot determine if the checksum is =
zero or not and hence the second
sentence =
must be removed. We would need to keep state to determine if =
the
subsequent fragments belong to the same flow =
that had the UDP checksum of zero or not.
That =
would not belong in this draft.
 
Senthil
------_=_NextPart_001_01CADC28.70EB7AFE-- From dthaler@microsoft.com Wed Apr 14 17:07:45 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7F243A679F for ; Wed, 14 Apr 2010 17:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.017 X-Spam-Level: X-Spam-Status: No, score=-110.017 tagged_above=-999 required=5 tests=[AWL=0.582, 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 cTLpE2TyyCv9 for ; Wed, 14 Apr 2010 17:07:44 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id B26623A6452 for ; Wed, 14 Apr 2010 17:07:44 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 14 Apr 2010 17:07:38 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.0.639.21; Wed, 14 Apr 2010 17:07:38 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.63]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 14 Apr 2010 17:07:38 -0700 From: Dave Thaler To: "Senthil Sivakumar (ssenthil)" , "behave@ietf.org" Thread-Topic: IPv6 no next header to IPv4 Thread-Index: AQHK3CUriTlxwdqwxEeRbz+o+4+zypIipR+w Date: Thu, 15 Apr 2010 00:05:13 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF65139336ED@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <20100407080001.688F73A68E4@core3.amsl.com> <4BBC4CC2.9060108@cernet.edu.cn> <4BBC750A.5020501@viagenie.ca><4BBC90F8.2050502@cernet.edu.cn> <4BBC93CC.1020706@viagenie.ca><4BBCFC1B.5080706@gmail.com><0ad101cad7e4$06069350$0600a8c0@china.huawei.com> <4BC139EB.6080704@cernet.edu.cn> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D224@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB09E2D224@xmb-sjc-236.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] IPv6 no next header to IPv4 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 00:07:45 -0000 No Next Header is value 59 (not 55). Personally I don't see why 59 should be handled any differently from any other arbitrary value like 200. Putting 59 in an IPv4 header doesn't seem=20 harmful to me, if that's what you'd do for protocol 200 with no data beyond the IP header. -Dave > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf = Of > Senthil Sivakumar (ssenthil) > Sent: Wednesday, April 14, 2010 3:51 PM > To: behave@ietf.org > Subject: [BEHAVE] IPv6 no next header to IPv4 >=20 > IPv6 packets can have a valid next header value of No next header (value > 55). According to the xlate draft if we simply copy over the next header > value to the protocol of IPv4 then that would be interpreted incorrectly > by the IPv4 side. >=20 > Protocol: For ICMPv6 (58) changed to ICMPv4 (1), otherwise skip > extension headers, copy the Next Header field (ESP, transport protocol > or undefined next header value) in the last known next header. >=20 > I am suggesting that we should drop the packet with a no next header, as > I don't think we can correctly translate it to a protocol value. Maybe > we could use a reserved protocol value not sure what it buys us. >=20 > Any suggestions/opinions? >=20 > Senthil > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From ssenthil@cisco.com Wed Apr 14 17:42:25 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D3CD3A699C for ; Wed, 14 Apr 2010 17:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 EtFaQkDXQpPE for ; Wed, 14 Apr 2010 17:42:24 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 964633A6968 for ; Wed, 14 Apr 2010 17:42:24 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALf9xUurR7Ht/2dsb2JhbACbW3GjapoOhQ0Egyk X-IronPort-AV: E=Sophos;i="4.52,208,1270425600"; d="scan'208";a="515138869" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 15 Apr 2010 00:42:18 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3F0gIUj003479; Thu, 15 Apr 2010 00:42:18 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Apr 2010 17:42:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Apr 2010 17:42:17 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB09E2D2B2@xmb-sjc-236.amer.cisco.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF65139336ED@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 no next header to IPv4 Thread-Index: AQHK3CUriTlxwdqwxEeRbz+o+4+zypIipR+wgAAIhgA= References: <20100407080001.688F73A68E4@core3.amsl.com><4BBC4CC2.9060108@cernet.edu.cn><4BBC750A.5020501@viagenie.ca><4BBC90F8.2050502@cernet.edu.cn><4BBC93CC.1020706@viagenie.ca><4BBCFC1B.5080706@gmail.com><0ad101cad7e4$06069350$0600a8c0@china.huawei.com><4BC139EB.6080704@cernet.edu.cn> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D224@xmb-sjc-236.amer.cisco.com> <9B57C850BB53634CACEC56EF4853FF65139336ED@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> From: "Senthil Sivakumar (ssenthil)" To: "Dave Thaler" , X-OriginalArrivalTime: 15 Apr 2010 00:42:18.0551 (UTC) FILETIME=[807C2470:01CADC34] Subject: Re: [BEHAVE] IPv6 no next header to IPv4 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 00:42:25 -0000 But the draft does suggest to ignore/drop/translate the other IPv6 specific protocol values like IPv6-Route (43), IPv6-Frag (44) & dst opts (60).=20 -----Original Message----- From: Dave Thaler [mailto:dthaler@microsoft.com]=20 Sent: Wednesday, April 14, 2010 8:05 PM To: Senthil Sivakumar (ssenthil); behave@ietf.org Subject: RE: IPv6 no next header to IPv4 No Next Header is value 59 (not 55). Personally I don't see why 59 should be handled any differently from any other arbitrary value like 200. Putting 59 in an IPv4 header doesn't seem harmful to me, if that's what you'd do for protocol 200 with no data beyond the IP header. -Dave > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On=20 > Behalf Of Senthil Sivakumar (ssenthil) > Sent: Wednesday, April 14, 2010 3:51 PM > To: behave@ietf.org > Subject: [BEHAVE] IPv6 no next header to IPv4 >=20 > IPv6 packets can have a valid next header value of No next header=20 > (value 55). According to the xlate draft if we simply copy over the=20 > next header value to the protocol of IPv4 then that would be=20 > interpreted incorrectly by the IPv4 side. >=20 > Protocol: For ICMPv6 (58) changed to ICMPv4 (1), otherwise skip=20 > extension headers, copy the Next Header field (ESP, transport protocol > or undefined next header value) in the last known next header. >=20 > I am suggesting that we should drop the packet with a no next header,=20 > as I don't think we can correctly translate it to a protocol value.=20 > Maybe we could use a reserved protocol value not sure what it buys us. >=20 > Any suggestions/opinions? >=20 > Senthil > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From xing@cernet.edu.cn Thu Apr 15 04:07:33 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89BE728C184 for ; Thu, 15 Apr 2010 04:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] 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 vxyYPz8HrqNa for ; Thu, 15 Apr 2010 04:07:32 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 2E4003A696B for ; Thu, 15 Apr 2010 04:07:10 -0700 (PDT) Received: from [202.112.35.220]([202.112.35.220]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm74bc76ab2; Thu, 15 Apr 2010 19:07:02 +0800 Message-ID: <4BC6F34C.7010206@cernet.edu.cn> Date: Thu, 15 Apr 2010 19:06:52 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" References: <20100407080001.688F73A68E4@core3.amsl.com><4BBC4CC2.9060108@cernet.edu.cn><4BBC750A.5020501@viagenie.ca><4BBC90F8.2050502@cernet.edu.cn><4BBC93CC.1020706@viagenie.ca><4BBCFC1B.5080706@gmail.com><0ad101cad7e4$06069350$0600a8c0@china.huawei.com><4BC139EB.6080704@cernet.edu.cn> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D224@xmb-sjc-236.amer.cisco.com> <9B57C850BB53634CACEC56EF4853FF65139336ED@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D2B2@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB09E2D2B2@xmb-sjc-236.amer.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: qM4uWCYB Cc: behave@ietf.org, Dave Thaler Subject: Re: [BEHAVE] IPv6 no next header to IPv4 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 11:07:33 -0000 Senthil Sivakumar (ssenthil) 写道: > But the draft does suggest to ignore/drop/translate the other IPv6 > specific protocol values like > IPv6-Route (43), IPv6-Frag (44) & dst opts (60). > The current wording in xlate-18 is 4.1. Translating IPv6 Headers into IPv4 Headers ...... Protocol: For ICMPv6 (58) changed to ICMPv4 (1), otherwise skip extension headers, copy the Next Header field (ESP, transport protocol or undefined next header value) in the last known next header. We think "copy the Next Header field (ESP, transport protocol or undefined next header value) in the last known next header" means "59 will be put in an IPv4 header, which seems not harmful". Regards, xing, congxiao > -----Original Message----- > From: Dave Thaler [mailto:dthaler@microsoft.com] > Sent: Wednesday, April 14, 2010 8:05 PM > To: Senthil Sivakumar (ssenthil); behave@ietf.org > Subject: RE: IPv6 no next header to IPv4 > > No Next Header is value 59 (not 55). > > Personally I don't see why 59 should be handled any differently from any > other arbitrary value like 200. Putting 59 in an IPv4 header doesn't > seem harmful to me, if that's what you'd do for protocol 200 with no > data beyond the IP header. > > -Dave > > >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf Of Senthil Sivakumar (ssenthil) >> Sent: Wednesday, April 14, 2010 3:51 PM >> To: behave@ietf.org >> Subject: [BEHAVE] IPv6 no next header to IPv4 >> >> IPv6 packets can have a valid next header value of No next header >> (value 55). According to the xlate draft if we simply copy over the >> next header value to the protocol of IPv4 then that would be >> interpreted incorrectly by the IPv4 side. >> >> Protocol: For ICMPv6 (58) changed to ICMPv4 (1), otherwise skip >> extension headers, copy the Next Header field (ESP, transport protocol >> > > >> or undefined next header value) in the last known next header. >> >> I am suggesting that we should drop the packet with a no next header, >> as I don't think we can correctly translate it to a protocol value. >> Maybe we could use a reserved protocol value not sure what it buys us. >> >> Any suggestions/opinions? >> >> Senthil >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > From xing@cernet.edu.cn Thu Apr 15 04:08:01 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80CD43A696B for ; Thu, 15 Apr 2010 04:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696] 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 z3KLafNTv15R for ; Thu, 15 Apr 2010 04:08:00 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 86E263A67A6 for ; Thu, 15 Apr 2010 04:07:27 -0700 (PDT) Received: from [202.112.35.220]([202.112.35.220]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm284bc76ac3; Thu, 15 Apr 2010 19:07:19 +0800 Message-ID: <4BC6F36C.2080804@cernet.edu.cn> Date: Thu, 15 Apr 2010 19:07:24 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" References: <85B2F271FDF6B949B3672BA5A7BB62FB09E2D250@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB09E2D250@xmb-sjc-236.amer.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: qPluWCYB Cc: behave@ietf.org Subject: Re: [BEHAVE] UDP checksum of zero. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 11:08:01 -0000 Thanks. Senthil Sivakumar (ssenthil) 写道: > "When a stateless translator receives the first fragment of a > fragmented UDP IPv4 packet and the checksum field is zero, the > translator SHOULD drop the packet and generate a system management > event specifying at least the IP addresses and port numbers in the > packet. When it receives fragments other than the first, it SHOULD > silently drop the packet, since there is no port information to log." > > The second sentence does not make sense. When a non-first fragment > is received there is no UDP header and hence there is no UDP checksum. > So you cannot determine if the checksum is zero or not and hence the second > sentence must be removed. We would need to keep state to determine if the > subsequent fragments belong to the same flow that had the UDP checksum of zero or not. > That would not belong in this draft. The second sentence simply means the fragments other than the first should be silently dropped. We will remove the second sentence in the next upload during the IESG process. Regards, xing, congxiao > > Senthil > ------------------------------------------------------------------------ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From ssenthil@cisco.com Thu Apr 15 04:27:07 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C80B13A68EA for ; Thu, 15 Apr 2010 04:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 DW-BYUREmTzC for ; Thu, 15 Apr 2010 04:27:06 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 721FA3A6901 for ; Thu, 15 Apr 2010 04:25:05 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALaUxkurRN+J/2dsb2JhbACDE5hbcaQ0iFwBkUGBKYEwgURxBIMpizY X-IronPort-AV: E=Sophos;i="4.52,212,1270425600"; d="scan'208";a="183437459" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 15 Apr 2010 11:24:59 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o3FBOx2a025152; Thu, 15 Apr 2010 11:24:59 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Apr 2010 04:24:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Date: Thu, 15 Apr 2010 04:24:56 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB09E2D377@xmb-sjc-236.amer.cisco.com> In-Reply-To: <4BC6F36C.2080804@cernet.edu.cn> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] UDP checksum of zero. Thread-Index: Acrci9Vf5wvFX0kwQSSxSizkuLpPHQAAf75A References: <85B2F271FDF6B949B3672BA5A7BB62FB09E2D250@xmb-sjc-236.amer.cisco.com> <4BC6F36C.2080804@cernet.edu.cn> From: "Senthil Sivakumar (ssenthil)" To: "Xing Li" X-OriginalArrivalTime: 15 Apr 2010 11:24:59.0080 (UTC) FILETIME=[4859EC80:01CADC8E] Cc: behave@ietf.org Subject: Re: [BEHAVE] UDP checksum of zero. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 11:27:07 -0000 -----Original Message----- From: Xing Li [mailto:xing@cernet.edu.cn] Sent: Thursday, April 15, 2010 7:07 AM To: Senthil Sivakumar (ssenthil) Cc: behave@ietf.org Subject: Re: [BEHAVE] UDP checksum of zero. Thanks. Senthil Sivakumar (ssenthil) $B "When a stateless translator receives the first fragment of a > fragmented UDP IPv4 packet and the checksum field is zero, the > translator SHOULD drop the packet and generate a system management > event specifying at least the IP addresses and port numbers in the > packet. When it receives fragments other than the first, it SHOULD > silently drop the packet, since there is no port information to log." > > The second sentence does not make sense. When a non-first fragment is > received there is no UDP header and hence there is no UDP checksum. > So you cannot determine if the checksum is zero or not and hence the > second sentence must be removed. We would need to keep state to > determine if the subsequent fragments belong to the same flow that had the UDP checksum of zero or not. > That would not belong in this draft. The second sentence simply means the fragments other than the first should be silently dropped. We will remove the second sentence in the next upload during the IESG process. [Senthil] We *cannot* silenty drop any non-first fragments, right?. The stateless translator would have to pass them on. The only thing we can do is identify and drop the first fragment with UDP csum of zero. Thanks Senthil Regards, xing, congxiao > > Senthil > ---------------------------------------------------------------------- > -- > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From xing@cernet.edu.cn Thu Apr 15 07:05:27 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35A993A6ADC for ; Thu, 15 Apr 2010 07:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696] 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 urmyfHLKIjva for ; Thu, 15 Apr 2010 07:05:22 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id D8BA03A6A16 for ; Thu, 15 Apr 2010 07:05:06 -0700 (PDT) Received: from [192.168.1.100]([123.112.69.141]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54bc79464; Thu, 15 Apr 2010 22:04:58 +0800 Message-ID: <4BC71D08.6040109@cernet.edu.cn> Date: Thu, 15 Apr 2010 22:04:56 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" References: <85B2F271FDF6B949B3672BA5A7BB62FB09E2D250@xmb-sjc-236.amer.cisco.com> <4BC6F36C.2080804@cernet.edu.cn> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D377@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB09E2D377@xmb-sjc-236.amer.cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: qmggZCYB Cc: behave@ietf.org Subject: Re: [BEHAVE] UDP checksum of zero. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 14:05:27 -0000 Hi, Senthil, Senthil Sivakumar (ssenthil) $B > > -----Original Message----- > From: Xing Li [mailto:xing@cernet.edu.cn] > Sent: Thursday, April 15, 2010 7:07 AM > To: Senthil Sivakumar (ssenthil) > Cc: behave@ietf.org > Subject: Re: [BEHAVE] UDP checksum of zero. > > Thanks. > > Senthil Sivakumar (ssenthil) $B >> "When a stateless translator receives the first fragment of a >> fragmented UDP IPv4 packet and the checksum field is zero, the >> translator SHOULD drop the packet and generate a system management >> event specifying at least the IP addresses and port numbers in the >> packet. When it receives fragments other than the first, it SHOULD >> silently drop the packet, since there is no port information to log." >> >> The second sentence does not make sense. When a non-first fragment is >> received there is no UDP header and hence there is no UDP checksum. >> So you cannot determine if the checksum is zero or not and hence the >> second sentence must be removed. We would need to keep state to >> determine if the subsequent fragments belong to the same flow that had the UDP checksum of zero or not. >> That would not belong in this draft. >> > > The second sentence simply means the fragments other than the first should be silently dropped. We will remove the second sentence in the next upload during the IESG process. > > [Senthil] We *cannot* silenty drop any non-first fragments, right?. The stateless translator would have to pass them on. The only thing we can do is identify and drop the first fragment with UDP csum of zero. > You are correct. If the translator can identify the problem, it will drop the packet which contains the problem, if the translator cannot identify the problem, it will pass the packet and let the end system handle it. Regards, xing, congxiao > Thanks > Senthil > > Regards, > > xing, congxiao > > >> >> Senthil >> ---------------------------------------------------------------------- >> -- >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >> > > > From dthaler@microsoft.com Thu Apr 15 13:15:07 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 126E13A6B09 for ; Thu, 15 Apr 2010 13:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.075 X-Spam-Level: X-Spam-Status: No, score=-110.075 tagged_above=-999 required=5 tests=[AWL=0.524, 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 GetJaqfsK1BJ for ; Thu, 15 Apr 2010 13:15:06 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id E811D28C271 for ; Thu, 15 Apr 2010 13:14:23 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 15 Apr 2010 13:14:14 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.0.639.21; Thu, 15 Apr 2010 13:14:12 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.63]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Thu, 15 Apr 2010 13:14:12 -0700 From: Dave Thaler To: "Senthil Sivakumar (ssenthil)" Thread-Topic: IPv6 no next header to IPv4 Thread-Index: AQHK3CUriTlxwdqwxEeRbz+o+4+zypIipR+wgAAIhgCAAUn6oA== Date: Thu, 15 Apr 2010 20:13:57 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF651393462E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <20100407080001.688F73A68E4@core3.amsl.com><4BBC4CC2.9060108@cernet.edu.cn><4BBC750A.5020501@viagenie.ca><4BBC90F8.2050502@cernet.edu.cn><4BBC93CC.1020706@viagenie.ca><4BBCFC1B.5080706@gmail.com><0ad101cad7e4$06069350$0600a8c0@china.huawei.com><4BC139EB.6080704@cernet.edu.cn> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D224@xmb-sjc-236.amer.cisco.com> <9B57C850BB53634CACEC56EF4853FF65139336ED@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D2B2@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB09E2D2B2@xmb-sjc-236.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] IPv6 no next header to IPv4 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 20:15:07 -0000 But each of those actually require IPv6-specific processing. No Next Header, on the other hand is quite different in that it has no IPv6-specific processing rules. As such, it is not in the same category as the other 3. There's really nothing you can do in IPv6 with protocol 59 that you can't do in IPv4 with protocol 59. > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf = Of > Senthil Sivakumar (ssenthil) > Sent: Wednesday, April 14, 2010 5:42 PM > To: Dave Thaler; behave@ietf.org > Subject: Re: [BEHAVE] IPv6 no next header to IPv4 >=20 > But the draft does suggest to ignore/drop/translate the other IPv6 > specific protocol values like > IPv6-Route (43), IPv6-Frag (44) & dst opts (60). >=20 >=20 > -----Original Message----- > From: Dave Thaler [mailto:dthaler@microsoft.com] > Sent: Wednesday, April 14, 2010 8:05 PM > To: Senthil Sivakumar (ssenthil); behave@ietf.org > Subject: RE: IPv6 no next header to IPv4 >=20 > No Next Header is value 59 (not 55). >=20 > Personally I don't see why 59 should be handled any differently from any > other arbitrary value like 200. Putting 59 in an IPv4 header doesn't > seem harmful to me, if that's what you'd do for protocol 200 with no > data beyond the IP header. >=20 > -Dave >=20 > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of Senthil Sivakumar (ssenthil) > > Sent: Wednesday, April 14, 2010 3:51 PM > > To: behave@ietf.org > > Subject: [BEHAVE] IPv6 no next header to IPv4 > > > > IPv6 packets can have a valid next header value of No next header > > (value 55). According to the xlate draft if we simply copy over the > > next header value to the protocol of IPv4 then that would be > > interpreted incorrectly by the IPv4 side. > > > > Protocol: For ICMPv6 (58) changed to ICMPv4 (1), otherwise skip > > extension headers, copy the Next Header field (ESP, transport protocol >=20 > > or undefined next header value) in the last known next header. > > > > I am suggesting that we should drop the packet with a no next header, > > as I don't think we can correctly translate it to a protocol value. > > Maybe we could use a reserved protocol value not sure what it buys us. > > > > Any suggestions/opinions? > > > > Senthil > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From brian.e.carpenter@gmail.com Thu Apr 15 14:57:14 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B78423A6A9F for ; Thu, 15 Apr 2010 14:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.270, 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 zVUH73GZmCzK for ; Thu, 15 Apr 2010 14:57:13 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id A104F3A6A3F for ; Thu, 15 Apr 2010 14:57:12 -0700 (PDT) Received: by pwj2 with SMTP id 2so1562551pwj.31 for ; Thu, 15 Apr 2010 14:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ujicELaAjNZIkz3qLlIzJXBt+cnChUVvivWWbAY7/h8=; b=igRbrrbnDZEjy0I/iZ2V6v9TMsGKTKvr+2E3JR4M8KB0+/apA/rubO+jCYUS9F17V3 dXFJROead7kfBYw388QXZwi7o2sa2pRgt5C8216puVMrBGZcmQnXHKnl1FT+qYz+LKzH 6+EAEmBnXiBUuZ4HFGKXS7ECjd7IzyXJzfwP0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=mdBh6i7sdFPL0c28UJqE8gRO8jWvdqwn9sxC+mMihalhqO8pP/r4jG80jxwmgDFGTA eMwudVx2sMP093nArEpFy2D9Lemjd/1qNbgT/m1UF5ZN077/+ZdvN5JQdnI9Bm1Cdcyi I0NrqMhBqfinn3GcxcAELp95uZfbStq6AoUBY= Received: by 10.115.114.34 with SMTP id r34mr933252wam.64.1271368623128; Thu, 15 Apr 2010 14:57:03 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 20sm1635826pzk.15.2010.04.15.14.57.00 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Apr 2010 14:57:01 -0700 (PDT) Message-ID: <4BC78BAA.1080009@gmail.com> Date: Fri, 16 Apr 2010 09:56:58 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dave Thaler References: <20100407080001.688F73A68E4@core3.amsl.com><4BBC4CC2.9060108@cernet.edu.cn><4BBC750A.5020501@viagenie.ca><4BBC90F8.2050502@cernet.edu.cn><4BBC93CC.1020706@viagenie.ca><4BBCFC1B.5080706@gmail.com><0ad101cad7e4$06069350$0600a8c0@china.huawei.com><4BC139EB.6080704@cernet.edu.cn> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D224@xmb-sjc-236.amer.cisco.com> <9B57C850BB53634CACEC56EF4853FF65139336ED@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D2B2@xmb-sjc-236.amer.cisco.com> <9B57C850BB53634CACEC56EF4853FF651393462E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF651393462E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] IPv6 no next header to IPv4 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 21:57:14 -0000 However, what can be the value of translating a "no next header" IPv6 packet into an IPv4 packet? The only meaningful content can be in some extension header or other, which can't be translated anyway. Would there be any damage if we just drop such packets? Brian On 2010-04-16 08:13, Dave Thaler wrote: > But each of those actually require IPv6-specific processing. > No Next Header, on the other hand is quite different in that it > has no IPv6-specific processing rules. > > As such, it is not in the same category as the other 3. > There's really nothing you can do in IPv6 with protocol 59 that > you can't do in IPv4 with protocol 59. > >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of >> Senthil Sivakumar (ssenthil) >> Sent: Wednesday, April 14, 2010 5:42 PM >> To: Dave Thaler; behave@ietf.org >> Subject: Re: [BEHAVE] IPv6 no next header to IPv4 >> >> But the draft does suggest to ignore/drop/translate the other IPv6 >> specific protocol values like >> IPv6-Route (43), IPv6-Frag (44) & dst opts (60). >> >> >> -----Original Message----- >> From: Dave Thaler [mailto:dthaler@microsoft.com] >> Sent: Wednesday, April 14, 2010 8:05 PM >> To: Senthil Sivakumar (ssenthil); behave@ietf.org >> Subject: RE: IPv6 no next header to IPv4 >> >> No Next Header is value 59 (not 55). >> >> Personally I don't see why 59 should be handled any differently from any >> other arbitrary value like 200. Putting 59 in an IPv4 header doesn't >> seem harmful to me, if that's what you'd do for protocol 200 with no >> data beyond the IP header. >> >> -Dave >> >>> -----Original Message----- >>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >>> Behalf Of Senthil Sivakumar (ssenthil) >>> Sent: Wednesday, April 14, 2010 3:51 PM >>> To: behave@ietf.org >>> Subject: [BEHAVE] IPv6 no next header to IPv4 >>> >>> IPv6 packets can have a valid next header value of No next header >>> (value 55). According to the xlate draft if we simply copy over the >>> next header value to the protocol of IPv4 then that would be >>> interpreted incorrectly by the IPv4 side. >>> >>> Protocol: For ICMPv6 (58) changed to ICMPv4 (1), otherwise skip >>> extension headers, copy the Next Header field (ESP, transport protocol >>> or undefined next header value) in the last known next header. >>> >>> I am suggesting that we should drop the packet with a no next header, >>> as I don't think we can correctly translate it to a protocol value. >>> Maybe we could use a reserved protocol value not sure what it buys us. >>> >>> Any suggestions/opinions? >>> >>> Senthil >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From simon.perreault@viagenie.ca Thu Apr 15 15:51:57 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51FE03A6830 for ; Thu, 15 Apr 2010 15:51:57 -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 3fgcDca3cCLr for ; Thu, 15 Apr 2010 15:51:56 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by core3.amsl.com (Postfix) with ESMTP id 9E31E3A6861 for ; Thu, 15 Apr 2010 15:51:55 -0700 (PDT) Received: from balaise.nomis80.org (modemcable245.152-21-96.mc.videotron.ca [96.21.152.245]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 873AD20E37 for ; Thu, 15 Apr 2010 18:51:48 -0400 (EDT) Message-ID: <4BC79883.9020702@viagenie.ca> Date: Thu, 15 Apr 2010 18:51:47 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: behave@ietf.org References: <20100407080001.688F73A68E4@core3.amsl.com><4BBC4CC2.9060108@cernet.edu.cn><4BBC750A.5020501@viagenie.ca><4BBC90F8.2050502@cernet.edu.cn><4BBC93CC.1020706@viagenie.ca><4BBCFC1B.5080706@gmail.com><0ad101cad7e4$06069350$0600a8c0@china.huawei.com><4BC139EB.6080704@cernet.edu.cn> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D224@xmb-sjc-236.amer.cisco.com> <9B57C850BB53634CACEC56EF4853FF65139336ED@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D2B2@xmb-sjc-236.amer.cisco.com> <9B57C850BB53634CACEC56EF4853FF651393462E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4BC78BAA.1080009@gmail.com> In-Reply-To: <4BC78BAA.1080009@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] IPv6 no next header to IPv4 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 22:51:57 -0000 On 04/15/2010 05:56 PM, Brian E Carpenter wrote: > However, what can be the value of translating a "no next > header" IPv6 packet into an IPv4 packet? The only meaningful > content can be in some extension header or other, which > can't be translated anyway. Would there be any damage if we > just drop such packets? Well, if two options are equally good (or equally useless in this case), why not choose the one which requires less code? That is, make no special case for 59 and translate/forward it as usual. Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From dwing@cisco.com Thu Apr 15 16:14:33 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7646F3A68EE for ; Thu, 15 Apr 2010 16:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.447 X-Spam-Level: X-Spam-Status: No, score=-10.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 SSRFwGp1M+nG for ; Thu, 15 Apr 2010 16:14:32 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 162A63A6835 for ; Thu, 15 Apr 2010 16:14:32 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkHAB46x0urR7Hu/2dsb2JhbACHWYEUkwFxpGSaLIUOBIMp X-IronPort-AV: E=Sophos;i="4.52,215,1270425600"; d="scan'208";a="219164763" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 15 Apr 2010 23:14:25 +0000 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3FNEPG7014121; Thu, 15 Apr 2010 23:14:25 GMT From: "Dan Wing" To: References: <20100407080001.688F73A68E4@core3.amsl.com><4BBC4CC2.9060108@cernet.edu.cn><4BBC750A.5020501@viagenie.ca><4BBC90F8.2050502@cernet.edu.cn><4BBC93CC.1020706@viagenie.ca><4BBCFC1B.5080706@gmail.com><0ad101cad7e4$06069350$0600a8c0@china.huawei.com><4BC139EB.6080704@cernet.edu.cn> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D224@xmb-sjc-236.amer.cisco.com> <9B57C850BB53634CACEC56EF4853FF65139336ED@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D2B2@xmb-sjc-236.amer.cisco.com> <9B57C850BB53634CACEC56EF4853FF651393462E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><4BC78BAA.1080009@gmail.com> <4BC79883.9020702@viagenie.ca> Date: Thu, 15 Apr 2010 16:14:27 -0700 Message-ID: <01f901cadcf1$658403a0$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acrc7kC9Mq/4RR2KTk+FRzOIT9+4AgAAK7oQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4BC79883.9020702@viagenie.ca> Cc: draft-ietf-behave-v6v4-xlate@tools.ietf.org, behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] IPv6 no next header to IPv4 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 23:14:33 -0000 > On 04/15/2010 05:56 PM, Brian E Carpenter wrote: > > However, what can be the value of translating a "no next > > header" IPv6 packet into an IPv4 packet? The only meaningful > > content can be in some extension header or other, which > > can't be translated anyway. Would there be any damage if we > > just drop such packets? > > Well, if two options are equally good (or equally useless in > this case), > why not choose the one which requires less code? That is, make no > special case for 59 and translate/forward it as usual. Doing that should help debug the problem; silently dropping such a packet might make debugging more difficult. So I prefer translating an IPv6 packet containing only IPv6-NoNxt. I suggest rewording xlate-18 from: OLD: The translator does not translate IPv6 routing headers, hop-by-hop extension headers, destination options headers, source routing headers, or any layer 4 protocol (e.g., TCP header, IPsec authentication header (AH) or encapsulating security payload (ESP) header). However, the translator needs to traverse the IPv6 'next header' chain and copy the next header value (which contains the transport protocol number) in the last known 'next header' to the protocol field in the IPv4 header. This means that the translator MUST forward all protocols to avoid black holing. Some protocols are known to fail when translated (e.g., IPsec AH) and will fail at the receiver. NEW: Certain IPv6 headers cannot be translated because they have no meaning in IPv4. These headers are skipped over during processing and include HOPOPT (0), IPv6-Route (43), IPv6-Opts (60), and source-routing (??). For the first 'next header' that does not match one of the values above, its next header value (which contains the transport protocol number) is copied to the protocol field in the IPv4 header. This means that all transport protocols are translated. Some translated protocols will fail at the receiver for various reasons: some are known to fail when translated (e.g., IPsec AH (51)), others are malformed IPv6 packets with a useless IPv4 protocol number (e.g., IPv6-NoNxt (59)), and others will fail checksum validation if the address translation is not checksum neutral [I-D.ietf-behave-address-format] and the translator does not update the transport protocol's checksum (because the translator doesn't support recalculating the checksum for that transport protocol, e.g., SCTP (132)). Comments on this rewording? Questions for the WG: 1. I don't know the value of 'source routing headers' (and left it as ?? in the proposed NEW text). I don't see what value from http://www.iana.org/assignments/protocol-numbers should be used. 2. Which transport protcols MUST have their checksums recalculated by a translator compliant with draft-ietf-behave-v6v4-xlate, if the address translation is not checksum neutral? Section 3.5 says: "If the address translation algorithm is not checksum neutral, the recalculation and updating of the transport-layer headers which contain pseudo headers (e.g. of TCP, UDP and DCCP) MUST be performed." The use of "e.g." means the list is non-normative. -d From ssenthil@cisco.com Thu Apr 15 17:42:20 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31A1E3A6AB3 for ; Thu, 15 Apr 2010 17:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 i1zNxrcC6qcq for ; Thu, 15 Apr 2010 17:42:19 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id EC40C3A6AAB for ; Thu, 15 Apr 2010 17:42:18 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPpOx0urR7Hu/2dsb2JhbACba3GkI5oihQ4Egys X-IronPort-AV: E=Sophos;i="4.52,215,1270425600"; d="scan'208";a="183862325" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 16 Apr 2010 00:37:20 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3G0bKjd001115; Fri, 16 Apr 2010 00:37:20 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Apr 2010 17:37:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Apr 2010 17:37:15 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB09E2D7D2@xmb-sjc-236.amer.cisco.com> In-Reply-To: <01f901cadcf1$658403a0$c2f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] IPv6 no next header to IPv4 Thread-Index: Acrc7kC9Mq/4RR2KTk+FRzOIT9+4AgAAK7oQAAL2+kA= References: <20100407080001.688F73A68E4@core3.amsl.com><4BBC4CC2.9060108@cernet.edu.cn><4BBC750A.5020501@viagenie.ca><4BBC90F8.2050502@cernet.edu.cn><4BBC93CC.1020706@viagenie.ca><4BBCFC1B.5080706@gmail.com><0ad101cad7e4$06069350$0600a8c0@china.huawei.com><4BC139EB.6080704@cernet.edu.cn> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D224@xmb-sjc-236.amer.cisco.com> <9B57C850BB53634CACEC56EF4853FF65139336ED@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D2B2@xmb-sjc-236.amer.cisco.com> <9B57C850BB53634CACEC56EF4853FF651393462E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><4BC78BAA.1080009@gmail.com><4BC79883.9020702@viagenie.ca> <01f901cadcf1$658403a0$c2f0200a@cisco.com> From: "Senthil Sivakumar (ssenthil)" To: "Dan Wing (dwing)" , X-OriginalArrivalTime: 16 Apr 2010 00:37:20.0758 (UTC) FILETIME=[F9664960:01CADCFC] Cc: draft-ietf-behave-v6v4-xlate@tools.ietf.org, behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] IPv6 no next header to IPv4 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 00:42:20 -0000 =20 -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Dan Wing (dwing) Sent: Thursday, April 15, 2010 7:14 PM To: behave@ietf.org Cc: draft-ietf-behave-v6v4-xlate@tools.ietf.org; behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] IPv6 no next header to IPv4 > On 04/15/2010 05:56 PM, Brian E Carpenter wrote: > > However, what can be the value of translating a "no next header"=20 > > IPv6 packet into an IPv4 packet? The only meaningful content can be=20 > > in some extension header or other, which can't be translated anyway. > > Would there be any damage if we just drop such packets? >=20 > Well, if two options are equally good (or equally useless in this=20 > case), why not choose the one which requires less code? That is, make=20 > no special case for 59 and translate/forward it as usual. Doing that should help debug the problem; silently dropping such a packet might make debugging more difficult. So I prefer translating an IPv6 packet containing only IPv6-NoNxt. I suggest rewording xlate-18 from: OLD: The translator does not translate IPv6 routing headers, hop-by-hop extension headers, destination options headers, source routing headers, or any layer 4 protocol (e.g., TCP header, IPsec authentication header (AH) or encapsulating security payload (ESP) header). However, the translator needs to traverse the IPv6 'next header' chain and copy the next header value (which contains the transport protocol number) in the last known 'next header' to the protocol field in the IPv4 header. This means that the translator MUST forward all protocols to avoid black holing. Some protocols are known to fail when translated (e.g., IPsec AH) and will fail at the receiver. NEW: Certain IPv6 headers cannot be translated because they have no meaning in IPv4. These headers are skipped over during processing and include HOPOPT (0), IPv6-Route (43), IPv6-Opts (60), and source-routing (??). For the first 'next header' that does not match=20 one of the values above, its next header value (which contains the transport protocol number) is copied to the protocol field in the IPv4 header. This means that all transport protocols are translated. Some translated protocols will fail at the receiver for various reasons: some are known to fail when translated (e.g., IPsec AH=20 (51)), others are malformed IPv6 packets with a useless IPv4=20 protocol number (e.g., IPv6-NoNxt (59)), and others will fail checksum validation if the address translation is not checksum=20 neutral [I-D.ietf-behave-address-format] and the translator does=20 not update the transport protocol's checksum (because the=20 translator doesn't support recalculating the checksum for that=20 transport protocol, e.g., SCTP (132)). Comments on this rewording? [Senthil] When you have fragment header as the next header, according to the text, one would end up copying the frag header as the protocol, which is not correct. You would want to add some wording for frag header as it is not skipped over but its contents are transformed into ipv4 frag values. Also, I suggest removing the "source routing (??) from the text. Questions for the WG: 1. I don't know the value of 'source routing headers' (and left=20 it as ?? in the proposed NEW text). I don't see what value from http://www.iana.org/assignments/protocol-numbers should be used. [Senthil] The source routing is an IPv4 term for Routing header (0). 2. Which transport protcols MUST have their checksums recalculated by a translator compliant with draft-ietf-behave-v6v4-xlate, if the address translation is not checksum neutral? Section 3.5 says: "If the address translation algorithm is not checksum neutral, the recalculation and updating of the transport-layer headers which contain pseudo headers (e.g. of TCP, UDP and DCCP) MUST be=20 performed." The use of "e.g." means the list is non-normative. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Thu Apr 15 18:00:40 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 596AA3A6900 for ; Thu, 15 Apr 2010 18:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.46 X-Spam-Level: X-Spam-Status: No, score=-10.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 nB+zTVMYtBNj for ; Thu, 15 Apr 2010 18:00:38 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 6FF0C3A685D for ; Thu, 15 Apr 2010 18:00:38 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.52,216,1270425600"; d="scan'208";a="116088146" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 16 Apr 2010 01:00:31 +0000 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3G10V7P012906; Fri, 16 Apr 2010 01:00:31 GMT From: "Dan Wing" To: "'Senthil Sivakumar \(ssenthil\)'" , References: <20100407080001.688F73A68E4@core3.amsl.com><4BBC4CC2.9060108@cernet.edu.cn><4BBC750A.5020501@viagenie.ca><4BBC90F8.2050502@cernet.edu.cn><4BBC93CC.1020706@viagenie.ca><4BBCFC1B.5080706@gmail.com><0ad101cad7e4$06069350$0600a8c0@china.huawei.com><4BC139EB.6080704@cernet.edu.cn> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D224@xmb-sjc-236.amer.cisco.com> <9B57C850BB53634CACEC56EF4853FF65139336ED@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D2B2@xmb-sjc-236.amer.cisco.com> <9B57C850BB53634CACEC56EF4853FF651393462E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><4BC78BAA.1080009@gmail.com><4BC79883.9020702@viagenie.ca> <01f901cadcf1$658403a0$c2f0200a@cisco.com> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D7D2@xmb-sjc-236.amer.cisco.com> Date: Thu, 15 Apr 2010 18:00:28 -0700 Message-ID: <024f01cadd00$37f322e0$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acrc7kC9Mq/4RR2KTk+FRzOIT9+4AgAAK7oQAAL2+kAAAQBNIA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB09E2D7D2@xmb-sjc-236.amer.cisco.com> Cc: draft-ietf-behave-v6v4-xlate@tools.ietf.org, behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] IPv6 no next header to IPv4 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 01:00:40 -0000 > -----Original Message----- > From: Senthil Sivakumar (ssenthil) [mailto:ssenthil@cisco.com] > Sent: Thursday, April 15, 2010 5:37 PM > To: Dan Wing (dwing); behave@ietf.org > Cc: draft-ietf-behave-v6v4-xlate@tools.ietf.org; > behave-chairs@tools.ietf.org > Subject: RE: [BEHAVE] IPv6 no next header to IPv4 > > > > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf > Of Dan Wing (dwing) > Sent: Thursday, April 15, 2010 7:14 PM > To: behave@ietf.org > Cc: draft-ietf-behave-v6v4-xlate@tools.ietf.org; > behave-chairs@tools.ietf.org > Subject: Re: [BEHAVE] IPv6 no next header to IPv4 > > > On 04/15/2010 05:56 PM, Brian E Carpenter wrote: > > > However, what can be the value of translating a "no next header" > > > IPv6 packet into an IPv4 packet? The only meaningful > content can be > > > in some extension header or other, which can't be > translated anyway. > > > > Would there be any damage if we just drop such packets? > > > > Well, if two options are equally good (or equally useless in this > > case), why not choose the one which requires less code? > That is, make > > no special case for 59 and translate/forward it as usual. > > Doing that should help debug the problem; silently dropping such a > packet might make debugging more difficult. So I prefer > translating an > IPv6 packet containing only IPv6-NoNxt. > > > I suggest rewording xlate-18 from: > > OLD: > The translator does not translate IPv6 routing headers, hop-by-hop > extension headers, destination options headers, source routing > headers, or any layer 4 protocol (e.g., TCP header, IPsec > authentication header (AH) or encapsulating security payload (ESP) > header). However, the translator needs to traverse the IPv6 'next > header' chain and copy the next header value (which contains the > transport protocol number) in the last known 'next header' to the > protocol field in the IPv4 header. This means that the translator > MUST forward all protocols to avoid black holing. Some > protocols are > known to fail when translated (e.g., IPsec AH) and will fail at the > receiver. > NEW: > Certain IPv6 headers cannot be translated because they have no > meaning in IPv4. These headers are skipped over during processing > and include HOPOPT (0), IPv6-Route (43), IPv6-Opts (60), and > source-routing (??). For the first 'next header' that does > not match > one of the values above, its next header value (which contains the > transport protocol number) is copied to the protocol field in the > IPv4 > header. This means that all transport protocols are translated. > Some translated protocols will fail at the receiver for various > reasons: some are known to fail when translated (e.g., IPsec AH > (51)), others are malformed IPv6 packets with a useless IPv4 > protocol number (e.g., IPv6-NoNxt (59)), and others will fail > checksum validation if the address translation is not checksum > neutral [I-D.ietf-behave-address-format] and the translator does > not update the transport protocol's checksum (because the > translator doesn't support recalculating the checksum for that > transport protocol, e.g., SCTP (132)). > > Comments on this rewording? > > [Senthil] When you have fragment header as the next header, > according to > the > text, one would end up copying the frag header as the > protocol, which is > not correct. > You would want to add some wording for frag header as it is > not skipped > over but its > contents are transformed into ipv4 frag values. > > Also, I suggest removing the "source routing (??) from the text. Done. Revised New text: NEW: Certain IPv6 headers cannot be translated because they have no meaning in IPv4. These headers are skipped over during processing and include HOPOPT (0), IPv6-Route (43), and IPv6-Opts (60). The IPv6-Frag (44) header is handled as discussed below. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ For the first 'next header' that does not match one of the values above, its next header value (which contains the transport protocol number) is copied to the protocol field in the IPv4 header. This means that all transport protocols are translated. Some translated protocols will fail at the receiver for various reasons: some are known to fail when translated (e.g., IPsec AH (51)), others are malformed IPv6 packets with a useless IPv4 protocol number (e.g., IPv6-NoNxt (59)), and others will fail checksum validation if the address translation is not checksum neutral [I-D.ietf-behave-address-format] and the translator does not update the transport protocol's checksum (because the translator doesn't support recalculating the checksum for that transport protocol, e.g., SCTP (132)). I believe that entire NEW paragraph should be moved from 4.0 (where the old paragraph is now) to Section 4.1, "Translating IPv6 Headers into IPv4 Headers", and other text discussing IPv6 headers in 4.1 be removed or collapsed, such as this existing text in xlate-18's Section 4.1: "If any of an IPv6 Hop-by-Hop Options header, Destination Options header, or Routing header with the Segments Left field equal to zero are present in the IPv6 packet, those IPv6 extension headers MUST be ignored (i.e., there is no attempt to translate the extension headers) and the packet translated normally. However, the Total Length field and the Protocol field are adjusted to "skip" these extension headers. If a Routing header with a non-zero Segments Left field is present then the packet MUST NOT be translated, and an ICMPv6 "parameter problem/erroneous header field encountered" (Type 4/Code 0) error message, with the Pointer field indicating the first byte of the Segments Left field, SHOULD be returned to the sender." Or is there some valuable stuff in there we want to keep -- such as perhaps that sentence starting with "However,", and probably we want to keep that last paragraph ("If a Routing header with a non-zero ...")? > > Questions for the WG: > > 1. I don't know the value of 'source routing headers' (and left > it as ?? in the proposed NEW text). I don't see what value > from http://www.iana.org/assignments/protocol-numbers should > be used. > > [Senthil] The source routing is an IPv4 term for Routing header (0). Ok, so it duplicates HOPOPT. Thanks. -d > 2. Which transport protcols MUST have their checksums recalculated > by a translator compliant with draft-ietf-behave-v6v4-xlate, if > the address translation is not checksum neutral? > > Section 3.5 says: > > "If the address translation algorithm is not checksum neutral, the > recalculation and updating of the transport-layer headers which > contain pseudo headers (e.g. of TCP, UDP and DCCP) MUST be > performed." > > The use of "e.g." means the list is non-normative. > > -d > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From wbeebee@cisco.com Fri Apr 16 06:27:10 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BD9528C15A for ; Fri, 16 Apr 2010 06:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.547 X-Spam-Level: X-Spam-Status: No, score=-9.547 tagged_above=-999 required=5 tests=[AWL=1.052, 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 3e0hGMxa+gri for ; Fri, 16 Apr 2010 06:27:09 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5EFF728C182 for ; Fri, 16 Apr 2010 06:16:33 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALL/x0utJV2a/2dsb2JhbACbcXGkC5obhQ4EgzA X-IronPort-AV: E=Sophos;i="4.52,219,1270425600"; d="scan'208";a="102371274" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 16 Apr 2010 13:16:25 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o3GDGPSJ005749; Fri, 16 Apr 2010 13:16:25 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Apr 2010 08:16:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Apr 2010 08:16:24 -0500 Message-ID: In-Reply-To: <4BC78BAA.1080009@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] IPv6 no next header to IPv4 Thread-Index: Acrc5qEmTnQVABe7R8m+BhOUWCV5PwAgCvbg References: <20100407080001.688F73A68E4@core3.amsl.com><4BBC4CC2.9060108@cernet.edu.cn><4BBC750A.5020501@viagenie.ca><4BBC90F8.2050502@cernet.edu.cn><4BBC93CC.1020706@viagenie.ca><4BBCFC1B.5080706@gmail.com><0ad101cad7e4$06069350$0600a8c0@china.huawei.com><4BC139EB.6080704@cernet.edu.cn> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D224@xmb-sjc-236.amer.cisco.com> <9B57C850BB53634CACEC56EF4853FF65139336ED@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D2B2@xmb-sjc-236.amer.cisco.com><9B57C850BB53634CACEC56EF4853FF651393462E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4BC78BAA.1080009@gmail.com> From: "Wes Beebee (wbeebee)" To: "Brian E Carpenter" , "Dave Thaler" X-OriginalArrivalTime: 16 Apr 2010 13:16:25.0494 (UTC) FILETIME=[042D7B60:01CADD67] Cc: behave@ietf.org Subject: Re: [BEHAVE] IPv6 no next header to IPv4 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 13:27:10 -0000 > However, what can be the value of translating a "no next header" IPv6 packet into an IPv4 packet? > The only meaningful content can be in some extension header or other, which can't be translated=20 > anyway. Would there be any damage if we just drop such packets? Unless the mere presence of the packet yields information (such as a protocol keepalive). - Wes From xing@cernet.edu.cn Sat Apr 17 07:06:07 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CCBD3A69C2 for ; Sat, 17 Apr 2010 07:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.397 X-Spam-Level: * X-Spam-Status: No, score=1.397 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, FH_HAS_XAIMC=2.696] 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 aZKpLgPq4KpV for ; Sat, 17 Apr 2010 07:06:06 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 2B6883A6A10 for ; Sat, 17 Apr 2010 07:06:04 -0700 (PDT) Received: from [192.168.1.100]([123.112.66.196]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm104bca3c3d; Sat, 17 Apr 2010 22:05:42 +0800 Message-ID: <4BC9C025.2090606@cernet.edu.cn> Date: Sat, 17 Apr 2010 22:05:25 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Dan Wing References: <20100407080001.688F73A68E4@core3.amsl.com><4BBC4CC2.9060108@cernet.edu.cn><4BBC750A.5020501@viagenie.ca><4BBC90F8.2050502@cernet.edu.cn><4BBC93CC.1020706@viagenie.ca><4BBCFC1B.5080706@gmail.com><0ad101cad7e4$06069350$0600a8c0@china.huawei.com><4BC139EB.6080704@cernet.edu.cn> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D224@xmb-sjc-236.amer.cisco.com> <9B57C850BB53634CACEC56EF4853FF65139336ED@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D2B2@xmb-sjc-236.amer.cisco.com> <9B57C850BB53634CACEC56EF4853FF651393462E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><4BC78BAA.1080009@gmail.com><4BC79883.9020702@viagenie.ca> <01f901cadcf1$658403a0$c2f0200a@cisco.com> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D7D2@xmb-sjc-236.amer.cisco.com> <024f01cadd00$37f322e0$c2f0200a@cisco.com> In-Reply-To: <024f01cadd00$37f322e0$c2f0200a@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: Id4eIDYB Cc: draft-ietf-behave-v6v4-xlate@tools.ietf.org, behave@ietf.org, behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] IPv6 no next header to IPv4 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Apr 2010 14:06:07 -0000 Hi, Dan and All, Dan Wing 写道: > > Revised New text: > > NEW: > Certain IPv6 headers cannot be translated because they have no > meaning in IPv4. These headers are skipped over during processing > and include HOPOPT (0), IPv6-Route (43), and IPv6-Opts (60). > The IPv6-Frag (44) header is handled as discussed below. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > For the first 'next header' that does > not match one of the values above, its next header value (which > contains the transport protocol number) is copied to the protocol > field in the IPv4 header. This means that all transport protocols > are translated. Some translated protocols will fail at the > receiver for various reasons: some are known to fail when > translated (e.g., IPsec AH (51)), others are malformed IPv6 > packets with a useless IPv4 protocol number (e.g., IPv6-NoNxt > (59)), and others will fail checksum validation if the address > translation is not checksum neutral > [I-D.ietf-behave-address-format] and the translator does not > update the transport protocol's checksum (because the translator > doesn't support recalculating the checksum for that transport > protocol, e.g., SCTP (132)). > > We have finished a new version of xlate (version 19) based on the proposed text. > I believe that entire NEW paragraph should be moved from 4.0 (where > the old paragraph is now) to Section 4.1, "Translating IPv6 Headers into IPv4 > Headers", and other text discussing IPv6 headers in 4.1 be removed or > collapsed, such as this existing text in xlate-18's Section 4.1: > > "If any of an IPv6 Hop-by-Hop Options header, Destination Options > header, or Routing header with the Segments Left field equal to zero > are present in the IPv6 packet, those IPv6 extension headers MUST be > ignored (i.e., there is no attempt to translate the extension > headers) and the packet translated normally. However, the Total > Length field and the Protocol field are adjusted to "skip" these > extension headers. > The total length is calculated according to the payload length and the length of the IPv4 header. > If a Routing header with a non-zero Segments Left field is present > then the packet MUST NOT be translated, and an ICMPv6 "parameter > problem/erroneous header field encountered" (Type 4/Code 0) error > message, with the Pointer field indicating the first byte of the > Segments Left field, SHOULD be returned to the sender." > It seems that we need to keep this one for better trouble shooting. > Or is there some valuable stuff in there we want to keep -- such as > perhaps that sentence starting with "However,", and probably we > want to keep that last paragraph ("If a Routing header with a > non-zero ...")? > > Thanks for the proposed text and comments. Regards, xing, congxiao From root@core3.amsl.com Sat Apr 17 07:15:01 2010 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C7F853A69AE; Sat, 17 Apr 2010 07:15: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: <20100417141501.C7F853A69AE@core3.amsl.com> Date: Sat, 17 Apr 2010 07:15:01 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-19.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Apr 2010 14: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 Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : IP/ICMP Translation Algorithm Author(s) : X. Li, et al. Filename : draft-ietf-behave-v6v4-xlate-19.txt Pages : 31 Date : 2010-04-17 This document forms a replacement of the Stateless IP/ICMP Translation Algorithm (SIIT) described in RFC 2765. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-19.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-behave-v6v4-xlate-19.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-17070605.I-D@ietf.org> --NextPart-- From rvaithia@cisco.com Sun Apr 18 21:33:49 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9115A3A6A70 for ; Sun, 18 Apr 2010 21:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.854 X-Spam-Level: X-Spam-Status: No, score=-9.854 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, 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 PSgul6csRo1k for ; Sun, 18 Apr 2010 21:33:48 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 6D00F3A6A80 for ; Sun, 18 Apr 2010 21:33:48 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABd6y0urR7Ht/2dsb2JhbACDFJhhcaEViFwBkByBKYJ2cQSDMos/ X-IronPort-AV: E=Sophos;i="4.52,234,1270425600"; d="scan'208";a="117181136" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 19 Apr 2010 04:33:40 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3J4XeP3011551; Mon, 19 Apr 2010 04:33:40 GMT Received: from xmb-sjc-231.amer.cisco.com ([128.107.191.73]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 18 Apr 2010 21:33:39 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Date: Sun, 18 Apr 2010 21:33:37 -0700 Message-ID: In-Reply-To: <4BC9C025.2090606@cernet.edu.cn> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] IPv6 no next header to IPv4 Thread-Index: AcreN0L9G1RbC8u1SXKIKldpWSgodABPZ3OQ References: <20100407080001.688F73A68E4@core3.amsl.com><4BBC4CC2.9060108@cernet.edu.cn><4BBC750A.5020501@viagenie.ca><4BBC90F8.2050502@cernet.edu.cn><4BBC93CC.1020706@viagenie.ca><4BBCFC1B.5080706@gmail.com><0ad101cad7e4$06069350$0600a8c0@china.huawei.com><4BC139EB.6080704@cernet.edu.cn> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D224@xmb-sjc-236.amer.cisco.com> <9B57C850BB53634CACEC56EF4853FF65139336ED@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D2B2@xmb-sjc-236.amer.cisco.com> <9B57C850BB53634CACEC56EF4853FF651393462E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><4BC78BAA.1080009@gmail.com><4BC79883.9020702@viagenie.ca> <01f901cadcf1$658403a0$c2f0200a@cisco.com> <85B2F271FDF6B949B3672BA5A7BB62FB09E2D7D2@xmb-sjc-236.amer.cisco.com><024f01cadd00$37f322e0$c2f0200a@cisco.com> <4BC9C025.2090606@cernet.edu.cn> From: "Ramji Vaithianathan (rvaithia)" To: "Xing Li" , "Dan Wing (dwing)" X-OriginalArrivalTime: 19 Apr 2010 04:33:39.0912 (UTC) FILETIME=[7C12BC80:01CADF79] Cc: draft-ietf-behave-v6v4-xlate@tools.ietf.org, behave@ietf.org, behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] IPv6 no next header to IPv4 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 04:33:49 -0000 Hi, I have few comments on the latest version 19. Comment 1: There is reference to SCTP in the latest versions: > translated (e.g., IPsec AH (51)), others are malformed IPv6 packets > with a useless IPv4 protocol number (e.g., IPv6-NoNxt (59)), and > others will fail checksum validation if the address translation is > not checksum neutral [I-D.ietf-behave-address-format] and the > translator does not update the transport protocol's checksum (because > the translator doesn't support recalculating the checksum for that > transport protocol, e.g., SCTP (132)). As I understand SCTP does not use pseudo header for Transport Layer Checksum calculation. So it should not fail due to not recalculating L4 checksum. However DCCP will fail, if the translator does not recalculate the L4 checksum. Should we change the reference to DCCP instead of SCTP, something like this: translator does not update the transport protocol's checksum (because the translator doesn't support recalculating the checksum for that transport protocol, e.g., DCCP (33)). Alternately, the statement can be introduced as part of following - please refer to the next comment. Comment 2: Also we have the following description: > 4. Translating from IPv6 to IPv4 > > When an IP/ICMP translator receives an IPv6 datagram addressed to a > destination towards the IPv4 domain, it translates the IPv6 header of > the received IPv6 packet into an IPv4 header. The original IPv6 > header on the packet is removed and replaced by an IPv4 header. > Since the ICMPv6 [RFC4443], TCP [RFC0793], UDP [RFC0768] and DCCP > [RFC4340] headers contain checksums that cover the IP header, if the > address mapping algorithm is not checksum-neutral, the checksum MUST > be evaluated before translation and the ICMP and transport-layer > headers MUST be updated. I had discussed this privately with you on this. Again the wording seems to imply we MUST support DCCP. We can probably add a line to indicate DCCP transport header translator is not mandatory. " When an IP/ICMP translator receives an IPv6 datagram addressed to a destination towards the IPv4 domain, it translates the IPv6 header of the received IPv6 packet into an IPv4 header. The original IPv6 header on the packet is removed and replaced by an IPv4 header. Since the ICMPv6 [RFC4443], TCP [RFC0793], UDP [RFC0768] and DCCP [RFC4340] headers contain checksums that cover the IP header, if the address mapping algorithm is not checksum-neutral, the checksum MUST be recalculated during translation and the ICMP and transport-layer headers MUST be updated. If the translator does not support translation of DCCP protocol, the transport checksum MAY be left unchanged after translation and the L3 header alone translated. DCCP protocol MAY fail because the translator does not support translating DCCP protocol" Comment 3: Similar comment applies to IPv4 to IPv6 translation. We could add 3. Translating from IPv4 to IPv6 When an IP/ICMP translator receives an IPv4 datagram addressed to a destination towards the IPv6 domain, it translates the IPv4 header of that packet into an IPv6 header. The original IPv4 header on the packet is removed and replaced by an IPv6 header. Since the ICMPv6 [RFC4443], TCP [RFC0793], UDP [RFC0768] and DCCP [RFC4340] headers contain checksums that cover IP header information, if the address mapping algorithm is not checksum-neutral, the checksum MUST be evaluated before translation and the ICMPv6 and transport-layer headers MUST be updated. The data portion of the packet is left unchanged. The IP/ICMP translator then forwards the packet based on the IPv6 destination address. If the translator does not support translation of DCCP protocol, the transport checksum MAY be left unchanged after translation and the L3 header alone translated. DCCP protocol MAY fail because the translator does not support translating DCCP protocol. Thanks, Ramji -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Xing Li Sent: Saturday, April 17, 2010 7:35 PM To: Dan Wing (dwing) Cc: draft-ietf-behave-v6v4-xlate@tools.ietf.org; behave@ietf.org; behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] IPv6 no next header to IPv4 Hi, Dan and All, Dan Wing $B > Revised New text: > > NEW: > Certain IPv6 headers cannot be translated because they have no > meaning in IPv4. These headers are skipped over during processing > and include HOPOPT (0), IPv6-Route (43), and IPv6-Opts (60). > The IPv6-Frag (44) header is handled as discussed below. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > For the first 'next header' that does > not match one of the values above, its next header value (which > contains the transport protocol number) is copied to the protocol > field in the IPv4 header. This means that all transport protocols > are translated. Some translated protocols will fail at the > receiver for various reasons: some are known to fail when > translated (e.g., IPsec AH (51)), others are malformed IPv6 > packets with a useless IPv4 protocol number (e.g., IPv6-NoNxt > (59)), and others will fail checksum validation if the address > translation is not checksum neutral > [I-D.ietf-behave-address-format] and the translator does not > update the transport protocol's checksum (because the translator > doesn't support recalculating the checksum for that transport > protocol, e.g., SCTP (132)). > > We have finished a new version of xlate (version 19) based on the proposed text. > I believe that entire NEW paragraph should be moved from 4.0 (where > the old paragraph is now) to Section 4.1, "Translating IPv6 Headers > into IPv4 Headers", and other text discussing IPv6 headers in 4.1 be > removed or collapsed, such as this existing text in xlate-18's Section 4.1: > > "If any of an IPv6 Hop-by-Hop Options header, Destination Options > header, or Routing header with the Segments Left field equal to zero > are present in the IPv6 packet, those IPv6 extension headers MUST be > ignored (i.e., there is no attempt to translate the extension > headers) and the packet translated normally. However, the Total > Length field and the Protocol field are adjusted to "skip" these > extension headers. > The total length is calculated according to the payload length and the length of the IPv4 header. > If a Routing header with a non-zero Segments Left field is present > then the packet MUST NOT be translated, and an ICMPv6 "parameter > problem/erroneous header field encountered" (Type 4/Code 0) error > message, with the Pointer field indicating the first byte of the > Segments Left field, SHOULD be returned to the sender." > It seems that we need to keep this one for better trouble shooting. > Or is there some valuable stuff in there we want to keep -- such as > perhaps that sentence starting with "However,", and probably we want > to keep that last paragraph ("If a Routing header with a non-zero > ...")? > > Thanks for the proposed text and comments. Regards, xing, congxiao _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From pchamp@cisco.com Tue Apr 20 07:11:45 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAE0B3A6BCD for ; Tue, 20 Apr 2010 07:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.74 X-Spam-Level: X-Spam-Status: No, score=-8.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 8eN+nekM2-yz for ; Tue, 20 Apr 2010 07:11:39 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5DB1528C1A2 for ; Tue, 20 Apr 2010 07:03:44 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPRQzUurR7Hu/2dsb2JhbACcAnGjCZpAhQ8EgzQ X-IronPort-AV: E=Sophos;i="4.52,243,1270425600"; d="scan'208";a="517859875" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 20 Apr 2010 14:03:35 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3KE3ZRp009212; Tue, 20 Apr 2010 14:03:35 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Apr 2010 07:03:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Apr 2010 07:03:34 -0700 Message-ID: <48214755113BB04F84D958B4F0DE261C0A3EEC01@xmb-sjc-222.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question Regarding Draft Stateful NAT64 Thread-Index: AcrgU3Ed2F5EMLPsSxGMU9p8+OfAPwAMptWgAAK6ctA= From: "Philippe Champagne (pchamp)" To: , X-OriginalArrivalTime: 20 Apr 2010 14:03:35.0728 (UTC) FILETIME=[44C7EB00:01CAE092] X-Mailman-Approved-At: Tue, 20 Apr 2010 08:57:07 -0700 Subject: [BEHAVE] FW: Question Regarding Draft Stateful NAT64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 14:11:45 -0000 Hi Everyone In the draft http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate-stateful/ At the very end of section 3.5.2.2, (page 29, just before V4 SYN RCV) "If there is no corresponding entry in the TCP BIB the packet is silently discarded." However, according to this RFC on NAT best practice: http://datatracker.ietf.org/doc/rfc5382/ Bottom of page 10 section 5: --------------- The handling of non-SYN packets for connections for which there is no active mapping is left unspecified. Such packets may be received if the NAT silently abandons a live connection, or abandons a connection in TIME_WAIT state before the 4 minute TIME_WAIT period expires. The decision to either silently drop such packets or to respond with a TCP RST packet is left up to the implementation. --------------- >From there, I believe you should remove the silently drop and replace it with "left up to the implementation" Personally, since the NAT (in overload when it allocates a new source port) gets implicated in the well being of the TCP connection, it has the responsibility to reply on the behalf of the server that no longer can be reached with the original tuple that has been lost. That's perhaps a philosophical debate, but it is beyond the point. I believe this draft should be in line with rfc5382. Regards Phil Champagne Cisco Systems, Inc. From ebisawa@sablenetworks.net Tue Apr 20 17:56:33 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ECB23A68C2 for ; Tue, 20 Apr 2010 17:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 tsVUBMlpvFav for ; Tue, 20 Apr 2010 17:56:32 -0700 (PDT) Received: from sablenetworks.net (sablenetworks.net [202.229.133.90]) by core3.amsl.com (Postfix) with ESMTP id 0BEFE3A6874 for ; Tue, 20 Apr 2010 17:56:31 -0700 (PDT) Received: (qmail 16779 invoked by SAV 20100420.025 by uid 0); 21 Apr 2010 09:56:21 +0900 Received: from unknown (HELO ?192.168.11.8?) (ebisawa@124.27.36.96) by dc12.etius.jp (202.229.133.90) with ESMTPA; 21 Apr 2010 09:56:21 +0900 Date: Wed, 21 Apr 2010 09:56:22 +0900 From: Kentaro Ebisawa To: behave@ietf.org Message-Id: <20100421095622.9B21.B01659E3@sablenetworks.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.54 [ja] Subject: [BEHAVE] IPv4 packet with DF=1 and already fragmented (xlate-19) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 00:56:33 -0000 Hi, In draft-ietf-behave-v6v4-xlate-19.txt Section 3. Page 6, it says: When an IPv4 node performs path MTU discovery (by setting the Don't Fragment (DF) bit in the header), path MTU discovery can operate end- ... snip ... As a result, an IPv6 fragment header is only included if the IPv4 packet is already fragmented. How should we handle fragmented IPv4 packet with DF=1 ? Since it's fragmented you need to add fragment hdr when translating to IPv6. But if you do so, it will imply you can fragment which means DF was 0... Or can we assume there are no valid IPv4 packet with DF=1 and already fragmented, and simply drop it ? It's little confusing since this sentence is written in the paragraph describing DF=1 case. Thanks, -- Kentaro Ebisawa From rvaithia@cisco.com Tue Apr 20 21:17:17 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE10C3A6C16 for ; Tue, 20 Apr 2010 21:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.227 X-Spam-Level: X-Spam-Status: No, score=-10.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 4efTzi30IHHn for ; Tue, 20 Apr 2010 21:17:13 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 877B73A69B8 for ; Tue, 20 Apr 2010 21:17:11 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJIZzkurR7Hu/2dsb2JhbACcEXGkaZpIhQ8EgzQ X-IronPort-AV: E=Sophos;i="4.52,247,1270425600"; d="scan'208,223";a="118311950" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 21 Apr 2010 04:16:49 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3L4Gnhg009033; Wed, 21 Apr 2010 04:16:49 GMT Received: from xmb-sjc-231.amer.cisco.com ([128.107.191.73]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Apr 2010 21:16:49 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Apr 2010 21:16:52 -0700 Message-ID: In-Reply-To: <20100421095622.9B21.B01659E3@sablenetworks.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] IPv4 packet with DF=1 and already fragmented (xlate-19) Thread-Index: Acrg7Xtcmr02+icHTluZxcA5KDaUpgAGNhqA References: <20100421095622.9B21.B01659E3@sablenetworks.net> From: "Ramji Vaithianathan (rvaithia)" To: "Kentaro Ebisawa" X-OriginalArrivalTime: 21 Apr 2010 04:16:49.0193 (UTC) FILETIME=[7676C190:01CAE109] Cc: behave@ietf.org Subject: Re: [BEHAVE] IPv4 packet with DF=1 and already fragmented (xlate-19) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 04:17:18 -0000 >From what I see there should be NO fragmented pkts with DF bit set, so such packets should be dropped as invalid. I had asked a similar question sometime back and we had requested input from the group on this, I don't think there was specific reply on this. Thanks, Ramji -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Kentaro Ebisawa Sent: Wednesday, April 21, 2010 6:26 AM To: behave@ietf.org Subject: [BEHAVE] IPv4 packet with DF=3D1 and already fragmented (xlate-19) Hi, In draft-ietf-behave-v6v4-xlate-19.txt Section 3. Page 6, it says: When an IPv4 node performs path MTU discovery (by setting the Don't Fragment (DF) bit in the header), path MTU discovery can operate end- ... snip ... As a result, an IPv6 fragment header is only included if the IPv4 packet is already fragmented. How should we handle fragmented IPv4 packet with DF=3D1 ? Since it's fragmented you need to add fragment hdr when translating to IPv6. But if you do so, it will imply you can fragment which means DF was 0... Or can we assume there are no valid IPv4 packet with DF=3D1 and already fragmented, and simply drop it ? It's little confusing since this sentence is written in the paragraph describing DF=3D1 case. Thanks, -- Kentaro Ebisawa _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From erik.nordmark@oracle.com Wed Apr 21 11:41:37 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97BA43A696A for ; Wed, 21 Apr 2010 11:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfmTyuk0k1D4 for ; Wed, 21 Apr 2010 11:41:36 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 72D0A3A6AC1 for ; Wed, 21 Apr 2010 11:37:05 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3LIaqc9016384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Apr 2010 18:36:53 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3LIapf0000775; Wed, 21 Apr 2010 18:36:51 GMT Received: from abhmt018.oracle.com by acsmt354.oracle.com with ESMTP id 178823431271874979; Wed, 21 Apr 2010 11:36:19 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Apr 2010 11:36:18 -0700 Message-ID: <4BCF45A1.3040906@oracle.com> Date: Wed, 21 Apr 2010 11:36:17 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 MIME-Version: 1.0 To: "Ramji Vaithianathan (rvaithia)" References: <20100421095622.9B21.B01659E3@sablenetworks.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: rcsinet15.oracle.com [148.87.113.117] X-CT-RefId: str=0001.0A090201.4BCF45C6.0082:SCFMA4539811,ss=1,fgs=0 Cc: Kentaro Ebisawa , behave@ietf.org Subject: Re: [BEHAVE] IPv4 packet with DF=1 and already fragmented (xlate-19) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 18:41:37 -0000 On 04/20/10 09:16 PM, Ramji Vaithianathan (rvaithia) wrote: > From what I see there should be NO fragmented pkts with DF bit set, so > such packets should be dropped as invalid. In which RFC does it say that they are invalid? I certainly haven't seen a prohibition on sending IPv4 packets with both DF and MF set, and this is used by at least some implementations. (The usage I know of comes from wanting to do optimal source fragmentation for NFS over UDP.) Erik > I had asked a similar question sometime back and we had requested input > from the group on this, I don't think there was specific reply on this. > > Thanks, > > Ramji > > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Kentaro Ebisawa > Sent: Wednesday, April 21, 2010 6:26 AM > To: behave@ietf.org > Subject: [BEHAVE] IPv4 packet with DF=1 and already fragmented > (xlate-19) > > Hi, > > In draft-ietf-behave-v6v4-xlate-19.txt Section 3. Page 6, it says: > > When an IPv4 node performs path MTU discovery (by setting the Don't > Fragment (DF) bit in the header), path MTU discovery can operate end- > ... snip ... > As a > result, an IPv6 fragment header is only included if the IPv4 packet > is already fragmented. > > How should we handle fragmented IPv4 packet with DF=1 ? > Since it's fragmented you need to add fragment hdr when translating to > IPv6. But if you do so, it will imply you can fragment which means DF > was 0... > > Or can we assume there are no valid IPv4 packet with DF=1 and already > fragmented, and simply drop it ? > > It's little confusing since this sentence is written in the paragraph > describing DF=1 case. > > Thanks, > -- > Kentaro Ebisawa > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From marka@isc.org Wed Apr 21 16:30:33 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA9DA3A6898 for ; Wed, 21 Apr 2010 16:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.472, 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 P66Xjk3K2HJn for ; Wed, 21 Apr 2010 16:30:33 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id E7F0D3A67FA for ; Wed, 21 Apr 2010 16:30:32 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 6A144E914E; Wed, 21 Apr 2010 23:30:21 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o3LNUGr1077066; Thu, 22 Apr 2010 09:30:16 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004212330.o3LNUGr1077066@drugs.dv.isc.org> To: Erik Nordmark From: Mark Andrews References: <20100421095622.9B21.B01659E3@sablenetworks.net> <4BCF45A1.3040906@oracle.com> In-reply-to: Your message of "Wed, 21 Apr 2010 11:36:17 MST." <4BCF45A1.3040906@oracle.com> Date: Thu, 22 Apr 2010 09:30:16 +1000 Sender: marka@isc.org Cc: Kentaro Ebisawa , behave@ietf.org, "Ramji Vaithianathan \(rvaithia\)" Subject: Re: [BEHAVE] IPv4 packet with DF=1 and already fragmented (xlate-19) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 23:30:33 -0000 In message <4BCF45A1.3040906@oracle.com>, Erik Nordmark writes: > On 04/20/10 09:16 PM, Ramji Vaithianathan (rvaithia) wrote: > > From what I see there should be NO fragmented pkts with DF bit set, so > > such packets should be dropped as invalid. > > In which RFC does it say that they are invalid? > > I certainly haven't seen a prohibition on sending IPv4 packets with both > DF and MF set, and this is used by at least some implementations. (The > usage I know of comes from wanting to do optimal source fragmentation > for NFS over UDP.) > > Erik As far as I know it is not prohibited but there are some kernel developers that believe it is and clear/don't set DF if they are sending packet that is fragmented at the source. This behaviour has been useful as far as DNS/UDP is concerned as only those EDNS packets in the 1481-1500 octet range get hit by IP-in-IP tunnels if DF is incorrectly set by the kernel on UDP packets without the application requesting it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From rvaithia@cisco.com Wed Apr 21 18:39:15 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E54303A6920 for ; Wed, 21 Apr 2010 18:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.351 X-Spam-Level: X-Spam-Status: No, score=-10.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 xaWvFz2CdjUY for ; Wed, 21 Apr 2010 18:39:15 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 17BC93A6894 for ; Wed, 21 Apr 2010 18:39:15 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM5Fz0urR7Ht/2dsb2JhbACcHHGkLZo3AoUMBIM0 X-IronPort-AV: E=Sophos;i="4.52,253,1270425600"; d="scan'208";a="251767959" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 22 Apr 2010 01:39:05 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3M1d5CK027105; Thu, 22 Apr 2010 01:39:05 GMT Received: from xmb-sjc-231.amer.cisco.com ([128.107.191.73]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Apr 2010 18:39:05 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Apr 2010 18:39:02 -0700 Message-ID: In-Reply-To: <201004212330.o3LNUGr1077066@drugs.dv.isc.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] IPv4 packet with DF=1 and already fragmented (xlate-19) Thread-Index: AcrhqqDpXmd4r114RXejj+PeJu+hagACfbug References: <20100421095622.9B21.B01659E3@sablenetworks.net> <4BCF45A1.3040906@oracle.com> <201004212330.o3LNUGr1077066@drugs.dv.isc.org> From: "Ramji Vaithianathan (rvaithia)" To: , "Erik Nordmark" , "Kentaro Ebisawa" X-OriginalArrivalTime: 22 Apr 2010 01:39:05.0758 (UTC) FILETIME=[983AEBE0:01CAE1BC] Cc: behave@ietf.org Subject: Re: [BEHAVE] IPv4 packet with DF=1 and already fragmented (xlate-19) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 01:39:16 -0000 Thanks for the clarification on this. So as far as the original question is concerned, what draft says currently: 3.1. Translating IPv4 Headers into IPv6 Headers ... ... If the DF bit is set and the packet is not a fragment (i.e., the MF flag is not set and the Fragment Offset is equal to zero) then the translator SHOULD NOT add a Fragment header to the resulting packet. The IPv6 header fields are set as follows: seems to answer the question. Basically if=20 DF bit is set to 1 and packet is a Fragment - we still add a Fragment Header. Ramji -----Original Message----- From: marka@isc.org [mailto:marka@isc.org]=20 Sent: Thursday, April 22, 2010 5:00 AM To: Erik Nordmark Cc: Ramji Vaithianathan (rvaithia); Kentaro Ebisawa; behave@ietf.org Subject: Re: [BEHAVE] IPv4 packet with DF=3D1 and already fragmented (xlate-19)=20 In message <4BCF45A1.3040906@oracle.com>, Erik Nordmark writes: > On 04/20/10 09:16 PM, Ramji Vaithianathan (rvaithia) wrote: > > From what I see there should be NO fragmented pkts with DF bit set, > > so such packets should be dropped as invalid. >=20 > In which RFC does it say that they are invalid? >=20 > I certainly haven't seen a prohibition on sending IPv4 packets with=20 > both DF and MF set, and this is used by at least some implementations. > (The usage I know of comes from wanting to do optimal source=20 > fragmentation for NFS over UDP.) >=20 > Erik As far as I know it is not prohibited but there are some kernel developers that believe it is and clear/don't set DF if they are sending packet that is fragmented at the source. This behaviour has been useful as far as DNS/UDP is concerned as only those EDNS packets in the 1481-1500 octet range get hit by IP-in-IP tunnels if DF is incorrectly set by the kernel on UDP packets without the application requesting it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ebisawa@sablenetworks.net Wed Apr 21 20:08:44 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E02C3A67E7 for ; Wed, 21 Apr 2010 20:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, J_CHICKENPOX_82=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 JkMt3ZcdwAPY for ; Wed, 21 Apr 2010 20:08:43 -0700 (PDT) Received: from sablenetworks.net (sablenetworks.net [202.229.133.90]) by core3.amsl.com (Postfix) with ESMTP id E0DAC3A68EB for ; Wed, 21 Apr 2010 20:08:42 -0700 (PDT) Received: (qmail 29826 invoked by SAV 20100421.039 by uid 0); 22 Apr 2010 12:08:31 +0900 Received: from unknown (HELO ?192.168.11.8?) (ebisawa@124.27.36.96) by dc12.etius.jp (202.229.133.90) with ESMTPA; 22 Apr 2010 12:08:31 +0900 Date: Thu, 22 Apr 2010 12:08:32 +0900 From: Kentaro Ebisawa To: "Ramji Vaithianathan (rvaithia)" In-Reply-To: References: <201004212330.o3LNUGr1077066@drugs.dv.isc.org> Message-Id: <20100422120832.9B93.B01659E3@sablenetworks.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.54 [ja] Cc: behave@ietf.org, Erik Nordmark , marka@isc.org Subject: Re: [BEHAVE] IPv4 packet with DF=1 and already fragmented (xlate-19) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 03:08:44 -0000 Thanks for the comments. So we add Fragment header if the packet is fragment(MF!=0 or offset=!0) but would not fragment it on translator if DF=1. -- Kentaro Ebisawa On Wed, 21 Apr 2010 18:39:02 -0700 "Ramji Vaithianathan (rvaithia)" wrote: > Thanks for the clarification on this. > > So as far as the original question is concerned, what draft says > currently: > > 3.1. Translating IPv4 Headers into IPv6 Headers > ... > ... > If the DF bit is set and the packet is not a fragment (i.e., the MF > flag is not set and the Fragment Offset is equal to zero) then the > translator SHOULD NOT add a Fragment header to the resulting packet. > The IPv6 header fields are set as follows: > > seems to answer the question. > > Basically if > DF bit is set to 1 and packet is a Fragment - we still add a Fragment > Header. > > Ramji > > > -----Original Message----- > From: marka@isc.org [mailto:marka@isc.org] > Sent: Thursday, April 22, 2010 5:00 AM > To: Erik Nordmark > Cc: Ramji Vaithianathan (rvaithia); Kentaro Ebisawa; behave@ietf.org > Subject: Re: [BEHAVE] IPv4 packet with DF=1 and already fragmented > (xlate-19) > > > In message <4BCF45A1.3040906@oracle.com>, Erik Nordmark writes: > > On 04/20/10 09:16 PM, Ramji Vaithianathan (rvaithia) wrote: > > > From what I see there should be NO fragmented pkts with DF bit set, > > > > so such packets should be dropped as invalid. > > > > In which RFC does it say that they are invalid? > > > > I certainly haven't seen a prohibition on sending IPv4 packets with > > both DF and MF set, and this is used by at least some implementations. > > > (The usage I know of comes from wanting to do optimal source > > fragmentation for NFS over UDP.) > > > > Erik > > As far as I know it is not prohibited but there are some kernel > developers that believe it is and clear/don't set DF if they are sending > packet that is fragmented at the source. > > This behaviour has been useful as far as DNS/UDP is concerned as only > those EDNS packets in the 1481-1500 octet range get hit by IP-in-IP > tunnels if DF is incorrectly set by the kernel on UDP packets without > the application requesting it. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From rvaithia@cisco.com Wed Apr 21 21:23:22 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A56683A6940 for ; Wed, 21 Apr 2010 21:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.113 X-Spam-Level: X-Spam-Status: No, score=-10.113 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxvHS8RVFdcs for ; Wed, 21 Apr 2010 21:23:17 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id CD7EF3A6AE3 for ; Wed, 21 Apr 2010 21:22:59 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD9sz0urR7Hu/2dsb2JhbACcHnGjbppGAoUMBIM0 X-IronPort-AV: E=Sophos;i="4.52,253,1270425600"; d="scan'208";a="118866720" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 22 Apr 2010 04:22:50 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3M4MoJp003848; Thu, 22 Apr 2010 04:22:50 GMT Received: from xmb-sjc-231.amer.cisco.com ([128.107.191.73]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Apr 2010 21:22:50 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Apr 2010 21:22:49 -0700 Message-ID: In-Reply-To: <20100422120832.9B93.B01659E3@sablenetworks.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] IPv4 packet with DF=1 and already fragmented (xlate-19) Thread-Index: AcrhyRstzRnLfr9+QnyoJ70OoGp0+AACLS5w References: <201004212330.o3LNUGr1077066@drugs.dv.isc.org> <20100422120832.9B93.B01659E3@sablenetworks.net> From: "Ramji Vaithianathan (rvaithia)" To: "Kentaro Ebisawa" X-OriginalArrivalTime: 22 Apr 2010 04:22:50.0336 (UTC) FILETIME=[78228E00:01CAE1D3] Cc: behave@ietf.org, Erik Nordmark , marka@isc.org Subject: Re: [BEHAVE] IPv4 packet with DF=1 and already fragmented (xlate-19) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 04:23:22 -0000 Yes, that is my understanding as well. Also, if the fragment size (IPv4 packet length) is greater than 1252 bytes, the translated IPv6 packet (which will have a fragment header) will be greater than 1280 bytes. So we will need to drop the fragment and generate ICMP PTB message?? So from what I see: some fragments (assuming they are <=3D 1252 bytes) will get translated with Frag Header and=20 some fragments (assuming they are > 1252 bytes) will get dropped. Thanks, Ramji -----Original Message----- From: Kentaro Ebisawa [mailto:ebisawa@sablenetworks.net]=20 Sent: Thursday, April 22, 2010 8:39 AM To: Ramji Vaithianathan (rvaithia) Cc: marka@isc.org; Erik Nordmark; behave@ietf.org Subject: Re: [BEHAVE] IPv4 packet with DF=3D1 and already fragmented (xlate-19) Thanks for the comments. So we add Fragment header if the packet is fragment(MF!=3D0 or = offset=3D!0) but would not fragment it on translator if DF=3D1. -- Kentaro Ebisawa On Wed, 21 Apr 2010 18:39:02 -0700 "Ramji Vaithianathan (rvaithia)" wrote: > Thanks for the clarification on this. >=20 > So as far as the original question is concerned, what draft says > currently: >=20 > 3.1. Translating IPv4 Headers into IPv6 Headers > ... > ... > If the DF bit is set and the packet is not a fragment (i.e., the MF > flag is not set and the Fragment Offset is equal to zero) then the > translator SHOULD NOT add a Fragment header to the resulting packet. > The IPv6 header fields are set as follows: >=20 > seems to answer the question. >=20 > Basically if=20 > DF bit is set to 1 and packet is a Fragment - we still add a Fragment > Header. >=20 > Ramji >=20 >=20 > -----Original Message----- > From: marka@isc.org [mailto:marka@isc.org]=20 > Sent: Thursday, April 22, 2010 5:00 AM > To: Erik Nordmark > Cc: Ramji Vaithianathan (rvaithia); Kentaro Ebisawa; behave@ietf.org > Subject: Re: [BEHAVE] IPv4 packet with DF=3D1 and already fragmented > (xlate-19)=20 >=20 >=20 > In message <4BCF45A1.3040906@oracle.com>, Erik Nordmark writes: > > On 04/20/10 09:16 PM, Ramji Vaithianathan (rvaithia) wrote: > > > From what I see there should be NO fragmented pkts with DF bit set, >=20 > > > so such packets should be dropped as invalid. > >=20 > > In which RFC does it say that they are invalid? > >=20 > > I certainly haven't seen a prohibition on sending IPv4 packets with=20 > > both DF and MF set, and this is used by at least some implementations. >=20 > > (The usage I know of comes from wanting to do optimal source=20 > > fragmentation for NFS over UDP.) > >=20 > > Erik >=20 > As far as I know it is not prohibited but there are some kernel > developers that believe it is and clear/don't set DF if they are sending > packet that is fragmented at the source. >=20 > This behaviour has been useful as far as DNS/UDP is concerned as only > those EDNS packets in the 1481-1500 octet range get hit by IP-in-IP > tunnels if DF is incorrectly set by the kernel on UDP packets without > the application requesting it. >=20 > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From Washam.Fan@huaweisymantec.com Thu Apr 29 01:59:25 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB8653A6C09 for ; Thu, 29 Apr 2010 01:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.012 X-Spam-Level: ** X-Spam-Status: No, score=2.012 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SaVDTYuVakZ for ; Thu, 29 Apr 2010 01:59:25 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id ECD143A6C07 for ; Thu, 29 Apr 2010 01:59:19 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0L1M00A8YRM6SA60@hstga01-in.huaweisymantec.com> for behave@ietf.org; Thu, 29 Apr 2010 16:58:54 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0L1M0037XRM5XD20@hstml02-in.huaweisymantec.com> for behave@ietf.org; Thu, 29 Apr 2010 16:58:54 +0800 (CST) Received: from [10.27.154.72] by hstml02-in.huaweisymantec.com (mshttpd); Thu, 29 Apr 2010 16:58:53 +0800 From: WashamFan To: behave@ietf.org Message-id: Date: Thu, 29 Apr 2010 16:58:53 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal Subject: [BEHAVE] Section 5 in RFC5508 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 08:59:26 -0000 Hi, I have a confusion about hairpinned ICMP query support described in section 5 in rfc5508. ICMP query msg has no indication for dest port and the NAT should have no idea how to forward this ICMP query msg to the intented host behind it. Am I missing something? THanks in advance. washam From lars.eggert@nokia.com Thu Apr 29 02:37:31 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7153728C1F0 for ; Thu, 29 Apr 2010 02:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.417 X-Spam-Level: X-Spam-Status: No, score=-6.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 u2diHPkKZdZ5 for ; Thu, 29 Apr 2010 02:37:30 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 916153A6C51 for ; Thu, 29 Apr 2010 02:37:24 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o3T9axih022405 for ; Thu, 29 Apr 2010 12:37:08 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Apr 2010 12:37:05 +0300 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Apr 2010 12:36:41 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o3T9aedV009475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 29 Apr 2010 12:36:40 +0300 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96 at fit.nokia.com Content-Type: multipart/signed; boundary=Apple-Mail-5-21329665; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 29 Apr 2010 12:36:29 +0300 Message-Id: To: IETF BEHAVE WG Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Thu, 29 Apr 2010 12:36:34 +0300 (EEST) X-OriginalArrivalTime: 29 Apr 2010 09:36:42.0004 (UTC) FILETIME=[79934D40:01CAE77F] X-Nokia-AV: Clean Subject: [BEHAVE] wanted: your old NAT home router X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Lars Eggert , Markku Kojo , Seppo Hatonen List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 09:37:31 -0000 --Apple-Mail-5-21329665 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, for a measurement study done together with Markku Kojo's team at the = University of Helsinki, we're looking to collect as many different NAT = home routers as possible. If you have an old clunker lying around = somewhere, please contact me off-list. I'll cover shipping via DHL. Feel = free to forward this email as you see fit. The boxes will find a permanent home at the University of Helsinki. = Study results will be published openly. The intent is that this = collection become a resource for the community to be shared for future = studies.=20 Caveat: The boxes should NAT between Ethernet interfaces - we don't have = DSL or cable access equipment in the lab setup at the moment. Thanks, Lars= --Apple-Mail-5-21329665 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDQyOTA5MzYyOVowIwYJKoZIhvcNAQkEMRYEFH8ROei8P3q8OMedCBh7Bz9K0U6aMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQBZzX02FfQbps4QKZu7Z7FNbaC3V5fZ4sllnund0GIQBUo3EDtFPsdhT+Y3t2fjFmdQsGhf 8YlfqnOpr8Y9QdpyTwhtoP2MCBgsMlIEq3pJXpvPSZvKJYEJafxyCIRgsY3eEx0e4/YmrmQK7+es BAxz6J/vMalRd7Yp+Xr8zxGgOiBv22WfVKLtfQdswN5/x6Zf0rMsUbhwWe0Q3PwqQDvHuxOfi4b5 8dIm2rJnIFrVv6Q/E4UnTMBVzvqO082C3mLINWQinMDv+6nHJaRbcmRT6zlTmzvoF6so+Tbb4Ujs B7GJL5DV9vPgAKaupH1jJoJO/ukpsG/vf2ooZfdOZuShAAAAAAAA --Apple-Mail-5-21329665-- From dwing@cisco.com Thu Apr 29 14:13:01 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B58023A6ACC for ; Thu, 29 Apr 2010 14:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.934 X-Spam-Level: X-Spam-Status: No, score=-8.934 tagged_above=-999 required=5 tests=[AWL=-0.749, BAYES_40=-0.185, 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 MWYwYjptMI+g for ; Thu, 29 Apr 2010 14:13:01 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 0EE683A6AC6 for ; Thu, 29 Apr 2010 14:13:01 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIIAMeS2UurR7H+/2dsb2JhbACHXYEUlCRxpSaZdoUQBIM8 X-IronPort-AV: E=Sophos;i="4.52,297,1270425600"; d="scan'208";a="253311970" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 29 Apr 2010 21:12:47 +0000 Received: from dwingwxp01 (tbarkus-w2k-3.cisco.com [128.107.166.56]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3TLCi6m010693; Thu, 29 Apr 2010 21:12:44 GMT From: "Dan Wing" To: "'WashamFan'" , References: Date: Thu, 29 Apr 2010 14:12:48 -0700 Message-ID: <00d901cae7e0$b81f9ad0$38a66b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-reply-to: Thread-Index: AcrnelYZihBrL/N/QyKs6M3zSBTy2gAZgYtQ Subject: Re: [BEHAVE] Section 5 in RFC5508 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 21:13:01 -0000 > I have a confusion about hairpinned ICMP query support described > in section 5 in rfc5508. ICMP query msg has no indication for dest > port and the NAT should have no idea how to forward this ICMP > query msg to the intented host behind it. Am I missing something? The requirement for hairpinning ICMP queries applies to "Basic NAT" -- which is not NAPT. It says: REQ-7: NAT devices enforcing Basic NAT [NAT-TRAD] MUST support the traversal of hairpinned ICMP Query sessions. All NAT devices (i.e., Basic NAT as well as NAPT devices) MUST support the traversal of hairpinned ICMP Error messages: a) When forwarding a hairpinned ICMP Error message, the NAT device MUST translate the destination IP address of the outer IP header to be same as the source IP address of the embedded IP packet after the translation. "Basic NAT" does not change transport-layer (UDP, TCP) ports. NAPT changes transport-layer ports. "Basic NAT" is not NAPT. Hope that helps, -d From wwwrun@rfc-editor.org Thu Apr 29 16:36:27 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 427913A6C77; Thu, 29 Apr 2010 16:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.783 X-Spam-Level: X-Spam-Status: No, score=-0.783 tagged_above=-999 required=5 tests=[AWL=-1.197, BAYES_40=-0.185, J_CHICKENPOX_93=0.6, 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 wnAJqrBiOwO3; Thu, 29 Apr 2010 16:36:26 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 55F283A68A8; Thu, 29 Apr 2010 16:36:26 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 63F52E07F2; Thu, 29 Apr 2010 16:36:13 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100429233613.63F52E07F2@rfc-editor.org> Date: Thu, 29 Apr 2010 16:36:13 -0700 (PDT) Cc: behave@ietf.org, rfc-editor@rfc-editor.org Subject: [BEHAVE] RFC 5766 on Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 23:36:27 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5766 Title: Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) Author: R. Mahy, P. Matthews, J. Rosenberg Status: Standards Track Stream: IETF Date: April 2010 Mailbox: rohan@ekabal.com, philip_matthews@magma.ca, jdrosen@jdrosen.net Pages: 67 Characters: 172112 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-behave-turn-16.txt URL: http://www.rfc-editor.org/rfc/rfc5766.txt If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. [STANDARDS TRACK] This document is a product of the Behavior Engineering for Hindrance Avoidance 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 Association Management Solutions, LLC From wwwrun@rfc-editor.org Thu Apr 29 16:37:09 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 181323A6CDA; Thu, 29 Apr 2010 16:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.603, 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 cPrloRPO1QRi; Thu, 29 Apr 2010 16:37:07 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 38D6C3A6C11; Thu, 29 Apr 2010 16:37:02 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 485A4E0803; Thu, 29 Apr 2010 16:36:49 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100429233649.485A4E0803@rfc-editor.org> Date: Thu, 29 Apr 2010 16:36:49 -0700 (PDT) Cc: behave@ietf.org, rfc-editor@rfc-editor.org Subject: [BEHAVE] RFC 5769 on Test Vectors for Session Traversal Utilities for NAT (STUN) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 23:37:09 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5769 Title: Test Vectors for Session Traversal Utilities for NAT (STUN) Author: R. Denis-Courmont Status: Informational Stream: IETF Date: April 2010 Mailbox: remi.denis-courmont@nokia.com Pages: 11 Characters: 15407 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-behave-stun-test-vectors-04.txt URL: http://www.rfc-editor.org/rfc/rfc5769.txt The Session Traversal Utilities for NAT (STUN) protocol defines several STUN attributes. The content of some of these -- FINGERPRINT, MESSAGE-INTEGRITY, and XOR-MAPPED-ADDRESS -- involve binary-logical operations (hashing, xor). This document provides test vectors for those attributes. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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 Association Management Solutions, LLC From Washam.Fan@huaweisymantec.com Thu Apr 29 18:37:50 2010 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 934D43A6358 for ; Thu, 29 Apr 2010 18:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.759 X-Spam-Level: X-Spam-Status: No, score=0.759 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDrb36dDv2J2 for ; Thu, 29 Apr 2010 18:37:49 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id AF17D3A6916 for ; Thu, 29 Apr 2010 18:37:49 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0L1O00IOR1UBU250@hstga02-in.huaweisymantec.com> for behave@ietf.org; Fri, 30 Apr 2010 09:37:23 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0L1O00C3U1UBQU10@hstml02-in.huaweisymantec.com> for behave@ietf.org; Fri, 30 Apr 2010 09:37:23 +0800 (CST) Received: from [10.27.154.72] by hstml02-in.huaweisymantec.com (mshttpd); Fri, 30 Apr 2010 09:37:23 +0800 From: WashamFan To: Dan Wing Message-id: Date: Fri, 30 Apr 2010 09:37:23 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <00d901cae7e0$b81f9ad0$38a66b80@cisco.com> References: <00d901cae7e0$b81f9ad0$38a66b80@cisco.com> Cc: behave@ietf.org Subject: Re: [BEHAVE] Section 5 in RFC5508 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 01:37:50 -0000 > > I have a confusion about hairpinned ICMP query support described > > in section 5 in rfc5508. ICMP query msg has no indication for dest > > port and the NAT should have no idea how to forward this ICMP > > query msg to the intented host behind it. Am I missing something? > > The requirement for hairpinning ICMP queries applies to "Basic NAT" > -- which is not NAPT. It says: > > REQ-7: NAT devices enforcing Basic NAT [NAT-TRAD] MUST support the > traversal of hairpinned ICMP Query sessions. All NAT devices > (i.e., Basic NAT as well as NAPT devices) MUST support the > traversal of hairpinned ICMP Error messages: > > a) When forwarding a hairpinned ICMP Error message, the NAT > device MUST translate the destination IP address of the > outer IP header to be same as the source IP address of the > embedded IP packet after the translation. > > "Basic NAT" does not change transport-layer (UDP, TCP) ports. NAPT > changes transport-layer ports. "Basic NAT" is not NAPT. > > Hope that helps, It does help, thanks. washam