From stig@venaas.com Tue Feb 1 10:39:37 2011 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 C38BA3A6FDC for ; Tue, 1 Feb 2011 10:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.406 X-Spam-Level: X-Spam-Status: No, score=-102.406 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7vNyQWQLVjx for ; Tue, 1 Feb 2011 10:39:36 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id ED7ED3A6FEC for ; Tue, 1 Feb 2011 10:39:35 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:6d71:d8d3:6654:757a] (unknown [IPv6:2001:420:4:ea0c:6d71:d8d3:6654:757a]) by ufisa.uninett.no (Postfix) with ESMTPSA id 9673A7FEF for ; Tue, 1 Feb 2011 19:42:52 +0100 (CET) Message-ID: <4D485424.1080400@venaas.com> Date: Tue, 01 Feb 2011 10:42:44 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: behave@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-01 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, 01 Feb 2011 18:39:37 -0000 Hi I have some comments on this draft. First of all I'm trying to understand the difference between this and ID.venaas-mcast46. It looks like you are doing double translation or tunneling, as opposed to a single translation, right? The main question I have, is whether you need stateful mapping and mapping lookups etc. for the 4-6-4 case (for 6-4-6 it is more useful). I understand that it buys some flexibility, but at a high cost. What are the benefits over using a /96 IPv6 prefix and just appending the IPv4 address? If you do this, then all that is needed is to learn the prefix, unless it is a well-known standardized prefix. It becomes a bit more complex for SSM of course. The proposed mapping function might work if there is a single provider between the HMAF and BMAF. If you need to traverse multiple networks, they would either need to agree on mappings and exchange state, or you need to re-translate on the networks' borders. Section 3.1 (How It Works) seems to only cover the SSM case. ASM is a bit interesting in that the BMAF will need to request mappings for the unicast addresses of the source traffic it receives. This happens without the HMAF requesting a mapping. One interesting thing to consider in this case is whether it is worth using a single (S,G') for say (S1,G) and (S2,G). Assuming that all ASM hosts joining G wants all the sources, this can reduce the amount of state and the pool of unicast addresses needed. Note that one could in fact consider doing SSM with a single (S,G') in the provider network for an ASM group G and all its sources. You may need to consider multiple BMAFs if the provider is multihomed or connects to multiple content providers. I think the mapper would determine which BMAF to use when the HMAF makes the request. Stig On 1/31/2011 12:29 PM, Tom Taylor wrote: > I added a section giving numerical examples. > > Tom T > > -------- Original Message -------- > Subject: New Version Notification for > draft-tsou-behave-translated-multicast-01 > Date: Thu, 27 Jan 2011 18:55:07 -0800 (PST) > From: IETF I-D Submission Tool > To: tom111.taylor@bell.net > CC: tena@huawei.com,cathyzhou@huawei.com,jihui@chinatelecom.com.cn > > > A new version of I-D, draft-tsou-behave-translated-multicast-01.txt has > been successfully submitted by Tom Taylor and posted to the IETF > repository. > > Filename: draft-tsou-behave-translated-multicast > Revision: 01 > Title: A Generic Approach to Multicast Translation In Support of IPv6 > Transition > Creation_date: 2011-01-28 > WG ID: Independent Submission > Number_of_pages: 12 > > Abstract: > Consider a situation which will arise in many IPv6 transition > scenarios, where Network A, to which a host is attached, supports one > IP version, but the host and Network B support a different IP > version. Suppose that the host wishes to access a multicast group > which is rooted or sourced in Network B. This document specifies a > stateful translation mechanism whereby the host can obtain its > desired access using the native multicast capabilities of Network A. > > > > > The IETF Secretariat. > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From alan.kavanagh@ericsson.com Wed Feb 2 07:38:14 2011 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 F29493A6D2D for ; Wed, 2 Feb 2011 07:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] 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 ObmiQucGC94b for ; Wed, 2 Feb 2011 07:38:13 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id DB74B3A6BA3 for ; Wed, 2 Feb 2011 07:38:12 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p12GNRYh019619; Wed, 2 Feb 2011 10:23:53 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.168]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 2 Feb 2011 10:41:28 -0500 From: Alan Kavanagh To: Mark Townsley , Dan Wing Date: Wed, 2 Feb 2011 10:41:20 -0500 Thread-Topic: [BEHAVE] naming a big NAT Thread-Index: AcvBodYLZEXh5QKNQq+CFBxiNDPePgBTbVrw Message-ID: <1B6D0317D3AD964FBF3956DEFA3524D509DB1C314E@EUSAACMS0701.eamcs.ericsson.se> References: <001301cbc1a0$14df55a0$3e9e00e0$@com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Behave WG' Subject: Re: [BEHAVE] naming a big NAT 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, 02 Feb 2011 15:38:14 -0000 +1 Given that CGN has been used in other forums it makes sense to go with this= and be consistent, hence I agree CGN makes sense. Alan=20 -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Mark Townsley Sent: January-31-11 6:51 PM To: Dan Wing Cc: 'Behave WG' Subject: Re: [BEHAVE] naming a big NAT I voted CGN. I believe I have seen this and LSN most often in various docum= ents and presentations to date. I'd rather settle on something that is alre= ady in circulation, rather than adding another acronym into the mix. In terms of LSN vs. CGN, I think the location in the network and how it is = operated is more important architecturally rather than scale per se. Also, = I wouldn't want to imply that this kind of NAT was somehow inherently scala= ble by putting that in the name. I'm sure there are at least as many different views on this as there are me= mbers on the list though. - Mark PS. Apropos as the last two /8s just went to apnic... On Feb 1, 2011, at 12:39 AM, Dan Wing wrote: > At IETF79 we were asked to run a survey on naming a big NAT. So here=20 > it is, http://www.surveymonkey.com/s/DJSB7ZM >=20 > Please vote so we can finally close this issue. >=20 > Note: Unfortunately, due to limitations of the SurveyMonkey=20 > tool, write-ins won't show up for others and if I=20 > add a write-in after the survey has started, it=20 > invalidates (destroys) all recorded tallies. >=20 > -d >=20 >=20 > _______________________________________________ > 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 remi.despres@free.fr Fri Feb 4 08:29:31 2011 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 A594A3A69C5 for ; Fri, 4 Feb 2011 08:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.134 X-Spam-Level: X-Spam-Status: No, score=-0.134 tagged_above=-999 required=5 tests=[AWL=-0.785, BAYES_50=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saa5o-CIwr-2 for ; Fri, 4 Feb 2011 08:29:31 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by core3.amsl.com (Postfix) with ESMTP id DE5763A695F for ; Fri, 4 Feb 2011 08:29:30 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2106.sfr.fr (SMTP Server) with ESMTP id F0F9270002A7 for ; Fri, 4 Feb 2011 17:32:55 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2106.sfr.fr (SMTP Server) with ESMTP id D793D70000AD for ; Fri, 4 Feb 2011 17:32:55 +0100 (CET) X-SFR-UUID: 20110204163255883.D793D70000AD@msfrf2106.sfr.fr Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1082) From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4D47ABF8.5010301@it.uc3m.es> Date: Fri, 4 Feb 2011 17:32:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <001301cbc1a0$14df55a0$3e9e00e0$@com> <4D47ABF8.5010301@it.uc3m.es> To: Behave WG X-Mailer: Apple Mail (2.1082) Subject: Re: [BEHAVE] naming a big NAT 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, 04 Feb 2011 16:29:31 -0000 Le 1 f=E9vr. 2011 =E0 07:45, marcelo bagnulo braun a =E9crit : > agree with mark +1=20 CGN is better than LSN to name a NAT whose key property is being = operated by an ISP or mobile operator. For the same purpose, LSN is confusing: - How large is a "large scale" NAT?=20 - Will a big NAT in a large private network be also called a LSN? - ...=20 Regards, RD > El 01/02/11 0:51, Mark Townsley escribi=F3: >>=20 >> In terms of LSN vs. CGN, I think the location in the network and how = it is operated is more important architecturally rather than scale per = se. Also, I wouldn't want to imply that this kind of NAT was somehow = inherently scalable by putting that in the name. From dean.willis@softarmor.com Fri Feb 4 21:54:46 2011 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 35C263A67A4 for ; Fri, 4 Feb 2011 21:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.432 X-Spam-Level: X-Spam-Status: No, score=-103.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cw9OC0r54uYe for ; Fri, 4 Feb 2011 21:54:45 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id CB7D23A657C for ; Fri, 4 Feb 2011 21:54:44 -0800 (PST) Received: by gyd12 with SMTP id 12so1338072gyd.31 for ; Fri, 04 Feb 2011 21:58:11 -0800 (PST) Received: by 10.100.107.13 with SMTP id f13mr7905136anc.159.1296885491234; Fri, 04 Feb 2011 21:58:11 -0800 (PST) Received: from [192.168.2.102] (cpe-66-25-6-220.tx.res.rr.com [66.25.6.220]) by mx.google.com with ESMTPS id f10sm1904252anh.5.2011.02.04.21.58.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Feb 2011 21:58:10 -0800 (PST) References: <001301cbc1a0$14df55a0$3e9e00e0$@com> In-Reply-To: <001301cbc1a0$14df55a0$3e9e00e0$@com> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Dean Willis Date: Fri, 4 Feb 2011 23:58:09 -0600 To: Dan Wing X-Mailer: Apple Mail (2.1082) Cc: 'Behave WG' Subject: Re: [BEHAVE] naming a big NAT 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, 05 Feb 2011 05:54:46 -0000 On Jan 31, 2011, at 5:39 PM, Dan Wing wrote: > At IETF79 we were asked to run a survey on naming a big NAT. So here = it is, > http://www.surveymonkey.com/s/DJSB7ZM >=20 Many traditions suggest that if by naming something, one might summon = it. Are you sure this is a good idea? -- Dean From dwing@cisco.com Mon Feb 7 12:52:27 2011 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 7651F3A6ECB for ; Mon, 7 Feb 2011 12:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.699 X-Spam-Level: X-Spam-Status: No, score=-107.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MANGLED_EXTNSN=2.3, 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 tAEoTMbFsHMI for ; Mon, 7 Feb 2011 12:52:24 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 456E33A69F5 for ; Mon, 7 Feb 2011 12:52:24 -0800 (PST) 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: Av0EAMHqT02rRN+J/2dsb2JhbACYLIx2c553mxKFWgSEeg Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 07 Feb 2011 20:52:29 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p17KqT72009736 for ; Mon, 7 Feb 2011 20:52:29 GMT From: "Dan Wing" To: "'Behave WG'" Date: Mon, 7 Feb 2011 12:52:28 -0800 Message-ID: <0d4c01cbc708$eee80540$ccb80fc0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvHCO6VFWqQvE7US9KmAaU/ufkRNA== Content-Language: en-us Subject: [BEHAVE] ftp64 progressing to IESG, PROTO writeup 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, 07 Feb 2011 20:52:27 -0000 Iljitsch published draft-ietf-behave-ftp64-07, which resolves the last WGLC comment regarding the LANG command (see thread beginning at http://www.ietf.org/mail-archive/web/behave/current/msg09103.html). Below is the PROTO writeup for draft-ietf-behave-ftp64-07. -d ----- (1.a) Who is the Document Shepherd for this document? draft-ietf-behave-ftp64-07 Dan Wing, dwing@cisco.com Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Yes. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has received significant review from BEHAVE. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? It was reviewed by people attending the FTPEXT2 BoF. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. IPR has been disclosed and announced to the mailing list, https://datatracker.ietf.org/ipr/search/?option=document_search&document_sea rch=draft-ietf-behave-ftp64 and there has been no discussion about this IPR declaration. (1.e) How solid is the WG consensus behind this document? Solid. Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG has a good understanding of, and agreement with, this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No such threats or appeals. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Yes. Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? The document adds new FTP commands, which extends http://www.iana.org/assignments/ftp-commands-extensions/ftp-commands-extensi ons.xhtml and the document contains an IANA Considerations section adequate for doing that. If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. Intended Status: Standards Track (1.h) Has the document split its references into normative and informative? Yes. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. All normative references are to standards-track RFCs. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? Yes. If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Yes. Are the IANA registries clearly identified? Yes. If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? The document does not create a new IANA registry. Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Yes, the ABNF passes the validator at http://www.apps.ietf.org/content/chris-newmans-abnf-validator (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document describes middlebox behavior to reduce the problem of IPv6 FTP clients connecting to IPv4 FTP servers on the Internet. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Yes, controversy around the requirements that could be made of already- deployed FTP clients and FTP servers. This text has been removed and will appear in a separate document. Document Quality Are there existing implementations of the protocol? None have been announced. Have a significant number of vendors indicated their plan to implement the specification? Yes, several vendors are actively implementing the specification. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? They are listed in the document's contributors section. If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? No such reviews were necessary. Personnel Who is the Document Shepherd for this document? Dan Wing, dwing@cisco.com Who is the Responsible Area Director? David Harrington, ietfdbh@comcast.net If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' The document doesn't require IANA experts. The Document Shepherd MUST send the Document Shepherd Write-Up to the Responsible Area Director and iesg-secretary@ietf.org together with the request to publish the document. The Document Shepherd SHOULD also send the entire Document Shepherd Write-Up to the working group mailing list. If the Document Shepherd feels that information which may prove to be sensitive, may lead to possible appeals, or is personal needs to be written up, it SHOULD be sent in direct email to the Responsible Area Director, because the Document Shepherd Write-Up is published openly in the ID Tracker. Question (1.f) of the Write-Up covers any material of this nature and specifies this more confidential handling. From dwing@cisco.com Mon Feb 7 18:04:59 2011 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 872093A7003 for ; Mon, 7 Feb 2011 18:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 xK+Qcd3r8QkX for ; Mon, 7 Feb 2011 18:04:58 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 9676D3A7002 for ; Mon, 7 Feb 2011 18:04:58 -0800 (PST) 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: Av0EAG4zUE2rR7Hu/2dsb2JhbACYMYx2c58MmxqFWgSEeg Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 08 Feb 2011 02:05:04 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p18253Qw023618 for ; Tue, 8 Feb 2011 02:05:04 GMT From: "Dan Wing" To: "'Behave WG'" References: In-Reply-To: Date: Mon, 7 Feb 2011 18:05:03 -0800 Message-ID: <00f301cbc734$99ae60c0$cd0b2240$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvBoBQNY0jcItbtSbmQXdL0gxe7wAFjvNLA Content-Language: en-us Subject: Re: [BEHAVE] naming a big NAT 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, 08 Feb 2011 02:04:59 -0000 > At IETF79 we were asked to run a survey on naming a big NAT. So here > it is, > http://www.surveymonkey.com/s/DJSB7ZM > > Please vote so we can finally close this issue. > > Note: Unfortunately, due to limitations of the SurveyMonkey > tool, write-ins won't show up for others and if I > add a write-in after the survey has started, it > invalidates (destroys) all recorded tallies. BEHAVE enjoyed 55 responses, including one from A. Nonymous. Interesting write-ins included SPAT (Service Provider nAT), GNAT (Giant NAT, pronounced the same as NAT). Ranked #1: 35 (67%) -> CGN 2: 17 (36%) -> LSN 3: 19 (42%) -> CGNat 4: 22 (53%) -> M-NAT 5: 24 (64%) -> MEN "CGN" wins. Pfew. -d From dwing@cisco.com Tue Feb 8 12:06:37 2011 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 87E313A683B for ; Tue, 8 Feb 2011 12:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 uYVA8NZ3T5m3 for ; Tue, 8 Feb 2011 12:06:36 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A9DEE3A680A for ; Tue, 8 Feb 2011 12:06:36 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIAwUU2rR7H+/2dsb2JhbACYQIx3c6FimzuCfgGCWwSEe5MV Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 08 Feb 2011 20:06:44 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p18K6hZr016713; Tue, 8 Feb 2011 20:06:44 GMT From: "Dan Wing" To: "'Behave WG'" Date: Tue, 8 Feb 2011 12:06:44 -0800 Message-ID: <03a701cbc7cb$b5af6390$210e2ab0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvHy7VS0fmviCbkT/iuyynd49+NoA== Content-Language: en-us Cc: draft-ietf-behave-lsn-requirements@tools.ietf.org Subject: [BEHAVE] LSN: bulk ports 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, 08 Feb 2011 20:06:37 -0000 Regarding Section 7.2 of draft-ietf-behave-lsn-requirements-00: "7.2. Fixed port assignment To save costs for storage, one can adopt this port assignment mechanism at LSN. By fixing the range of external port per user/CPE, and having the mapping of internal IP address to external IP address and port, there will be no need to store per session log. Note that this mechanism is possible only if the source port is known as well as the source address, the destination address and the destination port." The text in the I-D needs more detail. There is a range of things a CGN can do: 1. for every outgoing connection, create one mapping. 2. for an outgoing connection, create a "bin" of several mappings using random public ports. Subsequent outgoing connections will use ports from the "bin". When the "bin" is full, a new connection causes a new bin to be created. A bin is smaller or equal to the user's maximum port limit. 3. Same as (2), but the ports allocated to a "bin" are consecutive public ports. I have seen both (2) and (3) described as "bulk port allocation". But they are different. With the above three design (or configuration) decisions, there are at least four axis to consider: port utilization scaling, logging scaling (which is the subject of draft-ietf-behave-lsn-requirements-00's Section 7.2), security, and port re-use. All three should be discussed in a subsequent version of draft-ietf-behave-lsn-requirements: * Port Utilization Scaling: The mechanisms at the top of the list are very efficient in their port utilization. In that sense, they have good scaling properties (nothing is wasted). The mechanisms at the bottom of the list will waste ports. The number of wasted ports is proportional to size of the "bin". * Logging Scaling: Mechanism (1) logs destinations. Mechanisms (2) and (3) log only the source port. Mechanism (2) creates a slightly larger log (listing all of the port numbers) whereas (3) could indicate a range (e.g., "12000-12009") that is quite compact. Mechanism (1) creates a lot of log entries. Mechanism (2) and (3) create the same number of log entries, but (3)'s log entries are smaller because a range can be expressed very compactly. With large "bin" sizes, the logging for mechanisms (2) and (3) can approach the logging frequency of DHCP servers. However, mechanism (2) and (3) REQUIRE SERVERS ON THE INTERNET TO LOG SOURCE PORTS. If we suggest that CGN's do any sort of bulk port allocation (2) or (3), it is important to discuss the need for content servers to implement draft-ietf-intarea-server-logging-recommendations. By content servers, this means any server that might ask (or demand) the ISP disclose the identity of a subscriber that made a certain connection to a server running HTTP, HTTPS, ssh, IMAP, IMAPS, SMTP, etc. * Security: Mechanisms (1) and (2) provide very good security in that ports numbers are not easily guessed. Easily guessed port numbers put subscribers at risk of the attacks described in RFC6056 (it cites RFC5927, RFC4953, and Paul Watson's "Slipping in the Window: TCP Reset Attacks"). Mechanism (3) provides poor security to subscribers, especially if the "bin" size is large. * Port Re-Use: It should also be discussed in the CGN Requirements document if a CGNis allowed or prohibited from re-using a port that was previously assigned to the same internal host. For example, if an internal host is mapped to a certain port and then finishes using that port (e.g., with a proper FIN/FINACK/ACK handshake, TCP RST, or it simply times out due to inactivity), and after that port's TIME_WAIT-like delay has expired, can the NAT re-use the port for a new connection. This decision has impacts on port utilization scaling, logging scaling, and security. -d From mohamed.boucadair@orange-ftgroup.com Wed Feb 9 01:23:01 2011 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 F3DC83A695A for ; Wed, 9 Feb 2011 01:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjNLHPdQ41rg for ; Wed, 9 Feb 2011 01:23:00 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id C44813A6956 for ; Wed, 9 Feb 2011 01:22:59 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id C6D9022C5D2; Wed, 9 Feb 2011 10:23:07 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id ACE1223804B; Wed, 9 Feb 2011 10:23:07 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Wed, 9 Feb 2011 10:23:07 +0100 From: To: "'behave' (behave@ietf.org)" Date: Wed, 9 Feb 2011 10:23:06 +0100 Thread-Topic: Updated version of multicast IPv4-embedded address format I-D Thread-Index: Acu9cHBneN2ztU/fSxuIgnLcbf2nrAABxBdwArCDtxA= Message-ID: <10008_1297243387_4D525CFB_10008_51567_1_94C682931C08B048B7A8645303FDC9F33C44016417@PUEXCB1B.nanterre.francetelecom.fr> References: <3056_1294231762_4D2468D2_3056_328146_1_94C682931C08B048B7A8645303FDC9F33C3E9FD8EC@PUEXCB1B.nanterre.francetelecom.fr> <4D29657C.5050804@cernet.edu.cn> <109202.91767.qm@web111415.mail.gq1.yahoo.com> <4D3A76EB.2030806@cernet.edu.cn> <283593.42539.qm@web111412.mail.gq1.yahoo.com> <008a01cbbcf8$a696e7d0$f3c4b770$@com> <197335.19755.qm@web111406.mail.gq1.yahoo.com> <020101cbbd77$a8a53bb0$f9efb310$@com> In-Reply-To: <020101cbbd77$a8a53bb0$f9efb310$@com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.2.9.90322 Cc: "draft-boucadair-behave-64-multicast-address-format@tools.ietf.org" Subject: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D 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, 09 Feb 2011 09:23:01 -0000 Dear all, Together with Jacni, Yiu, Stig, Xing, and Mingwei we worked on an updated v= ersion of the multicast IPv4-embedded address format I-D: http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-form= at-01 We still have some discussion points, e.g.- whether we allow or not ASM IPv= 4=3D=3D>SSM IPv6, SSM IPv4=3D=3D>ASM IPv6. The current text says we should = not but we still need to assess whether there are valid use cases for relax= ing this. Cheers, Med ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From stig@venaas.com Wed Feb 9 10:28:59 2011 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 9DE223A6866 for ; Wed, 9 Feb 2011 10:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZbdpqGFV90L for ; Wed, 9 Feb 2011 10:28:57 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id E7B2B3A67F7 for ; Wed, 9 Feb 2011 10:28:56 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:f804:ac61:4e74:99ff] (unknown [IPv6:2001:420:4:ea0c:f804:ac61:4e74:99ff]) by ufisa.uninett.no (Postfix) with ESMTPSA id 068A2800A for ; Wed, 9 Feb 2011 19:29:05 +0100 (CET) Message-ID: <4D52DCEE.6080808@venaas.com> Date: Wed, 09 Feb 2011 10:29:02 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "'behave' (behave@ietf.org)" References: <3056_1294231762_4D2468D2_3056_328146_1_94C682931C08B048B7A8645303FDC9F33C3E9FD8EC@PUEXCB1B.nanterre.francetelecom.fr> <4D29657C.5050804@cernet.edu.cn> <109202.91767.qm@web111415.mail.gq1.yahoo.com> <4D3A76EB.2030806@cernet.edu.cn> <283593.42539.qm@web111412.mail.gq1.yahoo.com> <008a01cbbcf8$a696e7d0$f3c4b770$@com> <197335.19755.qm@web111406.mail.gq1.yahoo.com> <020101cbbd77$a8a53bb0$f9efb310$@com> <10008_1297243387_4D525CFB_10008_51567_1_94C682931C08B048B7A8645303FDC9F33C44016417@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <10008_1297243387_4D525CFB_10008_51567_1_94C682931C08B048B7A8645303FDC9F33C44016417@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D 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, 09 Feb 2011 18:28:59 -0000 On 2/9/2011 1:23 AM, mohamed.boucadair@orange-ftgroup.com wrote: > Dear all, > > Together with Jacni, Yiu, Stig, Xing, and Mingwei we worked on an updated version of the multicast IPv4-embedded address format I-D: > > http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-format-01 > > We still have some discussion points, e.g.- whether we allow or not ASM IPv4==>SSM IPv6, SSM IPv4==>ASM IPv6. The current text says we should not but we still need to assess whether there are valid use cases for relaxing this. My opinion is that there should be no restrictions on this. This embedding in itself should be very generic, and we may not know what uses people may come up with. If we standardize mechanisms making use of this embedding, then those may have restrictions. Let me try to describe a scenario where I can see a use for mixing ASM and SSM. Let us consider an IPv6 SSM-only network receiving IPv4 ASM multicast from an IPv4 network. Assuming that the relevant IPv4 groups have a single source each (which is fairly common), you can have a translator with a fixed IPv6 unicast address used for sending translated IPv4 multicast, call it S6. In the IPv6 network, for each IPv4 group G4, you take the translators address S6 and use the IPv4-embedded multicast format to construct say G6 = embed(G4). So the receivers in the IPv6 network use SSM to join (S6,G6). This reaches the translator, which then knows it should join G4 (the last 32 bits of G6). If there are multiple sources sending to G4, this may still work for e.g. RTP. Basically if the translator receives packets from S4 and S4', they could both be translated to (S6,G6). The RTP header is sufficient for the receiver to distinguish the streams. Stig From jacniq@gmail.com Wed Feb 9 22:54:40 2011 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 210F83A68CB for ; Wed, 9 Feb 2011 22:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kb-0y-YCCKh4 for ; Wed, 9 Feb 2011 22:54:06 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 8F3883A68D3 for ; Wed, 9 Feb 2011 22:53:55 -0800 (PST) Received: by ywk9 with SMTP id 9so500322ywk.31 for ; Wed, 09 Feb 2011 22:54:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BMZL3vdopJQShYLOiE409maZtAFsJxnEA46noIEVB/I=; b=r2/Ho+gQN5YVsk0eh4w64DnMrl4spSCKNM2V8CnN6nIzoNOb+zPzOQr8e85nPClZKp Ha5+vDWNHxthQ+Oyi7mzxlH3awsUG/n4GbYjxrcvm/0JZgRJJcDhcZejCCIY0e7kTGLv 12cxPR6wXw3X/Gv0WdDvN7C/qSOhyJESDS66k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=olzWyEGd54nF20+Yo+6VpOSgnhLAYf8mLceqz6O3wvaJ9xoPqEnFwVcjNcSPWzMP+f yIOtHIZvvrlyvkmAiAvvqy7irs8n0Ca5GvU69zKLhOcs93RbxT1XgAb5UMdzEvwCWlHM G1dj5DFYHs3GQYgowppq0d/iv0xMVNlCrWHBo= MIME-Version: 1.0 Received: by 10.151.12.18 with SMTP id p18mr1442982ybi.192.1297320841223; Wed, 09 Feb 2011 22:54:01 -0800 (PST) Received: by 10.147.82.18 with HTTP; Wed, 9 Feb 2011 22:54:01 -0800 (PST) In-Reply-To: <4D52DCEE.6080808@venaas.com> References: <3056_1294231762_4D2468D2_3056_328146_1_94C682931C08B048B7A8645303FDC9F33C3E9FD8EC@PUEXCB1B.nanterre.francetelecom.fr> <4D29657C.5050804@cernet.edu.cn> <109202.91767.qm@web111415.mail.gq1.yahoo.com> <4D3A76EB.2030806@cernet.edu.cn> <283593.42539.qm@web111412.mail.gq1.yahoo.com> <008a01cbbcf8$a696e7d0$f3c4b770$@com> <197335.19755.qm@web111406.mail.gq1.yahoo.com> <020101cbbd77$a8a53bb0$f9efb310$@com> <10008_1297243387_4D525CFB_10008_51567_1_94C682931C08B048B7A8645303FDC9F33C44016417@PUEXCB1B.nanterre.francetelecom.fr> <4D52DCEE.6080808@venaas.com> Date: Thu, 10 Feb 2011 14:54:01 +0800 Message-ID: From: Jacni Qin To: Stig Venaas Content-Type: multipart/alternative; boundary=000e0cd6a972e69d5e049be80bb7 Cc: "'behave' \(behave@ietf.org\)" Subject: Re: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D 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, 10 Feb 2011 06:54:41 -0000 --000e0cd6a972e69d5e049be80bb7 Content-Type: text/plain; charset=ISO-8859-1 Dear Stig, Inline please, On Thu, Feb 10, 2011 at 2:29 AM, Stig Venaas wrote: > On 2/9/2011 1:23 AM, mohamed.boucadair@orange-ftgroup.com wrote: > >> Dear all, >> >> Together with Jacni, Yiu, Stig, Xing, and Mingwei we worked on an updated >> version of the multicast IPv4-embedded address format I-D: >> >> >> http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-format-01 >> >> We still have some discussion points, e.g.- whether we allow or not ASM >> IPv4==>SSM IPv6, SSM IPv4==>ASM IPv6. The current text says we should not >> but we still need to assess whether there are valid use cases for relaxing >> this. >> > > My opinion is that there should be no restrictions on this. This > embedding in itself should be very generic, and we may not know > what uses people may come up with. If we standardize mechanisms > making use of this embedding, then those may have restrictions. > > Let me try to describe a scenario where I can see a use for mixing > ASM and SSM. > > Let us consider an IPv6 SSM-only network receiving IPv4 ASM > multicast from an IPv4 network. > Jacni>: I understand your case and elaboration below, while I'm a little concerned by the "SSM-Only network". Is it not capable of ASM indeed, or just restricted by deployment policies? Anyway, if the ASM mode is supported, I'd rather pick one ASM_MPREFIX64 to map the IPv4 ASM multicast, and avoid the complexity. Even there are native SSM receivers, it is not difficult to be compatible with ASM, right? Cheers, Jacni > Assuming that the relevant IPv4 groups have a single source > each (which is fairly common), you can have a translator > with a fixed IPv6 unicast address used for sending translated > IPv4 multicast, call it S6. > > In the IPv6 network, for each IPv4 group G4, you take the > translators address S6 and use the IPv4-embedded multicast > format to construct say G6 = embed(G4). So the receivers > in the IPv6 network use SSM to join (S6,G6). This reaches > the translator, which then knows it should join G4 (the > last 32 bits of G6). > > If there are multiple sources sending to G4, this may > still work for e.g. RTP. Basically if the translator > receives packets from S4 and S4', they could both be > translated to (S6,G6). The RTP header is sufficient for > the receiver to distinguish the streams. > > Stig > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > --000e0cd6a972e69d5e049be80bb7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Stig,

Inline please,

On Thu, Feb 10, 2011 at 2:29 AM, Stig Vena= as <stig@venaas.com= > wrote:
On 2/9/2011 1:23 AM, mohamed.boucadair@orange-ftgroup.com wrote:
Dear all,

Together with Jacni, Yiu, Stig, Xing, and Mingwei we worked on an updated v= ersion of the =A0multicast IPv4-embedded address format I-D:

http://tools.ietf.org/html/draft-boucad= air-behave-64-multicast-address-format-01

We still have some discussion points, e.g.- whether we allow or not ASM IPv= 4=3D=3D>SSM IPv6, SSM IPv4=3D=3D>ASM IPv6. The current text says we s= hould not but we still need to assess whether there are valid use cases for= relaxing this.

My opinion is that there should be no restrictions on this. This
embedding in itself should be very generic, and we may not know
what uses people may come up with. If we standardize mechanisms
making use of this embedding, then those may have restrictions.

Let me try to describe a scenario where I can see a use for mixing
ASM and SSM.

Let us consider an IPv6 SSM-only network receiving IPv4 ASM
multicast from an IPv4 network.

Jacni>: I understand your case and elaboration below, wh= ile I'm a little concerned by the "SSM-Only network".
Is i= t not capable of ASM indeed, or just restricted by deployment policies?
Anyway, if the ASM mode is supported, I'd rather pick one ASM_MPREFIX64= to map the IPv4 ASM multicast, and avoid the complexity. Even there are na= tive SSM receivers, it is not difficult to be compatible with ASM, right?

Cheers,
Jacni


Assuming that the relevant IPv4 groups have a single source
each (which is fairly common), you can have a translator
with a fixed IPv6 unicast address used for sending translated
IPv4 multicast, call it S6.

In the IPv6 network, for each IPv4 group G4, you take the
translators address S6 and use the IPv4-embedded multicast
format to construct say G6 =3D embed(G4). So the receivers
in the IPv6 network use SSM to join (S6,G6). This reaches
the translator, which then knows it should join G4 (the
last 32 bits of G6).

If there are multiple sources sending to G4, this may
still work for e.g. RTP. Basically if the translator
receives packets from S4 and S4', they could both be
translated to (S6,G6). The RTP header is sufficient for
the receiver to distinguish the streams.

Stig

_______________________________________________
Behave mailing list
Behave@ietf.org = https://www.ietf.org/mailman/listinfo/behave

--000e0cd6a972e69d5e049be80bb7-- From mohamed.boucadair@orange-ftgroup.com Wed Feb 9 23:04:56 2011 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 A54C03A685D for ; Wed, 9 Feb 2011 23:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_BACKHAIR_33=1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u00BITcOSEKo for ; Wed, 9 Feb 2011 23:04:55 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 237093A68B1 for ; Wed, 9 Feb 2011 23:04:55 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 880243B44F0; Thu, 10 Feb 2011 08:05:05 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 700DEC8047; Thu, 10 Feb 2011 08:05:05 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Thu, 10 Feb 2011 08:05:05 +0100 From: To: Stig Venaas , "'behave' (behave@ietf.org)" Date: Thu, 10 Feb 2011 08:05:03 +0100 Thread-Topic: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D Thread-Index: AcvIh0GUvY+XLBvDQZCJeOXMc0IpVQAZq/6A Message-ID: <12275_1297321505_4D538E21_12275_111140_1_94C682931C08B048B7A8645303FDC9F33C443B8A6B@PUEXCB1B.nanterre.francetelecom.fr> References: <3056_1294231762_4D2468D2_3056_328146_1_94C682931C08B048B7A8645303FDC9F33C3E9FD8EC@PUEXCB1B.nanterre.francetelecom.fr> <4D29657C.5050804@cernet.edu.cn> <109202.91767.qm@web111415.mail.gq1.yahoo.com> <4D3A76EB.2030806@cernet.edu.cn> <283593.42539.qm@web111412.mail.gq1.yahoo.com> <008a01cbbcf8$a696e7d0$f3c4b770$@com> <197335.19755.qm@web111406.mail.gq1.yahoo.com> <020101cbbd77$a8a53bb0$f9efb310$@com> <10008_1297243387_4D525CFB_10008_51567_1_94C682931C08B048B7A8645303FDC9F33C44016417@PUEXCB1B.nanterre.francetelecom.fr> <4D52DCEE.6080808@venaas.com> In-Reply-To: <4D52DCEE.6080808@venaas.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.2.10.61521 Subject: Re: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D 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, 10 Feb 2011 07:04:56 -0000 Hi Stig, I see your scenario even if I would check first whether it is feasible or n= ot to use ASM in the IPv6 side.=20 In my context, I don't have such scenario because we are using SSM mode (fo= r the delivery of IPTV). In the scenario you described, ** no ** address synthesis of the IPv6 sour= ce addresses is allowed in the receiver side. S6 should be notified somehow= to the receivers. The 64 interconnection function should not use RFC6052 f= or to represent the IPv4 source in the IPv6 domain. It is possible to relax the constraint of mapping ASM<=3D>SSM by providing = some guidelines to the IPv4-IPv6 interconnection function and to the receiv= er such as: * When SSM_PREFIX64 and ASM_PREFIX64 are configured, only ASM<=3D>ASM and S= SM<=3D>SSM synthesis are allowed. * If only one MPREFIX64 is provisioned to the interconnection function, bot= h ASM and SSM @es ca ne be mapped using MPREFIX64; still the interconnectio= n function need to be configured with the source IPv6 address to use or rel= y on RFC6052.=20 I don't know if this adds more complexity or not.=20 Cheers, Med -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Stig Venaas Envoy=E9 : mercredi 9 f=E9vrier 2011 19:29 =C0 : 'behave' (behave@ietf.org) Objet : Re: [BEHAVE] Updated version of multicast IPv4-embedded address for= mat I-D On 2/9/2011 1:23 AM, mohamed.boucadair@orange-ftgroup.com wrote: > Dear all, > > Together with Jacni, Yiu, Stig, Xing, and Mingwei we worked on an updated= version of the multicast IPv4-embedded address format I-D: > > http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-fo= rmat-01 > > We still have some discussion points, e.g.- whether we allow or not ASM I= Pv4=3D=3D>SSM IPv6, SSM IPv4=3D=3D>ASM IPv6. The current text says we shoul= d not but we still need to assess whether there are valid use cases for rel= axing this. My opinion is that there should be no restrictions on this. This embedding in itself should be very generic, and we may not know what uses people may come up with. If we standardize mechanisms making use of this embedding, then those may have restrictions. Let me try to describe a scenario where I can see a use for mixing ASM and SSM. Let us consider an IPv6 SSM-only network receiving IPv4 ASM multicast from an IPv4 network. Assuming that the relevant IPv4 groups have a single source each (which is fairly common), you can have a translator with a fixed IPv6 unicast address used for sending translated IPv4 multicast, call it S6. In the IPv6 network, for each IPv4 group G4, you take the translators address S6 and use the IPv4-embedded multicast format to construct say G6 =3D embed(G4). So the receivers in the IPv6 network use SSM to join (S6,G6). This reaches the translator, which then knows it should join G4 (the last 32 bits of G6). If there are multiple sources sending to G4, this may still work for e.g. RTP. Basically if the translator receives packets from S4 and S4', they could both be translated to (S6,G6). The RTP header is sufficient for the receiver to distinguish the streams. Stig _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From yiu_lee@cable.comcast.com Thu Feb 10 12:33:42 2011 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 42FC43A6833 for ; Thu, 10 Feb 2011 12:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.735 X-Spam-Level: X-Spam-Status: No, score=-100.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_BACKHAIR_55=1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rZd+VyKFjPd for ; Thu, 10 Feb 2011 12:33:41 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 56F9B3A67D1 for ; Thu, 10 Feb 2011 12:33:41 -0800 (PST) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.25398542; Thu, 10 Feb 2011 13:45:09 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Thu, 10 Feb 2011 15:33:52 -0500 From: "Lee, Yiu" To: Stig Venaas , "'behave' (behave@ietf.org)" Thread-Topic: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D Thread-Index: AQHLyWHUR1+AkoaUSkuG9oYHZxMYhQ== Date: Thu, 10 Feb 2011 20:33:51 +0000 Message-ID: In-Reply-To: <4D52DCEE.6080808@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.11] Content-Type: text/plain; charset="us-ascii" Content-ID: <5A9EDA699A4C9D44A367CB72DA62D9EC@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D 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, 10 Feb 2011 20:33:42 -0000 Hi Stig, I read Jacni and Med's replies. In your scenario, the IX function must be configured to know what PREFIX to be used for the SSMv6<=3D=3D>ASMv4 translation. AFAIK, this can be done by the IPv6-embedded address format, no new requirement is required. However, this will complicate the IX implementation which is beyond the discussion of this draft. Cheers, /Yiu On 2/9/11 1:29 PM, "Stig Venaas" wrote: >On 2/9/2011 1:23 AM, mohamed.boucadair@orange-ftgroup.com wrote: >> Dear all, >> >> Together with Jacni, Yiu, Stig, Xing, and Mingwei we worked on an >>updated version of the multicast IPv4-embedded address format I-D: >> >>=20 >>http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-fo >>rmat-01 >> >> We still have some discussion points, e.g.- whether we allow or not ASM >>IPv4=3D=3D>SSM IPv6, SSM IPv4=3D=3D>ASM IPv6. The current text says we sh= ould >>not but we still need to assess whether there are valid use cases for >>relaxing this. > >My opinion is that there should be no restrictions on this. This >embedding in itself should be very generic, and we may not know >what uses people may come up with. If we standardize mechanisms >making use of this embedding, then those may have restrictions. > >Let me try to describe a scenario where I can see a use for mixing >ASM and SSM. > >Let us consider an IPv6 SSM-only network receiving IPv4 ASM >multicast from an IPv4 network. > >Assuming that the relevant IPv4 groups have a single source >each (which is fairly common), you can have a translator >with a fixed IPv6 unicast address used for sending translated >IPv4 multicast, call it S6. > >In the IPv6 network, for each IPv4 group G4, you take the >translators address S6 and use the IPv4-embedded multicast >format to construct say G6 =3D embed(G4). So the receivers >in the IPv6 network use SSM to join (S6,G6). This reaches >the translator, which then knows it should join G4 (the >last 32 bits of G6). > >If there are multiple sources sending to G4, this may >still work for e.g. RTP. Basically if the translator >receives packets from S4 and S4', they could both be >translated to (S6,G6). The RTP header is sufficient for >the receiver to distinguish the streams. > >Stig >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From stig@venaas.com Thu Feb 10 13:15:18 2011 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 160433A6838 for ; Thu, 10 Feb 2011 13:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.983 X-Spam-Level: X-Spam-Status: No, score=-101.983 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, J_BACKHAIR_55=1, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfYntEAu4C1D for ; Thu, 10 Feb 2011 13:15:17 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id C3EA43A67B8 for ; Thu, 10 Feb 2011 13:15:16 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:8560:7a13:4656:69ee] (unknown [IPv6:2001:420:4:ea0c:8560:7a13:4656:69ee]) by ufisa.uninett.no (Postfix) with ESMTPSA id 915D78031; Thu, 10 Feb 2011 22:15:27 +0100 (CET) Message-ID: <4D54556D.80407@venaas.com> Date: Thu, 10 Feb 2011 13:15:25 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Lee, Yiu" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'behave' \(behave@ietf.org\)" Subject: Re: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D 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, 10 Feb 2011 21:15:18 -0000 On 2/10/2011 12:33 PM, Lee, Yiu wrote: > Hi Stig, > > I read Jacni and Med's replies. In your scenario, the IX function must be > configured to know what PREFIX to be used for the SSMv6<==>ASMv4 > translation. AFAIK, this can be done by the IPv6-embedded address format, > no new requirement is required. However, this will complicate the IX > implementation which is beyond the discussion of this draft. Let me try to answer all the replies I've seen. I'm not sure if my scenario is a good one, and maybe the IPv6 site should support ASM, but if someone wants to do something like this, then it is bad if we make it illegal. I would like this format to be generic and support all the different cases where you may want to embed an IPv4 multicast address in an IPv6 multicast address. If we restrict the usage, then it must be for a good reason. If some use case or implementation only accepts ASM in ASM, then they can check the address and discard it if say SSM in ASM. Can you guys provide examples or reasons for restricting it? I will also try to think about reasons both for and against, Stig > Cheers, > /Yiu > > > On 2/9/11 1:29 PM, "Stig Venaas" wrote: > >> On 2/9/2011 1:23 AM, mohamed.boucadair@orange-ftgroup.com wrote: >>> Dear all, >>> >>> Together with Jacni, Yiu, Stig, Xing, and Mingwei we worked on an >>> updated version of the multicast IPv4-embedded address format I-D: >>> >>> >>> http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-fo >>> rmat-01 >>> >>> We still have some discussion points, e.g.- whether we allow or not ASM >>> IPv4==>SSM IPv6, SSM IPv4==>ASM IPv6. The current text says we should >>> not but we still need to assess whether there are valid use cases for >>> relaxing this. >> >> My opinion is that there should be no restrictions on this. This >> embedding in itself should be very generic, and we may not know >> what uses people may come up with. If we standardize mechanisms >> making use of this embedding, then those may have restrictions. >> >> Let me try to describe a scenario where I can see a use for mixing >> ASM and SSM. >> >> Let us consider an IPv6 SSM-only network receiving IPv4 ASM >> multicast from an IPv4 network. >> >> Assuming that the relevant IPv4 groups have a single source >> each (which is fairly common), you can have a translator >> with a fixed IPv6 unicast address used for sending translated >> IPv4 multicast, call it S6. >> >> In the IPv6 network, for each IPv4 group G4, you take the >> translators address S6 and use the IPv4-embedded multicast >> format to construct say G6 = embed(G4). So the receivers >> in the IPv6 network use SSM to join (S6,G6). This reaches >> the translator, which then knows it should join G4 (the >> last 32 bits of G6). >> >> If there are multiple sources sending to G4, this may >> still work for e.g. RTP. Basically if the translator >> receives packets from S4 and S4', they could both be >> translated to (S6,G6). The RTP header is sufficient for >> the receiver to distinguish the streams. >> >> Stig >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave From mohamed.boucadair@orange-ftgroup.com Fri Feb 11 05:00:23 2011 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 24A813A67D4 for ; Fri, 11 Feb 2011 05:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.123 X-Spam-Level: X-Spam-Status: No, score=-1.123 tagged_above=-999 required=5 tests=[AWL=-0.875, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_BACKHAIR_33=1, J_BACKHAIR_55=1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUZ0zd878ylj for ; Fri, 11 Feb 2011 05:00:22 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id C98A83A681D for ; Fri, 11 Feb 2011 05:00:21 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 32AFF190688; Fri, 11 Feb 2011 14:00:36 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 0561738403A; Fri, 11 Feb 2011 14:00:36 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Fri, 11 Feb 2011 14:00:35 +0100 From: To: Stig Venaas , "Lee, Yiu" Date: Fri, 11 Feb 2011 14:00:34 +0100 Thread-Topic: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D Thread-Index: AcvJZ6iZYdn30Yq2TwqPQakP1xzLtwAg303Q Message-ID: <31963_1297429236_4D5532F4_31963_381209_1_94C682931C08B048B7A8645303FDC9F33C443B9265@PUEXCB1B.nanterre.francetelecom.fr> References: <4D54556D.80407@venaas.com> In-Reply-To: <4D54556D.80407@venaas.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.2.11.123319 Cc: "'behave' \(behave@ietf.org\)" Subject: Re: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D 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, 11 Feb 2011 13:00:23 -0000 Hi Stig, I don't have a strong opposition to relax it. My point is if we want to all= ow ASM<=3D=3D>SSM, we need to describe the implications of such choice. I p= rovided an example of the provisioning of the MPREFIX64 and also the impact= on the discovery of the source IPv6 address. Cheers, Med=20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Stig Venaas Envoy=E9 : jeudi 10 f=E9vrier 2011 22:15 =C0 : Lee, Yiu Cc : 'behave' (behave@ietf.org) Objet : Re: [BEHAVE] Updated version of multicast IPv4-embedded address for= mat I-D On 2/10/2011 12:33 PM, Lee, Yiu wrote: > Hi Stig, > > I read Jacni and Med's replies. In your scenario, the IX function must be > configured to know what PREFIX to be used for the SSMv6<=3D=3D>ASMv4 > translation. AFAIK, this can be done by the IPv6-embedded address format, > no new requirement is required. However, this will complicate the IX > implementation which is beyond the discussion of this draft. Let me try to answer all the replies I've seen. I'm not sure if my scenario is a good one, and maybe the IPv6 site should support ASM, but if someone wants to do something like this, then it is bad if we make it illegal. I would like this format to be generic and support all the different cases where you may want to embed an IPv4 multicast address in an IPv6 multicast address. If we restrict the usage, then it must be for a good reason. If some use case or implementation only accepts ASM in ASM, then they can check the address and discard it if say SSM in ASM. Can you guys provide examples or reasons for restricting it? I will also try to think about reasons both for and against, Stig > Cheers, > /Yiu > > > On 2/9/11 1:29 PM, "Stig Venaas" wrote: > >> On 2/9/2011 1:23 AM, mohamed.boucadair@orange-ftgroup.com wrote: >>> Dear all, >>> >>> Together with Jacni, Yiu, Stig, Xing, and Mingwei we worked on an >>> updated version of the multicast IPv4-embedded address format I-D: >>> >>> >>> http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-= fo >>> rmat-01 >>> >>> We still have some discussion points, e.g.- whether we allow or not ASM >>> IPv4=3D=3D>SSM IPv6, SSM IPv4=3D=3D>ASM IPv6. The current text says we = should >>> not but we still need to assess whether there are valid use cases for >>> relaxing this. >> >> My opinion is that there should be no restrictions on this. This >> embedding in itself should be very generic, and we may not know >> what uses people may come up with. If we standardize mechanisms >> making use of this embedding, then those may have restrictions. >> >> Let me try to describe a scenario where I can see a use for mixing >> ASM and SSM. >> >> Let us consider an IPv6 SSM-only network receiving IPv4 ASM >> multicast from an IPv4 network. >> >> Assuming that the relevant IPv4 groups have a single source >> each (which is fairly common), you can have a translator >> with a fixed IPv6 unicast address used for sending translated >> IPv4 multicast, call it S6. >> >> In the IPv6 network, for each IPv4 group G4, you take the >> translators address S6 and use the IPv4-embedded multicast >> format to construct say G6 =3D embed(G4). So the receivers >> in the IPv6 network use SSM to join (S6,G6). This reaches >> the translator, which then knows it should join G4 (the >> last 32 bits of G6). >> >> If there are multiple sources sending to G4, this may >> still work for e.g. RTP. Basically if the translator >> receives packets from S4 and S4', they could both be >> translated to (S6,G6). The RTP header is sufficient for >> the receiver to distinguish the streams. >> >> Stig >> _______________________________________________ >> 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 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From xing@cernet.edu.cn Fri Feb 11 23:11:28 2011 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 E83373A6894 for ; Fri, 11 Feb 2011 23:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.903 X-Spam-Level: X-Spam-Status: No, score=-98.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696, J_BACKHAIR_55=1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1U-aeqia94S9 for ; Fri, 11 Feb 2011 23:11:26 -0800 (PST) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by core3.amsl.com (Postfix) with SMTP id 20EB73A6895 for ; Fri, 11 Feb 2011 23:11:25 -0800 (PST) Received: from [192.168.1.101]([220.174.81.97]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm74d565453; Sat, 12 Feb 2011 15:11:41 +0800 Message-ID: <4D5632BF.1020700@cernet.edu.cn> Date: Sat, 12 Feb 2011 15:11:59 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Stig Venaas References: <4D54556D.80407@venaas.com> In-Reply-To: <4D54556D.80407@venaas.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: xctdJoZB Cc: "'behave' \(behave@ietf.org\)" , "Lee, Yiu" Subject: Re: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D 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, 12 Feb 2011 07:11:29 -0000 于 2011-2-11 5:15, Stig Venaas 写é“: > On 2/10/2011 12:33 PM, Lee, Yiu wrote: >> Hi Stig, >> >> I read Jacni and Med's replies. In your scenario, the IX function >> must be >> configured to know what PREFIX to be used for the SSMv6<==>ASMv4 >> translation. AFAIK, this can be done by the IPv6-embedded address >> format, >> no new requirement is required. However, this will complicate the IX >> implementation which is beyond the discussion of this draft. > > Let me try to answer all the replies I've seen. > > I'm not sure if my scenario is a good one, and maybe the IPv6 > site should support ASM, but if someone wants to do something > like this, then it is bad if we make it illegal. The CERNET2 IPv6-only backbone is an example, which provides IPv6 unicast and SSM services. The customer's ASM application is provided cross SSM backbone. > > I would like this format to be generic and support all the > different cases where you may want to embed an IPv4 multicast > address in an IPv6 multicast address. Agree. Since we are talking about IPv4/IPv6 interaction, if we believe there will be IPv6-only Internet in the future, we should define as little as possible in the transition and coexistent time. Regards, xing > > If we restrict the usage, then it must be for a good reason. > If some use case or implementation only accepts ASM in ASM, then > they can check the address and discard it if say SSM in ASM. > > Can you guys provide examples or reasons for restricting it? > I will also try to think about reasons both for and against, > > Stig > >> Cheers, >> /Yiu >> >> >> On 2/9/11 1:29 PM, "Stig Venaas" wrote: >> >>> On 2/9/2011 1:23 AM, mohamed.boucadair@orange-ftgroup.com wrote: >>>> Dear all, >>>> >>>> Together with Jacni, Yiu, Stig, Xing, and Mingwei we worked on an >>>> updated version of the multicast IPv4-embedded address format I-D: >>>> >>>> >>>> http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-fo >>>> >>>> rmat-01 >>>> >>>> We still have some discussion points, e.g.- whether we allow or not >>>> ASM >>>> IPv4==>SSM IPv6, SSM IPv4==>ASM IPv6. The current text says we should >>>> not but we still need to assess whether there are valid use cases for >>>> relaxing this. >>> >>> My opinion is that there should be no restrictions on this. This >>> embedding in itself should be very generic, and we may not know >>> what uses people may come up with. If we standardize mechanisms >>> making use of this embedding, then those may have restrictions. >>> >>> Let me try to describe a scenario where I can see a use for mixing >>> ASM and SSM. >>> >>> Let us consider an IPv6 SSM-only network receiving IPv4 ASM >>> multicast from an IPv4 network. >>> >>> Assuming that the relevant IPv4 groups have a single source >>> each (which is fairly common), you can have a translator >>> with a fixed IPv6 unicast address used for sending translated >>> IPv4 multicast, call it S6. >>> >>> In the IPv6 network, for each IPv4 group G4, you take the >>> translators address S6 and use the IPv4-embedded multicast >>> format to construct say G6 = embed(G4). So the receivers >>> in the IPv6 network use SSM to join (S6,G6). This reaches >>> the translator, which then knows it should join G4 (the >>> last 32 bits of G6). >>> >>> If there are multiple sources sending to G4, this may >>> still work for e.g. RTP. Basically if the translator >>> receives packets from S4 and S4', they could both be >>> translated to (S6,G6). The RTP header is sufficient for >>> the receiver to distinguish the streams. >>> >>> Stig >>> _______________________________________________ >>> 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 yiu_lee@cable.comcast.com Mon Feb 14 07:09:48 2011 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 584003A6D45 for ; Mon, 14 Feb 2011 07:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.735 X-Spam-Level: X-Spam-Status: No, score=-100.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_BACKHAIR_55=1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIx5LXCGK0u1 for ; Mon, 14 Feb 2011 07:09:47 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 669683A6B77 for ; Mon, 14 Feb 2011 07:09:47 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.25730825; Mon, 14 Feb 2011 08:18:45 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Mon, 14 Feb 2011 10:07:23 -0500 From: "Lee, Yiu" To: Xing Li , Stig Venaas Thread-Topic: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D Thread-Index: AQHLzFjhA1euEMNBV0ymmJE/kh1KjQ== Date: Mon, 14 Feb 2011 15:07:22 +0000 Message-ID: In-Reply-To: <4D5632BF.1020700@cernet.edu.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.13] Content-Type: text/plain; charset="iso-2022-jp" Content-ID: <13B96960BFCF694B956F38E437BFEBE7@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'behave' \(behave@ietf.org\)" Subject: Re: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D 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, 14 Feb 2011 15:09:48 -0000 Hi Stig and Xing, I tried to answer both emails together. See inline. Cheers, Yiu On 2/12/11 2:11 AM, "Xing Li" wrote: >=1B$BP2=1B(B 2011-2-11 5:15, Stig Venaas =1B$B> On 2/10/2011 12:33 PM, Lee, Yiu wrote: >>> Hi Stig, >>> >>> I read Jacni and Med's replies. In your scenario, the IX function >>> must be >>> configured to know what PREFIX to be used for the SSMv6<=3D=3D>ASMv4 >>> translation. AFAIK, this can be done by the IPv6-embedded address >>> format, >>> no new requirement is required. However, this will complicate the IX >>> implementation which is beyond the discussion of this draft. >> >> Let me try to answer all the replies I've seen. >> >> I'm not sure if my scenario is a good one, and maybe the IPv6 >> site should support ASM, but if someone wants to do something >> like this, then it is bad if we make it illegal. > > >The CERNET2 IPv6-only backbone is an example, which provides IPv6 >unicast and SSM services. The customer's ASM application is provided >cross SSM backbone. [YL] This is a valid use case. I am just curious how the ASM-SSM translation happens. How does the translator learns the IPv6 source of the SSM? Do you provision some kind of mapping? > >> >> I would like this format to be generic and support all the >> different cases where you may want to embed an IPv4 multicast >> address in an IPv6 multicast address. > >Agree. Since we are talking about IPv4/IPv6 interaction, if we believe >there will be IPv6-only Internet in the future, we should define as >little as possible in the transition and coexistent time. > [YL] I also agreed. > >> >> If we restrict the usage, then it must be for a good reason. >> If some use case or implementation only accepts ASM in ASM, then >> they can check the address and discard it if say SSM in ASM. >> >> Can you guys provide examples or reasons for restricting it? >> I will also try to think about reasons both for and against, >> [YL] No, I disagree to restrict this. We are on the same page. We should remove the current restriction from the ID. From dthaler@microsoft.com Mon Feb 14 11:14:27 2011 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 BDEE23A6C6C for ; Mon, 14 Feb 2011 11:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.268 X-Spam-Level: X-Spam-Status: No, score=-110.268 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 pQ0ObRBLkSEq for ; Mon, 14 Feb 2011 11:14:26 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id C43D13A6D55 for ; Mon, 14 Feb 2011 11:14:26 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 14 Feb 2011 11:14:49 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.270.2; Mon, 14 Feb 2011 11:14:49 -0800 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.97]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Mon, 14 Feb 2011 11:14:48 -0800 From: Dave Thaler To: "'behave' (behave@ietf.org)" Thread-Topic: Call for WG adoption of several documents Thread-Index: AcvMeOBolr6cyFteQDK8V1YifKfcvQ== Date: Mon, 14 Feb 2011 19:14:48 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF653AF59C76TK5EX14MBXW604w_" MIME-Version: 1.0 Subject: [BEHAVE] Call for WG adoption of several documents 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, 14 Feb 2011 19:14:27 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653AF59C76TK5EX14MBXW604w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On our charter we have the following milestones for which there is no curre= nt WG document: Apr 2011 Submit to IESG: avoiding NAT64 with dual-stack host for local networks (std= ) Apr 2011 Submit to IESG: NAT64 load balancing (std/info) For the first milestone, the chairs believe there are two complementary dra= fts that together may meet the milestone. These are: draft-korhonen-behave-nat64-learn-analysis-01 (-00 was presented last IETF, see minutes at http://www.ietf.org/proceeding= s/79/minutes/behave.txt) http://tools.ietf.org/html/draft-wing-behave-dns64-config-02 (this was presented at IETF 77, see minutes at http://www.ietf.org/proceedi= ngs/77/minutes/behave.txt) For the second milestone, there is: http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing-01 (-00 was presented last IETF, see minutes at http://www.ietf.org/proceeding= s/79/minutes/behave.txt) This email is to solicit WG feedback on whether to adopt each of the above = documents as WG documents. As a reminder, adoption as a WG document means there is consensus that the = document is a good starting point (but may still need work of course). Please respond saying whether or not you support WG adoption at this time o= f each document under consideration above. Thanks, -Dave --_000_9B57C850BB53634CACEC56EF4853FF653AF59C76TK5EX14MBXW604w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

On our charter w= e have the following milestones for which there is no current WG document:<= o:p>

=

Apr 2011

Submit to IESG: avoidi= ng NAT64 with dual-stack host for local networks (std)

Apr 2011

Submit to IESG: NAT64 load ba= lancing (std/info)

 

For the first milestone, the chairs= believe there are two complementary drafts that together may meet the mile= stone.  These are:

draft-korhonen-behave-nat64-learn-analysis-01=

(-00 was presente= d last IETF, see minutes at http://www.ietf.org/proceedings/79/minutes/behave.txt)

 

http://tools.ietf.org/html/draft-wing-behave-dns64-config-0= 2

(this w= as presented at IETF 77, see minutes at http://www.ietf.org/proceedings/77/minutes/b= ehave.txt)

 

For the second milestone, there is:

http://tools.ietf.org/html/d= raft-zhang-behave-nat64-load-balancing-01

(-00 was presented last IETF, see minutes = at http:/= /www.ietf.org/proceedings/79/minutes/behave.txt)

 

This email is to sol= icit WG feedback on whether to adopt each of the above documents as WG docu= ments.

As a reminder, adoption as a WG d= ocument means there is consensus that the document is a good starting point=

(but may still need work of course).

 

= Please respond saying whether or not you support WG adoption at this time o= f each document under consideration above.

 

Thanks,

-Dave

= --_000_9B57C850BB53634CACEC56EF4853FF653AF59C76TK5EX14MBXW604w_-- From John.Border@hughes.com Mon Feb 14 11:35:37 2011 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 1BBD23A6DAF for ; Mon, 14 Feb 2011 11:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 unpgySY35ofC for ; Mon, 14 Feb 2011 11:35:32 -0800 (PST) Received: from hnse2.hns.com (hnse2.hns.com [208.236.67.201]) by core3.amsl.com (Postfix) with ESMTP id A91D83A6D55 for ; Mon, 14 Feb 2011 11:35:32 -0800 (PST) Received: from mail.hughes.com (expexchub.hughes.com [139.85.54.34]) by hnse2.hns.com (Switch-3.3.4/Switch-3.3.4) with ESMTP id p1EJZtaJ000769 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 14 Feb 2011 14:35:55 -0500 (EST) Received: from EXPEXCVS1.hughes.com ([139.85.54.30]) by expexchub1.hughes.com ([10.33.14.13]) with mapi; Mon, 14 Feb 2011 14:35:55 -0500 From: John Border To: "'behave' (behave@ietf.org)" Date: Mon, 14 Feb 2011 14:35:53 -0500 Thread-Topic: Call for WG adoption of several documents Thread-Index: AcvMeOBolr6cyFteQDK8V1YifKfcvQABWA4Q Message-ID: <982B8F9A4E5BDC4B89FF7586464DD2190198A7E27DFD@EXPEXCVS1.hughes.com> References: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_982B8F9A4E5BDC4B89FF7586464DD2190198A7E27DFDEXPEXCVS1hu_" MIME-Version: 1.0 Subject: Re: [BEHAVE] Call for WG adoption of several documents 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, 14 Feb 2011 19:35:37 -0000 --_000_982B8F9A4E5BDC4B89FF7586464DD2190198A7E27DFDEXPEXCVS1hu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Would the first two be combined into a single document or will they rem= ain separate? Just curious... Either way, I am in favor of adopting all of them... John From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Dave Thaler Sent: Monday, February 14, 2011 2:15 PM To: 'behave' (behave@ietf.org) Subject: [BEHAVE] Call for WG adoption of several documents On our charter we have the following milestones for which there is no curre= nt WG document: Apr 2011 Submit to IESG: avoiding NAT64 with dual-stack host for local networks (std= ) Apr 2011 Submit to IESG: NAT64 load balancing (std/info) For the first milestone, the chairs believe there are two complementary dra= fts that together may meet the milestone. These are: draft-korhonen-behave-nat64-learn-analysis-01 (-00 was presented last IETF, see minutes at http://www.ietf.org/proceeding= s/79/minutes/behave.txt) http://tools.ietf.org/html/draft-wing-behave-dns64-config-02 (this was presented at IETF 77, see minutes at http://www.ietf.org/proceedi= ngs/77/minutes/behave.txt) For the second milestone, there is: http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing-01 (-00 was presented last IETF, see minutes at http://www.ietf.org/proceeding= s/79/minutes/behave.txt) This email is to solicit WG feedback on whether to adopt each of the above = documents as WG documents. As a reminder, adoption as a WG document means there is consensus that the = document is a good starting point (but may still need work of course). Please respond saying whether or not you support WG adoption at this time o= f each document under consideration above. Thanks, -Dave --_000_982B8F9A4E5BDC4B89FF7586464DD2190198A7E27DFDEXPEXCVS1hu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 =

    Would= the first two be combined into a single document or will they remain separate?  Just cu= rious…

 =

    Eithe= r way, I am in favor of adopting all of them…

 =

 =

John

 =

 =

 =

From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Dave Thaler
Sent: Monday, February 14, 2011 2:15 PM
To: 'behave' (behave@ietf.org)
Subject: [BEHAVE] Call for WG adoption of several documents

 

On our charter we have the following milestones for wh= ich there is no current WG document:

Apr 2011

Submit to IESG: avoiding NAT64 with dual-stack host = for local networks (std)

Apr 2011

Submit to IESG: NAT64 load balancing (std/info)

 

For the first milestone, the chairs believe there are = two complementary drafts that together may meet the milestone.  These are:=

draft-korhonen-behave-nat64-learn-analysis-01

(-00 was presented last IET= F, see minutes at http://www.ietf.org/proceedings/79/minutes/behave.txt)

 

http:= //tools.ietf.org/html/draft-wing-behave-dns64-config-02

(this was presented at IETF= 77, see minutes at http://www.ietf.org/proceedings/77/minutes/behave.txt)

 

For the second milestone, there is:

http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing-01

(-00 was presented last IET= F, see minutes at http://www.ietf.org/proceedings/79/minutes/behave.txt)

 

This email is to solicit WG feedback on whether to ado= pt each of the above documents as WG documents.

As a reminder, adoption as a WG document means there i= s consensus that the document is a good starting point

(but may still need work of course).

 

Please respond saying whether or not you support WG ad= option at this time of each document under consideration above.

 

Thanks,

-Dave

--_000_982B8F9A4E5BDC4B89FF7586464DD2190198A7E27DFDEXPEXCVS1hu_-- From dthaler@microsoft.com Mon Feb 14 11:45:45 2011 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 DC90C3A6A04 for ; Mon, 14 Feb 2011 11:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.323 X-Spam-Level: X-Spam-Status: No, score=-110.323 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 QSpytJ8PTK8v for ; Mon, 14 Feb 2011 11:45:41 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 3C2573A6D9B for ; Mon, 14 Feb 2011 11:45:41 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 14 Feb 2011 11:46:04 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.270.2; Mon, 14 Feb 2011 11:46:04 -0800 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.97]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Mon, 14 Feb 2011 11:46:03 -0800 From: Dave Thaler To: John Border Thread-Topic: Call for WG adoption of several documents Thread-Index: AcvMeOBolr6cyFteQDK8V1YifKfcvQABWA4QAABYRpA= Date: Mon, 14 Feb 2011 19:46:02 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653AF59E1F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <982B8F9A4E5BDC4B89FF7586464DD2190198A7E27DFD@EXPEXCVS1.hughes.com> In-Reply-To: <982B8F9A4E5BDC4B89FF7586464DD2190198A7E27DFD@EXPEXCVS1.hughes.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF653AF59E1FTK5EX14MBXW604w_" MIME-Version: 1.0 Cc: "'behave' \(behave@ietf.org\)" Subject: Re: [BEHAVE] Call for WG adoption of several documents 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, 14 Feb 2011 19:45:45 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653AF59E1FTK5EX14MBXW604w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dan and I had assumed they would remain separate if adopted, but WG opinion on that would be good to hear too. From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= John Border Sent: Monday, February 14, 2011 11:36 AM To: 'behave' (behave@ietf.org) Subject: Re: [BEHAVE] Call for WG adoption of several documents Would the first two be combined into a single document or will they rem= ain separate? Just curious... Either way, I am in favor of adopting all of them... John From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Dave Thaler Sent: Monday, February 14, 2011 2:15 PM To: 'behave' (behave@ietf.org) Subject: [BEHAVE] Call for WG adoption of several documents On our charter we have the following milestones for which there is no curre= nt WG document: Apr 2011 Submit to IESG: avoiding NAT64 with dual-stack host for local networks (std= ) Apr 2011 Submit to IESG: NAT64 load balancing (std/info) For the first milestone, the chairs believe there are two complementary dra= fts that together may meet the milestone. These are: draft-korhonen-behave-nat64-learn-analysis-01 (-00 was presented last IETF, see minutes at http://www.ietf.org/proceeding= s/79/minutes/behave.txt) http://tools.ietf.org/html/draft-wing-behave-dns64-config-02 (this was presented at IETF 77, see minutes at http://www.ietf.org/proceedi= ngs/77/minutes/behave.txt) For the second milestone, there is: http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing-01 (-00 was presented last IETF, see minutes at http://www.ietf.org/proceeding= s/79/minutes/behave.txt) This email is to solicit WG feedback on whether to adopt each of the above = documents as WG documents. As a reminder, adoption as a WG document means there is consensus that the = document is a good starting point (but may still need work of course). Please respond saying whether or not you support WG adoption at this time o= f each document under consideration above. Thanks, -Dave --_000_9B57C850BB53634CACEC56EF4853FF653AF59E1FTK5EX14MBXW604w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dan and I had assumed they would remain separate if adopted,<= o:p>

but= WG opinion on that would be good to hear too.

 

From: behave-bounces@ietf.org [mailto:= behave-bounces@ietf.org] On Behalf Of John Border
Sent: Mo= nday, February 14, 2011 11:36 AM
To: 'behave' (behave@ietf.org)Subject: Re: [BEHAVE] Call for WG adoption of several documents

 

 

    Wou= ld the first two be combined into a single document or will they remain sep= arate?  Just curious…

=  

    Either way, I am in fa= vor of adopting all of them…

 

 

John

 

 

=

 =

From: behave-bounces@ietf.org [mailto:= behave-bounces@ietf.org] On Behalf Of Dave Thaler
Sent: Mo= nday, February 14, 2011 2:15 PM
To: 'behave' (behave@ietf.org)Subject: [BEHAVE] Call for WG adoption of several documents

 

On our charter we have the following milestones for which the= re is no current WG document:

<= /table>

 

For t= he first milestone, the chairs believe there are two complementary drafts t= hat together may meet the milestone.  These are:

draft-korhonen-behave-na= t64-learn-analysis-01

(-00 was presented last IETF, see minutes at http://www.ietf.org/procee= dings/79/minutes/behave.txt)

 
=

http://tools.ietf.org/html/dr= aft-wing-behave-dns64-config-02

(this was presented at IETF 77, see minutes at http://www.iet= f.org/proceedings/77/minutes/behave.txt)

 

For the second milestone, th= ere is:

http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing-01=

(-00 was pre= sented last IETF, see minutes at http://www.ietf.org/proceedings/79/minutes/behave.t= xt)

 

This email is to solicit WG feedback on whether to adopt each of = the above documents as WG documents.

As = a reminder, adoption as a WG document means there is consensus that the doc= ument is a good starting point

(but may = still need work of course).

 <= /o:p>

Please respond saying whether or not you supp= ort WG adoption at this time of each document under consideration above.

 

= Thanks,

-Dave

= = --_000_9B57C850BB53634CACEC56EF4853FF653AF59E1FTK5EX14MBXW604w_-- From brian.e.carpenter@gmail.com Mon Feb 14 12:28:49 2011 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 920EB3A6DA1 for ; Mon, 14 Feb 2011 12:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=-0.909, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQPHKXINiXzE for ; Mon, 14 Feb 2011 12:28:48 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 164C83A6AB9 for ; Mon, 14 Feb 2011 12:28:47 -0800 (PST) Received: by fxm9 with SMTP id 9so6139044fxm.31 for ; Mon, 14 Feb 2011 12:29:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9pMCezz/tj394/Z7iTiR9QxVeF9/5hRsnzNG82SmMfw=; b=RmKIapIkABw5S89D62/a3RUMZH6eaIW0ZxisCAgfxUatrXTWLdaSvZHuUU9KOflXj2 ++SyQ8qQ2kY1WyzjgNOwGn3+naHvDmkPvSs9uts9+g/KOh1CwYjKSJ6LBErzIGL+RuoV yCFK3i+HuwDPLdPxci5SyvNiNreXJjXFnx5os= 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=wzxCUUcOtHQ1DNSbMCvHUHFTFd7nt/APwIQ/UDXDWkgaH6tbczAetLSsTftCvlKT3d j3lQB6khA5/UrbleWiMSQjoo9Hbu7Z0oz2AFKg2MgXvjWz1mLZIrQ87EXlkGcQlCKfNq xjYlu9AoqNlyvJEcC8vKL6mImRC10cdl4zLAA= Received: by 10.223.101.202 with SMTP id d10mr5002852fao.132.1297715351158; Mon, 14 Feb 2011 12:29:11 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id c11sm1297728fav.2.2011.02.14.12.29.07 (version=SSLv3 cipher=OTHER); Mon, 14 Feb 2011 12:29:09 -0800 (PST) Message-ID: <4D59908C.9060000@gmail.com> Date: Tue, 15 Feb 2011 09:29:00 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dave Thaler References: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "'behave' \(behave@ietf.org\)" Subject: Re: [BEHAVE] Call for WG adoption of several documents 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, 14 Feb 2011 20:28:50 -0000 Hi, On 2011-02-15 08:14, Dave Thaler wrote: > On our charter we have the following milestones for which there is no current WG document: > Apr 2011 > > Submit to IESG: avoiding NAT64 with dual-stack host for local networks (std) > > Apr 2011 > > Submit to IESG: NAT64 load balancing (std/info) > > > For the first milestone, the chairs believe there are two complementary drafts that together may meet the milestone. These are: > draft-korhonen-behave-nat64-learn-analysis-01 > (-00 was presented last IETF, see minutes at http://www.ietf.org/proceedings/79/minutes/behave.txt) > > > http://tools.ietf.org/html/draft-wing-behave-dns64-config-02 > (this was presented at IETF 77, see minutes at http://www.ietf.org/proceedings/77/minutes/behave.txt) I don't think either of these drafts is quite there yet. They both discuss various solutions at some length, but neither of them is clearly proposing a single solution to the stated problem. draft-wing- does express a preference, but we haven't debated that. Have we even debated whether the solution must work properly with untouched RFC3484-conforming hosts? I'd be very hesitant about any solution that *requires* host updates. Also, I don't think either draft considers the case where a dual stack host receives a NAT64-based IPv6 address via an application layer referral, so that DNS is not part of the picture. Are we trying to solve that case too? I think I'd rather see a new draft that contains only one solution. The existing drafts could then become informational background documents. Don't we *also* need a solution to the main problem considered by draft-korhonen- (learn NAT64 prefix)? That isn't in the charter, but seems important. > For the second milestone, there is: > http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing-01 > (-00 was presented last IETF, see minutes at http://www.ietf.org/proceedings/79/minutes/behave.txt) If the goal is Informational, this draft is a good one to adopt. Brian From teemu.savolainen@nokia.com Mon Feb 14 12:40:14 2011 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 11CCE3A6C51 for ; Mon, 14 Feb 2011 12:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.350, 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 wLsx9CQSSQOL for ; Mon, 14 Feb 2011 12:40:13 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 16A533A6C4F for ; Mon, 14 Feb 2011 12:40:13 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1EKeAYw019668; Mon, 14 Feb 2011 22:40:33 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Feb 2011 22:39:40 +0200 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 14 Feb 2011 21:39:39 +0100 Received: from 008-AM1MPN1-016.mgdnok.nokia.com ([169.254.6.185]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0270.002; Mon, 14 Feb 2011 21:39:39 +0100 From: To: , Thread-Topic: [BEHAVE] Call for WG adoption of several documents Thread-Index: AQHLzIXgEid1fjy5mESUT8vEktI/qJQBdDMA Date: Mon, 14 Feb 2011 20:39:37 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A31939D5DC@008-AM1MPN1-016.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4D59908C.9060000@gmail.com> In-Reply-To: <4D59908C.9060000@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.78.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Feb 2011 20:39:40.0028 (UTC) FILETIME=[4D5553C0:01CBCC87] X-Nokia-AV: Clean Cc: behave@ietf.org Subject: Re: [BEHAVE] Call for WG adoption of several documents 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, 14 Feb 2011 20:40:14 -0000 Hi, We have set of explicit solution drafts out there, e.g. but not limited: draft-korhonen-edns0-synthesis-flag-01 draft-savolainen-heuristic-nat64-discovery-00 The purpose of the draft-korhonen-behave-nat64-learn-analysis has been to c= ompare various solutions and propose next steps. In my opinion we might want to include content from draft-wing-behave-dns64= -config to draft-korhonen-behave-nat64-learn-analysis, agree what is the be= st solution, write down the decision, and then also adopt some of the solut= ions. It would be good to have the discussions now to progress before Prague. My personal opinion, probably quite unsurprisingly, is that the "DNS Query = for a Well-Known Name" (we will soon post update to draft-savolainen-heuris= tic-nat64-discovery that contains some updates learnt in discussions, like = DNSSEC considerations) should be one and then additionally we might need an= explicit solution as well (e.g. draft-korhonen-edns0-synthesis-flag).=20 Best regards, Teemu > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of ext Brian E Carpenter > Sent: 14. helmikuuta 2011 22:29 > To: Dave Thaler > Cc: 'behave' (behave@ietf.org) > Subject: Re: [BEHAVE] Call for WG adoption of several documents >=20 > Hi, >=20 > On 2011-02-15 08:14, Dave Thaler wrote: > > On our charter we have the following milestones for which there is no > current WG document: > > Apr 2011 > > > > Submit to IESG: avoiding NAT64 with dual-stack host for local > networks (std) > > > > Apr 2011 > > > > Submit to IESG: NAT64 load balancing (std/info) > > > > > > For the first milestone, the chairs believe there are two > complementary drafts that together may meet the milestone. These are: > > draft-korhonen-behave-nat64-learn-analysis- > 01 analysis-01> > > (-00 was presented last IETF, see minutes at > http://www.ietf.org/proceedings/79/minutes/behave.txt) > > > > > > http://tools.ietf.org/html/draft-wing-behave-dns64-config-02 > > (this was presented at IETF 77, see minutes at > http://www.ietf.org/proceedings/77/minutes/behave.txt) >=20 > I don't think either of these drafts is quite there yet. They both > discuss > various solutions at some length, but neither of them is clearly > proposing > a single solution to the stated problem. draft-wing- does express a > preference, but we haven't debated that. >=20 > Have we even debated whether the solution must work properly with > untouched RFC3484-conforming hosts? I'd be very hesitant about any > solution that *requires* host updates. >=20 > Also, I don't think either draft considers the case where a dual stack > host receives a NAT64-based IPv6 address via an application layer > referral, > so that DNS is not part of the picture. Are we trying to solve that > case too? >=20 > I think I'd rather see a new draft that contains only one solution. The > existing > drafts could then become informational background documents. >=20 > Don't we *also* need a solution to the main problem considered by > draft-korhonen- (learn NAT64 prefix)? That isn't in the charter, but > seems important. >=20 > > For the second milestone, there is: > > http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing-01 > > (-00 was presented last IETF, see minutes at > http://www.ietf.org/proceedings/79/minutes/behave.txt) >=20 > If the goal is Informational, this draft is a good one to adopt. >=20 > Brian > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Mon Feb 14 15:58:11 2011 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 EA80C3A6DDD for ; Mon, 14 Feb 2011 15:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 TKTyATrBr5GG for ; Mon, 14 Feb 2011 15:58:10 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 83CC53A6C3F for ; Mon, 14 Feb 2011 15:58:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4093; q=dns/txt; s=amsiport01001; t=1297727915; x=1298937515; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=FuSI8k19Gk3OZC6MzmybnTfNaw8uzhe7b6I60LAvZVc=; b=WNErwNF6YEcEi9TrPYvrxTXQK6z5t/5aAV37CIrwBcvi939aK9QfGgay 2+tPGfgnU+fGNNms2mFjvdrFuiZbQsVRUGmuht1FhfahUW0gnB8J9OoZK 079sB6XDnq50A7DTyqS9EiS6lzVMUqo471fveL46IrAw9tYVLPee2Qqjt o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAAtRWU2Q/khLgWdsb2JhbACXBYFljHgVAQEWIiSgNptBhV4EhQQ X-IronPort-AV: E=Sophos;i="4.60,471,1291593600"; d="scan'208";a="76270664" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 14 Feb 2011 23:58:23 +0000 Received: from dwingWS ([10.32.240.194]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p1ENwMOE015912; Mon, 14 Feb 2011 23:58:22 GMT From: "Dan Wing" To: "'Brian E Carpenter'" , "'Dave Thaler'" References: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4D59908C.9060000@gmail.com> In-Reply-To: <4D59908C.9060000@gmail.com> Date: Mon, 14 Feb 2011 15:58:21 -0800 Message-ID: <027501cbcca3$103b2c00$30b18400$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvMhd2OWTNN+f5hQ5etHtdMyZTknwAHCtPA Content-Language: en-us Cc: ''behave'' Subject: Re: [BEHAVE] Call for WG adoption of several documents 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, 14 Feb 2011 23:58:12 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Brian E Carpenter > Sent: Monday, February 14, 2011 12:29 PM > To: Dave Thaler > Cc: 'behave' (behave@ietf.org) > Subject: Re: [BEHAVE] Call for WG adoption of several documents > > Hi, > > On 2011-02-15 08:14, Dave Thaler wrote: > > On our charter we have the following milestones for which there is no > current WG document: > > Apr 2011 > > > > Submit to IESG: avoiding NAT64 with dual-stack host for local > networks (std) > > > > Apr 2011 > > > > Submit to IESG: NAT64 load balancing (std/info) > > > > > > For the first milestone, the chairs believe there are two > complementary drafts that together may meet the milestone. These are: > > draft-korhonen-behave-nat64-learn-analysis- > 01 analysis-01> > > (-00 was presented last IETF, see minutes at > http://www.ietf.org/proceedings/79/minutes/behave.txt) > > > > > > http://tools.ietf.org/html/draft-wing-behave-dns64-config-02 > > (this was presented at IETF 77, see minutes at > http://www.ietf.org/proceedings/77/minutes/behave.txt) > > I don't think either of these drafts is quite there yet. They both > discuss > various solutions at some length, but neither of them is clearly > proposing > a single solution to the stated problem. draft-wing- does express a > preference, but we haven't debated that. > > Have we even debated whether the solution must work properly with > untouched RFC3484-conforming hosts? I'd be very hesitant about any > solution that *requires* host updates. In my mind, I view draft-wing-behave-dns64-config as solving the problem when DNS is involved (that is, an application does a DNS query), and draft-korhonen-behave-nat64-learn-analysis as solving the problem when DNS is not involved (that is, an application has an IPv4 address literal). draft-wing-behave-dns64-config suggests using an IPv4-mapped IPv6 address as the first-priority DNS server. I have not tested many OSs with that configuration. But it feels like it could work pretty well. The other techniques listed in draft-wing-behave-dns64-config are worse ideas, but listed for completeness. Those could be easily moved into an Appendix or dropped from the document entirely. > Also, I don't think either draft considers the case where a dual stack > host receives a NAT64-based IPv6 address via an application layer > referral, > so that DNS is not part of the picture. Are we trying to solve that > case too? draft-korhonen-behave-nat64-learn-analysis tries to solve that case where an IPv4 address literal is obtained, and an IPv6-only host wants to use it. It analyzes a bunch of techniques and at the end of the last IETF meeting we reached a rough consensus similar to what Teemu just posted at http://www.ietf.org/mail-archive/web/behave/current/msg09196.html, namely that we use a heuristic for our immediate needs (doing a DNS query of a special name) and we build a standard for longer term (EDNS0). > I think I'd rather see a new draft that contains only one solution. The > existing > drafts could then become informational background documents. > > Don't we *also* need a solution to the main problem considered by > draft-korhonen- (learn NAT64 prefix)? That isn't in the charter, but > seems important. Learning the NAT64's prefix is the only way to solve the referral problem, where an IPv6-only host gets an IPv4 address literal and wants to communicate with that host. -d > > For the second milestone, there is: > > http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing-01 > > (-00 was presented last IETF, see minutes at > http://www.ietf.org/proceedings/79/minutes/behave.txt) > > If the goal is Informational, this draft is a good one to adopt. > > Brian > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From brian.e.carpenter@gmail.com Mon Feb 14 16:15:41 2011 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 1E8533A6DE5 for ; Mon, 14 Feb 2011 16:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.466 X-Spam-Level: X-Spam-Status: No, score=-103.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sz0YNPibcmHH for ; Mon, 14 Feb 2011 16:15:40 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id A02B73A6D7D for ; Mon, 14 Feb 2011 16:15:39 -0800 (PST) Received: by ewy8 with SMTP id 8so2926832ewy.31 for ; Mon, 14 Feb 2011 16:16:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LU1X4OMQpGbiwQuoz670Cme9PNP9O3lD49AFOKWQf/M=; b=ShgUYzjXyUIZih45IddTsCPktpC/9x7RKVrBPi0wjs3Vrw/CGMjNlNBd1TfTggkI+k qxY6wFmTJN02TtshK45tkFtP++HXphyAQ6z2UUHDKbs0uxnakQnBXLlDUSPqgIN/7Kr8 OYcwbiTj+MXeXqr9svgP3n5ndMp0qf87E2WB4= 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=Mqc7jXah5tB9mgSrWEBg+89FcNTMbsR4bA5mreD6rnSTd4HHBO68FSGPhcYhs7kl+I LCAnjUzgd+rdl1+jNaCSVhDak5w+6jRqjQD3Lk3sYoQj7k6EotdcvjUs+EN01ZRR6oaj UP8npy8rMvjeONp6nmwiS+Imfzj0P6rwIbCKA= Received: by 10.14.45.74 with SMTP id o50mr1544938eeb.28.1297728963082; Mon, 14 Feb 2011 16:16:03 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id q52sm3006977eei.9.2011.02.14.16.15.59 (version=SSLv3 cipher=OTHER); Mon, 14 Feb 2011 16:16:02 -0800 (PST) Message-ID: <4D59C5C6.7060004@gmail.com> Date: Tue, 15 Feb 2011 13:16:06 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dan Wing References: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4D59908C.9060000@gmail.com> <027501cbcca3$103b2c00$30b18400$@com> In-Reply-To: <027501cbcca3$103b2c00$30b18400$@com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ''behave'' , 'Dave Thaler' Subject: Re: [BEHAVE] Call for WG adoption of several documents 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, 15 Feb 2011 00:15:41 -0000 On 2011-02-15 12:58, Dan Wing wrote: >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf Of Brian E Carpenter >> Sent: Monday, February 14, 2011 12:29 PM >> To: Dave Thaler >> Cc: 'behave' (behave@ietf.org) >> Subject: Re: [BEHAVE] Call for WG adoption of several documents >> >> Hi, >> >> On 2011-02-15 08:14, Dave Thaler wrote: >>> On our charter we have the following milestones for which there is no >> current WG document: >>> Apr 2011 >>> >>> Submit to IESG: avoiding NAT64 with dual-stack host for local >> networks (std) >>> Apr 2011 >>> >>> Submit to IESG: NAT64 load balancing (std/info) >>> >>> >>> For the first milestone, the chairs believe there are two >> complementary drafts that together may meet the milestone. These are: >>> draft-korhonen-behave-nat64-learn-analysis- >> 01> analysis-01> >>> (-00 was presented last IETF, see minutes at >> http://www.ietf.org/proceedings/79/minutes/behave.txt) >>> >>> http://tools.ietf.org/html/draft-wing-behave-dns64-config-02 >>> (this was presented at IETF 77, see minutes at >> http://www.ietf.org/proceedings/77/minutes/behave.txt) >> >> I don't think either of these drafts is quite there yet. They both >> discuss >> various solutions at some length, but neither of them is clearly >> proposing >> a single solution to the stated problem. draft-wing- does express a >> preference, but we haven't debated that. >> >> Have we even debated whether the solution must work properly with >> untouched RFC3484-conforming hosts? I'd be very hesitant about any >> solution that *requires* host updates. > > In my mind, I view draft-wing-behave-dns64-config as solving the > problem when DNS is involved (that is, an application does a DNS > query), and draft-korhonen-behave-nat64-learn-analysis as solving the > problem when DNS is not involved (that is, an application has an > IPv4 address literal). Fair enough, if there's consensus on that. > > draft-wing-behave-dns64-config suggests using an IPv4-mapped > IPv6 address as the first-priority DNS server. I have not tested > many OSs with that configuration. But it feels like it could work > pretty well. The other techniques listed in > draft-wing-behave-dns64-config are worse ideas, but listed for > completeness. Those could be easily moved into an Appendix > or dropped from the document entirely. Fair enough too, if there's consensus, but the document would have to read more authoritatively than it does now. > >> Also, I don't think either draft considers the case where a dual stack >> host receives a NAT64-based IPv6 address via an application layer >> referral, >> so that DNS is not part of the picture. Are we trying to solve that >> case too? > > draft-korhonen-behave-nat64-learn-analysis tries to solve that case > where an IPv4 address literal is obtained, Yes. I'm asking about the opposite case, where IPv6-only host A gets a synthetic IPv6 address and passes it over to dual-stack host B. If we do nothing, B will just use that IPv6 address as-is and the result is either redundant translation, or failure, depending on the details. Maybe there's nothing we can do for that case, in which case we should document it and move on. and an IPv6-only host > wants to use it. It analyzes a bunch of techniques and at the > end of the last IETF meeting we reached a rough consensus similar > to what Teemu just posted at > http://www.ietf.org/mail-archive/web/behave/current/msg09196.html, > namely that we use a heuristic for our immediate needs (doing a > DNS query of a special name) and we build a standard for longer > term (EDNS0). > > > >> I think I'd rather see a new draft that contains only one solution. The >> existing >> drafts could then become informational background documents. >> >> Don't we *also* need a solution to the main problem considered by >> draft-korhonen- (learn NAT64 prefix)? That isn't in the charter, but >> seems important. > > Learning the NAT64's prefix is the only way to solve the referral > problem, where an IPv6-only host gets an IPv4 address literal and > wants to communicate with that host. > > -d > > >>> For the second milestone, there is: >>> http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing-01 >>> (-00 was presented last IETF, see minutes at >> http://www.ietf.org/proceedings/79/minutes/behave.txt) >> >> If the goal is Informational, this draft is a good one to adopt. >> >> Brian >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > > From dwing@cisco.com Mon Feb 14 17:02:00 2011 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 36BF73A6DE7 for ; Mon, 14 Feb 2011 17:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 k9pqldcyHpi3 for ; Mon, 14 Feb 2011 17:01:58 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 6ADC23A6D9B for ; Mon, 14 Feb 2011 17:01:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5774; q=dns/txt; s=amsiport02001; t=1297731742; x=1298941342; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=IlY94zbxL79E47p09Fs7MO0LIoJdEejYCFVnXSCoxjk=; b=q+0sRYHFaNpCaH1z7WXauFQ7HYOVgkzmNoE+I9shbw/Rr9jWhRSfnZuC 6VUw5HGwycfWW10WcBzEi7V6gTl4VMndGx7/3lkWhbUmik0eJd5rkN3Lr 0hDCbIz1zbNlCOXYJMKymXI/K/pDBbgCBmtQOhR3Mnv8lcBHKrYaRrK9c M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosEAFdfWU2Q/khMgWdsb2JhbACYa4x4FQEBFiIkoEebRYVeBIUF X-IronPort-AV: E=Sophos;i="4.60,471,1291593600"; d="scan'208";a="19177990" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 15 Feb 2011 01:02:20 +0000 Received: from dwingWS ([10.32.240.194]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p1F12J7T020081; Tue, 15 Feb 2011 01:02:19 GMT From: "Dan Wing" To: "'Brian E Carpenter'" References: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4D59908C.9060000@gmail.com> <027501cbcca3$103b2c00$30b18400$@com> <4D59C5C6.7060004@gmail.com> In-Reply-To: <4D59C5C6.7060004@gmail.com> Date: Mon, 14 Feb 2011 17:02:18 -0800 Message-ID: <02b201cbccab$ff4c1040$fde430c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvMpYv1fgQpTrnISQO0ylp0REfBiQAAFzXw Content-Language: en-us Cc: ''behave'' , 'Dave Thaler' Subject: Re: [BEHAVE] Call for WG adoption of several documents 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, 15 Feb 2011 01:02:00 -0000 > >>> For the first milestone, the chairs believe there are two > >> complementary drafts that together may meet the milestone. These > are: > >>> draft-korhonen-behave-nat64-learn-analysis- > >> 01 >> analysis-01> > >>> (-00 was presented last IETF, see minutes at > >> http://www.ietf.org/proceedings/79/minutes/behave.txt) > >>> > >>> http://tools.ietf.org/html/draft-wing-behave-dns64-config-02 > >>> (this was presented at IETF 77, see minutes at > >> http://www.ietf.org/proceedings/77/minutes/behave.txt) > >> > >> I don't think either of these drafts is quite there yet. They both > >> discuss > >> various solutions at some length, but neither of them is clearly > >> proposing > >> a single solution to the stated problem. draft-wing- does express a > >> preference, but we haven't debated that. > >> > >> Have we even debated whether the solution must work properly with > >> untouched RFC3484-conforming hosts? I'd be very hesitant about any > >> solution that *requires* host updates. > > > > In my mind, I view draft-wing-behave-dns64-config as solving the > > problem when DNS is involved (that is, an application does a DNS > > query), and draft-korhonen-behave-nat64-learn-analysis as solving the > > problem when DNS is not involved (that is, an application has an > > IPv4 address literal). > > Fair enough, if there's consensus on that. There probably isn't. I expect many people have not read the introduction of these two documents... :-| Hopefully this thread will initiate some discussion, along the lines of "Yes, I have exactly that problem." We (Cisco) have recently been having a lot more conversations with operators that are wondering how to build a network comprised of both IPv6-only hosts (which use a NAT64) and dual-stack hosts (which might use a NAT44), so that the dual-stack hosts don't put traffic on the NAT64. The working group has discussed this at meetings, but I don't recall much in-depth discussion on the mailing list. My slides are at http://www.ietf.org/proceedings/77/slides/behave-12.pdf (notably see slide #6), and I distinctly recall Andrew Sullivan pointing out that traffic that it costs the same to traverse a NAT44 or a NAT64, which I agree. The only true savings is if the network doesn't have a NAT44, such as depicted on slide 5, or of course if the application simply breaks when traversing a NAT64 (but works when traversing a NAT44). The question is: for dual-stack hosts, do we want to avoid the NAT64? > > draft-wing-behave-dns64-config suggests using an IPv4-mapped > > IPv6 address as the first-priority DNS server. I have not tested > > many OSs with that configuration. But it feels like it could work > > pretty well. The other techniques listed in > > draft-wing-behave-dns64-config are worse ideas, but listed for > > completeness. Those could be easily moved into an Appendix > > or dropped from the document entirely. > > Fair enough too, if there's consensus, but the document would have to > read more authoritatively than it does now. Point taken. Editing now. > >> Also, I don't think either draft considers the case where a dual > stack > >> host receives a NAT64-based IPv6 address via an application layer > >> referral, > >> so that DNS is not part of the picture. Are we trying to solve that > >> case too? > > > > draft-korhonen-behave-nat64-learn-analysis tries to solve that case > > where an IPv4 address literal is obtained, > > Yes. I'm asking about the opposite case, where IPv6-only host A gets a > synthetic IPv6 address and passes it over to dual-stack host B. If we > do nothing, B will just use that IPv6 address as-is and the result is > either redundant translation, or failure, depending on the details. > Maybe there's nothing we can do for that case, in which case we should > document it and move on. If it can, Host A should un-do the synthesis for passing along the referral. I don't know where that should be documented - grobj or in a behave spec? -d > and an IPv6-only host > > wants to use it. It analyzes a bunch of techniques and at the > > end of the last IETF meeting we reached a rough consensus similar > > to what Teemu just posted at > > http://www.ietf.org/mail-archive/web/behave/current/msg09196.html, > > namely that we use a heuristic for our immediate needs (doing a > > DNS query of a special name) and we build a standard for longer > > term (EDNS0). > > > > > > > >> I think I'd rather see a new draft that contains only one solution. > The > >> existing > >> drafts could then become informational background documents. > >> > >> Don't we *also* need a solution to the main problem considered by > >> draft-korhonen- (learn NAT64 prefix)? That isn't in the charter, but > >> seems important. > > > > Learning the NAT64's prefix is the only way to solve the referral > > problem, where an IPv6-only host gets an IPv4 address literal and > > wants to communicate with that host. > > > > -d > > > > > >>> For the second milestone, there is: > >>> http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing- > 01 > >>> (-00 was presented last IETF, see minutes at > >> http://www.ietf.org/proceedings/79/minutes/behave.txt) > >> > >> If the goal is Informational, this draft is a good one to adopt. > >> > >> Brian > >> _______________________________________________ > >> 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 Mon Feb 14 18:10:03 2011 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 ACC243A6E0C for ; Mon, 14 Feb 2011 18:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.97 X-Spam-Level: X-Spam-Status: No, score=-102.97 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_00=-2.599, 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 423qxYvJXSMU for ; Mon, 14 Feb 2011 18:10:01 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 9BCD43A6D91 for ; Mon, 14 Feb 2011 18:10:01 -0800 (PST) Received: by vxi40 with SMTP id 40so3373424vxi.31 for ; Mon, 14 Feb 2011 18:10:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6BMGBeLUXp04QSODdfT2Z/nsJ6V7suHTtbYSF5e2MQM=; b=opm1CbMKl8nDo03lQkIcNH+ORuv7yCk7VRl+LuTnzVf78uY7wU1gGqCOz1D9VBVtrq jE/lwMuGr6vhYw3La8GYPItkuY35D79jZT50+O7KQWBHQgNvxj/ju3P2yKweR9cHRKaH 9ODcz+gm93jpgydCBp1ObYRkB6Yk6FOB5lY+I= 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=uJ6V6fKl9n6L/xDNww+L9HFQF3bG5CoB8lKEt4MElM1oQHU1Dfzz50IIkS2xegufkx 6oGYdQiPoQj9+A6TjPouIF3XcjN2qf95GPlXSHINmcgfTBcc8WdfhomQAjPchzcBn6rP FyzEFTVQMuxLq4Bwh7HeqkNEKiRMH7VZuW/T0= Received: by 10.220.94.208 with SMTP id a16mr135725vcn.6.1297735825524; Mon, 14 Feb 2011 18:10:25 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id u14sm1052826vcr.25.2011.02.14.18.10.23 (version=SSLv3 cipher=OTHER); Mon, 14 Feb 2011 18:10:25 -0800 (PST) Message-ID: <4D59E097.4030303@gmail.com> Date: Tue, 15 Feb 2011 15:10:31 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dan Wing References: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4D59908C.9060000@gmail.com> <027501cbcca3$103b2c00$30b18400$@com> <4D59C5C6.7060004@gmail.com> <02b201cbccab$ff4c1040$fde430c0$@com> In-Reply-To: <02b201cbccab$ff4c1040$fde430c0$@com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ''behave'' , 'Dave Thaler' Subject: [BEHAVE] Desynthesis [was Call for WG adoption of several documents] 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, 15 Feb 2011 02:10:03 -0000 On 2011-02-15 14:02, Dan Wing wrote: >> Yes. I'm asking about the opposite case, where IPv6-only host A gets a >> synthetic IPv6 address and passes it over to dual-stack host B. If we >> do nothing, B will just use that IPv6 address as-is and the result is >> either redundant translation, or failure, depending on the details. >> Maybe there's nothing we can do for that case, in which case we should >> document it and move on. > > If it can, Host A should un-do the synthesis for passing along the > referral. I don't know where that should be documented - grobj or > in a behave spec? If A knows that B is dual stack, that would be appropriate. But if A is a genuine 100% pure IPv6-only host, it knows *nothing* about IPv4, in fact it doesn't know anything about NAT64 either, so it can't know that it should desynthesize the address. I don't see much future in specifying extra features for NAT64-aware IPv6-only hosts. Do you see operating systems vendors caring about that? Brian From dwing@cisco.com Mon Feb 14 18:24:01 2011 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 E1C823A6D24 for ; Mon, 14 Feb 2011 18:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 VRCC1oVjiRJb for ; Mon, 14 Feb 2011 18:24:00 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 840113A6C39 for ; Mon, 14 Feb 2011 18:24:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1778; q=dns/txt; s=amsiport01001; t=1297736665; x=1298946265; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=2HA8zDX2UaPnmmH/r/cta+KH9eq+Jbaky9hzOdlLC+U=; b=BKW3VOdtLtuxmFbUFTlk3yG+05lJHABxd8Ox01OsrJTUh4+PKcpNChCm Iq7hG4thfzWCfX4sjOLQHZp5bp0b4bMvGhKM+TiHYsWvpU3dreSggjo8o MyXSCvoczjxPqCIy9almidmWeHwCaKZ10ZhOslNTkVArtTshkSq/1Adkn I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAAdzWU2Q/khMgWdsb2JhbACEHZJrgWWMeBUBARYiJKBTinGQVYEng0F2BIUFjTo X-IronPort-AV: E=Sophos;i="4.60,471,1291593600"; d="scan'208";a="76275459" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 15 Feb 2011 02:24:24 +0000 Received: from dwingWS ([10.32.240.194]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p1F2OMbN031408; Tue, 15 Feb 2011 02:24:23 GMT From: "Dan Wing" To: "'Brian E Carpenter'" References: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4D59908C.9060000@gmail.com> <027501cbcca3$103b2c00$30b18400$@com> <4D59C5C6.7060004@gmail.com> <02b201cbccab$ff4c1040$fde430c0$@com> <4D59E097.4030303@gmail.com> In-Reply-To: <4D59E097.4030303@gmail.com> Date: Mon, 14 Feb 2011 18:24:22 -0800 Message-ID: <02f901cbccb7$75f67a40$61e36ec0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvMtYYHpFZvliUGQ3GjhwRQ9rHFoAAAK4SQ Content-Language: en-us Cc: ''behave'' Subject: Re: [BEHAVE] Desynthesis [was Call for WG adoption of several documents] 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, 15 Feb 2011 02:24:02 -0000 > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Monday, February 14, 2011 6:11 PM > To: Dan Wing > Cc: ''behave''; 'Dave Thaler' > Subject: Desynthesis [was Call for WG adoption of several documents] > > On 2011-02-15 14:02, Dan Wing wrote: > > > > >> Yes. I'm asking about the opposite case, where IPv6-only host A gets > a > >> synthetic IPv6 address and passes it over to dual-stack host B. If > we > >> do nothing, B will just use that IPv6 address as-is and the result > is > >> either redundant translation, or failure, depending on the details. > >> Maybe there's nothing we can do for that case, in which case we > should > >> document it and move on. > > > > If it can, Host A should un-do the synthesis for passing along the > > referral. I don't know where that should be documented - grobj or > > in a behave spec? > > If A knows that B is dual stack, that would be appropriate. But if > A is a genuine 100% pure IPv6-only host, it knows *nothing* about > IPv4, in fact it doesn't know anything about NAT64 either, so it > can't know that it should desynthesize the address. I don't see how such an application could be 100% pure IPv6-only. An application doing referrals with IPv4 peers (across a NAT64) will need to handle IPv4 addresses. That will remain true until the number of IPv4 peers for that application is miniscule. > I don't see much future in specifying extra features for > NAT64-aware IPv6-only hosts. Do you see operating systems vendors > caring about that? Applications care. And draft-savolainen-heuristic-nat64-discovery allows applications to learn the NAT64's prefix without cooperation or support of the underlying OS. -d From cb.list6@gmail.com Mon Feb 14 18:25:33 2011 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 0DE533A6D24 for ; Mon, 14 Feb 2011 18:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.493 X-Spam-Level: X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tfvcnH0DxP0 for ; Mon, 14 Feb 2011 18:25:32 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 2D2DC3A6C39 for ; Mon, 14 Feb 2011 18:25:32 -0800 (PST) Received: by qwi2 with SMTP id 2so3851883qwi.31 for ; Mon, 14 Feb 2011 18:25:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mGHrs8xKtLWpr77qU6ebyWAvVYO6spyhUs7XlCFQ5po=; b=SHVlszayXTmlhpcReXTxTOc+yAajXZn5q2tKhiyWU297JrbLPYPk8dc/lYrP5KwEeE wk2O8i1zb88BTbM4xesEzTGN2vr+Whx6YdUgfg0egnoq0LO82hF4raHQdpnZCQ8HtK4t l21L0wYgNFM7dT8UoK8H9hgQj+h44Oudtinro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ut3S8m3OyA/tev9dWayPpujYB6nxy1b1fvkyNQtYeBjjW3cPD+MAuvRv31HNwhiCj5 p3Ml7HfOqpI59/R1yOxvT9KdTS/fNSvq0sGzAg2pLOj6oEbMHo1HBiSv24bHFMnjQuQq eY/gl5pgVVkqo6l4OJ1JoQQNzEIMUP4ILsrOM= MIME-Version: 1.0 Received: by 10.229.250.135 with SMTP id mo7mr3509294qcb.30.1297736755945; Mon, 14 Feb 2011 18:25:55 -0800 (PST) Received: by 10.229.224.79 with HTTP; Mon, 14 Feb 2011 18:25:55 -0800 (PST) Received: by 10.229.224.79 with HTTP; Mon, 14 Feb 2011 18:25:55 -0800 (PST) In-Reply-To: <4D59E097.4030303@gmail.com> References: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4D59908C.9060000@gmail.com> <027501cbcca3$103b2c00$30b18400$@com> <4D59C5C6.7060004@gmail.com> <02b201cbccab$ff4c1040$fde430c0$@com> <4D59E097.4030303@gmail.com> Date: Mon, 14 Feb 2011 18:25:55 -0800 Message-ID: From: Cameron Byrne To: Brian E Carpenter Content-Type: multipart/alternative; boundary=00163630f77d59a170049c48e2e7 Cc: behave , Dan Wing , Dave Thaler Subject: Re: [BEHAVE] Desynthesis [was Call for WG adoption of several documents] 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, 15 Feb 2011 02:25:33 -0000 --00163630f77d59a170049c48e2e7 Content-Type: text/plain; charset=ISO-8859-1 I have considered use cases where nat64 is the preferred transition mechanism and ds-lite is used as a stop-gap mechanism for legacy apps and dns64 drives all possible traffic to the nat64. Therefore, I really don't think there is value is trying to be too smart and work around the nat64. If there is a nat64 in the network, the network operator put it there purposefully and expects it to be used. --00163630f77d59a170049c48e2e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I have considered use cases=A0 where nat64 is the preferred transition m= echanism and ds-lite is used as a stop-gap mechanism for legacy apps and dn= s64 drives all possible traffic to the nat64. Therefore, I really don't= think there is value is trying to be too smart and work around the nat64. = If there is a nat64 in the network, the network operator put it there purpo= sefully and expects it to be used.

--00163630f77d59a170049c48e2e7-- From brian.e.carpenter@gmail.com Mon Feb 14 18:37:24 2011 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 394D33A6E0F for ; Mon, 14 Feb 2011 18:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.458 X-Spam-Level: X-Spam-Status: No, score=-103.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgtfkkYmYChR for ; Mon, 14 Feb 2011 18:37:23 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 2F1FC3A6C0B for ; Mon, 14 Feb 2011 18:37:23 -0800 (PST) Received: by vws7 with SMTP id 7so3778834vws.31 for ; Mon, 14 Feb 2011 18:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VedppnAvqD1SLkdLfcnGj9WyUO4l3AyicA4ssyi47rE=; b=w+Cu6b0OlQ2Alm0wkKDVSfP9aG4cDTwQbr2k/ASPL8UZUKxHZK6rLRWN44N8mBDXEm TyK3rxf5q13sqIOw9aYQS44/ysM8EbzN+YDUjq02lqRKNe9idgwDddeiF1yveDPwoIa2 Ignu/Hqfszn2+UiNStwrmWLklGz8wANmcX+ZI= 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=j/bzNWOLtLmM9SQjWER3L/c8RCr+yz8e9yZneO+i4/WHx1JuOFLOrUAI7lrlk6EsGs xUlUqPKE0Ub/yx4yReKjyzULhTOFNSR9idnluR2O3IT2Q0fqTpMEG2yJ+AQwYEJNwOyM cC8XMRWrIqLJRZwtFVIoFBSr5V+MvRa7SMgWw= Received: by 10.220.201.77 with SMTP id ez13mr84318vcb.196.1297737467078; Mon, 14 Feb 2011 18:37:47 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id k39sm1066005vcr.26.2011.02.14.18.37.45 (version=SSLv3 cipher=OTHER); Mon, 14 Feb 2011 18:37:46 -0800 (PST) Message-ID: <4D59E700.3020709@gmail.com> Date: Tue, 15 Feb 2011 15:37:52 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dan Wing References: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4D59908C.9060000@gmail.com> <027501cbcca3$103b2c00$30b18400$@com> <4D59C5C6.7060004@gmail.com> <02b201cbccab$ff4c1040$fde430c0$@com> <4D59E097.4030303@gmail.com> <02f901cbccb7$75f67a40$61e36ec0$@com> In-Reply-To: <02f901cbccb7$75f67a40$61e36ec0$@com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ''behave'' Subject: Re: [BEHAVE] Desynthesis [was Call for WG adoption of several documents] 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, 15 Feb 2011 02:37:24 -0000 Dan, On 2011-02-15 15:24, Dan Wing wrote: >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Monday, February 14, 2011 6:11 PM >> To: Dan Wing >> Cc: ''behave''; 'Dave Thaler' >> Subject: Desynthesis [was Call for WG adoption of several documents] >> >> On 2011-02-15 14:02, Dan Wing wrote: >> >> >> >>>> Yes. I'm asking about the opposite case, where IPv6-only host A gets >> a >>>> synthetic IPv6 address and passes it over to dual-stack host B. If >> we >>>> do nothing, B will just use that IPv6 address as-is and the result >> is >>>> either redundant translation, or failure, depending on the details. >>>> Maybe there's nothing we can do for that case, in which case we >> should >>>> document it and move on. >>> If it can, Host A should un-do the synthesis for passing along the >>> referral. I don't know where that should be documented - grobj or >>> in a behave spec? >> If A knows that B is dual stack, that would be appropriate. But if >> A is a genuine 100% pure IPv6-only host, it knows *nothing* about >> IPv4, in fact it doesn't know anything about NAT64 either, so it >> can't know that it should desynthesize the address. > > I don't see how such an application could be 100% pure IPv6-only. > > An application doing referrals with IPv4 peers (across a > NAT64) will need to handle IPv4 addresses. That will remain > true until the number of IPv4 peers for that application is > miniscule. That's certainly true of some applications. I was thinking of the network stack. > >> I don't see much future in specifying extra features for >> NAT64-aware IPv6-only hosts. Do you see operating systems vendors >> caring about that? > > Applications care. And draft-savolainen-heuristic-nat64-discovery > allows applications to learn the NAT64's prefix without > cooperation or support of the underlying OS. OK, but does that imply work in this WG? Brian From cb.list6@gmail.com Mon Feb 14 18:41:07 2011 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 D3D533A6E17 for ; Mon, 14 Feb 2011 18:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.503 X-Spam-Level: X-Spam-Status: No, score=-3.503 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTKZUESIM8-F for ; Mon, 14 Feb 2011 18:41:06 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 12C5D3A6E0F for ; Mon, 14 Feb 2011 18:41:05 -0800 (PST) Received: by qyk34 with SMTP id 34so1827734qyk.10 for ; Mon, 14 Feb 2011 18:41:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0S3rEMEi6lsGf/lEjKSdZIe9g6N1WIE7rH4zvnphf+w=; b=c7OaI2W2QsFPAusil5wGFaZrNPGDV1RBOxXHFx/mIjyWA+xc/n/vId7UCWAyoyr8H/ gzJnekXSVwjv5ByZbCYfwiZd5SEMbmxJuAdn6bZ/52X6/bVAXWIN4+lzCm/gsbrpt5zL B4jSuniL2L9LMaXx7hJKQik3vsyenV8nvyaHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BCgNJ416tTPP9PJvjS2KP/2oJgi/XOSm2gGEkv5h3y+fMXbjmOb0GXAinryBjakWFB e9Lkrh+vTWxIhivF7DFeCvRXhz+uRjJx2cdDnrrak2s3pu1qqZ895scawIFd8Gk3wBbf b4g+o9Vq3sSJp336JNXH8njo+UXDWL6go6bfg= MIME-Version: 1.0 Received: by 10.229.96.83 with SMTP id g19mr3490760qcn.106.1297737690160; Mon, 14 Feb 2011 18:41:30 -0800 (PST) Received: by 10.229.224.79 with HTTP; Mon, 14 Feb 2011 18:41:30 -0800 (PST) Received: by 10.229.224.79 with HTTP; Mon, 14 Feb 2011 18:41:30 -0800 (PST) In-Reply-To: <02b201cbccab$ff4c1040$fde430c0$@com> References: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4D59908C.9060000@gmail.com> <027501cbcca3$103b2c00$30b18400$@com> <4D59C5C6.7060004@gmail.com> <02b201cbccab$ff4c1040$fde430c0$@com> Date: Mon, 14 Feb 2011 18:41:30 -0800 Message-ID: From: Cameron Byrne To: Dan Wing Content-Type: multipart/alternative; boundary=001636aa2b8e089f4d049c491af4 Cc: behave , Dave Thaler Subject: Re: [BEHAVE] Call for WG adoption of several documents 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, 15 Feb 2011 02:41:08 -0000 --001636aa2b8e089f4d049c491af4 Content-Type: text/plain; charset=ISO-8859-1 On Feb 14, 2011 5:02 PM, "Dan Wing" wrote: > > > >>> For the first milestone, the chairs believe there are two > > >> complementary drafts that together may meet the milestone. These > > are: > > >>> draft-korhonen-behave-nat64-learn-analysis- > > >> 01 > >> analysis-01> > > >>> (-00 was presented last IETF, see minutes at > > >> http://www.ietf.org/proceedings/79/minutes/behave.txt) > > >>> > > >>> http://tools.ietf.org/html/draft-wing-behave-dns64-config-02 > > >>> (this was presented at IETF 77, see minutes at > > >> http://www.ietf.org/proceedings/77/minutes/behave.txt) > > >> > > >> I don't think either of these drafts is quite there yet. They both > > >> discuss > > >> various solutions at some length, but neither of them is clearly > > >> proposing > > >> a single solution to the stated problem. draft-wing- does express a > > >> preference, but we haven't debated that. > > >> > > >> Have we even debated whether the solution must work properly with > > >> untouched RFC3484-conforming hosts? I'd be very hesitant about any > > >> solution that *requires* host updates. > > > > > > In my mind, I view draft-wing-behave-dns64-config as solving the > > > problem when DNS is involved (that is, an application does a DNS > > > query), and draft-korhonen-behave-nat64-learn-analysis as solving the > > > problem when DNS is not involved (that is, an application has an > > > IPv4 address literal). > > > > Fair enough, if there's consensus on that. > > There probably isn't. I expect many people have not read the > introduction of these two documents... :-| > > Hopefully this thread will initiate some discussion, along the > lines of "Yes, I have exactly that problem." > > We (Cisco) have recently been having a lot more conversations with > operators that are wondering how to build a network comprised of > both IPv6-only hosts (which use a NAT64) and dual-stack hosts (which > might use a NAT44), so that the dual-stack hosts don't put traffic > on the NAT64. The working group has discussed this at meetings, but > I don't recall much in-depth discussion on the mailing list. My > slides are at http://www.ietf.org/proceedings/77/slides/behave-12.pdf > (notably see slide #6), and I distinctly recall Andrew Sullivan pointing > out that traffic that it costs the same to traverse a NAT44 or a NAT64, > which I agree. The only true savings is if the network doesn't have a > NAT44, such as depicted on slide 5, or of course if the application > simply breaks when traversing a NAT64 (but works when traversing a > NAT44). > > The question is: for dual-stack hosts, do we want to avoid the > NAT64? > No. The network operator controls the DNS server and will provide dns64 as needed. That is the simplest answer and therefore likely the best. If, by design or not, a ds host gets dns64 not much is lost. In the networks where dns64 is most relevant nat44 is generally used as well. Cb > > > draft-wing-behave-dns64-config suggests using an IPv4-mapped > > > IPv6 address as the first-priority DNS server. I have not tested > > > many OSs with that configuration. But it feels like it could work > > > pretty well. The other techniques listed in > > > draft-wing-behave-dns64-config are worse ideas, but listed for > > > completeness. Those could be easily moved into an Appendix > > > or dropped from the document entirely. > > > > Fair enough too, if there's consensus, but the document would have to > > read more authoritatively than it does now. > > Point taken. Editing now. > > > >> Also, I don't think either draft considers the case where a dual > > stack > > >> host receives a NAT64-based IPv6 address via an application layer > > >> referral, > > >> so that DNS is not part of the picture. Are we trying to solve that > > >> case too? > > > > > > draft-korhonen-behave-nat64-learn-analysis tries to solve that case > > > where an IPv4 address literal is obtained, > > > > Yes. I'm asking about the opposite case, where IPv6-only host A gets a > > synthetic IPv6 address and passes it over to dual-stack host B. If we > > do nothing, B will just use that IPv6 address as-is and the result is > > either redundant translation, or failure, depending on the details. > > Maybe there's nothing we can do for that case, in which case we should > > document it and move on. > > If it can, Host A should un-do the synthesis for passing along the > referral. I don't know where that should be documented - grobj or > in a behave spec? > > -d > > > and an IPv6-only host > > > wants to use it. It analyzes a bunch of techniques and at the > > > end of the last IETF meeting we reached a rough consensus similar > > > to what Teemu just posted at > > > http://www.ietf.org/mail-archive/web/behave/current/msg09196.html, > > > namely that we use a heuristic for our immediate needs (doing a > > > DNS query of a special name) and we build a standard for longer > > > term (EDNS0). > > > > > > > > > > > >> I think I'd rather see a new draft that contains only one solution. > > The > > >> existing > > >> drafts could then become informational background documents. > > >> > > >> Don't we *also* need a solution to the main problem considered by > > >> draft-korhonen- (learn NAT64 prefix)? That isn't in the charter, but > > >> seems important. > > > > > > Learning the NAT64's prefix is the only way to solve the referral > > > problem, where an IPv6-only host gets an IPv4 address literal and > > > wants to communicate with that host. > > > > > > -d > > > > > > > > >>> For the second milestone, there is: > > >>> http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing- > > 01 > > >>> (-00 was presented last IETF, see minutes at > > >> http://www.ietf.org/proceedings/79/minutes/behave.txt) > > >> > > >> If the goal is Informational, this draft is a good one to adopt. > > >> > > >> Brian > > >> _______________________________________________ > > >> 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 --001636aa2b8e089f4d049c491af4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Feb 14, 2011 5:02 PM, "Dan Wing" <dwing@cisco.com> wrote:
>
> > >>> For the first milestone, the chairs believe there ar= e two
> > >> complementary drafts that together may meet the mileston= e. =A0These
> > are:
> > >>> draft-korhonen-behave-nat64-learn-analysis-
> > >> 01<http://tools.ietf.org/html/draft-korhonen-behave-na= t64-learn-
> > >> analysis-01>
> > >>> (-00 was presented last IETF, see minutes at
> > >> http://www.ietf.org/proceedings/79/minutes/behave.txt)
> > >>>
> > >>> http://tools.ietf.org/html/draft-wing-behave-dns64-con= fig-02
> > >>> (this was presented at IETF 77, see minutes at
> > >> http://www.ietf.org/proceedings/77/minutes/behave.txt)
> > >>
> > >> I don't think either of these drafts is quite there = yet. They both
> > >> discuss
> > >> various solutions at some length, but neither of them is= clearly
> > >> proposing
> > >> a single solution to the stated problem. draft-wing- doe= s express a
> > >> preference, but we haven't debated that.
> > >>
> > >> Have we even debated whether the solution must work prop= erly with
> > >> untouched RFC3484-conforming hosts? I'd be very hesi= tant about any
> > >> solution that *requires* host updates.
> > >
> > > In my mind, I view draft-wing-behave-dns64-config as solving= the
> > > problem when DNS is involved (that is, an application does a= DNS
> > > query), and draft-korhonen-behave-nat64-learn-analysis as so= lving the
> > > problem when DNS is not involved (that is, an application ha= s an
> > > IPv4 address literal).
> >
> > Fair enough, if there's consensus on that.
>
> There probably isn't. =A0I expect many people have not read the > introduction of these two documents... =A0:-|
>
> Hopefully this thread will initiate some discussion, along the
> lines of "Yes, I have exactly that problem."
>
> We (Cisco) have recently been having a lot more conversations with
> operators that are wondering how to build a network comprised of
> both IPv6-only hosts (which use a NAT64) and dual-stack hosts (which > might use a NAT44), so that the dual-stack hosts don't put traffic=
> on the NAT64. =A0The working group has discussed this at meetings, but=
> I don't recall much in-depth discussion on the mailing list. =A0My=
> slides are at http://www.ietf.org/proceedings/77/slides/behave-12.pdf
> (notably see slide #6), and I distinctly recall Andrew Sullivan pointi= ng
> out that traffic that it costs the same to traverse a NAT44 or a NAT64= ,
> which I agree. =A0The only true savings is if the network doesn't = have a
> NAT44, such as depicted on slide 5, or of course if the application > simply breaks when traversing a NAT64 (but works when traversing a
> NAT44).
>
> The question is: =A0for dual-stack hosts, do we want to avoid the
> NAT64?
>

No. The network operator controls the DNS server and will provide dns64 = as needed. That is the simplest answer and therefore likely the best.=A0

If, by design or not, a ds host gets dns64 not much is lost.=A0 In the n= etworks where dns64 is most relevant nat44 is generally used as well.

Cb

> > > draft-wing-behave-dns64-config suggests using an IPv4-map= ped
> > > IPv6 address as the first-priority DNS server. =A0I have not= tested
> > > many OSs with that configuration. =A0But it feels like it co= uld work
> > > pretty well. =A0The other techniques listed in
> > > draft-wing-behave-dns64-config are worse ideas, but listed f= or
> > > completeness. =A0Those could be easily moved into an Appendi= x
> > > or dropped from the document entirely.
> >
> > Fair enough too, if there's consensus, but the document would= have to
> > read more authoritatively than it does now.
>
> Point taken. =A0Editing now.
>
> > >> Also, I don't think either draft considers the case = where a dual
> > stack
> > >> host receives a NAT64-based IPv6 address via an applicat= ion layer
> > >> referral,
> > >> so that DNS is not part of the picture. Are we trying to= solve that
> > >> case too?
> > >
> > > draft-korhonen-behave-nat64-learn-analysis tries to solve th= at case
> > > where an IPv4 address literal is obtained,
> >
> > Yes. I'm asking about the opposite case, where IPv6-only host= A gets a
> > synthetic IPv6 address and passes it over to dual-stack host B. I= f we
> > do nothing, B will just use that IPv6 address as-is and the resul= t is
> > either redundant translation, or failure, depending on the detail= s.
> > Maybe there's nothing we can do for that case, in which case = we should
> > document it and move on.
>
> If it can, Host A should un-do the synthesis for passing along the
> referral. =A0I don't know where that should be documented - grobj = or
> in a behave spec?
>
> -d
>
> > and an IPv6-only host
> > > wants to use it. =A0It analyzes a bunch of techniques and at= the
> > > end of the last IETF meeting we reached a rough consensus si= milar
> > > to what Teemu just posted at
> > > http://www.ietf.org/mail-archive/web/behave/current/msg09= 196.html,
> > > namely that we use a heuristic for our immediate needs (doin= g a
> > > DNS query of a special name) and we build a standard for lon= ger
> > > term (EDNS0).
> > >
> > >
> > >
> > >> I think I'd rather see a new draft that contains onl= y one solution.
> > The
> > >> existing
> > >> drafts could then become informational background docume= nts.
> > >>
> > >> Don't we *also* need a solution to the main problem = considered by
> > >> draft-korhonen- (learn NAT64 prefix)? That isn't in = the charter, but
> > >> seems important.
> > >
> > > Learning the NAT64's prefix is the only way to solve the= referral
> > > problem, where an IPv6-only host gets an IPv4 address litera= l and
> > > wants to communicate with that host.
> > >
> > > -d
> > >
> > >
> > >>> For the second milestone, there is:
> > >>> http://tools.ietf.org/html/draft-zhang-behave-n= at64-load-balancing-
> > 01
> > >>> (-00 was presented last IETF, see minutes at
> > >> http://www.ietf.org/proceedings/79/minutes/behave.txt)
> > >>
> > >> If the goal is Informational, this draft is a good one t= o adopt.
> > >>
> > >> =A0 =A0Brian
> > >> _______________________________________________
> > >> 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.i= etf.org/mailman/listinfo/behave

--001636aa2b8e089f4d049c491af4-- From marka@isc.org Tue Feb 15 05:38:41 2011 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 63D7E3A6D0A for ; Tue, 15 Feb 2011 05:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CujsvSuElrUH for ; Tue, 15 Feb 2011 05:38:40 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 7B9823A6A6C for ; Tue, 15 Feb 2011 05:38:40 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 9B985C9421; Tue, 15 Feb 2011 13:38:57 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 4F8AD216C22; Tue, 15 Feb 2011 13:38:57 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id B6AFBA2245C; Wed, 16 Feb 2011 00:38:54 +1100 (EST) To: Cameron Byrne From: Mark Andrews References: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4D59908C.9060000@gmail.com> <027501cbcca3$103b2c00$30b18400$@com> <4D59C5C6.7060004@gmail.com> <02b201cbccab$ff4c1040$fde430c0$@com> <4D59E097.4030303@gmail.com> In-reply-to: Your message of "Mon, 14 Feb 2011 18:25:55 -0800." Date: Wed, 16 Feb 2011 00:38:54 +1100 Message-Id: <20110215133854.B6AFBA2245C@drugs.dv.isc.org> Cc: Dave Thaler , behave , Dan Wing Subject: Re: [BEHAVE] Desynthesis [was Call for WG adoption of several documents] 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, 15 Feb 2011 13:38:41 -0000 In message , Came ron Byrne writes: > > I have considered use cases where nat64 is the preferred transition > mechanism and ds-lite is used as a stop-gap mechanism for legacy apps and > dns64 drives all possible traffic to the nat64. Therefore, I really don't > think there is value is trying to be too smart and work around the nat64. If > there is a nat64 in the network, the network operator put it there > purposefully and expects it to be used. NAT64 could also be there for those hosts that don't yet support DS-Lite. As a mechanism to connect to IPv4 hosts DS-Lite does a better job than NAT64 can ever do. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From cb.list6@gmail.com Tue Feb 15 06:03:47 2011 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 400F23A6CAB for ; Tue, 15 Feb 2011 06:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8qmSkZpmOqd for ; Tue, 15 Feb 2011 06:03:46 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 10C473A6C94 for ; Tue, 15 Feb 2011 06:03:45 -0800 (PST) Received: by qwi2 with SMTP id 2so158202qwi.31 for ; Tue, 15 Feb 2011 06:04:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=N9+D6tbrc+8BgtSkXNWIXg+jeMt+LPyLVy1oKnU1skk=; b=M8RMgilo7f4C9Lz5k7DIHrifcj6XH3GDUD3LzhAnntax+7gI01PenLin3uz2mnSPNy HzeNGyIN24Mx2WPbEOYkKz4upJG2Og+k8ymOcOC+gnB8nqWQJwIkXsjd5EJmM07aZ6eQ YtUsdJg9ye3QZznARDasHbNSSNbNX6rIeaw7E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Vbv9XF1LLtPc9/RWAr7BMr37pJhalIX1/SEMnPBE9GQRsGANnhuqBXfcXpDnC/+b57 tegDOVIS0CgkpG1F/o37Eyk3NdRRFYrvgy4AICFJeb4dCuZNwp8aK6lfd6IW8+0LPG7f Je9pCAsKD/+nWf2igWxePcExLt3AB0M9JLErU= MIME-Version: 1.0 Received: by 10.224.6.71 with SMTP id 7mr559482qay.351.1297778651190; Tue, 15 Feb 2011 06:04:11 -0800 (PST) Received: by 10.229.185.196 with HTTP; Tue, 15 Feb 2011 06:04:11 -0800 (PST) Received: by 10.229.185.196 with HTTP; Tue, 15 Feb 2011 06:04:11 -0800 (PST) In-Reply-To: <20110215133854.B6AFBA2245C@drugs.dv.isc.org> References: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4D59908C.9060000@gmail.com> <027501cbcca3$103b2c00$30b18400$@com> <4D59C5C6.7060004@gmail.com> <02b201cbccab$ff4c1040$fde430c0$@com> <4D59E097.4030303@gmail.com> <20110215133854.B6AFBA2245C@drugs.dv.isc.org> Date: Tue, 15 Feb 2011 06:04:11 -0800 Message-ID: From: Cameron Byrne To: Mark Andrews Content-Type: multipart/alternative; boundary=0015175cd330805458049c52a34b Cc: Dan Wing , behave , Dave Thaler Subject: Re: [BEHAVE] Desynthesis [was Call for WG adoption of several documents] 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, 15 Feb 2011 14:03:47 -0000 --0015175cd330805458049c52a34b Content-Type: text/plain; charset=ISO-8859-1 On Feb 15, 2011 5:39 AM, "Mark Andrews" wrote: > > > In message , Came > ron Byrne writes: > > > > I have considered use cases where nat64 is the preferred transition > > mechanism and ds-lite is used as a stop-gap mechanism for legacy apps and > > dns64 drives all possible traffic to the nat64. Therefore, I really don't > > think there is value is trying to be too smart and work around the nat64. If > > there is a nat64 in the network, the network operator put it there > > purposefully and expects it to be used. > > NAT64 could also be there for those hosts that don't yet support > DS-Lite. As a mechanism to connect to IPv4 hosts DS-Lite does a > better job than NAT64 can ever do. > Seems like an opinion based on criteria .... any network operator want to claim this use case as valid? I think ds-lite is generally seen as a home gateway solution. I am not sure it will ever be in a deployment race with nat64 My only point is that a lot of the transition design is based on supporting the as-is ecosystem. Changing the ecosystem and host behavior to fit the transition mechanism can be dangerous and in a real use case destructive to operator intent. It is changing the rules of the game, which sometimes makes sense, but there should be strong consensus reached before attempting such changes in the ietf Cb > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org --0015175cd330805458049c52a34b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Feb 15, 2011 5:39 AM, "Mark Andrews" <marka@isc.org> wrote:
>
>
> In message <AANLkTik+fSzk3JCWDpxxrwb4vD4hh_FgqOiJAkn8NnqB@ma= il.gmail.com>, Came
> ron Byrne writes:
> >
> > I have considered use cases =A0where nat64 is the preferred trans= ition
> > mechanism and ds-lite is used as a stop-gap mechanism for legacy = apps and
> > dns64 drives all possible traffic to the nat64. Therefore, I real= ly don't
> > think there is value is trying to be too smart and work around th= e nat64. If
> > there is a nat64 in the network, the network operator put it ther= e
> > purposefully and expects it to be used.
>
> NAT64 could also be there for those hosts that don't yet support > DS-Lite. =A0As a mechanism to connect to IPv4 hosts DS-Lite does a
> better job than NAT64 can ever do.
>

Seems like an opinion based on criteria .... any network operator want t= o claim this use case as valid?

I think ds-lite is generally seen as a home gateway solution.=A0 I am no= t sure it will ever be in a deployment race with nat64

My only point is that a lot of the transition design is based on support= ing the as-is ecosystem.=A0 Changing the ecosystem and host behavior to fit= the transition mechanism can be dangerous and in a real use case destructi= ve to operator intent. It is changing the rules of the game, which sometime= s makes sense, but there should be strong consensus reached before attempti= ng such changes in the ietf

Cb
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@isc.org

--0015175cd330805458049c52a34b-- From marka@isc.org Tue Feb 15 06:40:10 2011 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 41EE33A6E84 for ; Tue, 15 Feb 2011 06:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pO7jENdFsPBc for ; Tue, 15 Feb 2011 06:40:09 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 14E673A6D2C for ; Tue, 15 Feb 2011 06:40:09 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 929DEC9423; Tue, 15 Feb 2011 14:40:26 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id DB3E0216C1E; Tue, 15 Feb 2011 14:40:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 0D4B7A22978; Wed, 16 Feb 2011 01:40:22 +1100 (EST) To: Cameron Byrne From: Mark Andrews References: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4D59908C.9060000@gmail.com> <027501cbcca3$103b2c00$30b18400$@com> <4D59C5C6.7060004@gmail.com> <02b201cbccab$ff4c1040$fde430c0$@com> <4D59E097.4030303@gmail.com> <20110215133854.B6AFBA2245C@drugs.dv.isc.org> In-reply-to: Your message of "Tue, 15 Feb 2011 06:04:11 -0800." Date: Wed, 16 Feb 2011 01:40:21 +1100 Message-Id: <20110215144022.0D4B7A22978@drugs.dv.isc.org> Cc: Dan Wing , behave , Dave Thaler Subject: Re: [BEHAVE] Desynthesis [was Call for WG adoption of several documents] 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, 15 Feb 2011 14:40:10 -0000 In message , Came ron Byrne writes: > --0015175cd330805458049c52a34b > Content-Type: text/plain; charset=ISO-8859-1 > > On Feb 15, 2011 5:39 AM, "Mark Andrews" wrote: > > > > > > In message , > Came > > ron Byrne writes: > > > > > > I have considered use cases where nat64 is the preferred transition > > > mechanism and ds-lite is used as a stop-gap mechanism for legacy apps > and > > > dns64 drives all possible traffic to the nat64. Therefore, I really > don't > > > think there is value is trying to be too smart and work around the > nat64. If > > > there is a nat64 in the network, the network operator put it there > > > purposefully and expects it to be used. > > > > NAT64 could also be there for those hosts that don't yet support > > DS-Lite. As a mechanism to connect to IPv4 hosts DS-Lite does a > > better job than NAT64 can ever do. > > Seems like an opinion based on criteria .... any network operator want to > claim this use case as valid? > > I think ds-lite is generally seen as a home gateway solution. I am not sure > it will ever be in a deployment race with nat64 > > My only point is that a lot of the transition design is based on supporting > the as-is ecosystem. Changing the ecosystem and host behavior to fit the > transition mechanism can be dangerous and in a real use case destructive to > operator intent. It is changing the rules of the game, which sometimes makes > sense, but there should be strong consensus reached before attempting such > changes in the ietf NAT64 of often deployed as it is the only thing which will "work" to provide access to the legacy network given the contraints of a IPv6 only network and hosts which may or may not support DS-Lite. With a little bit of ingenuity the operators could support DS-Lite capable hosts by looking for ds-lite dhcp option and returning non DNS64 servers along with the AFTR's address. This would result in less breakage at the cost of running different types of LSN instead of multiple LSN's of the same type. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mohamed.boucadair@orange-ftgroup.com Tue Feb 15 07:03:37 2011 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 48E5F3A6D10 for ; Tue, 15 Feb 2011 07:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vfjIaPw3kFQ for ; Tue, 15 Feb 2011 07:03:34 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id CE0D03A6A41 for ; Tue, 15 Feb 2011 07:03:32 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id BCFBA22C4D3; Tue, 15 Feb 2011 16:03:57 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id A06E9238055; Tue, 15 Feb 2011 16:03:57 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Tue, 15 Feb 2011 16:03:57 +0100 From: To: Dave Thaler , "'behave' (behave@ietf.org)" Date: Tue, 15 Feb 2011 16:03:56 +0100 Thread-Topic: Call for WG adoption of several documents Thread-Index: AcvMeOBolr6cyFteQDK8V1YifKfcvQAp/hvw Message-ID: <19952_1297782237_4D5A95DD_19952_4406_1_94C682931C08B048B7A8645303FDC9F33C444C8202@PUEXCB1B.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F33C444C8202PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.2.15.143314 Subject: Re: [BEHAVE] Call for WG adoption of several documents 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, 15 Feb 2011 15:03:37 -0000 --_000_94C682931C08B048B7A8645303FDC9F33C444C8202PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Dear Dave, all, IMO, draft-korhonen-behave-nat64-learn-analysis should be the place where issues about NAT64/DNS64 are analysed. Solution-related I-Ds are to be considered once the recommendations of draft-korhonen-behave-nat64-learn-analysis are frozen. BTW, I re-iterate my suggestion to include a section about draft-carpenter-behave-referral-object in the analysis document. Cheers, Med ________________________________ De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de Dave Thaler Envoyé : lundi 14 février 2011 20:15 À : 'behave' (behave@ietf.org) Objet : [BEHAVE] Call for WG adoption of several documents On our charter we have the following milestones for which there is no current WG document: Apr 2011 Submit to IESG: avoiding NAT64 with dual-stack host for local networks (std) Apr 2011 Submit to IESG: NAT64 load balancing (std/info) For the first milestone, the chairs believe there are two complementary drafts that together may meet the milestone. These are: draft-korhonen-behave-nat64-learn-analysis-01 (-00 was presented last IETF, see minutes at http://www.ietf.org/proceedings/79/minutes/behave.txt) http://tools.ietf.org/html/draft-wing-behave-dns64-config-02 (this was presented at IETF 77, see minutes at http://www.ietf.org/proceedings/77/minutes/behave.txt) For the second milestone, there is: http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing-01 (-00 was presented last IETF, see minutes at http://www.ietf.org/proceedings/79/minutes/behave.txt) This email is to solicit WG feedback on whether to adopt each of the above documents as WG documents. As a reminder, adoption as a WG document means there is consensus that the document is a good starting point (but may still need work of course). Please respond saying whether or not you support WG adoption at this time of each document under consideration above. Thanks, -Dave ******************************************************************************** IMPORTANT. Les informations contenues dans ce message électronique y compris les fichiers attachés sont strictement confidentielles et peuvent être protégées par la loi. Ce message électronique est destiné exclusivement au(x) destinataire(s) mentionné(s) ci-dessus. Si vous avez reçu ce message par erreur ou s'il ne vous est pas destiné, veuillez immédiatement le signaler à l'expéditeur et effacer ce message et tous les fichiers éventuellement attachés. Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. Tout message électronique est susceptible d'altération. A ce titre, le Groupe France Télécom décline toute responsabilité notamment s'il a été altéré, déformé ou falsifié ; de même, il appartient au destinataire de s'assurer de l'absence de tout virus.    IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure of this message is prohibited.  Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified; additionally the recipient should ensure they are actually virus free. ******************************************************************************** --_000_94C682931C08B048B7A8645303FDC9F33C444C8202PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit
Dear Dave, all,
 
IMO, draft-korhonen-behave-nat64-learn-analysis should be the place where issues about NAT64/DNS64 are analysed. Solution-related I-Ds are to be considered once the recommendations of draft-korhonen-behave-nat64-learn-analysis are frozen.
 
BTW, I re-iterate my suggestion to include a section about draft-carpenter-behave-referral-object in the analysis document.
 
Cheers,
Med

De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de Dave Thaler
Envoyé : lundi 14 février 2011 20:15
À : 'behave' (behave@ietf.org)
Objet : [BEHAVE] Call for WG adoption of several documents

On our charter we have the following milestones for which there is no current WG document:

Apr 2011

Submit to IESG: avoiding NAT64 with dual-stack host for local netwo= rks (std)

Apr 2011 =

Submit to IESG: NAT64 load balancing (std/info)

Apr 2011

Submit to IESG: avoiding NAT64 with dual-stack host for local networks (std)

Apr 2011

Submit to IESG: NAT64 load balancing (std/info)

 

For the first milestone, the chairs believe there are two complementary drafts that together may meet the milestone.  These are:

draft-korhonen-behave-nat64-learn-analysis-01

(-00 was presented last IETF, see minutes at http://www.ietf.org/proceedings/79/minutes/behave.txt)

 

http://tools.ietf.org/html/draft-wing-behave-dns64-config-02

(this was presented at IETF 77, see minutes at http://www.ietf.org/proceedings/77/minutes/behave.txt)

 

For the second milestone, there is:

http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing-01

(-00 was presented last IETF, see minutes at http://www.ietf.org/proceedings/79/minutes/behave.txt)

 

This email is to solicit WG feedback on whether to adopt each of the above documents as WG documents.

As a reminder, adoption as a WG document means there is consensus that the document is a good starting point

(but may still need work of course).

 

Please respond saying whether or not you support WG adoption at this time of each document under consideration above.

 

Thanks,

-Dave

********************************************************************************

IMPORTANT. 
Les informations contenues dans ce message électronique y compris les fichiers attachés sont strictement confidentielles et peuvent être protégées par la loi.
Ce message électronique est destiné exclusivement au(x) destinataire(s) mentionné(s) ci-dessus. 
Si vous avez reçu ce message par erreur ou s'il ne vous est pas destiné, veuillez immédiatement le signaler à l'expéditeur et effacer ce message et tous les fichiers éventuellement attachés.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. 
Tout message électronique est susceptible d'altération.
A ce titre, le Groupe France Télécom décline toute responsabilité notamment s'il a été altéré, déformé ou falsifié ; de même, il appartient au destinataire de s'assurer de l'absence de tout virus.
  
IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure of this message is prohibited. 
Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified; additionally the recipient should ensure they are actually virus free.

********************************************************************************
--_000_94C682931C08B048B7A8645303FDC9F33C444C8202PUEXCB1Bnante_-- From ajs@shinkuro.com Tue Feb 15 07:30:05 2011 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 3DA3C3A6D60 for ; Tue, 15 Feb 2011 07:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 HfAXuFLMFz-E for ; Tue, 15 Feb 2011 07:30:00 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id CB1633A6D4F for ; Tue, 15 Feb 2011 07:30:00 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 3D1F31ECB41D for ; Tue, 15 Feb 2011 15:30:23 +0000 (UTC) Date: Tue, 15 Feb 2011 10:30:18 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20110215153016.GB96213@shinkuro.com> References: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4D59908C.9060000@gmail.com> <027501cbcca3$103b2c00$30b18400$@com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <027501cbcca3$103b2c00$30b18400$@com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] Call for WG adoption of several documents 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, 15 Feb 2011 15:30:05 -0000 On Mon, Feb 14, 2011 at 03:58:21PM -0800, Dan Wing wrote: > wants to use it. It analyzes a bunch of techniques and at the > end of the last IETF meeting we reached a rough consensus similar > to what Teemu just posted at > http://www.ietf.org/mail-archive/web/behave/current/msg09196.html, > namely that we use a heuristic for our immediate needs (doing a > DNS query of a special name) and we build a standard for longer > term (EDNS0). I'm not sure how I overlooked that consensus, but if you want my opinion, step 2 is a waste of time. Once there is standardisation around looking up a special name, that has to be supported forever. Therefore, there is no reason at all to add the EDNS0 option: it just adds complexity without any benefit. There is no fast-track approval for EDNS0 option codes yet, so this objection is bound to be raised once the EDNS0 tactic comes up for discussion. So I would suggest that the well-known name trick (which, for the record, makes my skin crawl) has to be the permanent plan if you're going to adopt it. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ajs@shinkuro.com Tue Feb 15 07:48:54 2011 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 161733A6C38 for ; Tue, 15 Feb 2011 07:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 T8OshFGAtC+n for ; Tue, 15 Feb 2011 07:48:53 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 24D6C3A6CD6 for ; Tue, 15 Feb 2011 07:48:53 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id B4C871ECB41D for ; Tue, 15 Feb 2011 15:49:17 +0000 (UTC) Date: Tue, 15 Feb 2011 10:49:16 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20110215154915.GC96213@shinkuro.com> References: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4D59908C.9060000@gmail.com> <027501cbcca3$103b2c00$30b18400$@com> <4D59C5C6.7060004@gmail.com> <02b201cbccab$ff4c1040$fde430c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02b201cbccab$ff4c1040$fde430c0$@com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] Call for WG adoption of several documents 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, 15 Feb 2011 15:48:54 -0000 On Mon, Feb 14, 2011 at 05:02:18PM -0800, Dan Wing wrote: > (notably see slide #6), and I distinctly recall Andrew Sullivan pointing > out that traffic that it costs the same to traverse a NAT44 or a NAT64, > which I agree. The only true savings is if the network doesn't have a > NAT44, such as depicted on slide 5, or of course if the application > simply breaks when traversing a NAT64 (but works when traversing a > NAT44). > > The question is: for dual-stack hosts, do we want to avoid the > NAT64? I don't get why these dual-stack hosts are getting the DNS64 as their resolver. The only case I've heard so far is something to do with some complicated (and frankly, a little artificial) case where one group of network interfaces is really dual-stack, and the other group is actually NAT64, and you can't tell the difference up in the application layer and you pick the wrong one. That's not a problem we can solve: it's a MIF problem, and just a special case of the general problem that if you're in multiple networks and they have different networks available, you have a hard problem. On top of this (and this is the point Dan remembers), a lot of this talk is as though you have a pure, unmolested, IPv6 and IPv4 dual stack view, and then the nasty IPv4+NAT64 view. But that's almost never going to be true in the cases we care about: most of the time, the IPv4 connectivity is already NAT44, and you need a very compelling case for why we need to make this giant NAT64 hairball even fuzzier in order to prefer a NAT44 to a NAT64. The compelling case boils down to "protocols with IPv4 literals embedded in them." I find it very hard to believe that we are going to fix that generic problem well enough that the better answer won't be "application gateway" every time. We know how to build and ship the latter today. I don't think we should be adding elliptics, epicycles, and eccentrics to this already complicated NAT cosmology to solve the tiny percentage of the cases where this will really matter. I do think that having a way for applications to learn that they're getting synthetic responses from the DNS would be useful, but that's because over in DNS land we're already trying to build new PKIs on top of DNSSEC (see the DANE WG), and I'd hate for that all to break the moment someone is stuck behind a NAT64. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dwing@cisco.com Tue Feb 15 07:48:58 2011 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 7A7C13A6C3C for ; Tue, 15 Feb 2011 07:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 vXguOxwERQ2g for ; Tue, 15 Feb 2011 07:48:57 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 136BB3A6C38 for ; Tue, 15 Feb 2011 07:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2828; q=dns/txt; s=amsiport02001; t=1297784963; x=1298994563; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=pfNNQSudtUa0QqzE8YZj1tuKXDOgLCSUJe8aRHjRyjA=; b=oFs6pTRu1NosHbuaCDVnKTAqNSPDTB9KP4xLBP74/5QLSrxZTqYvvUIb +DfJk9ZKhQyA4nW7lufoFwU37Q2ohcr7jKzV/L+Q0OhnvtHEMkLeuWWwi 44Gk1B4QRWWfgXIuP4gPHk63t5v5bOamkUFuRqPHAt0r9WAuuge9/FCE0 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4BAM0uWk2Q/khMgWdsb2JhbACEHZJigWWMdRUBARYiJKBFinGQd4Eng0F2BIUFjT4 X-IronPort-AV: E=Sophos;i="4.60,474,1291593600"; d="scan'208";a="19250447" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 15 Feb 2011 15:49:22 +0000 Received: from dwingWS ([10.32.240.194]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p1FFnKor016573; Tue, 15 Feb 2011 15:49:21 GMT From: "Dan Wing" To: "'Brian E Carpenter'" References: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4D59908C.9060000@gmail.com> <027501cbcca3$103b2c00$30b18400$@com> <4D59C5C6.7060004@gmail.com> <02b201cbccab$ff4c1040$fde430c0$@com> <4D59E097.4030303@gmail.com> <02f901cbccb7$75f67a40$61e36ec0$@com> <4D59E700.3020709@gmail.com> In-Reply-To: <4D59E700.3020709@gmail.com> Date: Tue, 15 Feb 2011 07:49:20 -0800 Message-ID: <044601cbcd27$e9ba7240$bd2f56c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvMuVeMKQv50+RkQF6vTltJscB8lAAAwRuA Content-Language: en-us Cc: ''behave'' Subject: Re: [BEHAVE] Desynthesis [was Call for WG adoption of several documents] 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, 15 Feb 2011 15:48:58 -0000 > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Monday, February 14, 2011 6:38 PM > To: Dan Wing > Cc: ''behave'' > Subject: Re: Desynthesis [was Call for WG adoption of several > documents] > > Dan, > > On 2011-02-15 15:24, Dan Wing wrote: > >> -----Original Message----- > >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >> Sent: Monday, February 14, 2011 6:11 PM > >> To: Dan Wing > >> Cc: ''behave''; 'Dave Thaler' > >> Subject: Desynthesis [was Call for WG adoption of several documents] > >> > >> On 2011-02-15 14:02, Dan Wing wrote: > >> > >> > >> > >>>> Yes. I'm asking about the opposite case, where IPv6-only host A > gets > >> a > >>>> synthetic IPv6 address and passes it over to dual-stack host B. If > >> we > >>>> do nothing, B will just use that IPv6 address as-is and the result > >> is > >>>> either redundant translation, or failure, depending on the > details. > >>>> Maybe there's nothing we can do for that case, in which case we > >> should > >>>> document it and move on. > >>> If it can, Host A should un-do the synthesis for passing along the > >>> referral. I don't know where that should be documented - grobj or > >>> in a behave spec? > >> If A knows that B is dual stack, that would be appropriate. But if > >> A is a genuine 100% pure IPv6-only host, it knows *nothing* about > >> IPv4, in fact it doesn't know anything about NAT64 either, so it > >> can't know that it should desynthesize the address. > > > > I don't see how such an application could be 100% pure IPv6-only. > > > > An application doing referrals with IPv4 peers (across a > > NAT64) will need to handle IPv4 addresses. That will remain > > true until the number of IPv4 peers for that application is > > miniscule. > > That's certainly true of some applications. I was thinking of the > network stack. In that case, the application needs to know something about the synthesized address, and de-synthesize. Or else the referral will only work if the same synthesis occurs at the next host, at the next host, etc. I don't see a way to make it work without awareness of the synthesis and de-synthesis. > >> I don't see much future in specifying extra features for > >> NAT64-aware IPv6-only hosts. Do you see operating systems vendors > >> caring about that? > > > > Applications care. And draft-savolainen-heuristic-nat64-discovery > > allows applications to learn the NAT64's prefix without > > cooperation or support of the underlying OS. > > OK, but does that imply work in this WG? Learning of the NAT64's prefix belongs in BEHAVE, because NAT64 is BEHAVE's fault. I dunno about referral-related stuff, though, because it's the fault of applications. -d From teemu.savolainen@nokia.com Tue Feb 15 08:00:32 2011 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 6D6613A6C38 for ; Tue, 15 Feb 2011 08:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.832 X-Spam-Level: X-Spam-Status: No, score=-2.832 tagged_above=-999 required=5 tests=[AWL=-0.233, 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 k-nT9daacBT6 for ; Tue, 15 Feb 2011 08:00:31 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 008073A6AA6 for ; Tue, 15 Feb 2011 08:00:30 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1FG0tJC029431; Tue, 15 Feb 2011 18:00:55 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Feb 2011 18:00:18 +0200 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 15 Feb 2011 17:00:18 +0100 Received: from 008-AM1MPN1-016.mgdnok.nokia.com ([169.254.6.21]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0270.002; Tue, 15 Feb 2011 17:00:17 +0100 From: To: , Thread-Topic: [BEHAVE] Call for WG adoption of several documents Thread-Index: AQHLzSfmEid1fjy5mESUT8vEktI/qJQCt6qA Date: Tue, 15 Feb 2011 16:00:16 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A3193AB057@008-AM1MPN1-016.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4D59908C.9060000@gmail.com> <027501cbcca3$103b2c00$30b18400$@com> <4D59C5C6.7060004@gmail.com> <02b201cbccab$ff4c1040$fde430c0$@com> <20110215154915.GC96213@shinkuro.com> In-Reply-To: <20110215154915.GC96213@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.67.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 15 Feb 2011 16:00:18.0700 (UTC) FILETIME=[713764C0:01CBCD29] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Call for WG adoption of several documents 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, 15 Feb 2011 16:00:32 -0000 > I do think that having a way for applications to learn that they're > getting synthetic responses from the DNS would be useful, but that's In addition to learning an address is synthetic, there is one important (IM= HO) reason to learn the prefix: hosts that implement validating DNS resolve= rs and are in IPv6-only NAT64 setup must be able to learn the prefix. Other= wise they cannot synthesize IPv6 addresses after validating A replies. Teemu From ajs@shinkuro.com Tue Feb 15 08:02:44 2011 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 0C8CC3A6A9E for ; Tue, 15 Feb 2011 08:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 SRNsQq60kBp6 for ; Tue, 15 Feb 2011 08:02:43 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 4E95A3A6A8B for ; Tue, 15 Feb 2011 08:02:43 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C429A1ECB41D for ; Tue, 15 Feb 2011 16:03:08 +0000 (UTC) Date: Tue, 15 Feb 2011 11:03:07 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20110215160306.GE96213@shinkuro.com> References: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4D59908C.9060000@gmail.com> <027501cbcca3$103b2c00$30b18400$@com> <4D59C5C6.7060004@gmail.com> <02b201cbccab$ff4c1040$fde430c0$@com> <20110215154915.GC96213@shinkuro.com> <056B511A55F8AA42A3E492B7DD19A3193AB057@008-AM1MPN1-016.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <056B511A55F8AA42A3E492B7DD19A3193AB057@008-AM1MPN1-016.mgdnok.nokia.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] Call for WG adoption of several documents 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, 15 Feb 2011 16:02:44 -0000 On Tue, Feb 15, 2011 at 04:00:16PM +0000, teemu.savolainen@nokia.com wrote: > > I do think that having a way for applications to learn that they're > > getting synthetic responses from the DNS would be useful, but that's > > In addition to learning an address is synthetic, there is one important (IMHO) reason to learn the prefix: hosts that implement validating DNS resolvers and are in IPv6-only NAT64 setup must be able to learn the prefix. Otherwise they cannot synthesize IPv6 addresses after validating A replies. > Yes, exactly. (I guess it wasn't clear from what I was saying, but this is just what I was thinking of.) A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dwing@cisco.com Tue Feb 15 08:30:08 2011 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 E64AB3A6B3B for ; Tue, 15 Feb 2011 08:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 zdAjoH63NYxg for ; Tue, 15 Feb 2011 08:30:05 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 2C05B3A6A8B for ; Tue, 15 Feb 2011 08:30:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3608; q=dns/txt; s=amsiport02001; t=1297787430; x=1298997030; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=P6Nwkwn759E5mynSzxkHBzFKKhCAM6y5+TWOUpXr2w8=; b=fuS3nmgWYzsbM38CFb239uolob9ePwKMyC2+0t+ndWgGKvmMbJIjJ3gi az3+JDQ1R2Rt5fA2gbP3ezgl5ZCM9mv8nfY5CXCPCNgegKbXW6hNmiyD5 +C1L0hqo784nXtcug7tCClfQTmKV9VvlsO/glCsV5oB/ec2p+7u93Ipui g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4BAE45Wk2Q/khMgWdsb2JhbACXAIFljHUVAQEWIiSgTZtnhV4EhQU X-IronPort-AV: E=Sophos;i="4.60,474,1291593600"; d="scan'208";a="19254872" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 15 Feb 2011 16:30:29 +0000 Received: from dwingWS ([10.32.240.194]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p1FGUS3o027424; Tue, 15 Feb 2011 16:30:28 GMT From: "Dan Wing" To: "'Andrew Sullivan'" , References: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4D59908C.9060000@gmail.com> <027501cbcca3$103b2c00$30b18400$@com> <4D59C5C6.7060004@gmail.com> <02b201cbccab$ff4c1040$fde430c0$@com> <20110215154915.GC96213@shinkuro.com> In-Reply-To: <20110215154915.GC96213@shinkuro.com> Date: Tue, 15 Feb 2011 08:30:27 -0800 Message-ID: <046d01cbcd2d$a8332e60$f8998b20$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvNJ+zF6cwj+PdcT0+3RhcD4CTeuAAA6fhw Content-Language: en-us Subject: Re: [BEHAVE] Call for WG adoption of several documents 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, 15 Feb 2011 16:30:08 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Andrew Sullivan > Sent: Tuesday, February 15, 2011 7:49 AM > To: behave@ietf.org > Subject: Re: [BEHAVE] Call for WG adoption of several documents >=20 > On Mon, Feb 14, 2011 at 05:02:18PM -0800, Dan Wing wrote: >=20 > > (notably see slide #6), and I distinctly recall Andrew Sullivan > pointing > > out that traffic that it costs the same to traverse a NAT44 or a > NAT64, > > which I agree. The only true savings is if the network doesn't have > a > > NAT44, such as depicted on slide 5, or of course if the application > > simply breaks when traversing a NAT64 (but works when traversing a > > NAT44). > > > > The question is: for dual-stack hosts, do we want to avoid the > > NAT64? >=20 > I don't get why these dual-stack hosts are getting the DNS64 as their > resolver.=20 One physical network with two hosts: an IPv6-only host (which require a NAT64 to access the IPv4 Internet) and a dual-stack host. =20 The scenario is a network that wants/needs IPv6-only devices (perhaps for testing, perhaps for real deployment), but --=20 critically -- does not want to disrupt or disturb their existing dual-stack hosts. > The only case I've heard so far is something to do with > some complicated (and frankly, a little artificial) case where one > group of network interfaces is really dual-stack, and the other group > is actually NAT64, and you can't tell the difference up in the > application layer and you pick the wrong one.=20 That would be =FCber nasty. I had not heard that use-case. > That's not a problem we > can solve: it's a MIF problem, and just a special case of the general > problem that if you're in multiple networks and they have different > networks available, you have a hard problem. Agreed. > On top of this (and this is the point Dan remembers), a lot of this > talk is as though you have a pure, unmolested, IPv6 and IPv4 dual > stack view, and then the nasty IPv4+NAT64 view. But that's almost > never going to be true in the cases we care about: most of the time, > the IPv4 connectivity is already NAT44, and you need a very compelling > case for why we need to make this giant NAT64 hairball even fuzzier in > order to prefer a NAT44 to a NAT64. The compelling case boils down to > "protocols with IPv4 literals embedded in them." I find it very hard > to believe that we are going to fix that generic problem well enough > that the better answer won't be "application gateway" every time. We > know how to build and ship the latter today. >=20 > I don't think we should be adding elliptics, epicycles, and eccentrics > to this already complicated NAT cosmology to solve the tiny percentage > of the cases where this will really matter. Ok. > I do think that having a way for applications to learn that they're > getting synthetic responses from the DNS would be useful, but that's > because over in DNS land we're already trying to build new PKIs on top > of DNSSEC (see the DANE WG), and I'd hate for that all to break the > moment someone is stuck behind a NAT64. That's a vote for a solution in = draft-korhonen-behave-nat64-learn-analysis. I saw your other note about skin-crawling with a DNS name. :-) Will=20 follow up on that separately. -d > A >=20 > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From teemu.savolainen@nokia.com Tue Feb 15 08:40:20 2011 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 DF1C83A6B7C for ; Tue, 15 Feb 2011 08:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.274 X-Spam-Level: X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OadGk8uqXyFt for ; Tue, 15 Feb 2011 08:40:20 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 21CBD3A6A8B for ; Tue, 15 Feb 2011 08:40:15 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1FGe850024114 for ; Tue, 15 Feb 2011 18:40:40 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Feb 2011 18:40:25 +0200 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 15 Feb 2011 17:40:25 +0100 Received: from 008-AM1MPN1-016.mgdnok.nokia.com ([169.254.6.21]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0270.002; Tue, 15 Feb 2011 17:40:25 +0100 From: To: Thread-Topic: New Version Notification for draft-savolainen-heuristic-nat64-discovery-01 Thread-Index: AQHLzS4jSl8LVgzZ8EuG6HBW5dehgJQCwhUQ Date: Tue, 15 Feb 2011 16:40:24 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A3193AB0C4@008-AM1MPN1-016.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.67.119] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 15 Feb 2011 16:40:25.0844 (UTC) FILETIME=[0BFC6B40:01CBCD2F] X-Nokia-AV: Clean Subject: [BEHAVE] FW: New Version Notification for draft-savolainen-heuristic-nat64-discovery-01 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, 15 Feb 2011 16:40:21 -0000 SGVyZSBpcyB1cGRhdGUgdG8gdGhlICJEaXNjb3Zlcnkgb2YgYSBOZXR3b3JrLVNwZWNpZmljIE5B VDY0IFByZWZpeCB1c2luZyBhIFdlbGwtS25vd24gTmFtZSIuDQoNCk1haW4gY2hhbmdlczoNCi0g Y29uc2lkZXJhdGlvbiB0aGF0IGlmIGEgaG9zdCBpbXBsZW1lbnRzIHZhbGlkYXRpbmcgRE5TU0VD IHJlc29sdmVyIGl0IG11c3QgbGVhcm4gdGhlIHByZWZpeCBpbiBvcmRlciB0byBzeW50aGVzaXpl IGNvcnJlY3RseQ0KLSBjb21tZW50IHRoYXQgIkNEIi1iaXQgbXVzdCBiZSBzZXQgdG8gemVybyBp biB0aGUgcXVlcnkgZm9yIHdlbGwta25vd24gbmFtZSAob3RoZXJ3aXNlIEROUzY0IGRvZXMgbm90 IHN5bnRoZXNpemUpDQotIGNvbnNpZGVyYXRpb25zIGhvdyBwb3NzaWJsZSBtdWx0aXBsZSBwcmVm aXhlcyBhcmUgaGFuZGxlZCAoaWYgQUFBQSByZXNwb25zZSBjb250YWlucyBtdWx0aXBsZSBwb3Nz aWJsZSBkaWZmZXJlbnQgcHJlZml4ZXMpDQotIGhvdyB0byBoYW5kbGUgTlhET01BSU4gb3IgZW1w dHkgQUFBQSByZXBseQ0KLSBjb25zaWRlcmF0aW9ucyBpZiBub24tc3RhbmRhcmQgTlNQIGlzIHVz ZWQNCi0gdGV4dCBpbXByb3ZlbWVudHMgaGVyZSBhbmQgdGhlcmUNCg0KQ29tbWVudHMgd2VsY29t ZS4NCg0KCVRlZW11DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBleHQgSUVU RiBJLUQgU3VibWlzc2lvbiBUb29sIFttYWlsdG86aWRzdWJtaXNzaW9uQGlldGYub3JnXSANClNl bnQ6IDE1LiBoZWxtaWt1dXRhIDIwMTEgMTg6MzMNClRvOiBTYXZvbGFpbmVuIFRlZW11IChOb2tp YS1NUy9UYW1wZXJlKQ0KQ2M6IGpvdW5pLm5vc3BhbUBnbWFpbC5jb20NClN1YmplY3Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc2F2b2xhaW5lbi1oZXVyaXN0aWMtbmF0NjQt ZGlzY292ZXJ5LTAxIA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zYXZvbGFpbmVu LWhldXJpc3RpYy1uYXQ2NC1kaXNjb3ZlcnktMDEudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgVGVlbXUgU2F2b2xhaW5lbiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9z aXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtc2F2b2xhaW5lbi1oZXVyaXN0aWMtbmF0NjQtZGlz Y292ZXJ5DQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBEaXNjb3Zlcnkgb2YgYSBOZXR3b3JrLVNw ZWNpZmljIE5BVDY0IFByZWZpeCB1c2luZyBhIFdlbGwtS25vd24gTmFtZQ0KQ3JlYXRpb25fZGF0 ZToJIDIwMTEtMDItMTUNCldHIElEOgkJIEluZGVwZW5kZW50IFN1Ym1pc3Npb24NCk51bWJlcl9v Zl9wYWdlczogOA0KDQpBYnN0cmFjdDoNClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWV0aG9k IGZvciBkZXRlY3RpbmcgcHJlc2VuY2Ugb2YgRE5TNjQgYW5kDQpmb3IgbGVhcm5pbmcgSVB2NiBw cmVmaXggdXNlZCBmb3IgcHJvdG9jb2wgdHJhbnNsYXRpb24gb24gYW4gYWNjZXNzDQpuZXR3b3Jr IHdpdGhvdXQgZXhwbGljaXQgc3VwcG9ydCBmcm9tIHRoZSBhY2Nlc3MgbmV0d29yay4gIFRoZSBt ZXRob2QNCmRlcGVuZHMgb24gZXhpc3RlbmNlIG9mIGEga25vd24gSVB2NC1vbmx5IGRvbWFpbiBu YW1lLiAgVGhlDQppbmZvcm1hdGlvbiBsZWFybmVkIGVuYWJsZXMgYXBwbGljYXRpb25zIGFuZCBo b3N0cyB0byBwZXJmb3JtIGxvY2FsDQpJUHY2IGFkZHJlc3Mgc3ludGhlc2lzIGFuZCBvbiBkdWFs LXN0YWNrIGFjY2Vzc2VzIGF2b2lkIHRyYXZlcnNhbA0KdGhyb3VnaCBOQVQ2NC4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdC4NCg0KDQo= From cb.list6@gmail.com Tue Feb 15 09:36:46 2011 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 E00103A6CD5 for ; Tue, 15 Feb 2011 09:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvrsOJ4XnqsY for ; Tue, 15 Feb 2011 09:36:45 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id B05C83A6A57 for ; Tue, 15 Feb 2011 09:36:44 -0800 (PST) Received: by qyj19 with SMTP id 19so333370qyj.10 for ; Tue, 15 Feb 2011 09:37:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=O+Zz5N8foH3y7x8aXNcShib0/OriHDwE8bNQl20BgGQ=; b=qbkGmO/g5EQrmfM/tEnjZQg2LSgEuvr901Nx/0VBS5YyJvfNcOwJJ1XTBaJ36VCoTr pHUyQ/sbDagn0tt6iZsPSUG6J0o2Z1pusUHjKrcpz47cBNcqFDC6llrgpv378zmla9Xk TYol4oTXZOyzDeV0Op4nLiSwmdsEDGPt5UM20= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KW6n2Rm75ITP1kg+nzqdq0594Edq5eZQjpwkCoh6OhPX4eBd/lz2KGdB42sKeHI/sx PXVizlpmI0NhUPpxXRvPHlztHnYBRmc2IXHuu6QjtcEDIhTKTE2+0fuwEPo5BlIdCey1 hm/bFNAlXMi98Rp2jR7wTc6x0YrCVSqYGF8lY= MIME-Version: 1.0 Received: by 10.229.82.10 with SMTP id z10mr4284402qck.83.1297791429838; Tue, 15 Feb 2011 09:37:09 -0800 (PST) Received: by 10.229.185.196 with HTTP; Tue, 15 Feb 2011 09:37:09 -0800 (PST) In-Reply-To: <046d01cbcd2d$a8332e60$f8998b20$@com> References: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4D59908C.9060000@gmail.com> <027501cbcca3$103b2c00$30b18400$@com> <4D59C5C6.7060004@gmail.com> <02b201cbccab$ff4c1040$fde430c0$@com> <20110215154915.GC96213@shinkuro.com> <046d01cbcd2d$a8332e60$f8998b20$@com> Date: Tue, 15 Feb 2011 09:37:09 -0800 Message-ID: From: Cameron Byrne To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Andrew Sullivan , behave@ietf.org Subject: Re: [BEHAVE] Call for WG adoption of several documents 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, 15 Feb 2011 17:36:47 -0000 On Tue, Feb 15, 2011 at 8:30 AM, Dan Wing wrote: >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf Of Andrew Sullivan >> Sent: Tuesday, February 15, 2011 7:49 AM >> To: behave@ietf.org >> Subject: Re: [BEHAVE] Call for WG adoption of several documents >> >> On Mon, Feb 14, 2011 at 05:02:18PM -0800, Dan Wing wrote: >> >> > (notably see slide #6), and I distinctly recall Andrew Sullivan >> pointing >> > out that traffic that it costs the same to traverse a NAT44 or a >> NAT64, >> > which I agree. =A0The only true savings is if the network doesn't have >> a >> > NAT44, such as depicted on slide 5, or of course if the application >> > simply breaks when traversing a NAT64 (but works when traversing a >> > NAT44). >> > >> > The question is: =A0for dual-stack hosts, do we want to avoid the >> > NAT64? >> >> I don't get why these dual-stack hosts are getting the DNS64 as their >> resolver. > > One physical network with two hosts: =A0an IPv6-only host (which > require a NAT64 to access the IPv4 Internet) and a dual-stack > host. > Where does this use case arise? It's not in mobile, different classes of users have different APN settings which have different DNS servers. The network has a high degree of control of who gets which DNS server. Is there not similar control in xDSL, FTTH or DOCSIS networks? DHCPv6 controls and scopes? If these controls for network operator policy already exist, it seems better to use those as they already exist and are a known way of controlling who gets which DNS server. It seems like the easiest way to do this with a broad brush is to make the IPv6 DNS64 server only available over IPv6 and the straight DNS server available on IPv4, and end host configure as needed via whichever means are relevant in that network. I am just trying to be practical about where this work is relevant, specifically around the questionable notion of avoiding NAT64 in favor or NAT44. Cameron > The scenario is a network that wants/needs IPv6-only devices > (perhaps for testing, perhaps for real deployment), but -- > critically -- does not want to disrupt or disturb their > existing dual-stack hosts. > >> The only case I've heard so far is something to do with >> some complicated (and frankly, a little artificial) case where one >> group of network interfaces is really dual-stack, and the other group >> is actually NAT64, and you can't tell the difference up in the >> application layer and you pick the wrong one. > > That would be =FCber nasty. =A0I had not heard that use-case. > >> That's not a problem we >> can solve: it's a MIF problem, and just a special case of the general >> problem that if you're in multiple networks and they have different >> networks available, you have a hard problem. > > Agreed. > >> On top of this (and this is the point Dan remembers), a lot of this >> talk is as though you have a pure, unmolested, IPv6 and IPv4 dual >> stack view, and then the nasty IPv4+NAT64 view. =A0But that's almost >> never going to be true in the cases we care about: most of the time, >> the IPv4 connectivity is already NAT44, and you need a very compelling >> case for why we need to make this giant NAT64 hairball even fuzzier in >> order to prefer a NAT44 to a NAT64. =A0The compelling case boils down to >> "protocols with IPv4 literals embedded in them." =A0I find it very hard >> to believe that we are going to fix that generic problem well enough >> that the better answer won't be "application gateway" every time. =A0We >> know how to build and ship the latter today. >> >> I don't think we should be adding elliptics, epicycles, and eccentrics >> to this already complicated NAT cosmology to solve the tiny percentage >> of the cases where this will really matter. > > Ok. > >> I do think that having a way for applications to learn that they're >> getting synthetic responses from the DNS would be useful, but that's >> because over in DNS land we're already trying to build new PKIs on top >> of DNSSEC (see the DANE WG), and I'd hate for that all to break the >> moment someone is stuck behind a NAT64. > > That's a vote for a solution in draft-korhonen-behave-nat64-learn-analysi= s. > > I saw your other note about skin-crawling with a DNS name. =A0:-) =A0Will > follow up on that separately. > > -d > >> A >> >> -- >> Andrew Sullivan >> ajs@shinkuro.com >> Shinkuro, Inc. >> _______________________________________________ >> 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 behcetsarikaya@yahoo.com Tue Feb 15 09:49:07 2011 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 F04993A6C32 for ; Tue, 15 Feb 2011 09:49:06 -0800 (PST) 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 rTA3zTt-SCOJ for ; Tue, 15 Feb 2011 09:49:05 -0800 (PST) Received: from nm6.bullet.mail.sp2.yahoo.com (nm6.bullet.mail.sp2.yahoo.com [98.139.91.76]) by core3.amsl.com (Postfix) with SMTP id 811403A6D33 for ; Tue, 15 Feb 2011 09:49:04 -0800 (PST) Received: from [98.139.91.61] by nm6.bullet.mail.sp2.yahoo.com with NNFMP; 15 Feb 2011 17:49:30 -0000 Received: from [98.139.91.13] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 15 Feb 2011 17:49:30 -0000 Received: from [127.0.0.1] by omp1013.mail.sp2.yahoo.com with NNFMP; 15 Feb 2011 17:49:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 838848.88586.bm@omp1013.mail.sp2.yahoo.com Received: (qmail 26569 invoked by uid 60001); 15 Feb 2011 17:49:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1297792170; bh=HNB5BWO7OEkzRLnmzuH+H7eU88nVmi71Z4wUHoSXtJ0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=zmdIUTUA/6QEIdlLKlVdKMStCWFnGIi+SiEORknA0sQvHkKpWh7p28Tfer6XIy4LbBChx4aalje9r3/HYJ+/HnVy5GFC+CpuXd1XvuKX8JLmqZ5BbgAfjeOt/J6J7u9CnmG9NIjVSTQ8YLR43svsXXnUJj0H1w2yUsut5IoYmms= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=0ttlI3PwUh6Yadgyd7JLWtJXaTCMfg94GeYeDqEPEuUqLyn79G8y5KOPBSA1YaNS5WvWaiUcoGQ7R++S9RP75fYpEOSZIuAL3iH1X1NQP5F5E23RoJfLUYdFe3wZn3RDCu5+2DGW7XxwV94CsG/l2j1cNMwaWp8nso97tyeHLYQ=; Message-ID: <537215.26186.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: 67HYTe4VM1lGV3J5CvwTxhFaImfBGrpBIzxNPk2k3be19bz 5Ywu4OXXvrG5mambKWY4iKCF85FPu5su3Pkxv2KuzHN5lyayha4MKQAWff.Z q6b1v49k_Mv5HKVq08LcxwyXIrGjM3_30o8OZpgKuQfklxMKuNrffjmHtBxW HZbDVOTWGbIPCQQN9PcNLTY1If6f0Tr5XEptj_43GVV31NYDNy7UAd1e1yTO 08qjPKonTcwTKhFAhvMisB6v6TpEWo8irOXSkf7oejeqXjhfOzPkO1.LrFCL j.F4J1kvunpEh6.Qg8sEfhHz4ufcVfnvG_xhL_0k14YLw0zKbEVvx5EtTi7o GxRatHMs_wPxk8BF9pFN7kACLhiP5kzp1C4YBtCFTmbp6KAejzUAoACJU.7u VqbYrTCl1AaM- Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Tue, 15 Feb 2011 09:49:30 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.108.291010 References: <4D54556D.80407@venaas.com> <31963_1297429236_4D5532F4_31963_381209_1_94C682931C08B048B7A8645303FDC9F33C443B9265@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 15 Feb 2011 09:49:30 -0800 (PST) From: Behcet Sarikaya To: mohamed.boucadair@orange-ftgroup.com In-Reply-To: <31963_1297429236_4D5532F4_31963_381209_1_94C682931C08B048B7A8645303FDC9F33C443B9265@PUEXCB1B.nanterre.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "'behave' <\(behave@ietf.org\)>" Subject: Re: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 17:49:07 -0000 Hi Med, Can you please enlighten me The address format defined in this document applies for both IPv4- IPv6 translation and encapsulation schemes. why it would be needed for encapsulation schemes by referring to draft-qin-softwire-dslite-multicast Thanks, Behcet From dwing@cisco.com Tue Feb 15 09:51:04 2011 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 0C0153A6D2A for ; Tue, 15 Feb 2011 09:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 GtcAIQsmtB8r for ; Tue, 15 Feb 2011 09:51:02 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 0F6EB3A6D10 for ; Tue, 15 Feb 2011 09:51:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5699; q=dns/txt; s=amsiport02001; t=1297792288; x=1299001888; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=h5LwILmWZGEDFLCj5UTpTQjBOoi67MB3Eud6giZz+1Y=; b=u+Kuhryui5jF85MCT3uUeXHyvfPatUCWqXN/VxfjwUO+PlxZpR+OOcMo nZ5U+fWD4GBlYu756yVwh7XPJ2cRv5Vj0AKhKbSPNqqnejKRalJbP0IrC d4UCrGSro/T7xLyKBI2w4NlhUJrYlOPpZ7lLK1ziJvE8BrA4SrNdT1znV o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8EAA5MWk2Q/khLgWdsb2JhbACYZYx1FQEBFiIkoGmbZ4VeBIUF X-IronPort-AV: E=Sophos;i="4.60,475,1291593600"; d="scan'208";a="19262162" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 15 Feb 2011 17:51:27 +0000 Received: from dwingWS ([10.32.240.194]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p1FHpPqZ021594; Tue, 15 Feb 2011 17:51:26 GMT From: "Dan Wing" To: "'Cameron Byrne'" References: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4D59908C.9060000@gmail.com> <027501cbcca3$103b2c00$30b18400$@com> <4D59C5C6.7060004@gmail.com> <02b201cbccab$ff4c1040$fde430c0$@com> <20110215154915.GC96213@shinkuro.com> <046d01cbcd2d$a8332e60$f8998b20$@com> In-Reply-To: Date: Tue, 15 Feb 2011 09:51:25 -0800 Message-ID: <04df01cbcd38$f7f43330$e7dc9990$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvNNvrPI/NVQJEdQiua91WZyenlXQAAEOog Content-Language: en-us Cc: 'Andrew Sullivan' , behave@ietf.org Subject: Re: [BEHAVE] Call for WG adoption of several documents 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, 15 Feb 2011 17:51:04 -0000 > > One physical network with two hosts: =A0an IPv6-only host (which > > require a NAT64 to access the IPv4 Internet) and a dual-stack > > host. >=20 > Where does this use case arise? It's a natural transition from IPv4-only to the eventual end-game, which = is IPv6-only: 1. IPv4-only ("today"), possibly with NAPT44 2. dual-stack ("tomorrow"), possibly with NAPT44. Adding IPv6 to the network, or adding a dual-stack host, has=20 absolutely no effect on existing IPv4-only hosts (1). 3. IPv6-only ("day after tomorrow"), with stateful NAT64 and=20 likely with NAPT44. This requires adding DNS64 to the network. This has an effect on existing dual-stack hosts (2), because their traffic will immediately start traversing the NAT64. Best way to think of this is a University network, where students are connecting to the network and expect it "to just work". As=20 soon as the network begins supporting IPv6-only (3), by deploying a DNS64+NAT64, it causes an immediate change to how their=20 dual-stack hosts function. This may impair the successful deployment of DNS64+NAT64, and thus may impair the successful deployment of IPv6-only hosts. > It's not in mobile, different classes of users have different APN > settings which have different DNS servers. The network has a high > degree of control of who gets which DNS server. >=20 > Is there not similar control in xDSL, FTTH or DOCSIS networks? > DHCPv6 controls and scopes?=20 It's a network with two hosts: one dual stack and one IPv6-only. Conceptually it's an Ethernet network with two hosts. > If these controls for network operator > policy already exist, it seems better to use those as they already > exist and are a known way of controlling who gets which DNS server. >=20 > It seems like the easiest way to do this with a broad brush is to make > the IPv6 DNS64 server only available over IPv6 and the straight DNS > server available on IPv4, and end host configure as needed via > whichever means are relevant in that network. Sure. And that is exactly what draft-wing-behave-dns64-config-03 suggests: "For example, a dual-stack host and an IPv6-only host would be configured with the following DNS servers, in this order, where the first one is the normal DNS server (192.0.2.1) and the second one is the DNS64 server (2001:db8:dddd::1234) ::ffff:192.0.2.1 # 'normal' DNS server 2001:db8:dddd::1234 # DNS64 server " -d > I am just trying to be practical about where this work is relevant, > specifically around the questionable notion of avoiding NAT64 in favor > or NAT44. >=20 > Cameron >=20 >=20 > > The scenario is a network that wants/needs IPv6-only devices > > (perhaps for testing, perhaps for real deployment), but -- > > critically -- does not want to disrupt or disturb their > > existing dual-stack hosts. > > > >> The only case I've heard so far is something to do with > >> some complicated (and frankly, a little artificial) case where one > >> group of network interfaces is really dual-stack, and the other > group > >> is actually NAT64, and you can't tell the difference up in the > >> application layer and you pick the wrong one. > > > > That would be =FCber nasty. =A0I had not heard that use-case. > > > >> That's not a problem we > >> can solve: it's a MIF problem, and just a special case of the > general > >> problem that if you're in multiple networks and they have different > >> networks available, you have a hard problem. > > > > Agreed. > > > >> On top of this (and this is the point Dan remembers), a lot of this > >> talk is as though you have a pure, unmolested, IPv6 and IPv4 dual > >> stack view, and then the nasty IPv4+NAT64 view. =A0But that's = almost > >> never going to be true in the cases we care about: most of the = time, > >> the IPv4 connectivity is already NAT44, and you need a very > compelling > >> case for why we need to make this giant NAT64 hairball even fuzzier > in > >> order to prefer a NAT44 to a NAT64. =A0The compelling case boils = down > to > >> "protocols with IPv4 literals embedded in them." =A0I find it very > hard > >> to believe that we are going to fix that generic problem well = enough > >> that the better answer won't be "application gateway" every time. > =A0We > >> know how to build and ship the latter today. > >> > >> I don't think we should be adding elliptics, epicycles, and > eccentrics > >> to this already complicated NAT cosmology to solve the tiny > percentage > >> of the cases where this will really matter. > > > > Ok. > > > >> I do think that having a way for applications to learn that they're > >> getting synthetic responses from the DNS would be useful, but = that's > >> because over in DNS land we're already trying to build new PKIs on > top > >> of DNSSEC (see the DANE WG), and I'd hate for that all to break the > >> moment someone is stuck behind a NAT64. > > > > That's a vote for a solution in draft-korhonen-behave-nat64-learn- > analysis. > > > > I saw your other note about skin-crawling with a DNS name. =A0:-) = =A0Will > > follow up on that separately. > > > > -d > > > >> A > >> > >> -- > >> Andrew Sullivan > >> ajs@shinkuro.com > >> Shinkuro, Inc. > >> _______________________________________________ > >> 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 Tue Feb 15 13:41:35 2011 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 2A64E3A6C21 for ; Tue, 15 Feb 2011 13:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=-0.823, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rES3Itst3rh for ; Tue, 15 Feb 2011 13:41:33 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 161793A6ADB for ; Tue, 15 Feb 2011 13:41:32 -0800 (PST) Received: by fxm9 with SMTP id 9so774904fxm.31 for ; Tue, 15 Feb 2011 13:41:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=p4GNjjnY08Dd/32+Vx9UoiKrcoQn82HgEkqeNaFeUyo=; b=kXf9nbIWx+z5nu+XSkODtXGz8amDeBBqacvBkGOQS0u4ilWU7WQaKM6JR/bipARG60 EKxeedN4bBMFhSTyhcEDKe3+Ll0yf9UtTZowDNR7k/LZFjhwxNAVFYrRwj/r2PRkffFD WDzNTXZ1CSFO4gkCOFgaWlpPUsub9t0sD7UvE= 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=EeV7exNvhnrjgN5ketK4SOY5iCVfTMroPo1/+U9hh7BW5XVQfWgATESNDAW6/6K4lv fDEeQiFtD00U5gMtCy4ukeXhCbTgHAaxZlexttUs1/fi3VYsMJoENbHwJaiLMJI/fLqx 7ProH72iMxIhDFHPdRIoeqpGyA6U65c/iGuok= Received: by 10.223.101.202 with SMTP id d10mr6726673fao.132.1297806118981; Tue, 15 Feb 2011 13:41:58 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id n15sm1935421fam.12.2011.02.15.13.41.55 (version=SSLv3 cipher=OTHER); Tue, 15 Feb 2011 13:41:57 -0800 (PST) Message-ID: <4D5AF320.4080808@gmail.com> Date: Wed, 16 Feb 2011 10:41:52 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com References: <9B57C850BB53634CACEC56EF4853FF653AF59C76@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <19952_1297782237_4D5A95DD_19952_4406_1_94C682931C08B048B7A8645303FDC9F33C444C8202@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <19952_1297782237_4D5A95DD_19952_4406_1_94C682931C08B048B7A8645303FDC9F33C444C8202@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "'behave' \(behave@ietf.org\)" , Dave Thaler Subject: Re: [BEHAVE] Call for WG adoption of several documents 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, 15 Feb 2011 21:41:35 -0000 Mohamed, On 2011-02-16 04:03, mohamed.boucadair@orange-ftgroup.com wrote: > Dear Dave, all, >=20 > IMO, draft-korhonen-behave-nat64-learn-analysis should be the place wh= ere issues about NAT64/DNS64 are analysed. Solution-related I-Ds are to b= e considered once the recommendations of draft-korhonen-behave-nat64-lear= n-analysis are frozen. >=20 > BTW, I re-iterate my suggestion to include a section about draft-carpen= ter-behave-referral-object in the analysis document. Not that draft please - we are on draft-carpenter-referral-ps (problem st= atement only) now. Brian > Cheers, > Med >=20 > ________________________________ > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la par= t de Dave Thaler > Envoy=C3=A9 : lundi 14 f=C3=A9vrier 2011 20:15 > =C3=80 : 'behave' (behave@ietf.org) > Objet : [BEHAVE] Call for WG adoption of several documents >=20 > On our charter we have the following milestones for which there is no c= urrent WG document: > Apr 2011 >=20 > Submit to IESG: avoiding NAT64 with dual-stack host for local networks = (std) >=20 > Apr 2011 >=20 > Submit to IESG: NAT64 load balancing (std/info) >=20 >=20 > For the first milestone, the chairs believe there are two complementary= drafts that together may meet the milestone. These are: > draft-korhonen-behave-nat64-learn-analysis-01 > (-00 was presented last IETF, see minutes at http://www.ietf.org/procee= dings/79/minutes/behave.txt) >=20 >=20 > http://tools.ietf.org/html/draft-wing-behave-dns64-config-02 > (this was presented at IETF 77, see minutes at http://www.ietf.org/proc= eedings/77/minutes/behave.txt) >=20 > For the second milestone, there is: > http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing-01 > (-00 was presented last IETF, see minutes at http://www.ietf.org/procee= dings/79/minutes/behave.txt) >=20 > This email is to solicit WG feedback on whether to adopt each of the ab= ove documents as WG documents. > As a reminder, adoption as a WG document means there is consensus that = the document is a good starting point > (but may still need work of course). >=20 > Please respond saying whether or not you support WG adoption at this ti= me of each document under consideration above. >=20 > Thanks, > -Dave >=20 > ***********************************************************************= ********* >=20 > IMPORTANT.=20 > Les informations contenues dans ce message =C3=A9lectronique y compris = les fichiers attach=C3=A9s sont strictement confidentielles et peuvent =C3= =AAtre prot=C3=A9g=C3=A9es par la loi. > Ce message =C3=A9lectronique est destin=C3=A9 exclusivement au(x) desti= nataire(s) mentionn=C3=A9(s) ci-dessus.=20 > Si vous avez re=C3=A7u ce message par erreur ou s'il ne vous est pas de= stin=C3=A9, veuillez imm=C3=A9diatement le signaler =C3=A0 l'exp=C3=A9dit= eur et effacer ce message et tous les fichiers =C3=A9ventuellement attach= =C3=A9s. > Toute lecture, exploitation ou transmission des informations contenues = dans ce message est interdite.=20 > Tout message =C3=A9lectronique est susceptible d'alt=C3=A9ration. > A ce titre, le Groupe France T=C3=A9l=C3=A9com d=C3=A9cline toute respo= nsabilit=C3=A9 notamment s'il a =C3=A9t=C3=A9 alt=C3=A9r=C3=A9, d=C3=A9fo= rm=C3=A9 ou falsifi=C3=A9 ; de m=C3=AAme, il appartient au destinataire d= e s'assurer de l'absence de tout virus. > =20 > IMPORTANT.This e-mail message and any attachments are strictly confiden= tial and may be protected by law. This message is intended only for the n= amed recipient(s) above. > If you have received this message in error, or are not the named recipi= ent(s), please immediately notify the sender and delete this e-mail messa= ge. > Any unauthorized view, usage or disclosure of this message is prohibite= d.=20 > Since e-mail messages may not be reliable, France Telecom Group shall n= ot be liable for any message if modified, changed or falsified; additiona= lly the recipient should ensure they are actually virus free. >=20 > ***********************************************************************= ********* >=20 >=20 >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From mohamed.boucadair@orange-ftgroup.com Tue Feb 15 22:16:36 2011 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 75A2D3A6D91 for ; Tue, 15 Feb 2011 22:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBC9WRp1mG9d for ; Tue, 15 Feb 2011 22:16:35 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 56C6C3A6D8C for ; Tue, 15 Feb 2011 22:16:35 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 8C4513B434D; Wed, 16 Feb 2011 07:17:01 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 747494C013; Wed, 16 Feb 2011 07:17:01 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Wed, 16 Feb 2011 07:17:01 +0100 From: To: Behcet Sarikaya Date: Wed, 16 Feb 2011 07:17:00 +0100 Thread-Topic: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D Thread-Index: AcvNOLN/v+zg9ozuQH6UBNLdyI7fIAAZ1YoA Message-ID: <7108_1297837021_4D5B6BDD_7108_70108_1_94C682931C08B048B7A8645303FDC9F33C444C83BE@PUEXCB1B.nanterre.francetelecom.fr> References: <4D54556D.80407@venaas.com> <31963_1297429236_4D5532F4_31963_381209_1_94C682931C08B048B7A8645303FDC9F33C443B9265@PUEXCB1B.nanterre.francetelecom.fr> <537215.26186.qm@web111403.mail.gq1.yahoo.com> In-Reply-To: <537215.26186.qm@web111403.mail.gq1.yahoo.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.2.16.51215 Cc: "'behave' <\(behave@ietf.org\)>" Subject: Re: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D 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, 16 Feb 2011 06:16:36 -0000 Hi Behcet, draft-qin-softwire-dslite-multicast is only an example of a solution using the proposed address format for its operations. draft-xu-softwire-mesh-multicast is another solution requiring an address format for embedding IPv4 multicast addresses in an IPv6 Mcst. Concretely, draft-qin-softwire-dslite-multicast uses the proposed address format to allow: * Stateless interworking between IGMPvx-MLD in the CPE * Stateless IPv6-IPv4 PIM interworking * Stateless encap of IPv4 multicast flows at the v4-v6 interconnection nodes * No coordination is required between all the interworking function except the provisioning of a SSM or ASM Multicast_PREFIX64. Cheers, Med -----Message d'origine----- De : Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] Envoyé : mardi 15 février 2011 18:50 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : 'behave' <(behave@ietf.org)> Objet : Re: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D Hi Med, Can you please enlighten me The address format defined in this document applies for both IPv4- IPv6 translation and encapsulation schemes. why it would be needed for encapsulation schemes by referring to draft-qin-softwire-dslite-multicast Thanks, Behcet ******************************************************************************** IMPORTANT. Les informations contenues dans ce message électronique y compris les fichiers attachés sont strictement confidentielles et peuvent être protégées par la loi. Ce message électronique est destiné exclusivement au(x) destinataire(s) mentionné(s) ci-dessus. Si vous avez reçu ce message par erreur ou s'il ne vous est pas destiné, veuillez immédiatement le signaler à l'expéditeur et effacer ce message et tous les fichiers éventuellement attachés. Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. Tout message électronique est susceptible d'altération. A ce titre, le Groupe France Télécom décline toute responsabilité notamment s'il a été altéré, déformé ou falsifié. De même, il appartient au destinataire de s'assurer de l'absence de tout virus.    IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure of this message is prohibited.  Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ******************************************************************************** From behcetsarikaya@yahoo.com Wed Feb 16 08:01:14 2011 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 AF8893A6E5E for ; Wed, 16 Feb 2011 08:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, 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 t76FNs4ptrQg for ; Wed, 16 Feb 2011 08:01:13 -0800 (PST) Received: from nm4.bullet.mail.sp2.yahoo.com (nm4.bullet.mail.sp2.yahoo.com [98.139.91.74]) by core3.amsl.com (Postfix) with SMTP id D59A63A6D9D for ; Wed, 16 Feb 2011 08:01:13 -0800 (PST) Received: from [98.139.91.68] by nm4.bullet.mail.sp2.yahoo.com with NNFMP; 16 Feb 2011 16:01:42 -0000 Received: from [98.139.91.54] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 16 Feb 2011 16:01:42 -0000 Received: from [127.0.0.1] by omp1054.mail.sp2.yahoo.com with NNFMP; 16 Feb 2011 16:01:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 652948.83079.bm@omp1054.mail.sp2.yahoo.com Received: (qmail 37977 invoked by uid 60001); 16 Feb 2011 16:01:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1297872102; bh=UXoB5NhJjrpuQUNcnrmu2iWE615pytrgOMAdUIp/bys=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=njK84wCPZ0ZHqkL1BX4Ob+F+SKu3947WqDYXr76V53WtrH2Z8ReIV5nYCFzs6uraPLymwUwcb3QgiG0SGIoAS6rKeUU/0iUq75lfhPEkNcjSzKxfmOUHSEhp2phJHsYcZ6nzqWofrwe/KA23Hdn5Arz6tEtmJnyY5f07eU8d/Vc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1rXi1vZRzEspK0OB+pQy16AvxvsiYd8UILpA0rSeZV5o5E/gvqsEP/q0cvSyVOIYHIF7cjarUYoOFKIrKWjuH52Sj307zHTdh5jFhtFjp9pAZPdSrbbJwGWT6fTz2PGn6Lx1d29ZYKmdqZxq63OhkeXrcTFh0YJoW2HbeQfY/Eo=; Message-ID: <238315.35246.qm@web111411.mail.gq1.yahoo.com> X-YMail-OSG: dh3aJlQVM1n_INLOuxV6dx8IBVLx5ADhGA0F4OBsySflj90 _MkXLq25XA6u8hE7V1oURlyqi5Xg_G7G9sikSabT4tHna3Xpy6Ev0SK34VB. 2Am4m7fE.aFGxjRdqv0Dkl88YD4hfeudXdsqcHNgTHHH2eqyI9cyqjDoqRbv Lr8IU96zUJ5ALD8XFpZCAg0NqQphD6_1fZ4Pe5qnaDFcybb1cqd.b127tEXr z2KtITXmUGiFHFCluFYl6jMLgEKCn3z_v11gXQ66qCFbSloHb7QJu5EevuQg mFLtfHLwlpaGaKXjc1iPwHOC6t7KPnCour8XUR9tYG7juXldC4qp0Yui3vI_ 1PTysESSMMcISw_aUjxtq.UkmG6pkl.s2W4uffdAkJUdEo0dSbRj8.DCD07X 96g7LJDLk0HPH Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Wed, 16 Feb 2011 08:01:41 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.109.292656 References: <4D54556D.80407@venaas.com> <31963_1297429236_4D5532F4_31963_381209_1_94C682931C08B048B7A8645303FDC9F33C443B9265@PUEXCB1B.nanterre.francetelecom.fr> <537215.26186.qm@web111403.mail.gq1.yahoo.com> <7108_1297837021_4D5B6BDD_7108_70108_1_94C682931C08B048B7A8645303FDC9F33C444C83BE@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 16 Feb 2011 08:01:41 -0800 (PST) From: Behcet Sarikaya To: mohamed.boucadair@orange-ftgroup.com In-Reply-To: <7108_1297837021_4D5B6BDD_7108_70108_1_94C682931C08B048B7A8645303FDC9F33C444C83BE@PUEXCB1B.nanterre.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "'behave' <\(behave@ietf.org\)>" Subject: Re: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 16:01:14 -0000 =0A=0A=0A=0A=0A> Hi Behcet,=0A> =0A> draft-qin-softwire-dslite-multicast is= only an example of a solution using the =0A>proposed address format for i= ts operations. draft-xu-softwire-mesh-multicast is =0A>another solution re= quiring an address format for embedding IPv4 multicast =0A>addresses in an= IPv6 Mcst.=0A> =0A> Concretely, draft-qin-softwire-dslite-multicast uses = the proposed address =0A>format to allow:=0A> * Stateless interworking bet= ween IGMPvx-MLD in the CPE=0A> * Stateless IPv6-IPv4 PIM interworking =0A>= * Stateless encap of IPv4 multicast flows at the v4-v6 interconnection no= des=0A> * No coordination is required between all the interworking functio= n except the =0A>provisioning of a SSM or ASM Multicast_PREFIX64.=0A> =0A= =0AThis is one way but IMHO it would be totally unnecessary to use IPv4-emb= edded =0AIPv6 address. I can not see the need for it except that you want t= o do multicast =0Arouting in the access network.=0A=0AIf you can lift this = "requirement" then there is a much simpler solution, I =0Asuggest looking i= nto draft-ietf-multimob-pmipv6-base-solution=0A=0ARegards,=0A=0ABehcet=0A= =0A> Cheers,=0A> Med=0A> =0A> -----Message d'origine-----=0A> De : Behcet = Sarikaya [mailto:behcetsarikaya@yahoo.com] =0A> Envoy=E9 : mardi 15 f=E9vr= ier 2011 18:50=0A> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP=0A> Cc : 'behave' = <(behave@ietf.org)>=0A> Objet : Re: [BEHAVE] Updated version of multicast = IPv4-embedded address format =0A>I-D=0A> =0A> Hi Med,=0A> Can you please= enlighten me =0A> =0A> =0A> The address format defined in this document = applies for both IPv4-=0A> IPv6 translation and encapsulation schemes.= =0A> =0A> why it would be needed for encapsulation schemes by referring to= =0A> =0A> draft-qin-softwire-dslite-multicast=0A> =0A> Thanks,=0A> =0A> Be= hcet=0A=0A=0A From zhangdong_rh@huaweisymantec.com Wed Feb 16 17:54:14 2011 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 DEA783A6EEC; Wed, 16 Feb 2011 17:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.709 X-Spam-Level: *** X-Spam-Status: No, score=3.709 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 i3eTEqYHH5K4; Wed, 16 Feb 2011 17:54:14 -0800 (PST) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 959AF3A6BA0; Wed, 16 Feb 2011 17:54:13 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_4znOfmVJn62G/Iu036WXCw)" 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 <0LGQ0071HNYWBH10@hstga02-in.huaweisymantec.com>; Thu, 17 Feb 2011 09:54:32 +0800 (CST) Received: from Z90001956Z ([10.27.136.91]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0LGQ00KV9NYTAZ20@hstml02-in.huaweisymantec.com>; Thu, 17 Feb 2011 09:54:32 +0800 (CST) Date: Thu, 17 Feb 2011 09:54:30 +0800 From: Dong Zhang To: v6ops References: <20110217011001.69BDE3A6D34@core3.amsl.com> Message-id: <201102170954297669884@huaweisymantec.com> X-Mailer: Foxmail 6, 10, 201, 20 [cn] Cc: "behave@ietf.org" Subject: [BEHAVE] Fw: New Version Notification for draft-zhang-v6ops-cgn-source-trace-00 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, 17 Feb 2011 01:54:15 -0000 This is a multi-part message in MIME format. --Boundary_(ID_4znOfmVJn62G/Iu036WXCw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgZm9sa3MsDQoNCldlIGhhdmUgcHJvcG9zZWQgYSBuZXcgZHJhZnQgYWJvdXQgdGhlIHNvdXJj ZSBhZGRyZXNzIHRyYWNpbmcgaXNzdWUuIA0KQXMgdGhlIENHTiBpcyBkZXBsb3llZCwgdGhlIElQ djQgYWRkcmVzcyB3aWxsIGJlIHNoYXJlZCBieSBtb3JlIHRoYW4gb25lIHVzZXJzLiBUaGUgZHJh ZnQgdGFsa3MgYWJvdXQgdGhlIHJlcXVpcmVtZW50cyBhbmQgdGhlIHNvbHV0aW9uIG1vZGVscyBm b3Igc291cmNlIGFkZHJlc3MgdHJhY2luZy4NCg0KV2VsY29tZSBjb21tZW50Lg0KVGhhbmtzLg0K DQoNCjIwMTEtMDItMTcNCg0KDQoNCkRvbmcgWmhhbmcNCg0KDQoNCg0Kt6K8/sjLo7ogSUVURiBJ LUQgU3VibWlzc2lvbiBUb29sDQq3osvNyrG85KO6IDIwMTEtMDItMTcgMDk6MTA6MzMNCsrVvP7I y6O6IHpoYW5nZG9uZ19yaEBodWF3ZWlzeW1hbnRlYy5jb20NCrOty82juiANCtb3zOKjuiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXpoYW5nLXY2b3BzLWNnbi1zb3VyY2UtdHJh Y2UtMDANCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtemhhbmctdjZvcHMtY2duLXNv dXJjZS10cmFjZS0wMC50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBEb25n IFpoYW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICBk cmFmdC16aGFuZy12Nm9wcy1jZ24tc291cmNlLXRyYWNlDQpSZXZpc2lvbjogIDAwDQpUaXRsZTog IFNvbHV0aW9uIE1vZGVsIG9mIFNvdXJjZSBBZGRyZXNzIFRyYWNpbmcgZm9yIENhcnJpZXIgR3Jh ZGUgTkFUIChDR04pDQpDcmVhdGlvbl9kYXRlOiAgMjAxMS0wMi0xNg0KV0cgSUQ6ICBJbmRlcGVu ZGVudCBTdWJtaXNzaW9uDQpOdW1iZXJfb2ZfcGFnZXM6IDgNCg0KQWJzdHJhY3Q6DQpTaW5jZSBO QVQgZnVuY3Rpb24gb24gQ0dOIGJveCB3aWxsIG1ha2UgdGhlIElQdjQgYWRkcmVzcyByZS11c2Vk IGJ5DQptb3JlIHRoYW4gb25lIHVzZXIsIHRoZSBwYWNrZXRzIHNlbnQgb3V0c2lkZSBDR04gYXJl IG5vdCBhYmxlIHRvIGJlDQppZGVudGlmaWQgd2hlcmUgdGhleSBhcmUgZnJvbSBvciB3aGljaCB1 c2VyIHRoZXkgYmVsb25nIHRvIGFjY29yZGluZw0KdG8gdGhlIHNvdXJjZSBhZGRyZXNzIHdpdGhp biB0aGUgcGFja2V0cy4gIEhvd2V2ZXIsIHVuZGVyIHNvbWUNCmNlcnRhaW4gY2lyY3Vtc3RhbmNl cywga25vd2luZyB0aGUgb3JpZ2luYWwgc291cmNlIElQIGFkZHJlc3MgYW5kIHRoZQ0KaWRlbnRp dHkgb2YgdGhlIHVzZXIgd2hvIHNlbmRzIHRoZSBwYWNrZXQgb3V0IGlzIG5lY2Vzc2FyeS4gIFRo aXMNCmRvY3VtZW50IHN0YXRlcyB0aGUgcmVxdWlyZW1lbnQgb2Ygc291cmNlIGFkZHJlc3MgdHJh Y2luZyBicmllZmx5LA0KYW5kIGRpc2N1c3NlcyB0aGUgcG9zc2libGUgc29sdXRpb24gbW9kZWxz IGZvciB0aGlzIGlzc3VlLg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRG IFNlY3JldGFyaWF0Lg0K --Boundary_(ID_4znOfmVJn62G/Iu036WXCw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOC4wMC43NjAwLjE2NzAwIj4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglmb250 LWZhbWlseTogy87M5TsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBWZXJkYW5hOw0K fQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDLzszlOw0KfQ0KQHBhZ2UgU2VjdGlvbjEg e3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4w cHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0NClAuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6 IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBw dDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0K TEkuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElH TjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcg Um9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNU SUZZOiBpbnRlci1pZGVvZ3JhcGg7IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgRk9OVC1TSVpFOiAxMC41cHQN Cn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9 DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5k ZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjog dW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxl OyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcgew0KCUZP TlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IENPTE9SOiB3aW5kb3d0ZXh0 OyBGT05ULVdFSUdIVDogbm9ybWFsOyBURVhULURFQ09SQVRJT046IG5vbmU7IG1zby1zdHlsZS10 eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rpb24x DQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQNCn0NCkJMT0NLUVVPVEUgew0KCU1BUkdJ Ti1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tTEVGVDogMmVtDQp9DQpPTCB7 DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NClVMIHsNCglNQVJHSU4t VE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KPC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZ IHN0eWxlPSJGT05ULUZBTUlMWTogdmVyZGFuYTsgRk9OVC1TSVpFOiAxMHB0Ij4NCjxESVY+PEZP TlQgY29sb3I9IzAwMDA4MCBzaXplPTIgZmFjZT1WZXJkYW5hPkhpIGZvbGtzLDwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxG T05UIGNvbG9yPSMwMDAwODA+V2UgaGF2ZSBwcm9wb3NlZCBhIG5ldyBkcmFmdCBhYm91dCB0aGUg c291cmNlIGFkZHJlc3MgDQp0cmFjaW5nIGlzc3VlLiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IGNvbG9yPSMwMDAwODA+QXMgdGhlIENHTiBpcyBkZXBsb3llZCwgdGhlIElQdjQgYWRkcmVzcyB3 aWxsIGJlIHNoYXJlZCANCmJ5IG1vcmUgdGhhbiBvbmUgdXNlcnMuIFRoZSBkcmFmdCB0YWxrcyBh Ym91dCB0aGUgcmVxdWlyZW1lbnRzIGFuZCB0aGUgc29sdXRpb24gDQptb2RlbHMgZm9yIHNvdXJj ZSBhZGRyZXNzIHRyYWNpbmcuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgw PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD5XZWxjb21lIGNv bW1lbnQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPlRoYW5rcy48L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+PC9GT05UPiZuYnNw OzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jYzBjMGMwIHNpemU9MiBmYWNlPVZlcmRhbmE+MjAx MS0wMi0xNzwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWIGFsaWduPWxlZnQ+DQo8RElWIGFsaWdu PWxlZnQ+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT4NCjxIUiBzdHlsZT0iV0lEVEg6IDEyMnB4 OyBIRUlHSFQ6IDJweCIgU0laRT0yPg0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0j YzBjMGMwPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNQQU4+DQo8RElWPg0KPERJVj48Rk9O VCBzaXplPTIgZmFjZT1WZXJkYW5hPkRvbmcgDQpaaGFuZzxCUj48L0ZPTlQ+PC9ESVY+PC9ESVY+ PC9TUEFOPjwvRk9OVD48L0RJVj48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFu YT4NCjxIUj4NCjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hPjxGT05UIHNp emU9Mj48U1RST05HPreivP7Iy6O6PC9TVFJPTkc+IElFVEYgSS1EIFN1Ym1pc3Npb24gDQpUb29s PC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hPjxGT05UIHNpemU9 Mj48U1RST05HPreiy83Ksbzko7o8L1NUUk9ORz4gDQoyMDExLTAyLTE3Jm5ic3A7MDk6MTA6MzM8 L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmE+PEZPTlQgc2l6ZT0y PjxTVFJPTkc+ytW8/sjLo7o8L1NUUk9ORz4gDQp6aGFuZ2RvbmdfcmhAaHVhd2Vpc3ltYW50ZWMu Y29tPC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hPjxGT05UIHNp emU9Mj48U1RST05HPrOty82jujwvU1RST05HPiA8L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPVZlcmRhbmE+PEZPTlQgc2l6ZT0yPjxTVFJPTkc+1vfM4qO6PC9TVFJPTkc+IE5l dyBWZXJzaW9uIA0KTm90aWZpY2F0aW9uIGZvciBkcmFmdC16aGFuZy12Nm9wcy1jZ24tc291cmNl LXRyYWNlLTAwPC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVy ZGFuYT48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5BJm5ic3A7bmV3Jm5ic3A7dmVyc2lvbiZuYnNwO29m Jm5ic3A7SS1ELCZuYnNwO2RyYWZ0LXpoYW5nLXY2b3BzLWNnbi1zb3VyY2UtdHJhY2UtMDAudHh0 Jm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3N1Y2Nlc3NmdWxseSZuYnNwO3N1Ym1pdHRlZCZuYnNw O2J5Jm5ic3A7RG9uZyZuYnNwO1poYW5nJm5ic3A7YW5kJm5ic3A7cG9zdGVkJm5ic3A7dG8mbmJz cDt0aGUmbmJzcDtJRVRGJm5ic3A7cmVwb3NpdG9yeS48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ DQo8RElWPkZpbGVuYW1lOiAmbmJzcDtkcmFmdC16aGFuZy12Nm9wcy1jZ24tc291cmNlLXRyYWNl PC9ESVY+DQo8RElWPlJldmlzaW9uOiAmbmJzcDswMDwvRElWPg0KPERJVj5UaXRsZTogDQombmJz cDtTb2x1dGlvbiZuYnNwO01vZGVsJm5ic3A7b2YmbmJzcDtTb3VyY2UmbmJzcDtBZGRyZXNzJm5i c3A7VHJhY2luZyZuYnNwO2ZvciZuYnNwO0NhcnJpZXImbmJzcDtHcmFkZSZuYnNwO05BVCZuYnNw OyhDR04pPC9ESVY+DQo8RElWPkNyZWF0aW9uX2RhdGU6ICZuYnNwOzIwMTEtMDItMTY8L0RJVj4N CjxESVY+V0cmbmJzcDtJRDogJm5ic3A7SW5kZXBlbmRlbnQmbmJzcDtTdWJtaXNzaW9uPC9ESVY+ DQo8RElWPk51bWJlcl9vZl9wYWdlczombmJzcDs4PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0K PERJVj5BYnN0cmFjdDo8L0RJVj4NCjxESVY+U2luY2UmbmJzcDtOQVQmbmJzcDtmdW5jdGlvbiZu YnNwO29uJm5ic3A7Q0dOJm5ic3A7Ym94Jm5ic3A7d2lsbCZuYnNwO21ha2UmbmJzcDt0aGUmbmJz cDtJUHY0Jm5ic3A7YWRkcmVzcyZuYnNwO3JlLXVzZWQmbmJzcDtieTwvRElWPg0KPERJVj5tb3Jl Jm5ic3A7dGhhbiZuYnNwO29uZSZuYnNwO3VzZXIsJm5ic3A7dGhlJm5ic3A7cGFja2V0cyZuYnNw O3NlbnQmbmJzcDtvdXRzaWRlJm5ic3A7Q0dOJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7YWJsZSZu YnNwO3RvJm5ic3A7YmU8L0RJVj4NCjxESVY+aWRlbnRpZmlkJm5ic3A7d2hlcmUmbmJzcDt0aGV5 Jm5ic3A7YXJlJm5ic3A7ZnJvbSZuYnNwO29yJm5ic3A7d2hpY2gmbmJzcDt1c2VyJm5ic3A7dGhl eSZuYnNwO2JlbG9uZyZuYnNwO3RvJm5ic3A7YWNjb3JkaW5nPC9ESVY+DQo8RElWPnRvJm5ic3A7 dGhlJm5ic3A7c291cmNlJm5ic3A7YWRkcmVzcyZuYnNwO3dpdGhpbiZuYnNwO3RoZSZuYnNwO3Bh Y2tldHMuJm5ic3A7Jm5ic3A7SG93ZXZlciwmbmJzcDt1bmRlciZuYnNwO3NvbWU8L0RJVj4NCjxE SVY+Y2VydGFpbiZuYnNwO2NpcmN1bXN0YW5jZXMsJm5ic3A7a25vd2luZyZuYnNwO3RoZSZuYnNw O29yaWdpbmFsJm5ic3A7c291cmNlJm5ic3A7SVAmbmJzcDthZGRyZXNzJm5ic3A7YW5kJm5ic3A7 dGhlPC9ESVY+DQo8RElWPmlkZW50aXR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDt1c2VyJm5ic3A7 d2hvJm5ic3A7c2VuZHMmbmJzcDt0aGUmbmJzcDtwYWNrZXQmbmJzcDtvdXQmbmJzcDtpcyZuYnNw O25lY2Vzc2FyeS4mbmJzcDsmbmJzcDtUaGlzPC9ESVY+DQo8RElWPmRvY3VtZW50Jm5ic3A7c3Rh dGVzJm5ic3A7dGhlJm5ic3A7cmVxdWlyZW1lbnQmbmJzcDtvZiZuYnNwO3NvdXJjZSZuYnNwO2Fk ZHJlc3MmbmJzcDt0cmFjaW5nJm5ic3A7YnJpZWZseSw8L0RJVj4NCjxESVY+YW5kJm5ic3A7ZGlz Y3Vzc2VzJm5ic3A7dGhlJm5ic3A7cG9zc2libGUmbmJzcDtzb2x1dGlvbiZuYnNwO21vZGVscyZu YnNwO2ZvciZuYnNwO3RoaXMmbmJzcDtpc3N1ZS48L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+VGhlJm5ic3A7SUVURiZuYnNwO1NlY3JldGFyaWF0LjwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPjwvRk9O VD48L0RJVj48L0ZPTlQ+PC9CT0RZPjwvSFRNTD4NCg== --Boundary_(ID_4znOfmVJn62G/Iu036WXCw)-- From ssenthil@cisco.com Wed Feb 16 23:25:04 2011 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 2B7223A6E83 for ; Wed, 16 Feb 2011 23:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.135 X-Spam-Level: X-Spam-Status: No, score=-7.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fY9o+xjEmIML for ; Wed, 16 Feb 2011 23:24:59 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 817B13A6D56 for ; Wed, 16 Feb 2011 23:24:59 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswGAJNcXE2rR7Hu/2dsb2JhbACCSpVDjTdRAnOgZJtChV4EhQqHBoNA X-IronPort-AV: E=Sophos;i="4.60,485,1291593600"; d="scan'208,217";a="408449957" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 17 Feb 2011 07:25:29 +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 p1H7PTmT016524 for ; Thu, 17 Feb 2011 07:25:29 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.4675); Wed, 16 Feb 2011 23:25:29 -0800 Received: from 72.163.191.177 ([72.163.191.177]) by xmb-sjc-236.amer.cisco.com ([128.107.191.121]) with Microsoft Exchange Server HTTP-DAV ; Thu, 17 Feb 2011 07:25:28 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 17 Feb 2011 02:26:08 -0500 From: ssenthil To: Message-ID: Thread-Topic: Handling of non-TCP/UDP/ICMP packets Thread-Index: AcvOc/GXC+cyhiCbMUu7QxUZfrLpMg== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3380754368_58669023" X-OriginalArrivalTime: 17 Feb 2011 07:25:29.0678 (UTC) FILETIME=[DAC02EE0:01CBCE73] Subject: [BEHAVE] Handling of non-TCP/UDP/ICMP packets 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, 17 Feb 2011 07:25:04 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3380754368_58669023 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable The stateless draft mentions that Next Header: For ICMPv4 (1) changed to ICMPv6 (58), otherwise protocol field MUST be copied from IPv4 header. The stateless draft states that: =20 If the incoming packet is an IPv4 packet that contains a protocol other than TCP, UDP or ICMPv4, then the packet SHOULD discarded and, if the security policy permits, the NAT64 SHOULD send an ICMPv4 Destination Unreachable error message with Code 2 (Protocol Unreachable) to the source address of the received packet Which is contradicting. So what should be the expected behavior, for stateless traffic the protocol MUST be copied over to the IPv6 header and for stateful traffic only TCP/UDP/ICMP packets should be translated? I don=B9= t remember the rationale for saying the non-TCP/UDP/ICMP packets to be dropped. (This is generic question that applies to both v6->v4 and v4->v6 =AD but just quoting it from the v4->v6 perspective). Thanks Senthil --B_3380754368_58669023 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Handling of non-TCP/UDP/ICMP packets The stateless draft mentions that

Next Header:  For ICMPv4 (1) changed to ICMPv6 (58), otherwise
      protocol field MUST be copied from IPv4= header.


The stateless draft states that:
 
  If the incoming packet is an IPv4 packet that contains a protoc= ol
   other than TCP, UDP or ICMPv4, then the packet SHOULD dis= carded and,
   if the security policy permits, the NAT64 SHOULD send an = ICMPv4
   Destination Unreachable error message with Code 2 (Protoc= ol
   Unreachable) to the source address of the received packet=

Which is contradicting. So what should be the expected behavior, for statel= ess traffic the protocol MUST be copied over to the IPv6 header and for stat= eful traffic only TCP/UDP/ICMP packets should be translated? I don’t r= emember the rationale for saying the non-TCP/UDP/ICMP packets to be dropped.= (This is generic question that applies to both v6->v4 and v4->v6 R= 11; but just quoting it from the v4->v6 perspective).

Thanks
Senthil --B_3380754368_58669023-- From behcetsarikaya@yahoo.com Thu Feb 17 08:23:07 2011 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 590503A6D59 for ; Thu, 17 Feb 2011 08:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 QncpuxHvUgr4 for ; Thu, 17 Feb 2011 08:23:06 -0800 (PST) Received: from nm11-vm0.bullet.mail.sp2.yahoo.com (nm11-vm0.bullet.mail.sp2.yahoo.com [98.139.91.240]) by core3.amsl.com (Postfix) with SMTP id 4C8703A6A25 for ; Thu, 17 Feb 2011 08:23:06 -0800 (PST) Received: from [98.139.91.61] by nm11.bullet.mail.sp2.yahoo.com with NNFMP; 17 Feb 2011 16:23:35 -0000 Received: from [98.139.91.24] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 17 Feb 2011 16:23:35 -0000 Received: from [127.0.0.1] by omp1024.mail.sp2.yahoo.com with NNFMP; 17 Feb 2011 16:23:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 173962.31438.bm@omp1024.mail.sp2.yahoo.com Received: (qmail 90782 invoked by uid 60001); 17 Feb 2011 16:23:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1297959814; bh=9VnPEGYNBGLZp46+s6IMHFkXBasDv8PpDoHBMNjswGg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=6SZQvZDYpLfpbVnFYP2Tz5XH6jCqdADSk8Cqp9mcBugnSbqmnd/399isCxsl20LsbZ5Qo7qmjhV6X3/kuDzyr0mbd+aO0bphgM2LqSEm1nEqRfn+KWt0oLfV55iVxc5kBgViQLGC6/d/8VHrgsHzUz2XXIpDg/9IL3efOzcFdGA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fqAi7broHuUZRg65B2mIf2mKnNtCxsH90ZMGRDJR4xZ8oZxy3HVdNLN8JYIKb3DMYxet1r0h3/EyH8vqSb7Ek22F9ZJsQPvzgQavZ7kgT51qarIGfoMhpxKnMZR3g3I9SD8d/fZp7RoXCksNTdCXBK6YGkIIneEhYdudCHh1Rgg=; Message-ID: <882341.89762.qm@web111416.mail.gq1.yahoo.com> X-YMail-OSG: Owg.HhEVM1mEmGRsI6Ys9iv91Q.i9JqN8Qek2YyUW1nYnU2 N_oju6NBlRj4SXHxj0CfsS8MuDZ7PssOWtSssipD1DpLXR9loQpsUs5meobU DChE4kjbvdhNTSu4.os1kPBLfU.QS7yhf1xFRy2zbAL6MPyvU3SBpUhwFXDN 0CnenlAEkM7CYF2ClVPCIFDCwQgOCSZ0QBAUhI4C6NY8gJirJCwh45pdeJwT OLiKZFSBTkfjBXPYeAOTvDNWWYqmb10_S.W3.VWAc5j6dVSsZfwasSwUIv1N oc3WY8nYiY0ssJSvKmtzTCdNPLgkHEnhX1yUpqgYrVwymfeAKwOj0Mq65MZL oautM6jeFz5NJ6tabgqX4pdTa.DTzos2SXF8_B_VBQYEFrmar.QRcsMe2PL6 VX21GQKY.eeoM Received: from [206.16.17.212] by web111416.mail.gq1.yahoo.com via HTTP; Thu, 17 Feb 2011 08:23:34 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.109.292656 References: <20110119183002.30410.51185.idtracker@localhost> <98A16B2D00B5724F81E80EF1927A029703FC95@nasanexd01e.na.qualcomm.com> <31963_1297088150_4D4FFE96_31963_99436_1_94C682931C08B048B7A8645303FDC9F33C44015A86@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 17 Feb 2011 08:23:34 -0800 (PST) From: Behcet Sarikaya To: mohamed.boucadair@orange-ftgroup.com In-Reply-To: <31963_1297088150_4D4FFE96_31963_99436_1_94C682931C08B048B7A8645303FDC9F33C44015A86@PUEXCB1B.nanterre.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 'behave' Subject: [BEHAVE] [behave] address format draft X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 16:23:07 -0000 Hi Med,=0A=A0 I read draft-qin-softwire-dslite-multicast. =0AQualifying thi= s draft as encapsulation draft IMHO is wrong. It does translation =0Afor IG= MP into MLD but it uses encapsulation for multicast data.=0A=0AAs such it i= s hybrid.=0A=0AThat is why (due to translation) you need address translatio= n not due to =0Aencapsulation.=0A=0ATake away for your address format I-D: = there is no case for encapsulation, but =0Athere is only for translation. = =0A=0A=0A=0A=0ARegards,=0A=0ABehcet=0A=0A=0A From huitema@microsoft.com Thu Feb 17 08:55:32 2011 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 6B5AD3A6C3C for ; Thu, 17 Feb 2011 08:55:32 -0800 (PST) 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 oziJ+CvVNEyz for ; Thu, 17 Feb 2011 08:55:27 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 601273A6CB4 for ; Thu, 17 Feb 2011 08:55:27 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 17 Feb 2011 08:55:58 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.270.2; Thu, 17 Feb 2011 08:55:58 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.204]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Thu, 17 Feb 2011 08:55:57 -0800 From: Christian Huitema To: ssenthil , "behave@ietf.org" Thread-Topic: Handling of non-TCP/UDP/ICMP packets Thread-Index: AcvOc/GXC+cyhiCbMUu7QxUZfrLpMgAT2O0g Date: Thu, 17 Feb 2011 16:55:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_CEBCE3CF81D2D441B14B84256C3C46810BD9E516TK5EX14MBXW651w_" MIME-Version: 1.0 Subject: Re: [BEHAVE] Handling of non-TCP/UDP/ICMP packets 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, 17 Feb 2011 16:55:32 -0000 --_000_CEBCE3CF81D2D441B14B84256C3C46810BD9E516TK5EX14MBXW651w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There are many NAT44 that pass other protocols than TCP/UDP/ICMP. For examp= le, many use various heuristics to match incoming and outgoing IPSEC contex= ts. Is the intent to ban such support? From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= ssenthil Sent: Wednesday, February 16, 2011 11:26 PM To: behave@ietf.org Subject: [BEHAVE] Handling of non-TCP/UDP/ICMP packets The stateless draft mentions that Next Header: For ICMPv4 (1) changed to ICMPv6 (58), otherwise protocol field MUST be copied from IPv4 header. The stateless draft states that: If the incoming packet is an IPv4 packet that contains a protocol other than TCP, UDP or ICMPv4, then the packet SHOULD discarded and, if the security policy permits, the NAT64 SHOULD send an ICMPv4 Destination Unreachable error message with Code 2 (Protocol Unreachable) to the source address of the received packet Which is contradicting. So what should be the expected behavior, for statel= ess traffic the protocol MUST be copied over to the IPv6 header and for sta= teful traffic only TCP/UDP/ICMP packets should be translated? I don't remem= ber the rationale for saying the non-TCP/UDP/ICMP packets to be dropped. (T= his is generic question that applies to both v6->v4 and v4->v6 - but just q= uoting it from the v4->v6 perspective). Thanks Senthil --_000_CEBCE3CF81D2D441B14B84256C3C46810BD9E516TK5EX14MBXW651w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Handling of non-TCP/UDP/ICMP packets<= /title><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f= ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>There are= many NAT44 that pass other protocols than TCP/UDP/ICMP. For example, many = use various heuristics to match incoming and outgoing IPSEC contexts. Is th= e intent to ban such support?  <o:p></o:p></span></p><p class=3DMsoNor= mal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";colo= r:#1F497D'><o:p> </o:p></span></p><div><div style=3D'border:none;borde= r-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoNormal><= b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:<= /span></b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"= '> behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] <b>On Behalf Of= </b>ssenthil<br><b>Sent:</b> Wednesday, February 16, 2011 11:26 PM<br><b>T= o:</b> behave@ietf.org<br><b>Subject:</b> [BEHAVE] Handling of non-TCP/UDP/= ICMP packets<o:p></o:p></span></p></div></div><p class=3DMsoNormal><o:p>&nb= sp;</o:p></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-fami= ly:"Calibri","sans-serif"'>The stateless draft mentions that <br><br>Next H= eader:  For ICMPv4 (1) changed to ICMPv6 (58), otherwise<br> &nbs= p;    protocol field MUST be copied from IPv4 header.<b= r><br><br>The stateless draft states that:<br> <br>  If the = incoming packet is an IPv4 packet that contains a protocol<br>  &= nbsp;other than TCP, UDP or ICMPv4, then the packet SHOULD discarded and,<b= r>   if the security policy permits, the NAT64 SHOULD send a= n ICMPv4<br>   Destination Unreachable error message with Co= de 2 (Protocol<br>   Unreachable) to the source address of t= he received packet<br><br>Which is contradicting. So what should be the exp= ected behavior, for stateless traffic the protocol MUST be copied over to t= he IPv6 header and for stateful traffic only TCP/UDP/ICMP packets should be= translated? I don’t remember the rationale for saying the non-TCP/UD= P/ICMP packets to be dropped. (This is generic question that applies to bot= h v6->v4 and v4->v6 – but just quoting it from the v4->v6 pe= rspective). <br><br>Thanks<br>Senthil</span> <o:p></o:p></p></div></body></= html>= --_000_CEBCE3CF81D2D441B14B84256C3C46810BD9E516TK5EX14MBXW651w_-- From dwing@cisco.com Thu Feb 17 10:22:00 2011 Return-Path: <dwing@cisco.com> 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 636D33A6E2C for <behave@core3.amsl.com>; Thu, 17 Feb 2011 10:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.277 X-Spam-Level: X-Spam-Status: No, score=-110.277 tagged_above=-999 required=5 tests=[AWL=0.322, 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 LKOXM-z12rcx for <behave@core3.amsl.com>; Thu, 17 Feb 2011 10:21:58 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 995FF3A6D60 for <behave@ietf.org>; Thu, 17 Feb 2011 10:21:58 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.62,181,1297036800"; d="scan'208";a="408630911" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 17 Feb 2011 18:22:30 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p1HIMTL2005490; Thu, 17 Feb 2011 18:22:30 GMT From: "Dan Wing" <dwing@cisco.com> To: "'Christian Huitema'" <huitema@microsoft.com>, "'ssenthil'" <ssenthil@cisco.com>, <behave@ietf.org> References: <C98237C0.3D15%ssenthil@cisco.com> <CEBCE3CF81D2D441B14B84256C3C46810BD9E516@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <CEBCE3CF81D2D441B14B84256C3C46810BD9E516@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 17 Feb 2011 10:22:29 -0800 Message-ID: <055101cbcecf$a2f3cd30$e8db6790$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvOc/GXC+cyhiCbMUu7QxUZfrLpMgAT2O0gAAL+3XA= Content-Language: en-us Subject: Re: [BEHAVE] Handling of non-TCP/UDP/ICMP packets X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/behave> List-Post: <mailto:behave@ietf.org> List-Help: <mailto:behave-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 17 Feb 2011 18:22:00 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Christian Huitema > Sent: Thursday, February 17, 2011 8:56 AM > To: ssenthil; behave@ietf.org > Subject: Re: [BEHAVE] Handling of non-TCP/UDP/ICMP packets > > There are many NAT44 that pass other protocols than TCP/UDP/ICMP. For > example, many use various heuristics to match incoming and outgoing > IPSEC contexts. Those heuristics are not documented by the IETF. To my knowledge, they aren't documented anywhere. And to my knowledge, the heuristics used by IPsec SPI inspection are all stateful. -d > Is the intent to ban such support? > > > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of ssenthil > Sent: Wednesday, February 16, 2011 11:26 PM > To: behave@ietf.org > Subject: [BEHAVE] Handling of non-TCP/UDP/ICMP packets > > > > The stateless draft mentions that > > Next Header: For ICMPv4 (1) changed to ICMPv6 (58), otherwise > protocol field MUST be copied from IPv4 header. > > > The stateless draft states that: > > If the incoming packet is an IPv4 packet that contains a protocol > other than TCP, UDP or ICMPv4, then the packet SHOULD discarded and, > if the security policy permits, the NAT64 SHOULD send an ICMPv4 > Destination Unreachable error message with Code 2 (Protocol > Unreachable) to the source address of the received packet > > Which is contradicting. So what should be the expected behavior, for > stateless traffic the protocol MUST be copied over to the IPv6 header > and for stateful traffic only TCP/UDP/ICMP packets should be > translated? I don't remember the rationale for saying the non- > TCP/UDP/ICMP packets to be dropped. (This is generic question that > applies to both v6->v4 and v4->v6 - but just quoting it from the v4->v6 > perspective). > > Thanks > Senthil From jacniq@gmail.com Thu Feb 17 17:22:47 2011 Return-Path: <jacniq@gmail.com> 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 91F7B3A6D61 for <behave@core3.amsl.com>; Thu, 17 Feb 2011 17:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoZzUayuOTfJ for <behave@core3.amsl.com>; Thu, 17 Feb 2011 17:22:46 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 51A3E3A6C72 for <behave@ietf.org>; Thu, 17 Feb 2011 17:22:46 -0800 (PST) Received: by ywk9 with SMTP id 9so1518985ywk.31 for <behave@ietf.org>; Thu, 17 Feb 2011 17:23:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qebvQ9dJOsubS9A96tPKdqC0l8HxWE/lacAokGAiETo=; b=uJA56zL1Ne/+sXgaVc+MmteuPjdqSM9eh/IT1dCGxBbzKJD/bjamQiWFo2el9fill6 vexlteFVu2EVC57v7r7L7dCQMNa9jmBCmcLpfNEZYvvUIxB0xojsNPnMH835WRl3vxpm IR+PMHhgw5LaxjJUhgJXl0kwP58LAuwpkshHE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Y2tRh0sG5VVd4xcIDcfKfLH9zUuQxlGBReUfPf3GsuzUFBKJbGE9jbiwyfCm9OGhkR PkyS08izmLVgPnNet8qGszXzKjtDP9imkEPu7JIJNL74fTNoXUTvFDpQRWpb3slqqTSl vjK4DmkbjMirdn50Rq5F4LceFoxqe3KKpEJl0= MIME-Version: 1.0 Received: by 10.101.186.1 with SMTP id n1mr52484anp.209.1297992198308; Thu, 17 Feb 2011 17:23:18 -0800 (PST) Received: by 10.147.31.34 with HTTP; Thu, 17 Feb 2011 17:23:18 -0800 (PST) In-Reply-To: <882341.89762.qm@web111416.mail.gq1.yahoo.com> References: <20110119183002.30410.51185.idtracker@localhost> <98A16B2D00B5724F81E80EF1927A029703FC95@nasanexd01e.na.qualcomm.com> <31963_1297088150_4D4FFE96_31963_99436_1_94C682931C08B048B7A8645303FDC9F33C44015A86@PUEXCB1B.nanterre.francetelecom.fr> <882341.89762.qm@web111416.mail.gq1.yahoo.com> Date: Fri, 18 Feb 2011 09:23:18 +0800 Message-ID: <AANLkTinFxa0RFNB4K3pV1xWw7GMpBvwCvesLS1uAbJ9d@mail.gmail.com> From: Jacni Qin <jacniq@gmail.com> To: Behcet Sarikaya <sarikaya@ieee.org> Content-Type: multipart/alternative; boundary=00163691ff6ae6c5b7049c845bc7 Cc: behave <behave@ietf.org>, Behcet Sarikaya <behcetsarikaya@yahoo.com>, mohamed.boucadair@orange-ftgroup.com Subject: Re: [BEHAVE] [behave] address format draft X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/behave> List-Post: <mailto:behave@ietf.org> List-Help: <mailto:behave-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 18 Feb 2011 01:22:47 -0000 --00163691ff6ae6c5b7049c845bc7 Content-Type: text/plain; charset=ISO-8859-1 Hi Behcet, I'd rather not argue which category the mDS-Lite draft should be of, there were similar stories. While the RFC6052 is for both translation and encapsulation, see Section1.1 Cheers, Jacni On Fri, Feb 18, 2011 at 12:23 AM, Behcet Sarikaya <behcetsarikaya@yahoo.com>wrote: > Hi Med, > I read draft-qin-softwire-dslite-multicast. > Qualifying this draft as encapsulation draft IMHO is wrong. It does > translation > for IGMP into MLD but it uses encapsulation for multicast data. > > As such it is hybrid. > > That is why (due to translation) you need address translation not due to > encapsulation. > > Take away for your address format I-D: there is no case for encapsulation, > but > there is only for translation. > > > > > Regards, > > Behcet > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > --00163691ff6ae6c5b7049c845bc7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <font face=3D"verdana,sans-serif">Hi Behcet,<br><br>I'd rather not argu= e which category the mDS-Lite draft should be of, there were similar storie= s.<br>While the RFC6052 is for both translation and encapsulation, see Sect= ion1.1<br> <br><br>Cheers,<br>Jacni<br><br></font><br><div class=3D"gmail_quote">On Fr= i, Feb 18, 2011 at 12:23 AM, Behcet Sarikaya <span dir=3D"ltr"><<a href= =3D"mailto:behcetsarikaya@yahoo.com">behcetsarikaya@yahoo.com</a>></span= > wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi Med,<br> =A0 I read draft-qin-softwire-dslite-multicast.<br> Qualifying this draft as encapsulation draft IMHO is wrong. It does transla= tion<br> for IGMP into MLD but it uses encapsulation for multicast data.<br> <br> As such it is hybrid.<br> <br> That is why (due to translation) you need address translation not due to<br= > encapsulation.<br> <br> Take away for your address format I-D: there is no case for encapsulation, = but<br> there is only for translation.<br> <br> <br> <br> <br> Regards,<br> <br> Behcet<br> <br> <br> <br> _______________________________________________<br> Behave mailing list<br> <a href=3D"mailto:Behave@ietf.org">Behave@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/behave" target=3D"_blank">= https://www.ietf.org/mailman/listinfo/behave</a><br> </blockquote></div><br> --00163691ff6ae6c5b7049c845bc7-- From yiu_lee@cable.comcast.com Thu Feb 17 17:38:35 2011 Return-Path: <yiu_lee@cable.comcast.com> 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 05C5A3A6C72 for <behave@core3.amsl.com>; Thu, 17 Feb 2011 17:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.619 X-Spam-Level: X-Spam-Status: No, score=-104.619 tagged_above=-999 required=5 tests=[AWL=3.844, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3O1tRycYfi0l for <behave@core3.amsl.com>; Thu, 17 Feb 2011 17:38:34 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id EC5C73A6C3E for <behave@ietf.org>; Thu, 17 Feb 2011 17:38:33 -0800 (PST) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.114137420; Thu, 17 Feb 2011 20:39:02 -0500 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Thu, 17 Feb 2011 20:39:02 -0500 From: "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com> To: Behcet Sarikaya <sarikaya@ieee.org>, "mohamed.boucadair@orange-ftgroup.com" <mohamed.boucadair@orange-ftgroup.com> Thread-Topic: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D Thread-Index: AQHLzwye5zluq8k3j0qJgF2p/9m8Jg== Date: Fri, 18 Feb 2011 01:39:01 +0000 Message-ID: <C9833752.8BE5%yiu_lee@cable.comcast.com> In-Reply-To: <238315.35246.qm@web111411.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.13] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9BE57693FB69944590A0F2ABA81944DA@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'behave' <\(behave@ietf.org\)>" <behave@ietf.org> Subject: Re: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/behave> List-Post: <mailto:behave@ietf.org> List-Help: <mailto:behave-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 18 Feb 2011 01:38:35 -0000 Hi Behect, We are doing IPv4 multicast in the access network today. I foresee we will continue to do IPv6 multicast in the access network in the future. IMHO, multimob-pmipv6-base-solution is not simpler because it will require the fixed line operator to implement PMIP. I don't see this is a simple requirement. Regards, Yiu > > > >This is one way but IMHO it would be totally unnecessary to use >IPv4-embedded=20 >IPv6 address. I can not see the need for it except that you want to do >multicast=20 >routing in the access network. > >If you can lift this "requirement" then there is a much simpler solution, >I=20 >suggest looking into draft-ietf-multimob-pmipv6-base-solution > >Regards, > >Behcet > >> Cheers, >> Med >>=20 >> -----Message d'origine----- >> De : Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] >> Envoy=E9 : mardi 15 f=E9vrier 2011 18:50 >> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >> Cc : 'behave' <(behave@ietf.org)> >> Objet : Re: [BEHAVE] Updated version of multicast IPv4-embedded >>address format=20 >>I-D >>=20 >> Hi Med, >> Can you please enlighten me >>=20 >>=20 >> The address format defined in this document applies for both IPv4- >> IPv6 translation and encapsulation schemes. >>=20 >> why it would be needed for encapsulation schemes by referring to >>=20 >> draft-qin-softwire-dslite-multicast >>=20 >> Thanks, >>=20 >> Behcet > > > =20 >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From yiu_lee@cable.comcast.com Thu Feb 17 17:44:18 2011 Return-Path: <yiu_lee@cable.comcast.com> 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 099253A6D61 for <behave@core3.amsl.com>; Thu, 17 Feb 2011 17:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.388 X-Spam-Level: X-Spam-Status: No, score=-105.388 tagged_above=-999 required=5 tests=[AWL=3.075, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7QKg7jk9lYh for <behave@core3.amsl.com>; Thu, 17 Feb 2011 17:44:17 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id EAEB23A6C28 for <behave@ietf.org>; Thu, 17 Feb 2011 17:44:16 -0800 (PST) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.114137644; Thu, 17 Feb 2011 20:44:43 -0500 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Thu, 17 Feb 2011 20:44:44 -0500 From: "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com> To: Behcet Sarikaya <sarikaya@ieee.org>, "mohamed.boucadair@orange-ftgroup.com" <mohamed.boucadair@orange-ftgroup.com> Thread-Topic: [BEHAVE] [behave] address format draft Thread-Index: AQHLzw1pw0HM7FlPjkGrPd8mLAsCSQ== Date: Fri, 18 Feb 2011 01:44:42 +0000 Message-ID: <C98337FF.8BE8%yiu_lee@cable.comcast.com> In-Reply-To: <882341.89762.qm@web111416.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.13] Content-Type: text/plain; charset="us-ascii" Content-ID: <82DA72A6D51252499BE4D3751A560267@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'behave' <behave@ietf.org> Subject: Re: [BEHAVE] [behave] address format draft X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/behave> List-Post: <mailto:behave@ietf.org> List-Help: <mailto:behave-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 18 Feb 2011 01:44:18 -0000 Hi Behcet, The mcast address format draft discusses how to embed an IPv4 group address in an IPv6 group address. It doesn't discuss how IPv4-IPv6 multicast should be implemented. We reference "draft-qin-softwire-dslite-multicast" in the draft because it requires a standard format to embed the IPv4 multicast address to make the encapsulation possible. This is also true for the mesh-multicast draft. Regards, Yiu On 2/17/11 11:23 AM, "Behcet Sarikaya" <behcetsarikaya@yahoo.com> wrote: >Hi Med, > I read draft-qin-softwire-dslite-multicast. >Qualifying this draft as encapsulation draft IMHO is wrong. It does >translation=20 >for IGMP into MLD but it uses encapsulation for multicast data. > >As such it is hybrid. > >That is why (due to translation) you need address translation not due to >encapsulation. > >Take away for your address format I-D: there is no case for >encapsulation, but >there is only for translation. > > > > >Regards, > >Behcet > > > =20 >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From xing@cernet.edu.cn Thu Feb 17 21:34:51 2011 Return-Path: <xing@cernet.edu.cn> 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 757A23A6C4E for <behave@core3.amsl.com>; Thu, 17 Feb 2011 21:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.903 X-Spam-Level: X-Spam-Status: No, score=-99.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696, 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 NS2QSLU0FxZb for <behave@core3.amsl.com>; Thu, 17 Feb 2011 21:34:49 -0800 (PST) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by core3.amsl.com (Postfix) with SMTP id 103EA3A6B77 for <behave@ietf.org>; Thu, 17 Feb 2011 21:34:48 -0800 (PST) Received: from [202.38.110.1]([202.38.110.1]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54d5e26bf; Fri, 18 Feb 2011 13:35:20 +0800 Message-ID: <4D5E050D.5040409@cernet.edu.cn> Date: Fri, 18 Feb 2011 13:35:09 +0800 From: Xing Li <xing@cernet.edu.cn> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com> References: <C97EAD90.887B%yiu_lee@cable.comcast.com> In-Reply-To: <C97EAD90.887B%yiu_lee@cable.comcast.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: xowzSqZB Cc: Stig Venaas <stig@venaas.com>, "'behave' \(behave@ietf.org\)" <behave@ietf.org> Subject: Re: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/behave> List-Post: <mailto:behave@ietf.org> List-Help: <mailto:behave-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 18 Feb 2011 05:34:51 -0000 >> The CERNET2 IPv6-only backbone is an example, which provides IPv6 >> unicast and SSM services. The customer's ASM application is provided >> cross SSM backbone. > [YL] This is a valid use case. I am just curious how the ASM-SSM > translation happens. How does the translator learns the IPv6 source of the > SSM? Do you provision some kind of mapping? Currently, it is via distributed servers. xing >>> I would like this format to be generic and support all the >>> different cases where you may want to embed an IPv4 multicast >>> address in an IPv6 multicast address. >> Agree. Since we are talking about IPv4/IPv6 interaction, if we believe >> there will be IPv6-only Internet in the future, we should define as >> little as possible in the transition and coexistent time. >> > [YL] I also agreed. > >>> If we restrict the usage, then it must be for a good reason. >>> If some use case or implementation only accepts ASM in ASM, then >>> they can check the address and discard it if say SSM in ASM. >>> >>> Can you guys provide examples or reasons for restricting it? >>> I will also try to think about reasons both for and against, >>> > [YL] No, I disagree to restrict this. We are on the same page. We should > remove the current restriction from the ID. > > > From zhangdong_rh@huaweisymantec.com Fri Feb 18 00:10:36 2011 Return-Path: <zhangdong_rh@huaweisymantec.com> 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 2F6DE3A6DF8; Fri, 18 Feb 2011 00:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.709 X-Spam-Level: *** X-Spam-Status: No, score=3.709 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 xZbOlXQ8Z7zt; Fri, 18 Feb 2011 00:10:35 -0800 (PST) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id B0EFF3A6CE6; Fri, 18 Feb 2011 00:10:34 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_5Pwco46EAL1YTTGNiuvogQ)" 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 <0LGT00445029OT70@hstga02-in.huaweisymantec.com>; Fri, 18 Feb 2011 16:10:57 +0800 (CST) Received: from Z90001956Z ([10.27.136.91]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0LGT000G7025GN00@hstml02-in.huaweisymantec.com>; Fri, 18 Feb 2011 16:10:57 +0800 (CST) Date: Fri, 18 Feb 2011 16:10:53 +0800 From: Dong Zhang <zhangdong_rh@huaweisymantec.com> To: Joel Jaeggli <joelja@bogus.com>, draft-zhang-v6ops-cgn-source-tra <draft-zhang-v6ops-cgn-source-trace@tools.ietf.org>, IPv6 Ops WG <v6ops@ietf.org>, behave <behave@ietf.org> References: <4D5E160D.2010409@bogus.com> Message-id: <201102181610534957820@huaweisymantec.com> X-Mailer: Foxmail 6, 10, 201, 20 [cn] Cc: David Harrington <ietfdbh@comcast.net> Subject: Re: [BEHAVE] thoughts on the draft...http://tools.ietf.org/html/draft-zhang-v6ops-cgn-source-trace-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/behave> List-Post: <mailto:behave@ietf.org> List-Help: <mailto:behave-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 18 Feb 2011 08:10:36 -0000 This is a multi-part message in MIME format. --Boundary_(ID_5Pwco46EAL1YTTGNiuvogQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgSm9lbCwNCg0KVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlLg0KUGxlYXNlIHNlZSBpbmxpbmVz Lg0KDQoNCg0KDQq3orz+yMujuiBKb2VsIEphZWdnbGkgDQq3osvNyrG85KO6IDIwMTEtMDItMTgg IDE0OjQ4OjA2IA0KytW8/sjLo7ogZHJhZnQtemhhbmctdjZvcHMtY2duLXNvdXJjZS10cmFjZUB0 b29scy5pZXRmLm9yZzsgSVB2NiBPcHMgV0cgDQqzrcvNo7ogRGF2aWQgSGFycmluZ3RvbiANCtb3 zOKjuiB0aG91Z2h0cyBvbiB0aGUgZHJhZnQuLi5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC16aGFuZy12Nm9wcy1jZ24tc291cmNlLXRyYWNlLTAwIA0KIA0KVGhlIHF1ZXN0aW9uICJ3 aG9zZSB1c2luZyB0aGlzIHNvdXJjZS9kZXN0L3Nwb3J0L2Rwb3J0IHR1cHBsZSBpcyByaWdodA0K bm93IiByZWFsbHkgbWVhbnMsIHdoZW4gSSBvcmlnaW5hdGVkIHRoZSBxdWVzdGlvbi4NCg0KdGhl IHF1ZXN0aW9uIGlzIGFsd2F5cyBpbiB0aGUgcGFzdCB0ZW5zZSAod2hvIHdhcyB1c2luZyBpdCBh dCB0aW1lLXQsDQpldmVuIGluIHRoZSBjYXNlIG9mIGFuIG9uZ2luZyBjb25uZWN0aW9uKQ0KDQp3 ZSBhbnN3ZXIgdGhpcyBxdWVzdGlvbiBpbiB0aGUgY29udGV4dCBvZiB3ZWJzZXJ2ZXJzIGFsbCB0 aGUgdGltZS4NCg0KSSB0aGluayB0aGlzIGRyYWZ0IGNvdWxkIHByb2JhYmx5IGJlIHR1cm5lZCBp bnRvIGEgcmVhc29uYWJsZSBzdGF0ZW1lbnQNCm9mIHRoZSBwcm9ibGVtLCBidXQgSSBkb24ndCB0 aGluayB0aGVyZSdzIHJlYWxseSBhIG1ham9yIGRpZmZlcmVuY2UNCmJldHdlZW4gdGhlIHR3byBj YXNlcy4NCg0KKioqKioqKioqKioqKioqKioqKioqKioqDQpbRG9uZ10gSWYgSSB1bmRlcnN0YW5k IHlvdXIgY29tbWVudCBjb3JyZWN0bHksIEkgdGhpbmsgdGhlcmUgaXMgYSBtaXN1bmRlcnN0YW5k aW5nLiANCg0KSSBhZ3Jlc3MgdGhhdCB3aGVuIGFueSBxdWVyeSBhY3Rpb24gaGFwcGVucywgdGhl IGluZm9ybWF0aW9uIG9mIHRoZSBxdWVyeSBzaG91bGQgDQphbHJlYWR5IGhhdmUgYmVlbiBwcm9k dWNlZC4gVGh1cywgdGhlIGFuc3dlciBpcyBhbHdheXMgaW4gcGFzdCB0aW1lLiANCkJ1dCB3aGF0 IEkgYW0gdHJ5aW5nIHRvIHNheSBpbiB0aGUgZHJhZnQgaXMgdGhhdCB3aGVuIHNvdXJjZSB0cmFj aW5nIGJlaGF2aW9yIGhhcHBlbnMsIA0KdGhlIHNlc3Npb24gdHJhbnNsYXRpb24gYmluZGluZyBp cyBzdGlsbCBhY3RpdmUgb24gdGhlIENHTiBib3guIFRoaXMgY2FzZSBpcyBjYWxsZWQNCnJlbGF0 aW1lIHRyYWNpbmcuDQpUaGUgb3RoZXIgY2FzZSBpcyBub24tcmVsYXRpbWUgdHJhY2luZy4gQmVj YXVzZSB0aGUgbG9nIHNlcnZlciBzdG9yZXMgdGhlIGhpc3RvcnkgDQppbmZvcm1hdGlvbiwgd2hl biB0aGUgdHJhY2luZyBhY3Rpb24gaGFwcGVucywgdGhlIHNlc3Npb24gYmluZGluZyBoYXMgYmVl biBkZWxldGVkIG9uDQpDR04gYm94LiAgDQoqKioqKioqKioqKioqKioqKioqKioqKioNCg0KaWYg eW91IHdlcmUgbG9va2luZyBmb3IgYSBsb2NhdGlvbiBmb3IgdGhpcyB3b3JrIEkgd291bGQgY29u c2lkZXINCnRyYW5zcG9ydCBhbmQgc3BlY2lmaWNhbGx5IGJlaGF2ZSBhcyBwb3RlbnRpYWxseSBh cHByb3ByaWF0ZSBsb2NhdGlvbg0KZm9yIHN1Y2guDQoNCioqKioqKioqKioqKioqKioqKioqKioq Kg0KW0RvbmddIEkga25vdyBzZXZlcmFsIGNhcnJpZXJzIGhhdmUgcHJvcG9zZWQgdGhlIHNvdXJj ZSBhZGRyZXNzIHRyYWNpbmcgcmVxdWlyZW1lbnQgDQpleHBsaWNpdGx5LiBUaGV5IGFzayB0aGUg Q0dOIHZlbmRvcnMgZm9yIHRyYWNpbmcgc29sdXRpb24gd2hlbiB0aGV5IGNvbnNpZGVyIGRlcGxv eWluZyANCk5BVDQ0NCwgRFMtTGl0ZSBhbmQgTkFUNjQuIEJhc2VkIG9uIHRoaXMgcmVhc29uLCBp IHRoaW5rIGEgZ3VpZGFuY2UgZG9jdW1lbnQgbWF5IGJlIA0KbmVlZGVkLiANCg0KQWN0dWFsbHks IHRoZSBwcm9ibGVtIGhhcyBiZWVuIHBvaW50ZWQgb3V0IGluIGRyYWZ0LWlldGYtdjZvcHMtdjYt aW4tbW9iaWxlLW5ldHdvcmtzLTAzLg0KDQpkcmFmdC1pZXRmLXY2b3BzLXY2LWluLW1vYmlsZS1u ZXR3b3Jrcy0wMyBzYXlzOg0KDQogICBJbiBhZGRpdGlvbiB0byB0aGUgZGV2ZWxvcG1lbnRzIGNp dGVkIGFib3ZlLCBOQVQgcGxhY2VtZW50IGlzDQogICBpbXBvcnRhbnQgZm9yIG90aGVyIHJlYXNv bnMuICBBY2Nlc3MgbmV0d29ya3MgZ2VuZXJhbGx5IG5lZWQgdG8NCiAgIHByb2R1Y2UgbmV0d29y ayBhbmQgc2VydmljZSB1c2FnZSByZWNvcmRzIGZvciBiaWxsaW5nIGFuZCBhY2NvdW50aW5nLg0K ICAgVGhpcyBpcyB0cnVlIGZvciBtb2JpbGUgbmV0d29ya3MgYXMgd2VsbCB3aGVyZSAic3Vic2Ny aWJlcg0KICAgbWFuYWdlbWVudCIgZmVhdHVyZXMgKGkuZS4sIFFvUywgUG9saWN5LCBhbmQgQmls bGluZyBhbmQgQWNjb3VudGluZykNCiAgIGNhbiBiZSBmYWlybHkgZGV0YWlsZWQuICBTaW5jZSBh IE5BVCBpbnRyb2R1Y2VzIGEgYmluZGluZyBiZXR3ZWVuIHR3bw0KICAgYWRkcmVzc2VzLCB0aGUg YmluZGluZ3MgdGhlbXNlbHZlcyBiZWNvbWUgbmVjZXNzYXJ5IGluZm9ybWF0aW9uIGZvcg0KICAg c3Vic2NyaWJlciBtYW5hZ2VtZW50LiAgRm9yIGluc3RhbmNlLCB0aGUgb2ZmZXJlZCBRb1Mgb24g cHJpdmF0ZSBJUHY0DQogICBhZGRyZXNzIGFuZCB0aGUgKHNoYXJlZCkgcHVibGljIElQdjQgYWRk cmVzcyBtYXkgbmVlZCB0byBiZQ0KICAgY29ycmVsYXRlZCBmb3IgYWNjb3VudGluZyBwdXJwb3Nl cy4gIEFzIGFub3RoZXIgZXhhbXBsZSwgdGhlDQogICBBcHBsaWNhdGlvbiBTZXJ2ZXJzIHdpdGhp biB0aGUgcHJvdmlkZXIgbmV0d29yayBtYXkgbmVlZCB0byB0cmVhdA0KICAgdHJhZmZpYyBiYXNl ZCBvbiBwb2xpY3kgcHJvdmlkZWQgYnkgdGhlIFBDUkYuICBJZiB0aGUgSVAgYWRkcmVzcyBzZWVu DQogICBieSB0aGVzZSBBcHBsaWNhdGlvbiBTZXJ2ZXJzIGlzIG5vdCB1bmlxdWUsIHRoZSBQQ1JG IG5lZWRzIHRvIGJlIGFibGUNCiAgIHRvIGluc3BlY3QgdGhlIE5BVCBiaW5kaW5nIHRvIGRpc2Ft YmlndWF0ZSBhbW9uZyB0aGUgaW5kaXZpZHVhbCBNTnMuDQogICBBbmQsIHRoZSBzdWJzY3JpYmVy IHNlc3Npb24gbWFuYWdlbWVudCBpbmZvcm1hdGlvbiBhbmQgdGhlIHNlcnZpY2UNCiAgIHVzYWdl IGluZm9ybWF0aW9uIGFsc28gbmVlZCB0byBiZSBjb3JyZWxhdGVkIGluIG9yZGVyIHRvIHByb2R1 Y2UNCiAgIGhhcm1vbml6ZWQgcmVjb3Jkcy4gIEZ1cnRoZXJtb3JlLCB0aGVyZSBtYXkgYmUgbGVn YWwgcmVxdWlyZW1lbnRzIGZvcg0KICAgc3RvcmluZyB0aGUgTkFUIGJpbmRpbmcgcmVjb3Jkcy4g IEluZGVlZCwgdGhlc2UgcHJvYmxlbXMgZGlzYXBwZWFyDQogICB3aXRoIHRoZSB0cmFuc2l0aW9u IHRvIElQdjYuICBGb3Igbm93LCBpdCBzdWZmaWNlcyB0byBzdGF0ZSB0aGF0IE5BVA0KICAgaW50 cm9kdWNlcyBzdGF0ZSB3aGljaCBuZWVkcyB0byBiZSBjb3JyZWxhdGVkIGFuZCBwb3NzaWJseSBz dG9yZWQNCiAgIHdpdGggb3RoZXIgcm91dGluZSBzdWJzY3JpYmVyIGluZm9ybWF0aW9uLg0KDQoN Ckhvd2V2ZXIsIHRoZSBhaW0gb2YgZHJhZnQtemhhbmctdjZvcHMtY2duLXNvdXJjZS10cmFjZSBp cyBpbnRyb2R1Y2luZyB0aGUgZGVwbG95bWVudCANCm1vZGVscyBvZiBzb3VyY2UgdHJhY2luZyBz b2x1dGlvbi4gDQoNClRoYW5rIHlvdS4NCg0KKioqKioqKioqKioqKioqKioqKioqKioqDQoNCkkg d291bGQgYWxzbyBlbmNvdXJhZ2UgdGhlIGF1dGhvcnMgdG8gcG9uZGVyIHJmYyAyODA0IHdoZW4g Y29uc2lkZXJpbmcNCmhvdyBhbmQgdW5kZXIgd2hhdCBjaXJjdW1zdGFuY2VzIHRoZSBpZXRmIHdv dWxkIHVuZGVydGFrZSB0byBzdGFuZGFyZGl6ZQ0KdGhlIGZ1bmN0aW9uYWxpdHkgdGhlIHByb2Js ZW0gc3RhdGVtZW50IHJlcXVpcmVzLi4uDQoNClRyYW5zcG9ydCBBRCBjb3BpZWQgdG8gY2xvc2Ug bG9vcC4NCg== --Boundary_(ID_5Pwco46EAL1YTTGNiuvogQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOC4wMC43NjAwLjE2NzAwIj4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglmb250 LWZhbWlseTogy87M5TsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBWZXJkYW5hOw0K fQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDLzszlOw0KfQ0KQHBhZ2UgU2VjdGlvbjEg e3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4w cHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0NClAuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6 IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBw dDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0K TEkuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElH TjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcg Um9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNU SUZZOiBpbnRlci1pZGVvZ3JhcGg7IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgRk9OVC1TSVpFOiAxMC41cHQN Cn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9 DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5k ZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjog dW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxl OyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcgew0KCUZP TlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IENPTE9SOiB3aW5kb3d0ZXh0 OyBGT05ULVdFSUdIVDogbm9ybWFsOyBURVhULURFQ09SQVRJT046IG5vbmU7IG1zby1zdHlsZS10 eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rpb24x DQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQNCn0NCkJMT0NLUVVPVEUgew0KCU1BUkdJ Ti1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tTEVGVDogMmVtDQp9DQpPTCB7 DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NClVMIHsNCglNQVJHSU4t VE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KPC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZ IHN0eWxlPSJGT05ULUZBTUlMWTogdmVyZGFuYTsgRk9OVC1TSVpFOiAxMHB0Ij4NCjxESVY+PEZP TlQgY29sb3I9IzAwMDA4MCBzaXplPTIgZmFjZT1WZXJkYW5hPkhpIEpvZWwsPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgY29sb3I9IzAwMDA4MD5UaGFua3MgZm9yIHlvdXIgcmVzcG9uc2UuPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPlBsZWFzZSBzZWUgaW5saW5lcy48L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElWPjxGT05UIGNvbG9y PSMwMDAwODAgc2l6ZT0yIA0KZmFjZT1WZXJkYW5hPg0KPEhSPg0KPC9GT05UPg0KPERJVj48Rk9O VCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTVFJPTkc+t6K8/sjLo7o8L1NUUk9ORz4gSm9lbCBKYWVn Z2xpIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1RST05H Preiy83Ksbzko7o8L1NUUk9ORz4gMjAxMS0wMi0xOCZuYnNwOyAxNDo0ODowNiANCjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1RST05HPsrVvP7Iy6O6PC9T VFJPTkc+IA0KZHJhZnQtemhhbmctdjZvcHMtY2duLXNvdXJjZS10cmFjZUB0b29scy5pZXRmLm9y ZzsgSVB2NiBPcHMgV0cgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJk YW5hPjxTVFJPTkc+s63LzaO6PC9TVFJPTkc+IERhdmlkIEhhcnJpbmd0b24gDQo8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNUUk9ORz7W98zio7o8L1NUUk9O Rz4gdGhvdWdodHMgb24gdGhlIA0KZHJhZnQuLi5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC16aGFuZy12Nm9wcy1jZ24tc291cmNlLXRyYWNlLTAwIA0KPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjwvRk9OVD4gPC9ESVY+DQo8RElWPjxGT05UIHNp emU9MiBmYWNlPVZlcmRhbmE+DQo8RElWPlRoZSZuYnNwO3F1ZXN0aW9uJm5ic3A7Indob3NlJm5i c3A7dXNpbmcmbmJzcDt0aGlzJm5ic3A7c291cmNlL2Rlc3Qvc3BvcnQvZHBvcnQmbmJzcDt0dXBw bGUmbmJzcDtpcyZuYnNwO3JpZ2h0PC9ESVY+DQo8RElWPm5vdyImbmJzcDtyZWFsbHkmbmJzcDtt ZWFucywmbmJzcDt3aGVuJm5ic3A7SSZuYnNwO29yaWdpbmF0ZWQmbmJzcDt0aGUmbmJzcDtxdWVz dGlvbi48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPnRoZSZuYnNwO3F1ZXN0aW9uJm5i c3A7aXMmbmJzcDthbHdheXMmbmJzcDtpbiZuYnNwO3RoZSZuYnNwO3Bhc3QmbmJzcDt0ZW5zZSZu YnNwOyh3aG8mbmJzcDt3YXMmbmJzcDt1c2luZyZuYnNwO2l0Jm5ic3A7YXQmbmJzcDt0aW1lLXQs PC9ESVY+DQo8RElWPmV2ZW4mbmJzcDtpbiZuYnNwO3RoZSZuYnNwO2Nhc2UmbmJzcDtvZiZuYnNw O2FuJm5ic3A7b25naW5nJm5ic3A7Y29ubmVjdGlvbik8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ DQo8RElWPndlJm5ic3A7YW5zd2VyJm5ic3A7dGhpcyZuYnNwO3F1ZXN0aW9uJm5ic3A7aW4mbmJz cDt0aGUmbmJzcDtjb250ZXh0Jm5ic3A7b2YmbmJzcDt3ZWJzZXJ2ZXJzJm5ic3A7YWxsJm5ic3A7 dGhlJm5ic3A7dGltZS48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkkmbmJzcDt0aGlu ayZuYnNwO3RoaXMmbmJzcDtkcmFmdCZuYnNwO2NvdWxkJm5ic3A7cHJvYmFibHkmbmJzcDtiZSZu YnNwO3R1cm5lZCZuYnNwO2ludG8mbmJzcDthJm5ic3A7cmVhc29uYWJsZSZuYnNwO3N0YXRlbWVu dDwvRElWPg0KPERJVj5vZiZuYnNwO3RoZSZuYnNwO3Byb2JsZW0sJm5ic3A7YnV0Jm5ic3A7SSZu YnNwO2Rvbid0Jm5ic3A7dGhpbmsmbmJzcDt0aGVyZSdzJm5ic3A7cmVhbGx5Jm5ic3A7YSZuYnNw O21ham9yJm5ic3A7ZGlmZmVyZW5jZTwvRElWPg0KPERJVj5iZXR3ZWVuJm5ic3A7dGhlJm5ic3A7 dHdvJm5ic3A7Y2FzZXMuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4NCjxESVY+Kioq KioqKioqKioqKioqKioqKioqKioqPC9ESVY+DQo8RElWPltEb25nXSBJZiBJIHVuZGVyc3RhbmQg eW91ciBjb21tZW50IGNvcnJlY3RseSwgSSB0aGluayB0aGVyZSBpcyBhIA0KbWlzdW5kZXJzdGFu ZGluZy4gPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5JIGFncmVzcyB0aGF0IHdoZW4g YW55IHF1ZXJ5IGFjdGlvbiBoYXBwZW5zLCB0aGUmbmJzcDtpbmZvcm1hdGlvbiBvZiB0aGUgDQpx dWVyeSBzaG91bGQgPC9ESVY+DQo8RElWPmFscmVhZHkgaGF2ZSBiZWVuIHByb2R1Y2VkLiBUaHVz LCB0aGUgYW5zd2VyIGlzIGFsd2F5cyBpbiBwYXN0IHRpbWUuIDwvRElWPg0KPERJVj5CdXQgd2hh dCBJIGFtIHRyeWluZyB0byBzYXkgaW4gdGhlIGRyYWZ0IGlzIHRoYXQgd2hlbiZuYnNwO3NvdXJj ZSANCnRyYWNpbmcmbmJzcDtiZWhhdmlvciZuYnNwO2hhcHBlbnMsIDwvRElWPg0KPERJVj50aGUg c2Vzc2lvbiB0cmFuc2xhdGlvbiBiaW5kaW5nIGlzIHN0aWxsIGFjdGl2ZSBvbiB0aGUgQ0dOJm5i c3A7Ym94LiBUaGlzIA0KY2FzZSBpcyZuYnNwO2NhbGxlZDwvRElWPg0KPERJVj5yZWxhdGltZSB0 cmFjaW5nLjwvRElWPg0KPERJVj5UaGUgb3RoZXIgY2FzZSBpcyBub24tcmVsYXRpbWUgdHJhY2lu Zy4gQmVjYXVzZSB0aGUgbG9nIHNlcnZlciANCnN0b3JlcyZuYnNwO3RoZSBoaXN0b3J5IDwvRElW Pg0KPERJVj5pbmZvcm1hdGlvbiwgd2hlbiB0aGUgdHJhY2luZyBhY3Rpb24gaGFwcGVucywgdGhl IHNlc3Npb24gYmluZGluZyBoYXMgYmVlbiANCmRlbGV0ZWQmbmJzcDtvbjwvRElWPg0KPERJVj5D R04gYm94LiZuYnNwOyZuYnNwOzwvRElWPg0KPERJVj4qKioqKioqKioqKioqKioqKioqKioqKio8 L0RJVj48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPmlmJm5ic3A7eW91Jm5ic3A7d2Vy ZSZuYnNwO2xvb2tpbmcmbmJzcDtmb3ImbmJzcDthJm5ic3A7bG9jYXRpb24mbmJzcDtmb3ImbmJz cDt0aGlzJm5ic3A7d29yayZuYnNwO0kmbmJzcDt3b3VsZCZuYnNwO2NvbnNpZGVyPC9ESVY+DQo8 RElWPnRyYW5zcG9ydCZuYnNwO2FuZCZuYnNwO3NwZWNpZmljYWxseSZuYnNwO2JlaGF2ZSZuYnNw O2FzJm5ic3A7cG90ZW50aWFsbHkmbmJzcDthcHByb3ByaWF0ZSZuYnNwO2xvY2F0aW9uPC9ESVY+ DQo8RElWPmZvciZuYnNwO3N1Y2guPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4qKioq KioqKioqKioqKioqKioqKioqKio8L0RJVj4NCjxESVY+W0RvbmddIEkga25vdyBzZXZlcmFsIGNh cnJpZXJzIGhhdmUgcHJvcG9zZWQgdGhlIHNvdXJjZSBhZGRyZXNzIHRyYWNpbmcgDQpyZXF1aXJl bWVudCA8L0RJVj4NCjxESVY+ZXhwbGljaXRseS4gVGhleSBhc2sgdGhlIENHTiB2ZW5kb3JzIGZv ciB0cmFjaW5nJm5ic3A7c29sdXRpb24gd2hlbiB0aGV5IA0KY29uc2lkZXIgZGVwbG95aW5nIDwv RElWPg0KPERJVj5OQVQ0NDQsIERTLUxpdGUgYW5kIE5BVDY0LiBCYXNlZCBvbiB0aGlzIHJlYXNv biwgaSB0aGluayBhIGd1aWRhbmNlIA0KZG9jdW1lbnQgbWF5IGJlIDwvRElWPg0KPERJVj5uZWVk ZWQuIDwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+QWN0dWFsbHksIHRoZSBwcm9ibGVt IGhhcyBiZWVuIHBvaW50ZWQgb3V0IGluIA0KZHJhZnQtaWV0Zi12Nm9wcy12Ni1pbi1tb2JpbGUt bmV0d29ya3MtMDMuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5kcmFmdC1pZXRmLXY2 b3BzLXY2LWluLW1vYmlsZS1uZXR3b3Jrcy0wMyBzYXlzOjwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+Jm5ic3A7Jm5ic3A7IEluIGFkZGl0aW9uIHRvIHRoZSBkZXZlbG9wbWVudHMgY2l0 ZWQgYWJvdmUsIE5BVCBwbGFjZW1lbnQgDQppczxCUj4mbmJzcDsmbmJzcDsgaW1wb3J0YW50IGZv ciBvdGhlciByZWFzb25zLiZuYnNwOyBBY2Nlc3MgbmV0d29ya3MgZ2VuZXJhbGx5IA0KbmVlZCB0 bzxCUj4mbmJzcDsmbmJzcDsgcHJvZHVjZSBuZXR3b3JrIGFuZCBzZXJ2aWNlIHVzYWdlIHJlY29y ZHMgZm9yIGJpbGxpbmcgDQphbmQgYWNjb3VudGluZy48QlI+Jm5ic3A7Jm5ic3A7IFRoaXMgaXMg dHJ1ZSBmb3IgbW9iaWxlIG5ldHdvcmtzIGFzIHdlbGwgd2hlcmUgDQoic3Vic2NyaWJlcjxCUj4m bmJzcDsmbmJzcDsgbWFuYWdlbWVudCIgZmVhdHVyZXMgKGkuZS4sIFFvUywgUG9saWN5LCBhbmQg QmlsbGluZyANCmFuZCBBY2NvdW50aW5nKTxCUj4mbmJzcDsmbmJzcDsgY2FuIGJlIGZhaXJseSBk ZXRhaWxlZC4mbmJzcDsgU2luY2UgYSBOQVQgDQppbnRyb2R1Y2VzIGEgYmluZGluZyBiZXR3ZWVu IHR3bzxCUj4mbmJzcDsmbmJzcDsgYWRkcmVzc2VzLCB0aGUgYmluZGluZ3MgDQp0aGVtc2VsdmVz IGJlY29tZSBuZWNlc3NhcnkgaW5mb3JtYXRpb24gZm9yPEJSPiZuYnNwOyZuYnNwOyBzdWJzY3Jp YmVyIA0KbWFuYWdlbWVudC4mbmJzcDsgRm9yIGluc3RhbmNlLCB0aGUgb2ZmZXJlZCBRb1Mgb24g cHJpdmF0ZSBJUHY0PEJSPiZuYnNwOyZuYnNwOyANCmFkZHJlc3MgYW5kIHRoZSAoc2hhcmVkKSBw dWJsaWMgSVB2NCBhZGRyZXNzIG1heSBuZWVkIHRvIGJlPEJSPiZuYnNwOyZuYnNwOyANCmNvcnJl bGF0ZWQgZm9yIGFjY291bnRpbmcgcHVycG9zZXMuJm5ic3A7IEFzIGFub3RoZXIgZXhhbXBsZSwg DQp0aGU8QlI+Jm5ic3A7Jm5ic3A7IEFwcGxpY2F0aW9uIFNlcnZlcnMgd2l0aGluIHRoZSBwcm92 aWRlciBuZXR3b3JrIG1heSBuZWVkIHRvIA0KdHJlYXQ8QlI+Jm5ic3A7Jm5ic3A7IHRyYWZmaWMg YmFzZWQgb24gcG9saWN5IHByb3ZpZGVkIGJ5IHRoZSBQQ1JGLiZuYnNwOyBJZiB0aGUgDQpJUCBh ZGRyZXNzIHNlZW48QlI+Jm5ic3A7Jm5ic3A7IGJ5IHRoZXNlIEFwcGxpY2F0aW9uIFNlcnZlcnMg aXMgbm90IHVuaXF1ZSwgdGhlIA0KUENSRiBuZWVkcyB0byBiZSBhYmxlPEJSPiZuYnNwOyZuYnNw OyB0byBpbnNwZWN0IHRoZSBOQVQgYmluZGluZyB0byBkaXNhbWJpZ3VhdGUgDQphbW9uZyB0aGUg aW5kaXZpZHVhbCBNTnMuPEJSPiZuYnNwOyZuYnNwOyBBbmQsIHRoZSBzdWJzY3JpYmVyIHNlc3Np b24gbWFuYWdlbWVudCANCmluZm9ybWF0aW9uIGFuZCB0aGUgc2VydmljZTxCUj4mbmJzcDsmbmJz cDsgdXNhZ2UgaW5mb3JtYXRpb24gYWxzbyBuZWVkIHRvIGJlIA0KY29ycmVsYXRlZCBpbiBvcmRl ciB0byBwcm9kdWNlPEJSPiZuYnNwOyZuYnNwOyBoYXJtb25pemVkIHJlY29yZHMuJm5ic3A7IA0K RnVydGhlcm1vcmUsIHRoZXJlIG1heSBiZSBsZWdhbCByZXF1aXJlbWVudHMgZm9yPEJSPiZuYnNw OyZuYnNwOyBzdG9yaW5nIHRoZSBOQVQgDQpiaW5kaW5nIHJlY29yZHMuJm5ic3A7IEluZGVlZCwg dGhlc2UgcHJvYmxlbXMgZGlzYXBwZWFyPEJSPiZuYnNwOyZuYnNwOyB3aXRoIHRoZSANCnRyYW5z aXRpb24gdG8gSVB2Ni4mbmJzcDsgRm9yIG5vdywgaXQgc3VmZmljZXMgdG8gc3RhdGUgdGhhdCBO QVQ8QlI+Jm5ic3A7Jm5ic3A7IA0KaW50cm9kdWNlcyBzdGF0ZSB3aGljaCBuZWVkcyB0byBiZSBj b3JyZWxhdGVkIGFuZCBwb3NzaWJseSANCnN0b3JlZDxCUj4mbmJzcDsmbmJzcDsgd2l0aCBvdGhl ciByb3V0aW5lIHN1YnNjcmliZXIgaW5mb3JtYXRpb24uPEJSPjxCUj48L0RJVj4NCjxESVY+SG93 ZXZlciwgdGhlIGFpbSBvZiBkcmFmdC16aGFuZy12Nm9wcy1jZ24tc291cmNlLXRyYWNlIGlzIGlu dHJvZHVjaW5nIA0KdGhlJm5ic3A7ZGVwbG95bWVudCA8L0RJVj4NCjxESVY+bW9kZWxzIG9mIHNv dXJjZSB0cmFjaW5nIHNvbHV0aW9uLiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE SVY+VGhhbmsgeW91LjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+KioqKioqKioqKioq KioqKioqKioqKioqPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5JJm5ic3A7d291bGQm bmJzcDthbHNvJm5ic3A7ZW5jb3VyYWdlJm5ic3A7dGhlJm5ic3A7YXV0aG9ycyZuYnNwO3RvJm5i c3A7cG9uZGVyJm5ic3A7cmZjJm5ic3A7MjgwNCZuYnNwO3doZW4mbmJzcDtjb25zaWRlcmluZzwv RElWPg0KPERJVj5ob3cmbmJzcDthbmQmbmJzcDt1bmRlciZuYnNwO3doYXQmbmJzcDtjaXJjdW1z dGFuY2VzJm5ic3A7dGhlJm5ic3A7aWV0ZiZuYnNwO3dvdWxkJm5ic3A7dW5kZXJ0YWtlJm5ic3A7 dG8mbmJzcDtzdGFuZGFyZGl6ZTwvRElWPg0KPERJVj50aGUmbmJzcDtmdW5jdGlvbmFsaXR5Jm5i c3A7dGhlJm5ic3A7cHJvYmxlbSZuYnNwO3N0YXRlbWVudCZuYnNwO3JlcXVpcmVzLi4uPC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5UcmFuc3BvcnQmbmJzcDtBRCZuYnNwO2NvcGllZCZu YnNwO3RvJm5ic3A7Y2xvc2UmbmJzcDtsb29wLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj48L0ZP TlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== --Boundary_(ID_5Pwco46EAL1YTTGNiuvogQ)-- From ssenthil@cisco.com Fri Feb 18 02:53:59 2011 Return-Path: <ssenthil@cisco.com> 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 C155D3A6AF3 for <behave@core3.amsl.com>; Fri, 18 Feb 2011 02:53:59 -0800 (PST) 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 Kt3d2BI8dYSG for <behave@core3.amsl.com>; Fri, 18 Feb 2011 02:53:58 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C660A3A6F3D for <behave@ietf.org>; Fri, 18 Feb 2011 02:53:56 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsBAB/eXU2rR7Ht/2dsb2JhbACXV45Jc6EcmzGFXgSFC4pG X-IronPort-AV: E=Sophos;i="4.62,186,1297036800"; d="scan'208";a="408831596" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 18 Feb 2011 10:54:30 +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 p1IAsUnx012822; Fri, 18 Feb 2011 10:54:30 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.4675); Fri, 18 Feb 2011 02:54:30 -0800 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, 18 Feb 2011 02:54:29 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB0C506A1D@xmb-sjc-236.amer.cisco.com> In-Reply-To: <055101cbcecf$a2f3cd30$e8db6790$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Handling of non-TCP/UDP/ICMP packets Thread-Index: AcvOc/GXC+cyhiCbMUu7QxUZfrLpMgAT2O0gAAL+3XAAIbLywA== References: <C98237C0.3D15%ssenthil@cisco.com> <CEBCE3CF81D2D441B14B84256C3C46810BD9E516@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <055101cbcecf$a2f3cd30$e8db6790$@com> From: "Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com> To: "Dan Wing (dwing)" <dwing@cisco.com>, "Christian Huitema" <huitema@microsoft.com>, <behave@ietf.org> X-OriginalArrivalTime: 18 Feb 2011 10:54:30.0041 (UTC) FILETIME=[37CD7890:01CBCF5A] Subject: Re: [BEHAVE] Handling of non-TCP/UDP/ICMP packets X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/behave> List-Post: <mailto:behave@ietf.org> List-Help: <mailto:behave-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 18 Feb 2011 10:53:59 -0000 How about other protocols? Are we convinced that no other protocols would work without stateful processing of the individual protocols, so dropping is the right thing to do? It seems to me that we cannot know the answer that no other applications/protocols/deployments would work or not, without doing a lot of research and recommending dropping seems excessive. I have seen with nat44 GRE protocol will pass through and apparently was a deployed use case. Sure, you cannot do multiplexing in an effort to conserve IPv4 addresses but that is a known short coming that deployments may be willing to accept. Senthil -----Original Message----- From: Dan Wing (dwing)=20 Sent: Thursday, February 17, 2011 1:22 PM To: 'Christian Huitema'; Senthil Sivakumar (ssenthil); behave@ietf.org Subject: RE: [BEHAVE] Handling of non-TCP/UDP/ICMP packets > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Christian Huitema > Sent: Thursday, February 17, 2011 8:56 AM > To: ssenthil; behave@ietf.org > Subject: Re: [BEHAVE] Handling of non-TCP/UDP/ICMP packets >=20 > There are many NAT44 that pass other protocols than TCP/UDP/ICMP. For > example, many use various heuristics to match incoming and outgoing > IPSEC contexts. Those heuristics are not documented by the IETF. To my knowledge,=20 they aren't documented anywhere. And to my knowledge, the heuristics used by IPsec SPI inspection are all stateful. -d > Is the intent to ban such support? >=20 >=20 >=20 > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of ssenthil > Sent: Wednesday, February 16, 2011 11:26 PM > To: behave@ietf.org > Subject: [BEHAVE] Handling of non-TCP/UDP/ICMP packets >=20 >=20 >=20 > The stateless draft mentions that >=20 > Next Header: For ICMPv4 (1) changed to ICMPv6 (58), otherwise > protocol field MUST be copied from IPv4 header. >=20 >=20 > The stateless draft states that: >=20 > If the incoming packet is an IPv4 packet that contains a protocol > other than TCP, UDP or ICMPv4, then the packet SHOULD discarded and, > if the security policy permits, the NAT64 SHOULD send an ICMPv4 > Destination Unreachable error message with Code 2 (Protocol > Unreachable) to the source address of the received packet >=20 > Which is contradicting. So what should be the expected behavior, for > stateless traffic the protocol MUST be copied over to the IPv6 header > and for stateful traffic only TCP/UDP/ICMP packets should be > translated? I don't remember the rationale for saying the non- > TCP/UDP/ICMP packets to be dropped. (This is generic question that > applies to both v6->v4 and v4->v6 - but just quoting it from the v4->v6 > perspective). >=20 > Thanks > Senthil From behcetsarikaya@yahoo.com Fri Feb 18 08:10:11 2011 Return-Path: <behcetsarikaya@yahoo.com> 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 231903A6F08 for <behave@core3.amsl.com>; Fri, 18 Feb 2011 08:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 NKCxESoeJu2R for <behave@core3.amsl.com>; Fri, 18 Feb 2011 08:10:05 -0800 (PST) Received: from nm15.bullet.mail.sp2.yahoo.com (nm15.bullet.mail.sp2.yahoo.com [98.139.91.85]) by core3.amsl.com (Postfix) with SMTP id AEE753A6E69 for <behave@ietf.org>; Fri, 18 Feb 2011 08:10:05 -0800 (PST) Received: from [98.139.91.62] by nm15.bullet.mail.sp2.yahoo.com with NNFMP; 18 Feb 2011 16:10:39 -0000 Received: from [98.139.91.10] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 18 Feb 2011 16:10:39 -0000 Received: from [127.0.0.1] by omp1010.mail.sp2.yahoo.com with NNFMP; 18 Feb 2011 16:10:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 873656.4082.bm@omp1010.mail.sp2.yahoo.com Received: (qmail 93201 invoked by uid 60001); 18 Feb 2011 16:10:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1298045439; bh=QWPURWUJpDxpV1K5BZID5qBdwFBNGVXBiWpfxF99mNE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=2HIwJv1XHxBr1nARzaeNT81kJZK+Uyget18fpy/ll6t256Y+NxFMw96QSn3zHyECU53cVcxF7SyoPXIwxJBblxFyNWXElRJrH/+ua/ND8BIgVSuzJA4XfDNXku5HcWgOacJYChWESflwyBBPY247qE5aEP6ixQ4vh/T32oDGh8U= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=CkcuyKQxSpHDopHONdEvkjHK1ZfkzQnfM9GAPvspZo4NAJQQqk1gqgtyRfWAv1SUHuBlehvWcpU0yWDNSVepAYRy00RLwT8vLAadUYhp2+28lAGVLW/DfVu/OZeB2KVXMCbIaD2levYbyKYUU1Ke9MunPXFu6rJFquG7oq8ozrs=; Message-ID: <428869.93192.qm@web111415.mail.gq1.yahoo.com> X-YMail-OSG: zN6f78EVM1kvT6JFDsDeF8hrVjWncImX3zTqsLZMqnj2muW WfAdMHEzjrMLzwxkEySKgGV9Pjr87lJLmimBKSbjKyEM4QhNSbM_bz7yxbKG XwEG5IVS2uMz.sggr1LGT6ejEad0XmvIMEGImpBaz2UH51rDNxpU8mAffzco xgNgcfgMaf.DndgsP0bN2SHQ6MeGOoRnPRujzyxytgVv4DBX0IGjwfWp8jUp zGeMuSC6aMbMZtxsb.3VztyxHrgB4uxwJ3IfzF3l6L788HAmvVeNbQvHM.k5 iccJxvG06w08dz5UZcs10.Asa8Kq4qs_dMLsi9I5lo_1CuCdTsPRzioSTvvT SUgtBJzTTl87fDJKLhT7EqEZAWb970ELlrTDTsGF97QZCjJgXykyfK3hqcCt .TM8ATcMFG6Xx Received: from [206.16.17.212] by web111415.mail.gq1.yahoo.com via HTTP; Fri, 18 Feb 2011 08:10:39 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.109.292656 References: <20110119183002.30410.51185.idtracker@localhost> <98A16B2D00B5724F81E80EF1927A029703FC95@nasanexd01e.na.qualcomm.com> <31963_1297088150_4D4FFE96_31963_99436_1_94C682931C08B048B7A8645303FDC9F33C44015A86@PUEXCB1B.nanterre.francetelecom.fr> <882341.89762.qm@web111416.mail.gq1.yahoo.com> <AANLkTinFxa0RFNB4K3pV1xWw7GMpBvwCvesLS1uAbJ9d@mail.gmail.com> Date: Fri, 18 Feb 2011 08:10:39 -0800 (PST) From: Behcet Sarikaya <behcetsarikaya@yahoo.com> To: Jacni Qin <jacniq@gmail.com> In-Reply-To: <AANLkTinFxa0RFNB4K3pV1xWw7GMpBvwCvesLS1uAbJ9d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: behave <behave@ietf.org> Subject: Re: [BEHAVE] [behave] address format draft X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya <sarikaya@ieee.org> List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/behave> List-Post: <mailto:behave@ietf.org> List-Help: <mailto:behave-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 18 Feb 2011 16:10:11 -0000 My comment was referring to the S bit the draft had in -00. I said that is not needed. Having looked at -01, I realize that S bit has been abandoned. I am OK with it. I suggest that any discussion on encapsulation in draft-boucadair-behave-64-multicast-address-format be simply removed. Regards, Behcet > >Hi Behcet, > >I'd rather not argue which category the mDS-Lite draft should be of, there were >similar stories. >While the RFC6052 is for both translation and encapsulation, see Section1.1 > > >Cheers, >Jacni > > > >On Fri, Feb 18, 2011 at 12:23 AM, Behcet Sarikaya <behcetsarikaya@yahoo.com> >wrote: > >Hi Med, >> I read draft-qin-softwire-dslite-multicast. >>Qualifying this draft as encapsulation draft IMHO is wrong. It does translation >>for IGMP into MLD but it uses encapsulation for multicast data. >> >>As such it is hybrid. >> >>That is why (due to translation) you need address translation not due to >>encapsulation. >> >>Take away for your address format I-D: there is no case for encapsulation, but >>there is only for translation. >> >> >> >> >>Regards, >> >>Behcet >> >> >> >>_______________________________________________ >>Behave mailing list >>Behave@ietf.org >>https://www.ietf.org/mailman/listinfo/behave >> > From behcetsarikaya@yahoo.com Fri Feb 18 08:11:54 2011 Return-Path: <behcetsarikaya@yahoo.com> 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 AB8D33A6F30 for <behave@core3.amsl.com>; Fri, 18 Feb 2011 08:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 iz8hkx0nT3Rb for <behave@core3.amsl.com>; Fri, 18 Feb 2011 08:11:53 -0800 (PST) Received: from nm29-vm0.bullet.mail.sp2.yahoo.com (nm29-vm0.bullet.mail.sp2.yahoo.com [98.139.91.236]) by core3.amsl.com (Postfix) with SMTP id ECE0E3A6E69 for <behave@ietf.org>; Fri, 18 Feb 2011 08:11:53 -0800 (PST) Received: from [98.139.91.68] by nm29.bullet.mail.sp2.yahoo.com with NNFMP; 18 Feb 2011 16:12:28 -0000 Received: from [98.139.91.46] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 18 Feb 2011 16:12:28 -0000 Received: from [127.0.0.1] by omp1046.mail.sp2.yahoo.com with NNFMP; 18 Feb 2011 16:12:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 141209.85956.bm@omp1046.mail.sp2.yahoo.com Received: (qmail 80387 invoked by uid 60001); 18 Feb 2011 16:12:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1298045547; bh=jkPzy7PMm/2WyHAE8SPNBw4WX0/akDxayR24NEBF5Nw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=zZhee1gOJJ68nCyzGZZwmD1S7ctnYaeKI6td3fii2imXZuE7QtFpH6EL/SBki2n8wXIA/FoEuFwtg/gDtmO+s8NGUgiYsJY34ADyTiCaok8GPHQAjnDnAAmvljtXTdZtwdFD10z/0loZUNgl5zPVVnFCn9v0pGr/HSRKiefp6UA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=fqTAlUhub2bHu9t9eQ8leDhsNkI8d29ZsUaPBqaGnSjayXO7JS9K7j3IbkYrUfBNCnBX+7eNh9CLaoSwwkDSTLy79DTRJoB0SvMrvBmTmO+mzCrfxg5Ji5j7iXwebfEhN4XJkP2XVfGvszODquRaP4La0OaFUG8pVsq8EP2NSWI=; Message-ID: <828919.79769.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: FKdfwGoVM1lVcKYx6TP0WYRMkK0I3rPCyXhFgegilg_AEG2 Qy7vNA2bkhBDQyx11NJOJ5IwfoaLTvMClHd_zhYrP4Uuk7LLGNOm4kXTs8jv KKUCAa7o0d1c59r5elyhhc.nTis.KkGMFPC1ZxRire1wDnmK57HRUOu1Z9ax lx1POb_DJL57KDYzAGq0gvRprQDUteKMS2eZImDCseoJnatKY0_W0p2mnpgt B5W3gZ0MJGONNkLwK90S4bAoqBmdnEN6l880FJYDSntnY2rxgCLJJXabZE1B 9AYXgPOr1NOHg7Dxx2vnWo0SD3HUTT__Fd9sYlaNvZ6yvhvXBuYFBY9ggENT RTGxOrL273cGYb0MmdGxTurlOUjKRAa9r8SljPQiWLFeY8TFtefIEnqCZeOk rC8IrY1T7t4N5 Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Fri, 18 Feb 2011 08:12:27 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.109.292656 References: <C98337FF.8BE8%yiu_lee@cable.comcast.com> Date: Fri, 18 Feb 2011 08:12:27 -0800 (PST) From: Behcet Sarikaya <behcetsarikaya@yahoo.com> To: "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com> In-Reply-To: <C98337FF.8BE8%yiu_lee@cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: behave <behave@ietf.org> Subject: Re: [BEHAVE] [behave] address format draft X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya <sarikaya@ieee.org> List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/behave> List-Post: <mailto:behave@ietf.org> List-Help: <mailto:behave-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 18 Feb 2011 16:11:54 -0000 > Hi Behcet, > > The mcast address format draft discusses how to embed an IPv4 group > address in an IPv6 group address. It doesn't discuss how IPv4-IPv6 > multicast should be implemented. We reference > "draft-qin-softwire-dslite-multicast" in the draft because it requires a > standard format to embed the IPv4 multicast address to make the > encapsulation possible. This is also true for the mesh-multicast draft. > Yiu, please see my comments to Jacni. Regards, Behcet From behcetsarikaya@yahoo.com Fri Feb 18 08:13:54 2011 Return-Path: <behcetsarikaya@yahoo.com> 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 34ECB3A6E67 for <behave@core3.amsl.com>; Fri, 18 Feb 2011 08:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 QEmrSc1Hi1xs for <behave@core3.amsl.com>; Fri, 18 Feb 2011 08:13:53 -0800 (PST) Received: from nm25-vm0.bullet.mail.ne1.yahoo.com (nm25-vm0.bullet.mail.ne1.yahoo.com [98.138.91.73]) by core3.amsl.com (Postfix) with SMTP id 4A02A3A6E27 for <behave@ietf.org>; Fri, 18 Feb 2011 08:13:53 -0800 (PST) Received: from [98.138.90.55] by nm25.bullet.mail.ne1.yahoo.com with NNFMP; 18 Feb 2011 16:14:23 -0000 Received: from [98.138.89.253] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 18 Feb 2011 16:14:23 -0000 Received: from [127.0.0.1] by omp1045.mail.ne1.yahoo.com with NNFMP; 18 Feb 2011 16:14:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 897250.95160.bm@omp1045.mail.ne1.yahoo.com Received: (qmail 52076 invoked by uid 60001); 18 Feb 2011 16:14:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1298045663; bh=jwcmO7I3/0GoXrODnqdOaIKFI3Yl6xdFam7AvKFmhbo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=vgu7ryJlztsJq+cXrpiErt3QDHpnz6jmqSKH5wqXk7AiE1WECzuh1bbaioeHe0sE+30o9a7bGrsG/0h2xUk90ygyujpuW4K781wmjTMQHIxP5lxrRmvLKsArS6oAqTDFtjkmDLno+3XuMUrYR9yElv6BhjefsYaIFzOAQoBWN1w= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=21jNXTceld0C0Qil6BL4kHhKl6z12rDH8uIvrw29DY4K495OGAa3sr/sQzte+I9zHXj58LzxEJfgOc4cOT8UeimHHe+hLwW2cy9Hc5HYd5Dh87KmHnCBkAA+EVMiynZ3/zf7IoC0AQzprn2QILbgcqy6d59Trpu50nM0o4ufxsw=; Message-ID: <251976.52029.qm@web111407.mail.gq1.yahoo.com> X-YMail-OSG: hpM00IEVM1kjyRqz2YZCvMhGE0s9M4CPgMs5Ncim5fAnNmt cQ5gVobrNrk4dqVzRHuDwOpYGDYaJqs..YU7uuu2jXeOnAnpkPXm6rGST.E9 Z6Ts4SnQem_JB_HY9VYeH06uRHNPv3KMl9Yc8oR9k1E8qUvnTFdGGFax6jv_ nt8wl0.tp27kfHh0CqCnHCqMigvmcpSjSlJd7MK9sn_L9_aO5HSdOWrQp.fP lILt_cimxljxltesTtEVCJJ7I9thNgB8d2Qcppmu5QgC6P0XyLBItCTyu94t JYH_Ae40AQoGGx40o41IToCv5oK6P6qkEt_dSXuKiFbI2OZyW6tBXDfA9VY1 r_I6uFMrJkE2oU4WOB.iLQWGtifXECZ9EAEcE5kmWSuAlMWCHNc_97zGA2aa rmtxJ_5uSBtTY Received: from [206.16.17.212] by web111407.mail.gq1.yahoo.com via HTTP; Fri, 18 Feb 2011 08:14:23 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.109.292656 References: <C9833752.8BE5%yiu_lee@cable.comcast.com> Date: Fri, 18 Feb 2011 08:14:23 -0800 (PST) From: Behcet Sarikaya <behcetsarikaya@yahoo.com> To: "Lee, Yiu" <Yiu_Lee@cable.comcast.com> In-Reply-To: <C9833752.8BE5%yiu_lee@cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "'behave' <\(behave@ietf.org\)>" <behave@ietf.org> Subject: Re: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya <sarikaya@ieee.org> List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/behave> List-Post: <mailto:behave@ietf.org> List-Help: <mailto:behave-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 18 Feb 2011 16:13:54 -0000 > > Hi Behect, > > We are doing IPv4 multicast in the access network today. I foresee we will > continue to do IPv6 multicast in the access network in the future. No comments on this. >IMHO, > multimob-pmipv6-base-solution is not simpler because it will require the > fixed line operator to implement PMIP. I don't see this is a simple > requirement. No that's not true. Regards, Behcet From yiu_lee@cable.comcast.com Fri Feb 18 08:14:00 2011 Return-Path: <yiu_lee@cable.comcast.com> 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 07A343A6F37 for <behave@core3.amsl.com>; Fri, 18 Feb 2011 08:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=-0.801, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0OkHqJSlm2c for <behave@core3.amsl.com>; Fri, 18 Feb 2011 08:13:59 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 333CC3A6F36 for <behave@ietf.org>; Fri, 18 Feb 2011 08:13:59 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.26499614; Fri, 18 Feb 2011 09:25:28 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Fri, 18 Feb 2011 11:14:16 -0500 From: "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com> To: Behcet Sarikaya <sarikaya@ieee.org> Thread-Topic: [BEHAVE] [behave] address format draft Thread-Index: AQHLz4bj3t84Hhs2v0u5yhC/a/4r3A== Date: Fri, 18 Feb 2011 16:14:15 +0000 Message-ID: <C98404C1.8C56%yiu_lee@cable.comcast.com> In-Reply-To: <828919.79769.qm@web111403.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.13] Content-Type: text/plain; charset="us-ascii" Content-ID: <FCDBDCA9CCFBBE4D878315C9F430D22E@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: behave <behave@ietf.org> Subject: Re: [BEHAVE] [behave] address format draft X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/behave> List-Post: <mailto:behave@ietf.org> List-Help: <mailto:behave-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 18 Feb 2011 16:14:00 -0000 Behcet, I read the reply. I think in 00 and 01 we listed the reference for motivation behind this draft. I am ok to remove them when this becomes a WG item. Regards, Yiu On 2/18/11 11:12 AM, "Behcet Sarikaya" <behcetsarikaya@yahoo.com> wrote: > > >> Hi Behcet, >>=20 >> The mcast address format draft discusses how to embed an IPv4 group >> address in an IPv6 group address. It doesn't discuss how IPv4-IPv6 >> multicast should be implemented. We reference >> "draft-qin-softwire-dslite-multicast" in the draft because it requires >>a >> standard format to embed the IPv4 multicast address to make the >> encapsulation possible. This is also true for the mesh-multicast draft. >>=20 > >Yiu, please see my comments to Jacni. > >Regards, > >Behcet > > > > =20 From yiu_lee@cable.comcast.com Fri Feb 18 08:16:45 2011 Return-Path: <yiu_lee@cable.comcast.com> 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 1073B3A6CA1 for <behave@core3.amsl.com>; Fri, 18 Feb 2011 08:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.422 X-Spam-Level: X-Spam-Status: No, score=-102.422 tagged_above=-999 required=5 tests=[AWL=-0.687, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZolYVVa78c31 for <behave@core3.amsl.com>; Fri, 18 Feb 2011 08:16:44 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 58FB73A6C6A for <behave@ietf.org>; Fri, 18 Feb 2011 08:16:44 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.26500160; Fri, 18 Feb 2011 09:28:44 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Fri, 18 Feb 2011 11:17:11 -0500 From: "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com> To: Behcet Sarikaya <sarikaya@ieee.org> Thread-Topic: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D Thread-Index: AQHLz4dMNGHAk8BvS0qyPg/Uu3qG6g== Date: Fri, 18 Feb 2011 16:17:11 +0000 Message-ID: <C9840538.8C5D%yiu_lee@cable.comcast.com> In-Reply-To: <251976.52029.qm@web111407.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.13] Content-Type: text/plain; charset="us-ascii" Content-ID: <BB9B40E1D43C9B4F86BAF14CB3CE6422@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'behave' <\(behave@ietf.org\)>" <behave@ietf.org> Subject: Re: [BEHAVE] Updated version of multicast IPv4-embedded address format I-D X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/behave> List-Post: <mailto:behave@ietf.org> List-Help: <mailto:behave-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 18 Feb 2011 16:16:45 -0000 Hi Behcet, > >>IMHO, >> multimob-pmipv6-base-solution is not simpler because it will require >>the >> fixed line operator to implement PMIP. I don't see this is a simple >> requirement. > >No that's not true. Can you elaborate this a little more because I am not familiar with multimob-pmipv6-base-solution? I am very interested to see how this can be implemented in fixed line network and can simplify the multicast translation. Thanks, Yiu > From dwing@cisco.com Fri Feb 18 09:08:22 2011 Return-Path: <dwing@cisco.com> 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 055A63A6C7D for <behave@core3.amsl.com>; Fri, 18 Feb 2011 09:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 uFh9lzL3unQP for <behave@core3.amsl.com>; Fri, 18 Feb 2011 09:08:20 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 5C7A13A6C6A for <behave@ietf.org>; Fri, 18 Feb 2011 09:08:20 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.62,188,1297036800"; d="scan'208";a="262006815" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 18 Feb 2011 17:08:54 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1IH8sWU011147; Fri, 18 Feb 2011 17:08:54 GMT From: "Dan Wing" <dwing@cisco.com> To: "'Senthil Sivakumar \(ssenthil\)'" <ssenthil@cisco.com>, "'Christian Huitema'" <huitema@microsoft.com>, <behave@ietf.org> References: <C98237C0.3D15%ssenthil@cisco.com> <CEBCE3CF81D2D441B14B84256C3C46810BD9E516@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <055101cbcecf$a2f3cd30$e8db6790$@com> <85B2F271FDF6B949B3672BA5A7BB62FB0C506A1D@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB0C506A1D@xmb-sjc-236.amer.cisco.com> Date: Fri, 18 Feb 2011 09:08:54 -0800 Message-ID: <0a0c01cbcf8e$85b4dec0$911e9c40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvOc/GXC+cyhiCbMUu7QxUZfrLpMgAT2O0gAAL+3XAAIbLywAANNnhw Content-Language: en-us Subject: Re: [BEHAVE] Handling of non-TCP/UDP/ICMP packets X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/behave> List-Post: <mailto:behave@ietf.org> List-Help: <mailto:behave-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 18 Feb 2011 17:08:22 -0000 > -----Original Message----- > From: Senthil Sivakumar (ssenthil) [mailto:ssenthil@cisco.com] > Sent: Friday, February 18, 2011 2:54 AM > To: Dan Wing (dwing); Christian Huitema; behave@ietf.org > Subject: RE: [BEHAVE] Handling of non-TCP/UDP/ICMP packets > > How about other protocols? Are we convinced that no other protocols > would work without stateful processing of the individual protocols, so > dropping is the right thing to do? It seems to me that we cannot know > the answer that no other applications/protocols/deployments would work > or not, without doing a lot of research and recommending dropping seems > excessive. I have seen with nat44 GRE protocol will pass through and > apparently was a deployed use case. Sure, you cannot do multiplexing in > an effort to conserve IPv4 addresses but that is a known short coming > that deployments may be willing to accept. Let me digress with a little Motherhood and Apple Pie: The goal for BEHAVE's IPv6/IPv4 standardization effort was to get TCP, UDP, and ICMP working properly through a NAT64. We did this in two years. This is very fast for any standards body. I believe we achieved this because we purposefully kept the scope as small as possible to achieve the greatest benefit to the Internet community as we approach IPv4 exhaustion. In the stateless NAT64 document, it only says SHOULD drop. SHOULD, as you know, means that if the implementation "knows better", it can go beyond what is written in the specification (that is, "violate" the SHOULD). In this case, an implementation can pass a certain protocol. The intent of the text is to provide immediate feedback (with an ICMP message) so that the sending host can choose a different protocol, such as tunneling its traffic over UDP which is commonly done for exactly this reason with NAT44 devices; or ask the NAT64 administrator to adjust CLI settings; or ask the NAT64 vendor to support the protocol. An example which supports your point (GRE) and Christian's point (IPsec), let me add another example. There are NATs that support SCTP, because they will just NAT packets (no matter the protocol) in the hopes that it will "Just Work". That's what you're proposing the NAT64 document say. See https://fit.nokia.com/lars/papers/2010-imc-hgw-study.pdf, searching for "SCTP". However, it is unknown if they would work with multiple SCTP clients behind a NAT going to the same or different IPv4 servers, how the clients, NATs, or servers would handle SCTP source port collisions, and so on. Afterall, if SCTP "just worked" across NATs, SCTP would not need changes to the SCTP client and SCTP server, draft-ietf-tsvwg-natsupp. I have no idea how much of these concerns might apply to stateless NAT64. It requires analysis. SCTP is not common on the IPv4 Internet, so it doesn't seem worthwhile to analyze how to get SCTP to work across a NAT64, at least not today. It's good that GRE works. We might consider doing an Errata against the stateless NAT64 document saying that GRE should be permitted, which would get folded into an eventual "bis" document. I assume for stateless NAT64 you really mean that both GRE and PPTP work. So, we should craft some appropriate wording. Alternatively, we might consider going through a list of protocols and determining which ones Just Work through a NAT64; it might be a much longer list. As for IPsec, it has nuances with the SPI changing during an IPsec session. -d > Senthil > > -----Original Message----- > From: Dan Wing (dwing) > Sent: Thursday, February 17, 2011 1:22 PM > To: 'Christian Huitema'; Senthil Sivakumar (ssenthil); behave@ietf.org > Subject: RE: [BEHAVE] Handling of non-TCP/UDP/ICMP packets > > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of Christian Huitema > > Sent: Thursday, February 17, 2011 8:56 AM > > To: ssenthil; behave@ietf.org > > Subject: Re: [BEHAVE] Handling of non-TCP/UDP/ICMP packets > > > > There are many NAT44 that pass other protocols than TCP/UDP/ICMP. For > > example, many use various heuristics to match incoming and outgoing > > IPSEC contexts. > > Those heuristics are not documented by the IETF. To my knowledge, > they aren't documented anywhere. And to my knowledge, the > heuristics used by IPsec SPI inspection are all stateful. > > -d > > > > Is the intent to ban such support? > > > > > > > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of ssenthil > > Sent: Wednesday, February 16, 2011 11:26 PM > > To: behave@ietf.org > > Subject: [BEHAVE] Handling of non-TCP/UDP/ICMP packets > > > > > > > > The stateless draft mentions that > > > > Next Header: For ICMPv4 (1) changed to ICMPv6 (58), otherwise > > protocol field MUST be copied from IPv4 header. > > > > > > The stateless draft states that: > > > > If the incoming packet is an IPv4 packet that contains a protocol > > other than TCP, UDP or ICMPv4, then the packet SHOULD discarded > and, > > if the security policy permits, the NAT64 SHOULD send an ICMPv4 > > Destination Unreachable error message with Code 2 (Protocol > > Unreachable) to the source address of the received packet > > > > Which is contradicting. So what should be the expected behavior, for > > stateless traffic the protocol MUST be copied over to the IPv6 header > > and for stateful traffic only TCP/UDP/ICMP packets should be > > translated? I don't remember the rationale for saying the non- > > TCP/UDP/ICMP packets to be dropped. (This is generic question that > > applies to both v6->v4 and v4->v6 - but just quoting it from the > v4->v6 > > perspective). > > > > Thanks > > Senthil From huitema@microsoft.com Fri Feb 18 12:00:52 2011 Return-Path: <huitema@microsoft.com> 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 450D73A6FD3 for <behave@core3.amsl.com>; Fri, 18 Feb 2011 12:00:52 -0800 (PST) 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 z2BHs6NY2x5A for <behave@core3.amsl.com>; Fri, 18 Feb 2011 12:00:51 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 87A6E3A7014 for <behave@ietf.org>; Fri, 18 Feb 2011 12:00:41 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 18 Feb 2011 12:01:15 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.270.2; Fri, 18 Feb 2011 12:00:26 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.204]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Fri, 18 Feb 2011 12:00:26 -0800 From: Christian Huitema <huitema@microsoft.com> To: Dan Wing <dwing@cisco.com>, "'Senthil Sivakumar (ssenthil)'" <ssenthil@cisco.com>, "behave@ietf.org" <behave@ietf.org> Thread-Topic: [BEHAVE] Handling of non-TCP/UDP/ICMP packets Thread-Index: AQHLzs+qcOnKBbNPckaM5HbWHEPFsZQHnOuAgABonAD//6lygA== Date: Fri, 18 Feb 2011 20:00:25 +0000 Message-ID: <CEBCE3CF81D2D441B14B84256C3C46810BD9F610@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> References: <C98237C0.3D15%ssenthil@cisco.com> <CEBCE3CF81D2D441B14B84256C3C46810BD9E516@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <055101cbcecf$a2f3cd30$e8db6790$@com> <85B2F271FDF6B949B3672BA5A7BB62FB0C506A1D@xmb-sjc-236.amer.cisco.com> <0a0c01cbcf8e$85b4dec0$911e9c40$@com> In-Reply-To: <0a0c01cbcf8e$85b4dec0$911e9c40$@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] Handling of non-TCP/UDP/ICMP packets X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/behave> List-Post: <mailto:behave@ietf.org> List-Help: <mailto:behave-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 18 Feb 2011 20:00:52 -0000 Arguably, that means adding a qualifier, "SHOULD drop unless protocol speci= fic behavior has been developed in the NAT64. If the NAT64 does drop, it SH= OULD send back an ICMP (modulo rate limit, etc.) " -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: Friday, February 18, 2011 9:09 AM To: 'Senthil Sivakumar (ssenthil)'; Christian Huitema; behave@ietf.org Subject: RE: [BEHAVE] Handling of non-TCP/UDP/ICMP packets > -----Original Message----- > From: Senthil Sivakumar (ssenthil) [mailto:ssenthil@cisco.com] > Sent: Friday, February 18, 2011 2:54 AM > To: Dan Wing (dwing); Christian Huitema; behave@ietf.org > Subject: RE: [BEHAVE] Handling of non-TCP/UDP/ICMP packets >=20 > How about other protocols? Are we convinced that no other protocols=20 > would work without stateful processing of the individual protocols, so=20 > dropping is the right thing to do? It seems to me that we cannot know=20 > the answer that no other applications/protocols/deployments would work=20 > or not, without doing a lot of research and recommending dropping=20 > seems excessive. I have seen with nat44 GRE protocol will pass through=20 > and apparently was a deployed use case. Sure, you cannot do=20 > multiplexing in an effort to conserve IPv4 addresses but that is a=20 > known short coming that deployments may be willing to accept. Let me digress with a little Motherhood and Apple Pie: The goal for BEHAVE= 's IPv6/IPv4 standardization effort was to get TCP, UDP, and ICMP working p= roperly through a NAT64. We did this in two years. =20 This is very fast for any standards body. I believe we achieved this becau= se we purposefully kept the scope as small as possible to achieve the great= est benefit to the Internet community as we approach IPv4 exhaustion. In the stateless NAT64 document, it only says SHOULD drop. SHOULD, as you = know, means that if the implementation "knows better", it can go beyond wha= t is written in the specification (that is, "violate" the SHOULD). In this= case, an implementation can pass a certain protocol. The intent of the text is to provide immediate feedback (with an ICMP message) so that the sending host can choose a different protocol, such as = tunneling its traffic over UDP which is commonly done for exactly this reas= on with NAT44 devices; or ask the NAT64 administrator to adjust CLI setting= s; or ask the NAT64 vendor to support the protocol. An example which supports your point (GRE) and Christian's point (IPsec), l= et me add another example. There are NATs that support SCTP, because they = will just NAT packets (no matter the protocol) in the hopes that it will "J= ust Work". That's what you're proposing the NAT64 document say. See https= ://fit.nokia.com/lars/papers/2010-imc-hgw-study.pdf, searching for "SCTP". = However, it is unknown if they would work with multiple SCTP clients behin= d a NAT going to the same or different IPv4 servers, how the clients, NATs, or servers would handle SCTP source po= rt collisions, and so on. Afterall, if SCTP "just worked" across NATs, SCT= P would not need changes to the SCTP client and SCTP server, draft-ietf-tsv= wg-natsupp. I have no idea how much of these concerns might apply to state= less NAT64. It requires analysis. SCTP is not common on the IPv4 Internet= , so it doesn't seem worthwhile to analyze how to get SCTP to work across a= NAT64, at least not today. It's good that GRE works. We might consider doing an Errata against the st= ateless NAT64 document saying that GRE should be permitted, which would get= folded into an eventual "bis"=20 document. I assume for stateless NAT64 you really mean that both GRE and P= PTP work. So, we should craft some appropriate wording. Alternatively, we= might consider going through a list of protocols and determining which one= s Just Work through a NAT64; it might be a much longer list. As for IPsec, it has nuances with the SPI changing during an IPsec session. -d > Senthil >=20 > -----Original Message----- > From: Dan Wing (dwing) > Sent: Thursday, February 17, 2011 1:22 PM > To: 'Christian Huitema'; Senthil Sivakumar (ssenthil); behave@ietf.org > Subject: RE: [BEHAVE] Handling of non-TCP/UDP/ICMP packets >=20 > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On=20 > > Behalf Of Christian Huitema > > Sent: Thursday, February 17, 2011 8:56 AM > > To: ssenthil; behave@ietf.org > > Subject: Re: [BEHAVE] Handling of non-TCP/UDP/ICMP packets > > > > There are many NAT44 that pass other protocols than TCP/UDP/ICMP.=20 > > For example, many use various heuristics to match incoming and=20 > > outgoing IPSEC contexts. >=20 > Those heuristics are not documented by the IETF. To my knowledge,=20 > they aren't documented anywhere. And to my knowledge, the heuristics=20 > used by IPsec SPI inspection are all stateful. >=20 > -d >=20 >=20 > > Is the intent to ban such support? > > > > > > > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On=20 > > Behalf Of ssenthil > > Sent: Wednesday, February 16, 2011 11:26 PM > > To: behave@ietf.org > > Subject: [BEHAVE] Handling of non-TCP/UDP/ICMP packets > > > > > > > > The stateless draft mentions that > > > > Next Header: For ICMPv4 (1) changed to ICMPv6 (58), otherwise > > protocol field MUST be copied from IPv4 header. > > > > > > The stateless draft states that: > > > > If the incoming packet is an IPv4 packet that contains a protocol > > other than TCP, UDP or ICMPv4, then the packet SHOULD discarded > and, > > if the security policy permits, the NAT64 SHOULD send an ICMPv4 > > Destination Unreachable error message with Code 2 (Protocol > > Unreachable) to the source address of the received packet > > > > Which is contradicting. So what should be the expected behavior, for=20 > > stateless traffic the protocol MUST be copied over to the IPv6=20 > > header and for stateful traffic only TCP/UDP/ICMP packets should be=20 > > translated? I don't remember the rationale for saying the non-=20 > > TCP/UDP/ICMP packets to be dropped. (This is generic question that=20 > > applies to both v6->v4 and v4->v6 - but just quoting it from the > v4->v6 > > perspective). > > > > Thanks > > Senthil From iljitsch@muada.com Sun Feb 20 08:47:01 2011 Return-Path: <iljitsch@muada.com> 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 0F9BF3A6CCA for <behave@core3.amsl.com>; Sun, 20 Feb 2011 08:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 9DjZyzkQ0eyo for <behave@core3.amsl.com>; Sun, 20 Feb 2011 08:46:53 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by core3.amsl.com (Postfix) with ESMTP id 960F83A6D9F for <behave@ietf.org>; Sun, 20 Feb 2011 08:46:52 -0800 (PST) Received: from [192.168.0.101] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p1KGkd7H035998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 20 Feb 2011 17:46:40 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB0C506A1D@xmb-sjc-236.amer.cisco.com> Date: Sun, 20 Feb 2011 17:47:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <93FD7B0A-4ECA-4989-A3D9-37EBC9D323E3@muada.com> References: <C98237C0.3D15%ssenthil@cisco.com> <CEBCE3CF81D2D441B14B84256C3C46810BD9E516@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <055101cbcecf$a2f3cd30$e8db6790$@com> <85B2F271FDF6B949B3672BA5A7BB62FB0C506A1D@xmb-sjc-236.amer.cisco.com> To: Senthil Sivakumar (ssenthil) <ssenthil@cisco.com> X-Mailer: Apple Mail (2.1082) Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Handling of non-TCP/UDP/ICMP packets X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/behave> List-Post: <mailto:behave@ietf.org> List-Help: <mailto:behave-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 20 Feb 2011 16:47:01 -0000 On 18 feb 2011, at 11:54, Senthil Sivakumar (ssenthil) wrote: > How about other protocols? Are we convinced that no other protocols > would work without stateful processing of the individual protocols, so > dropping is the right thing to do? It's a multiplexing issue. As multiple IPv6 clients end up sharing the = same IPv4 address, the NAT64 wouldn't know where to send the return = packets if multiple IPv6 hosts talk to the same IPv4 host using an = unknown protocol. With a home NAT this usually works to some degree because there's rarely = multiple local systems talking GRE, IPv6-in-IPv4 or SCTP towards the = same destination. Don't forget that you help a NAT64 user much more by getting more stuff = on IPv6 than by getting more stuff to work through the NAT64. From ssenthil@cisco.com Sun Feb 20 18:12:24 2011 Return-Path: <ssenthil@cisco.com> 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 2D4013A6D07 for <behave@core3.amsl.com>; Sun, 20 Feb 2011 18:12:24 -0800 (PST) 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 YwyF0gnNGFcc for <behave@core3.amsl.com>; Sun, 20 Feb 2011 18:12:23 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 7E6733A6CEF for <behave@ietf.org>; Sun, 20 Feb 2011 18:12:23 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADZZYU2rR7Ht/2dsb2JhbACmNXOeJJo/hV4EhQ2HBoNB X-IronPort-AV: E=Sophos;i="4.62,197,1297036800"; d="scan'208";a="332542719" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 21 Feb 2011 02:12:45 +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 p1L2CjOi028218; Mon, 21 Feb 2011 02:12:45 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.4675); Sun, 20 Feb 2011 18:12:45 -0800 Received: from 10.65.71.151 ([10.65.71.151]) by xmb-sjc-236.amer.cisco.com ([128.107.191.121]) with Microsoft Exchange Server HTTP-DAV ; Mon, 21 Feb 2011 02:12:43 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Sun, 20 Feb 2011 21:13:23 -0500 From: ssenthil <ssenthil@cisco.com> To: Iljitsch van Beijnum <iljitsch@muada.com> Message-ID: <C9873473.40EA%ssenthil@cisco.com> Thread-Topic: [BEHAVE] Handling of non-TCP/UDP/ICMP packets Thread-Index: AcvRbOpu6HCs0Lyfc06FM6M7uJPsDQ== In-Reply-To: <93FD7B0A-4ECA-4989-A3D9-37EBC9D323E3@muada.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Feb 2011 02:12:45.0743 (UTC) FILETIME=[D439EBF0:01CBD16C] Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Handling of non-TCP/UDP/ICMP packets X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/behave> List-Post: <mailto:behave@ietf.org> List-Help: <mailto:behave-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 21 Feb 2011 02:12:24 -0000 On 2/20/11 11:47 AM, "Iljitsch van Beijnum" <iljitsch@muada.com> wrote: > On 18 feb 2011, at 11:54, Senthil Sivakumar (ssenthil) wrote: > >> How about other protocols? Are we convinced that no other protocols >> would work without stateful processing of the individual protocols, so >> dropping is the right thing to do? > > It's a multiplexing issue. As multiple IPv6 clients end up sharing the same > IPv4 address, the NAT64 wouldn't know where to send the return packets if > multiple IPv6 hosts talk to the same IPv4 host using an unknown protocol. > [Senthil] You are assuming multiplexing is the only mode NAT64 is going to be deployed, which will not be the case. It would be a predominantly popular deployment scenario but not the only one. There will be n-1 multiplexing for the transport protocols like TCP/UDP and 1-1 mapping for the others. > With a home NAT this usually works to some degree because there's rarely > multiple local systems talking GRE, IPv6-in-IPv4 or SCTP towards the same > destination. > > Don't forget that you help a NAT64 user much more by getting more stuff on > IPv6 than by getting more stuff to work through the NAT64. > From lars.eggert@nokia.com Sun Feb 20 23:55:27 2011 Return-Path: <lars.eggert@nokia.com> 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 356AD3A6FA2 for <behave@core3.amsl.com>; Sun, 20 Feb 2011 23:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.222 X-Spam-Level: X-Spam-Status: No, score=-103.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Vyy9-Vy-A-b for <behave@core3.amsl.com>; Sun, 20 Feb 2011 23:55:26 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 3323F3A6FA1 for <behave@ietf.org>; Sun, 20 Feb 2011 23:55:26 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1L7u300008582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Feb 2011 09:56:04 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-125--7308069; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert <lars.eggert@nokia.com> In-Reply-To: <0a0c01cbcf8e$85b4dec0$911e9c40$@com> Date: Mon, 21 Feb 2011 09:55:55 +0200 Message-Id: <55145526-B941-46AD-8C41-D9D81C71EC91@nokia.com> References: <C98237C0.3D15%ssenthil@cisco.com> <CEBCE3CF81D2D441B14B84256C3C46810BD9E516@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <055101cbcecf$a2f3cd30$e8db6790$@com> <85B2F271FDF6B949B3672BA5A7BB62FB0C506A1D@xmb-sjc-236.amer.cisco.com> <0a0c01cbcf8e$85b4dec0$911e9c40$@com> To: Dan Wing <dwing@cisco.com> X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Mon, 21 Feb 2011 09:56:00 +0200 (EET) X-Nokia-AV: Clean Cc: behave@ietf.org Subject: Re: [BEHAVE] Handling of non-TCP/UDP/ICMP packets X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/behave> List-Post: <mailto:behave@ietf.org> List-Help: <mailto:behave-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 21 Feb 2011 07:55:27 -0000 --Apple-Mail-125--7308069 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2011-2-18, at 19:08, Dan Wing wrote: > There are NATs that support=20 > SCTP, because they will just NAT packets (no matter the protocol)=20 > in the hopes that it will "Just Work". That's what you're=20 > proposing the NAT64 document say. See=20 > https://fit.nokia.com/lars/papers/2010-imc-hgw-study.pdf, searching > for "SCTP". However, it is unknown if they would work with=20 > multiple SCTP clients behind a NAT going to the same or different > IPv4 servers, how the clients, NATs, or servers would handle SCTP=20 > source port collisions, and so on. FWIW, we're planning to more fully investigate this in the upcoming = second round of our NAT tests (which were delayed by needing to move all = the equipment...) Lars= --Apple-Mail-125--7308069 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIyMTA3NTU1NVowIwYJKoZIhvcNAQkE MRYEFHDxSoY6Vz3texLldAy1FKFqTBRmMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AD9c3r6daYTtzCxVc2ZyYfrkNOV80Q9jL0rzKgG7m5J9za09gjZGCZqj1uDEjFaMGqh9stcpb0Bx YEBMyedjEESuyxrSgrdVZgMOcK75Md5vUbITnHuo1/hxIksdkfqe4L5fZueOAD2LBGKmcHK6O4st guaoagwa8qjKNmKeklDezvwmkud4cXmA2Wfa0H4QVPEYnRCxnG8lBI5OXYnPBwncg8FTJRYNnTHy iRSGOaJi2qjlMgziDUiGjftMTXdEnGkQ6J55iVSWxHyNbHaMo2TnPZm2K/X6FC09sMkD5VO9YQhe VlUTuqdeZsTW5rKB1ILqs72RD5h21KL7okljnm0AAAAAAAA= --Apple-Mail-125--7308069-- From jouni.nospam@gmail.com Tue Feb 22 06:45:24 2011 Return-Path: <jouni.nospam@gmail.com> 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 5FF893A68F6 for <behave@core3.amsl.com>; Tue, 22 Feb 2011 06:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z72EqXi8g+hu for <behave@core3.amsl.com>; Tue, 22 Feb 2011 06:45:23 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 38A223A68AC for <behave@ietf.org>; Tue, 22 Feb 2011 06:45:23 -0800 (PST) Received: by wyb42 with SMTP id 42so1519966wyb.31 for <behave@ietf.org>; Tue, 22 Feb 2011 06:46:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:references:to:message-id:mime-version:x-mailer; bh=lqwRlDgI50Hl/u2cC38OyAZyHihIbu7+VzVg8UpZR/4=; b=WW2v09Z9JJ4O821Ip7v9OhQ0TsJ8mRHCN/OpszYJGzrVOYe0E4HWE1qmc24jnqH2R7 uNKcVHhFzrSbI2x9thVSNfn9mXtV2qDx7kcv4d0X8uToVCIb3TQ6GZhKWTHnfdPLV2zq pBbDvcjS5xcxxqPSDKPd8WGjF97+9H2Eylekw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; b=x0uxH+nhFBoF8P24q/xKtzMkvwp1lf82lyQHa6EcbfC6CoiFnEIio9FqNkf/keDv9T zt+K0R2o4SsYhcUZur09U3gOeVZShY5T1Z/aVXEstxTgg6Ml9/oqpfz3R95bwAfh2LJ7 7OvzAvMHRSUn+WKdCrYAeuCAtr5U+eoixFU6s= Received: by 10.227.195.76 with SMTP id eb12mr2502046wbb.34.1298385967084; Tue, 22 Feb 2011 06:46:07 -0800 (PST) Received: from a88-112-204-48.elisa-laajakaista.fi (a88-112-204-48.elisa-laajakaista.fi [88.112.204.48]) by mx.google.com with ESMTPS id f27sm571648wbf.1.2011.02.22.06.46.04 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Feb 2011 06:46:05 -0800 (PST) From: jouni korhonen <jouni.nospam@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Feb 2011 16:46:03 +0200 References: <20110222140001.3797.57027.idtracker@localhost> To: "'behave' (behave@ietf.org)" <behave@ietf.org> Message-Id: <F3B30C46-123A-428A-80BD-BFE06ADC8BA0@gmail.com> Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [BEHAVE] Fwd: I-D Action:draft-korhonen-behave-nat64-learn-analysis-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/behave> List-Post: <mailto:behave@ietf.org> List-Help: <mailto:behave-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Feb 2011 14:45:24 -0000 Folks, We have update the draft based on the comments we received.=20 * Some more meat added to Issue#4. * We clarified the Issue#5 regarding multiple NSPs. Learning one NSP is = enough for a host to do the synthesis but in order to avoid NAT64 the = host should learn all NSPs in the access network. * We added a paragraph regarding referral objects. * We added a new section for "Learning the IPv6 Prefix of a Network's = NAT64 using Access Technology Specific Methods". * We lifted up our solution recommendation/proposal so that even lazy = readers can spot it out in conclusions ;) Some more tweaking in = conclusions like stating that no DNS based solution comes without real = standards effort.. - Jouni & Teemu Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: February 22, 2011 4:00:01 PM GMT+02:00 > To: i-d-announce@ietf.org > Subject: I-D Action:draft-korhonen-behave-nat64-learn-analysis-02.txt > Reply-To: internet-drafts@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Analysis of solution proposals for hosts to = learn NAT64 prefix > Author(s) : J. Korhonen, T. Savolainen > Filename : = draft-korhonen-behave-nat64-learn-analysis-02.txt > Pages : 26 > Date : 2011-02-22 >=20 > Hosts and applications may benefit from the knowledge if an IPv6 > address is synthesized, which would mean a NAT64 is used to reach the > IPv4 network or Internet. This document analyses a number of > proposed solutions for communicating whether the synthesis is taking > place, used address format, and the IPv6 prefix used by the NAT64 and > DNS64. This enables both NAT64 avoidance and intentional utilization > by allowing local IPv6 address synthesis. From miyakawa@nttv6.jp Thu Feb 24 22:53:55 2011 Return-Path: <miyakawa@nttv6.jp> 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 045993A6938 for <behave@core3.amsl.com>; Thu, 24 Feb 2011 22:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 U4KcbA96Enqo for <behave@core3.amsl.com>; Thu, 24 Feb 2011 22:53:49 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:144::148]) by core3.amsl.com (Postfix) with ESMTP id 87B203A693D for <behave@ietf.org>; Thu, 24 Feb 2011 22:53:46 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:208::212]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id EC56ABDC18; Fri, 25 Feb 2011 15:54:36 +0900 (JST) Received: from localhost (localhost [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id BEA0A70525; Fri, 25 Feb 2011 15:54:36 +0900 (JST) Date: Fri, 25 Feb 2011 15:54:36 +0900 (JST) Message-Id: <20110225.155436.488389578.miyakawa@nttv6.jp> To: dwing@cisco.com, dthaler@microsoft.com From: Shin Miyakawa <miyakawa@nttv6.jp> In-Reply-To: <03a701cbc7cb$b5af6390$210e2ab0$@com> <9B57C850BB53634CACEC56EF4853FF65343694EA@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> References: <03a701cbc7cb$b5af6390$210e2ab0$@com> Organizaton: NTT Communications X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: miyakawa@nttv6.jp, behave@ietf.org, draft-ietf-behave-lsn-requirements@tools.ietf.org Subject: Re: [BEHAVE] LSN: bulk ports X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/behave> List-Post: <mailto:behave@ietf.org> List-Help: <mailto:behave-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Feb 2011 06:53:55 -0000 Dear BEHAVE Chairs, We lsn-requirement draft authers have discussed and (1)We're welcome the new editor as you suggested. (2)We'd like to update our drafts to follow the comments especially Chairs'. However so, still some points are not settled down. For example; Dan said ; From: "Dan Wing" <dwing@cisco.com> Subject: LSN: bulk ports Date: Tue, 8 Feb 2011 12:06:44 -0800 Regarding Section 7.2 of draft-ietf-behave-lsn-requirements-00: <snip> The text in the I-D needs more detail. <snip> However so, in the different mail from Dave, another BEHAVE Chair wrote : From: Dave Thaler <dthaler@microsoft.com> Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-lsn-requirements-00.txt Date: Sun, 7 Nov 2010 02:36:59 +0000 8) Section 7 starts to describe a mechanism ("The following mechanisms can be used ..."). I don't think that's appropriate in a requirements document. Sections 7.1 and 7.2 should be deleted in my view. So we're very confused. At least, talking about the section 7.2 of our drafts, Should we add more detail (Dan's suggestion) ? or, Should we delete it (Dave's suggestion) ? Chairs, please make us know the way we should go. (Psalm 143:8) # Or can we discussed this a bit off mailing list first ? Best wishes, Shin Miyakawa From dthaler@microsoft.com Mon Feb 28 12:54:38 2011 Return-Path: <dthaler@microsoft.com> 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 651AA3A6CAB for <behave@core3.amsl.com>; Mon, 28 Feb 2011 12:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.477 X-Spam-Level: X-Spam-Status: No, score=-110.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 C-guXdS8deL4 for <behave@core3.amsl.com>; Mon, 28 Feb 2011 12:54:37 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 515B43A6CA9 for <behave@ietf.org>; Mon, 28 Feb 2011 12:54:37 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 28 Feb 2011 12:55:38 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.270.2; Mon, 28 Feb 2011 12:55:37 -0800 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.245]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0270.002; Mon, 28 Feb 2011 12:55:35 -0800 From: Dave Thaler <dthaler@microsoft.com> To: "behave@ietf.org" <behave@ietf.org> Thread-Topic: Comments on draft-ietf-behave-v4v6-bih-02 Thread-Index: AcvXh1UbHpfb2lXBRvGZdRJSdxR9OQ== Date: Mon, 28 Feb 2011 20:55:35 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653AFA5E52@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] Comments on draft-ietf-behave-v4v6-bih-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/behave> List-Post: <mailto:behave@ietf.org> List-Help: <mailto:behave-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Feb 2011 20:54:38 -0000 I have reviewed the latest version and have two main technical comments. I also have lots of editorial nits that I will send directly to the authors= . The main technical comments are summarized as follows. 1) There are three ways to implement the ENR. a) at the API layer (works fine with DNSSEC) b) as a recursive resolver on the same host as discussed in Appendix A (I believe this has the same properties as DNS64 with respect to DNSSEC impact) c) in the network stack as shown in figure 2 (I think this breaks DNSSE= C) Currently the document allows all three options, though seems to treat (a) and (c) as equally recommended, and (b) is almost an aftertho= ught. I would prefer a stronger recommendation towards things that work with DNSSEC. For example, could we remove (c) all together from this Standards Track document? I'd rather just make (a) a MUST, or at least a strong SHOULD. Note that the choice of where the ENR is implemented is orthogonal to where the protocol translation is implemented (which could be either API layer, or in the network stack). Don't confuse this commen= t with BIS vs BIA for data translation. 2) Applications using name resolution APIs like gethostbyname() have no idea whether DNS will be used or something else (hosts file, mDNS, netbios, or whatever else). Indeed that was one of the main points of RFC 6055. That's another reason why a type (a) ENR works much better than a type (b) or (c) ENR, since (a) can be done in a name resolution protocol agnostic way and the others cannot. Hopefully folks now understand why I'd prefer to make (a) be a MUST or at least a strong SHOULD. 3) Section 2.2 on the translator module in a BIS-like implementation claims that it needs to do fragmentation. Since as shown in figure 2, the translator sits on top of the IPv6 stack, and the IPv6 stack can do fragmentation, I can't imagine any reason the translator itself would need to do fragmentation. It should just send it down to the IPv6 module to fragment as needed. 4) Section 2.4 states that the mapper registers a pair itself. However it never gives any reason or use for this, so I think that should be remov= ed. -Dave From dwing@cisco.com Mon Feb 28 13:09:46 2011 Return-Path: <dwing@cisco.com> 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 CA8583A6842 for <behave@core3.amsl.com>; Mon, 28 Feb 2011 13:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 5Jz+5ljrdOiS for <behave@core3.amsl.com>; Mon, 28 Feb 2011 13:09:45 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id CC0723A6837 for <behave@ietf.org>; Mon, 28 Feb 2011 13:09:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=828; q=dns/txt; s=iport; t=1298927447; x=1300137047; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=4ihMv3ry5fJ/7Wa5xI3OUpwWVtV/+94UPDz6OIZq7a4=; b=P05qeRMal8ePCthFh2L+Vp9eoYP9/mz3eIoI2f/Yr52ynbVpltqMu8av 7G1FI2X8yh7y4j2uRMnyeFloIfo4+J6vLPyMBFlk4lmSWVdLNXHSbIKDK wDGDUlxNUh+F3stnEBVOVCDRTqx1iiVyENOrlN8lsTNfzG+N73kD9+Ed1 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAADKea02rR7H+/2dsb2JhbACXcYFljG90oA2bXYVhBIUP X-IronPort-AV: E=Sophos;i="4.62,242,1297036800"; d="scan'208";a="271941038" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 28 Feb 2011 21:10:47 +0000 Received: from dwingWS (dhcp-128-107-104-148.cisco.com [128.107.104.148]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1SLAl0u000235 for <behave@ietf.org>; Mon, 28 Feb 2011 21:10:47 GMT From: "Dan Wing" <dwing@cisco.com> To: "'Behave WG'" <behave@ietf.org> Date: Mon, 28 Feb 2011 13:10:47 -0800 Message-ID: <021e01cbd78b$f801e1d0$e805a570$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvU2smSHr0IpSjxSkWOaqwZS+CrIwCsPamA Content-Language: en-us Subject: [BEHAVE] FW: [dccp] WGLC for draft-ietf-dccp-udpencap X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/behave> List-Post: <mailto:behave@ietf.org> List-Help: <mailto:behave-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Feb 2011 21:09:46 -0000 The DCCP working group has finished their DCCP-over-UDP, which was primarily done to provide an encapsulation for DCCP to work across NATs. If you have time, please do review the document and send feedback to the dccp working group's mailing list, dccp@ietf.org. Thanks! -d -----Original Message----- From: dccp-bounces@ietf.org [mailto:dccp-bounces@ietf.org] On Behalf Of Pasi Sarolahti Sent: Friday, February 25, 2011 2:57 AM To: 'dccp' working group Subject: [dccp] WGLC for draft-ietf-dccp-udpencap Hi, This mail starts a working group last call for the UDP encapsulation draft. The draft is available at http://tools.ietf.org/html/draft-ietf-dccp-udpencap-06 . Please read the draft and send any comments to the DCCP mailing list. The WGLC lasts for two weeks, until March 11. - Pasi From dwing@cisco.com Mon Feb 28 18:52:46 2011 Return-Path: <dwing@cisco.com> 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 7247B3A6C6F for <behave@core3.amsl.com>; Mon, 28 Feb 2011 18:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.487 X-Spam-Level: X-Spam-Status: No, score=-110.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 t8wdLJ2IhlAc for <behave@core3.amsl.com>; Mon, 28 Feb 2011 18:52:45 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 51CC83A6C4C for <behave@ietf.org>; Mon, 28 Feb 2011 18:52:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=265; q=dns/txt; s=iport; t=1298948027; x=1300157627; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=zUhAiIXZA3afezwdXHep/xJc/dbLxf80x6QdjqRFN4A=; b=lbJUi2qH9p6lIAfnVMWgzejlYSd46Hu4jBZYLAu7wziPcUMl9jYHZt0G x+PqlSWBVAgzSG8OolMl9dn3Uv4ShsegAf9sXlpeUg8s0q04fiMlKuSru MsWNFzMFynwywqZu596vVaPOX1EpHvP614AAPQlQVV2yhbsPcfg5d0pwN Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJfua02rR7Hu/2dsb2JhbACZWoxwdJ9Xm22FYQSFEg X-IronPort-AV: E=Sophos;i="4.62,245,1297036800"; d="scan'208";a="266860451" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 01 Mar 2011 02:53:47 +0000 Received: from dwingWS (dhcp-128-107-104-148.cisco.com [128.107.104.148]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p212rlja012035 for <behave@ietf.org>; Tue, 1 Mar 2011 02:53:47 GMT From: "Dan Wing" <dwing@cisco.com> To: "'Behave WG'" <behave@ietf.org> Date: Mon, 28 Feb 2011 18:53:47 -0800 Message-ID: <040201cbd7bb$e2c245f0$a846d1d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvXu+KfdvHwE4GdRzyFZBUZzG8b8g== Content-Language: en-us Subject: [BEHAVE] BEHAVE agenda X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/behave> List-Post: <mailto:behave@ietf.org> List-Help: <mailto:behave-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 01 Mar 2011 02:52:46 -0000 Document status is at http://datatracker.ietf.org/wg/behave/ Our preliminary agenda is at http://www.ietf.org/proceedings/80/agenda/behave.html If you want a slot, please email me. We have a 2.5 hour slot on Tuesday and a 2 hour slot on Friday. -d