From magnus.westerlund@ericsson.com Thu Oct 1 09:12:57 2009 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 DFA253A6A74 for ; Thu, 1 Oct 2009 09:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.736 X-Spam-Level: X-Spam-Status: No, score=-5.736 tagged_above=-999 required=5 tests=[AWL=0.513, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enxaVFy8eoHP for ; Thu, 1 Oct 2009 09:12:57 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id A56743A6989 for ; Thu, 1 Oct 2009 09:12:56 -0700 (PDT) X-AuditID: c1b4fb24-b7ba0ae000005786-8e-4ac4d55c60b8 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 4D.1E.22406.C55D4CA4; Thu, 1 Oct 2009 18:14:20 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 18:13:04 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 18:13:03 +0200 Message-ID: <4AC4D50F.10605@ericsson.com> Date: Thu, 01 Oct 2009 18:13:03 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Marc Blanchet References: <4AAFF2C5.1010103@acm.org> <200909151616.16445.simon.perreault@viagenie.ca> <4AB0215F.1080407@acm.org> <4AB023B3.2010009@viagenie.ca> <4AB02784.8060604@acm.org> <4AB038E2.2070403@viagenie.ca> In-Reply-To: <4AB038E2.2070403@viagenie.ca> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 01 Oct 2009 16:13:03.0728 (UTC) FILETIME=[0DD6E700:01CA42B2] X-Brightmail-Tracker: AAAAAA== Cc: Peter Livesey , behave@ietf.org, Tim Polk Subject: Re: [BEHAVE] Discusses regarding security mechanism usage for TURN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 16:12:58 -0000 Hi, We ADs has discussed the deployment case where you deploy the TURN server on the border between a private domain and the Internet. And because of the clients being controlled and required to be coming from that private domain an per client authentication is not required for using the TURN server. We note that this may fulfill the security requirements. However, the current draft is substantially lacking in description of the details that are needed to handle this case. Both how you reliably determine that a client really is connecting from the trusted domain and how you ensure that the client know if it needs to use the authentication mechanism or not. I personally don't think documenting this model can be done quickly. I would note that TURN can be extended in various ways, that include adding additional security models. So starting work on a separate document for this solution sounds like a possible way forward. TURN has been under development under a long time. It is time we publish TURN. I do note that TURN drafts currently are hold up the following documents from being published: C3 AUTH48 draft-ietf-sipping-app-interaction-framework C3 AUTH48 draft-ietf-sipping-gruu-reg-event C3 MISSREF draft-ietf-sipping-v6-transition C3 AUTH48 draft-ietf-sip-gruu C3 MISSREF draft-ietf-mmusic-ice C3 AUTH48 draft-shacham-sipping-session-mobility C3 MISSREF* draft-ietf-sip-ice-option-tag C3 REF draft-ietf-behave-stun-test-vectors C3 AUTH48 draft-ietf-sip-sips C3 MISSREF draft-ietf-sip-ua-privacy C3 AUTH48 draft-ietf-sip-outbound C3 AUTH48 draft-ietf-sip-record-route-fix I will give the proponents for the above describe security solution time to answer. Then I intended to push forward to get TURN approved. Regards Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From matthew@matthew.at Thu Oct 1 09:24:53 2009 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 E50FD3A69C4 for ; Thu, 1 Oct 2009 09:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.252 X-Spam-Level: X-Spam-Status: No, score=-0.252 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_05=-1.11, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 TS68mrstD3Cs for ; Thu, 1 Oct 2009 09:24:53 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by core3.amsl.com (Postfix) with ESMTP id 523AC3A6A11 for ; Thu, 1 Oct 2009 09:24:53 -0700 (PDT) Received: from [10.10.155.2] (unknown [10.10.155.2]) by where.matthew.at (Postfix) with ESMTP id 310FA14807C; Thu, 1 Oct 2009 09:26:17 -0700 (PDT) Message-ID: <4AC4D828.2030009@matthew.at> Date: Thu, 01 Oct 2009 09:26:16 -0700 From: Matthew Kaufman User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Magnus Westerlund References: <4AAFF2C5.1010103@acm.org> <200909151616.16445.simon.perreault@viagenie.ca> <4AB0215F.1080407@acm.org> <4AB023B3.2010009@viagenie.ca> <4AB02784.8060604@acm.org> <4AB038E2.2070403@viagenie.ca> <4AC4D50F.10605@ericsson.com> In-Reply-To: <4AC4D50F.10605@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marc Blanchet , Peter Livesey , behave@ietf.org, Tim Polk Subject: Re: [BEHAVE] Discusses regarding security mechanism usage for TURN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: matthew@matthew.at List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 16:24:54 -0000 Magnus Westerlund wrote: > ... > > I will give the proponents for the above describe security solution time > to answer. Then I intended to push forward to get TURN approved. > > Due to the still-unaddressed issues raised by the addition of "CreatePermission required for each destination address" some number of drafts ago, TURN is not really suitable for my particular widely-distributed application any more anyway, so failing to address the TURN-server-at-border case won't be the reason TURN support is removed in favor of an alternative protocol. I had hoped that TURN would be the UDP-UDP proxy protocol of choice for a wide variety of UDP-based protocols, but it has unfortunately narrowed in capability so much that it will no longer work for me, so there will be at least one more UDP-UDP proxy protocol deployed in the world in order to meet my requirements. Matthew Kaufman From magnus.westerlund@ericsson.com Thu Oct 1 09:46:18 2009 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 AF73F3A67D3 for ; Thu, 1 Oct 2009 09:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.74 X-Spam-Level: X-Spam-Status: No, score=-5.74 tagged_above=-999 required=5 tests=[AWL=0.509, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNwKzZWc1s05 for ; Thu, 1 Oct 2009 09:46:18 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 7D7463A6855 for ; Thu, 1 Oct 2009 09:46:17 -0700 (PDT) X-AuditID: c1b4fb3e-b7b63ae0000049dc-48-4ac4dd2d8d29 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id FD.E4.18908.D2DD4CA4; Thu, 1 Oct 2009 18:47:42 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 18:47:06 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 18:47:06 +0200 Message-ID: <4AC4DD0A.3080408@ericsson.com> Date: Thu, 01 Oct 2009 18:47:06 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: matthew@matthew.at References: <4AAFF2C5.1010103@acm.org> <200909151616.16445.simon.perreault@viagenie.ca> <4AB0215F.1080407@acm.org> <4AB023B3.2010009@viagenie.ca> <4AB02784.8060604@acm.org> <4AB038E2.2070403@viagenie.ca> <4AC4D50F.10605@ericsson.com> <4AC4D828.2030009@matthew.at> In-Reply-To: <4AC4D828.2030009@matthew.at> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 01 Oct 2009 16:47:06.0077 (UTC) FILETIME=[CF2CA0D0:01CA42B6] X-Brightmail-Tracker: AAAAAA== Cc: Marc Blanchet , Peter Livesey , behave@ietf.org, Tim Polk Subject: Re: [BEHAVE] Discusses regarding security mechanism usage for TURN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 16:46:18 -0000 Matthew Kaufman skrev: > Magnus Westerlund wrote: >> ... >> >> I will give the proponents for the above describe security solution time >> to answer. Then I intended to push forward to get TURN approved. >> >> > Due to the still-unaddressed issues raised by the addition of > "CreatePermission required for each destination address" some number of > drafts ago, TURN is not really suitable for my particular > widely-distributed application any more anyway, so failing to address > the TURN-server-at-border case won't be the reason TURN support is > removed in favor of an alternative protocol. I think the addition of CreatePermission for each destination is the result of WG consensus. > > I had hoped that TURN would be the UDP-UDP proxy protocol of choice for > a wide variety of UDP-based protocols, but it has unfortunately narrowed > in capability so much that it will no longer work for me, so there will > be at least one more UDP-UDP proxy protocol deployed in the world in > order to meet my requirements. > For me it appears that the security requirements we have on the protocol prevents it from being applicable to all possible use cases for an UDP relay protocol. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From simon.perreault@viagenie.ca Thu Oct 1 09:52:20 2009 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 9ADDF3A6AA0 for ; Thu, 1 Oct 2009 09:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.114, 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 cySWL6k+Gjss for ; Thu, 1 Oct 2009 09:52:19 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 37FF128C12F for ; Thu, 1 Oct 2009 09:52:19 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 0A9A429E1620; Thu, 1 Oct 2009 12:53:44 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 007D429E15F5; Thu, 1 Oct 2009 12:53:44 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: behave@ietf.org Date: Thu, 1 Oct 2009 12:53:39 -0400 User-Agent: KMail/1.12.0 (Linux/2.6.30.5-43.fc11.x86_64; KDE/4.3.0; x86_64; ; ) References: <4AB038E2.2070403@viagenie.ca> <4AC4D50F.10605@ericsson.com> In-Reply-To: <4AC4D50F.10605@ericsson.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200910011253.40031.simon.perreault@viagenie.ca> Cc: Tim Polk , Peter Livesey , Marc Blanchet Subject: Re: [BEHAVE] Discusses regarding security mechanism usage for TURN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 16:52:20 -0000 On Thursday 01 October 2009 12:13:03 Magnus Westerlund wrote: > We note that this may fulfill the security requirements. However, the > current draft is substantially lacking in description of the details > that are needed to handle this case. Both how you reliably determine > that a client really is connecting from the trusted domain and how you > ensure that the client know if it needs to use the authentication > mechanism or not. Why must this use case be explained in detail? Is there a rule somewhere that says "each and every "SHOULD" in a document MUST include a complete discussion of the possible use cases for not complying"? If so, then a bunch of RFCs will need to be revised... Just s/MUST/SHOULD/ and be done with it. The Security Considerations section, in particular section 17.1.1, already explain the full implications. People are not stupid. It is plain as day that a TURN server offers a service, and authentication is a good idea if you don't want people abusing the service. I don't think having a MUST instead of a SHOULD will impact in any way the trust that people will have in this protocol. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From magnus.westerlund@ericsson.com Thu Oct 1 10:17:24 2009 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 4C3333A68D5 for ; Thu, 1 Oct 2009 10:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.745 X-Spam-Level: X-Spam-Status: No, score=-5.745 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEx5rEeg9gxU for ; Thu, 1 Oct 2009 10:17:23 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 151143A67BE for ; Thu, 1 Oct 2009 10:17:22 -0700 (PDT) X-AuditID: c1b4fb24-b7ba0ae000005786-79-4ac4e477b941 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 54.40.22406.774E4CA4; Thu, 1 Oct 2009 19:18:47 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 19:17:42 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 19:17:42 +0200 Message-ID: <4AC4E436.80301@ericsson.com> Date: Thu, 01 Oct 2009 19:17:42 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Simon Perreault References: <4AB038E2.2070403@viagenie.ca> <4AC4D50F.10605@ericsson.com> <200910011253.40031.simon.perreault@viagenie.ca> In-Reply-To: <200910011253.40031.simon.perreault@viagenie.ca> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 01 Oct 2009 17:17:42.0360 (UTC) FILETIME=[15AF2D80:01CA42BB] X-Brightmail-Tracker: AAAAAA== Cc: Marc Blanchet , Peter Livesey , behave@ietf.org, Tim Polk Subject: Re: [BEHAVE] Discusses regarding security mechanism usage for TURN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 17:17:24 -0000 Simon Perreault skrev: > On Thursday 01 October 2009 12:13:03 Magnus Westerlund wrote: >> We note that this may fulfill the security requirements. However, the >> current draft is substantially lacking in description of the details >> that are needed to handle this case. Both how you reliably determine >> that a client really is connecting from the trusted domain and how you >> ensure that the client know if it needs to use the authentication >> mechanism or not. > > Why must this use case be explained in detail? Is there a rule somewhere that > says "each and every "SHOULD" in a document MUST include a complete discussion > of the possible use cases for not complying"? If so, then a bunch of RFCs will > need to be revised... > > Just s/MUST/SHOULD/ and be done with it. > > The Security Considerations section, in particular section 17.1.1, already > explain the full implications. People are not stupid. It is plain as day that > a TURN server offers a service, and authentication is a good idea if you don't > want people abusing the service. > > I don't think having a MUST instead of a SHOULD will impact in any way the > trust that people will have in this protocol. The reason in this case is that it has a huge impact on the security properties of the protocol. The SHOULD is only applicable if you have an alternative solution that meets the security requirements. And that is what we now are proposing. Especially as we don't seem to have a good mechanism to know where a TURN server is located and if you can trust it if not using authentication or not. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From petithug@acm.org Thu Oct 1 10:32:02 2009 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 2A8C228C0CF for ; Thu, 1 Oct 2009 10:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.023 X-Spam-Level: X-Spam-Status: No, score=-102.023 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 nLvAigUchGmu for ; Thu, 1 Oct 2009 10:32:01 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 66DD828C180 for ; Thu, 1 Oct 2009 10:32:01 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id CD1B26C98528; Thu, 1 Oct 2009 17:33:26 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 1919A6C98522; Thu, 1 Oct 2009 17:33:26 +0000 (UTC) Message-ID: <4AC4E7E5.4020809@acm.org> Date: Thu, 01 Oct 2009 10:33:25 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: Simon Perreault References: <4AB038E2.2070403@viagenie.ca> <4AC4D50F.10605@ericsson.com> <200910011253.40031.simon.perreault@viagenie.ca> In-Reply-To: <200910011253.40031.simon.perreault@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Tim Polk , Peter Livesey , behave@ietf.org, Marc Blanchet Subject: Re: [BEHAVE] Discusses regarding security mechanism usage for TURN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 17:32:02 -0000 Simon Perreault wrote: > On Thursday 01 October 2009 12:13:03 Magnus Westerlund wrote: >> We note that this may fulfill the security requirements. However, the >> current draft is substantially lacking in description of the details >> that are needed to handle this case. Both how you reliably determine >> that a client really is connecting from the trusted domain and how you >> ensure that the client know if it needs to use the authentication >> mechanism or not. > > Why must this use case be explained in detail? Is there a rule somewhere that > says "each and every "SHOULD" in a document MUST include a complete discussion > of the possible use cases for not complying"? Yes, for security. RFC 2119 is clear on that: "[RFC 2129] terms are frequently used to specify behavior with security implications. The effects on security of not implementing a MUST or SHOULD, or doing something the specification says MUST NOT or SHOULD NOT be done may be very subtle. Document authors should take the time to elaborate the security implications of not following recommendations or requirements as most implementors will not have had the benefit of the experience and discussion that produced the specification." > If so, then a bunch of RFCs will > need to be revised... > > Just s/MUST/SHOULD/ and be done with it. > > The Security Considerations section, in particular section 17.1.1, already > explain the full implications. People are not stupid. It is plain as day that > a TURN server offers a service, and authentication is a good idea if you don't > want people abusing the service. > > I don't think having a MUST instead of a SHOULD will impact in any way the > trust that people will have in this protocol. > > Simon -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From simon.perreault@viagenie.ca Thu Oct 1 10:40:28 2009 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 659223A6ABF for ; Thu, 1 Oct 2009 10:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.110, 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 UpPglxfqOIN0 for ; Thu, 1 Oct 2009 10:40:27 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id E658E3A6AC4 for ; Thu, 1 Oct 2009 10:40:26 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 8876229E1624; Thu, 1 Oct 2009 13:41:52 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 7DC0E29E1615; Thu, 1 Oct 2009 13:41:52 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: "Marc Petit-Huguenin" Date: Thu, 1 Oct 2009 13:41:49 -0400 User-Agent: KMail/1.12.0 (Linux/2.6.30.5-43.fc11.x86_64; KDE/4.3.0; x86_64; ; ) References: <200910011253.40031.simon.perreault@viagenie.ca> <4AC4E7E5.4020809@acm.org> In-Reply-To: <4AC4E7E5.4020809@acm.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200910011341.49292.simon.perreault@viagenie.ca> Cc: Tim Polk , Peter Livesey , behave@ietf.org, Marc Blanchet Subject: Re: [BEHAVE] Discusses regarding security mechanism usage for TURN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 17:40:28 -0000 On Thursday 01 October 2009 13:33:25 Marc Petit-Huguenin wrote: > "[RFC 2129] terms are frequently used to specify behavior with security > implications. The effects on security of not implementing a MUST or > SHOULD, or doing something the specification says MUST NOT or SHOULD NOT be > done may be very subtle. Document authors should take the time to elaborate > the security implications of not following recommendations or requirements > as most implementors will not have had the benefit of the experience and > discussion that produced the specification." As I said, this is already fulfilled by section 17.1.1. What seems to be required by IESG is discussion of one use case for not complying with the SHOULD. I think that's not necessary. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From teemu.savolainen@nokia.com Mon Oct 5 01:50:53 2009 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 4C95C3A6774 for ; Mon, 5 Oct 2009 01:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIbxUBky2YEt for ; Mon, 5 Oct 2009 01:50:52 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 23D793A6892 for ; Mon, 5 Oct 2009 01:50:51 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n958q7am007198 for ; Mon, 5 Oct 2009 11:52:24 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 11:52:06 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 11:52:05 +0300 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.3959); Mon, 5 Oct 2009 11:51:53 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 5 Oct 2009 10:51:51 +0200 From: To: Date: Mon, 5 Oct 2009 10:50:25 +0200 Thread-Topic: DNS64, AAAA synthesis, and multihoming related question Thread-Index: AcpFmOFPK38+986rSVWmY0aweIzwnQ== Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F3EF0E69687@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_18034D4D7FE9AE48BF19AB1B0EF2729F3EF0E69687NOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 05 Oct 2009 08:51:53.0012 (UTC) FILETIME=[15B72F40:01CA4599] X-Nokia-AV: Clean Subject: [BEHAVE] DNS64, AAAA synthesis, and multihoming related question 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, 05 Oct 2009 08:50:53 -0000 --_000_18034D4D7FE9AE48BF19AB1B0EF2729F3EF0E69687NOKEUMSG01mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A question relating to DNS64 and multihoming. (I'm updating my DNS server s= election draft: http://tools.ietf.org/internet-drafts/draft-savolainen-mif-= dns-server-selection-00.txt ) The synthesised AAAA record may be constructed by using Network-Specific Pr= efix or Well-Known Prefix, right? Let's assume we have a host connected to two networks which both employ pro= tocol translators (both are IPv6-network-to-IPv4-Internet deployments). In the case of Network-Specific Prefix, the synthesised AAAA record can onl= y be used on the interface it was learned from (or synthesised for in stub = resolver based DNS64)? Trying to send IPv6 packet to the synthesised IPv6 d= estination address on wrong interface would unlikely work, right? I.e. with= Network-Specific Prefix, the AAAA record should only be used on the interf= ace it was learned from (synthesised for)? In the case of Well-Known Prefix, and non-private IPv4 destination address,= the AAAA record should be used on the interface it was learned from (synth= esised for), but in case both networks use WKP based Pref64, the synthesise= d AAAA record could actually be used on either interface, right? In the case of Well-Known Prefix, and private IPv4 destination address [RFC= 1918], the AAAA record must only be used on the interface it was learned fr= om (synthesised for). To summarize: can it be stated that synthesised AAAA record should only be = used on the network interface the host received one (or host synthesised it= for)? Thanks, Teemu --_000_18034D4D7FE9AE48BF19AB1B0EF2729F3EF0E69687NOKEUMSG01mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
A question relating to DNS64 and multihoming. (I'm updating my DNS ser= ver selection draft: htt= p://tools.ietf.org/internet-drafts/draft-savolainen-mif-dns-server-selectio= n-00.txt )
 
The synthesised AAAA record may be constructed by using Network-Specif= ic Prefix or Well-Known Prefix, right?
 
Let's assume we have a host connected to two networks which both emplo= y protocol translators (both are IPv6-network-to-IPv4-Internet deployments)= .
 
In the case of Network-Specific Prefix, the synthesised AAAA record ca= n only be used on the interface it was learned from (or synthesised for in = stub resolver based DNS64)? Trying to send IPv6 packet to the synthesised I= Pv6 destination address on wrong interface would unlikely work, right? I.e. with Network-Specific Prefix, th= e AAAA record should only be used on the interface it was learned from (syn= thesised for)?
 
In the case of Well-Known Prefix, and non-private IPv4 destination add= ress, the AAAA record should be used on the interface it was learned from (= synthesised for), but in case both networks use WKP based Pref64, the synth= esised AAAA record could actually be used on either interface, right?
 
In the case of Well-Known Prefix, and private IPv4 destination address= [RFC1918], the AAAA record must only be used on the interface it was learn= ed from (synthesised for).
 
 
To summarize: can it be stated that synthesised AAAA record should onl= y be used on the network interface the host received one (or host synthesis= ed it for)?
 
 
Thanks,
 
        Teemu
 
 --_000_18034D4D7FE9AE48BF19AB1B0EF2729F3EF0E69687NOKEUMSG01mgd_-- From simon.perreault@viagenie.ca Mon Oct 5 04:37:12 2009 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 14B7A3A69C6 for ; Mon, 5 Oct 2009 04:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.107, 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 nu4eMWAJbure for ; Mon, 5 Oct 2009 04:37:11 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id DBFE63A69C3 for ; Mon, 5 Oct 2009 04:37:10 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 82CA429E1628; Mon, 5 Oct 2009 07:38:45 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 3523429E1618; Mon, 5 Oct 2009 07:38:45 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: behave@ietf.org Date: Mon, 5 Oct 2009 07:38:44 -0400 User-Agent: KMail/1.12.0 (Linux/2.6.30.5-43.fc11.x86_64; KDE/4.3.0; x86_64; ; ) References: <18034D4D7FE9AE48BF19AB1B0EF2729F3EF0E69687@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F3EF0E69687@NOK-EUMSG-01.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200910050738.44626.simon.perreault@viagenie.ca> Subject: Re: [BEHAVE] DNS64, AAAA synthesis, and multihoming related question 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, 05 Oct 2009 11:37:12 -0000 On Monday 05 October 2009 04:50:25 teemu.savolainen@nokia.com wrote: > To summarize: can it be stated that synthesised AAAA record should only be > used on the network interface the host received one (or host synthesised it > for)? Well, theoretically one could query a DNS64 server on one interface and use its synthetic records on another, as long as the DNS64 and the NAT64 use the same prefix. In all currently envisaged use cases it will end up being the same interface. So I would rephrase like this: a AAAA record synthesized by a DNS64 using a given Pref64::/n can only be used on a network interface where a NAT64 is available and is using the same Pref64::/n. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From marcelo@it.uc3m.es Mon Oct 5 06:17:31 2009 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 5E16928C186 for ; Mon, 5 Oct 2009 06:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEJzu9m32Tzz for ; Mon, 5 Oct 2009 06:17:30 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 184D73A69D0 for ; Mon, 5 Oct 2009 06:17:29 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp03.uc3m.es (Postfix) with ESMTP id 45C0572D2AB; Mon, 5 Oct 2009 15:19:03 +0200 (CEST) Message-ID: <4AC9F247.2070906@it.uc3m.es> Date: Mon, 05 Oct 2009 15:19:03 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <18034D4D7FE9AE48BF19AB1B0EF2729F3EF0E69687@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F3EF0E69687@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16928.003 Cc: behave@ietf.org Subject: Re: [BEHAVE] DNS64, AAAA synthesis, and multihoming related question 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, 05 Oct 2009 13:17:31 -0000 teemu.savolainen@nokia.com escribió: > Hi, > > A question relating to DNS64 and multihoming. (I'm updating my DNS > server selection draft: > _http://tools.ietf.org/internet-drafts/draft-savolainen-mif-dns-server-selection-00.txt_ > ) > > The synthesised AAAA record may be constructed by using > Network-Specific Prefix or Well-Known Prefix, right? > > Let's assume we have a host connected to two networks which both > employ protocol translators (both are IPv6-network-to-IPv4-Internet > deployments). > > In the case of Network-Specific Prefix, the synthesised AAAA record > can only be used on the interface it was learned from (or synthesised > for in stub resolver based DNS64)? Trying to send IPv6 packet to the > synthesised IPv6 destination address on wrong interface would unlikely > work, right? I.e. with Network-Specific Prefix, the AAAA record should > only be used on the interface it was learned from (synthesised for)? > > In the case of Well-Known Prefix, and non-private IPv4 destination > address, the AAAA record should be used on the interface it was > learned from (synthesised for), but in case both networks use WKP > based Pref64, the synthesised AAAA record could actually be used on > either interface, right? well, but the problem that you may encounter here is that in the other interface, you don't have a NAT64 available, so packets addressed to the WK prefix are sink So, if you are sure that there are NAT64 in both interfaces, then you could use synthetic AAAA RR with the WK prefix in any of them, but the problem is how to know that you have a NAT64 in the other interface. I assume that if you receive a synthetic AAAA RR in one interface, then you can reach a NAT64 in that interface, but assuming that becuase you have received a synthetic AAAA RR in one interface you can reach a NAT64 in the other one, doens't seem wise. > > In the case of Well-Known Prefix, and private IPv4 destination address > [RFC1918], the AAAA record must only be used on the interface it was > learned from (synthesised for). > WKP and private addresses are not supposed to be used together, so if you receive this, something went wrong > > To summarize: can it be stated that synthesised AAAA record should > only be used on the network interface the host received one (or host > synthesised it for)? That seems to be the safe side, yes. Regards, marcelo > > > Thanks, > > Teemu > > ------------------------------------------------------------------------ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From marcelo@it.uc3m.es Mon Oct 5 06:18:57 2009 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 0DD503A69B5 for ; Mon, 5 Oct 2009 06:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dN1f9JEesRWm for ; Mon, 5 Oct 2009 06:18:56 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id ED49E3A69CC for ; Mon, 5 Oct 2009 06:18:55 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp03.uc3m.es (Postfix) with ESMTP id 88A5172D8C4; Mon, 5 Oct 2009 15:20:29 +0200 (CEST) Message-ID: <4AC9F29D.6070705@it.uc3m.es> Date: Mon, 05 Oct 2009 15:20:29 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Simon Perreault References: <18034D4D7FE9AE48BF19AB1B0EF2729F3EF0E69687@NOK-EUMSG-01.mgdnok.nokia.com> <200910050738.44626.simon.perreault@viagenie.ca> In-Reply-To: <200910050738.44626.simon.perreault@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16928.003 Cc: behave@ietf.org Subject: Re: [BEHAVE] DNS64, AAAA synthesis, and multihoming related question 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, 05 Oct 2009 13:18:57 -0000 Simon Perreault escribió: > On Monday 05 October 2009 04:50:25 teemu.savolainen@nokia.com wrote: > >> To summarize: can it be stated that synthesised AAAA record should only be >> used on the network interface the host received one (or host synthesised it >> for)? >> > > Well, theoretically one could query a DNS64 server on one interface and use > its synthetic records on another, as long as the DNS64 and the NAT64 use the > same prefix. In all currently envisaged use cases it will end up being the > same interface. > > So I would rephrase like this: a AAAA record synthesized by a DNS64 using a > given Pref64::/n can only be used on a network interface where a NAT64 is > available and is using the same Pref64::/n. > right, the problem that i guess Teemu has i how to guess if there is a NAT 64 in that interface. I think that a reasonable guess is that there ought ot be a NAT64 through the interface that you have recieved the synthetic AAAA RR, but not a clue about the other interfaces imho Regards, marcelo > Simon > From teemu.savolainen@nokia.com Mon Oct 5 06:53:26 2009 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 C16FC28C1E9 for ; Mon, 5 Oct 2009 06:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.255 X-Spam-Level: X-Spam-Status: No, score=-6.255 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgjeqn7PThDN for ; Mon, 5 Oct 2009 06:53:25 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 8DFFB28C1DE for ; Mon, 5 Oct 2009 06:53:25 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n95DstjA000423; Mon, 5 Oct 2009 16:54:57 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 16:54:43 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 16:54:33 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 5 Oct 2009 15:54:31 +0200 From: To: , Date: Mon, 5 Oct 2009 15:53:04 +0200 Thread-Topic: [BEHAVE] DNS64, AAAA synthesis, and multihoming related question Thread-Index: AcpFvq2KIjhJYaIyRgursnRxwa1rhgAAs46g Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F3EF0ED515D@NOK-EUMSG-01.mgdnok.nokia.com> References: <18034D4D7FE9AE48BF19AB1B0EF2729F3EF0E69687@NOK-EUMSG-01.mgdnok.nokia.com> <200910050738.44626.simon.perreault@viagenie.ca> <4AC9F29D.6070705@it.uc3m.es> In-Reply-To: <4AC9F29D.6070705@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Oct 2009 13:54:33.0522 (UTC) FILETIME=[5E391920:01CA45C3] X-Nokia-AV: Clean Cc: behave@ietf.org Subject: Re: [BEHAVE] DNS64, AAAA synthesis, and multihoming related question 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, 05 Oct 2009 13:53:26 -0000 Thanks Marcelo and Simon, I'm mainly looking at the aspect of a host learning synthetic AAAA record f= rom one DNS server on one network interface: the host should not use the le= arned address on other network interfaces (unless they are actually facing = the same network domain) even if the other interfaces would be more preferr= ed for other reasons.=20 E.g. if a host has learned synthetic AAAA from DNS server of IPv6 cellular = access, it should not use it on some random IPv6-enabled WLAN access, but i= nstead redo DNS query also on the WLAN interface. Best regards, Teemu >-----Original Message----- >From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org]=20 >On Behalf Of ext marcelo bagnulo braun >Sent: 05 October, 2009 16:20 >To: Simon Perreault >Cc: behave@ietf.org >Subject: Re: [BEHAVE] DNS64, AAAA synthesis, and multihoming=20 >related question > >Simon Perreault escribi=F3: >> On Monday 05 October 2009 04:50:25 teemu.savolainen@nokia.com wrote: >> =20 >>> To summarize: can it be stated that synthesised AAAA record should=20 >>> only be used on the network interface the host received one=20 >(or host=20 >>> synthesised it for)? >>> =20 >> >> Well, theoretically one could query a DNS64 server on one interface=20 >> and use its synthetic records on another, as long as the=20 >DNS64 and the=20 >> NAT64 use the same prefix. In all currently envisaged use cases it=20 >> will end up being the same interface. >> >> So I would rephrase like this: a AAAA record synthesized by a DNS64=20 >> using a given Pref64::/n can only be used on a network=20 >interface where=20 >> a NAT64 is available and is using the same Pref64::/n. >> =20 > > >right, the problem that i guess Teemu has i how to guess if=20 >there is a NAT 64 in that interface. I think that a reasonable=20 >guess is that there ought ot be a NAT64 through the interface=20 >that you have recieved the synthetic AAAA RR, but not a clue=20 >about the other interfaces imho > >Regards, marcelo > >> Simon >> =20 > >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave >= From ajs@shinkuro.com Mon Oct 5 07:23:15 2009 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 73F833A682D for ; Mon, 5 Oct 2009 07:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=0.388, 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 Ji7ynxUplCH9 for ; Mon, 5 Oct 2009 07:23:14 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id B92233A657C for ; Mon, 5 Oct 2009 07:23:14 -0700 (PDT) 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 37F132FE8CA1 for ; Mon, 5 Oct 2009 14:24:49 +0000 (UTC) Date: Mon, 5 Oct 2009 10:24:43 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20091005142443.GA12886@shinkuro.com> References: <18034D4D7FE9AE48BF19AB1B0EF2729F3EF0E69687@NOK-EUMSG-01.mgdnok.nokia.com> <200910050738.44626.simon.perreault@viagenie.ca> <4AC9F29D.6070705@it.uc3m.es> <18034D4D7FE9AE48BF19AB1B0EF2729F3EF0ED515D@NOK-EUMSG-01.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F3EF0ED515D@NOK-EUMSG-01.mgdnok.nokia.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] DNS64, AAAA synthesis, and multihoming related question 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, 05 Oct 2009 14:23:15 -0000 On Mon, Oct 05, 2009 at 03:53:04PM +0200, teemu.savolainen@nokia.com wrote: > record from one DNS server on one network interface: the host should > not use the learned address on other network interfaces (unless they > are actually facing the same network domain) even if the other > interfaces would be more preferred for other reasons. Not even that "unless" is right. "The same network domain" is not exactly meaningful in the context of resolution (or anyway it's often not meaningful in the way people think it is). Therefore, the limitation should be that you only use results obtained by one interface on that interface. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From suresh.krishnan@ericsson.com Mon Oct 5 13:04:51 2009 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 1A49E28C2A3 for ; Mon, 5 Oct 2009 13:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLWTzo0P-LBz for ; Mon, 5 Oct 2009 13:04:50 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 5FBE928C2A1 for ; Mon, 5 Oct 2009 13:04:50 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n95K6Nw7028885; Mon, 5 Oct 2009 15:06:25 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 15:06:00 -0500 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 15:05:59 -0500 Received: from [142.133.10.113] (147.117.20.212) by eusaamw0712.eamcs.ericsson.se (147.117.20.182) with Microsoft SMTP Server id 8.1.375.2; Mon, 5 Oct 2009 16:05:59 -0400 Message-ID: <4ACA506B.4000602@ericsson.com> Date: Mon, 5 Oct 2009 16:00:43 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andrew Sullivan References: <18034D4D7FE9AE48BF19AB1B0EF2729F3EF0E69687@NOK-EUMSG-01.mgdnok.nokia.com> <200910050738.44626.simon.perreault@viagenie.ca> <4AC9F29D.6070705@it.uc3m.es> <18034D4D7FE9AE48BF19AB1B0EF2729F3EF0ED515D@NOK-EUMSG-01.mgdnok.nokia.com> <20091005142443.GA12886@shinkuro.com> In-Reply-To: <20091005142443.GA12886@shinkuro.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2009 20:05:59.0855 (UTC) FILETIME=[41E9A3F0:01CA45F7] Cc: "behave@ietf.org" Subject: Re: [BEHAVE] DNS64, AAAA synthesis, and multihoming related question 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, 05 Oct 2009 20:04:51 -0000 Hi Andrew, On 09-10-05 10:24 AM, Andrew Sullivan wrote: > On Mon, Oct 05, 2009 at 03:53:04PM +0200, teemu.savolainen@nokia.com wrote: > Not even that "unless" is right. "The same network domain" is not > exactly meaningful in the context of resolution (or anyway it's often > not meaningful in the way people think it is). Therefore, the > limitation should be that you only use results obtained by one > interface on that interface. I agree with you. The DNS server information should be interface specific. This is the only scenario that is guaranteed to work. Cheers Suresh From ajs@shinkuro.com Mon Oct 5 13:14:15 2009 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 8E2373A67A8 for ; Mon, 5 Oct 2009 13:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=0.495, 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 x+IQabxQYWaU for ; Mon, 5 Oct 2009 13:14:14 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 546893A68D3 for ; Mon, 5 Oct 2009 13:13:53 -0700 (PDT) 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 24C4B2FE8CA1 for ; Mon, 5 Oct 2009 20:15:26 +0000 (UTC) Date: Mon, 5 Oct 2009 16:15:24 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20091005201524.GR25543@shinkuro.com> References: <18034D4D7FE9AE48BF19AB1B0EF2729F3EF0E69687@NOK-EUMSG-01.mgdnok.nokia.com> <200910050738.44626.simon.perreault@viagenie.ca> <4AC9F29D.6070705@it.uc3m.es> <18034D4D7FE9AE48BF19AB1B0EF2729F3EF0ED515D@NOK-EUMSG-01.mgdnok.nokia.com> <20091005142443.GA12886@shinkuro.com> <4ACA506B.4000602@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ACA506B.4000602@ericsson.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] DNS64, AAAA synthesis, and multihoming related question 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, 05 Oct 2009 20:14:15 -0000 On Mon, Oct 05, 2009 at 04:00:43PM -0400, Suresh Krishnan wrote: > I agree with you. The DNS server information should be interface > specific. This is the only scenario that is guaranteed to work. Thanks. Unless anyone objects, this stricture will be in the next dns64 draft (on which I am working this week). A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From teemu.savolainen@nokia.com Mon Oct 5 14:20:54 2009 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 5C6533A684E for ; Mon, 5 Oct 2009 14:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XY30ELHRTs+x for ; Mon, 5 Oct 2009 14:20:53 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 51B2D3A67ED for ; Mon, 5 Oct 2009 14:20:53 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n95LMOI0031920; Tue, 6 Oct 2009 00:22:26 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 00:22:25 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 00:22:20 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 5 Oct 2009 23:22:19 +0200 From: To: , Date: Mon, 5 Oct 2009 23:20:52 +0200 Thread-Topic: [BEHAVE] DNS64, AAAA synthesis, and multihoming related question Thread-Index: AcpF+KbEi+bOQNUsQKWXQx5VVEbDdwACMYQw Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F3EF0ED53E2@NOK-EUMSG-01.mgdnok.nokia.com> References: <18034D4D7FE9AE48BF19AB1B0EF2729F3EF0E69687@NOK-EUMSG-01.mgdnok.nokia.com> <200910050738.44626.simon.perreault@viagenie.ca> <4AC9F29D.6070705@it.uc3m.es> <18034D4D7FE9AE48BF19AB1B0EF2729F3EF0ED515D@NOK-EUMSG-01.mgdnok.nokia.com> <20091005142443.GA12886@shinkuro.com> <4ACA506B.4000602@ericsson.com> <20091005201524.GR25543@shinkuro.com> In-Reply-To: <20091005201524.GR25543@shinkuro.com> 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 X-OriginalArrivalTime: 05 Oct 2009 21:22:20.0499 (UTC) FILETIME=[EC307230:01CA4601] X-Nokia-AV: Clean Subject: Re: [BEHAVE] DNS64, AAAA synthesis, and multihoming related question 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, 05 Oct 2009 21:20:54 -0000 Thanks all, this is what I wanted to get confirmed.=20 Teemu >-----Original Message----- >From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org]=20 >On Behalf Of ext Andrew Sullivan >Sent: 05 October, 2009 23:15 >To: behave@ietf.org >Subject: Re: [BEHAVE] DNS64, AAAA synthesis, and multihoming=20 >related question > >On Mon, Oct 05, 2009 at 04:00:43PM -0400, Suresh Krishnan wrote: >> I agree with you. The DNS server information should be interface=20 >> specific. This is the only scenario that is guaranteed to work. > >Thanks. Unless anyone objects, this stricture will be in the next >dns64 draft (on which I am working this week). > >A > >-- >Andrew Sullivan >ajs@shinkuro.com >Shinkuro, Inc. >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave >= From cb.list6@gmail.com Mon Oct 5 16:36:48 2009 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 2EC0D3A68D0 for ; Mon, 5 Oct 2009 16:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1R35Gijez8h for ; Mon, 5 Oct 2009 16:36:47 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 489953A68CE for ; Mon, 5 Oct 2009 16:36:46 -0700 (PDT) Received: by ywh13 with SMTP id 13so3399664ywh.31 for ; Mon, 05 Oct 2009 16:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:date:to :message-id:content-type:mime-version; bh=WToMsZzeHV2z39SZvUx1ZEFATUhSE8y3aGBNttVlMA4=; b=ZMyTE4DBLsYz2J4haPdoKQia9XwYvYA5X6y+33aYrUdcPSak/1DW1PiIUU9fQFEw2J aYiJxOi3PMRFNlgLi7j2H6Y4wNNyljB09Y9iGK0vrsUoi5kuQvHPcbGNW7ICexftFbSO etYEOM6LoLdaf9f2qr1KKEzgnwPlp0cYF4EIg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:date:to:message-id:content-type:mime-version; b=jVcWME9SKWmlb1khYx6tnZ1TaeoDextVYpEyVUKpY+80PFXjax9r6JU3zS0iCP4nD4 NJfd6dsO6u9UbcAvRyD6LQGmwP5s8NVxSZF7yOpeRwqtAeJpcpuAu+Zjk9iSF7J2R2mC MWLCghIofCPg1vffKCpmpHcyBsYW7FhltpviY= Received: by 10.101.144.30 with SMTP id w30mr728039ann.188.1254785899111; Mon, 05 Oct 2009 16:38:19 -0700 (PDT) Received: from localhost (m170e36d0.tmodns.net [208.54.14.23]) by mx.google.com with ESMTPS id 21sm171193yxe.1.2009.10.05.16.38.15 (version=SSLv3 cipher=RC4-MD5); Mon, 05 Oct 2009 16:38:18 -0700 (PDT) From: cam byrne Date: Mon, 05 Oct 2009 16:38:08 -0700 To: Andrew Sullivan , behave@ietf.org Message-ID: <20091005201524.GR25543@shinkuro.com> Content-Type: multipart/mixed; boundary="----LST95BPTXHAVJ0DKG2H34RF9GANLNL" MIME-Version: 1.0 Subject: Re: [BEHAVE] DNS64, AAAA synthesis, and multihoming related question 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, 05 Oct 2009 23:36:48 -0000 ------LST95BPTXHAVJ0DKG2H34RF9GANLNL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSBhbHNvIGFncmVlLiAgSXQgaXMgdGhlIHNpbXBsZXN0IHdheS4gCgotQ2FtZXJvbiBCeXJuZSAK CkFuZHJldyBTdWxsaXZhbiA8YWpzQHNoaW5rdXJvLmNvbT4gd3JvdGU6Cgo+T24gTW9uLCBPY3Qg MDUsIDIwMDkgYXQgMDQ6MDA6NDNQTSAtMDQwMCwgU3VyZXNoIEtyaXNobmFuIHdyb3RlOg0KPj4g SSBhZ3JlZSB3aXRoIHlvdS4gVGhlIEROUyBzZXJ2ZXIgaW5mb3JtYXRpb24gc2hvdWxkIGJlIGlu dGVyZmFjZSAgDQo+PiBzcGVjaWZpYy4gVGhpcyBpcyB0aGUgb25seSBzY2VuYXJpbyB0aGF0IGlz IGd1YXJhbnRlZWQgdG8gd29yay4NCj4NCj5UaGFua3MuICBVbmxlc3MgYW55b25lIG9iamVjdHMs IHRoaXMgc3RyaWN0dXJlIHdpbGwgYmUgaW4gdGhlIG5leHQNCj5kbnM2NCBkcmFmdCAob24gd2hp Y2ggSSBhbSB3b3JraW5nIHRoaXMgd2VlaykuDQo+DQo+QQ0KPg0KPi0tIA0KPkFuZHJldyBTdWxs aXZhbg0KPmFqc0BzaGlua3Vyby5jb20NCj5TaGlua3VybywgSW5jLg0KPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+QmVoYXZlIG1haWxpbmcgbGlzdA0K PkJlaGF2ZUBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v YmVoYXZlDQo= ------LST95BPTXHAVJ0DKG2H34RF9GANLNL-- From marka@isc.org Mon Oct 5 19:46:04 2009 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 CA2693A6823 for ; Mon, 5 Oct 2009 19:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 lde7dSJBLFmZ for ; Mon, 5 Oct 2009 19:46:04 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id E9C853A680F for ; Mon, 5 Oct 2009 19:46:03 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 0504BE601C; Tue, 6 Oct 2009 02:47:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n962lV1W017132; Tue, 6 Oct 2009 13:47:31 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200910060247.n962lV1W017132@drugs.dv.isc.org> To: cam byrne From: Mark Andrews References: <20091005201524.GR25543@shinkuro.com> In-reply-to: Your message of "Mon, 05 Oct 2009 16:38:08 PDT." <20091005201524.GR25543@shinkuro.com> Date: Tue, 06 Oct 2009 13:47:31 +1100 Sender: marka@isc.org Cc: Andrew Sullivan , behave@ietf.org Subject: Re: [BEHAVE] DNS64, AAAA synthesis, and multihoming related question X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 02:46:04 -0000 The real problem is that RA's don't provide "site" information, just link information. If we had site information provided then address selection rules would actually work. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From root@core3.amsl.com Wed Oct 7 08:00:01 2009 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B341A3A6939; Wed, 7 Oct 2009 08:00:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20091007150001.B341A3A6939@core3.amsl.com> Date: Wed, 7 Oct 2009 08:00:01 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] BEHAVE interim teleconference call X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 15:00:01 -0000 As announced at the Stockholm IETF's BEHAVE meeting, BEHAVE will be using WebEx and PSTN conferencing for the following interim meeting to discuss 6/4 translation and advance those documents: Wednesday, October 21, 7am-9am Pacific Time Per http://www.ietf.org/meeting/cutoff-dates.html#76, the cut-off for revised I-Ds is October 26. Agendas WebEx URL and PSTN dial-in information will be published on BEHAVE's wiki at http://trac.tools.ietf.org/wg/behave/trac/wiki From zhouboyj@gmail.com Wed Oct 7 09:05:58 2009 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 B8D7628C1A9; Wed, 7 Oct 2009 09:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=0.607, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLMatkIotlTU; Wed, 7 Oct 2009 09:05:56 -0700 (PDT) Received: from mail-iw0-f186.google.com (mail-iw0-f186.google.com [209.85.223.186]) by core3.amsl.com (Postfix) with ESMTP id 9818E28C18B; Wed, 7 Oct 2009 09:05:56 -0700 (PDT) Received: by iwn16 with SMTP id 16so2113787iwn.29 for ; Wed, 07 Oct 2009 09:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=no6WIgtUXQMsFWF/wNfrZbp6NeQQC5THmeMJf/F3L48=; b=Ip57iuMFK8Cmkj1Tr5a6JEv5RjzEElxayhRs+6LngH4+XmJijcnEocuT/7CUnMAQnl IUBKpeoLvX5KSYmx+qpaX9fGUD9A82VKLFy+n4t06x46rZSNmYWMA0CuIcfyIDbp+pn1 uCD5jyMlCoa/gugarXi3cfTZ5i7308XBQc5AQ= 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=aJQBKGst0ccZcGwxbqDagvaLAGkz8VSUo3osg2JB7kYM7D4XxYh5nFxfy/33bidUYd pdDiKhVe0nzJg8Yb/mU58Ycr/7dHOznyNkaveY6UHpUhiu5RTU4YC0AkA9TseIZK4t25 xCG7nCFcJFUXw+93LIKzTzff9qWe8Z4serM9c= MIME-Version: 1.0 Received: by 10.231.122.139 with SMTP id l11mr67273ibr.53.1254931653955; Wed, 07 Oct 2009 09:07:33 -0700 (PDT) In-Reply-To: <20090929163001.CBD933A6942@core3.amsl.com> References: <20090929163001.CBD933A6942@core3.amsl.com> Date: Thu, 8 Oct 2009 00:07:33 +0800 Message-ID: <36a593230910070907p6b6f4be9xf4c344d055587cbf@mail.gmail.com> From: bo zhou To: Dave Thaler , Dan Wing Content-Type: multipart/alternative; boundary=001485f99caa73903204755a8bdc Cc: behave@ietf.org, iesg@ietf.org, ietf-announce@ietf.org Subject: Re: [BEHAVE] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 16:05:58 -0000 --001485f99caa73903204755a8bdc Content-Type: text/plain; charset=ISO-8859-1 Hi Dave and Dan, I just found the charter of the Behave has been modified. "5. An IPv6 network to an IPv4 network, i.e., perform translation between IPv6 and IPv4 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translation function is intended to service a specific IPv6 network of arbitrary size and a specific IPv4 network of arbitrary size (neither of which are the Internet)." Does this cover host based translator solutions for 6 to 4? Regards, Bo Zhou On Wed, Sep 30, 2009 at 12:30 AM, IESG Secretary wrote: > A modified charter has been submitted for the Behavior Engineering for > Hindrance Avoidance (behave) working group in the Transport Area of the > IETF. The IESG has not made any determination as yet. The modified > charter is provided below for informational purposes only. Please send > your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, October > 6, 2009. > > Behavior Engineering for Hindrance Avoidance (behave) > ----------------------------------------------------- > Current Status: Active Working Group > Last Modified: 2009-09-09 > > Current Status: Active Working Group > > Additional information is available at tools.ietf.org/wg/behave > Chair(s): > > * Dan Wing > * Dave Thaler > > Transport Area Director(s): > > * Magnus Westerlund > * Lars Eggert > > Transport Area Advisor: > > * Magnus Westerlund > > Mailing Lists: > General Discussion: behave@ietf.org > To Subscribe: behave-request@ietf.org > In Body: In Body: subscribe > Archive: http://www.ietf.org/mail-archive/web/behave > > Description of Working Group: > > The behavior of NATs varies from one implementation to another. As a > result it is very difficult for applications to predict or discover the > behavior of these devices. Predicting and/or discovering the behavior > of NATs is important for designing application protocols and NAT > traversal techniques that work reliably in existing networks. This > situation is especially problematic for end-to-end applications where > one or both end-points are behind a NAT, such as multiuser games, > interactive multimedia and P2P download. > > The working group documents best current practices to enable NATs to > function in as deterministic a fashion as possible. The NAT behavior > practices will be application independent. This has already completed > for UDP, TCP, DCCP, Multicast and ICMP. It continues with SCTP and any > additional protocol deemed necessary to handle. The WG has documented > approaches for characterizing and testing NAT devices. > > BEHAVE will develop protocol-independent toolkits usable by application > protocols for NAT traversal. The WG has already produced an update of > the binding discovery protocol STUN. It will now produce a relay > protocol that focuses on security and is usable with both IPv4 and > IPv6, and capable of relaying between the two IP versions. > > Due to the WG's experience with translators and their behavior it has > been given the following tasks to help encourage migration to IPv6. To > support deployments where communicating hosts require using different > address families (IPv4 or IPv6), address family translation is > needed to establish communication. In BEHAVE's specification work on > this topic it will coordinate with the V6ops WG on requirements and > operational considerations. > > "An IPv4 network" or "an IPv6 network" in the descriptions below refer > to a network with a clearly identifiable administrative domain (e.g., > an enterprise campus network, a mobile operator's cellular network, a > residential subscriber network, etc.). It will also be that network > that deploys the necessary equipment for translation. > > The BEHAVE WG will design solutions for the following six translation > scenarios; other scenarios are out of scope: > > 1. An IPv6 network to IPv4 Internet, i.e. perform translation between > IPv4 and IPv6 for packets in uni- or bi-directional flows that are > initiated from an IPv6 host towards an IPv4 host. The translator > function is intended to service a specific IPv6 network of arbitary > size. Port translation is necessary on the IPv4 side for efficient IPv4 > address usage. > > 2. IPv6 Internet to an IPv4 network, i.e. perform translation between > IPv4 and IPv6 for packets in uni- or bi-directional flows that are > initiated from an IPv6 host towards an IPv4 host. The translator > function is intended to service a specific IPv4 network using either > private or public IPv4 addresses. This scenario has different > constraints compared to (1), e.g. the IPv4 hosts that are to be > reachable over IPv6 can be enumerated. Therefore, the WG should attempt > to design a simpler solution with less impact on applications. > > 3. An IPv4 network to IPv6 Internet, i.e. perform translation between > IPv4 and IPv6 for packets in uni- or bi-directional flows that are > initiated from an IPv4 host towards an IPv6 host. The translator > function is intended to service a specific IPv4 network using either > public or private IPv4 address space. > > 4. IPv4 Internet to an IPv6 network, i.e. perform translation between > IPv4 and IPv6 for packets in uni- or bi-directional flows that are > initiated from an IPv4 host towards an IPv6 host. The translator > function is intended to service a specific IPv6 network where selected > IPv6 hosts and services are to be reachable. > > 5. An IPv6 network to an IPv4 network, i.e., perform translation between > IPv6 and IPv4 for packets in uni- or bi-directional flows that are > initiated from an IPv6 host towards an IPv4 host. The translation > function is intended to service a specific IPv6 network of arbitrary > size and a specific IPv4 network of arbitrary size (neither of which are > the Internet). > > 6. An IPv4 network to an IPv6 network, i.e., perform translation between > IPv4 and IPv6 for packets in uni- or bi-directional flows that are > initiated from an IPv4 host towards an IPv6 host. The translation > function is intended to service a specific IPv6 network of arbitrary > size and a specific IPv4 network of arbitrary size (neither of which are > the Internet). > > All translation solutions shall be capable of handling flows using TCP, > UDP, DCCP, and SCTP, unless they prevent a timely completion of the > work item. The parts of ICMP that can be translated are also required > to work across a translation solution. Additional protocols directly > on top of IP may be supported. Translation mechanisms must handle IP > fragmentation. > > The translators should support multicast traffic and its control > traffic (IGMP and MLD) across them, both Single Source Multicast (SSM) > and Any Source Multicast (ASM). However, the WG may determine that it > becomes too complex or too difficult to realize with maintained > functionality, for some or all cases of multicast functionality. > > Translation mechanisms cannot transparently support protocols that > embed network addresses within their protocol messages without > application level gateways (ALGs). Because ALGs have security issues > (like blocking usage of TLS), are error prone and brittle, and hinder > application development, the usage of ALGs in the defined translators > should be avoided. Instead application developers will need to be aware > and use mechanisms that handle the address family translation. ALGs may > be considered only for the most crucial of legacy applications. > > DNS is a crucial part in making a large number of applications work > across a translator. Thus the solution to the above translation cases > shall include recommendations for DNS. If additional DNS functionality > is needed, it may be developed. Any DNS extensions must be developed > together with the DNSEXT WG, including issuing a joint WG last call for > any documents. > > The WG needs to determine the best method for providing address space > to a translator in the different deployment cases and documenting the > pros and cons of the suggested approaches. The WG is to seek input from > the Routing, Operations and Internet areas. > > Solutions may solve more than one of the cases, however timely delivery > is more important than a unified solution. > > Goals and Milestones: > > Done Submit BCP that defines unicast UDP behavioral requirements > for NATs to IESG > Done Submit a BCP that defines TCP behavioral requireents for NATs > to IESG > Done Submit a BCP that defines ICMP behavioral requirements for > NATs to IESG > Done Submit informational that discusses current NAT traversal > techniques used by applications > Done Submit BCP that defines multicast UDP > Done Submit revision of RFC 3489 to IESG behavioral requirements for > NATs to IESG > Done Submit informational document for rfc3489bis test vectors > Done Submit experimental document that describes how an application > can determine the type of NAT it is behind > Done Submit BCP document for DCCP NAT behavior > Dec 2009 Submit to IESG: SCTP NAT behavior (BCP) > Done Submit to IESG: relay protocol (std) > Done Determine relative prioritization of the four translation > cases. Documented in IETF74 minutes. > Sep 2009 Submit to IESG: relaying of a TCP bytestream (std) > Dec 2009 Submit to IESG: IPv6 relay protocol (std) > Done Determine what solutions(s) and components are needed to solve > each of the four cases. Create new milestones for the solution(s) and > the components. Documented in IETF74 minutes. > Done Submit to IESG: TURN-URI document (std) > Dec 2009 Submit to IESG: framework for IPv6/IPv4 translation (info) > Dec 2009 Submit to IESG: stateless IPv6/IPv4 translation (std) > Dec 2009 Submit to IESG: stateful IPv6/IPv4 translation (std) > Dec 2009 Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std) > Jan 2010 Submit to IESG: FTP ALG for IPv6/IPv4 translation (std) > Jan 2010 Submit to IESG: IPv6 prefix for IPv6/IPv4 translator (std) > Mar 2010 Submit to IESG: large scale NAT requirements (BCP) > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > -- Regards, Bo Zhou China Mobile --001485f99caa73903204755a8bdc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dave and Dan,
=A0
I just found the charter of the Behave has been modified.
=A0
"5. An IPv6 network to an IPv4 network, i.e., perform translation= between
IPv6 and IPv4 for packets in uni- or bi-directional flows that = are
initiated from an IPv6 host towards an IPv4 host. =A0The translation=
function is intended to service a specific IPv6 network of arbitrary
siz= e and a specific IPv4 network of arbitrary size (neither of which are
th= e Internet)."
=A0
Does this cover host based translator solutions for 6 to 4?
=A0
Regards,
=A0
Bo Zhou

On Wed, Sep 30, 2009 at 12:30 AM, IESG Secretary= <iesg-secr= etary@ietf.org> wrote:
A modified charter has been subm= itted for the Behavior Engineering for
Hindrance Avoidance (behave) work= ing group in the Transport Area of the
IETF. =A0The IESG has not made any determination as yet. =A0The modifiedcharter is provided below for informational purposes only. =A0Please send<= br>your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, October
6, 2009.

Behavior Engineering for Hindrance Avoidance (behave)
--= ---------------------------------------------------
Current Status: Acti= ve Working Group
Last Modified: 2009-09-09

Current Status: Active= Working Group

Additional information is available at tools.ietf.org/wg/behave
Chair(s):
=
=A0 =A0* Dan Wing <dwing@cisco.co= m>
=A0 =A0* Dave Thaler <dthaler@m= icrosoft.com>

Transport Area Director(s):

=A0 =A0* Mag= nus Westerlund <magnus= .westerlund@ericsson.com>
=A0 =A0* Lars Eggert <lars.egge= rt@nokia.com>

Transport Area Advisor:

=A0 =A0* Magnus = Westerlund <magnus.wes= terlund@ericsson.com>

Mailing Lists:
=A0General Discussion: behave@ietf.org
=A0To Subscribe: behave-request@ietf.org
=A0In Body: In Body: subscribe<= br>=A0Archive: http://www.ietf.org/mail-archive/web/behave

Description of Working Group:

The behavior of NATs varies from o= ne implementation to another. As a
result it is very difficult for appli= cations to predict or discover the
behavior of these devices. Predicting= and/or discovering the behavior
of NATs is important for designing application protocols and NAT
travers= al techniques that work reliably in existing networks. This
situation is= especially problematic for end-to-end applications where
one or both en= d-points are behind a NAT, such as multiuser games,
interactive multimedia and P2P download.

The working group documents= best current practices to enable NATs to
function in as deterministic a= fashion as possible. The NAT behavior
practices will be application ind= ependent. This has already completed
for UDP, TCP, DCCP, Multicast and ICMP. It continues with SCTP and any
a= dditional protocol deemed necessary to handle. The WG has documented
app= roaches for characterizing and testing NAT devices.

BEHAVE will deve= lop protocol-independent toolkits usable by application
protocols for NAT traversal. The WG has already produced an update of
th= e binding discovery protocol STUN. It will now produce a relay
protocol = that focuses on security and is usable with both IPv4 and
IPv6, and capa= ble of relaying between the two IP versions.

Due to the WG's experience with translators and their behavior it h= as
been given the following tasks to help encourage migration to IPv6. T= o
support deployments where communicating hosts require using different<= br> address families (IPv4 or IPv6), address family translation is
needed to= establish communication. In BEHAVE's specification work on
this top= ic it will coordinate with the V6ops WG on requirements and
operational = considerations.

"An IPv4 network" or "an IPv6 network" in the descr= iptions below refer
to a network with a clearly identifiable administrat= ive domain (e.g.,
an enterprise campus network, a mobile operator's = cellular network, a
residential subscriber network, etc.). It will also be that network
that= deploys the necessary equipment for translation.

The BEHAVE WG will= design solutions for the following six translation
scenarios; other sce= narios are out of scope:

1. An IPv6 network to IPv4 Internet, i.e. perform translation betweenIPv4 and IPv6 for packets in uni- or bi-directional flows that are
ini= tiated from an IPv6 host towards an IPv4 host. The translator
function i= s intended to service a specific IPv6 network of arbitary
size. Port translation is necessary on the IPv4 side for efficient IPv4
= address usage.

2. IPv6 Internet to an IPv4 network, i.e. perform tra= nslation between
IPv4 and IPv6 for packets in uni- or bi-directional flo= ws that are
initiated from an IPv6 host towards an IPv4 host. The translator
functio= n is intended to service a specific IPv4 network using either
private or= public IPv4 addresses. This scenario has different
constraints compared= to (1), e.g. the IPv4 hosts that are to be
reachable over IPv6 can be enumerated. Therefore, the WG should attempt
= to design a simpler solution with less impact on applications.

3. An= IPv4 network to IPv6 Internet, i.e. perform translation between
IPv4 an= d IPv6 for packets in uni- or bi-directional flows that are
initiated from an IPv4 host towards an IPv6 host. The translator
functio= n is intended to service a specific IPv4 network using either
public or = private IPv4 address space.

4. IPv4 Internet to an IPv6 network, i.e= . perform translation between
IPv4 and IPv6 for packets in uni- or bi-directional flows that are
initi= ated from an IPv4 host towards an IPv6 host. The translator
function is = intended to service a specific IPv6 network where selected
IPv6 hosts an= d services are to be reachable.

5. An IPv6 network to an IPv4 network, i.e., perform translation betwee= n
IPv6 and IPv4 for packets in uni- or bi-directional flows that are
= initiated from an IPv6 host towards an IPv4 host. =A0The translation
fun= ction is intended to service a specific IPv6 network of arbitrary
size and a specific IPv4 network of arbitrary size (neither of which arethe Internet).

6. An IPv4 network to an IPv6 network, i.e., perform= translation between
IPv4 and IPv6 for packets in uni- or bi-directional= flows that are
initiated from an IPv4 host towards an IPv6 host. =A0The translation
fun= ction is intended to service a specific IPv6 network of arbitrary
size a= nd a specific IPv4 network of arbitrary size (neither of which are
the I= nternet).

All translation solutions shall be capable of handling flows using TCP,=
UDP, DCCP, and SCTP, unless they prevent a timely completion of the
= work item. The parts of ICMP that can be translated are also required
to work across a translation solution. =A0Additional protocols directly
= on top of IP may be supported. Translation mechanisms must handle IP
fra= gmentation.

The translators should support multicast traffic and its= control
traffic (IGMP and MLD) across them, both Single Source Multicast (SSM)
a= nd Any Source Multicast (ASM). However, the WG may determine that it
bec= omes too complex or too difficult to realize with maintained
functionali= ty, for some or all cases of multicast functionality.

Translation mechanisms cannot transparently support protocols that
e= mbed network addresses within their protocol messages without
applicatio= n level gateways (ALGs). Because ALGs have security issues
(like blockin= g usage of TLS), are error prone and brittle, and hinder
application development, the usage of ALGs in the defined translators
sh= ould be avoided. Instead application developers will need to be aware
an= d use mechanisms that handle the address family translation. ALGs may
be considered only for the most crucial of legacy applications.

DNS = is a crucial part in making a large number of applications work
across a= translator. Thus the solution to the above translation cases
shall incl= ude recommendations for DNS. If additional DNS functionality
is needed, it may be developed. Any DNS extensions must be developed
tog= ether with the DNSEXT WG, including issuing a joint WG last call for
any= documents.

The WG needs to determine the best method for providing = address space
to a translator in the different deployment cases and documenting the
pr= os and cons of the suggested approaches. The WG is to seek input from
th= e Routing, Operations and Internet areas.

Solutions may solve more t= han one of the cases, however timely delivery
is more important than a unified solution.

Goals and Milestones:
=
Done =A0 =A0 =A0Submit BCP that defines unicast UDP behavioral requirem= ents
for NATs to IESG
Done =A0 =A0 =A0Submit a BCP that defines TCP b= ehavioral requireents for NATs
to IESG
Done =A0 =A0 =A0Submit a BCP that defines ICMP behavioral requir= ements for
NATs to IESG
Done =A0 =A0 =A0Submit informational that dis= cusses current NAT traversal
techniques used by applications
Done =A0= =A0 =A0Submit BCP that defines multicast UDP
Done =A0 =A0 =A0Submit revision of RFC 3489 to IESG behavioral requirements= for
NATs to IESG
Done =A0 =A0 =A0Submit informational document for r= fc3489bis test vectors
Done =A0 =A0 =A0Submit experimental document that= describes how an application
can determine the type of NAT it is behind
Done =A0 =A0 =A0Submit BCP do= cument for DCCP NAT behavior
Dec 2009 =A0Submit to IESG: SCTP NAT behavi= or (BCP)
Done =A0 =A0 =A0Submit to IESG: relay protocol (std)
Done = =A0 =A0 =A0Determine relative prioritization of the four translation
cases. Documented in IETF74 minutes.
Sep 2009 =A0Submit to IESG: relayin= g of a TCP bytestream (std)
Dec 2009 =A0Submit to IESG: IPv6 relay proto= col (std)
Done =A0 =A0 =A0Determine what solutions(s) and components are= needed to solve
each of the four cases. Create new milestones for the solution(s) and
th= e components. Documented in IETF74 minutes.
Done =A0 =A0 =A0Submit to IE= SG: =A0TURN-URI document (std)
Dec 2009 =A0Submit to IESG: =A0framework = for IPv6/IPv4 translation (info)
Dec 2009 =A0Submit to IESG: =A0stateless IPv6/IPv4 translation (std)
Dec= 2009 =A0Submit to IESG: =A0stateful IPv6/IPv4 translation (std)
Dec 200= 9 =A0Submit to IESG: =A0DNS rewriting for IPv6/IPv4 translation (std)
Ja= n 2010 =A0Submit to IESG: =A0FTP ALG for IPv6/IPv4 translation (std)
Jan 2010 =A0Submit to IESG: =A0IPv6 prefix for IPv6/IPv4 translator (std)Mar 2010 =A0Submit to IESG: =A0large scale NAT requirements (BCP)
____= ___________________________________________
Behave mailing list
Behave@ietf.org
= https://www.ietf.org/mailman/listinfo/behave

=

--
Regards,

Bo Zhou
China Mobile
--001485f99caa73903204755a8bdc-- From dwing@cisco.com Wed Oct 7 10:41:32 2009 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 3DE103A6973; Wed, 7 Oct 2009 10:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.299 X-Spam-Level: X-Spam-Status: No, score=-8.299 tagged_above=-999 required=5 tests=[AWL=1.700, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1vnIqpqT956; Wed, 7 Oct 2009 10:41:28 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 315183A6872; Wed, 7 Oct 2009 10:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=11747; q=dns/txt; s=amsiport01001; t=1254937387; x=1256146987; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Dan=20Wing"=20|Subject:=20RE: =20[BEHAVE]=20WG=20Review:=20Recharter=20of=20Behavior=20 Engineering=20for=20Hindrance=20Avoidance=20(behave) |Date:=20Wed,=207=20Oct=202009=2010:43:01=20-0700 |Message-ID:=20<0a9101ca4775$9fa951a0$c2f0200a@cisco.com> |To:=20"'bo=20zhou'"=20,=20"'Dave=20T haler'"=20|Cc:=20,=20,=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=207bit |In-Reply-To:=20<36a593230910070907p6b6f4be9xf4c344d05558 7cbf@mail.gmail.com>|References:=20<20090929163001.CBD933 A6942@core3.amsl.com>=20<36a593230910070907p6b6f4be9xf4c3 44d055587cbf@mail.gmail.com>; bh=UOoJ8dxsOsqdDTzGAsOr5+nd6A9O05o9ERTQDeRBS5g=; b=OgcuT84niygnt1choTRKOPdyNxPww3HvtcwZ6Zb3dAxc3CciKcDI6QwB nMM7w41n7e9CFRvaZPZdumJTu8TfwHJUHbChnFH78df/zG0lIo8AW10eR z+VOon6DlZPbIyma2toFnBOz31BWDHvc/L0zCoBXteQF12HsWFbbHBG4k Y=; Authentication-Results: ams-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=dwing@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoAAHpwzEqQ/uCKe2dsb2JhbACKX5AeAQEWJAajO4hjAY88BoI2gXSBWg X-IronPort-AV: E=Sophos;i="4.44,520,1249257600"; d="scan'208";a="51209581" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 07 Oct 2009 17:43:05 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n97Hh52I030516; Wed, 7 Oct 2009 19:43:05 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n97Hh573018942; Wed, 7 Oct 2009 17:43:05 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Oct 2009 19:43:04 +0200 Received: from dwingwxp01 ([10.21.87.29]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Oct 2009 19:43:04 +0200 From: "Dan Wing" To: "'bo zhou'" , "'Dave Thaler'" References: <20090929163001.CBD933A6942@core3.amsl.com> <36a593230910070907p6b6f4be9xf4c344d055587cbf@mail.gmail.com> Date: Wed, 7 Oct 2009 10:43:01 -0700 Message-ID: <0a9101ca4775$9fa951a0$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpHaEj6+zuI8NfgQtepbavnweAmswADM75Q In-Reply-To: <36a593230910070907p6b6f4be9xf4c344d055587cbf@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-OriginalArrivalTime: 07 Oct 2009 17:43:04.0620 (UTC) FILETIME=[9F801EC0:01CA4775] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16932.003 X-TM-AS-Result: No--25.865600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11747; t=1254937385; x=1255801385; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20WG=20Review=3A=20Recharter=2 0of=20Behavior=20Engineering=20for=20Hindrance=20Avoidance=2 0(behave) |Sender:=20; bh=UOoJ8dxsOsqdDTzGAsOr5+nd6A9O05o9ERTQDeRBS5g=; b=RPUbuimP/cbz6IWT4UQubnraSIYBxhcEm07WGt98U5BVGuVJMGpGDcsgbC 4skO3Fvh7sS0FLS/zZh+UU/VickmXOX+IAml5UK8DpKVIpAjXlIc7MdFSHq6 m2UlRMK8cV; Cc: behave@ietf.org, iesg@ietf.org, ietf-announce@ietf.org Subject: Re: [BEHAVE] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 17:41:33 -0000 > -----Original Message----- > From: bo zhou [mailto:zhouboyj@gmail.com] > Sent: Wednesday, October 07, 2009 9:08 AM > To: Dave Thaler; Dan Wing > Cc: ietf-announce@ietf.org; behave@ietf.org; iesg@ietf.org > Subject: Re: [BEHAVE] WG Review: Recharter of Behavior > Engineering for Hindrance Avoidance (behave) > > Hi Dave and Dan, > > I just found the charter of the Behave has been modified. > > "5. An IPv6 network to an IPv4 network, i.e., perform > translation between > IPv6 and IPv4 for packets in uni- or bi-directional flows that are > initiated from an IPv6 host towards an IPv4 host. The translation > function is intended to service a specific IPv6 network of arbitrary > size and a specific IPv4 network of arbitrary size (neither > of which are > the Internet)." > > Does this cover host based translator solutions for 6 to 4? Yes, the "specific IPv6 network of arbitrary size" is a network containing 1 host. -d > Regards, > > Bo Zhou > > > On Wed, Sep 30, 2009 at 12:30 AM, IESG Secretary > wrote: > > > A modified charter has been submitted for the Behavior > Engineering for > Hindrance Avoidance (behave) working group in the > Transport Area of the > IETF. The IESG has not made any determination as yet. > The modified > charter is provided below for informational purposes > only. Please send > your comments to the IESG mailing list (iesg@ietf.org) > by Tuesday, October > 6, 2009. > > Behavior Engineering for Hindrance Avoidance (behave) > ----------------------------------------------------- > Current Status: Active Working Group > Last Modified: 2009-09-09 > > Current Status: Active Working Group > > Additional information is available at tools.ietf.org/wg/behave > Chair(s): > > * Dan Wing > * Dave Thaler > > Transport Area Director(s): > > * Magnus Westerlund > * Lars Eggert > > Transport Area Advisor: > > * Magnus Westerlund > > Mailing Lists: > General Discussion: behave@ietf.org > To Subscribe: behave-request@ietf.org > In Body: In Body: subscribe > Archive: http://www.ietf.org/mail-archive/web/behave > > Description of Working Group: > > The behavior of NATs varies from one implementation to > another. As a > result it is very difficult for applications to predict > or discover the > behavior of these devices. Predicting and/or > discovering the behavior > of NATs is important for designing application protocols and NAT > traversal techniques that work reliably in existing > networks. This > situation is especially problematic for end-to-end > applications where > one or both end-points are behind a NAT, such as > multiuser games, > interactive multimedia and P2P download. > > The working group documents best current practices to > enable NATs to > function in as deterministic a fashion as possible. The > NAT behavior > practices will be application independent. This has > already completed > for UDP, TCP, DCCP, Multicast and ICMP. It continues > with SCTP and any > additional protocol deemed necessary to handle. The WG > has documented > approaches for characterizing and testing NAT devices. > > BEHAVE will develop protocol-independent toolkits > usable by application > protocols for NAT traversal. The WG has already > produced an update of > the binding discovery protocol STUN. It will now produce a relay > protocol that focuses on security and is usable with > both IPv4 and > IPv6, and capable of relaying between the two IP versions. > > Due to the WG's experience with translators and their > behavior it has > been given the following tasks to help encourage > migration to IPv6. To > support deployments where communicating hosts require > using different > address families (IPv4 or IPv6), address family translation is > needed to establish communication. In BEHAVE's > specification work on > this topic it will coordinate with the V6ops WG on > requirements and > operational considerations. > > "An IPv4 network" or "an IPv6 network" in the > descriptions below refer > to a network with a clearly identifiable administrative > domain (e.g., > an enterprise campus network, a mobile operator's > cellular network, a > residential subscriber network, etc.). It will also be > that network > that deploys the necessary equipment for translation. > > The BEHAVE WG will design solutions for the following > six translation > scenarios; other scenarios are out of scope: > > 1. An IPv6 network to IPv4 Internet, i.e. perform > translation between > IPv4 and IPv6 for packets in uni- or bi-directional > flows that are > initiated from an IPv6 host towards an IPv4 host. The translator > function is intended to service a specific IPv6 network > of arbitary > size. Port translation is necessary on the IPv4 side > for efficient IPv4 > address usage. > > 2. IPv6 Internet to an IPv4 network, i.e. perform > translation between > IPv4 and IPv6 for packets in uni- or bi-directional > flows that are > initiated from an IPv6 host towards an IPv4 host. The translator > function is intended to service a specific IPv4 network > using either > private or public IPv4 addresses. This scenario has different > constraints compared to (1), e.g. the IPv4 hosts that are to be > reachable over IPv6 can be enumerated. Therefore, the > WG should attempt > to design a simpler solution with less impact on applications. > > 3. An IPv4 network to IPv6 Internet, i.e. perform > translation between > IPv4 and IPv6 for packets in uni- or bi-directional > flows that are > initiated from an IPv4 host towards an IPv6 host. The translator > function is intended to service a specific IPv4 network > using either > public or private IPv4 address space. > > 4. IPv4 Internet to an IPv6 network, i.e. perform > translation between > IPv4 and IPv6 for packets in uni- or bi-directional > flows that are > initiated from an IPv4 host towards an IPv6 host. The translator > function is intended to service a specific IPv6 network > where selected > IPv6 hosts and services are to be reachable. > > 5. An IPv6 network to an IPv4 network, i.e., perform > translation between > IPv6 and IPv4 for packets in uni- or bi-directional > flows that are > initiated from an IPv6 host towards an IPv4 host. The > translation > function is intended to service a specific IPv6 network > of arbitrary > size and a specific IPv4 network of arbitrary size > (neither of which are > the Internet). > > 6. An IPv4 network to an IPv6 network, i.e., perform > translation between > IPv4 and IPv6 for packets in uni- or bi-directional > flows that are > initiated from an IPv4 host towards an IPv6 host. The > translation > function is intended to service a specific IPv6 network > of arbitrary > size and a specific IPv4 network of arbitrary size > (neither of which are > the Internet). > > All translation solutions shall be capable of handling > flows using TCP, > UDP, DCCP, and SCTP, unless they prevent a timely > completion of the > work item. The parts of ICMP that can be translated are > also required > to work across a translation solution. Additional > protocols directly > on top of IP may be supported. Translation mechanisms > must handle IP > fragmentation. > > The translators should support multicast traffic and its control > traffic (IGMP and MLD) across them, both Single Source > Multicast (SSM) > and Any Source Multicast (ASM). However, the WG may > determine that it > becomes too complex or too difficult to realize with maintained > functionality, for some or all cases of multicast functionality. > > Translation mechanisms cannot transparently support > protocols that > embed network addresses within their protocol messages without > application level gateways (ALGs). Because ALGs have > security issues > (like blocking usage of TLS), are error prone and > brittle, and hinder > application development, the usage of ALGs in the > defined translators > should be avoided. Instead application developers will > need to be aware > and use mechanisms that handle the address family > translation. ALGs may > be considered only for the most crucial of legacy applications. > > DNS is a crucial part in making a large number of > applications work > across a translator. Thus the solution to the above > translation cases > shall include recommendations for DNS. If additional > DNS functionality > is needed, it may be developed. Any DNS extensions must > be developed > together with the DNSEXT WG, including issuing a joint > WG last call for > any documents. > > The WG needs to determine the best method for providing > address space > to a translator in the different deployment cases and > documenting the > pros and cons of the suggested approaches. The WG is to > seek input from > the Routing, Operations and Internet areas. > > Solutions may solve more than one of the cases, however > timely delivery > is more important than a unified solution. > > Goals and Milestones: > > Done Submit BCP that defines unicast UDP > behavioral requirements > for NATs to IESG > Done Submit a BCP that defines TCP behavioral > requireents for NATs > to IESG > Done Submit a BCP that defines ICMP behavioral > requirements for > NATs to IESG > Done Submit informational that discusses current > NAT traversal > techniques used by applications > Done Submit BCP that defines multicast UDP > Done Submit revision of RFC 3489 to IESG > behavioral requirements for > NATs to IESG > Done Submit informational document for rfc3489bis > test vectors > Done Submit experimental document that describes > how an application > can determine the type of NAT it is behind > Done Submit BCP document for DCCP NAT behavior > Dec 2009 Submit to IESG: SCTP NAT behavior (BCP) > Done Submit to IESG: relay protocol (std) > Done Determine relative prioritization of the four > translation > cases. Documented in IETF74 minutes. > Sep 2009 Submit to IESG: relaying of a TCP bytestream (std) > Dec 2009 Submit to IESG: IPv6 relay protocol (std) > Done Determine what solutions(s) and components > are needed to solve > each of the four cases. Create new milestones for the > solution(s) and > the components. Documented in IETF74 minutes. > Done Submit to IESG: TURN-URI document (std) > Dec 2009 Submit to IESG: framework for IPv6/IPv4 > translation (info) > Dec 2009 Submit to IESG: stateless IPv6/IPv4 translation (std) > Dec 2009 Submit to IESG: stateful IPv6/IPv4 translation (std) > Dec 2009 Submit to IESG: DNS rewriting for IPv6/IPv4 > translation (std) > Jan 2010 Submit to IESG: FTP ALG for IPv6/IPv4 > translation (std) > Jan 2010 Submit to IESG: IPv6 prefix for IPv6/IPv4 > translator (std) > Mar 2010 Submit to IESG: large scale NAT requirements (BCP) > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > > > > -- > Regards, > > Bo Zhou > China Mobile > > From zhouboyj@gmail.com Wed Oct 7 18:17:46 2009 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 A26733A68A7 for ; Wed, 7 Oct 2009 18:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.414 X-Spam-Level: X-Spam-Status: No, score=-1.414 tagged_above=-999 required=5 tests=[AWL=0.584, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 568BfFLah+J7 for ; Wed, 7 Oct 2009 18:17:44 -0700 (PDT) Received: from mail-iw0-f186.google.com (mail-iw0-f186.google.com [209.85.223.186]) by core3.amsl.com (Postfix) with ESMTP id E5B3E3A687E for ; Wed, 7 Oct 2009 18:17:42 -0700 (PDT) Received: by iwn16 with SMTP id 16so2374006iwn.29 for ; Wed, 07 Oct 2009 18:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=/8avvG5AZdUHmyfCWEp5L55rpPFnupZWoaeICLXbjPM=; b=mcY9GvGhY7H/edPE699g2Pci8/vq7+zV48/dJwDRumR/yzIUNk7YoXB8pFZfjyd8I9 gWTLmnzBL5BJsl8XyfUUIZqmmwR1yZqLnV2nEO/NOgKLcHjMc990h81g06mF7xkDpMWG KP6EiaPPHWnmbN27InI10dHgeikvX+boIfRSY= 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=tHrXlFJeN1KFxQx4/mNGjkjhUHNBa7NOCC5rTCbrIk7XnNXP4yBTsHc3AnhFF/+HV3 lxxSExekm1Hb0pe1KI7ztiHOnQN7rn/f1mnNf7wNdbBPNcct4fo7gQmQ+UZ1EJ9khJLK O1i6eMtSnOmjlr7pM0P5TgUWL/CZpNeG6+ZDg= MIME-Version: 1.0 Received: by 10.231.125.156 with SMTP id y28mr1204413ibr.8.1254964760465; Wed, 07 Oct 2009 18:19:20 -0700 (PDT) In-Reply-To: <0a9101ca4775$9fa951a0$c2f0200a@cisco.com> References: <20090929163001.CBD933A6942@core3.amsl.com> <36a593230910070907p6b6f4be9xf4c344d055587cbf@mail.gmail.com> <0a9101ca4775$9fa951a0$c2f0200a@cisco.com> Date: Thu, 8 Oct 2009 09:19:20 +0800 Message-ID: <36a593230910071819u2aa422afh846bb7ba7da54eff@mail.gmail.com> From: bo zhou To: Dan Wing Content-Type: multipart/alternative; boundary=0016e64ec0a2c0d4ea04756240c4 Cc: behave@ietf.org, Dave Thaler Subject: Re: [BEHAVE] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 01:17:46 -0000 --0016e64ec0a2c0d4ea04756240c4 Content-Type: text/plain; charset=ISO-8859-1 Hi Dan, Thank you for your confirmation. Regards, Bo Zhou On Thu, Oct 8, 2009 at 1:43 AM, Dan Wing wrote: > > > > > -----Original Message----- > > From: bo zhou [mailto:zhouboyj@gmail.com] > > Sent: Wednesday, October 07, 2009 9:08 AM > > To: Dave Thaler; Dan Wing > > Cc: ietf-announce@ietf.org; behave@ietf.org; iesg@ietf.org > > Subject: Re: [BEHAVE] WG Review: Recharter of Behavior > > Engineering for Hindrance Avoidance (behave) > > > > Hi Dave and Dan, > > > > I just found the charter of the Behave has been modified. > > > > "5. An IPv6 network to an IPv4 network, i.e., perform > > translation between > > IPv6 and IPv4 for packets in uni- or bi-directional flows that are > > initiated from an IPv6 host towards an IPv4 host. The translation > > function is intended to service a specific IPv6 network of arbitrary > > size and a specific IPv4 network of arbitrary size (neither > > of which are > > the Internet)." > > > > Does this cover host based translator solutions for 6 to 4? > > Yes, the "specific IPv6 network of arbitrary size" is a network containing > 1 > host. > > -d > > > > Regards, > > > > Bo Zhou > > > > > > On Wed, Sep 30, 2009 at 12:30 AM, IESG Secretary > > wrote: > > > > > > A modified charter has been submitted for the Behavior > > Engineering for > > Hindrance Avoidance (behave) working group in the > > Transport Area of the > > IETF. The IESG has not made any determination as yet. > > The modified > > charter is provided below for informational purposes > > only. Please send > > your comments to the IESG mailing list (iesg@ietf.org) > > by Tuesday, October > > 6, 2009. > > > > Behavior Engineering for Hindrance Avoidance (behave) > > ----------------------------------------------------- > > Current Status: Active Working Group > > Last Modified: 2009-09-09 > > > > Current Status: Active Working Group > > > > Additional information is available at tools.ietf.org/wg/behave > > Chair(s): > > > > * Dan Wing > > * Dave Thaler > > > > Transport Area Director(s): > > > > * Magnus Westerlund > > * Lars Eggert > > > > Transport Area Advisor: > > > > * Magnus Westerlund > > > > Mailing Lists: > > General Discussion: behave@ietf.org > > To Subscribe: behave-request@ietf.org > > In Body: In Body: subscribe > > Archive: http://www.ietf.org/mail-archive/web/behave > > > > Description of Working Group: > > > > The behavior of NATs varies from one implementation to > > another. As a > > result it is very difficult for applications to predict > > or discover the > > behavior of these devices. Predicting and/or > > discovering the behavior > > of NATs is important for designing application protocols and NAT > > traversal techniques that work reliably in existing > > networks. This > > situation is especially problematic for end-to-end > > applications where > > one or both end-points are behind a NAT, such as > > multiuser games, > > interactive multimedia and P2P download. > > > > The working group documents best current practices to > > enable NATs to > > function in as deterministic a fashion as possible. The > > NAT behavior > > practices will be application independent. This has > > already completed > > for UDP, TCP, DCCP, Multicast and ICMP. It continues > > with SCTP and any > > additional protocol deemed necessary to handle. The WG > > has documented > > approaches for characterizing and testing NAT devices. > > > > BEHAVE will develop protocol-independent toolkits > > usable by application > > protocols for NAT traversal. The WG has already > > produced an update of > > the binding discovery protocol STUN. It will now produce a relay > > protocol that focuses on security and is usable with > > both IPv4 and > > IPv6, and capable of relaying between the two IP versions. > > > > Due to the WG's experience with translators and their > > behavior it has > > been given the following tasks to help encourage > > migration to IPv6. To > > support deployments where communicating hosts require > > using different > > address families (IPv4 or IPv6), address family translation is > > needed to establish communication. In BEHAVE's > > specification work on > > this topic it will coordinate with the V6ops WG on > > requirements and > > operational considerations. > > > > "An IPv4 network" or "an IPv6 network" in the > > descriptions below refer > > to a network with a clearly identifiable administrative > > domain (e.g., > > an enterprise campus network, a mobile operator's > > cellular network, a > > residential subscriber network, etc.). It will also be > > that network > > that deploys the necessary equipment for translation. > > > > The BEHAVE WG will design solutions for the following > > six translation > > scenarios; other scenarios are out of scope: > > > > 1. An IPv6 network to IPv4 Internet, i.e. perform > > translation between > > IPv4 and IPv6 for packets in uni- or bi-directional > > flows that are > > initiated from an IPv6 host towards an IPv4 host. The translator > > function is intended to service a specific IPv6 network > > of arbitary > > size. Port translation is necessary on the IPv4 side > > for efficient IPv4 > > address usage. > > > > 2. IPv6 Internet to an IPv4 network, i.e. perform > > translation between > > IPv4 and IPv6 for packets in uni- or bi-directional > > flows that are > > initiated from an IPv6 host towards an IPv4 host. The translator > > function is intended to service a specific IPv4 network > > using either > > private or public IPv4 addresses. This scenario has different > > constraints compared to (1), e.g. the IPv4 hosts that are to be > > reachable over IPv6 can be enumerated. Therefore, the > > WG should attempt > > to design a simpler solution with less impact on applications. > > > > 3. An IPv4 network to IPv6 Internet, i.e. perform > > translation between > > IPv4 and IPv6 for packets in uni- or bi-directional > > flows that are > > initiated from an IPv4 host towards an IPv6 host. The translator > > function is intended to service a specific IPv4 network > > using either > > public or private IPv4 address space. > > > > 4. IPv4 Internet to an IPv6 network, i.e. perform > > translation between > > IPv4 and IPv6 for packets in uni- or bi-directional > > flows that are > > initiated from an IPv4 host towards an IPv6 host. The translator > > function is intended to service a specific IPv6 network > > where selected > > IPv6 hosts and services are to be reachable. > > > > 5. An IPv6 network to an IPv4 network, i.e., perform > > translation between > > IPv6 and IPv4 for packets in uni- or bi-directional > > flows that are > > initiated from an IPv6 host towards an IPv4 host. The > > translation > > function is intended to service a specific IPv6 network > > of arbitrary > > size and a specific IPv4 network of arbitrary size > > (neither of which are > > the Internet). > > > > 6. An IPv4 network to an IPv6 network, i.e., perform > > translation between > > IPv4 and IPv6 for packets in uni- or bi-directional > > flows that are > > initiated from an IPv4 host towards an IPv6 host. The > > translation > > function is intended to service a specific IPv6 network > > of arbitrary > > size and a specific IPv4 network of arbitrary size > > (neither of which are > > the Internet). > > > > All translation solutions shall be capable of handling > > flows using TCP, > > UDP, DCCP, and SCTP, unless they prevent a timely > > completion of the > > work item. The parts of ICMP that can be translated are > > also required > > to work across a translation solution. Additional > > protocols directly > > on top of IP may be supported. Translation mechanisms > > must handle IP > > fragmentation. > > > > The translators should support multicast traffic and its control > > traffic (IGMP and MLD) across them, both Single Source > > Multicast (SSM) > > and Any Source Multicast (ASM). However, the WG may > > determine that it > > becomes too complex or too difficult to realize with maintained > > functionality, for some or all cases of multicast functionality. > > > > Translation mechanisms cannot transparently support > > protocols that > > embed network addresses within their protocol messages without > > application level gateways (ALGs). Because ALGs have > > security issues > > (like blocking usage of TLS), are error prone and > > brittle, and hinder > > application development, the usage of ALGs in the > > defined translators > > should be avoided. Instead application developers will > > need to be aware > > and use mechanisms that handle the address family > > translation. ALGs may > > be considered only for the most crucial of legacy applications. > > > > DNS is a crucial part in making a large number of > > applications work > > across a translator. Thus the solution to the above > > translation cases > > shall include recommendations for DNS. If additional > > DNS functionality > > is needed, it may be developed. Any DNS extensions must > > be developed > > together with the DNSEXT WG, including issuing a joint > > WG last call for > > any documents. > > > > The WG needs to determine the best method for providing > > address space > > to a translator in the different deployment cases and > > documenting the > > pros and cons of the suggested approaches. The WG is to > > seek input from > > the Routing, Operations and Internet areas. > > > > Solutions may solve more than one of the cases, however > > timely delivery > > is more important than a unified solution. > > > > Goals and Milestones: > > > > Done Submit BCP that defines unicast UDP > > behavioral requirements > > for NATs to IESG > > Done Submit a BCP that defines TCP behavioral > > requireents for NATs > > to IESG > > Done Submit a BCP that defines ICMP behavioral > > requirements for > > NATs to IESG > > Done Submit informational that discusses current > > NAT traversal > > techniques used by applications > > Done Submit BCP that defines multicast UDP > > Done Submit revision of RFC 3489 to IESG > > behavioral requirements for > > NATs to IESG > > Done Submit informational document for rfc3489bis > > test vectors > > Done Submit experimental document that describes > > how an application > > can determine the type of NAT it is behind > > Done Submit BCP document for DCCP NAT behavior > > Dec 2009 Submit to IESG: SCTP NAT behavior (BCP) > > Done Submit to IESG: relay protocol (std) > > Done Determine relative prioritization of the four > > translation > > cases. Documented in IETF74 minutes. > > Sep 2009 Submit to IESG: relaying of a TCP bytestream (std) > > Dec 2009 Submit to IESG: IPv6 relay protocol (std) > > Done Determine what solutions(s) and components > > are needed to solve > > each of the four cases. Create new milestones for the > > solution(s) and > > the components. Documented in IETF74 minutes. > > Done Submit to IESG: TURN-URI document (std) > > Dec 2009 Submit to IESG: framework for IPv6/IPv4 > > translation (info) > > Dec 2009 Submit to IESG: stateless IPv6/IPv4 translation (std) > > Dec 2009 Submit to IESG: stateful IPv6/IPv4 translation (std) > > Dec 2009 Submit to IESG: DNS rewriting for IPv6/IPv4 > > translation (std) > > Jan 2010 Submit to IESG: FTP ALG for IPv6/IPv4 > > translation (std) > > Jan 2010 Submit to IESG: IPv6 prefix for IPv6/IPv4 > > translator (std) > > Mar 2010 Submit to IESG: large scale NAT requirements (BCP) > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > > > > > > > > > > > -- > > Regards, > > > > Bo Zhou > > China Mobile > > > > > > -- Regards, Bo Zhou China Mobile --0016e64ec0a2c0d4ea04756240c4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dan,
=A0
Thank you for your confirmation.
=A0
Regards,
=A0
Bo Zhou

On Thu, Oct 8, 2009 at 1:43 AM, Dan Wing <dwing@cisco.com> wrote:



> -----Original Message-----
> From:= bo zhou [mailto:zhouboyj@gmail.com]
> Sent: Wednesday, October 07, 2009 9:08 AM
> To: Dave Thal= er; Dan Wing
> Cc: ietf-announce@ietf.org; behave@ietf.org; iesg@ietf.org
> Subject: Re: [BEHAVE] WG Review= : Recharter of Behavior
> Engineering for Hindrance Avoidance (behave)
>
> Hi Dave and Dan,
>
> I just found the ch= arter of the Behave has been modified.
>
> "5. An IPv6 net= work to an IPv4 network, i.e., perform
> translation between
> = IPv6 and IPv4 for packets in uni- or bi-directional flows that are
> initiated from an IPv6 host towards an IPv4 host. =A0The translation> function is intended to service a specific IPv6 network of arbitrary=
> size and a specific IPv4 network of arbitrary size (neither
>= ; of which are
> the Internet)."
>
> Does this cover host based transl= ator solutions for 6 to 4?

Yes, the "specific IPv6 networ= k of arbitrary size" is a network containing 1
host.

-d


> Regards,
>
> Bo Zhou
>
= >
> On Wed, Sep 30, 2009 at 12:30 AM, IESG Secretary
> <<= a href=3D"mailto:iesg-secretary@ietf.org">iesg-secretary@ietf.org> w= rote:
>
>
> =A0 =A0 =A0 A modified charter has been submitted for = the Behavior
> Engineering for
> =A0 =A0 =A0 Hindrance Avoidanc= e (behave) working group in the
> Transport Area of the
> =A0 = =A0 =A0 IETF. =A0The IESG has not made any determination as yet.
> The modified
> =A0 =A0 =A0 charter is provided below for informa= tional purposes
> only. =A0Please send
> =A0 =A0 =A0 your comme= nts to the IESG mailing list (iesg@ietf.or= g)
> by Tuesday, October
> =A0 =A0 =A0 6, 2009.
>
> =A0 =A0 =A0 Behavior Engineering = for Hindrance Avoidance (behave)
> =A0 =A0 =A0 ----------------------= -------------------------------
> =A0 =A0 =A0 Current Status: Active = Working Group
> =A0 =A0 =A0 Last Modified: 2009-09-09
>
> =A0 =A0 =A0 Current Status: Active Working Group
>
&g= t; =A0 =A0 =A0 Additional information is available at tools.ietf.org/wg/behave
&g= t; =A0 =A0 =A0 Chair(s):
>
> =A0 =A0 =A0 =A0 =A0* Dan Wing <dwing@cisco.com>
> =A0 =A0 =A0 =A0 =A0* Dave Thaler <= ;dthaler@microsoft.com>
= >
> =A0 =A0 =A0 Transport Area Director(s):
>
> =A0 =A0 =A0 =A0 =A0* Magnus Westerlund <magnus.westerlund@ericsson.com>
&g= t; =A0 =A0 =A0 =A0 =A0* Lars Eggert <lars.eggert@nokia.com>
>
> =A0 =A0 =A0 Transport Area Advisor:
>
> =A0 =A0 = =A0 =A0 =A0* Magnus Westerlund <magnus.westerlund@ericsson.com>
>
> =A0 =A0 = =A0 Mailing Lists:
> =A0 =A0 =A0 =A0General Discussion: behave@ietf.org
> =A0 =A0 =A0 =A0To Subscribe: behave-request@ietf.org
> =A0 =A0 =A0 =A0In Body: In Body: subs= cribe
> =A0 =A0 =A0 =A0Archive: http://www.ietf.org/mail-archive/web/b= ehave
>
> =A0 =A0 =A0 Description of Working Group:
>
> =A0 = =A0 =A0 The behavior of NATs varies from one implementation to
> anot= her. As a
> =A0 =A0 =A0 result it is very difficult for applications = to predict
> or discover the
> =A0 =A0 =A0 behavior of these devices. Predict= ing and/or
> discovering the behavior
> =A0 =A0 =A0 of NATs is = important for designing application protocols and NAT
> =A0 =A0 =A0 t= raversal techniques that work reliably in existing
> networks. This
> =A0 =A0 =A0 situation is especially problematic= for end-to-end
> applications where
> =A0 =A0 =A0 one or both = end-points are behind a NAT, such as
> multiuser games,
> =A0 = =A0 =A0 interactive multimedia and P2P download.
>
> =A0 =A0 =A0 The working group documents best current practices= to
> enable NATs to
> =A0 =A0 =A0 function in as deterministic= a fashion as possible. The
> NAT behavior
> =A0 =A0 =A0 practi= ces will be application independent. This has
> already completed
> =A0 =A0 =A0 for UDP, TCP, DCCP, Multicast an= d ICMP. It continues
> with SCTP and any
> =A0 =A0 =A0 addition= al protocol deemed necessary to handle. The WG
> has documented
&g= t; =A0 =A0 =A0 approaches for characterizing and testing NAT devices.
>
> =A0 =A0 =A0 BEHAVE will develop protocol-independent toolkits<= br>> usable by application
> =A0 =A0 =A0 protocols for NAT travers= al. The WG has already
> produced an update of
> =A0 =A0 =A0 th= e binding discovery protocol STUN. It will now produce a relay
> =A0 =A0 =A0 protocol that focuses on security and is usable with
&g= t; both IPv4 and
> =A0 =A0 =A0 IPv6, and capable of relaying between = the two IP versions.
>
> =A0 =A0 =A0 Due to the WG's experi= ence with translators and their
> behavior it has
> =A0 =A0 =A0 been given the following tasks to = help encourage
> migration to IPv6. To
> =A0 =A0 =A0 support de= ployments where communicating hosts require
> using different
>= =A0 =A0 =A0 address families (IPv4 or IPv6), address family translation is=
> =A0 =A0 =A0 needed to establish communication. In BEHAVE's
>= specification work on
> =A0 =A0 =A0 this topic it will coordinate wi= th the V6ops WG on
> requirements and
> =A0 =A0 =A0 operational= considerations.
>
> =A0 =A0 =A0 "An IPv4 network" or "an IPv6 netwo= rk" in the
> descriptions below refer
> =A0 =A0 =A0 to a n= etwork with a clearly identifiable administrative
> domain (e.g.,
= > =A0 =A0 =A0 an enterprise campus network, a mobile operator's
> cellular network, a
> =A0 =A0 =A0 residential subscriber network= , etc.). It will also be
> that network
> =A0 =A0 =A0 that depl= oys the necessary equipment for translation.
>
> =A0 =A0 =A0 Th= e BEHAVE WG will design solutions for the following
> six translation
> =A0 =A0 =A0 scenarios; other scenarios are out= of scope:
>
> =A0 =A0 =A0 1. An IPv6 network to IPv4 Internet,= i.e. perform
> translation between
> =A0 =A0 =A0 IPv4 and IPv6= for packets in uni- or bi-directional
> flows that are
> =A0 =A0 =A0 initiated from an IPv6 host towards= an IPv4 host. The translator
> =A0 =A0 =A0 function is intended to s= ervice a specific IPv6 network
> of arbitary
> =A0 =A0 =A0 size= . Port translation is necessary on the IPv4 side
> for efficient IPv4
> =A0 =A0 =A0 address usage.
>
> = =A0 =A0 =A0 2. IPv6 Internet to an IPv4 network, i.e. perform
> trans= lation between
> =A0 =A0 =A0 IPv4 and IPv6 for packets in uni- or bi-= directional
> flows that are
> =A0 =A0 =A0 initiated from an IPv6 host towards= an IPv4 host. The translator
> =A0 =A0 =A0 function is intended to s= ervice a specific IPv4 network
> using either
> =A0 =A0 =A0 pri= vate or public IPv4 addresses. This scenario has different
> =A0 =A0 =A0 constraints compared to (1), e.g. the IPv4 hosts that are = to be
> =A0 =A0 =A0 reachable over IPv6 can be enumerated. Therefore,= the
> WG should attempt
> =A0 =A0 =A0 to design a simpler solu= tion with less impact on applications.
>
> =A0 =A0 =A0 3. An IPv4 network to IPv6 Internet, i.e. perform<= br>> translation between
> =A0 =A0 =A0 IPv4 and IPv6 for packets i= n uni- or bi-directional
> flows that are
> =A0 =A0 =A0 initiat= ed from an IPv4 host towards an IPv6 host. The translator
> =A0 =A0 =A0 function is intended to service a specific IPv4 network> using either
> =A0 =A0 =A0 public or private IPv4 address space= .
>
> =A0 =A0 =A0 4. IPv4 Internet to an IPv6 network, i.e. per= form
> translation between
> =A0 =A0 =A0 IPv4 and IPv6 for packets in uni- or bi-directional
>= ; flows that are
> =A0 =A0 =A0 initiated from an IPv4 host towards an= IPv6 host. The translator
> =A0 =A0 =A0 function is intended to serv= ice a specific IPv6 network
> where selected
> =A0 =A0 =A0 IPv6 hosts and services are to be r= eachable.
>
> =A0 =A0 =A0 5. An IPv6 network to an IPv4 network= , i.e., perform
> translation between
> =A0 =A0 =A0 IPv6 and IP= v4 for packets in uni- or bi-directional
> flows that are
> =A0 =A0 =A0 initiated from an IPv6 host towards= an IPv4 host. =A0The
> translation
> =A0 =A0 =A0 function is i= ntended to service a specific IPv6 network
> of arbitrary
> =A0= =A0 =A0 size and a specific IPv4 network of arbitrary size
> (neither of which are
> =A0 =A0 =A0 the Internet).
>
&g= t; =A0 =A0 =A0 6. An IPv4 network to an IPv6 network, i.e., perform
>= translation between
> =A0 =A0 =A0 IPv4 and IPv6 for packets in uni- = or bi-directional
> flows that are
> =A0 =A0 =A0 initiated from an IPv4 host towards= an IPv6 host. =A0The
> translation
> =A0 =A0 =A0 function is i= ntended to service a specific IPv6 network
> of arbitrary
> =A0= =A0 =A0 size and a specific IPv4 network of arbitrary size
> (neither of which are
> =A0 =A0 =A0 the Internet).
>
&g= t; =A0 =A0 =A0 All translation solutions shall be capable of handling
&g= t; flows using TCP,
> =A0 =A0 =A0 UDP, DCCP, and SCTP, unless they pr= event a timely
> completion of the
> =A0 =A0 =A0 work item. The parts of ICMP tha= t can be translated are
> also required
> =A0 =A0 =A0 to work a= cross a translation solution. =A0Additional
> protocols directly
&= gt; =A0 =A0 =A0 on top of IP may be supported. Translation mechanisms
> must handle IP
> =A0 =A0 =A0 fragmentation.
>
> =A0 = =A0 =A0 The translators should support multicast traffic and its control> =A0 =A0 =A0 traffic (IGMP and MLD) across them, both Single Source> Multicast (SSM)
> =A0 =A0 =A0 and Any Source Multicast (ASM). However, the WG may
>= ; determine that it
> =A0 =A0 =A0 becomes too complex or too difficul= t to realize with maintained
> =A0 =A0 =A0 functionality, for some or= all cases of multicast functionality.
>
> =A0 =A0 =A0 Translation mechanisms cannot transparently suppor= t
> protocols that
> =A0 =A0 =A0 embed network addresses within= their protocol messages without
> =A0 =A0 =A0 application level gate= ways (ALGs). Because ALGs have
> security issues
> =A0 =A0 =A0 (like blocking usage of TLS), are = error prone and
> brittle, and hinder
> =A0 =A0 =A0 application= development, the usage of ALGs in the
> defined translators
> = =A0 =A0 =A0 should be avoided. Instead application developers will
> need to be aware
> =A0 =A0 =A0 and use mechanisms that handle th= e address family
> translation. ALGs may
> =A0 =A0 =A0 be consi= dered only for the most crucial of legacy applications.
>
> =A0= =A0 =A0 DNS is a crucial part in making a large number of
> applications work
> =A0 =A0 =A0 across a translator. Thus the so= lution to the above
> translation cases
> =A0 =A0 =A0 shall inc= lude recommendations for DNS. If additional
> DNS functionality
&g= t; =A0 =A0 =A0 is needed, it may be developed. Any DNS extensions must
> be developed
> =A0 =A0 =A0 together with the DNSEXT WG, includin= g issuing a joint
> WG last call for
> =A0 =A0 =A0 any document= s.
>
> =A0 =A0 =A0 The WG needs to determine the best method fo= r providing
> address space
> =A0 =A0 =A0 to a translator in the different dep= loyment cases and
> documenting the
> =A0 =A0 =A0 pros and cons= of the suggested approaches. The WG is to
> seek input from
> = =A0 =A0 =A0 the Routing, Operations and Internet areas.
>
> =A0 =A0 =A0 Solutions may solve more than one of the cases, ho= wever
> timely delivery
> =A0 =A0 =A0 is more important than a = unified solution.
>
> =A0 =A0 =A0 Goals and Milestones:
>=
> =A0 =A0 =A0 Done =A0 =A0 =A0Submit BCP that defines unicast UDP > behavioral requirements
> =A0 =A0 =A0 for NATs to IESG
> = =A0 =A0 =A0 Done =A0 =A0 =A0Submit a BCP that defines TCP behavioral
>= ; requireents for NATs
> =A0 =A0 =A0 to IESG
> =A0 =A0 =A0 Done= =A0 =A0 =A0Submit a BCP that defines ICMP behavioral
> requirements for
> =A0 =A0 =A0 NATs to IESG
> =A0 =A0 =A0 = Done =A0 =A0 =A0Submit informational that discusses current
> NAT tra= versal
> =A0 =A0 =A0 techniques used by applications
> =A0 =A0 = =A0 Done =A0 =A0 =A0Submit BCP that defines multicast UDP
> =A0 =A0 =A0 Done =A0 =A0 =A0Submit revision of RFC 3489 to IESG
>= ; behavioral requirements for
> =A0 =A0 =A0 NATs to IESG
> =A0 = =A0 =A0 Done =A0 =A0 =A0Submit informational document for rfc3489bis
>= ; test vectors
> =A0 =A0 =A0 Done =A0 =A0 =A0Submit experimental docu= ment that describes
> how an application
> =A0 =A0 =A0 can determine the type of NAT i= t is behind
> =A0 =A0 =A0 Done =A0 =A0 =A0Submit BCP document for DCC= P NAT behavior
> =A0 =A0 =A0 Dec 2009 =A0Submit to IESG: SCTP NAT beh= avior (BCP)
> =A0 =A0 =A0 Done =A0 =A0 =A0Submit to IESG: relay proto= col (std)
> =A0 =A0 =A0 Done =A0 =A0 =A0Determine relative prioritization of the f= our
> translation
> =A0 =A0 =A0 cases. Documented in IETF74 min= utes.
> =A0 =A0 =A0 Sep 2009 =A0Submit to IESG: relaying of a TCP byt= estream (std)
> =A0 =A0 =A0 Dec 2009 =A0Submit to IESG: IPv6 relay pr= otocol (std)
> =A0 =A0 =A0 Done =A0 =A0 =A0Determine what solutions(s) and components=
> are needed to solve
> =A0 =A0 =A0 each of the four cases. Cr= eate new milestones for the
> solution(s) and
> =A0 =A0 =A0 the= components. Documented in IETF74 minutes.
> =A0 =A0 =A0 Done =A0 =A0 =A0Submit to IESG: =A0TURN-URI document (std)=
> =A0 =A0 =A0 Dec 2009 =A0Submit to IESG: =A0framework for IPv6/IPv4=
> translation (info)
> =A0 =A0 =A0 Dec 2009 =A0Submit to IESG:= =A0stateless IPv6/IPv4 translation (std)
> =A0 =A0 =A0 Dec 2009 =A0Submit to IESG: =A0stateful IPv6/IPv4 translat= ion (std)
> =A0 =A0 =A0 Dec 2009 =A0Submit to IESG: =A0DNS rewriting = for IPv6/IPv4
> translation (std)
> =A0 =A0 =A0 Jan 2010 =A0Sub= mit to IESG: =A0FTP ALG for IPv6/IPv4
> translation (std)
> =A0 =A0 =A0 Jan 2010 =A0Submit to IESG: =A0I= Pv6 prefix for IPv6/IPv4
> translator (std)
> =A0 =A0 =A0 Mar 2= 010 =A0Submit to IESG: =A0large scale NAT requirements (BCP)
> =A0 = =A0 =A0 _______________________________________________
> =A0 =A0 =A0 Behave mailing list
> =A0 =A0 =A0 Behave@ietf.org
> =A0 =A0 =A0 https://www.ietf.o= rg/mailman/listinfo/behave
>
>
>
>
>
> --
> Regards,
>> Bo Zhou
> China Mobile
>
>




--
Regards,

Bo Zhou
China Mobile
--0016e64ec0a2c0d4ea04756240c4-- From william.polk@nist.gov Thu Oct 8 09:56:19 2009 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 DFD4E28C136 for ; Thu, 8 Oct 2009 09:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fSWLjG1EoYs for ; Thu, 8 Oct 2009 09:56:16 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 3D7A028C12F for ; Thu, 8 Oct 2009 09:56:15 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n98Gtuni010078; Thu, 8 Oct 2009 12:55:57 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Thu, 8 Oct 2009 12:55:41 -0400 From: "Polk, William T." To: Simon Perreault , Marc Petit-Huguenin Date: Thu, 8 Oct 2009 12:55:39 -0400 Thread-Topic: [BEHAVE] Discusses regarding security mechanism usage for TURN Thread-Index: AcpCvpVCA3x7ICkMTZq+A7FXlWEEJQFeZSIS Message-ID: In-Reply-To: <200910011341.49292.simon.perreault@viagenie.ca> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6F391CB16DC4timpolknistgov_" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov Cc: "Polk, William T." , Peter Livesey , "behave@ietf.org" , Blanchet , Marc Subject: Re: [BEHAVE] Discusses regarding security mechanism usage for TURN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 16:56:20 -0000 --_000_C6F391CB16DC4timpolknistgov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Simon, As I understand it, the wg is comfortable with deployments that do not requ= ire authentication *only* because that TURN server can be protected using f= iltering on specific interfaces given specific networks architectures, in c= ombination with tightly controlled (usually static) client configuration. = The set of attributes that must be in place for this to be a safe configur= ation is rather complicated, and I have my doubts about such deployments be= ing fully realized in practice, especially since the document that list of = attributes has been documented in various emails, but does not appear in th= e document. To be clear, section 4 currently states: = One reason that a server might not require requests to be authenticated is that TURN is being used in a carefully controlled environment in which the risks of unauthenticated requests by hostile third-parties have been mitigated. See Section 17 for more discussion on this point. If the wg has consensus that such deployments should be permitted, so be it= . However, it is essential that the document clearly convey the deployment= criteria that need to be met for such a deployment. That is, we need a cl= ear statement of that "carefully controlled environment", and I can't find = it in section 17. Thanks, Tim On 10/1/09 1:41 PM, "Simon Perreault" wrote: On Thursday 01 October 2009 13:33:25 Marc Petit-Huguenin wrote: > "[RFC 2129] terms are frequently used to specify behavior with security > implications. The effects on security of not implementing a MUST or > SHOULD, or doing something the specification says MUST NOT or SHOULD NOT = be > done may be very subtle. Document authors should take the time to elabora= te > the security implications of not following recommendations or requirement= s > as most implementors will not have had the benefit of the experience and > discussion that produced the specification." As I said, this is already fulfilled by section 17.1.1. What seems to be required by IESG is discussion of one use case for not complying with the SHOULD. I think that's not necessary. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org --_000_C6F391CB16DC4timpolknistgov_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [BEHAVE] Discusses regarding security mechanism usage for TURN</= TITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:= 11pt'>Simon,<BR> <BR> As I understand it, the wg is comfortable with deployments that do not requ= ire authentication *only* because that TURN server can be protected using f= iltering on specific interfaces given specific networks architectures, in c= ombination with tightly controlled (usually static) client configuration. &= nbsp; The set of attributes that must be in place for this to be a saf= e configuration is rather complicated, and I have my doubts about such depl= oyments being fully realized in practice, especially since the document tha= t list of attributes has been documented in various emails, but does not ap= pear in the document.<BR> <BR> To be clear, section 4 currently states:<BR> <BR>             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;          </SPAN></FON= T><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Courier, Courier New">One re= ason that a server might not<BR>       require requests to be authenticated is= that TURN is being used in<BR>       a carefully controlled environment in w= hich the risks of<BR>       unauthenticated requests by hostile thi= rd-parties have been<BR>       mitigated.  See <FONT COLOR=3D"#1C= 00EF"><U>Section 17</U></FONT> for more discussion on this point.<BR> <BR> </FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">If the wg has cons= ensus that such deployments should be permitted, so be it.  However, i= t is essential that the document clearly convey the deployment criteria tha= t need to be met for such a deployment.  That is, we need a clear stat= ement of that “carefully controlled environment”, and I canR= 17;t find it in section 17.<BR> <BR> Thanks,<BR> <BR> Tim<BR> <BR> On 10/1/09 1:41 PM, "Simon Perreault" <<a href=3D"simon.perrea= ult@viagenie.ca">simon.perreault@viagenie.ca</a>> wrote:<BR> <BR> </FONT></SPAN><BLOCKQUOTE><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Cali= bri, Verdana, Helvetica, Arial">On Thursday 01 October 2009 13:33:25 Marc P= etit-Huguenin wrote:<BR> > "[RFC 2129] terms are frequently used to specify behavior with se= curity<BR> > implications.  The effects on security of not implementing a MUST= or<BR> > SHOULD, or doing something the specification says MUST NOT or SHOULD N= OT be<BR> > done may be very subtle. Document authors should take the time to elab= orate<BR> > the security implications of not following recommendations or requirem= ents<BR> > as most implementors will not have had the benefit of the experience a= nd<BR> > discussion that produced the specification."<BR> <BR> As I said, this is already fulfilled by section 17.1.1.<BR> <BR> What seems to be required by IESG is discussion of one use case for not<BR> complying with the SHOULD. I think that's not necessary.<BR> <BR> Simon<BR> --<BR> DNS64 open-source   --> <a href=3D"http://ecdysis.viagenie.ca"= >http://ecdysis.viagenie.ca</a><BR> STUN/TURN server    --> <a href=3D"http://numb.viagenie.c= a">http://numb.viagenie.ca</a><BR> vCard 4.0           -->= ; <a href=3D"http://www.vcarddav.org">http://www.vcarddav.org</a><BR> <BR> </FONT></SPAN></BLOCKQUOTE> </BODY> </HTML> --_000_C6F391CB16DC4timpolknistgov_-- From dthaler@microsoft.com Thu Oct 8 12:31:40 2009 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 5B8743A684F for <behave@core3.amsl.com>; Thu, 8 Oct 2009 12:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.465 X-Spam-Level: X-Spam-Status: No, score=-10.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 CvvemHwnIq-m for <behave@core3.amsl.com>; Thu, 8 Oct 2009 12:31:39 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 8E5D63A69DE for <behave@ietf.org>; Thu, 8 Oct 2009 12:31:39 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 8 Oct 2009 12:33:21 -0700 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 id 14.0.639.20; Thu, 8 Oct 2009 12:33:21 -0700 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.171]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Thu, 8 Oct 2009 12:33:21 -0700 From: Dave Thaler <dthaler@microsoft.com> To: Simon Perreault <simon.perreault@viagenie.ca>, "behave@ietf.org" <behave@ietf.org> Thread-Topic: [BEHAVE] Discusses regarding security mechanism usage for TURN Thread-Index: AQHKNmk0rDvACuhYKUSVinn4sbSSaZDxbKGAgAALWICACrZyIA== Date: Thu, 8 Oct 2009 19:33:20 +0000 Message-ID: <E4561B14EE2A3E4E9D478EBFB5416E1B221309DF@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> References: <C67BCA34F23E804199B464EAF3BE55DF06439A68@oslexcp2.eu.tandberg.int> <4AB038E2.2070403@viagenie.ca> <4AC4D50F.10605@ericsson.com> <200910011253.40031.simon.perreault@viagenie.ca> In-Reply-To: <200910011253.40031.simon.perreault@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Tim Polk <tim.polk@nist.gov>, Peter Livesey <peter.livesey@tandberg.com>, Marc Blanchet <marc.blanchet@viagenie.ca> Subject: Re: [BEHAVE] Discusses regarding security mechanism usage for TURN 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, 08 Oct 2009 19:31:40 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Simon Perreault > Sent: Thursday, October 01, 2009 9:54 AM > To: behave@ietf.org > Cc: Tim Polk; Peter Livesey; Marc Blanchet > Subject: Re: [BEHAVE] Discusses regarding security mechanism usage for > TURN >=20 > On Thursday 01 October 2009 12:13:03 Magnus Westerlund wrote: > > We note that this may fulfill the security requirements. However, the > > current draft is substantially lacking in description of the details > > that are needed to handle this case. Both how you reliably determine > > that a client really is connecting from the trusted domain and how > you > > ensure that the client know if it needs to use the authentication > > mechanism or not. >=20 > Why must this use case be explained in detail? Is there a rule > somewhere that > says "each and every "SHOULD" in a document MUST include a complete > discussion > of the possible use cases for not complying"? If so, then a bunch of > RFCs will > need to be revised... >=20 > Just s/MUST/SHOULD/ and be done with it. >=20 > The Security Considerations section, in particular section 17.1.1, > already > explain the full implications. People are not stupid. It is plain as > day that > a TURN server offers a service, and authentication is a good idea if > you don't > want people abusing the service. >=20 > I don't think having a MUST instead of a SHOULD will impact in any way > the > trust that people will have in this protocol. >=20 > Simon Perhaps a conditional MUST would be better than a SHOULD. For example: Unless the server can reliably determine that a client is connecting from a trusted network, the server MUST demand=20 that all requests from the client be authenticated using this=20 mechanism, or that a equally strong or stronger mechanism for=20 client authentication is used. Mechanisms for reliably=20 determining that a client is connecting from a trusted network are outside the scope of this document. =20 -Dave From simon.perreault@viagenie.ca Thu Oct 8 12:41:52 2009 Return-Path: <simon.perreault@viagenie.ca> 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 ED0FE3A6916 for <behave@core3.amsl.com>; Thu, 8 Oct 2009 12:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.103, 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 B-abrJphxcDz for <behave@core3.amsl.com>; Thu, 8 Oct 2009 12:41:39 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 2ED623A69E1 for <behave@ietf.org>; Thu, 8 Oct 2009 12:41:33 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 08AEC20E03; Thu, 8 Oct 2009 15:43:16 -0400 (EDT) From: Simon Perreault <simon.perreault@viagenie.ca> Organization: =?iso-8859-1?q?Viag=E9nie?= To: Dave Thaler <dthaler@microsoft.com> Date: Thu, 8 Oct 2009 15:39:32 -0400 User-Agent: KMail/1.12.0 (Linux/2.6.30.5-43.fc11.x86_64; KDE/4.3.0; x86_64; ; ) References: <C67BCA34F23E804199B464EAF3BE55DF06439A68@oslexcp2.eu.tandberg.int> <200910011253.40031.simon.perreault@viagenie.ca> <E4561B14EE2A3E4E9D478EBFB5416E1B221309DF@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <E4561B14EE2A3E4E9D478EBFB5416E1B221309DF@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200910081539.33005.simon.perreault@viagenie.ca> Cc: Tim Polk <tim.polk@nist.gov>, Peter Livesey <peter.livesey@tandberg.com>, "behave@ietf.org" <behave@ietf.org>, Marc Blanchet <marc.blanchet@viagenie.ca> Subject: Re: [BEHAVE] Discusses regarding security mechanism usage for TURN 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, 08 Oct 2009 19:41:53 -0000 On Thursday 08 October 2009 15:33:20 Dave Thaler wrote: > Perhaps a conditional MUST would be better than a SHOULD. > For example: > > Unless the server can reliably determine that a client > is connecting from a trusted network, the server MUST demand > that all requests from the client be authenticated using this > mechanism, or that a equally strong or stronger mechanism for > client authentication is used. Mechanisms for reliably > determining that a client is connecting from a trusted network > are outside the scope of this document. +1, especially the latter part. This is not a simple topic, and should be out of scope for TURN. It would apply equally to many other protocols. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From petithug@acm.org Thu Oct 8 13:28:23 2009 Return-Path: <petithug@acm.org> 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 5B7353A69FC for <behave@core3.amsl.com>; Thu, 8 Oct 2009 13:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 h3tFMsuesYJi for <behave@core3.amsl.com>; Thu, 8 Oct 2009 13:28:22 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 03E593A6804 for <behave@ietf.org>; Thu, 8 Oct 2009 13:28:22 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id AB5326C98532; Thu, 8 Oct 2009 20:30:04 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id D9D6F6C98526; Thu, 8 Oct 2009 20:30:03 +0000 (UTC) Message-ID: <4ACE4BCB.9030207@acm.org> Date: Thu, 08 Oct 2009 13:30:03 -0700 From: Marc Petit-Huguenin <petithug@acm.org> User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: Dave Thaler <dthaler@microsoft.com> References: <C67BCA34F23E804199B464EAF3BE55DF06439A68@oslexcp2.eu.tandberg.int> <4AB038E2.2070403@viagenie.ca> <4AC4D50F.10605@ericsson.com> <200910011253.40031.simon.perreault@viagenie.ca> <E4561B14EE2A3E4E9D478EBFB5416E1B221309DF@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <E4561B14EE2A3E4E9D478EBFB5416E1B221309DF@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Peter Livesey <peter.livesey@tandberg.com>, "behave@ietf.org" <behave@ietf.org>, Marc Blanchet <marc.blanchet@viagenie.ca>, Tim Polk <tim.polk@nist.gov> Subject: Re: [BEHAVE] Discusses regarding security mechanism usage for TURN 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, 08 Oct 2009 20:28:23 -0000 Dave Thaler wrote: >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf Of Simon Perreault >> Sent: Thursday, October 01, 2009 9:54 AM >> To: behave@ietf.org >> Cc: Tim Polk; Peter Livesey; Marc Blanchet >> Subject: Re: [BEHAVE] Discusses regarding security mechanism usage for >> TURN >> >> On Thursday 01 October 2009 12:13:03 Magnus Westerlund wrote: >>> We note that this may fulfill the security requirements. However, the >>> current draft is substantially lacking in description of the details >>> that are needed to handle this case. Both how you reliably determine >>> that a client really is connecting from the trusted domain and how >> you >>> ensure that the client know if it needs to use the authentication >>> mechanism or not. >> Why must this use case be explained in detail? Is there a rule >> somewhere that >> says "each and every "SHOULD" in a document MUST include a complete >> discussion >> of the possible use cases for not complying"? If so, then a bunch of >> RFCs will >> need to be revised... >> >> Just s/MUST/SHOULD/ and be done with it. >> >> The Security Considerations section, in particular section 17.1.1, >> already >> explain the full implications. People are not stupid. It is plain as >> day that >> a TURN server offers a service, and authentication is a good idea if >> you don't >> want people abusing the service. >> >> I don't think having a MUST instead of a SHOULD will impact in any way >> the >> trust that people will have in this protocol. >> >> Simon > > Perhaps a conditional MUST would be better than a SHOULD. > For example: > > Unless the server can reliably determine that a client > is connecting from a trusted network, the server MUST demand > that all requests from the client be authenticated using this > mechanism, or that a equally strong or stronger mechanism for > client authentication is used. Mechanisms for reliably > determining that a client is connecting from a trusted network > are outside the scope of this document. > +1 -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From fred@cisco.com Fri Oct 9 11:15:32 2009 Return-Path: <fred@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 CD1203A67CF for <behave@core3.amsl.com>; Fri, 9 Oct 2009 11:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.168 X-Spam-Level: X-Spam-Status: No, score=-106.168 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6aChOyluICy for <behave@core3.amsl.com>; Fri, 9 Oct 2009 11:15:32 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DF3973A67FC for <behave@ietf.org>; Fri, 9 Oct 2009 11:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2449; q=dns/txt; s=sjiport06001; t=1255112237; x=1256321837; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Fred=20Baker=20<fred@cisco.com>|Subject:=20Need =20another=20case=20in=203.2.5|Date:=20Fri,=209=20Oct=202 009=2011:17:14=20-0700|Message-Id:=20<CC6108C4-E9D2-432F- AC53-B96995220DE8@cisco.com>|To:=20draft-ietf-behave-addr ess-format@tools.ietf.org|Cc:=20Behave=20WG=20<behave@iet f.org>|Mime-Version:=201.0=20(Apple=20Message=20framework =20v936)|Content-Transfer-Encoding:=207bit; bh=BcSIMB76lur2uFCtulT0ac0h5/hc/G9MuA1I/nv5yAk=; b=FAY0pdYlfGWnFc0RrZxqG1Ji4UZcdSb3Jjbd7x3F/n98CtdEaFbR2mpZ 2+SxJefKEwu7jd3o7BgLsuhOx4AU7ODjyUdbAVU0Xhu3nOcbP1Rxgbqby PW2/IGF6s9NRNgVtsTZDRYJV7VPjwBKcgPqsUP74IVPxwpGaCzTOwVYqM k=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAL8az0qrR7Ht/2dsb2JhbADCW5hAhCwEgVg X-IronPort-AV: E=Sophos;i="4.44,533,1249257600"; d="scan'208";a="405624531" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 09 Oct 2009 18:17:17 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n99IHGM2005196; Fri, 9 Oct 2009 18:17:16 GMT Message-Id: <CC6108C4-E9D2-432F-AC53-B96995220DE8@cisco.com> From: Fred Baker <fred@cisco.com> To: draft-ietf-behave-address-format@tools.ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 9 Oct 2009 11:17:14 -0700 X-Mailer: Apple Mail (2.936) Cc: Behave WG <behave@ietf.org> Subject: [BEHAVE] Need another case in 3.2.5 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, 09 Oct 2009 18:15:32 -0000 The draft proposes three formats, two of which are checksum neutral, and says that the result SHOULD be checksum neutral - basically stacking the deck against the third option. They are: 3.2.3: | 96 bits | 32 bits | +-------------------------------------------+---------------------+ | PREFIX | IPv4 address | +-------------------------------------------+---------------------+ This format is not checksum-neutral unless the PREFIX is checksum- neutral. Hence, a well-known prefix can ensure checksum neutrality, but using this format with network-specific prefixes in general cannot. 3.2.4: | 80 bits | 16 | 32 bits | +--------------------------------------+----+---------------------+ | PREFIX |comp| IPv4 address | +--------------------------------------+----+---------------------+ This is by definition checksum neutral with a provider-assigned prefix, as the value of the 16 bits is determined by the 80 bit prefix. 3.2.5: | n bits | 32 bits | 96-n bits | +--------------------------+---------------------+----------------+ | PREFIX | IPv4 address | Zero | +--------------------------+---------------------+----------------+ This is not checksum neutral as specified. 3.2.3 and 3.2.4 neglect one of the primary requirements that led to 3.2.5, however: it doesn't allow a /64 to include a portion of the embedded IPv4 address, and hence doesn't allow a service provider to distribute small numbers of such an address to each of a set of customers without using a well-known prefix, which as we have noted presents other problems in service provider routing. This can be fixed, and trivially. Add one more case 3.2.++: | n bits | 32 bits | 80-n bits | 16 | +--------------------------+---------------------+------------+----+ | PREFIX | IPv4 address | Zero |comp| +--------------------------+---------------------+------------+----+ This provides checksum neutrality *and* addresses use by a service provider. I believe that Xing Li has proposed something similar in another document. From huitema@microsoft.com Fri Oct 9 13:06:54 2009 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 C987A3A6966 for <behave@core3.amsl.com>; Fri, 9 Oct 2009 13:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 0+Pwi4pwfnJt for <behave@core3.amsl.com>; Fri, 9 Oct 2009 13:06:53 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id DDB493A695E for <behave@ietf.org>; Fri, 9 Oct 2009 13:06:53 -0700 (PDT) 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; Fri, 9 Oct 2009 13:08:44 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server id 14.0.639.20; Fri, 9 Oct 2009 13:08:38 -0700 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.171]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Fri, 9 Oct 2009 13:08:39 -0700 From: Christian Huitema <huitema@microsoft.com> To: Fred Baker <fred@cisco.com>, "draft-ietf-behave-address-format@tools.ietf.org" <draft-ietf-behave-address-format@tools.ietf.org> Thread-Topic: [BEHAVE] Need another case in 3.2.5 Thread-Index: AQHKSQzgGQEbBR8O30W5v+HNU/6HnpD9n8Hw Date: Fri, 9 Oct 2009 20:08:36 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA211A6737@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> References: <CC6108C4-E9D2-432F-AC53-B96995220DE8@cisco.com> In-Reply-To: <CC6108C4-E9D2-432F-AC53-B96995220DE8@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Need another case in 3.2.5 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, 09 Oct 2009 20:06:54 -0000 We were having a similar discussion when preparing the next version of the = addressing documents.=20 There are a couple of constraints, of various importance, that we need to a= ddress. You mention checksum neutrality, and we can certainly accommodate t= hat, but there are a few others that lead to discussions. For example, for = stateless translation, we need to be able to route packets in the IPv6 netw= ork based on the IPv4 address. If we want to protect against address spoofi= ng, we need to also perform reverse path checks based the IPv4 address. Eve= n for stateful translation, we may need to select the translator based on t= he target IPv4 address, e.g. to perform load balancing. That requirement can be accommodated in several ways, the simplest one bein= g to format the addresses a prefix (well known or network specific), concat= enated with the IPv4 address and a suffix. That way, the network can perfor= m internal routing and checks on the combination of prefix+IPv4 address. B= ut then, there are a few complications. First, we wonder about the importance of the 64 bit boundary. Addressing do= cuments specify that the global address is essentially formed of a 64 bit s= ubnet prefix and a 64 bit host identifier, with the host identifier compati= ble with IEEE 802 identifiers. Does that mean that the "routing" requiremen= t of stateless translation can only be addressed if the IPv4 bytes are enti= rely contained within the subnet prefix? Different authors have different o= pinions, so WG input would be beneficial. Second, we wonder about the constraints of host identifiers. A first questi= on is whether an all null identifier would be legitimate and practical. The= re is some evidence that it works with most stacks. But there is also a sta= tement in the addressing document that the all null address is reserved for= the subnet anycast address. Do stacks actually implement the subnet anycas= t function? Should the specification be removed from the addressing RFC? Ca= n we just ignore it? If we cannot ignore it, we will have to specify some v= alue different from zero for the suffix. A "checksum neutrality" field migh= t do that, but please consider the second question. The second question regards the uniqueness of host identifiers. Suppose we = define the address used for stateless translation as: 32 bit "provider" pre= fix, 32 bit IPv4 address, and a constant identifier, either 0 or the "check= sum neutrality" value, which is only a function of the provider prefix. Sup= pose now that for some reason there are two "IPv4 addressed" hosts on the s= ame link, e.g. because many servers are located in the same server room. Th= e two hosts will have different addresses, in different 64 bit subnets, but= they will also have different host identifiers. Is that OK?=20 -- Christian Huitema From root@core3.amsl.com Sat Oct 10 12:15:01 2009 Return-Path: <root@core3.amsl.com> X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 316D328C0EE; Sat, 10 Oct 2009 12:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091010191501.316D328C0EE@core3.amsl.com> Date: Sat, 10 Oct 2009 12:15:01 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-stateful-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: Sat, 10 Oct 2009 19:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers Author(s) : M. Bagnulo, et al. Filename : draft-ietf-behave-v6v4-xlate-stateful-02.txt Pages : 40 Date : 2009-10-10 NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and vice-versa. DNS64 is a mechanism for synthesizing AAAA records from A records. These two mechanisms together enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. They also enable peer-to-peer communication between an IPv4 and an IPv6 node, where the communication can be initiated by either end using existing, NAT-traversing, peer-to-peer communication techniques. This document specifies NAT64, and gives suggestions on how they should be deployed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-stateful-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-v6v4-xlate-stateful-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-10120554.I-D@ietf.org> --NextPart-- From marcelo@it.uc3m.es Sat Oct 10 13:11:11 2009 Return-Path: <marcelo@it.uc3m.es> 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 8AAEC3A68F8 for <behave@core3.amsl.com>; Sat, 10 Oct 2009 13:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMGHFbET73GV for <behave@core3.amsl.com>; Sat, 10 Oct 2009 13:11:10 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id DCA1D3A6819 for <behave@ietf.org>; Sat, 10 Oct 2009 13:11:09 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (236.pool85-53-131.dynamic.orange.es [85.53.131.236]) by smtp03.uc3m.es (Postfix) with ESMTP id 2D6AA72DB27 for <behave@ietf.org>; Sat, 10 Oct 2009 22:12:53 +0200 (CEST) Message-ID: <4AD0EAC1.5030309@it.uc3m.es> Date: Sat, 10 Oct 2009 22:12:49 +0200 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: behave@ietf.org References: <20091010191501.316D328C0EE@core3.amsl.com> In-Reply-To: <20091010191501.316D328C0EE@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16940.000 Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-stateful-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: Sat, 10 Oct 2009 20:11:11 -0000 Hi, We have submitted a new version of the draft. This new version - Includes the processing of ICMP queries. - Includes the processing of TCP RST as discussed in the last meeting - Updates the section 8 about scenarios to be aligned with the framework document - Updates the document to be more aligned with the prefix document removed the /96 and added the suffix to the address transform in the non normative part (the normative part simply refers to the other document) - adds support to manually configured entries in the bib. - alignes with the stateless document What is still missing: - deal with the fragmentation mess - cross check that we comply with the behave requirements. In particular, things i would like to check: -- ICMP error handling, in particular, i need to deal with ICMP extensions, and verify that ICMP error handling is compliant with the behave requirements -- check for the cases of silently discarding packets and when to send a ICMP error back (i think this is ok, but i need to double check) -- overview of all behave requirements and i would like to include a section that states what behave requirements are fullfilled by the nat64 - align with the prefix document once the prefix document is more advanced. Comments are welcome, Regards, marcelo Internet-Drafts@ietf.org escribió: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. > > > Title : NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers > Author(s) : M. Bagnulo, et al. > Filename : draft-ietf-behave-v6v4-xlate-stateful-02.txt > Pages : 40 > Date : 2009-10-10 > > NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and > vice-versa. DNS64 is a mechanism for synthesizing AAAA records from > A records. These two mechanisms together enable client-server > communication between an IPv6-only client and an IPv4-only server, > without requiring any changes to either the IPv6 or the IPv4 node, > for the class of applications that work through NATs. They also > enable peer-to-peer communication between an IPv4 and an IPv6 node, > where the communication can be initiated by either end using > existing, NAT-traversing, peer-to-peer communication techniques. > This document specifies NAT64, and gives suggestions on how they > should be deployed. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-stateful-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From caozhenpku@gmail.com Sat Oct 10 19:28:15 2009 Return-Path: <caozhenpku@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 2C5B43A6845 for <behave@core3.amsl.com>; Sat, 10 Oct 2009 19:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 CbiLESJUU6JL for <behave@core3.amsl.com>; Sat, 10 Oct 2009 19:28:14 -0700 (PDT) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 49D543A67F9 for <behave@ietf.org>; Sat, 10 Oct 2009 19:28:14 -0700 (PDT) Received: by pzk6 with SMTP id 6so4045635pzk.29 for <behave@ietf.org>; Sat, 10 Oct 2009 19:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KThe6/xtDgd9CgOX29ibKI3KqOgRXQ2gzJ1vRpWQztY=; b=XwjKVjd1hyZLevMcePDHBZeHrMoG6/h67KjdcBt7veXMgPU7waUxu6mURF2g6GJcKs HTeCQEDxX8Bnk64kg8BxaZsYU8YVLye92tbyqSdY0f6kqU7C7fu72/d5ljkfzq7+sP4I /M1dNE6k2QQUBISPAWikrkxbs5BZNoiordF3I= 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=jzgMh4vycTS9oHuKRUPku9li1lC//hYYb6YgeKiTdckYqL+tZ6RgU4GSPsW3fCo6Rv FRdCqA5OnFoa1idMtKMyDlZTbEx2ZCx87GJ1SAqQSvAMoVej7DdvSoBwOpbH4MQs++Rn R8qKHTGhS6nOLEfO4+rcqzzAL3YRkwvPKhtJ0= MIME-Version: 1.0 Received: by 10.142.75.12 with SMTP id x12mr253791wfa.157.1255228199149; Sat, 10 Oct 2009 19:29:59 -0700 (PDT) In-Reply-To: <4AD0EAC1.5030309@it.uc3m.es> References: <20091010191501.316D328C0EE@core3.amsl.com> <4AD0EAC1.5030309@it.uc3m.es> Date: Sun, 11 Oct 2009 10:29:59 +0800 Message-ID: <a7c8d0a30910101929p3006f8afk26145019dfdcaea1@mail.gmail.com> From: Zhen Cao <caozhenpku@gmail.com> To: marcelo bagnulo braun <marcelo@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-stateful-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: Sun, 11 Oct 2009 02:28:15 -0000 Hi, The ICMP error in section 7 is still left unchanged. I made some comments on section.7 before, as in http://www.ietf.org/mail-archive/web/behave/current/msg06865.html, and Iljitsch agreed the current text wronged the handling. Regards, Zhen On Sun, Oct 11, 2009 at 4:12 AM, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote: > Hi, > > We have submitted a new version of the draft. > > This new version > - Includes the processing of ICMP queries. > - Includes the processing of TCP RST as discussed in the last meeting > - Updates the section 8 about scenarios to be aligned with the framework > document > - Updates the document to be more aligned with the prefix document remove= d > the /96 and added the suffix to the address transform in the non normativ= e > part (the normative part simply refers to the other document) > - adds support to manually configured entries in the bib. > - alignes with the stateless document > > What is still missing: > - deal with the fragmentation mess > - cross check that we comply with the behave requirements. In particular, > things i would like to check: > -- ICMP error handling, in particular, i need to deal with ICMP extension= s, > and verify that ICMP error handling is compliant with the behave > requirements > -- check for the cases of silently discarding packets and when to send a > ICMP error back (i think this is ok, but i need to double check) > -- overview of all behave requirements and i would like to include a sect= ion > that states what behave requirements are fullfilled by the nat64 > - align with the prefix document once the prefix document is more advance= d. > > Comments are welcome, > > Regards, marcelo > > > Internet-Drafts@ietf.org escribi=F3: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Behavior Engineering for Hindrance >> Avoidance Working Group of the IETF. >> >> >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : NAT64: Network Address and Pr= otocol Translation >> from IPv6 Clients to IPv4 Servers >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : M. Bagnulo, et al. >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-behave-v6v4-xlate-st= ateful-02.txt >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 40 >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-10-10 >> >> NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and >> vice-versa. =A0DNS64 is a mechanism for synthesizing AAAA records from >> A records. =A0These two mechanisms together enable client-server >> communication between an IPv6-only client and an IPv4-only server, >> without requiring any changes to either the IPv6 or the IPv4 node, >> for the class of applications that work through NATs. =A0They also >> enable peer-to-peer communication between an IPv4 and an IPv6 node, >> where the communication can be initiated by either end using >> existing, NAT-traversing, peer-to-peer communication techniques. >> This document specifies NAT64, and gives suggestions on how they >> should be deployed. >> >> A URL for this Internet-Draft is: >> >> http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-statefu= l-02.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> =A0---------------------------------------------------------------------= --- >> >> _______________________________________________ >> 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 marcelo@it.uc3m.es Sun Oct 11 01:04:45 2009 Return-Path: <marcelo@it.uc3m.es> 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 9A72C3A6851 for <behave@core3.amsl.com>; Sun, 11 Oct 2009 01:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diDo+TPCQx89 for <behave@core3.amsl.com>; Sun, 11 Oct 2009 01:04:43 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 6240C3A67E6 for <behave@ietf.org>; Sun, 11 Oct 2009 01:04:42 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (22.pool85-53-134.dynamic.orange.es [85.53.134.22]) by smtp01.uc3m.es (Postfix) with ESMTP id 3584CBA4D21; Sun, 11 Oct 2009 10:06:27 +0200 (CEST) Message-ID: <4AD19203.7020505@it.uc3m.es> Date: Sun, 11 Oct 2009 10:06:27 +0200 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Zhen Cao <caozhenpku@gmail.com> References: <20091010191501.316D328C0EE@core3.amsl.com> <4AD0EAC1.5030309@it.uc3m.es> <a7c8d0a30910101929p3006f8afk26145019dfdcaea1@mail.gmail.com> In-Reply-To: <a7c8d0a30910101929p3006f8afk26145019dfdcaea1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16940.003 Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-stateful-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: Sun, 11 Oct 2009 08:04:45 -0000 yes, this is the part of handling fragmentation and mtu issues that i still haven't deal with. Will be done for next rev. Zhen Cao escribió: > Hi, > > The ICMP error in section 7 is still left unchanged. I made some > comments on section.7 before, as in > http://www.ietf.org/mail-archive/web/behave/current/msg06865.html, and > Iljitsch agreed the current text wronged the handling. > > Regards, > Zhen > On Sun, Oct 11, 2009 at 4:12 AM, marcelo bagnulo braun > <marcelo@it.uc3m.es> wrote: > >> Hi, >> >> We have submitted a new version of the draft. >> >> This new version >> - Includes the processing of ICMP queries. >> - Includes the processing of TCP RST as discussed in the last meeting >> - Updates the section 8 about scenarios to be aligned with the framework >> document >> - Updates the document to be more aligned with the prefix document removed >> the /96 and added the suffix to the address transform in the non normative >> part (the normative part simply refers to the other document) >> - adds support to manually configured entries in the bib. >> - alignes with the stateless document >> >> What is still missing: >> - deal with the fragmentation mess >> - cross check that we comply with the behave requirements. In particular, >> things i would like to check: >> -- ICMP error handling, in particular, i need to deal with ICMP extensions, >> and verify that ICMP error handling is compliant with the behave >> requirements >> -- check for the cases of silently discarding packets and when to send a >> ICMP error back (i think this is ok, but i need to double check) >> -- overview of all behave requirements and i would like to include a section >> that states what behave requirements are fullfilled by the nat64 >> - align with the prefix document once the prefix document is more advanced. >> >> Comments are welcome, >> >> Regards, marcelo >> >> >> Internet-Drafts@ietf.org escribió: >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Behavior Engineering for Hindrance >>> Avoidance Working Group of the IETF. >>> >>> >>> Title : NAT64: Network Address and Protocol Translation >>> from IPv6 Clients to IPv4 Servers >>> Author(s) : M. Bagnulo, et al. >>> Filename : draft-ietf-behave-v6v4-xlate-stateful-02.txt >>> Pages : 40 >>> Date : 2009-10-10 >>> >>> NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and >>> vice-versa. DNS64 is a mechanism for synthesizing AAAA records from >>> A records. These two mechanisms together enable client-server >>> communication between an IPv6-only client and an IPv4-only server, >>> without requiring any changes to either the IPv6 or the IPv4 node, >>> for the class of applications that work through NATs. They also >>> enable peer-to-peer communication between an IPv4 and an IPv6 node, >>> where the communication can be initiated by either end using >>> existing, NAT-traversing, peer-to-peer communication techniques. >>> This document specifies NAT64, and gives suggestions on how they >>> should be deployed. >>> >>> A URL for this Internet-Draft is: >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-stateful-02.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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 dwing@cisco.com Sun Oct 11 09:59:18 2009 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 5CFA23A6938 for <behave@core3.amsl.com>; Sun, 11 Oct 2009 09:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYax6+ks4xxx for <behave@core3.amsl.com>; Sun, 11 Oct 2009 09:59:16 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E8C193A6814 for <behave@ietf.org>; Sun, 11 Oct 2009 09:59:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1162; q=dns/txt; s=sjiport06001; t=1255280358; x=1256489958; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Dan=20Wing"=20<dwing@cisco.com>|Subject:=20pres entation=20requests=20and=20cutoff=20dates|Date:=20Sun, =2011=20Oct=202009=2009:59:16=20-0700|Message-ID:=20<05ff 01ca4a94$2acaa7e0$a8f746ab@cisco.com>|To:=20<behave@ietf. org>|MIME-Version:=201.0|Content-Transfer-Encoding:=207bi t; bh=a1SvpghaancAnt7oIZGfxvozjHnt/78sPivyNCacFho=; b=UffREJrhimrpgt8E261bjJg14sTzokovjZGOs0nnzZQHDATwfne/cNE+ IEuSs/Nvja6GapmWquVEBlTb+3Ib5/13CnNMyQa+ocfYehndfhCamIs6x sDpLdo0Um4SmFQd2v27/ADBQP+g1QX9bBUuU1a0AFHNHxbwzsTu5Ec9SY c=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEACqs0UqrR7H+/2dsb2JhbACKXbNDllqELQQ X-IronPort-AV: E=Sophos;i="4.44,542,1249257600"; d="scan'208";a="406798291" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 11 Oct 2009 16:59:18 +0000 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9BGxG1c008248 for <behave@ietf.org>; Sun, 11 Oct 2009 16:59:16 GMT From: "Dan Wing" <dwing@cisco.com> To: <behave@ietf.org> Date: Sun, 11 Oct 2009 09:59:16 -0700 Message-ID: <05ff01ca4a94$2acaa7e0$a8f746ab@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpKlCqFfYsJVDnoS4eVVuM+zP/mxA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: [BEHAVE] presentation requests and cutoff dates 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, 11 Oct 2009 16:59:18 -0000 If you want to present in Hiroshima, please send me email with: * name of presenter * topic (what will be presented; this might or might not be the Internet Draft itself. For example, it could be a discussion of implementation experience) * name of associated Internet Draft(s) * requested time Last minute presentation requests may be refused. We received a lot of last-minute presentation requests for the last IETF (Stockholm), and this made scheduling the meetings unnecessarily difficult, and also meant many WG participants had no time to read individual submissions. Please make the WG aware of new drafts, and get on the agenda early, so that the meeting time can be best utilized discussing technology, rather than the meeting being the first time a new idea is first seen. Thanks. As a reminder, IETF cutoff dates for new (-00) Internet Drafts is 2009-10-19 (Monday) by 17:00 PDT (24:00 UTC/GMT), and revised Internet Drafts is 2009-10-26 (Monday) by 17:00 PDT (24:00 UTC/GMT). Internet Drafts are submitted using https://datatracker.ietf.org/idst/upload.cgi or email to internet-drafts@ietf.org. -d From magnus.westerlund@ericsson.com Mon Oct 12 04:46:44 2009 Return-Path: <magnus.westerlund@ericsson.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 E33723A69BC; Mon, 12 Oct 2009 04:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bxiRIbpOyRu; Mon, 12 Oct 2009 04:46:43 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 618F43A69B8; Mon, 12 Oct 2009 04:46:42 -0700 (PDT) X-AuditID: c1b4fb24-b7ba0ae000005786-c2-4ad317208e0e Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id B4.77.22406.02713DA4; Mon, 12 Oct 2009 13:46:41 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 13:46:40 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 13:46:40 +0200 Message-ID: <4AD31720.3010004@ericsson.com> Date: Mon, 12 Oct 2009 13:46:40 +0200 From: Magnus Westerlund <magnus.westerlund@ericsson.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dan Wing <dwing@cisco.com> References: <20090929163001.CBD933A6942@core3.amsl.com> <36a593230910070907p6b6f4be9xf4c344d055587cbf@mail.gmail.com> <0a9101ca4775$9fa951a0$c2f0200a@cisco.com> In-Reply-To: <0a9101ca4775$9fa951a0$c2f0200a@cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 12 Oct 2009 11:46:40.0244 (UTC) FILETIME=[A97C0B40:01CA4B31] X-Brightmail-Tracker: AAAAAA== Cc: 'bo zhou' <zhouboyj@gmail.com>, behave@ietf.org, iesg@ietf.org, 'Dave Thaler' <dthaler@microsoft.com> Subject: Re: [BEHAVE] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) 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, 12 Oct 2009 11:46:45 -0000 Hi, I just want to indicate that this was not my interpretation of the charter. Case 5 and 6 was to my knowledge added to handle the cases when two different businesses or different parts of the same organization want to connect their networks together and need translation, rather than going through the Internet. When it comes to host based translation, I think we would need more discussion about the motivation for that use case are. As I understand it it is a case of handling IPv4 only legacy applications when you have updated the operating system and uses an IPv6 only network. I don't see any reason for doing it for IPv6 only applications as they should be capable of handling IPv4 connectivity. And if an application really needs IPv6 to function there exist tunneling solutions that would be a better gap-filler than a translation based solution. So for host based solutions I think we haven't had a conclusive discussion about either what the requirements and motivations are or if there is consensus to take that on. Regards Magnus Westerlund Dan Wing skrev: > > >> -----Original Message----- >> From: bo zhou [mailto:zhouboyj@gmail.com] >> Sent: Wednesday, October 07, 2009 9:08 AM >> To: Dave Thaler; Dan Wing >> Cc: ietf-announce@ietf.org; behave@ietf.org; iesg@ietf.org >> Subject: Re: [BEHAVE] WG Review: Recharter of Behavior >> Engineering for Hindrance Avoidance (behave) >> >> Hi Dave and Dan, >> >> I just found the charter of the Behave has been modified. >> >> "5. An IPv6 network to an IPv4 network, i.e., perform >> translation between >> IPv6 and IPv4 for packets in uni- or bi-directional flows that are >> initiated from an IPv6 host towards an IPv4 host. The translation >> function is intended to service a specific IPv6 network of arbitrary >> size and a specific IPv4 network of arbitrary size (neither >> of which are >> the Internet)." >> >> Does this cover host based translator solutions for 6 to 4? > > Yes, the "specific IPv6 network of arbitrary size" is a network containing 1 > host. > > -d > > >> Regards, >> >> Bo Zhou >> >> >> On Wed, Sep 30, 2009 at 12:30 AM, IESG Secretary >> <iesg-secretary@ietf.org> wrote: >> >> >> A modified charter has been submitted for the Behavior >> Engineering for >> Hindrance Avoidance (behave) working group in the >> Transport Area of the >> IETF. The IESG has not made any determination as yet. >> The modified >> charter is provided below for informational purposes >> only. Please send >> your comments to the IESG mailing list (iesg@ietf.org) >> by Tuesday, October >> 6, 2009. >> >> Behavior Engineering for Hindrance Avoidance (behave) >> ----------------------------------------------------- >> Current Status: Active Working Group >> Last Modified: 2009-09-09 >> >> Current Status: Active Working Group >> >> Additional information is available at tools.ietf.org/wg/behave >> Chair(s): >> >> * Dan Wing <dwing@cisco.com> >> * Dave Thaler <dthaler@microsoft.com> >> >> Transport Area Director(s): >> >> * Magnus Westerlund <magnus.westerlund@ericsson.com> >> * Lars Eggert <lars.eggert@nokia.com> >> >> Transport Area Advisor: >> >> * Magnus Westerlund <magnus.westerlund@ericsson.com> >> >> Mailing Lists: >> General Discussion: behave@ietf.org >> To Subscribe: behave-request@ietf.org >> In Body: In Body: subscribe >> Archive: http://www.ietf.org/mail-archive/web/behave >> >> Description of Working Group: >> >> The behavior of NATs varies from one implementation to >> another. As a >> result it is very difficult for applications to predict >> or discover the >> behavior of these devices. Predicting and/or >> discovering the behavior >> of NATs is important for designing application protocols and NAT >> traversal techniques that work reliably in existing >> networks. This >> situation is especially problematic for end-to-end >> applications where >> one or both end-points are behind a NAT, such as >> multiuser games, >> interactive multimedia and P2P download. >> >> The working group documents best current practices to >> enable NATs to >> function in as deterministic a fashion as possible. The >> NAT behavior >> practices will be application independent. This has >> already completed >> for UDP, TCP, DCCP, Multicast and ICMP. It continues >> with SCTP and any >> additional protocol deemed necessary to handle. The WG >> has documented >> approaches for characterizing and testing NAT devices. >> >> BEHAVE will develop protocol-independent toolkits >> usable by application >> protocols for NAT traversal. The WG has already >> produced an update of >> the binding discovery protocol STUN. It will now produce a relay >> protocol that focuses on security and is usable with >> both IPv4 and >> IPv6, and capable of relaying between the two IP versions. >> >> Due to the WG's experience with translators and their >> behavior it has >> been given the following tasks to help encourage >> migration to IPv6. To >> support deployments where communicating hosts require >> using different >> address families (IPv4 or IPv6), address family translation is >> needed to establish communication. In BEHAVE's >> specification work on >> this topic it will coordinate with the V6ops WG on >> requirements and >> operational considerations. >> >> "An IPv4 network" or "an IPv6 network" in the >> descriptions below refer >> to a network with a clearly identifiable administrative >> domain (e.g., >> an enterprise campus network, a mobile operator's >> cellular network, a >> residential subscriber network, etc.). It will also be >> that network >> that deploys the necessary equipment for translation. >> >> The BEHAVE WG will design solutions for the following >> six translation >> scenarios; other scenarios are out of scope: >> >> 1. An IPv6 network to IPv4 Internet, i.e. perform >> translation between >> IPv4 and IPv6 for packets in uni- or bi-directional >> flows that are >> initiated from an IPv6 host towards an IPv4 host. The translator >> function is intended to service a specific IPv6 network >> of arbitary >> size. Port translation is necessary on the IPv4 side >> for efficient IPv4 >> address usage. >> >> 2. IPv6 Internet to an IPv4 network, i.e. perform >> translation between >> IPv4 and IPv6 for packets in uni- or bi-directional >> flows that are >> initiated from an IPv6 host towards an IPv4 host. The translator >> function is intended to service a specific IPv4 network >> using either >> private or public IPv4 addresses. This scenario has different >> constraints compared to (1), e.g. the IPv4 hosts that are to be >> reachable over IPv6 can be enumerated. Therefore, the >> WG should attempt >> to design a simpler solution with less impact on applications. >> >> 3. An IPv4 network to IPv6 Internet, i.e. perform >> translation between >> IPv4 and IPv6 for packets in uni- or bi-directional >> flows that are >> initiated from an IPv4 host towards an IPv6 host. The translator >> function is intended to service a specific IPv4 network >> using either >> public or private IPv4 address space. >> >> 4. IPv4 Internet to an IPv6 network, i.e. perform >> translation between >> IPv4 and IPv6 for packets in uni- or bi-directional >> flows that are >> initiated from an IPv4 host towards an IPv6 host. The translator >> function is intended to service a specific IPv6 network >> where selected >> IPv6 hosts and services are to be reachable. >> >> 5. An IPv6 network to an IPv4 network, i.e., perform >> translation between >> IPv6 and IPv4 for packets in uni- or bi-directional >> flows that are >> initiated from an IPv6 host towards an IPv4 host. The >> translation >> function is intended to service a specific IPv6 network >> of arbitrary >> size and a specific IPv4 network of arbitrary size >> (neither of which are >> the Internet). >> >> 6. An IPv4 network to an IPv6 network, i.e., perform >> translation between >> IPv4 and IPv6 for packets in uni- or bi-directional >> flows that are >> initiated from an IPv4 host towards an IPv6 host. The >> translation >> function is intended to service a specific IPv6 network >> of arbitrary >> size and a specific IPv4 network of arbitrary size >> (neither of which are >> the Internet). >> >> All translation solutions shall be capable of handling >> flows using TCP, >> UDP, DCCP, and SCTP, unless they prevent a timely >> completion of the >> work item. The parts of ICMP that can be translated are >> also required >> to work across a translation solution. Additional >> protocols directly >> on top of IP may be supported. Translation mechanisms >> must handle IP >> fragmentation. >> >> The translators should support multicast traffic and its control >> traffic (IGMP and MLD) across them, both Single Source >> Multicast (SSM) >> and Any Source Multicast (ASM). However, the WG may >> determine that it >> becomes too complex or too difficult to realize with maintained >> functionality, for some or all cases of multicast functionality. >> >> Translation mechanisms cannot transparently support >> protocols that >> embed network addresses within their protocol messages without >> application level gateways (ALGs). Because ALGs have >> security issues >> (like blocking usage of TLS), are error prone and >> brittle, and hinder >> application development, the usage of ALGs in the >> defined translators >> should be avoided. Instead application developers will >> need to be aware >> and use mechanisms that handle the address family >> translation. ALGs may >> be considered only for the most crucial of legacy applications. >> >> DNS is a crucial part in making a large number of >> applications work >> across a translator. Thus the solution to the above >> translation cases >> shall include recommendations for DNS. If additional >> DNS functionality >> is needed, it may be developed. Any DNS extensions must >> be developed >> together with the DNSEXT WG, including issuing a joint >> WG last call for >> any documents. >> >> The WG needs to determine the best method for providing >> address space >> to a translator in the different deployment cases and >> documenting the >> pros and cons of the suggested approaches. The WG is to >> seek input from >> the Routing, Operations and Internet areas. >> >> Solutions may solve more than one of the cases, however >> timely delivery >> is more important than a unified solution. >> >> Goals and Milestones: >> >> Done Submit BCP that defines unicast UDP >> behavioral requirements >> for NATs to IESG >> Done Submit a BCP that defines TCP behavioral >> requireents for NATs >> to IESG >> Done Submit a BCP that defines ICMP behavioral >> requirements for >> NATs to IESG >> Done Submit informational that discusses current >> NAT traversal >> techniques used by applications >> Done Submit BCP that defines multicast UDP >> Done Submit revision of RFC 3489 to IESG >> behavioral requirements for >> NATs to IESG >> Done Submit informational document for rfc3489bis >> test vectors >> Done Submit experimental document that describes >> how an application >> can determine the type of NAT it is behind >> Done Submit BCP document for DCCP NAT behavior >> Dec 2009 Submit to IESG: SCTP NAT behavior (BCP) >> Done Submit to IESG: relay protocol (std) >> Done Determine relative prioritization of the four >> translation >> cases. Documented in IETF74 minutes. >> Sep 2009 Submit to IESG: relaying of a TCP bytestream (std) >> Dec 2009 Submit to IESG: IPv6 relay protocol (std) >> Done Determine what solutions(s) and components >> are needed to solve >> each of the four cases. Create new milestones for the >> solution(s) and >> the components. Documented in IETF74 minutes. >> Done Submit to IESG: TURN-URI document (std) >> Dec 2009 Submit to IESG: framework for IPv6/IPv4 >> translation (info) >> Dec 2009 Submit to IESG: stateless IPv6/IPv4 translation (std) >> Dec 2009 Submit to IESG: stateful IPv6/IPv4 translation (std) >> Dec 2009 Submit to IESG: DNS rewriting for IPv6/IPv4 >> translation (std) >> Jan 2010 Submit to IESG: FTP ALG for IPv6/IPv4 >> translation (std) >> Jan 2010 Submit to IESG: IPv6 prefix for IPv6/IPv4 >> translator (std) >> Mar 2010 Submit to IESG: large scale NAT requirements (BCP) >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >> >> >> >> >> -- >> Regards, >> >> Bo Zhou >> China Mobile >> >> > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > -- Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From cb.list6@gmail.com Mon Oct 12 08:54:27 2009 Return-Path: <cb.list6@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 5DDD528C242; Mon, 12 Oct 2009 08:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmV6ChhnPUEf; Mon, 12 Oct 2009 08:54:25 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id ADE9328C23E; Mon, 12 Oct 2009 08:54:25 -0700 (PDT) Received: by pxi6 with SMTP id 6so1595207pxi.31 for <multiple recipients>; Mon, 12 Oct 2009 08:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=t/hKGS35pYvJXo+/oEl2Q9hMgO660ENOU+Sxs2ub6QY=; b=eoM2w3C7lQ9LfomIkStVTA49oSoHUgRzeAdiTd0GLe1L5BxkjBad/XdfKB5HBSBRMj a50iXMGhb1fd1y9CZ5hgflOoPE6anV0h86r1+q1hlvBJ6ewqW1zXL83nZ2oAWSAOubuE OINj8RieiPTAlH6XJvgJs5It3xqcCFC2PG2Xw= 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=l2nuh5M/fW7NDG4QdIcXZbBc1PhYH9Zv8V/IDb5RFwVdKR8Ng9W7ys7lLMMqQhMhn4 WRMWMGwvhoVfVGMMFToOBpgt5XB04ozPQPS/MEeQq4UEE6rkJV6BRzpDMPLSZvS9RNiG vU7hjiz6Qvr/o2tEkNfTSIaEKspErW3JVBZL4= MIME-Version: 1.0 Received: by 10.142.1.3 with SMTP id 3mr467373wfa.66.1255362866428; Mon, 12 Oct 2009 08:54:26 -0700 (PDT) In-Reply-To: <4AD31720.3010004@ericsson.com> References: <20090929163001.CBD933A6942@core3.amsl.com> <36a593230910070907p6b6f4be9xf4c344d055587cbf@mail.gmail.com> <0a9101ca4775$9fa951a0$c2f0200a@cisco.com> <4AD31720.3010004@ericsson.com> Date: Mon, 12 Oct 2009 08:54:26 -0700 Message-ID: <bcff0fba0910120854w74fd3bc0n9a3a4cb71e2db398@mail.gmail.com> From: Cameron Byrne <cb.list6@gmail.com> To: Magnus Westerlund <magnus.westerlund@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Dave Thaler <dthaler@microsoft.com>, bo zhou <zhouboyj@gmail.com>, behave@ietf.org, iesg@ietf.org, Dan Wing <dwing@cisco.com> Subject: Re: [BEHAVE] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) 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, 12 Oct 2009 15:54:27 -0000 On Mon, Oct 12, 2009 at 4:46 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote: > Hi, > > I just want to indicate that this was not my interpretation of the > charter. Case 5 and 6 was to my knowledge added to handle the cases when > two different businesses or different parts of the same organization > want to connect their networks together and need translation, rather > than going through the Internet. > > When it comes to host based translation, I think we would need more > discussion about the motivation for that use case are. As I understand > it it is a case of handling IPv4 only legacy applications when you have > updated the operating system and uses an IPv6 only network. I don't see > any reason for doing it for IPv6 only applications as they should be > capable of handling IPv4 connectivity. And if an application really > needs IPv6 to function there exist tunneling solutions that would be a > better gap-filler than a translation based solution. > > So for host based solutions I think we haven't had a conclusive > discussion about either what the requirements and motivations are or if > there is consensus to take that on. Agreed. I really struggle to understand the need for host based solutions. The host based solutions are essentially a greenfield build since it requires the host to ultimately be IPv6 and have the PNAT software extensions. It seems wiser to me, if you assume a new host software is required, to go straight IPv6 with DNS64 / NAT64 as an interworking technology that has a known exit strategy (reaching the goal of IPv6 end-to-end) and has incentives for both the network operator and the content owners to move towards end-to-end IPv6. For network operators, less NAT state is less cost so they want native IPv6 ASAP. For content owners and application developers, they want to ensure their content is delivered inline with the end-to-end principles to give the user the best experience. In this way, NAT64 / DNS64 allows me to keep growing my network with a steady-state service model (NAT44 -- it is common in mobile today, and CGN will make it common in fixed line) and provides rewards to content owners and network operators to solve the chicken and egg problem that is IPv6 adoptions. Much of the calls for host based NAT are fueled by fear of legacy IPv4 applications, but my users mostly use common protocols for Web and Email that works well natively in IPv6 and through translators. A very small portion of my users use applications that have no path to IPv6 native or NAT64, and they can be kept as IPv4 in the medium term. I cannot architect my future network based on 1% of users and their legacy needs. The only clear reason i can see to do host based IPv6 to IPv4 interworking is if the economics are such that transferring the complexity of the translation from the network to the host is in someway advantageous. In my world of North American mobile wireless, the service provider subsidizes the handset and therefore as the service provider we have a large amount of control over which handsets are used and we are responsible for supporting those handsets. And, we have a large degree of ownership of the architecture and complexity in the network (which includes the devices attached to the network). It behooves us to choose solutions that are end-to-end less complex and easier to support in the long run, not simply transferring the complexity to the handset vendors. That said, network operators can deploy what makes sense for their unique economic and technology context, and IMHO NAT64 / DNS64 in the network is the best strategic option, it has the right incentives towards end to end IPv6, and it is only an incremental change to the NAT44 world of today. Host based solutions, IMHO, are not being considered seriously in North America or Europe. Cameron Byrne Principal Engineer T-Mobile USA. > > Regards > > Magnus Westerlund > > > Dan Wing skrev: >> >> >>> -----Original Message----- >>> From: bo zhou [mailto:zhouboyj@gmail.com] >>> Sent: Wednesday, October 07, 2009 9:08 AM >>> To: Dave Thaler; Dan Wing >>> Cc: ietf-announce@ietf.org; behave@ietf.org; iesg@ietf.org >>> Subject: Re: [BEHAVE] WG Review: Recharter of Behavior >>> Engineering for Hindrance Avoidance (behave) >>> >>> Hi Dave and Dan, >>> >>> I just found the charter of the Behave has been modified. >>> >>> "5. An IPv6 network to an IPv4 network, i.e., perform >>> translation between >>> IPv6 and IPv4 for packets in uni- or bi-directional flows that are >>> initiated from an IPv6 host towards an IPv4 host. =A0The translation >>> function is intended to service a specific IPv6 network of arbitrary >>> size and a specific IPv4 network of arbitrary size (neither >>> of which are >>> the Internet)." >>> >>> Does this cover host based translator solutions for 6 to 4? >> >> Yes, the "specific IPv6 network of arbitrary size" is a network containi= ng 1 >> host. >> >> -d >> >> >>> Regards, >>> >>> Bo Zhou >>> >>> >>> On Wed, Sep 30, 2009 at 12:30 AM, IESG Secretary >>> <iesg-secretary@ietf.org> wrote: >>> >>> >>> =A0 =A0 =A0A modified charter has been submitted for the Behavior >>> Engineering for >>> =A0 =A0 =A0Hindrance Avoidance (behave) working group in the >>> Transport Area of the >>> =A0 =A0 =A0IETF. =A0The IESG has not made any determination as yet. >>> The modified >>> =A0 =A0 =A0charter is provided below for informational purposes >>> only. =A0Please send >>> =A0 =A0 =A0your comments to the IESG mailing list (iesg@ietf.org) >>> by Tuesday, October >>> =A0 =A0 =A06, 2009. >>> >>> =A0 =A0 =A0Behavior Engineering for Hindrance Avoidance (behave) >>> =A0 =A0 =A0----------------------------------------------------- >>> =A0 =A0 =A0Current Status: Active Working Group >>> =A0 =A0 =A0Last Modified: 2009-09-09 >>> >>> =A0 =A0 =A0Current Status: Active Working Group >>> >>> =A0 =A0 =A0Additional information is available at tools.ietf.org/wg/beh= ave >>> =A0 =A0 =A0Chair(s): >>> >>> =A0 =A0 =A0 =A0 * Dan Wing <dwing@cisco.com> >>> =A0 =A0 =A0 =A0 * Dave Thaler <dthaler@microsoft.com> >>> >>> =A0 =A0 =A0Transport Area Director(s): >>> >>> =A0 =A0 =A0 =A0 * Magnus Westerlund <magnus.westerlund@ericsson.com> >>> =A0 =A0 =A0 =A0 * Lars Eggert <lars.eggert@nokia.com> >>> >>> =A0 =A0 =A0Transport Area Advisor: >>> >>> =A0 =A0 =A0 =A0 * Magnus Westerlund <magnus.westerlund@ericsson.com> >>> >>> =A0 =A0 =A0Mailing Lists: >>> =A0 =A0 =A0 General Discussion: behave@ietf.org >>> =A0 =A0 =A0 To Subscribe: behave-request@ietf.org >>> =A0 =A0 =A0 In Body: In Body: subscribe >>> =A0 =A0 =A0 Archive: http://www.ietf.org/mail-archive/web/behave >>> >>> =A0 =A0 =A0Description of Working Group: >>> >>> =A0 =A0 =A0The behavior of NATs varies from one implementation to >>> another. As a >>> =A0 =A0 =A0result it is very difficult for applications to predict >>> or discover the >>> =A0 =A0 =A0behavior of these devices. Predicting and/or >>> discovering the behavior >>> =A0 =A0 =A0of NATs is important for designing application protocols and= NAT >>> =A0 =A0 =A0traversal techniques that work reliably in existing >>> networks. This >>> =A0 =A0 =A0situation is especially problematic for end-to-end >>> applications where >>> =A0 =A0 =A0one or both end-points are behind a NAT, such as >>> multiuser games, >>> =A0 =A0 =A0interactive multimedia and P2P download. >>> >>> =A0 =A0 =A0The working group documents best current practices to >>> enable NATs to >>> =A0 =A0 =A0function in as deterministic a fashion as possible. The >>> NAT behavior >>> =A0 =A0 =A0practices will be application independent. This has >>> already completed >>> =A0 =A0 =A0for UDP, TCP, DCCP, Multicast and ICMP. It continues >>> with SCTP and any >>> =A0 =A0 =A0additional protocol deemed necessary to handle. The WG >>> has documented >>> =A0 =A0 =A0approaches for characterizing and testing NAT devices. >>> >>> =A0 =A0 =A0BEHAVE will develop protocol-independent toolkits >>> usable by application >>> =A0 =A0 =A0protocols for NAT traversal. The WG has already >>> produced an update of >>> =A0 =A0 =A0the binding discovery protocol STUN. It will now produce a r= elay >>> =A0 =A0 =A0protocol that focuses on security and is usable with >>> both IPv4 and >>> =A0 =A0 =A0IPv6, and capable of relaying between the two IP versions. >>> >>> =A0 =A0 =A0Due to the WG's experience with translators and their >>> behavior it has >>> =A0 =A0 =A0been given the following tasks to help encourage >>> migration to IPv6. To >>> =A0 =A0 =A0support deployments where communicating hosts require >>> using different >>> =A0 =A0 =A0address families (IPv4 or IPv6), address family translation = is >>> =A0 =A0 =A0needed to establish communication. In BEHAVE's >>> specification work on >>> =A0 =A0 =A0this topic it will coordinate with the V6ops WG on >>> requirements and >>> =A0 =A0 =A0operational considerations. >>> >>> =A0 =A0 =A0"An IPv4 network" or "an IPv6 network" in the >>> descriptions below refer >>> =A0 =A0 =A0to a network with a clearly identifiable administrative >>> domain (e.g., >>> =A0 =A0 =A0an enterprise campus network, a mobile operator's >>> cellular network, a >>> =A0 =A0 =A0residential subscriber network, etc.). It will also be >>> that network >>> =A0 =A0 =A0that deploys the necessary equipment for translation. >>> >>> =A0 =A0 =A0The BEHAVE WG will design solutions for the following >>> six translation >>> =A0 =A0 =A0scenarios; other scenarios are out of scope: >>> >>> =A0 =A0 =A01. An IPv6 network to IPv4 Internet, i.e. perform >>> translation between >>> =A0 =A0 =A0IPv4 and IPv6 for packets in uni- or bi-directional >>> flows that are >>> =A0 =A0 =A0initiated from an IPv6 host towards an IPv4 host. The transl= ator >>> =A0 =A0 =A0function is intended to service a specific IPv6 network >>> of arbitary >>> =A0 =A0 =A0size. Port translation is necessary on the IPv4 side >>> for efficient IPv4 >>> =A0 =A0 =A0address usage. >>> >>> =A0 =A0 =A02. IPv6 Internet to an IPv4 network, i.e. perform >>> translation between >>> =A0 =A0 =A0IPv4 and IPv6 for packets in uni- or bi-directional >>> flows that are >>> =A0 =A0 =A0initiated from an IPv6 host towards an IPv4 host. The transl= ator >>> =A0 =A0 =A0function is intended to service a specific IPv4 network >>> using either >>> =A0 =A0 =A0private or public IPv4 addresses. This scenario has differen= t >>> =A0 =A0 =A0constraints compared to (1), e.g. the IPv4 hosts that are to= be >>> =A0 =A0 =A0reachable over IPv6 can be enumerated. Therefore, the >>> WG should attempt >>> =A0 =A0 =A0to design a simpler solution with less impact on application= s. >>> >>> =A0 =A0 =A03. An IPv4 network to IPv6 Internet, i.e. perform >>> translation between >>> =A0 =A0 =A0IPv4 and IPv6 for packets in uni- or bi-directional >>> flows that are >>> =A0 =A0 =A0initiated from an IPv4 host towards an IPv6 host. The transl= ator >>> =A0 =A0 =A0function is intended to service a specific IPv4 network >>> using either >>> =A0 =A0 =A0public or private IPv4 address space. >>> >>> =A0 =A0 =A04. IPv4 Internet to an IPv6 network, i.e. perform >>> translation between >>> =A0 =A0 =A0IPv4 and IPv6 for packets in uni- or bi-directional >>> flows that are >>> =A0 =A0 =A0initiated from an IPv4 host towards an IPv6 host. The transl= ator >>> =A0 =A0 =A0function is intended to service a specific IPv6 network >>> where selected >>> =A0 =A0 =A0IPv6 hosts and services are to be reachable. >>> >>> =A0 =A0 =A05. An IPv6 network to an IPv4 network, i.e., perform >>> translation between >>> =A0 =A0 =A0IPv6 and IPv4 for packets in uni- or bi-directional >>> flows that are >>> =A0 =A0 =A0initiated from an IPv6 host towards an IPv4 host. =A0The >>> translation >>> =A0 =A0 =A0function is intended to service a specific IPv6 network >>> of arbitrary >>> =A0 =A0 =A0size and a specific IPv4 network of arbitrary size >>> (neither of which are >>> =A0 =A0 =A0the Internet). >>> >>> =A0 =A0 =A06. An IPv4 network to an IPv6 network, i.e., perform >>> translation between >>> =A0 =A0 =A0IPv4 and IPv6 for packets in uni- or bi-directional >>> flows that are >>> =A0 =A0 =A0initiated from an IPv4 host towards an IPv6 host. =A0The >>> translation >>> =A0 =A0 =A0function is intended to service a specific IPv6 network >>> of arbitrary >>> =A0 =A0 =A0size and a specific IPv4 network of arbitrary size >>> (neither of which are >>> =A0 =A0 =A0the Internet). >>> >>> =A0 =A0 =A0All translation solutions shall be capable of handling >>> flows using TCP, >>> =A0 =A0 =A0UDP, DCCP, and SCTP, unless they prevent a timely >>> completion of the >>> =A0 =A0 =A0work item. The parts of ICMP that can be translated are >>> also required >>> =A0 =A0 =A0to work across a translation solution. =A0Additional >>> protocols directly >>> =A0 =A0 =A0on top of IP may be supported. Translation mechanisms >>> must handle IP >>> =A0 =A0 =A0fragmentation. >>> >>> =A0 =A0 =A0The translators should support multicast traffic and its con= trol >>> =A0 =A0 =A0traffic (IGMP and MLD) across them, both Single Source >>> Multicast (SSM) >>> =A0 =A0 =A0and Any Source Multicast (ASM). However, the WG may >>> determine that it >>> =A0 =A0 =A0becomes too complex or too difficult to realize with maintai= ned >>> =A0 =A0 =A0functionality, for some or all cases of multicast functional= ity. >>> >>> =A0 =A0 =A0Translation mechanisms cannot transparently support >>> protocols that >>> =A0 =A0 =A0embed network addresses within their protocol messages witho= ut >>> =A0 =A0 =A0application level gateways (ALGs). Because ALGs have >>> security issues >>> =A0 =A0 =A0(like blocking usage of TLS), are error prone and >>> brittle, and hinder >>> =A0 =A0 =A0application development, the usage of ALGs in the >>> defined translators >>> =A0 =A0 =A0should be avoided. Instead application developers will >>> need to be aware >>> =A0 =A0 =A0and use mechanisms that handle the address family >>> translation. ALGs may >>> =A0 =A0 =A0be considered only for the most crucial of legacy applicatio= ns. >>> >>> =A0 =A0 =A0DNS is a crucial part in making a large number of >>> applications work >>> =A0 =A0 =A0across a translator. Thus the solution to the above >>> translation cases >>> =A0 =A0 =A0shall include recommendations for DNS. If additional >>> DNS functionality >>> =A0 =A0 =A0is needed, it may be developed. Any DNS extensions must >>> be developed >>> =A0 =A0 =A0together with the DNSEXT WG, including issuing a joint >>> WG last call for >>> =A0 =A0 =A0any documents. >>> >>> =A0 =A0 =A0The WG needs to determine the best method for providing >>> address space >>> =A0 =A0 =A0to a translator in the different deployment cases and >>> documenting the >>> =A0 =A0 =A0pros and cons of the suggested approaches. The WG is to >>> seek input from >>> =A0 =A0 =A0the Routing, Operations and Internet areas. >>> >>> =A0 =A0 =A0Solutions may solve more than one of the cases, however >>> timely delivery >>> =A0 =A0 =A0is more important than a unified solution. >>> >>> =A0 =A0 =A0Goals and Milestones: >>> >>> =A0 =A0 =A0Done =A0 =A0 =A0Submit BCP that defines unicast UDP >>> behavioral requirements >>> =A0 =A0 =A0for NATs to IESG >>> =A0 =A0 =A0Done =A0 =A0 =A0Submit a BCP that defines TCP behavioral >>> requireents for NATs >>> =A0 =A0 =A0to IESG >>> =A0 =A0 =A0Done =A0 =A0 =A0Submit a BCP that defines ICMP behavioral >>> requirements for >>> =A0 =A0 =A0NATs to IESG >>> =A0 =A0 =A0Done =A0 =A0 =A0Submit informational that discusses current >>> NAT traversal >>> =A0 =A0 =A0techniques used by applications >>> =A0 =A0 =A0Done =A0 =A0 =A0Submit BCP that defines multicast UDP >>> =A0 =A0 =A0Done =A0 =A0 =A0Submit revision of RFC 3489 to IESG >>> behavioral requirements for >>> =A0 =A0 =A0NATs to IESG >>> =A0 =A0 =A0Done =A0 =A0 =A0Submit informational document for rfc3489bis >>> test vectors >>> =A0 =A0 =A0Done =A0 =A0 =A0Submit experimental document that describes >>> how an application >>> =A0 =A0 =A0can determine the type of NAT it is behind >>> =A0 =A0 =A0Done =A0 =A0 =A0Submit BCP document for DCCP NAT behavior >>> =A0 =A0 =A0Dec 2009 =A0Submit to IESG: SCTP NAT behavior (BCP) >>> =A0 =A0 =A0Done =A0 =A0 =A0Submit to IESG: relay protocol (std) >>> =A0 =A0 =A0Done =A0 =A0 =A0Determine relative prioritization of the fou= r >>> translation >>> =A0 =A0 =A0cases. Documented in IETF74 minutes. >>> =A0 =A0 =A0Sep 2009 =A0Submit to IESG: relaying of a TCP bytestream (st= d) >>> =A0 =A0 =A0Dec 2009 =A0Submit to IESG: IPv6 relay protocol (std) >>> =A0 =A0 =A0Done =A0 =A0 =A0Determine what solutions(s) and components >>> are needed to solve >>> =A0 =A0 =A0each of the four cases. Create new milestones for the >>> solution(s) and >>> =A0 =A0 =A0the components. Documented in IETF74 minutes. >>> =A0 =A0 =A0Done =A0 =A0 =A0Submit to IESG: =A0TURN-URI document (std) >>> =A0 =A0 =A0Dec 2009 =A0Submit to IESG: =A0framework for IPv6/IPv4 >>> translation (info) >>> =A0 =A0 =A0Dec 2009 =A0Submit to IESG: =A0stateless IPv6/IPv4 translati= on (std) >>> =A0 =A0 =A0Dec 2009 =A0Submit to IESG: =A0stateful IPv6/IPv4 translatio= n (std) >>> =A0 =A0 =A0Dec 2009 =A0Submit to IESG: =A0DNS rewriting for IPv6/IPv4 >>> translation (std) >>> =A0 =A0 =A0Jan 2010 =A0Submit to IESG: =A0FTP ALG for IPv6/IPv4 >>> translation (std) >>> =A0 =A0 =A0Jan 2010 =A0Submit to IESG: =A0IPv6 prefix for IPv6/IPv4 >>> translator (std) >>> =A0 =A0 =A0Mar 2010 =A0Submit to IESG: =A0large scale NAT requirements = (BCP) >>> =A0 =A0 =A0_______________________________________________ >>> =A0 =A0 =A0Behave mailing list >>> =A0 =A0 =A0Behave@ietf.org >>> =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/behave >>> >>> >>> >>> >>> >>> -- >>> Regards, >>> >>> Bo Zhou >>> China Mobile >>> >>> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > > > -- > > Magnus Westerlund > > IETF Transport Area Director > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 > F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From dwing@cisco.com Mon Oct 12 18:54:25 2009 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 9C7A928C2D6; Mon, 12 Oct 2009 18:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.37 X-Spam-Level: X-Spam-Status: No, score=-5.37 tagged_above=-999 required=5 tests=[AWL=0.629, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZ+qXxLnpHNz; Mon, 12 Oct 2009 18:54:24 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0794128C14C; Mon, 12 Oct 2009 18:54:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=15506; q=dns/txt; s=sjiport06001; t=1255398865; x=1256608465; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Dan=20Wing"=20<dwing@cisco.com>|Subject:=20RE: =20[BEHAVE]=20WG=20Review:=20Recharter=20of=20Behavior=20 Engineering=20for=09Hindrance=20Avoidance=20(behave) |Date:=20Mon,=2012=20Oct=202009=2018:54:19=20-0700 |Message-ID:=20<08f601ca4ba8$145f76b0$a8f746ab@cisco.com> |To:=20"'Magnus=20Westerlund'"=20<magnus.westerlund@erics son.com>|Cc:=20"'bo=20zhou'"=20<zhouboyj@gmail.com>,=20"' Dave=20Thaler'"=20<dthaler@microsoft.com>,=0D=0A=20=20=20 =20=20=20=20=20<behave@ietf.org>,=20<iesg@ietf.org> |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20<4AD31720.3010004@ericsson.com> |References:=20<20090929163001.CBD933A6942@core3.amsl.com >=09<36a593230910070907p6b6f4be9xf4c344d055587cbf@mail.gm ail.com>=20<0a9101ca4775$9fa951a0$c2f0200a@cisco.com>=20< 4AD31720.3010004@ericsson.com>; bh=+2nGT1bZ54z1wldpe85pdwBrHYujkn7h+Z+4+37QS/s=; b=IElGAXlApQ6uO+dGxnhby3gPbc0GbJWrXiVDN4aLBzvJGv8el9/oFKfC RxsuAgo86KRqho9jEggEIgYLyb7ffsvBiVZUQl0DCw3hoz5y0vN+HC0FN owTjBLdUxH7W5LapMptn+uq/wMYFKRIejSHu8dsnuUX501zHMjWmu0GNg Y=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAEp700qrR7Hu/2dsb2JhbACKXrRZl0UCgjWBdgSBWA X-IronPort-AV: E=Sophos;i="4.44,548,1249257600"; d="scan'208";a="407841305" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 13 Oct 2009 01:54:20 +0000 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9D1sJBj021679; Tue, 13 Oct 2009 01:54:19 GMT From: "Dan Wing" <dwing@cisco.com> To: "'Magnus Westerlund'" <magnus.westerlund@ericsson.com> References: <20090929163001.CBD933A6942@core3.amsl.com> <36a593230910070907p6b6f4be9xf4c344d055587cbf@mail.gmail.com> <0a9101ca4775$9fa951a0$c2f0200a@cisco.com> <4AD31720.3010004@ericsson.com> Date: Mon, 12 Oct 2009 18:54:19 -0700 Message-ID: <08f601ca4ba8$145f76b0$a8f746ab@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpLMbB9FhYJmQouRciChDiohBO9vwAdhntA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4AD31720.3010004@ericsson.com> Cc: 'bo zhou' <zhouboyj@gmail.com>, behave@ietf.org, iesg@ietf.org, 'Dave Thaler' <dthaler@microsoft.com> Subject: Re: [BEHAVE] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) 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, 13 Oct 2009 01:54:25 -0000 =20 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: Monday, October 12, 2009 4:47 AM > To: Dan Wing > Cc: 'bo zhou'; 'Dave Thaler'; behave@ietf.org; iesg@ietf.org > Subject: Re: [BEHAVE] WG Review: Recharter of Behavior=20 > Engineering for Hindrance Avoidance (behave) >=20 > Hi, >=20 > I just want to indicate that this was not my interpretation of the > charter. Case 5 and 6 was to my knowledge added to handle the=20 > cases when > two different businesses or different parts of the same organization > want to connect their networks together and need translation, rather > than going through the Internet. >=20 > When it comes to host based translation, I think we would need more > discussion about the motivation for that use case are. As I understand > it it is a case of handling IPv4 only legacy applications=20 > when you have > updated the operating system and uses an IPv6 only network. I=20 > don't see > any reason for doing it for IPv6 only applications as they should be > capable of handling IPv4 connectivity. And if an application really > needs IPv6 to function there exist tunneling solutions that would be a > better gap-filler than a translation based solution. >=20 > So for host based solutions I think we haven't had a conclusive > discussion about either what the requirements and motivations=20 > are or if > there is consensus to take that on. I agree we do not have consensus to adopt host-based translation. But 6/4 translation is a function which could be done in a host or=20 in a network device; I didn't intend any more meaning with my=20 response. -d > Regards >=20 > Magnus Westerlund >=20 >=20 > Dan Wing skrev: > > =20 > >=20 > >> -----Original Message----- > >> From: bo zhou [mailto:zhouboyj@gmail.com]=20 > >> Sent: Wednesday, October 07, 2009 9:08 AM > >> To: Dave Thaler; Dan Wing > >> Cc: ietf-announce@ietf.org; behave@ietf.org; iesg@ietf.org > >> Subject: Re: [BEHAVE] WG Review: Recharter of Behavior=20 > >> Engineering for Hindrance Avoidance (behave) > >> > >> Hi Dave and Dan, > >> =20 > >> I just found the charter of the Behave has been modified. > >> =20 > >> "5. An IPv6 network to an IPv4 network, i.e., perform=20 > >> translation between > >> IPv6 and IPv4 for packets in uni- or bi-directional flows that are > >> initiated from an IPv6 host towards an IPv4 host. The translation > >> function is intended to service a specific IPv6 network of=20 > arbitrary > >> size and a specific IPv4 network of arbitrary size (neither=20 > >> of which are > >> the Internet)." > >> =20 > >> Does this cover host based translator solutions for 6 to 4? > >=20 > > Yes, the "specific IPv6 network of arbitrary size" is a=20 > network containing 1 > > host. > >=20 > > -d > >=20 > >=20 > >> Regards, > >> =20 > >> Bo Zhou > >> > >> > >> On Wed, Sep 30, 2009 at 12:30 AM, IESG Secretary=20 > >> <iesg-secretary@ietf.org> wrote: > >> > >> > >> A modified charter has been submitted for the Behavior=20 > >> Engineering for > >> Hindrance Avoidance (behave) working group in the=20 > >> Transport Area of the > >> IETF. The IESG has not made any determination as yet. =20 > >> The modified > >> charter is provided below for informational purposes=20 > >> only. Please send > >> your comments to the IESG mailing list (iesg@ietf.org)=20 > >> by Tuesday, October > >> 6, 2009. > >> =09 > >> Behavior Engineering for Hindrance Avoidance (behave) > >> ----------------------------------------------------- > >> Current Status: Active Working Group > >> Last Modified: 2009-09-09 > >> =09 > >> Current Status: Active Working Group > >> =09 > >> Additional information is available at tools.ietf.org/wg/behave > >> Chair(s): > >> =09 > >> * Dan Wing <dwing@cisco.com> > >> * Dave Thaler <dthaler@microsoft.com> > >> =09 > >> Transport Area Director(s): > >> =09 > >> * Magnus Westerlund <magnus.westerlund@ericsson.com> > >> * Lars Eggert <lars.eggert@nokia.com> > >> =09 > >> Transport Area Advisor: > >> =09 > >> * Magnus Westerlund <magnus.westerlund@ericsson.com> > >> =09 > >> Mailing Lists: > >> General Discussion: behave@ietf.org > >> To Subscribe: behave-request@ietf.org > >> In Body: In Body: subscribe > >> Archive: http://www.ietf.org/mail-archive/web/behave > >> =09 > >> Description of Working Group: > >> =09 > >> The behavior of NATs varies from one implementation to=20 > >> another. As a > >> result it is very difficult for applications to predict=20 > >> or discover the > >> behavior of these devices. Predicting and/or=20 > >> discovering the behavior > >> of NATs is important for designing application protocols and NAT > >> traversal techniques that work reliably in existing=20 > >> networks. This > >> situation is especially problematic for end-to-end=20 > >> applications where > >> one or both end-points are behind a NAT, such as=20 > >> multiuser games, > >> interactive multimedia and P2P download. > >> =09 > >> The working group documents best current practices to=20 > >> enable NATs to > >> function in as deterministic a fashion as possible. The=20 > >> NAT behavior > >> practices will be application independent. This has=20 > >> already completed > >> for UDP, TCP, DCCP, Multicast and ICMP. It continues=20 > >> with SCTP and any > >> additional protocol deemed necessary to handle. The WG=20 > >> has documented > >> approaches for characterizing and testing NAT devices. > >> =09 > >> BEHAVE will develop protocol-independent toolkits=20 > >> usable by application > >> protocols for NAT traversal. The WG has already=20 > >> produced an update of > >> the binding discovery protocol STUN. It will now produce a relay > >> protocol that focuses on security and is usable with=20 > >> both IPv4 and > >> IPv6, and capable of relaying between the two IP versions. > >> =09 > >> Due to the WG's experience with translators and their=20 > >> behavior it has > >> been given the following tasks to help encourage=20 > >> migration to IPv6. To > >> support deployments where communicating hosts require=20 > >> using different > >> address families (IPv4 or IPv6), address family translation is > >> needed to establish communication. In BEHAVE's=20 > >> specification work on > >> this topic it will coordinate with the V6ops WG on=20 > >> requirements and > >> operational considerations. > >> =09 > >> "An IPv4 network" or "an IPv6 network" in the=20 > >> descriptions below refer > >> to a network with a clearly identifiable administrative=20 > >> domain (e.g., > >> an enterprise campus network, a mobile operator's=20 > >> cellular network, a > >> residential subscriber network, etc.). It will also be=20 > >> that network > >> that deploys the necessary equipment for translation. > >> =09 > >> The BEHAVE WG will design solutions for the following=20 > >> six translation > >> scenarios; other scenarios are out of scope: > >> =09 > >> 1. An IPv6 network to IPv4 Internet, i.e. perform=20 > >> translation between > >> IPv4 and IPv6 for packets in uni- or bi-directional=20 > >> flows that are > >> initiated from an IPv6 host towards an IPv4 host. The translator > >> function is intended to service a specific IPv6 network=20 > >> of arbitary > >> size. Port translation is necessary on the IPv4 side=20 > >> for efficient IPv4 > >> address usage. > >> =09 > >> 2. IPv6 Internet to an IPv4 network, i.e. perform=20 > >> translation between > >> IPv4 and IPv6 for packets in uni- or bi-directional=20 > >> flows that are > >> initiated from an IPv6 host towards an IPv4 host. The translator > >> function is intended to service a specific IPv4 network=20 > >> using either > >> private or public IPv4 addresses. This scenario has different > >> constraints compared to (1), e.g. the IPv4 hosts that are to be > >> reachable over IPv6 can be enumerated. Therefore, the=20 > >> WG should attempt > >> to design a simpler solution with less impact on applications. > >> =09 > >> 3. An IPv4 network to IPv6 Internet, i.e. perform=20 > >> translation between > >> IPv4 and IPv6 for packets in uni- or bi-directional=20 > >> flows that are > >> initiated from an IPv4 host towards an IPv6 host. The translator > >> function is intended to service a specific IPv4 network=20 > >> using either > >> public or private IPv4 address space. > >> =09 > >> 4. IPv4 Internet to an IPv6 network, i.e. perform=20 > >> translation between > >> IPv4 and IPv6 for packets in uni- or bi-directional=20 > >> flows that are > >> initiated from an IPv4 host towards an IPv6 host. The translator > >> function is intended to service a specific IPv6 network=20 > >> where selected > >> IPv6 hosts and services are to be reachable. > >> =09 > >> 5. An IPv6 network to an IPv4 network, i.e., perform=20 > >> translation between > >> IPv6 and IPv4 for packets in uni- or bi-directional=20 > >> flows that are > >> initiated from an IPv6 host towards an IPv4 host. The=20 > >> translation > >> function is intended to service a specific IPv6 network=20 > >> of arbitrary > >> size and a specific IPv4 network of arbitrary size=20 > >> (neither of which are > >> the Internet). > >> =09 > >> 6. An IPv4 network to an IPv6 network, i.e., perform=20 > >> translation between > >> IPv4 and IPv6 for packets in uni- or bi-directional=20 > >> flows that are > >> initiated from an IPv4 host towards an IPv6 host. The=20 > >> translation > >> function is intended to service a specific IPv6 network=20 > >> of arbitrary > >> size and a specific IPv4 network of arbitrary size=20 > >> (neither of which are > >> the Internet). > >> =09 > >> All translation solutions shall be capable of handling=20 > >> flows using TCP, > >> UDP, DCCP, and SCTP, unless they prevent a timely=20 > >> completion of the > >> work item. The parts of ICMP that can be translated are=20 > >> also required > >> to work across a translation solution. Additional=20 > >> protocols directly > >> on top of IP may be supported. Translation mechanisms=20 > >> must handle IP > >> fragmentation. > >> =09 > >> The translators should support multicast traffic and its control > >> traffic (IGMP and MLD) across them, both Single Source=20 > >> Multicast (SSM) > >> and Any Source Multicast (ASM). However, the WG may=20 > >> determine that it > >> becomes too complex or too difficult to realize with maintained > >> functionality, for some or all cases of multicast functionality. > >> =09 > >> Translation mechanisms cannot transparently support=20 > >> protocols that > >> embed network addresses within their protocol messages without > >> application level gateways (ALGs). Because ALGs have=20 > >> security issues > >> (like blocking usage of TLS), are error prone and=20 > >> brittle, and hinder > >> application development, the usage of ALGs in the=20 > >> defined translators > >> should be avoided. Instead application developers will=20 > >> need to be aware > >> and use mechanisms that handle the address family=20 > >> translation. ALGs may > >> be considered only for the most crucial of legacy applications. > >> =09 > >> DNS is a crucial part in making a large number of=20 > >> applications work > >> across a translator. Thus the solution to the above=20 > >> translation cases > >> shall include recommendations for DNS. If additional=20 > >> DNS functionality > >> is needed, it may be developed. Any DNS extensions must=20 > >> be developed > >> together with the DNSEXT WG, including issuing a joint=20 > >> WG last call for > >> any documents. > >> =09 > >> The WG needs to determine the best method for providing=20 > >> address space > >> to a translator in the different deployment cases and=20 > >> documenting the > >> pros and cons of the suggested approaches. The WG is to=20 > >> seek input from > >> the Routing, Operations and Internet areas. > >> =09 > >> Solutions may solve more than one of the cases, however=20 > >> timely delivery > >> is more important than a unified solution. > >> =09 > >> Goals and Milestones: > >> =09 > >> Done Submit BCP that defines unicast UDP=20 > >> behavioral requirements > >> for NATs to IESG > >> Done Submit a BCP that defines TCP behavioral=20 > >> requireents for NATs > >> to IESG > >> Done Submit a BCP that defines ICMP behavioral=20 > >> requirements for > >> NATs to IESG > >> Done Submit informational that discusses current=20 > >> NAT traversal > >> techniques used by applications > >> Done Submit BCP that defines multicast UDP > >> Done Submit revision of RFC 3489 to IESG=20 > >> behavioral requirements for > >> NATs to IESG > >> Done Submit informational document for rfc3489bis=20 > >> test vectors > >> Done Submit experimental document that describes=20 > >> how an application > >> can determine the type of NAT it is behind > >> Done Submit BCP document for DCCP NAT behavior > >> Dec 2009 Submit to IESG: SCTP NAT behavior (BCP) > >> Done Submit to IESG: relay protocol (std) > >> Done Determine relative prioritization of the four=20 > >> translation > >> cases. Documented in IETF74 minutes. > >> Sep 2009 Submit to IESG: relaying of a TCP bytestream (std) > >> Dec 2009 Submit to IESG: IPv6 relay protocol (std) > >> Done Determine what solutions(s) and components=20 > >> are needed to solve > >> each of the four cases. Create new milestones for the=20 > >> solution(s) and > >> the components. Documented in IETF74 minutes. > >> Done Submit to IESG: TURN-URI document (std) > >> Dec 2009 Submit to IESG: framework for IPv6/IPv4=20 > >> translation (info) > >> Dec 2009 Submit to IESG: stateless IPv6/IPv4 translation (std) > >> Dec 2009 Submit to IESG: stateful IPv6/IPv4 translation (std) > >> Dec 2009 Submit to IESG: DNS rewriting for IPv6/IPv4=20 > >> translation (std) > >> Jan 2010 Submit to IESG: FTP ALG for IPv6/IPv4=20 > >> translation (std) > >> Jan 2010 Submit to IESG: IPv6 prefix for IPv6/IPv4=20 > >> translator (std) > >> Mar 2010 Submit to IESG: large scale NAT requirements (BCP) > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www.ietf.org/mailman/listinfo/behave > >> =09 > >> > >> > >> > >> > >> --=20 > >> Regards, > >> > >> Bo Zhou > >> China Mobile > >> > >> > >=20 > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > >=20 >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > IETF Transport Area Director > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > -------------------------------------------------------------- > -------- From caozhenpku@gmail.com Mon Oct 12 20:15:56 2009 Return-Path: <caozhenpku@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 4D64A3A6903; Mon, 12 Oct 2009 20:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z94ddfKE+8qs; Mon, 12 Oct 2009 20:15:54 -0700 (PDT) Received: from mail-px0-f204.google.com (mail-px0-f204.google.com [209.85.216.204]) by core3.amsl.com (Postfix) with ESMTP id 65AF63A6840; Mon, 12 Oct 2009 20:15:54 -0700 (PDT) Received: by pxi42 with SMTP id 42so9085441pxi.5 for <multiple recipients>; Mon, 12 Oct 2009 20:15:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hQMENGadxWr0gRo47y8n5UbePaf/ZJRo/qznDpzImYM=; b=Zn3yDpUW0qfTWvH6ENTFaC52S3UOrnUFo8112fow8DqEP9/maeUYToRpf/JQFZGbTk ZzrGraQTAiyrUQtg9xq46l85lUSHCxxalKWyf/sto5HRncqACrk+TudnTRa7h4kuM3J/ XyzlZDVQRrlp02TH/JsVoRDJSMXb9tyfnorX8= 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=va6nG9k0iY2FRsaOxNn+NWaAFic06tk80CDI79MXsmupaeQLek5l6hc7nw3ZTTHgf2 sbDpSZORclbhOXY7f8mHMx5S2XGW8IIYGcjavYHoxGWnIL2Tq0ybcaQg0888TWl6ATgC S4xDtXNWClmBAGXSKGJXzaLvRuLajVDknyab8= MIME-Version: 1.0 Received: by 10.142.5.31 with SMTP id 31mr502054wfe.78.1255403751257; Mon, 12 Oct 2009 20:15:51 -0700 (PDT) In-Reply-To: <bcff0fba0910120854w74fd3bc0n9a3a4cb71e2db398@mail.gmail.com> References: <20090929163001.CBD933A6942@core3.amsl.com> <36a593230910070907p6b6f4be9xf4c344d055587cbf@mail.gmail.com> <0a9101ca4775$9fa951a0$c2f0200a@cisco.com> <4AD31720.3010004@ericsson.com> <bcff0fba0910120854w74fd3bc0n9a3a4cb71e2db398@mail.gmail.com> Date: Tue, 13 Oct 2009 11:15:51 +0800 Message-ID: <a7c8d0a30910122015w551b2564i436c168e2b29a6d7@mail.gmail.com> From: Zhen Cao <caozhenpku@gmail.com> To: Cameron Byrne <cb.list6@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org, Dave Thaler <dthaler@microsoft.com>, bo zhou <zhouboyj@gmail.com>, iesg@ietf.org, Dan Wing <dwing@cisco.com> Subject: Re: [BEHAVE] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) 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, 13 Oct 2009 03:15:56 -0000 On Mon, Oct 12, 2009 at 11:54 PM, Cameron Byrne <cb.list6@gmail.com> wrote: > On Mon, Oct 12, 2009 at 4:46 AM, Magnus Westerlund > <magnus.westerlund@ericsson.com> wrote: >> Hi, >> >> I just want to indicate that this was not my interpretation of the >> charter. Case 5 and 6 was to my knowledge added to handle the cases when >> two different businesses or different parts of the same organization >> want to connect their networks together and need translation, rather >> than going through the Internet. >> >> When it comes to host based translation, I think we would need more >> discussion about the motivation for that use case are. As I understand >> it it is a case of handling IPv4 only legacy applications when you have >> updated the operating system and uses an IPv6 only network. I don't see >> any reason for doing it for IPv6 only applications as they should be >> capable of handling IPv4 connectivity. And if an application really >> needs IPv6 to function there exist tunneling solutions that would be a >> better gap-filler than a translation based solution. >> >> So for host based solutions I think we haven't had a conclusive >> discussion about either what the requirements and motivations are or if >> there is consensus to take that on. > > Agreed. =A0I really struggle to understand the need for host based > solutions. =A0The host based solutions are essentially a greenfield > build since it requires the host to ultimately be IPv6 and have the > PNAT software extensions. Host based solutions are not greenfield considering BIS and BIA solutions presence. > It seems wiser to me, if you assume a new > host software is required, to go straight IPv6 with DNS64 / NAT64 as Going to IPv6 is not straightforward, at least we need to update all applications we are using. Comparatively, users can just install one software while using host based solution. > an interworking technology that has a known exit strategy (reaching > the goal of IPv6 end-to-end) and has incentives for both the network > operator and the content owners to move towards end-to-end IPv6. =A0For > network operators, less NAT state is less cost so they want native > IPv6 ASAP. =A0For content owners and application developers, they want > to ensure their content is delivered inline with the end-to-end > principles to give the user the best experience. =A0In this way, NAT64 / > DNS64 allows me to keep growing my network with a steady-state service > model (NAT44 -- it is common in mobile today, and CGN will make it > common in fixed line) and provides rewards to content owners and > network operators to solve the chicken and egg problem that is IPv6 > adoptions. > > Much of the calls for host based NAT are fueled by fear of legacy IPv4 > applications, but my users mostly use common protocols for Web and > Email that works well natively in IPv6 and through translators. A very > small portion of my users use applications that have no path to IPv6 > native or NAT64, and they can be kept as IPv4 in the medium term. =A0I > cannot architect my future network based on 1% of users and their > legacy needs. > > The only clear reason i can see to do host based IPv6 to IPv4 > interworking is if the economics are such that transferring the > complexity of the translation from the network to the host is in > someway advantageous. =A0In my world of North American mobile wireless, Not necessarily the only reason. First, Host based translation does not resist network translation. Second, IETF has multiple solutions to do IPv6 transition, it is hard to evaluate them from economic reasons. > the service provider subsidizes the handset and therefore as the > service provider we have a large amount of control over which handsets > are used and we are responsible for supporting those handsets. =A0And, > we have a large degree of ownership of the architecture and complexity > in the network (which includes the devices attached to the network). > It behooves us to choose solutions that are end-to-end less complex > and easier to support in the long run, not simply transferring the > complexity to the handset vendors. =A0That said, network operators can > deploy what makes sense for their unique economic and technology > context, and IMHO NAT64 / DNS64 in the network is the best strategic > option, it has the right incentives towards end to end IPv6, and it is > only an incremental change to the NAT44 world of today. =A0Host based > solutions, IMHO, =A0are not being considered seriously in North America > or Europe. Do you have enough experience to say that for sure? Thanks for discussion. Regards > > Cameron Byrne > Principal Engineer > T-Mobile USA. > >> >> Regards >> >> Magnus Westerlund >> >> >> Dan Wing skrev: >>> >>> >>>> -----Original Message----- >>>> From: bo zhou [mailto:zhouboyj@gmail.com] >>>> Sent: Wednesday, October 07, 2009 9:08 AM >>>> To: Dave Thaler; Dan Wing >>>> Cc: ietf-announce@ietf.org; behave@ietf.org; iesg@ietf.org >>>> Subject: Re: [BEHAVE] WG Review: Recharter of Behavior >>>> Engineering for Hindrance Avoidance (behave) >>>> >>>> Hi Dave and Dan, >>>> >>>> I just found the charter of the Behave has been modified. >>>> >>>> "5. An IPv6 network to an IPv4 network, i.e., perform >>>> translation between >>>> IPv6 and IPv4 for packets in uni- or bi-directional flows that are >>>> initiated from an IPv6 host towards an IPv4 host. =A0The translation >>>> function is intended to service a specific IPv6 network of arbitrary >>>> size and a specific IPv4 network of arbitrary size (neither >>>> of which are >>>> the Internet)." >>>> >>>> Does this cover host based translator solutions for 6 to 4? >>> >>> Yes, the "specific IPv6 network of arbitrary size" is a network contain= ing 1 >>> host. >>> >>> -d >>> >>> >>>> Regards, >>>> >>>> Bo Zhou >>>> >>>> >>>> On Wed, Sep 30, 2009 at 12:30 AM, IESG Secretary >>>> <iesg-secretary@ietf.org> wrote: >>>> >>>> >>>> =A0 =A0 =A0A modified charter has been submitted for the Behavior >>>> Engineering for >>>> =A0 =A0 =A0Hindrance Avoidance (behave) working group in the >>>> Transport Area of the >>>> =A0 =A0 =A0IETF. =A0The IESG has not made any determination as yet. >>>> The modified >>>> =A0 =A0 =A0charter is provided below for informational purposes >>>> only. =A0Please send >>>> =A0 =A0 =A0your comments to the IESG mailing list (iesg@ietf.org) >>>> by Tuesday, October >>>> =A0 =A0 =A06, 2009. >>>> >>>> =A0 =A0 =A0Behavior Engineering for Hindrance Avoidance (behave) >>>> =A0 =A0 =A0----------------------------------------------------- >>>> =A0 =A0 =A0Current Status: Active Working Group >>>> =A0 =A0 =A0Last Modified: 2009-09-09 >>>> >>>> =A0 =A0 =A0Current Status: Active Working Group >>>> >>>> =A0 =A0 =A0Additional information is available at tools.ietf.org/wg/be= have >>>> =A0 =A0 =A0Chair(s): >>>> >>>> =A0 =A0 =A0 =A0 * Dan Wing <dwing@cisco.com> >>>> =A0 =A0 =A0 =A0 * Dave Thaler <dthaler@microsoft.com> >>>> >>>> =A0 =A0 =A0Transport Area Director(s): >>>> >>>> =A0 =A0 =A0 =A0 * Magnus Westerlund <magnus.westerlund@ericsson.com> >>>> =A0 =A0 =A0 =A0 * Lars Eggert <lars.eggert@nokia.com> >>>> >>>> =A0 =A0 =A0Transport Area Advisor: >>>> >>>> =A0 =A0 =A0 =A0 * Magnus Westerlund <magnus.westerlund@ericsson.com> >>>> >>>> =A0 =A0 =A0Mailing Lists: >>>> =A0 =A0 =A0 General Discussion: behave@ietf.org >>>> =A0 =A0 =A0 To Subscribe: behave-request@ietf.org >>>> =A0 =A0 =A0 In Body: In Body: subscribe >>>> =A0 =A0 =A0 Archive: http://www.ietf.org/mail-archive/web/behave >>>> >>>> =A0 =A0 =A0Description of Working Group: >>>> >>>> =A0 =A0 =A0The behavior of NATs varies from one implementation to >>>> another. As a >>>> =A0 =A0 =A0result it is very difficult for applications to predict >>>> or discover the >>>> =A0 =A0 =A0behavior of these devices. Predicting and/or >>>> discovering the behavior >>>> =A0 =A0 =A0of NATs is important for designing application protocols an= d NAT >>>> =A0 =A0 =A0traversal techniques that work reliably in existing >>>> networks. This >>>> =A0 =A0 =A0situation is especially problematic for end-to-end >>>> applications where >>>> =A0 =A0 =A0one or both end-points are behind a NAT, such as >>>> multiuser games, >>>> =A0 =A0 =A0interactive multimedia and P2P download. >>>> >>>> =A0 =A0 =A0The working group documents best current practices to >>>> enable NATs to >>>> =A0 =A0 =A0function in as deterministic a fashion as possible. The >>>> NAT behavior >>>> =A0 =A0 =A0practices will be application independent. This has >>>> already completed >>>> =A0 =A0 =A0for UDP, TCP, DCCP, Multicast and ICMP. It continues >>>> with SCTP and any >>>> =A0 =A0 =A0additional protocol deemed necessary to handle. The WG >>>> has documented >>>> =A0 =A0 =A0approaches for characterizing and testing NAT devices. >>>> >>>> =A0 =A0 =A0BEHAVE will develop protocol-independent toolkits >>>> usable by application >>>> =A0 =A0 =A0protocols for NAT traversal. The WG has already >>>> produced an update of >>>> =A0 =A0 =A0the binding discovery protocol STUN. It will now produce a = relay >>>> =A0 =A0 =A0protocol that focuses on security and is usable with >>>> both IPv4 and >>>> =A0 =A0 =A0IPv6, and capable of relaying between the two IP versions. >>>> >>>> =A0 =A0 =A0Due to the WG's experience with translators and their >>>> behavior it has >>>> =A0 =A0 =A0been given the following tasks to help encourage >>>> migration to IPv6. To >>>> =A0 =A0 =A0support deployments where communicating hosts require >>>> using different >>>> =A0 =A0 =A0address families (IPv4 or IPv6), address family translation= is >>>> =A0 =A0 =A0needed to establish communication. In BEHAVE's >>>> specification work on >>>> =A0 =A0 =A0this topic it will coordinate with the V6ops WG on >>>> requirements and >>>> =A0 =A0 =A0operational considerations. >>>> >>>> =A0 =A0 =A0"An IPv4 network" or "an IPv6 network" in the >>>> descriptions below refer >>>> =A0 =A0 =A0to a network with a clearly identifiable administrative >>>> domain (e.g., >>>> =A0 =A0 =A0an enterprise campus network, a mobile operator's >>>> cellular network, a >>>> =A0 =A0 =A0residential subscriber network, etc.). It will also be >>>> that network >>>> =A0 =A0 =A0that deploys the necessary equipment for translation. >>>> >>>> =A0 =A0 =A0The BEHAVE WG will design solutions for the following >>>> six translation >>>> =A0 =A0 =A0scenarios; other scenarios are out of scope: >>>> >>>> =A0 =A0 =A01. An IPv6 network to IPv4 Internet, i.e. perform >>>> translation between >>>> =A0 =A0 =A0IPv4 and IPv6 for packets in uni- or bi-directional >>>> flows that are >>>> =A0 =A0 =A0initiated from an IPv6 host towards an IPv4 host. The trans= lator >>>> =A0 =A0 =A0function is intended to service a specific IPv6 network >>>> of arbitary >>>> =A0 =A0 =A0size. Port translation is necessary on the IPv4 side >>>> for efficient IPv4 >>>> =A0 =A0 =A0address usage. >>>> >>>> =A0 =A0 =A02. IPv6 Internet to an IPv4 network, i.e. perform >>>> translation between >>>> =A0 =A0 =A0IPv4 and IPv6 for packets in uni- or bi-directional >>>> flows that are >>>> =A0 =A0 =A0initiated from an IPv6 host towards an IPv4 host. The trans= lator >>>> =A0 =A0 =A0function is intended to service a specific IPv4 network >>>> using either >>>> =A0 =A0 =A0private or public IPv4 addresses. This scenario has differe= nt >>>> =A0 =A0 =A0constraints compared to (1), e.g. the IPv4 hosts that are t= o be >>>> =A0 =A0 =A0reachable over IPv6 can be enumerated. Therefore, the >>>> WG should attempt >>>> =A0 =A0 =A0to design a simpler solution with less impact on applicatio= ns. >>>> >>>> =A0 =A0 =A03. An IPv4 network to IPv6 Internet, i.e. perform >>>> translation between >>>> =A0 =A0 =A0IPv4 and IPv6 for packets in uni- or bi-directional >>>> flows that are >>>> =A0 =A0 =A0initiated from an IPv4 host towards an IPv6 host. The trans= lator >>>> =A0 =A0 =A0function is intended to service a specific IPv4 network >>>> using either >>>> =A0 =A0 =A0public or private IPv4 address space. >>>> >>>> =A0 =A0 =A04. IPv4 Internet to an IPv6 network, i.e. perform >>>> translation between >>>> =A0 =A0 =A0IPv4 and IPv6 for packets in uni- or bi-directional >>>> flows that are >>>> =A0 =A0 =A0initiated from an IPv4 host towards an IPv6 host. The trans= lator >>>> =A0 =A0 =A0function is intended to service a specific IPv6 network >>>> where selected >>>> =A0 =A0 =A0IPv6 hosts and services are to be reachable. >>>> >>>> =A0 =A0 =A05. An IPv6 network to an IPv4 network, i.e., perform >>>> translation between >>>> =A0 =A0 =A0IPv6 and IPv4 for packets in uni- or bi-directional >>>> flows that are >>>> =A0 =A0 =A0initiated from an IPv6 host towards an IPv4 host. =A0The >>>> translation >>>> =A0 =A0 =A0function is intended to service a specific IPv6 network >>>> of arbitrary >>>> =A0 =A0 =A0size and a specific IPv4 network of arbitrary size >>>> (neither of which are >>>> =A0 =A0 =A0the Internet). >>>> >>>> =A0 =A0 =A06. An IPv4 network to an IPv6 network, i.e., perform >>>> translation between >>>> =A0 =A0 =A0IPv4 and IPv6 for packets in uni- or bi-directional >>>> flows that are >>>> =A0 =A0 =A0initiated from an IPv4 host towards an IPv6 host. =A0The >>>> translation >>>> =A0 =A0 =A0function is intended to service a specific IPv6 network >>>> of arbitrary >>>> =A0 =A0 =A0size and a specific IPv4 network of arbitrary size >>>> (neither of which are >>>> =A0 =A0 =A0the Internet). >>>> >>>> =A0 =A0 =A0All translation solutions shall be capable of handling >>>> flows using TCP, >>>> =A0 =A0 =A0UDP, DCCP, and SCTP, unless they prevent a timely >>>> completion of the >>>> =A0 =A0 =A0work item. The parts of ICMP that can be translated are >>>> also required >>>> =A0 =A0 =A0to work across a translation solution. =A0Additional >>>> protocols directly >>>> =A0 =A0 =A0on top of IP may be supported. Translation mechanisms >>>> must handle IP >>>> =A0 =A0 =A0fragmentation. >>>> >>>> =A0 =A0 =A0The translators should support multicast traffic and its co= ntrol >>>> =A0 =A0 =A0traffic (IGMP and MLD) across them, both Single Source >>>> Multicast (SSM) >>>> =A0 =A0 =A0and Any Source Multicast (ASM). However, the WG may >>>> determine that it >>>> =A0 =A0 =A0becomes too complex or too difficult to realize with mainta= ined >>>> =A0 =A0 =A0functionality, for some or all cases of multicast functiona= lity. >>>> >>>> =A0 =A0 =A0Translation mechanisms cannot transparently support >>>> protocols that >>>> =A0 =A0 =A0embed network addresses within their protocol messages with= out >>>> =A0 =A0 =A0application level gateways (ALGs). Because ALGs have >>>> security issues >>>> =A0 =A0 =A0(like blocking usage of TLS), are error prone and >>>> brittle, and hinder >>>> =A0 =A0 =A0application development, the usage of ALGs in the >>>> defined translators >>>> =A0 =A0 =A0should be avoided. Instead application developers will >>>> need to be aware >>>> =A0 =A0 =A0and use mechanisms that handle the address family >>>> translation. ALGs may >>>> =A0 =A0 =A0be considered only for the most crucial of legacy applicati= ons. >>>> >>>> =A0 =A0 =A0DNS is a crucial part in making a large number of >>>> applications work >>>> =A0 =A0 =A0across a translator. Thus the solution to the above >>>> translation cases >>>> =A0 =A0 =A0shall include recommendations for DNS. If additional >>>> DNS functionality >>>> =A0 =A0 =A0is needed, it may be developed. Any DNS extensions must >>>> be developed >>>> =A0 =A0 =A0together with the DNSEXT WG, including issuing a joint >>>> WG last call for >>>> =A0 =A0 =A0any documents. >>>> >>>> =A0 =A0 =A0The WG needs to determine the best method for providing >>>> address space >>>> =A0 =A0 =A0to a translator in the different deployment cases and >>>> documenting the >>>> =A0 =A0 =A0pros and cons of the suggested approaches. The WG is to >>>> seek input from >>>> =A0 =A0 =A0the Routing, Operations and Internet areas. >>>> >>>> =A0 =A0 =A0Solutions may solve more than one of the cases, however >>>> timely delivery >>>> =A0 =A0 =A0is more important than a unified solution. >>>> >>>> =A0 =A0 =A0Goals and Milestones: >>>> >>>> =A0 =A0 =A0Done =A0 =A0 =A0Submit BCP that defines unicast UDP >>>> behavioral requirements >>>> =A0 =A0 =A0for NATs to IESG >>>> =A0 =A0 =A0Done =A0 =A0 =A0Submit a BCP that defines TCP behavioral >>>> requireents for NATs >>>> =A0 =A0 =A0to IESG >>>> =A0 =A0 =A0Done =A0 =A0 =A0Submit a BCP that defines ICMP behavioral >>>> requirements for >>>> =A0 =A0 =A0NATs to IESG >>>> =A0 =A0 =A0Done =A0 =A0 =A0Submit informational that discusses current >>>> NAT traversal >>>> =A0 =A0 =A0techniques used by applications >>>> =A0 =A0 =A0Done =A0 =A0 =A0Submit BCP that defines multicast UDP >>>> =A0 =A0 =A0Done =A0 =A0 =A0Submit revision of RFC 3489 to IESG >>>> behavioral requirements for >>>> =A0 =A0 =A0NATs to IESG >>>> =A0 =A0 =A0Done =A0 =A0 =A0Submit informational document for rfc3489bi= s >>>> test vectors >>>> =A0 =A0 =A0Done =A0 =A0 =A0Submit experimental document that describes >>>> how an application >>>> =A0 =A0 =A0can determine the type of NAT it is behind >>>> =A0 =A0 =A0Done =A0 =A0 =A0Submit BCP document for DCCP NAT behavior >>>> =A0 =A0 =A0Dec 2009 =A0Submit to IESG: SCTP NAT behavior (BCP) >>>> =A0 =A0 =A0Done =A0 =A0 =A0Submit to IESG: relay protocol (std) >>>> =A0 =A0 =A0Done =A0 =A0 =A0Determine relative prioritization of the fo= ur >>>> translation >>>> =A0 =A0 =A0cases. Documented in IETF74 minutes. >>>> =A0 =A0 =A0Sep 2009 =A0Submit to IESG: relaying of a TCP bytestream (s= td) >>>> =A0 =A0 =A0Dec 2009 =A0Submit to IESG: IPv6 relay protocol (std) >>>> =A0 =A0 =A0Done =A0 =A0 =A0Determine what solutions(s) and components >>>> are needed to solve >>>> =A0 =A0 =A0each of the four cases. Create new milestones for the >>>> solution(s) and >>>> =A0 =A0 =A0the components. Documented in IETF74 minutes. >>>> =A0 =A0 =A0Done =A0 =A0 =A0Submit to IESG: =A0TURN-URI document (std) >>>> =A0 =A0 =A0Dec 2009 =A0Submit to IESG: =A0framework for IPv6/IPv4 >>>> translation (info) >>>> =A0 =A0 =A0Dec 2009 =A0Submit to IESG: =A0stateless IPv6/IPv4 translat= ion (std) >>>> =A0 =A0 =A0Dec 2009 =A0Submit to IESG: =A0stateful IPv6/IPv4 translati= on (std) >>>> =A0 =A0 =A0Dec 2009 =A0Submit to IESG: =A0DNS rewriting for IPv6/IPv4 >>>> translation (std) >>>> =A0 =A0 =A0Jan 2010 =A0Submit to IESG: =A0FTP ALG for IPv6/IPv4 >>>> translation (std) >>>> =A0 =A0 =A0Jan 2010 =A0Submit to IESG: =A0IPv6 prefix for IPv6/IPv4 >>>> translator (std) >>>> =A0 =A0 =A0Mar 2010 =A0Submit to IESG: =A0large scale NAT requirements= (BCP) >>>> =A0 =A0 =A0_______________________________________________ >>>> =A0 =A0 =A0Behave mailing list >>>> =A0 =A0 =A0Behave@ietf.org >>>> =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/behave >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Regards, >>>> >>>> Bo Zhou >>>> China Mobile >>>> >>>> >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >> >> >> -- >> >> Magnus Westerlund >> >> IETF Transport Area Director >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 >> F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From cb.list6@gmail.com Mon Oct 12 23:12:26 2009 Return-Path: <cb.list6@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 01CA63A6A3F; Mon, 12 Oct 2009 23:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JMxkybu-Yjl; Mon, 12 Oct 2009 23:12:24 -0700 (PDT) Received: from mail-pz0-f198.google.com (mail-pz0-f198.google.com [209.85.222.198]) by core3.amsl.com (Postfix) with ESMTP id E6B373A67EC; Mon, 12 Oct 2009 23:12:23 -0700 (PDT) Received: by pzk36 with SMTP id 36so6764029pzk.5 for <multiple recipients>; Mon, 12 Oct 2009 23:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lcltWp9k9MJ6qSCEKF79v+K5iwlFbl0bbS2JgkvBVtc=; b=YQeCGpOxVe8R+HRftPdG/eqvaTBKu9o9nkUydDXYtsje52ttzA1rwgjRVsTdVc9Oqi f/MxzaqMiErutFV106lHxDMw/f3VRXgiXKYB+TRshigTdjUbpw4NrAQ+PtiVUynn1v91 xa7YB6uPkrCXSAz5wRRF2wU71yXqya87cH0No= 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=RD1qWC4b+Y592XCGzCDGggoKKjMIt88SLolk0M1JsaZoSf+syy3/XMW63vBx1iNQ4I ac38F/Q/WPXetGxh7JpPDJipEMJSZ8bsJKTV1o0G4ovDWJN2ee3+9ZUPTdiehgklzwGx 7I/laKDZgxXkJoPspB/LvM1d0y0b3QUp/Qdwc= MIME-Version: 1.0 Received: by 10.142.195.18 with SMTP id s18mr24388wff.263.1255414342708; Mon, 12 Oct 2009 23:12:22 -0700 (PDT) In-Reply-To: <a7c8d0a30910122015w551b2564i436c168e2b29a6d7@mail.gmail.com> References: <20090929163001.CBD933A6942@core3.amsl.com> <36a593230910070907p6b6f4be9xf4c344d055587cbf@mail.gmail.com> <0a9101ca4775$9fa951a0$c2f0200a@cisco.com> <4AD31720.3010004@ericsson.com> <bcff0fba0910120854w74fd3bc0n9a3a4cb71e2db398@mail.gmail.com> <a7c8d0a30910122015w551b2564i436c168e2b29a6d7@mail.gmail.com> Date: Mon, 12 Oct 2009 23:12:22 -0700 Message-ID: <bcff0fba0910122312h1606a321mdfab07cc9662ed89@mail.gmail.com> From: Cameron Byrne <cb.list6@gmail.com> To: Zhen Cao <caozhenpku@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org, Dave Thaler <dthaler@microsoft.com>, bo zhou <zhouboyj@gmail.com>, iesg@ietf.org, Dan Wing <dwing@cisco.com> Subject: Re: [BEHAVE] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) 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, 13 Oct 2009 06:12:26 -0000 On Mon, Oct 12, 2009 at 8:15 PM, Zhen Cao <caozhenpku@gmail.com> wrote: > On Mon, Oct 12, 2009 at 11:54 PM, Cameron Byrne <cb.list6@gmail.com> wrot= e: >> On Mon, Oct 12, 2009 at 4:46 AM, Magnus Westerlund >> <magnus.westerlund@ericsson.com> wrote: >>> Hi, >>> >>> I just want to indicate that this was not my interpretation of the >>> charter. Case 5 and 6 was to my knowledge added to handle the cases whe= n >>> two different businesses or different parts of the same organization >>> want to connect their networks together and need translation, rather >>> than going through the Internet. >>> >>> When it comes to host based translation, I think we would need more >>> discussion about the motivation for that use case are. As I understand >>> it it is a case of handling IPv4 only legacy applications when you have >>> updated the operating system and uses an IPv6 only network. I don't see >>> any reason for doing it for IPv6 only applications as they should be >>> capable of handling IPv4 connectivity. And if an application really >>> needs IPv6 to function there exist tunneling solutions that would be a >>> better gap-filler than a translation based solution. >>> >>> So for host based solutions I think we haven't had a conclusive >>> discussion about either what the requirements and motivations are or if >>> there is consensus to take that on. >> >> Agreed. =A0I really struggle to understand the need for host based >> solutions. =A0The host based solutions are essentially a greenfield >> build since it requires the host to ultimately be IPv6 and have the >> PNAT software extensions. > Host based solutions are not greenfield considering BIS and BIA > solutions presence. In my environment, doing a software upgrade on an existing device to change the transport to achieve PNAT would be too risky to do on a large scale. Deploying anything with IPv6, for my environment, would be a slow phased approach most likely incorporated into new devices and services, not back-ported into existing devices and services. Your environment may be different. For me, any IPv6 will be greenfield. > >> It seems wiser to me, if you assume a new >> host software is required, to go straight IPv6 with DNS64 / NAT64 as > Going to IPv6 is not straightforward, at least we need to update all > applications we are using. Comparatively, users can just install one > software while using host based solution. Which applications are you concerned about updating? My users mostly use web and email, and those clients are commonly available for IPv6 users today. Which common applications are your users commonly using that cannot use IPv6? > >> an interworking technology that has a known exit strategy (reaching >> the goal of IPv6 end-to-end) and has incentives for both the network >> operator and the content owners to move towards end-to-end IPv6. =A0For >> network operators, less NAT state is less cost so they want native >> IPv6 ASAP. =A0For content owners and application developers, they want >> to ensure their content is delivered inline with the end-to-end >> principles to give the user the best experience. =A0In this way, NAT64 / >> DNS64 allows me to keep growing my network with a steady-state service >> model (NAT44 -- it is common in mobile today, and CGN will make it >> common in fixed line) and provides rewards to content owners and >> network operators to solve the chicken and egg problem that is IPv6 >> adoptions. >> >> Much of the calls for host based NAT are fueled by fear of legacy IPv4 >> applications, but my users mostly use common protocols for Web and >> Email that works well natively in IPv6 and through translators. A very >> small portion of my users use applications that have no path to IPv6 >> native or NAT64, and they can be kept as IPv4 in the medium term. =A0I >> cannot architect my future network based on 1% of users and their >> legacy needs. >> >> The only clear reason i can see to do host based IPv6 to IPv4 >> interworking is if the economics are such that transferring the >> complexity of the translation from the network to the host is in >> someway advantageous. =A0In my world of North American mobile wireless, > > Not necessarily the only reason. First, Host based translation does > not resist network translation. Second, IETF has multiple solutions to > do IPv6 transition, it is hard to evaluate them from economic reasons. Hard, but the technology strategist at services providers will generally be required to understand the options and the economics to select the right solution. > >> the service provider subsidizes the handset and therefore as the >> service provider we have a large amount of control over which handsets >> are used and we are responsible for supporting those handsets. =A0And, >> we have a large degree of ownership of the architecture and complexity >> in the network (which includes the devices attached to the network). >> It behooves us to choose solutions that are end-to-end less complex >> and easier to support in the long run, not simply transferring the >> complexity to the handset vendors. =A0That said, network operators can >> deploy what makes sense for their unique economic and technology >> context, and IMHO NAT64 / DNS64 in the network is the best strategic >> option, it has the right incentives towards end to end IPv6, and it is >> only an incremental change to the NAT44 world of today. =A0Host based >> solutions, IMHO, =A0are not being considered seriously in North America >> or Europe. > > Do you have enough experience to say that for sure? For North America, yes. I worked on this 3G Americas paper with the AT&T and Rogers, host based translation was never mentioned as an option in any of the discussion during the production of the paper. http://www.3gamericas.org/documents/2008_IPv6_transition_3GA_Mar2008.pdf Verizon has a public spec available for their LTE devices, they are IPv6 only with optional dual stack for IPv4. No requirement for host based translations. Regarding Europe, T-Mobile entities are not considering PNAT. I don't personally have experience with other European operators. But, i can only officially speak for myself. I have only seen one network operator on this list or any list support host based translation. That does not mean it will not be a standard or work well for that one operator, it just means the solution has a narrow fit. Thanks for the discussion, Cameron > > Thanks for discussion. > > Regards > >> >> Cameron Byrne >> Principal Engineer >> T-Mobile USA. >> >>> >>> Regards >>> >>> Magnus Westerlund >>> >>> >>> Dan Wing skrev: >>>> >>>> >>>>> -----Original Message----- >>>>> From: bo zhou [mailto:zhouboyj@gmail.com] >>>>> Sent: Wednesday, October 07, 2009 9:08 AM >>>>> To: Dave Thaler; Dan Wing >>>>> Cc: ietf-announce@ietf.org; behave@ietf.org; iesg@ietf.org >>>>> Subject: Re: [BEHAVE] WG Review: Recharter of Behavior >>>>> Engineering for Hindrance Avoidance (behave) >>>>> >>>>> Hi Dave and Dan, >>>>> >>>>> I just found the charter of the Behave has been modified. >>>>> >>>>> "5. An IPv6 network to an IPv4 network, i.e., perform >>>>> translation between >>>>> IPv6 and IPv4 for packets in uni- or bi-directional flows that are >>>>> initiated from an IPv6 host towards an IPv4 host. =A0The translation >>>>> function is intended to service a specific IPv6 network of arbitrary >>>>> size and a specific IPv4 network of arbitrary size (neither >>>>> of which are >>>>> the Internet)." >>>>> >>>>> Does this cover host based translator solutions for 6 to 4? >>>> >>>> Yes, the "specific IPv6 network of arbitrary size" is a network contai= ning 1 >>>> host. >>>> >>>> -d >>>> >>>> >>>>> Regards, >>>>> >>>>> Bo Zhou >>>>> >>>>> >>>>> On Wed, Sep 30, 2009 at 12:30 AM, IESG Secretary >>>>> <iesg-secretary@ietf.org> wrote: >>>>> >>>>> >>>>> =A0 =A0 =A0A modified charter has been submitted for the Behavior >>>>> Engineering for >>>>> =A0 =A0 =A0Hindrance Avoidance (behave) working group in the >>>>> Transport Area of the >>>>> =A0 =A0 =A0IETF. =A0The IESG has not made any determination as yet. >>>>> The modified >>>>> =A0 =A0 =A0charter is provided below for informational purposes >>>>> only. =A0Please send >>>>> =A0 =A0 =A0your comments to the IESG mailing list (iesg@ietf.org) >>>>> by Tuesday, October >>>>> =A0 =A0 =A06, 2009. >>>>> >>>>> =A0 =A0 =A0Behavior Engineering for Hindrance Avoidance (behave) >>>>> =A0 =A0 =A0----------------------------------------------------- >>>>> =A0 =A0 =A0Current Status: Active Working Group >>>>> =A0 =A0 =A0Last Modified: 2009-09-09 >>>>> >>>>> =A0 =A0 =A0Current Status: Active Working Group >>>>> >>>>> =A0 =A0 =A0Additional information is available at tools.ietf.org/wg/b= ehave >>>>> =A0 =A0 =A0Chair(s): >>>>> >>>>> =A0 =A0 =A0 =A0 * Dan Wing <dwing@cisco.com> >>>>> =A0 =A0 =A0 =A0 * Dave Thaler <dthaler@microsoft.com> >>>>> >>>>> =A0 =A0 =A0Transport Area Director(s): >>>>> >>>>> =A0 =A0 =A0 =A0 * Magnus Westerlund <magnus.westerlund@ericsson.com> >>>>> =A0 =A0 =A0 =A0 * Lars Eggert <lars.eggert@nokia.com> >>>>> >>>>> =A0 =A0 =A0Transport Area Advisor: >>>>> >>>>> =A0 =A0 =A0 =A0 * Magnus Westerlund <magnus.westerlund@ericsson.com> >>>>> >>>>> =A0 =A0 =A0Mailing Lists: >>>>> =A0 =A0 =A0 General Discussion: behave@ietf.org >>>>> =A0 =A0 =A0 To Subscribe: behave-request@ietf.org >>>>> =A0 =A0 =A0 In Body: In Body: subscribe >>>>> =A0 =A0 =A0 Archive: http://www.ietf.org/mail-archive/web/behave >>>>> >>>>> =A0 =A0 =A0Description of Working Group: >>>>> >>>>> =A0 =A0 =A0The behavior of NATs varies from one implementation to >>>>> another. As a >>>>> =A0 =A0 =A0result it is very difficult for applications to predict >>>>> or discover the >>>>> =A0 =A0 =A0behavior of these devices. Predicting and/or >>>>> discovering the behavior >>>>> =A0 =A0 =A0of NATs is important for designing application protocols a= nd NAT >>>>> =A0 =A0 =A0traversal techniques that work reliably in existing >>>>> networks. This >>>>> =A0 =A0 =A0situation is especially problematic for end-to-end >>>>> applications where >>>>> =A0 =A0 =A0one or both end-points are behind a NAT, such as >>>>> multiuser games, >>>>> =A0 =A0 =A0interactive multimedia and P2P download. >>>>> >>>>> =A0 =A0 =A0The working group documents best current practices to >>>>> enable NATs to >>>>> =A0 =A0 =A0function in as deterministic a fashion as possible. The >>>>> NAT behavior >>>>> =A0 =A0 =A0practices will be application independent. This has >>>>> already completed >>>>> =A0 =A0 =A0for UDP, TCP, DCCP, Multicast and ICMP. It continues >>>>> with SCTP and any >>>>> =A0 =A0 =A0additional protocol deemed necessary to handle. The WG >>>>> has documented >>>>> =A0 =A0 =A0approaches for characterizing and testing NAT devices. >>>>> >>>>> =A0 =A0 =A0BEHAVE will develop protocol-independent toolkits >>>>> usable by application >>>>> =A0 =A0 =A0protocols for NAT traversal. The WG has already >>>>> produced an update of >>>>> =A0 =A0 =A0the binding discovery protocol STUN. It will now produce a= relay >>>>> =A0 =A0 =A0protocol that focuses on security and is usable with >>>>> both IPv4 and >>>>> =A0 =A0 =A0IPv6, and capable of relaying between the two IP versions. >>>>> >>>>> =A0 =A0 =A0Due to the WG's experience with translators and their >>>>> behavior it has >>>>> =A0 =A0 =A0been given the following tasks to help encourage >>>>> migration to IPv6. To >>>>> =A0 =A0 =A0support deployments where communicating hosts require >>>>> using different >>>>> =A0 =A0 =A0address families (IPv4 or IPv6), address family translatio= n is >>>>> =A0 =A0 =A0needed to establish communication. In BEHAVE's >>>>> specification work on >>>>> =A0 =A0 =A0this topic it will coordinate with the V6ops WG on >>>>> requirements and >>>>> =A0 =A0 =A0operational considerations. >>>>> >>>>> =A0 =A0 =A0"An IPv4 network" or "an IPv6 network" in the >>>>> descriptions below refer >>>>> =A0 =A0 =A0to a network with a clearly identifiable administrative >>>>> domain (e.g., >>>>> =A0 =A0 =A0an enterprise campus network, a mobile operator's >>>>> cellular network, a >>>>> =A0 =A0 =A0residential subscriber network, etc.). It will also be >>>>> that network >>>>> =A0 =A0 =A0that deploys the necessary equipment for translation. >>>>> >>>>> =A0 =A0 =A0The BEHAVE WG will design solutions for the following >>>>> six translation >>>>> =A0 =A0 =A0scenarios; other scenarios are out of scope: >>>>> >>>>> =A0 =A0 =A01. An IPv6 network to IPv4 Internet, i.e. perform >>>>> translation between >>>>> =A0 =A0 =A0IPv4 and IPv6 for packets in uni- or bi-directional >>>>> flows that are >>>>> =A0 =A0 =A0initiated from an IPv6 host towards an IPv4 host. The tran= slator >>>>> =A0 =A0 =A0function is intended to service a specific IPv6 network >>>>> of arbitary >>>>> =A0 =A0 =A0size. Port translation is necessary on the IPv4 side >>>>> for efficient IPv4 >>>>> =A0 =A0 =A0address usage. >>>>> >>>>> =A0 =A0 =A02. IPv6 Internet to an IPv4 network, i.e. perform >>>>> translation between >>>>> =A0 =A0 =A0IPv4 and IPv6 for packets in uni- or bi-directional >>>>> flows that are >>>>> =A0 =A0 =A0initiated from an IPv6 host towards an IPv4 host. The tran= slator >>>>> =A0 =A0 =A0function is intended to service a specific IPv4 network >>>>> using either >>>>> =A0 =A0 =A0private or public IPv4 addresses. This scenario has differ= ent >>>>> =A0 =A0 =A0constraints compared to (1), e.g. the IPv4 hosts that are = to be >>>>> =A0 =A0 =A0reachable over IPv6 can be enumerated. Therefore, the >>>>> WG should attempt >>>>> =A0 =A0 =A0to design a simpler solution with less impact on applicati= ons. >>>>> >>>>> =A0 =A0 =A03. An IPv4 network to IPv6 Internet, i.e. perform >>>>> translation between >>>>> =A0 =A0 =A0IPv4 and IPv6 for packets in uni- or bi-directional >>>>> flows that are >>>>> =A0 =A0 =A0initiated from an IPv4 host towards an IPv6 host. The tran= slator >>>>> =A0 =A0 =A0function is intended to service a specific IPv4 network >>>>> using either >>>>> =A0 =A0 =A0public or private IPv4 address space. >>>>> >>>>> =A0 =A0 =A04. IPv4 Internet to an IPv6 network, i.e. perform >>>>> translation between >>>>> =A0 =A0 =A0IPv4 and IPv6 for packets in uni- or bi-directional >>>>> flows that are >>>>> =A0 =A0 =A0initiated from an IPv4 host towards an IPv6 host. The tran= slator >>>>> =A0 =A0 =A0function is intended to service a specific IPv6 network >>>>> where selected >>>>> =A0 =A0 =A0IPv6 hosts and services are to be reachable. >>>>> >>>>> =A0 =A0 =A05. An IPv6 network to an IPv4 network, i.e., perform >>>>> translation between >>>>> =A0 =A0 =A0IPv6 and IPv4 for packets in uni- or bi-directional >>>>> flows that are >>>>> =A0 =A0 =A0initiated from an IPv6 host towards an IPv4 host. =A0The >>>>> translation >>>>> =A0 =A0 =A0function is intended to service a specific IPv6 network >>>>> of arbitrary >>>>> =A0 =A0 =A0size and a specific IPv4 network of arbitrary size >>>>> (neither of which are >>>>> =A0 =A0 =A0the Internet). >>>>> >>>>> =A0 =A0 =A06. An IPv4 network to an IPv6 network, i.e., perform >>>>> translation between >>>>> =A0 =A0 =A0IPv4 and IPv6 for packets in uni- or bi-directional >>>>> flows that are >>>>> =A0 =A0 =A0initiated from an IPv4 host towards an IPv6 host. =A0The >>>>> translation >>>>> =A0 =A0 =A0function is intended to service a specific IPv6 network >>>>> of arbitrary >>>>> =A0 =A0 =A0size and a specific IPv4 network of arbitrary size >>>>> (neither of which are >>>>> =A0 =A0 =A0the Internet). >>>>> >>>>> =A0 =A0 =A0All translation solutions shall be capable of handling >>>>> flows using TCP, >>>>> =A0 =A0 =A0UDP, DCCP, and SCTP, unless they prevent a timely >>>>> completion of the >>>>> =A0 =A0 =A0work item. The parts of ICMP that can be translated are >>>>> also required >>>>> =A0 =A0 =A0to work across a translation solution. =A0Additional >>>>> protocols directly >>>>> =A0 =A0 =A0on top of IP may be supported. Translation mechanisms >>>>> must handle IP >>>>> =A0 =A0 =A0fragmentation. >>>>> >>>>> =A0 =A0 =A0The translators should support multicast traffic and its c= ontrol >>>>> =A0 =A0 =A0traffic (IGMP and MLD) across them, both Single Source >>>>> Multicast (SSM) >>>>> =A0 =A0 =A0and Any Source Multicast (ASM). However, the WG may >>>>> determine that it >>>>> =A0 =A0 =A0becomes too complex or too difficult to realize with maint= ained >>>>> =A0 =A0 =A0functionality, for some or all cases of multicast function= ality. >>>>> >>>>> =A0 =A0 =A0Translation mechanisms cannot transparently support >>>>> protocols that >>>>> =A0 =A0 =A0embed network addresses within their protocol messages wit= hout >>>>> =A0 =A0 =A0application level gateways (ALGs). Because ALGs have >>>>> security issues >>>>> =A0 =A0 =A0(like blocking usage of TLS), are error prone and >>>>> brittle, and hinder >>>>> =A0 =A0 =A0application development, the usage of ALGs in the >>>>> defined translators >>>>> =A0 =A0 =A0should be avoided. Instead application developers will >>>>> need to be aware >>>>> =A0 =A0 =A0and use mechanisms that handle the address family >>>>> translation. ALGs may >>>>> =A0 =A0 =A0be considered only for the most crucial of legacy applicat= ions. >>>>> >>>>> =A0 =A0 =A0DNS is a crucial part in making a large number of >>>>> applications work >>>>> =A0 =A0 =A0across a translator. Thus the solution to the above >>>>> translation cases >>>>> =A0 =A0 =A0shall include recommendations for DNS. If additional >>>>> DNS functionality >>>>> =A0 =A0 =A0is needed, it may be developed. Any DNS extensions must >>>>> be developed >>>>> =A0 =A0 =A0together with the DNSEXT WG, including issuing a joint >>>>> WG last call for >>>>> =A0 =A0 =A0any documents. >>>>> >>>>> =A0 =A0 =A0The WG needs to determine the best method for providing >>>>> address space >>>>> =A0 =A0 =A0to a translator in the different deployment cases and >>>>> documenting the >>>>> =A0 =A0 =A0pros and cons of the suggested approaches. The WG is to >>>>> seek input from >>>>> =A0 =A0 =A0the Routing, Operations and Internet areas. >>>>> >>>>> =A0 =A0 =A0Solutions may solve more than one of the cases, however >>>>> timely delivery >>>>> =A0 =A0 =A0is more important than a unified solution. >>>>> >>>>> =A0 =A0 =A0Goals and Milestones: >>>>> >>>>> =A0 =A0 =A0Done =A0 =A0 =A0Submit BCP that defines unicast UDP >>>>> behavioral requirements >>>>> =A0 =A0 =A0for NATs to IESG >>>>> =A0 =A0 =A0Done =A0 =A0 =A0Submit a BCP that defines TCP behavioral >>>>> requireents for NATs >>>>> =A0 =A0 =A0to IESG >>>>> =A0 =A0 =A0Done =A0 =A0 =A0Submit a BCP that defines ICMP behavioral >>>>> requirements for >>>>> =A0 =A0 =A0NATs to IESG >>>>> =A0 =A0 =A0Done =A0 =A0 =A0Submit informational that discusses curren= t >>>>> NAT traversal >>>>> =A0 =A0 =A0techniques used by applications >>>>> =A0 =A0 =A0Done =A0 =A0 =A0Submit BCP that defines multicast UDP >>>>> =A0 =A0 =A0Done =A0 =A0 =A0Submit revision of RFC 3489 to IESG >>>>> behavioral requirements for >>>>> =A0 =A0 =A0NATs to IESG >>>>> =A0 =A0 =A0Done =A0 =A0 =A0Submit informational document for rfc3489b= is >>>>> test vectors >>>>> =A0 =A0 =A0Done =A0 =A0 =A0Submit experimental document that describe= s >>>>> how an application >>>>> =A0 =A0 =A0can determine the type of NAT it is behind >>>>> =A0 =A0 =A0Done =A0 =A0 =A0Submit BCP document for DCCP NAT behavior >>>>> =A0 =A0 =A0Dec 2009 =A0Submit to IESG: SCTP NAT behavior (BCP) >>>>> =A0 =A0 =A0Done =A0 =A0 =A0Submit to IESG: relay protocol (std) >>>>> =A0 =A0 =A0Done =A0 =A0 =A0Determine relative prioritization of the f= our >>>>> translation >>>>> =A0 =A0 =A0cases. Documented in IETF74 minutes. >>>>> =A0 =A0 =A0Sep 2009 =A0Submit to IESG: relaying of a TCP bytestream (= std) >>>>> =A0 =A0 =A0Dec 2009 =A0Submit to IESG: IPv6 relay protocol (std) >>>>> =A0 =A0 =A0Done =A0 =A0 =A0Determine what solutions(s) and components >>>>> are needed to solve >>>>> =A0 =A0 =A0each of the four cases. Create new milestones for the >>>>> solution(s) and >>>>> =A0 =A0 =A0the components. Documented in IETF74 minutes. >>>>> =A0 =A0 =A0Done =A0 =A0 =A0Submit to IESG: =A0TURN-URI document (std) >>>>> =A0 =A0 =A0Dec 2009 =A0Submit to IESG: =A0framework for IPv6/IPv4 >>>>> translation (info) >>>>> =A0 =A0 =A0Dec 2009 =A0Submit to IESG: =A0stateless IPv6/IPv4 transla= tion (std) >>>>> =A0 =A0 =A0Dec 2009 =A0Submit to IESG: =A0stateful IPv6/IPv4 translat= ion (std) >>>>> =A0 =A0 =A0Dec 2009 =A0Submit to IESG: =A0DNS rewriting for IPv6/IPv4 >>>>> translation (std) >>>>> =A0 =A0 =A0Jan 2010 =A0Submit to IESG: =A0FTP ALG for IPv6/IPv4 >>>>> translation (std) >>>>> =A0 =A0 =A0Jan 2010 =A0Submit to IESG: =A0IPv6 prefix for IPv6/IPv4 >>>>> translator (std) >>>>> =A0 =A0 =A0Mar 2010 =A0Submit to IESG: =A0large scale NAT requirement= s (BCP) >>>>> =A0 =A0 =A0_______________________________________________ >>>>> =A0 =A0 =A0Behave mailing list >>>>> =A0 =A0 =A0Behave@ietf.org >>>>> =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/behave >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> >>>>> Bo Zhou >>>>> China Mobile >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >>>> >>> >>> >>> -- >>> >>> Magnus Westerlund >>> >>> IETF Transport Area Director >>> ---------------------------------------------------------------------- >>> Multimedia Technologies, Ericsson Research EAB/TVM >>> ---------------------------------------------------------------------- >>> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 >>> F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079 >>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >>> ---------------------------------------------------------------------- >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > From caozhenpku@gmail.com Tue Oct 13 00:10:09 2009 Return-Path: <caozhenpku@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 790BF3A68B0; Tue, 13 Oct 2009 00:10:09 -0700 (PDT) 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 uTsWOXDRtQxu; Tue, 13 Oct 2009 00:10:08 -0700 (PDT) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 34DD63A679F; Tue, 13 Oct 2009 00:10:08 -0700 (PDT) Received: by pwi4 with SMTP id 4so26883pwi.29 for <multiple recipients>; Tue, 13 Oct 2009 00:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iEC94ljhZu6qfu4fmRL9KO6iDjp4hARAdm6lE3myP2Q=; b=iJ6Nb2mAU21gMfS8fKVaxCZVLRtqBXLVI+WXVIBGNt1QZhYBqBr8EcTX2Al+rn/Pg1 5KnWmwpCg6Hv9+l4PxIcSYtA1ZcdBFjC8Jf/B79oOpkoTU6Bc/bRchkbt5YXF0wtqDji wmvLmCUVyX+lg0YCTvDrCbSu74xxe5VR8f8TA= 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=Go4u0t86EVvfOJOVxdes2iudZSPr/xhrK9nhEJbcTYMrgk0xmpBVSKRH56OVAL1btS j9UuGTERcZ16LTbto+WeLvETXwQVGNToQ12Bb4nwjD4/JaMNpNLM01VJsKzGwmK+Zuau Hbdd2QlaV6eHot3xpTgqdHYZN2s+VNNxzt1gw= MIME-Version: 1.0 Received: by 10.142.195.7 with SMTP id s7mr574575wff.130.1255417805866; Tue, 13 Oct 2009 00:10:05 -0700 (PDT) In-Reply-To: <bcff0fba0910122312h1606a321mdfab07cc9662ed89@mail.gmail.com> References: <20090929163001.CBD933A6942@core3.amsl.com> <36a593230910070907p6b6f4be9xf4c344d055587cbf@mail.gmail.com> <0a9101ca4775$9fa951a0$c2f0200a@cisco.com> <4AD31720.3010004@ericsson.com> <bcff0fba0910120854w74fd3bc0n9a3a4cb71e2db398@mail.gmail.com> <a7c8d0a30910122015w551b2564i436c168e2b29a6d7@mail.gmail.com> <bcff0fba0910122312h1606a321mdfab07cc9662ed89@mail.gmail.com> Date: Tue, 13 Oct 2009 15:10:05 +0800 Message-ID: <a7c8d0a30910130010w10fa2b1cua3c7b2957aaecff7@mail.gmail.com> From: Zhen Cao <caozhenpku@gmail.com> To: Cameron Byrne <cb.list6@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org, Dave Thaler <dthaler@microsoft.com>, bo zhou <zhouboyj@gmail.com>, iesg@ietf.org, Dan Wing <dwing@cisco.com> Subject: Re: [BEHAVE] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) 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, 13 Oct 2009 07:10:09 -0000 On Tue, Oct 13, 2009 at 2:12 PM, Cameron Byrne <cb.list6@gmail.com> wrote: >>> Agreed. =A0I really struggle to understand the need for host based >>> solutions. =A0The host based solutions are essentially a greenfield >>> build since it requires the host to ultimately be IPv6 and have the >>> PNAT software extensions. >> Host based solutions are not greenfield considering BIS and BIA >> solutions presence. > > In my environment, doing a software upgrade on an existing device to > change the transport to achieve PNAT would be too risky to do on a > large scale. =A0Deploying anything with IPv6, for my environment, would > be a slow phased approach most likely incorporated into new devices > and services, not back-ported into existing devices and services. > Your environment may be different. =A0For me, any IPv6 will be > greenfield Host translation is not difficult to deploy according to our experience. The header translation software is just a plug-in module and easy to install for users. >>> It seems wiser to me, if you assume a new >>> host software is required, to go straight IPv6 with DNS64 / NAT64 as >> Going to IPv6 is not straightforward, at least we need to update all >> applications we are using. Comparatively, users can just install one >> software while using host based solution. > > Which applications are you concerned about updating? =A0My users mostly > use web and email, and those clients are commonly available for IPv6 > users today. =A0Which common applications are your users commonly using > that cannot use IPv6? Online games, video applications, anti-virus softwares, ftp, online banking security plug-in, downloading, p2p-streaming, and any softwares that are regularly updated from the internet.... I cannot give an exhaustive list. >>> the service provider subsidizes the handset and therefore as the >>> service provider we have a large amount of control over which handsets >>> are used and we are responsible for supporting those handsets. =A0And, >>> we have a large degree of ownership of the architecture and complexity >>> in the network (which includes the devices attached to the network). >>> It behooves us to choose solutions that are end-to-end less complex >>> and easier to support in the long run, not simply transferring the >>> complexity to the handset vendors. =A0That said, network operators can >>> deploy what makes sense for their unique economic and technology >>> context, and IMHO NAT64 / DNS64 in the network is the best strategic >>> option, it has the right incentives towards end to end IPv6, and it is >>> only an incremental change to the NAT44 world of today. =A0Host based >>> solutions, IMHO, =A0are not being considered seriously in North America >>> or Europe. >> >> Do you have enough experience to say that for sure? > > For North America, yes. =A0I worked on this 3G Americas paper with the > AT&T and Rogers, host based translation was never mentioned as an > option in any of the discussion during the production of the paper. > http://www.3gamericas.org/documents/2008_IPv6_transition_3GA_Mar2008.pdf We have come across too many such kind of whitepapers; few of them actually flies. Maybe this one is different, but i do not know. We only saw technologies fly away by one witnessed success and then others followed the example. > Verizon has a public spec available for their LTE devices, they are > IPv6 only with optional dual stack for IPv4. =A0 No requirement for host > based translations. > > Regarding Europe, T-Mobile entities are not considering PNAT. =A0I don't > personally have experience with other European operators. =A0But, i can > only officially speak for myself. =A0I have only seen one network > operator on this list or any list support host based translation. > That does not mean it will not be a standard or work well for that one > operator, it just means the solution has a narrow fit. What's a narrow fit, count w.r.t operators or users? Europe has 0.3 billion users but >50 operators, while China Mobile has 0.5 billion users. From root@core3.amsl.com Tue Oct 13 17:00:02 2009 Return-Path: <root@core3.amsl.com> X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4027E3A682E; Tue, 13 Oct 2009 17:00:01 -0700 (PDT) From: IESG Secretary <iesg-secretary@ietf.org> To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20091014000002.4027E3A682E@core3.amsl.com> Date: Tue, 13 Oct 2009 17:00:02 -0700 (PDT) Cc: behave@ietf.org, dthaler@microsoft.com, dwing@cisco.com Subject: [BEHAVE] WG Action: RECHARTER: Behavior Engineering for Hindrance Avoidance (behave) 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: Wed, 14 Oct 2009 00:00:02 -0000 The charter of the Behavior Engineering for Hindrance Avoidance (behave) working group in the Transport Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- Last Modified: 2009-09-09 Current Status: Active Working Group Additional information is available at tools.ietf.org/wg/behave Chair(s): * Dan Wing <dwing@cisco.com> * Dave Thaler <dthaler@microsoft.com> Transport Area Director(s): * Magnus Westerlund <magnus.westerlund@ericsson.com> * Lars Eggert <lars.eggert@nokia.com> Transport Area Advisor: * Magnus Westerlund <magnus.westerlund@ericsson.com> Mailing Lists: General Discussion: behave@ietf.org To Subscribe: behave-request@ietf.org In Body: In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/behave Description of Working Group: The behavior of NATs varies from one implementation to another. As a result it is very difficult for applications to predict or discover the behavior of these devices. Predicting and/or discovering the behavior of NATs is important for designing application protocols and NAT traversal techniques that work reliably in existing networks. This situation is especially problematic for end-to-end applications where one or both end-points are behind a NAT, such as multiuser games, interactive multimedia and P2P download. The working group documents best current practices to enable NATs to function in as deterministic a fashion as possible. The NAT behavior practices will be application independent. This has already completed for UDP, TCP, DCCP, Multicast and ICMP. It continues with SCTP and any additional protocol deemed necessary to handle. The WG has documented approaches for characterizing and testing NAT devices. BEHAVE will develop protocol-independent toolkits usable by application protocols for NAT traversal. The WG has already produced an update of the binding discovery protocol STUN. It will now produce a relay protocol that focuses on security and is usable with both IPv4 and IPv6, and capable of relaying between the two IP versions. Due to the WG's experience with translators and their behavior it has been given the following tasks to help encourage migration to IPv6. To support deployments where communicating hosts require using different address families (IPv4 or IPv6), address family translation is needed to establish communication. In BEHAVE's specification work on this topic it will coordinate with the V6ops WG on requirements and operational considerations. "An IPv4 network" or "an IPv6 network" in the descriptions below refer to a network with a clearly identifiable administrative domain (e.g., an enterprise campus network, a mobile operator's cellular network, a residential subscriber network, etc.). It will also be that network that deploys the necessary equipment for translation. The BEHAVE WG will design solutions for the following six translation scenarios; other scenarios are out of scope: 1. An IPv6 network to IPv4 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translator function is intended to service a specific IPv6 network of arbitary size. Port translation is necessary on the IPv4 side for efficient IPv4 address usage. 2. IPv6 Internet to an IPv4 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translator function is intended to service a specific IPv4 network using either private or public IPv4 addresses. This scenario has different constraints compared to (1), e.g. the IPv4 hosts that are to be reachable over IPv6 can be enumerated. Therefore, the WG should attempt to design a simpler solution with less impact on applications. 3. An IPv4 network to IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv4 network using either public or private IPv4 address space. 4. IPv4 Internet to an IPv6 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv6 network where selected IPv6 hosts and services are to be reachable. 5. An IPv6 network to an IPv4 network, i.e., perform translation between IPv6 and IPv4 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translation function is intended to service a specific IPv6 network of arbitrary size and a specific IPv4 network of arbitrary size (neither of which are the Internet). 6. An IPv4 network to an IPv6 network, i.e., perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translation function is intended to service a specific IPv6 network of arbitrary size and a specific IPv4 network of arbitrary size (neither of which are the Internet). All translation solutions shall be capable of handling flows using TCP, UDP, DCCP, and SCTP, unless they prevent a timely completion of the work item. The parts of ICMP that can be translated are also required to work across a translation solution. Additional protocols directly on top of IP may be supported. Translation mechanisms must handle IP fragmentation. The translators should support multicast traffic and its control traffic (IGMP and MLD) across them, both Single Source Multicast (SSM) and Any Source Multicast (ASM). However, the WG may determine that it becomes too complex or too difficult to realize with maintained functionality, for some or all cases of multicast functionality. Translation mechanisms cannot transparently support protocols that embed network addresses within their protocol messages without application level gateways (ALGs). Because ALGs have security issues (like blocking usage of TLS), are error prone and brittle, and hinder application development, the usage of ALGs in the defined translators should be avoided. Instead application developers will need to be aware and use mechanisms that handle the address family translation. ALGs may be considered only for the most crucial of legacy applications. DNS is a crucial part in making a large number of applications work across a translator. Thus the solution to the above translation cases shall include recommendations for DNS. If additional DNS functionality is needed, it may be developed. Any DNS extensions must be developed together with the DNSEXT WG, including issuing a joint WG last call for any documents. The WG needs to determine the best method for providing address space to a translator in the different deployment cases and documenting the pros and cons of the suggested approaches. The WG is to seek input from the Routing, Operations and Internet areas. Solutions may solve more than one of the cases, however timely delivery is more important than a unified solution. Goals and Milestones: Done Submit BCP that defines unicast UDP behavioral requirements for NATs to IESG Done Submit a BCP that defines TCP behavioral requireents for NATs to IESG Done Submit a BCP that defines ICMP behavioral requirements for NATs to IESG Done Submit informational that discusses current NAT traversal techniques used by applications Done Submit BCP that defines multicast UDP Done Submit revision of RFC 3489 to IESG behavioral requirements for NATs to IESG Done Submit informational document for rfc3489bis test vectors Done Submit experimental document that describes how an application can determine the type of NAT it is behind Done Submit BCP document for DCCP NAT behavior Dec 2009 Submit to IESG: SCTP NAT behavior (BCP) Done Submit to IESG: relay protocol (std) Done Determine relative prioritization of the four translation cases. Documented in IETF74 minutes. Sep 2009 Submit to IESG: relaying of a TCP bytestream (std) Dec 2009 Submit to IESG: IPv6 relay protocol (std) Done Determine what solutions(s) and components are needed to solve each of the four cases. Create new milestones for the solution(s) and the components. Documented in IETF74 minutes. Done Submit to IESG: TURN-URI document (std) Dec 2009 Submit to IESG: framework for IPv6/IPv4 translation (info) Dec 2009 Submit to IESG: stateless IPv6/IPv4 translation (std) Dec 2009 Submit to IESG: stateful IPv6/IPv4 translation (std) Dec 2009 Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std) Jan 2010 Submit to IESG: FTP ALG for IPv6/IPv4 translation (std) Jan 2010 Submit to IESG: IPv6 prefix for IPv6/IPv4 translator (std) Mar 2010 Submit to IESG: large scale NAT requirements (BCP) From xing@cernet.edu.cn Wed Oct 14 03:44:58 2009 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 7CA493A68DA; Wed, 14 Oct 2009 03:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.697 X-Spam-Level: ** X-Spam-Status: No, score=2.697 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAHLuGk0UNmy; Wed, 14 Oct 2009 03:44:57 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 36AF03A67E7; Wed, 14 Oct 2009 03:44:54 -0700 (PDT) Received: from [59.66.24.140]([59.66.24.140]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54ad5fadb; Wed, 14 Oct 2009 18:44:49 +0800 Message-ID: <4AD5AB6B.4030508@cernet.edu.cn> Date: Wed, 14 Oct 2009 18:43:55 +0800 From: Xing Li <xing@cernet.edu.cn> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dan Wing <dwing@cisco.com> References: <20090929163001.CBD933A6942@core3.amsl.com> <36a593230910070907p6b6f4be9xf4c344d055587cbf@mail.gmail.com> <0a9101ca4775$9fa951a0$c2f0200a@cisco.com> <4AD31720.3010004@ericsson.com> <08f601ca4ba8$145f76b0$a8f746ab@cisco.com> In-Reply-To: <08f601ca4ba8$145f76b0$a8f746ab@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: IAdVByWB Cc: 'bo zhou' <zhouboyj@gmail.com>, behave@ietf.org, iesg@ietf.org, 'Dave Thaler' <dthaler@microsoft.com> Subject: Re: [BEHAVE] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) 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: Wed, 14 Oct 2009 10:44:58 -0000 Dan Wing 写é“: >> I agree we do not have consensus to adopt host-based translation. >> But 6/4 translation is a function which could be done in a host or >> in a network device; I didn't intend any more meaning with my >> response. >> +1 xing >> -d >> >> >> From root@core3.amsl.com Wed Oct 14 05:45:02 2009 Return-Path: <root@core3.amsl.com> X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 096463A69EF; Wed, 14 Oct 2009 05:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091014124502.096463A69EF@core3.amsl.com> Date: Wed, 14 Oct 2009 05:45:02 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-turn-ipv6-07.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: Wed, 14 Oct 2009 12:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Traversal Using Relays around NAT (TURN) Extension for IPv6 Author(s) : S. Perreault, et al. Filename : draft-ietf-behave-turn-ipv6-07.txt Pages : 13 Date : 2009-10-14 This document adds IPv6 support to Traversal Using Relays around NAT (TURN). IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying. This document defines the REQUESTED- ADDRESS-FAMILY attribute for TURN. The REQUESTED-ADDRESS-FAMILY attribute allows a client to explicitly request the address type the TURN server will allocate (e.g., an IPv4-only node may request the TURN server to allocate an IPv6 address). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-ipv6-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-turn-ipv6-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-14054007.I-D@ietf.org> --NextPart-- From simon.perreault@viagenie.ca Wed Oct 14 05:52:07 2009 Return-Path: <simon.perreault@viagenie.ca> 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 890FB28C165 for <behave@core3.amsl.com>; Wed, 14 Oct 2009 05:52:07 -0700 (PDT) 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 UHD57JD20TJM for <behave@core3.amsl.com>; Wed, 14 Oct 2009 05:52:06 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 74DB73A68E2 for <behave@ietf.org>; Wed, 14 Oct 2009 05:52:06 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7BD4A20E00 for <behave@ietf.org>; Wed, 14 Oct 2009 08:52:08 -0400 (EDT) From: Simon Perreault <simon.perreault@viagenie.ca> Organization: =?iso-8859-1?q?Viag=E9nie?= To: behave@ietf.org Date: Wed, 14 Oct 2009 08:52:07 -0400 User-Agent: KMail/1.12.0 (Linux/2.6.30.5-43.fc11.x86_64; KDE/4.3.0; x86_64; ; ) References: <20091014124502.096463A69EF@core3.amsl.com> In-Reply-To: <20091014124502.096463A69EF@core3.amsl.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200910140852.07564.simon.perreault@viagenie.ca> Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-ipv6-07.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: Wed, 14 Oct 2009 12:52:07 -0000 On Wednesday 14 October 2009 08:45:02 Internet-Drafts@ietf.org wrote: > Title : Traversal Using Relays around NAT (TURN) Extension for > IPv6 Author(s) : S. Perreault, et al. > Filename : draft-ietf-behave-turn-ipv6-07.txt > Pages : 13 > Date : 2009-10-14 As requested by the authors, I took on the role of editor. My task was to bring this draft up to date with the current version of the TURN draft. After careful review, I did not find any changes in the TURN draft that warranted changes in TURN-IPv6. I only updated the references and adjusted some wording. One thing caught my attention: it seems that this draft implicitly ignores the presence of the DONT-FRAGMENT attribute. I made this fact explicit by adding the sentence "If present, the DONT-FRAGMENT attribute MUST be ignored by the server." This makes DONT-FRAGMENT only applicable to IPv4-IPv4 relay. Is this right? Discuss. ;) I know of no other issue with this draft. Thanks, Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From xing@cernet.edu.cn Wed Oct 14 05:56:32 2009 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 D04FB28C1C5 for <behave@core3.amsl.com>; Wed, 14 Oct 2009 05:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.142 X-Spam-Level: ** X-Spam-Status: No, score=2.142 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXVKk2u7h5AB for <behave@core3.amsl.com>; Wed, 14 Oct 2009 05:56:31 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id A3CCB28C1C0 for <behave@ietf.org>; Wed, 14 Oct 2009 05:56:30 -0700 (PDT) Received: from [59.66.24.140]([59.66.24.140]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jmf4ad619b7; Wed, 14 Oct 2009 20:56:30 +0800 Message-ID: <4AD5CA52.8000907@cernet.edu.cn> Date: Wed, 14 Oct 2009 20:55:46 +0800 From: Xing Li <xing@cernet.edu.cn> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christian Huitema <huitema@microsoft.com> References: <CC6108C4-E9D2-432F-AC53-B96995220DE8@cisco.com> <6B55F0F93C3E9D45AF283313B8D342BA211A6737@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA211A6737@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: IrEZDyWB Cc: Xing Li <xing@cernet.edu.cn>, congxiao <congxiao@cernet.edu.cn>, "draft-ietf-behave-address-format@tools.ietf.org" <draft-ietf-behave-address-format@tools.ietf.org>, Behave WG <behave@ietf.org>, Fred Baker <fred@cisco.com> Subject: Re: [BEHAVE] Need another case in 3.2.5 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: Wed, 14 Oct 2009 12:56:32 -0000 Hi, Christian, Christian Huitema 写é“: > We were having a similar discussion when preparing the next version of the addressing documents. > > There are a couple of constraints, of various importance, that we need to address. You mention checksum neutrality, and we can certainly accommodate that, but there are a few others that lead to discussions. For example, for stateless translation, we need to be able to route packets in the IPv6 network based on the IPv4 address. If we want to protect against address spoofing, we need to also perform reverse path checks based the IPv4 address. Even for stateful translation, we may need to select the translator based on the target IPv4 address, e.g. to perform load balancing. > > That requirement can be accommodated in several ways, the simplest one being to format the addresses a prefix (well known or network specific), concatenated with the IPv4 address and a suffix. That way, the network can perform internal routing and checks on the combination of prefix+IPv4 address. But then, there are a few complications. > > First, we wonder about the importance of the 64 bit boundary. Addressing documents specify that the global address is essentially formed of a 64 bit subnet prefix and a 64 bit host identifier, with the host identifier compatible with IEEE 802 identifiers. Does that mean that the "routing" requirement of stateless translation can only be addressed if the IPv4 bytes are entirely contained within the subnet prefix? Different authors have different opinions, so WG input would be beneficial. > Based on our understanding and our large scale IPv6 network operation experience: (1) The IPv6 network should be able to route any prefix length from default to /128. However, the wire-speed forwarding may require /80 or shorter for some routers. (2) The stateless host configuration requires the /64 as the subnet prefix length. However, if DHCPv6 or static configuration is implemented. The subnet prefix can be with any prefix length. > Second, we wonder about the constraints of host identifiers. A first question is whether an all null identifier would be legitimate and practical. There is some evidence that it works with most stacks. But there is also a statement in the addressing document that the all null address is reserved for the subnet anycast address. Do stacks actually implement the subnet anycast function? Should the specification be removed from the addressing RFC? Can we just ignore it? If we cannot ignore it, we will have to specify some value different from zero for the suffix. A "checksum neutrality" field might do that, but please consider the second question. > Based on Section 2 of RFC4291, it reads: "In IPv6, all zeros and all ones are legal values for any field, unless specifically excluded. Specifically, prefixes may contain, or end with, zero-valued fields." Based on Section 2.6.1 of RFC4291, all zeros are used for the subnet-router anycast address. However, we don't need to remove this specification from RFC4291, since we never use "all null identifier" for the IPv4-translatable addresses. For example, if 202.38.108.0/24 is mapped into IPv4-translatable addresses, it will become 2001:da8:ffca:266c:0::/64 (for easier demonstration, we use four consecutive octets and the PREFIX is 2001:da8:ff00::/40). It is clear that the individual IPv4-translatable addresses are 2001:da8:ffca:266c:100::/64, 2001:da8:ffca:266c:200::/64, ..., 2001:da8:ffca:266c:fe00::/64. while the subnet-router anycast address is 2001:da8:ffca:266c:0::/64. They are different. Note that we are not using 2001:da8:ffca:266c:0000::/64, because it is the network identifier in IPv4. Based on the above analysis, we don't need to specify some value different from zero for the suffix. > The second question regards the uniqueness of host identifiers. Suppose we define the address used for stateless translation as: 32 bit "provider" prefix, 32 bit IPv4 address, and a constant identifier, either 0 or the "checksum neutrality" value, which is only a function of the provider prefix. Suppose now that for some reason there are two "IPv4 addressed" hosts on the same link, e.g. because many servers are located in the same server room. The two hosts will have different addresses, in different 64 bit subnets, but they will also have different host identifiers. Is that OK? > Based on the above reasons, it is OK. Regards, xing, congxiao > -- Christian Huitema > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > From denghui02@gmail.com Wed Oct 14 07:35:25 2009 Return-Path: <denghui02@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 67FC53A6A0D; Wed, 14 Oct 2009 07:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EP2qep5syJQC; Wed, 14 Oct 2009 07:35:24 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id A07183A6A09; Wed, 14 Oct 2009 07:35:23 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so1224389qwb.31 for <multiple recipients>; Wed, 14 Oct 2009 07:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EmreyoAgyGSuJvbbxuWXImkR88Lq6ECDYCCMQYeAEDs=; b=FYERyMJaMRo3fzhevyIFBKYQFmssmICofhLbJg4nFOd13ZUsiZTDB/q1kDrrR8bay2 MFdarlNu/8SI0PacOTUpDGvHdoGGRXSW672IwQkeo68HuP6SKEhbxHNl8wggutPRGSkk bjThcjh64uIaqwUVDkTO/MOIjRS7kdNTWC/OQ= 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=vKV6jGZw0fvi/EsuF7aMIXPSdPYP1L8gEYAbDagSZFGgemvLBKKHq3ENR7bdFC2JsG airOCwwy1YXxP3vAKwn1R9vaQqNbTv1QiXSff/UoJIZldVVLzoNntP07sA8E1QJhoG2H 0gwEeblSwxRTBBihzQkr/eqHIJQSKZGReyeUs= MIME-Version: 1.0 Received: by 10.224.35.12 with SMTP id n12mr7064067qad.250.1255530919668; Wed, 14 Oct 2009 07:35:19 -0700 (PDT) In-Reply-To: <4AD31720.3010004@ericsson.com> References: <20090929163001.CBD933A6942@core3.amsl.com> <36a593230910070907p6b6f4be9xf4c344d055587cbf@mail.gmail.com> <0a9101ca4775$9fa951a0$c2f0200a@cisco.com> <4AD31720.3010004@ericsson.com> Date: Wed, 14 Oct 2009 22:35:19 +0800 Message-ID: <1d38a3350910140735le1c87a5y82d9393e14637ac0@mail.gmail.com> From: Hui Deng <denghui02@gmail.com> To: Magnus Westerlund <magnus.westerlund@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Dave Thaler <dthaler@microsoft.com>, bo zhou <zhouboyj@gmail.com>, behave@ietf.org, iesg@ietf.org, Dan Wing <dwing@cisco.com> Subject: Re: [BEHAVE] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) 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: Wed, 14 Oct 2009 14:35:25 -0000 Hi, Magnus, Thanks for your advice, we have many people working on the requirement and motivation draft at the moment as you pointed out here, Best regards, -Hui 2009/10/12 Magnus Westerlund <magnus.westerlund@ericsson.com>: > Hi, > > I just want to indicate that this was not my interpretation of the > charter. Case 5 and 6 was to my knowledge added to handle the cases when > two different businesses or different parts of the same organization > want to connect their networks together and need translation, rather > than going through the Internet. > > When it comes to host based translation, I think we would need more > discussion about the motivation for that use case are. As I understand > it it is a case of handling IPv4 only legacy applications when you have > updated the operating system and uses an IPv6 only network. I don't see > any reason for doing it for IPv6 only applications as they should be > capable of handling IPv4 connectivity. And if an application really > needs IPv6 to function there exist tunneling solutions that would be a > better gap-filler than a translation based solution. > > So for host based solutions I think we haven't had a conclusive > discussion about either what the requirements and motivations are or if > there is consensus to take that on. > > Regards > > Magnus Westerlund > > > Dan Wing skrev: >> >> >>> -----Original Message----- >>> From: bo zhou [mailto:zhouboyj@gmail.com] >>> Sent: Wednesday, October 07, 2009 9:08 AM >>> To: Dave Thaler; Dan Wing >>> Cc: ietf-announce@ietf.org; behave@ietf.org; iesg@ietf.org >>> Subject: Re: [BEHAVE] WG Review: Recharter of Behavior >>> Engineering for Hindrance Avoidance (behave) >>> >>> Hi Dave and Dan, >>> >>> I just found the charter of the Behave has been modified. >>> >>> "5. An IPv6 network to an IPv4 network, i.e., perform >>> translation between >>> IPv6 and IPv4 for packets in uni- or bi-directional flows that are >>> initiated from an IPv6 host towards an IPv4 host. =A0The translation >>> function is intended to service a specific IPv6 network of arbitrary >>> size and a specific IPv4 network of arbitrary size (neither >>> of which are >>> the Internet)." >>> >>> Does this cover host based translator solutions for 6 to 4? >> >> Yes, the "specific IPv6 network of arbitrary size" is a network containi= ng 1 >> host. >> >> -d >> >> >>> Regards, >>> >>> Bo Zhou >>> >>> >>> On Wed, Sep 30, 2009 at 12:30 AM, IESG Secretary >>> <iesg-secretary@ietf.org> wrote: >>> >>> >>> =A0 =A0 =A0A modified charter has been submitted for the Behavior >>> Engineering for >>> =A0 =A0 =A0Hindrance Avoidance (behave) working group in the >>> Transport Area of the >>> =A0 =A0 =A0IETF. =A0The IESG has not made any determination as yet. >>> The modified >>> =A0 =A0 =A0charter is provided below for informational purposes >>> only. =A0Please send >>> =A0 =A0 =A0your comments to the IESG mailing list (iesg@ietf.org) >>> by Tuesday, October >>> =A0 =A0 =A06, 2009. >>> >>> =A0 =A0 =A0Behavior Engineering for Hindrance Avoidance (behave) >>> =A0 =A0 =A0----------------------------------------------------- >>> =A0 =A0 =A0Current Status: Active Working Group >>> =A0 =A0 =A0Last Modified: 2009-09-09 >>> >>> =A0 =A0 =A0Current Status: Active Working Group >>> >>> =A0 =A0 =A0Additional information is available at tools.ietf.org/wg/beh= ave >>> =A0 =A0 =A0Chair(s): >>> >>> =A0 =A0 =A0 =A0 * Dan Wing <dwing@cisco.com> >>> =A0 =A0 =A0 =A0 * Dave Thaler <dthaler@microsoft.com> >>> >>> =A0 =A0 =A0Transport Area Director(s): >>> >>> =A0 =A0 =A0 =A0 * Magnus Westerlund <magnus.westerlund@ericsson.com> >>> =A0 =A0 =A0 =A0 * Lars Eggert <lars.eggert@nokia.com> >>> >>> =A0 =A0 =A0Transport Area Advisor: >>> >>> =A0 =A0 =A0 =A0 * Magnus Westerlund <magnus.westerlund@ericsson.com> >>> >>> =A0 =A0 =A0Mailing Lists: >>> =A0 =A0 =A0 General Discussion: behave@ietf.org >>> =A0 =A0 =A0 To Subscribe: behave-request@ietf.org >>> =A0 =A0 =A0 In Body: In Body: subscribe >>> =A0 =A0 =A0 Archive: http://www.ietf.org/mail-archive/web/behave >>> >>> =A0 =A0 =A0Description of Working Group: >>> >>> =A0 =A0 =A0The behavior of NATs varies from one implementation to >>> another. As a >>> =A0 =A0 =A0result it is very difficult for applications to predict >>> or discover the >>> =A0 =A0 =A0behavior of these devices. Predicting and/or >>> discovering the behavior >>> =A0 =A0 =A0of NATs is important for designing application protocols and= NAT >>> =A0 =A0 =A0traversal techniques that work reliably in existing >>> networks. This >>> =A0 =A0 =A0situation is especially problematic for end-to-end >>> applications where >>> =A0 =A0 =A0one or both end-points are behind a NAT, such as >>> multiuser games, >>> =A0 =A0 =A0interactive multimedia and P2P download. >>> >>> =A0 =A0 =A0The working group documents best current practices to >>> enable NATs to >>> =A0 =A0 =A0function in as deterministic a fashion as possible. The >>> NAT behavior >>> =A0 =A0 =A0practices will be application independent. This has >>> already completed >>> =A0 =A0 =A0for UDP, TCP, DCCP, Multicast and ICMP. It continues >>> with SCTP and any >>> =A0 =A0 =A0additional protocol deemed necessary to handle. The WG >>> has documented >>> =A0 =A0 =A0approaches for characterizing and testing NAT devices. >>> >>> =A0 =A0 =A0BEHAVE will develop protocol-independent toolkits >>> usable by application >>> =A0 =A0 =A0protocols for NAT traversal. The WG has already >>> produced an update of >>> =A0 =A0 =A0the binding discovery protocol STUN. It will now produce a r= elay >>> =A0 =A0 =A0protocol that focuses on security and is usable with >>> both IPv4 and >>> =A0 =A0 =A0IPv6, and capable of relaying between the two IP versions. >>> >>> =A0 =A0 =A0Due to the WG's experience with translators and their >>> behavior it has >>> =A0 =A0 =A0been given the following tasks to help encourage >>> migration to IPv6. To >>> =A0 =A0 =A0support deployments where communicating hosts require >>> using different >>> =A0 =A0 =A0address families (IPv4 or IPv6), address family translation = is >>> =A0 =A0 =A0needed to establish communication. In BEHAVE's >>> specification work on >>> =A0 =A0 =A0this topic it will coordinate with the V6ops WG on >>> requirements and >>> =A0 =A0 =A0operational considerations. >>> >>> =A0 =A0 =A0"An IPv4 network" or "an IPv6 network" in the >>> descriptions below refer >>> =A0 =A0 =A0to a network with a clearly identifiable administrative >>> domain (e.g., >>> =A0 =A0 =A0an enterprise campus network, a mobile operator's >>> cellular network, a >>> =A0 =A0 =A0residential subscriber network, etc.). It will also be >>> that network >>> =A0 =A0 =A0that deploys the necessary equipment for translation. >>> >>> =A0 =A0 =A0The BEHAVE WG will design solutions for the following >>> six translation >>> =A0 =A0 =A0scenarios; other scenarios are out of scope: >>> >>> =A0 =A0 =A01. An IPv6 network to IPv4 Internet, i.e. perform >>> translation between >>> =A0 =A0 =A0IPv4 and IPv6 for packets in uni- or bi-directional >>> flows that are >>> =A0 =A0 =A0initiated from an IPv6 host towards an IPv4 host. The transl= ator >>> =A0 =A0 =A0function is intended to service a specific IPv6 network >>> of arbitary >>> =A0 =A0 =A0size. Port translation is necessary on the IPv4 side >>> for efficient IPv4 >>> =A0 =A0 =A0address usage. >>> >>> =A0 =A0 =A02. IPv6 Internet to an IPv4 network, i.e. perform >>> translation between >>> =A0 =A0 =A0IPv4 and IPv6 for packets in uni- or bi-directional >>> flows that are >>> =A0 =A0 =A0initiated from an IPv6 host towards an IPv4 host. The transl= ator >>> =A0 =A0 =A0function is intended to service a specific IPv4 network >>> using either >>> =A0 =A0 =A0private or public IPv4 addresses. This scenario has differen= t >>> =A0 =A0 =A0constraints compared to (1), e.g. the IPv4 hosts that are to= be >>> =A0 =A0 =A0reachable over IPv6 can be enumerated. Therefore, the >>> WG should attempt >>> =A0 =A0 =A0to design a simpler solution with less impact on application= s. >>> >>> =A0 =A0 =A03. An IPv4 network to IPv6 Internet, i.e. perform >>> translation between >>> =A0 =A0 =A0IPv4 and IPv6 for packets in uni- or bi-directional >>> flows that are >>> =A0 =A0 =A0initiated from an IPv4 host towards an IPv6 host. The transl= ator >>> =A0 =A0 =A0function is intended to service a specific IPv4 network >>> using either >>> =A0 =A0 =A0public or private IPv4 address space. >>> >>> =A0 =A0 =A04. IPv4 Internet to an IPv6 network, i.e. perform >>> translation between >>> =A0 =A0 =A0IPv4 and IPv6 for packets in uni- or bi-directional >>> flows that are >>> =A0 =A0 =A0initiated from an IPv4 host towards an IPv6 host. The transl= ator >>> =A0 =A0 =A0function is intended to service a specific IPv6 network >>> where selected >>> =A0 =A0 =A0IPv6 hosts and services are to be reachable. >>> >>> =A0 =A0 =A05. An IPv6 network to an IPv4 network, i.e., perform >>> translation between >>> =A0 =A0 =A0IPv6 and IPv4 for packets in uni- or bi-directional >>> flows that are >>> =A0 =A0 =A0initiated from an IPv6 host towards an IPv4 host. =A0The >>> translation >>> =A0 =A0 =A0function is intended to service a specific IPv6 network >>> of arbitrary >>> =A0 =A0 =A0size and a specific IPv4 network of arbitrary size >>> (neither of which are >>> =A0 =A0 =A0the Internet). >>> >>> =A0 =A0 =A06. An IPv4 network to an IPv6 network, i.e., perform >>> translation between >>> =A0 =A0 =A0IPv4 and IPv6 for packets in uni- or bi-directional >>> flows that are >>> =A0 =A0 =A0initiated from an IPv4 host towards an IPv6 host. =A0The >>> translation >>> =A0 =A0 =A0function is intended to service a specific IPv6 network >>> of arbitrary >>> =A0 =A0 =A0size and a specific IPv4 network of arbitrary size >>> (neither of which are >>> =A0 =A0 =A0the Internet). >>> >>> =A0 =A0 =A0All translation solutions shall be capable of handling >>> flows using TCP, >>> =A0 =A0 =A0UDP, DCCP, and SCTP, unless they prevent a timely >>> completion of the >>> =A0 =A0 =A0work item. The parts of ICMP that can be translated are >>> also required >>> =A0 =A0 =A0to work across a translation solution. =A0Additional >>> protocols directly >>> =A0 =A0 =A0on top of IP may be supported. Translation mechanisms >>> must handle IP >>> =A0 =A0 =A0fragmentation. >>> >>> =A0 =A0 =A0The translators should support multicast traffic and its con= trol >>> =A0 =A0 =A0traffic (IGMP and MLD) across them, both Single Source >>> Multicast (SSM) >>> =A0 =A0 =A0and Any Source Multicast (ASM). However, the WG may >>> determine that it >>> =A0 =A0 =A0becomes too complex or too difficult to realize with maintai= ned >>> =A0 =A0 =A0functionality, for some or all cases of multicast functional= ity. >>> >>> =A0 =A0 =A0Translation mechanisms cannot transparently support >>> protocols that >>> =A0 =A0 =A0embed network addresses within their protocol messages witho= ut >>> =A0 =A0 =A0application level gateways (ALGs). Because ALGs have >>> security issues >>> =A0 =A0 =A0(like blocking usage of TLS), are error prone and >>> brittle, and hinder >>> =A0 =A0 =A0application development, the usage of ALGs in the >>> defined translators >>> =A0 =A0 =A0should be avoided. Instead application developers will >>> need to be aware >>> =A0 =A0 =A0and use mechanisms that handle the address family >>> translation. ALGs may >>> =A0 =A0 =A0be considered only for the most crucial of legacy applicatio= ns. >>> >>> =A0 =A0 =A0DNS is a crucial part in making a large number of >>> applications work >>> =A0 =A0 =A0across a translator. Thus the solution to the above >>> translation cases >>> =A0 =A0 =A0shall include recommendations for DNS. If additional >>> DNS functionality >>> =A0 =A0 =A0is needed, it may be developed. Any DNS extensions must >>> be developed >>> =A0 =A0 =A0together with the DNSEXT WG, including issuing a joint >>> WG last call for >>> =A0 =A0 =A0any documents. >>> >>> =A0 =A0 =A0The WG needs to determine the best method for providing >>> address space >>> =A0 =A0 =A0to a translator in the different deployment cases and >>> documenting the >>> =A0 =A0 =A0pros and cons of the suggested approaches. The WG is to >>> seek input from >>> =A0 =A0 =A0the Routing, Operations and Internet areas. >>> >>> =A0 =A0 =A0Solutions may solve more than one of the cases, however >>> timely delivery >>> =A0 =A0 =A0is more important than a unified solution. >>> >>> =A0 =A0 =A0Goals and Milestones: >>> >>> =A0 =A0 =A0Done =A0 =A0 =A0Submit BCP that defines unicast UDP >>> behavioral requirements >>> =A0 =A0 =A0for NATs to IESG >>> =A0 =A0 =A0Done =A0 =A0 =A0Submit a BCP that defines TCP behavioral >>> requireents for NATs >>> =A0 =A0 =A0to IESG >>> =A0 =A0 =A0Done =A0 =A0 =A0Submit a BCP that defines ICMP behavioral >>> requirements for >>> =A0 =A0 =A0NATs to IESG >>> =A0 =A0 =A0Done =A0 =A0 =A0Submit informational that discusses current >>> NAT traversal >>> =A0 =A0 =A0techniques used by applications >>> =A0 =A0 =A0Done =A0 =A0 =A0Submit BCP that defines multicast UDP >>> =A0 =A0 =A0Done =A0 =A0 =A0Submit revision of RFC 3489 to IESG >>> behavioral requirements for >>> =A0 =A0 =A0NATs to IESG >>> =A0 =A0 =A0Done =A0 =A0 =A0Submit informational document for rfc3489bis >>> test vectors >>> =A0 =A0 =A0Done =A0 =A0 =A0Submit experimental document that describes >>> how an application >>> =A0 =A0 =A0can determine the type of NAT it is behind >>> =A0 =A0 =A0Done =A0 =A0 =A0Submit BCP document for DCCP NAT behavior >>> =A0 =A0 =A0Dec 2009 =A0Submit to IESG: SCTP NAT behavior (BCP) >>> =A0 =A0 =A0Done =A0 =A0 =A0Submit to IESG: relay protocol (std) >>> =A0 =A0 =A0Done =A0 =A0 =A0Determine relative prioritization of the fou= r >>> translation >>> =A0 =A0 =A0cases. Documented in IETF74 minutes. >>> =A0 =A0 =A0Sep 2009 =A0Submit to IESG: relaying of a TCP bytestream (st= d) >>> =A0 =A0 =A0Dec 2009 =A0Submit to IESG: IPv6 relay protocol (std) >>> =A0 =A0 =A0Done =A0 =A0 =A0Determine what solutions(s) and components >>> are needed to solve >>> =A0 =A0 =A0each of the four cases. Create new milestones for the >>> solution(s) and >>> =A0 =A0 =A0the components. Documented in IETF74 minutes. >>> =A0 =A0 =A0Done =A0 =A0 =A0Submit to IESG: =A0TURN-URI document (std) >>> =A0 =A0 =A0Dec 2009 =A0Submit to IESG: =A0framework for IPv6/IPv4 >>> translation (info) >>> =A0 =A0 =A0Dec 2009 =A0Submit to IESG: =A0stateless IPv6/IPv4 translati= on (std) >>> =A0 =A0 =A0Dec 2009 =A0Submit to IESG: =A0stateful IPv6/IPv4 translatio= n (std) >>> =A0 =A0 =A0Dec 2009 =A0Submit to IESG: =A0DNS rewriting for IPv6/IPv4 >>> translation (std) >>> =A0 =A0 =A0Jan 2010 =A0Submit to IESG: =A0FTP ALG for IPv6/IPv4 >>> translation (std) >>> =A0 =A0 =A0Jan 2010 =A0Submit to IESG: =A0IPv6 prefix for IPv6/IPv4 >>> translator (std) >>> =A0 =A0 =A0Mar 2010 =A0Submit to IESG: =A0large scale NAT requirements = (BCP) >>> =A0 =A0 =A0_______________________________________________ >>> =A0 =A0 =A0Behave mailing list >>> =A0 =A0 =A0Behave@ietf.org >>> =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/behave >>> >>> >>> >>> >>> >>> -- >>> Regards, >>> >>> Bo Zhou >>> China Mobile >>> >>> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > > > -- > > Magnus Westerlund > > IETF Transport Area Director > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 > F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From magnus.westerlund@ericsson.com Thu Oct 15 06:22:57 2009 Return-Path: <magnus.westerlund@ericsson.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 A67A13A696E for <behave@core3.amsl.com>; Thu, 15 Oct 2009 06:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.219 X-Spam-Level: X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opRCXtL2Wm06 for <behave@core3.amsl.com>; Thu, 15 Oct 2009 06:22:56 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 333F63A6971 for <behave@ietf.org>; Thu, 15 Oct 2009 06:22:56 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-7b-4ad722319065 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 38.03.04191.13227DA4; Thu, 15 Oct 2009 15:22:57 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 15:22:49 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 15:22:48 +0200 Message-ID: <4AD72228.4060209@ericsson.com> Date: Thu, 15 Oct 2009 15:22:48 +0200 From: Magnus Westerlund <magnus.westerlund@ericsson.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Marc Petit-Huguenin <petithug@acm.org> References: <C67BCA34F23E804199B464EAF3BE55DF06439A68@oslexcp2.eu.tandberg.int> <4AB038E2.2070403@viagenie.ca> <4AC4D50F.10605@ericsson.com> <200910011253.40031.simon.perreault@viagenie.ca> <E4561B14EE2A3E4E9D478EBFB5416E1B221309DF@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <4ACE4BCB.9030207@acm.org> In-Reply-To: <4ACE4BCB.9030207@acm.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Oct 2009 13:22:48.0751 (UTC) FILETIME=[97059BF0:01CA4D9A] X-Brightmail-Tracker: AAAAAA== Cc: "behave@ietf.org" <behave@ietf.org>, Tim Polk <tim.polk@nist.gov>, Dave Thaler <dthaler@microsoft.com>, Marc Blanchet <marc.blanchet@viagenie.ca>, Peter Livesey <peter.livesey@tandberg.com> Subject: Re: [BEHAVE] Discusses regarding security mechanism usage for TURN 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, 15 Oct 2009 13:22:57 -0000 Marc Petit-Huguenin skrev: > Dave Thaler wrote: >>> -----Original Message----- >>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >>> Behalf Of Simon Perreault >>> Sent: Thursday, October 01, 2009 9:54 AM >>> To: behave@ietf.org >>> Cc: Tim Polk; Peter Livesey; Marc Blanchet >>> Subject: Re: [BEHAVE] Discusses regarding security mechanism usage for >>> TURN >>> >>> On Thursday 01 October 2009 12:13:03 Magnus Westerlund wrote: >>>> We note that this may fulfill the security requirements. However, the >>>> current draft is substantially lacking in description of the details >>>> that are needed to handle this case. Both how you reliably determine >>>> that a client really is connecting from the trusted domain and how >>> you >>>> ensure that the client know if it needs to use the authentication >>>> mechanism or not. >>> Why must this use case be explained in detail? Is there a rule >>> somewhere that >>> says "each and every "SHOULD" in a document MUST include a complete >>> discussion >>> of the possible use cases for not complying"? If so, then a bunch of >>> RFCs will >>> need to be revised... >>> >>> Just s/MUST/SHOULD/ and be done with it. >>> >>> The Security Considerations section, in particular section 17.1.1, >>> already >>> explain the full implications. People are not stupid. It is plain as >>> day that >>> a TURN server offers a service, and authentication is a good idea if >>> you don't >>> want people abusing the service. >>> >>> I don't think having a MUST instead of a SHOULD will impact in any way >>> the >>> trust that people will have in this protocol. >>> >>> Simon >> Perhaps a conditional MUST would be better than a SHOULD. >> For example: >> >> Unless the server can reliably determine that a client >> is connecting from a trusted network, the server MUST demand >> that all requests from the client be authenticated using this >> mechanism, or that a equally strong or stronger mechanism for >> client authentication is used. Mechanisms for reliably >> determining that a client is connecting from a trusted network >> are outside the scope of this document. >> > > +1 > Good, I think we can go forward with that. I have added an RFC-editor note: Section 4, paragraph 3 (Page 20-21): OLD: [RFC5389] specifies a Long-Term Credential mechanism for STUN. TURN servers and clients MUST implement this mechanism. The server SHOULD demand that all requests from the client be authenticated using this mechanism, and the client MUST be prepared to authenticate requests if required. In general, it is strongly recommended that servers require requests to be authenticated, as the security of TURN can otherwise be quite weak. One reason that a server might not require requests to be authenticated is that TURN is being used in a carefully controlled environment in which the risks of unauthenticated requests by hostile third-parties have been mitigated. See Section 17 for more discussion on this point. NEW: [RFC5389] specifies a Long-Term Credential mechanism for STUN. TURN servers and clients MUST implement this mechanism. Unless the server can reliably determine that a client is connecting from a trusted network, the server MUST demand that all requests from the client be authenticated using this mechanism, or that a equally strong or stronger mechanism for client authentication is used. Mechanisms for reliably determining that a client is connecting from a trusted network are outside the scope of this document. [remove note] I think this implements Dave's proposal in the document. If you see some issues with only doing changes here please indicate so ASAP. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Thu Oct 15 06:33:45 2009 Return-Path: <magnus.westerlund@ericsson.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 302E53A68EE; Thu, 15 Oct 2009 06:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.222 X-Spam-Level: X-Spam-Status: No, score=-6.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBsxEKbUIX+x; Thu, 15 Oct 2009 06:33:44 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id EF3483A68DA; Thu, 15 Oct 2009 06:33:43 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-5a-4ad724b9bfe4 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 82.CA.24026.9B427DA4; Thu, 15 Oct 2009 15:33:45 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 15:33:30 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 15:33:30 +0200 Message-ID: <4AD724A9.2080800@ericsson.com> Date: Thu, 15 Oct 2009 15:33:29 +0200 From: Magnus Westerlund <magnus.westerlund@ericsson.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Hui Deng <denghui02@gmail.com> References: <20090929163001.CBD933A6942@core3.amsl.com> <36a593230910070907p6b6f4be9xf4c344d055587cbf@mail.gmail.com> <0a9101ca4775$9fa951a0$c2f0200a@cisco.com> <4AD31720.3010004@ericsson.com> <1d38a3350910140735le1c87a5y82d9393e14637ac0@mail.gmail.com> In-Reply-To: <1d38a3350910140735le1c87a5y82d9393e14637ac0@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Oct 2009 13:33:30.0066 (UTC) FILETIME=[15468320:01CA4D9C] X-Brightmail-Tracker: AAAAAA== Cc: Dan Wing <dwing@cisco.com>, bo zhou <zhouboyj@gmail.com>, behave@ietf.org, iesg@ietf.org, Dave Thaler <dthaler@microsoft.com> Subject: Re: [BEHAVE] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) 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, 15 Oct 2009 13:33:45 -0000 Hui Deng skrev: > Hi, Magnus, > > Thanks for your advice, we have many people working on the requirement > and motivation draft at the moment as you pointed out here, > Great, looking forward to reading the document. Best Regards Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From wwwrun@core3.amsl.com Thu Oct 15 07:28:19 2009 Return-Path: <wwwrun@core3.amsl.com> X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 891023A696C; Thu, 15 Oct 2009 07:28:19 -0700 (PDT) X-idtracker: yes To: IETF-Announce <ietf-announce@ietf.org> From: The IESG <iesg-secretary@ietf.org> Message-Id: <20091015142819.891023A696C@core3.amsl.com> Date: Thu, 15 Oct 2009 07:28:19 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] Last Call: draft-ietf-behave-turn-uri (Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.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: Thu, 15 Oct 2009 14:28:19 -0000 The IESG has received a request from the Behavior Engineering for Hindrance Avoidance WG (behave) to consider the following document: - 'Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers ' <draft-ietf-behave-turn-uri-03.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-10-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-uri-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18080&rfc_flag=0 From xing@cernet.edu.cn Thu Oct 15 20:04:32 2009 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 D65393A68F3 for <behave@core3.amsl.com>; Thu, 15 Oct 2009 20:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.119 X-Spam-Level: * X-Spam-Status: No, score=1.119 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6myO2W75sNE for <behave@core3.amsl.com>; Thu, 15 Oct 2009 20:04:31 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 92EB43A6835 for <behave@ietf.org>; Thu, 15 Oct 2009 20:04:28 -0700 (PDT) Received: from [59.66.24.140]([59.66.24.140]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm04ad85b2d; Fri, 16 Oct 2009 11:04:30 +0800 Message-ID: <4AD7D16F.3030907@cernet.edu.cn> Date: Fri, 16 Oct 2009 09:50:39 +0800 From: Xing Li <xing@cernet.edu.cn> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Xiangsong Cui <Xiangsong.Cui@huawei.com> References: <20090909091501.EFF623A68BC@core3.amsl.com> <007601ca4178$b791ff40$40106f0a@china.huawei.com> In-Reply-To: <007601ca4178$b791ff40$40106f0a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: RQQHdyWB Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-01.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: Fri, 16 Oct 2009 03:04:32 -0000 Thanks for the info. Note that the extension-header handling is discussed in other places of the document. > If there is no IPv6 Fragment header, the IPv4 header fields are set > > as follows: > > Protocol: Next Header field copied from IPv6 header. > > If any of an IPv6 hop-by-hop options header, destination options > > header, or routing header with the Segments Left field equal to zero > > are present in the IPv6 packet, they are ignored i.e., there is no > > attempt to translate them. However, the Total Length field and the > > Protocol field is adjusted to "skip" these extension headers. > > If the IPv6 packet contains a Fragment header the header fields are > > set as above with the following exceptions: > > Protocol: Next Header value copied from Fragment header. > regards, xing Xiangsong Cui 写é“: > Hello all, > > I'm reading this draft and I have a comment. > > In section 3.1 Translating IPv6 Headers into IPv4 Headers, > for the protocol translation, it says > "Protocol: Next Header field copied from IPv6 header." > > It seems that in the translation procedure, the protocol type > copying is before the IPv6 extension headers' being ignored. > > For the example mentioned in section 4 of [RFC2460], > > +---------------+----------------+------------------------ > | IPv6 header | Routing header | TCP header + data > | | | > | Next Header = | Next Header = | > | Routing | TCP | > +---------------+----------------+------------------------ > The value of Next Header field in IPv6 header is for Routing header. > > So, how about changing this sentence to a clearer statement? > such as "Next Header field copied from IPv6 header if there is no > IPv6 extension header, or copied from the last IPv6 extension header"... > > Regards > Xiangsong > > > ----- Original Message ----- From: <Internet-Drafts@ietf.org> > To: <i-d-announce@ietf.org> > Cc: <behave@ietf.org> > Sent: Wednesday, September 09, 2009 5:15 PM > Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-01.txt > > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Behavior Engineering for Hindrance >> Avoidance Working Group of the IETF. >> >> >> Title : IP/ICMP Translation Algorithm >> Author(s) : X. Li, et al. >> Filename : draft-ietf-behave-v6v4-xlate-01.txt >> Pages : 24 >> Date : 2009-09-09 >> >> This document specifies an update to the Stateless IP/ICMP >> Translation Algorithm (SIIT) described in RFC 2765. The algorithm >> translates between IPv4 and IPv6 packet headers (including ICMP >> headers). >> >> This specification addresses both a stateless and a stateful mode. >> In the stateless mode, translation information is carried in the >> address itself, permitting both IPv4->IPv6 and IPv6->IPv4 session >> establishment without maintaining state in the IP/ICMP translator. >> In the stateful mode, translation state is maintained between IPv4 >> address/transport port tuples and IPv6 address/transport port tuples, >> enabling IPv6 systems to open sessions with IPv4 systems. The choice >> of operational mode is made by the operator deploying the network and >> is critical to the operation of the applications using it. >> >> Significant issues exist in the stateless and stateful modes that are >> not addressed in this document, related to the address assignment and >> the maintenance of the translation tables, respectively. This >> document confines itself to the actual translation. >> >> Acknowledgement of previous work >> >> This document is a product of the 2008-2009 effort to define a >> replacement for NAT-PT. It is an update to and directly derivative >> from Erik Nordmark's [RFC2765], which similarly provides both >> stateless and stateful translation between IPv4 [RFC0791] and IPv6 >> [RFC2460], and between ICMPv4 [RFC0792] and ICMPv6 [RFC4443]. The >> original document was a product of the NGTRANS working group. >> >> The changes in this document reflect five components: >> >> 1. Redescribing the network model to map to present and projected >> >> usage [I-D.ietf-behave-v6v4-framework]. >> >> 2. Moving the address format to the address format document >> >> [I-D.ietf-behave-address-format], to coordinate with other drafts >> >> on the topic. >> >> 3. Describing both stateful and stateless operation. >> 4. Some changes in ICMP. >> >> 5. Updating references. >> >> Requirements >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> document are to be interpreted as described in RFC 2119. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> > > > -------------------------------------------------------------------------------- > > > >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From Xiangsong.Cui@huawei.com Thu Oct 15 23:03:03 2009 Return-Path: <Xiangsong.Cui@huawei.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 75F763A6907 for <behave@core3.amsl.com>; Thu, 15 Oct 2009 23:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwlo-AS15XTJ for <behave@core3.amsl.com>; Thu, 15 Oct 2009 23:03:02 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 171573A6783 for <behave@ietf.org>; Thu, 15 Oct 2009 23:03:02 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRL00BS3FGU4T@szxga03-in.huawei.com> for behave@ietf.org; Fri, 16 Oct 2009 14:02:54 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRL00BV0FGU98@szxga03-in.huawei.com> for behave@ietf.org; Fri, 16 Oct 2009 14:02:54 +0800 (CST) Date: Fri, 16 Oct 2009 14:02:54 +0800 From: Xiangsong Cui <Xiangsong.Cui@huawei.com> To: Xing Li <xing@cernet.edu.cn> Message-id: <00a801ca4e26$4d4a5000$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=UTF-8; reply-type=response Content-transfer-encoding: 8BIT X-Priority: 3 X-MSMail-priority: Normal References: <20090909091501.EFF623A68BC@core3.amsl.com> <007601ca4178$b791ff40$40106f0a@china.huawei.com> <4AD7D16F.3030907@cernet.edu.cn> Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-01.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: Fri, 16 Oct 2009 06:03:03 -0000 Thanks for your detailed explanation, I find the "skip" adjustment in the document. Regards Xiangsong ----- Original Message ----- From: "Xing Li" <xing@cernet.edu.cn> To: "Xiangsong Cui" <Xiangsong.Cui@huawei.com> Cc: <behave@ietf.org> Sent: Friday, October 16, 2009 9:50 AM Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-01.txt > Thanks for the info. > > Note that the extension-header handling is discussed in other places of > the document. > >> If there is no IPv6 Fragment header, the IPv4 header fields are set >> >> as follows: >> >> Protocol: Next Header field copied from IPv6 header. >> > >> If any of an IPv6 hop-by-hop options header, destination options >> >> header, or routing header with the Segments Left field equal to zero >> >> are present in the IPv6 packet, they are ignored i.e., there is no >> >> attempt to translate them. However, the Total Length field and the >> >> Protocol field is adjusted to "skip" these extension headers. >> >> If the IPv6 packet contains a Fragment header the header fields are >> >> set as above with the following exceptions: >> >> Protocol: Next Header value copied from Fragment header. >> > regards, > > xing > > > Xiangsong Cui 写é“: >> Hello all, >> >> I'm reading this draft and I have a comment. >> >> In section 3.1 Translating IPv6 Headers into IPv4 Headers, >> for the protocol translation, it says >> "Protocol: Next Header field copied from IPv6 header." >> >> It seems that in the translation procedure, the protocol type >> copying is before the IPv6 extension headers' being ignored. >> >> For the example mentioned in section 4 of [RFC2460], >> >> +---------------+----------------+------------------------ >> | IPv6 header | Routing header | TCP header + data >> | | | >> | Next Header = | Next Header = | >> | Routing | TCP | >> +---------------+----------------+------------------------ >> The value of Next Header field in IPv6 header is for Routing header. >> >> So, how about changing this sentence to a clearer statement? >> such as "Next Header field copied from IPv6 header if there is no >> IPv6 extension header, or copied from the last IPv6 extension header"... >> >> Regards >> Xiangsong >> >> >> ----- Original Message ----- From: <Internet-Drafts@ietf.org> >> To: <i-d-announce@ietf.org> >> Cc: <behave@ietf.org> >> Sent: Wednesday, September 09, 2009 5:15 PM >> Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-01.txt >> >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Behavior Engineering for Hindrance >>> Avoidance Working Group of the IETF. >>> >>> >>> Title : IP/ICMP Translation Algorithm >>> Author(s) : X. Li, et al. >>> Filename : draft-ietf-behave-v6v4-xlate-01.txt >>> Pages : 24 >>> Date : 2009-09-09 >>> >>> This document specifies an update to the Stateless IP/ICMP >>> Translation Algorithm (SIIT) described in RFC 2765. The algorithm >>> translates between IPv4 and IPv6 packet headers (including ICMP >>> headers). >>> >>> This specification addresses both a stateless and a stateful mode. >>> In the stateless mode, translation information is carried in the >>> address itself, permitting both IPv4->IPv6 and IPv6->IPv4 session >>> establishment without maintaining state in the IP/ICMP translator. >>> In the stateful mode, translation state is maintained between IPv4 >>> address/transport port tuples and IPv6 address/transport port tuples, >>> enabling IPv6 systems to open sessions with IPv4 systems. The choice >>> of operational mode is made by the operator deploying the network and >>> is critical to the operation of the applications using it. >>> >>> Significant issues exist in the stateless and stateful modes that are >>> not addressed in this document, related to the address assignment and >>> the maintenance of the translation tables, respectively. This >>> document confines itself to the actual translation. >>> >>> Acknowledgement of previous work >>> >>> This document is a product of the 2008-2009 effort to define a >>> replacement for NAT-PT. It is an update to and directly derivative >>> from Erik Nordmark's [RFC2765], which similarly provides both >>> stateless and stateful translation between IPv4 [RFC0791] and IPv6 >>> [RFC2460], and between ICMPv4 [RFC0792] and ICMPv6 [RFC4443]. The >>> original document was a product of the NGTRANS working group. >>> >>> The changes in this document reflect five components: >>> >>> 1. Redescribing the network model to map to present and projected >>> >>> usage [I-D.ietf-behave-v6v4-framework]. >>> >>> 2. Moving the address format to the address format document >>> >>> [I-D.ietf-behave-address-format], to coordinate with other drafts >>> >>> on the topic. >>> >>> 3. Describing both stateful and stateless operation. >>> 4. Some changes in ICMP. >>> >>> 5. Updating references. >>> >>> Requirements >>> >>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >>> document are to be interpreted as described in RFC 2119. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-01.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >> >> >> -------------------------------------------------------------------------------- >> >> >> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >> > > From magnus.westerlund@ericsson.com Fri Oct 16 01:34:26 2009 Return-Path: <magnus.westerlund@ericsson.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 1B1503A6863 for <behave@core3.amsl.com>; Fri, 16 Oct 2009 01:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcCvN9iwWXUg for <behave@core3.amsl.com>; Fri, 16 Oct 2009 01:34:24 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 1738E3A659C for <behave@ietf.org>; Fri, 16 Oct 2009 01:34:23 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-56-4ad83012c8bd Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 32.F4.08816.21038DA4; Fri, 16 Oct 2009 10:34:26 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 10:34:26 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 10:34:26 +0200 Message-ID: <4AD83011.6040508@ericsson.com> Date: Fri, 16 Oct 2009 10:34:25 +0200 From: Magnus Westerlund <magnus.westerlund@ericsson.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Magnus Westerlund <magnus.westerlund@ericsson.com> References: <C67BCA34F23E804199B464EAF3BE55DF06439A68@oslexcp2.eu.tandberg.int> <4AB038E2.2070403@viagenie.ca> <4AC4D50F.10605@ericsson.com> <200910011253.40031.simon.perreault@viagenie.ca> <E4561B14EE2A3E4E9D478EBFB5416E1B221309DF@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <4ACE4BCB.9030207@acm.org> <4AD72228.4060209@ericsson.com> In-Reply-To: <4AD72228.4060209@ericsson.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Oct 2009 08:34:26.0078 (UTC) FILETIME=[783CFBE0:01CA4E3B] X-Brightmail-Tracker: AAAAAA== Cc: "behave@ietf.org" <behave@ietf.org>, Tim Polk <tim.polk@nist.gov>, Dave Thaler <dthaler@microsoft.com>, Marc Blanchet <marc.blanchet@viagenie.ca>, Peter Livesey <peter.livesey@tandberg.com> Subject: Re: [BEHAVE] Discusses regarding security mechanism usage for TURN 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, 16 Oct 2009 08:34:26 -0000 Hi, I have had more discussion with Cullen and Tim about this. To get TURN done I have added the following RFC-editor note that requires TURN to use a authentication mechanism. The proponents for the trusted network is going to need to write up the solution in a separate document that updates the TURN spec. This as we ADs thinks this cannot be done quickly and actually requires some substantial additions to the document. Please note that we are not against such work. Only that it not hold up the publication. Thus we need to move forward with what there is agreement on between the WG and the ADs. With the below RFC-editor note, this document can be approved, as both Tim and Cullen has cleared. Any suggestions for correction to the note that implements the must use authentication are welcome ASAP. Note to RFC Editor Section 2.2, first paragraph: OLD: To create an allocation on the server, the client uses an Allocate transaction. The client sends a Allocate request to the server, and the server replies with an Allocate success response containing the allocated relayed transport address. The client can include attributes in the Allocate request that describe the type of allocation it desires (e.g., the lifetime of the allocation). Since relaying data may require lots of bandwidth, the server typically requires that the client authenticate itself using STUN's long-term credential mechanism, to show that it is authorized to use the server. NEW: To create an allocation on the server, the client uses an Allocate transaction. The client sends a Allocate request to the server, and the server replies with an Allocate success response containing the allocated relayed transport address. The client can include attributes in the Allocate request that describe the type of allocation it desires (e.g., the lifetime of the allocation). Since relaying data has security implications, the server requires that the client authenticate itself, typically using STUN's long-term credential mechanism, to show that it is authorized to use the server. Section 4, paragraph 3 (Page 20-21): OLD: [RFC5389] specifies a Long-Term Credential mechanism for STUN. TURN servers and clients MUST implement this mechanism. The server SHOULD demand that all requests from the client be authenticated using this mechanism, and the client MUST be prepared to authenticate requests if required. In general, it is strongly recommended that servers require requests to be authenticated, as the security of TURN can otherwise be quite weak. One reason that a server might not require requests to be authenticated is that TURN is being used in a carefully controlled environment in which the risks of unauthenticated requests by hostile third-parties have been mitigated. See Section 17 for more discussion on this point. NEW: [RFC5389] specifies a Long-Term Credential mechanism for STUN. TURN servers and clients MUST implement this mechanism. The server MUST demand that all requests from the client be authenticated using this mechanism, or that a equally strong or stronger mechanism for client authentication is used. [remove paragrap] Section 6.2, First bullet point in paragraph 2: OLD: 1. The server SHOULD require that the request be authenticated using the Long-Term Credential mechanism of [RFC5389]. NEW: 1. The server MUST require that the request be authenticated. Using the Long-Term Credential mechanism of [RFC5389] unless another mechanism is signaled. Section 16, Third paragraph: OLD: The server follows the recommended practice in this specification of requiring all requests to be authenticated. Thus when the server receives the initial Allocate request, it rejects the request because the request does not contain the authentication attributes. Following the procedures of the Long-Term Credential Mechanism of STUN [RFC5389], the server includes an ERROR-CODE attribute with a value of 401 (Unauthorized), a REALM attribute that specifies the authentication realm used by the server (in this case, the server's domain "example.com"), and a nonce value in a NONCE attribute. The server also includes a SOFTWARE attribute that gives information about the server's software. NEW: Servers requires any request to be authenticated. Thus when the server receives the initial Allocate request, it rejects the request because the request does not contain the authentication attributes. Following the procedures of the Long-Term Credential Mechanism of STUN [RFC5389], the server includes an ERROR-CODE attribute with a value of 401 (Unauthorized), a REALM attribute that specifies the authentication realm used by the server (in this case, the server's domain "example.com"), and a nonce value in a NONCE attribute. The server also includes a SOFTWARE attribute that gives information about the server's software. Section 17, second paragraph: OLD: Note: Most of the attacks on TURN are mitigated by the server requiring requests be authenticated using the Long-Term Credential mechanism of STUN. Thus it is strongly recommended that servers demand that requests be authenticated. However, in certain deployments, the use of this mechanism may be unnecessary. An example might be a deployment where access to the TURN server is available only through a network where their are fairly tight controls over what devices can connect to the network (and by whom) and what software these devices can use. Tightly-run corporate networks can arguably fall into this category. NEW: Most of the attacks on TURN are mitigated by the server requiring requests be authenticated. Thus this specification requires the use of authentication. The mandatory to implement mechanism is the Long-Term Credential mechanism of STUN. Other authentication mechanisms of equal or stronger security properties may be used. However, it is important to ensure that they can be invoked in an inter-operable way. Best Regards Magnus Magnus Westerlund skrev: > Marc Petit-Huguenin skrev: >> Dave Thaler wrote: >>>> -----Original Message----- >>>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >>>> Behalf Of Simon Perreault >>>> Sent: Thursday, October 01, 2009 9:54 AM >>>> To: behave@ietf.org >>>> Cc: Tim Polk; Peter Livesey; Marc Blanchet >>>> Subject: Re: [BEHAVE] Discusses regarding security mechanism usage for >>>> TURN >>>> >>>> On Thursday 01 October 2009 12:13:03 Magnus Westerlund wrote: >>>>> We note that this may fulfill the security requirements. However, the >>>>> current draft is substantially lacking in description of the details >>>>> that are needed to handle this case. Both how you reliably determine >>>>> that a client really is connecting from the trusted domain and how >>>> you >>>>> ensure that the client know if it needs to use the authentication >>>>> mechanism or not. >>>> Why must this use case be explained in detail? Is there a rule >>>> somewhere that >>>> says "each and every "SHOULD" in a document MUST include a complete >>>> discussion >>>> of the possible use cases for not complying"? If so, then a bunch of >>>> RFCs will >>>> need to be revised... >>>> >>>> Just s/MUST/SHOULD/ and be done with it. >>>> >>>> The Security Considerations section, in particular section 17.1.1, >>>> already >>>> explain the full implications. People are not stupid. It is plain as >>>> day that >>>> a TURN server offers a service, and authentication is a good idea if >>>> you don't >>>> want people abusing the service. >>>> >>>> I don't think having a MUST instead of a SHOULD will impact in any way >>>> the >>>> trust that people will have in this protocol. >>>> >>>> Simon >>> Perhaps a conditional MUST would be better than a SHOULD. >>> For example: >>> >>> Unless the server can reliably determine that a client >>> is connecting from a trusted network, the server MUST demand >>> that all requests from the client be authenticated using this >>> mechanism, or that a equally strong or stronger mechanism for >>> client authentication is used. Mechanisms for reliably >>> determining that a client is connecting from a trusted network >>> are outside the scope of this document. >>> >> +1 >> > > Good, I think we can go forward with that. > > I have added an RFC-editor note: > > Section 4, paragraph 3 (Page 20-21): > > OLD: > [RFC5389] specifies a Long-Term Credential mechanism for STUN. TURN > servers and clients MUST implement this mechanism. The server SHOULD > demand that all requests from the client be authenticated using this > mechanism, and the client MUST be prepared to authenticate requests > if required. > > In general, it is strongly recommended that servers require > requests to be authenticated, as the security of TURN can > otherwise be quite weak. One reason that a server might not > require requests to be authenticated is that TURN is being used in > a carefully controlled environment in which the risks of > unauthenticated requests by hostile third-parties have been > mitigated. See Section 17 for more discussion on this point. > > > NEW: > > [RFC5389] specifies a Long-Term Credential mechanism for STUN. TURN > servers and clients MUST implement this mechanism. Unless the server > can reliably determine that a client is connecting from a trusted > network, the server MUST demand that all requests from the client be > authenticated using this mechanism, or that a equally strong or > stronger mechanism for client authentication is used. Mechanisms for > reliably determining that a client is connecting from a trusted > network are outside the scope of this document. > > [remove note] > > > I think this implements Dave's proposal in the document. If you see some > issues with only doing changes here please indicate so ASAP. > > > Cheers > > Magnus Westerlund > > IETF Transport Area Director > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > -- Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From simon.perreault@viagenie.ca Fri Oct 16 05:00:17 2009 Return-Path: <simon.perreault@viagenie.ca> 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 3762E28C207 for <behave@core3.amsl.com>; Fri, 16 Oct 2009 05:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U43ywbA5VogV for <behave@core3.amsl.com>; Fri, 16 Oct 2009 05:00:15 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id 672F128C20F for <behave@ietf.org>; Fri, 16 Oct 2009 05:00:15 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 625E820BE1; Fri, 16 Oct 2009 08:00:19 -0400 (EDT) From: Simon Perreault <simon.perreault@viagenie.ca> Organization: =?iso-8859-1?q?Viag=E9nie?= To: behave@ietf.org Date: Fri, 16 Oct 2009 07:59:39 -0400 User-Agent: KMail/1.12.0 (Linux/2.6.30.5-43.fc11.x86_64; KDE/4.3.0; x86_64; ; ) References: <C67BCA34F23E804199B464EAF3BE55DF06439A68@oslexcp2.eu.tandberg.int> <4AD72228.4060209@ericsson.com> <4AD83011.6040508@ericsson.com> In-Reply-To: <4AD83011.6040508@ericsson.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200910160759.39634.simon.perreault@viagenie.ca> Cc: Marc Blanchet <marc.blanchet@viagenie.ca>, Peter Livesey <peter.livesey@tandberg.com>, Dave Thaler <dthaler@microsoft.com>, Tim Polk <tim.polk@nist.gov> Subject: Re: [BEHAVE] Discusses regarding security mechanism usage for TURN 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, 16 Oct 2009 12:00:17 -0000 On Friday 16 October 2009 04:34:25 Magnus Westerlund wrote: > I have had more discussion with Cullen and Tim about this. To get TURN > done I have added the following RFC-editor note that requires TURN to > use a authentication mechanism. If I understand this clearly, Dave's suggestion, which clearly got WG consensus, is reversed in favour of IESG's previous position? Did I miss anything? Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From magnus.westerlund@ericsson.com Fri Oct 16 06:38:24 2009 Return-Path: <magnus.westerlund@ericsson.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 08D683A6873 for <behave@core3.amsl.com>; Fri, 16 Oct 2009 06:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSi125EJznyG for <behave@core3.amsl.com>; Fri, 16 Oct 2009 06:38:23 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id B13853A6853 for <behave@ietf.org>; Fri, 16 Oct 2009 06:38:22 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-0b-4ad877519b83 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id D2.FB.24026.15778DA4; Fri, 16 Oct 2009 15:38:25 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 15:37:44 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 15:37:43 +0200 Message-ID: <4AD87727.3080406@ericsson.com> Date: Fri, 16 Oct 2009 15:37:43 +0200 From: Magnus Westerlund <magnus.westerlund@ericsson.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Simon Perreault <simon.perreault@viagenie.ca> References: <C67BCA34F23E804199B464EAF3BE55DF06439A68@oslexcp2.eu.tandberg.int> <4AD72228.4060209@ericsson.com> <4AD83011.6040508@ericsson.com> <200910160759.39634.simon.perreault@viagenie.ca> In-Reply-To: <200910160759.39634.simon.perreault@viagenie.ca> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Oct 2009 13:37:43.0713 (UTC) FILETIME=[D6DFB910:01CA4E65] X-Brightmail-Tracker: AAAAAA== Cc: Tim Polk <tim.polk@nist.gov>, Peter Livesey <peter.livesey@tandberg.com>, behave@ietf.org, Dave Thaler <dthaler@microsoft.com>, Marc Blanchet <marc.blanchet@viagenie.ca> Subject: Re: [BEHAVE] Discusses regarding security mechanism usage for TURN 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, 16 Oct 2009 13:38:24 -0000 Simon Perreault skrev: > On Friday 16 October 2009 04:34:25 Magnus Westerlund wrote: >> I have had more discussion with Cullen and Tim about this. To get TURN >> done I have added the following RFC-editor note that requires TURN to >> use a authentication mechanism. > > If I understand this clearly, Dave's suggestion, which clearly got WG > consensus, is reversed in favour of IESG's previous position? Did I miss > anything? What happened was another round of me discussing this topic with Tim and Cullen. That made me realize a few things. Maybe I should have explained better in my previous email about the reversal. Dave's proposal got support from the proponents of the border deployment scenario. There was no one else really providing input. Thus, I wouldn't call it WG consensus. Especially as there has been strong views on this prior in the WG. Cullen claims this discussion simply has worn out all the one that thinks authentication is needed. Especially in regards that BEHAVE has moved onto new topics. I think there is a clear point to this. Thus, we would need to gather a forum where this can be discussed and actually achieve consensus. Secondly, Tim was not that happy with the proposed text unless the border deployment was more substantiated in the document. Cullen requires a spec that is sufficient to implement the border deployment with all its issues. I agree that there are issues in this deployment that needs to be worked out. Thus, border deployment scenario needs description. We have discussed this document for several months since the last update. We are not making progress. TURN now blocks 10+ documents from being published as RFCs. It was time for me to use the decision power I have been given. As a result of the above I mad a decision that gets TURN published. I will also support BEHAVE taking on a new WG document that describes how you can deploy TURN on the border and because of that can configure authentication mechanism differently. Thus I am not preventing the proponents for the border deployment scenario to get what they want, only that we do it without blocking TURN from publication for usage in other scenarios. Best Regards Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From simon.perreault@viagenie.ca Fri Oct 16 07:44:21 2009 Return-Path: <simon.perreault@viagenie.ca> 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 749C63A6A55 for <behave@core3.amsl.com>; Fri, 16 Oct 2009 07:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEVH2vxfZK6Y for <behave@core3.amsl.com>; Fri, 16 Oct 2009 07:44:20 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id 87F2D3A68BA for <behave@ietf.org>; Fri, 16 Oct 2009 07:44:20 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A43C121B8F; Fri, 16 Oct 2009 10:44:24 -0400 (EDT) From: Simon Perreault <simon.perreault@viagenie.ca> Organization: =?iso-8859-1?q?Viag=E9nie?= To: Magnus Westerlund <magnus.westerlund@ericsson.com> Date: Fri, 16 Oct 2009 10:41:47 -0400 User-Agent: KMail/1.12.0 (Linux/2.6.30.5-43.fc11.x86_64; KDE/4.3.0; x86_64; ; ) References: <C67BCA34F23E804199B464EAF3BE55DF06439A68@oslexcp2.eu.tandberg.int> <200910160759.39634.simon.perreault@viagenie.ca> <4AD87727.3080406@ericsson.com> In-Reply-To: <4AD87727.3080406@ericsson.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200910161041.47348.simon.perreault@viagenie.ca> Cc: Tim Polk <tim.polk@nist.gov>, Peter Livesey <peter.livesey@tandberg.com>, behave@ietf.org, Dave Thaler <dthaler@microsoft.com>, Marc Blanchet <marc.blanchet@viagenie.ca> Subject: Re: [BEHAVE] Discusses regarding security mechanism usage for TURN 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, 16 Oct 2009 14:44:21 -0000 Magnus, Thanks for the explanation. I honestly wasn't sure if I was reading the changed text properly. It seemed to me that Dave's suggestion had made everyone happy. Oh well... There is a time for discussion, and there is a time for publishing stuff. Now is time for publishing stuff. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From wwwrun@core3.amsl.com Fri Oct 16 08:04:51 2009 Return-Path: <wwwrun@core3.amsl.com> X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id C1DB03A6978; Fri, 16 Oct 2009 08:04:51 -0700 (PDT) X-idtracker: yes From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> Message-Id: <20091016150451.C1DB03A6978@core3.amsl.com> Date: Fri, 16 Oct 2009 08:04:51 -0700 (PDT) Cc: Internet Architecture Board <iab@iab.org>, behave mailing list <behave@ietf.org>, behave chair <behave-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org> Subject: [BEHAVE] Protocol Action: 'Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)' to Proposed Standard 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, 16 Oct 2009 15:04:51 -0000 The IESG has approved the following document: - 'Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) ' <draft-ietf-behave-turn-16.txt> as a Proposed Standard This document is the product of the Behavior Engineering for Hindrance Avoidance Working Group. The IESG contact persons are Magnus Westerlund and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-16.txt Technical Summary This specification defines a protocol that allows the host to control the operation of a relay and to exchange IPv4/UDP packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it can be also used without ICE. Working Group Summary There is a strong consensus on publishing this document. Some details have had significant discussion and there has been difficult to find the right trade-off between maintaining transport functionality and the desired implementability. Protocol Quality This specification is well reviewed. It also includes the experience of implementations and their deployment. Personell The WG shepherd is Dan Wing and the Responsible AD Magnus Westerlund Note to RFC Editor Section 2.2, first paragraph: OLD: To create an allocation on the server, the client uses an Allocate transaction. The client sends a Allocate request to the server, and the server replies with an Allocate success response containing the allocated relayed transport address. The client can include attributes in the Allocate request that describe the type of allocation it desires (e.g., the lifetime of the allocation). Since relaying data may require lots of bandwidth, the server typically requires that the client authenticate itself using STUN's long-term credential mechanism, to show that it is authorized to use the server. NEW: To create an allocation on the server, the client uses an Allocate transaction. The client sends a Allocate request to the server, and the server replies with an Allocate success response containing the allocated relayed transport address. The client can include attributes in the Allocate request that describe the type of allocation it desires (e.g., the lifetime of the allocation). Since relaying data has security implications, the server requires that the client authenticate itself, typically using STUN's long-term credential mechanism, to show that it is authorized to use the server. Section 4, paragraph 3 (Page 20-21): OLD: [RFC5389] specifies a Long-Term Credential mechanism for STUN. TURN servers and clients MUST implement this mechanism. The server SHOULD demand that all requests from the client be authenticated using this mechanism, and the client MUST be prepared to authenticate requests if required. In general, it is strongly recommended that servers require requests to be authenticated, as the security of TURN can otherwise be quite weak. One reason that a server might not require requests to be authenticated is that TURN is being used in a carefully controlled environment in which the risks of unauthenticated requests by hostile third-parties have been mitigated. See Section 17 for more discussion on this point. NEW: [RFC5389] specifies a Long-Term Credential mechanism for STUN. TURN servers and clients MUST implement this mechanism. The server MUST demand that all requests from the client be authenticated using this mechanism, or that a equally strong or stronger mechanism for client authentication is used. [remove paragraph] Section 6.2, First bullet point in paragraph 2: OLD: 1. The server SHOULD require that the request be authenticated using the Long-Term Credential mechanism of [RFC5389]. NEW: 1. The server MUST require that the request be authenticated. Using the Long-Term Credential mechanism of [RFC5389] unless another mechanism is signaled. Section 16, Third paragraph: OLD: The server follows the recommended practice in this specification of requiring all requests to be authenticated. Thus when the server receives the initial Allocate request, it rejects the request because the request does not contain the authentication attributes. Following the procedures of the Long-Term Credential Mechanism of STUN [RFC5389], the server includes an ERROR-CODE attribute with a value of 401 (Unauthorized), a REALM attribute that specifies the authentication realm used by the server (in this case, the server's domain "example.com"), and a nonce value in a NONCE attribute. The server also includes a SOFTWARE attribute that gives information about the server's software. NEW: Servers requires any request to be authenticated. Thus when the server receives the initial Allocate request, it rejects the request because the request does not contain the authentication attributes. Following the procedures of the Long-Term Credential Mechanism of STUN [RFC5389], the server includes an ERROR-CODE attribute with a value of 401 (Unauthorized), a REALM attribute that specifies the authentication realm used by the server (in this case, the server's domain "example.com"), and a nonce value in a NONCE attribute. The server also includes a SOFTWARE attribute that gives information about the server's software. Section 17, second paragraph: OLD: Note: Most of the attacks on TURN are mitigated by the server requiring requests be authenticated using the Long-Term Credential mechanism of STUN. Thus it is strongly recommended that servers demand that requests be authenticated. However, in certain deployments, the use of this mechanism may be unnecessary. An example might be a deployment where access to the TURN server is available only through a network where their are fairly tight controls over what devices can connect to the network (and by whom) and what software these devices can use. Tightly-run corporate networks can arguably fall into this category. NEW: Most of the attacks on TURN are mitigated by the server requiring requests be authenticated. Thus this specification requires the use of authentication. The mandatory to implement mechanism is the Long-Term Credential mechanism of STUN. Other authentication mechanisms of equal or stronger security properties may be used. However, it is important to ensure that they can be invoked in an inter-operable way. From magnus.westerlund@ericsson.com Mon Oct 19 00:38:23 2009 Return-Path: <magnus.westerlund@ericsson.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 006DF3A67FD for <behave@core3.amsl.com>; Mon, 19 Oct 2009 00:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.237 X-Spam-Level: X-Spam-Status: No, score=-6.237 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRtfMmhcm0ub for <behave@core3.amsl.com>; Mon, 19 Oct 2009 00:38:22 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 116DB3A67D9 for <behave@ietf.org>; Mon, 19 Oct 2009 00:38:21 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-53-4adc1772f763 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id EF.00.08816.2771CDA4; Mon, 19 Oct 2009 09:38:26 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 09:36:52 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 09:36:51 +0200 Message-ID: <4ADC1713.10709@ericsson.com> Date: Mon, 19 Oct 2009 09:36:51 +0200 From: Magnus Westerlund <magnus.westerlund@ericsson.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Simon Perreault <simon.perreault@viagenie.ca> References: <C67BCA34F23E804199B464EAF3BE55DF06439A68@oslexcp2.eu.tandberg.int> <200910160759.39634.simon.perreault@viagenie.ca> <4AD87727.3080406@ericsson.com> <200910161041.47348.simon.perreault@viagenie.ca> In-Reply-To: <200910161041.47348.simon.perreault@viagenie.ca> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 19 Oct 2009 07:36:51.0672 (UTC) FILETIME=[EC7DB580:01CA508E] X-Brightmail-Tracker: AAAAAA== Cc: Tim Polk <tim.polk@nist.gov>, Peter Livesey <peter.livesey@tandberg.com>, behave@ietf.org, Dave Thaler <dthaler@microsoft.com>, Marc Blanchet <marc.blanchet@viagenie.ca> Subject: Re: [BEHAVE] Discusses regarding security mechanism usage for TURN 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, 19 Oct 2009 07:38:23 -0000 Simon Perreault skrev: > Magnus, > > Thanks for the explanation. I honestly wasn't sure if I was reading the > changed text properly. It seemed to me that Dave's suggestion had made > everyone happy. Oh well... There is a time for discussion, and there is a time > for publishing stuff. Now is time for publishing stuff. I am sorry that Cullen hasn't taken the time expressing his comments on the list, and that discussion mostly happened on phone conferences within the IESG. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From root@core3.amsl.com Mon Oct 19 07:00:02 2009 Return-Path: <root@core3.amsl.com> X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 22B7628C0E9; Mon, 19 Oct 2009 07:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091019140002.22B7628C0E9@core3.amsl.com> Date: Mon, 19 Oct 2009 07:00:02 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-framework-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: Mon, 19 Oct 2009 14:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Framework for IPv4/IPv6 Translation Author(s) : F. Baker, et al. Filename : draft-ietf-behave-v6v4-framework-02.txt Pages : 31 Date : 2009-10-19 This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing NAT-PT, which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-framework-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-v6v4-framework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-19064756.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 19 07:00:02 2009 Return-Path: <root@core3.amsl.com> X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2C8E63A689A; Mon, 19 Oct 2009 07:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091019140002.2C8E63A689A@core3.amsl.com> Date: Mon, 19 Oct 2009 07:00:02 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-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: Mon, 19 Oct 2009 14:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : IP/ICMP Translation Algorithm Author(s) : X. Li, et al. Filename : draft-ietf-behave-v6v4-xlate-02.txt Pages : 25 Date : 2009-10-19 This document specifies an update to the Stateless IP/ICMP Translation Algorithm (SIIT) described in RFC 2765. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers). This specification addresses both a stateless and a stateful mode. In the stateless mode, translation information is carried in the address itself, permitting both IPv4->IPv6 and IPv6->IPv4 session establishment without maintaining state in the IP/ICMP translator. In the stateful mode, translation state is maintained between IPv4 address/transport port tuples and IPv6 address/transport port tuples, enabling IPv6 systems to open sessions with IPv4 systems. The choice of operational mode is made by the operator deploying the network and is critical to the operation of the applications using it. Significant issues exist in the stateless and stateful modes that are not addressed in this document, related to the address assignment and the maintenance of the translation tables, respectively. This document confines itself to the actual translation. Acknowledgement of previous work This document is a product of the 2008-2009 effort to define a replacement for NAT-PT. It is an update to and directly derivative from Erik Nordmark's [RFC2765], which similarly provides both stateless and stateful translation between IPv4 [RFC0791] and IPv6 [RFC2460], and between ICMPv4 [RFC0792] and ICMPv6 [RFC4443]. The original document was a product of the NGTRANS working group. The changes in this document reflect five components: 1. Redescribing the network model to map to present and projected usage [I-D.ietf-behave-v6v4-framework]. 2. Moving the address format to the address format document [I-D.ietf-behave-address-format], to coordinate with other drafts on the topic. 3. Describing both stateful and stateless operation. 4. Some changes in ICMP. 5. Updating references. Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-v6v4-xlate-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-19064944.I-D@ietf.org> --NextPart-- From mohamed.boucadair@orange-ftgroup.com Mon Oct 19 07:51:05 2009 Return-Path: <mohamed.boucadair@orange-ftgroup.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 1113528C1A9 for <behave@core3.amsl.com>; Mon, 19 Oct 2009 07:51:05 -0700 (PDT) X-Quarantine-ID: <QD+fdJA8RBni> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 QD+fdJA8RBni for <behave@core3.amsl.com>; Mon, 19 Oct 2009 07:51:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id C00D828C0FA for <behave@ietf.org>; Mon, 19 Oct 2009 07:51:03 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id BE9F72AC156 for <behave@ietf.org>; Mon, 19 Oct 2009 16:51:09 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 9FCF8180042; Mon, 19 Oct 2009 16:51:09 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Mon, 19 Oct 2009 16:51:09 +0200 From: <mohamed.boucadair@orange-ftgroup.com> To: "behave@ietf.org" <behave@ietf.org> Date: Mon, 19 Oct 2009 16:51:08 +0200 Thread-Topic: DNS64 Service discovery Thread-Index: AcpQhaSjUStSDdrqTjip+uyhzJ/FLQARbc/A Message-ID: <17511_1255963869_4ADC7CDD_17511_10270_1_94C682931C08B048B7A8645303FDC9F30781AA4C81@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/mixed; boundary="_002_94C682931C08B048B7A8645303FDC9F30781AA4C81PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.10.19.142117 Cc: BURGEY Eric RD-CORE <eric.burgey@orange-ftgroup.com> Subject: [BEHAVE] DNS64 Service discovery 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, 19 Oct 2009 14:51:05 -0000 --_002_94C682931C08B048B7A8645303FDC9F30781AA4C81PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Dear all, A new draft on DNS64 service discovery has been submitted. Comments, suggestions, inputs and questions are more than welcome. Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de Internet-Drafts@ietf.org Envoy=E9 : lundi 19 octobre 2009 08:30 =C0 : i-d-announce@ietf.org Objet : I-D Action:draft-boucadair-behave-dns64-discovery-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : DNS64 Service Location and Discovery Author(s) : M. Boucadair, E. Burgey Filename : draft-boucadair-behave-dns64-discovery-00.txt Pages : 12 Date : 2009-10-18 This memo proposes a set of solutions for the discovery of DNS64 [I-D.ietf-= behave-dns64] service. Three solution candidates are proposed: SRV RR, DHCP and RA-based. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boucadair-behave-dns64-discovery-= 00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementa= tion to automatically retrieve the ASCII version of the Internet-Draft. ********************************* 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. ******************************** --_002_94C682931C08B048B7A8645303FDC9F30781AA4C81PUEXCB1Bnante_ Content-Type: message/external-body; name="draft-boucadair-behave-dns64-discovery-00.url" Content-Description: draft-boucadair-behave-dns64-discovery-00.url Content-Disposition: attachment; filename="draft-boucadair-behave-dns64-discovery-00.url"; size=106; creation-date="Mon, 19 Oct 2009 08:30:25 GMT"; modification-date="Mon, 19 Oct 2009 08:30:25 GMT" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1ib3VjYWRhaXItYmVoYXZlLWRuczY0LWRpc2NvdmVyeS0wMC50eHQNCg== --_002_94C682931C08B048B7A8645303FDC9F30781AA4C81PUEXCB1Bnante_-- From petithug@acm.org Mon Oct 19 10:19:04 2009 Return-Path: <petithug@acm.org> 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 834153A68D0 for <behave@core3.amsl.com>; Mon, 19 Oct 2009 10:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.619 X-Spam-Level: X-Spam-Status: No, score=-101.619 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MISSING_HEADERS=1.292, 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 340y2AwviKoo for <behave@core3.amsl.com>; Mon, 19 Oct 2009 10:19:03 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id C838C3A681C for <behave@ietf.org>; Mon, 19 Oct 2009 10:19:00 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id ADD7C6C98532; Mon, 19 Oct 2009 17:19:07 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id B27F66C9852C for <behave@ietf.org>; Mon, 19 Oct 2009 17:19:06 +0000 (UTC) Message-ID: <4ADC9F88.4000506@acm.org> Date: Mon, 19 Oct 2009 10:19:04 -0700 From: Marc Petit-Huguenin <petithug@acm.org> User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 CC: behave@ietf.org References: <20091014124502.096463A69EF@core3.amsl.com> In-Reply-To: <20091014124502.096463A69EF@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-ipv6-07.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: Mon, 19 Oct 2009 17:19:04 -0000 Some comments on this I-D: - Section 1, 2nd paragraph: "This document also defines and registers a new error response code with the value 444[...]" The document also defines error response code 443. - Section 3, 2nd paragraph: "Assuming the request is authenticated and has not been tampered with[...]" "has not been tampered with" is redundant. - Section 4.2, 1st paragraph: The action and error code to use in case of RESERVATION-TOKEN present are missing. - Section 4.2, 5th and 6th: I think that it should be explicitly specified that a TURN server implementing this I-D but not supporting IPv4 allocation (i.e. only IPv4-IPv6 and IPv6-IPv6) must return a 440 if the Allocate request received does not contain a REQUESTED-ADDRESS-FAMILY attribute. - Section 5.2: Returning a 443 is probably better, at least if the family does not match the Allocation. - Section 8.3, last paragraph: The DONT-FRAGMENT attribute should be followed for an IPv6 to IPv4 translation. - Section 10.2: The 443 error code is missing. Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. > > > Title : Traversal Using Relays around NAT (TURN) Extension for IPv6 > Author(s) : S. Perreault, et al. > Filename : draft-ietf-behave-turn-ipv6-07.txt > Pages : 13 > Date : 2009-10-14 > > This document adds IPv6 support to Traversal Using Relays around NAT > (TURN). IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, > and IPv6-to-IPv4 relaying. This document defines the REQUESTED- > ADDRESS-FAMILY attribute for TURN. The REQUESTED-ADDRESS-FAMILY > attribute allows a client to explicitly request the address type the > TURN server will allocate (e.g., an IPv4-only node may request the > TURN server to allocate an IPv6 address). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-ipv6-07.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From root@core3.amsl.com Mon Oct 19 11:00:02 2009 Return-Path: <root@core3.amsl.com> X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1AFBE3A692D; Mon, 19 Oct 2009 11:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091019180002.1AFBE3A692D@core3.amsl.com> Date: Mon, 19 Oct 2009 11:00:01 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.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: Mon, 19 Oct 2009 18:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers Author(s) : M. Bagnulo, et al. Filename : draft-ietf-behave-dns64-01.txt Pages : 29 Date : 2009-10-19 DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-dns64-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-dns64-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-19105346.I-D@ietf.org> --NextPart-- From ajs@shinkuro.com Mon Oct 19 11:15:54 2009 Return-Path: <ajs@shinkuro.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 1648F28C0E2 for <behave@core3.amsl.com>; Mon, 19 Oct 2009 11:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.533 X-Spam-Level: X-Spam-Status: No, score=-1.533 tagged_above=-999 required=5 tests=[AWL=1.066, 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 dHJCWHyx7-Nr for <behave@core3.amsl.com>; Mon, 19 Oct 2009 11:15:53 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 590C328C12B for <behave@ietf.org>; Mon, 19 Oct 2009 11:15:53 -0700 (PDT) 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 7874D2FE8CDC for <behave@ietf.org>; Mon, 19 Oct 2009 18:15:59 +0000 (UTC) Date: Mon, 19 Oct 2009 14:15:56 -0400 From: Andrew Sullivan <ajs@shinkuro.com> To: behave@ietf.org Message-ID: <20091019181555.GC9536@shinkuro.com> References: <20091019180002.1AFBE3A692D@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091019180002.1AFBE3A692D@core3.amsl.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.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: Mon, 19 Oct 2009 18:15:54 -0000 Dear colleagues, On Mon, Oct 19, 2009 at 11:00:01AM -0700, Internet-Drafts@ietf.org wrote: > Title : DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers > Author(s) : M. Bagnulo, et al. > Filename : draft-ietf-behave-dns64-01.txt > Pages : 29 > Date : 2009-10-19 I believe that the draft addresses all the concerns raised since the last draft. The editors would appreciate feedback. I was late getting this to the others, so any errors or omissions you can blame on me alone. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From root@core3.amsl.com Mon Oct 19 12:30:03 2009 Return-Path: <root@core3.amsl.com> X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E77E73A6892; Mon, 19 Oct 2009 12:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091019193002.E77E73A6892@core3.amsl.com> Date: Mon, 19 Oct 2009 12:30:02 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-turn-tcp-05.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: Mon, 19 Oct 2009 19:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations Author(s) : S. Perreault, J. Rosenberg Filename : draft-ietf-behave-turn-tcp-05.txt Pages : 13 Date : 2009-10-19 This specification defines an extension of Traversal Using Relays around NAT (TURN), a relay protocol for NAT traversal, to allow a TURN client to request TCP allocations, and defines new requests and indications for the TURN server to open and accept TCP connections with the client's peers. TURN and this extension both purposefully restrict the ways in which the relayed address can be used. In particular, it prevents users from running general purpose servers from ports obtained from the TURN server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-tcp-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-turn-tcp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-19121511.I-D@ietf.org> --NextPart-- From simon.perreault@viagenie.ca Mon Oct 19 12:48:52 2009 Return-Path: <simon.perreault@viagenie.ca> 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 528B428C131 for <behave@core3.amsl.com>; Mon, 19 Oct 2009 12:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.671 X-Spam-Level: X-Spam-Status: No, score=-1.671 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_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 TeVSYTHxpS8Y for <behave@core3.amsl.com>; Mon, 19 Oct 2009 12:48:51 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id ED1C728C10E for <behave@ietf.org>; Mon, 19 Oct 2009 12:48:50 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id 6682721BB7 for <behave@ietf.org>; Mon, 19 Oct 2009 15:48:54 -0400 (EDT) Message-ID: <4ADCC2A6.2020102@viagenie.ca> Date: Mon, 19 Oct 2009 15:48:54 -0400 From: Simon Perreault <simon.perreault@viagenie.ca> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4 MIME-Version: 1.0 To: behave@ietf.org References: <20091019193002.E77E73A6892@core3.amsl.com> In-Reply-To: <20091019193002.E77E73A6892@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-tcp-05.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: Mon, 19 Oct 2009 19:48:52 -0000 Internet-Drafts@ietf.org wrote, on 2009-10-19 15:30: > Title : Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations > Author(s) : S. Perreault, J. Rosenberg > Filename : draft-ietf-behave-turn-tcp-05.txt > Pages : 13 > Date : 2009-10-19 This new version addresses the comments received during WGLC. As far as I know, all of them have been addressed. In particular: - Clarification, wording, etc. - Explicitly state the one outgoing connection per allocation maximum. - Removed the unnecessary restriction on interpretation of tunnelled data. - Explicitly allow TCP keep-alives between client and server. - Allow servers to arbitrarily deny connections based on local policy. - Added 30 seconds timeout for receiving ConnectionBind request. - Added security consideration on buffer size and possibility of DoS. See here for a full diff: http://tools.ietf.org/rfcdiff?url2=draft-ietf-behave-turn-tcp-05.txt Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From dwing@cisco.com Mon Oct 19 12:55:16 2009 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 91F723A68C1 for <behave@core3.amsl.com>; Mon, 19 Oct 2009 12:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUksqO6KP3LF for <behave@core3.amsl.com>; Mon, 19 Oct 2009 12:55:15 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 7B7323A6903 for <behave@ietf.org>; Mon, 19 Oct 2009 12:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1903; q=dns/txt; s=sjiport03001; t=1255982122; x=1257191722; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Dan=20Wing"=20<dwing@cisco.com>|Subject:=20Agen da=20requests=20[was=20RE:=20presentation=20requests=20an d=20cutoff=20dates]|Date:=20Mon,=2019=20Oct=202009=2012:5 5:22=20-0700|Message-ID:=20<004d01ca50f6$17de1e10$c4f0200 a@cisco.com>|To:=20<behave@ietf.org>|Cc:=20"'Dave=20Thale r'"=20<dthaler@microsoft.com>|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20 |References:=20; bh=TYmj8VmMvM1fySaNeIXCKD4MAf5qHgXN9Lm7CAW+z8k=; b=ZVDhS+n9+ep969HCyWDzF4D0S7ZXxfHex6cXorn7c8YU8hN7soca8nHs 7XyamEqRqcuCoegZSFIKNt0Efy5Hzfw6NLVoVoJI5KVuBwWXuXdONrsb0 3mhTvGZlxvALGOBH7HvFLGHa2eHdCqRImfMMMPy3zX1gtyFjTL5PdwJ0n c=; Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAPNg3EqrR7Hu/2dsb2JhbACKYLkklw+EMQQ X-IronPort-AV: E=Sophos;i="4.44,587,1249257600"; d="scan'208";a="197489236" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 19 Oct 2009 19:55:22 +0000 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9JJtM48013266; Mon, 19 Oct 2009 19:55:22 GMT From: "Dan Wing" <dwing@cisco.com> To: <behave@ietf.org> References: Date: Mon, 19 Oct 2009 12:55:22 -0700 Message-ID: <004d01ca50f6$17de1e10$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpKlCqFfYsJVDnoS4eVVuM+zP/mxAGYQbRA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: Cc: 'Dave Thaler' <dthaler@microsoft.com> Subject: [BEHAVE] Agenda requests [was RE: presentation requests and cutoff dates] 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, 19 Oct 2009 19:55:16 -0000 Once again, SEND YOUR AGENDA REQUESTS. I have received only a few. Our preliminary agenda is now published at http://www.ietf.org/proceedings/09nov/agenda/behave.html but as you can see I have received only a few agenda requests. The chairs struggled with scheduling at the last meeting which was due to last minute agenda requests. We are not interested in repeating this experience. Send agenda requests to me or behave-chairs@tools.ietf.org. -d > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Sunday, October 11, 2009 9:59 AM > To: 'behave@ietf.org' > Subject: presentation requests and cutoff dates > > If you want to present in Hiroshima, please send me email with: > > * name of presenter > * topic (what will be presented; this might or might not be > the Internet Draft itself. For example, it could be a > discussion of implementation experience) > * name of associated Internet Draft(s) > * requested time > > Last minute presentation requests may be refused. We > received a lot of last-minute presentation requests for the > last IETF (Stockholm), and this made scheduling the meetings > unnecessarily difficult, and also meant many WG participants > had no time to read individual submissions. Please make the > WG aware of new drafts, and get on the agenda early, so that > the meeting time can be best utilized discussing technology, > rather than the meeting being the first time a new idea is > first seen. Thanks. > > > As a reminder, IETF cutoff dates for new (-00) Internet > Drafts is 2009-10-19 (Monday) by 17:00 PDT (24:00 UTC/GMT), > and revised Internet Drafts is 2009-10-26 (Monday) by 17:00 > PDT (24:00 UTC/GMT). Internet Drafts are submitted using > https://datatracker.ietf.org/idst/upload.cgi or email to > internet-drafts@ietf.org. > > -d > > From iljitsch@muada.com Mon Oct 19 13:38:15 2009 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 273BC3A6981 for <behave@core3.amsl.com>; Mon, 19 Oct 2009 13:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DV97hbEKJbth for <behave@core3.amsl.com>; Mon, 19 Oct 2009 13:38:14 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 795E53A698E for <behave@ietf.org>; Mon, 19 Oct 2009 13:35:49 -0700 (PDT) Received: from [192.168.0.193] (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 n9JKZNxt066745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <behave@ietf.org>; Mon, 19 Oct 2009 22:35:24 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <BAC17CEA-BBD0-4760-8821-B406050555D2@muada.com> From: Iljitsch van Beijnum <iljitsch@muada.com> To: Behave WG <behave@ietf.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 19 Oct 2009 22:35:48 +0200 References: <20091019203200.BB91D28C154@core3.amsl.com> X-Mailer: Apple Mail (2.936) Subject: [BEHAVE] Fwd: New Version Notification for draft-van-beijnum-behave-ftp64-06 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, 19 Oct 2009 20:38:15 -0000 Hi all, Here's a new version of the FTP64 draft. As far as I know, it addresses all comments made by everyone previously. (I haven't carefully read for spelling and grammar yet, though.) Please let me know if you have any new comments, or if I managed to overlook an old one. Thanks, Iljitsch Begin forwarded message: > From: IETF I-D Submission Tool <idsubmission@ietf.org> > Date: 19 oktober 2009 22:32:00 GMT+02:00 > To: iljitsch@muada.com > Subject: New Version Notification for draft-van-beijnum-behave- > ftp64-06 > > > A new version of I-D, draft-van-beijnum-behave-ftp64-06.txt has been > successfuly submitted by Iljitsch van Beijnum and posted to the IETF > repository. > > Filename: draft-van-beijnum-behave-ftp64 > Revision: 06 > Title: IPv6-to-IPv4 translation FTP considerations > Creation_date: 2009-10-19 > WG ID: Independent Submission > Number_of_pages: 12 > > Abstract: > The File Transfer Protocol has a very long history, and despite the > fact that today, other options exist to perform file transfers, FTP > is still in common use. As such, it is important that in the > situation where some client computers are IPv6-only while many > servers are still IPv4-only and IPv6-to-IPv4 translators are used to > bridge that gap, FTP is made to work through these translators as > best it can. > > FTP has an active and a passive mode, both as original commands that > are IPv4-specific, and as extended, IP version agnostic commands. > The only FTP mode that works without changes through an IPv6-to-IPv4 > translator is extended passive. However, many existing FTP servers > don't support this mode, and some clients don't ask for it. This > document describes server, client and middlebox (if any) behavior > that minimizes this problem. > > > > The IETF Secretariat. > From charliep@wichorus.com Mon Oct 19 14:15:56 2009 Return-Path: <charliep@wichorus.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 25D603A6926 for <behave@core3.amsl.com>; Mon, 19 Oct 2009 14:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 ugytjYMuUf5X for <behave@core3.amsl.com>; Mon, 19 Oct 2009 14:15:55 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 4EA8D3A680C for <behave@ietf.org>; Mon, 19 Oct 2009 14:15:55 -0700 (PDT) Received: from [12.204.153.98] (helo=[10.166.254.13]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charliep@wichorus.com>) id 1MzzaE-00067M-AQ for behave@ietf.org; Mon, 19 Oct 2009 17:16:02 -0400 Message-ID: <4ADCD710.5070302@wichorus.com> Date: Mon, 19 Oct 2009 14:16:00 -0700 From: "Charles E. Perkins" <charliep@wichorus.com> Organization: WiChorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "behave@ietf.org" <behave@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52488ba78ce198942218ba7c1c08b0d4ec350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Subject: [BEHAVE] SIPNAT documents posted 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, 19 Oct 2009 21:15:56 -0000 Hello folks, At 1:59:30pm Pacific Time today, I posted the following draft: "Payload-assisted Delivery for SIPNAT" http://www.ietf.org/internet-drafts/draft-perkins-behave-dpinat-00.txt There is also a revision to the base SIPNAT document: "Translating IPv4 to IPv6 based on source IPv4 address" http://www.ietf.org/internet-drafts/draft-perkins-sourceipnat-01.txt Comments are appreciated. Thanks to those who have helped me to improve these documents before submission. Regards, Charlie P. From dwing@cisco.com Mon Oct 19 17:03:48 2009 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 EC1D228C0E5 for <behave@core3.amsl.com>; Mon, 19 Oct 2009 17:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.292 X-Spam-Level: X-Spam-Status: No, score=-6.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLcUrP520uY1 for <behave@core3.amsl.com>; Mon, 19 Oct 2009 17:03:48 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 270133A699A for <behave@ietf.org>; Mon, 19 Oct 2009 17:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1694; q=dns/txt; s=sjiport06001; t=1255997035; x=1257206635; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Dan=20Wing"=20<dwing@cisco.com>|Subject:=20Conc erns=20with=20IPv4=20Applications=20Accessing=20IPv6=20Se rvers=20(NAT46)=20-=20draft-wing-behave-v4app-v6server-00 |Date:=20Mon,=2019=20Oct=202009=2017:03:49=20-0700 |Message-ID:=20<025401ca5118$cd0062e0$c4f0200a@cisco.com> |To:=20"Behave=20WG"=20<behave@ietf.org>|Cc:=20"'Cameron =20Byrne'"=20<Cameron.Byrne@T-Mobile.com>|MIME-Version: =201.0|Content-Transfer-Encoding:=207bit; bh=xVDNLBcSbw9rqNhIi2UaL9jI4+OkGBfGy4grDGShWWI=; b=DKHp28IRzFWRTMdDqEcpVMYXTP/yyqyv2pSmdSSpIU9oXx1Qt9gQnaEy bN2KMFQYrKKpBn9KqCzR3ScqGDnbN+wLaIR/mqKsOZImkxClzD3kEnTDS H9iS9Hb8s801xdA8DwIVSDe44+ZPoKwZbIC6L4suZG7PSYJekkPQKUIZF 8=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEANea3EqrR7H+/2dsb2JhbACKYLgClz+EMQSBWw X-IronPort-AV: E=Sophos;i="4.44,587,1249257600"; d="scan'208";a="412994578" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 20 Oct 2009 00:03:49 +0000 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9K03n90022459; Tue, 20 Oct 2009 00:03:49 GMT From: "Dan Wing" <dwing@cisco.com> To: "Behave WG" <behave@ietf.org> Date: Mon, 19 Oct 2009 17:03:49 -0700 Message-ID: <025401ca5118$cd0062e0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpRGMzEbpNLHFV/QkCvPq+dA6w8Eg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: 'Cameron Byrne' <Cameron.Byrne@T-Mobile.com> Subject: [BEHAVE] Concerns with IPv4 Applications Accessing IPv6 Servers (NAT46) - draft-wing-behave-v4app-v6server-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: Tue, 20 Oct 2009 00:03:49 -0000 Hi. Today we submitted "Concerns with IPv4 Applications Accessing IPv6 Servers (NAT46)", which discusses concerns with IPv4 applications accessing IPv6 servers. PNAT is analyzed in detail, but Virtual IPv6 Connectivity seems to have similar drawbacks. The largest concern is the potential harm for V6 deployment. The concern is that the introduction of an AAAA record on a server will change the operation mode of a client from NAT464 to NAT46, causing different code paths to be taken. This is quite different from today's behavior: adding a new resource record to a server, such an an AAAA record (or any other type of record), has no effect on applications that don't query that resource record. The draft also demonstrates that an ALG is necessary once the operation mode is NAT46 for the protocol examined in detail, which is FTP. Others might be interested in examining other protocols (SIP, H.323, RTSP, HTTP with IPv4 address literals, and so on), and how those might need an ALG to fully function with NAT464 or with NAT46. Abstract: Bump-in-the-Stack and Bump-in-the-API allow IPv4 applications to access IPv6 servers. This is done by using in-host NAT46 translator. When used in conjunction with an in-network NAT64, it is also possible for the IPv4 application to access an IPv4 server via an IPv6-only network. This document describes how these functions work in detail, and discusses some concerns especially around IPv4 applications accessing IPv6 servers. These concerns can be reduced by not having IPv4 applications access IPv6 servers. http://tools.ietf.org/html/draft-wing-behave-v4app-v6server-00 -d From dwing@cisco.com Mon Oct 19 17:49:19 2009 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 376FB3A687C; Mon, 19 Oct 2009 17:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.053 X-Spam-Level: X-Spam-Status: No, score=-6.053 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPsAUG+fMx-l; Mon, 19 Oct 2009 17:49:18 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 47EBF3A681A; Mon, 19 Oct 2009 17:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2379; q=dns/txt; s=sjiport06001; t=1255999766; x=1257209366; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Dan=20Wing"=20<dwing@cisco.com>|Reply-To:=20<v6 ops@ops.ietf.org>|Subject:=20Building=20IPv6=20Applicatio ns=20which=20Access=20IPv4=20Servers=20-=20draft-wing-v6o ps-v6app-v4server-00|Date:=20Mon,=2019=20Oct=202009=2017: 49:25=20-0700|Message-ID:=20<028701ca511f$2bf3bb70$c4f020 0a@cisco.com>|To:=20"'IPv6=20Operations'"=20<v6ops@ops.ie tf.org>,=20<apps-discuss@ietf.org>,=0D=0A=20=20=20=20=20 =20=20=20"Behave=20WG"=20<behave@ietf.org>|MIME-Version: =201.0|Content-Transfer-Encoding:=207bit; bh=lrSODG7T8yLiaWzd2jrZf+Scn2LpUHpoafo+R4HlVtg=; b=fjAocG3lC+cSQVV8B75IMw96i5zbVZnXsiKRITmreveFe8pTWyr8ufkE 7CHDWYpDGiSHKKPTov/GKoPFQDQl5oPcf6d7OQyzBRPTTo3qZkoSktROI 0Rx598l6zaCwQfXDe1cTlsbAuWfolhz658RVwqXV/VGU0+e599U6X717V 4=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAJ+l3EqrR7Hu/2dsb2JhbACKYLdfl0uEMQSBWw X-IronPort-AV: E=Sophos;i="4.44,588,1249257600"; d="scan'208";a="413019968" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 20 Oct 2009 00:49:25 +0000 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9K0nPXO025680; Tue, 20 Oct 2009 00:49:25 GMT From: "Dan Wing" <dwing@cisco.com> To: "'IPv6 Operations'" <v6ops@ops.ietf.org>, <apps-discuss@ietf.org>, "Behave WG" <behave@ietf.org> Date: Mon, 19 Oct 2009 17:49:25 -0700 Message-ID: <028701ca511f$2bf3bb70$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpRHyuxTiUCYKaIT2eZtZLH/JbKZg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: [BEHAVE] Building IPv6 Applications which Access IPv4 Servers - draft-wing-v6ops-v6app-v4server-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: v6ops@ops.ietf.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: Tue, 20 Oct 2009 00:49:19 -0000 (Please reply to v6ops@ops.ietf.org) V6Ops, Apps-Discuss, Behave, I just submitted a short draft, "Building IPv6 Applications which Access IPv4 Servers" which may be interesting to apps area, behave, and v6ops, as it has some bearing on each. The document applies to IPv6 hosts operating in BEHAVE's scenarios 1 ("an IPv6 network to IPv4 Internet"), and scenario 5 ("an IPv6 network to an IPv4 network"). It explains that while DNS64 and 6/4 translation is helpful and functional for many IPv6 applications, there are some IPv6 applications that will need to additional functionality -- either (a) in the application itself using the translator (e.g., an IPv6 SIP application could be extended to do this) or (b) using some sort of application-level proxy functionality (e.g., a SIP application can use a TURN-IPv6 relay; an HTTP application can use an HTTP proxy that is connected to IPv4 and IPv6). The purpose of this document is to examine 6/4 translation in more detail, and show what IPv6 applications need to add so that we can avoid Application Layer Gateways (ALGs) in hosts, in CPEs, and in 6/4 translators. Some protocols, notably SIP, have already finished their efforts to explain how the protocol will transition to IPv6 (in fact, two SIP documents explain two different mechanisms; that might not be a bad thing). Other protocols such as FTP are being examined by BEHAVE. Other protocols, such as RTSP, XMPP, and probably others, I have no idea of their status regarding IPv6 and if/how they have decided to handle IPv6-only applications communicating with IPv4 addresses. This draft hopes to start that discussion. Abstract: When an application runs on a host or network that only supports IPv6 ("IPv6-only"), it is sometimes necessary that the application communicate with IPv4 peers. When that communication involves DNS, DNS64 and a 6/4 translator works well without any changes to most applications. However, when that communication does not involve DNS, it can require additional features be configured on or programmed into the IPv6 application. This document explains why this functionality is important and describes mechanisms for applications to provide such functionality. http://tools.ietf.org/html/draft-wing-v6ops-v6app-v4server-00 Comments welcome. -d From xing@cernet.edu.cn Mon Oct 19 18:09:15 2009 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 EF5EC3A6839 for <behave@core3.amsl.com>; Mon, 19 Oct 2009 18:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.986 X-Spam-Level: * X-Spam-Status: No, score=1.986 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_40=-0.185, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtdlC1DnbcFE for <behave@core3.amsl.com>; Mon, 19 Oct 2009 18:09:15 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 54CCD3A681A for <behave@ietf.org>; Mon, 19 Oct 2009 18:09:13 -0700 (PDT) Received: from [59.66.24.140]([59.66.24.140]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm254add16da; Tue, 20 Oct 2009 09:09:19 +0800 Message-ID: <4ADD0DC1.7030807@cernet.edu.cn> Date: Tue, 20 Oct 2009 09:09:21 +0800 From: Xing Li <xing@cernet.edu.cn> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: 'Behave WG' <behave@ietf.org> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: bszNDAXB Cc: congxiao <congxiao@cernet.edu.cn>, Xing Li <xing@cernet.edu.cn>, Fred Baker <fred@cisco.com>, Kevin Yin <kyin@cisco.com> Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-framework-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, 20 Oct 2009 01:09:16 -0000 This new version addresses the comments received from the previous interim meeting. In particular: (1) Update the terminology (IPv4-translatable address, Network Specific Prefix, IPv6-only, etc) (2) Address the concern of the direction of the initiated communication for stateful translator. See here for a full diff: http://tools.ietf.org/rfcdiff?url2=draft-ietf-behave-v6v4-framework-02.txt Regards, xing From xing@cernet.edu.cn Mon Oct 19 18:09:50 2009 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 13EDE3A6839 for <behave@core3.amsl.com>; Mon, 19 Oct 2009 18:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.839 X-Spam-Level: * X-Spam-Status: No, score=1.839 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_20=-0.74, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMAkcTXXnkAA for <behave@core3.amsl.com>; Mon, 19 Oct 2009 18:09:49 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 6DD563A681A for <behave@ietf.org>; Mon, 19 Oct 2009 18:09:48 -0700 (PDT) Received: from [59.66.24.140]([59.66.24.140]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm324add16fd; Tue, 20 Oct 2009 09:09:54 +0800 Message-ID: <4ADD0DE8.9080001@cernet.edu.cn> Date: Tue, 20 Oct 2009 09:10:00 +0800 From: Xing Li <xing@cernet.edu.cn> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: 'Behave WG' <behave@ietf.org> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: bw8ODAXB Cc: congxiao <congxiao@cernet.edu.cn>, Xing Li <xing@cernet.edu.cn>, Fred Baker <fred@cisco.com> Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-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, 20 Oct 2009 01:09:50 -0000 This new version addresses the comments received from the previous interim meeting. In particular: (1) Add Section 1.4. Path MTU discovery and fragmentation (2) Add the notation for IPv4-mapped and IPv4-translatable addresses (3) Discuss the ICMP and ICMPError handling of the non-IPv4-translatable addresses in the IPv6 to IPv4 translation. See here for a full diff: http://tools.ietf.org/rfcdiff?url2=draft-ietf-behave-v6v4-xlate-02.txt Regards, xing From cb.list6@gmail.com Mon Oct 19 23:01:16 2009 Return-Path: <cb.list6@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 1F1323A65A6 for <behave@core3.amsl.com>; Mon, 19 Oct 2009 23:01:16 -0700 (PDT) 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 zP9z0li0lA6f for <behave@core3.amsl.com>; Mon, 19 Oct 2009 23:01:15 -0700 (PDT) Received: from mail-px0-f173.google.com (mail-px0-f173.google.com [209.85.216.173]) by core3.amsl.com (Postfix) with ESMTP id 4842C3A6359 for <behave@ietf.org>; Mon, 19 Oct 2009 23:01:15 -0700 (PDT) Received: by pxi3 with SMTP id 3so5625863pxi.29 for <behave@ietf.org>; Mon, 19 Oct 2009 23:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=fGsLKsZBCYq29OytkFyG5cZrmuf78LzyFY4qW9/46V4=; b=UQLm5hr2nbSagiRNVcv3590YKncEt5vHmm4h+k44MpL3KaORz0vwr3KfhZZX8Q2wf+ xwFRYDr5PW/UYQRnNl8V8luosf398LF91jKrrwWr+NY7zBT+RaL++EnXk9H0VD0Si8Ns Rhq631vo/oulZkOG1YtWeugb7epYYryjttUbQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=hbOca8jUEkHGpLC+czamDR92d/Ie98QYFRcSKY98d/ttb3JkQbR5g3wPXxfsRVUUBI A1wuUmZD/46UhHC0rrAoT19oogrldyO1PMm2+oRtdkqO6Np+4YSlIj4PtX7voiPCRCO0 R3ZXp+Dz8TOrcVqH99JBB/GANrJQYqZ43SmJo= MIME-Version: 1.0 Received: by 10.142.9.29 with SMTP id 29mr402816wfi.131.1256018479536; Mon, 19 Oct 2009 23:01:19 -0700 (PDT) Date: Mon, 19 Oct 2009 23:01:19 -0700 Message-ID: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com> From: Cameron Byrne <cb.list6@gmail.com> To: behave@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [BEHAVE] Using DNS64 to load balance to NAT64 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, 20 Oct 2009 06:01:16 -0000 Folks, One of the major problems many operators have is scaling the CGN in a reliable way. Scaling in the number of session per seconds as well as raw concurrent sessions continues to be an issue, and will continue to be an issue. Additionally, given that state and ALGs are being used, boxes are known to reboot when protocols act in unexpected ways, so fault isolation is another desire (array of independent boxes). Does the scenarios where i have boxes NAT64-A, NAT64-B, and NAT64-C (all unique state boxes or high-available pairs of active/standby boxes, with unique prefix64 A, B, and C respectively announced from each) and the DNS64 load balances traffic (for example, round-robin assignments of Prefix64-A, B, and C to resolving clients) destine to each NAT64-A, B, C systems evenly. This way, the DNS64 drives 1/3 of the requests to each of the 3 NAT64 systems. And, it scales linearly in terms of NAT64 boxes. This assumes the DNS64 system scales higher than the NAT64 systems, which i think is a good assumption. Additionally, the NAT64 and the DNS64 should be able to communicate in such a way that the NAT64 can signal an overloading situation such that the DNS64 drops the overloaded NAT64 out of the round-robin prefix64 synthesis for some period of time. This could be implemented as simple SNMP GET sampling of the sessions that NAT64 systems are currently processing. Does this make sense to have this level of load-balancing between an array of independent NAT64 boxes and feedback / back-pressure communicated to the DNS64 system that is ultimately driving the load to the NAT64 boxes? Does this fit within the existing drafts? Or is this implementation minutia that does not require being covered here? At a minimum, i think it would be nice to have the DNS64 draft examine how the DNS64 system can drive load to multiple unique NAT64 systems. Thoughts? Regards, Cameron Byrne Cameron From phdgang@gmail.com Mon Oct 19 23:45:53 2009 Return-Path: <phdgang@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 398D83A6814 for <behave@core3.amsl.com>; Mon, 19 Oct 2009 23:45:53 -0700 (PDT) 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 RR66E+flXt7v for <behave@core3.amsl.com>; Mon, 19 Oct 2009 23:45:52 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id 5CE3C3A67A1 for <behave@ietf.org>; Mon, 19 Oct 2009 23:45:52 -0700 (PDT) Received: by pzk42 with SMTP id 42so4461804pzk.31 for <behave@ietf.org>; Mon, 19 Oct 2009 23:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=LtVC3DAFDphJgu04Tl1/Z4wGDlyX+dTtP7RjSsG++1Y=; b=pve9dQg9XzzwU+AzmTk1FDLqYdcrIhn8rijG3xUgK0CorVTO09c/t0XPp+XRXD4H8M wnYM23JwxSadJ4dFZoiZgNhQfSkF5kr4d6pWCT/bR36VRnMYNtxp5KTSaxnM4aBNo/KN 30j0wiHZMnsYRGLiyi6rey6MGwj7FlGG33loM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=H0tldC0suUAqV5WPq0Lu/5a8DUTc+RSgG2Z9GAkob7VeexPrXcSELgW59ywA7PpwnU jqNnR0zjaE+/BARkaISAKtDs50LeQMLh+0bCNLbSypdqcUAIKFx1Hm1cl/9Mz6ZAIWHG Od/Ak2TOYD5AQx0n1xzw4PkhUAR85ohJruOdQ= MIME-Version: 1.0 Received: by 10.143.27.39 with SMTP id e39mr405842wfj.212.1256021157543; Mon, 19 Oct 2009 23:45:57 -0700 (PDT) Date: Tue, 20 Oct 2009 14:45:57 +0800 Message-ID: <36ba02b00910192345x2dd7c680r8439fee2d0090bff@mail.gmail.com> From: Chen Gang <phdgang@gmail.com> To: Behave WG <behave@ietf.org> Content-Type: multipart/alternative; boundary=001636e1f77fed014f04765836bf Subject: [BEHAVE] I-D ACTION:draft-chen-behave-olnat-00.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, 20 Oct 2009 06:45:53 -0000 --001636e1f77fed014f04765836bf Content-Type: text/plain; charset=ISO-8859-1 Hello all, We have posted a new draft about optimal load-balance for NAT64 based on anycast mechanism. Please kinldy to review it. Any comment is welcome. Thanks -Gang A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Optimal Load-balance mechanism for NAT64 (OL-NAT) Author(s) : G. Chen, H. Deng Filename : draft-chen-behave-olnat-00.txt Pages : 12 Date : 2009-10-19 In NAT64 scenaires,sigle-point failure is a critical issue to restrict large-scale deployment. In order to overcome this hurdle, this memo has proposed a optimal load-balance mechanism for NAT64. Through the new-defined evaluation metrics, several extended ICMP messages combining with anycast are performed to achieve optimal NAT64 selection. Meanwihle, the synchroniztion process of IP address mapping information is also designed to guarantee the service continuity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-behave-olnat-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --001636e1f77fed014f04765836bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p>Hello all,<br>=A0<br>We have posted a new draft about optimal load-balan= ce for NAT64 based on anycast mechanism. <br>=A0<br>Please kinldy to review= it.<br>Any comment is welcome.<br>=A0<br>Thanks<br>=A0<br>-Gang</p> <p>A New Internet-Draft is available from the on-line Internet-Drafts<br>di= rectories.</p> <p><br>=A0=A0=A0=A0=A0=A0 Title=A0=A0=A0=A0=A0=A0=A0=A0: A Optimal Load-bal= ance mechanism for NAT64 (OL-NAT)<br>=A0=A0=A0=A0=A0=A0 Author(s)=A0: G. Ch= en, H. Deng<br>=A0=A0=A0=A0=A0=A0 Filename=A0: draft-chen-behave-olnat-00.t= xt<br>=A0=A0=A0=A0=A0=A0 Pages=A0=A0=A0=A0=A0: 12<br>=A0=A0=A0=A0=A0=A0 Dat= e=A0=A0=A0=A0=A0=A0=A0 : 2009-10-19</p> <p>=A0 In NAT64 scenaires,sigle-point failure is a critical issue to<br>=A0= restrict large-scale deployment.=A0 In order to overcome this hurdle,<br>= =A0 this memo has proposed a optimal load-balance mechanism for NAT64.<br>= =A0 Through the new-defined evaluation metrics, several extended ICMP<br> =A0 messages combining with anycast are performed to achieve optimal<br>=A0= NAT64 selection.=A0 Meanwihle, the synchroniztion process of IP address<br= >=A0 mapping information is also designed to guarantee the service<br>=A0 c= ontinuity.</p> <p>A URL for this Internet-Draft is:<br><a href=3D"http://www.ietf.org/inte= rnet-drafts/draft-chen-behave-olnat-00.txt">http://www.ietf.org/internet-dr= afts/draft-chen-behave-olnat-00.txt</a></p> <p>Internet-Drafts are also available by anonymous FTP at:<br><a href=3D"ft= p://ftp.ietf.org/internet-drafts/">ftp://ftp.ietf.org/internet-drafts/</a><= /p> <p>Below is the data which will enable a MIME compliant mail reader<br>impl= ementation to automatically retrieve the ASCII version of the<br>Internet-D= raft.</p> --001636e1f77fed014f04765836bf-- From xuxh@huawei.com Tue Oct 20 00:02:13 2009 Return-Path: <xuxh@huawei.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 CDFC33A6904 for <behave@core3.amsl.com>; Tue, 20 Oct 2009 00:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.673 X-Spam-Level: * X-Spam-Status: No, score=1.673 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f670q2U7tsRw for <behave@core3.amsl.com>; Tue, 20 Oct 2009 00:02:13 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id F0C2B3A6883 for <behave@ietf.org>; Tue, 20 Oct 2009 00:02:12 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRS002MTWQ7QZ@szxga03-in.huawei.com> for behave@ietf.org; Tue, 20 Oct 2009 14:58:55 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRS00H1AWQ7OA@szxga03-in.huawei.com> for behave@ietf.org; Tue, 20 Oct 2009 14:58:55 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRS00HKWWQ6E4@szxml06-in.huawei.com> for behave@ietf.org; Tue, 20 Oct 2009 14:58:55 +0800 (CST) Date: Tue, 20 Oct 2009 14:58:54 +0800 From: Xu Xiaohu <xuxh@huawei.com> In-reply-to: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com> To: 'Cameron Byrne' <cb.list6@gmail.com>, behave@ietf.org Message-id: <004901ca5152$ca000ed0$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpRSs/YwjQr1N40QkycsLqFQ7VPAQABr1zw Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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, 20 Oct 2009 07:02:13 -0000 Hi Cameron, > Does this fit within the existing drafts? Or is this implementation > minutia that does not require being covered here? At a minimum, i > think it would be nice to have the DNS64 draft examine how the DNS64 > system can drive load to multiple unique NAT64 systems. In the following draft (http://tools.ietf.org/id/draft-xu-behave-nat64-standby-00.txt), some consideration about the load-balancing together with redundancy is discussed. Of course, this demo does not discuss the issues with achieving best balance by adjusting the numbers of hosts adopting different prefix64s since there are many possible options to achieve this, e.g., by using DNS64, or using prefix-learning mechanism defined in [draft-wing-behave-learn-prefix-03]. Xiaohu From ajs@shinkuro.com Tue Oct 20 06:21:41 2009 Return-Path: <ajs@shinkuro.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 2709F3A6983 for <behave@core3.amsl.com>; Tue, 20 Oct 2009 06:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.585 X-Spam-Level: X-Spam-Status: No, score=-1.585 tagged_above=-999 required=5 tests=[AWL=1.014, 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 QvsXGhxgea54 for <behave@core3.amsl.com>; Tue, 20 Oct 2009 06:21:40 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 31FF83A6963 for <behave@ietf.org>; Tue, 20 Oct 2009 06:21:40 -0700 (PDT) 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 1F07A2FE8CA1 for <behave@ietf.org>; Tue, 20 Oct 2009 13:21:47 +0000 (UTC) Date: Tue, 20 Oct 2009 09:21:45 -0400 From: Andrew Sullivan <ajs@shinkuro.com> To: behave@ietf.org Message-ID: <20091020132145.GD34289@shinkuro.com> References: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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, 20 Oct 2009 13:21:41 -0000 On Mon, Oct 19, 2009 at 11:01:19PM -0700, Cameron Byrne wrote: > boxes, with unique prefix64 A, B, and C respectively announced from > each) and the DNS64 load balances traffic (for example, round-robin > assignments of Prefix64-A, B, and C to resolving clients) destine to > each NAT64-A, B, C systems evenly. This way, the DNS64 drives 1/3 of > the requests to each of the 3 NAT64 systems. And, it scales linearly > in terms of NAT64 boxes. This assumes the DNS64 system scales higher > than the NAT64 systems, which i think is a good assumption. As a general matter, DNS-based load balancing is broken. If nothing else, there are way too many examples of applications holding onto an IP address and continuing to use it, which means that your attempts to take things in and out of service based on what you think the DNS is giving out will cause failures. (It's also almost certainly going to cause you heartburn with DNSSEC, but I'm just assuming here that you're planning to give up on DNSSEC in this context.) Moreover, there are often interdependencies among different requests such that the attempts to load balance via DNS breal the interdependencies and cause otherwise working arrangements to fail. Based on that previous experience, I suspect that the above plan is not a good idea. What I would prefer to see suggested is some sort of multiple-redundant NAT64 set, with multiple-redundant DNS64. A client should not use inconsistent sets of DNS64 servers (on a given interface), but should stick to one set. Nevertheless, I am realistic enough to realise that your proposal is bound to be implemented by someone, because we've invented the DNS64. I suspect it will be fragile in exactly the ways DNS load balancing is today. > Additionally, the NAT64 and the DNS64 should be able to communicate in > such a way that the NAT64 can signal an overloading situation such > that the DNS64 drops the overloaded NAT64 out of the round-robin > prefix64 synthesis for some period of time. This could be implemented > as simple SNMP GET sampling of the sessions that NAT64 systems are > currently processing. That does not seem to be consistent with the current DNS64 draft, which says that the DNS64 and NAT64 share one common configuration but are otherwise not coupled. It sounds like you're proposing to reinvent the NAT-PT DNS ALG, and if we were going to do that why wouldn't we just write "RFC 4966 considered harmful" and be done with it? > Does this fit within the existing drafts? Or is this implementation > minutia that does not require being covered here? At a minimum, i > think it would be nice to have the DNS64 draft examine how the DNS64 > system can drive load to multiple unique NAT64 systems. I would need quite a bit more argument in favour of this technique in order to be co-operative about adding that sort of discussion to the draft. It is _very hard_ to control what people will do with the data they get out of the DNS, and even the limited number of assumptions we have in there will clearly break some installations. (I have a gateway device sitting on my desk that would almost certainly immediately break were it to be put behind a DNS64 service, because it's a mixed-mode iterator and forwarder.) I'm not really keen on inventing new ways to make DNS64 more fragile. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From teemu.savolainen@nokia.com Tue Oct 20 06:48:38 2009 Return-Path: <teemu.savolainen@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 5F0A43A6997 for <behave@core3.amsl.com>; Tue, 20 Oct 2009 06:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNWVJ7wplB+7 for <behave@core3.amsl.com>; Tue, 20 Oct 2009 06:48:37 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 859AA3A677D for <behave@ietf.org>; Tue, 20 Oct 2009 06:48:37 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9KDlPP1013419; Tue, 20 Oct 2009 08:48:44 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 16:48:33 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 16:48:33 +0300 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.3959); Tue, 20 Oct 2009 16:48:28 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 20 Oct 2009 15:48:27 +0200 From: <teemu.savolainen@nokia.com> To: <ajs@shinkuro.com>, <behave@ietf.org> Date: Tue, 20 Oct 2009 15:46:53 +0200 Thread-Topic: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt Thread-Index: AcpQ6EHLCT5UNyrGTcev6LjQnMuZpQAogG6Q Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F3EF10EF424@NOK-EUMSG-01.mgdnok.nokia.com> References: <20091019180002.1AFBE3A692D@core3.amsl.com> <20091019181555.GC9536@shinkuro.com> In-Reply-To: <20091019181555.GC9536@shinkuro.com> 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 X-OriginalArrivalTime: 20 Oct 2009 13:48:28.0720 (UTC) FILETIME=[00FAFB00:01CA518C] X-Nokia-AV: Clean Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.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, 20 Oct 2009 13:48:38 -0000 Hi, The draft contains question about multihoming:"In particular, how is the mu= lti-homed host supposed to know that a given AAAA is synthetic?". I just updated my MIF related draft http://tools.ietf.org/html/draft-savola= inen-mif-dns-server-selection-01 to contain also this case. The multi-homed host does not necessarily need to know AAAA is synthetic: i= t could assume split DNS can happen in IPv6 domain as well, and thus consid= er all AAAA responses it gets as interface local - not as host global.=20 Anyhow, I don't think DNS64 specification has to solve this, as MIF WG exis= t to look at this problem domain. It is good to mention in DNS64 document, = though. Best regards, Teemu >-----Original Message----- >From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org]=20 >On Behalf Of ext Andrew Sullivan >Sent: 19 October, 2009 21:16 >To: behave@ietf.org >Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt > >Dear colleagues, > >On Mon, Oct 19, 2009 at 11:00:01AM -0700,=20 >Internet-Drafts@ietf.org wrote: >> Title : DNS64: DNS extensions for Network=20 >Address Translation from IPv6 Clients to IPv4 Servers >> Author(s) : M. Bagnulo, et al. >> Filename : draft-ietf-behave-dns64-01.txt >> Pages : 29 >> Date : 2009-10-19 > >I believe that the draft addresses all the concerns raised=20 >since the last draft. The editors would appreciate feedback. =20 >I was late getting this to the others, so any errors or=20 >omissions you can blame on me alone. > >A > > >-- >Andrew Sullivan >ajs@shinkuro.com >Shinkuro, Inc. >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave >= From ajs@shinkuro.com Tue Oct 20 07:01:12 2009 Return-Path: <ajs@shinkuro.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 D19853A69B4 for <behave@core3.amsl.com>; Tue, 20 Oct 2009 07:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.663 X-Spam-Level: X-Spam-Status: No, score=-1.663 tagged_above=-999 required=5 tests=[AWL=0.936, 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 re9pYDxsiADh for <behave@core3.amsl.com>; Tue, 20 Oct 2009 07:01:12 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 067D13A6985 for <behave@ietf.org>; Tue, 20 Oct 2009 07:01:12 -0700 (PDT) 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 655392FE8CA1 for <behave@ietf.org>; Tue, 20 Oct 2009 14:01:19 +0000 (UTC) Date: Tue, 20 Oct 2009 10:01:16 -0400 From: Andrew Sullivan <ajs@shinkuro.com> To: behave@ietf.org Message-ID: <20091020140116.GE34289@shinkuro.com> References: <20091019180002.1AFBE3A692D@core3.amsl.com> <20091019181555.GC9536@shinkuro.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3EF10EF424@NOK-EUMSG-01.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F3EF10EF424@NOK-EUMSG-01.mgdnok.nokia.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.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, 20 Oct 2009 14:01:12 -0000 On Tue, Oct 20, 2009 at 03:46:53PM +0200, teemu.savolainen@nokia.com wrote: > > The multi-homed host does not necessarily need to know AAAA is synthetic: it could assume split DNS can happen in IPv6 domain as well, and thus consider all AAAA responses it gets as interface local - not as host global. > Ok, I see. > Anyhow, I don't think DNS64 specification has to solve this, as MIF WG exist to look at this problem domain. It is good to mention in DNS64 document, though. > I'll put in a reference. Thanks. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From denghui02@gmail.com Tue Oct 20 07:05:21 2009 Return-Path: <denghui02@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 78BAB3A6A1C for <behave@core3.amsl.com>; Tue, 20 Oct 2009 07:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4tumSvRvDwD for <behave@core3.amsl.com>; Tue, 20 Oct 2009 07:05:20 -0700 (PDT) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by core3.amsl.com (Postfix) with ESMTP id 68EF43A67A6 for <behave@ietf.org>; Tue, 20 Oct 2009 07:05:20 -0700 (PDT) Received: by qyk29 with SMTP id 29so4195399qyk.32 for <behave@ietf.org>; Tue, 20 Oct 2009 07:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=xlDVwWBQEeG1N6+LtJZILLhmADfRmliBzs2PgA9epWc=; b=Iwxkmg4Scprx8jOxkwbf41hasSY4+bpBXuoC9OF3Ei37CM1e+I6F+ncupjdWHIPcWD WJWdZAaHE0BGH07CYVOJL+QOmLrTZs7AG3L2SIxb5eQhCc+khUrk+/FqIfCTPuv9DLoa p92JJeiUBuH9Tt9VOs9VVJCAi5JHgruuiIRps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=Z8bS913QSYWsaiS6GgWF1tAj8hq6exBwFP30BWQ2IRJQfpFOPkeSFLmn2JyAwgVuKS W9i1acMLdN9jvnIgE5An45y4DfoSbACE/cz9Yca4O+g4lGXOAiHMhQ7u69D4CwAg1m5c WP+bsT3oASgSdCmq2ewIfo099HY9vqOPLh6Zk= MIME-Version: 1.0 Received: by 10.224.25.205 with SMTP id a13mr3240596qac.202.1256047525511; Tue, 20 Oct 2009 07:05:25 -0700 (PDT) Date: Tue, 20 Oct 2009 22:05:25 +0800 Message-ID: <1d38a3350910200705l198d5814v19fcadac0aa579af@mail.gmail.com> From: Hui Deng <denghui02@gmail.com> To: Dan Wing <dwing@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: behave@ietf.org, Dave Thaler <dthaler@microsoft.com> Subject: [BEHAVE] PNAT drafts 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, 20 Oct 2009 14:05:21 -0000 Dear all. PNAT related drafts,historically there have been lots of review, and we have updated a lot, would appreciate if you could kind help to review it again, http://www.ietf.org/internet-drafts/draft-cao-behave-hbt-req-00.txt http://www.ietf.org/internet-drafts/draft-huang-behave-rfc2767bis-00.txt http://www.ietf.org/internet-drafts/draft-huang-behave-rfc3338bis-00.txt http://www.ietf.org/internet-drafts/draft-huang-behave-pnat-00.txt By the way, we have done multiple vendors's implementations and it works very good by now. And we are deploying this technology on some part of our network. Many thanks, -Hui From iljitsch@muada.com Tue Oct 20 07:10:19 2009 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 A9B413A6862 for <behave@core3.amsl.com>; Tue, 20 Oct 2009 07:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ox-ipz5obQPk for <behave@core3.amsl.com>; Tue, 20 Oct 2009 07:10:18 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id A4F593A6856 for <behave@ietf.org>; Tue, 20 Oct 2009 07:10:18 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.216]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n9KE9nkp072494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Oct 2009 16:09:49 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com> Date: Tue, 20 Oct 2009 16:10:14 +0200 Content-Transfer-Encoding: 7bit Message-Id: <643AD0DC-5BD4-44BD-A206-D58A5F965F3A@muada.com> References: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com> To: Cameron Byrne <cb.list6@gmail.com> X-Mailer: Apple Mail (2.1076) Cc: behave@ietf.org Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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, 20 Oct 2009 14:10:19 -0000 On 20 okt 2009, at 08:01, Cameron Byrne wrote: > Additionally, the NAT64 and the DNS64 should be able to communicate in > such a way that the NAT64 can signal an overloading situation such > that the DNS64 drops the overloaded NAT64 out of the round-robin > prefix64 synthesis for some period of time. I have one problem here in addition to Andrew's objections: If make a given host move to a different NAT64, that means that for some time, there will be an inconsistency between the external IPv4 addresses associated with different sessions. This makes protocols like STUN fail, and as such, should be avoided. You really don't want to run so close to your translator capacity that systems like this become useful. From mrw@lilacglade.org Tue Oct 20 08:08:51 2009 Return-Path: <mrw@lilacglade.org> 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 7C64628C11E; Tue, 20 Oct 2009 08:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzEEwgtEKZys; Tue, 20 Oct 2009 08:08:50 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 4FE8A28C10C; Tue, 20 Oct 2009 08:08:50 -0700 (PDT) Received: from [10.2.0.20] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n9KF8nFS082573 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Oct 2009 11:08:49 -0400 (EDT) (envelope-from mrw@lilacglade.org) From: Margaret Wasserman <mrw@lilacglade.org> To: Behave WG <behave@ietf.org> In-Reply-To: <01c101ca509f$f314a8c0$8e27460a@china.huawei.com> X-Priority: 3 References: <01c101ca509f$f314a8c0$8e27460a@china.huawei.com> Message-Id: <61FFB311-CA42-4EE4-A6F9-3DE0581A9E8F@lilacglade.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 20 Oct 2009 11:08:47 -0400 X-Mailer: Apple Mail (2.936) Cc: ops-dir@ietf.org Subject: [BEHAVE] Opsdir Review of draft-ietf-behave-turn-uri-03.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, 20 Oct 2009 15:08:51 -0000 Hello Behave Folks, As a member of the Operations Directorate, I was asked to review draft-ietf-behave-turn-uri-03.txt. I have some operational concerns with this document that should probably be resolved before the document is published. I apologize in advance if my comments reflect a lack of knowledge of this subject. In section 4, there is a numbered list of ways in which the TURN resolution may be processed, and this appears to be the core of the document. I have spent a considerable amount of time trying to figure out what this list says, and I have not been completely successful. My current understanding is as follows: (1.) If the <host> is an IP address, the other fields are filled in as follows: - <port> is set to the value in the URI if present, or to the default in draft-ietf-behave-turn. - If <transport> is defined: > <scheme> and <transport> are converted to a TURN transport. - If <transport> is not defined: > The supported transports are tried in order of preference. If <host> is a Domain Name, the fields are filled in as follows: (2.)- If <port> is defined: > <host> is resolved to a list of IP addresses via DNS. > If <transport> is defined: >> <scheme> and <transport> are converted to a TURN transport > If <transport> is not defined: >> The supported transports are tried in order of preference. - If <port> is not defined: (3.) > If <transport> is defined: >> <host> is converted to list of IP address and port tuples via a DNS SRV query, with <scheme> as the service name and <transport> as the protocol name. [There is some wording here about the fact that the SRV algorith recommends doing an A query, but it doesn't actually say to do one, and the text above this already indicates that you would have reached the TURN server or returned an error.] (4.) > If <transport> is not defined: >> <host> is convered to an ordered list of IP Address, port and and transport tuples via the S-NAPTR algorithm. >> The TURN transports supported by the application are then converted into Application Protocol Tags, and the protocol tags are "tried" in some order. [It is not clear, to me, what it means to "try" a protocol tag. Also, we seem to using all of the tags supported by the application, not anything returned from the S-NAPTR algorithm?] [Again, we have the problem that there is text after the previous text has either succeeded or returned an error. In this case, it says that the <host> is converted to a list of IP Address and Port tuples using the algorithm in section 3 "for each of the TURN transports supported by the application". It is not clear to me what this means, exactly.] In addition to not being able to decipher exactly what steps should be performed, I am somewhat concerned about what I consider to be an artificial distinction between domain names and IP addresses. Is it actually the case that you cannot use the S-NAPTR algorithm and/or look up SRV records using an IP address instead of a Domain Name? I am somewhat concerned about the impacts of this choice on management and debugging, although I am not sure if the problem lies in this document or in the S-NAPTR and SRV documents. I also have a couple of suggestions that might make the URI scheme more straightforward for operators and users: (1) Why is it desirable to overload the transport name "tcp" in the URI scheme to mean TCP for TURN and TLS for TURNS, when similar overloading is not present in the NAPTR definition? Is there some advantage to doing so that offsets the potential for confusion? (2) At various places in this document, decision trees are represented as numbered or bulleted lists, instead of laying out the choices at each layer. While I think that the lists are logically consistent and represent all of the choices, this format does not make it easy to tell. (3) It would be better to include a more complete range of examples showing all of the different permutations. Margaret From cb.list6@gmail.com Tue Oct 20 08:33:09 2009 Return-Path: <cb.list6@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 45A3F3A6A2E for <behave@core3.amsl.com>; Tue, 20 Oct 2009 08:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 YG1mMWnspO2Q for <behave@core3.amsl.com>; Tue, 20 Oct 2009 08:33:08 -0700 (PDT) Received: from mail-px0-f204.google.com (mail-px0-f204.google.com [209.85.216.204]) by core3.amsl.com (Postfix) with ESMTP id 6E50C3A68B3 for <behave@ietf.org>; Tue, 20 Oct 2009 08:33:08 -0700 (PDT) Received: by pxi42 with SMTP id 42so4342801pxi.5 for <behave@ietf.org>; Tue, 20 Oct 2009 08:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=2wY55AMpb/Cnhyd5pJhtiZT3/kRkdT6HOuMXtg5Wy54=; b=wMblpKQyUL+4qNUMCu7zwakkQA+PhQ4Kg/gctDzKnhEBB3512k9s3b8tyAJ3KCOW/h hvX6HSYrc3vGNgWa5Ak977edsq14KwJ7DmfHyK8Byi4VJ3+z+GeETOTOTnFnymrgds/8 C9c+TSFtjRYzy3Oc5iADa8loyWjSYbAd+yU/Y= 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=VWgW5ZaTIrF0pDKoxxtGdTqriEWFlkUIKh4IcnMS+xm3vA2dr8Fatd/moJ+b3lLK7Q eWA46cwVXP7eqmOLebwxq53fZWcEQbPqGM2ZI70LDEGh1K176Xpbfjkxkqz4PwI3U4sn GbYOCuIh+e2PvXsf0mg4ng52VOdAKxtQ3q+yY= MIME-Version: 1.0 Received: by 10.142.250.3 with SMTP id x3mr512910wfh.23.1256052792817; Tue, 20 Oct 2009 08:33:12 -0700 (PDT) In-Reply-To: <643AD0DC-5BD4-44BD-A206-D58A5F965F3A@muada.com> References: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com> <643AD0DC-5BD4-44BD-A206-D58A5F965F3A@muada.com> Date: Tue, 20 Oct 2009 08:33:12 -0700 Message-ID: <bcff0fba0910200833n61e17ba9xa239eb9f5af0b2d7@mail.gmail.com> From: Cameron Byrne <cb.list6@gmail.com> To: Iljitsch van Beijnum <iljitsch@muada.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: behave@ietf.org Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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, 20 Oct 2009 15:33:09 -0000 On Tue, Oct 20, 2009 at 7:10 AM, Iljitsch van Beijnum <iljitsch@muada.com> wrote: > On 20 okt 2009, at 08:01, Cameron Byrne wrote: > >> Additionally, the NAT64 and the DNS64 should be able to communicate in >> such a way that the NAT64 can signal an overloading situation such >> that the DNS64 drops the overloaded NAT64 out of the round-robin >> prefix64 synthesis for some period of time. > > I have one problem here in addition to Andrew's objections: > > If make a given host move to a different NAT64, that means that for some > time, there will be an inconsistency between the external IPv4 addresses > associated with different sessions. This makes protocols like STUN fail, and > as such, should be avoided. > > You really don't want to run so close to your translator capacity that > systems like this become useful. Unfortunately, there is no box that meets my translation capacity needs today. I do over 10 million busy hour simultaneous translations today in the USA, and that number is going to grow and grow (100%+ growth a year is the trend) with more users and more things like AJAX, always on connections, application NAT keepalives ..... So, the scaling mechanism as put forth today, is broken in NAT64 / DNS64 since it is bounded and coupled to pairings of NAT64 and DNS64 boxes. The NAT44 and NAT64 designs, as is , require a lot of routing magic to balance the traffic and meet the demand. Today, i have to have arrays of boxes that scale linearly as part of the NAT44 topology design. There is no other way. I have to use policy based routing on routers to carve up the NAT44 demand from my customers and assign it to NAT44 boxes. So even in a highly distributed deployment, I have nearly 20 locations today in the USA where i have arrays of NAT44 capacity, scaling is not ideal. It is ugly to look at for a purest... but it works and scales linearly. It would be nice if we could bake in an ability for DNS64 / NAT64 to scale linearly (10x boxes / Prefix64 is practical). Today, coupling DNS64 capacity with NAT64 capacity won't work for me. I will again have to slice and dice capacity with router tricks to balance the load over an array of capacity. Not ideal. We need a better way. Scaling is a practical and real problem that we must address. We cannot turn our noses up at this problem as a minor issue. From ajs@shinkuro.com Tue Oct 20 08:39:02 2009 Return-Path: <ajs@shinkuro.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 D46BD3A6863 for <behave@core3.amsl.com>; Tue, 20 Oct 2009 08:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.73 X-Spam-Level: X-Spam-Status: No, score=-1.73 tagged_above=-999 required=5 tests=[AWL=0.869, 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 bzG9m+7uRx9S for <behave@core3.amsl.com>; Tue, 20 Oct 2009 08:39:01 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 874923A67F4 for <behave@ietf.org>; Tue, 20 Oct 2009 08:39:01 -0700 (PDT) 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 D50422FE8CA1 for <behave@ietf.org>; Tue, 20 Oct 2009 15:39:08 +0000 (UTC) Date: Tue, 20 Oct 2009 11:39:07 -0400 From: Andrew Sullivan <ajs@shinkuro.com> To: behave@ietf.org Message-ID: <20091020153749.GI34289@shinkuro.com> References: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com> <643AD0DC-5BD4-44BD-A206-D58A5F965F3A@muada.com> <bcff0fba0910200833n61e17ba9xa239eb9f5af0b2d7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <bcff0fba0910200833n61e17ba9xa239eb9f5af0b2d7@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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, 20 Oct 2009 15:39:02 -0000 On Tue, Oct 20, 2009 at 08:33:12AM -0700, Cameron Byrne wrote: > Scaling is a practical and real problem that we must address. We > cannot turn our noses up at this problem as a minor issue. I don't think anyone is turning up noses. The plain fact is that using "DNS load balancing" to scale these sorts of things is broken _today_, and DNS64 can't be any better (indeed, it can make things worse). A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From cb.list6@gmail.com Tue Oct 20 08:41:08 2009 Return-Path: <cb.list6@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 D78C428C149 for <behave@core3.amsl.com>; Tue, 20 Oct 2009 08:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 muj7grrrtk4f for <behave@core3.amsl.com>; Tue, 20 Oct 2009 08:41:04 -0700 (PDT) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 424B828C13D for <behave@ietf.org>; Tue, 20 Oct 2009 08:41:03 -0700 (PDT) Received: by pzk6 with SMTP id 6so7599320pzk.29 for <behave@ietf.org>; Tue, 20 Oct 2009 08:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1A2wblThYxzv5dq65gYFjhXZ7IbblIm6/LjG+nIXepA=; b=EXvThDP7NhgLb21ayfDHxPTu+/Dk0fZC/zXFjif2o3dqJkGd63IZDlHZx8xUgIx2Cm IL047ATujTdstJoi24HnSACyWG4Tk7dzuJjXktNPKJyryLoD6eHGZWYBc78pizRTFpSK Qks6hINhbrzWEYgBzkolDtKimwT0ZIIvqlE4o= 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=jwZpbrqsv9LRmynkFp/GJOweezKjGyDQC5igQ52ykoV937qYnb4fZef6kzl39Rs1Wt GopDlUvTLQk1mpNOnQgjdL8XGFBDxZW9E54POfKRoR7RulipJNaSyXjNMYewuNYPiqaK eSoWtdUn8bSgYJ+WS+nOsGRR3rthwQkui/mLM= MIME-Version: 1.0 Received: by 10.142.150.41 with SMTP id x41mr438215wfd.243.1256053268596; Tue, 20 Oct 2009 08:41:08 -0700 (PDT) In-Reply-To: <004901ca5152$ca000ed0$d40c6f0a@china.huawei.com> References: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com> <004901ca5152$ca000ed0$d40c6f0a@china.huawei.com> Date: Tue, 20 Oct 2009 08:41:08 -0700 Message-ID: <bcff0fba0910200841u73b1e05bu651a30cb48f5c17e@mail.gmail.com> From: Cameron Byrne <cb.list6@gmail.com> To: Xu Xiaohu <xuxh@huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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, 20 Oct 2009 15:41:09 -0000 On Mon, Oct 19, 2009 at 11:58 PM, Xu Xiaohu <xuxh@huawei.com> wrote: > Hi Cameron, > >> Does this fit within the existing drafts? =A0Or is this implementation >> minutia that does not require being covered here? =A0At a minimum, i >> think it would be nice to have the DNS64 draft examine how the DNS64 >> system can drive load to multiple unique NAT64 systems. > > In the following draft > (http://tools.ietf.org/id/draft-xu-behave-nat64-standby-00.txt), some > consideration about the load-balancing together with redundancy is > discussed. Of course, this demo does not discuss the issues with achievin= g > best balance by adjusting the numbers of hosts adopting different prefix6= 4s > since there are many possible options to achieve this, e.g., by using DNS= 64, > or using prefix-learning mechanism defined in > [draft-wing-behave-learn-prefix-03]. > > Xiaohu The mechanics in this draft are very similar to the state of the practice today in any vendors NAT44 implementation. Today, most NAT44 products do the things described in this draft. I am specifically looking for something that scales linearly leverages the control plane (DNS64?) to drive the traffic. From iljitsch@muada.com Tue Oct 20 08:49:09 2009 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 6409228C126 for <behave@core3.amsl.com>; Tue, 20 Oct 2009 08:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQNQjykZbTWA for <behave@core3.amsl.com>; Tue, 20 Oct 2009 08:49:08 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 412F228C0F1 for <behave@ietf.org>; Tue, 20 Oct 2009 08:49:08 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.216]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n9KFmfbj073152 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Oct 2009 17:48:42 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <bcff0fba0910200833n61e17ba9xa239eb9f5af0b2d7@mail.gmail.com> Date: Tue, 20 Oct 2009 17:49:07 +0200 Content-Transfer-Encoding: 7bit Message-Id: <18F1FF50-7D5F-49DD-9C07-458862038136@muada.com> References: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com> <643AD0DC-5BD4-44BD-A206-D58A5F965F3A@muada.com> <bcff0fba0910200833n61e17ba9xa239eb9f5af0b2d7@mail.gmail.com> To: Cameron Byrne <cb.list6@gmail.com> X-Mailer: Apple Mail (2.1076) Cc: behave@ietf.org Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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, 20 Oct 2009 15:49:09 -0000 On 20 okt 2009, at 17:33, Cameron Byrne wrote: > Today, coupling > DNS64 capacity with NAT64 capacity won't work for me. (Did we land on a conclusion on whether it would be ok to put a caching DNS server behind a DNS64?) The requirement is that the DNS64 that a host uses and the NAT64 that a host uses agree on the prefix. One very simple way to do this is to have one prefix that is shared by a bunch of NAT64s (like a well-known prefix). The disadvantage of that approach is that you can't use different prefixes to make traffic move to different NAT64s, which is probably something you want in a setup like yours. You can also first move the DNS request to the right (cluster of) DNS64 (s) by simply giving different hosts different DNS resolver addresses. So unlike NAT44, you're pretty free to place the boxes where you want rather than be forced to place them where the traffic happens to be. I would also talk to my vendors and ask them for the ability to send different DNS64 replies to different hosts based on their source addresses. This limits the number of DNS64 boxes that you need. > I will again > have to slice and dice capacity with router tricks to balance the load > over an array of capacity. Not ideal. We need a better way. IPv6, no NAT? :-) > Scaling is a practical and real problem that we must address. We > cannot turn our noses up at this problem as a minor issue. We weren't saying that. What I was saying is that dynamically balancing load over different NAT64s has problems for NAT traversal and what Andrew was saying is that it probably won't work (if I'm not mistaken). From cb.list6@gmail.com Tue Oct 20 08:57:32 2009 Return-Path: <cb.list6@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 3512828C123 for <behave@core3.amsl.com>; Tue, 20 Oct 2009 08:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 glkDoQ+PVeHV for <behave@core3.amsl.com>; Tue, 20 Oct 2009 08:57:31 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id 20D2728C0F1 for <behave@ietf.org>; Tue, 20 Oct 2009 08:57:31 -0700 (PDT) Received: by pzk42 with SMTP id 42so4842236pzk.31 for <behave@ietf.org>; Tue, 20 Oct 2009 08:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QZAF71CPEOt4SV8FX03NKbHN6LwCeqOWdQfLd2vXHtQ=; b=kNzfYtLcmEZGE0k6T0a/UTb6QEG33WihGozO4mI6YNQK1M3oEGDTjbk3COAfxp1/t9 Ll7pOwwXuGbdOwcXhUenWeZddV184emV4kss9kuQ3wcNI74jVIUsQyjcGlAss1SC6nz0 LQONPh5RwFWcQbnIZs70y2tDGTjpUK2n3wCXo= 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=R46SpSfdTHNlrmd70rgNkKT9bJdKJYCyS1E7l6OXra+ZuP5q6CiJ12xENrl8viDe3i oXSbPUxiJGAy/TTPg4TgGcuYFT53ny1NX+yPlfRVFrKxyrnjeqnEgHXqPYmmckMOq91Q 7DcXs6GabWX0zPXZKFy22JY3jacbRilkrjGcA= MIME-Version: 1.0 Received: by 10.143.84.2 with SMTP id m2mr482376wfl.4.1256054255780; Tue, 20 Oct 2009 08:57:35 -0700 (PDT) In-Reply-To: <20091020132145.GD34289@shinkuro.com> References: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com> <20091020132145.GD34289@shinkuro.com> Date: Tue, 20 Oct 2009 08:57:35 -0700 Message-ID: <bcff0fba0910200857r45d70938ge67fa7b673d00f3e@mail.gmail.com> From: Cameron Byrne <cb.list6@gmail.com> To: Andrew Sullivan <ajs@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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, 20 Oct 2009 15:57:32 -0000 On Tue, Oct 20, 2009 at 6:21 AM, Andrew Sullivan <ajs@shinkuro.com> wrote: > On Mon, Oct 19, 2009 at 11:01:19PM -0700, Cameron Byrne wrote: > >> boxes, with unique prefix64 A, B, and C respectively announced from >> each) and =A0the DNS64 load balances traffic (for example, round-robin >> assignments of Prefix64-A, B, and C to resolving clients) destine to >> each NAT64-A, B, C systems evenly. This way, the DNS64 drives 1/3 of >> the requests to each of the 3 NAT64 systems. =A0And, it scales linearly >> in terms of NAT64 boxes. =A0This assumes the DNS64 system scales higher >> than the NAT64 systems, which i think is a good assumption. > > As a general matter, DNS-based load balancing is broken. =A0If nothing Can you elaborate on the scale of the brokenness ? It is my understanding that DNS based load-balancing is very common on the Internet today. From a purest point of view i guess i understand, but my issue is a practical one and i see DNS based load balancing as a practical and common tool today, broken or not. > else, there are way too many examples of applications holding onto an > IP address and continuing to use it, which means that your attempts to > take things in and out of service based on what you think the DNS is > giving out will cause failures. =A0(It's also almost certainly going to > cause you heartburn with DNSSEC, but I'm just assuming here that > you're planning to give up on DNSSEC in this context.) =A0Moreover, > there are often interdependencies among different requests such that > the attempts to load balance via DNS breal the interdependencies and > cause otherwise working arrangements to fail. > > Based on that previous experience, I suspect that the above plan is > not a good idea. =A0What I would prefer to see suggested is some sort of > multiple-redundant NAT64 set, with multiple-redundant DNS64. =A0A client > should not use inconsistent sets of DNS64 servers (on a given > interface), but should stick to one set. Via DHCP i could load balance out different DNS64 address which could help me control the loading, but then my ability to spread load is in increments of users, not flows ... and the loading and failover (back pressure sensitivity) is now dependent on DHCP lease times. In reality, this would not be a huge issue and would address the problem.... But are we just shuffling the ugliness from one area to another? I still feel DNS64 is the more germane solution. > > Nevertheless, I am realistic enough to realise that your proposal is > bound to be implemented by someone, because we've invented the DNS64. > I suspect it will be fragile in exactly the ways DNS load balancing is > today. I agree. It will be implemented, better to provide guidance from the community here than leave it to a product manager. > >> Additionally, the NAT64 and the DNS64 should be able to communicate in >> such a way that the NAT64 can signal an overloading situation such >> that the DNS64 drops the overloaded NAT64 out of the round-robin >> prefix64 synthesis for some period of time. =A0This could be implemented >> as simple SNMP GET sampling of the sessions that NAT64 systems are >> currently processing. > > That does not seem to be consistent with the current DNS64 draft, > which says that the DNS64 and NAT64 share one common configuration but > are otherwise not coupled. =A0It sounds like you're proposing to > reinvent the NAT-PT DNS ALG, and if we were going to do that why > wouldn't we just write "RFC 4966 considered harmful" and be done with > it? No. Not in the least. I want the DNS64 to be more like a control plane that statelessly drives traffic to our fragile and scale-burdened NAT64 boxes. > >> Does this fit within the existing drafts? =A0Or is this implementation >> minutia that does not require being covered here? =A0At a minimum, i >> think it would be nice to have the DNS64 draft examine how the DNS64 >> system can drive load to multiple unique NAT64 systems. > > I would need quite a bit more argument in favour of this technique in > order to be co-operative about adding that sort of discussion to the > draft. =A0It is _very hard_ to control what people will do with the data > they get out of the DNS, and even the limited number of assumptions we > have in there will clearly break some installations. =A0(I have a > gateway device sitting on my desk that would almost certainly > immediately break were it to be put behind a DNS64 service, because > it's a mixed-mode iterator and forwarder.) =A0I'm not really keen on > inventing new ways to make DNS64 more fragile. Agreed, this is will make DNS64 marginally more fragile, but i believe it makes the DNS64 / NAT64 system as a whole more robust. I am most concerned with making the general case work at a high scale. Anything that needs to by-pass the NAT64 for purity / complexity sake has an incentive to move to end-to-end IPv6 communication. > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From ajs@shinkuro.com Tue Oct 20 09:18:31 2009 Return-Path: <ajs@shinkuro.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 5DCFA28C17B for <behave@core3.amsl.com>; Tue, 20 Oct 2009 09:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.811, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLyUzw8gMRxf for <behave@core3.amsl.com>; Tue, 20 Oct 2009 09:18:30 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 70F5528C12B for <behave@ietf.org>; Tue, 20 Oct 2009 09:18:30 -0700 (PDT) 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 BCF322FE8CA1 for <behave@ietf.org>; Tue, 20 Oct 2009 16:18:37 +0000 (UTC) Date: Tue, 20 Oct 2009 12:18:36 -0400 From: Andrew Sullivan <ajs@shinkuro.com> To: behave@ietf.org Message-ID: <20091020161835.GJ34289@shinkuro.com> References: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com> <20091020132145.GD34289@shinkuro.com> <bcff0fba0910200857r45d70938ge67fa7b673d00f3e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <bcff0fba0910200857r45d70938ge67fa7b673d00f3e@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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, 20 Oct 2009 16:18:31 -0000 On Tue, Oct 20, 2009 at 08:57:35AM -0700, Cameron Byrne wrote: > > Can you elaborate on the scale of the brokenness ? It is my > understanding that DNS based load-balancing is very common on the > Internet today. From a purest point of view i guess i understand, but > my issue is a practical one and i see DNS based load balancing as a > practical and common tool today, broken or not. You'll get different answers depending on whom you ask, but the basic issue is that people who get the data out of the DNS might not do what you think they will with it. There are a few basic problems: 1. Some clients cache the results of their first A record query and then keep using that, sometimes even after the TTL is expired. 2. Some clients might re-query after an expired TTL even if they're still using a connection (for instance, because they need to make a different connection). If you split them across different target servers, then depending on how your application works, you have broken state in the system, 3. There are unpredictable interactions with intermediate caches and new queries, so you can end up with inconsistent data in the cache (which results in resolution failures). You're quite right, however, that we can describe lots of things we see on the Internet as "DNS based load-balancing", and some result in more failures than others. Very often the load balancing stuff works just fine for stateless protocols like http, and since that's the bulk of the traffic any trouble it causes is all but invisible. > Via DHCP i could load balance out different DNS64 address which could > help me control the loading, but then my ability to spread load is in > increments of users, not flows ... and the loading and failover (back > pressure sensitivity) is now dependent on DHCP lease times. In > reality, this would not be a huge issue and would address the > problem.... But are we just shuffling the ugliness from one area to > another? I still feel DNS64 is the more germane solution. It does move ugliness around, but at least then users are presented with a consistent view, which means that they don't get surprise transient failures that are almost impossible to debug. (In DNS load balancing, since you get different answers from "the same server" depending on when you ask, you can be all but sure that if you try to diagnose a problem you won't be able to see it. It's almost like the cat box, where your mere act of trying to troubleshoot the problem causes traffic which alters the problem to be solved.) > > No. Not in the least. I want the DNS64 to be more like a control > plane that statelessly drives traffic to our fragile and > scale-burdened NAT64 boxes. And that's not the way the draft reads today, in which there is not supposed to be any shared state between the different services: In general, the only shared state between the DNS64 and the IPv6/IPv4 translator is the Pref64::/n and an optional set of static parameters. The Pref64::/n and the set of static parameters must be configured to be the same on both; there is no communication between the DNS64 device and IPv6/IPv4 translator functions. > Agreed, this is will make DNS64 marginally more fragile, but i believe > it makes the DNS64 / NAT64 system as a whole more robust. I am most > concerned with making the general case work at a high scale. Anything > that needs to by-pass the NAT64 for purity / complexity sake has an > incentive to move to end-to-end IPv6 communication. I have pretty grave doubts that this sort of system is going to work in a general case at high scale. But I'm content to be proven wrong. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ajs@shinkuro.com Tue Oct 20 09:21:00 2009 Return-Path: <ajs@shinkuro.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 1B8CC28C12B for <behave@core3.amsl.com>; Tue, 20 Oct 2009 09:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.839 X-Spam-Level: X-Spam-Status: No, score=-1.839 tagged_above=-999 required=5 tests=[AWL=0.760, 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 y4cM0emtBTXa for <behave@core3.amsl.com>; Tue, 20 Oct 2009 09:20:59 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 5092D28C122 for <behave@ietf.org>; Tue, 20 Oct 2009 09:20:59 -0700 (PDT) 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 CA9B22FE8CA1 for <behave@ietf.org>; Tue, 20 Oct 2009 16:21:06 +0000 (UTC) Date: Tue, 20 Oct 2009 12:21:05 -0400 From: Andrew Sullivan <ajs@shinkuro.com> To: behave@ietf.org Message-ID: <20091020162105.GK34289@shinkuro.com> References: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com> <643AD0DC-5BD4-44BD-A206-D58A5F965F3A@muada.com> <bcff0fba0910200833n61e17ba9xa239eb9f5af0b2d7@mail.gmail.com> <18F1FF50-7D5F-49DD-9C07-458862038136@muada.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18F1FF50-7D5F-49DD-9C07-458862038136@muada.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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, 20 Oct 2009 16:21:00 -0000 On Tue, Oct 20, 2009 at 05:49:07PM +0200, Iljitsch van Beijnum wrote: > > (Did we land on a conclusion on whether it would be ok to put a caching > DNS server behind a DNS64?) Yes. It will never work. We have assured that in the latest draft by saying that the additional section MUST NOT be altered. > We weren't saying that. What I was saying is that dynamically balancing > load over different NAT64s has problems for NAT traversal and what Andrew > was saying is that it probably won't work (if I'm not mistaken). Yes, that's what I'm saying. At least for some values of "work". If you think that "Internet access" means "Web access" (and one of the largest ISPs in Canada seems to think that, for instance), then maybe it'll mostly work well enough that users won't notice the breakage. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dwing@cisco.com Tue Oct 20 09:58:15 2009 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 97ACF28C0F0 for <behave@core3.amsl.com>; Tue, 20 Oct 2009 09:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ue8EZLI8onD1 for <behave@core3.amsl.com>; Tue, 20 Oct 2009 09:58:14 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9689A3A6806 for <behave@ietf.org>; Tue, 20 Oct 2009 09:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2000; q=dns/txt; s=sjiport06001; t=1256057902; x=1257267502; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Dan=20Wing"=20<dwing@cisco.com>|Subject:=20RE: =20[BEHAVE]=20=20I-D=20ACTION:draft-chen-behave-olnat-00. txt|Date:=20Tue,=2020=20Oct=202009=2009:58:23=20-0700 |Message-ID:=20<047a01ca51a6$888c0860$c4f0200a@cisco.com> |To:=20"'Chen=20Gang'"=20<phdgang@gmail.com>,=20"'Behave =20WG'"=20<behave@ietf.org>|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<36ba02 b00910192345x2dd7c680r8439fee2d0090bff@mail.gmail.com> |References:=20<36ba02b00910192345x2dd7c680r8439fee2d0090 bff@mail.gmail.com>; bh=m9FjgZwo5LlRhVDzcWoOGHmyaq5im9OZcWayVYqhTV8=; b=W9J9nG+N57dq4qhs2zVKdrxCj8OaCBhyd4jIBZpKj0PoFUkEvo0V8XmJ 12LOFEkPNV6+1C/Vh4DGQfwULPHX8y6oMZbncoWhFH8K65ZxEUc1TYHE6 wrN04/AiM4zSmwacK5SbytrhNvKJZZYI7yWVAzdqAOAOovF+wMzE9r+Ih g=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMEAPmI3UqrR7Ht/2dsb2JhbACKX7dqmEGEMQSBXA X-IronPort-AV: E=Sophos;i="4.44,592,1249257600"; d="scan'208";a="413591996" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 20 Oct 2009 16:58:22 +0000 Received: from dwingwxp01 (dhcp-171-69-132-248.cisco.com [171.69.132.248]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9KGwMX9026734; Tue, 20 Oct 2009 16:58:22 GMT From: "Dan Wing" <dwing@cisco.com> To: "'Chen Gang'" <phdgang@gmail.com>, "'Behave WG'" <behave@ietf.org> References: <36ba02b00910192345x2dd7c680r8439fee2d0090bff@mail.gmail.com> Date: Tue, 20 Oct 2009 09:58:23 -0700 Message-ID: <047a01ca51a6$888c0860$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpRUQWAaQumd8yNTtWHrlU0OL6R8AAVQXXA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <36ba02b00910192345x2dd7c680r8439fee2d0090bff@mail.gmail.com> Subject: Re: [BEHAVE] I-D ACTION:draft-chen-behave-olnat-00.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, 20 Oct 2009 16:58:15 -0000 > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Chen Gang > Sent: Monday, October 19, 2009 11:46 PM > To: Behave WG > Subject: [BEHAVE] I-D ACTION:draft-chen-behave-olnat-00.txt > > Hello all, > > We have posted a new draft about optimal load-balance for > NAT64 based on anycast mechanism. If this is going to be applicable to stateful NATs, this requires all the NATs to share state (specifically, all the NATs that are participating in this scheme on a single network). Such state sharing requires memory and a considerable amount of network traffic to keep the state synchronized. -d > Please kinldy to review it. > Any comment is welcome. > > Thanks > > -Gang > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : A Optimal Load-balance mechanism for > NAT64 (OL-NAT) > Author(s) : G. Chen, H. Deng > Filename : draft-chen-behave-olnat-00.txt > Pages : 12 > Date : 2009-10-19 > > In NAT64 scenaires,sigle-point failure is a critical issue to > restrict large-scale deployment. In order to overcome this hurdle, > this memo has proposed a optimal load-balance mechanism for NAT64. > Through the new-defined evaluation metrics, several extended ICMP > messages combining with anycast are performed to achieve optimal > NAT64 selection. Meanwihle, the synchroniztion process of > IP address > mapping information is also designed to guarantee the service > continuity. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chen-behave-olnat-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > From dthaler@microsoft.com Tue Oct 20 12:11:50 2009 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 B19083A67F5 for <behave@core3.amsl.com>; Tue, 20 Oct 2009 12:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wU5S182F9tWv for <behave@core3.amsl.com>; Tue, 20 Oct 2009 12:11:50 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 162903A67EC for <behave@ietf.org>; Tue, 20 Oct 2009 12:11:50 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 20 Oct 2009 12:11:58 -0700 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 id 14.0.639.20; Tue, 20 Oct 2009 12:11:57 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Tue, 20 Oct 2009 12:11:58 -0700 From: Dave Thaler <dthaler@microsoft.com> To: Behave WG <behave@ietf.org> Thread-Topic: Request for agenda topic for tomorrow's interim meeting Thread-Index: AcpRuTCVKxZR66vORRG5AL2Kg4ThLg== Date: Tue, 20 Oct 2009 19:11:55 +0000 Message-ID: <E4561B14EE2A3E4E9D478EBFB5416E1B29B0A56C@TK5EX14MBXW653.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_E4561B14EE2A3E4E9D478EBFB5416E1B29B0A56CTK5EX14MBXW653w_" MIME-Version: 1.0 Subject: [BEHAVE] Request for agenda topic for tomorrow's interim meeting 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, 20 Oct 2009 19:11:50 -0000 --_000_E4561B14EE2A3E4E9D478EBFB5416E1B29B0A56CTK5EX14MBXW653w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reminder: We have a virtual interim meeting tomorrow. Please send agenda requests (and slides) to the chairs ASAP if you want time on the agenda. -Dave --_000_E4561B14EE2A3E4E9D478EBFB5416E1B29B0A56CTK5EX14MBXW653w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m= icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office= :access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"= uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof= t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co= m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee= t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns= :odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro= soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" = xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m= icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://= schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share= point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel= /2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois= =3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://= schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3= .org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint= /dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http= ://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha= repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"= xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://= schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001= /XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so= ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc= p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/= /schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche= mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi= crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat= s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf= ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c= om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa= ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web= partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20= 06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200= 6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli= deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal= Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:= st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"= > <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-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-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.Section1 {page:Section1;} --> </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 vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal>Reminder: We have a virtual interim meeting tomorrow.<= o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Please send agenda requests (and slides) to the chairs= ASAP if you want <o:p></o:p></p> <p class=3DMsoNormal>time on the agenda.<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>-Dave<o:p></o:p></p> </div> </body> </html> --_000_E4561B14EE2A3E4E9D478EBFB5416E1B29B0A56CTK5EX14MBXW653w_-- From petithug@acm.org Tue Oct 20 12:12:42 2009 Return-Path: <petithug@acm.org> 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 BD4313A68D0; Tue, 20 Oct 2009 12:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.111 X-Spam-Level: X-Spam-Status: No, score=-102.111 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 i9ZT1isrfy+x; Tue, 20 Oct 2009 12:12:41 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id A36A63A67EC; Tue, 20 Oct 2009 12:12:38 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 863156C98530; Tue, 20 Oct 2009 19:12:45 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 32C236C98528; Tue, 20 Oct 2009 19:12:44 +0000 (UTC) Message-ID: <4ADE0BAB.1040402@acm.org> Date: Tue, 20 Oct 2009 12:12:43 -0700 From: Marc Petit-Huguenin <petithug@acm.org> User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: Margaret Wasserman <mrw@lilacglade.org> References: <01c101ca509f$f314a8c0$8e27460a@china.huawei.com> <61FFB311-CA42-4EE4-A6F9-3DE0581A9E8F@lilacglade.org> In-Reply-To: <61FFB311-CA42-4EE4-A6F9-3DE0581A9E8F@lilacglade.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ops-dir@ietf.org, Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Opsdir Review of draft-ietf-behave-turn-uri-03.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, 20 Oct 2009 19:12:42 -0000 Hi Margaret, Thanks for your review. Please see my comments inline. Margaret Wasserman wrote: > > Hello Behave Folks, > > As a member of the Operations Directorate, I was asked to review > draft-ietf-behave-turn-uri-03.txt. > > I have some operational concerns with this document that should probably > be resolved before the document is published. I apologize in advance > if my comments reflect a lack of knowledge of this subject. > > In section 4, there is a numbered list of ways in which the TURN > resolution may be processed, and this appears to be the core of the > document. I have spent a considerable amount of time trying to figure > out what this list says, and I have not been completely successful. > My current understanding is as follows: > > (1.) If the <host> is an IP address, the other fields are filled in as > follows: > > - <port> is set to the value in the URI if present, or to the > default in draft-ietf-behave-turn. > - If <transport> is defined: > > <scheme> and <transport> are converted to a TURN transport. > - If <transport> is not defined: > > The supported transports are tried in order of > preference. Correct. > > If <host> is a Domain Name, the fields are filled in as follows: > > (2.)- If <port> is defined: > > <host> is resolved to a list of IP addresses via DNS. > > If <transport> is defined: > >> <scheme> and <transport> are converted to a TURN > transport > > If <transport> is not defined: > >> The supported transports are tried in order of > preference. Correct. > > - If <port> is not defined: > (3.) > If <transport> is defined: > >> <host> is converted to list of IP address > and port tuples via a DNS SRV query, with > <scheme> as the service name and <transport> > as the protocol name. > > [There is some wording here about the fact that the > SRV algorith recommends doing an A query, but it > doesn't actually say to do one, and the text above > this already indicates that you would have reached > the TURN server or returned an error.] No, the SRV algorithm says to try the SRV RR, then the A RR if everything fails. The text in the I-D modifies the SRV algorithm by specifying what to do if everything fails: Use the default port and also do an AAAA RR query (OT: RFC 2782 could probably benefit from an update at some point in the future). I reorganized the paragraph as follow. Let me know if this made the intent easier to understand: "3. If <host> is a domain name and <port> is not defined but <transport> is defined, then <host> is converted to a list of IP address and port tuples via a DNS SRV query as defined in [I-D.ietf-behave-turn] section 6.1. <scheme> is used for the service name and <transport> is used for the protocol name in the SRV algorithm [RFC2782]. The SRV algorithm recommends doing an A query if the SRV query returns an error or no SRV RR; in this case the default port declared in [I-D.ietf-behave-turn] for the SRV service name defined in <scheme> MUST be used for contacting the TURN server. Also in this case, this specification modifies the SRV algorithm by recommending an A and AAAA query. If the TURN client cannot contact a TURN server at any of the IP address, port and transport tuples returned by the SRV algorithm then the resolution MUST stop with an error." > > (4.) > If <transport> is not defined: > >> <host> is convered to an ordered list of > IP Address, port and and transport tuples > via the S-NAPTR algorithm. > >> The TURN transports supported by the > application are then converted into > Application Protocol Tags, and the protocol > tags are "tried" in some order. > > [It is not clear, to me, what it means to > "try" a protocol tag. Also, we seem to > using all of the tags supported by the > application, not anything returned from > the S-NAPTR algorithm?] > > [Again, we have the problem that there is > text after the previous text has either > succeeded or returned an error. In this > case, it says that the <host> is converted > to a list of IP Address and Port tuples > using the algorithm in section 3 "for each > of the TURN transports supported by the > application". It is not clear to me what > this means, exactly.] Here's a reorganized version of the text. Let me know if this made the intent easier to understand: "4. If <host> is a domain name and <port> and <transport> are not defined, then <host> is converted to an ordered list of IP address, port and transport tuples via the S-NAPTR algorithm defined in [RFC3958] with a "RELAY" Application Service Tag. The TURN transports supported by the application are converted in Application Protocol Tags by using "turn.udp" if the TURN transport is UDP, "turn.tcp" if the TURN transport is TCP and "turn.tls" if the TURN transport is TLS. The order to try the Application Protocol Tags is provided by the ranking of the first set of NAPTR records. If multiple Application Protocol Tags have the same ranking, the preferred order set by the application is used. If the first NAPTR SRV query does not return any result then <host> is converted to a list of IP address and port tuples by using the algorithm specified in step 3 for each of the TURN transports supported by the application in order of preference. If the TURN client cannot contact a TURN server with any of the IP address, port and transport tuples returned by the S-NAPTR algorithm, then the resolution MUST stop with an error." > > In addition to not being able to decipher exactly what steps > should be performed, I am somewhat concerned about what I > consider to be an artificial distinction between domain names > and IP addresses. Is it actually the case that you cannot > use the S-NAPTR algorithm and/or look up SRV records using an > IP address instead of a Domain Name? Yes, S-NAPTR and SRV resolution can only be done on domain names. > I am somewhat concerned > about the impacts of this choice on management and debugging, > although I am not sure if the problem lies in this document > or in the S-NAPTR and SRV documents. RFC 3958 section 3.2 lists some guidelines that apply also to this I-D. > > I also have a couple of suggestions that might make the URI scheme > more straightforward for operators and users: > > (1) Why is it desirable to overload the transport name "tcp" in the > URI scheme to mean TCP for TURN and TLS for TURNS, when similar > overloading is not present in the NAPTR definition? Is there some > advantage to doing so that offsets the potential for confusion? This is inspired by the SIP/SIPS URI schemes and as TURN is mostly used in a VoIP context, the confusion seems less likely. I considered referencing the uri-transports[1] I-D but abandoned this idea as it is targeted for Experimental. > > (2) At various places in this document, decision trees are represented > as numbered or bulleted lists, instead of laying out the choices > at each layer. While I think that the lists are logically > consistent and represent all of the choices, this format does not > make it easy to tell. What format would you suggest to use? I tried to write the most concise and formal description that I could (as a developer, I have very little patience with verbose and/or imprecise RFC), but I am open to any way to improve the text. > > (3) It would be better to include a more complete range of examples > showing all of the different permutations. I have a full set of examples (which are in fact my unit tests) that I can add to the I-D, but as a developer I am a bit reluctant to do this as I consider examples in RFCs as been harmful (thanks to so called developers who think that they can implement an RFC just by looking at the examples). This said, as the editor of this I-D, I will add more examples if requested. [1] http://tools.ietf.org/html/draft-wood-tae-specifying-uri-transports -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From brian.e.carpenter@gmail.com Tue Oct 20 13:43:56 2009 Return-Path: <brian.e.carpenter@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 E22D43A6816 for <behave@core3.amsl.com>; Tue, 20 Oct 2009 13:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 FeMDkRHq6mNd for <behave@core3.amsl.com>; Tue, 20 Oct 2009 13:43:56 -0700 (PDT) Received: from mail-px0-f173.google.com (mail-px0-f173.google.com [209.85.216.173]) by core3.amsl.com (Postfix) with ESMTP id 367EC3A6825 for <behave@ietf.org>; Tue, 20 Oct 2009 13:43:56 -0700 (PDT) Received: by pxi3 with SMTP id 3so6269453pxi.29 for <behave@ietf.org>; Tue, 20 Oct 2009 13:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Bjff2wehB6qa7UtSCmY4Lb1RpOOjzMSpGoEf2DE6mt0=; b=doIszhcYzjpQBjFAwL/BickHmqtD6Rz5XTFpVXTnh8Z/Rs0Uy1E0hGfYIAIhUAn2ab YFFdAHGBHLA7bnJqDqZdYW+ZFaXNv6LvcjEdtW11EX0GPrY0umLqjRZDF/a9yY6+2kzG Wmjb/xYByMfl41DApXVhjKO1bsldWwuBqfd8s= 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=yAXW4pEhdGybdQqLNZM/ALoTEvY9ZNiSTMYymCZf9tmW1sMKEGPz3QQVyZwjb3IEOY AnOeFA/m01sEAbIns1djeeAejpDoY3qvn9sD47qLwcWM6Qb1VPxCeO/z2QpA+CAbd371 MSU1sixidXniijdWTYJHPIvPa6hDyJzOZ0yCw= Received: by 10.115.67.30 with SMTP id u30mr10030165wak.119.1256071441867; Tue, 20 Oct 2009 13:44:01 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 20sm185166pxi.11.2009.10.20.13.44.00 (version=SSLv3 cipher=RC4-MD5); Tue, 20 Oct 2009 13:44:01 -0700 (PDT) Message-ID: <4ADE210F.8030001@gmail.com> Date: Wed, 21 Oct 2009 09:43:59 +1300 From: Brian E Carpenter <brian.e.carpenter@gmail.com> Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cameron Byrne <cb.list6@gmail.com> References: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com> In-Reply-To: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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, 20 Oct 2009 20:43:57 -0000 Cameron, Perhaps if you rephrase your requirement as "load sharing" instead of "load balancing", you can find a scalable solution. Basically, I would suggest that if you calculate that the maximum safe load for a DNS64/NAT64 pair is N hosts, you need to configure the network in such away that only N hosts will actually use each pair. Yes, that means that each DNS64/NAT64 pair becomes a single point of failure for N hosts. But that's been part of the price of NAT since NAT was invented. It also means a different Pref64::/n for each pair, but so what? I can't see anything but a sea of troubles in dynamic load balancing and failover, for all the reasons given by others. Brian From ajs@shinkuro.com Tue Oct 20 13:49:22 2009 Return-Path: <ajs@shinkuro.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 6D5363A686A for <behave@core3.amsl.com>; Tue, 20 Oct 2009 13:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=0.716, 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 ralCgdNGniL8 for <behave@core3.amsl.com>; Tue, 20 Oct 2009 13:49:21 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id C0C7E3A6816 for <behave@ietf.org>; Tue, 20 Oct 2009 13:49:21 -0700 (PDT) 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 391A92FE8CA1 for <behave@ietf.org>; Tue, 20 Oct 2009 20:49:29 +0000 (UTC) Date: Tue, 20 Oct 2009 16:49:27 -0400 From: Andrew Sullivan <ajs@shinkuro.com> To: behave@ietf.org Message-ID: <20091020204927.GG35537@shinkuro.com> References: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com> <4ADE210F.8030001@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ADE210F.8030001@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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, 20 Oct 2009 20:49:22 -0000 On Wed, Oct 21, 2009 at 09:43:59AM +1300, Brian E Carpenter wrote: > Yes, that means that each DNS64/NAT64 pair becomes a single > point of failure for N hosts. But that's been part of the price > of NAT since NAT was invented. It also means a different > Pref64::/n for each pair, but so what? I like that approach also because it seems not to violate the KISS principle. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dthaler@microsoft.com Tue Oct 20 13:53:16 2009 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 37FB23A6864 for <behave@core3.amsl.com>; Tue, 20 Oct 2009 13:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 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 jgQD3qMEA+H8 for <behave@core3.amsl.com>; Tue, 20 Oct 2009 13:53:15 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 488EC3A6816 for <behave@ietf.org>; Tue, 20 Oct 2009 13:53:15 -0700 (PDT) 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; Tue, 20 Oct 2009 13:53:32 -0700 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 id 14.0.639.20; Tue, 20 Oct 2009 13:53:23 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Tue, 20 Oct 2009 13:53:23 -0700 From: Dave Thaler <dthaler@microsoft.com> To: Behave WG <behave@ietf.org> Thread-Topic: Request for agenda topic for tomorrow's interim meeting Thread-Index: AcpRuTCVKxZR66vORRG5AL2Kg4ThLgADf9mA Date: Tue, 20 Oct 2009 20:53:20 +0000 Message-ID: <E4561B14EE2A3E4E9D478EBFB5416E1B29B0ABD1@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> References: <E4561B14EE2A3E4E9D478EBFB5416E1B29B0A56C@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <E4561B14EE2A3E4E9D478EBFB5416E1B29B0A56C@TK5EX14MBXW653.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_E4561B14EE2A3E4E9D478EBFB5416E1B29B0ABD1TK5EX14MBXW653w_" MIME-Version: 1.0 Subject: Re: [BEHAVE] Request for agenda topic for tomorrow's interim meeting 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, 20 Oct 2009 20:53:16 -0000 --_000_E4561B14EE2A3E4E9D478EBFB5416E1B29B0ABD1TK5EX14MBXW653w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The meeting information, agenda, and materials received so far, are now all posted at http://trac.tools.ietf.org/wg/behave/trac/wiki/WikiStart Let me know if there are additional agenda item requests. -Dave From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Dave Thaler Sent: Tuesday, October 20, 2009 12:12 PM To: Behave WG Subject: [BEHAVE] Request for agenda topic for tomorrow's interim meeting Reminder: We have a virtual interim meeting tomorrow. Please send agenda requests (and slides) to the chairs ASAP if you want time on the agenda. -Dave --_000_E4561B14EE2A3E4E9D478EBFB5416E1B29B0ABD1TK5EX14MBXW653w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m= icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office= :access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"= uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof= t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co= m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee= t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns= :odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro= soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" = xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m= icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://= schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share= point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel= /2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois= =3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://= schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3= .org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint= /dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http= ://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha= repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"= xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://= schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001= /XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so= ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc= p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/= /schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche= mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi= crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat= s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf= ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c= om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa= ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web= partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20= 06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200= 6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli= deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal= Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:= st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"= > <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @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:11.0pt; font-family:"Calibri","sans-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; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.Section1 {page:Section1;} --> </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 vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><span style=3D'color:#1F497D'>The meeting information,= agenda, and materials received so far, are now all<o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'color:#1F497D'>posted at <a href=3D"http://trac.tools.ietf.org/wg/behave/trac/wiki/WikiStart">http://tr= ac.tools.ietf.org/wg/behave/trac/wiki/WikiStart</a><o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p> </o:p></span>= </p> <p class=3DMsoNormal><span style=3D'color:#1F497D'>Let me know if there are additional agenda item requests.<o:p></o:p></span></p> <p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p> </o:p></span>= </p> <p class=3DMsoNormal><span style=3D'color:#1F497D'>-Dave<o:p></o:p></span><= /p> <p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p> </o:p></span>= </p> <div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt'> <div> <div style=3D'border:none;border-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-bounce= s@ietf.org [mailto:behave-bounces@ietf.org] <b>On Behalf Of </b>Dave Thaler<br> <b>Sent:</b> Tuesday, October 20, 2009 12:12 PM<br> <b>To:</b> Behave WG<br> <b>Subject:</b> [BEHAVE] Request for agenda topic for tomorrow's interim meeting<o:p></o:p></span></p> </div> </div> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Reminder: We have a virtual interim meeting tomorrow.<= o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Please send agenda requests (and slides) to the chairs= ASAP if you want <o:p></o:p></p> <p class=3DMsoNormal>time on the agenda.<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>-Dave<o:p></o:p></p> </div> </div> </body> </html> --_000_E4561B14EE2A3E4E9D478EBFB5416E1B29B0ABD1TK5EX14MBXW653w_-- From cb.list6@gmail.com Tue Oct 20 15:15:05 2009 Return-Path: <cb.list6@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 6F3643A6960 for <behave@core3.amsl.com>; Tue, 20 Oct 2009 15:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 ZhaHfYpQ7G0r for <behave@core3.amsl.com>; Tue, 20 Oct 2009 15:15:04 -0700 (PDT) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 92E2B3A680C for <behave@ietf.org>; Tue, 20 Oct 2009 15:15:04 -0700 (PDT) Received: by pzk6 with SMTP id 6so7914884pzk.29 for <behave@ietf.org>; Tue, 20 Oct 2009 15:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AVVdTLJNEXNjx1WBrNA1x1Sj+LpNs1ahq2HV3OdvxpQ=; b=ilsvm+NSzduP9oduDjZ9vBqLZqshvrf1MCrmrnthMe1v3c4KUqyQLXyaz6gL1WK3Bh leOk079RpYXfJvZ/sFPPWZQZ2rXRngqZO5Nb4oUAr/t0fRs7doHSjjoc4ZZ/Ahx4IKv6 S9r0wMVYjRKdcTM5osz6w9O4taOWOwnxd0HGY= 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=n5iLODnDwMubjYh+mh9gbGkV/mUbLPGEOxRQQ82eq4P6BR3i/ZBG/XzkXBVc+4YaF5 18ccRrEQ8AwQCSGpwZNG5+XjWFw9JlzSbRz3lpj5oDpPoqwaeUKxBDlBAQ4xboDm+7++ RffMnh3rKVhCYQZqj8E8QOABAK2+aHpAEP6zo= MIME-Version: 1.0 Received: by 10.143.21.42 with SMTP id y42mr490522wfi.207.1256076909368; Tue, 20 Oct 2009 15:15:09 -0700 (PDT) In-Reply-To: <4ADE210F.8030001@gmail.com> References: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com> <4ADE210F.8030001@gmail.com> Date: Tue, 20 Oct 2009 15:15:09 -0700 Message-ID: <bcff0fba0910201515y104ef889o6eb44141e436a979@mail.gmail.com> From: Cameron Byrne <cb.list6@gmail.com> To: Brian E Carpenter <brian.e.carpenter@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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, 20 Oct 2009 22:15:05 -0000 On Tue, Oct 20, 2009 at 1:43 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: > Cameron, > > Perhaps if you rephrase your requirement as "load sharing" instead > of "load balancing", you can find a scalable solution. Basically, Sharing or balancing both work for me. I understand the semantics can be important, but load sharing works plenty fine for me. > I would suggest that if you calculate that the maximum safe > load for a DNS64/NAT64 pair is N hosts, you need to configure > the network in such away that only N hosts will actually use > each pair. > > Yes, that means that each DNS64/NAT64 pair becomes a single > point of failure for N hosts. But that's been part of the price > of NAT since NAT was invented. It also means a different > Pref64::/n for each pair, but so what? Yeah, using many Pref64 is no big deal. Also, there is no reason to have a single point of failure. I generally pass 2 DNS servers to my customers today. I can do the same in the future, but in this case i am passing them 2 DNS64s what are coupled with 2 NAT64, all transparent to the user. Also, most NAT44 deployments in carriers are 1+1 redundant. Today, my NAT44 deployment is 1+1 active / standby + load sharing using sourced / policy based routing. Scaling linearly is a requirement in my world. > > I can't see anything but a sea of troubles in dynamic load > balancing and failover, for all the reasons given by others. When I learned about NAT64 a few months back, i thought it was great that the DNS-ALG / DNS64 was decoupled from the NAT64. I assumed that was to facilitate better end to end IPv6 communication and to assist in the scaling of the NAT64 -- the part with the failure prone ALGs and limited resources in session setup, packets per second ... At that time, I assumed there would be many NAT64 boxes to 1 DNS64 box deployment and it made sense. Today, I have many NAT44 boxes and 1 anycast (many servers with the same IP) IPv4 DNS deployment. I understand to some degree the groups concerns that it may be ugly, but I have worked for more than one network operator ... and yes, things are sometimes ugly, they are robust and at the same time fragile, especially when we have to react on the fly and make tactical decisions about scaling. But, personally, i think geo-DNS and DNS based load sharing are good things in today's internet. I really don't think the Internet would be where it is today (the good parts) without making these trade-offs in favor of scaling. I think tinkering with DHCP DNS servers may work, but ultimately vendors that give me, the network operator, more control will win the RFP. Added control and "reliability" features frequently are the headlines for vendor differentiation. At least, when i look at my infrastructure today, that is what i see. Geo-load balanced DNS and all. Cameron > > =A0 Brian > From xuxh@huawei.com Tue Oct 20 19:27:53 2009 Return-Path: <xuxh@huawei.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 114873A6839 for <behave@core3.amsl.com>; Tue, 20 Oct 2009 19:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[AWL=2.064, 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 ZQ16vf3Ji-Zc for <behave@core3.amsl.com>; Tue, 20 Oct 2009 19:27:52 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 22E843A6405 for <behave@ietf.org>; Tue, 20 Oct 2009 19:27:52 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRU00FD9EUMGT@szxga02-in.huawei.com> for behave@ietf.org; Wed, 21 Oct 2009 10:27:58 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRU0069FEUM3Y@szxga02-in.huawei.com> for behave@ietf.org; Wed, 21 Oct 2009 10:27:58 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRU00ECVEULCT@szxml06-in.huawei.com> for behave@ietf.org; Wed, 21 Oct 2009 10:27:58 +0800 (CST) Date: Wed, 21 Oct 2009 10:27:56 +0800 From: Xu Xiaohu <xuxh@huawei.com> In-reply-to: <18F1FF50-7D5F-49DD-9C07-458862038136@muada.com> To: 'Iljitsch van Beijnum' <iljitsch@muada.com>, 'Cameron Byrne' <cb.list6@gmail.com> Message-id: <003301ca51f6$19f82d20$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpRnOV2BkeqDl2gTsq8Fhh8MyaAIAAUwbrA Cc: behave@ietf.org Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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: Wed, 21 Oct 2009 02:27:53 -0000 > The requirement is that the DNS64 that a host uses and the NAT64 that > a host uses agree on the prefix. One very simple way to do this is to > have one prefix that is shared by a bunch of NAT64s (like a well-known > prefix). The disadvantage of that approach is that you can't use > different prefixes to make traffic move to different NAT64s, which is > probably something you want in a setup like yours. Another disadvantage of using the same prefix on different NAT64 boxes for load-balancing is that an internal topology change of the IPv6 network will possibly cause the packets of the same session to traverse different NAT64 boxes. In order to make the session survive from the NAT64 change, the mapping states have to be synchronized among these NAT64 boxes. > You can also first move the DNS request to the right (cluster of) DNS64 > (s) by simply giving different hosts different DNS resolver addresses. > So unlike NAT44, you're pretty free to place the boxes where you want > rather than be forced to place them where the traffic happens to be. > > I would also talk to my vendors and ask them for the ability to send > different DNS64 replies to different hosts based on their source > addresses. This limits the number of DNS64 boxes that you need. Besides using different prefix64s for address synthesis according to the different DNS clients, the DNS64 server could also use different prefix64s according to different A records in the received DNS replies. Similarly, if the IPv6 host itself implements the IPv6 address synthesis by using the prefix64 learnt from DNS, DHCPv6 or RA (see draft-wing-behave-learn-prefix), the DNS and DHCP server could also provides different prefix64s according to different clients, and the gateways(default routers) could announces different prefix64s to different subnets. Of course, multiple prefix64 can also be offered to the IPv6 hosts and make them choose which prefix64 to use according to the similar rules as mentioned above. Xiaohu From xuxh@huawei.com Tue Oct 20 20:19:15 2009 Return-Path: <xuxh@huawei.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 AFAE728C112 for <behave@core3.amsl.com>; Tue, 20 Oct 2009 20:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.051 X-Spam-Level: X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[AWL=1.548, 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 nP8oVsCjWNNB for <behave@core3.amsl.com>; Tue, 20 Oct 2009 20:19:15 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id D66853A6908 for <behave@ietf.org>; Tue, 20 Oct 2009 20:19:14 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRU00F2DH89FM@szxga03-in.huawei.com> for behave@ietf.org; Wed, 21 Oct 2009 11:19:21 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRU00E8GH89NY@szxga03-in.huawei.com> for behave@ietf.org; Wed, 21 Oct 2009 11:19:21 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRU00H8OH89AX@szxml04-in.huawei.com> for behave@ietf.org; Wed, 21 Oct 2009 11:19:21 +0800 (CST) Date: Wed, 21 Oct 2009 11:19:20 +0800 From: Xu Xiaohu <xuxh@huawei.com> In-reply-to: <bcff0fba0910200841u73b1e05bu651a30cb48f5c17e@mail.gmail.com> To: behave@ietf.org Message-id: <003801ca51fd$482aca20$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpRm+GWEcy9rdMoSUCX/MbrHVDYLAAX+fag Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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: Wed, 21 Oct 2009 03:19:15 -0000 > > In the following draft > > (http://tools.ietf.org/id/draft-xu-behave-nat64-standby-00.txt), some > > consideration about the load-balancing together with redundancy is > > discussed. Of course, this demo does not discuss the issues with achieving > > best balance by adjusting the numbers of hosts adopting different prefix64s > > since there are many possible options to achieve this, e.g., by using DNS64, > > or using prefix-learning mechanism defined in > > [draft-wing-behave-learn-prefix-03]. > > > > Xiaohu > > The mechanics in this draft are very similar to the state of the > practice today in any vendors NAT44 implementation. Today, most NAT44 > products do the things described in this draft. Hi all, Is it necessary to standardize the redundancy and load-balancing mechanisms of large-scale NAT (also called CGN), including NAT64, NAT44 and even NAT46? Xiaohu From mohamed.boucadair@orange-ftgroup.com Tue Oct 20 23:06:58 2009 Return-Path: <mohamed.boucadair@orange-ftgroup.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 2131F3A68D1; Tue, 20 Oct 2009 23:06:58 -0700 (PDT) X-Quarantine-ID: <Zm8ohJZSBgZa> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 Zm8ohJZSBgZa; Tue, 20 Oct 2009 23:06:57 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 0335E3A6807; Tue, 20 Oct 2009 23:06:56 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 5AA6B278158; Wed, 21 Oct 2009 08:07:04 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 40568238059; Wed, 21 Oct 2009 08:07:04 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Wed, 21 Oct 2009 08:07:04 +0200 From: <mohamed.boucadair@orange-ftgroup.com> To: "behave@ietf.org" <behave@ietf.org>, "ospf@ietf.org" <ospf@ietf.org> Date: Wed, 21 Oct 2009 08:07:03 +0200 Thread-Topic: Multi-Topology/Instance OSPFv3 for IPv4-mapped IPv6 Thread-Index: AcpRe1/fHlMnoBdFT9yZh3ykdeCzHwAmMCuw Message-ID: <28623_1256105224_4ADEA508_28623_8299_1_94C682931C08B048B7A8645303FDC9F30781AA5276@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: fr-FR x-tm-as-product-ver: SMEX-8.0.0.1259-5.600.1016-16652.007 x-tm-as-result: No--32.731800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/mixed; boundary="_002_94C682931C08B048B7A8645303FDC9F30781AA5276PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.10.21.55125 Subject: [BEHAVE] Multi-Topology/Instance OSPFv3 for IPv4-mapped IPv6 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: Wed, 21 Oct 2009 06:06:58 -0000 --_002_94C682931C08B048B7A8645303FDC9F30781AA5276PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Dear all, FYI. We submitted the following draft. Comments are more than welcome. Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de Internet-Drafts@ietf.org Envoy=E9 : mardi 20 octobre 2009 13:45 =C0 : i-d-announce@ietf.org Objet : I-D Action:draft-boucadair-ospf-v4v6-ospfv3-mt-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Multi-Topology OSPFv3 for IPv4-mapped IPv6 Author(s) : M. Boucadair, et al. Filename : draft-boucadair-ospf-v4v6-ospfv3-mt-01.txt Pages : 7 Date : 2009-10-20 This memo defines two new Multi Topology Routing Identifiers (MT IDs) in OS= PFv3 [RFC2740]). These new MT-OSPFv3 [I-D.ietf-ospf-mt-ospfv3] topologies = are meant to convey routing information which is restricted to IPv4-mapped = IPv6 addresses [I-D.ietf-behave-address-format]. The goal of running separ= ate instances for IPv4-mapped IPv6 routes is to isolate the IPv6 routing ta= ble from the IPv4 routing table, and to avoid any overload due to the popul= ation of the table by IPv4-inferred routes. This isolation is motivated al= so from an operational perspective to enforce specific routing policies for= each topology. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boucadair-ospf-v4v6-ospfv3-mt-01.= txt The URL for the multi-instance draft is: http://www.ietf.org/internet-drafts/draft-boucadair-ospf-v4v6-ospfv3-mi-01.= txt ********************************* 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. ******************************** --_002_94C682931C08B048B7A8645303FDC9F30781AA5276PUEXCB1Bnante_ Content-Type: message/external-body; name="draft-boucadair-ospf-v4v6-ospfv3-mt-01.url" Content-Description: draft-boucadair-ospf-v4v6-ospfv3-mt-01.url Content-Disposition: attachment; filename="draft-boucadair-ospf-v4v6-ospfv3-mt-01.url"; size=103; creation-date="Tue, 20 Oct 2009 13:49:26 GMT"; modification-date="Tue, 20 Oct 2009 13:49:26 GMT" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1ib3VjYWRhaXItb3NwZi12NHY2LW9zcGZ2My1tdC0wMS50eHQNCg== --_002_94C682931C08B048B7A8645303FDC9F30781AA5276PUEXCB1Bnante_-- From phdgang@gmail.com Tue Oct 20 23:40:08 2009 Return-Path: <phdgang@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 A05483A6407 for <behave@core3.amsl.com>; Tue, 20 Oct 2009 23:40:08 -0700 (PDT) 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 lnYq4YAQgdMo for <behave@core3.amsl.com>; Tue, 20 Oct 2009 23:40:07 -0700 (PDT) Received: from mail-px0-f173.google.com (mail-px0-f173.google.com [209.85.216.173]) by core3.amsl.com (Postfix) with ESMTP id 1E5193A685B for <behave@ietf.org>; Tue, 20 Oct 2009 23:40:06 -0700 (PDT) Received: by pxi3 with SMTP id 3so6626003pxi.29 for <behave@ietf.org>; Tue, 20 Oct 2009 23:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=yh525SqvFUDtTs3zuva8fc7ClHIhhJyf+qklGsbXqBg=; b=CuBtMDxHk3AaEDapP8V0zhl+tg9e5pE3j8msizlrWMwrg4KPSF1HbYd75hVm0UPeLB IhcTwt7IYJCGBdAJ7m251oW0XhTKMEvE4zAu3tr2uL7ZFt4e+IqDbT0/TzmyxGY+4eM4 mGmgLhr914ERFwiQ2Lac3Uf3SJzxGhg+QssDg= 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=wcaNUMyZ3e3kQ0MAdDy5lnuBZ+y8zDmkoki6IouwxIg5ayqMSeTf61cof8BjTmsKCd 8TT8YOyLyChxXEfpKc6etix+x8Am3ZFQ8LWYsDrtlkst9paXQgJPTXTbOnkXS7xnX/QE uWEV+Dp7thOIeZDsZqweIGKBROA7/wvP+AYac= MIME-Version: 1.0 Received: by 10.142.66.15 with SMTP id o15mr487272wfa.145.1256107212126; Tue, 20 Oct 2009 23:40:12 -0700 (PDT) In-Reply-To: <047a01ca51a6$888c0860$c4f0200a@cisco.com> References: <36ba02b00910192345x2dd7c680r8439fee2d0090bff@mail.gmail.com> <047a01ca51a6$888c0860$c4f0200a@cisco.com> Date: Wed, 21 Oct 2009 14:40:12 +0800 Message-ID: <36ba02b00910202340k5d0043c0h924f0c9b5d36208c@mail.gmail.com> From: Chen Gang <phdgang@gmail.com> To: Dan Wing <dwing@cisco.com> Content-Type: multipart/alternative; boundary=001636e90a212db97a04766c40ba Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] I-D ACTION:draft-chen-behave-olnat-00.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: Wed, 21 Oct 2009 06:40:09 -0000 --001636e90a212db97a04766c40ba Content-Type: text/plain; charset=ISO-8859-1 2009/10/21 Dan Wing <dwing@cisco.com> > > -----Original Message----- > > From: behave-bounces@ietf.org > > [mailto:behave-bounces@ietf.org] On Behalf Of Chen Gang > > Sent: Monday, October 19, 2009 11:46 PM > > To: Behave WG > > Subject: [BEHAVE] I-D ACTION:draft-chen-behave-olnat-00.txt > > > > Hello all, > > > > We have posted a new draft about optimal load-balance for > > NAT64 based on anycast mechanism. > > If this is going to be applicable to stateful NATs, this requires > all the NATs to share state (specifically, all the NATs that are > participating in this scheme on a single network). Such state > sharing requires memory and a considerable amount of network > traffic to keep the state synchronized. > > -d > Thanks for your comments. For memory issues and considerable sychronization traffic, we could shrink mapping states by constructing a virtual group, which identified by a specific anycast address and multicast address. Depending on that, only NATs within the virtual group are required to share state. Meanwhile, the update traffic could be also decreased. In addition, the update traffic could be reduced by configuring a proper sychchronization interval. I will revise the draft to clarify above considerations. BRs -Gang > > > > Please kinldy to review it. > > Any comment is welcome. > > > > Thanks > > > > -Gang > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : A Optimal Load-balance mechanism for > > NAT64 (OL-NAT) > > Author(s) : G. Chen, H. Deng > > Filename : draft-chen-behave-olnat-00.txt > > Pages : 12 > > Date : 2009-10-19 > > > > In NAT64 scenaires,sigle-point failure is a critical issue to > > restrict large-scale deployment. In order to overcome this hurdle, > > this memo has proposed a optimal load-balance mechanism for NAT64. > > Through the new-defined evaluation metrics, several extended ICMP > > messages combining with anycast are performed to achieve optimal > > NAT64 selection. Meanwihle, the synchroniztion process of > > IP address > > mapping information is also designed to guarantee the service > > continuity. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-chen-behave-olnat-00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > --001636e90a212db97a04766c40ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br> <div class=3D"gmail_quote">2009/10/21 Dan Wing <span dir=3D"ltr"><<a hre= f=3D"mailto:dwing@cisco.com">dwing@cisco.com</a>></span><br> <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0= px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"> <div class=3D"im">> -----Original Message-----<br>> From: <a href=3D"= mailto:behave-bounces@ietf.org">behave-bounces@ietf.org</a><br>> [mailto= :<a href=3D"mailto:behave-bounces@ietf.org">behave-bounces@ietf.org</a>] On= Behalf Of Chen Gang<br> > Sent: Monday, October 19, 2009 11:46 PM<br>> To: Behave WG<br>> = Subject: [BEHAVE] I-D ACTION:draft-chen-behave-olnat-00.txt<br>><br>>= Hello all,<br>><br>> We have posted a new draft about optimal load-b= alance for<br> > NAT64 based on anycast mechanism.<br><br></div>If this is going to be = applicable to stateful NATs, this requires<br>all the NATs to share state (= specifically, all the NATs that are<br>participating in this scheme on a si= ngle network). =A0Such state<br> sharing requires memory and a considerable amount of network<br>traffic to = keep the state synchronized.<br><font color=3D"#888888"><br>-d<br></font></= blockquote> <div>=A0</div> <div>=A0</div> <div>=A0</div> <div>Thanks for your comments.</div> <div>For memory issues and considerable=A0sychronization traffic, we could = shrink mapping states=A0by constructing a virtual group, which identified b= y a specific anycast address and multicast address.=A0Depending on that, on= ly=A0NATs within the virtual group are required to share state.=A0Meanwhile= , the update traffic could be also decreased. In addition,=A0the update tra= ffic could be reduced by configuring a proper sychchronization interval. </= div> <div>I will revise the draft=A0to clarify above considerations.</div> <div>=A0</div> <div>BRs=A0</div> <div>=A0</div> <div>-Gang</div> <div>=A0</div> <div>=A0</div> <div>=A0</div> <div>=A0</div> <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0= px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"> <div> <div></div> <div class=3D"h5"><br><br>> Please kinldy to review it.<br>> Any comm= ent is welcome.<br>><br>> Thanks<br>><br>> -Gang<br>><br>>= ; A New Internet-Draft is available from the on-line Internet-Drafts<br> > directories.<br>><br>><br>> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 = =A0: A Optimal Load-balance mechanism for<br>> NAT64 (OL-NAT)<br>> = =A0 =A0 =A0 =A0Author(s) : G. Chen, H. Deng<br>> =A0 =A0 =A0 =A0Filename= : draft-chen-behave-olnat-00.txt<br> > =A0 =A0 =A0 =A0Pages =A0 =A0 : 12<br>> =A0 =A0 =A0 =A0Date =A0 =A0 = =A0 =A0: 2009-10-19<br>><br>> =A0 In NAT64 scenaires,sigle-point fail= ure is a critical issue to<br>> =A0 restrict large-scale deployment. =A0= In order to overcome this hurdle,<br> > =A0 this memo has proposed a optimal load-balance mechanism for NAT64.= <br>> =A0 Through the new-defined evaluation metrics, several extended I= CMP<br>> =A0 messages combining with anycast are performed to achieve op= timal<br> > =A0 NAT64 selection. =A0Meanwihle, the synchroniztion process of<br>&g= t; IP address<br>> =A0 mapping information is also designed to guarantee= the service<br>> =A0 continuity.<br>><br>> A URL for this Interne= t-Draft is:<br> > <a href=3D"http://www.ietf.org/internet-drafts/draft-chen-behave-olnat= -00.txt" target=3D"_blank">http://www.ietf.org/internet-drafts/draft-chen-b= ehave-olnat-00.txt</a><br>><br>> Internet-Drafts are also available b= y anonymous FTP at:<br> > <a href=3D"ftp://ftp.ietf.org/internet-drafts/" target=3D"_blank">ftp:= //ftp.ietf.org/internet-drafts/</a><br>><br>> Below is the data which= will enable a MIME compliant mail reader<br>> implementation to automat= ically retrieve the ASCII version of the<br> > Internet-Draft.<br>><br>><br><br></div></div></blockquote></div>= <br> --001636e90a212db97a04766c40ba-- From marcelo@it.uc3m.es Wed Oct 21 00:26:01 2009 Return-Path: <marcelo@it.uc3m.es> 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 2BF433A690F for <behave@core3.amsl.com>; Wed, 21 Oct 2009 00:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJWKtxtIDhcc for <behave@core3.amsl.com>; Wed, 21 Oct 2009 00:26:00 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id C2C9D3A68FA for <behave@ietf.org>; Wed, 21 Oct 2009 00:25:59 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp03.uc3m.es (Postfix) with ESMTP id 5EF2F72C26C; Wed, 21 Oct 2009 09:26:06 +0200 (CEST) Message-ID: <4ADEB78D.2060809@it.uc3m.es> Date: Wed, 21 Oct 2009 09:26:05 +0200 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Cameron Byrne <cb.list6@gmail.com> References: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com> In-Reply-To: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16960.003 Cc: behave@ietf.org Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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: Wed, 21 Oct 2009 07:26:01 -0000 Cameron Byrne escribió: > Folks, > > One of the major problems many operators have is scaling the CGN in a > reliable way. Scaling in the number of session per seconds as well as > raw concurrent sessions continues to be an issue, and will continue to > be an issue. Additionally, given that state and ALGs are being used, > boxes are known to reboot when protocols act in unexpected ways, so > fault isolation is another desire (array of independent boxes). > > Does the scenarios where i have boxes NAT64-A, NAT64-B, and NAT64-C > (all unique state boxes or high-available pairs of active/standby > boxes, with unique prefix64 A, B, and C respectively announced from > each) and the DNS64 load balances traffic (for example, round-robin > assignments of Prefix64-A, B, and C to resolving clients) destine to > each NAT64-A, B, C systems evenly. This way, the DNS64 drives 1/3 of > the requests to each of the 3 NAT64 systems. And, it scales linearly > in terms of NAT64 boxes. This assumes the DNS64 system scales higher > than the NAT64 systems, which i think is a good assumption. > this would be one way of doing it with the considerations expressed by Andrew. However, you could also play with the IGP, right? I mean, suppose you use the same Pref64/n for all the NAT64 boxes. Suppose now that the IPv6 representation of the IPv4 address X is created as Pref64:X:SUFFIX Now, you could configure the different NAT64 boxes propagating several more specific routes of Pref64/n, for instance propagating Pref64:abcd::/n+i (for different values of abcd) The result afaiu would be similar to the one you achieve today when you have multiple egress routers. I understand that ISPs and big sites alreayd do this, so this wouldn't change that operational practice. Would that make sense to you? > Additionally, the NAT64 and the DNS64 should be able to communicate in > such a way that the NAT64 can signal an overloading situation such > that the DNS64 drops the overloaded NAT64 out of the round-robin > prefix64 synthesis for some period of time. This could be implemented > as simple SNMP GET sampling of the sessions that NAT64 systems are > currently processing. > you could do that, but i am afraid that you could end up with significant stability problems depending on the parameters and the response time, the RTT and the lifetime of the flows. I mean this looks like a lot to routing based on congestion and we already had experienced stability issues with that. I am not saying this cannot be done, i am saying that stability is a concern and that defining this behavious is not only defining the snmp extensions, but some stability analysis is granted > Does this make sense to have this level of load-balancing between an > array of independent NAT64 boxes and feedback / back-pressure > communicated to the DNS64 system that is ultimately driving the load > to the NAT64 boxes? > > Does this fit within the existing drafts? Or is this implementation > minutia that does not require being covered here? At a minimum, i > think it would be nice to have the DNS64 draft examine how the DNS64 > system can drive load to multiple unique NAT64 systems. > > AFAIU, we already have the request to support multiple prefixes in the dns64 draft so i think this would fit in there, so nothing else would be needed for the load sharing using the igp, the main consideration is about the address format, which is still under discussion For the dynamic thing, as i said, i think a stability analysis is needed. Regards, marcelo > Thoughts? > > Regards, > > Cameron Byrne > > Cameron > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From marcelo@it.uc3m.es Wed Oct 21 00:39:46 2009 Return-Path: <marcelo@it.uc3m.es> 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 0C95A3A6960 for <behave@core3.amsl.com>; Wed, 21 Oct 2009 00:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwZuc5WxEqj7 for <behave@core3.amsl.com>; Wed, 21 Oct 2009 00:39:45 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 0ADCB3A68FA for <behave@ietf.org>; Wed, 21 Oct 2009 00:39:44 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp01.uc3m.es (Postfix) with ESMTP id 4D279BA5841; Wed, 21 Oct 2009 09:39:51 +0200 (CEST) Message-ID: <4ADEBAC7.4030202@it.uc3m.es> Date: Wed, 21 Oct 2009 09:39:51 +0200 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Iljitsch van Beijnum <iljitsch@muada.com> References: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com> <643AD0DC-5BD4-44BD-A206-D58A5F965F3A@muada.com> In-Reply-To: <643AD0DC-5BD4-44BD-A206-D58A5F965F3A@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16960.003 Cc: Cameron Byrne <cb.list6@gmail.com>, behave@ietf.org Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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: Wed, 21 Oct 2009 07:39:46 -0000 Iljitsch van Beijnum escribió: > On 20 okt 2009, at 08:01, Cameron Byrne wrote: > >> Additionally, the NAT64 and the DNS64 should be able to communicate in >> such a way that the NAT64 can signal an overloading situation such >> that the DNS64 drops the overloaded NAT64 out of the round-robin >> prefix64 synthesis for some period of time. > > I have one problem here in addition to Andrew's objections: > > If make a given host move to a different NAT64, that means that for > some time, there will be an inconsistency between the external IPv4 > addresses associated with different sessions. This makes protocols > like STUN fail, and as such, should be avoided. but you could solve that problem by making the pref64 used by the dns64 dependent on the source address of the query, right? I mean, in that way, you could make sure that all the DNS queries coming to the dns64 server from the same source IP address get the same Pref64 bt different sources get different Pref64 This would result in per source host load sharing and woudl address this particular issue i think Regards, marcelo > > You really don't want to run so close to your translator capacity that > systems like this become useful. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From iljitsch@muada.com Wed Oct 21 01:25:48 2009 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 150C33A6782 for <behave@core3.amsl.com>; Wed, 21 Oct 2009 01:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qbZS7eJL4l3 for <behave@core3.amsl.com>; Wed, 21 Oct 2009 01:25:47 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 31A423A657C for <behave@ietf.org>; Wed, 21 Oct 2009 01:25:47 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.216] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n9L8NiTn079289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Oct 2009 10:25:14 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <4ADEBAC7.4030202@it.uc3m.es> Date: Wed, 21 Oct 2009 10:23:40 +0200 Content-Transfer-Encoding: 7bit Message-Id: <775E5901-E88E-4465-97DF-2381705D8FBA@muada.com> References: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com> <643AD0DC-5BD4-44BD-A206-D58A5F965F3A@muada.com> <4ADEBAC7.4030202@it.uc3m.es> To: marcelo bagnulo braun <marcelo@it.uc3m.es> X-Mailer: Apple Mail (2.1076) Cc: Cameron Byrne <cb.list6@gmail.com>, behave@ietf.org Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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: Wed, 21 Oct 2009 08:25:48 -0000 On 21 okt 2009, at 09:39, marcelo bagnulo braun wrote: >> If make a given host move to a different NAT64, that means that for >> some time, there will be an inconsistency between the external IPv4 >> addresses associated with different sessions. This makes protocols >> like STUN fail, and as such, should be avoided. > but you could solve that problem by making the pref64 used by the > dns64 dependent on the source address of the query, right? Yes. But that still doesn't give you dynamic load balancing, or perhaps you only assign "new" sources to different NAT64s dynamically. (New = haven't been active for some hours or just (re)connected to the network.) From xuxh@huawei.com Wed Oct 21 03:07:22 2009 Return-Path: <xuxh@huawei.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 172893A697A for <behave@core3.amsl.com>; Wed, 21 Oct 2009 03:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.062 X-Spam-Level: *** X-Spam-Status: No, score=3.062 tagged_above=-999 required=5 tests=[AWL=-1.973, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] 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 p-PiX8Ms4CRS for <behave@core3.amsl.com>; Wed, 21 Oct 2009 03:07:21 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 3EA793A68C4 for <behave@ietf.org>; Wed, 21 Oct 2009 03:07:21 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRU002IMZZZ7W@szxga03-in.huawei.com> for behave@ietf.org; Wed, 21 Oct 2009 18:04:48 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRU00J7SZZZ40@szxga03-in.huawei.com> for behave@ietf.org; Wed, 21 Oct 2009 18:04:47 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRU004W8ZZYK0@szxml04-in.huawei.com> for behave@ietf.org; Wed, 21 Oct 2009 18:04:47 +0800 (CST) Date: Wed, 21 Oct 2009 18:04:46 +0800 From: Xu Xiaohu <xuxh@huawei.com> In-reply-to: <4ADEBAC7.4030202@it.uc3m.es> To: 'marcelo bagnulo braun' <marcelo@it.uc3m.es>, 'Iljitsch van Beijnum' <iljitsch@muada.com> Message-id: <005401ca5235$eb61a5f0$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcpSIgWcQdfldthVRHKbIofds9sZQAAE2F1w Cc: 'Cameron Byrne' <cb.list6@gmail.com>, behave@ietf.org Subject: [BEHAVE] =?gb2312?b?tPC4tDogIFVzaW5nIEROUzY0IHRvIGxvYWQgYmFsYW5j?= =?gb2312?b?ZSB0byBOQVQ2NA==?= 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: Wed, 21 Oct 2009 10:07:22 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] =B4=FA=B1=ED > marcelo bagnulo braun > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA10=D4=C221=C8=D5 15:40 > =CA=D5=BC=FE=C8=CB: Iljitsch van Beijnum > =B3=AD=CB=CD: Cameron Byrne; behave@ietf.org > =D6=F7=CC=E2: Re: [BEHAVE] Using DNS64 to load balance to NAT64 >=20 > Iljitsch van Beijnum escribi=A8=AE: > > On 20 okt 2009, at 08:01, Cameron Byrne wrote: > > > >> Additionally, the NAT64 and the DNS64 should be able to communicate = in > >> such a way that the NAT64 can signal an overloading situation such > >> that the DNS64 drops the overloaded NAT64 out of the round-robin > >> prefix64 synthesis for some period of time. > > > > I have one problem here in addition to Andrew's objections: > > > > If make a given host move to a different NAT64, that means that for > > some time, there will be an inconsistency between the external IPv4 > > addresses associated with different sessions. This makes protocols > > like STUN fail, and as such, should be avoided. > but you could solve that problem by making the pref64 used by the = dns64 > dependent on the source address of the query, right? If I understood it correctly, the external address for the internal host learnt from STUN is used by the external host to initiate communication session. So would it cause any problem when allocating prefix according = to destinations (i.e. A record contained in DNS reply)? Xiaohu > I mean, in that way, you could make sure that all the DNS queries = coming > to the dns64 server from the same source IP address get the same = Pref64 > bt different sources get different Pref64 >=20 > This would result in per source host load sharing and woudl address = this > particular issue i think >=20 > Regards, marcelo >=20 >=20 > > > > You really don't want to run so close to your translator capacity = that > > systems like this become useful. > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From mohamed.boucadair@orange-ftgroup.com Wed Oct 21 06:51:32 2009 Return-Path: <mohamed.boucadair@orange-ftgroup.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 DEC683A683A; Wed, 21 Oct 2009 06:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 SZ56F7nX0Ym0; Wed, 21 Oct 2009 06:51:29 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by core3.amsl.com (Postfix) with ESMTP id 0C3893A6809; Wed, 21 Oct 2009 06:51:29 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 09452C0224; Wed, 21 Oct 2009 15:51:37 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id DFE093841D1; Wed, 21 Oct 2009 15:51:36 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 21 Oct 2009 15:51:36 +0200 From: <mohamed.boucadair@orange-ftgroup.com> To: Acee Lindem <acee.lindem@ericsson.com>, "behave@ietf.org" <behave@ietf.org>, "ospf@ietf.org" <ospf@ietf.org> Date: Wed, 21 Oct 2009 15:51:35 +0200 Thread-Topic: Multi-Topology/Instance OSPFv3 for IPv4-mapped IPv6 Thread-Index: AcpRe1/fHlMnoBdFT9yZh3ykdeCzHwAmMCuwAA69t+AAAW3V4A== Message-ID: <9648_1256133096_4ADF11E8_9648_1113_1_94C682931C08B048B7A8645303FDC9F30781B15636@PUEXCB1B.nanterre.francetelecom.fr> References: <28623_1256105224_4ADEA508_28623_8299_1_94C682931C08B048B7A8645303FDC9F30781AA5276@PUEXCB1B.nanterre.francetelecom.fr> <D5F99F4CF1A1564DBFEE8B5DB5CB387AA6A5C01C09@EUSAACMS0702.eamcs.ericsson.se> In-Reply-To: <D5F99F4CF1A1564DBFEE8B5DB5CB387AA6A5C01C09@EUSAACMS0702.eamcs.ericsson.se> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR x-tm-as-product-ver: SMEX-8.0.0.1259-5.500.1027-16228.007 x-tm-as-result: No--32.351700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.10.14.151224 Subject: Re: [BEHAVE] Multi-Topology/Instance OSPFv3 for IPv4-mapped IPv6 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: Wed, 21 Oct 2009 13:51:33 -0000 Dear Acee, all, Actually, no. Two drafts have been submitted: one for multi-topology and an= other one for multi-instance. We don't want to make any choice about the us= e of MT or MI. It is up to the SP's taste. Sorry for the confusion. Cheers, Med=20 -----Message d'origine----- De : Acee Lindem [mailto:acee.lindem@ericsson.com]=20 Envoy=E9 : mercredi 21 octobre 2009 15:07 =C0 : BOUCADAIR Mohamed NCPI/NAD/TIP; behave@ietf.org; ospf@ietf.org Objet : RE: Multi-Topology/Instance OSPFv3 for IPv4-mapped IPv6 Hi Mohamed, I take it then that draft-boucadair-ospf-v4v6-ospfv3-mi-01.txt was a misnam= ed version of draft-boucadair-ospf-v4v6-ospfv3-mt-01.txt and should be igno= red. Correct?=20 Thanks, Acee=20 |-----Original Message----- |From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of=20 |mohamed.boucadair@orange-ftgroup.com |Sent: Wednesday, October 21, 2009 2:07 AM |To: behave@ietf.org; ospf@ietf.org |Subject: [OSPF] Multi-Topology/Instance OSPFv3 for IPv4-mapped IPv6 | |=20 |Dear all, | |FYI. We submitted the following draft. | |Comments are more than welcome. | |Cheers, |Med | |-----Message d'origine----- |De : i-d-announce-bounces@ietf.org |[mailto:i-d-announce-bounces@ietf.org] De la part de=20 |Internet-Drafts@ietf.org Envoy=E9 : mardi 20 octobre 2009 13:45 =C0 :=20 |i-d-announce@ietf.org Objet : I-D=20 |Action:draft-boucadair-ospf-v4v6-ospfv3-mt-01.txt | |A New Internet-Draft is available from the on-line Internet-Drafts=20 |directories. | | Title : Multi-Topology OSPFv3 for IPv4-mapped IPv6 | Author(s) : M. Boucadair, et al. | Filename : draft-boucadair-ospf-v4v6-ospfv3-mt-01.txt | Pages : 7 | Date : 2009-10-20 | |This memo defines two new Multi Topology Routing Identifiers (MT IDs)=20 |in OSPFv3 [RFC2740]). These new MT-OSPFv3 [I-D.ietf-ospf-mt-ospfv3]=20 |topologies are meant to convey routing information which is restricted=20 |to IPv4-mapped IPv6 addresses [I-D.ietf-behave-address-format]. The=20 |goal of running separate instances for IPv4-mapped IPv6 routes is to=20 |isolate the IPv6 routing table from the IPv4 routing table, and to=20 |avoid any overload due to the population of the table by IPv4-inferred=20 |routes. This isolation is motivated also from an operational=20 |perspective to enforce specific routing policies for each topology. | |A URL for this Internet-Draft is: |http://www.ietf.org/internet-drafts/draft-boucadair-ospf-v4v6-o |spfv3-mt-01.txt | |The URL for the multi-instance draft is: |http://www.ietf.org/internet-drafts/draft-boucadair-ospf-v4v6-o |spfv3-mi-01.txt | |********************************* |This message and any attachments (the "message") are confidential and=20 |intended solely for the addressees. |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,=20 |changed or falsified. |If you are not the intended addressee of this message, please cancel it=20 |immediately and inform the sender. |******************************** | | ********************************* 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 cb.list6@gmail.com Wed Oct 21 07:22:21 2009 Return-Path: <cb.list6@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 A8A483A6955 for <behave@core3.amsl.com>; Wed, 21 Oct 2009 07:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 3vgpVSNDMIVL for <behave@core3.amsl.com>; Wed, 21 Oct 2009 07:22:20 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id C5C4C3A679C for <behave@ietf.org>; Wed, 21 Oct 2009 07:22:20 -0700 (PDT) Received: by pzk42 with SMTP id 42so5637169pzk.31 for <behave@ietf.org>; Wed, 21 Oct 2009 07:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wmBGUh092QWYtSNiW5gicajyzPD8HQ+Iw0j3hdrp3KU=; b=KDbhOb5ywK4VGaydh0OgvIgsOJGk4TuSlFZn2Zh1RTwhCsNEAfziIKGKXmmEGzbQEP eJr/AXgi4nPWB/EKuYO4irgQhV/IhRYq0RUEyswK3W7R0+MYUq8HH0cHem9ukIzgMhCY nK3w4LApVXDkt91JAtFXWJals2udZp462FGS0= 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=ISycniiMdwN4wRHEVNSQEu3pzRmp27hm30NInYyXGR6bjV4skb0JvJlNz862JfSEZJ uDx/YSQDGr1JavGLRgV548eYECnA0/3589aWs5C6Gk0ZdzY0zs9romApKnTZaG76wBNO 0vjgKni60fVBtFtON6DkJntXY24zDG9Oyofsw= MIME-Version: 1.0 Received: by 10.142.75.6 with SMTP id x6mr586254wfa.198.1256134946344; Wed, 21 Oct 2009 07:22:26 -0700 (PDT) In-Reply-To: <4ADEBAC7.4030202@it.uc3m.es> References: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com> <643AD0DC-5BD4-44BD-A206-D58A5F965F3A@muada.com> <4ADEBAC7.4030202@it.uc3m.es> Date: Wed, 21 Oct 2009 07:22:26 -0700 Message-ID: <bcff0fba0910210722n4bcec955o1610b0e807a3596c@mail.gmail.com> From: Cameron Byrne <cb.list6@gmail.com> To: marcelo bagnulo braun <marcelo@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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: Wed, 21 Oct 2009 14:22:21 -0000 On Wed, Oct 21, 2009 at 12:39 AM, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote: > Iljitsch van Beijnum escribi=F3: >> >> On 20 okt 2009, at 08:01, Cameron Byrne wrote: >> >>> Additionally, the NAT64 and the DNS64 should be able to communicate in >>> such a way that the NAT64 can signal an overloading situation such >>> that the DNS64 drops the overloaded NAT64 out of the round-robin >>> prefix64 synthesis for some period of time. >> >> I have one problem here in addition to Andrew's objections: >> >> If make a given host move to a different NAT64, that means that for some >> time, there will be an inconsistency between the external IPv4 addresses >> associated with different sessions. This makes protocols like STUN fail,= and >> as such, should be avoided. > > but you could solve that problem by making the pref64 used by the dns64 > dependent on the source address of the query, right? This, in part, is exactly what i am looking for. This level of load sharing would help me a great deal in delivering a solutions that scales linearly. I can keep adding pref64 to the one DNS64 and keep adding NAT64 boxes as demand arises. > > I mean, in that way, you could make sure that all the DNS queries coming = to > the dns64 server from the same source IP address get the same Pref64 bt > different sources get different Pref64 Excellent. One other thing. I am not interested in including IGP in any of this PREF64. I do not want temporary topology changes (link down) to swing around NAT64 traffic when it is not needed. I want a DNS64 to hand out a a specific and consistent PREF64 all the time. Perhaps a sourced based hash that results in buckets 1, 2, 3 ... and each bucket is a PREF64-1, -2, 3. Also, keep in mind, the DNS64 will likely be deployed as an anycast in many geographic locations ... so it will be subject to IGP changes... but, i dont want the PREF64 to be dependent on IGP beyond the anycast DNS64. For me, PREF64 should be statically tied to a single NAT64 entity (which will be 1+1 boxes). It's possible i did not understand what was meant by Marcelo wrt to IGP. > > This would result in per source host load sharing and woudl address this > particular issue i think YES! :) > > Regards, marcelo > > >> >> You really don't want to run so close to your translator capacity that >> systems like this become useful. >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > > From acee.lindem@ericsson.com Wed Oct 21 06:06:50 2009 Return-Path: <acee.lindem@ericsson.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 EA49D3A67F1; Wed, 21 Oct 2009 06:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9E9pl451ynM; Wed, 21 Oct 2009 06:06:50 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id D73EE28C0D7; Wed, 21 Oct 2009 06:06:46 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n9LD6oTj018766; Wed, 21 Oct 2009 08:06:52 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 08:06:43 -0500 Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 08:06:43 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.118]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 21 Oct 2009 09:06:42 -0400 From: Acee Lindem <acee.lindem@ericsson.com> To: "mohamed.boucadair@orange-ftgroup.com" <mohamed.boucadair@orange-ftgroup.com>, "behave@ietf.org" <behave@ietf.org>, "ospf@ietf.org" <ospf@ietf.org> Date: Wed, 21 Oct 2009 09:06:41 -0400 Thread-Topic: Multi-Topology/Instance OSPFv3 for IPv4-mapped IPv6 Thread-Index: AcpRe1/fHlMnoBdFT9yZh3ykdeCzHwAmMCuwAA69t+A= Message-ID: <D5F99F4CF1A1564DBFEE8B5DB5CB387AA6A5C01C09@EUSAACMS0702.eamcs.ericsson.se> References: <28623_1256105224_4ADEA508_28623_8299_1_94C682931C08B048B7A8645303FDC9F30781AA5276@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <28623_1256105224_4ADEA508_28623_8299_1_94C682931C08B048B7A8645303FDC9F30781AA5276@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Oct 2009 13:06:43.0002 (UTC) FILETIME=[55DE81A0:01CA524F] X-Mailman-Approved-At: Wed, 21 Oct 2009 08:46:38 -0700 Subject: Re: [BEHAVE] Multi-Topology/Instance OSPFv3 for IPv4-mapped IPv6 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: Wed, 21 Oct 2009 13:06:51 -0000 Hi Mohamed, I take it then that draft-boucadair-ospf-v4v6-ospfv3-mi-01.txt was a misnam= ed version of draft-boucadair-ospf-v4v6-ospfv3-mt-01.txt and should be igno= red. Correct?=20 Thanks, Acee=20 |-----Original Message----- |From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On=20 |Behalf Of mohamed.boucadair@orange-ftgroup.com |Sent: Wednesday, October 21, 2009 2:07 AM |To: behave@ietf.org; ospf@ietf.org |Subject: [OSPF] Multi-Topology/Instance OSPFv3 for IPv4-mapped IPv6 | |=20 |Dear all, | |FYI. We submitted the following draft. | |Comments are more than welcome. | |Cheers, |Med | |-----Message d'origine----- |De : i-d-announce-bounces@ietf.org=20 |[mailto:i-d-announce-bounces@ietf.org] De la part de=20 |Internet-Drafts@ietf.org Envoy=E9 : mardi 20 octobre 2009 13:45=20 |=C0 : i-d-announce@ietf.org Objet : I-D=20 |Action:draft-boucadair-ospf-v4v6-ospfv3-mt-01.txt=20 | |A New Internet-Draft is available from the on-line=20 |Internet-Drafts directories. | | Title : Multi-Topology OSPFv3 for IPv4-mapped IPv6 | Author(s) : M. Boucadair, et al. | Filename : draft-boucadair-ospf-v4v6-ospfv3-mt-01.txt | Pages : 7 | Date : 2009-10-20 | |This memo defines two new Multi Topology Routing Identifiers=20 |(MT IDs) in OSPFv3 [RFC2740]). These new MT-OSPFv3=20 |[I-D.ietf-ospf-mt-ospfv3] topologies are meant to convey=20 |routing information which is restricted to IPv4-mapped IPv6=20 |addresses [I-D.ietf-behave-address-format]. The goal of=20 |running separate instances for IPv4-mapped IPv6 routes is to=20 |isolate the IPv6 routing table from the IPv4 routing table,=20 |and to avoid any overload due to the population of the table=20 |by IPv4-inferred routes. This isolation is motivated also=20 |from an operational perspective to enforce specific routing=20 |policies for each topology. | |A URL for this Internet-Draft is: |http://www.ietf.org/internet-drafts/draft-boucadair-ospf-v4v6-o |spfv3-mt-01.txt | |The URL for the multi-instance draft is: |http://www.ietf.org/internet-drafts/draft-boucadair-ospf-v4v6-o |spfv3-mi-01.txt | |********************************* |This message and any attachments (the "message") are=20 |confidential and intended 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=20 |altered, changed or falsified. |If you are not the intended addressee of this message, please=20 |cancel it immediately and inform the sender. |******************************** | |= From acee.lindem@ericsson.com Wed Oct 21 08:26:28 2009 Return-Path: <acee.lindem@ericsson.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 59BB53A6948; Wed, 21 Oct 2009 08:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doBeKJEUOUhP; Wed, 21 Oct 2009 08:26:27 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 5CE603A680D; Wed, 21 Oct 2009 08:26:27 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n9LFQYhV014266; Wed, 21 Oct 2009 10:26:35 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 10:25:48 -0500 Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 10:25:48 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.118]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 21 Oct 2009 11:25:47 -0400 From: Acee Lindem <acee.lindem@ericsson.com> To: "mohamed.boucadair@orange-ftgroup.com" <mohamed.boucadair@orange-ftgroup.com>, "behave@ietf.org" <behave@ietf.org>, "ospf@ietf.org" <ospf@ietf.org> Date: Wed, 21 Oct 2009 11:25:46 -0400 Thread-Topic: Multi-Topology/Instance OSPFv3 for IPv4-mapped IPv6 Thread-Index: AcpRe1/fHlMnoBdFT9yZh3ykdeCzHwAmMCuwAA69t+AAAW3V4AADcf5w Message-ID: <D5F99F4CF1A1564DBFEE8B5DB5CB387AA6A5C01D40@EUSAACMS0702.eamcs.ericsson.se> References: <28623_1256105224_4ADEA508_28623_8299_1_94C682931C08B048B7A8645303FDC9F30781AA5276@PUEXCB1B.nanterre.francetelecom.fr> <D5F99F4CF1A1564DBFEE8B5DB5CB387AA6A5C01C09@EUSAACMS0702.eamcs.ericsson.se> <9648_1256133096_4ADF11E8_9648_1113_1_94C682931C08B048B7A8645303FDC9F30781B15636@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <9648_1256133096_4ADF11E8_9648_1113_1_94C682931C08B048B7A8645303FDC9F30781B15636@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Oct 2009 15:25:48.0773 (UTC) FILETIME=[C4561950:01CA5262] X-Mailman-Approved-At: Wed, 21 Oct 2009 08:46:38 -0700 Subject: Re: [BEHAVE] Multi-Topology/Instance OSPFv3 for IPv4-mapped IPv6 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: Wed, 21 Oct 2009 15:26:28 -0000 Hi Mohamed, Perhaps a single draft would have sufficed.=20 Thanks, Acee=20 |-----Original Message----- |From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On=20 |Behalf Of mohamed.boucadair@orange-ftgroup.com |Sent: Wednesday, October 21, 2009 9:52 AM |To: Acee Lindem; behave@ietf.org; ospf@ietf.org |Subject: Re: [OSPF] Multi-Topology/Instance OSPFv3 for IPv4-mapped IPv6 | | |Dear Acee, all, | |Actually, no. Two drafts have been submitted: one for=20 |multi-topology and another one for multi-instance. We don't=20 |want to make any choice about the use of MT or MI. It is up to=20 |the SP's taste. | |Sorry for the confusion. | |Cheers, |Med=20 | | |-----Message d'origine----- |De : Acee Lindem [mailto:acee.lindem@ericsson.com] Envoy=E9 :=20 |mercredi 21 octobre 2009 15:07 =C0 : BOUCADAIR Mohamed=20 |NCPI/NAD/TIP; behave@ietf.org; ospf@ietf.org Objet : RE:=20 |Multi-Topology/Instance OSPFv3 for IPv4-mapped IPv6 | |Hi Mohamed, |I take it then that draft-boucadair-ospf-v4v6-ospfv3-mi-01.txt=20 |was a misnamed version of=20 |draft-boucadair-ospf-v4v6-ospfv3-mt-01.txt and should be=20 |ignored. Correct?=20 |Thanks, |Acee=20 ||-----Original Message----- ||From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On=20 |Behalf Of=20 ||mohamed.boucadair@orange-ftgroup.com ||Sent: Wednesday, October 21, 2009 2:07 AM ||To: behave@ietf.org; ospf@ietf.org ||Subject: [OSPF] Multi-Topology/Instance OSPFv3 for IPv4-mapped IPv6 || ||=20 ||Dear all, || ||FYI. We submitted the following draft. || ||Comments are more than welcome. || ||Cheers, ||Med || ||-----Message d'origine----- ||De : i-d-announce-bounces@ietf.org ||[mailto:i-d-announce-bounces@ietf.org] De la part de=20 ||Internet-Drafts@ietf.org Envoy=E9 : mardi 20 octobre 2009 13:45 =C0 : ||i-d-announce@ietf.org Objet : I-D ||Action:draft-boucadair-ospf-v4v6-ospfv3-mt-01.txt || ||A New Internet-Draft is available from the on-line Internet-Drafts=20 ||directories. || || Title : Multi-Topology OSPFv3 for IPv4-mapped IPv6 || Author(s) : M. Boucadair, et al. || Filename : draft-boucadair-ospf-v4v6-ospfv3-mt-01.txt || Pages : 7 || Date : 2009-10-20 || ||This memo defines two new Multi Topology Routing Identifiers (MT IDs)=20 ||in OSPFv3 [RFC2740]). These new MT-OSPFv3 [I-D.ietf-ospf-mt-ospfv3]=20 ||topologies are meant to convey routing information which is=20 |restricted=20 ||to IPv4-mapped IPv6 addresses [I-D.ietf-behave-address-format]. The=20 ||goal of running separate instances for IPv4-mapped IPv6 routes is to=20 ||isolate the IPv6 routing table from the IPv4 routing table, and to=20 ||avoid any overload due to the population of the table by=20 |IPv4-inferred=20 ||routes. This isolation is motivated also from an operational=20 ||perspective to enforce specific routing policies for each topology. || ||A URL for this Internet-Draft is: ||http://www.ietf.org/internet-drafts/draft-boucadair-ospf-v4v6-o ||spfv3-mt-01.txt || ||The URL for the multi-instance draft is: ||http://www.ietf.org/internet-drafts/draft-boucadair-ospf-v4v6-o ||spfv3-mi-01.txt || ||********************************* ||This message and any attachments (the "message") are confidential and=20 ||intended solely for the addressees. ||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,=20 ||changed or falsified. ||If you are not the intended addressee of this message, please=20 |cancel it=20 ||immediately and inform the sender. ||******************************** || || |********************************* |This message and any attachments (the "message") are=20 |confidential and intended 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=20 |altered, changed or falsified. |If you are not the intended addressee of this message, please=20 |cancel it immediately and inform the sender. |******************************** | |_______________________________________________ |OSPF mailing list |OSPF@ietf.org |https://www.ietf.org/mailman/listinfo/ospf |= From huitema@microsoft.com Wed Oct 21 09:39:28 2009 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 416C73A69BC for <behave@core3.amsl.com>; Wed, 21 Oct 2009 09:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOGaTlB7AdOF for <behave@core3.amsl.com>; Wed, 21 Oct 2009 09:39:27 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 65C3C3A6990 for <behave@ietf.org>; Wed, 21 Oct 2009 09:39:24 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 21 Oct 2009 09:39:43 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server id 14.0.639.20; Wed, 21 Oct 2009 09:39:32 -0700 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 21 Oct 2009 09:39:32 -0700 From: Christian Huitema <huitema@microsoft.com> To: "teemu.savolainen@nokia.com" <teemu.savolainen@nokia.com>, "ajs@shinkuro.com" <ajs@shinkuro.com>, "behave@ietf.org" <behave@ietf.org> Thread-Topic: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt Thread-Index: AQHKUOZcB4qVxczK40+zVvgdVO4zY5ENo/MAgAFHKICAAUzkUA== Date: Wed, 21 Oct 2009 16:39:31 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA211C9BC9@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <20091019180002.1AFBE3A692D@core3.amsl.com> <20091019181555.GC9536@shinkuro.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3EF10EF424@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F3EF10EF424@NOK-EUMSG-01.mgdnok.nokia.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] I-D Action:draft-ietf-behave-dns64-01.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: Wed, 21 Oct 2009 16:39:28 -0000 > The draft contains question about multihoming:"In particular, how is the > multi-homed host supposed to know that a given AAAA is synthetic?". Wonder about that too. Isn't the best solution to create a new record type,= say A4A6, that would contain the mapped addresses of IPv4 only hosts? -- Christian Huitema From dwing@cisco.com Wed Oct 21 09:40:21 2009 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 B49A528C105 for <behave@core3.amsl.com>; Wed, 21 Oct 2009 09:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.887 X-Spam-Level: X-Spam-Status: No, score=-5.887 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4, URIBL_RED=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 PA-ztiVclJBh for <behave@core3.amsl.com>; Wed, 21 Oct 2009 09:40:20 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 7231A3A6842 for <behave@ietf.org>; Wed, 21 Oct 2009 09:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=7071; q=dns/txt; s=sjiport01001; t=1256143229; x=1257352829; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Dan=20Wing"=20<dwing@cisco.com>|Subject:=20AAAA =20records=20on=20the=20Internet=20(::ffff:=20(IPv4-mappe d),=20loopback)|Date:=20Wed,=2021=20Oct=202009=2009:40:24 =20-0700|Message-ID:=20<005c01ca526d$31533510$c5f0200a@ci sco.com>|To:=20"'Behave=20WG'"=20<behave@ietf.org>,=20"An drew=20Sullivan"=20<ajs@shinkuro.com>,=0D=0A=20=20=20=20 =20=20=20=20"'marcelo=20bagnulo=20braun'"=20<marcelo@it.u c3m.es>|MIME-Version:=201.0|Content-Transfer-Encoding:=20 7bit; bh=aL/lhxPyS+dHGE2Ze6mHs1a/Y0oxR0F0Tjm/5GzGVYY=; b=lJefJ/FVlct0kbxgip597/85Wp1I11qCGHukVqRfySjDqO0bFbjBuKo4 dVQlsE57UqpbMCxYQHMxhjw61RF3bDOlnKjd20hDv3+slR9MiIkOjMLCS cE6Rct6Jw95U0fcJ/IL/X0z/OxdnRbKoI55xW0XRViiNyga4rkjLa7+eS c=; 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: Aj+MAHvW3kqrR7Hu/2dsb2JhbACDAodei3KtIYkMAY9MhDEEgVyIQQ X-IronPort-AV: E=Sophos;i="4.44,598,1249257600"; d="scan'208";a="259338047" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 21 Oct 2009 16:40:26 +0000 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9LGePm7003262; Wed, 21 Oct 2009 16:40:25 GMT From: "Dan Wing" <dwing@cisco.com> To: "'Behave WG'" <behave@ietf.org>, "Andrew Sullivan" <ajs@shinkuro.com>, "'marcelo bagnulo braun'" <marcelo@it.uc3m.es> Date: Wed, 21 Oct 2009 09:40:24 -0700 Message-ID: <005c01ca526d$31533510$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcpSbS/RpufhBuF4Qx2L/B9l8eaE8g== Subject: [BEHAVE] AAAA records on the Internet (::ffff: (IPv4-mapped), loopback) 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: Wed, 21 Oct 2009 16:40:22 -0000 During today's interim meeting I shared a summary of AAAA records on the Internet with IPv4-mapped addresses (::ffff:). My test uses Alexa's list of top-1,000,000 websites (see top right of http://www.alexa.com/topsites). I examine the top 25,000 sites and eliminate duplicates and IPv4 address literals resulting in 24959 hosts checked. This is run on a system with native IPv4 and native IPv6 connectivity and its own BIND nameserver. I ran the test again after the interim meeting to have fresh data which shows of the 99 AAAA records advertised for the top 24,959 sites, 20 of them (approximately 20%) are using IPv4-mapped addresses. total hostnames checked: 24959 count with A: 24771 (99.247%) count without A: 188 ( 0.753%) count without AAAA: 24860 (99.603%) count with AAAA: 99 ( 0.397%) count of AAAA, without IPv4-mapped: 77 (77.778%) count of AAAA, with IPv4-mapped: 20 (20.202%) count of AAAA, with loopback: 2 ( 2.020%) Testing connectivity to TCP/80 for IPv6 records of non-IPv4-mapped hosts: hosts tested: 77 IPv6 connection ok: 67 (87.013%) IPv6 connection failed: 10 (12.987%) Another address that DNS64 operators may want to treat similar to IPv4-mapped (::ffff:) and ignore is the IPv6 loopback address (::1). As shown in the summary above, there are 2 occurrences in the 99 AAAA records, accounting for 2% of what would be failures for DNS64/NAT64 (or very confused users, if the user is running an IPv6 webserver on their own host): # grep " ::1 " weekly.out-2009-10-21 top100.cn has IPv4 has IPv6 ::1 (ok) akilli.tv has IPv4 has IPv6 ::1 (ok) # host top100.cn top100.cn has address 59.151.24.134 top100.cn has IPv6 address ::1 top100.cn mail is handled by 10 mx.sina.net. # host akilli.tv akilli.tv has address 212.146.130.4 akilli.tv has IPv6 address ::1 akilli.tv mail is handled by 10 mail.akilli.tv. (my result shows "(ok)" instead of "(failed)" for those hosts because there is an IPv6 webserver running on the same host running the test.) Many people are surprised with the high number of "count without A", which was 188 on this run. I agree this is odd considering those very same FQDNs were compiled by Alexa as being top sites the previous day. I copied my raw data to ftp://ftpeng.cisco.com/dwing/behave/weekly.out-2009-10-21 so that everyone can do their own tests against it. Almost all of the failures can be verified to be legitimate failures by running: #grep "no IPv4" weekly.out-2009-10-21 | cut -d " " -f 1 | xargs -n 1 host Host www.bp.blogspot.com not found: 3(NXDOMAIN) Host www.rmxads.com not found: 3(NXDOMAIN) Host www.ggpht.com not found: 3(NXDOMAIN) Host www.webry.info not found: 3(NXDOMAIN) Host www.866-86.cn not found: 3(NXDOMAIN) Host www.images-amazon.com not found: 3(NXDOMAIN) Host www.ytimg.com not found: 3(NXDOMAIN) Host www.1e100.net not found: 3(NXDOMAIN) Host www.livefilestore.com not found: 3(NXDOMAIN) Host www.myspacecdn.com not found: 3(NXDOMAIN) Host www.tokyo.jp not found: 3(NXDOMAIN) Host www.edgesuite.net not found: 3(NXDOMAIN) Host www.uimserv.net not found: 3(NXDOMAIN) Host www.pgmediaserve.com not found: 3(NXDOMAIN) Host www.k12.ca.us not found: 3(NXDOMAIN) Host www.ucom.ne.jp not found: 3(NXDOMAIN) Host www.xii.jp not found: 3(NXDOMAIN) Host www.yahoofs.jp not found: 3(NXDOMAIN) Host www.wateen.net not found: 3(NXDOMAIN) Host www.ebayrtm.com not found: 3(NXDOMAIN) www.fastwebnet.it mail is handled by 10 mx3.fastwebnet.it. www.fastwebnet.it mail is handled by 10 mx4.fastwebnet.it. www.fastwebnet.it mail is handled by 10 mx1.fastwebnet.it. www.fastwebnet.it mail is handled by 10 mx2.fastwebnet.it. Host www.rj.gov.br not found: 3(NXDOMAIN) ... and so on ... I find the results similar on three different hosts, all using different nameservers. Thus, I have attributed this anomaly to DNS hiccups. Finally, the last part of the report shows the success/failure of connections to the IPv6 address. This is a simple connect() call; I do not try to download a web page. If we exclude the IPv4-mapped addresses (which don't interest us, because DNS64 will essentially ignore them), there are still some failures: # grep failed weekly.out | grep -v "::ffff" www.fudan.edu.cn has IPv4 has IPv6 2001:da8:8001:2:21e:c9ff:feb5:eace (failed) exchangecash.de has IPv4 has IPv6 ::1bcc:2f02:0:0:21cc:2f02 (failed) www.bayimg.com has IPv4 has IPv6 2a01:298:3:1:1337::13 (failed) sify.com has IPv4 has IPv6 2001:e48:0:10::10 (failed) tribune.com has IPv4 has IPv6 2002:a3c0:1712::a3c0:1712 (failed) die.net has IPv4 has IPv6 2607:f820:42::4 (failed) pcc.edu has IPv4 has IPv6 192:192:168:168:1:1:1:1 (failed) cbn.net.id has IPv4 has IPv6 2001:d10:2:80::80 (failed) www.bt-chat.com has IPv4 has IPv6 2001:5c0:1500:b300::1:1 (failed) www.proua.com has IPv4 has IPv6 2a01:d0::10:1 (failed) but all of those work fine with IPv4, as can be tested with: # grep failed weekly.out-2009-10-21 | grep -v "::ffff" | cut -d " " -f 1 | xargs -n 1 wget --spider -4 Spider mode enabled. Check if remote file exists. --2009-10-21 09:33:32-- http://www.fudan.edu.cn/ Resolving www.fudan.edu.cn... 61.129.42.5 Connecting to www.fudan.edu.cn|61.129.42.5|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Remote file exists and could contain further links, but recursion is disabled -- not retrieving. Spider mode enabled. Check if remote file exists. --2009-10-21 09:33:33-- http://exchangecash.de/ Resolving exchangecash.de... 91.121.20.228 Connecting to exchangecash.de|91.121.20.228|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://exchangecash.de/infoseite/index.html [following] Spider mode enabled. Check if remote file exists. --2009-10-21 09:33:33-- http://exchangecash.de/infoseite/index.html Connecting to exchangecash.de|91.121.20.228|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 3202 (3.1K) [text/html] Remote file exists and could contain further links, but recursion is disabled -- not retrieving. ... and so on ... All of them worked fine for IPv4. I expect this information provides sufficient justification for keeping text in the DNS64 document encouraging implementors to allow the DNS64 operator to treat certain AAAA responses as bogus. -d From ajs@shinkuro.com Wed Oct 21 10:05:29 2009 Return-Path: <ajs@shinkuro.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 E85943A67E3 for <behave@core3.amsl.com>; Wed, 21 Oct 2009 10:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=0.719, 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 kzZLy7AR2STB for <behave@core3.amsl.com>; Wed, 21 Oct 2009 10:05:29 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 0FA003A68DE for <behave@ietf.org>; Wed, 21 Oct 2009 10:05:29 -0700 (PDT) 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 323B42FE8CDC for <behave@ietf.org>; Wed, 21 Oct 2009 17:05:37 +0000 (UTC) Date: Wed, 21 Oct 2009 13:05:35 -0400 From: Andrew Sullivan <ajs@shinkuro.com> To: behave@ietf.org Message-ID: <20091021170535.GI41456@shinkuro.com> References: <20091019180002.1AFBE3A692D@core3.amsl.com> <20091019181555.GC9536@shinkuro.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3EF10EF424@NOK-EUMSG-01.mgdnok.nokia.com> <6B55F0F93C3E9D45AF283313B8D342BA211C9BC9@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA211C9BC9@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.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: Wed, 21 Oct 2009 17:05:30 -0000 On Wed, Oct 21, 2009 at 04:39:31PM +0000, Christian Huitema wrote: > > The draft contains question about multihoming:"In particular, how is the > > multi-homed host supposed to know that a given AAAA is synthetic?". > > Wonder about that too. Isn't the best solution to create a new > record type, say A4A6, that would contain the mapped addresses of > IPv4 only hosts? As I've been saying to someone else off-list about proposals like that, the point of this whole DNS64 exercise is that we don't want to have to rely on everyone in the world being upgraded in order to provide a semblance of service continuity. Anything that begins with "let's add a DNS RRTYPE" isn't going to fly not because it's hard to add DNSRRs (it'd be very easy for this case), but because getting all the systems upgraded in order to achieve the goal is not possible. If we could do that, we could just get everyone onto IPv6, I think. No? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dthaler@microsoft.com Wed Oct 21 17:39:28 2009 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 B1D343A6806 for <behave@core3.amsl.com>; Wed, 21 Oct 2009 17:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYCVQmVBZW4x for <behave@core3.amsl.com>; Wed, 21 Oct 2009 17:39:28 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 024983A63D3 for <behave@ietf.org>; Wed, 21 Oct 2009 17:39:27 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 21 Oct 2009 17:39:47 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server id 14.0.639.20; Wed, 21 Oct 2009 17:39:36 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 21 Oct 2009 17:39:38 -0700 From: Dave Thaler <dthaler@microsoft.com> To: Behave WG <behave@ietf.org> Thread-Topic: Address format terminology Thread-Index: AcpSsCDX36XO1uK9Q5+qCzE+bl6tZw== Date: Thu, 22 Oct 2009 00:39:35 +0000 Message-ID: <E4561B14EE2A3E4E9D478EBFB5416E1B29B0F19A@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.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: [BEHAVE] Address format terminology 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, 22 Oct 2009 00:39:28 -0000 During today's interim meeting, those present agreed to use=20 "IPv4-embedded" in place of "IPv4-mapped", to avoid confusion=20 with the specific range ::ffff:a.b.c.d/96, unless/until a better=20 terms is found. One problem with "IPv4-embedded" is that=20 there are techniques that do not actually embed an IPv4=20 address literally, but obscure it in some way. Another problem is that "IPv4-translatable" addresses also "embed" an IPv4=20 address. Hence I (and Dan) feel the term "IPv4-embedded" is=20 too general to be appropriate. I think regardless of the root word, we want to retain the=20 suffix "-ed" to mean the mapping of a regular IPv4 address assigned to some host has already been performed (past tense), to get an=20 IPv6 address. And the suffix "-able" means that the IPv6 address=20 has not yet had any mapping done to it (future tense), but is=20 directly assigned to an IPv6 host. So I went to my thesaurus after the call to look for synonyms of translate and map, and found two that might be possible. The two possibilities for consideration are: a) IPv4-converted b) IPv4-transformed -Dave From xing@cernet.edu.cn Thu Oct 22 00:58:06 2009 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 6F4543A6918 for <behave@core3.amsl.com>; Thu, 22 Oct 2009 00:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.933 X-Spam-Level: X-Spam-Status: No, score=0.933 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N--CPbar7PVH for <behave@core3.amsl.com>; Thu, 22 Oct 2009 00:58:05 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 7E1ED3A6940 for <behave@ietf.org>; Thu, 22 Oct 2009 00:58:02 -0700 (PDT) Received: from [59.66.24.140]([59.66.24.140]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jmb4ae03f4e; Thu, 22 Oct 2009 15:58:08 +0800 Message-ID: <4AE01091.3020202@cernet.edu.cn> Date: Thu, 22 Oct 2009 15:58:09 +0800 From: Xing Li <xing@cernet.edu.cn> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dave Thaler <dthaler@microsoft.com> References: <E4561B14EE2A3E4E9D478EBFB5416E1B29B0F19A@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <E4561B14EE2A3E4E9D478EBFB5416E1B29B0F19A@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: Afi8sAXB Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Address format terminology 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, 22 Oct 2009 07:58:06 -0000 Dave Thaler 写é“: > So I went to my thesaurus after the call to look for synonyms of > translate and map, and found two that might be possible. The > two possibilities for consideration are: > > a) IPv4-converted I perfer this one. xing > > b) IPv4-transformed > > -Dave > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > From xing@cernet.edu.cn Thu Oct 22 01:47:58 2009 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 992893A677C for <behave@core3.amsl.com>; Thu, 22 Oct 2009 01:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.094 X-Spam-Level: ** X-Spam-Status: No, score=2.094 tagged_above=-999 required=5 tests=[AWL=-0.603, BAYES_50=0.001, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bocLVf+6LaJm for <behave@core3.amsl.com>; Thu, 22 Oct 2009 01:47:57 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id A8A823A63EC for <behave@ietf.org>; Thu, 22 Oct 2009 01:47:56 -0700 (PDT) Received: from [59.66.24.140]([59.66.24.140]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54ae04b01; Thu, 22 Oct 2009 16:48:03 +0800 Message-ID: <4AE01C41.4000006@cernet.edu.cn> Date: Thu, 22 Oct 2009 16:48:01 +0800 From: Xing Li <xing@cernet.edu.cn> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: 'Behave WG' <behave@ietf.org> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: AcBVtAXB Subject: [BEHAVE] Address-sharing stateless double IVI 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, 22 Oct 2009 08:47:58 -0000 Dear all, We submitted the following draft. http://tools.ietf.org/html/draft-xli-behave-divi-00 Comments are more than welcome. Regards, xing From mohamed.boucadair@orange-ftgroup.com Thu Oct 22 04:44:34 2009 Return-Path: <mohamed.boucadair@orange-ftgroup.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 10CF73A6889 for <behave@core3.amsl.com>; Thu, 22 Oct 2009 04:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 kmkOeRDTMPyr for <behave@core3.amsl.com>; Thu, 22 Oct 2009 04:44:33 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id C10D73A6840 for <behave@ietf.org>; Thu, 22 Oct 2009 04:44:32 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 48C5F248408; Thu, 22 Oct 2009 13:44:41 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 2D4D22380E0; Thu, 22 Oct 2009 13:44:41 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 22 Oct 2009 13:44:41 +0200 From: <mohamed.boucadair@orange-ftgroup.com> To: Christian Huitema <huitema@microsoft.com>, "teemu.savolainen@nokia.com" <teemu.savolainen@nokia.com>, "ajs@shinkuro.com" <ajs@shinkuro.com>, "behave@ietf.org" <behave@ietf.org> Date: Thu, 22 Oct 2009 13:44:39 +0200 Thread-Topic: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt Thread-Index: AQHKUOZcB4qVxczK40+zVvgdVO4zY5ENo/MAgAFHKICAAUzkUIABPuww Message-ID: <23132_1256211881_4AE045A9_23132_13404_1_94C682931C08B048B7A8645303FDC9F30781B159F8@PUEXCB1B.nanterre.francetelecom.fr> References: <20091019180002.1AFBE3A692D@core3.amsl.com> <20091019181555.GC9536@shinkuro.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3EF10EF424@NOK-EUMSG-01.mgdnok.nokia.com> <6B55F0F93C3E9D45AF283313B8D342BA211C9BC9@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA211C9BC9@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR x-tm-as-product-ver: SMEX-8.0.0.1259-5.600.1016-16652.007 x-tm-as-result: No--39.951800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.10.22.110924 Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.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: Thu, 22 Oct 2009 11:44:34 -0000 Dear Christian, all, FYI, we have submitted a draft to describe the A64 record for IPv4-mapped I= Pv6 addresses. An updated version of the draft will be submitted soon Title : A64: DNS Resource Record for IPv4-mapped IPv6 Address Author(s) : M. Boucadair, E. Burgey Filename : draft-boucadair-behave-dns-a64-00.txt Pages : 9 Date : 2009-10-18 In this context of IPv4-IPv6 interconnection, several solutions have been p= roposed. Some of these solutions require the definition of a new IPv4-mapp= ed IPv6 address [I-D.ietf-behave-address-format] which is used to represent= an IPv4-only host in an IPv6 realms and the definition of a new mechanism = called DNS64 for synthesizing a AAAA record, representing an IPv4-mapped IP= v6 address in the DNS system, from the A record representing the IPv4 addre= ss of the IPv4-only host [I-D.ietf-behave-dns64]. This IPv4-mapped IPv6 ad= dress, when managed by a translator, is to be considered as "fake" address = in a DNS system since it is not necessarily assigned to any host's interfac= e qualified by the associated name. This document defines a new DNS record= type and query type to identify IPv4-mapped IPv6 address [I-D.ietf-behave-= address-format] from native IPv6 ones. The new record type and query type = aim at helping the remote party to enforce its policies and avoid NAT64 box= es when possible. Native addresses are to be preferred. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boucadair-behave-dns-a64-00.txt Cheers, Med =20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Christian Huitema Envoy=E9 : mercredi 21 octobre 2009 18:40 =C0 : teemu.savolainen@nokia.com; ajs@shinkuro.com; behave@ietf.org Objet : Re: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt > The draft contains question about multihoming:"In particular, how is=20 > the multi-homed host supposed to know that a given AAAA is synthetic?". Wonder about that too. Isn't the best solution to create a new record type,= say A4A6, that would contain the mapped addresses of IPv4 only hosts? -- Christian Huitema _______________________________________________ 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 simon.perreault@viagenie.ca Thu Oct 22 05:30:37 2009 Return-Path: <simon.perreault@viagenie.ca> 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 455923A68A4 for <behave@core3.amsl.com>; Thu, 22 Oct 2009 05:30:37 -0700 (PDT) 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 93IO6KaT4P6x for <behave@core3.amsl.com>; Thu, 22 Oct 2009 05:30:36 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 46F1D3A6858 for <behave@ietf.org>; Thu, 22 Oct 2009 05:30:36 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id 9AD47210F5 for <behave@ietf.org>; Thu, 22 Oct 2009 08:30:45 -0400 (EDT) Message-ID: <4AE05075.6020807@viagenie.ca> Date: Thu, 22 Oct 2009 08:30:45 -0400 From: Simon Perreault <simon.perreault@viagenie.ca> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4 MIME-Version: 1.0 To: behave@ietf.org References: <20091014124502.096463A69EF@core3.amsl.com> <4ADC9F88.4000506@acm.org> In-Reply-To: <4ADC9F88.4000506@acm.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-ipv6-07.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: Thu, 22 Oct 2009 12:30:37 -0000 Marc Petit-Huguenin wrote, on 2009-10-19 13:19: > - Section 1, 2nd paragraph: "This document also defines and registers a new > error response code with the value 444[...]" > > The document also defines error response code 443. Indeed. I also added it to the IANA considerations section. > - Section 3, 2nd paragraph: "Assuming the request is authenticated and has not > been tampered with[...]" > > "has not been tampered with" is redundant. True. I removed it. > - Section 4.2, 1st paragraph: > > The action and error code to use in case of RESERVATION-TOKEN present are missing. I added the following: If it contains both a RESERVATION-TOKEN and a REQUESTED-ADDRESS-FAMILY, the server replies with a 400 (Bad Request) Allocate Error Response. > - Section 4.2, 5th and 6th: > > I think that it should be explicitly specified that a TURN server implementing > this I-D but not supporting IPv4 allocation (i.e. only IPv4-IPv6 and IPv6-IPv6) > must return a 440 if the Allocate request received does not contain a > REQUESTED-ADDRESS-FAMILY attribute. I added the following: If allocation of IPv4 addresses is disabled by local policy, the server returns a a 440 (Address Family not Supported) Allocate Error Response. > - Section 5.2: > > Returning a 443 is probably better, at least if the family does not match the > Allocation. Agreed. I changed it to the following: If a server receives a Refresh Request with a REQUESTED-ADDRESS-FAMILY attribute, and the attribute's value doesn't match the address family of the allocation, the server MUST reply with a 443 (Peer Address Family Mismatch) Refresh Error Response. > - Section 8.3, last paragraph: > > The DONT-FRAGMENT attribute should be followed for an IPv6 to IPv4 translation. That's what I thought too, but [draft-ietf-behave-v6v4-xlate-02] says to set DF=1 systematically, except when you receive a fragment header. Can you help me figure out what to replace the two ?'s below with? - Preferred behaviour - DONT-FRAGMENT absent - Fragment header absent => Set DF=1 - Fragment header present => Set DF=0 - DONT-FRAGMENT present - Fragment header absent => Set DF=1 - Fragment header present => Set DF=? - Alternative behaviour - DONT-FRAGMENT absent => Set DF=? - DONT-FRAGMENT present => Set DF=1 > - Section 10.2: > > The 443 error code is missing. Added. Thanks, Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From dwing@cisco.com Thu Oct 22 09:06:07 2009 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 E1CAA28C15B for <behave@core3.amsl.com>; Thu, 22 Oct 2009 09:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFby+nx6qw6w for <behave@core3.amsl.com>; Thu, 22 Oct 2009 09:06:07 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id F0A7928C103 for <behave@ietf.org>; Thu, 22 Oct 2009 09:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3605; q=dns/txt; s=sjiport05001; t=1256227577; x=1257437177; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Dan=20Wing"=20<dwing@cisco.com>|Subject:=20RE: =20[BEHAVE]=20Using=20DNS64=20to=20load=20balance=20to=20 NAT64|Date:=20Thu,=2022=20Oct=202009=2009:06:16=20-0700 |Message-ID:=20<026101ca5331$95fae070$5ba36b80@cisco.com> |To:=20"'Cameron=20Byrne'"=20<cb.list6@gmail.com>,=0D=0A =20=20=20=20=20=20=20=20"'marcelo=20bagnulo=20braun'"=20< marcelo@it.uc3m.es>|Cc:=20<behave@ietf.org>|MIME-Version: =201.0|Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<bcff0fba0910210722n4bcec955o1610b0e807a3 596c@mail.gmail.com>|References:=20<bcff0fba0910192301w6c ac213fl7109154d86f52480@mail.gmail.com><643AD0DC-5BD4-44B D-A206-D58A5F965F3A@muada.com><4ADEBAC7.4030202@it.uc3m.e s>=20<bcff0fba0910210722n4bcec955o1610b0e807a3596c@mail.g mail.com>; bh=P23b+L2REsWKpMclBuOHGd7Df4CthEGce+aZRLHyVZA=; b=Zp+vlQ7LS8FtYf9ruMMLgQ9r0yuUPLJgZhzuKp1dIldrh18Of6dgZ+3X kOM3eBuZcn74/WlyD2scku5oC/KXZxplg69adU6/OkX0/VjDI13qDqwxL 2FTbFlwmSSVtQYgxsxihThi2b6JXl0skaJInhM0ngX2mrnG0dAK4cUctZ Y=; 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: Aq0EAAMg4EqrR7H+/2dsb2JhbACKYbh+mFuEPwSBXQ X-IronPort-AV: E=Sophos;i="4.44,605,1249257600"; d="scan'208";a="100402623" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 22 Oct 2009 16:06:17 +0000 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9MG6GbL023140; Thu, 22 Oct 2009 16:06:16 GMT From: "Dan Wing" <dwing@cisco.com> To: "'Cameron Byrne'" <cb.list6@gmail.com>, "'marcelo bagnulo braun'" <marcelo@it.uc3m.es> References: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com><643AD0DC-5BD4-44BD-A206-D58A5F965F3A@muada.com><4ADEBAC7.4030202@it.uc3m.es> <bcff0fba0910210722n4bcec955o1610b0e807a3596c@mail.gmail.com> Date: Thu, 22 Oct 2009 09:06:16 -0700 Message-ID: <026101ca5331$95fae070$5ba36b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcpSWe3hVMm9sGF7TzynOWl5EjGXfAA1t5uQ In-Reply-To: <bcff0fba0910210722n4bcec955o1610b0e807a3596c@mail.gmail.com> Cc: behave@ietf.org Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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, 22 Oct 2009 16:06:08 -0000 =20 > -----Original Message----- > From: behave-bounces@ietf.org=20 > [mailto:behave-bounces@ietf.org] On Behalf Of Cameron Byrne > Sent: Wednesday, October 21, 2009 7:22 AM > To: marcelo bagnulo braun > Cc: behave@ietf.org > Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 >=20 > On Wed, Oct 21, 2009 at 12:39 AM, marcelo bagnulo braun > <marcelo@it.uc3m.es> wrote: > > Iljitsch van Beijnum escribi=F3: > >> > >> On 20 okt 2009, at 08:01, Cameron Byrne wrote: > >> > >>> Additionally, the NAT64 and the DNS64 should be able to=20 > communicate in > >>> such a way that the NAT64 can signal an overloading situation such > >>> that the DNS64 drops the overloaded NAT64 out of the round-robin > >>> prefix64 synthesis for some period of time. > >> > >> I have one problem here in addition to Andrew's objections: > >> > >> If make a given host move to a different NAT64, that means=20 > that for some > >> time, there will be an inconsistency between the external=20 > IPv4 addresses > >> associated with different sessions. This makes protocols=20 > like STUN fail, and > >> as such, should be avoided. > > > > but you could solve that problem by making the pref64 used=20 > by the dns64 > > dependent on the source address of the query, right? >=20 > This, in part, is exactly what i am looking for. This level of load > sharing would help me a great deal in delivering a solutions that > scales linearly. I can keep adding pref64 to the one DNS64 and keep > adding NAT64 boxes as demand arises. >=20 > > > > I mean, in that way, you could make sure that all the DNS=20 > queries coming to > > the dns64 server from the same source IP address get the=20 > same Pref64 bt > > different sources get different Pref64 >=20 > Excellent. >=20 > One other thing. I am not interested in including IGP in any of this > PREF64. I do not want temporary topology changes (link down) to swing > around NAT64 traffic when it is not needed. I want a DNS64 to hand > out a a specific and consistent PREF64 all the time. Perhaps a > sourced based hash that results in buckets 1, 2, 3 ... and each bucket > is a PREF64-1, -2, 3. >=20 > Also, keep in mind, the DNS64 will likely be deployed as an anycast in > many geographic locations ... so it will be subject to IGP changes... > but, i dont want the PREF64 to be dependent on IGP beyond the anycast > DNS64. For me, PREF64 should be statically tied to a single NAT64 > entity (which will be 1+1 boxes).=20 That is exactly the model I had in mind, as well. One thing to note is that if NAT state is shared between several NATs (as with draft-chen-behave-olnat or=20 draft-xu-behave-nat-state-sync) it would be possible to allow packets to egress any of the NATs that have the necessary state, and thus allow the IGP to attract traffic to a lightly- loaded NAT. -d > It's possible i did not understand > what was meant by Marcelo wrt to IGP. >=20 >=20 > > > > This would result in per source host load sharing and woudl=20 > address this > > particular issue i think >=20 > YES! :) >=20 > > > > Regards, marcelo > > > > > >> > >> You really don't want to run so close to your translator=20 > capacity that > >> systems like this become useful. > >> _______________________________________________ > >> 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 dwing@cisco.com Thu Oct 22 09:48:53 2009 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 AFB1A3A6983 for <behave@core3.amsl.com>; Thu, 22 Oct 2009 09:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.251 X-Spam-Level: X-Spam-Status: No, score=-6.251 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpfhApxPZgFV for <behave@core3.amsl.com>; Thu, 22 Oct 2009 09:48:52 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id D2CD13A6977 for <behave@ietf.org>; Thu, 22 Oct 2009 09:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=334; q=dns/txt; s=sjiport03001; t=1256230143; x=1257439743; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Dan=20Wing"=20<dwing@cisco.com>|Subject:=20adop t=20draft-van-beijnum-behave-ftp64-06=20as=20WG=20item |Date:=20Thu,=2022=20Oct=202009=2009:49:02=20-0700 |Message-ID:=20<02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> |To:=20<behave@ietf.org>|Cc:=20=3D?gb2312?B?J8H1tPPF9Cc =3D?=3D=20<liudapeng@chinamobile.com>,=0D=0A=20=20=20=20 =20=20=20=20=3D?gb2312?B?J7Lc1fEn?=3D=20<caozhen@chinamob ile.com>,=0D=0A=20=20=20=20=20=20=20=20"'Iljitsch=20van =20Beijnum'"=20<iljitsch@muada.com>,=0D=0A=20=20=20=20=20 =20=20=20"'Behave=20Chairs'"=20<behave-chairs@tools.ietf. org>|MIME-Version:=201.0|Content-Transfer-Encoding:=207bi t; bh=0gOpir9kJ11VrhOMetrhnmXYi1lz9W5KXZqui6eS2nI=; b=J3EC1Ek4K0hSalgpsMjpTT6t3Yi1hyN4s09TFCxtRiPF+egOL3BZe947 hpWMq/l6O6/L13ZKsf5wrfSlonO/ubzuoJ+Hy9CJQTXrYraMXN0Uusvr8 G/Wtrl0H2CQmBrjX4rFLKQ5mZ38u8U3SjFaHap2IYBmTD8bnyliYDvXLe A=; Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4EABcq4EqrR7H+/2dsb2JhbACEdIVtuUGHCwiRSYEugjpXBIFd X-IronPort-AV: E=Sophos;i="4.44,606,1249257600"; d="scan'208";a="198273437" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 22 Oct 2009 16:49:02 +0000 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9MGn2Ur019973; Thu, 22 Oct 2009 16:49:02 GMT From: "Dan Wing" <dwing@cisco.com> To: <behave@ietf.org> Date: Thu, 22 Oct 2009 09:49:02 -0700 Message-ID: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcpTN47p4TJlBdfLRuKKtqagQV0crw== Cc: =?gb2312?B?J8H1tPPF9Cc=?= <liudapeng@chinamobile.com>, =?gb2312?B?J7Lc1fEn?= <caozhen@chinamobile.com>, 'Behave Chairs' <behave-chairs@tools.ietf.org> Subject: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 22 Oct 2009 16:48:53 -0000 We are considering adopting draft-van-beijnum-behave-ftp64-06 as a WG document to meet our milestone "Jan 2010 Submit to IESG: FTP ALG for IPv6/IPv4 translation (std)", http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-06 The author believes the document now incorporates all feedback. Please reply to the list. -d From dwing@cisco.com Thu Oct 22 10:08:23 2009 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 5940F28C16F for <behave@core3.amsl.com>; Thu, 22 Oct 2009 10:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.282 X-Spam-Level: X-Spam-Status: No, score=-6.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvMxjQRlpM5o for <behave@core3.amsl.com>; Thu, 22 Oct 2009 10:08:22 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 7160328C16D for <behave@ietf.org>; Thu, 22 Oct 2009 10:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=738; q=dns/txt; s=sjiport01001; t=1256231312; x=1257440912; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Dan=20Wing"=20<dwing@cisco.com>|Subject:=20draf t-boucadair-behave-dns-a64-00.txt=20[was=20RE:=20[BEHAVE] =20I-D=20Action:draft-ietf-behave-dns64-01.txt]|Date:=20T hu,=2022=20Oct=202009=2010:08:31=20-0700|Message-ID:=20<0 2d401ca533a$4893ba10$5ba36b80@cisco.com>|To:=20<mohamed.b oucadair@orange-ftgroup.com>|Cc:=20"'Christian=20Huitema' "=20<huitema@microsoft.com>,=0D=0A=20=20=20=20=20=20=20 =20<teemu.savolainen@nokia.com>,=20<ajs@shinkuro.com>,=20 <behave@ietf.org>,=0D=0A=20=20=20=20=20=20=20=20<draft-bo ucadair-behave-dns-a64@tools.ietf.org>|MIME-Version:=201. 0|Content-Transfer-Encoding:=207bit|In-Reply-To:=20<23132 _1256211881_4AE045A9_23132_13404_1_94C682931C08B048B7A864 5303FDC9F30781B159F8@PUEXCB1B.nanterre.francetelecom.fr> |References:=20<20091019180002.1AFBE3A692D@core3.amsl.com ><20091019181555.GC9536@shinkuro.com><18034D4D7FE9AE48BF1 9AB1B0EF2729F3EF10EF424@NOK-EUMSG-01.mgdnok.nokia.com><6B 55F0F93C3E9D45AF283313B8D342BA211C9BC9@TK5EX14MBXW652.win group.windeploy.ntdev.microsoft.com>=20<23132_1256211881_ 4AE045A9_23132_13404_1_94C682931C08B048B7A8645303FDC9F307 81B159F8@PUEXCB1B.nanterre.francetelecom.fr>; bh=XuXud3CbsNSOud+QygCv1WAGD5c/A0JUw9qFnK1TRoo=; b=tBwXRSDM/xTJTkpnAfs0mUhCR+oIqGovfbUpMDrPZV0l8IwKSeGtZsqO iI1SxIYTYR5F+wujv9U3najuMyFz5N67ZettU385zcN4FXYRgxvfybSSU TJQOokTnLrlWWRRt2U+X5ATrr/gmgz9CpISfZQ71Ju9gVFqkEGBS5X1m1 w=; 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: Aq0EANct4EqrR7Hu/2dsb2JhbACKYblImFiEPwSBXQ X-IronPort-AV: E=Sophos;i="4.44,606,1249257600"; d="scan'208";a="259949700" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 22 Oct 2009 17:08:32 +0000 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9MH8WgI003271; Thu, 22 Oct 2009 17:08:32 GMT From: "Dan Wing" <dwing@cisco.com> To: <mohamed.boucadair@orange-ftgroup.com> References: <20091019180002.1AFBE3A692D@core3.amsl.com><20091019181555.GC9536@shinkuro.com><18034D4D7FE9AE48BF19AB1B0EF2729F3EF10EF424@NOK-EUMSG-01.mgdnok.nokia.com><6B55F0F93C3E9D45AF283313B8D342BA211C9BC9@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <23132_1256211881_4AE045A9_23132_13404_1_94C682931C08B048B7A8645303FDC9F30781B159F8@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 22 Oct 2009 10:08:31 -0700 Message-ID: <02d401ca533a$4893ba10$5ba36b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AQHKUOZcB4qVxczK40+zVvgdVO4zY5ENo/MAgAFHKICAAUzkUIABPuwwgABYBaA= In-Reply-To: <23132_1256211881_4AE045A9_23132_13404_1_94C682931C08B048B7A8645303FDC9F30781B159F8@PUEXCB1B.nanterre.francetelecom.fr> Cc: ajs@shinkuro.com, draft-boucadair-behave-dns-a64@tools.ietf.org, behave@ietf.org Subject: [BEHAVE] draft-boucadair-behave-dns-a64-00.txt [was RE: I-D Action:draft-ietf-behave-dns64-01.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: Thu, 22 Oct 2009 17:08:23 -0000 > FYI, we have submitted a draft to describe the A64 record for > IPv4-mapped IPv6 addresses. An updated version of the draft > will be submitted soon draft-boucadair-behave-dns-a64-00 requires the DNS64 and the host to implement a new DNS resource record, A64, in order to learn if the DNS64 synthesized a response. Instead, have you considered just having the host query an existing DNS64 with the CD and DO bits set (which disables the DNS64's AAAA synthesis) and have the host do its own DNS64 processing? See item #3 in http://tools.ietf.org/html/draft-ietf-behave-dns64-01#section-5.5 If you have considered that technique, I expect you found some sort of disadvantage to that technique. Please share. -d From cb.list6@gmail.com Thu Oct 22 10:20:07 2009 Return-Path: <cb.list6@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 B8D063A680D for <behave@core3.amsl.com>; Thu, 22 Oct 2009 10:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 KzBEpHnIKtUW for <behave@core3.amsl.com>; Thu, 22 Oct 2009 10:20:06 -0700 (PDT) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 9C9A83A65A6 for <behave@ietf.org>; Thu, 22 Oct 2009 10:20:06 -0700 (PDT) Received: by pwi4 with SMTP id 4so1643387pwi.29 for <behave@ietf.org>; Thu, 22 Oct 2009 10:20:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pjjv7VF+OdVxfx8JynQyQITCQTURZLb3dsSxAkr5tf0=; b=RnDP4HuTTRHayMfd3gpPbraH+WKWpHNFsJNcXe7ERJe6/DTJI0o/TXO4gcj3o8/trN AaqAwKRP1wOs/BfaRoq/OdHXDdlaZx1Ls9FPe32V1QCbEk/spix3/5FAfkwAfa+WAhFK rjz9lN0Eyec/OzpyUvslExmaQZF8RQkJCSzhE= 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=b8wsQO1qJBCS9VCTvfdU+2HKCHttTum7yzoM6q8FpH3yg+jPOGtAgq8WecRXKqJrX9 IPEg4WKw5XwPNQFferRLKoCEnV0xFo/ZE8pblDgEWpambIcdGj3hS5LSWUR5ozTn9VgO bXfYeWQ2WDR5Pdfa9S2LfVDsGSlopFhTFyUcA= MIME-Version: 1.0 Received: by 10.142.150.41 with SMTP id x41mr701269wfd.243.1256232013601; Thu, 22 Oct 2009 10:20:13 -0700 (PDT) In-Reply-To: <026101ca5331$95fae070$5ba36b80@cisco.com> References: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com> <643AD0DC-5BD4-44BD-A206-D58A5F965F3A@muada.com> <4ADEBAC7.4030202@it.uc3m.es> <bcff0fba0910210722n4bcec955o1610b0e807a3596c@mail.gmail.com> <026101ca5331$95fae070$5ba36b80@cisco.com> Date: Thu, 22 Oct 2009 10:20:13 -0700 Message-ID: <bcff0fba0910221020r64db8931o3a94abe9b30411e7@mail.gmail.com> From: Cameron Byrne <cb.list6@gmail.com> To: Dan Wing <dwing@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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, 22 Oct 2009 17:20:07 -0000 On Thu, Oct 22, 2009 at 9:06 AM, Dan Wing <dwing@cisco.com> wrote: > > >> -----Original Message----- >> From: behave-bounces@ietf.org >> [mailto:behave-bounces@ietf.org] On Behalf Of Cameron Byrne >> Sent: Wednesday, October 21, 2009 7:22 AM >> To: marcelo bagnulo braun >> Cc: behave@ietf.org >> Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 >> >> On Wed, Oct 21, 2009 at 12:39 AM, marcelo bagnulo braun >> <marcelo@it.uc3m.es> wrote: >> > Iljitsch van Beijnum escribi=F3: >> >> >> >> On 20 okt 2009, at 08:01, Cameron Byrne wrote: >> >> >> >>> Additionally, the NAT64 and the DNS64 should be able to >> communicate in >> >>> such a way that the NAT64 can signal an overloading situation such >> >>> that the DNS64 drops the overloaded NAT64 out of the round-robin >> >>> prefix64 synthesis for some period of time. >> >> >> >> I have one problem here in addition to Andrew's objections: >> >> >> >> If make a given host move to a different NAT64, that means >> that for some >> >> time, there will be an inconsistency between the external >> IPv4 addresses >> >> associated with different sessions. This makes protocols >> like STUN fail, and >> >> as such, should be avoided. >> > >> > but you could solve that problem by making the pref64 used >> by the dns64 >> > dependent on the source address of the query, right? >> >> This, in part, is exactly what i am looking for. =A0This level of load >> sharing would help me a great deal in delivering a solutions that >> scales linearly. =A0I can keep adding pref64 to the one DNS64 and keep >> adding NAT64 boxes as demand arises. >> >> > >> > I mean, in that way, you could make sure that all the DNS >> queries coming to >> > the dns64 server from the same source IP address get the >> same Pref64 bt >> > different sources get different Pref64 >> >> Excellent. >> >> One other thing. =A0I am not interested in including IGP in any of this >> PREF64. =A0I do not want temporary topology changes (link down) to swing >> around NAT64 traffic when it is not needed. =A0I want a DNS64 to hand >> out a a specific and consistent PREF64 all the time. =A0Perhaps a >> sourced based hash that results in buckets 1, 2, 3 ... and each bucket >> is a PREF64-1, -2, 3. >> >> Also, keep in mind, the DNS64 will likely be deployed as an anycast in >> many geographic locations ... so it will be subject to IGP changes... >> but, i dont want the PREF64 to be dependent on IGP beyond the anycast >> DNS64. =A0For me, PREF64 should be statically tied to a single NAT64 >> entity (which will be 1+1 boxes). > > That is exactly the model I had in mind, as well. > > > One thing to note is that if NAT state is shared between several > NATs (as with draft-chen-behave-olnat or > draft-xu-behave-nat-state-sync) it would be possible to allow > packets to egress any of the NATs that have the necessary > state, and thus allow the IGP to attract traffic to a lightly- > loaded NAT. > > -d I would be very hesitant to creep the NAT functions into the IGP or BGP or any sort of network topology technology. The WAN guys have enough trouble today figuring out why flows work the way they do on the network with IGP / BGP / MPLS / TE / VPN / multi-topology /... They don't need another variable to look at when they are troubleshooting shooting basic network topology issues. This is why i am suggesting that the DNS64 have a hand in either "dumb round robin" or "intelligent NAT64 system aware" load sharing, since DNS64 is assigning the PREF64 to the client resolver, it is the driver directing the load on the network / NAT64. This is an important point. The DNS64 system drives the load to unique PREF64 / NAT64 that is hosted on a specific location in the network topology. One of the main advantages of DNS64/NAT64 is that it is not required to be part of shortest path routing topology between the user and the content like NAT-PT was, thus the entire system encourages and benefits from NAT-free end to end IPv6 communication. The DNS64 / PREF64 provides a very elegant detour from the shortest path string of routers and into a NAT64 service specific / optimized node, only when NAT64 is needed. In my NAT44 experience, there is such a thing as a "bad state".... protocols act in unexpected ways, which triggers unforeseen software defects and unforeseen feature interaction that can results in catastrophic system failure. I have seen this several times from several NAT / Firewall vendors where there is a 1+ 1 pair with state sync... some SIP packet comes in the firewall with an awkward mix of parameters, and both the Active and Standby firewall reboot because the active wall setup the "bad" session then replicated it to the standby box ...and now both active and standby hang and / or reboot... Rebooting being the better scenario than just locking up. This is the reality of NAT from all vendors. That said, i really don't like state sync beyond local 1+1 pairs, network wide state sync does not fly ... think cascading failures across the entire network. Given how fragile these state machines are, the fault domain needs to be small and simple. I would also not overestimate the ability to replicate state across many systems in small region. Replicating state requires a lot of CPU cycles and is very time / distance / latency sensitive. I assume many HTTP sessions conclude on the initiating NAT system before the session is replicated and installed on the standby system. Cameron > >> It's possible i did not understand >> what was meant by Marcelo wrt to IGP. >> >> >> > >> > This would result in per source host load sharing and woudl >> address this >> > particular issue i think >> >> YES! :) >> >> > >> > Regards, marcelo >> > >> > >> >> >> >> You really don't want to run so close to your translator >> capacity that >> >> systems like this become useful. >> >> _______________________________________________ >> >> 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 ajs@shinkuro.com Thu Oct 22 10:56:00 2009 Return-Path: <ajs@shinkuro.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 D32883A69CB for <behave@core3.amsl.com>; Thu, 22 Oct 2009 10:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.683, 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 Nvr+ySOYPRSN for <behave@core3.amsl.com>; Thu, 22 Oct 2009 10:56:00 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 046BE3A6985 for <behave@ietf.org>; Thu, 22 Oct 2009 10:56:00 -0700 (PDT) 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 00F282FE8CDC for <behave@ietf.org>; Thu, 22 Oct 2009 17:56:08 +0000 (UTC) Date: Thu, 22 Oct 2009 13:56:07 -0400 From: Andrew Sullivan <ajs@shinkuro.com> To: behave@ietf.org Message-ID: <20091022175607.GC44604@shinkuro.com> References: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com> <643AD0DC-5BD4-44BD-A206-D58A5F965F3A@muada.com> <4ADEBAC7.4030202@it.uc3m.es> <bcff0fba0910210722n4bcec955o1610b0e807a3596c@mail.gmail.com> <026101ca5331$95fae070$5ba36b80@cisco.com> <bcff0fba0910221020r64db8931o3a94abe9b30411e7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <bcff0fba0910221020r64db8931o3a94abe9b30411e7@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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, 22 Oct 2009 17:56:00 -0000 On Thu, Oct 22, 2009 at 10:20:13AM -0700, Cameron Byrne wrote: > This is why i am suggesting that the DNS64 have a hand in either "dumb > round robin" or "intelligent NAT64 system aware" load sharing, since > DNS64 is assigning the PREF64 to the client resolver, it is the driver > directing the load on the network / NAT64. This is an important > point. The DNS64 system drives the load to unique PREF64 / NAT64 that > is hosted on a specific location in the network topology. One of the > main advantages of DNS64/NAT64 is that it is not required to be part > of shortest path routing topology between the user and the content > like NAT-PT was, thus the entire system encourages and benefits from > NAT-free end to end IPv6 communication. The DNS64 / PREF64 provides a > very elegant detour from the shortest path string of routers and into > a NAT64 service specific / optimized node, only when NAT64 is needed. This view is exactly how we got so much sludge from various local DNS systems leaking out onto the Internet. For instance, we have a _whole system_ (the AS112 system) of anycast name servers just to sink the traffic that used to arrive at the in-addr.arpa zone due to RFC 1918 address space allocations. The idea that these DNS answers are not going to leak, are not going to get out onto the wider Internet, and so on is completely fanciful. They will, and the only question is how we can arrange things so that they do the least damage. Therefore, the trickier the strategy one proposes for DNS64, the more my alarm bells ring. I think we want to take DNS64 for what it is -- a cute trick that allows us to make two completely different networks talk to one another -- and accept that, as all cute tricks, it has a number of limitations some of which will be, "Performance is rotten." Anything that smacks of DNS tricks that already break all over the place in the plain old DNS world (and that will break even more as DNSSEC gets turned on) sounds to me like the sort of trouble we shouldn't be borrowing. I'm aware that people are going to do those things, but if I have to give them the sort of advice that will really help them with deployment, my advice is "don't". A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dwing@cisco.com Thu Oct 22 12:15:51 2009 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 144A428C126 for <behave@core3.amsl.com>; Thu, 22 Oct 2009 12:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.309 X-Spam-Level: X-Spam-Status: No, score=-6.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VloyMrGz7nha for <behave@core3.amsl.com>; Thu, 22 Oct 2009 12:15:49 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 32C7B3A69D9 for <behave@ietf.org>; Thu, 22 Oct 2009 12:15:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4172; q=dns/txt; s=sjiport06001; t=1256238959; x=1257448559; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Dan=20Wing"=20<dwing@cisco.com>|Subject:=20RE: =20[BEHAVE]=20Using=20DNS64=20to=20load=20balance=20to=20 NAT64|Date:=20Thu,=2022=20Oct=202009=2012:15:54=20-0700 |Message-ID:=20<03e101ca534c$164faa20$5ba36b80@cisco.com> |To:=20"'Andrew=20Sullivan'"=20<ajs@shinkuro.com>,=20<beh ave@ietf.org>|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<200910 22175607.GC44604@shinkuro.com>|References:=20<bcff0fba091 0192301w6cac213fl7109154d86f52480@mail.gmail.com><643AD0D C-5BD4-44BD-A206-D58A5F965F3A@muada.com><4ADEBAC7.4030202 @it.uc3m.es><bcff0fba0910210722n4bcec955o1610b0e807a3596c @mail.gmail.com><026101ca5331$95fae070$5ba36b80@cisco.com ><bcff0fba0910221020r64db8931o3a94abe9b30411e7@mail.gmail .com>=20<20091022175607.GC44604@shinkuro.com>; bh=pkuLDBdbRxofPf4p/xJxuHmMdNOSx5etMa0jirh25IE=; b=PNaL+Fjp11/2AnvHgf02rHNn6VVGgRHdnhieZO54UkBwI0+4SxIqfyrW NKFn+U6ziXuGb7kq7Izj+jlodMXZFcHbc4eJRpcbdlqutsKRk9+4wYoX4 EpaZRvpeLzZz4I7gylny5mYMg9hMeW3myaHhDxIFACBIuON8w1eKEBuLi Q=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEEAMdM4EqrR7Hu/2dsb2JhbACKYbkVmFOEPwSBXQ X-IronPort-AV: E=Sophos;i="4.44,606,1249257600"; d="scan'208";a="415446106" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 22 Oct 2009 19:15:59 +0000 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9MJFsSq000371; Thu, 22 Oct 2009 19:15:58 GMT From: "Dan Wing" <dwing@cisco.com> To: "'Andrew Sullivan'" <ajs@shinkuro.com>, <behave@ietf.org> References: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com><643AD0DC-5BD4-44BD-A206-D58A5F965F3A@muada.com><4ADEBAC7.4030202@it.uc3m.es><bcff0fba0910210722n4bcec955o1610b0e807a3596c@mail.gmail.com><026101ca5331$95fae070$5ba36b80@cisco.com><bcff0fba0910221020r64db8931o3a94abe9b30411e7@mail.gmail.com> <20091022175607.GC44604@shinkuro.com> Date: Thu, 22 Oct 2009 12:15:54 -0700 Message-ID: <03e101ca534c$164faa20$5ba36b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcpTQPGbCqmQQJxBRBi1cvUdKmSY6gACdKaA In-Reply-To: <20091022175607.GC44604@shinkuro.com> Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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, 22 Oct 2009 19:15:51 -0000 > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Andrew Sullivan > Sent: Thursday, October 22, 2009 10:56 AM > To: behave@ietf.org > Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 > > On Thu, Oct 22, 2009 at 10:20:13AM -0700, Cameron Byrne wrote: > > > This is why i am suggesting that the DNS64 have a hand in > either "dumb > > round robin" or "intelligent NAT64 system aware" load sharing, since > > DNS64 is assigning the PREF64 to the client resolver, it is > the driver > > directing the load on the network / NAT64. This is an important > > point. The DNS64 system drives the load to unique PREF64 / > NAT64 that > > is hosted on a specific location in the network topology. > One of the > > main advantages of DNS64/NAT64 is that it is not required to be part > > of shortest path routing topology between the user and the content > > like NAT-PT was, thus the entire system encourages and benefits from > > NAT-free end to end IPv6 communication. The DNS64 / PREF64 > provides a > > very elegant detour from the shortest path string of > routers and into > > a NAT64 service specific / optimized node, only when NAT64 > is needed. > > This view is exactly how we got so much sludge from various local DNS > systems leaking out onto the Internet. For instance, we have a _whole > system_ (the AS112 system) of anycast name servers just to sink the > traffic that used to arrive at the in-addr.arpa zone due to RFC 1918 > address space allocations. The idea that these DNS answers are not > going to leak, are not going to get out onto the wider Internet, and > so on is completely fanciful. They will, and the only question is how > we can arrange things so that they do the least damage. > > Therefore, the trickier the strategy one proposes for DNS64, the more > my alarm bells ring. I think we want to take DNS64 for what it is -- > a cute trick that allows us to make two completely different networks > talk to one another -- and accept that, as all cute tricks, it has a > number of limitations some of which will be, "Performance is rotten." > Anything that smacks of DNS tricks that already break all over the > place in the plain old DNS world (and that will break even more as > DNSSEC gets turned on) sounds to me like the sort of trouble we > shouldn't be borrowing. I'm aware that people are going to do those > things, but if I have to give them the sort of advice that will really > help them with deployment, my advice is "don't". It's important that, as best we can, the public IPv4 address stay the same for all translations by a client. Otherwise some applications will break. FTP certainly breaks. Other IP-based auth/authz systems break, too, and I am told some websites use cookies that encode IP addresses. That's why REQ-1 is written in http://tools.ietf.org/html/draft-nishitani-cgn-02#section-3 If the DNS64 were to change the Prefix as a NAT64's load changed, it would cause flows to take a different NAT64. If that different NAT64 is not sharing state with other NAT64s, a different public IPv4 address would be assigned. So, a safer approach is to load balance when the IPv6 address is assigned, using DHCPv6 to assign a DNS64 to a host is safer, and have that DNS64 always use the same Prefix for its synthesized answers. This is a natural thing to do, anyway -- if you have 5 NAT64 devices you want 20% of users to go to each one. So 20% of your users are pointed to one DNS64, 20% to another DNS64, and so on. Each DNS64 could, actually, be the same DNS64 box -- which means for this scheme the DNS64 should use the *destination* address of the arriving DNS query (rather than source address) to decide which Prefix to use in the synthesized response. Would that be reasonable to put into the DNS64 spec? -d > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From ajs@shinkuro.com Thu Oct 22 13:10:10 2009 Return-Path: <ajs@shinkuro.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 174703A693B for <behave@core3.amsl.com>; Thu, 22 Oct 2009 13:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.651, 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 PmsZhc2ovc8y for <behave@core3.amsl.com>; Thu, 22 Oct 2009 13:10:09 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 35B9D3A68EE for <behave@ietf.org>; Thu, 22 Oct 2009 13:10:09 -0700 (PDT) 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 8CE5E2FE8CDC for <behave@ietf.org>; Thu, 22 Oct 2009 20:10:18 +0000 (UTC) Date: Thu, 22 Oct 2009 16:10:16 -0400 From: Andrew Sullivan <ajs@shinkuro.com> To: behave@ietf.org Message-ID: <20091022201015.GH44604@shinkuro.com> References: <20091022175607.GC44604@shinkuro.com> <03e101ca534c$164faa20$5ba36b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03e101ca534c$164faa20$5ba36b80@cisco.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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, 22 Oct 2009 20:10:10 -0000 On Thu, Oct 22, 2009 at 12:15:54PM -0700, Dan Wing wrote: > DNS64, and so on. Each DNS64 could, actually, be the same > DNS64 box -- which means for this scheme the DNS64 should use > the *destination* address of the arriving DNS query (rather > than source address) to decide which Prefix to use in the > synthesized response. Would that be reasonable to put into > the DNS64 spec? This sounds like a suggestion about a section detailing different strategies for managing multiple Pref::64/n, in case multiple such prefixes are assigned. This exact path was what I was wary of travelling when the whole multicast problem came up, because it sounds like we're going to start recommending ways to make this thing quite a bit more complicated than what I'd hoped. But if we really want that, ok, let's get some text and start figuring out how to add it. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From wangxuewei@huawei.com Fri Oct 23 01:12:24 2009 Return-Path: <wangxuewei@huawei.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 410853A68F7 for <behave@core3.amsl.com>; Fri, 23 Oct 2009 01:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.258 X-Spam-Level: * X-Spam-Status: No, score=1.258 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, 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 82cmMabF05ar for <behave@core3.amsl.com>; Fri, 23 Oct 2009 01:12:23 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 14F313A68A4 for <behave@ietf.org>; Fri, 23 Oct 2009 01:12:23 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRY0071SK4ML6@szxga02-in.huawei.com> for behave@ietf.org; Fri, 23 Oct 2009 16:12:23 +0800 (CST) Received: from w00104636 ([10.111.12.107]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRY0055JK4MDF@szxga02-in.huawei.com> for behave@ietf.org; Fri, 23 Oct 2009 16:12:22 +0800 (CST) Date: Fri, 23 Oct 2009 16:12:21 +0800 From: Xuewei Wang <wangxuewei@huawei.com> To: mohamed.boucadair@orange-ftgroup.com, Christian Huitema <huitema@microsoft.com>, teemu.savolainen@nokia.com, ajs@shinkuro.com, behave@ietf.org Message-id: <00d501ca53b8$8c491c90$6b0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <20091019180002.1AFBE3A692D@core3.amsl.com> <20091019181555.GC9536@shinkuro.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3EF10EF424@NOK-EUMSG-01.mgdnok.nokia.com> <6B55F0F93C3E9D45AF283313B8D342BA211C9BC9@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <23132_1256211881_4AE045A9_23132_13404_1_94C682931C08B048B7A8645303FDC9F30781B159F8@PUEXCB1B.nanterre.francetelecom.fr> Subject: [BEHAVE] draft-boucadair-behave-dns-a64-00.txt [was RE: I-DAction:draft-ietf-behave-dns64-01.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: Fri, 23 Oct 2009 08:12:24 -0000 SGksIG1vaGFtZWQsDQpJIGhhdmUgbm90aWNlZCB5b3VyIG5ldyBkcmFmdCBkcmFmdC1ib3VjYWRh aXItYmVoYXZlLWRucy1hNjQtMDAuICBJZiBpIHVuZGVyc3RhbmQgaXQgY29ycmVjdGx5IHRoaXMg ZHJhZnQgbWFrZXMgRE5TIHNlcnZlciB0byBhZGQgYSBuZXcgYTY0IFJSIHRvIHJlcHJlc2VudCBh biBJUHY0LW1hcHBlZCBJUHY2IGFkZHJlc3Nlcy4gQmVjYXVzZSB0aGUgRE5TIHNlcnZlciBkb24n dCBzZXJ2ZSBhbnkgc3BlY2lmaWMgTkFUNjRzLCBzbyB0aGUgcHJlZml4NjQgd2hpY2ggdGhlIERO UyBzZXJ2ZXIgdXNlcyB0byBjb25zdHJ1Y3QgYTY0IFJSIG11c3QgYmUgYSBXZWxsLUtub3duIFBy ZWZpeCByYXRoZXIgdGhhbiBhIE5ldHdvcmstU3BlY2lmaWMgUHJlZml4LCBpcyBteSB1bmRlcnN0 YW5kIGNvcnJlY3Q/DQoNCg0KWHVld2VpIFdhbmcNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0gDQpGcm9tOiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLWZ0Z3JvdXAuY29tPg0KVG86ICJD aHJpc3RpYW4gSHVpdGVtYSIgPGh1aXRlbWFAbWljcm9zb2Z0LmNvbT47IDx0ZWVtdS5zYXZvbGFp bmVuQG5va2lhLmNvbT47IDxhanNAc2hpbmt1cm8uY29tPjsgPGJlaGF2ZUBpZXRmLm9yZz4NClNl bnQ6IFRodXJzZGF5LCBPY3RvYmVyIDIyLCAyMDA5IDc6NDQgUE0NClN1YmplY3Q6IFJlOiBbQkVI QVZFXSBJLUQgQWN0aW9uOmRyYWZ0LWlldGYtYmVoYXZlLWRuczY0LTAxLnR4dA0KDQoNCg0KRGVh ciBDaHJpc3RpYW4sIGFsbCwNCg0KRllJLCB3ZSBoYXZlIHN1Ym1pdHRlZCBhIGRyYWZ0IHRvIGRl c2NyaWJlIHRoZSBBNjQgcmVjb3JkIGZvciBJUHY0LW1hcHBlZCBJUHY2IGFkZHJlc3Nlcy4gQW4g dXBkYXRlZCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCB3aWxsIGJlIHN1Ym1pdHRlZCBzb29uDQoNClRp dGxlICAgICAgICAgICA6IEE2NDogRE5TIFJlc291cmNlIFJlY29yZCBmb3IgSVB2NC1tYXBwZWQg SVB2NiBBZGRyZXNzDQpBdXRob3IocykgICAgICAgOiBNLiBCb3VjYWRhaXIsIEUuIEJ1cmdleQ0K RmlsZW5hbWUgICAgICAgIDogZHJhZnQtYm91Y2FkYWlyLWJlaGF2ZS1kbnMtYTY0LTAwLnR4dA0K UGFnZXMgICAgICAgICAgIDogOQ0KRGF0ZSAgICAgICAgICAgIDogMjAwOS0xMC0xOA0KDQpJbiB0 aGlzIGNvbnRleHQgb2YgSVB2NC1JUHY2IGludGVyY29ubmVjdGlvbiwgc2V2ZXJhbCBzb2x1dGlv bnMgaGF2ZSBiZWVuIHByb3Bvc2VkLiAgU29tZSBvZiB0aGVzZSBzb2x1dGlvbnMgcmVxdWlyZSB0 aGUgZGVmaW5pdGlvbiBvZiBhIG5ldyBJUHY0LW1hcHBlZCBJUHY2IGFkZHJlc3MgW0ktRC5pZXRm LWJlaGF2ZS1hZGRyZXNzLWZvcm1hdF0gd2hpY2ggaXMgdXNlZCB0byByZXByZXNlbnQgYW4gSVB2 NC1vbmx5IGhvc3QgaW4gYW4gSVB2NiByZWFsbXMgYW5kIHRoZSBkZWZpbml0aW9uIG9mIGEgbmV3 IG1lY2hhbmlzbSBjYWxsZWQgRE5TNjQgZm9yIHN5bnRoZXNpemluZyBhIEFBQUEgcmVjb3JkLCBy ZXByZXNlbnRpbmcgYW4gSVB2NC1tYXBwZWQgSVB2NiBhZGRyZXNzIGluIHRoZSBETlMgc3lzdGVt LCBmcm9tIHRoZSBBIHJlY29yZCByZXByZXNlbnRpbmcgdGhlIElQdjQgYWRkcmVzcyBvZiB0aGUg SVB2NC1vbmx5IGhvc3QgW0ktRC5pZXRmLWJlaGF2ZS1kbnM2NF0uICBUaGlzIElQdjQtbWFwcGVk IElQdjYgYWRkcmVzcywgd2hlbiBtYW5hZ2VkIGJ5IGEgdHJhbnNsYXRvciwgaXMgdG8gYmUgY29u c2lkZXJlZCBhcyAiZmFrZSIgYWRkcmVzcyBpbiBhIEROUyBzeXN0ZW0gc2luY2UgaXQgaXMgbm90 IG5lY2Vzc2FyaWx5IGFzc2lnbmVkIHRvIGFueSBob3N0J3MgaW50ZXJmYWNlIHF1YWxpZmllZCBi eSB0aGUgYXNzb2NpYXRlZCBuYW1lLiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IEROUyBy ZWNvcmQgdHlwZSBhbmQgcXVlcnkgdHlwZSB0byBpZGVudGlmeSBJUHY0LW1hcHBlZCBJUHY2IGFk ZHJlc3MgW0ktRC5pZXRmLWJlaGF2ZS1hZGRyZXNzLWZvcm1hdF0gZnJvbSBuYXRpdmUgSVB2NiBv bmVzLiAgVGhlIG5ldyByZWNvcmQgdHlwZSBhbmQgcXVlcnkgdHlwZSBhaW0gYXQgaGVscGluZyB0 aGUgcmVtb3RlIHBhcnR5IHRvIGVuZm9yY2UgaXRzIHBvbGljaWVzIGFuZCBhdm9pZCBOQVQ2NCBi b3hlcyB3aGVuIHBvc3NpYmxlLiAgTmF0aXZlIGFkZHJlc3NlcyBhcmUgdG8gYmUgcHJlZmVycmVk Lg0KDQpBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCmh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWJvdWNhZGFpci1iZWhhdmUtZG5zLWE2NC0wMC50eHQN Cg0KDQpDaGVlcnMsDQpNZWQNCg0KIA0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRl IDogYmVoYXZlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpiZWhhdmUtYm91bmNlc0BpZXRmLm9y Z10gRGUgbGEgcGFydCBkZSBDaHJpc3RpYW4gSHVpdGVtYQ0KRW52b3npIDogbWVyY3JlZGkgMjEg b2N0b2JyZSAyMDA5IDE4OjQwDQrAIDogdGVlbXUuc2F2b2xhaW5lbkBub2tpYS5jb207IGFqc0Bz aGlua3Vyby5jb207IGJlaGF2ZUBpZXRmLm9yZw0KT2JqZXQgOiBSZTogW0JFSEFWRV0gSS1EIEFj dGlvbjpkcmFmdC1pZXRmLWJlaGF2ZS1kbnM2NC0wMS50eHQNCg0KPiBUaGUgZHJhZnQgY29udGFp bnMgcXVlc3Rpb24gYWJvdXQgbXVsdGlob21pbmc6IkluIHBhcnRpY3VsYXIsIGhvdyBpcyANCj4g dGhlIG11bHRpLWhvbWVkIGhvc3Qgc3VwcG9zZWQgdG8ga25vdyB0aGF0IGEgZ2l2ZW4gQUFBQSBp cyBzeW50aGV0aWM/Ii4NCg0KV29uZGVyIGFib3V0IHRoYXQgdG9vLiBJc24ndCB0aGUgYmVzdCBz b2x1dGlvbiB0byBjcmVhdGUgYSBuZXcgcmVjb3JkIHR5cGUsIHNheSBBNEE2LCB0aGF0IHdvdWxk IGNvbnRhaW4gdGhlIG1hcHBlZCBhZGRyZXNzZXMgb2YgSVB2NCBvbmx5IGhvc3RzPw0KDQotLSBD aHJpc3RpYW4gSHVpdGVtYQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkJlaGF2ZSBtYWlsaW5nIGxpc3QNCkJlaGF2ZUBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZWhhdmUNCg0KKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqDQpUaGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyAo dGhlICJtZXNzYWdlIikgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0 aGUgYWRkcmVzc2Vlcy4gDQpBbnkgdW5hdXRob3Jpc2VkIHVzZSBvciBkaXNzZW1pbmF0aW9uIGlz IHByb2hpYml0ZWQuDQpNZXNzYWdlcyBhcmUgc3VzY2VwdGlibGUgdG8gYWx0ZXJhdGlvbi4gDQpG cmFuY2UgVGVsZWNvbSBHcm91cCBzaGFsbCBub3QgYmUgbGlhYmxlIGZvciB0aGUgbWVzc2FnZSBp ZiBhbHRlcmVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCklmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCBhZGRyZXNzZWUgb2YgdGhpcyBtZXNzYWdlLCBwbGVhc2UgY2FuY2VsIGl0IGltbWVkaWF0 ZWx5IGFuZCBpbmZvcm0gdGhlIHNlbmRlci4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpC ZWhhdmUgbWFpbGluZyBsaXN0DQpCZWhhdmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYmVoYXZl From mohamed.boucadair@orange-ftgroup.com Fri Oct 23 01:34:33 2009 Return-Path: <mohamed.boucadair@orange-ftgroup.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 2D9033A6808 for <behave@core3.amsl.com>; Fri, 23 Oct 2009 01:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 Oc65t0z2vEwe for <behave@core3.amsl.com>; Fri, 23 Oct 2009 01:34:32 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id ED3673A67F3 for <behave@ietf.org>; Fri, 23 Oct 2009 01:34:31 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id A55B33740DB; Fri, 23 Oct 2009 10:34:40 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 85DE2C808C; Fri, 23 Oct 2009 10:34:40 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Fri, 23 Oct 2009 10:34:40 +0200 From: <mohamed.boucadair@orange-ftgroup.com> To: Xuewei Wang <wangxuewei@huawei.com>, Christian Huitema <huitema@microsoft.com>, "teemu.savolainen@nokia.com" <teemu.savolainen@nokia.com>, "ajs@shinkuro.com" <ajs@shinkuro.com>, "behave@ietf.org" <behave@ietf.org> Date: Fri, 23 Oct 2009 10:34:39 +0200 Thread-Topic: [BEHAVE] draft-boucadair-behave-dns-a64-00.txt [was RE: I-DAction:draft-ietf-behave-dns64-01.txt] Thread-Index: AcpTuI+z+W9ykB8DTDCrVCIR85h1zgAAi9tw Message-ID: <11300_1256286880_4AE16AA0_11300_12706_1_94C682931C08B048B7A8645303FDC9F30781B15DD4@PUEXCB1B.nanterre.francetelecom.fr> References: <20091019180002.1AFBE3A692D@core3.amsl.com> <20091019181555.GC9536@shinkuro.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3EF10EF424@NOK-EUMSG-01.mgdnok.nokia.com> <6B55F0F93C3E9D45AF283313B8D342BA211C9BC9@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <23132_1256211881_4AE045A9_23132_13404_1_94C682931C08B048B7A8645303FDC9F30781B159F8@PUEXCB1B.nanterre.francetelecom.fr> <00d501ca53b8$8c491c90$6b0c6f0a@china.huawei.com> In-Reply-To: <00d501ca53b8$8c491c90$6b0c6f0a@china.huawei.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.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.10.23.74825 Cc: BURGEY Eric RD-CORE <eric.burgey@orange-ftgroup.com> Subject: Re: [BEHAVE] draft-boucadair-behave-dns-a64-00.txt [was RE: I-DAction:draft-ietf-behave-dns64-01.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: Fri, 23 Oct 2009 08:34:33 -0000 Dear Xuewei, all, The A64 proposal does not make any assumption about the type of the pref6 t= o be used. Both WKP and LIR prefixes are supported. We are currently updati= ng the draft to describe a mode in which an authoritative server can be upd= ated to support A64 (and therefore a LIR pref can be used). Cheers, Med=20 -----Message d'origine----- De : Xuewei Wang [mailto:wangxuewei@huawei.com]=20 Envoy=E9 : vendredi 23 octobre 2009 10:12 =C0 : BOUCADAIR Mohamed NCPI/NAD/TIP; Christian Huitema; teemu.savolainen@n= okia.com; ajs@shinkuro.com; behave@ietf.org Objet : [BEHAVE] draft-boucadair-behave-dns-a64-00.txt [was RE: I-DAction:d= raft-ietf-behave-dns64-01.txt] Hi, mohamed, I have noticed your new draft draft-boucadair-behave-dns-a64-00. If i unde= rstand it correctly this draft makes DNS server to add a new a64 RR to repr= esent an IPv4-mapped IPv6 addresses. Because the DNS server don't serve any= specific NAT64s, so the prefix64 which the DNS server uses to construct a6= 4 RR must be a Well-Known Prefix rather than a Network-Specific Prefix, is = my understand correct? Xuewei Wang ----- Original Message ----- From: <mohamed.boucadair@orange-ftgroup.com> To: "Christian Huitema" <huitema@microsoft.com>; <teemu.savolainen@nokia.co= m>; <ajs@shinkuro.com>; <behave@ietf.org> Sent: Thursday, October 22, 2009 7:44 PM Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt Dear Christian, all, FYI, we have submitted a draft to describe the A64 record for IPv4-mapped I= Pv6 addresses. An updated version of the draft will be submitted soon Title : A64: DNS Resource Record for IPv4-mapped IPv6 Address Author(s) : M. Boucadair, E. Burgey Filename : draft-boucadair-behave-dns-a64-00.txt Pages : 9 Date : 2009-10-18 In this context of IPv4-IPv6 interconnection, several solutions have been p= roposed. Some of these solutions require the definition of a new IPv4-mapp= ed IPv6 address [I-D.ietf-behave-address-format] which is used to represent= an IPv4-only host in an IPv6 realms and the definition of a new mechanism = called DNS64 for synthesizing a AAAA record, representing an IPv4-mapped IP= v6 address in the DNS system, from the A record representing the IPv4 addre= ss of the IPv4-only host [I-D.ietf-behave-dns64]. This IPv4-mapped IPv6 ad= dress, when managed by a translator, is to be considered as "fake" address = in a DNS system since it is not necessarily assigned to any host's interfac= e qualified by the associated name. This document defines a new DNS record= type and query type to identify IPv4-mapped IPv6 address [I-D.ietf-behave-= address-format] from native IPv6 ones. The new record type and query type = aim at helping the remote party to enforce its policies and avoid NAT64 box= es when possible. Native addresses are to be preferred. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boucadair-behave-dns-a64-00.txt Cheers, Med =20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Christian Huitema Envoy=E9 : mercredi 21 octobre 2009 18:40 =C0 : teemu.savolainen@nokia.com; ajs@shinkuro.com; behave@ietf.org Objet : Re: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt > The draft contains question about multihoming:"In particular, how is=20 > the multi-homed host supposed to know that a given AAAA is synthetic?". Wonder about that too. Isn't the best solution to create a new record type,= say A4A6, that would contain the mapped addresses of IPv4 only hosts? -- Christian Huitema _______________________________________________ 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. ******************************** _______________________________________________ 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 wangxuewei@huawei.com Fri Oct 23 01:57:00 2009 Return-Path: <wangxuewei@huawei.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 6938A3A68F9 for <behave@core3.amsl.com>; Fri, 23 Oct 2009 01:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.258 X-Spam-Level: * X-Spam-Status: No, score=1.258 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, 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 N2nWnh0uudWV for <behave@core3.amsl.com>; Fri, 23 Oct 2009 01:56:59 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 7EEC53A6768 for <behave@ietf.org>; Fri, 23 Oct 2009 01:56:54 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRY001QDM6UNE@szxga04-in.huawei.com> for behave@ietf.org; Fri, 23 Oct 2009 16:56:54 +0800 (CST) Received: from w00104636 ([10.111.12.107]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRY00CAEM6T78@szxga04-in.huawei.com> for behave@ietf.org; Fri, 23 Oct 2009 16:56:54 +0800 (CST) Date: Fri, 23 Oct 2009 16:56:53 +0800 From: Xuewei Wang <wangxuewei@huawei.com> To: mohamed.boucadair@orange-ftgroup.com, Christian Huitema <huitema@microsoft.com>, teemu.savolainen@nokia.com, ajs@shinkuro.com, behave@ietf.org Message-id: <011a01ca53be$c489b050$6b0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <20091019180002.1AFBE3A692D@core3.amsl.com> <20091019181555.GC9536@shinkuro.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3EF10EF424@NOK-EUMSG-01.mgdnok.nokia.com> <6B55F0F93C3E9D45AF283313B8D342BA211C9BC9@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <23132_1256211881_4AE045A9_23132_13404_1_94C682931C08B048B7A8645303FDC9F30781B159F8@PUEXCB1B.nanterre.francetelecom.fr> <00d501ca53b8$8c491c90$6b0c6f0a@china.huawei.com> <11300_1256286880_4AE16AA0_11300_12706_1_94C682931C08B048B7A8645303FDC9F30781B15DD4@PUEXCB1B.nanterre.francetelecom.fr> Cc: BURGEY Eric RD-CORE <eric.burgey@orange-ftgroup.com> Subject: Re: [BEHAVE] draft-boucadair-behave-dns-a64-00.txt [was RE: I-DAction:draft-ietf-behave-dns64-01.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: Fri, 23 Oct 2009 08:57:00 -0000 TG9va2luZyBmb3J3YXJkIHRvIHlvdXIgdXBkYXRpbmcgZHJhZnQgISANCg0KWHVld2VpIFdhbmcN Ci0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiA8bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLWZ0Z3JvdXAuY29tPg0KVG86ICJYdWV3ZWkgV2FuZyIgPHdhbmd4dWV3ZWlAaHVhd2Vp LmNvbT47ICJDaHJpc3RpYW4gSHVpdGVtYSIgPGh1aXRlbWFAbWljcm9zb2Z0LmNvbT47IDx0ZWVt dS5zYXZvbGFpbmVuQG5va2lhLmNvbT47IDxhanNAc2hpbmt1cm8uY29tPjsgPGJlaGF2ZUBpZXRm Lm9yZz4NCkNjOiAiQlVSR0VZIEVyaWMgUkQtQ09SRSIgPGVyaWMuYnVyZ2V5QG9yYW5nZS1mdGdy b3VwLmNvbT4NClNlbnQ6IEZyaWRheSwgT2N0b2JlciAyMywgMjAwOSA0OjM0IFBNDQpTdWJqZWN0 OiBSZTogW0JFSEFWRV0gZHJhZnQtYm91Y2FkYWlyLWJlaGF2ZS1kbnMtYTY0LTAwLnR4dCBbd2Fz IFJFOiBJLURBY3Rpb246ZHJhZnQtaWV0Zi1iZWhhdmUtZG5zNjQtMDEudHh0XQ0KDQoNCg0KRGVh ciBYdWV3ZWksIGFsbCwNCg0KVGhlIEE2NCBwcm9wb3NhbCBkb2VzIG5vdCBtYWtlIGFueSBhc3N1 bXB0aW9uIGFib3V0IHRoZSB0eXBlIG9mIHRoZSBwcmVmNiB0byBiZSB1c2VkLiBCb3RoIFdLUCBh bmQgTElSIHByZWZpeGVzIGFyZSBzdXBwb3J0ZWQuIFdlIGFyZSBjdXJyZW50bHkgdXBkYXRpbmcg dGhlIGRyYWZ0IHRvIGRlc2NyaWJlIGEgbW9kZSBpbiB3aGljaCBhbiBhdXRob3JpdGF0aXZlIHNl cnZlciBjYW4gYmUgdXBkYXRlZCB0byBzdXBwb3J0IEE2NCAoYW5kIHRoZXJlZm9yZSBhIExJUiBw cmVmIGNhbiBiZSB1c2VkKS4NCg0KQ2hlZXJzLA0KTWVkIA0KDQotLS0tLU1lc3NhZ2UgZCdvcmln aW5lLS0tLS0NCkRlIDogWHVld2VpIFdhbmcgW21haWx0bzp3YW5neHVld2VpQGh1YXdlaS5jb21d IA0KRW52b3npIDogdmVuZHJlZGkgMjMgb2N0b2JyZSAyMDA5IDEwOjEyDQrAIDogQk9VQ0FEQUlS IE1vaGFtZWQgTkNQSS9OQUQvVElQOyBDaHJpc3RpYW4gSHVpdGVtYTsgdGVlbXUuc2F2b2xhaW5l bkBub2tpYS5jb207IGFqc0BzaGlua3Vyby5jb207IGJlaGF2ZUBpZXRmLm9yZw0KT2JqZXQgOiBb QkVIQVZFXSBkcmFmdC1ib3VjYWRhaXItYmVoYXZlLWRucy1hNjQtMDAudHh0IFt3YXMgUkU6IEkt REFjdGlvbjpkcmFmdC1pZXRmLWJlaGF2ZS1kbnM2NC0wMS50eHRdDQoNCkhpLCBtb2hhbWVkLA0K SSBoYXZlIG5vdGljZWQgeW91ciBuZXcgZHJhZnQgZHJhZnQtYm91Y2FkYWlyLWJlaGF2ZS1kbnMt YTY0LTAwLiAgSWYgaSB1bmRlcnN0YW5kIGl0IGNvcnJlY3RseSB0aGlzIGRyYWZ0IG1ha2VzIERO UyBzZXJ2ZXIgdG8gYWRkIGEgbmV3IGE2NCBSUiB0byByZXByZXNlbnQgYW4gSVB2NC1tYXBwZWQg SVB2NiBhZGRyZXNzZXMuIEJlY2F1c2UgdGhlIEROUyBzZXJ2ZXIgZG9uJ3Qgc2VydmUgYW55IHNw ZWNpZmljIE5BVDY0cywgc28gdGhlIHByZWZpeDY0IHdoaWNoIHRoZSBETlMgc2VydmVyIHVzZXMg dG8gY29uc3RydWN0IGE2NCBSUiBtdXN0IGJlIGEgV2VsbC1Lbm93biBQcmVmaXggcmF0aGVyIHRo YW4gYSBOZXR3b3JrLVNwZWNpZmljIFByZWZpeCwgaXMgbXkgdW5kZXJzdGFuZCBjb3JyZWN0Pw0K DQoNClh1ZXdlaSBXYW5nDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiA8bW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLWZ0Z3JvdXAuY29tPg0KVG86ICJDaHJpc3RpYW4gSHVpdGVt YSIgPGh1aXRlbWFAbWljcm9zb2Z0LmNvbT47IDx0ZWVtdS5zYXZvbGFpbmVuQG5va2lhLmNvbT47 IDxhanNAc2hpbmt1cm8uY29tPjsgPGJlaGF2ZUBpZXRmLm9yZz4NClNlbnQ6IFRodXJzZGF5LCBP Y3RvYmVyIDIyLCAyMDA5IDc6NDQgUE0NClN1YmplY3Q6IFJlOiBbQkVIQVZFXSBJLUQgQWN0aW9u OmRyYWZ0LWlldGYtYmVoYXZlLWRuczY0LTAxLnR4dA0KDQoNCg0KRGVhciBDaHJpc3RpYW4sIGFs bCwNCg0KRllJLCB3ZSBoYXZlIHN1Ym1pdHRlZCBhIGRyYWZ0IHRvIGRlc2NyaWJlIHRoZSBBNjQg cmVjb3JkIGZvciBJUHY0LW1hcHBlZCBJUHY2IGFkZHJlc3Nlcy4gQW4gdXBkYXRlZCB2ZXJzaW9u IG9mIHRoZSBkcmFmdCB3aWxsIGJlIHN1Ym1pdHRlZCBzb29uDQoNClRpdGxlICAgICAgICAgICA6 IEE2NDogRE5TIFJlc291cmNlIFJlY29yZCBmb3IgSVB2NC1tYXBwZWQgSVB2NiBBZGRyZXNzDQpB dXRob3IocykgICAgICAgOiBNLiBCb3VjYWRhaXIsIEUuIEJ1cmdleQ0KRmlsZW5hbWUgICAgICAg IDogZHJhZnQtYm91Y2FkYWlyLWJlaGF2ZS1kbnMtYTY0LTAwLnR4dA0KUGFnZXMgICAgICAgICAg IDogOQ0KRGF0ZSAgICAgICAgICAgIDogMjAwOS0xMC0xOA0KDQpJbiB0aGlzIGNvbnRleHQgb2Yg SVB2NC1JUHY2IGludGVyY29ubmVjdGlvbiwgc2V2ZXJhbCBzb2x1dGlvbnMgaGF2ZSBiZWVuIHBy b3Bvc2VkLiAgU29tZSBvZiB0aGVzZSBzb2x1dGlvbnMgcmVxdWlyZSB0aGUgZGVmaW5pdGlvbiBv ZiBhIG5ldyBJUHY0LW1hcHBlZCBJUHY2IGFkZHJlc3MgW0ktRC5pZXRmLWJlaGF2ZS1hZGRyZXNz LWZvcm1hdF0gd2hpY2ggaXMgdXNlZCB0byByZXByZXNlbnQgYW4gSVB2NC1vbmx5IGhvc3QgaW4g YW4gSVB2NiByZWFsbXMgYW5kIHRoZSBkZWZpbml0aW9uIG9mIGEgbmV3IG1lY2hhbmlzbSBjYWxs ZWQgRE5TNjQgZm9yIHN5bnRoZXNpemluZyBhIEFBQUEgcmVjb3JkLCByZXByZXNlbnRpbmcgYW4g SVB2NC1tYXBwZWQgSVB2NiBhZGRyZXNzIGluIHRoZSBETlMgc3lzdGVtLCBmcm9tIHRoZSBBIHJl Y29yZCByZXByZXNlbnRpbmcgdGhlIElQdjQgYWRkcmVzcyBvZiB0aGUgSVB2NC1vbmx5IGhvc3Qg W0ktRC5pZXRmLWJlaGF2ZS1kbnM2NF0uICBUaGlzIElQdjQtbWFwcGVkIElQdjYgYWRkcmVzcywg d2hlbiBtYW5hZ2VkIGJ5IGEgdHJhbnNsYXRvciwgaXMgdG8gYmUgY29uc2lkZXJlZCBhcyAiZmFr ZSIgYWRkcmVzcyBpbiBhIEROUyBzeXN0ZW0gc2luY2UgaXQgaXMgbm90IG5lY2Vzc2FyaWx5IGFz c2lnbmVkIHRvIGFueSBob3N0J3MgaW50ZXJmYWNlIHF1YWxpZmllZCBieSB0aGUgYXNzb2NpYXRl ZCBuYW1lLiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IEROUyByZWNvcmQgdHlwZSBhbmQg cXVlcnkgdHlwZSB0byBpZGVudGlmeSBJUHY0LW1hcHBlZCBJUHY2IGFkZHJlc3MgW0ktRC5pZXRm LWJlaGF2ZS1hZGRyZXNzLWZvcm1hdF0gZnJvbSBuYXRpdmUgSVB2NiBvbmVzLiAgVGhlIG5ldyBy ZWNvcmQgdHlwZSBhbmQgcXVlcnkgdHlwZSBhaW0gYXQgaGVscGluZyB0aGUgcmVtb3RlIHBhcnR5 IHRvIGVuZm9yY2UgaXRzIHBvbGljaWVzIGFuZCBhdm9pZCBOQVQ2NCBib3hlcyB3aGVuIHBvc3Np YmxlLiAgTmF0aXZlIGFkZHJlc3NlcyBhcmUgdG8gYmUgcHJlZmVycmVkLg0KDQpBIFVSTCBmb3Ig dGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWJvdWNhZGFpci1iZWhhdmUtZG5zLWE2NC0wMC50eHQNCg0KDQpDaGVlcnMsDQpN ZWQNCg0KIA0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlIDogYmVoYXZlLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpiZWhhdmUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBk ZSBDaHJpc3RpYW4gSHVpdGVtYQ0KRW52b3npIDogbWVyY3JlZGkgMjEgb2N0b2JyZSAyMDA5IDE4 OjQwDQrAIDogdGVlbXUuc2F2b2xhaW5lbkBub2tpYS5jb207IGFqc0BzaGlua3Vyby5jb207IGJl aGF2ZUBpZXRmLm9yZw0KT2JqZXQgOiBSZTogW0JFSEFWRV0gSS1EIEFjdGlvbjpkcmFmdC1pZXRm LWJlaGF2ZS1kbnM2NC0wMS50eHQNCg0KPiBUaGUgZHJhZnQgY29udGFpbnMgcXVlc3Rpb24gYWJv dXQgbXVsdGlob21pbmc6IkluIHBhcnRpY3VsYXIsIGhvdyBpcyANCj4gdGhlIG11bHRpLWhvbWVk IGhvc3Qgc3VwcG9zZWQgdG8ga25vdyB0aGF0IGEgZ2l2ZW4gQUFBQSBpcyBzeW50aGV0aWM/Ii4N Cg0KV29uZGVyIGFib3V0IHRoYXQgdG9vLiBJc24ndCB0aGUgYmVzdCBzb2x1dGlvbiB0byBjcmVh dGUgYSBuZXcgcmVjb3JkIHR5cGUsIHNheSBBNEE2LCB0aGF0IHdvdWxkIGNvbnRhaW4gdGhlIG1h cHBlZCBhZGRyZXNzZXMgb2YgSVB2NCBvbmx5IGhvc3RzPw0KDQotLSBDaHJpc3RpYW4gSHVpdGVt YQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkJlaGF2ZSBtYWlsaW5nIGxpc3QNCkJlaGF2ZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9iZWhhdmUNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqDQpUaGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyAodGhlICJtZXNzYWdlIikg YXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2Vlcy4g DQpBbnkgdW5hdXRob3Jpc2VkIHVzZSBvciBkaXNzZW1pbmF0aW9uIGlzIHByb2hpYml0ZWQuDQpN ZXNzYWdlcyBhcmUgc3VzY2VwdGlibGUgdG8gYWx0ZXJhdGlvbi4gDQpGcmFuY2UgVGVsZWNvbSBH cm91cCBzaGFsbCBub3QgYmUgbGlhYmxlIGZvciB0aGUgbWVzc2FnZSBpZiBhbHRlcmVkLCBjaGFu Z2VkIG9yIGZhbHNpZmllZC4NCklmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBhZGRyZXNzZWUg b2YgdGhpcyBtZXNzYWdlLCBwbGVhc2UgY2FuY2VsIGl0IGltbWVkaWF0ZWx5IGFuZCBpbmZvcm0g dGhlIHNlbmRlci4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpCZWhhdmUgbWFpbGluZyBs aXN0DQpCZWhhdmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYmVoYXZlDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNClRoaXMgbWVzc2Fn ZSBhbmQgYW55IGF0dGFjaG1lbnRzICh0aGUgIm1lc3NhZ2UiKSBhcmUgY29uZmlkZW50aWFsIGFu ZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWVzLiANCkFueSB1bmF1dGhvcmlzZWQg dXNlIG9yIGRpc3NlbWluYXRpb24gaXMgcHJvaGliaXRlZC4NCk1lc3NhZ2VzIGFyZSBzdXNjZXB0 aWJsZSB0byBhbHRlcmF0aW9uLiANCkZyYW5jZSBUZWxlY29tIEdyb3VwIHNoYWxsIG5vdCBiZSBs aWFibGUgZm9yIHRoZSBtZXNzYWdlIGlmIGFsdGVyZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0K SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIGFkZHJlc3NlZSBvZiB0aGlzIG1lc3NhZ2UsIHBs ZWFzZSBjYW5jZWwgaXQgaW1tZWRpYXRlbHkgYW5kIGluZm9ybSB0aGUgc2VuZGVyLg0KKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkJlaGF2ZSBtYWlsaW5nIGxpc3QNCkJlaGF2ZUBpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZWhhdmU= From marcelo@it.uc3m.es Fri Oct 23 03:12:39 2009 Return-Path: <marcelo@it.uc3m.es> 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 E26693A6807 for <behave@core3.amsl.com>; Fri, 23 Oct 2009 03:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bur57PX+AnO6 for <behave@core3.amsl.com>; Fri, 23 Oct 2009 03:12:39 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id D953B3A6859 for <behave@ietf.org>; Fri, 23 Oct 2009 03:12:38 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp01.uc3m.es (Postfix) with ESMTP id 84205BA7995; Fri, 23 Oct 2009 12:12:47 +0200 (CEST) Message-ID: <4AE1819F.1010905@it.uc3m.es> Date: Fri, 23 Oct 2009 12:12:47 +0200 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dan Wing <dwing@cisco.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> In-Reply-To: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16964.003 Cc: =?UTF-8?B?J+WImOWkp+m5jyc=?= <liudapeng@chinamobile.com>, =?UTF-8?B?J+abueaMryc=?= <caozhen@chinamobile.com>, behave@ietf.org, 'Behave Chairs' <behave-chairs@tools.ietf.org> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 23 Oct 2009 10:12:40 -0000 I agree with adopting this doc as a WG item regards, marcelo Dan Wing escribió: > We are considering adopting draft-van-beijnum-behave-ftp64-06 as a WG document > to meet our milestone "Jan 2010 Submit to IESG: FTP ALG for IPv6/IPv4 > translation (std)", > http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-06 > > The author believes the document now incorporates all feedback. > > Please reply to the list. > -d > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From marcelo@it.uc3m.es Fri Oct 23 03:22:29 2009 Return-Path: <marcelo@it.uc3m.es> 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 11E1F3A6A25 for <behave@core3.amsl.com>; Fri, 23 Oct 2009 03:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRvLHeri-Odp for <behave@core3.amsl.com>; Fri, 23 Oct 2009 03:22:28 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 0222F3A6A0F for <behave@ietf.org>; Fri, 23 Oct 2009 03:22:27 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp01.uc3m.es (Postfix) with ESMTP id 9BE0FB4A36B; Fri, 23 Oct 2009 12:22:36 +0200 (CEST) Message-ID: <4AE183EC.1080504@it.uc3m.es> Date: Fri, 23 Oct 2009 12:22:36 +0200 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dan Wing <dwing@cisco.com> References: <20091019180002.1AFBE3A692D@core3.amsl.com><20091019181555.GC9536@shinkuro.com><18034D4D7FE9AE48BF19AB1B0EF2729F3EF10EF424@NOK-EUMSG-01.mgdnok.nokia.com><6B55F0F93C3E9D45AF283313B8D342BA211C9BC9@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <23132_1256211881_4AE045A9_23132_13404_1_94C682931C08B048B7A8645303FDC9F30781B159F8@PUEXCB1B.nanterre.francetelecom.fr> <02d401ca533a$4893ba10$5ba36b80@cisco.com> In-Reply-To: <02d401ca533a$4893ba10$5ba36b80@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16964.003 Cc: ajs@shinkuro.com, behave@ietf.org, draft-boucadair-behave-dns-a64@tools.ietf.org, mohamed.boucadair@orange-ftgroup.com Subject: Re: [BEHAVE] draft-boucadair-behave-dns-a64-00.txt [was RE: I-D Action:draft-ietf-behave-dns64-01.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: Fri, 23 Oct 2009 10:22:29 -0000 Dan Wing escribió: >> FYI, we have submitted a draft to describe the A64 record for >> IPv4-mapped IPv6 addresses. An updated version of the draft >> will be submitted soon >> > > draft-boucadair-behave-dns-a64-00 requires the DNS64 and the host to implement > a new DNS resource record, A64, in order to learn if the DNS64 synthesized a > response. > > Instead, have you considered just having the host query an > existing DNS64 with the CD and DO bits set (which disables the > DNS64's AAAA synthesis) and have the host do its own DNS64 > processing? See item #3 in > http://tools.ietf.org/html/draft-ietf-behave-dns64-01#section-5.5 > > If you have considered that technique, I expect you found some sort > of disadvantage to that technique. Please share. > I am not sure there would be an actual practical reason for not doing that, but from a purist point of view (in case it is not a contradiction in terms talking about purism and nats in the same sentence), i understand that we would be overloading the DO and CD bits if we do that. In particular, it would imply that you could not get the dns server to do the validation _and_ distinguish synthetic RR, i guess Regards, marcelo > -d > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From marcelo@it.uc3m.es Fri Oct 23 04:01:11 2009 Return-Path: <marcelo@it.uc3m.es> 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 C12053A67DF for <behave@core3.amsl.com>; Fri, 23 Oct 2009 04:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjE0iljwgq5Q for <behave@core3.amsl.com>; Fri, 23 Oct 2009 04:01:10 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 39FE03A62C1 for <behave@ietf.org>; Fri, 23 Oct 2009 04:01:10 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id 1517A6570B8; Fri, 23 Oct 2009 13:01:19 +0200 (CEST) Message-ID: <4AE18CFF.6010102@it.uc3m.es> Date: Fri, 23 Oct 2009 13:01:19 +0200 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dan Wing <dwing@cisco.com> References: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com><643AD0DC-5BD4-44BD-A206-D58A5F965F3A@muada.com><4ADEBAC7.4030202@it.uc3m.es><bcff0fba0910210722n4bcec955o1610b0e807a3596c@mail.gmail.com><026101ca5331$95fae070$5ba36b80@cisco.com><bcff0fba0910221020r64db8931o3a94abe9b30411e7@mail.gmail.com> <20091022175607.GC44604@shinkuro.com> <03e101ca534c$164faa20$5ba36b80@cisco.com> In-Reply-To: <03e101ca534c$164faa20$5ba36b80@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16964.003 Cc: 'Andrew Sullivan' <ajs@shinkuro.com>, behave@ietf.org Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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, 23 Oct 2009 11:01:11 -0000 Dan Wing escribió: > > > >> -----Original Message----- >> From: behave-bounces@ietf.org >> [mailto:behave-bounces@ietf.org] On Behalf Of Andrew Sullivan >> Sent: Thursday, October 22, 2009 10:56 AM >> To: behave@ietf.org >> Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 >> >> On Thu, Oct 22, 2009 at 10:20:13AM -0700, Cameron Byrne wrote: >> >> >>> This is why i am suggesting that the DNS64 have a hand in >>> >> either "dumb >> >>> round robin" or "intelligent NAT64 system aware" load sharing, since >>> DNS64 is assigning the PREF64 to the client resolver, it is >>> >> the driver >> >>> directing the load on the network / NAT64. This is an important >>> point. The DNS64 system drives the load to unique PREF64 / >>> >> NAT64 that >> >>> is hosted on a specific location in the network topology. >>> >> One of the >> >>> main advantages of DNS64/NAT64 is that it is not required to be part >>> of shortest path routing topology between the user and the content >>> like NAT-PT was, thus the entire system encourages and benefits from >>> NAT-free end to end IPv6 communication. The DNS64 / PREF64 >>> >> provides a >> >>> very elegant detour from the shortest path string of >>> >> routers and into >> >>> a NAT64 service specific / optimized node, only when NAT64 >>> >> is needed. >> >> This view is exactly how we got so much sludge from various local DNS >> systems leaking out onto the Internet. For instance, we have a _whole >> system_ (the AS112 system) of anycast name servers just to sink the >> traffic that used to arrive at the in-addr.arpa zone due to RFC 1918 >> address space allocations. The idea that these DNS answers are not >> going to leak, are not going to get out onto the wider Internet, and >> so on is completely fanciful. They will, and the only question is how >> we can arrange things so that they do the least damage. >> >> Therefore, the trickier the strategy one proposes for DNS64, the more >> my alarm bells ring. I think we want to take DNS64 for what it is -- >> a cute trick that allows us to make two completely different networks >> talk to one another -- and accept that, as all cute tricks, it has a >> number of limitations some of which will be, "Performance is rotten." >> Anything that smacks of DNS tricks that already break all over the >> place in the plain old DNS world (and that will break even more as >> DNSSEC gets turned on) sounds to me like the sort of trouble we >> shouldn't be borrowing. I'm aware that people are going to do those >> things, but if I have to give them the sort of advice that will really >> help them with deployment, my advice is "don't". >> > > > It's important that, as best we can, the public IPv4 address stay > the same for all translations by a client. Otherwise > some applications will break. FTP certainly breaks. Other > IP-based auth/authz systems break, too, and I am told some > websites use cookies that encode IP addresses. That's why > REQ-1 is written in > http://tools.ietf.org/html/draft-nishitani-cgn-02#section-3 > > If the DNS64 were to change the Prefix as a NAT64's load changed, > it would cause flows to take a different NAT64. If that different > NAT64 is not sharing state with other NAT64s, a different public > IPv4 address would be assigned. > > So, a safer approach is to load balance when the IPv6 address is > assigned, using DHCPv6 to assign a DNS64 to a host is safer, and > have that DNS64 always use the same Prefix for its synthesized > answers. This is a natural thing to do, anyway -- if you have > 5 NAT64 devices you want 20% of users to go to each one. So > 20% of your users are pointed to one DNS64, 20% to another > DNS64, and so on. Each DNS64 could, actually, be the same > DNS64 box -- which means for this scheme the DNS64 should use > the *destination* address of the arriving DNS query (rather > than source address) to decide which Prefix to use in the > synthesized response. right, this seems cleaner to me as well > Would that be reasonable to put into > the DNS64 spec? > > mmm, afaict this doens't change the spec at all. I think it may make sense to document reccomended deployment practices (with cool tricks like this one), but maybe in a separated BCP document? Regards, marcelo > -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 maxpassion@gmail.com Fri Oct 23 04:04:19 2009 Return-Path: <maxpassion@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 A41463A67DF for <behave@core3.amsl.com>; Fri, 23 Oct 2009 04:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oauxh8eESlu2 for <behave@core3.amsl.com>; Fri, 23 Oct 2009 04:04:18 -0700 (PDT) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id DAEA53A62C1 for <behave@ietf.org>; Fri, 23 Oct 2009 04:04:18 -0700 (PDT) Received: by pwi4 with SMTP id 4so2109521pwi.29 for <behave@ietf.org>; Fri, 23 Oct 2009 04:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=PjWWaF9yMji+kZOEfqZZcel/ubE5J8tw19pHgLImrpY=; b=cyuf8PO5G/fDwAqLb6domRCnfIxutgSsGuZf6QHIuvrFDOlehaS2UySPp6z7NovZFE YS7Up8Am0AyGbmzHKQ9HTraYIKAhduMyqTjkjBISwCyw/8ItcIaNmHH0PfMQW2QlIKNb qVZI3H4iKFVFLlbqY01rdrC7yvvn1jGYsneys= 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=JCTOWxoid18T4vkzcqfOjnP2DS4cN5ucyYCpfDySkQOLxtKn4pCoaEqIwVeGSfgdfj P5rD5ICDDIPbtM/+LpGkWU9dLE4ZlwFmKhb9pgbDm3P2lIgLKCmsZCGqBh7tvc9Q4nWM sA8SnElEcP24DC1Y3FLdSrEwiuk5ErpcI8KUQ= MIME-Version: 1.0 Received: by 10.143.25.39 with SMTP id c39mr864380wfj.10.1256295866041; Fri, 23 Oct 2009 04:04:26 -0700 (PDT) In-Reply-To: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> Date: Fri, 23 Oct 2009 19:04:26 +0800 Message-ID: <25e1aaa40910230404m4517c64ew2a04e610cc6f2bcd@mail.gmail.com> From: liu dapeng <maxpassion@gmail.com> To: Dan Wing <dwing@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: =?GB2312?B?wfW088X0?= <liudapeng@chinamobile.com>, =?GB2312?B?stzV8Q==?= <caozhen@chinamobile.com>, behave@ietf.org, Behave Chairs <behave-chairs@tools.ietf.org> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 23 Oct 2009 11:04:19 -0000 We know that there are two drafts discussing the ftp64 issue. Would the WG consider merging draft-van-beijnum-behave-ftp64 and draft-liu-behave-ftp64 as the WG document? BR, Dapeng Liu 2009/10/23, Dan Wing <dwing@cisco.com>: > We are considering adopting draft-van-beijnum-behave-ftp64-06 as a WG > document > to meet our milestone "Jan 2010 Submit to IESG: FTP ALG for IPv6/IPv4 > translation (std)", > http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-06 > > The author believes the document now incorporates all feedback. > > Please reply to the list. > -d > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From iljitsch@muada.com Fri Oct 23 04:11:06 2009 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 A21EC3A68B0 for <behave@core3.amsl.com>; Fri, 23 Oct 2009 04:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8EcAsdgik7J for <behave@core3.amsl.com>; Fri, 23 Oct 2009 04:11:05 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 98EDB3A68A7 for <behave@ietf.org>; Fri, 23 Oct 2009 04:11:05 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.216]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n9NBA3vA097904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 23 Oct 2009 13:10:03 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <25e1aaa40910230404m4517c64ew2a04e610cc6f2bcd@mail.gmail.com> Date: Fri, 23 Oct 2009 13:10:31 +0200 Content-Transfer-Encoding: 7bit Message-Id: <D1DA2BB2-E064-4656-B75A-A10339A1B9FB@muada.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> <25e1aaa40910230404m4517c64ew2a04e610cc6f2bcd@mail.gmail.com> To: liu dapeng <maxpassion@gmail.com> X-Mailer: Apple Mail (2.1076) Cc: =?utf-8?B?5YiY5aSn6bmP?= <liudapeng@chinamobile.com>, =?utf-8?B?5pu55oyv?= <caozhen@chinamobile.com>, behave@ietf.org, Behave Chairs <behave-chairs@tools.ietf.org>, Dan Wing <dwing@cisco.com> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 23 Oct 2009 11:11:06 -0000 On 23 okt 2009, at 13:04, liu dapeng wrote: > We know that there are two drafts discussing the ftp64 issue. Would > the WG consider merging draft-van-beijnum-behave-ftp64 and > draft-liu-behave-ftp64 as the WG document? Do you feel the current text in draft-van-beijnum-behave-ftp64-06 doesn't address your previous objections? From marcelo@it.uc3m.es Fri Oct 23 04:13:44 2009 Return-Path: <marcelo@it.uc3m.es> 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 7ED153A68A7 for <behave@core3.amsl.com>; Fri, 23 Oct 2009 04:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gt-hlksH0tZo for <behave@core3.amsl.com>; Fri, 23 Oct 2009 04:13:43 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id F11933A68A5 for <behave@ietf.org>; Fri, 23 Oct 2009 04:13:42 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp03.uc3m.es (Postfix) with ESMTP id 2952D72E14F; Fri, 23 Oct 2009 13:13:51 +0200 (CEST) Message-ID: <4AE18FEE.3000706@it.uc3m.es> Date: Fri, 23 Oct 2009 13:13:50 +0200 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com References: <20091019180002.1AFBE3A692D@core3.amsl.com> <20091019181555.GC9536@shinkuro.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3EF10EF424@NOK-EUMSG-01.mgdnok.nokia.com> <6B55F0F93C3E9D45AF283313B8D342BA211C9BC9@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <23132_1256211881_4AE045A9_23132_13404_1_94C682931C08B048B7A8645303FDC9F30781B159F8@PUEXCB1B.nanterre.francetelecom.fr> <00d501ca53b8$8c491c90$6b0c6f0a@china.huawei.com> <11300_1256286880_4AE16AA0_11300_12706_1_94C682931C08B048B7A8645303FDC9F30781B15DD4@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <11300_1256286880_4AE16AA0_11300_12706_1_94C682931C08B048B7A8645303FDC9F30781B15DD4@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16964.003 Cc: Xuewei Wang <wangxuewei@huawei.com>, "behave@ietf.org" <behave@ietf.org>, "ajs@shinkuro.com" <ajs@shinkuro.com>, BURGEY Eric RD-CORE <eric.burgey@orange-ftgroup.com> Subject: Re: [BEHAVE] draft-boucadair-behave-dns-a64-00.txt [was RE: I-DAction:draft-ietf-behave-dns64-01.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: Fri, 23 Oct 2009 11:13:44 -0000 actually, i guess it makes more sense for the NSP prefix than for the WK = prefix, since synthetic RR containing addresses witht he WKP can be=20 distinguished by the WKP, i guess Regards, marcelo mohamed.boucadair@orange-ftgroup.com escribi=F3: > Dear Xuewei, all, > > The A64 proposal does not make any assumption about the type of the pre= f6 to be used. Both WKP and LIR prefixes are supported. We are currently = updating the draft to describe a mode in which an authoritative server ca= n be updated to support A64 (and therefore a LIR pref can be used). > > Cheers, > Med=20 > > -----Message d'origine----- > De : Xuewei Wang [mailto:wangxuewei@huawei.com]=20 > Envoy=E9 : vendredi 23 octobre 2009 10:12 > =C0 : BOUCADAIR Mohamed NCPI/NAD/TIP; Christian Huitema; teemu.savolain= en@nokia.com; ajs@shinkuro.com; behave@ietf.org > Objet : [BEHAVE] draft-boucadair-behave-dns-a64-00.txt [was RE: I-DActi= on:draft-ietf-behave-dns64-01.txt] > > Hi, mohamed, > I have noticed your new draft draft-boucadair-behave-dns-a64-00. If i = understand it correctly this draft makes DNS server to add a new a64 RR t= o represent an IPv4-mapped IPv6 addresses. Because the DNS server don't s= erve any specific NAT64s, so the prefix64 which the DNS server uses to co= nstruct a64 RR must be a Well-Known Prefix rather than a Network-Specific= Prefix, is my understand correct? > > > Xuewei Wang > ----- Original Message ----- > From: <mohamed.boucadair@orange-ftgroup.com> > To: "Christian Huitema" <huitema@microsoft.com>; <teemu.savolainen@noki= a.com>; <ajs@shinkuro.com>; <behave@ietf.org> > Sent: Thursday, October 22, 2009 7:44 PM > Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt > > > > Dear Christian, all, > > FYI, we have submitted a draft to describe the A64 record for IPv4-mapp= ed IPv6 addresses. An updated version of the draft will be submitted soon= > > Title : A64: DNS Resource Record for IPv4-mapped IPv6 Address= > Author(s) : M. Boucadair, E. Burgey > Filename : draft-boucadair-behave-dns-a64-00.txt > Pages : 9 > Date : 2009-10-18 > > In this context of IPv4-IPv6 interconnection, several solutions have be= en proposed. Some of these solutions require the definition of a new IPv= 4-mapped IPv6 address [I-D.ietf-behave-address-format] which is used to r= epresent an IPv4-only host in an IPv6 realms and the definition of a new = mechanism called DNS64 for synthesizing a AAAA record, representing an IP= v4-mapped IPv6 address in the DNS system, from the A record representing = the IPv4 address of the IPv4-only host [I-D.ietf-behave-dns64]. This IPv= 4-mapped IPv6 address, when managed by a translator, is to be considered = as "fake" address in a DNS system since it is not necessarily assigned to= any host's interface qualified by the associated name. This document de= fines a new DNS record type and query type to identify IPv4-mapped IPv6 a= ddress [I-D.ietf-behave-address-format] from native IPv6 ones. The new r= ecord type and query type aim at helping the remote party to enforce its = policies and avoid NAT64 boxes when possible. Native addresses are to be= preferred. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-boucadair-behave-dns-a64-00.t= xt > > > Cheers, > Med > > =20 > > -----Message d'origine----- > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la par= t de Christian Huitema > Envoy=E9 : mercredi 21 octobre 2009 18:40 > =C0 : teemu.savolainen@nokia.com; ajs@shinkuro.com; behave@ietf.org > Objet : Re: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt > > =20 >> The draft contains question about multihoming:"In particular, how is=20 >> the multi-homed host supposed to know that a given AAAA is synthetic?"= =2E >> =20 > > Wonder about that too. Isn't the best solution to create a new record t= ype, say A4A6, that would contain the mapped addresses of IPv4 only hosts= ? > > -- Christian Huitema > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > ********************************* > This message and any attachments (the "message") are confidential and i= ntended 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, ch= anged or falsified. > If you are not the intended addressee of this message, please cancel it= immediately and inform the sender. > ******************************** > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > ********************************* > This message and any attachments (the "message") are confidential and i= ntended 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, ch= anged or falsified. > If you are not the intended addressee of this message, please cancel it= immediately and inform the sender. > ******************************** > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > =20 From ajs@shinkuro.com Fri Oct 23 07:15:10 2009 Return-Path: <ajs@shinkuro.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 5AC9F3A6851 for <behave@core3.amsl.com>; Fri, 23 Oct 2009 07:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.659, 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 QqKkxZ8XeqXx for <behave@core3.amsl.com>; Fri, 23 Oct 2009 07:15:09 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 9FF133A683E for <behave@ietf.org>; Fri, 23 Oct 2009 07:15:09 -0700 (PDT) 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 372322FE8CDC for <behave@ietf.org>; Fri, 23 Oct 2009 14:15:16 +0000 (UTC) Date: Fri, 23 Oct 2009 10:15:14 -0400 From: Andrew Sullivan <ajs@shinkuro.com> To: behave@ietf.org Message-ID: <20091023141514.GE52439@shinkuro.com> References: <20091022175607.GC44604@shinkuro.com> <03e101ca534c$164faa20$5ba36b80@cisco.com> <4AE18CFF.6010102@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AE18CFF.6010102@it.uc3m.es> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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, 23 Oct 2009 14:15:10 -0000 On Fri, Oct 23, 2009 at 01:01:19PM +0200, marcelo bagnulo braun wrote: > > I think it may make sense to document reccomended deployment practices > (with cool tricks like this one), but maybe in a separated BCP document? I think this is a really good idea. Actual operation of a protocol is quite a bit different from the definition of the protocol. I think it would be nice to avoid adding a lot of operational scenarios to the DNS64 document, partly because I don't believe we completely understand how it's really going to be used (and usable) in practice, except that we know some things will break for sure. Would it be acceptable to push ahead with just the definition of the service first, and then create a later document describing how everything might be used? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ajs@shinkuro.com Fri Oct 23 07:28:57 2009 Return-Path: <ajs@shinkuro.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 A82FB3A67E1 for <behave@core3.amsl.com>; Fri, 23 Oct 2009 07:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.632, 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 LGwwqHly57Gp for <behave@core3.amsl.com>; Fri, 23 Oct 2009 07:28:56 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id D07663A67D9 for <behave@ietf.org>; Fri, 23 Oct 2009 07:28:56 -0700 (PDT) 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 073C62FE8CDC for <behave@ietf.org>; Fri, 23 Oct 2009 14:29:06 +0000 (UTC) Date: Fri, 23 Oct 2009 10:29:05 -0400 From: Andrew Sullivan <ajs@shinkuro.com> To: behave@ietf.org Message-ID: <20091023142905.GF52439@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [BEHAVE] DNS64 and CNAME/DNAME 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, 23 Oct 2009 14:28:57 -0000 Dear colleagues, When planning to make the changes we discussed at the interim, I realised we have another issue that's currently not quite right. We cover the case where the AAAA gets an error, and empty answer, or AAAA in the answer, but we don't discuss the case where the answer comes back as a CNAME or DNAME. I propose the following text: If the response contains a CNAME or a DNAME, then the CNAME or DNAME chain is followed until the first terminating A or AAAA record is reached. This may require the DNS64 to ask for an A record, in case the response to the original AAAA query is a CNAME or DNAME without an AAAA record to follow. The resulting AAAA or A record is treated like any other AAAA or A case, as appropriate. When assembling the answer section, the original CNAME or DNAME RR is included as part of the answer, and the synthetic AAAA, if appropriate, is included. Ok? The idea here is that we don't want to hand back a CNAME answer with only an A in it, because the end node will not be able to use it. So we do various queries until we get an address we can either pass back unchanged, or an address that we can use as the basis for synthesis. The alternative, I suppose, is to return to the client the CNAME or DNAME answer to the AAAA answer, without any address data if there's no AAAA record or if the AAAA is in the exclusion set that we determined on Wednesday we want to add. Thoughts? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dwing@cisco.com Fri Oct 23 07:44:57 2009 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 9F4F13A6811 for <behave@core3.amsl.com>; Fri, 23 Oct 2009 07:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.331 X-Spam-Level: X-Spam-Status: No, score=-6.331 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBfLj6wIuPv6 for <behave@core3.amsl.com>; Fri, 23 Oct 2009 07:44:56 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 1ED183A6851 for <behave@ietf.org>; Fri, 23 Oct 2009 07:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5672; q=dns/txt; s=sjiport03001; t=1256309106; x=1257518706; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Dan=20Wing"=20<dwing@cisco.com>|Subject:=20RE: =20[BEHAVE]=20Using=20DNS64=20to=20load=20balance=20to=20 NAT64|Date:=20Fri,=2023=20Oct=202009=2007:45:05=20-0700 |Message-ID:=20<091901ca53ef$690c8dc0$5ba36b80@cisco.com> |To:=20"'marcelo=20bagnulo=20braun'"=20<marcelo@it.uc3m.e s>|Cc:=20"'Andrew=20Sullivan'"=20<ajs@shinkuro.com>,=20<b ehave@ietf.org>|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<4AE18CFF.6010102@it.uc3m.es>|References: =20<bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gma il.com><643AD0DC-5BD4-44BD-A206-D58A5F965F3A@muada.com><4 ADEBAC7.4030202@it.uc3m.es><bcff0fba0910210722n4bcec955o1 610b0e807a3596c@mail.gmail.com><026101ca5331$95fae070$5ba 36b80@cisco.com><bcff0fba0910221020r64db8931o3a94abe9b304 11e7@mail.gmail.com>=09<20091022175607.GC44604@shinkuro.c om>=20<03e101ca534c$164faa20$5ba36b80@cisco.com>=20<4AE18 CFF.6010102@it.uc3m.es>; bh=nRCTyWj0lb2iGQw41/Dv9jDMn4Zc5DPYKOPWT8oWsA0=; b=fh7N3C/e6tZQyOwWe/01RmCfxDpS/A2ZRCBKKMY6FItmRSi/soZxiyJC +yr/+BnKPxWOFoVdV4PoDpaduTAlQBVh0sIZGjHDJZ/bd/RJ5C1yHDfom Lja2PTrf6cI3gyQB5CLH9x19iLVy2ZzPrEyppf32Bvl2WuV/3+TSX22Zt Q=; Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAFVe4UqrR7H+/2dsb2JhbACKX7Y1mD6EPwSBXQ X-IronPort-AV: E=Sophos;i="4.44,612,1249257600"; d="scan'208";a="198519338" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 23 Oct 2009 14:45:05 +0000 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9NEj5VD029196; Fri, 23 Oct 2009 14:45:05 GMT From: "Dan Wing" <dwing@cisco.com> To: "'marcelo bagnulo braun'" <marcelo@it.uc3m.es> References: <bcff0fba0910192301w6cac213fl7109154d86f52480@mail.gmail.com><643AD0DC-5BD4-44BD-A206-D58A5F965F3A@muada.com><4ADEBAC7.4030202@it.uc3m.es><bcff0fba0910210722n4bcec955o1610b0e807a3596c@mail.gmail.com><026101ca5331$95fae070$5ba36b80@cisco.com><bcff0fba0910221020r64db8931o3a94abe9b30411e7@mail.gmail.com> <20091022175607.GC44604@shinkuro.com> <03e101ca534c$164faa20$5ba36b80@cisco.com> <4AE18CFF.6010102@it.uc3m.es> Date: Fri, 23 Oct 2009 07:45:05 -0700 Message-ID: <091901ca53ef$690c8dc0$5ba36b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcpT0C77TfodFAcCSBy9FFiCzfSNgAAHyncg In-Reply-To: <4AE18CFF.6010102@it.uc3m.es> Cc: 'Andrew Sullivan' <ajs@shinkuro.com>, behave@ietf.org Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 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, 23 Oct 2009 14:44:57 -0000 =20 > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > Sent: Friday, October 23, 2009 4:01 AM > To: Dan Wing > Cc: 'Andrew Sullivan'; behave@ietf.org > Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 >=20 > Dan Wing escribi=F3: > > =20 > > > > =20 > >> -----Original Message----- > >> From: behave-bounces@ietf.org=20 > >> [mailto:behave-bounces@ietf.org] On Behalf Of Andrew Sullivan > >> Sent: Thursday, October 22, 2009 10:56 AM > >> To: behave@ietf.org > >> Subject: Re: [BEHAVE] Using DNS64 to load balance to NAT64 > >> > >> On Thu, Oct 22, 2009 at 10:20:13AM -0700, Cameron Byrne wrote: > >> =20 > >> =20 > >>> This is why i am suggesting that the DNS64 have a hand in=20 > >>> =20 > >> either "dumb > >> =20 > >>> round robin" or "intelligent NAT64 system aware" load=20 > sharing, since > >>> DNS64 is assigning the PREF64 to the client resolver, it is=20 > >>> =20 > >> the driver > >> =20 > >>> directing the load on the network / NAT64. This is an important > >>> point. The DNS64 system drives the load to unique PREF64 /=20 > >>> =20 > >> NAT64 that > >> =20 > >>> is hosted on a specific location in the network topology. =20 > >>> =20 > >> One of the > >> =20 > >>> main advantages of DNS64/NAT64 is that it is not required=20 > to be part > >>> of shortest path routing topology between the user and the content > >>> like NAT-PT was, thus the entire system encourages and=20 > benefits from > >>> NAT-free end to end IPv6 communication. The DNS64 / PREF64=20 > >>> =20 > >> provides a > >> =20 > >>> very elegant detour from the shortest path string of=20 > >>> =20 > >> routers and into > >> =20 > >>> a NAT64 service specific / optimized node, only when NAT64=20 > >>> =20 > >> is needed. > >> > >> This view is exactly how we got so much sludge from=20 > various local DNS > >> systems leaking out onto the Internet. For instance, we=20 > have a _whole > >> system_ (the AS112 system) of anycast name servers just to sink the > >> traffic that used to arrive at the in-addr.arpa zone due=20 > to RFC 1918 > >> address space allocations. The idea that these DNS answers are not > >> going to leak, are not going to get out onto the wider=20 > Internet, and > >> so on is completely fanciful. They will, and the only=20 > question is how > >> we can arrange things so that they do the least damage. > >> > >> Therefore, the trickier the strategy one proposes for=20 > DNS64, the more > >> my alarm bells ring. I think we want to take DNS64 for=20 > what it is -- > >> a cute trick that allows us to make two completely=20 > different networks > >> talk to one another -- and accept that, as all cute=20 > tricks, it has a > >> number of limitations some of which will be, "Performance=20 > is rotten." > >> Anything that smacks of DNS tricks that already break all over the > >> place in the plain old DNS world (and that will break even more as > >> DNSSEC gets turned on) sounds to me like the sort of trouble we > >> shouldn't be borrowing. I'm aware that people are going=20 > to do those > >> things, but if I have to give them the sort of advice that=20 > will really > >> help them with deployment, my advice is "don't". > >> =20 > > > > > > It's important that, as best we can, the public IPv4 address stay > > the same for all translations by a client. Otherwise=20 > > some applications will break. FTP certainly breaks. Other=20 > > IP-based auth/authz systems break, too, and I am told some=20 > > websites use cookies that encode IP addresses. That's why=20 > > REQ-1 is written in=20 > > http://tools.ietf.org/html/draft-nishitani-cgn-02#section-3 > > > > If the DNS64 were to change the Prefix as a NAT64's load changed, > > it would cause flows to take a different NAT64. If that different > > NAT64 is not sharing state with other NAT64s, a different public > > IPv4 address would be assigned. > > > > So, a safer approach is to load balance when the IPv6 address is > > assigned, using DHCPv6 to assign a DNS64 to a host is safer, and=20 > > have that DNS64 always use the same Prefix for its synthesized=20 > > answers. This is a natural thing to do, anyway -- if you have=20 > > 5 NAT64 devices you want 20% of users to go to each one. So=20 > > 20% of your users are pointed to one DNS64, 20% to another=20 > > DNS64, and so on. Each DNS64 could, actually, be the same=20 > > DNS64 box -- which means for this scheme the DNS64 should use=20 > > the *destination* address of the arriving DNS query (rather=20 > > than source address) to decide which Prefix to use in the=20 > > synthesized response.=20 > right, this seems cleaner to me as well >=20 > > Would that be reasonable to put into > > the DNS64 spec? > > mmm, afaict this doens't change the spec at all. Agreed. > I think it may make sense to document reccomended deployment=20 > practices (with cool tricks like this one), but maybe in=20 > a separated BCP document? That sounds reasonable. -d > Regards, marcelo >=20 >=20 >=20 >=20 > > -d > > > > > > =20 > >> A > >> > >> --=20 > >> Andrew Sullivan > >> ajs@shinkuro.com > >> Shinkuro, Inc. > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www.ietf.org/mailman/listinfo/behave > >> =20 > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > > > =20 >=20 From ajs@shinkuro.com Fri Oct 23 08:19:39 2009 Return-Path: <ajs@shinkuro.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 697823A6821 for <behave@core3.amsl.com>; Fri, 23 Oct 2009 08:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[AWL=0.607, 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 vx0M5zsAd8Hq for <behave@core3.amsl.com>; Fri, 23 Oct 2009 08:19:37 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id A83C93A6800 for <behave@ietf.org>; Fri, 23 Oct 2009 08:19:35 -0700 (PDT) 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 BF33B2FE8CDC for <behave@ietf.org>; Fri, 23 Oct 2009 15:19:45 +0000 (UTC) Date: Fri, 23 Oct 2009 11:19:44 -0400 From: Andrew Sullivan <ajs@shinkuro.com> To: behave@ietf.org Message-ID: <20091023151943.GH52439@shinkuro.com> References: <20091023142905.GF52439@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091023142905.GF52439@shinkuro.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] DNS64 and CNAME/DNAME 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, 23 Oct 2009 15:19:39 -0000 Also, I should have mentioned that I'm keen to make the Monday deadline, so unless I hear objections I'll plan to go ahead with this. Best, A On Fri, Oct 23, 2009 at 10:29:05AM -0400, Andrew Sullivan wrote: > Dear colleagues, > > When planning to make the changes we discussed at the interim, I > realised we have another issue that's currently not quite right. > > We cover the case where the AAAA gets an error, and empty answer, or > AAAA in the answer, but we don't discuss the case where the answer > comes back as a CNAME or DNAME. I propose the following text: > > If the response contains a CNAME or a DNAME, then the CNAME or > DNAME chain is followed until the first terminating A or AAAA > record is reached. This may require the DNS64 to ask for an A > record, in case the response to the original AAAA query is a CNAME > or DNAME without an AAAA record to follow. The resulting AAAA or > A record is treated like any other AAAA or A case, as appropriate. > > > When assembling the answer section, the original CNAME or DNAME > RR is included as part of the answer, and the synthetic AAAA, if > appropriate, is included. > > Ok? The idea here is that we don't want to hand back a CNAME answer > with only an A in it, because the end node will not be able to use it. > So we do various queries until we get an address we can either pass > back unchanged, or an address that we can use as the basis for > synthesis. The alternative, I suppose, is to return to the client the > CNAME or DNAME answer to the AAAA answer, without any address data if > there's no AAAA record or if the AAAA is in the exclusion set that we > determined on Wednesday we want to add. > > Thoughts? > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From mohamed.boucadair@orange-ftgroup.com Fri Oct 23 08:37:08 2009 Return-Path: <mohamed.boucadair@orange-ftgroup.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 A7B593A693C for <behave@core3.amsl.com>; Fri, 23 Oct 2009 08:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 D3scTQ9q2nPZ for <behave@core3.amsl.com>; Fri, 23 Oct 2009 08:37:07 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 4116D3A6904 for <behave@ietf.org>; Fri, 23 Oct 2009 08:37:07 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 2393D13407A; Fri, 23 Oct 2009 17:37:17 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 00DCA27C037; Fri, 23 Oct 2009 17:37:17 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Fri, 23 Oct 2009 17:37:16 +0200 From: <mohamed.boucadair@orange-ftgroup.com> To: marcelo bagnulo braun <marcelo@it.uc3m.es> Date: Fri, 23 Oct 2009 17:37:15 +0200 Thread-Topic: [BEHAVE] draft-boucadair-behave-dns-a64-00.txt [was RE: I-DAction:draft-ietf-behave-dns64-01.txt] Thread-Index: AcpT0edZqm9r97shQjW1Gz/OEMbGaQAJAEGg Message-ID: <22138_1256312237_4AE1CDAD_22138_2570_1_94C682931C08B048B7A8645303FDC9F30781B16107@PUEXCB1B.nanterre.francetelecom.fr> References: <20091019180002.1AFBE3A692D@core3.amsl.com> <20091019181555.GC9536@shinkuro.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3EF10EF424@NOK-EUMSG-01.mgdnok.nokia.com> <6B55F0F93C3E9D45AF283313B8D342BA211C9BC9@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <23132_1256211881_4AE045A9_23132_13404_1_94C682931C08B048B7A8645303FDC9F30781B159F8@PUEXCB1B.nanterre.francetelecom.fr> <00d501ca53b8$8c491c90$6b0c6f0a@china.huawei.com> <11300_1256286880_4AE16AA0_11300_12706_1_94C682931C08B048B7A8645303FDC9F30781B15DD4@PUEXCB1B.nanterre.francetelecom.fr> <4AE18FEE.3000706@it.uc3m.es> In-Reply-To: <4AE18FEE.3000706@it.uc3m.es> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR x-tm-as-product-ver: SMEX-8.0.0.1259-5.600.1016-16638.006 x-tm-as-result: No--51.791600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.10.23.144819 Cc: Xuewei Wang <wangxuewei@huawei.com>, "behave@ietf.org" <behave@ietf.org>, "ajs@shinkuro.com" <ajs@shinkuro.com>, BURGEY Eric RD-CORE <eric.burgey@orange-ftgroup.com> Subject: Re: [BEHAVE] draft-boucadair-behave-dns-a64-00.txt [was RE: I-DAction:draft-ietf-behave-dns64-01.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: Fri, 23 Oct 2009 15:37:08 -0000 Dear Marcelo, all, Agreed.=20 Cheers, Med =20 -----Message d'origine----- De : marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 Envoy=E9 : vendredi 23 octobre 2009 13:14 =C0 : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : Xuewei Wang; Christian Huitema; teemu.savolainen@nokia.com; ajs@shinku= ro.com; behave@ietf.org; BURGEY Eric RD-CORE Objet : Re: [BEHAVE] draft-boucadair-behave-dns-a64-00.txt [was RE: I-DActi= on:draft-ietf-behave-dns64-01.txt] actually, i guess it makes more sense for the NSP prefix than for the WK pr= efix, since synthetic RR containing addresses witht he WKP can be distingui= shed by the WKP, i guess Regards, marcelo mohamed.boucadair@orange-ftgroup.com escribi=F3: > Dear Xuewei, all, > > The A64 proposal does not make any assumption about the type of the pref6= to be used. Both WKP and LIR prefixes are supported. We are currently upda= ting the draft to describe a mode in which an authoritative server can be u= pdated to support A64 (and therefore a LIR pref can be used). > > Cheers, > Med > > -----Message d'origine----- > De : Xuewei Wang [mailto:wangxuewei@huawei.com] Envoy=E9 : vendredi 23=20 > octobre 2009 10:12 =C0 : BOUCADAIR Mohamed NCPI/NAD/TIP; Christian=20 > Huitema; teemu.savolainen@nokia.com; ajs@shinkuro.com; behave@ietf.org=20 > Objet : [BEHAVE] draft-boucadair-behave-dns-a64-00.txt [was RE:=20 > I-DAction:draft-ietf-behave-dns64-01.txt] > > Hi, mohamed, > I have noticed your new draft draft-boucadair-behave-dns-a64-00. If i un= derstand it correctly this draft makes DNS server to add a new a64 RR to re= present an IPv4-mapped IPv6 addresses. Because the DNS server don't serve a= ny specific NAT64s, so the prefix64 which the DNS server uses to construct = a64 RR must be a Well-Known Prefix rather than a Network-Specific Prefix, i= s my understand correct? > > > Xuewei Wang > ----- Original Message ----- > From: <mohamed.boucadair@orange-ftgroup.com> > To: "Christian Huitema" <huitema@microsoft.com>;=20 > <teemu.savolainen@nokia.com>; <ajs@shinkuro.com>; <behave@ietf.org> > Sent: Thursday, October 22, 2009 7:44 PM > Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt > > > > Dear Christian, all, > > FYI, we have submitted a draft to describe the A64 record for=20 > IPv4-mapped IPv6 addresses. An updated version of the draft will be=20 > submitted soon > > Title : A64: DNS Resource Record for IPv4-mapped IPv6 Address > Author(s) : M. Boucadair, E. Burgey > Filename : draft-boucadair-behave-dns-a64-00.txt > Pages : 9 > Date : 2009-10-18 > > In this context of IPv4-IPv6 interconnection, several solutions have been= proposed. Some of these solutions require the definition of a new IPv4-ma= pped IPv6 address [I-D.ietf-behave-address-format] which is used to represe= nt an IPv4-only host in an IPv6 realms and the definition of a new mechanis= m called DNS64 for synthesizing a AAAA record, representing an IPv4-mapped = IPv6 address in the DNS system, from the A record representing the IPv4 add= ress of the IPv4-only host [I-D.ietf-behave-dns64]. This IPv4-mapped IPv6 = address, when managed by a translator, is to be considered as "fake" addres= s in a DNS system since it is not necessarily assigned to any host's interf= ace qualified by the associated name. This document defines a new DNS reco= rd type and query type to identify IPv4-mapped IPv6 address [I-D.ietf-behav= e-address-format] from native IPv6 ones. The new record type and query typ= e aim at helping the remote party to enforce its policies and avoid NAT64 b= oxes when possible. Native addresses are to be preferred. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-boucadair-behave-dns-a64-00. > txt > > > Cheers, > Med > >=20=20 > > -----Message d'origine----- > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la=20 > part de Christian Huitema Envoy=E9 : mercredi 21 octobre 2009 18:40 =C0 := =20 > teemu.savolainen@nokia.com; ajs@shinkuro.com; behave@ietf.org Objet :=20 > Re: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt > >=20=20=20 >> The draft contains question about multihoming:"In particular, how is=20 >> the multi-homed host supposed to know that a given AAAA is synthetic?". >>=20=20=20=20=20 > > Wonder about that too. Isn't the best solution to create a new record typ= e, say A4A6, that would contain the mapped addresses of IPv4 only hosts? > > -- Christian Huitema > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > ********************************* > This message and any attachments (the "message") are confidential and int= ended 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, chan= ged or falsified. > If you are not the intended addressee of this message, please cancel it i= mmediately and inform the sender. > ******************************** > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > ********************************* > This message and any attachments (the "message") are confidential and int= ended 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, chan= ged or falsified. > If you are not the intended addressee of this message, please cancel it i= mmediately and inform the sender. > ******************************** > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > >=20=20=20 ********************************* 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 mohamed.boucadair@orange-ftgroup.com Fri Oct 23 08:39:34 2009 Return-Path: <mohamed.boucadair@orange-ftgroup.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 64E4D3A6932 for <behave@core3.amsl.com>; Fri, 23 Oct 2009 08:39:34 -0700 (PDT) X-Quarantine-ID: <oazGJeXE27sf> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 oazGJeXE27sf for <behave@core3.amsl.com>; Fri, 23 Oct 2009 08:39:33 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 3E89F3A6947 for <behave@ietf.org>; Fri, 23 Oct 2009 08:39:33 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 237303B4348 for <behave@ietf.org>; Fri, 23 Oct 2009 17:39:43 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 07413C8065; Fri, 23 Oct 2009 17:39:43 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Fri, 23 Oct 2009 17:39:42 +0200 From: <mohamed.boucadair@orange-ftgroup.com> To: "behave@ietf.org" <behave@ietf.org> Date: Fri, 23 Oct 2009 17:39:40 +0200 Thread-Topic: A64-DNS Resource Record for IPv4-mapped IPv6 Address Thread-Index: AcpT9eurO1sJtfLdRfCoXMhcRvq/NAAANH7A Message-ID: <11302_1256312383_4AE1CE3F_11302_90229_1_94C682931C08B048B7A8645303FDC9F30781B1610A@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: fr-FR x-tm-as-product-ver: SMEX-8.0.0.1259-5.500.1027-16228.007 x-tm-as-result: No--23.372500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/mixed; boundary="_002_94C682931C08B048B7A8645303FDC9F30781B1610APUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.10.23.151220 Cc: BURGEY Eric RD-CORE <eric.burgey@orange-ftgroup.com> Subject: [BEHAVE] A64-DNS Resource Record for IPv4-mapped IPv6 Address 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, 23 Oct 2009 15:39:34 -0000 --_002_94C682931C08B048B7A8645303FDC9F30781B1610APUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Dear all, FYI, we have updated the draft to clarify various points and especially wit= h Q/A sections.=20 Comments, clarifications, suggestions are more than welcome. Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de Internet-Drafts@ietf.org Envoy=E9 : vendredi 23 octobre 2009 17:30 =C0 : i-d-announce@ietf.org Objet : I-D Action:draft-boucadair-behave-dns-a64-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : A64: DNS Resource Record for IPv4-mapped IPv6 Address Author(s) : M. Boucadair, E. Burgey Filename : draft-boucadair-behave-dns-a64-01.txt Pages : 15 Date : 2009-10-23 In the context of IPv4-IPv6 interconnection (or interworking), several solu= tions have been proposed within IETF. Some of these solutions require the = definition of a new IPv4-mapped IPv6 address [I-D.ietf-behave-address-forma= t] which is used to represent an IPv4- only host in an IPv6 realms and the = definition of a new mechanism called DNS64 for synthesizing a AAAA record, = representing an IPv4- mapped IPv6 address in the DNS system, from the A rec= ord representing the IPv4 address of the IPv4-only host [I-D.ietf-behave-dn= s64]. This IPv4-mapped IPv6 address, when managed by a translator, is to b= e considered as "fake" address in a DNS system since it is not necessarily = assigned to any host's interface qualified by the associated name. This do= cument defines a new DNS record type and query type to identify IPv4-mapped= IPv6 address [I-D.ietf-behave-address-format] from native IPv6 ones. The = new record type and query type aim at helping the requesting party to enfor= ce its policies and avoid crossing NAT64 boxes when possible. Native addresses are to be preferred. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boucadair-behave-dns-a64-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementa= tion to automatically retrieve the ASCII version of the Internet-Draft. ********************************* 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. ******************************** --_002_94C682931C08B048B7A8645303FDC9F30781B1610APUEXCB1Bnante_ Content-Type: message/external-body; name="draft-boucadair-behave-dns-a64-01.url" Content-Description: draft-boucadair-behave-dns-a64-01.url Content-Disposition: attachment; filename="draft-boucadair-behave-dns-a64-01.url"; size=98; creation-date="Fri, 23 Oct 2009 17:31:41 GMT"; modification-date="Fri, 23 Oct 2009 17:31:41 GMT" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1ib3VjYWRhaXItYmVoYXZlLWRucy1hNjQtMDEudHh0DQo= --_002_94C682931C08B048B7A8645303FDC9F30781B1610APUEXCB1Bnante_-- From root@core3.amsl.com Sat Oct 24 01:15:02 2009 Return-Path: <root@core3.amsl.com> X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 079473A68FF; Sat, 24 Oct 2009 01:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091024081502.079473A68FF@core3.amsl.com> Date: Sat, 24 Oct 2009 01:15:02 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-framework-03.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: Sat, 24 Oct 2009 08:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Framework for IPv4/IPv6 Translation Author(s) : F. Baker, et al. Filename : draft-ietf-behave-v6v4-framework-03.txt Pages : 30 Date : 2009-10-24 This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing NAT-PT, which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-framework-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-v6v4-framework-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-24010608.I-D@ietf.org> --NextPart-- From shengjiang@huawei.com Sat Oct 24 02:48:42 2009 Return-Path: <shengjiang@huawei.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 7E0583A69AC for <behave@core3.amsl.com>; Sat, 24 Oct 2009 02:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.34 X-Spam-Level: * X-Spam-Status: No, score=1.34 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPV8ipN2nwqf for <behave@core3.amsl.com>; Sat, 24 Oct 2009 02:48:41 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 1192F3A67D1 for <behave@ietf.org>; Sat, 24 Oct 2009 02:48:37 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS0006O6J9ATE@szxga03-in.huawei.com> for behave@ietf.org; Sat, 24 Oct 2009 17:48:46 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS0004YBJ9AEJ@szxga03-in.huawei.com> for behave@ietf.org; Sat, 24 Oct 2009 17:48:46 +0800 (CST) Received: from JiangXiong ([221.223.117.232]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KS0009KHJ971K@szxml02-in.huawei.com>; Sat, 24 Oct 2009 17:48:46 +0800 (CST) Date: Sat, 24 Oct 2009 17:48:29 +0800 From: Sheng Jiang <shengjiang@huawei.com> In-reply-to: <D1DA2BB2-E064-4656-B75A-A10339A1B9FB@muada.com> To: 'Iljitsch van Beijnum' <iljitsch@muada.com>, 'liu dapeng' <maxpassion@gmail.com> Message-id: <86F15BB9FC58443ABF2071A5CC843384@JiangXiong> Organization: Huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcpT0ZU0bBbYNw/2ThmwEFd5/tu9WAAvNfQQ References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> <25e1aaa40910230404m4517c64ew2a04e610cc6f2bcd@mail.gmail.com> <D1DA2BB2-E064-4656-B75A-A10339A1B9FB@muada.com> Cc: 'Sheng Jiang' <shengjiang@huawei.com>, behave@ietf.org, =?gb2312?B?J8H1tPPF9Cc=?= <liudapeng@chinamobile.com>, =?gb2312?B?J7Lc1fEn?= <caozhen@chinamobile.com>, 'Behave Chairs' <behave-chairs@tools.ietf.org>, 'Dan Wing' <dwing@cisco.com> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: shengjiang@huawei.com 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: Sat, 24 Oct 2009 09:48:42 -0000 Hi, I support to adopt the draft as WG documentation. However, the author wrote in the draft: =A1=B0Versions -05 and -06 of = this document adopts several important design decisions from [I-D.liu-behave-ftp64].=A1=B1 Should at least one author from draft-liu-behave-ftp64 deserve to be co-author of this draft-van-beijnum-behave-ftp64? Best wishes, Sheng > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On = Behalf Of > Iljitsch van Beijnum > Sent: Friday, October 23, 2009 7:11 PM > To: liu dapeng > Cc: =C1=F5=B4=F3=C5=F4; =B2=DC=D5=F1; behave@ietf.org; Behave Chairs; = Dan Wing > Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG = item >=20 > On 23 okt 2009, at 13:04, liu dapeng wrote: >=20 > > We know that there are two drafts discussing the ftp64 issue. Would > > the WG consider merging draft-van-beijnum-behave-ftp64 and > > draft-liu-behave-ftp64 as the WG document? >=20 > Do you feel the current text in draft-van-beijnum-behave-ftp64-06 > doesn't address your previous objections? > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From root@core3.amsl.com Sat Oct 24 06:15:01 2009 Return-Path: <root@core3.amsl.com> X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id ADC313A681B; Sat, 24 Oct 2009 06:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091024131501.ADC313A681B@core3.amsl.com> Date: Sat, 24 Oct 2009 06:15:01 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-03.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: Sat, 24 Oct 2009 13:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : IP/ICMP Translation Algorithm Author(s) : X. Li, et al. Filename : draft-ietf-behave-v6v4-xlate-03.txt Pages : 24 Date : 2009-10-24 This document specifies an update to the Stateless IP/ICMP Translation Algorithm (SIIT) described in RFC 2765. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers). This specification addresses both a stateless and a stateful mode. In the stateless mode, translation information is carried in the address itself, permitting both IPv4->IPv6 and IPv6->IPv4 session establishment without maintaining state in the IP/ICMP translator. In the stateful mode, translation state is maintained between IPv4 address/transport port tuples and IPv6 address/transport port tuples, enabling IPv6 systems to open sessions with IPv4 systems. The choice of operational mode is made by the operator deploying the network and is critical to the operation of the applications using it. Significant issues exist in the stateless and stateful modes that are not addressed in this document, related to the address assignment and the maintenance of the translation tables, respectively. This document confines itself to the actual translation. Acknowledgement of previous work This document is a product of the 2008-2009 effort to define a replacement for NAT-PT. It is an update to and directly derivative from Erik Nordmark's [RFC2765], which similarly provides both stateless and stateful translation between IPv4 [RFC0791] and IPv6 [RFC2460], and between ICMPv4 [RFC0792] and ICMPv6 [RFC4443]. The original document was a product of the NGTRANS working group. The changes in this document reflect five components: 1. Redescribing the network model to map to present and projected usage [I-D.ietf-behave-v6v4-framework]. 2. Moving the address format to the address format document [I-D.ietf-behave-address-format], to coordinate with other drafts on the topic. 3. Describing both stateful and stateless operation. 4. Some changes in ICMP. 5. Updating references. Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-v6v4-xlate-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-24060302.I-D@ietf.org> --NextPart-- From zhouboyj@gmail.com Sat Oct 24 09:12:42 2009 Return-Path: <zhouboyj@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 1D2883A6910 for <behave@core3.amsl.com>; Sat, 24 Oct 2009 09:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.148 X-Spam-Level: X-Spam-Status: No, score=-0.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WisZZFHm0mqc for <behave@core3.amsl.com>; Sat, 24 Oct 2009 09:12:38 -0700 (PDT) Received: from mail-iw0-f202.google.com (mail-iw0-f202.google.com [209.85.223.202]) by core3.amsl.com (Postfix) with ESMTP id 1E15E3A68B5 for <behave@ietf.org>; Sat, 24 Oct 2009 09:12:38 -0700 (PDT) Received: by iwn40 with SMTP id 40so5332312iwn.32 for <behave@ietf.org>; Sat, 24 Oct 2009 09:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=CHq06Ck6b4knhnzeAXIzFJ3CrazxukAZmp0+SSGFfWE=; b=UpzfiXQncpAAxDI0SMwX8rHi4ov4g36OZdQ4NmgyXkQvwV2kMyCzRoE9pQ1ynsgNQ7 kS04kWGBwFCdE467Dpe0NToUERw+lV3aMc4kwC2nWscF+3HvWoJyx5Gr3HhhqVQTvFkW zQ/RCY104s9eOzydlDLjNPIvN4ljKoZZxWkoo= 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=ZKGZrEoq13TBkzSVW5lQ8RjhDArIDVkeUOrh9SQa8lwkON86IjQ4El+YKuQRAF/mcD oDtSEKFiM+HnQShDpPjmY5m051toAkEgqiRVxzr5e219I6npRG8vK4Ax7/AOlKHI3wDz JDP7LZyrAI59PqmWpde6ZjKKDkPnDhGwDd1BU= MIME-Version: 1.0 Received: by 10.231.121.93 with SMTP id g29mr2937169ibr.13.1256400766390; Sat, 24 Oct 2009 09:12:46 -0700 (PDT) In-Reply-To: <86F15BB9FC58443ABF2071A5CC843384@JiangXiong> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> <25e1aaa40910230404m4517c64ew2a04e610cc6f2bcd@mail.gmail.com> <D1DA2BB2-E064-4656-B75A-A10339A1B9FB@muada.com> <86F15BB9FC58443ABF2071A5CC843384@JiangXiong> Date: Sun, 25 Oct 2009 00:12:46 +0800 Message-ID: <36a593230910240912w7fbfa34fmbd476690c450db17@mail.gmail.com> From: bo zhou <zhouboyj@gmail.com> To: shengjiang@huawei.com Content-Type: multipart/alternative; boundary=0016e646926a60521f0476b0992b Cc: behave@ietf.org, liu dapeng <maxpassion@gmail.com>, =?GB2312?B?wfW088X0?= <liudapeng@chinamobile.com>, =?GB2312?B?stzV8Q==?= <caozhen@chinamobile.com>, Behave Chairs <behave-chairs@tools.ietf.org>, Dan Wing <dwing@cisco.com> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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: Sat, 24 Oct 2009 16:12:42 -0000 --0016e646926a60521f0476b0992b Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Support Sheng's suggestion. Regards, Bo 2009/10/24 Sheng Jiang <shengjiang@huawei.com> > Hi, > > I support to adopt the draft as WG documentation. > > However, the author wrote in the draft: =A1=B0Versions -05 and -06 of thi= s > document adopts several important design decisions from > [I-D.liu-behave-ftp64].=A1=B1 Should at least one author from > draft-liu-behave-ftp64 deserve to be co-author of this > draft-van-beijnum-behave-ftp64? > > Best wishes, > > Sheng > > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behal= f > Of > > Iljitsch van Beijnum > > Sent: Friday, October 23, 2009 7:11 PM > > To: liu dapeng > > Cc: =C1=F5=B4=F3=C5=F4; =B2=DC=D5=F1; behave@ietf.org; Behave Chairs; D= an Wing > > Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG ite= m > > > > On 23 okt 2009, at 13:04, liu dapeng wrote: > > > > > We know that there are two drafts discussing the ftp64 issue. Would > > > the WG consider merging draft-van-beijnum-behave-ftp64 and > > > draft-liu-behave-ftp64 as the WG document? > > > > Do you feel the current text in draft-van-beijnum-behave-ftp64-06 > > doesn't address your previous objections? > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > --=20 Regards, Bo Zhou China Mobile --0016e646926a60521f0476b0992b Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable <div>Support Sheng's suggestion.</div> <div> </div> <div>Regards,</div> <div> </div> <div>Bo<br><br></div> <div class=3D"gmail_quote">2009/10/24 Sheng Jiang <span dir=3D"ltr"><<a = href=3D"mailto:shengjiang@huawei.com">shengjiang@huawei.com</a>></span><= br> <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0= px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi,<br><br>I support to adopt th= e draft as WG documentation.<br><br>However, the author wrote in the draft:= “Versions -05 and -06 of this<br> document adopts several important design decisions from<br>[I-D.liu-behave-= ftp64].” Should at least one author from<br>draft-liu-behave-ftp64 de= serve to be co-author of this<br>draft-van-beijnum-behave-ftp64?<br><br>Bes= t wishes,<br> <font color=3D"#888888"><br>Sheng<br></font> <div> <div></div> <div class=3D"h5"><br>> -----Original Message-----<br>> From: <a href= =3D"mailto:behave-bounces@ietf.org">behave-bounces@ietf.org</a> [mailto:<a = href=3D"mailto:behave-bounces@ietf.org">behave-bounces@ietf.org</a>] On Beh= alf<br> Of<br>> Iljitsch van Beijnum<br>> Sent: Friday, October 23, 2009 7:11= PM<br>> To: liu dapeng<br>> Cc: =C1=F5=B4=F3=C5=F4; =B2=DC=D5=F1; <a= href=3D"mailto:behave@ietf.org">behave@ietf.org</a>; Behave Chairs; Dan Wi= ng<br>> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as= WG item<br> ><br>> On 23 okt 2009, at 13:04, liu dapeng wrote:<br>><br>> &g= t; We know that there are two drafts discussing the ftp64 issue. Would<br>&= gt; > the WG consider merging draft-van-beijnum-behave-ftp64 and<br> > > draft-liu-behave-ftp64 as the WG document?<br>><br>> Do you= feel the current text in draft-van-beijnum-behave-ftp64-06<br>> doesn&#= 39;t address your previous objections?<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/behav= e" target=3D"_blank">https://www.ietf.org/mailman/listinfo/behave</a><br><b= r> _______________________________________________<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.o= rg/mailman/listinfo/behave</a><br> </div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Regards,<br= ><br>Bo Zhou<br>China Mobile<br> --0016e646926a60521f0476b0992b-- From shawngespan@gmail.com Sat Oct 24 23:41:06 2009 Return-Path: <shawngespan@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 670953A688E for <behave@core3.amsl.com>; Sat, 24 Oct 2009 23:41:06 -0700 (PDT) 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 SgIxpNNiHKxy for <behave@core3.amsl.com>; Sat, 24 Oct 2009 23:41:05 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 6A6213A682C for <behave@ietf.org>; Sat, 24 Oct 2009 23:41:05 -0700 (PDT) Received: by ywh13 with SMTP id 13so14255916ywh.29 for <behave@ietf.org>; Sat, 24 Oct 2009 23:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=y+wWSJ4KjiyGQqeQulv+/CWU51t9EPpidcBrV+jVzYE=; b=TvmASRHn5Xh5MdEvTf0aDZdKNYQnYVbaPXvnIa4itWEx3VrSdsI5fwK06KjoY1r+ub 74lLsEpTdjBZxNXk+Nmg3t9FJA/u8NoSdR3pRSu+SLUbFYbOPgOQVXgAGkn9S9S2F4I6 r9aI0rIZykRa6Jg5ilTNLbLOToPLCMq0D3yF4= 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 :content-type; b=pRdyKAOK+T+mtVVqxxydBEJM9hiAuvWZOLUZA7fuxhuX5YPN54bF3rRrZtzxUKjiC+ ro9ICIxZprN0QDUriD6iWmN0NbOFX0fFZZ03XN0kZ4O3H1ZvaWyIIYIDkD6pAA+ngBhP r96w29yDjZ4aRzsbInRrXee9iWliyx41xaFYU= MIME-Version: 1.0 Received: by 10.150.44.6 with SMTP id r6mr8563846ybr.244.1256452874400; Sat, 24 Oct 2009 23:41:14 -0700 (PDT) In-Reply-To: <mailman.2319.1256312374.4669.behave@ietf.org> References: <mailman.2319.1256312374.4669.behave@ietf.org> Date: Sun, 25 Oct 2009 14:41:14 +0800 Message-ID: <5bd2ab9c0910242341m451bcb85sdf65912a52850bdc@mail.gmail.com> From: Huan Huan <shawngespan@gmail.com> To: behave@ietf.org Content-Type: multipart/alternative; boundary=000e0cd59bb64172fc0476bcbbd2 Subject: Re: [BEHAVE] Behave Digest, Vol 38, Issue 20 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, 25 Oct 2009 06:41:07 -0000 --000e0cd59bb64172fc0476bcbbd2 Content-Type: text/plain; charset=ISO-8859-1 In fact, I think draft-van-beijnum-behave-ftp64 had addressed some opinions from draft-liu-behave-ftp64, for example, when Server ack message including address and port, client should use IPv6 address (not IPv4 address) to connect, there is similar in two drafts. From: Iljitsch van Beijnum <iljitsch@muada.com> > To: liu dapeng <maxpassion@gmail.com> > Date: Fri, 23 Oct 2009 13:10:31 +0200 > Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item > On 23 okt 2009, at 13:04, liu dapeng wrote: > > We know that there are two drafts discussing the ftp64 issue. Would >> the WG consider merging draft-van-beijnum-behave-ftp64 and >> draft-liu-behave-ftp64 as the WG document? >> > > Do you feel the current text in draft-van-beijnum-behave-ftp64-06 doesn't > address your previous objections? > Best Regards, -- Huan Huan BII Group IPv6 R&D Center Technique Project Manager --000e0cd59bb64172fc0476bcbbd2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In fact, I think draft-van-beijnum-behave-ftp64 had addressed some opinions= from draft-liu-behave-ftp64, for example, when Server ack message includin= g address and port, client should use IPv6 address (not IPv4 address) to co= nnect, there is similar in two drafts.<div class=3D"gmail_quote"> <br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(2= 04, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">From:=A0Iljit= sch van Beijnum <<a href=3D"mailto:iljitsch@muada.com">iljitsch@muada.co= m</a>><br> To:=A0liu dapeng <<a href=3D"mailto:maxpassion@gmail.com">maxpassion@gma= il.com</a>><br>Date:=A0Fri, 23 Oct 2009 13:10:31 +0200<br>Subject:=A0Re:= [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item<br>On 23 okt 2= 009, at 13:04, liu dapeng wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> We know that there are two drafts discussing the ftp64 issue. Would<br> the WG consider merging draft-van-beijnum-behave-ftp64 and<br> draft-liu-behave-ftp64 as the WG document?<br> </blockquote> <br> Do you feel the current text in draft-van-beijnum-behave-ftp64-06 doesn'= ;t address your previous objections?<br> </blockquote></div><br>Best Regards,<br>-- <br>Huan Huan<br><br>BII Group<b= r>IPv6 R&D Center<br>Technique Project Manager<br> --000e0cd59bb64172fc0476bcbbd2-- From shawngespan@gmail.com Sat Oct 24 23:43:05 2009 Return-Path: <shawngespan@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 5E7E13A682C for <behave@core3.amsl.com>; Sat, 24 Oct 2009 23:43:05 -0700 (PDT) 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 FwqFCu6x5d6m for <behave@core3.amsl.com>; Sat, 24 Oct 2009 23:43:04 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 7C0273A679C for <behave@ietf.org>; Sat, 24 Oct 2009 23:43:04 -0700 (PDT) Received: by yxe30 with SMTP id 30so13883325yxe.29 for <behave@ietf.org>; Sat, 24 Oct 2009 23:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=03kvyRR/JwZcfciSNJMpPw1qvhG+JaTBYtWzaVmpRkk=; b=oS8alP6Zk2yu9SocRa6ek0FuBViju6HlUF7GwolAy2FriElhkP8STsd5jsJLPqA/NT HJNHWIuaklWJ6+P4jtl4ywIbIrss32sA9H2QnTJucLjXRYbPrCDDlzhye7OZQwrEXg4S 2NShdnFqTAikUqG14tlnXKxYKpNjE3Sp9aqg8= 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 :content-type; b=KswBlFBTxIolQWUVbQgxESwdaKDVbzxiedBSWi93p/3crpZzX9/RDwveFTBlbIVuih 5e4hHtMVW8nm576GdHsFlBnVlF1sM4tOkewx9ZOKuOQLGw3HsBAZqrVrnnkSPSCLUaMa PYsowuYjePz5qJeFRLgQRp0BZAgvXLIeAuWLI= MIME-Version: 1.0 Received: by 10.150.19.5 with SMTP id 5mr1989123ybs.103.1256452993054; Sat, 24 Oct 2009 23:43:13 -0700 (PDT) In-Reply-To: <mailman.82.1256410809.13085.behave@ietf.org> References: <mailman.82.1256410809.13085.behave@ietf.org> Date: Sun, 25 Oct 2009 14:43:13 +0800 Message-ID: <5bd2ab9c0910242343i6dede93ate7aae147e38530fa@mail.gmail.com> From: Huan Huan <shawngespan@gmail.com> To: behave@ietf.org Content-Type: multipart/alternative; boundary=000e0cd6c8b653f7de0476bcc251 Subject: Re: [BEHAVE] Behave Digest, Vol 38, Issue 21 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, 25 Oct 2009 06:43:05 -0000 --000e0cd6c8b653f7de0476bcc251 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable agree. From: Sheng Jiang <shengjiang@huawei.com> > To: 'Iljitsch van Beijnum' <iljitsch@muada.com>, 'liu dapeng' < > maxpassion@gmail.com> > Date: Sat, 24 Oct 2009 17:48:29 +0800 > Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item > Hi, > > I support to adopt the draft as WG documentation. > > However, the author wrote in the draft: =93Versions -05 and -06 of this > document adopts several important design decisions from > [I-D.liu-behave-ftp64].=94 Should at least one author from > draft-liu-behave-ftp64 deserve to be co-author of this > draft-van-beijnum-behave-ftp64? > > Best wishes, > > Sheng > > --=20 Huan Huan BII Group IPv6 R&D Center Technique Project Manager --000e0cd6c8b653f7de0476bcc251 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable agree.<br><br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" = style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8= ex; padding-left: 1ex;">From:=A0Sheng Jiang <<a href=3D"mailto:shengjian= g@huawei.com">shengjiang@huawei.com</a>><br> To:=A0'Iljitsch van Beijnum' <<a href=3D"mailto:iljitsch@muada.c= om">iljitsch@muada.com</a>>, 'liu dapeng' <<a href=3D"mailto:= maxpassion@gmail.com">maxpassion@gmail.com</a>><br>Date:=A0Sat, 24 Oct 2= 009 17:48:29 +0800<br> Subject:=A0Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item<= br>Hi,<br> <br> I support to adopt the draft as WG documentation.<br> <br> However, the author wrote in the draft: =93Versions -05 and -06 of this<br> document adopts several important design decisions from<br> [I-D.liu-behave-ftp64].=94 Should at least one author from<br> draft-liu-behave-ftp64 deserve to be co-author of this<br> draft-van-beijnum-behave-ftp64?<br> <br> Best wishes,<br> <br> Sheng<br> <br clear=3D"all"></blockquote></div><br>-- <br>Huan Huan<br><br>BII Group<= br>IPv6 R&D Center<br>Technique Project Manager<br> --000e0cd6c8b653f7de0476bcc251-- From iljitsch@muada.com Sun Oct 25 03:41:58 2009 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 E65803A6970 for <behave@core3.amsl.com>; Sun, 25 Oct 2009 03:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8BS48y4aCE4 for <behave@core3.amsl.com>; Sun, 25 Oct 2009 03:41:58 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id D95053A696E for <behave@ietf.org>; Sun, 25 Oct 2009 03:41:57 -0700 (PDT) Received: from [192.168.2.11] (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 n9PAeHSd020036 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 25 Oct 2009 11:40:58 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <86F15BB9FC58443ABF2071A5CC843384@JiangXiong> Date: Sun, 25 Oct 2009 11:41:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3932CF6D-1634-4C35-BA4A-3A4A0F3ED577@muada.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> <25e1aaa40910230404m4517c64ew2a04e610cc6f2bcd@mail.gmail.com> <D1DA2BB2-E064-4656-B75A-A10339A1B9FB@muada.com> <86F15BB9FC58443ABF2071A5CC843384@JiangXiong> To: shengjiang@huawei.com X-Mailer: Apple Mail (2.1076) Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 25 Oct 2009 10:41:59 -0000 On 24 okt 2009, at 11:48, Sheng Jiang wrote: > However, the author wrote in the draft: =93Versions -05 and -06 of = this > document adopts several important design decisions from > [I-D.liu-behave-ftp64].=94 Should at least one author from > draft-liu-behave-ftp64 deserve to be co-author of this > draft-van-beijnum-behave-ftp64? I'm happy that so many of you want work together on the FTP64 document. However, I would prefer to not add co-authors for the following reasons: - Having a single author reduces the time needed for coordination so =20 progress can be faster. - Although many people have contributed tests, ideas and suggestions =20 (as noted in the acknowledgments), I wrote all the text and I did all =20= the presentations at IETF meetings. However, when the document is adopted as a working group document I =20 would be willing to listen to the chairs if they want to suggest =20 additional authors if they have important reasons for adding more =20 authors. Iljitsch= From mohamed.boucadair@orange-ftgroup.com Sun Oct 25 06:33:59 2009 Return-Path: <mohamed.boucadair@orange-ftgroup.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 75F4B3A682B for <behave@core3.amsl.com>; Sun, 25 Oct 2009 06:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 E7hG4ziDXg58 for <behave@core3.amsl.com>; Sun, 25 Oct 2009 06:33:58 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 40CCA3A677C for <behave@ietf.org>; Sun, 25 Oct 2009 06:33:57 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id E32D0104311; Sun, 25 Oct 2009 14:34:08 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id C534D23806C; Sun, 25 Oct 2009 14:34:08 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Sun, 25 Oct 2009 14:34:08 +0100 From: <mohamed.boucadair@orange-ftgroup.com> To: Dan Wing <dwing@cisco.com> Date: Sun, 25 Oct 2009 14:34:06 +0100 Thread-Topic: draft-boucadair-behave-dns-a64-00.txt [was RE: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt] Thread-Index: AQHKUOZcB4qVxczK40+zVvgdVO4zY5ENo/MAgAFHKICAAUzkUIABPuwwgABYBaCABH3VwA== Message-ID: <25123_1256477648_4AE453D0_25123_1358_1_94C682931C08B048B7A8645303FDC9F30781B161A8@PUEXCB1B.nanterre.francetelecom.fr> References: <20091019180002.1AFBE3A692D@core3.amsl.com><20091019181555.GC9536@shinkuro.com><18034D4D7FE9AE48BF19AB1B0EF2729F3EF10EF424@NOK-EUMSG-01.mgdnok.nokia.com><6B55F0F93C3E9D45AF283313B8D342BA211C9BC9@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <23132_1256211881_4AE045A9_23132_13404_1_94C682931C08B048B7A8645303FDC9F30781B159F8@PUEXCB1B.nanterre.francetelecom.fr> <02d401ca533a$4893ba10$5ba36b80@cisco.com> In-Reply-To: <02d401ca533a$4893ba10$5ba36b80@cisco.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.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.10.25.13923 Cc: "ajs@shinkuro.com" <ajs@shinkuro.com>, "draft-boucadair-behave-dns-a64@tools.ietf.org" <draft-boucadair-behave-dns-a64@tools.ietf.org>, "behave@ietf.org" <behave@ietf.org> Subject: Re: [BEHAVE] draft-boucadair-behave-dns-a64-00.txt [was RE: I-D Action:draft-ietf-behave-dns64-01.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: Sun, 25 Oct 2009 13:33:59 -0000 Hi Dan, all, I'm aware about that mode. In fact it is also part of draft-boucadair spec.= The procedure described in draft-ietf-behave-dns64 is assumed as the first= step. draft-boucadair is a step forward to solve some pending issues as el= aborated in 01 version of draft-boucadair. Please refer to Section Q/A of t= he updated draft for more discussion. Do you have in mind explicit "disadvantages"? Cheers, Med=20 -----Message d'origine----- De : Dan Wing [mailto:dwing@cisco.com]=20 Envoy=E9 : jeudi 22 octobre 2009 19:09 =C0 : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : 'Christian Huitema'; teemu.savolainen@nokia.com; ajs@shinkuro.com; beh= ave@ietf.org; draft-boucadair-behave-dns-a64@tools.ietf.org Objet : draft-boucadair-behave-dns-a64-00.txt [was RE: [BEHAVE] I-D Action:= draft-ietf-behave-dns64-01.txt] > FYI, we have submitted a draft to describe the A64 record for=20 > IPv4-mapped IPv6 addresses. An updated version of the draft will be=20 > submitted soon draft-boucadair-behave-dns-a64-00 requires the DNS64 and the host to implem= ent a new DNS resource record, A64, in order to learn if the DNS64 synthesi= zed a response. Instead, have you considered just having the host query an existing DNS64 w= ith the CD and DO bits set (which disables the DNS64's AAAA synthesis) and = have the host do its own DNS64 processing? See item #3 in http://tools.ietf.org/html/draft-ietf-behave-dns64-01#section-5.5 If you have considered that technique, I expect you found some sort of disa= dvantage to that technique. Please share. -d ********************************* 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 petithug@acm.org Sun Oct 25 12:03:45 2009 Return-Path: <petithug@acm.org> 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 9F8EA28C146 for <behave@core3.amsl.com>; Sun, 25 Oct 2009 12:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.199 X-Spam-Level: X-Spam-Status: No, score=-101.199 tagged_above=-999 required=5 tests=[AWL=-0.734, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_51=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_62=0.6, 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 U0IhUJixsomc for <behave@core3.amsl.com>; Sun, 25 Oct 2009 12:03:43 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id CF0B028C14F for <behave@ietf.org>; Sun, 25 Oct 2009 12:03:43 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 8C75E6C9852C; Sun, 25 Oct 2009 19:03:56 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id D83956C98524; Sun, 25 Oct 2009 19:03:53 +0000 (UTC) Message-ID: <4AE4A119.5050007@acm.org> Date: Sun, 25 Oct 2009 12:03:53 -0700 From: Marc Petit-Huguenin <petithug@acm.org> User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: Margaret Wasserman <mrw@lilacglade.org>, Behave WG <behave@ietf.org> References: <01c101ca509f$f314a8c0$8e27460a@china.huawei.com> <61FFB311-CA42-4EE4-A6F9-3DE0581A9E8F@lilacglade.org> <4ADE0BAB.1040402@acm.org> <FF53CDBF-9204-490D-8D04-9DF806EFE275@lilacglade.org> <4AE0A9F0.2010106@acm.org> <839B17D7-0BDE-4F11-8DC6-BDF694F7521D@lilacglade.org> In-Reply-To: <839B17D7-0BDE-4F11-8DC6-BDF694F7521D@lilacglade.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] Opsdir Review of draft-ietf-behave-turn-uri-03.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: Sun, 25 Oct 2009 19:03:45 -0000 Hi Margaret, see inline. Margaret Wasserman wrote: > Hi Marc, > > I've added the WG back to this message, because I think that some of > my questions/comments in this message should be considered by the > group. > > I think that I understand this specification now. I do have a few > more comments on your proposed text (in-line below), but I also have a > few more fundamental concerns about this specification. > > It is possible that the WG has already discussed these issues and > agreed to the approach in your document. If so, I apologize for > wasting time. If not, though, I think it is important that we all > understand these issues and agree on the right approach. > > (1) Implicit vs. Explicit Processing: > > The URIs in the specification are defined so that the processing > performed to resolve them is implied by the contents and/or presence > of various fields in the URI. > > - If the <host> is an IP address, no DNS lookup is performed. > > - If the <host> is a domain name (or any string that could be a domain > name), processing depends on the existence of the <transport> and > <port> fields. > > -- If <port> is defined, then a DNS A/AAAA lookup is defined, and > services are contacted at the defined port. > > -- If <port> is not defined, and <transport> is defined a DNS SRV > lookup is performed, with fallback to an A/AAAA lookup. > > -- If neither <port> nor <transport> is defined, then an S-NAPTR > lookup is performed, with fallback to DNS SRV, and subsequent fallback > to A/AAAA. > > Having the type(s) of resolution performed be dependent on the > inclusion/exclusion of fields in the URI has some advantages. One is > that you are never asked to perform a type of resolution for which you > do not have the appropriate information. > > However, there are some downsides to this approach, because it limits > the flexibility of the application. > > It is not possible, for example, to request an S-NAPTR lookup without > fallback to DNS SRV. If there should be an S-NAPTR record or a DNS > SRV record, and that lookup fails, fallback to trying all supported > transports based on an A/AAAA lookup may result in connecting to a > different TURN/TURNS service than desired, or to a different server > than has been contacted in the past. All of this would, presumably, > be invisible to the user and perhaps to the application, so debugging > the problem might be difficult. > > Were these tradeoffs discussed in the WG? No. > What were the reasons for > choosing the current implicit processing approach? This design is inspired by RFC 3263. The idea is that domain administrators can choose to implement either A/AAAA or SRV+A/AAAA or NAPTR+SRV+A/AAAA as they see fit for their environment, but still use the same TURN URI. Let's use as example the growth of a VoIP provider. The TURN URI provisioned in the VoIP end-user devices is "turn:example.com", and cannot be easily changed. The provider starts with few identical TURN boxes and use an A RR for each box. Each endpoint queries for NAPTR, which fails; then for SRV, which fails; then for A, which succeeds. After some time, more TURN servers are added, but they are not identical, so load balancing is needed, so the provider adds some SRV RR. Now each endpoint queries for NAPTR, which fails; then for SRV, which succeeds; then the final A. Without modifications on the endpoint, the administrators were successful in upgrading their infrastructure. After even more time, the provider decides to delegate the management of the TURN servers to an external company, so they add a NAPTR RR. Now each endpoint queries for the NAPTR which succeed to delegate to the NAPTR of the domain of the company managing the TURN servers, and the SRV succeeds, and then the A. Here again, the provider succeeded in changing their infrastructure without having to reconfigure the endpoints. > > (2) TURNS vs. TURN URIs: > > The document specifies two different URI schemes, TURN and TURNS. > > However, the processing steps defined imply that a TURNS URL might > end-up reaching a TURN server, and vice versa. I am particularly > concerned about the case where a request for an authenticated, > encrypted session (TURNS) may result in connection to an insecure > service (TURN). > > This could happen (I believe) in at least two cases: > > - If an IP address is provided for the <host> and no <transport> is > provided, "the TURN transports supported by the application are > tried by preference order." > > - If a domain name is provided for <host>, <port> is defined and > <transport> is not defined, "the TURN transports supported by the > application are tried by preference order." > > Is it intentional that these choices will try all of the "TURN > transports" supported by the application, not just those that match > the <scheme> in the URI? If so, why? > > If this is not intentional, then further wording changes are needed. > > If this is intentional, the implications should be discussed in the > Security Considerations section. You are absolutely right, this is a bug in the spec, the ordered list of TURN transports should have been filtered by the <scheme> used. I propose to replace "...the TURN transports supported by the application..." by "...the filtered TURN transports supported by the application..." in step #1 and #2 and to add the following paragraph before paragraph 6: "After verifying the validity of the URI elements, the algorithm filters the list of TURN transports supported by the application by keeping only the UDP and TCP TURN transports if the <scheme> is defined as "turn" and by keeping only the TLS TURN transport if the <scheme> is defined as "turns". If the list of TURN transports is empty after this filtering, the resolution MUST stop with an error." and to modify paragraph 6 (now 7) like this: "After filtering the list of TURN transports supported by the application, the algorithm applies the steps described below. Note that in some steps, <scheme> and <transport> have to be converted to [...]" > > (2) There seem to be some ambiguity in case 2 about whether the > service will always be contacted using the <transport> defined in the > URI, if any. The text indicates that a <transport> may be defined and > would be used to construct a TURN transport, but then the text says: > If the TURN client cannot contact a TURN server with this port and any > combination of transports supported by the application and resolved IP > addresses then the resolution MUST stop with an error. > > So, it appears that the resolution process will try all of the > transports supported by the application, even if a <transport> is > specified in the URI. There are similar ambiguities elsewhere. > > Is this intentional? If so, why? If not, then further wording > changes are required to make this clearer. New proposed text: "2. If <host> is a domain name and <port> is defined, then <host> is resolved to a list of IP addresses via DNS A and AAAA queries. If <transport> is defined, then <scheme> and <transport> are converted to a TURN transport as specified in Table 1. If <transport> is not defined, the filtered TURN transports supported by the application are tried in preference order. The TURN client can choose the order to contact the resolved IP addresses in any implementation-specific way. If the TURN client cannot contact a TURN server with this port, the transport or list of transports, and the resolved IP addresses, then the resolution MUST stop with an error." > > (4) I also continue to be concerned about the amount of information in > the 4 numbered paragraphs in section 4, and their relative lack of > structure, as well as the lack of examples. I am concerned that this > specification may not be clear enough to promote consistent > implementation. > > I think that it would be much better if you added a section explaining > how each type of lookup (A/AAAA, SRV, S-NAPTR) is constructed from the > fields of the URI and performed, with examples. Then you could > include a trimmed down version of your current section that explains > how to determine which lookups to perform based on the contents of the > URI. I think that would be clearer than trying to do it all in the > same paragraphs. You might also consider writing the procedures more > in the order they would be performed if they were written in a > program, perhaps handling the IP address case first (as you have done), > but then reversing the order of the other cases and describing how > you would fall through from one type of lookup to another. I still think that examples must not be added until the text is so clear that the examples are useless. > > On Oct 22, 2009, at 2:52 PM, Marc Petit-Huguenin wrote: > >> Here's the new proposed text: >> "3. If <host> is a domain name and >> <port> is not defined but <transport> is defined, then <host> is >> converted to a list of IP address and port tuples via a DNS SRV >> query as defined in [I-D.ietf-behave-turn] section 6.1. <host> is >> used for the Name, <scheme> is used for the Service and <transport> >> is used for the Protocol in the SRV algorithm [RFC2782]. The SRV >> algorithm recommends doing an A query if the SRV query returns an >> error or no SRV RR; in this case the default port declared in >> [I-D.ietf-behave-turn] for the SRV service name defined in <scheme> >> MUST be used for contacting the TURN server. Also in this case, > > Will these connection attempts also use the <transport> defined > above? Or will they use all of the transports supported by the > application? This is specified by RFC 2782 section "Usage Rules": "else Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A for each address record found, try to connect to the (protocol, address, service)" protocol been already defined as <transport>. > >> this specification modifies the SRV algorithm by recommending an A >> and AAAA query. If the TURN client cannot contact a TURN server at >> any of the IP address, port and transport tuples returned by the SRV >> algorithm then the resolution MUST stop with an error." > > This has the same problem as the one you fixed in section 4. We > don't return an error if the SRV fails, only if both the SRV lookup > and the subsequent A/AAAA lookup fail, right? I disagree here. The text says "SRV algorithm" not "SRV query". The fallback to A is part of the SRV algorithm, not something added by this text, so the tuples returned by the SRV algorithm eventually contains the result of the A query (and AAAA as modified by the text). And thinking of it, I am not sure I should have modified step 4, but see below. > >> > When you say "using the algorithm specified in step 3" do you >> > really mean that if S-NAPTR fails, the client should try multiple >> > DNS SRV queries using the supported TURN transports to construct >> > DNS SRV lookup targets? Or are you talking about the second half >> > of step 3? Or both? >> >> Both, so if NAPTR fails, then SRV is tried. If SRV fails then >> A/AAAA is tried. > >> Here's the new proposed text: >> "4. If <host> is a domain name and >> <port> and <transport> are not defined, then <host> is converted to >> an ordered list of IP address, port and transport tuples via the >> S-NAPTR algorithm defined in [RFC3958] by using <host> as the >> initial target domain name and "RELAY" as the Application Service >> Tag. The TURN transports supported by the application are converted >> in Application Protocol Tags by using "turn.udp" if the TURN >> transport is UDP, "turn.tcp" if the TURN transport is TCP and >> "turn.tls" if the TURN transport is TLS. The order to try the >> Application Protocol Tags is provided by the ranking of the first >> set of NAPTR records. If multiple Application Protocol Tags have >> the same ranking, the preferred order set by the application is >> used. If the first NAPTR query does not return any result then >> <host> is converted to a list of IP address and port tuples by using >> the algorithms specified in step 3, including the fallback to the >> A/AAAA query, for each of the TURN transports supported by the >> application in order of preference. > > This makes it clear that the A/AAAA lookup is included, but does not > make it clear that the DNS SRV lookup is included. I think that the main problem here is that I tried to reuse step 3 as a procedure call, and that parameter passing does not work very well in a human language. So instead of fixing this, I added a step 5 that copies step 3, so the new text becomes this: "4. If <host> is a domain name and <port> and <transport> are not defined, then <host> is converted to an ordered list of IP address, port and transport tuples via the S-NAPTR algorithm defined in [RFC3958] by using <host> as the initial target domain name and "RELAY" as the Application Service Tag. The TURN transports supported by the application are converted in Application Protocol Tags by using "turn.udp" if the TURN transport is UDP, "turn.tcp" if the TURN transport is TCP and "turn.tls" if the TURN transport is TLS. The order to try the Application Protocol Tags is provided by the ranking of the first set of NAPTR records. If multiple Application Protocol Tags have the same ranking, the preferred order set by the application is used. If the TURN client cannot contact a TURN server with any of the IP address, port and transport tuples returned by the S-NAPTR algorithm then the resolution MUST stop with an error. 5. If the first NAPTR query in the previous step does not return any result then <host> is converted to a list of IP address and port tuples via a DNS SRV query as defined in [I-D.ietf-behave-turn] section 6.1. The filtered TURN transports supported by the application are tried in preference order for the Protocol, <host> is used for the Name and <scheme> is used for the Service in the SRV algorithm [RFC2782]. The SRV algorithm recommends doing an A query if the SRV query returns an error or no SRV RR; in this case the default port declared in [I-D.ietf-behave-turn] for the SRV service name defined in <scheme> MUST be used for contacting the TURN server. Also in this case, this specification modifies the SRV algorithm by recommending an A and AAAA query. If the TURN client cannot contact a TURN server at any of the IP address, port and transport tuples returned by the SRV algorithm then the resolution MUST stop with an error." > >> If the TURN client cannot >> contact a TURN server with any of the IP address, port and transport >> tuples returned by the S-NAPTR algorithm or by eventually applying >> the algorithms specified in step 3, then the resolution MUST stop >> with an error." > >> > My concern is that there are some subtleties omitted from your >> > text, such as exactly how an SRV lookup target, an S-NAPTR lookup >> > target and/or an A/AAAA lookup target are constructed from the >> > contents of the URI, and I think further examples might make this >> > clearer. You make it clearer in the text, instead, if you think >> > that would be preferable. > >> I hope that we can settle on a normative text that would not require >> developers to look at the examples. > > It is still not clear to me, from your text, how the S-NAPTR lookup > would be constructed, but that may reflect my limited understanding > of S-NAPTR. -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From rpenno@juniper.net Sun Oct 25 23:41:19 2009 Return-Path: <rpenno@juniper.net> 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 7901628C1EF for <behave@core3.amsl.com>; Sun, 25 Oct 2009 23:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFa5vvnoGrwS for <behave@core3.amsl.com>; Sun, 25 Oct 2009 23:41:18 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 825DE28C11B for <behave@ietf.org>; Sun, 25 Oct 2009 23:41:17 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSuVEmudv0RpEjroexBnGy4vMn2XiHWnV@postini.com; Sun, 25 Oct 2009 23:41:31 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sun, 25 Oct 2009 23:40:23 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 26 Oct 2009 02:40:22 -0400 From: Reinaldo Penno <rpenno@juniper.net> To: "behave@ietf.org" <behave@ietf.org> Date: Mon, 26 Oct 2009 02:40:19 -0400 Thread-Topic: Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-02.txt Thread-Index: AcpWBy8xbp6mvz6WAUa46kgZ6b/YzA== Message-ID: <C70A9263.68C5%rpenno@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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: Mon, 26 Oct 2009 06:41:20 -0000 Hello, The draft is evolving quite nicely and looks very good. I have a comment on the way TCP RSTs are handled. I will post other comments shortly. I believe the way the text is written today precludes an implementation tha= t wants to provide more security. I would not mind if the 'basic' mode of operation did not preclude a more secure mode, but the way it is written, this is not possible. Text is the following... =B3 If a V4 RST or a V6 RST packet is received, the packet is translated and forwarded. The lifetime is set to 4 min and state is moved to RST RCV.=B2 And then =B3 *** RST RCV *** If a packet is received, the lifetime is set to 2 hours and 4 min and the state is moved to ESTABLISHED. If the lifetime expires, the session table entry is deleted and the state is moved to CLOSED. =B3 I have two comments on the text above: 1) If I have a way of detecting brute force TCP RST attacks or forged TCP RSTs I would like to drop the TCP RST instead of blindly translating it. Th= e current text does not allow for it. 2) If I track TCP seq numbers and the TCP RST passes my security policy, I do not want to keep the connection around for 4 minutes. This represents a huge waste of resources knowing that many connections (~12%) end up with TC= P RST. I have a general comment irrespective of the two points above. 3) keeping a connection around for 2 hour and 4 minutes if just so happens that I receive a packet after a TCP RST is also a security issue and waste of resources. I would suggest running a timer _after_ receiving this new packet and if no other packet is received from the opposite direction then the connection should be moved to CLOSED state. It seems this is a escape provision in the case the TCP RST is not acceptable by the end hosts. Add-on Text: ----------- Then I would suggest the following text: "If the security policy determines that the TCP RST packet is an attack it can be silently drooped (There is already a similar text for V4 SYNs). .... If the implementation tracks TCP sequence numbers and the TCP RST passes it= s security policy the connection can be moved to the CLOSED state." Regards, Reinaldo From marcelo@it.uc3m.es Mon Oct 26 00:11:07 2009 Return-Path: <marcelo@it.uc3m.es> 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 6D1B03A698E for <behave@core3.amsl.com>; Mon, 26 Oct 2009 00:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iX0R+uH7x9Ao for <behave@core3.amsl.com>; Mon, 26 Oct 2009 00:11:06 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id CAC743A68B4 for <behave@ietf.org>; Mon, 26 Oct 2009 00:11:04 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.30.243]) by smtp01.uc3m.es (Postfix) with ESMTP id 783CCBA7F75; Mon, 26 Oct 2009 08:11:16 +0100 (CET) Message-ID: <4AE54B88.2090104@it.uc3m.es> Date: Mon, 26 Oct 2009 08:11:04 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Reinaldo Penno <rpenno@juniper.net> References: <C70A9263.68C5%rpenno@juniper.net> In-Reply-To: <C70A9263.68C5%rpenno@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16970.003 Cc: "behave@ietf.org" <behave@ietf.org> Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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: Mon, 26 Oct 2009 07:11:07 -0000 Reinaldo Penno escribió: > Add-on Text: > ----------- > > Then I would suggest the following text: > > "If the security policy determines that the TCP RST packet is an attack it > can be silently drooped (There is already a similar text for V4 SYNs). > > .... > > If the implementation tracks TCP sequence numbers and the TCP RST passes its > security policy the connection can be moved to the CLOSED state." > > I personally don't have an issue with adding this text. I will do so unless someone else has a problem and thinks it deserves more discussion. Regards, marcelo > Regards, > > Reinaldo > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From lars.eggert@nokia.com Mon Oct 26 02:47:36 2009 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 EAC8128C13A for <behave@core3.amsl.com>; Mon, 26 Oct 2009 02:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 wqGRKV-ZGlXt for <behave@core3.amsl.com>; Mon, 26 Oct 2009 02:47:36 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id E27FE28C145 for <behave@ietf.org>; Mon, 26 Oct 2009 02:47:35 -0700 (PDT) Received: from [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (lars.local [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (may be forged)) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n9Q9lepQ076176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Oct 2009 11:47:40 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-13--929614166; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert <lars.eggert@nokia.com> In-Reply-To: <4AE54B88.2090104@it.uc3m.es> Date: Mon, 26 Oct 2009 11:47:39 +0200 Message-Id: <B8C0608A-10E2-4212-9662-E317CA8C5CD9@nokia.com> References: <C70A9263.68C5%rpenno@juniper.net> <4AE54B88.2090104@it.uc3m.es> To: marcelo bagnulo braun <marcelo@it.uc3m.es> X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [IPv6:2001:708:40:fff1::1]); Mon, 26 Oct 2009 11:47:42 +0200 (EET) Cc: "behave@ietf.org" <behave@ietf.org> Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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: Mon, 26 Oct 2009 09:47:37 -0000 --Apple-Mail-13--929614166 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes Hi, On 2009-10-26, at 9:11, marcelo bagnulo braun wrote: > Reinaldo Penno escribi=F3: >> Then I would suggest the following text: >> >> "If the security policy determines that the TCP RST packet is an =20 >> attack it >> can be silently drooped (There is already a similar text for V4 =20 >> SYNs). >> .... >> If the implementation tracks TCP sequence numbers and the TCP RST =20 >> passes its >> security policy the connection can be moved to the CLOSED state." > > I personally don't have an issue with adding this text. I will do so > unless someone else has a problem and thinks it deserves more =20 > discussion. objection. A NAT is *not* a security device and does not implement =20 "security policies." We've hit this several times in the past with different BEHAVE =20 document, and we've always been very careful to focus on the =20 "translator" functions only. (Other WGs have talked about firewall/=20 security functions, e.g., V6OPS.) Lars= --Apple-Mail-13--929614166 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTAyNjA5NDc0MFowIwYJKoZIhvcNAQkEMRYEFOPBv7taEHXOm9mjh+PCpqroNwJFMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQBWhqSsZ0Bk0Afi5noVTpOEardGApS7G0SmyxWnFSPW628kN203uI3F2g2kZplwbQZqGdEn lzUPq2wGgDtp112wVafQLqz7GPOLTmL0i+v/UacAiTklmfe/8Di4WzkvTSlBxoNhiRnxygCT6LXP A8zfGShvjZ5w7sbhn823MyPbNKaNJcfcOzuVjMz2E5H8Oa5aOXTnT76qzSpujFTXWZRCZVoOdp2G k+Rn/7T4/MJ0UFvlOZFrCfHX8dKYQA0uDWUMsJgakaodA64w5eUq9KFa/9XmxEkxXOIJnHpQK/nS 8UEj/jKNHl1u5lmexyqZaUgkKJB0kmIw7mYYk0mFZDctAAAAAAAA --Apple-Mail-13--929614166-- From rpenno@juniper.net Mon Oct 26 03:04:54 2009 Return-Path: <rpenno@juniper.net> 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 272A83A67E6 for <behave@core3.amsl.com>; Mon, 26 Oct 2009 03:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrYrmjKQEwkt for <behave@core3.amsl.com>; Mon, 26 Oct 2009 03:04:53 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id F3E903A659C for <behave@ietf.org>; Mon, 26 Oct 2009 03:04:46 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSuV0TCGH14/6w2N2eawNWk8OtjN81eEN@postini.com; Mon, 26 Oct 2009 03:05:06 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 26 Oct 2009 03:04:58 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 26 Oct 2009 06:04:58 -0400 From: Reinaldo Penno <rpenno@juniper.net> To: Lars Eggert <lars.eggert@nokia.com>, marcelo bagnulo braun <marcelo@it.uc3m.es> Date: Mon, 26 Oct 2009 06:04:55 -0400 Thread-Topic: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-02.txt Thread-Index: AcpWIWXl78NkyBkuREqSZYiVrmU42gAAl5eP Message-ID: <C70AC257.68FC%rpenno@juniper.net> In-Reply-To: <B8C0608A-10E2-4212-9662-E317CA8C5CD9@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" <behave@ietf.org> Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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: Mon, 26 Oct 2009 10:04:54 -0000 On 10/26/09 2:47 AM, "Lars Eggert" <lars.eggert@nokia.com> wrote: > Hi, >=20 > On 2009-10-26, at 9:11, marcelo bagnulo braun wrote: >> Reinaldo Penno escribi=F3: >>> Then I would suggest the following text: >>>=20 >>> "If the security policy determines that the TCP RST packet is an >>> attack it >>> can be silently drooped (There is already a similar text for V4 >>> SYNs). >>> .... >>> If the implementation tracks TCP sequence numbers and the TCP RST >>> passes its >>> security policy the connection can be moved to the CLOSED state." >>=20 >> I personally don't have an issue with adding this text. I will do so >> unless someone else has a problem and thinks it deserves more >> discussion. >=20 > objection. A NAT is *not* a security device and does not implement > "security policies." I understand your point of view but security is discussed at length in RFC4787 and RFC5382. There are many examples and the word 'policy' is used: " subject to the NAT's security policy" " if its security policy permits" " security properties of the NAT" ... Filtering behavior is also a type of security. Therefore what I'm proposing is following previous recommendations. The tex= t as exists today have security issues. >=20 > We've hit this several times in the past with different BEHAVE > document, and we've always been very careful to focus on the > "translator" functions only. (Other WGs have talked about firewall/ > security functions, e.g., V6OPS.) >=20 > Lars From iljitsch@muada.com Mon Oct 26 03:09:07 2009 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 468723A6926 for <behave@core3.amsl.com>; Mon, 26 Oct 2009 03:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H01QkT3fnJAn for <behave@core3.amsl.com>; Mon, 26 Oct 2009 03:09:06 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 37CC73A659C for <behave@ietf.org>; Mon, 26 Oct 2009 03:09:05 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.216]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n9QA8dmp030059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 26 Oct 2009 11:08:39 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <B8C0608A-10E2-4212-9662-E317CA8C5CD9@nokia.com> Date: Mon, 26 Oct 2009 11:09:09 +0100 Content-Transfer-Encoding: 7bit Message-Id: <59490F0A-C5DF-4756-A85B-A8609A97FDE9@muada.com> References: <C70A9263.68C5%rpenno@juniper.net> <4AE54B88.2090104@it.uc3m.es> <B8C0608A-10E2-4212-9662-E317CA8C5CD9@nokia.com> To: Lars Eggert <lars.eggert@nokia.com> X-Mailer: Apple Mail (2.1076) Cc: "behave@ietf.org" <behave@ietf.org> Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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: Mon, 26 Oct 2009 10:09:07 -0000 On 26 okt 2009, at 10:47, Lars Eggert wrote: > objection. A NAT is *not* a security device and does not implement > "security policies." Agree. We've had this discussion a while ago. The translator is not in a good position to know what are and what aren't legitimate reset packets. If it guesses wrong, it can either reset sessions that the host in question wanted to keep alive, or it can delay the removal of stale state. A NAT44 isn't a firewall, so in that case the above objection is relevant. But a NAT64 is even less of a firewall than a NAT44, because the IPv6 side of the translator can't be considered to be "internal". Hosts need to handle their own security, translators should stay out of this. And if and when implementers decide that they want to implement "security policies" (which would be a mistake as per the above) it's important that this functionality is kept separate from the translator functionality. From rpenno@juniper.net Mon Oct 26 03:31:22 2009 Return-Path: <rpenno@juniper.net> 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 679D13A6934 for <behave@core3.amsl.com>; Mon, 26 Oct 2009 03:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29kLhPLaW1FC for <behave@core3.amsl.com>; Mon, 26 Oct 2009 03:31:21 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 369863A6906 for <behave@ietf.org>; Mon, 26 Oct 2009 03:31:10 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKSuV6ewqCbcOxJxP1v0ttfJ9axAmFfMDT@postini.com; Mon, 26 Oct 2009 03:31:31 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 26 Oct 2009 03:29:16 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 26 Oct 2009 06:29:15 -0400 From: Reinaldo Penno <rpenno@juniper.net> To: Iljitsch van Beijnum <iljitsch@muada.com>, Lars Eggert <lars.eggert@nokia.com> Date: Mon, 26 Oct 2009 06:29:12 -0400 Thread-Topic: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-02.txt Thread-Index: AcpWJGdB4UHu7INJQ1yfO+7tlGyWtQAAsFwW Message-ID: <C70AC808.6944%rpenno@juniper.net> In-Reply-To: <59490F0A-C5DF-4756-A85B-A8609A97FDE9@muada.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" <behave@ietf.org> Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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: Mon, 26 Oct 2009 10:31:22 -0000 As I said, NAT 'security policy' term is used in RFC4787 and RFC5382. The current NAT64 document has the following text which follows from the two RFCs mentioned above. " If the **security policy** requires silently dropping externally initiated TCP connections, then the packet is silently discarded, else," " For any other IPv6 packet, depending on the **security policy** other packets MAY be forwarded or MAY be silently discarded. " " If the local **security policy** determines that ICMPv6 Informative packets are to be filtered, the packet is silently discarded." Etc.... Therefore I'm not sure as why the term 'security policy' comes as a surprise. It is in all documents and widely deployed. I feel that NAT64 should look and feel in terms of behavior (forwarding, control & security) as closely as NAT44 as possible in order to be deployed successfully. =20 Are you suggesting all those security considerations should be removed fro= m NAT64 to another document and/or deprecated in NAT44 documents? Thanks, Reinaldo On 10/26/09 3:09 AM, "Iljitsch van Beijnum" <iljitsch@muada.com> wrote: > On 26 okt 2009, at 10:47, Lars Eggert wrote: >=20 >> objection. A NAT is *not* a security device and does not implement >> "security policies." >=20 > Agree. >=20 > We've had this discussion a while ago. The translator is not in a good > position to know what are and what aren't legitimate reset packets. If > it guesses wrong, it can either reset sessions that the host in > question wanted to keep alive, or it can delay the removal of stale > state. >=20 > A NAT44 isn't a firewall, so in that case the above objection is > relevant. But a NAT64 is even less of a firewall than a NAT44, because > the IPv6 side of the translator can't be considered to be "internal". > Hosts need to handle their own security, translators should stay out > of this. >=20 > And if and when implementers decide that they want to implement > "security policies" (which would be a mistake as per the above) it's > important that this functionality is kept separate from the translator > functionality. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From iljitsch@muada.com Mon Oct 26 03:58:00 2009 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 44C713A6A51 for <behave@core3.amsl.com>; Mon, 26 Oct 2009 03:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCdMo2yEOp67 for <behave@core3.amsl.com>; Mon, 26 Oct 2009 03:57:59 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 39BAF3A694E for <behave@ietf.org>; Mon, 26 Oct 2009 03:57:59 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.216]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n9QAvYWK030306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 26 Oct 2009 11:57:34 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <C70AC808.6944%rpenno@juniper.net> Date: Mon, 26 Oct 2009 11:58:02 +0100 Content-Transfer-Encoding: 7bit Message-Id: <E7FA8BDB-6D92-4C58-8BD0-535FABC80DF5@muada.com> References: <C70AC808.6944%rpenno@juniper.net> To: Reinaldo Penno <rpenno@juniper.net> X-Mailer: Apple Mail (2.1076) Cc: "behave@ietf.org" <behave@ietf.org> Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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: Mon, 26 Oct 2009 10:58:00 -0000 On 26 okt 2009, at 11:29, Reinaldo Penno wrote: > I feel that NAT64 should look and feel in terms of behavior > (forwarding, > control & security) as closely as NAT44 as possible in order to be > deployed > successfully. No. A traditional NAT44 sits on an internal/external boundary, a place where you would naturally want to apply security policy. However, this is not the case for a NAT64, which sits more towards the middle of the network. (Same for an ISP-operated NAT44.) It makes no sense to import NAT44 baggage into NAT64. Also, BEHAVE has been writing up what NAT44s actually do, while for NAT64 we're specifying what we WANT them to do, which is a rather different approach. > Are you suggesting all those security considerations should be > removed from > NAT64 to another document and/or deprecated in NAT44 documents? Yes, I believe some of the text quoted earlier would best be removed. Obviously that doesn't mean a NAT64 document shouldn't have any security considerations, just that firewalling should be kept out of the NAT64 document. From marcelo@it.uc3m.es Mon Oct 26 04:17:11 2009 Return-Path: <marcelo@it.uc3m.es> 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 2503128C103 for <behave@core3.amsl.com>; Mon, 26 Oct 2009 04:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEkC2YCoChUo for <behave@core3.amsl.com>; Mon, 26 Oct 2009 04:17:09 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id ADFD03A697B for <behave@ietf.org>; Mon, 26 Oct 2009 04:17:09 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.30.159]) by smtp01.uc3m.es (Postfix) with ESMTP id 4BD68BA7FC6; Mon, 26 Oct 2009 12:17:21 +0100 (CET) Message-ID: <4AE58532.6070401@it.uc3m.es> Date: Mon, 26 Oct 2009 12:17:06 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Lars Eggert <lars.eggert@nokia.com> References: <C70A9263.68C5%rpenno@juniper.net> <4AE54B88.2090104@it.uc3m.es> <B8C0608A-10E2-4212-9662-E317CA8C5CD9@nokia.com> In-Reply-To: <B8C0608A-10E2-4212-9662-E317CA8C5CD9@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16970.006 Cc: "behave@ietf.org" <behave@ietf.org> Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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: Mon, 26 Oct 2009 11:17:11 -0000 Lars Eggert escribió: > Hi, > > On 2009-10-26, at 9:11, marcelo bagnulo braun wrote: >> Reinaldo Penno escribió: >>> Then I would suggest the following text: >>> >>> "If the security policy determines that the TCP RST packet is an >>> attack it >>> can be silently drooped (There is already a similar text for V4 SYNs). >>> .... >>> If the implementation tracks TCP sequence numbers and the TCP RST >>> passes its >>> security policy the connection can be moved to the CLOSED state." >> >> I personally don't have an issue with adding this text. I will do so >> unless someone else has a problem and thinks it deserves more >> discussion. > > objection. A NAT is *not* a security device and does not implement > "security policies." right, so far we have been following the behave requirements closely, so there are a few places where the security policy appears, for instance whether to silently discard packets or not. As i said, i don't have a strong opinion here. Regards, marcelo > > We've hit this several times in the past with different BEHAVE > document, and we've always been very careful to focus on the > "translator" functions only. (Other WGs have talked about > firewall/security functions, e.g., V6OPS.) > > Lars From marcelo@it.uc3m.es Mon Oct 26 04:25:51 2009 Return-Path: <marcelo@it.uc3m.es> 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 37D8E28C10D for <behave@core3.amsl.com>; Mon, 26 Oct 2009 04:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4gGoIYyERFP for <behave@core3.amsl.com>; Mon, 26 Oct 2009 04:25:50 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id E838E3A6970 for <behave@ietf.org>; Mon, 26 Oct 2009 04:25:49 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.30.159]) by smtp02.uc3m.es (Postfix) with ESMTP id C430A6C27EF; Mon, 26 Oct 2009 12:25:59 +0100 (CET) Message-ID: <4AE5873A.4090405@it.uc3m.es> Date: Mon, 26 Oct 2009 12:25:46 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Reinaldo Penno <rpenno@juniper.net> References: <C70AC808.6944%rpenno@juniper.net> In-Reply-To: <C70AC808.6944%rpenno@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16970.006 Cc: "behave@ietf.org" <behave@ietf.org> Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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: Mon, 26 Oct 2009 11:25:51 -0000 Reinaldo Penno escribió: > As I said, NAT 'security policy' term is used in RFC4787 and RFC5382. The > current NAT64 document has the following text which follows from the two > RFCs mentioned above. > > " If the **security policy** requires silently dropping externally > initiated TCP connections, then the packet is silently discarded, > else," > > " For any other IPv6 packet, depending on the **security policy** other > packets MAY be forwarded or MAY be silently discarded. " > > " If the local **security policy** determines that ICMPv6 Informative > packets are to be filtered, the packet is silently discarded." > > Etc.... > > Therefore I'm not sure as why the term 'security policy' comes as a > surprise. It is in all documents and widely deployed. > > I feel that NAT64 should look and feel in terms of behavior (forwarding, > control & security) as closely as NAT44 as possible in order to be deployed > successfully. > > Are you suggesting all those security considerations should be removed from > NAT64 to another document and/or deprecated in NAT44 documents? > Let me comment on this. Current NAT64 draft fllows as closely as possible behave requirements for nats (TCP, UDP, ICMP) so, if i have done correctly, only the cases that are explictly considered in the behave requirements as depending on the security policy are covered in the nat46 spec. I think this can eb the right approach. We build on the consensus reached on the beheva requirements. We don't add or remove any of the security considerations compared to the behave requirements. (please let me know if i a missing any of them in the current nat64 document, i will heck it mysefl in any case) Regards, marcelo > Thanks, > > Reinaldo > > > On 10/26/09 3:09 AM, "Iljitsch van Beijnum" <iljitsch@muada.com> wrote: > > >> On 26 okt 2009, at 10:47, Lars Eggert wrote: >> >> >>> objection. A NAT is *not* a security device and does not implement >>> "security policies." >>> >> Agree. >> >> We've had this discussion a while ago. The translator is not in a good >> position to know what are and what aren't legitimate reset packets. If >> it guesses wrong, it can either reset sessions that the host in >> question wanted to keep alive, or it can delay the removal of stale >> state. >> >> A NAT44 isn't a firewall, so in that case the above objection is >> relevant. But a NAT64 is even less of a firewall than a NAT44, because >> the IPv6 side of the translator can't be considered to be "internal". >> Hosts need to handle their own security, translators should stay out >> of this. >> >> And if and when implementers decide that they want to implement >> "security policies" (which would be a mistake as per the above) it's >> important that this functionality is kept separate from the translator >> functionality. >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From rpenno@juniper.net Mon Oct 26 04:39:55 2009 Return-Path: <rpenno@juniper.net> 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 A07E228C243 for <behave@core3.amsl.com>; Mon, 26 Oct 2009 04:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjOAjdh9p9Fe for <behave@core3.amsl.com>; Mon, 26 Oct 2009 04:39:54 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id DA0A83A67D1 for <behave@ietf.org>; Mon, 26 Oct 2009 04:39:49 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSuWKj4+INeyyP0lbfZ+iITK7bBZQNnAe@postini.com; Mon, 26 Oct 2009 04:40:08 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 26 Oct 2009 04:38:39 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 26 Oct 2009 07:38:38 -0400 From: Reinaldo Penno <rpenno@juniper.net> To: marcelo bagnulo braun <marcelo@it.uc3m.es> Date: Mon, 26 Oct 2009 07:38:35 -0400 Thread-Topic: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-02.txt Thread-Index: AcpWLxwE/GeoIo41T3i5ziUIT1aE3gAAb4Gd Message-ID: <C70AD84B.6990%rpenno@juniper.net> In-Reply-To: <4AE5873A.4090405@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" <behave@ietf.org> Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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: Mon, 26 Oct 2009 11:39:55 -0000 Thanks for your answer Marcelo. I think specifying the TCP state transition and associated behavior 'add ne= w security considerations' as you put it since it is something not fully discussed on the previous BEHAVE TCP RFC. Perhaps a companion document could specify TCP state tracking for NATs sinc= e it is useful and mostly common to both NAT44 and NAT64. Thanks, Reinaldo On 10/26/09 4:25 AM, "marcelo bagnulo braun" <marcelo@it.uc3m.es> wrote: > Reinaldo Penno escribi=F3: >> As I said, NAT 'security policy' term is used in RFC4787 and RFC5382. Th= e >> current NAT64 document has the following text which follows from the two >> RFCs mentioned above. >>=20 >> " If the **security policy** requires silently dropping externally >> initiated TCP connections, then the packet is silently discarded, >> else," >>=20 >> " For any other IPv6 packet, depending on the **security policy** other >> packets MAY be forwarded or MAY be silently discarded. " >>=20 >> " If the local **security policy** determines that ICMPv6 Informativ= e >> packets are to be filtered, the packet is silently discarded." >>=20 >> Etc.... >>=20 >> Therefore I'm not sure as why the term 'security policy' comes as a >> surprise. It is in all documents and widely deployed. >>=20 >> I feel that NAT64 should look and feel in terms of behavior (forwarding, >> control & security) as closely as NAT44 as possible in order to be deplo= yed >> successfully. =20 >>=20 >> Are you suggesting all those security considerations should be removed = from >> NAT64 to another document and/or deprecated in NAT44 documents? >> =20 >=20 > Let me comment on this. >=20 > Current NAT64 draft fllows as closely as possible behave requirements > for nats (TCP, UDP, ICMP) >=20 > so, if i have done correctly, only the cases that are explictly > considered in the behave requirements as depending on the security > policy are covered in the nat46 spec. > I think this can eb the right approach. We build on the consensus > reached on the beheva requirements. We don't add or remove any of the > security considerations compared to the behave requirements. >=20 > (please let me know if i a missing any of them in the current nat64 > document, i will heck it mysefl in any case) >=20 > Regards, marcelo >=20 >=20 >> Thanks, >>=20 >> Reinaldo >>=20 >>=20 >> On 10/26/09 3:09 AM, "Iljitsch van Beijnum" <iljitsch@muada.com> wrote: >>=20 >> =20 >>> On 26 okt 2009, at 10:47, Lars Eggert wrote: >>>=20 >>> =20 >>>> objection. A NAT is *not* a security device and does not implement >>>> "security policies." >>>> =20 >>> Agree. >>>=20 >>> We've had this discussion a while ago. The translator is not in a good >>> position to know what are and what aren't legitimate reset packets. If >>> it guesses wrong, it can either reset sessions that the host in >>> question wanted to keep alive, or it can delay the removal of stale >>> state. >>>=20 >>> A NAT44 isn't a firewall, so in that case the above objection is >>> relevant. But a NAT64 is even less of a firewall than a NAT44, because >>> the IPv6 side of the translator can't be considered to be "internal". >>> Hosts need to handle their own security, translators should stay out >>> of this. >>>=20 >>> And if and when implementers decide that they want to implement >>> "security policies" (which would be a mistake as per the above) it's >>> important that this functionality is kept separate from the translator >>> functionality. >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> =20 >>=20 >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >>=20 >> =20 >=20 From marcelo@it.uc3m.es Mon Oct 26 04:42:33 2009 Return-Path: <marcelo@it.uc3m.es> 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 B893B3A67D1 for <behave@core3.amsl.com>; Mon, 26 Oct 2009 04:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4HYezDir3aM for <behave@core3.amsl.com>; Mon, 26 Oct 2009 04:42:31 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id CA3EF28C258 for <behave@ietf.org>; Mon, 26 Oct 2009 04:42:30 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.30.159]) by smtp02.uc3m.es (Postfix) with ESMTP id 6CD0D6C2DB2; Mon, 26 Oct 2009 12:42:41 +0100 (CET) Message-ID: <4AE58B23.8030703@it.uc3m.es> Date: Mon, 26 Oct 2009 12:42:27 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Reinaldo Penno <rpenno@juniper.net> References: <C70AD84B.6990%rpenno@juniper.net> In-Reply-To: <C70AD84B.6990%rpenno@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16970.007 Cc: "behave@ietf.org" <behave@ietf.org> Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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: Mon, 26 Oct 2009 11:42:33 -0000 Reinaldo Penno escribió: > Thanks for your answer Marcelo. > > I think specifying the TCP state transition and associated behavior 'add new > security considerations' as you put it since it is something not fully > discussed on the previous BEHAVE TCP RFC. > > Perhaps a companion document could specify TCP state tracking for NATs since > it is useful and mostly common to both NAT44 and NAT64. > maybe that is a reasonable way forward. In the current nat64 we strictly reflect current behave requirements In addition, an additional document covers the seq number tracking and other security features and is presented to the WG for consideration. regards, marcelo > Thanks, > > Reinaldo > > > On 10/26/09 4:25 AM, "marcelo bagnulo braun" <marcelo@it.uc3m.es> wrote: > > >> Reinaldo Penno escribió: >> >>> As I said, NAT 'security policy' term is used in RFC4787 and RFC5382. The >>> current NAT64 document has the following text which follows from the two >>> RFCs mentioned above. >>> >>> " If the **security policy** requires silently dropping externally >>> initiated TCP connections, then the packet is silently discarded, >>> else," >>> >>> " For any other IPv6 packet, depending on the **security policy** other >>> packets MAY be forwarded or MAY be silently discarded. " >>> >>> " If the local **security policy** determines that ICMPv6 Informative >>> packets are to be filtered, the packet is silently discarded." >>> >>> Etc.... >>> >>> Therefore I'm not sure as why the term 'security policy' comes as a >>> surprise. It is in all documents and widely deployed. >>> >>> I feel that NAT64 should look and feel in terms of behavior (forwarding, >>> control & security) as closely as NAT44 as possible in order to be deployed >>> successfully. >>> >>> Are you suggesting all those security considerations should be removed from >>> NAT64 to another document and/or deprecated in NAT44 documents? >>> >>> >> Let me comment on this. >> >> Current NAT64 draft fllows as closely as possible behave requirements >> for nats (TCP, UDP, ICMP) >> >> so, if i have done correctly, only the cases that are explictly >> considered in the behave requirements as depending on the security >> policy are covered in the nat46 spec. >> I think this can eb the right approach. We build on the consensus >> reached on the beheva requirements. We don't add or remove any of the >> security considerations compared to the behave requirements. >> >> (please let me know if i a missing any of them in the current nat64 >> document, i will heck it mysefl in any case) >> >> Regards, marcelo >> >> >> >>> Thanks, >>> >>> Reinaldo >>> >>> >>> On 10/26/09 3:09 AM, "Iljitsch van Beijnum" <iljitsch@muada.com> wrote: >>> >>> >>> >>>> On 26 okt 2009, at 10:47, Lars Eggert wrote: >>>> >>>> >>>> >>>>> objection. A NAT is *not* a security device and does not implement >>>>> "security policies." >>>>> >>>>> >>>> Agree. >>>> >>>> We've had this discussion a while ago. The translator is not in a good >>>> position to know what are and what aren't legitimate reset packets. If >>>> it guesses wrong, it can either reset sessions that the host in >>>> question wanted to keep alive, or it can delay the removal of stale >>>> state. >>>> >>>> A NAT44 isn't a firewall, so in that case the above objection is >>>> relevant. But a NAT64 is even less of a firewall than a NAT44, because >>>> the IPv6 side of the translator can't be considered to be "internal". >>>> Hosts need to handle their own security, translators should stay out >>>> of this. >>>> >>>> And if and when implementers decide that they want to implement >>>> "security policies" (which would be a mistake as per the above) it's >>>> important that this functionality is kept separate from the translator >>>> functionality. >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >>>> >>>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >>> >>> > > > From rpenno@juniper.net Mon Oct 26 04:47:15 2009 Return-Path: <rpenno@juniper.net> 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 366A93A68FE for <behave@core3.amsl.com>; Mon, 26 Oct 2009 04:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Du+sqyDmvND5 for <behave@core3.amsl.com>; Mon, 26 Oct 2009 04:47:14 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 0FAAA3A68EE for <behave@ietf.org>; Mon, 26 Oct 2009 04:47:09 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSuWMS7K8Lo9Edhw6Jn5qV6GC11XJ0rjw@postini.com; Mon, 26 Oct 2009 04:47:27 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 26 Oct 2009 04:45:12 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 26 Oct 2009 07:45:11 -0400 From: Reinaldo Penno <rpenno@juniper.net> To: Iljitsch van Beijnum <iljitsch@muada.com> Date: Mon, 26 Oct 2009 07:45:09 -0400 Thread-Topic: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-02.txt Thread-Index: AcpWKzjVsBfEQl6VSZqEM1/5W7VzLAABowMB Message-ID: <C70AD9D5.6994%rpenno@juniper.net> In-Reply-To: <E7FA8BDB-6D92-4C58-8BD0-535FABC80DF5@muada.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" <behave@ietf.org> Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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: Mon, 26 Oct 2009 11:47:15 -0000 On 10/26/09 3:58 AM, "Iljitsch van Beijnum" <iljitsch@muada.com> wrote: > On 26 okt 2009, at 11:29, Reinaldo Penno wrote: >=20 >> I feel that NAT64 should look and feel in terms of behavior >> (forwarding, >> control & security) as closely as NAT44 as possible in order to be >> deployed >> successfully. >=20 > No. A traditional NAT44 sits on an internal/external boundary, a place > where you would naturally want to apply security policy. However, this > is not the case for a NAT64, which sits more towards the middle of the > network. (Same for an ISP-operated NAT44.) If an enterprise starts using IPv6 where do you think it will sit? I would suggest that it will sit where NAT44 sits today and not in the middle of th= e network somewhere as you mention. Why do you think this is not a valid case or have such a narrow view of NAT64? I think NAT64 applicability statement should be clarified in the document.=20 It makes no sense to import > NAT44 baggage into NAT64. Also, BEHAVE has been writing up what NAT44s > actually do, while for NAT64 we're specifying what we WANT them to do, > which is a rather different approach. Agreed, but operators are used to the look and feel of NAT44 and since NAT6= 4 will in many occupy a similar position and perform similar function, operators will want similar behavior. I think emails in this regard were already sent to the list. >=20 >> Are you suggesting all those security considerations should be >> removed from >> NAT64 to another document and/or deprecated in NAT44 documents? >=20 > Yes, I believe some of the text quoted earlier would best be removed. That seems at odds with the general consensus with the document until now..= . Regardless, the security text in the current document and the points I raised around NAT64 would still need to be documented somewhere. There is a= n interesting document about this subject. http://tools.ietf.org/html/draft-gont-behave-nat-security-01 > Obviously that doesn't mean a NAT64 document shouldn't have any > security considerations, just that firewalling should be kept out of > the NAT64 document. From iljitsch@muada.com Mon Oct 26 04:56:07 2009 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 8DFA728C251 for <behave@core3.amsl.com>; Mon, 26 Oct 2009 04:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXkp6TTFNg4l for <behave@core3.amsl.com>; Mon, 26 Oct 2009 04:56:06 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 82A563A67F3 for <behave@ietf.org>; Mon, 26 Oct 2009 04:56:06 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.216]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n9QBtb1T030762 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 26 Oct 2009 12:55:38 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <C70AD9D5.6994%rpenno@juniper.net> Date: Mon, 26 Oct 2009 12:56:08 +0100 Content-Transfer-Encoding: 7bit Message-Id: <6D9F9B2D-BEAB-4EF0-9465-CB9A4054C21B@muada.com> References: <C70AD9D5.6994%rpenno@juniper.net> To: Reinaldo Penno <rpenno@juniper.net> X-Mailer: Apple Mail (2.1076) Cc: "behave@ietf.org" <behave@ietf.org> Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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: Mon, 26 Oct 2009 11:56:07 -0000 On 26 okt 2009, at 12:45, Reinaldo Penno wrote: > If an enterprise starts using IPv6 where do you think it will sit? I don't know. The point of NAT64 is that ISPs run it for their customers. But I do know that enterprises are paranoid enough to have separate firewalls rather than depend on the way a NAT64 may or may not filter TCP resets. Filtering packets is not a core function of a NAT64 so it shouldn't do any packet filtering as such, rather than adopt the notion "hey, these are packets that some other boxes would filter out so let's filter them out here, too!" Airplanes have wheels. That doesn't mean we require pilots to have a driver's license. Also, the end-to-end principle applies here: hosts need to validate resets anyway, so there is no point in doing that in the middle of the network, too. > There is an > interesting document about this subject. > http://tools.ietf.org/html/draft-gont-behave-nat-security-01 I wasn't very impressed with the previous documents in this series, so I'll save myself and the author the aggravation of reading it and then firing off a bunch of criticisms. From cb.list6@gmail.com Mon Oct 26 08:26:35 2009 Return-Path: <cb.list6@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 0A2B53A697E for <behave@core3.amsl.com>; Mon, 26 Oct 2009 08:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 CBs+YJPkhMSf for <behave@core3.amsl.com>; Mon, 26 Oct 2009 08:26:34 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id 00E593A67FC for <behave@ietf.org>; Mon, 26 Oct 2009 08:26:33 -0700 (PDT) Received: by pxi6 with SMTP id 6so432295pxi.31 for <behave@ietf.org>; Mon, 26 Oct 2009 08:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ox5sVNoRKcEF4+9lfL+NZ/RcjipvSsdB1wR4oo47Hqw=; b=Z10GMhj3VawTb8DZCTk+mLnwhMH79PJe08IWsvy/TSYWH6SaXr+FvO0kj+jrUnmM3Z Nm2BsQNbqZuymA2NLxWo1LETRJhxu/OjqJxh0j5lh6S1FlKQkY3aNnlm19u9YNP9/ryS Bl+BgjCp1DR8oVh8C4NE/kHYKTnL7yxvUpGP0= 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=rubzy+q2XrqdNF9rmcLTa3hKmKw0bS9Cg+UQuQ7Zy0rQnHFLVQE5oYorVza6QYwaxV TKHk44ks8ZXpEVodxwyMovbr3/jT5YS4jHG1g2ejslqWXIoZo3ZvL/sb806S3ltNHnmX MyOW5tsXB71ogpSE1L1pKB60K0ZSmfTrZNNm0= MIME-Version: 1.0 Received: by 10.142.67.29 with SMTP id p29mr1112786wfa.89.1256570804203; Mon, 26 Oct 2009 08:26:44 -0700 (PDT) In-Reply-To: <C70AD9D5.6994%rpenno@juniper.net> References: <E7FA8BDB-6D92-4C58-8BD0-535FABC80DF5@muada.com> <C70AD9D5.6994%rpenno@juniper.net> Date: Mon, 26 Oct 2009 08:26:44 -0700 Message-ID: <bcff0fba0910260826o3680f925he836b7834c70a8be@mail.gmail.com> From: Cameron Byrne <cb.list6@gmail.com> To: Reinaldo Penno <rpenno@juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "behave@ietf.org" <behave@ietf.org> Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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: Mon, 26 Oct 2009 15:26:35 -0000 On Mon, Oct 26, 2009 at 4:45 AM, Reinaldo Penno <rpenno@juniper.net> wrote: > > > > On 10/26/09 3:58 AM, "Iljitsch van Beijnum" <iljitsch@muada.com> wrote: > >> On 26 okt 2009, at 11:29, Reinaldo Penno wrote: >> >>> I feel that NAT64 should look and feel in terms of behavior >>> (forwarding, >>> control & security) as closely as NAT44 as possible in order to be >>> deployed >>> successfully. Agreed. NAT64 should be about service continuity with NAT44. I understand the point about baggage of NAT44, but my ideal is that i go from NAT44 to NAT64 and my customers (excluding the uber-techy 2%) never know it happened. NAT44 is the service they pay for today, and it is the service my operations folks are comfortable delivering and supporting. >> >> No. A traditional NAT44 sits on an internal/external boundary, a place >> where you would naturally want to apply security policy. However, this >> is not the case for a NAT64, which sits more towards the middle of the >> network. (Same for an ISP-operated NAT44.) > > If an enterprise starts using IPv6 where do you think it will sit? I woul= d > suggest that it will sit where NAT44 sits today and not in the middle of = the > network somewhere as you mention. > > Why do you think this is not a valid case or have such a narrow view of > NAT64? I think NAT64 applicability statement should be clarified in the > document. > > > It makes no sense to import >> NAT44 baggage into NAT64. Also, BEHAVE has been writing up what NAT44s >> actually do, while for NAT64 we're specifying what we WANT them to do, >> which is a rather different approach. > > Agreed, but operators are used to the look and feel of NAT44 and since NA= T64 > will in many occupy a similar position and perform similar function, > operators will want similar behavior. I think emails in this regard were > already sent to the list. I agree with Reinaldo here. Many operators will see the NAT64 as an enhancement to existing NAT44 software / hardware / topology. In my deployment, i expect the NAT64 to bridge between my dual-stack / 6VPE network and the IPv4 internet ... so my NAT64 will be on the border to the v4 Internet. I control the servers and services within my network, so i can make them either dual-stack or leverage the front-end load balancers to do the internetworking as required. I will not use NAT64 for interworking for flows that originate and terminate in my network. > >> >>> Are you suggesting =A0all those security considerations should be >>> removed from >>> NAT64 to another document and/or deprecated in NAT44 documents? >> >> Yes, I believe some of the text quoted earlier would best be removed. > > That seems at odds with the general consensus with the document until now= ... > > Regardless, the security text in the current document and the points I > raised around NAT64 would still need to be documented somewhere. There is= an > interesting document about this subject. > > http://tools.ietf.org/html/draft-gont-behave-nat-security-01 > >> Obviously that doesn't mean a NAT64 document shouldn't have any >> security considerations, just that firewalling should be kept out of >> the NAT64 document. We also must not neglect the fact that many (the majority?) of the NAT64 boxes and boxes to be have a "day job" of being a firewall. That said, we don't want to have NAT64 to preclude the value that the underlying firewall platform may have. I am not saying NAT64 needs to be a security device, i wont go near that can of worms, but we just don't want to preclude the platform from having those features as a part of a product. Then again, the vendors frequently can build the knobs to turn the security on and off. So, lets just craft the language so that it does not paint folks into having to be non-compliant which is bad for them and bad for the standard. > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From root@core3.amsl.com Mon Oct 26 08:45:01 2009 Return-Path: <root@core3.amsl.com> X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 550F23A6A8F; Mon, 26 Oct 2009 08:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026154501.550F23A6A8F@core3.amsl.com> Date: Mon, 26 Oct 2009 08:45:01 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-address-format-01.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: Mon, 26 Oct 2009 15:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : IPv6 Addressing of IPv4/IPv6 Translators Author(s) : C. Huitema, et al. Filename : draft-ietf-behave-address-format-01.txt Pages : 15 Date : 2009-10-26 This document discusses how an individual IPv6 address can be algorithmically translated to a corresponding IPv4 address, and vice versa, using only statically configured information. This technique is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-address-format-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-address-format-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26084158.I-D@ietf.org> --NextPart-- From iljitsch@muada.com Mon Oct 26 08:51:57 2009 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 5F7783A67B5 for <behave@core3.amsl.com>; Mon, 26 Oct 2009 08:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-kS2k0LfqLV for <behave@core3.amsl.com>; Mon, 26 Oct 2009 08:51:56 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 24B8C3A681B for <behave@ietf.org>; Mon, 26 Oct 2009 08:51:55 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.216]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n9QFpUQs032334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 26 Oct 2009 16:51:30 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <bcff0fba0910260826o3680f925he836b7834c70a8be@mail.gmail.com> Date: Mon, 26 Oct 2009 16:52:00 +0100 Content-Transfer-Encoding: 7bit Message-Id: <4443745B-D636-430D-A41B-987D3E753EAB@muada.com> References: <E7FA8BDB-6D92-4C58-8BD0-535FABC80DF5@muada.com> <C70AD9D5.6994%rpenno@juniper.net> <bcff0fba0910260826o3680f925he836b7834c70a8be@mail.gmail.com> To: Cameron Byrne <cb.list6@gmail.com> X-Mailer: Apple Mail (2.1076) Cc: "behave@ietf.org" <behave@ietf.org> Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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: Mon, 26 Oct 2009 15:51:57 -0000 On 26 okt 2009, at 16:26, Cameron Byrne wrote: > Agreed. NAT64 should be about service continuity with NAT44. I > understand the point about baggage of NAT44, but my ideal is that i go > from NAT44 to NAT64 and my customers (excluding the uber-techy 2%) > never know it happened. Sorry, I have to disagree. NAT64 lives in the IPv6 world. In IPv6, there is no NAT. So there are no existing ideas about what a NAT should do, either. So what we need to do is break as little as we can. Since there is no presumption that a NAT64 is going to protect IPv6 hosts (and obviously it isn't because it doesn't sit between IPv6-to-IPv6 communications) that means filtering as little as possible. From lars.eggert@nokia.com Mon Oct 26 09:25:48 2009 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 9B6083A6A98 for <behave@core3.amsl.com>; Mon, 26 Oct 2009 09:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GL-8W6uQTQPu for <behave@core3.amsl.com>; Mon, 26 Oct 2009 09:25:47 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 867E13A6A83 for <behave@ietf.org>; Mon, 26 Oct 2009 09:25:47 -0700 (PDT) Received: from [IPv6:2001:14b8:18f::225:ff:fe45:eccf] ([IPv6:2001:14b8:18f:0:225:ff:fe45:eccf]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n9QGPghH003523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Oct 2009 18:25:43 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-34--905736469; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert <lars.eggert@nokia.com> In-Reply-To: <bcff0fba0910260826o3680f925he836b7834c70a8be@mail.gmail.com> Date: Mon, 26 Oct 2009 18:25:37 +0200 Message-Id: <2BD9ADC2-F76F-461B-9488-AB5C7834F3EA@nokia.com> References: <E7FA8BDB-6D92-4C58-8BD0-535FABC80DF5@muada.com> <C70AD9D5.6994%rpenno@juniper.net> <bcff0fba0910260826o3680f925he836b7834c70a8be@mail.gmail.com> To: Cameron Byrne <cb.list6@gmail.com> X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [IPv6:2001:708:40:fff1::1]); Mon, 26 Oct 2009 18:25:43 +0200 (EET) Cc: "behave@ietf.org" <behave@ietf.org> Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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: Mon, 26 Oct 2009 16:25:48 -0000 --Apple-Mail-34--905736469 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes On 2009-10-26, at 17:26, Cameron Byrne wrote: > We also must not neglect the fact that many (the majority?) of the > NAT64 boxes and boxes to be have a "day job" of being a firewall. Nobody is saying that a vendor cannot or should not implement both NAT'ing and firewalling functions on the same piece of hardware. But there is no need to conflate the two functions in one IETF specification. The draft should describe how to NAT v6 to v4 in a stateful way. Nothing more, nothing less. How to implement firewall functions is orthogonal to that. Lars --Apple-Mail-34--905736469 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTAyNjE2MjUzOFowIwYJKoZIhvcNAQkEMRYEFF8NrQmkpgIzpK7UthF//4gAFjRsMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQA/eK5LCR2Hd4chVXRnBvxprHo15llABPvGBQ2BcrFYsrg+xYs+pQCe5wy7yrExfdyZt1ys kIcu92ejl/KenrCBF2/gupwbd7NU5rb138rTzF7AtQ92Ni68vMfndwBrhWPRZK707/J6zxqSRhhj vNdVoKHG/GuQeeXQ8sIKWAQB/NppyHFxxrKZqBhOjknVUWAU3RqOV5lf0cIg4l1Mxmat0rWFqpHS i1B0e7Yu4+oVDvtORdzsqTXFO/9ODgiysqHvoeJsaTJRKWOq9DLLAijMxDoR8NSgAtS4JboV8rjQ 4Lvib/fQJpRbReK9tfHsMrz4f0fILqBxe4+CXWwJvuaNAAAAAAAA --Apple-Mail-34--905736469-- From eric.burgey@orange-ftgroup.com Mon Oct 26 09:55:54 2009 Return-Path: <eric.burgey@orange-ftgroup.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 3264228C114 for <behave@core3.amsl.com>; Mon, 26 Oct 2009 09:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 dPONc93uwbjF for <behave@core3.amsl.com>; Mon, 26 Oct 2009 09:55:52 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 734AD28C107 for <behave@ietf.org>; Mon, 26 Oct 2009 09:55:52 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 17:56:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 17:56:01 +0100 Message-ID: <08BA2C59E081884DB2AAE4A0BE9D6DC1840DA4@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <20091026154501.550F23A6A8F@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] I-D Action:draft-ietf-behave-address-format-01.txt Thread-Index: AcpWU8ReAgGJr6NTTimZZss6fyypAgABvagA References: <20091026154501.550F23A6A8F@core3.amsl.com> From: <eric.burgey@orange-ftgroup.com> To: <behave@ietf.org> X-OriginalArrivalTime: 26 Oct 2009 16:56:03.0683 (UTC) FILETIME=[33F08B30:01CA565D] Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-address-format-01.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: Mon, 26 Oct 2009 16:55:54 -0000 Hi, I have some difficulties to understand the figure in chapter 2. An IPv6 address is only 16 byte long and not 17. More precisely it is difficult to understand the last line of the = figure. Is it a /96 prefix without byte u or is it a /88 prefix with a u byte ? Best regards Eric BURGEY France TELECOM Orange Labs =20 -----Message d'origine----- De=A0: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la = part de Internet-Drafts@ietf.org Envoy=E9=A0: lundi 26 octobre 2009 16:45 =C0=A0: i-d-announce@ietf.org Cc=A0: behave@ietf.org Objet=A0: [BEHAVE] I-D Action:draft-ietf-behave-address-format-01.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Behavior Engineering for Hindrance = Avoidance Working Group of the IETF. Title : IPv6 Addressing of IPv4/IPv6 Translators Author(s) : C. Huitema, et al. Filename : draft-ietf-behave-address-format-01.txt Pages : 15 Date : 2009-10-26 This document discusses how an individual IPv6 address can be algorithmically translated to a corresponding IPv4 address, and vice versa, using only statically configured information. This technique is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-address-format-01.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From rpenno@juniper.net Mon Oct 26 09:57:56 2009 Return-Path: <rpenno@juniper.net> 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 6F66A28C280 for <behave@core3.amsl.com>; Mon, 26 Oct 2009 09:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.589 X-Spam-Level: X-Spam-Status: No, score=-6.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUZwFjLKgWW3 for <behave@core3.amsl.com>; Mon, 26 Oct 2009 09:57:55 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id B114C28C250 for <behave@ietf.org>; Mon, 26 Oct 2009 09:57:52 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSuXVHkCn3QP0lFt1N6CSr2dSMYTih6/I@postini.com; Mon, 26 Oct 2009 09:58:09 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 26 Oct 2009 09:54:33 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 26 Oct 2009 12:54:32 -0400 From: Reinaldo Penno <rpenno@juniper.net> To: Iljitsch van Beijnum <iljitsch@muada.com>, Cameron Byrne <cb.list6@gmail.com> Date: Mon, 26 Oct 2009 12:54:30 -0400 Thread-Topic: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-02.txt Thread-Index: AcpWVEkxbp/THJcHR1qcv/ohWcFnkwACLLqC Message-ID: <C70B2256.6A03%rpenno@juniper.net> In-Reply-To: <4443745B-D636-430D-A41B-987D3E753EAB@muada.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" <behave@ietf.org> Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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: Mon, 26 Oct 2009 16:57:56 -0000 On 10/26/09 8:52 AM, "Iljitsch van Beijnum" <iljitsch@muada.com> wrote: > On 26 okt 2009, at 16:26, Cameron Byrne wrote: >=20 >> Agreed. NAT64 should be about service continuity with NAT44. I >> understand the point about baggage of NAT44, but my ideal is that i go >> from NAT44 to NAT64 and my customers (excluding the uber-techy 2%) >> never know it happened. >=20 > Sorry, I have to disagree. >=20 > NAT64 lives in the IPv6 world. In IPv6, there is no NAT. There has been NAT in IPv6 since 8 years ago with NAT-PT. This effort is an update to NAT-PT. So there are =20 > no existing ideas about what a NAT should do, either. So what we need > to do is break as little as we can. Since there is no presumption that > a NAT64 is going to protect IPv6 hosts (and obviously it isn't because > it doesn't sit between IPv6-to-IPv6 communications) We have NAT66 for that. > filtering as little as possible. >=20 From rpenno@juniper.net Mon Oct 26 10:13:09 2009 Return-Path: <rpenno@juniper.net> 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 D69773A697C for <behave@core3.amsl.com>; Mon, 26 Oct 2009 10:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.29 X-Spam-Level: X-Spam-Status: No, score=-6.29 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2N7hNwqvPnb for <behave@core3.amsl.com>; Mon, 26 Oct 2009 10:13:09 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 795CE3A67AC for <behave@ietf.org>; Mon, 26 Oct 2009 10:13:04 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKSuXYrazi87xNzR5gLLPM/SYalrF7D6oF@postini.com; Mon, 26 Oct 2009 10:13:21 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 26 Oct 2009 10:10:11 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 26 Oct 2009 13:10:10 -0400 From: Reinaldo Penno <rpenno@juniper.net> To: Lars Eggert <lars.eggert@nokia.com>, Cameron Byrne <cb.list6@gmail.com> Date: Mon, 26 Oct 2009 13:10:07 -0400 Thread-Topic: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-02.txt Thread-Index: AcpWWQluEJQtbD9jQS2CVC9+NrKGAQABiEoj Message-ID: <C70B25FF.6A0F%rpenno@juniper.net> In-Reply-To: <2BD9ADC2-F76F-461B-9488-AB5C7834F3EA@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" <behave@ietf.org> Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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: Mon, 26 Oct 2009 17:13:10 -0000 I think we are talking about NAT specific filtering behavior: port + addres= s filtering which is a NAT property, translations of unsolicited packets, dropping certain packets due to state of translation. A firewall as a separate entity (or software system) as you advocate would not have access to NAT binding/map tables or policies and therefore cannot perform such functions. Or maybe you are suggesting something different? On 10/26/09 9:25 AM, "Lars Eggert" <lars.eggert@nokia.com> wrote: > On 2009-10-26, at 17:26, Cameron Byrne wrote: >> We also must not neglect the fact that many (the majority?) of the >> NAT64 boxes and boxes to be have a "day job" of being a firewall. >=20 > Nobody is saying that a vendor cannot or should not implement both > NAT'ing and firewalling functions on the same piece of hardware. But > there is no need to conflate the two functions in one IETF > specification. >=20 > The draft should describe how to NAT v6 to v4 in a stateful way. > Nothing more, nothing less. How to implement firewall functions is > orthogonal to that. >=20 > Lars From dwing@cisco.com Mon Oct 26 10:20:18 2009 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 086B528C232 for <behave@core3.amsl.com>; Mon, 26 Oct 2009 10:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.125 X-Spam-Level: X-Spam-Status: No, score=-5.125 tagged_above=-999 required=5 tests=[AWL=-0.976, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n294diNia2bm for <behave@core3.amsl.com>; Mon, 26 Oct 2009 10:20:17 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4F2843A6B0F for <behave@ietf.org>; Mon, 26 Oct 2009 10:19:16 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAKd25UqrR7H+/2dsb2JhbACEcoVttkCHCwiPf4EugjpXBIFefw X-IronPort-AV: E=Sophos;i="4.44,626,1249257600"; d="scan'208";a="418122920" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 26 Oct 2009 17:19:29 +0000 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9QHJTbZ021977; Mon, 26 Oct 2009 17:19:29 GMT From: "Dan Wing" <dwing@cisco.com> To: <shengjiang@huawei.com>, "'Iljitsch van Beijnum'" <iljitsch@muada.com>, "'liu dapeng'" <maxpassion@gmail.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> <25e1aaa40910230404m4517c64ew2a04e610cc6f2bcd@mail.gmail.com> <D1DA2BB2-E064-4656-B75A-A10339A1B9FB@muada.com> <86F15BB9FC58443ABF2071A5CC843384@JiangXiong> Date: Mon, 26 Oct 2009 10:19:29 -0700 Message-ID: <09be01ca5660$7a1de870$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpT0ZU0bBbYNw/2ThmwEFd5/tu9WAAvNfQQAHQB9YA= In-Reply-To: <86F15BB9FC58443ABF2071A5CC843384@JiangXiong> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: =?GB2312?B?J8H1tPPF9Cc=?= <liudapeng@chinamobile.com>, =?GB2312?B?J7Lc1fEn?= <caozhen@chinamobile.com>, 'bo zhou' <zhouboyj@gmail.com>, behave@ietf.org, 'Behave Chairs' <behave-chairs@tools.ietf.org> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 26 Oct 2009 17:20:18 -0000 Looking at http://tools.ietf.org/rfcdiff?url2=3Ddraft-van-beijnum-behave-ftp64-06.tx= t and reviewing draft-liu-behave-ftp64-03, I believe the change caused by draft-liu-behave-ftp64 was the new paragraph in Section 6, "ALG = Functionality" starting with "On the other hand,". Is that correct? If that is all = that was incorporated, it falls below my threshold for adding a second author, = and rewording the Acknowledgements to better acknowledge the contribution = seems adequate along the lines of "Dapeng Liu and Zhen Cao suggested that = network operators encourage upgrading FTP clients rather than deploy an FTP = ALG." -d > -----Original Message----- > From: Sheng Jiang [mailto:shengjiang@huawei.com]=20 > Sent: Saturday, October 24, 2009 2:48 AM > To: 'Iljitsch van Beijnum'; 'liu dapeng' > Cc: '=C1=F5=B4=F3=C5=F4'; '=B2=DC=D5=F1'; behave@ietf.org; 'Behave = Chairs'; 'Dan=20 > Wing'; 'Sheng Jiang' > Subject: RE: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06=20 > as WG item >=20 > Hi, >=20 > I support to adopt the draft as WG documentation. >=20 > However, the author wrote in the draft: =A1=B0Versions -05 and -06 of = this > document adopts several important design decisions from > [I-D.liu-behave-ftp64].=A1=B1 Should at least one author from > draft-liu-behave-ftp64 deserve to be co-author of this > draft-van-beijnum-behave-ftp64? >=20 > Best wishes, >=20 > Sheng >=20 > > -----Original Message----- > > From: behave-bounces@ietf.org=20 > [mailto:behave-bounces@ietf.org] On Behalf > Of > > Iljitsch van Beijnum > > Sent: Friday, October 23, 2009 7:11 PM > > To: liu dapeng > > Cc: =C1=F5=B4=F3=C5=F4; =B2=DC=D5=F1; behave@ietf.org; Behave = Chairs; Dan Wing > > Subject: Re: [BEHAVE] adopt=20 > draft-van-beijnum-behave-ftp64-06 as WG item > >=20 > > On 23 okt 2009, at 13:04, liu dapeng wrote: > >=20 > > > We know that there are two drafts discussing the ftp64=20 > issue. Would > > > the WG consider merging draft-van-beijnum-behave-ftp64 and > > > draft-liu-behave-ftp64 as the WG document? > >=20 > > Do you feel the current text in draft-van-beijnum-behave-ftp64-06 > > doesn't address your previous objections? > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave >=20 From dthaler@microsoft.com Mon Oct 26 11:36:09 2009 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 7D87928C123 for <behave@core3.amsl.com>; Mon, 26 Oct 2009 11:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmYJl4QcGAyY for <behave@core3.amsl.com>; Mon, 26 Oct 2009 11:36:08 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 982633A69A8 for <behave@ietf.org>; Mon, 26 Oct 2009 11:36:08 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 26 Oct 2009 11:36:33 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server id 14.0.639.20; Mon, 26 Oct 2009 11:35:38 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Mon, 26 Oct 2009 11:35:39 -0700 From: Dave Thaler <dthaler@microsoft.com> To: "eric.burgey@orange-ftgroup.com" <eric.burgey@orange-ftgroup.com>, "behave@ietf.org" <behave@ietf.org> Thread-Topic: [BEHAVE] I-D Action:draft-ietf-behave-address-format-01.txt Thread-Index: AQHKVlO7mkjY2PBSYkK6sa15IDFs5JEYgxWA//+lyDA= Date: Mon, 26 Oct 2009 18:35:36 +0000 Message-ID: <E4561B14EE2A3E4E9D478EBFB5416E1B29B1BF4E@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> References: <20091026154501.550F23A6A8F@core3.amsl.com> <08BA2C59E081884DB2AAE4A0BE9D6DC1840DA4@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <08BA2C59E081884DB2AAE4A0BE9D6DC1840DA4@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-address-format-01.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: Mon, 26 Oct 2009 18:36:09 -0000 I agree the figure looks incorrect. I believe the intent was to look like this: +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |PLEN| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-| +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/32 | prefix |v4(32) | u | suffix | +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/40 | prefix |v4(24) | u |(8)| suffix | +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/48 | prefix |v4(16) | u | (16) | suffix | +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/56 | prefix |(8)| u | v4(24) | suffix | +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/64 | prefix | u | v4(32) | suffix | +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/96 | prefix | v4(32) | +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ -Dave > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of eric.burgey@orange-ftgroup.com > Sent: Monday, October 26, 2009 9:56 AM > To: behave@ietf.org > Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-address-format- > 01.txt >=20 > Hi, > I have some difficulties to understand the figure in chapter 2. > An IPv6 address is only 16 byte long and not 17. > More precisely it is difficult to understand the last line of the > figure. > Is it a /96 prefix without byte u or is it a /88 prefix with a u byte ? >=20 > Best regards >=20 > Eric BURGEY >=20 > France TELECOM > Orange Labs >=20 >=20 >=20 > -----Message d'origine----- > De=A0: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la > part de Internet-Drafts@ietf.org > Envoy=E9=A0: lundi 26 octobre 2009 16:45 > =C0=A0: i-d-announce@ietf.org > Cc=A0: behave@ietf.org > Objet=A0: [BEHAVE] I-D Action:draft-ietf-behave-address-format-01.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Behavior Engineering for Hindrance > Avoidance Working Group of the IETF. >=20 >=20 > Title : IPv6 Addressing of IPv4/IPv6 Translators > Author(s) : C. Huitema, et al. > Filename : draft-ietf-behave-address-format-01.txt > Pages : 15 > Date : 2009-10-26 >=20 > This document discusses how an individual IPv6 address can be > algorithmically translated to a corresponding IPv4 address, and vice > versa, using only statically configured information. This technique > is used in IPv4/IPv6 translators, as well as other types of proxies > and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-address-format- > 01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dthaler@microsoft.com Mon Oct 26 11:43:56 2009 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 7F95428C2B6 for <behave@core3.amsl.com>; Mon, 26 Oct 2009 11:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giG0sualOAwF for <behave@core3.amsl.com>; Mon, 26 Oct 2009 11:43:55 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 8D6B128C19A for <behave@ietf.org>; Mon, 26 Oct 2009 11:43:55 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 26 Oct 2009 11:44:20 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server id 14.0.639.20; Mon, 26 Oct 2009 11:44:07 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Mon, 26 Oct 2009 11:44:07 -0700 From: Dave Thaler <dthaler@microsoft.com> To: Dave Thaler <dthaler@microsoft.com>, "eric.burgey@orange-ftgroup.com" <eric.burgey@orange-ftgroup.com>, "behave@ietf.org" <behave@ietf.org> Thread-Topic: [BEHAVE] I-D Action:draft-ietf-behave-address-format-01.txt Thread-Index: AQHKVlO7mkjY2PBSYkK6sa15IDFs5JEYgxWA//+lyDCAAAKLoA== Date: Mon, 26 Oct 2009 18:44:05 +0000 Message-ID: <E4561B14EE2A3E4E9D478EBFB5416E1B29B1C0D8@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> References: <20091026154501.550F23A6A8F@core3.amsl.com> <08BA2C59E081884DB2AAE4A0BE9D6DC1840DA4@ftrdmel0.rd.francetelecom.fr> <E4561B14EE2A3E4E9D478EBFB5416E1B29B1BF4E@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <E4561B14EE2A3E4E9D478EBFB5416E1B29B1BF4E@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-address-format-01.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: Mon, 26 Oct 2009 18:43:56 -0000 I missed answering Eric's second question, about why "u" isn't in the last line. I agree it should be. If the prefix is a well-known /96 prefix, then the well-known prefix would have the u bits specified correctly by IANA. If the prefix is a network-specific prefix, or a shorter well-known= =20 prefix, then the use of the "u" should be no different from any other line. -Dave > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Dave Thaler > Sent: Monday, October 26, 2009 11:36 AM > To: eric.burgey@orange-ftgroup.com; behave@ietf.org > Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-address-format- > 01.txt >=20 > I agree the figure looks incorrect. > I believe the intent was to look like this: >=20 > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- > --+ > |PLEN| 0-------------32--40--48--56--64--72--80--88--96--104-112- > 120-| > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- > --+ > |/32 | prefix |v4(32) | u | suffix > | > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- > --+ > |/40 | prefix |v4(24) | u |(8)| suffix > | > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- > --+ > |/48 | prefix |v4(16) | u | (16) | suffix > | > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- > --+ > |/56 | prefix |(8)| u | v4(24) | suffix > | > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- > --+ > |/64 | prefix | u | v4(32) | suffix > | > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- > --+ > |/96 | prefix | v4(32) > | > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- > --+ >=20 > -Dave >=20 > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of eric.burgey@orange-ftgroup.com > > Sent: Monday, October 26, 2009 9:56 AM > > To: behave@ietf.org > > Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-address-format- > > 01.txt > > > > Hi, > > I have some difficulties to understand the figure in chapter 2. > > An IPv6 address is only 16 byte long and not 17. > > More precisely it is difficult to understand the last line of the > > figure. > > Is it a /96 prefix without byte u or is it a /88 prefix with a u byte > ? > > > > Best regards > > > > Eric BURGEY > > > > France TELECOM > > Orange Labs > > > > > > > > -----Message d'origine----- > > De=A0: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la > > part de Internet-Drafts@ietf.org > > Envoy=E9=A0: lundi 26 octobre 2009 16:45 > > =C0=A0: i-d-announce@ietf.org > > Cc=A0: behave@ietf.org > > Objet=A0: [BEHAVE] I-D Action:draft-ietf-behave-address-format-01.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Behavior Engineering for Hindrance > > Avoidance Working Group of the IETF. > > > > > > Title : IPv6 Addressing of IPv4/IPv6 Translators > > Author(s) : C. Huitema, et al. > > Filename : draft-ietf-behave-address-format-01.txt > > Pages : 15 > > Date : 2009-10-26 > > > > This document discusses how an individual IPv6 address can be > > algorithmically translated to a corresponding IPv4 address, and vice > > versa, using only statically configured information. This technique > > is used in IPv4/IPv6 translators, as well as other types of proxies > > and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-behave-address-format- > > 01.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From huitema@microsoft.com Mon Oct 26 12:08:25 2009 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 EB3AE28C17B for <behave@core3.amsl.com>; Mon, 26 Oct 2009 12:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 KmbhL9dBhi4x for <behave@core3.amsl.com>; Mon, 26 Oct 2009 12:08:24 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id B015D28C392 for <behave@ietf.org>; Mon, 26 Oct 2009 12:07:18 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 26 Oct 2009 12:07:44 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server id 14.0.639.20; Mon, 26 Oct 2009 12:07:31 -0700 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Mon, 26 Oct 2009 12:07:32 -0700 From: Christian Huitema <huitema@microsoft.com> To: Dave Thaler <dthaler@microsoft.com>, Dave Thaler <dthaler@microsoft.com>, "eric.burgey@orange-ftgroup.com" <eric.burgey@orange-ftgroup.com>, "behave@ietf.org" <behave@ietf.org> Thread-Topic: [BEHAVE] I-D Action:draft-ietf-behave-address-format-01.txt Thread-Index: AQHKVlO7/pHU0zWOoEGNvtRVw4EJyJEYgxWAgAAb0wCAAAJfgP//jtXw Date: Mon, 26 Oct 2009 19:07:30 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA211CDEF1@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <20091026154501.550F23A6A8F@core3.amsl.com> <08BA2C59E081884DB2AAE4A0BE9D6DC1840DA4@ftrdmel0.rd.francetelecom.fr> <E4561B14EE2A3E4E9D478EBFB5416E1B29B1BF4E@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <E4561B14EE2A3E4E9D478EBFB5416E1B29B1C0D8@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <E4561B14EE2A3E4E9D478EBFB5416E1B29B1C0D8@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-address-format-01.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: Mon, 26 Oct 2009 19:08:26 -0000 Sorry about the bug in the figure. We will fix that in the next version. As for the (u) byte being required or not, it depends. The real requirement= is that the prefix be compatible with the addressing architecture, i.e.: For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. So the requirement is either to use the WKP, or if you use a Network Specif= ic Prefix to have the (u) byte correctly set. The table would become: +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |PLEN| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-| +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/32 | prefix |v4(32) | u | suffix | +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/40 | prefix |v4(24) | u |(8)| suffix | +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/48 | prefix |v4(16) | u | (16) | suffix | +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/56 | prefix |(8)| u | v4(24) | suffix | +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/64 | prefix | u | v4(32) | suffix | +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/88 | prefix (64) | u | (24) | v4(32) | +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |/96 | prefix (compatible with RFC 4291) | v4(32) | +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Hopefully, by the next edition, we will have a clear idea of what the well = known prefix should be, e.g. what value, 32 or 96 bits, etc. That will make= diagrams simpler. -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Dave Thaler Sent: Monday, October 26, 2009 11:44 AM To: Dave Thaler; eric.burgey@orange-ftgroup.com; behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-address-format-01.txt I missed answering Eric's second question, about why "u" isn't in the last line. I agree it should be. If the prefix is a well-known /96 prefix, then the well-known prefix would have the u bits specified correctly by IANA. If the prefix is a network-specific prefix, or a shorter well-known= =20 prefix, then the use of the "u" should be no different from any other line. -Dave > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Dave Thaler > Sent: Monday, October 26, 2009 11:36 AM > To: eric.burgey@orange-ftgroup.com; behave@ietf.org > Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-address-format- > 01.txt >=20 > I agree the figure looks incorrect. > I believe the intent was to look like this: >=20 > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- > --+ > |PLEN| 0-------------32--40--48--56--64--72--80--88--96--104-112- > 120-| > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- > --+ > |/32 | prefix |v4(32) | u | suffix > | > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- > --+ > |/40 | prefix |v4(24) | u |(8)| suffix > | > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- > --+ > |/48 | prefix |v4(16) | u | (16) | suffix > | > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- > --+ > |/56 | prefix |(8)| u | v4(24) | suffix > | > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- > --+ > |/64 | prefix | u | v4(32) | suffix > | > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- > --+ > |/96 | prefix | v4(32) > | > +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- > --+ >=20 > -Dave >=20 > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of eric.burgey@orange-ftgroup.com > > Sent: Monday, October 26, 2009 9:56 AM > > To: behave@ietf.org > > Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-address-format- > > 01.txt > > > > Hi, > > I have some difficulties to understand the figure in chapter 2. > > An IPv6 address is only 16 byte long and not 17. > > More precisely it is difficult to understand the last line of the > > figure. > > Is it a /96 prefix without byte u or is it a /88 prefix with a u byte > ? > > > > Best regards > > > > Eric BURGEY > > > > France TELECOM > > Orange Labs > > > > > > > > -----Message d'origine----- > > De=A0: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la > > part de Internet-Drafts@ietf.org > > Envoy=E9=A0: lundi 26 octobre 2009 16:45 > > =C0=A0: i-d-announce@ietf.org > > Cc=A0: behave@ietf.org > > Objet=A0: [BEHAVE] I-D Action:draft-ietf-behave-address-format-01.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Behavior Engineering for Hindrance > > Avoidance Working Group of the IETF. > > > > > > Title : IPv6 Addressing of IPv4/IPv6 Translators > > Author(s) : C. Huitema, et al. > > Filename : draft-ietf-behave-address-format-01.txt > > Pages : 15 > > Date : 2009-10-26 > > > > This document discusses how an individual IPv6 address can be > > algorithmically translated to a corresponding IPv4 address, and vice > > versa, using only statically configured information. This technique > > is used in IPv4/IPv6 translators, as well as other types of proxies > > and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-behave-address-format- > > 01.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave >=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 root@core3.amsl.com Mon Oct 26 13:00:02 2009 Return-Path: <root@core3.amsl.com> X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0755A28C2FA; Mon, 26 Oct 2009 13:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026200002.0755A28C2FA@core3.amsl.com> Date: Mon, 26 Oct 2009 13:00:02 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-dns64-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: Mon, 26 Oct 2009 20:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers Author(s) : M. Bagnulo, et al. Filename : draft-ietf-behave-dns64-02.txt Pages : 30 Date : 2009-10-26 DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-dns64-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-dns64-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26125959.I-D@ietf.org> --NextPart-- From ajs@shinkuro.com Mon Oct 26 13:10:22 2009 Return-Path: <ajs@shinkuro.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 882E23A69C2 for <behave@core3.amsl.com>; Mon, 26 Oct 2009 13:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=0.617, 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 7qOB5G6McDGf for <behave@core3.amsl.com>; Mon, 26 Oct 2009 13:10:21 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id AEF7A3A67AC for <behave@ietf.org>; Mon, 26 Oct 2009 13:10:21 -0700 (PDT) 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 AC3FA2FE8CDC for <behave@ietf.org>; Mon, 26 Oct 2009 20:10:34 +0000 (UTC) Date: Mon, 26 Oct 2009 16:10:32 -0400 From: Andrew Sullivan <ajs@shinkuro.com> To: behave@ietf.org Message-ID: <20091026201032.GN55437@shinkuro.com> References: <20091026200002.0755A28C2FA@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091026200002.0755A28C2FA@core3.amsl.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-dns64-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: Mon, 26 Oct 2009 20:10:22 -0000 Dear colleagues, On Mon, Oct 26, 2009 at 01:00:02PM -0700, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. > > > Title : DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers > Author(s) : M. Bagnulo, et al. > Filename : draft-ietf-behave-dns64-02.txt > Pages : 30 > Date : 2009-10-26 This version includes the changes we discussed in the interim last Wednesday, as well as the CNAME/DNAME discussion I mentioned last week. Comments, as always, are solicited. Best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From brian.e.carpenter@gmail.com Mon Oct 26 15:07:11 2009 Return-Path: <brian.e.carpenter@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 9CE7C28C19B for <behave@core3.amsl.com>; Mon, 26 Oct 2009 15:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9HKZnMVt1KP for <behave@core3.amsl.com>; Mon, 26 Oct 2009 15:07:11 -0700 (PDT) Received: from mail-px0-f173.google.com (mail-px0-f173.google.com [209.85.216.173]) by core3.amsl.com (Postfix) with ESMTP id 02C2428C181 for <behave@ietf.org>; Mon, 26 Oct 2009 15:07:10 -0700 (PDT) Received: by pxi3 with SMTP id 3so2777443pxi.29 for <behave@ietf.org>; Mon, 26 Oct 2009 15:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=jLCgcTrTRNe+hXHeJ0kQYmwgz4f585AP9teiQSM/h+8=; b=dQ5x8lYzXIm3FfSntl/WxYDHnFuf1Ll0xZQyQEXO//3/F87bx5P535RiPLIQ6cFlmK HWcvfrkZuZK4AXATECuEej3UDXpw0mqW3oMcx635AOtiaPrelFxbC1nP2w1yXfikjLJp ilIbot0uMhqNxSnsxI8jGn6mEMyKGZ2XU7SKM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; b=F3FAY3G6sYKsRyFsNZ0J4LPUBryTM3ThnbxW9XMoLLlCfojtCvCOoqlNfO0XNY5WQP iYYbKS9wosXHdB9Pme+myqct8Ca93VvHntXK2bCBMjChHRsseNShT8EUaVOUqC+woKfB t8K3tI8ghwJ/hOBp77GwaXdoTCBCzQTiR2J0Y= Received: by 10.114.251.14 with SMTP id y14mr10304774wah.144.1256594841585; Mon, 26 Oct 2009 15:07:21 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 21sm356287pxi.0.2009.10.26.15.07.20 (version=SSLv3 cipher=RC4-MD5); Mon, 26 Oct 2009 15:07:20 -0700 (PDT) Message-ID: <4AE61D94.3090207@gmail.com> Date: Tue, 27 Oct 2009 11:07:16 +1300 From: Brian E Carpenter <brian.e.carpenter@gmail.com> Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "behave@ietf.org" <behave@ietf.org> References: <E7FA8BDB-6D92-4C58-8BD0-535FABC80DF5@muada.com> <C70AD9D5.6994%rpenno@juniper.net> <bcff0fba0910260826o3680f925he836b7834c70a8be@mail.gmail.com> <2BD9ADC2-F76F-461B-9488-AB5C7834F3EA@nokia.com> In-Reply-To: <2BD9ADC2-F76F-461B-9488-AB5C7834F3EA@nokia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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: Mon, 26 Oct 2009 22:07:11 -0000 On 2009-10-27 05:25, Lars Eggert wrote: > On 2009-10-26, at 17:26, Cameron Byrne wrote: >> We also must not neglect the fact that many (the majority?) of the >> NAT64 boxes and boxes to be have a "day job" of being a firewall. > > Nobody is saying that a vendor cannot or should not implement both > NAT'ing and firewalling functions on the same piece of hardware. But > there is no need to conflate the two functions in one IETF specification. > > The draft should describe how to NAT v6 to v4 in a stateful way. Nothing > more, nothing less. How to implement firewall functions is orthogonal to > that. I don't think we yet know enough about scalability and prefix discovery to know where NAT64/DNS64 pairs will be deployed topologically, so I think we genuinely don't know whether there will be security functions in the same box. Lars is correct. Brian From dwing@cisco.com Mon Oct 26 17:20:17 2009 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 B62D13A6860 for <behave@core3.amsl.com>; Mon, 26 Oct 2009 17:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.337 X-Spam-Level: X-Spam-Status: No, score=-6.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tk4O16dkutO for <behave@core3.amsl.com>; Mon, 26 Oct 2009 17:20:16 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DF9F23A69E0 for <behave@ietf.org>; Mon, 26 Oct 2009 17:20:16 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEABfZ5UqrR7Ht/2dsb2JhbACKX7ZVl2aEPwSBXg X-IronPort-AV: E=Sophos;i="4.44,628,1249257600"; d="scan'208";a="418415979" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2009 00:20:30 +0000 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9R0KUsL027154; Tue, 27 Oct 2009 00:20:30 GMT From: "Dan Wing" <dwing@cisco.com> To: "'Reinaldo Penno'" <rpenno@juniper.net>, "'Iljitsch van Beijnum'" <iljitsch@muada.com> References: <E7FA8BDB-6D92-4C58-8BD0-535FABC80DF5@muada.com> <C70AD9D5.6994%rpenno@juniper.net> Date: Mon, 26 Oct 2009 17:20:30 -0700 Message-ID: <0f5501ca569b$4acf2710$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpWKzjVsBfEQl6VSZqEM1/5W7VzLAABowMBABpazwA= In-Reply-To: <C70AD9D5.6994%rpenno@juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: behave@ietf.org Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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, 27 Oct 2009 00:20:17 -0000 > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Reinaldo Penno > Sent: Monday, October 26, 2009 4:45 AM > To: Iljitsch van Beijnum > Cc: behave@ietf.org > Subject: Re: [BEHAVE] Comments on TCP RST handling in > draft-ietf-behave-v6v4-xlate-stateful-02.txt > > > > > On 10/26/09 3:58 AM, "Iljitsch van Beijnum" > <iljitsch@muada.com> wrote: > > > On 26 okt 2009, at 11:29, Reinaldo Penno wrote: > > > >> I feel that NAT64 should look and feel in terms of behavior > >> (forwarding, > >> control & security) as closely as NAT44 as possible in order to be > >> deployed > >> successfully. > > > > No. A traditional NAT44 sits on an internal/external > boundary, a place > > where you would naturally want to apply security policy. > However, this > > is not the case for a NAT64, which sits more towards the > middle of the > > network. (Same for an ISP-operated NAT44.) > > If an enterprise starts using IPv6 where do you think it will > sit? I would > suggest that it will sit where NAT44 sits today and not in > the middle of the > network somewhere as you mention. > > Why do you think this is not a valid case or have such a > narrow view of > NAT64? I think NAT64 applicability statement should be > clarified in the > document. > > > It makes no sense to import > > NAT44 baggage into NAT64. Also, BEHAVE has been writing up > what NAT44s > > actually do, while for NAT64 we're specifying what we WANT > them to do, > > which is a rather different approach. > > Agreed, but operators are used to the look and feel of NAT44 > and since NAT64 > will in many occupy a similar position and perform similar function, > operators will want similar behavior. I think emails in this > regard were > already sent to the list. > > > > >> Are you suggesting all those security considerations should be > >> removed from > >> NAT64 to another document and/or deprecated in NAT44 documents? > > > > Yes, I believe some of the text quoted earlier would best > be removed. > > That seems at odds with the general consensus with the > document until now... > > Regardless, the security text in the current document and the points I > raised around NAT64 would still need to be documented > somewhere. There is an interesting document about this subject. > > http://tools.ietf.org/html/draft-gont-behave-nat-security-01 Yes, and Fernando has asked for an agenda slot at the upcoming BEHAVE meeting to present it. -d > > Obviously that doesn't mean a NAT64 document shouldn't have any > > security considerations, just that firewalling should be kept out of > > the NAT64 document. > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From dthaler@microsoft.com Mon Oct 26 19:15:53 2009 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 D68383A68B8 for <behave@core3.amsl.com>; Mon, 26 Oct 2009 19:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Irg1VyjieRZm for <behave@core3.amsl.com>; Mon, 26 Oct 2009 19:15:52 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 0924D3A6824 for <behave@ietf.org>; Mon, 26 Oct 2009 19:15:51 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 26 Oct 2009 19:16:17 -0700 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 id 14.0.639.20; Mon, 26 Oct 2009 19:16:05 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Mon, 26 Oct 2009 19:16:05 -0700 From: Dave Thaler <dthaler@microsoft.com> To: Iljitsch van Beijnum <iljitsch@muada.com>, Reinaldo Penno <rpenno@juniper.net> Thread-Topic: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-02.txt Thread-Index: AQHKVjNeP51m5BrFYEioRguf+USPmpEYo73g Date: Tue, 27 Oct 2009 02:16:04 +0000 Message-ID: <E4561B14EE2A3E4E9D478EBFB5416E1B29B1DC52@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> References: <C70AD9D5.6994%rpenno@juniper.net> <6D9F9B2D-BEAB-4EF0-9465-CB9A4054C21B@muada.com> In-Reply-To: <6D9F9B2D-BEAB-4EF0-9465-CB9A4054C21B@muada.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" <behave@ietf.org> Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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, 27 Oct 2009 02:15:53 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Iljitsch van Beijnum > Sent: Monday, October 26, 2009 4:56 AM > To: Reinaldo Penno > Cc: behave@ietf.org > Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf- > behave-v6v4-xlate-stateful-02.txt >=20 > On 26 okt 2009, at 12:45, Reinaldo Penno wrote: >=20 > > If an enterprise starts using IPv6 where do you think it will sit? >=20 > I don't know. The point of NAT64 is that ISPs run it for their > customers.=20 Disagree. The point of NAT64 is to support multiple scenarios, of which that is one. For the scenario "IPv6 Internet to an IPv4 network" (which is the scenario Microsoft's "Direct Access" fits into), the NAT64 would be run by the enterprise, and would likely sit near the ISP side of the enterprise network so that remote IPv6=20 clients that the firewall lets in (which in the Direct Access case is traffic protected by IPsec) could reach internal IPv4-only servers with private IPv4 addresses. -Dave > But I do know that enterprises are paranoid enough to have > separate firewalls rather than depend on the way a NAT64 may or may > not filter TCP resets. >=20 > Filtering packets is not a core function of a NAT64 so it shouldn't do > any packet filtering as such, rather than adopt the notion "hey, these > are packets that some other boxes would filter out so let's filter > them out here, too!" >=20 > Airplanes have wheels. That doesn't mean we require pilots to have a > driver's license. >=20 > Also, the end-to-end principle applies here: hosts need to validate > resets anyway, so there is no point in doing that in the middle of the > network, too. >=20 > > There is an > > interesting document about this subject. >=20 > > http://tools.ietf.org/html/draft-gont-behave-nat-security-01 >=20 > I wasn't very impressed with the previous documents in this series, so > I'll save myself and the author the aggravation of reading it and then > firing off a bunch of criticisms. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From maxpassion@gmail.com Mon Oct 26 20:02:59 2009 Return-Path: <maxpassion@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 4079D3A69DE for <behave@core3.amsl.com>; Mon, 26 Oct 2009 20:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTfBaYQDfVsu for <behave@core3.amsl.com>; Mon, 26 Oct 2009 20:02:58 -0700 (PDT) Received: from mail-px0-f173.google.com (mail-px0-f173.google.com [209.85.216.173]) by core3.amsl.com (Postfix) with ESMTP id 528163A695C for <behave@ietf.org>; Mon, 26 Oct 2009 20:02:58 -0700 (PDT) Received: by pxi3 with SMTP id 3so2907258pxi.29 for <behave@ietf.org>; Mon, 26 Oct 2009 20:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=V0gRDRYfzNYdntgHNQj4F6q3Tzhr49Ku1KB48F3GCfY=; b=t+tskVHJ5+YxbNx3GlUvgCkgWHG1bk4ROJsGAu8LX3BLhYLXfRrgbQAms4miJUmfEn aIkZym2ZHGs8wlg5s+N2mn384+BiZNOOXKleYlhLPLgJPi6ZhmFDnCQQs6DWdjB5Pyu7 rRU2HB8htYO5T1HJ1zzl2eG2VJTsuQVgFUgGs= 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=At17ci1DanlY81tg+KgtiiSSiBnWzxiRwmwy0yTtzmvpusWMYuNqVQbxMSxSjTX24P zDM3AzkfWkc+07g65mgefHaSGdU6ZBPx42O7iJLlwRUVFf6l5yErY8Y8z+6dN/y6klh+ RUrEik2icmWvtQ7ffVcyd12sVCFb15mWCTjK0= MIME-Version: 1.0 Received: by 10.142.202.9 with SMTP id z9mr1210637wff.166.1256612588126; Mon, 26 Oct 2009 20:03:08 -0700 (PDT) In-Reply-To: <09be01ca5660$7a1de870$c5f0200a@cisco.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> <25e1aaa40910230404m4517c64ew2a04e610cc6f2bcd@mail.gmail.com> <D1DA2BB2-E064-4656-B75A-A10339A1B9FB@muada.com> <86F15BB9FC58443ABF2071A5CC843384@JiangXiong> <09be01ca5660$7a1de870$c5f0200a@cisco.com> Date: Tue, 27 Oct 2009 11:03:07 +0800 Message-ID: <25e1aaa40910262003u3779279fxa614487c9d304f87@mail.gmail.com> From: liu dapeng <maxpassion@gmail.com> To: Dan Wing <dwing@cisco.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: shengjiang@huawei.com, behave@ietf.org, =?GB2312?B?wfW088X0?= <liudapeng@chinamobile.com>, bo zhou <zhouboyj@gmail.com>, =?GB2312?B?stzV8Q==?= <caozhen@chinamobile.com>, Behave Chairs <behave-chairs@tools.ietf.org> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 27 Oct 2009 03:02:59 -0000 Hi Dan, We updated the ftp64 draft: http://tools.ietf.org/html/draft-liu-behave-ftp64-04. As you mentioned, attitude toward FTP ALG is one of the ideas that merged by draft-van-beijnum-behave-ftp64-06.txt; Furthermore, the handling of FTP client when retrying with PASV command is another important idea that merged by draft-van-beijnum-behave-ftp64-06.txt. The original handling method will cause problems and probably does not work. We believe that draft-van-beijnum-behave-ftp64-06 still need more improveme= nt, so we upgrade draft-liu-behave-ftp64-04 to reflect our thoughts more precisely. We would like the WG to review and comments on this draft and to see whether it is more suitable to be the working foundation to further proceed the ftp64 issue in IPv6 transition scenario. If it is convenient, we would like to present it in the coming meeting(5-10 minutes). Thanks for your comments and kindly help. BR, Dapeng Liu 2009/10/27, Dan Wing <dwing@cisco.com>: > Looking at > http://tools.ietf.org/rfcdiff?url2=3Ddraft-van-beijnum-behave-ftp64-06.tx= t and > reviewing draft-liu-behave-ftp64-03, I believe the change caused by > draft-liu-behave-ftp64 was the new paragraph in Section 6, "ALG > Functionality" > starting with "On the other hand,". Is that correct? If that is all tha= t > was > incorporated, it falls below my threshold for adding a second author, and > rewording the Acknowledgements to better acknowledge the contribution see= ms > adequate along the lines of "Dapeng Liu and Zhen Cao suggested that netwo= rk > operators encourage upgrading FTP clients rather than deploy an FTP ALG." > > -d > > >> -----Original Message----- >> From: Sheng Jiang [mailto:shengjiang@huawei.com] >> Sent: Saturday, October 24, 2009 2:48 AM >> To: 'Iljitsch van Beijnum'; 'liu dapeng' >> Cc: '=C1=F5=B4=F3=C5=F4'; '=B2=DC=D5=F1'; behave@ietf.org; 'Behave Chair= s'; 'Dan >> Wing'; 'Sheng Jiang' >> Subject: RE: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 >> as WG item >> >> Hi, >> >> I support to adopt the draft as WG documentation. >> >> However, the author wrote in the draft: =A1=B0Versions -05 and -06 of th= is >> document adopts several important design decisions from >> [I-D.liu-behave-ftp64].=A1=B1 Should at least one author from >> draft-liu-behave-ftp64 deserve to be co-author of this >> draft-van-beijnum-behave-ftp64? >> >> Best wishes, >> >> Sheng >> >> > -----Original Message----- >> > From: behave-bounces@ietf.org >> [mailto:behave-bounces@ietf.org] On Behalf >> Of >> > Iljitsch van Beijnum >> > Sent: Friday, October 23, 2009 7:11 PM >> > To: liu dapeng >> > Cc: =C1=F5=B4=F3=C5=F4; =B2=DC=D5=F1; behave@ietf.org; Behave Chairs; = Dan Wing >> > Subject: Re: [BEHAVE] adopt >> draft-van-beijnum-behave-ftp64-06 as WG item >> > >> > On 23 okt 2009, at 13:04, liu dapeng wrote: >> > >> > > We know that there are two drafts discussing the ftp64 >> issue. Would >> > > the WG consider merging draft-van-beijnum-behave-ftp64 and >> > > draft-liu-behave-ftp64 as the WG document? >> > >> > Do you feel the current text in draft-van-beijnum-behave-ftp64-06 >> > doesn't address your previous objections? >> > _______________________________________________ >> > Behave mailing list >> > Behave@ietf.org >> > https://www.ietf.org/mailman/listinfo/behave >> > > From maxpassion@gmail.com Mon Oct 26 22:04:09 2009 Return-Path: <maxpassion@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 193D03A684F for <behave@core3.amsl.com>; Mon, 26 Oct 2009 22:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.245, 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 WTHap1gWztAg for <behave@core3.amsl.com>; Mon, 26 Oct 2009 22:04:08 -0700 (PDT) Received: from mail-px0-f173.google.com (mail-px0-f173.google.com [209.85.216.173]) by core3.amsl.com (Postfix) with ESMTP id 3CA1E3A67F2 for <behave@ietf.org>; Mon, 26 Oct 2009 22:04:08 -0700 (PDT) Received: by pxi3 with SMTP id 3so2963244pxi.29 for <behave@ietf.org>; Mon, 26 Oct 2009 22:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lawaNtwM+WT3AJyXEA499fgRrCQjnO9SydsQNGIa9pQ=; b=Sc5cin91J+AbOAZxfYly3yRh4h7HXsumKqP8mplABD/5k3IE8RTQijWwT7R/LZeNbo RW5xPAA6QgyvEUMolKUvwuvQLMPEJG27diYPIHJHdLQJNevuexgy3+q+iA6EXsk2AWEG Z/EgjlOG0WeMSdl9j6/Yliy3+tpPWWw4g7OmM= 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=DLXU96GLVrZ3s06p+usLMhVrRKDyNFmzr9AXBwaQg4/Q9C78ev5I9q063qrqSUTPZh ckNnKt2BUX6Oe/C6VyOkksT3MhimLGaQwIlX2xN9Yci1eHTUk3nZYQPcu0ZH4KQ/okL8 ysOO8Jn1lCWoAG0OZREC34RV59j7AZqXQrtq8= MIME-Version: 1.0 Received: by 10.142.7.39 with SMTP id 39mr1280466wfg.113.1256619859818; Mon, 26 Oct 2009 22:04:19 -0700 (PDT) In-Reply-To: <3932CF6D-1634-4C35-BA4A-3A4A0F3ED577@muada.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> <25e1aaa40910230404m4517c64ew2a04e610cc6f2bcd@mail.gmail.com> <D1DA2BB2-E064-4656-B75A-A10339A1B9FB@muada.com> <86F15BB9FC58443ABF2071A5CC843384@JiangXiong> <3932CF6D-1634-4C35-BA4A-3A4A0F3ED577@muada.com> Date: Tue, 27 Oct 2009 13:04:19 +0800 Message-ID: <25e1aaa40910262204k76ae9fe6pc64d5b9c7ddc4262@mail.gmail.com> From: liu dapeng <maxpassion@gmail.com> To: Iljitsch van Beijnum <iljitsch@muada.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: shengjiang@huawei.com, Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 27 Oct 2009 05:04:09 -0000 2009/10/25, Iljitsch van Beijnum <iljitsch@muada.com>: > On 24 okt 2009, at 11:48, Sheng Jiang wrote: > >> However, the author wrote in the draft: =93Versions -05 and -06 of this >> document adopts several important design decisions from >> [I-D.liu-behave-ftp64].=94 Should at least one author from >> draft-liu-behave-ftp64 deserve to be co-author of this >> draft-van-beijnum-behave-ftp64? > > I'm happy that so many of you want work together on the FTP64 document. > > However, I would prefer to not add co-authors for the following reasons: > > - Having a single author reduces the time needed for coordination so > progress can be faster. Single author has the problem that it may can not reflect all the useful opinions that aim to improve the document in time. It may depends on the single author's preference that whether to adopt the useful ideas and opinions. From this perspective, it may not help to quicken the progress since the WG draft should reflect consensus of the WG . BR, Dapeng Liu > - Although many people have contributed tests, ideas and suggestions > (as noted in the acknowledgments), I wrote all the text and I did all > the presentations at IETF meetings. > > However, when the document is adopted as a working group document I > would be willing to listen to the chairs if they want to suggest > additional authors if they have important reasons for adding more > authors. > > Iljitsch > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From christian.vogt@ericsson.com Mon Oct 26 22:28:23 2009 Return-Path: <christian.vogt@ericsson.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 EDAE73A68F0 for <behave@core3.amsl.com>; Mon, 26 Oct 2009 22:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 3SWeHIgVbIoJ for <behave@core3.amsl.com>; Mon, 26 Oct 2009 22:28:23 -0700 (PDT) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by core3.amsl.com (Postfix) with ESMTP id 4064D3A67F2 for <behave@ietf.org>; Mon, 26 Oct 2009 22:28:23 -0700 (PDT) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 7CD86BC7B2; Tue, 27 Oct 2009 01:28:35 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 27 Oct 2009 01:28:36 -0400 X-Sasl-enc: UlFdKB8LPb2Wetv1Il+5CjBoARjiQZmMAmrWITo98FNh 1256621315 Received: from [10.0.1.3] (adsl-99-35-52-135.dsl.pltn13.sbcglobal.net [99.35.52.135]) by mail.messagingengine.com (Postfix) with ESMTPSA id 8E1895CBD3; Tue, 27 Oct 2009 01:28:34 -0400 (EDT) From: Christian Vogt <christian.vogt@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 26 Oct 2009 18:33:22 -0700 Message-Id: <75D15243-2569-4B04-B02A-021502FAEDC9@ericsson.com> To: Behave Mailing List <behave@ietf.org> Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Cc: Alain Durand <alain_durand@cable.comcast.com>, Dan Wing <dwing@cisco.com>, Dave Thaler <dthaler@windows.microsoft.com> Subject: [BEHAVE] Update of Virtual IPv6 Connectivity document 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, 27 Oct 2009 05:28:24 -0000 Dear all - Alain and I updated the Virtual IPv6 Connectivity specification: http://www.ietf.org/id/draft-vogt-durand-virtual-ip6-connectivity-03.txt The document now includes a section on side-effects of Virtual IPv6 Connectivity. This section identifies the side-effects, and explains why the side-effects are inevitable consequences of the objectives for which Virtual IPv6 Connectivity was designed. The section includes feedback we got from the working group previously. As always, your reviews and feedback will be highly appreciated. - Christian From lars.eggert@nokia.com Tue Oct 27 03:52:27 2009 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 518C228C118 for <behave@core3.amsl.com>; Tue, 27 Oct 2009 03:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfMvTgwjAG6K for <behave@core3.amsl.com>; Tue, 27 Oct 2009 03:52:26 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 4B9EB28C176 for <behave@ietf.org>; Tue, 27 Oct 2009 03:52:26 -0700 (PDT) Received: from [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (lars.local [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (may be forged)) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n9RAqUNO080464 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 Oct 2009 12:52:30 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-47--839324253; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert <lars.eggert@nokia.com> In-Reply-To: <C70B25FF.6A0F%rpenno@juniper.net> Date: Tue, 27 Oct 2009 12:52:29 +0200 Message-Id: <1B1A1645-B6A5-4B75-A55F-B854A56096B1@nokia.com> References: <C70B25FF.6A0F%rpenno@juniper.net> To: Reinaldo Penno <rpenno@juniper.net> X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [IPv6:2001:708:40:fff1::1]); Tue, 27 Oct 2009 12:52:32 +0200 (EET) Cc: Cameron Byrne <cb.list6@gmail.com>, "behave@ietf.org" <behave@ietf.org> Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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, 27 Oct 2009 10:52:27 -0000 --Apple-Mail-47--839324253 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, On 2009-10-26, at 19:10, Reinaldo Penno wrote: > I think we are talking about NAT specific filtering behavior: port + > address > filtering which is a NAT property, translations of unsolicited > packets, > dropping certain packets due to state of translation. NATs don't "filter". Stateful NATs translate packets for which they have binding state, and drop packets for which they have none. That they need to drop packets for which they have no binding is a side- effect of NAT'ing and not a feature. Yes, that side effect is similar to the filtering function that firewalls perform, and especially stateful firewalls implement similar connection state tracking functions than NATs. But although the mechanism is similar, the purpose is different. > A firewall as a separate entity (or software system) as you advocate > would > not have access to NAT binding/map tables or policies and therefore > cannot > perform such functions. Or maybe you are suggesting something > different? You're throwing to concepts together that are logically separate. Both stateful NATs and stateful firewalls implement connection state tracking - but for different purposes. Yes, implementing NAT and firewall functions on the same piece of hardware can therefore be beneficial, because you can share this mechanism. Lars --Apple-Mail-47--839324253 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTAyNzEwNTIzMFowIwYJKoZIhvcNAQkEMRYEFAT5oGC4qJJoPjJdcoCCWlqYj86TMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQC2jCsBNAfZ/L8yRT/Js2odqf2675vZM+gSeYmD7RiERknejzsH5YUvr8BVfjvaml4yf48b puyNKWS4UoMgNi+76Pk/BArZAuOtTNuKogrZ+eXWi624RZWj5k1tWNjfmmFp7aroMsAkSkttjj5z 1njWzqojDc2Lr66XlTabyTy/rVVGqmLOUUBGaMOk9XJqfjrSHyk9B7kUjqgyTdZJNep2BdwbfoAn GHbVrpckk2tJApmSobkafWAsChh/ukOBRLkYNcT3NsX7MXllOdBmpP51IyTkwX1uE00sF20ikE5S 2Y/DJiTNxYH5L1qKeHPcetjTBdzw16rOunsRIYp40+CMAAAAAAAA --Apple-Mail-47--839324253-- From jukai.zte@gmail.com Tue Oct 27 04:46:48 2009 Return-Path: <jukai.zte@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 DA3A33A68D3 for <behave@core3.amsl.com>; Tue, 27 Oct 2009 04:46:48 -0700 (PDT) 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 j6dQN6dnuLnM for <behave@core3.amsl.com>; Tue, 27 Oct 2009 04:46:47 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 66E6A3A681A for <behave@ietf.org>; Tue, 27 Oct 2009 04:46:47 -0700 (PDT) Received: by ewy4 with SMTP id 4so52311ewy.37 for <behave@ietf.org>; Tue, 27 Oct 2009 04:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=sJoaBmrn8hPmRDu0VP5omD76mcMJSrJnV0gJCv2Agak=; b=gc72A1r3aCrro4yPstztwDKiNdWte7vEAe/1WRU0p4DajSyl6lMYuffcQJPTqrUCDo 2Rdn7+FyWoZ3Nka2rvimd3ZXnw0pkubCKMGxbR4H6ioveKpxkB3DXv5vUmgYzhLpxFFJ rQvAH6rk3Jbj/sBWITEqxdLWCUPzivU9FC47k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=dcX6Ztg9CS/qzDXfpwsUvfm6cqGJn/Ej9BqUU0Us1dULMbfj6nUXhCcsrjW69ZbJER jIcOXxIBWh2CuXCMUmHbtFc/NBrxEIkEGtQuL/IhXlsB2+iJDEAW/h7AqUHZGj8rt1Ue fi3g6ni0MhSuhdhCCP6TsOwkubAqVKM9VyLao= MIME-Version: 1.0 Received: by 10.239.168.154 with SMTP id k26mr1430363hbe.104.1256644013201; Tue, 27 Oct 2009 04:46:53 -0700 (PDT) Date: Tue, 27 Oct 2009 19:46:53 +0800 Message-ID: <3db7b9d60910270446s7cee37e5u6a8cd7209659a549@mail.gmail.com> From: Kai Ju <jukai.zte@gmail.com> To: "behave@ietf.org" <behave@ietf.org> Content-Type: multipart/alternative; boundary=0016364990130419d20476e93cd9 Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 27 Oct 2009 11:46:48 -0000 --0016364990130419d20476e93cd9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 2009/10/25, Iljitsch van Beijnum <iljitsch at muada.com>: > On 24 okt 2009, at 11:48, Sheng Jiang wrote: > >> However, the author wrote in the draft: =93Versions -05 and -06 of this >> document adopts several important design decisions from >> [I-D.liu-behave-ftp64].=94 Should at least one author from >> draft-liu-behave-ftp64 deserve to be co-author of this >> draft-van-beijnum-behave-ftp64? > > I'm happy that so many of you want work together on the FTP64 document. > > However, I would prefer to not add co-authors for the following reasons: > > - Having a single author reduces the time needed for coordination so > progress can be faster. Single author has the problem that it may can not reflect all the useful opinions that aim to improve the document in time. It may depends on the single author's preference that whether to adopt the useful ideas and opinions. From this perspective, it may not help to quicken the progress since the WG draft should reflect consensus of the WG . BR, Dapeng Liu > - Although many people have contributed tests, ideas and suggestions > (as noted in the acknowledgments), I wrote all the text and I did all > the presentations at IETF meetings. > > However, when the document is adopted as a working group document I > would be willing to listen to the chairs if they want to suggest > additional authors if they have important reasons for adding more > authors. > > Iljitsch > _______________________________________________ > Behave mailing list > Behave at ietf.org > https://www.ietf.org/mailman/listinfo/behave > Although the author deny that he quoted someone else's draft, but obviously, there are other's point of view in it, and I do not think only one author can speed up the progress is a reasonable reason. BR, Kai Ju --0016364990130419d20476e93cd9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable <pre>2009/10/25, Iljitsch van Beijnum <iljitsch at <a href=3D"http://mua= da.com">muada.com</a>>: > On 24 okt 2009, at 11:48, Sheng Jiang wrote: > >> However, the author wrote in the draft: =93Versions -05 and -06 of= this >> document adopts several important design decisions from >> [I-D.liu-behave-ftp64].=94 Should at least one author from >> draft-liu-behave-ftp64 deserve to be co-author of this >> draft-van-beijnum-behave-ftp64? > > I'm happy that so many of you want work together on the FTP64 docu= ment. > > However, I would prefer to not add co-authors for the following reason= s: > > - Having a single author reduces the time needed for coordination so > progress can be faster. Single author has the problem that it may can not reflect all the useful opinions that aim to improve the document in time. It may depends on the single author's preference that whether to adopt the useful ideas and opinions. From this perspective, it may not help to quicken the progress since the WG draft should reflect consensus of the WG . BR, Dapeng Liu > - Although many people have contributed tests, ideas and suggestions > (as noted in the acknowledgments), I wrote all the text and I did all > the presentations at IETF meetings. > > However, when the document is adopted as a working group document I > would be willing to listen to the chairs if they want to suggest > additional authors if they have important reasons for adding more > authors. > > Iljitsch > _______________________________________________ > Behave mailing list > Behave at <a href=3D"http://ietf.org">ietf.org</a> > <a href=3D"https://www.ietf.org/mailman/listinfo/behave" rel=3D"nofoll= ow">https://www.ietf.org/mailman/listinfo/behave</a> > <div dir=3D"ltr" id=3D"result_box">Although the author deny that he quoted = someone else's draft, but obviously, there are other's point of vie= w in it, </div><div dir=3D"ltr">and I do not think only one author can spee= d up the progress is a reasonable reason.</div> <div dir=3D"ltr">=A0</div><div dir=3D"ltr">BR,</div><div dir=3D"ltr">Kai Ju= </div></pre> --0016364990130419d20476e93cd9-- From rpenno@juniper.net Tue Oct 27 08:13:31 2009 Return-Path: <rpenno@juniper.net> 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 90B523A6A24 for <behave@core3.amsl.com>; Tue, 27 Oct 2009 08:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tb9KZ+9m-IgJ for <behave@core3.amsl.com>; Tue, 27 Oct 2009 08:13:30 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 160EC3A69D1 for <behave@ietf.org>; Tue, 27 Oct 2009 08:13:26 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSucOJJ8ShFoElnMwzV2wer98lSoUfeqM@postini.com; Tue, 27 Oct 2009 08:13:45 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 27 Oct 2009 08:07:43 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 27 Oct 2009 11:07:42 -0400 From: Reinaldo Penno <rpenno@juniper.net> To: Lars Eggert <lars.eggert@nokia.com> Date: Tue, 27 Oct 2009 11:07:40 -0400 Thread-Topic: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-02.txt Thread-Index: AcpW851zWS5UAjgiSUuRECZxxzl4OgAI5xrS Message-ID: <C70C5ACC.6C94%rpenno@juniper.net> In-Reply-To: <1B1A1645-B6A5-4B75-A55F-B854A56096B1@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Cameron Byrne <cb.list6@gmail.com>, "behave@ietf.org" <behave@ietf.org> Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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, 27 Oct 2009 15:13:31 -0000 Thank you for your answer Lars, comments inline... On 10/27/09 3:52 AM, "Lars Eggert" <lars.eggert@nokia.com> wrote: > Hi, >=20 > On 2009-10-26, at 19:10, Reinaldo Penno wrote: >> I think we are talking about NAT specific filtering behavior: port + >> address >> filtering which is a NAT property, translations of unsolicited >> packets, >> dropping certain packets due to state of translation. >=20 > NATs don't "filter". Stateful NATs translate packets for which they > have binding state, and drop packets for which they have none. That > they need to drop packets for which they have no binding is a side- > effect of NAT'ing and not a feature. >=20 > Yes, that side effect is similar to the filtering function that > firewalls perform, and especially stateful firewalls implement similar > connection state tracking functions than NATs. But although the > mechanism is similar, the purpose is different. In the case of RFC4787, Section 15, "Filtering Behavior", the level of filtering is a function of how stringent is the NAT security policy. It is = a security choice since there are multiple filtering levels based on a single outcome (matching a half-state). The discussion on filtering is extensive and driven solely from the point of security (and application usability). For example,=20 " ....In theory, filtering based on both IP address and port is more secure than filtering based only on the IP address (because the external endpoint could, in reality, be two endpoints behind another NAT, where one of the two endpoints is an attacker)." And this type of behavior is the one I was pointing out. >=20 >> A firewall as a separate entity (or software system) as you advocate >> would >> not have access to NAT binding/map tables or policies and therefore >> cannot >> perform such functions. Or maybe you are suggesting something >> different? >=20 > You're throwing to concepts together that are logically separate. I'm actually agreeing they are logically separate and trying to point out that in order to perform filtering as described in Section 15 of RFC4787 yo= u need to: * be the NAT device, or * have access to the NAT state. In the latter you can argue that a firewall could do it, but it is driven b= y NAT security policy and need to access NAT state, therefore it becomes somewhat of a 'NAT-Firewall'. The same is true for any NAT security policy and associated behavior that i= s based on NAT state. Does that make sense? > Both =20 > stateful NATs and stateful firewalls implement connection state > tracking - but for different purposes. Yes, implementing NAT and > firewall functions on the same piece of hardware can therefore be > beneficial, because you can share this mechanism. >=20 > Lars Regards, Reinaldo From marcelo@it.uc3m.es Tue Oct 27 08:25:34 2009 Return-Path: <marcelo@it.uc3m.es> 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 4E9193A6951 for <behave@core3.amsl.com>; Tue, 27 Oct 2009 08:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fskHoHUwbhQC for <behave@core3.amsl.com>; Tue, 27 Oct 2009 08:25:33 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 518B63A6359 for <behave@ietf.org>; Tue, 27 Oct 2009 08:25:29 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id C2A716C25DA; Tue, 27 Oct 2009 16:25:42 +0100 (CET) Message-ID: <4AE710F6.1090905@it.uc3m.es> Date: Tue, 27 Oct 2009 16:25:42 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Reinaldo Penno <rpenno@juniper.net> References: <C70C5ACC.6C94%rpenno@juniper.net> In-Reply-To: <C70C5ACC.6C94%rpenno@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16972.003 Cc: Cameron Byrne <cb.list6@gmail.com>, "behave@ietf.org" <behave@ietf.org> Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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, 27 Oct 2009 15:25:34 -0000 I still think that we should rely on the security guidelines that were specified by the behave requirements. I mean, filtering behaviour that need to be supported are carefully defined by the behave requirements, we should simply stick to them There was consensus on this requirements, i don't see the need to go back and open these issues. Regards, marcelo Reinaldo Penno escribió: > Thank you for your answer Lars, comments inline... > > On 10/27/09 3:52 AM, "Lars Eggert" <lars.eggert@nokia.com> wrote: > > >> Hi, >> >> On 2009-10-26, at 19:10, Reinaldo Penno wrote: >> >>> I think we are talking about NAT specific filtering behavior: port + >>> address >>> filtering which is a NAT property, translations of unsolicited >>> packets, >>> dropping certain packets due to state of translation. >>> >> NATs don't "filter". Stateful NATs translate packets for which they >> have binding state, and drop packets for which they have none. That >> they need to drop packets for which they have no binding is a side- >> effect of NAT'ing and not a feature. >> >> Yes, that side effect is similar to the filtering function that >> firewalls perform, and especially stateful firewalls implement similar >> connection state tracking functions than NATs. But although the >> mechanism is similar, the purpose is different. >> > > In the case of RFC4787, Section 15, "Filtering Behavior", the level of > filtering is a function of how stringent is the NAT security policy. It is a > security choice since there are multiple filtering levels based on a single > outcome (matching a half-state). The discussion on filtering is extensive > and driven solely from the point of security (and application usability). > For example, > > " ....In theory, filtering based on > both IP address and port is more secure than filtering based only > on the IP address (because the external endpoint could, in > reality, be two endpoints behind another NAT, where one of the two > endpoints is an attacker)." > > And this type of behavior is the one I was pointing out. > > >>> A firewall as a separate entity (or software system) as you advocate >>> would >>> not have access to NAT binding/map tables or policies and therefore >>> cannot >>> perform such functions. Or maybe you are suggesting something >>> different? >>> >> You're throwing to concepts together that are logically separate. >> > > I'm actually agreeing they are logically separate and trying to point out > that in order to perform filtering as described in Section 15 of RFC4787 you > need to: > > * be the NAT device, or > * have access to the NAT state. > > In the latter you can argue that a firewall could do it, but it is driven by > NAT security policy and need to access NAT state, therefore it becomes > somewhat of a 'NAT-Firewall'. > > The same is true for any NAT security policy and associated behavior that is > based on NAT state. > > Does that make sense? > > >> Both >> stateful NATs and stateful firewalls implement connection state >> tracking - but for different purposes. Yes, implementing NAT and >> firewall functions on the same piece of hardware can therefore be >> beneficial, because you can share this mechanism. >> >> Lars >> > > Regards, > > Reinaldo > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From caozhenpku@gmail.com Tue Oct 27 08:39:57 2009 Return-Path: <caozhenpku@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 028E13A68BF for <behave@core3.amsl.com>; Tue, 27 Oct 2009 08:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=0.623, 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 zAxWHTS5sn3J for <behave@core3.amsl.com>; Tue, 27 Oct 2009 08:39:56 -0700 (PDT) Received: from mail-pz0-f198.google.com (mail-pz0-f198.google.com [209.85.222.198]) by core3.amsl.com (Postfix) with ESMTP id 498B43A67F1 for <behave@ietf.org>; Tue, 27 Oct 2009 08:39:56 -0700 (PDT) Received: by pzk36 with SMTP id 36so187930pzk.5 for <behave@ietf.org>; Tue, 27 Oct 2009 08:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=0VfrCsNcS29S2YygseDAyHq0nCyH/GU5bbsy9KyuL+g=; b=uweLjsXR9Qwgfib8+b60j1tVLz9kNhwf+J+VPb3B6wJSa0hlf5vcrpV3k0+ojNljgP QxoyqFfCAbC0cKWyRjnAoU0nQ7W1j258GmAN8wXH4u8gDNcYFgjyR8xbmG4bD7C4Htci DYS3TUwTT69gZELWIxCooa0dB35c2CWMzk2ek= 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=dF+rBGYf0kQxGMA/Hrb87qIlcNqU2AoQ3khGCulCxH5MrSZPgohAsYdQWI5yslga5o 6slT4PsuYGw2bWmoABXqIS8jTz/UvM3ag2CE0gA+3VVQH18BrV0nosN44rT04Fz2z9KC 04nrIbTQCDmRVACiIVViovMgnbXyvn3ySC29c= MIME-Version: 1.0 Received: by 10.142.209.21 with SMTP id h21mr1252484wfg.162.1256658008258; Tue, 27 Oct 2009 08:40:08 -0700 (PDT) In-Reply-To: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> Date: Tue, 27 Oct 2009 23:40:08 +0800 Message-ID: <a7c8d0a30910270840l3fca4fa6v6ce58fa5d6db34f4@mail.gmail.com> From: Zhen Cao <caozhenpku@gmail.com> To: Dan Wing <dwing@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: =?UTF-8?B?5YiY5aSn6bmP?= <liudapeng@chinamobile.com>, =?UTF-8?B?5pu55oyv?= <caozhen@chinamobile.com>, behave@ietf.org, Behave Chairs <behave-chairs@tools.ietf.org> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 27 Oct 2009 15:39:57 -0000 Hi Dan and All, Many parts of the document are still very confusing. 1) It did not clearly specify the target scenario. From the title, people may think it is talking about IPv6 ftp client communicating with IPv4 server. But in section.5, it confuses me a lot by this sentence "even if the client has IPv4 reachability......". 2) ALG problem. Section 6 starts with ALG but does not specify clearly which case needs ALG and which does not. 3) Again ALG, multiple protocols need ALG in the NAT64 cases, we cannot specify them all and in fact many protocols related ALG have not been specified, i wonder if we have a strong motivation to define FTP Alg in this document. In this case, i do not see much difference between draft-liu-behave-ftp64-04 and draft-van-beijnum-behave-ftp64-06. Thanks and regards, Zhen 2009/10/23 Dan Wing <dwing@cisco.com>: > We are considering adopting draft-van-beijnum-behave-ftp64-06 as a WG document > to meet our milestone "Jan 2010 Submit to IESG: FTP ALG for IPv6/IPv4 > translation (std)", > http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-06 > > The author believes the document now incorporates all feedback. > > Please reply to the list. > -d > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From iljitsch@muada.com Tue Oct 27 08:45:32 2009 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 E48D63A6951 for <behave@core3.amsl.com>; Tue, 27 Oct 2009 08:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STWsyvDSsu6C for <behave@core3.amsl.com>; Tue, 27 Oct 2009 08:45:32 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id E93633A691F for <behave@ietf.org>; Tue, 27 Oct 2009 08:45:31 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.216]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n9RFj67X047045 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Oct 2009 16:45:06 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <a7c8d0a30910270840l3fca4fa6v6ce58fa5d6db34f4@mail.gmail.com> Date: Tue, 27 Oct 2009 16:45:37 +0100 Content-Transfer-Encoding: 7bit Message-Id: <0BD12441-097D-44D3-8D10-E58B84277DBB@muada.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> <a7c8d0a30910270840l3fca4fa6v6ce58fa5d6db34f4@mail.gmail.com> To: Zhen Cao <caozhenpku@gmail.com> X-Mailer: Apple Mail (2.1076) Cc: "behave@ietf.org WG" <behave@ietf.org> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 27 Oct 2009 15:45:33 -0000 On 27 okt 2009, at 16:40, Zhen Cao wrote: > Again ALG, multiple protocols need ALG in the NAT64 > cases, we cannot specify them all and in fact many protocols related > ALG have not been specified, Which protocols do you feel need ALGs to work through IPv6-to-IPv4 translators? Iljitsch From caozhenpku@gmail.com Tue Oct 27 08:59:16 2009 Return-Path: <caozhenpku@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 EDD443A6986 for <behave@core3.amsl.com>; Tue, 27 Oct 2009 08:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.038 X-Spam-Level: X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5 tests=[AWL=0.561, 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 FBBEzPw1bx-M for <behave@core3.amsl.com>; Tue, 27 Oct 2009 08:59:14 -0700 (PDT) Received: from mail-px0-f173.google.com (mail-px0-f173.google.com [209.85.216.173]) by core3.amsl.com (Postfix) with ESMTP id 920AA3A6847 for <behave@ietf.org>; Tue, 27 Oct 2009 08:59:14 -0700 (PDT) Received: by pxi3 with SMTP id 3so203440pxi.29 for <behave@ietf.org>; Tue, 27 Oct 2009 08:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Kb7bzCM7PwB4gguvzSwXLCecDbfpwp+7ywxDPdCFNHg=; b=WnT+o6sv7F4n05YFHlKZdEbChi6t2sFLdrXDYu42iYJ9H4dE3kaIT4jcsYecBSSNwN uVFvMQ+G3UZXYKyq+NVQXUgdhrFKoFLMUWNpABM+fPZAYQtQYMaFUs+hkULJT0SDrwOP CZthWUbzEaEI0FObPBd9G4Mv8LIA8xEZ+rVEw= 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=F0jHlCksyCjCg8JsZjDq18jz7UES9VHTTF5EU/6+RW3tY1ojZlmzhKUwgcdtosVaQH 1TUKXr/IXbaT7qxJaGRs18s3IQ5Olevg8209l9vT8cGxjysOWvJmqGPKJM4+r9N1dShD 9d74MNlddMNcRZzUyVHO9xxU6Ic+1PKTrnabs= MIME-Version: 1.0 Received: by 10.142.59.17 with SMTP id h17mr1232423wfa.45.1256659165575; Tue, 27 Oct 2009 08:59:25 -0700 (PDT) In-Reply-To: <0BD12441-097D-44D3-8D10-E58B84277DBB@muada.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> <a7c8d0a30910270840l3fca4fa6v6ce58fa5d6db34f4@mail.gmail.com> <0BD12441-097D-44D3-8D10-E58B84277DBB@muada.com> Date: Tue, 27 Oct 2009 23:59:25 +0800 Message-ID: <a7c8d0a30910270859i1b5ca44cjc0b3e2473d78f84d@mail.gmail.com> From: Zhen Cao <caozhenpku@gmail.com> To: Iljitsch van Beijnum <iljitsch@muada.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: "behave@ietf.org WG" <behave@ietf.org> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 27 Oct 2009 15:59:16 -0000 On Tue, Oct 27, 2009 at 11:45 PM, Iljitsch van Beijnum <iljitsch@muada.com> wrote: > On 27 okt 2009, at 16:40, Zhen Cao wrote: > >> Again ALG, multiple protocols need ALG in the NAT64 >> cases, we cannot specify them all and in fact many protocols related >> ALG have not been specified, > > Which protocols do you feel need ALGs to work through IPv6-to-IPv4 > translators? RTSP, SIP where there needs SDP to carry the address. > > Iljitsch > From marcelo@it.uc3m.es Tue Oct 27 09:26:12 2009 Return-Path: <marcelo@it.uc3m.es> 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 F1FAA3A6767 for <behave@core3.amsl.com>; Tue, 27 Oct 2009 09:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZANRz61p1fu for <behave@core3.amsl.com>; Tue, 27 Oct 2009 09:26:11 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id B90343A6359 for <behave@ietf.org>; Tue, 27 Oct 2009 09:26:10 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id F0A3C6BAC54 for <behave@ietf.org>; Tue, 27 Oct 2009 17:26:23 +0100 (CET) Message-ID: <4AE71F2F.1020402@it.uc3m.es> Date: Tue, 27 Oct 2009 17:26:23 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Behave WG <behave@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16972.003 Subject: [BEHAVE] Fragmentation and NAT64 stateful translation 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, 27 Oct 2009 16:26:12 -0000 Hi, So, one thing that is still under discussion is how does the NAT64 manages fragmentation. the issues that i describe here are specific to the stateful translation and do not affect the stateless translation. (see justification in each case below) I will try to present the issue concisely so we can have some discussion. In the IPv4 to IPv6 direction: ------------------------------ The problem here is that how to handle IPv4 packets containing fragments that are not the first fragment i.e. that do not contain the src, dest port information to allow the translation of the packet. So the question is how to handle packets containing fragments that are not the first. We have essentially two options: - We reassemble the fragments, so that we have a full packet and we process the full packet as any other packet. the Main problem here is that we need to buffer the packets. - We process fragments independently. In order to do that we need to create state based on the first fragment. the state basically would include the set of ID fields of all the fragmented packets of a given session. Managing that state may require some effort, i guess. In any case, we will to buffer the fragments in case the arrive out of order until the first fragment arrives (so we still need to buffer) (This is specific to stateful translation cause the port information is only used by the stateful translator to perform the translation) In the IPv6 to IPv4 direction: ------------------------------ The problem here is how to manage the IPv4 ID space for the IPv4 addresses assigned to the translator. Since the IPv4 addresses of the nat64 are shared among multiple IPv6 hosts, we need to make sure that dfferent packets belong have different IDs. (this si specific to the stateful case) (note that not all IPv6 packets carry the ID field and the IPv6 ID filed is 16 bits, while the IPv4 ID filed is 32 bits) So, we have two types of incoming IPv6 packets. - IPv6 packet withouth the fragmentation header. These packet do not carry a ID. these need to be translated to and IPv4 packet and needs to include an ID. So we need to assign them an ID. Since multiple source IPv6 addresses are translated as the same source IPv4 address, we need to make sure that they ID does not clash in the different packets. We could do this by simply using a counter for setting the ID of outgoing IPv4 packets, as any IPv4 host would do. - IPv6 packets with the fragmentation header. these are fragments of the same IPv6 packet. the question is how do we handle these. We have two options again: -- either we translate each IPv6 fragment independently, in which case we need to make sure that all IPv4 packet resulting from translating fragments of the IPv6 packet contain the same ID and the Offset is copied (i think that would be enough). In order to do that, we could simply copy the 16 bits of the IPv6 packet ID into the IPv4 packet ID, as long as it does not colides with the ID s we are suing for the non fragmented packets. In order to do that, we could partition the ID number space and use one part for non fragmented IPv6 packets and another for fragmented IPv6 packets (this is possible since the IPv4 ID sapce is bigger than the one in IPv6) -- the other option is to reassemble the IPv6 packet and process it as any other packet. the drawback here is that we need to buffer. So, as you can see one option would be to simply reassemble the packets in both directions and process them as any other packet. This is inline with what the stateless document is doing. And it would not add much complication to the spec. so, i am very tempted to go in that direction. does people have an opinion on this, why we should not do the reassemble first approach? Thanks, marcelo From cb.list6@gmail.com Tue Oct 27 09:40:15 2009 Return-Path: <cb.list6@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 3CF113A6925 for <behave@core3.amsl.com>; Tue, 27 Oct 2009 09:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 hpi47K-wOKH1 for <behave@core3.amsl.com>; Tue, 27 Oct 2009 09:40:14 -0700 (PDT) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 28B4C3A69A7 for <behave@ietf.org>; Tue, 27 Oct 2009 09:40:14 -0700 (PDT) Received: by pwi4 with SMTP id 4so211420pwi.29 for <behave@ietf.org>; Tue, 27 Oct 2009 09:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=spQxwScnKvaIz9GcZOfCYrqaVOMSMtmx4G479k4qvBU=; b=O0/96oGOL2b6ijWsPKtLKWwWs0Y/TEyoUbHGMHxcumhOdoKmurYChyKhkRX2q/HBu1 3YFKrdiDvEf/tV/1uc0NnKOxxcURGa8P6mlSNBxWVNvlErf4TSQszKvuS68V1QoHHt2G 11h+cbnDYs37+Y+5/Ktoixh9q+0Qsnjo5ziLo= 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=adDj/ptkR7EXnqZ4joHkI71XzYcpDusxKe+05sxGvLRICpBbhGpEuCgdNNJI7oQVGr z+xF6p13b/TysM+aqY54l7vRFAOV4fzrP/s9BR7zyVL4Q127F+qDmszMH5ODpMCntnjH uHqOow2fpym2Izd0rwvm3R/18QyYS/3ZZ3vjU= MIME-Version: 1.0 Received: by 10.142.5.35 with SMTP id 35mr1296511wfe.69.1256661623082; Tue, 27 Oct 2009 09:40:23 -0700 (PDT) In-Reply-To: <4AE71F2F.1020402@it.uc3m.es> References: <4AE71F2F.1020402@it.uc3m.es> Date: Tue, 27 Oct 2009 09:40:23 -0700 Message-ID: <bcff0fba0910270940t32c8cefp17390b852c5ee1c0@mail.gmail.com> From: Cameron Byrne <cb.list6@gmail.com> To: marcelo bagnulo braun <marcelo@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Fragmentation and NAT64 stateful translation 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, 27 Oct 2009 16:40:15 -0000 On Tue, Oct 27, 2009 at 9:26 AM, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote: > Hi, > > So, one thing that is still under discussion is how does the NAT64 manage= s > fragmentation. > > the issues that i describe here are specific to the stateful translation = and > do not affect the stateless translation. (see justification in each case > below) > > I will try to present the issue concisely so we can have some discussion. > > In the IPv4 to IPv6 direction: > ------------------------------ > > The problem here is that how to handle IPv4 packets containing fragments > that are not the first fragment i.e. that do not contain the src, dest po= rt > information to allow the translation of the packet. > So the question is how to handle packets containing fragments that are no= t > the first. > We have essentially two options: > - We reassemble the fragments, so that we have a full packet and we proce= ss > the full packet as any other packet. the Main problem here is that we nee= d > to buffer the packets. > - We process fragments independently. In order to do that we need to crea= te > state based on the first fragment. the state basically would include the = set > of ID fields of all the fragmented packets of a given session. Managing t= hat > state may require some effort, i guess. In any case, we will to buffer th= e > fragments in case the arrive out of order until the =A0first fragment arr= ives > (so we still need to buffer) > > (This is specific to stateful translation cause the port information is o= nly > used by the stateful translator to perform the translation) > > In the IPv6 to IPv4 direction: > ------------------------------ > > The problem here is how to manage the IPv4 ID space for the IPv4 addresse= s > assigned to the translator. > Since the IPv4 addresses of the nat64 are shared among multiple IPv6 host= s, > we need to make sure that dfferent packets belong have different IDs. (th= is > si specific to the stateful case) > (note that not all IPv6 packets carry the ID field and the IPv6 ID filed = is > 16 bits, while the IPv4 ID filed is 32 bits) > > So, we have two types of incoming IPv6 packets. > - IPv6 packet withouth the fragmentation header. These packet do not carr= y a > ID. these need to be translated to and IPv4 packet and needs to include a= n > ID. So we need to assign them an ID. Since multiple source IPv6 addresses > are translated as the same source IPv4 address, we need to make sure that > they ID does not clash in the different packets. We could do this by simp= ly > using a counter for setting the ID of outgoing IPv4 packets, as any IPv4 > host would do. > - IPv6 packets with the fragmentation header. these are fragments of the > same IPv6 packet. the question is how do we handle these. > We have two options again: > -- either we translate each IPv6 fragment independently, in which case we > need to make sure that all IPv4 packet resulting from translating fragmen= ts > of the IPv6 packet contain the same ID and the Offset is copied (i think > that would be enough). In order to do that, we could simply copy the 16 b= its > of the IPv6 packet ID into the IPv4 packet ID, as long as it does not > colides with the ID s we are suing for the non fragmented packets. In ord= er > to do that, we could partition the ID number space and use one part for n= on > fragmented IPv6 packets and another for fragmented IPv6 packets (this is > possible since the IPv4 ID sapce is bigger than the one in IPv6) > -- the other option is to reassemble the IPv6 packet and process it as an= y > other packet. the drawback here is that we need to buffer. > > > > So, as you can see one option would be to simply reassemble the packets i= n > both directions and process them as any other packet. This is inline with > what the stateless document is doing. And it would not add much complicat= ion > to the spec. Agreed. This is also consistent with how NAT44 works in rfc4787 > > so, i am very tempted to go in that direction. does people have an opinio= n > on this, why we should not do the reassemble first approach? > > Thanks, marcelo > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From ajs@shinkuro.com Tue Oct 27 11:57:04 2009 Return-Path: <ajs@shinkuro.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 F0A4F28C104 for <behave@core3.amsl.com>; Tue, 27 Oct 2009 11:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.86 X-Spam-Level: X-Spam-Status: No, score=0.86 tagged_above=-999 required=5 tests=[AWL=1.499, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 VV6oBDMXgPy8 for <behave@core3.amsl.com>; Tue, 27 Oct 2009 11:57:04 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 4D12628C101 for <behave@ietf.org>; Tue, 27 Oct 2009 11:57:04 -0700 (PDT) Received: from crankycanuck.ca (unknown [74.198.28.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 848612FE8CDC for <behave@ietf.org>; Tue, 27 Oct 2009 18:57:17 +0000 (UTC) Date: Tue, 27 Oct 2009 14:57:15 -0400 From: Andrew Sullivan <ajs@shinkuro.com> To: behave@ietf.org Message-ID: <20091027185713.GC60934@shinkuro.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> <a7c8d0a30910270840l3fca4fa6v6ce58fa5d6db34f4@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <a7c8d0a30910270840l3fca4fa6v6ce58fa5d6db34f4@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 27 Oct 2009 18:57:05 -0000 Dear colleagues, On Tue, Oct 27, 2009 at 11:40:08PM +0800, Zhen Cao wrote: > Many parts of the document are still very confusing. I'd very strongly prefer that we settle the question asked by the Chairs ("adopt this document or not?") in one thread; and if another thread for the discussion of the document is needed, open that thread for such discussion. As far as I can tell, the document is appropriate to adopt in order to form the basis for the WG milestone. I confess that I find it hard to get real excited about the milestone itself -- ftp is no longer, in my opinion, the critical protocol it once was -- but since the WG decided on the milestone, I think draft-van-beijnum-behave-ftp64-06 is a solid basis for the WG's work. I therefore support the adoption. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dwing@cisco.com Tue Oct 27 14:19:11 2009 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 3F0CB3A680F for <behave@core3.amsl.com>; Tue, 27 Oct 2009 14:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.126 X-Spam-Level: X-Spam-Status: No, score=-5.126 tagged_above=-999 required=5 tests=[AWL=-0.977, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nyJuOGx-fHT for <behave@core3.amsl.com>; Tue, 27 Oct 2009 14:19:10 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 5FDC43A67AA for <behave@ietf.org>; Tue, 27 Oct 2009 14:19:10 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEABoB50qrR7Hu/2dsb2JhbACEc4VttxqHDAiRO4EugjpXBIFf X-IronPort-AV: E=Sophos;i="4.44,635,1249257600"; d="scan'208";a="199215222" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 27 Oct 2009 21:19:13 +0000 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9RLJC01014206; Tue, 27 Oct 2009 21:19:12 GMT From: "Dan Wing" <dwing@cisco.com> To: "'Zhen Cao'" <caozhenpku@gmail.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> <a7c8d0a30910270840l3fca4fa6v6ce58fa5d6db34f4@mail.gmail.com> Date: Tue, 27 Oct 2009 14:19:16 -0700 Message-ID: <14ab01ca574b$240791c0$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpXG8OM3/vQSDBPRAGVM8k4YcdszwABE5fg In-Reply-To: <a7c8d0a30910270840l3fca4fa6v6ce58fa5d6db34f4@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: =?GB2312?B?J8H1tPPF9Cc=?= <liudapeng@chinamobile.com>, =?GB2312?B?J7Lc1fEn?= <caozhen@chinamobile.com>, behave@ietf.org, 'Behave Chairs' <behave-chairs@tools.ietf.org> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 27 Oct 2009 21:19:11 -0000 =20 > -----Original Message----- > From: Zhen Cao [mailto:caozhenpku@gmail.com]=20 > Sent: Tuesday, October 27, 2009 8:40 AM > To: Dan Wing > Cc: behave@ietf.org; =C1=F5=B4=F3=C5=F4; =B2=DC=D5=F1; Behave Chairs > Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06=20 > as WG item >=20 > Hi Dan and All, >=20 > Many parts of the document are still very confusing. 1) It did not > clearly specify the target scenario. From the title, people may think > it is talking about IPv6 ftp client communicating with IPv4 server. > But in section.5, it confuses me a lot by this sentence "even if the > client has IPv4 reachability......". 2) ALG problem. Section 6 starts > with ALG but does not specify clearly which case needs ALG and which > does not. Thanks. I expect those can be resolved as the document progresses as a WG document. > 3) Again ALG, multiple protocols need ALG in the NAT64 > cases, we cannot specify them all and in fact many protocols related > ALG have not been specified,=20 And are unlikely to be specified. On this topic, BEHAVE's charter says = "ALGs may be considered only for the most crucial of legacy applications.", http://www.ietf.org/dyn/wg/charter/behave-charter.html > i wonder if we have a strong motivation > to define FTP Alg in this document. http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-06#section-6 provides the motivation. Are you saying you disagree with the text in = that section, or disagree with its conclusion, or something else? -d > In this case, i do not see much > difference between draft-liu-behave-ftp64-04 and > draft-van-beijnum-behave-ftp64-06. >=20 > Thanks and regards, > Zhen >=20 > 2009/10/23 Dan Wing <dwing@cisco.com>: > > We are considering adopting=20 > draft-van-beijnum-behave-ftp64-06 as a WG document > > to meet our milestone "Jan 2010 Submit to IESG: FTP ALG for=20 > IPv6/IPv4 > > translation (std)", > > http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-06 > > > > The author believes the document now incorporates all feedback. > > > > Please reply to the list. > > -d > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > From caozhenpku@gmail.com Tue Oct 27 19:13:33 2009 Return-Path: <caozhenpku@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 55D6F3A6A96 for <behave@core3.amsl.com>; Tue, 27 Oct 2009 19:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.510, 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 GWRHy5JRMLfI for <behave@core3.amsl.com>; Tue, 27 Oct 2009 19:13:32 -0700 (PDT) Received: from mail-px0-f173.google.com (mail-px0-f173.google.com [209.85.216.173]) by core3.amsl.com (Postfix) with ESMTP id 64BEF3A67C0 for <behave@ietf.org>; Tue, 27 Oct 2009 19:13:32 -0700 (PDT) Received: by pxi3 with SMTP id 3so254638pxi.29 for <behave@ietf.org>; Tue, 27 Oct 2009 19:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7bKjIzPRiqySX7WgnwPvnSYcfJ5YxSs22zefUGM7IzQ=; b=YiWaf3YlFc6/BjkF14rNlN4/y8RoZHj1HwI/3ezEY6hq25GWCUx2LMUmqn0MA1zup3 3RkXl8kvn3pDujT1NcOVeUjWG4FzYDwFcCYb60Cr2pRz0TRcrzZLZmw7tERp4d5pWxJU sXPt3wuUb88JWbwpR7CjqR5FchfdBJEC55zIE= 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=FSXvsyMoe6cVq29B9x8ECtt5yAIxxmTPtXnbeH6DMGIRZhNLqhzgoBnMs9l7EgE03F sDTfzZdBu3oR4DdnTeqiv1GMWMb8hHHIlKNS4qQKqwCVF4aw9hy5mtv002j11omC90Ao Cvob/QokybZyWimmv/QgSDIgXE21W0FHdB6dg= MIME-Version: 1.0 Received: by 10.142.248.2 with SMTP id v2mr1343614wfh.177.1256696024757; Tue, 27 Oct 2009 19:13:44 -0700 (PDT) In-Reply-To: <4AE71F2F.1020402@it.uc3m.es> References: <4AE71F2F.1020402@it.uc3m.es> Date: Wed, 28 Oct 2009 10:13:44 +0800 Message-ID: <a7c8d0a30910271913l20d77a4ga916ac176338be4f@mail.gmail.com> From: Zhen Cao <caozhenpku@gmail.com> To: marcelo bagnulo braun <marcelo@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Fragmentation and NAT64 stateful translation 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: Wed, 28 Oct 2009 02:13:33 -0000 On Wed, Oct 28, 2009 at 12:26 AM, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote: > Hi, > > So, one thing that is still under discussion is how does the NAT64 manage= s > fragmentation. > > the issues that i describe here are specific to the stateful translation = and > do not affect the stateless translation. (see justification in each case > below) > > I will try to present the issue concisely so we can have some discussion. > > In the IPv4 to IPv6 direction: > ------------------------------ > > The problem here is that how to handle IPv4 packets containing fragments > that are not the first fragment i.e. that do not contain the src, dest po= rt > information to allow the translation of the packet. > So the question is how to handle packets containing fragments that are no= t > the first. > We have essentially two options: > - We reassemble the fragments, so that we have a full packet and we proce= ss > the full packet as any other packet. the Main problem here is that we nee= d > to buffer the packets. > - We process fragments independently. In order to do that we need to crea= te > state based on the first fragment. the state basically would include the = set > of ID fields of all the fragmented packets of a given session. Managing t= hat > state may require some effort, i guess. In any case, we will to buffer th= e > fragments in case the arrive out of order until the =A0first fragment arr= ives > (so we still need to buffer) > > (This is specific to stateful translation cause the port information is o= nly > used by the stateful translator to perform the translation) > > In the IPv6 to IPv4 direction: > ------------------------------ > > The problem here is how to manage the IPv4 ID space for the IPv4 addresse= s > assigned to the translator. > Since the IPv4 addresses of the nat64 are shared among multiple IPv6 host= s, > we need to make sure that dfferent packets belong have different IDs. (th= is > si specific to the stateful case) > (note that not all IPv6 packets carry the ID field and the IPv6 ID filed = is > 16 bits, while the IPv4 ID filed is 32 bits) IPv6 ID is 32 bits and IPv4 is 16 bits. > > So, we have two types of incoming IPv6 packets. > - IPv6 packet withouth the fragmentation header. These packet do not carr= y a > ID. these need to be translated to and IPv4 packet and needs to include a= n > ID. So we need to assign them an ID. Since multiple source IPv6 addresses > are translated as the same source IPv4 address, we need to make sure that > they ID does not clash in the different packets. We could do this by simp= ly > using a counter for setting the ID of outgoing IPv4 packets, as any IPv4 > host would do. > - IPv6 packets with the fragmentation header. these are fragments of the > same IPv6 packet. the question is how do we handle these. > We have two options again: > -- either we translate each IPv6 fragment independently, in which case we > need to make sure that all IPv4 packet resulting from translating fragmen= ts > of the IPv6 packet contain the same ID and the Offset is copied (i think > that would be enough). In order to do that, we could simply copy the 16 b= its > of the IPv6 packet ID into the IPv4 packet ID, as long as it does not > colides with the ID s we are suing for the non fragmented packets. In ord= er > to do that, we could partition the ID number space and use one part for n= on > fragmented IPv6 packets and another for fragmented IPv6 packets (this is > possible since the IPv4 ID sapce is bigger than the one in IPv6) > -- the other option is to reassemble the IPv6 packet and process it as an= y > other packet. the drawback here is that we need to buffer. > > So, as you can see one option would be to simply reassemble the packets i= n > both directions and process them as any other packet. This is inline with > what the stateless document is doing. And it would not add much complicat= ion > to the spec. Do you mean to choose option one for both 6-4 and 4-6 scenarios above? > > so, i am very tempted to go in that direction. does people have an opinio= n > on this, why we should not do the reassemble first approach? > > Thanks, marcelo > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From caozhenpku@gmail.com Tue Oct 27 22:16:35 2009 Return-Path: <caozhenpku@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 F18E628C178 for <behave@core3.amsl.com>; Tue, 27 Oct 2009 22:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.907 X-Spam-Level: X-Spam-Status: No, score=-0.907 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLAP5DPSvzyi for <behave@core3.amsl.com>; Tue, 27 Oct 2009 22:16:35 -0700 (PDT) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id E911B3A66B4 for <behave@ietf.org>; Tue, 27 Oct 2009 22:16:34 -0700 (PDT) Received: by pwi4 with SMTP id 4so648964pwi.29 for <behave@ietf.org>; Tue, 27 Oct 2009 22:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=A25Y6odoCokWdhhHGculr1arLULvKPHMo6HHbO1F3WI=; b=Bqh8OO3NScqi8Oha0J55iQrbEUqg4/Ex3Bsr6wIyISYBCW4Z3eeqFaAIeCrJn8+QD/ 1sBDdNlMUTryvWBKIBSsMG8vp1WEiUA7S9hd3HKojo/UnbRzUjehxbMF2BBlGEED3sWX NBslTZtPJnV7axbmoKry42CIUFkTHCYAI4zPE= 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=isvKaXu9Uz4+8l+MAku7Tzn/qeh6uyHyjdwtmxVqhI1v0uHFsZUcmVqUESS+cauIKz EX4qgv5vj2jxpEiKjQkhdvM0uDQ/C8+Gxxo/10ERSo31Bx87MdUyHWL5ExYkK0tq/q6Q /z6hz6M2MvaDOlIjBnY0erlpiF7+Buou+UrXA= MIME-Version: 1.0 Received: by 10.142.209.21 with SMTP id h21mr1350773wfg.162.1256707006639; Tue, 27 Oct 2009 22:16:46 -0700 (PDT) In-Reply-To: <14ab01ca574b$240791c0$c5f0200a@cisco.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> <a7c8d0a30910270840l3fca4fa6v6ce58fa5d6db34f4@mail.gmail.com> <14ab01ca574b$240791c0$c5f0200a@cisco.com> Date: Wed, 28 Oct 2009 13:16:46 +0800 Message-ID: <a7c8d0a30910272216s5e2860d5kd1f1325c9bcdb412@mail.gmail.com> From: Zhen Cao <caozhenpku@gmail.com> To: Dan Wing <dwing@cisco.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: =?GB2312?B?wfW088X0?= <liudapeng@chinamobile.com>, =?GB2312?B?stzV8Q==?= <caozhen@chinamobile.com>, behave@ietf.org, Behave Chairs <behave-chairs@tools.ietf.org> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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: Wed, 28 Oct 2009 05:16:36 -0000 2009/10/28 Dan Wing <dwing@cisco.com>: > > >> -----Original Message----- >> From: Zhen Cao [mailto:caozhenpku@gmail.com] >> Sent: Tuesday, October 27, 2009 8:40 AM >> To: Dan Wing >> Cc: behave@ietf.org; =C1=F5=B4=F3=C5=F4; =B2=DC=D5=F1; Behave Chairs >> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 >> as WG item >> >> Hi Dan and All, >> >> Many parts of the document are still very confusing. 1) It did not >> clearly specify the target scenario. From the title, people may think >> it is talking about IPv6 ftp client communicating with IPv4 server. >> But in section.5, it confuses me a lot by this sentence "even if the >> client has IPv4 reachability......". 2) ALG problem. Section 6 starts >> with ALG but does not specify clearly which case needs ALG and which >> does not. > > Thanks. I expect those can be resolved as the document progresses > as a WG document. Back to Andrew's proposal, I was just raising some concerns on why I do not support the adoption. I am afraid it is not a solid basis. From marcelo@it.uc3m.es Tue Oct 27 23:59:35 2009 Return-Path: <marcelo@it.uc3m.es> 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 6119C3A6830 for <behave@core3.amsl.com>; Tue, 27 Oct 2009 23:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRRHeT0moABa for <behave@core3.amsl.com>; Tue, 27 Oct 2009 23:59:34 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 5F2943A6870 for <behave@ietf.org>; Tue, 27 Oct 2009 23:59:34 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.30.143]) by smtp02.uc3m.es (Postfix) with ESMTP id 761596BADF7; Wed, 28 Oct 2009 07:59:47 +0100 (CET) Message-ID: <4AE7EBD8.5030603@it.uc3m.es> Date: Wed, 28 Oct 2009 07:59:36 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Zhen Cao <caozhenpku@gmail.com> References: <4AE71F2F.1020402@it.uc3m.es> <a7c8d0a30910271913l20d77a4ga916ac176338be4f@mail.gmail.com> In-Reply-To: <a7c8d0a30910271913l20d77a4ga916ac176338be4f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16974.003 Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Fragmentation and NAT64 stateful translation 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: Wed, 28 Oct 2009 06:59:35 -0000 Zhen Cao escribió: >> >> So, as you can see one option would be to simply reassemble the packets in >> both directions and process them as any other packet. This is inline with >> what the stateless document is doing. And it would not add much complication >> to the spec. >> > > Do you mean to choose option one for both 6-4 and 4-6 scenarios above? > > yes, would that make sense to you? Regards, marcelo >> so, i am very tempted to go in that direction. does people have an opinion >> on this, why we should not do the reassemble first approach? >> >> Thanks, marcelo >> >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >> > > From marcelo@it.uc3m.es Wed Oct 28 00:54:20 2009 Return-Path: <marcelo@it.uc3m.es> 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 663EA3A68DB for <behave@core3.amsl.com>; Wed, 28 Oct 2009 00:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[AWL=-1.148, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYrnykm1vrax for <behave@core3.amsl.com>; Wed, 28 Oct 2009 00:54:19 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 5F7643A68E2 for <behave@ietf.org>; Wed, 28 Oct 2009 00:54:19 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp03.uc3m.es (Postfix) with ESMTP id BD46A7F2FA0; Wed, 28 Oct 2009 08:54:32 +0100 (CET) Message-ID: <4AE7F8B8.3030407@it.uc3m.es> Date: Wed, 28 Oct 2009 08:54:32 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Zhen Cao <caozhenpku@gmail.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> <a7c8d0a30910270840l3fca4fa6v6ce58fa5d6db34f4@mail.gmail.com> <14ab01ca574b$240791c0$c5f0200a@cisco.com> <a7c8d0a30910272216s5e2860d5kd1f1325c9bcdb412@mail.gmail.com> In-Reply-To: <a7c8d0a30910272216s5e2860d5kd1f1325c9bcdb412@mail.gmail.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16974.003 Cc: =?GB2312?B?wfW088X0?= <liudapeng@chinamobile.com>, =?GB2312?B?stzV8Q==?= <caozhen@chinamobile.com>, behave@ietf.org, Behave Chairs <behave-chairs@tools.ietf.org>, Dan Wing <dwing@cisco.com> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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: Wed, 28 Oct 2009 07:54:20 -0000 Zhen, from the points you make, it doesn't seem that you have a fundamental problem with the document but changes that can easily be integrated in the document, if the WG agreed with them. Since we are only accepting a WG document and not in WGLC, i don't think the argument is strong not ot accept the doc as a WG document, it just needs to be improved as any other doc when accepted as WG document. Regards, marcelo Zhen Cao escribi¨®: > 2009/10/28 Dan Wing <dwing@cisco.com>: > >> >>> -----Original Message----- >>> From: Zhen Cao [mailto:caozhenpku@gmail.com] >>> Sent: Tuesday, October 27, 2009 8:40 AM >>> To: Dan Wing >>> Cc: behave@ietf.org; Áõ´óÅô; ²ÜÕñ; Behave Chairs >>> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 >>> as WG item >>> >>> Hi Dan and All, >>> >>> Many parts of the document are still very confusing. 1) It did not >>> clearly specify the target scenario. From the title, people may think >>> it is talking about IPv6 ftp client communicating with IPv4 server. >>> But in section.5, it confuses me a lot by this sentence "even if the >>> client has IPv4 reachability......". 2) ALG problem. Section 6 starts >>> with ALG but does not specify clearly which case needs ALG and which >>> does not. >>> >> Thanks. I expect those can be resolved as the document progresses >> as a WG document. >> > > Back to Andrew's proposal, I was just raising some concerns on why I > do not support the adoption. I am afraid it is not a solid basis. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From fernando.gont.netbook.win@gmail.com Wed Oct 28 02:21:36 2009 Return-Path: <fernando.gont.netbook.win@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 C50BA3A699D for <behave@core3.amsl.com>; Wed, 28 Oct 2009 02:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0JVhOMtZhJO for <behave@core3.amsl.com>; Wed, 28 Oct 2009 02:21:36 -0700 (PDT) Received: from mail-bw0-f166.google.com (mail-bw0-f166.google.com [209.85.218.166]) by core3.amsl.com (Postfix) with ESMTP id BD00F3A697D for <behave@ietf.org>; Wed, 28 Oct 2009 02:21:35 -0700 (PDT) Received: by mail-bw0-f166.google.com with SMTP id 6so232063bwz.9 for <behave@ietf.org>; Wed, 28 Oct 2009 02:21:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:x-enigmail-version:openpgp :content-type:content-transfer-encoding; bh=Puykz+994tu84ReUb6j+repf9o6n0QG0rzjdZuCeRpg=; b=Zvw5/QNEEjIRD4DfSfdwJ3K2aNuTiFVNrz23YeQ91UCGXTpnF0cs/ZZYOX0w5hJ0Yf qCl/s8f9XvBpKC5a9ocIGjLSdpJvV4xMQp7U56PjCI6ZerdAxIO6ZDBHATZzPhqIAxzb ewXsDp8WyZYOGbK7PZcVlnU8ojq93IH+nClpE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=klTte9rTOalRHjgEv0E9/ZGxfPk4rzT9BwiK8b/K5sA6dQU11yx7xIOJwGYEMskuEA wxaMIJ9TZkiaJS0k46KJXVwjcdDFrx1/RVDq2EQWmvzbg+UzH7/ILxAoioemb8YoCTQm T0p86NJQz6w+li4IVsiSYcIBiPfAdwbKByFi4= Received: by 10.204.6.65 with SMTP id 1mr6668142bky.186.1256721710837; Wed, 28 Oct 2009 02:21:50 -0700 (PDT) Received: from ?192.168.98.26? (ip-213-135-236-32.static.luxdsl.pt.lu [213.135.236.32]) by mx.google.com with ESMTPS id 14sm209331bwz.13.2009.10.28.02.21.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 28 Oct 2009 02:21:50 -0700 (PDT) Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com> Message-ID: <4AE7FF0D.9020003@gont.com.ar> Date: Wed, 28 Oct 2009 06:21:33 -0200 From: Fernando Gont <fernando@gont.com.ar> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Behave WG <behave@ietf.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [BEHAVE] New revision of our I-D on NAT security 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: Wed, 28 Oct 2009 09:21:36 -0000 Hello, folks, We have posted a revision of our I-D draft-gont-behave-nat-security. The new I-D is available at: http://tools.ietf.org/id/draft-gont-behave-nat-security-03.txt We have restructured the document, removed some sections, added others, etc. Your feedback would be really welcome. Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From marcelo@it.uc3m.es Wed Oct 28 02:24:34 2009 Return-Path: <marcelo@it.uc3m.es> 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 111313A67E4 for <behave@core3.amsl.com>; Wed, 28 Oct 2009 02:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRnfcX1Rb40i for <behave@core3.amsl.com>; Wed, 28 Oct 2009 02:24:33 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 3B9EE3A67D3 for <behave@ietf.org>; Wed, 28 Oct 2009 02:24:33 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp01.uc3m.es (Postfix) with ESMTP id D165DBA7B77 for <behave@ietf.org>; Wed, 28 Oct 2009 10:24:46 +0100 (CET) Message-ID: <4AE80DDE.4040709@it.uc3m.es> Date: Wed, 28 Oct 2009 10:24:46 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Behave WG <behave@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16974.003 Subject: [BEHAVE] PMTUD, TCP MSS, stateless and stateful translation 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: Wed, 28 Oct 2009 09:24:34 -0000 Hi, After looking into the issue regarding PMUTD, i cannot find anything that is specific to the stateful translation about PMTUD. Does anybody sees anything that should be covered in the statefull document about the PMTUD handling? If not, i will refer as much as possible to the stateless document for this. Similar to the TCP MSS handling. I don't think there is anything specific about how to handle that to the stateful translator. I will also refer then to the stateless translator. Comments? regards, marcelo From fernando.gont.netbook.win@gmail.com Wed Oct 28 03:23:16 2009 Return-Path: <fernando.gont.netbook.win@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 5A2F53A67E4 for <behave@core3.amsl.com>; Wed, 28 Oct 2009 03:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lqppd49nsXGb for <behave@core3.amsl.com>; Wed, 28 Oct 2009 03:23:15 -0700 (PDT) Received: from mail-bw0-f166.google.com (mail-bw0-f166.google.com [209.85.218.166]) by core3.amsl.com (Postfix) with ESMTP id 4CEAB3A67B6 for <behave@ietf.org>; Wed, 28 Oct 2009 03:23:15 -0700 (PDT) Received: by bwz6 with SMTP id 6so248871bwz.9 for <behave@ietf.org>; Wed, 28 Oct 2009 03:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=N9MpxjBtZxLGK6f3U+9a0oIxu4+6pkEEKoDENDV4dcw=; b=kVQoJPn02DIdb1OBW7YG6Qa4d0iWF6fr0WeZ8ufoPG3f9Nvdi1J3vszf+JmIwGOEqn PnIhmMmTyxj8bJ+bbC7Y1mBALPAzy+WAdEPDYeAAvf3j9Uq8tE64+72uavUgmPJ6qXKX D/XPO42uSG5GZ08dwN2Kar7eK6HbeoYJj1Tpk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=CFeIXltf104DQNXiFFeoP0rW5cBAfc7yxao/MnhTgbdTIvi8B9IhmQSTwuvTLe6vF4 Ixh6vAMepYVDjWglZyTXlLx+5tSI+oSi+KCzQNOmhZarxeh/CB/gHHnU6tB5S5eLPCMV BPzvbO7gulYtEY/Wl5nTRb+m9djIhdA3ZHnqU= Received: by 10.204.154.135 with SMTP id o7mr526000bkw.201.1256725406375; Wed, 28 Oct 2009 03:23:26 -0700 (PDT) Received: from ?192.168.98.26? (ip-213-135-236-32.static.luxdsl.pt.lu [213.135.236.32]) by mx.google.com with ESMTPS id 13sm221478bwz.6.2009.10.28.03.23.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 28 Oct 2009 03:23:24 -0700 (PDT) Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com> Message-ID: <4AE80D84.20109@gont.com.ar> Date: Wed, 28 Oct 2009 07:23:16 -0200 From: Fernando Gont <fernando@gont.com.ar> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Lars Eggert <lars.eggert@nokia.com> References: <C70A9263.68C5%rpenno@juniper.net> <4AE54B88.2090104@it.uc3m.es> <B8C0608A-10E2-4212-9662-E317CA8C5CD9@nokia.com> In-Reply-To: <B8C0608A-10E2-4212-9662-E317CA8C5CD9@nokia.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" <behave@ietf.org> Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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: Wed, 28 Oct 2009 10:23:16 -0000 Lars Eggert wrote: >> I personally don't have an issue with adding this text. I will do so >> unless someone else has a problem and thinks it deserves more discussion. > > objection. A NAT is *not* a security device and does not implement > "security policies." > > We've hit this several times in the past with different BEHAVE document, > and we've always been very careful to focus on the "translator" > functions only. (Other WGs have talked about firewall/security > functions, e.g., V6OPS.) As part of that translation, you hit security issues whether you like it or not. >From the external realm, all connections come from the NAT. Therefore the NAT should comply to the same type of requirements as and end system (e.g., in respect of how ISNs are generated, how IP IDs are selected, etc.) -- if you don't, there's the potential of interoperability problems *introduced* by the NAT behavior. Once you realize there's more you should do than translating the addresses, you probably want to do it security-wise. Although, the NAT could be subject of DoS attacks similar to those that can be performed against end-systems (e.g., fragmentation attacks). So yes, the NAT should do something about it. P.S.: draft-gont-behace-nat-security discusses some of these issues. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From iljitsch@muada.com Wed Oct 28 03:29:33 2009 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 5951A3A68B3 for <behave@core3.amsl.com>; Wed, 28 Oct 2009 03:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXJAJxyEJHIu for <behave@core3.amsl.com>; Wed, 28 Oct 2009 03:29:32 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 0ABBD3A6358 for <behave@ietf.org>; Wed, 28 Oct 2009 03:29:31 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.216]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n9SASh6q053983 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Oct 2009 11:29:06 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <a7c8d0a30910270859i1b5ca44cjc0b3e2473d78f84d@mail.gmail.com> Date: Wed, 28 Oct 2009 11:29:43 +0100 Content-Transfer-Encoding: 7bit Message-Id: <D3A4D7F4-F2DB-40AD-A37B-5C500B630169@muada.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> <a7c8d0a30910270840l3fca4fa6v6ce58fa5d6db34f4@mail.gmail.com> <0BD12441-097D-44D3-8D10-E58B84277DBB@muada.com> <a7c8d0a30910270859i1b5ca44cjc0b3e2473d78f84d@mail.gmail.com> To: Zhen Cao <caozhenpku@gmail.com> X-Mailer: Apple Mail (2.1076) Cc: "behave@ietf.org WG" <behave@ietf.org> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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: Wed, 28 Oct 2009 10:29:33 -0000 On 27 okt 2009, at 16:59, Zhen Cao wrote: >> Which protocols do you feel need ALGs to work through IPv6-to-IPv4 >> translators? > RTSP, SIP where there needs SDP to carry the address. I'm not sure about the status of RTSP, but I believe that it's used less and less exactly because it doesn't work through NAT44 without an ALG... As for SIP, I believe the consensus is that ALGs create more harm than benefit. The wg consensus is that the use of ALGs should be minimized. I don't believe there would be consensus to specify RTSP and SIP ALGs for NAT64. From fernando.gont.netbook.win@gmail.com Wed Oct 28 03:32:48 2009 Return-Path: <fernando.gont.netbook.win@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 26F683A68BA for <behave@core3.amsl.com>; Wed, 28 Oct 2009 03:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rxj9H491bYuX for <behave@core3.amsl.com>; Wed, 28 Oct 2009 03:32:47 -0700 (PDT) Received: from mail-bw0-f166.google.com (mail-bw0-f166.google.com [209.85.218.166]) by core3.amsl.com (Postfix) with ESMTP id 21E643A68B3 for <behave@ietf.org>; Wed, 28 Oct 2009 03:32:46 -0700 (PDT) Received: by bwz6 with SMTP id 6so251762bwz.9 for <behave@ietf.org>; Wed, 28 Oct 2009 03:32:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=AiQcK0Uy1Jx3Ufd2pjKFoWLUh3d9mUV/f9NOPXIDNbQ=; b=GmbqkNseOcN2N6fgMVbNeS+nLdLYT4TvCUDJiGASoea4rb/SQsEUkCyjWv7jJOEnZS mIcNevv/KgCtfN5UnsXMzdP+7p51i9+EATiALUFHXKSdROaKIif+tf7SytNAunVEmV5Q AaT45+27oXco10Jk9GWTAsFUd7wmrJ8vO+Phk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=Hczz3jAHphyh/PKPXGK5YqXq7PpT5S+kkCsaKL/sx+LqTTJpk48FiB5Y/lIQjXmuRO YOUll1DT/VD7efANly/ME74H0J5yuRTBOwhfg//28TfgsUILmaJt4tDOpSeL+XWuZYxu DVgkX1MIGRPlMrYJtPy4JLuso/0pm+79bJ8iE= Received: by 10.204.48.140 with SMTP id r12mr3660534bkf.112.1256725977675; Wed, 28 Oct 2009 03:32:57 -0700 (PDT) Received: from ?192.168.98.26? (ip-213-135-236-32.static.luxdsl.pt.lu [213.135.236.32]) by mx.google.com with ESMTPS id 16sm120797bwz.7.2009.10.28.03.32.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 28 Oct 2009 03:32:56 -0700 (PDT) Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com> Message-ID: <4AE80FC0.2040609@gont.com.ar> Date: Wed, 28 Oct 2009 07:32:48 -0200 From: Fernando Gont <fernando@gont.com.ar> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Iljitsch van Beijnum <iljitsch@muada.com> References: <C70AD9D5.6994%rpenno@juniper.net> <6D9F9B2D-BEAB-4EF0-9465-CB9A4054C21B@muada.com> In-Reply-To: <6D9F9B2D-BEAB-4EF0-9465-CB9A4054C21B@muada.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" <behave@ietf.org> Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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: Wed, 28 Oct 2009 10:32:48 -0000 Iljitsch van Beijnum wrote: >> There is an >> interesting document about this subject. > >> http://tools.ietf.org/html/draft-gont-behave-nat-security-01 > > I wasn't very impressed with the previous documents in this series, so > I'll save myself and the author the aggravation of reading it and then > firing off a bunch of criticisms. There was a single (real) version of the I-D (-01), which has now been revised. Version -01 was presented at MPLS, but my impression was that quite a few folks were in "reject mode" by default. And didn't consider the interoperability implications that may arise when you do less than what you should be doing. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From iljitsch@muada.com Wed Oct 28 04:07:14 2009 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 068C93A68E0 for <behave@core3.amsl.com>; Wed, 28 Oct 2009 04:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hU8dawcaCdCo for <behave@core3.amsl.com>; Wed, 28 Oct 2009 04:07:13 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id D7CEE3A6774 for <behave@ietf.org>; Wed, 28 Oct 2009 04:07:12 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.216]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n9SB6k0R055024 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Oct 2009 12:06:47 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <4AE80D84.20109@gont.com.ar> Date: Wed, 28 Oct 2009 12:07:18 +0100 Content-Transfer-Encoding: 7bit Message-Id: <19A72C76-2837-4636-8DF5-2B6586C1AB1A@muada.com> References: <C70A9263.68C5%rpenno@juniper.net> <4AE54B88.2090104@it.uc3m.es> <B8C0608A-10E2-4212-9662-E317CA8C5CD9@nokia.com> <4AE80D84.20109@gont.com.ar> To: Fernando Gont <fernando@gont.com.ar> X-Mailer: Apple Mail (2.1076) Cc: "behave@ietf.org" <behave@ietf.org> Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-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: Wed, 28 Oct 2009 11:07:14 -0000 On 28 okt 2009, at 10:23, Fernando Gont wrote: > As part of that translation, you hit security issues whether you > like it > or not. From http://tools.ietf.org/html/draft-gont-behave-nat-security-01 When the target host receives the two unrelated datagrams, carrying same fragmentation id, and from the same assigned host address, the target host is unable to determine which of the two sessions the datagrams belong to and might corrupt both sessions. This can be a security breach any of the sessions associated. This is not a security issue. This is a correctness issue. Here we invoke the words "unreliable datagram service". In other words: life is hard, corruption happens, if you don't like it, use better checksums at higher layers. Which is of course exactly what protocols that promote security such as TLS and IPsec do. Nothing to see here; please move along. (I predicted that me reading that draft wouldn't be fun for either of us.) Here's something I especially disagree with: NATs should implement an ephemeral port selection algorithm such that the source port of outgoing packets is obfuscated This is NOT a NAT's job! NATs should rewrite the Sequence Number This is ridiculous. Tracking sequence numbers increase state in a NAT significantly, while the end-to-end argument tells us that if the endpoint need to select initial sequence numbers properly anyway, there is no point in a middlebox revisiting that decision. Your unstated assumption is that hosts make the wrong choices and NATs should rectify that situation. That is NOT what NATs are for!!! And that goes double for NAT64s! From iljitsch@muada.com Wed Oct 28 04:11:03 2009 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 4BC5F28C0E0 for <behave@core3.amsl.com>; Wed, 28 Oct 2009 04:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vyhbP03Jnxi for <behave@core3.amsl.com>; Wed, 28 Oct 2009 04:11:02 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 423B63A6774 for <behave@ietf.org>; Wed, 28 Oct 2009 04:11:02 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.216]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n9SBAc4q055051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Oct 2009 12:10:38 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <4AE80DDE.4040709@it.uc3m.es> Date: Wed, 28 Oct 2009 12:11:09 +0100 Content-Transfer-Encoding: 7bit Message-Id: <E6C96682-26DD-4C59-B196-15DD2F656686@muada.com> References: <4AE80DDE.4040709@it.uc3m.es> To: marcelo bagnulo braun <marcelo@it.uc3m.es> X-Mailer: Apple Mail (2.1076) Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] PMTUD, TCP MSS, stateless and stateful translation 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: Wed, 28 Oct 2009 11:11:03 -0000 On 28 okt 2009, at 10:24, marcelo bagnulo braun wrote: > After looking into the issue regarding PMUTD, i cannot find anything > that is specific to the stateful translation about PMTUD. Does > anybody sees anything that should be covered in the statefull > document about the PMTUD handling? If not, i will refer as much as > possible to the stateless document for this. Sorry I didn't mention this earlier: but the ID field handling needs to be different in a few places. > Similar to the TCP MSS handling. I don't think there is anything > specific about how to handle that to the stateful translator. I will > also refer then to the stateless translator. My conclusion a while back was that the added benefit of making changes to the TCP MSS option aren't worth the additional complexity. In the common situation where all hosts use a 1500-byte MTU there is no benefit to modifying the MSS. In some other situations modifying the MTU reduces a PMTUD step, but PMTUD needs to work anyway to support the cases where the smallest MTU isn't in the first or last hop. From iljitsch@muada.com Wed Oct 28 04:14:01 2009 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 7379E3A6928 for <behave@core3.amsl.com>; Wed, 28 Oct 2009 04:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amsNGm8C+5LN for <behave@core3.amsl.com>; Wed, 28 Oct 2009 04:14:00 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id CCF253A6962 for <behave@ietf.org>; Wed, 28 Oct 2009 04:13:59 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.216]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n9SBCr3p055090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Oct 2009 12:13:32 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <25e1aaa40910262003u3779279fxa614487c9d304f87@mail.gmail.com> Date: Wed, 28 Oct 2009 12:14:09 +0100 Content-Transfer-Encoding: 7bit Message-Id: <8DC9E6B4-DF80-436C-BFC0-0B4990B275B8@muada.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> <25e1aaa40910230404m4517c64ew2a04e610cc6f2bcd@mail.gmail.com> <D1DA2BB2-E064-4656-B75A-A10339A1B9FB@muada.com> <86F15BB9FC58443ABF2071A5CC843384@JiangXiong> <09be01ca5660$7a1de870$c5f0200a@cisco.com> <25e1aaa40910262003u3779279fxa614487c9d304f87@mail.gmail.com> To: liu dapeng <maxpassion@gmail.com> X-Mailer: Apple Mail (2.1076) Cc: "behave@ietf.org WG" <behave@ietf.org> Subject: [BEHAVE] draft-liu-behave-ftp64-04 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: Wed, 28 Oct 2009 11:14:01 -0000 On 27 okt 2009, at 04:03, liu dapeng wrote: > We updated the ftp64 draft: > http://tools.ietf.org/html/draft-liu-behave-ftp64-04. > As you mentioned, attitude toward FTP ALG is one of the ideas that > merged by draft-van-beijnum-behave-ftp64-06.txt; Furthermore, the > handling of FTP client when retrying with PASV command is another > important idea that merged by draft-van-beijnum-behave-ftp64-06.txt. If I remember correctly, this is the first place this idea is mentioned: http://www.ietf.org/mail-archive/web/behave/current/msg05940.html It appears in the -03 version of draft-van-beijnum-behave-ftp64. > We believe that draft-van-beijnum-behave-ftp64-06 still need more > improvement, > so we upgrade draft-liu-behave-ftp64-04 to reflect our thoughts more > precisely. We would like the WG to review and comments on this draft > and to see whether it is more suitable to be the working foundation to > further proceed the ftp64 issue in IPv6 transition scenario. I read draft-liu-behave-ftp64-04, but I didn't see any places where you suggest new ways forward that are very different from draft-van- beijnum-behave-ftp64-06, except that the ALG specification is much less detailed and no server changes are specified, only client changes. Can you please outline your specific suggestions? (It also seems that draft-liu-behave-ftp64 has taken many ideas from draft-van-beijnum-behave-ftp64. In some cases, the wording is even quite close.) From zhouboyj@gmail.com Wed Oct 28 05:00:11 2009 Return-Path: <zhouboyj@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 9560D28C11B for <behave@core3.amsl.com>; Wed, 28 Oct 2009 05:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.373 X-Spam-Level: X-Spam-Status: No, score=-1.373 tagged_above=-999 required=5 tests=[AWL=1.225, 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 LaikuvUJOXFp for <behave@core3.amsl.com>; Wed, 28 Oct 2009 05:00:10 -0700 (PDT) Received: from mail-iw0-f202.google.com (mail-iw0-f202.google.com [209.85.223.202]) by core3.amsl.com (Postfix) with ESMTP id 8E1BC3A6784 for <behave@ietf.org>; Wed, 28 Oct 2009 05:00:10 -0700 (PDT) Received: by iwn40 with SMTP id 40so566742iwn.32 for <behave@ietf.org>; Wed, 28 Oct 2009 05:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=D2IAAsM9K6zBjlIo2VnPdzeacawP9G6Q+UKrIPVmB+4=; b=BlGcrVqHGgzwfpoyb+cgziBFqBVJhBEiS4+TPwL63XAui0wEUaFDA0JnfkzaZgLar/ cteDpgoezldBc/dCs0JghZCIxKRH+BWeJhB/+QqlNK/w5UCInr8oF6zvP2N77n+fGKRh 5UVvo5I+vK3Kkhxq7RQs1Na5qGZ2pJJnpYk74= 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=JRMvi2E3LZaWUEYS6JZYHw4rXlQdQ5vrP8Pxu+9Pq8eF4/cGVatW4jasQh6pcXSXC5 Ka/iwdYmiqxd4+BjQPS0U3aMGisW+33moLuaqEteTXGZ4tqs4YHn05IuMa6tqRM9bgsK hTNDU5VFKgoGMt4OReXuI6fmfB/BO50V7Ni+4= MIME-Version: 1.0 Received: by 10.231.83.75 with SMTP id e11mr4302292ibl.11.1256731223043; Wed, 28 Oct 2009 05:00:23 -0700 (PDT) In-Reply-To: <D3A4D7F4-F2DB-40AD-A37B-5C500B630169@muada.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> <a7c8d0a30910270840l3fca4fa6v6ce58fa5d6db34f4@mail.gmail.com> <0BD12441-097D-44D3-8D10-E58B84277DBB@muada.com> <a7c8d0a30910270859i1b5ca44cjc0b3e2473d78f84d@mail.gmail.com> <D3A4D7F4-F2DB-40AD-A37B-5C500B630169@muada.com> Date: Wed, 28 Oct 2009 20:00:22 +0800 Message-ID: <36a593230910280500o2737e5c5t77a433a770dc9364@mail.gmail.com> From: bo zhou <zhouboyj@gmail.com> To: Iljitsch van Beijnum <iljitsch@muada.com> Content-Type: multipart/alternative; boundary=000e0cd6aa0620aec90476fd8ac9 Cc: "behave@ietf.org WG" <behave@ietf.org>, Zhen Cao <caozhenpku@gmail.com> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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: Wed, 28 Oct 2009 12:00:11 -0000 --000e0cd6aa0620aec90476fd8ac9 Content-Type: text/plain; charset=ISO-8859-1 Hi Iljitsch, "minimize" does not mean avoid in my mind. BTW, you ask "which protocols do you feel need ALGs to work through 6-to-4 translator?" I guess Zhen want to answer your question using RTSP, SIP as two examples. I believe more applications rather than RTSP, SIP need to do ALG in such scenario, but it is really depend on how the user use these applications. for example, a standard HTTP protocol can include IP address or domain name inside. if the user choose the IP address filling, then the ALG cannot avoid. But likely, more user use domain name rather than IP address for HTTP application which need not ALG in the translator. regards, Bo On Wed, Oct 28, 2009 at 6:29 PM, Iljitsch van Beijnum <iljitsch@muada.com>wrote: > On 27 okt 2009, at 16:59, Zhen Cao wrote: > > Which protocols do you feel need ALGs to work through IPv6-to-IPv4 >>> translators? >>> >> > RTSP, SIP where there needs SDP to carry the address. >> > > I'm not sure about the status of RTSP, but I believe that it's used less > and less exactly because it doesn't work through NAT44 without an ALG... > > As for SIP, I believe the consensus is that ALGs create more harm than > benefit. > > The wg consensus is that the use of ALGs should be minimized. I don't > believe there would be consensus to specify RTSP and SIP ALGs for NAT64. > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > -- Regards, Bo Zhou China Mobile --000e0cd6aa0620aec90476fd8ac9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>Hi Iljitsch,</div> <div>=A0</div> <div>"minimize" does not mean avoid in my mind. </div> <div>BTW, you ask "which protocols do you feel need ALGs to work throu= gh 6-to-4 translator?"</div> <div>I guess Zhen want to answer your question using RTSP, SIP as two examp= les.</div> <div>I believe more applications rather than RTSP, SIP need to do ALG in su= ch scenario, but it is really depend on how the user use these applications= . for example, a standard HTTP protocol can include IP address or domain na= me inside. if the user choose the IP address filling, then the ALG cannot a= void. But likely, more user use domain name rather than IP address for HTTP= application which need not ALG in the translator. </div> <div>=A0</div> <div>regards,</div> <div>=A0</div> <div>Bo </div> <div><br><br>=A0</div> <div class=3D"gmail_quote">On Wed, Oct 28, 2009 at 6:29 PM, Iljitsch van Be= ijnum <span dir=3D"ltr"><<a href=3D"mailto:iljitsch@muada.com">iljitsch@= muada.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0= px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"> <div class=3D"im">On 27 okt 2009, at 16:59, Zhen Cao wrote:<br><br> <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0= px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"> <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0= px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Which protocols do you feel need= ALGs to work through IPv6-to-IPv4<br>translators?<br></blockquote></blockq= uote> <br> <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0= px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">RTSP, SIP where there needs SDP = to carry the address.<br></blockquote><br></div>I'm not sure about the = status of RTSP, but I believe that it's used less and less exactly beca= use it doesn't work through NAT44 without an ALG...<br> <br>As for SIP, I believe the consensus is that ALGs create more harm than = benefit.<br><br>The wg consensus is that the use of ALGs should be minimize= d. I don't believe there would be consensus to specify RTSP and SIP ALG= s for NAT64.=20 <div> <div></div> <div class=3D"h5"><br>_______________________________________________<br>Be= have mailing list<br><a href=3D"mailto:Behave@ietf.org" target=3D"_blank">B= ehave@ietf.org</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/beha= ve" target=3D"_blank">https://www.ietf.org/mailman/listinfo/behave</a><br> </div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Regards,<br= ><br>Bo Zhou<br>China Mobile<br> --000e0cd6aa0620aec90476fd8ac9-- From zhouboyj@gmail.com Wed Oct 28 05:02:31 2009 Return-Path: <zhouboyj@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 858D63A6982 for <behave@core3.amsl.com>; Wed, 28 Oct 2009 05:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.761 X-Spam-Level: X-Spam-Status: No, score=-0.761 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4rdqGlrPA7H for <behave@core3.amsl.com>; Wed, 28 Oct 2009 05:02:30 -0700 (PDT) Received: from mail-iw0-f202.google.com (mail-iw0-f202.google.com [209.85.223.202]) by core3.amsl.com (Postfix) with ESMTP id 6F6AD3A696A for <behave@ietf.org>; Wed, 28 Oct 2009 05:02:30 -0700 (PDT) Received: by iwn40 with SMTP id 40so568244iwn.32 for <behave@ietf.org>; Wed, 28 Oct 2009 05:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=fy+9k5yxaJpHfUWcQlQu6RIk9i5RpY9trfy69uNJE3Q=; b=XnaxAC2a2AwYOFVpxCNjij1fIAAgVfV2MtTO3UJY5oPzjelFLXZJ7BjECsYmLlZDqJ cY8B2p5HiRdbxzN2lVoR3RdaiOXIcico5ORBJMTjFKwSIBj/eOwlVQO+7p5ahiGC55F1 5py0vilVY5DjmNVd4OqMrG8raZG4zv15QyqxA= 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=UglqCGoA9UUhhhAaZ0MknkrkOhDLaedixPWK45jXFXA8bRXIxohmsbat9UTjbwOAGs 4A47NIbqhrnpcanrI48uk23CAfJwuRFHZr/uNt80UClGAdvNeC+3GDDlQ+M1XfiBh19G ZaVv7gGAa7Kswm56LS/Z6WHP7PDphvJJUHbQU= MIME-Version: 1.0 Received: by 10.231.3.220 with SMTP id 28mr3374824ibo.40.1256731362881; Wed, 28 Oct 2009 05:02:42 -0700 (PDT) In-Reply-To: <4AE7F8B8.3030407@it.uc3m.es> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> <a7c8d0a30910270840l3fca4fa6v6ce58fa5d6db34f4@mail.gmail.com> <14ab01ca574b$240791c0$c5f0200a@cisco.com> <a7c8d0a30910272216s5e2860d5kd1f1325c9bcdb412@mail.gmail.com> <4AE7F8B8.3030407@it.uc3m.es> Date: Wed, 28 Oct 2009 20:02:42 +0800 Message-ID: <36a593230910280502u7d7c0f62vcffdbb8924611715@mail.gmail.com> From: bo zhou <zhouboyj@gmail.com> To: marcelo bagnulo braun <marcelo@it.uc3m.es> Content-Type: multipart/alternative; boundary=00151773dfb27671a90476fd928f Cc: behave@ietf.org, Zhen Cao <caozhenpku@gmail.com>, =?GB2312?B?wfW088X0?= <liudapeng@chinamobile.com>, =?GB2312?B?stzV8Q==?= <caozhen@chinamobile.com>, Behave Chairs <behave-chairs@tools.ietf.org>, Dan Wing <dwing@cisco.com> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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: Wed, 28 Oct 2009 12:02:31 -0000 --00151773dfb27671a90476fd928f Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Marcelo, In your mind, what's fundamental problem? Could you give us a definition? I am a little confused. Thank you very much. Regards, Bo 2009/10/28 marcelo bagnulo braun <marcelo@it.uc3m.es> > Zhen, > > from the points you make, it doesn't seem that you have a fundamental > problem with the document but changes that can easily be integrated in > the document, if the WG agreed with them. Since we are only accepting a > WG document and not in WGLC, i don't think the argument is strong not ot > accept the doc as a WG document, it just needs to be improved as any > other doc when accepted as WG document. > > Regards, marcelo > > > Zhen Cao escribi=A8=AE: > > 2009/10/28 Dan Wing <dwing@cisco.com>: > > > >> > >>> -----Original Message----- > >>> From: Zhen Cao [mailto:caozhenpku@gmail.com] > >>> Sent: Tuesday, October 27, 2009 8:40 AM > >>> To: Dan Wing > >>> Cc: behave@ietf.org; =C1=F5=B4=F3=C5=F4; =B2=DC=D5=F1; Behave Chairs > >>> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 > >>> as WG item > >>> > >>> Hi Dan and All, > >>> > >>> Many parts of the document are still very confusing. 1) It did not > >>> clearly specify the target scenario. From the title, people may think > >>> it is talking about IPv6 ftp client communicating with IPv4 server. > >>> But in section.5, it confuses me a lot by this sentence "even if the > >>> client has IPv4 reachability......". 2) ALG problem. Section 6 starts > >>> with ALG but does not specify clearly which case needs ALG and which > >>> does not. > >>> > >> Thanks. I expect those can be resolved as the document progresses > >> as a WG document. > >> > > > > Back to Andrew's proposal, I was just raising some concerns on why I > > do not support the adoption. I am afraid it is not a solid basis. > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > --=20 Regards, Bo Zhou China Mobile --00151773dfb27671a90476fd928f Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable <div>Hi Marcelo,</div> <div> </div> <div>In your mind, what's fundamental problem? Could you give us a defi= nition? I am a little confused.</div> <div>Thank you very much.</div> <div> </div> <div>Regards,</div> <div> </div> <div>Bo <br><br></div> <div class=3D"gmail_quote">2009/10/28 marcelo bagnulo braun <span dir=3D"lt= r"><<a href=3D"mailto:marcelo@it.uc3m.es">marcelo@it.uc3m.es</a>></sp= an><br> <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0= px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Zhen,<br><br>from the points you= make, it doesn't seem that you have a fundamental<br>problem with the = document but changes that can easily be integrated in<br> the document, if the WG agreed with them. Since we are only accepting a<br>= WG document and not in WGLC, i don't think the argument is strong not o= t<br>accept the doc as a WG document, it just needs to be improved as any<b= r> other doc when accepted as WG document.<br><br>Regards, marcelo<br><br><br>= Zhen Cao escribi=A8=AE:<br> <div> <div></div> <div class=3D"h5">> 2009/10/28 Dan Wing <<a href=3D"mailto:dwing@cisc= o.com">dwing@cisco.com</a>>:<br>><br>>><br>>>> -----Or= iginal Message-----<br>>>> From: Zhen Cao [mailto:<a href=3D"mailt= o:caozhenpku@gmail.com">caozhenpku@gmail.com</a>]<br> >>> Sent: Tuesday, October 27, 2009 8:40 AM<br>>>> To: Da= n Wing<br>>>> Cc: <a href=3D"mailto:behave@ietf.org">behave@ietf.o= rg</a>; =C1=F5=B4=F3=C5=F4; =B2=DC=D5=F1; Behave Chairs<br>>>> Sub= ject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06<br> >>> as WG item<br>>>><br>>>> Hi Dan and All,<br>= >>><br>>>> Many parts of the document are still very conf= using. 1) It did not<br>>>> clearly specify the target scenario. F= rom the title, people may think<br> >>> it is talking about IPv6 ftp client communicating with IPv4 se= rver.<br>>>> But in section.5, it confuses me a lot by this senten= ce "even if the<br>>>> client has IPv4 reachability......&quo= t;. 2) ALG problem. Section 6 starts<br> >>> with ALG but does not specify clearly which case needs ALG and= which<br>>>> does not.<br>>>><br>>> Thanks.  = I expect those can be resolved as the document progresses<br>>> as a = WG document.<br> >><br>><br>> Back to Andrew's proposal, I was just raising = some concerns on why I<br>> do not support the adoption. I am afraid it = is not a solid basis.<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/behav= e" target=3D"_blank">https://www.ietf.org/mailman/listinfo/behave</a><br>&g= t;<br> <br>_______________________________________________<br>Behave mailing list<= br><a href=3D"mailto:Behave@ietf.org">Behave@ietf.org</a><br><a href=3D"htt= ps://www.ietf.org/mailman/listinfo/behave" target=3D"_blank">https://www.ie= tf.org/mailman/listinfo/behave</a><br> </div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Regards,<br= ><br>Bo Zhou<br>China Mobile<br> --00151773dfb27671a90476fd928f-- From maxpassion@gmail.com Wed Oct 28 06:32:21 2009 Return-Path: <maxpassion@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 713F43A6802 for <behave@core3.amsl.com>; Wed, 28 Oct 2009 06:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.204, 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 uh6Uu+M-repf for <behave@core3.amsl.com>; Wed, 28 Oct 2009 06:32:20 -0700 (PDT) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 2D99E3A6782 for <behave@ietf.org>; Wed, 28 Oct 2009 06:32:20 -0700 (PDT) Received: by pwi4 with SMTP id 4so851162pwi.29 for <behave@ietf.org>; Wed, 28 Oct 2009 06:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Kn+ULJM4jAOkEAZS5W/Tz1u0KNh3BAfwC7z4PCq6ttw=; b=b6V//RyKWppKzfYa4lFBcBKHn987knBLg/RRiZeWWx1fqAjnhtXqFlNUV/d0+ns7PL BJUbd9nPpENaKCcNtpcC9ZB4Of0iCKQSK3CChNkYGEO5L8V4JjcsWUTc9ofqUEUPcIN1 mG4Jd8ohkig/aQ+yZ4H3cJDMEV7Jg6c7GAPK8= 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=K8EmFpbNUd0chjrurdN+b7bZW/KpuVPZoBNB3Mr4n9W15y1U1lPqg8sPwc4cesgMvD xAcEmzYpaPVX2aL1exYYo/s50BxJIsw5GJiJKVjzTJPWt9zmE0S1cglKxz7X0XjP+3KE NA18sOOtBwmcCSQ3JneZZeTjF8OrdYZBJDMN0= MIME-Version: 1.0 Received: by 10.142.202.9 with SMTP id z9mr1444738wff.166.1256736754402; Wed, 28 Oct 2009 06:32:34 -0700 (PDT) In-Reply-To: <8DC9E6B4-DF80-436C-BFC0-0B4990B275B8@muada.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> <25e1aaa40910230404m4517c64ew2a04e610cc6f2bcd@mail.gmail.com> <D1DA2BB2-E064-4656-B75A-A10339A1B9FB@muada.com> <86F15BB9FC58443ABF2071A5CC843384@JiangXiong> <09be01ca5660$7a1de870$c5f0200a@cisco.com> <25e1aaa40910262003u3779279fxa614487c9d304f87@mail.gmail.com> <8DC9E6B4-DF80-436C-BFC0-0B4990B275B8@muada.com> Date: Wed, 28 Oct 2009 21:32:34 +0800 Message-ID: <25e1aaa40910280632w74e19d01u513efe24e05cc016@mail.gmail.com> From: liu dapeng <maxpassion@gmail.com> To: Iljitsch van Beijnum <iljitsch@muada.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: "behave@ietf.org WG" <behave@ietf.org> Subject: Re: [BEHAVE] draft-liu-behave-ftp64-04 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: Wed, 28 Oct 2009 13:32:21 -0000 2009/10/28, Iljitsch van Beijnum <iljitsch@muada.com>: > On 27 okt 2009, at 04:03, liu dapeng wrote: > >> We updated the ftp64 draft: >> http://tools.ietf.org/html/draft-liu-behave-ftp64-04. >> As you mentioned, attitude toward FTP ALG is one of the ideas that >> merged by draft-van-beijnum-behave-ftp64-06.txt; Furthermore, the >> handling of FTP client when retrying with PASV command is another >> important idea that merged by draft-van-beijnum-behave-ftp64-06.txt. > > If I remember correctly, this is the first place this idea is mentioned: > > http://www.ietf.org/mail-archive/web/behave/current/msg05940.html We propose our idea in: http://www.ietf.org/mail-archive/web/behave/current/msg06210.html At that time, we did not notice whether there was other opinions, but it is clear that in a long time draft-van-beijnum-behave-ftp64 did not update to accept this idea, which lead to a solution that can not work until we post draft-liu-behave-ftp64-00. That is why we post another draft on this topic. We have to express our ideas which may improve the design precisely and make sure the ideas will not be ignored without a specific reason. > It appears in the -03 version of draft-van-beijnum-behave-ftp64. > >> We believe that draft-van-beijnum-behave-ftp64-06 still need more >> improvement, >> so we upgrade draft-liu-behave-ftp64-04 to reflect our thoughts more >> precisely. We would like the WG to review and comments on this draft >> and to see whether it is more suitable to be the working foundation to >> further proceed the ftp64 issue in IPv6 transition scenario. > > I read draft-liu-behave-ftp64-04, but I didn't see any places where > you suggest new ways forward that are very different from draft-van- > beijnum-behave-ftp64-06, except that the ALG specification is much > less detailed and no server changes are specified, only client > changes. Can you please outline your specific suggestions? The attitude towards FTP ALG is our idea. So we insist that we need not to identify too much details about FTP ALG. Furthermore, it is reasonable to ask the IPv6 FTP client to "change" since there is no much IPv6 FTP client right now and it is a good time for us to make a guideline and to let the implementer to know how to design the IPv6 FTP client to avoid bothering the translation box to do FTP ALG. I guess that is the meaning why behave WG try to proceed this document(without this ftp issue may belong to application area). That idea is very important since it gives the meaning of this document. Conversely, require the legacy IPv4 FTP server to change is difficult. So draft-liu-behave-ftp64-04 does not agree to change IPv4 FTP server. We do not want to make a specification that no one want to comply. > (It also seems that draft-liu-behave-ftp64 has taken many ideas from > draft-van-beijnum-behave-ftp64. In some cases, the wording is even > quite close.) As you mentioned, you can borrow many other's ideas in draft-van-beijnum-behave-ftp64, I also can borrow ideas from others but I do not use any wording from draft-van-beijnum-behave-ftp64, if you find any wording that are not appropriate, please kindly to point it out, I will revise the wording. BR,2009/10/28, Iljitsch van Beijnum <iljitsch@muada.com>: > On 27 okt 2009, at 04:03, liu dapeng wrote: > >> We updated the ftp64 draft: >> http://tools.ietf.org/html/draft-liu-behave-ftp64-04. >> As you mentioned, attitude toward FTP ALG is one of the ideas that >> merged by draft-van-beijnum-behave-ftp64-06.txt; Furthermore, the >> handling of FTP client when retrying with PASV command is another >> important idea that merged by draft-van-beijnum-behave-ftp64-06.txt. > > If I remember correctly, this is the first place this idea is mentioned: > > http://www.ietf.org/mail-archive/web/behave/current/msg05940.html We propose our idea in: http://www.ietf.org/mail-archive/web/behave/current/msg06210.html At that time, we did not notice whether there was other opinions, but it is clear that in a long time draft-van-beijnum-behave-ftp64 did not update to accept this idea, which lead to a solution that can not work until we post draft-liu-behave-ftp64-00. That is why we post another draft on this topic. We have to express our ideas which may improve the design precisely and make sure the ideas will not be ignored without a specific reason. > It appears in the -03 version of draft-van-beijnum-behave-ftp64. > >> We believe that draft-van-beijnum-behave-ftp64-06 still need more >> improvement, >> so we upgrade draft-liu-behave-ftp64-04 to reflect our thoughts more >> precisely. We would like the WG to review and comments on this draft >> and to see whether it is more suitable to be the working foundation to >> further proceed the ftp64 issue in IPv6 transition scenario. > > I read draft-liu-behave-ftp64-04, but I didn't see any places where > you suggest new ways forward that are very different from draft-van- > beijnum-behave-ftp64-06, except that the ALG specification is much > less detailed and no server changes are specified, only client > changes. Can you please outline your specific suggestions? The attitude towards FTP ALG is our idea. So we need not to identify much details about FTP ALG. Furthermore, it is reasonable to ask the IPv6 FTP client to "change" since there is no much IPv6 FTP client right now and it is a good time for us to make a guideline and to let the implementer to know how to design the IPv6 FTP client to avoid bothering the translation box to do FTP ALG. I guess that is the meaning why behave WG try to proceed this document(which may belong to application area). That idea is very important since it gives the meaning of this document. Conversely, require the legacy IPv4 FTP server to change is difficult. So draft-liu-behave-ftp64-04 does not agree to change IPv4 FTP server. We do not want to make a specification that no one want to comply. > (It also seems that draft-liu-behave-ftp64 has taken many ideas from > draft-van-beijnum-behave-ftp64. In some cases, the wording is even > quite close.) As you mentioned, you can borrow many other's ideas in draft-van-beijnum-behave-ftp64, I also can borrow ideas from others but I do not use any wording from any other documents, if you find any wording that are not appropriate, please kindly help to point it out, I will revise the wording. BR, Dapeng Liu Dapeng Liu From caozhenpku@gmail.com Wed Oct 28 06:34:02 2009 Return-Path: <caozhenpku@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 ECA513A69F2 for <behave@core3.amsl.com>; Wed, 28 Oct 2009 06:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.526, 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 xEeBVbwvc788 for <behave@core3.amsl.com>; Wed, 28 Oct 2009 06:34:02 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id 2D2D53A68F9 for <behave@ietf.org>; Wed, 28 Oct 2009 06:34:02 -0700 (PDT) Received: by pzk42 with SMTP id 42so634222pzk.31 for <behave@ietf.org>; Wed, 28 Oct 2009 06:34:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=cErEhIw15opcrTkergF+Y6cey9wjvATqe8RuEs3Bi6Y=; b=ZYRMsnu3UNaHBiQw+BiO3xrGXut9aSWMz8xrrkqclchZHG/SCbKi7k1U6uSiA5Kuro r5RE/X55enemDukJjGH4QikBELlWBKn1C/F/qPIDq36EWFEZCQ3klf5D2SMbn7Ydv/3h yNFW4Ky1fxXxHAKSp1FnZ/d4xHUDHrlw+kAv8= 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=DAUegoHZgq3jHPylorteWb/6tHVllC7Op8jmUeVXgEm2LNNcX06v1QcoqYMaVnEucc 1Vz/21TQgjF3eaDFvIJiU9PrDebKTiZb6/nvZosOfDIbR12GNnPQKbe2n7le2qoMigHo m2MAhi0yutj9JgUi+zH0Hdg0KBNkIABd6WHao= MIME-Version: 1.0 Received: by 10.142.209.19 with SMTP id h19mr1503065wfg.129.1256736853000; Wed, 28 Oct 2009 06:34:13 -0700 (PDT) In-Reply-To: <4AE80DDE.4040709@it.uc3m.es> References: <4AE80DDE.4040709@it.uc3m.es> Date: Wed, 28 Oct 2009 21:34:12 +0800 Message-ID: <a7c8d0a30910280634n6967363etd781c689a2d9b893@mail.gmail.com> From: Zhen Cao <caozhenpku@gmail.com> To: marcelo bagnulo braun <marcelo@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1 Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] PMTUD, TCP MSS, stateless and stateful translation 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: Wed, 28 Oct 2009 13:34:03 -0000 On Wed, Oct 28, 2009 at 5:24 PM, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote: > Hi, > > After looking into the issue regarding PMUTD, i cannot find anything that is > specific to the stateful translation about PMTUD. Does anybody sees anything > that should be covered in the statefull document about the PMTUD handling? > If not, i will refer as much as possible to the stateless document for this. Do you mean to remove the text on PMTUD in the xlate-stateful draft and simply refer to the xlate draft? I am afraid there is no PMTUD handling in the xlate draft (regarding the ICMP error translation). And for PMTUD, the translator should keep state according to different destination addresses. I think it is a stateful behavior. > > Similar to the TCP MSS handling. I don't think there is anything specific > about how to handle that to the stateful translator. I will also refer then > to the stateless translator Again, i do not see any detailed text in the stateless draft on TCP MSS. And, xlate draft would like to cover both stateless and stateful cases. > > Comments? > > regards, marcelo > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From caozhenpku@gmail.com Wed Oct 28 06:46:38 2009 Return-Path: <caozhenpku@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 6B7943A69E7 for <behave@core3.amsl.com>; Wed, 28 Oct 2009 06:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=0.488, 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 GesK58+Pis5D for <behave@core3.amsl.com>; Wed, 28 Oct 2009 06:46:37 -0700 (PDT) Received: from mail-px0-f173.google.com (mail-px0-f173.google.com [209.85.216.173]) by core3.amsl.com (Postfix) with ESMTP id 71A1C3A6802 for <behave@ietf.org>; Wed, 28 Oct 2009 06:46:37 -0700 (PDT) Received: by pxi3 with SMTP id 3so577235pxi.29 for <behave@ietf.org>; Wed, 28 Oct 2009 06:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FzG4Y3M1EikRnkmruhLR5QYO3ju8V/Bv8oHU78qvDXw=; b=clKaJHmiCgAVHCkQGm5kbh38fy1fidn458KgNxDPem+B/eRRd6+jB9y4UrLQodyqc0 2JN0gUP8H+MRwoezWOasAytXcungcorsxYgIbyaxmFCkUEQcpxcSkuj73rZfM+gVKuzg oEjq4hEXDl9emy10hsJ+wnqla/1y3d2MiVIjU= 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=e3EJre/rVPmuDyoxDXhR4rzcwseUsprpcEcJbQUq176tW5du+hQwJd0twdw6IrKlkq IHIrudEvMfyFbPgmEn8SjmzlIPvW2bx1UaDeNTi4JN8ywT/UmmUJt327zVduSrMXCdsQ hxp7VnmmG30cF+wZyc0TvCs2OEDsczhExdkQE= MIME-Version: 1.0 Received: by 10.143.25.38 with SMTP id c38mr1253555wfj.253.1256737609049; Wed, 28 Oct 2009 06:46:49 -0700 (PDT) In-Reply-To: <4AE7EBD8.5030603@it.uc3m.es> References: <4AE71F2F.1020402@it.uc3m.es> <a7c8d0a30910271913l20d77a4ga916ac176338be4f@mail.gmail.com> <4AE7EBD8.5030603@it.uc3m.es> Date: Wed, 28 Oct 2009 21:46:49 +0800 Message-ID: <a7c8d0a30910280646k7a8034d5i538a9f4f9097d1fb@mail.gmail.com> From: Zhen Cao <caozhenpku@gmail.com> To: marcelo bagnulo braun <marcelo@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Fragmentation and NAT64 stateful translation 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: Wed, 28 Oct 2009 13:46:38 -0000 I think it makes more sense if we list and analyze those options in the document, and make some recommendation if necessary. For the IPv4-to-IPv6 direction, the current text in the draft is good but it implicitly suggests to keep the session state rather than wait and reassemble. I think in this direction, we should keep the session state in stead of wait and assemble. If application keeps sending fragmented packets (udp case), it is too consuming to buffer and reassemble the ip packets. For the IPv6-to-IPv4 directions, i also prefer not to buffer the packet, and tradeoff to avoid id collision should be cheaper than buffering. Thanks, Zhen On Wed, Oct 28, 2009 at 2:59 PM, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote: > Zhen Cao escribi=F3: >>> >>> So, as you can see one option would be to simply reassemble the packets >>> in >>> both directions and process them as any other packet. This is inline wi= th >>> what the stateless document is doing. And it would not add much >>> complication >>> to the spec. >>> >> >> Do you mean to choose option one for both 6-4 and 4-6 scenarios above? >> >> > > yes, would that make sense to you? > Regards, marcelo > > >>> so, i am very tempted to go in that direction. does people have an >>> opinion >>> on this, why we should not do the reassemble first approach? >>> >>> Thanks, marcelo >>> >>> >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >>> >> >> > > From iljitsch@muada.com Wed Oct 28 06:55:24 2009 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 EFD5B3A698F for <behave@core3.amsl.com>; Wed, 28 Oct 2009 06:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1pSW4ro0U5g for <behave@core3.amsl.com>; Wed, 28 Oct 2009 06:55:23 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id DB4C83A6782 for <behave@ietf.org>; Wed, 28 Oct 2009 06:55:22 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.216]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n9SDsrE8056016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Oct 2009 14:54:54 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <a7c8d0a30910280646k7a8034d5i538a9f4f9097d1fb@mail.gmail.com> Date: Wed, 28 Oct 2009 14:55:25 +0100 Content-Transfer-Encoding: 7bit Message-Id: <DF95DADA-9469-467C-905E-05B658D58F07@muada.com> References: <4AE71F2F.1020402@it.uc3m.es> <a7c8d0a30910271913l20d77a4ga916ac176338be4f@mail.gmail.com> <4AE7EBD8.5030603@it.uc3m.es> <a7c8d0a30910280646k7a8034d5i538a9f4f9097d1fb@mail.gmail.com> To: Zhen Cao <caozhenpku@gmail.com> X-Mailer: Apple Mail (2.1076) Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Fragmentation and NAT64 stateful translation 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: Wed, 28 Oct 2009 13:55:24 -0000 On 28 okt 2009, at 14:46, Zhen Cao wrote: > For the IPv4-to-IPv6 direction, the current text in the draft is good > but it implicitly suggests to keep the session state rather than wait > and reassemble. I think in this direction, we should keep the session > state in stead of wait and assemble. If application keeps sending > fragmented packets (udp case), it is too consuming to buffer and > reassemble the ip packets. In the case where the fragments arrive out of order, there isn't much of a difference between the two approaches, in both cases you need to buffer any non-first fragments until the first fragment arrives. The main difference is that the reassemble-then-translate option is much easier to specify. If people send fragments there isn't much you can do... Note that even with TCP, fragments happen in practice. > For the IPv6-to-IPv4 directions, i also prefer not to buffer the > packet, and tradeoff to avoid id collision should be cheaper than > buffering. In the IPv6-to-IPv4 direction you can always translate individual fragments (except non-first fragments of packets that set up a new session), so you don't need to buffer. From caozhenpku@gmail.com Wed Oct 28 07:12:55 2009 Return-Path: <caozhenpku@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 72E143A687C for <behave@core3.amsl.com>; Wed, 28 Oct 2009 07:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.427, 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 er1Nsqsu9T2P for <behave@core3.amsl.com>; Wed, 28 Oct 2009 07:12:54 -0700 (PDT) Received: from mail-pz0-f198.google.com (mail-pz0-f198.google.com [209.85.222.198]) by core3.amsl.com (Postfix) with ESMTP id 8AAA63A6893 for <behave@ietf.org>; Wed, 28 Oct 2009 07:12:54 -0700 (PDT) Received: by pzk36 with SMTP id 36so554441pzk.5 for <behave@ietf.org>; Wed, 28 Oct 2009 07:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=U99VTYcudMQxJtFWQQN+F28A8HyVW/DA7xaw72z9yvU=; b=rGnKc2FWObeHeIRnHaer0zG4XhSGkgBD2lx/S6eRpspig/W3H7/sanlAuxRodfyipn Wc3D8h08KE3DgkoAaaxBiGyRbAtv4A8tS12n3mV3vBI7PksMlyuK6YAcI6i4S77ZqUsx GIdrlTJQzz2f6nn5aDVqNuBRroizucNl9/Mag= 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=kaB4yr++N/Ayu+4ll/xYeKyCC1eKcyI3wIhr5NCAqGZXdIn5ZShAO+XDL5bZW9FIwb Ve0QViiXm5HEwYhnY4uWIHDKIC6RcC7WMOUcAO043jKAvWGj3RdbHuSrQA30N1SYvQbl LVr9T7H9XH69KY0BFnv9bx/S4D8JZxuz7vUkM= MIME-Version: 1.0 Received: by 10.142.118.9 with SMTP id q9mr1419507wfc.49.1256739187500; Wed, 28 Oct 2009 07:13:07 -0700 (PDT) In-Reply-To: <DF95DADA-9469-467C-905E-05B658D58F07@muada.com> References: <4AE71F2F.1020402@it.uc3m.es> <a7c8d0a30910271913l20d77a4ga916ac176338be4f@mail.gmail.com> <4AE7EBD8.5030603@it.uc3m.es> <a7c8d0a30910280646k7a8034d5i538a9f4f9097d1fb@mail.gmail.com> <DF95DADA-9469-467C-905E-05B658D58F07@muada.com> Date: Wed, 28 Oct 2009 22:13:07 +0800 Message-ID: <a7c8d0a30910280713h660ae45dq183a9b071af837a@mail.gmail.com> From: Zhen Cao <caozhenpku@gmail.com> To: Iljitsch van Beijnum <iljitsch@muada.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Fragmentation and NAT64 stateful translation 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: Wed, 28 Oct 2009 14:12:55 -0000 On Wed, Oct 28, 2009 at 9:55 PM, Iljitsch van Beijnum <iljitsch@muada.com> wrote: > On 28 okt 2009, at 14:46, Zhen Cao wrote: > >> For the IPv4-to-IPv6 direction, the current text in the draft is good >> but it implicitly suggests to keep the session state rather than wait >> and reassemble. =A0I think in this direction, we should keep the session >> state in stead of wait and assemble. If application keeps sending >> fragmented packets (udp case), it is too consuming to buffer and >> reassemble the ip packets. > > In the case where the fragments arrive out of order, there isn't much of = a > difference between the two approaches, in both cases you need to buffer a= ny > non-first fragments until the first fragment arrives. The main difference= is > that the reassemble-then-translate option is much easier to specify. > > If people send fragments there isn't much you can do... Note that even wi= th > TCP, fragments happen in practice. > >> For the IPv6-to-IPv4 directions, =A0i also prefer not to buffer the >> packet, and tradeoff to avoid id collision should be cheaper than >> buffering. > > In the IPv6-to-IPv4 direction you can always translate individual fragmen= ts > (except non-first fragments of packets that set up a new session), so you > don't need to buffer. I know, and we discussed this before. But Marcelo here does not mean this above. I quote back his original text below. "We have two options again: -- either we translate each IPv6 fragment independently, in which case we need to make sure that all IPv4 packet resulting from translating fragments of the IPv6 packet contain the same ID and the Offset is copied (i think that would be enough). In order to do that, we could simply copy the 16 bits of the IPv6 packet ID into the IPv4 packet ID, as long as it does not colides with the ID s we are suing for the non fragmented packets. In order to do that, we could partition the ID number space and use one part for non fragmented IPv6 packets and another for fragmented IPv6 packets (this is possible since the IPv4 ID sapce is bigger than the one in IPv6) -- the other option is to reassemble the IPv6 packet and process it as any other packet. the drawback here is that we need to buffer." > From marcelo@it.uc3m.es Wed Oct 28 08:46:03 2009 Return-Path: <marcelo@it.uc3m.es> 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 DA97D28C116 for <behave@core3.amsl.com>; Wed, 28 Oct 2009 08:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEbvUCkF7j1R for <behave@core3.amsl.com>; Wed, 28 Oct 2009 08:46:03 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id D50AD3A69C9 for <behave@ietf.org>; Wed, 28 Oct 2009 08:46:02 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.30.143]) by smtp02.uc3m.es (Postfix) with ESMTP id EF96F6C1B09; Wed, 28 Oct 2009 16:46:15 +0100 (CET) Message-ID: <4AE8673B.9010508@it.uc3m.es> Date: Wed, 28 Oct 2009 16:46:03 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Zhen Cao <caozhenpku@gmail.com> References: <4AE80DDE.4040709@it.uc3m.es> <a7c8d0a30910280634n6967363etd781c689a2d9b893@mail.gmail.com> In-Reply-To: <a7c8d0a30910280634n6967363etd781c689a2d9b893@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16976.000 Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] PMTUD, TCP MSS, stateless and stateful translation 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: Wed, 28 Oct 2009 15:46:03 -0000 Zhen Cao escribió: > On Wed, Oct 28, 2009 at 5:24 PM, marcelo bagnulo braun > <marcelo@it.uc3m.es> wrote: > >> Hi, >> >> After looking into the issue regarding PMUTD, i cannot find anything that is >> specific to the stateful translation about PMTUD. Does anybody sees anything >> that should be covered in the statefull document about the PMTUD handling? >> If not, i will refer as much as possible to the stateless document for this. >> > > Do you mean to remove the text on PMTUD in the xlate-stateful draft > and simply refer to the xlate draft? I am afraid there is no PMTUD > handling in the xlate draft (regarding the ICMP error translation). > i am in processing of checking the stateless document, so i cannot comment just yet, but, if we agree that is common, then it should be in the stateless draft imho > And for PMTUD, the translator should keep state according to different > destination addresses. I think it is a stateful behavior. > > mmm, you mean that we should store the MTU for each destination we are sending packets to, right? But we need that as well in the stateless case, right? (i mean agree that this is state, but i think it is state that the stateless translator needs as well, i am afraid. and conversely, if the stateless trnaslator does not need it, i guess the statefull doesnt need it neither) >> Similar to the TCP MSS handling. I don't think there is anything specific >> about how to handle that to the stateful translator. I will also refer then >> to the stateless translator >> > > Again, i do not see any detailed text in the stateless draft on TCP > MSS. And, xlate draft would like to cover both stateless and stateful > cases. > > maybe so, so the point is that we may need to add that? Regards, marcelo >> Comments? >> > > > >> regards, marcelo >> >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >> > > From marcelo@it.uc3m.es Wed Oct 28 08:55:12 2009 Return-Path: <marcelo@it.uc3m.es> 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 EC67C3A68ED for <behave@core3.amsl.com>; Wed, 28 Oct 2009 08:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+LilYdayFJB for <behave@core3.amsl.com>; Wed, 28 Oct 2009 08:55:12 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 0E5E73A6937 for <behave@ietf.org>; Wed, 28 Oct 2009 08:55:11 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.30.143]) by smtp02.uc3m.es (Postfix) with ESMTP id 56DF26C1C14; Wed, 28 Oct 2009 16:55:25 +0100 (CET) Message-ID: <4AE86961.1040504@it.uc3m.es> Date: Wed, 28 Oct 2009 16:55:13 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Iljitsch van Beijnum <iljitsch@muada.com> References: <4AE71F2F.1020402@it.uc3m.es> <a7c8d0a30910271913l20d77a4ga916ac176338be4f@mail.gmail.com> <4AE7EBD8.5030603@it.uc3m.es> <a7c8d0a30910280646k7a8034d5i538a9f4f9097d1fb@mail.gmail.com> <DF95DADA-9469-467C-905E-05B658D58F07@muada.com> In-Reply-To: <DF95DADA-9469-467C-905E-05B658D58F07@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16976.000 Cc: Behave WG <behave@ietf.org>, Zhen Cao <caozhenpku@gmail.com> Subject: Re: [BEHAVE] Fragmentation and NAT64 stateful translation 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: Wed, 28 Oct 2009 15:55:13 -0000 Iljitsch van Beijnum escribió: > On 28 okt 2009, at 14:46, Zhen Cao wrote: > >> For the IPv4-to-IPv6 direction, the current text in the draft is good >> but it implicitly suggests to keep the session state rather than wait >> and reassemble. I think in this direction, we should keep the session >> state in stead of wait and assemble. If application keeps sending >> fragmented packets (udp case), it is too consuming to buffer and >> reassemble the ip packets. > > In the case where the fragments arrive out of order, there isn't much > of a difference between the two approaches, in both cases you need to > buffer any non-first fragments until the first fragment arrives. The > main difference is that the reassemble-then-translate option is much > easier to specify. Not only that, but i understand that several of the attacks that have been described involving fragmentation would be solved by this approach. Of course, the vector of DoS relying on sending incomplete fragments is worse, but this can be dealt with by limiting the resources assigned to this task. Regards, marcelo > > If people send fragments there isn't much you can do... Note that even > with TCP, fragments happen in practice. > >> For the IPv6-to-IPv4 directions, i also prefer not to buffer the >> packet, and tradeoff to avoid id collision should be cheaper than >> buffering. > > In the IPv6-to-IPv4 direction you can always translate individual > fragments (except non-first fragments of packets that set up a new > session), so you don't need to buffer. > From ikuhei@nttv6.jp Wed Oct 28 13:33:01 2009 Return-Path: <ikuhei@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 3C5A728C141 for <behave@core3.amsl.com>; Wed, 28 Oct 2009 13:33:01 -0700 (PDT) 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 xpWljDOjf6pH for <behave@core3.amsl.com>; Wed, 28 Oct 2009 13:33:00 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:144::148]) by core3.amsl.com (Postfix) with ESMTP id 1D35D28C155 for <behave@ietf.org>; Wed, 28 Oct 2009 13:33:00 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:208::212]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 5B4E9BDC26; Thu, 29 Oct 2009 05:33:14 +0900 (JST) Received: from [192.168.11.28] (localhost.nttv6.jp [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 456F76FF77; Thu, 29 Oct 2009 05:33:14 +0900 (JST) Date: Thu, 29 Oct 2009 05:33:14 +0900 From: "Ikuhei.Yamagata" <ikuhei@nttv6.jp> To: Behave WG <behave@ietf.org> Message-Id: <20091029053211.99DF.68FF0486@nttv6.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Mailer: Becky! ver. 2.50 [ja] Cc: shared@hir.jp Subject: [BEHAVE] Fw: New Version Notification for draft-shirasaki-nat444-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: Wed, 28 Oct 2009 20:33:01 -0000 Dear all, We have submitted new draft, draft-shirasaki-nat444-00. This is the draft removed informations about ip addresses from draft-shirasaki-nat444-isp-shared-addr-02. Your feedback would be really welcome. ikuhei Forwarded by "Ikuhei.Yamagata" <ikuhei@nttv6.jp> ----------------------- Original Message ----------------------- A new version of I-D, draft-shirasaki-nat444-00.txt has been successfuly submitted by Ikuhei Yamagata and posted to the IETF repository. Filename: draft-shirasaki-nat444 Revision: 00 Title: NAT444 Creation_date: 2009-10-19 WG ID: Independent Submission Number_of_pages: 11 Abstract: This document describes one of the network models that are designed for smooth transition to IPv6. It is called NAT444 model. NAT444 model is composed of IPv6, and IPv4 with Large Scale NAT (LSN). NAT444 is the only scheme not to require replacing Customer Premises Equipment (CPE) even if IPv4 address exhausted. But it must be noted that NAT444 has serious restrictions i.e. it limits the number of sessions per CPE so that rich applications such as AJAX and RSS feed cannot work well. Therefore, IPv6 which is free from such a difficulty has to be introduced into the network at the same time. In other words, NAT444 is just a tool to make IPv6 transition easy to be swallowed. It is designed for the days IPv4 and IPv6 co-existence. The IETF Secretariat. --------------------- Original Message Ends -------------------- ---------------------------------------------- Ikuhei Yamagata Innovative IP Architecture Center NTT Communications Corporation ikuhei@nttv6.jp phone:81-3-6733-8671(main) 50-3812-4704(direct) ---------------------------------------------- From dwing@cisco.com Wed Oct 28 18:40:59 2009 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 04A993A6909 for <behave@core3.amsl.com>; Wed, 28 Oct 2009 18:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.002 X-Spam-Level: X-Spam-Status: No, score=-6.002 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vL4g6FLWyFkj for <behave@core3.amsl.com>; Wed, 28 Oct 2009 18:40:57 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id BA25D3A6359 for <behave@ietf.org>; Wed, 28 Oct 2009 18:40:57 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEABKP6EqrR7Ht/2dsb2JhbACKX7h5mBCEPwSBYQ X-IronPort-AV: E=Sophos;i="4.44,643,1249257600"; d="scan'208";a="420184902" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 29 Oct 2009 01:41:09 +0000 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9T1f9an022533; Thu, 29 Oct 2009 01:41:09 GMT From: "Dan Wing" <dwing@cisco.com> To: "'Zhen Cao'" <caozhenpku@gmail.com>, "'Iljitsch van Beijnum'" <iljitsch@muada.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com><a7c8d0a30910270840l3fca4fa6v6ce58fa5d6db34f4@mail.gmail.com><0BD12441-097D-44D3-8D10-E58B84277DBB@muada.com> <a7c8d0a30910270859i1b5ca44cjc0b3e2473d78f84d@mail.gmail.com> Date: Wed, 28 Oct 2009 18:41:09 -0700 Message-ID: <1b0501ca5838$e3f75310$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpXHpvr0FDkUlz3QzWNLyVZ59mAmABF6yLQ In-Reply-To: <a7c8d0a30910270859i1b5ca44cjc0b3e2473d78f84d@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: behave@ietf.org Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 29 Oct 2009 01:40:59 -0000 > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Zhen Cao > Sent: Tuesday, October 27, 2009 8:59 AM > To: Iljitsch van Beijnum > Cc: behave@ietf.org WG > Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 > as WG item > > On Tue, Oct 27, 2009 at 11:45 PM, Iljitsch van Beijnum > <iljitsch@muada.com> wrote: > > On 27 okt 2009, at 16:40, Zhen Cao wrote: > > > >> Again ALG, multiple protocols need ALG in the NAT64 > >> cases, we cannot specify them all and in fact many > protocols related > >> ALG have not been specified, > > > > Which protocols do you feel need ALGs to work through IPv6-to-IPv4 > > translators? > RTSP, SIP where there needs SDP to carry the address. For the IPv6 transition, IPv6 endpoints are expected to do the work; that's part of pushing intelligence to the host -- a long-standing IETF mantra. I have written down this expectation in http://tools.ietf.org/html/draft-wing-v6ops-v6app-v4server-00 (recently published) which I hope to present in v6ops. However, the standards for RTSP and SIP have already said that IPv6 hosts have do the work of IPv6/IPv4 interworking: Regarding RTSP, please see http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-08, which extends RTSPv2 using ICE-like mechanisms for NAT traversal, including IPv6/IPv4 interworking. Regarding SIP, note that most deployments today aren't using ALGs (e.g., Vonage doesn't need an ALG, and works behind in-home NAT44s successfully). Rather, SBCs incorporate a 'media latching' feature, described in: http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-02 SIP interworking between IPv4 and IPv6 is also accomplished, in the field, using SBCs. Regarding SIP and its IPv6/IPv4 interworking in standards, see: http://tools.ietf.org/html/draft-wing-behave-nat64-referrals-01#section-2.1 http://tools.ietf.org/html/draft-ietf-sipping-v6-transition-07 http://tools.ietf.org/html/draft-ietf-sipping-nat-scenarios-09#section-6 As IPv6-capable RTSP endpoints and SIP endpoints are built, they are expected to comply with those specifications. Most of those I-Ds that I cited above are relatively mature and a few are in RFC editor's queue. Which brings us to: why do we need an FTP64 ALG? Because IPv6 FTP clients send EPSV (in compliance with RFC2428), but EPSV does not work in practice with deployed IPv4 FTP servers. IPv6 FTP clients aren't new -- they exist in deployed web browsers (IE, Firefox, Opera, Safari, Chrome) and thus, if an IPv6-only network is deployed today, it would break FTP. An FTP64 ALG is the only way for those deployed FTP clients to work with IPv4 FTP servers. Once those FTP clients are upgraded to work well with IPv4 FTP servers, the FTP64 ALG is no longer needed. -d > > > > Iljitsch > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Wed Oct 28 18:53:06 2009 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 C8EC93A6960 for <behave@core3.amsl.com>; Wed, 28 Oct 2009 18:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.002 X-Spam-Level: X-Spam-Status: No, score=-6.002 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJIb18erRlmh for <behave@core3.amsl.com>; Wed, 28 Oct 2009 18:53:05 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 7CDD33A6956 for <behave@ietf.org>; Wed, 28 Oct 2009 18:53:05 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAGaS6EqrR7Ht/2dsb2JhbACKX7kBmBCEPwSBYQ X-IronPort-AV: E=Sophos;i="4.44,643,1249257600"; d="scan'208";a="219026177" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 29 Oct 2009 01:53:21 +0000 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9T1rL5x029620 for <behave@ietf.org>; Thu, 29 Oct 2009 01:53:21 GMT From: "Dan Wing" <dwing@cisco.com> To: "Behave WG" <behave@ietf.org> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com><a7c8d0a30910270840l3fca4fa6v6ce58fa5d6db34f4@mail.gmail.com><0BD12441-097D-44D3-8D10-E58B84277DBB@muada.com> <a7c8d0a30910270859i1b5ca44cjc0b3e2473d78f84d@mail.gmail.com> Date: Wed, 28 Oct 2009 18:53:21 -0700 Message-ID: <1b0c01ca583a$98023770$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpXHpvr0FDkUlz3QzWNLyVZ59mAmABF6yLQ In-Reply-To: <a7c8d0a30910270859i1b5ca44cjc0b3e2473d78f84d@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: [BEHAVE] need for ALGs in NAT64 scenarios [was Re: adopt draft-van-beijnum-behave-ftp64-06 as WG item] 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, 29 Oct 2009 01:53:06 -0000 (This message contains the same content as my earlier post at http://www.ietf.org/mail-archive/web/behave/current/msg07192.html. But I changed the subject line so we can quit the 'adopt FTP64' thread, as this diverges considerably from 'adopt FTP64'. Sorry about that; I had intended to change the Subject line before replying, but neglected to do that.) > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Zhen Cao > Sent: Tuesday, October 27, 2009 8:59 AM > To: Iljitsch van Beijnum > Cc: behave@ietf.org WG > Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 > as WG item > > On Tue, Oct 27, 2009 at 11:45 PM, Iljitsch van Beijnum > <iljitsch@muada.com> wrote: > > On 27 okt 2009, at 16:40, Zhen Cao wrote: > > > >> Again ALG, multiple protocols need ALG in the NAT64 > >> cases, we cannot specify them all and in fact many > protocols related > >> ALG have not been specified, > > > > Which protocols do you feel need ALGs to work through IPv6-to-IPv4 > > translators? > RTSP, SIP where there needs SDP to carry the address. For the IPv6 transition, IPv6 endpoints are expected to do the work; that's part of pushing intelligence to the host -- a long-standing IETF mantra. I have written down this expectation in http://tools.ietf.org/html/draft-wing-v6ops-v6app-v4server-00 (recently published) which I hope to present in v6ops. However, the standards for RTSP and SIP have already said that IPv6 hosts have do the work of IPv6/IPv4 interworking: Regarding RTSP, please see http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-08, which extends RTSPv2 using ICE-like mechanisms for NAT traversal, including IPv6/IPv4 interworking. Regarding SIP, note that most deployments today aren't using ALGs (e.g., Vonage doesn't need an ALG, and works behind in-home NAT44s successfully). Rather, SBCs incorporate a 'media latching' feature, described in: http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-02 SIP interworking between IPv4 and IPv6 is also accomplished, in the field, using SBCs. Regarding SIP and its IPv6/IPv4 interworking in standards, see: http://tools.ietf.org/html/draft-wing-behave-nat64-referrals-01#section-2.1 http://tools.ietf.org/html/draft-ietf-sipping-v6-transition-07 http://tools.ietf.org/html/draft-ietf-sipping-nat-scenarios-09#section-6 As IPv6-capable RTSP endpoints and SIP endpoints are built, they are expected to comply with those specifications. Most of those I-Ds that I cited above are relatively mature and a few are in RFC editor's queue. Which brings us to: why do we need an FTP64 ALG? Because IPv6 FTP clients send EPSV (in compliance with RFC2428), but EPSV does not work in practice with deployed IPv4 FTP servers. IPv6 FTP clients aren't new -- they exist in deployed web browsers (IE, Firefox, Opera, Safari, Chrome) and thus, if an IPv6-only network is deployed today, it would break FTP. An FTP64 ALG is the only way for those deployed FTP clients to work with IPv4 FTP servers. Once those FTP clients are upgraded to work well with IPv4 FTP servers, the FTP64 ALG is no longer needed. -d > > > > Iljitsch > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From shengjiang@huawei.com Wed Oct 28 20:06:17 2009 Return-Path: <shengjiang@huawei.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 033963A6855 for <behave@core3.amsl.com>; Wed, 28 Oct 2009 20:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.491 X-Spam-Level: X-Spam-Status: No, score=-0.491 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4LhJ-zduyWe for <behave@core3.amsl.com>; Wed, 28 Oct 2009 20:06:16 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id D13343A67B8 for <behave@ietf.org>; Wed, 28 Oct 2009 20:06:15 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS90081Y9YPB5@szxga02-in.huawei.com> for behave@ietf.org; Thu, 29 Oct 2009 11:06:25 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS9003XQ9YPHM@szxga02-in.huawei.com> for behave@ietf.org; Thu, 29 Oct 2009 11:06:25 +0800 (CST) Received: from j66104a ([10.111.12.58]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KS900BZD9YOF5@szxml06-in.huawei.com> for behave@ietf.org; Thu, 29 Oct 2009 11:06:25 +0800 (CST) Date: Thu, 29 Oct 2009 11:06:24 +0800 From: Sheng Jiang <shengjiang@huawei.com> In-reply-to: <4AE7F8B8.3030407@it.uc3m.es> To: 'marcelo bagnulo braun' <marcelo@it.uc3m.es>, 'Zhen Cao' <caozhenpku@gmail.com> Message-id: <003b01ca5844$ccf7e920$3a0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcpXpEseLlYHp4HqRZieusP5+bS8LQAn8OyQ Cc: =?gb2312?B?J8H1tPPF9Cc=?= <liudapeng@chinamobile.com>, =?gb2312?B?J7Lc1fEn?= <caozhen@chinamobile.com>, behave@ietf.org, 'Behave Chairs' <behave-chairs@tools.ietf.org>, 'Dan Wing' <dwing@cisco.com> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 29 Oct 2009 03:06:17 -0000 Hi, Iljitsch, Taking one coauthor from the carriers, who would be the major user of = ftp64, would potentially make your work better. Actually, their work has = already improved your draft as you took input from their draft and the = discussion with them. It should do no harm for you, I guess.=20 Sheng > -----Original Message----- > From: behave-bounces@ietf.org=20 > [mailto:behave-bounces@ietf.org] On Behalf Of marcelo bagnulo braun > Sent: Wednesday, October 28, 2009 3:55 PM > To: Zhen Cao > Cc: =C1=F5=B4=F3=C5=F4; =B2=DC=D5=F1; behave@ietf.org; Behave Chairs; = Dan Wing > Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06=20 > as WG item >=20 > Zhen, >=20 > from the points you make, it doesn't seem that you have a=20 > fundamental problem with the document but changes that can=20 > easily be integrated in the document, if the WG agreed with=20 > them. Since we are only accepting a WG document and not in=20 > WGLC, i don't think the argument is strong not ot accept the=20 > doc as a WG document, it just needs to be improved as any=20 > other doc when accepted as WG document. >=20 > Regards, marcelo >=20 >=20 > Zhen Cao escribi=A8=AE: > > 2009/10/28 Dan Wing <dwing@cisco.com>: > > =20 > >> =20 > >>> -----Original Message----- > >>> From: Zhen Cao [mailto:caozhenpku@gmail.com] > >>> Sent: Tuesday, October 27, 2009 8:40 AM > >>> To: Dan Wing > >>> Cc: behave@ietf.org; =C1=F5=B4=F3=C5=F4; =B2=DC=D5=F1; Behave = Chairs > >>> Subject: Re: [BEHAVE] adopt=20 > draft-van-beijnum-behave-ftp64-06 as WG=20 > >>> item > >>> > >>> Hi Dan and All, > >>> > >>> Many parts of the document are still very confusing. 1)=20 > It did not=20 > >>> clearly specify the target scenario. From the title, people may=20 > >>> think it is talking about IPv6 ftp client communicating=20 > with IPv4 server. > >>> But in section.5, it confuses me a lot by this sentence=20 > "even if the=20 > >>> client has IPv4 reachability......". 2) ALG problem. Section 6=20 > >>> starts with ALG but does not specify clearly which case needs ALG=20 > >>> and which does not. > >>> =20 > >> Thanks. I expect those can be resolved as the document=20 > progresses as=20 > >> a WG document. > >> =20 > > > > Back to Andrew's proposal, I was just raising some concerns=20 > on why I=20 > > do not support the adoption. I am afraid it is not a solid basis. > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > =20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave >=20 From marcelo@it.uc3m.es Wed Oct 28 23:44:09 2009 Return-Path: <marcelo@it.uc3m.es> 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 F30943A69F3 for <behave@core3.amsl.com>; Wed, 28 Oct 2009 23:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.32 X-Spam-Level: X-Spam-Status: No, score=-5.32 tagged_above=-999 required=5 tests=[AWL=-1.171, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIH5-1ocSRsO for <behave@core3.amsl.com>; Wed, 28 Oct 2009 23:44:08 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id CBFCE3A67F2 for <behave@ietf.org>; Wed, 28 Oct 2009 23:44:07 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.30.143]) by smtp02.uc3m.es (Postfix) with ESMTP id D08906C19CC; Thu, 29 Oct 2009 07:44:21 +0100 (CET) Message-ID: <4AE939BA.3060101@it.uc3m.es> Date: Thu, 29 Oct 2009 07:44:10 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Sheng Jiang <shengjiang@huawei.com> References: <003b01ca5844$ccf7e920$3a0c6f0a@china.huawei.com> In-Reply-To: <003b01ca5844$ccf7e920$3a0c6f0a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16976.003 Cc: behave@ietf.org, 'Zhen Cao' <caozhenpku@gmail.com>, =?GB2312?B?J8H1tPPF9Cc=?= <liudapeng@chinamobile.com>, =?GB2312?B?J7Lc1fEn?= <caozhen@chinamobile.com>, 'Behave Chairs' <behave-chairs@tools.ietf.org>, 'Dan Wing' <dwing@cisco.com> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 29 Oct 2009 06:44:09 -0000 What strikes me is that you seem to be conditioning the support for acceptance of this doc as WG document to the fact whether and additional editor is added to the document or not. These seems different issues imho. Any document needs to reflect the WG consensus whether it has one or many _editors_ The question at hand is whehter this document is or not a good starting point to do that. Regards, marcelo Sheng Jiang escribi¨®: > Hi, Iljitsch, > > Taking one coauthor from the carriers, who would be the major user of ftp64, > would potentially make your work better. Actually, their work has already > improved your draft as you took input from their draft and the discussion > with them. It should do no harm for you, I guess. > > Sheng > > >> -----Original Message----- >> From: behave-bounces@ietf.org >> [mailto:behave-bounces@ietf.org] On Behalf Of marcelo bagnulo braun >> Sent: Wednesday, October 28, 2009 3:55 PM >> To: Zhen Cao >> Cc: Áõ´óÅô; ²ÜÕñ; behave@ietf.org; Behave Chairs; Dan Wing >> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 >> as WG item >> >> Zhen, >> >> from the points you make, it doesn't seem that you have a >> fundamental problem with the document but changes that can >> easily be integrated in the document, if the WG agreed with >> them. Since we are only accepting a WG document and not in >> WGLC, i don't think the argument is strong not ot accept the >> doc as a WG document, it just needs to be improved as any >> other doc when accepted as WG document. >> >> Regards, marcelo >> >> >> Zhen Cao escribi¨®: >> >>> 2009/10/28 Dan Wing <dwing@cisco.com>: >>> >>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Zhen Cao [mailto:caozhenpku@gmail.com] >>>>> Sent: Tuesday, October 27, 2009 8:40 AM >>>>> To: Dan Wing >>>>> Cc: behave@ietf.org; Áõ´óÅô; ²ÜÕñ; Behave Chairs >>>>> Subject: Re: [BEHAVE] adopt >>>>> >> draft-van-beijnum-behave-ftp64-06 as WG >> >>>>> item >>>>> >>>>> Hi Dan and All, >>>>> >>>>> Many parts of the document are still very confusing. 1) >>>>> >> It did not >> >>>>> clearly specify the target scenario. From the title, people may >>>>> think it is talking about IPv6 ftp client communicating >>>>> >> with IPv4 server. >> >>>>> But in section.5, it confuses me a lot by this sentence >>>>> >> "even if the >> >>>>> client has IPv4 reachability......". 2) ALG problem. Section 6 >>>>> starts with ALG but does not specify clearly which case needs ALG >>>>> and which does not. >>>>> >>>>> >>>> Thanks. I expect those can be resolved as the document >>>> >> progresses as >> >>>> a WG document. >>>> >>>> >>> Back to Andrew's proposal, I was just raising some concerns >>> >> on why I >> >>> do not support the adoption. I am afraid it is not a solid basis. >>> _______________________________________________ >>> 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 dwing@cisco.com Thu Oct 29 00:29:34 2009 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 4217C3A6911 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 00:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.302 X-Spam-Level: X-Spam-Status: No, score=-6.302 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiSmO9FExO4W for <behave@core3.amsl.com>; Thu, 29 Oct 2009 00:29:33 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5BDCB3A68F1 for <behave@ietf.org>; Thu, 29 Oct 2009 00:29:33 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEABvh6EqrR7Ht/2dsb2JhbACKX49WqRuJGgGOd4Q/BIFh X-IronPort-AV: E=Sophos;i="4.44,645,1249257600"; d="scan'208";a="420297591" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 29 Oct 2009 07:29:49 +0000 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9T7TnZC010802; Thu, 29 Oct 2009 07:29:49 GMT From: "Dan Wing" <dwing@cisco.com> To: "'bo zhou'" <zhouboyj@gmail.com>, "'Iljitsch van Beijnum'" <iljitsch@muada.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com><a7c8d0a30910270840l3fca4fa6v6ce58fa5d6db34f4@mail.gmail.com><0BD12441-097D-44D3-8D10-E58B84277DBB@muada.com><a7c8d0a30910270859i1b5ca44cjc0b3e2473d78f84d@mail.gmail.com><D3A4D7F4-F2DB-40AD-A37B-5C500B630169@muada.com> <36a593230910280500o2737e5c5t77a433a770dc9364@mail.gmail.com> Date: Thu, 29 Oct 2009 00:29:49 -0700 Message-ID: <1bbb01ca5869$98f67720$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpXxj4SA+e7H0XqQbqbgepAosyx0gAojE4g In-Reply-To: <36a593230910280500o2737e5c5t77a433a770dc9364@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: behave@ietf.org, 'Zhen Cao' <caozhenpku@gmail.com> Subject: [BEHAVE] need for ALGs in NAT64 scenarios [was RE: adopt draft-van-beijnum-behave-ftp64-06 as WG item] 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, 29 Oct 2009 07:29:34 -0000 > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of bo zhou > Sent: Wednesday, October 28, 2009 5:00 AM > To: Iljitsch van Beijnum > Cc: behave@ietf.org WG; Zhen Cao > Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 > as WG item > > Hi Iljitsch, > > "minimize" does not mean avoid in my mind. > BTW, you ask "which protocols do you feel need ALGs to work > through 6-to-4 translator?" > I guess Zhen want to answer your question using RTSP, SIP as > two examples. > I believe more applications rather than RTSP, SIP need to do > ALG in such scenario, but it is really depend on how the user > use these applications. for example, a standard HTTP protocol > can include IP address or domain name inside. if the user > choose the IP address filling, then the ALG cannot avoid. An ALG is not necessary for that problem. I describe a workaround for that specific problem in http://tools.ietf.org/html/draft-wing-behave-http-ip-address-literals-01 which does not use an ALG. However, as noted that draft, my workaround may not properly handle Java or Javascript which contains IPv4 address literals -- but neither will an ALG (unless the ALG is going to interpret Java and Javascript, which *significantly* increases its complexity and CPU hit to solve a small problem; see below). > But likely, more user use domain name rather than IP address for > HTTP application which need not ALG in the translator. Yes. I analyzed the likelyhood by looking at the top 1,000,000 domains per alexa.com, results are at: http://tools.ietf.org/html/draft-wing-behave-http-ip-address-literals-01#appen dix-B which says: ... An examination of Alexa's top 1 million domains [Alexa] at the end of August, 2009, showed 2.38% of the HTML in their home pages contained IPv4 address literals. ... Of the top 1 million websites at the end of August, 2009, 3455 (0.35%) of them are IPv4 address literals (e.g., http://192.0.2.1). ... -d > regards, > > Bo > > > > On Wed, Oct 28, 2009 at 6:29 PM, Iljitsch van Beijnum > <iljitsch@muada.com> wrote: > > > On 27 okt 2009, at 16:59, Zhen Cao wrote: > > > > Which protocols do you feel need ALGs > to work through IPv6-to-IPv4 > translators? > > > > RTSP, SIP where there needs SDP to carry the address. > > > > I'm not sure about the status of RTSP, but I believe > that it's used less and less exactly because it doesn't work > through NAT44 without an ALG... > > As for SIP, I believe the consensus is that ALGs create > more harm than benefit. > > The wg consensus is that the use of ALGs should be > minimized. I don't believe there would be consensus to > specify RTSP and SIP ALGs for NAT64. > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > > > > -- > Regards, > > Bo Zhou > China Mobile > > From marcelo@it.uc3m.es Thu Oct 29 01:14:00 2009 Return-Path: <marcelo@it.uc3m.es> 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 6C9A53A67E5 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 01:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVWXiQXf6lu1 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 01:13:59 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 8A8333A680B for <behave@ietf.org>; Thu, 29 Oct 2009 01:13:59 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id 29A386C1BA9 for <behave@ietf.org>; Thu, 29 Oct 2009 09:14:14 +0100 (CET) Message-ID: <4AE94ED6.5050600@it.uc3m.es> Date: Thu, 29 Oct 2009 09:14:14 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Behave WG <behave@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16976.003 Subject: [BEHAVE] Amount of fragmentation resulting from translation 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, 29 Oct 2009 08:14:00 -0000 Hi, Been looking at the stateless document and i see that when translating IPv4 packets into IPv6 packets, the recommendation is: However, when the IPv4 sender does not set the DF bit,the translator has to ensure that the packet does not exceed the path MTU on the IPv6 side. This is done by fragmenting the IPv4 packet so that it fits in 1280 byte IPv6 packets, since that is the minimum IPv6 packet size. (note that this was defined in this way in the original rfc2765, so this is not a change introduced in this version) So, my question is whether this behaviour would not result is massive fragmentation. I mean, one could guess that 1500 byte long packet are fairly common, and that the defined behavour would imply fragmentation of all these packets for example. Of course, the solution of this problem relies on the translator doing PMTUD for IPv6, which requires to store state and adds complexity. (FWIW, i am operating under the assumption that we should use the same appraoch for stateless and stateful. Of course, we could also discuss that i.e. selecting a different appraoch for stateless than for stateful, so if anyone wants to comment on this it would also be relevant) I thought this worth some discussion. Comments? regards, marcelo From marcelo@it.uc3m.es Thu Oct 29 01:34:50 2009 Return-Path: <marcelo@it.uc3m.es> 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 47F2A3A689F for <behave@core3.amsl.com>; Thu, 29 Oct 2009 01:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.461 X-Spam-Level: X-Spam-Status: No, score=-6.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkGaseoC7JvN for <behave@core3.amsl.com>; Thu, 29 Oct 2009 01:34:49 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 812033A681C for <behave@ietf.org>; Thu, 29 Oct 2009 01:34:49 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp03.uc3m.es (Postfix) with ESMTP id E5F697F37DE for <behave@ietf.org>; Thu, 29 Oct 2009 09:35:03 +0100 (CET) Message-ID: <4AE953B7.1090709@it.uc3m.es> Date: Thu, 29 Oct 2009 09:35:03 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Behave WG <behave@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16976.003 Subject: [BEHAVE] translator generating packet too big ICMP errors 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, 29 Oct 2009 08:34:50 -0000 Hi, After reading the stateless translation draft, i couldn't find that the translator should generate ICMP error packet too big messages, in case it needs to drop an IPv4 packet with teh DF flag set with larger MTU than the one available in the IPv6 side or when it receives an IPv6 packet wihtout the fragment header that doesn't fit in the IPv4 MTU. Did i miss that or it isn't there? If it isn't there, should we include it? Regards, marcelo From rpenno@juniper.net Thu Oct 29 01:44:44 2009 Return-Path: <rpenno@juniper.net> 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 79DB43A68BB for <behave@core3.amsl.com>; Thu, 29 Oct 2009 01:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.243 X-Spam-Level: X-Spam-Status: No, score=-6.243 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbQS05tGyuuB for <behave@core3.amsl.com>; Thu, 29 Oct 2009 01:44:43 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 156293A6948 for <behave@ietf.org>; Thu, 29 Oct 2009 01:44:30 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSulV/ZfeI0s1txjP55EJC06hD7whIG8L@postini.com; Thu, 29 Oct 2009 01:44:54 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 29 Oct 2009 01:40:17 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 29 Oct 2009 04:40:16 -0400 From: Reinaldo Penno <rpenno@juniper.net> To: marcelo bagnulo braun <marcelo@it.uc3m.es>, Behave WG <behave@ietf.org> Date: Thu, 29 Oct 2009 04:40:13 -0400 Thread-Topic: [BEHAVE] Amount of fragmentation resulting from translation Thread-Index: AcpYb9JZyBrMwQcASO2dh5Qn5GbK3AAA5wJd Message-ID: <C70EA2FD.7214%rpenno@juniper.net> In-Reply-To: <4AE94ED6.5050600@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Amount of fragmentation resulting from translation 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, 29 Oct 2009 08:44:44 -0000 I believe you have a point since 1500 byte packets are common. I think the last part of the recommendation is what is causing the confusion... " This is done by fragmenting the IPv4 packet so that it fits in 1280 byte IPv6 packets, since that is the minimum IPv6 packet size." If we keep just the " However, when the IPv4 sender does not set the DF bit, the translator has to ensure that the packet does not exceed the path MTU on the IPv6 side. " should be okay. In other words, you just fragment if needed. As far as PMTUD goes although it creates state, you need to remember such values per outgoing interface and not really per NAT binding. On 10/29/09 1:14 AM, "marcelo bagnulo braun" <marcelo@it.uc3m.es> wrote: > Hi, >=20 > Been looking at the stateless document and i see that when translating > IPv4 packets into IPv6 packets, the recommendation is: >=20 > However, when the IPv4 sender does not set the DF bit,the translator > has to ensure that the packet does not exceed the path MTU on the > IPv6 side. This is done by fragmenting the IPv4 packet so that it > fits in 1280 byte IPv6 packets, since that is the minimum IPv6 packet > size. >=20 > (note that this was defined in this way in the original rfc2765, so this > is not a change introduced in this version) >=20 > So, my question is whether this behaviour would not result is massive > fragmentation. I mean, one could guess that 1500 byte long packet are > fairly common, and that the defined behavour would imply fragmentation > of all these packets for example. >=20 > Of course, the solution of this problem relies on the translator doing > PMTUD for IPv6, which requires to store state and adds complexity. >=20 > (FWIW, i am operating under the assumption that we should use the same > appraoch for stateless and stateful. Of course, we could also discuss > that i.e. selecting a different appraoch for stateless than for > stateful, so if anyone wants to comment on this it would also be relevant= ) >=20 > I thought this worth some discussion. >=20 > Comments? >=20 > regards, marcelo > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From caozhenpku@gmail.com Thu Oct 29 01:48:34 2009 Return-Path: <caozhenpku@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 1A9CB3A68CD for <behave@core3.amsl.com>; Thu, 29 Oct 2009 01:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJ35hdEw8U7v for <behave@core3.amsl.com>; Thu, 29 Oct 2009 01:48:33 -0700 (PDT) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id 56F833A681C for <behave@ietf.org>; Thu, 29 Oct 2009 01:48:33 -0700 (PDT) Received: by pxi1 with SMTP id 1so1084711pxi.32 for <behave@ietf.org>; Thu, 29 Oct 2009 01:48:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4KpRzSERrar89yrMAnnYq/nwbO3y10atKYE17uLaUIY=; b=kJcjB8+xmo2TCNmXPhYfML1LQFAPf82IUIlqxvAcu/Pb/qbom/vbdfmh4EjHA10tf3 yuANFYcwiBLucCmMFucwHmh3fIFx3PKLcV7ucVqS+KumnmQN8ld0OQ1TxzAk5VSP3QDZ MMJf1u06j6ZEE4XGXZI5QdAdNkSQXfzbO/Dpg= 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=R2aw+oRb1rCImkrLAMEEWjmLMYHYIzYaeyPRho5Hxc/gYjtK20r7D2Vt5KuYJRrqH3 lG3wBNXRqBEYbIsDHBYefrQuPtR/49VxVTLhv4OBqGzEuRAWKu0ug1FvOW1NcHMJNYED p9n2x7+Sq+2u7uaAgkJsRo1eDvBBEdj03B794= MIME-Version: 1.0 Received: by 10.142.248.2 with SMTP id v2mr1527843wfh.177.1256806125788; Thu, 29 Oct 2009 01:48:45 -0700 (PDT) In-Reply-To: <4AE94ED6.5050600@it.uc3m.es> References: <4AE94ED6.5050600@it.uc3m.es> Date: Thu, 29 Oct 2009 16:48:45 +0800 Message-ID: <a7c8d0a30910290148h6e1c7b8cq4e211dff3315cc83@mail.gmail.com> From: Zhen Cao <caozhenpku@gmail.com> To: marcelo bagnulo braun <marcelo@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Amount of fragmentation resulting from translation 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, 29 Oct 2009 08:48:34 -0000 On Thu, Oct 29, 2009 at 4:14 PM, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote: > Hi, > > Been looking at the stateless document and i see that when translating IP= v4 > packets into IPv6 packets, the recommendation is: > > =A0However, when the IPv4 sender does not set the DF bit,the translator > =A0has to ensure that the packet does not exceed the path MTU on the > =A0IPv6 side. =A0This is done by fragmenting the IPv4 packet so that it > =A0fits in 1280 byte IPv6 packets, since that is the minimum IPv6 packet > =A0size. > > (note that this was defined in this way in the original rfc2765, so this = is > not a change introduced in this version > > So, my question is whether this behaviour would not result is massive > fragmentation. I mean, one could guess that 1500 byte long packet are fai= rly > common, and that the defined behavour would imply fragmentation of all th= ese > packets for example. xlate draft defines so because it only consider stateless translation, so not appropriate to add state due to PMTU on the translator. > > Of course, the solution of this problem relies on the translator doing PM= TUD > for IPv6, which requires to store state and adds complexity. In stateful translation, i think the state is trivial comparably. > > (FWIW, i am operating under the assumption that we should use the same > appraoch for stateless and stateful. Of course, we could also discuss tha= t > i.e. selecting a different appraoch for stateless than for stateful, so i= f > anyone wants to comment on this it would also be relevant) > > I thought this worth some discussion. > > Comments? It turns out that the specification of fragmentation and mtu issues requires much coordination between stateless and stateful documents. That's why i suggested to have an individual document on those topics. Regards -Zhen From iljitsch@muada.com Thu Oct 29 01:54:01 2009 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 98A2D3A6948 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 01:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ljK5jm73+4p for <behave@core3.amsl.com>; Thu, 29 Oct 2009 01:54:00 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 8912C3A68CE for <behave@ietf.org>; Thu, 29 Oct 2009 01:54:00 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.216]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n9T8rZeA064584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Oct 2009 09:53:36 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <4AE94ED6.5050600@it.uc3m.es> Date: Thu, 29 Oct 2009 09:54:08 +0100 Content-Transfer-Encoding: 7bit Message-Id: <B7943394-8740-4292-B0FF-1050B0DFD3FF@muada.com> References: <4AE94ED6.5050600@it.uc3m.es> To: marcelo bagnulo braun <marcelo@it.uc3m.es> X-Mailer: Apple Mail (2.1076) Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Amount of fragmentation resulting from translation 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, 29 Oct 2009 08:54:01 -0000 On 29 okt 2009, at 09:14, marcelo bagnulo braun wrote: > So, my question is whether this behaviour would not result is > massive fragmentation. I mean, one could guess that 1500 byte long > packet are fairly common, and that the defined behavour would imply > fragmentation of all these packets for example. Right. Of course most traffic is TCP which has PMTUD enabled so DF=1, but there is some TCP with DF=0 and UDP video streaming usually has ~ 1470 byte packets and DF=0. The problem is that if you translate IPv4 packets with DF=0 and they're too big on the IPv6 side, an IPv6 router will send back a too big message, and if you translate that message to an IPv4 too big message it will probably be ignored because UDP protocols have to do their own PMTUD in IPv4 which they don't AFAIK, and in the case of TCP with DF=0 PMTUD was almost certainly turned off. So in the case where the IPv6 MTU is smaller than the IPv4 MTU (and 20 bytes for the difference between the v6/v4 header sizes) for packets with DF=0 you need to fragment. That means the only question is whether you simply always fragment, or track the PMTU on the IPv6 side and only fragment when necessary. Since any IPv6 host needs to track the PMTU for any host it talks to anyway (if it wants to send > 1280 byte packets, at least) the state requirement doesn't seem very unusual so I would go for that. But maybe others would prefer the other choice. On 29 okt 2009, at 09:40, Reinaldo Penno wrote: > As far as PMTUD goes although it creates state, you need to remember > such > values per outgoing interface and not really per NAT binding. No, it's per IPv6 destination address. Could be that one host that uses the translator can handle 1500 byte packets while another can only handle 1480 or 1280. From shengjiang@huawei.com Thu Oct 29 02:27:02 2009 Return-Path: <shengjiang@huawei.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 C37D628B23E for <behave@core3.amsl.com>; Thu, 29 Oct 2009 02:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.448 X-Spam-Level: X-Spam-Status: No, score=-0.448 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1Hc3q6dDcWA for <behave@core3.amsl.com>; Thu, 29 Oct 2009 02:27:01 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 7C38C3A6A5B for <behave@ietf.org>; Thu, 29 Oct 2009 02:26:15 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS9000KDRG97W@szxga02-in.huawei.com> for behave@ietf.org; Thu, 29 Oct 2009 17:24:10 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS900B04RG96W@szxga02-in.huawei.com> for behave@ietf.org; Thu, 29 Oct 2009 17:24:09 +0800 (CST) Received: from j66104a ([10.111.12.58]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KS900DCSRG8V5@szxml04-in.huawei.com> for behave@ietf.org; Thu, 29 Oct 2009 17:24:09 +0800 (CST) Date: Thu, 29 Oct 2009 17:24:11 +0800 From: Sheng Jiang <shengjiang@huawei.com> In-reply-to: <4AE939BA.3060101@it.uc3m.es> To: 'marcelo bagnulo braun' <marcelo@it.uc3m.es> Message-id: <004501ca5879$938933d0$3a0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcpYY1OJZYd80XA7SECOuZcvh65KIAAFJUIw Cc: behave@ietf.org, 'Zhen Cao' <caozhenpku@gmail.com>, =?gb2312?B?J8H1tPPF9Cc=?= <liudapeng@chinamobile.com>, =?gb2312?B?J7Lc1fEn?= <caozhen@chinamobile.com>, 'Behave Chairs' <behave-chairs@tools.ietf.org>, 'Dan Wing' <dwing@cisco.com> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 29 Oct 2009 09:27:02 -0000 My opinions here is simple: without the contributions from China Mobile, = the draft is not good enough to be adopted as WG document though its initial contents are valuable and important. I support the current draft to be adopted for its contents without conditions. I also think single author = does not respect the others who makes important contributions. Furthermore, after the draft be accepted as WG document, future refine = work is still needed. A coauthor from China Mobile, who has proofed = understanding ftp64 issues, will only do good for the work. I don't understand the insistence why rejects a helpful coauthor. For = me, if an expert who understands my draft well wants to coauthor my draft with valuable contributions, he will be really appreciated. Best regards, Sheng > -----Original Message----- > From: behave-bounces@ietf.org=20 > [mailto:behave-bounces@ietf.org] On Behalf Of marcelo bagnulo braun > Sent: Thursday, October 29, 2009 2:44 PM > To: Sheng Jiang > Cc: behave@ietf.org; 'Zhen Cao'; '=C1=F5=B4=F3=C5=F4'; '=B2=DC=D5=F1'; = 'Behave=20 > Chairs'; 'Dan Wing' > Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06=20 > as WG item >=20 > What strikes me is that you seem to be conditioning the=20 > support for acceptance of this doc as WG document to the fact=20 > whether and additional editor is added to the document or not. >=20 > These seems different issues imho. Any document needs to=20 > reflect the WG consensus whether it has one or many _editors_ >=20 > The question at hand is whehter this document is or not a=20 > good starting point to do that. >=20 > Regards, marcelo >=20 >=20 >=20 > Sheng Jiang escribi=A8=AE: > > Hi, Iljitsch, > > > > Taking one coauthor from the carriers, who would be the=20 > major user of=20 > > ftp64, would potentially make your work better. Actually,=20 > their work=20 > > has already improved your draft as you took input from=20 > their draft and=20 > > the discussion with them. It should do no harm for you, I guess. > > > > Sheng > > > > =20 > >> -----Original Message----- > >> From: behave-bounces@ietf.org > >> [mailto:behave-bounces@ietf.org] On Behalf Of marcelo bagnulo braun > >> Sent: Wednesday, October 28, 2009 3:55 PM > >> To: Zhen Cao > >> Cc: =C1=F5=B4=F3=C5=F4; =B2=DC=D5=F1; behave@ietf.org; Behave = Chairs; Dan Wing > >> Subject: Re: [BEHAVE] adopt=20 > draft-van-beijnum-behave-ftp64-06 as WG=20 > >> item > >> > >> Zhen, > >> > >> from the points you make, it doesn't seem that you have a=20 > fundamental=20 > >> problem with the document but changes that can easily be=20 > integrated=20 > >> in the document, if the WG agreed with them. Since we are only=20 > >> accepting a WG document and not in WGLC, i don't think the=20 > argument=20 > >> is strong not ot accept the doc as a WG document, it just=20 > needs to be=20 > >> improved as any other doc when accepted as WG document. > >> > >> Regards, marcelo > >> > >> > >> Zhen Cao escribi=A8=AE: > >> =20 > >>> 2009/10/28 Dan Wing <dwing@cisco.com>: > >>> =20 > >>> =20 > >>>> =20 > >>>> =20 > >>>>> -----Original Message----- > >>>>> From: Zhen Cao [mailto:caozhenpku@gmail.com] > >>>>> Sent: Tuesday, October 27, 2009 8:40 AM > >>>>> To: Dan Wing > >>>>> Cc: behave@ietf.org; =C1=F5=B4=F3=C5=F4; =B2=DC=D5=F1; Behave = Chairs > >>>>> Subject: Re: [BEHAVE] adopt > >>>>> =20 > >> draft-van-beijnum-behave-ftp64-06 as WG > >> =20 > >>>>> item > >>>>> > >>>>> Hi Dan and All, > >>>>> > >>>>> Many parts of the document are still very confusing. 1) > >>>>> =20 > >> It did not > >> =20 > >>>>> clearly specify the target scenario. From the title, people may=20 > >>>>> think it is talking about IPv6 ftp client communicating > >>>>> =20 > >> with IPv4 server. > >> =20 > >>>>> But in section.5, it confuses me a lot by this sentence > >>>>> =20 > >> "even if the > >> =20 > >>>>> client has IPv4 reachability......". 2) ALG problem. Section 6=20 > >>>>> starts with ALG but does not specify clearly which case=20 > needs ALG=20 > >>>>> and which does not. > >>>>> =20 > >>>>> =20 > >>>> Thanks. I expect those can be resolved as the document > >>>> =20 > >> progresses as > >> =20 > >>>> a WG document. > >>>> =20 > >>>> =20 > >>> Back to Andrew's proposal, I was just raising some concerns > >>> =20 > >> on why I > >> =20 > >>> do not support the adoption. I am afraid it is not a solid basis. > >>> _______________________________________________ > >>> Behave mailing list > >>> Behave@ietf.org > >>> https://www.ietf.org/mailman/listinfo/behave > >>> =20 > >>> =20 > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www.ietf.org/mailman/listinfo/behave > >> > >> =20 > > > > > > =20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave >=20 From rpenno@juniper.net Thu Oct 29 02:27:18 2009 Return-Path: <rpenno@juniper.net> 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 E72F828C107 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 02:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2v0OTYq2ebhY for <behave@core3.amsl.com>; Thu, 29 Oct 2009 02:27:18 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 45FD228C0F6 for <behave@ietf.org>; Thu, 29 Oct 2009 02:27:10 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKSulf/WNmpSflcJsnhtx9KemZ+w8/wrlN@postini.com; Thu, 29 Oct 2009 02:27:34 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 29 Oct 2009 02:26:31 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 29 Oct 2009 05:26:30 -0400 From: Reinaldo Penno <rpenno@juniper.net> To: Iljitsch van Beijnum <iljitsch@muada.com>, marcelo bagnulo braun <marcelo@it.uc3m.es> Date: Thu, 29 Oct 2009 05:26:28 -0400 Thread-Topic: [BEHAVE] Amount of fragmentation resulting from translation Thread-Index: AcpYdWg/b5sCRlBTSmivdNu09uSIZQABHwux Message-ID: <C70EADD4.7220%rpenno@juniper.net> In-Reply-To: <B7943394-8740-4292-B0FF-1050B0DFD3FF@muada.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Amount of fragmentation resulting from translation 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, 29 Oct 2009 09:27:19 -0000 Right, I was thinking about the directly connected case example in NAT64 bu= t if it is more than one hop away and there is no way of knowing the host's attached link MTU you would need to keep on a per destination. On 10/29/09 1:54 AM, "Iljitsch van Beijnum" <iljitsch@muada.com> wrote: >> As far as PMTUD goes although it creates state, you need to remember >> such >> values per outgoing interface and not really per NAT binding. >=20 > No, it's per IPv6 destination address. Could be that one host that > uses the translator can handle 1500 byte packets while another can > only handle 1480 or 1280. From marcelo@it.uc3m.es Thu Oct 29 03:14:07 2009 Return-Path: <marcelo@it.uc3m.es> 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 1C93F28C12E for <behave@core3.amsl.com>; Thu, 29 Oct 2009 03:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.243 X-Spam-Level: X-Spam-Status: No, score=-5.243 tagged_above=-999 required=5 tests=[AWL=-1.094, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuTcFbN+RLA7 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 03:14:06 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id BF57A28C134 for <behave@ietf.org>; Thu, 29 Oct 2009 03:14:04 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id 7F8386BAC71; Thu, 29 Oct 2009 11:14:19 +0100 (CET) Message-ID: <4AE96AFB.5000406@it.uc3m.es> Date: Thu, 29 Oct 2009 11:14:19 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Sheng Jiang <shengjiang@huawei.com> References: <004501ca5879$938933d0$3a0c6f0a@china.huawei.com> In-Reply-To: <004501ca5879$938933d0$3a0c6f0a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16976.003 Cc: behave@ietf.org, 'Zhen Cao' <caozhenpku@gmail.com>, =?GB2312?B?xfQn?= <liudapeng@chinamobile.com>, =?GB2312?B?J8H1tPM=?=, =?GB2312?B?J7Lc1fEn?= <caozhen@chinamobile.com>, 'Behave Chairs' <behave-chairs@tools.ietf.org>, 'Dan Wing' <dwing@cisco.com> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 29 Oct 2009 10:14:07 -0000 so, you do agree to take this doc as a WG item, right? Sheng Jiang escribi¨®: > My opinions here is simple: without the contributions from China Mobile, the > draft is not good enough to be adopted as WG document though its initial > contents are valuable and important. I support the current draft to be > adopted for its contents without conditions. I also think single author does > not respect the others who makes important contributions. > > Furthermore, after the draft be accepted as WG document, future refine work > is still needed. A coauthor from China Mobile, who has proofed understanding > ftp64 issues, will only do good for the work. > > I don't understand the insistence why rejects a helpful coauthor. For me, if > an expert who understands my draft well wants to coauthor my draft with > valuable contributions, he will be really appreciated. > > Best regards, > > Sheng > > >> -----Original Message----- >> From: behave-bounces@ietf.org >> [mailto:behave-bounces@ietf.org] On Behalf Of marcelo bagnulo braun >> Sent: Thursday, October 29, 2009 2:44 PM >> To: Sheng Jiang >> Cc: behave@ietf.org; 'Zhen Cao'; 'Áõ´óÅô'; '²ÜÕñ'; 'Behave >> Chairs'; 'Dan Wing' >> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 >> as WG item >> >> What strikes me is that you seem to be conditioning the >> support for acceptance of this doc as WG document to the fact >> whether and additional editor is added to the document or not. >> >> These seems different issues imho. Any document needs to >> reflect the WG consensus whether it has one or many _editors_ >> >> The question at hand is whehter this document is or not a >> good starting point to do that. >> >> Regards, marcelo >> >> >> >> Sheng Jiang escribi¨®: >> >>> Hi, Iljitsch, >>> >>> Taking one coauthor from the carriers, who would be the >>> >> major user of >> >>> ftp64, would potentially make your work better. Actually, >>> >> their work >> >>> has already improved your draft as you took input from >>> >> their draft and >> >>> the discussion with them. It should do no harm for you, I guess. >>> >>> Sheng >>> >>> >>> >>>> -----Original Message----- >>>> From: behave-bounces@ietf.org >>>> [mailto:behave-bounces@ietf.org] On Behalf Of marcelo bagnulo braun >>>> Sent: Wednesday, October 28, 2009 3:55 PM >>>> To: Zhen Cao >>>> Cc: Áõ´óÅô; ²ÜÕñ; behave@ietf.org; Behave Chairs; Dan Wing >>>> Subject: Re: [BEHAVE] adopt >>>> >> draft-van-beijnum-behave-ftp64-06 as WG >> >>>> item >>>> >>>> Zhen, >>>> >>>> from the points you make, it doesn't seem that you have a >>>> >> fundamental >> >>>> problem with the document but changes that can easily be >>>> >> integrated >> >>>> in the document, if the WG agreed with them. Since we are only >>>> accepting a WG document and not in WGLC, i don't think the >>>> >> argument >> >>>> is strong not ot accept the doc as a WG document, it just >>>> >> needs to be >> >>>> improved as any other doc when accepted as WG document. >>>> >>>> Regards, marcelo >>>> >>>> >>>> Zhen Cao escribi¨®: >>>> >>>> >>>>> 2009/10/28 Dan Wing <dwing@cisco.com>: >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Zhen Cao [mailto:caozhenpku@gmail.com] >>>>>>> Sent: Tuesday, October 27, 2009 8:40 AM >>>>>>> To: Dan Wing >>>>>>> Cc: behave@ietf.org; Áõ´óÅô; ²ÜÕñ; Behave Chairs >>>>>>> Subject: Re: [BEHAVE] adopt >>>>>>> >>>>>>> >>>> draft-van-beijnum-behave-ftp64-06 as WG >>>> >>>> >>>>>>> item >>>>>>> >>>>>>> Hi Dan and All, >>>>>>> >>>>>>> Many parts of the document are still very confusing. 1) >>>>>>> >>>>>>> >>>> It did not >>>> >>>> >>>>>>> clearly specify the target scenario. From the title, people may >>>>>>> think it is talking about IPv6 ftp client communicating >>>>>>> >>>>>>> >>>> with IPv4 server. >>>> >>>> >>>>>>> But in section.5, it confuses me a lot by this sentence >>>>>>> >>>>>>> >>>> "even if the >>>> >>>> >>>>>>> client has IPv4 reachability......". 2) ALG problem. Section 6 >>>>>>> starts with ALG but does not specify clearly which case >>>>>>> >> needs ALG >> >>>>>>> and which does not. >>>>>>> >>>>>>> >>>>>>> >>>>>> Thanks. I expect those can be resolved as the document >>>>>> >>>>>> >>>> progresses as >>>> >>>> >>>>>> a WG document. >>>>>> >>>>>> >>>>>> >>>>> Back to Andrew's proposal, I was just raising some concerns >>>>> >>>>> >>>> on why I >>>> >>>> >>>>> do not support the adoption. I am afraid it is not a solid basis. >>>>> _______________________________________________ >>>>> Behave mailing list >>>>> Behave@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/behave >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >>>> >>>> >>>> >>> >>> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >> > > > From marcelo@it.uc3m.es Thu Oct 29 03:49:03 2009 Return-Path: <marcelo@it.uc3m.es> 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 1FC3D3A6AAB for <behave@core3.amsl.com>; Thu, 29 Oct 2009 03:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.118 X-Spam-Level: X-Spam-Status: No, score=-6.118 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6Rxyea-oyVy for <behave@core3.amsl.com>; Thu, 29 Oct 2009 03:49:02 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id E55373A6AA5 for <behave@ietf.org>; Thu, 29 Oct 2009 03:49:01 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp01.uc3m.es (Postfix) with ESMTP id 02729BA7CDA; Thu, 29 Oct 2009 11:49:15 +0100 (CET) Message-ID: <4AE9732A.9030300@it.uc3m.es> Date: Thu, 29 Oct 2009 11:49:14 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Zhen Cao <caozhenpku@gmail.com> References: <4AE94ED6.5050600@it.uc3m.es> <a7c8d0a30910290148h6e1c7b8cq4e211dff3315cc83@mail.gmail.com> In-Reply-To: <a7c8d0a30910290148h6e1c7b8cq4e211dff3315cc83@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16976.003 Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Amount of fragmentation resulting from translation 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, 29 Oct 2009 10:49:03 -0000 Zhen Cao escribió: > On Thu, Oct 29, 2009 at 4:14 PM, marcelo bagnulo braun > <marcelo@it.uc3m.es> wrote: > >> Hi, >> >> Been looking at the stateless document and i see that when translating IPv4 >> packets into IPv6 packets, the recommendation is: >> >> However, when the IPv4 sender does not set the DF bit,the translator >> has to ensure that the packet does not exceed the path MTU on the >> IPv6 side. This is done by fragmenting the IPv4 packet so that it >> fits in 1280 byte IPv6 packets, since that is the minimum IPv6 packet >> size. >> >> (note that this was defined in this way in the original rfc2765, so this is >> not a change introduced in this version >> >> So, my question is whether this behaviour would not result is massive >> fragmentation. I mean, one could guess that 1500 byte long packet are fairly >> common, and that the defined behavour would imply fragmentation of all these >> packets for example. >> > > xlate draft defines so because it only consider stateless translation, > so not appropriate to add state due to PMTU on the translator. > The difference between the stateless and the stateful is that the address translation requires state in one case and does not requires state in the other. My understanding was the all the rest of the translation was the the same. the issues about how to select the size of the outgoing packet has no relationship whatsoever with the state needed for the address translation afaict. So i see this as being orthogonal to the issue of doing statefull or stateless translation. OTOH, i don't have much problemwith defining different mechanisms for handling this for the stateless document and for the stateful document. Regards, marcelo > >> Of course, the solution of this problem relies on the translator doing PMTUD >> for IPv6, which requires to store state and adds complexity. >> > > In stateful translation, i think the state is trivial comparably. > > >> (FWIW, i am operating under the assumption that we should use the same >> appraoch for stateless and stateful. Of course, we could also discuss that >> i.e. selecting a different appraoch for stateless than for stateful, so if >> anyone wants to comment on this it would also be relevant) >> >> I thought this worth some discussion. >> >> Comments? >> > > It turns out that the specification of fragmentation and mtu issues > requires much coordination between stateless and stateful documents. > That's why i suggested to have an individual document on those topics. > > Regards > -Zhen > > From simon.perreault@viagenie.ca Thu Oct 29 04:50:05 2009 Return-Path: <simon.perreault@viagenie.ca> 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 186C23A6883 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 04:50:05 -0700 (PDT) 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 M2V6a+qUm3gg for <behave@core3.amsl.com>; Thu, 29 Oct 2009 04:50:04 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 1F2773A687B for <behave@ietf.org>; Thu, 29 Oct 2009 04:50:04 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id EA25220E35 for <behave@ietf.org>; Thu, 29 Oct 2009 07:50:19 -0400 (EDT) Message-ID: <4AE9817B.6020701@viagenie.ca> Date: Thu, 29 Oct 2009 07:50:19 -0400 From: Simon Perreault <simon.perreault@viagenie.ca> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4 MIME-Version: 1.0 To: behave@ietf.org References: <4AE94ED6.5050600@it.uc3m.es> In-Reply-To: <4AE94ED6.5050600@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] Amount of fragmentation resulting from translation 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, 29 Oct 2009 11:50:05 -0000 marcelo bagnulo braun wrote, on 2009-10-29 04:14: > So, my question is whether this behaviour would not result is massive > fragmentation. I mean, one could guess that 1500 byte long packet are > fairly common, and that the defined behavour would imply fragmentation > of all these packets for example. My take on this: Yes 1500 bytes packets are common, but with DF=0 it means the end host is not doing PMTUD. This means it should be ready to suffer the consequence of having its packets be fragmented. Do not do PMTUD in the host's stead. That would be too kind for its own good. ;) Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From iljitsch@muada.com Thu Oct 29 04:53:50 2009 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 E6B0E3A68D6 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 04:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DdqvOeQLhbR for <behave@core3.amsl.com>; Thu, 29 Oct 2009 04:53:50 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id E733E3A68C6 for <behave@ietf.org>; Thu, 29 Oct 2009 04:53:49 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.216]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n9TBrNMj066016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Oct 2009 12:53:23 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <4AE9817B.6020701@viagenie.ca> Date: Thu, 29 Oct 2009 12:53:56 +0100 Content-Transfer-Encoding: 7bit Message-Id: <6296B281-9FA1-495B-BD4D-B1C8A1B711AC@muada.com> References: <4AE94ED6.5050600@it.uc3m.es> <4AE9817B.6020701@viagenie.ca> To: Simon Perreault <simon.perreault@viagenie.ca> X-Mailer: Apple Mail (2.1076) Cc: behave@ietf.org Subject: Re: [BEHAVE] Amount of fragmentation resulting from translation 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, 29 Oct 2009 11:53:51 -0000 On 29 okt 2009, at 12:50, Simon Perreault wrote: > Do not do PMTUD in the host's stead. That would be too kind for its > own good. ;) It's not the host sourcing the > 1280 DF=0 packets that suffers if the translator fragments all those packets, but the translator and the receiver, which have to do extra work. In my opinion, the preferred way to handle too bigs coming in on the IPv6 side of the translator is to handle them as a host would, i.e., start sending smaller packets. This also avoids black holes when the IPv4 host sends packets with DF=1 but doesn't react to "too big" messages, which is all too common. From simon.perreault@viagenie.ca Thu Oct 29 04:57:38 2009 Return-Path: <simon.perreault@viagenie.ca> 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 CFCDB3A6883 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 04:57:38 -0700 (PDT) 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 mf8L6uX5W0mZ for <behave@core3.amsl.com>; Thu, 29 Oct 2009 04:57:38 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 145333A659C for <behave@ietf.org>; Thu, 29 Oct 2009 04:57:38 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id ED88E20806 for <behave@ietf.org>; Thu, 29 Oct 2009 07:57:53 -0400 (EDT) Message-ID: <4AE98341.6050302@viagenie.ca> Date: Thu, 29 Oct 2009 07:57:53 -0400 From: Simon Perreault <simon.perreault@viagenie.ca> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4 MIME-Version: 1.0 To: behave@ietf.org References: <4AE953B7.1090709@it.uc3m.es> In-Reply-To: <4AE953B7.1090709@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] translator generating packet too big ICMP errors 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, 29 Oct 2009 11:57:38 -0000 marcelo bagnulo braun wrote, on 2009-10-29 04:35: > After reading the stateless translation draft, i couldn't find that the > translator should generate ICMP error packet too big messages, in case > it needs to drop an IPv4 packet with teh DF flag set with larger MTU > than the one available in the IPv6 side or when it receives an IPv6 > packet wihtout the fragment header that doesn't fit in the IPv4 MTU. Did you read your own document? ;) http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-02#section-7.1 There is a reference to it from the stateless doc in section 1.4: http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-03#section-1.4 Maybe I misinterpreted your question... Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From simon.perreault@viagenie.ca Thu Oct 29 05:07:51 2009 Return-Path: <simon.perreault@viagenie.ca> 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 64E753A6965 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 05:07:51 -0700 (PDT) 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 2c8uuFU8mK3F for <behave@core3.amsl.com>; Thu, 29 Oct 2009 05:07:50 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 715953A6837 for <behave@ietf.org>; Thu, 29 Oct 2009 05:07:50 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id 404152110D; Thu, 29 Oct 2009 08:08:06 -0400 (EDT) Message-ID: <4AE985A5.5030801@viagenie.ca> Date: Thu, 29 Oct 2009 08:08:05 -0400 From: Simon Perreault <simon.perreault@viagenie.ca> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4 MIME-Version: 1.0 To: Iljitsch van Beijnum <iljitsch@muada.com> References: <4AE94ED6.5050600@it.uc3m.es> <4AE9817B.6020701@viagenie.ca> <6296B281-9FA1-495B-BD4D-B1C8A1B711AC@muada.com> In-Reply-To: <6296B281-9FA1-495B-BD4D-B1C8A1B711AC@muada.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] Amount of fragmentation resulting from translation 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, 29 Oct 2009 12:07:51 -0000 Iljitsch van Beijnum wrote, on 2009-10-29 07:53: > It's not the host sourcing the > 1280 DF=0 packets that suffers if the > translator fragments all those packets, but the translator and the > receiver, which have to do extra work. > > In my opinion, the preferred way to handle too bigs coming in on the > IPv6 side of the translator is to handle them as a host would, i.e., > start sending smaller packets. How would the amount of work required of the translator and the receiver compare to that of the current text? Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From caozhenpku@gmail.com Thu Oct 29 07:46:48 2009 Return-Path: <caozhenpku@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 4FCD73A698B for <behave@core3.amsl.com>; Thu, 29 Oct 2009 07:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.396, 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 gPGDOfRVGgPF for <behave@core3.amsl.com>; Thu, 29 Oct 2009 07:46:47 -0700 (PDT) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id 82F353A697C for <behave@ietf.org>; Thu, 29 Oct 2009 07:46:47 -0700 (PDT) Received: by pxi1 with SMTP id 1so1276561pxi.32 for <behave@ietf.org>; Thu, 29 Oct 2009 07:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=BeFoB6iPDYxhplcmHxFCvZDiTZAusFe/qdJl/cwlQr4=; b=ZAY3DG8m7Eg2zhdiWbMNkV8NiskVEO6ld/y9ay2uoztzJu5cSu7Fz1SHB7VT0k/VeZ yyAp6fXKvAEDlkns9L97MotB0zAEKFgM727DnHM1ldXKyKtrcYKAsnKgNJzmMfqkmmAS 6slCmU/dOsTd6Vumz41wRc77KlyuE2XaP+JcE= 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=HUOPm5XyNMfzs6GFqF72baZzkALp7u07RN8V8NJYZdVmAVNWqewc8HaYqZvLdaI1AC QQir4o5N/X8lWZQ5YBLLTMOZQLGX8BNm2/kQLj95Uufu88o51uzRcEEKKsBlZVG6gz4s WSzkIQq8MdJ2AaEd7JrTOpqt+24kf0t/fACwU= MIME-Version: 1.0 Received: by 10.142.152.26 with SMTP id z26mr12753wfd.201.1256827621132; Thu, 29 Oct 2009 07:47:01 -0700 (PDT) In-Reply-To: <4AE9732A.9030300@it.uc3m.es> References: <4AE94ED6.5050600@it.uc3m.es> <a7c8d0a30910290148h6e1c7b8cq4e211dff3315cc83@mail.gmail.com> <4AE9732A.9030300@it.uc3m.es> Date: Thu, 29 Oct 2009 22:47:01 +0800 Message-ID: <a7c8d0a30910290747i75db4c38pb4f16e19ad52a1db@mail.gmail.com> From: Zhen Cao <caozhenpku@gmail.com> To: marcelo bagnulo braun <marcelo@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1 Cc: nordmark@sun.com, Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Amount of fragmentation resulting from translation 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, 29 Oct 2009 14:46:48 -0000 On Thu, Oct 29, 2009 at 6:49 PM, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote: >>> So, my question is whether this behaviour would not result is massive >>> fragmentation. I mean, one could guess that 1500 byte long packet are >>> fairly >>> common, and that the defined behavour would imply fragmentation of all >>> these >>> packets for example. >>> >> >> xlate draft defines so because it only consider stateless translation, >> so not appropriate to add state due to PMTU on the translator. > > The difference between the stateless and the stateful is that the address > translation requires state in one case and does not requires state in the > other. > My understanding was the all the rest of the translation was the the same. > the issues about how to select the size of the outgoing packet has no > relationship whatsoever with the state needed for the address translation I do not agree. But we can solicit the authors of RFC2765 to answer the question. >From the definition in framework draft, stateless translation strictly require there is not any state created by the translation algorithm. Stateful Translation: A translation algorithm may be said to "require state in a network element" or be "stateful" if the transmission or reception of a packet creates or modifies a data structure in the relevant network element. Stateless Translation: A translation algorithm that is not "stateful" is "stateless". It derives its needed information algorithmically from the messages it is translating. > > So i see this as being orthogonal to the issue of doing statefull or > stateless translation. > OTOH, i don't have much problemwith defining different mechanisms for > handling this for the stateless document and for the stateful document. > > Regards, marcelo > From marcelo@it.uc3m.es Thu Oct 29 07:50:24 2009 Return-Path: <marcelo@it.uc3m.es> 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 930DC3A6955 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 07:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jw9JjDfvDzbm for <behave@core3.amsl.com>; Thu, 29 Oct 2009 07:50:23 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 764513A6807 for <behave@ietf.org>; Thu, 29 Oct 2009 07:50:23 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id E38BA6C1925; Thu, 29 Oct 2009 15:50:37 +0100 (CET) Message-ID: <4AE9ABBD.5080308@it.uc3m.es> Date: Thu, 29 Oct 2009 15:50:37 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Simon Perreault <simon.perreault@viagenie.ca> References: <4AE953B7.1090709@it.uc3m.es> <4AE98341.6050302@viagenie.ca> In-Reply-To: <4AE98341.6050302@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16976.003 Cc: behave@ietf.org Subject: Re: [BEHAVE] translator generating packet too big ICMP errors 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, 29 Oct 2009 14:50:24 -0000 Simon Perreault escribió: > marcelo bagnulo braun wrote, on 2009-10-29 04:35: > >> After reading the stateless translation draft, i couldn't find that the >> translator should generate ICMP error packet too big messages, in case >> it needs to drop an IPv4 packet with teh DF flag set with larger MTU >> than the one available in the IPv6 side or when it receives an IPv6 >> packet wihtout the fragment header that doesn't fit in the IPv4 MTU. >> > > Did you read your own document? ;) > > http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-02#section-7.1 > I did read my own document, thanks for asking... The point that i am trying to raise is that there is nothing specific to the stateful translation about generating packet too big packet at the translator when presented with a packet too big that cannot be fragmented. So, my point was whether this should be specified in the stateless document rather than in the stateful Regards, marcelo > There is a reference to it from the stateless doc in section 1.4: > > http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-03#section-1.4 > > Maybe I misinterpreted your question... > > Simon > From jukai.zte@gmail.com Thu Oct 29 07:59:27 2009 Return-Path: <jukai.zte@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 0ECF23A6807 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 07:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.373 X-Spam-Level: X-Spam-Status: No, score=-1.373 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrsUtNv7u1ly for <behave@core3.amsl.com>; Thu, 29 Oct 2009 07:59:25 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 493963A67E6 for <behave@ietf.org>; Thu, 29 Oct 2009 07:59:25 -0700 (PDT) Received: by qyk41 with SMTP id 41so1197667qyk.29 for <behave@ietf.org>; Thu, 29 Oct 2009 07:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=UDUVH/khKj0c52DPr1rVNovsaGlBo1unvoEUlaFESKo=; b=HGZv9ouqU8BD9owMRf3AWIBTxxsUef70hoAEXf4tZBHEyZyKeAXahAZET+vGiJhOjp aj0RhgZILBt/aRmPS9gfW/40o1ULoTNJY/JnkYEs7pQIiQ9rR82HaRNp+WHjY1pIwDNu 4XU5bEZCv1ifFHGDyK/KsTh1MEIlPsTQWWaDo= 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=V7ri1FtzY55aRgzPvgQ9z1/fL+bTunE0vCC+NN8C0EGVcwqdypTYh91tiMb3NlRCS8 /1MzrytxRz38J7V68jZgETx0sOHOB/7A3RuYcnY/C1Gfvu8C3NSRxnY+XuiSmxGF1l4s RpVgS/YwzKRxQKWfbnx7Zyg2Wd2cuhpe8iECU= MIME-Version: 1.0 Received: by 10.239.196.130 with SMTP id v2mr14151hbi.207.1256828375500; Thu, 29 Oct 2009 07:59:35 -0700 (PDT) In-Reply-To: <4AE96AFB.5000406@it.uc3m.es> References: <004501ca5879$938933d0$3a0c6f0a@china.huawei.com> <4AE96AFB.5000406@it.uc3m.es> Date: Thu, 29 Oct 2009 22:59:35 +0800 Message-ID: <3db7b9d60910290759k4314a976p1b8750417b0c03d8@mail.gmail.com> From: Kai Ju <jukai.zte@gmail.com> To: marcelo bagnulo braun <marcelo@it.uc3m.es> Content-Type: multipart/alternative; boundary=00c09feaf271dd881b047714282b Cc: Sheng Jiang <shengjiang@huawei.com>, behave@ietf.org, Zhen Cao <caozhenpku@gmail.com>, =?GB2312?B?xfQn?= <liudapeng@chinamobile.com>, =?GB2312?B?stzV8Q==?= <caozhen@chinamobile.com>, Behave Chairs <behave-chairs@tools.ietf.org>, Dan Wing <dwing@cisco.com> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 29 Oct 2009 14:59:27 -0000 --00c09feaf271dd881b047714282b Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable jiang sheng's pre condition is quite clear, by including other author, this draft could be adopted. 2009/10/29 marcelo bagnulo braun <marcelo@it.uc3m.es> > so, you do agree to take this doc as a WG item, right? > > > Sheng Jiang escribi=A8=AE: > > My opinions here is simple: without the contributions from China > Mobile, the > > draft is not good enough to be adopted as WG document though its initia= l > > contents are valuable and important. I support the current draft to be > > adopted for its contents without conditions. I also think single author > does > > not respect the others who makes important contributions. > > > > Furthermore, after the draft be accepted as WG document, future refine > work > > is still needed. A coauthor from China Mobile, who has proofed > understanding > > ftp64 issues, will only do good for the work. > > > > I don't understand the insistence why rejects a helpful coauthor. For m= e, > if > > an expert who understands my draft well wants to coauthor my draft with > > valuable contributions, he will be really appreciated. > > > > Best regards, > > > > Sheng > > > > > >> -----Original Message----- > >> From: behave-bounces@ietf.org > >> [mailto:behave-bounces@ietf.org] On Behalf Of marcelo bagnulo braun > >> Sent: Thursday, October 29, 2009 2:44 PM > >> To: Sheng Jiang > >> Cc: behave@ietf.org; 'Zhen Cao'; '=C1=F5=B4=F3=C5=F4'; '=B2=DC=D5=F1';= 'Behave > >> Chairs'; 'Dan Wing' > >> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 > >> as WG item > >> > >> What strikes me is that you seem to be conditioning the > >> support for acceptance of this doc as WG document to the fact > >> whether and additional editor is added to the document or not. > >> > >> These seems different issues imho. Any document needs to > >> reflect the WG consensus whether it has one or many _editors_ > >> > >> The question at hand is whehter this document is or not a > >> good starting point to do that. > >> > >> Regards, marcelo > >> > >> > >> > >> Sheng Jiang escribi=A8=AE: > >> > >>> Hi, Iljitsch, > >>> > >>> Taking one coauthor from the carriers, who would be the > >>> > >> major user of > >> > >>> ftp64, would potentially make your work better. Actually, > >>> > >> their work > >> > >>> has already improved your draft as you took input from > >>> > >> their draft and > >> > >>> the discussion with them. It should do no harm for you, I guess. > >>> > >>> Sheng > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: behave-bounces@ietf.org > >>>> [mailto:behave-bounces@ietf.org] On Behalf Of marcelo bagnulo braun > >>>> Sent: Wednesday, October 28, 2009 3:55 PM > >>>> To: Zhen Cao > >>>> Cc: =C1=F5=B4=F3=C5=F4; =B2=DC=D5=F1; behave@ietf.org; Behave Chairs= ; Dan Wing > >>>> Subject: Re: [BEHAVE] adopt > >>>> > >> draft-van-beijnum-behave-ftp64-06 as WG > >> > >>>> item > >>>> > >>>> Zhen, > >>>> > >>>> from the points you make, it doesn't seem that you have a > >>>> > >> fundamental > >> > >>>> problem with the document but changes that can easily be > >>>> > >> integrated > >> > >>>> in the document, if the WG agreed with them. Since we are only > >>>> accepting a WG document and not in WGLC, i don't think the > >>>> > >> argument > >> > >>>> is strong not ot accept the doc as a WG document, it just > >>>> > >> needs to be > >> > >>>> improved as any other doc when accepted as WG document. > >>>> > >>>> Regards, marcelo > >>>> > >>>> > >>>> Zhen Cao escribi=A8=AE: > >>>> > >>>> > >>>>> 2009/10/28 Dan Wing <dwing@cisco.com>: > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Zhen Cao [mailto:caozhenpku@gmail.com] > >>>>>>> Sent: Tuesday, October 27, 2009 8:40 AM > >>>>>>> To: Dan Wing > >>>>>>> Cc: behave@ietf.org; =C1=F5=B4=F3=C5=F4; =B2=DC=D5=F1; Behave Cha= irs > >>>>>>> Subject: Re: [BEHAVE] adopt > >>>>>>> > >>>>>>> > >>>> draft-van-beijnum-behave-ftp64-06 as WG > >>>> > >>>> > >>>>>>> item > >>>>>>> > >>>>>>> Hi Dan and All, > >>>>>>> > >>>>>>> Many parts of the document are still very confusing. 1) > >>>>>>> > >>>>>>> > >>>> It did not > >>>> > >>>> > >>>>>>> clearly specify the target scenario. From the title, people may > >>>>>>> think it is talking about IPv6 ftp client communicating > >>>>>>> > >>>>>>> > >>>> with IPv4 server. > >>>> > >>>> > >>>>>>> But in section.5, it confuses me a lot by this sentence > >>>>>>> > >>>>>>> > >>>> "even if the > >>>> > >>>> > >>>>>>> client has IPv4 reachability......". 2) ALG problem. Section 6 > >>>>>>> starts with ALG but does not specify clearly which case > >>>>>>> > >> needs ALG > >> > >>>>>>> and which does not. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> Thanks. I expect those can be resolved as the document > >>>>>> > >>>>>> > >>>> progresses as > >>>> > >>>> > >>>>>> a WG document. > >>>>>> > >>>>>> > >>>>>> > >>>>> Back to Andrew's proposal, I was just raising some concerns > >>>>> > >>>>> > >>>> on why I > >>>> > >>>> > >>>>> do not support the adoption. I am afraid it is not a solid basis. > >>>>> _______________________________________________ > >>>>> 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 > >> > >> > > > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > --00c09feaf271dd881b047714282b Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable jiang sheng's pre condition is quite clear, by including other author, = this draft could be adopted.<br><br> <div class=3D"gmail_quote">2009/10/29 marcelo bagnulo braun <span dir=3D"lt= r"><<a href=3D"mailto:marcelo@it.uc3m.es" target=3D"_blank">marcelo@it.u= c3m.es</a>></span><br> <blockquote style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex= ; PADDING-LEFT: 1ex" class=3D"gmail_quote">so, you do agree to take this do= c as a WG item, right?<br><br><br>Sheng Jiang escribi=A8=AE:<br> <div> <div></div> <div>> My opinions here is simple: without the contributions from China = Mobile, the<br>> draft is not good enough to be adopted as WG document t= hough its initial<br>> contents are valuable and important. I support th= e current draft to be<br> > adopted for its contents without conditions. I also think single autho= r does<br>> not respect the others who makes important contributions.<br= >><br>> Furthermore, after the draft be accepted as WG document, futu= re refine work<br> > is still needed. A coauthor from China Mobile, who has proofed underst= anding<br>> ftp64 issues, will only do good for the work.<br>><br>>= ; I don't understand the insistence why rejects a helpful coauthor. For= me, if<br> > an expert who understands my draft well wants to coauthor my draft wit= h<br>> valuable contributions, he will be really appreciated.<br>><br= >> Best regards,<br>><br>> Sheng<br>><br>><br>>> -----= Original Message-----<br> >> From: <a href=3D"mailto:behave-bounces@ietf.org" target=3D"_blank"= >behave-bounces@ietf.org</a><br>>> [mailto:<a href=3D"mailto:behave-b= ounces@ietf.org" target=3D"_blank">behave-bounces@ietf.org</a>] On Behalf O= f marcelo bagnulo braun<br> >> Sent: Thursday, October 29, 2009 2:44 PM<br>>> To: Sheng Jia= ng<br>>> Cc: <a href=3D"mailto:behave@ietf.org" target=3D"_blank">beh= ave@ietf.org</a>; 'Zhen Cao'; '=C1=F5=B4=F3=C5=F4'; '= =B2=DC=D5=F1'; 'Behave<br> >> Chairs'; 'Dan Wing'<br>>> Subject: Re: [BEHAVE] = adopt draft-van-beijnum-behave-ftp64-06<br>>> as WG item<br>>><= br>>> What strikes me is that you seem to be conditioning the<br> >> support for acceptance of this doc as WG document to the fact<br>&= gt;> whether and additional editor is added to the document or not.<br>&= gt;><br>>> These seems different issues imho. Any document needs t= o<br> >> reflect the WG consensus whether it has one or many _editors_<br>&= gt;><br>>> The question at hand is whehter this document is or not= a<br>>> good starting point to do that.<br>>><br>>> Rega= rds, marcelo<br> >><br>>><br>>><br>>> Sheng Jiang escribi=A8=AE:<br>= >><br>>>> Hi, Iljitsch,<br>>>><br>>>> Taki= ng one coauthor from the carriers, who would be the<br>>>><br>>= > major user of<br> >><br>>>> ftp64, would potentially make your work better. Ac= tually,<br>>>><br>>> their work<br>>><br>>>> = has already improved your draft as you took input from<br>>>><br> >> their draft and<br>>><br>>>> the discussion with th= em. It should do no harm for you, I guess.<br>>>><br>>>> = Sheng<br>>>><br>>>><br>>>><br>>>>> -= ----Original Message-----<br> >>>> From: <a href=3D"mailto:behave-bounces@ietf.org" target=3D= "_blank">behave-bounces@ietf.org</a><br>>>>> [mailto:<a href=3D= "mailto:behave-bounces@ietf.org" target=3D"_blank">behave-bounces@ietf.org<= /a>] On Behalf Of marcelo bagnulo braun<br> >>>> Sent: Wednesday, October 28, 2009 3:55 PM<br>>>>&= gt; To: Zhen Cao<br>>>>> Cc: =C1=F5=B4=F3=C5=F4; =B2=DC=D5=F1; = <a href=3D"mailto:behave@ietf.org" target=3D"_blank">behave@ietf.org</a>; B= ehave Chairs; Dan Wing<br> >>>> Subject: Re: [BEHAVE] adopt<br>>>>><br>>>= ; draft-van-beijnum-behave-ftp64-06 as WG<br>>><br>>>>> i= tem<br>>>>><br>>>>> Zhen,<br>>>>><br> >>>> from the points you make, it doesn't seem that you hav= e a<br>>>>><br>>> fundamental<br>>><br>>>>= > problem with the document but changes that can easily be<br>>>&g= t;><br> >> integrated<br>>><br>>>>> in the document, if the= WG agreed with them. Since we are only<br>>>>> accepting a WG = document and not in WGLC, i don't think the<br>>>>><br> >> argument<br>>><br>>>>> is strong not ot accept t= he doc as a WG document, it just<br>>>>><br>>> needs to b= e<br>>><br>>>>> improved as any other doc when accepted a= s WG document.<br> >>>><br>>>>> Regards, marcelo<br>>>>><b= r>>>>><br>>>>> Zhen Cao escribi=A8=AE:<br>>>&= gt;><br>>>>><br>>>>>> 2009/10/28 Dan Wing <= ;<a href=3D"mailto:dwing@cisco.com" target=3D"_blank">dwing@cisco.com</a>&g= t;:<br> >>>>><br>>>>>><br>>>>>><br>>= ;>>>>><br>>>>>>><br>>>>>>&g= t;<br>>>>>>>> -----Original Message-----<br>>>&g= t;>>>> From: Zhen Cao [mailto:<a href=3D"mailto:caozhenpku@gmai= l.com" target=3D"_blank">caozhenpku@gmail.com</a>]<br> >>>>>>> Sent: Tuesday, October 27, 2009 8:40 AM<br>>= ;>>>>>> To: Dan Wing<br>>>>>>>> Cc: = <a href=3D"mailto:behave@ietf.org" target=3D"_blank">behave@ietf.org</a>; = =C1=F5=B4=F3=C5=F4; =B2=DC=D5=F1; Behave Chairs<br> >>>>>>> Subject: Re: [BEHAVE] adopt<br>>>>>= ;>>><br>>>>>>>><br>>>>> draft-van= -beijnum-behave-ftp64-06 as WG<br>>>>><br>>>>><br> >>>>>>> item<br>>>>>>>><br>>&g= t;>>>>> Hi Dan and All,<br>>>>>>>><br>&= gt;>>>>>> Many parts of the document are still very confu= sing. 1)<br> >>>>>>><br>>>>>>>><br>>>>= ;> It did not<br>>>>><br>>>>><br>>>>>= ;>>> clearly specify the target scenario. From the title, people m= ay<br> >>>>>>> think it is talking about IPv6 ftp client comm= unicating<br>>>>>>>><br>>>>>>>><b= r>>>>> with IPv4 server.<br>>>>><br>>>>>= ;<br> >>>>>>> But in section.5, it confuses me a lot by this= sentence<br>>>>>>>><br>>>>>>>><b= r>>>>> "even if the<br>>>>><br>>>>>= ;<br> >>>>>>> client has IPv4 reachability......". 2) A= LG problem. Section 6<br>>>>>>>> starts with ALG but d= oes not specify clearly which case<br>>>>>>>><br>>&= gt; needs ALG<br> >><br>>>>>>>> and which does not.<br>>>>= ;>>>><br>>>>>>>><br>>>>>>&g= t;><br>>>>>>> Thanks.  I expect those can be reso= lved as the document<br> >>>>>><br>>>>>>><br>>>>> pr= ogresses as<br>>>>><br>>>>><br>>>>>>= > a WG document.<br>>>>>>><br>>>>>>>= <br> >>>>>><br>>>>>> Back to Andrew's propo= sal, I was just raising some concerns<br>>>>>><br>>>&g= t;>><br>>>>> on why I<br>>>>><br>>>>= ><br> >>>>> do not support the adoption. I am afraid it is not a s= olid basis.<br>>>>>> _______________________________________= ________<br>>>>>> Behave mailing list<br>>>>>>= ; <a href=3D"mailto:Behave@ietf.org" target=3D"_blank">Behave@ietf.org</a><= br> >>>>> <a href=3D"https://www.ietf.org/mailman/listinfo/behav= e" target=3D"_blank">https://www.ietf.org/mailman/listinfo/behave</a><br>&g= t;>>>><br>>>>>><br>>>>>><br>>&= gt;>> _______________________________________________<br> >>>> Behave mailing list<br>>>>> <a href=3D"mailto:= Behave@ietf.org" target=3D"_blank">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> >>>><br>>>>><br>>>>><br>>>><br= >>>><br>>> _______________________________________________<b= r>>> Behave mailing list<br>>> <a href=3D"mailto:Behave@ietf.or= g" target=3D"_blank">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>>><br>&g= t;><br>><br>><br>><br><br>_____________________________________= __________<br> Behave mailing list<br><a href=3D"mailto:Behave@ietf.org" target=3D"_blank"= >Behave@ietf.org</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/be= have" target=3D"_blank">https://www.ietf.org/mailman/listinfo/behave</a><br= ></div> </div></blockquote></div><br> --00c09feaf271dd881b047714282b-- From marcelo@it.uc3m.es Thu Oct 29 08:07:44 2009 Return-Path: <marcelo@it.uc3m.es> 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 537443A6955 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 08:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[AWL=-1.047, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pa4aXnvhdwtD for <behave@core3.amsl.com>; Thu, 29 Oct 2009 08:07:43 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 9EEE53A6807 for <behave@ietf.org>; Thu, 29 Oct 2009 08:07:42 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp01.uc3m.es (Postfix) with ESMTP id 55C41BA7B92; Thu, 29 Oct 2009 16:07:57 +0100 (CET) Message-ID: <4AE9AFCD.4080102@it.uc3m.es> Date: Thu, 29 Oct 2009 16:07:57 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Kai Ju <jukai.zte@gmail.com> References: <004501ca5879$938933d0$3a0c6f0a@china.huawei.com> <4AE96AFB.5000406@it.uc3m.es> <3db7b9d60910290759k4314a976p1b8750417b0c03d8@mail.gmail.com> In-Reply-To: <3db7b9d60910290759k4314a976p1b8750417b0c03d8@mail.gmail.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16976.003 Cc: Sheng Jiang <shengjiang@huawei.com>, behave@ietf.org, Zhen Cao <caozhenpku@gmail.com>, =?GB2312?B?xfQn?= <liudapeng@chinamobile.com>, =?GB2312?B?stzV8Q==?= <caozhen@chinamobile.com>, Behave Chairs <behave-chairs@tools.ietf.org>, Dan Wing <dwing@cisco.com> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 29 Oct 2009 15:07:44 -0000 that s exactly the condition that i find very strange for adopting a document... either the document is a good base for a WG document or not, irrespectively of the editors that the document has. the basis for accepting a WG document should be technical reasons not whether you like or not the editor list. regards, marcelo Kai Ju escribi¨®: > jiang sheng's pre condition is quite clear, by including other author, > this draft could be adopted. > > 2009/10/29 marcelo bagnulo braun <marcelo@it.uc3m.es > <mailto:marcelo@it.uc3m.es>> > > so, you do agree to take this doc as a WG item, right? > > > Sheng Jiang escribi¨®: > > My opinions here is simple: without the contributions from China > Mobile, the > > draft is not good enough to be adopted as WG document though its > initial > > contents are valuable and important. I support the current draft > to be > > adopted for its contents without conditions. I also think single > author does > > not respect the others who makes important contributions. > > > > Furthermore, after the draft be accepted as WG document, future > refine work > > is still needed. A coauthor from China Mobile, who has proofed > understanding > > ftp64 issues, will only do good for the work. > > > > I don't understand the insistence why rejects a helpful > coauthor. For me, if > > an expert who understands my draft well wants to coauthor my > draft with > > valuable contributions, he will be really appreciated. > > > > Best regards, > > > > Sheng > > > > > >> -----Original Message----- > >> From: behave-bounces@ietf.org <mailto:behave-bounces@ietf.org> > >> [mailto:behave-bounces@ietf.org > <mailto:behave-bounces@ietf.org>] On Behalf Of marcelo bagnulo braun > >> Sent: Thursday, October 29, 2009 2:44 PM > >> To: Sheng Jiang > >> Cc: behave@ietf.org <mailto:behave@ietf.org>; 'Zhen Cao'; 'Áõ´ó > Åô'; '²ÜÕñ'; 'Behave > >> Chairs'; 'Dan Wing' > >> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 > >> as WG item > >> > >> What strikes me is that you seem to be conditioning the > >> support for acceptance of this doc as WG document to the fact > >> whether and additional editor is added to the document or not. > >> > >> These seems different issues imho. Any document needs to > >> reflect the WG consensus whether it has one or many _editors_ > >> > >> The question at hand is whehter this document is or not a > >> good starting point to do that. > >> > >> Regards, marcelo > >> > >> > >> > >> Sheng Jiang escribi¨®: > >> > >>> Hi, Iljitsch, > >>> > >>> Taking one coauthor from the carriers, who would be the > >>> > >> major user of > >> > >>> ftp64, would potentially make your work better. Actually, > >>> > >> their work > >> > >>> has already improved your draft as you took input from > >>> > >> their draft and > >> > >>> the discussion with them. It should do no harm for you, I guess. > >>> > >>> Sheng > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: behave-bounces@ietf.org <mailto:behave-bounces@ietf.org> > >>>> [mailto:behave-bounces@ietf.org > <mailto:behave-bounces@ietf.org>] On Behalf Of marcelo bagnulo braun > >>>> Sent: Wednesday, October 28, 2009 3:55 PM > >>>> To: Zhen Cao > >>>> Cc: Áõ´óÅô; ²ÜÕñ; behave@ietf.org <mailto:behave@ietf.org>; > Behave Chairs; Dan Wing > >>>> Subject: Re: [BEHAVE] adopt > >>>> > >> draft-van-beijnum-behave-ftp64-06 as WG > >> > >>>> item > >>>> > >>>> Zhen, > >>>> > >>>> from the points you make, it doesn't seem that you have a > >>>> > >> fundamental > >> > >>>> problem with the document but changes that can easily be > >>>> > >> integrated > >> > >>>> in the document, if the WG agreed with them. Since we are only > >>>> accepting a WG document and not in WGLC, i don't think the > >>>> > >> argument > >> > >>>> is strong not ot accept the doc as a WG document, it just > >>>> > >> needs to be > >> > >>>> improved as any other doc when accepted as WG document. > >>>> > >>>> Regards, marcelo > >>>> > >>>> > >>>> Zhen Cao escribi¨®: > >>>> > >>>> > >>>>> 2009/10/28 Dan Wing <dwing@cisco.com <mailto:dwing@cisco.com>>: > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Zhen Cao [mailto:caozhenpku@gmail.com > <mailto:caozhenpku@gmail.com>] > >>>>>>> Sent: Tuesday, October 27, 2009 8:40 AM > >>>>>>> To: Dan Wing > >>>>>>> Cc: behave@ietf.org <mailto:behave@ietf.org>; Áõ´óÅô; ²Ü > Õñ; Behave Chairs > >>>>>>> Subject: Re: [BEHAVE] adopt > >>>>>>> > >>>>>>> > >>>> draft-van-beijnum-behave-ftp64-06 as WG > >>>> > >>>> > >>>>>>> item > >>>>>>> > >>>>>>> Hi Dan and All, > >>>>>>> > >>>>>>> Many parts of the document are still very confusing. 1) > >>>>>>> > >>>>>>> > >>>> It did not > >>>> > >>>> > >>>>>>> clearly specify the target scenario. From the title, > people may > >>>>>>> think it is talking about IPv6 ftp client communicating > >>>>>>> > >>>>>>> > >>>> with IPv4 server. > >>>> > >>>> > >>>>>>> But in section.5, it confuses me a lot by this sentence > >>>>>>> > >>>>>>> > >>>> "even if the > >>>> > >>>> > >>>>>>> client has IPv4 reachability......". 2) ALG problem. Section 6 > >>>>>>> starts with ALG but does not specify clearly which case > >>>>>>> > >> needs ALG > >> > >>>>>>> and which does not. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> Thanks. I expect those can be resolved as the document > >>>>>> > >>>>>> > >>>> progresses as > >>>> > >>>> > >>>>>> a WG document. > >>>>>> > >>>>>> > >>>>>> > >>>>> Back to Andrew's proposal, I was just raising some concerns > >>>>> > >>>>> > >>>> on why I > >>>> > >>>> > >>>>> do not support the adoption. I am afraid it is not a solid > basis. > >>>>> _______________________________________________ > >>>>> Behave mailing list > >>>>> Behave@ietf.org <mailto:Behave@ietf.org> > >>>>> https://www.ietf.org/mailman/listinfo/behave > >>>>> > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> Behave mailing list > >>>> Behave@ietf.org <mailto:Behave@ietf.org> > >>>> https://www.ietf.org/mailman/listinfo/behave > >>>> > >>>> > >>>> > >>> > >>> > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org <mailto:Behave@ietf.org> > >> https://www.ietf.org/mailman/listinfo/behave > >> > >> > > > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org <mailto:Behave@ietf.org> > https://www.ietf.org/mailman/listinfo/behave > > From ajs@shinkuro.com Thu Oct 29 08:12:07 2009 Return-Path: <ajs@shinkuro.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 281633A6955 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 08:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=0.667, 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 rDdla2umcTYp for <behave@core3.amsl.com>; Thu, 29 Oct 2009 08:12:06 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 41E183A6942 for <behave@ietf.org>; Thu, 29 Oct 2009 08:12:06 -0700 (PDT) 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 5EBD72FE8CDC for <behave@ietf.org>; Thu, 29 Oct 2009 15:12:21 +0000 (UTC) Date: Thu, 29 Oct 2009 11:12:19 -0400 From: Andrew Sullivan <ajs@shinkuro.com> To: behave@ietf.org Message-ID: <20091029151219.GG65688@shinkuro.com> References: <004501ca5879$938933d0$3a0c6f0a@china.huawei.com> <4AE96AFB.5000406@it.uc3m.es> <3db7b9d60910290759k4314a976p1b8750417b0c03d8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3db7b9d60910290759k4314a976p1b8750417b0c03d8@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 29 Oct 2009 15:12:07 -0000 On Thu, Oct 29, 2009 at 10:59:35PM +0800, Kai Ju wrote: > jiang sheng's pre condition is quite clear, by including other author, this > draft could be adopted. I'm not sure how our Chairs prefer to work these matters, but it is my understanding that the editors of a draft which is to be a WG product normally serve at the pleasure of the Chairs. Therefore, I don't believe the WG participants are in a position to insist on one or another editor for the draft as a condition of making it a WG work item. "Is the _draft_ to be worked on by the WG?" is the question, as I understand it. The Chairs might well decide that someone previously entirely unconnected to this effort will hold the pen, and that's something they get to choose after the WG has expressed its willingness to adopt the work item. Best regards, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From marcelo@it.uc3m.es Thu Oct 29 08:13:08 2009 Return-Path: <marcelo@it.uc3m.es> 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 1DDD73A69AB for <behave@core3.amsl.com>; Thu, 29 Oct 2009 08:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.379 X-Spam-Level: X-Spam-Status: No, score=-6.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PCh2aNWIMeW for <behave@core3.amsl.com>; Thu, 29 Oct 2009 08:13:07 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 3EF5B3A6942 for <behave@ietf.org>; Thu, 29 Oct 2009 08:13:07 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp01.uc3m.es (Postfix) with ESMTP id 0C8C3BA69FD for <behave@ietf.org>; Thu, 29 Oct 2009 16:13:22 +0100 (CET) Message-ID: <4AE9B111.9010702@it.uc3m.es> Date: Thu, 29 Oct 2009 16:13:21 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Behave WG <behave@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16976.003 Subject: [BEHAVE] setting the ID field and the DF flag for outgoing IPv4 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, 29 Oct 2009 15:13:08 -0000 Hi, according to the stateless draft: 3.1. Translating IPv6 Headers into IPv4 Headers If there is no IPv6 Fragment header, the IPv4 header fields are set as follows: ... Identification: All zero. ... Flags: The More Fragments flag is copied from the M flag in the Fragment header. The Don't Fragments flag is set to zero allowing this packet to be fragmented by IPv4 routers. So, is it me or this is a problem? (note that this was unchanged from rfc2765) I mean, we are allowing fragmentation but we are including a reasonable ID value, so if packets get fragmented, we won't be able to reasemeble them, cause all packet will contain the same ID... what am i missing? Regards, marcelo From marcelo@it.uc3m.es Thu Oct 29 08:16:25 2009 Return-Path: <marcelo@it.uc3m.es> 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 C47F73A67B3 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 08:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.387 X-Spam-Level: X-Spam-Status: No, score=-6.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SO3yYZ0qRm6B for <behave@core3.amsl.com>; Thu, 29 Oct 2009 08:16:25 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id CC51C3A6783 for <behave@ietf.org>; Thu, 29 Oct 2009 08:16:24 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id 62AD56C2846 for <behave@ietf.org>; Thu, 29 Oct 2009 16:16:39 +0100 (CET) Message-ID: <4AE9B1D7.8020709@it.uc3m.es> Date: Thu, 29 Oct 2009 16:16:39 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Behave WG <behave@ietf.org> References: <4AE9B111.9010702@it.uc3m.es> In-Reply-To: <4AE9B111.9010702@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16976.003 Subject: Re: [BEHAVE] setting the ID field and the DF flag for outgoing IPv4 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, 29 Oct 2009 15:16:25 -0000 please disregard this message. I mixed the processing of the IPv6 packets with and without fragment header. sorry for the noise marcelo bagnulo braun escribió: > Hi, > > according to the stateless draft: > > 3.1. Translating IPv6 Headers into IPv4 Headers > > > If there is no IPv6 Fragment header, the IPv4 header fields are set > as follows: > > ... > > Identification: All zero. > ... > > Flags: The More Fragments flag is copied from the M flag in the > Fragment header. The Don't Fragments flag is set to zero allowing > this packet to be fragmented by IPv4 routers. > > > So, is it me or this is a problem? > > (note that this was unchanged from rfc2765) > > I mean, we are allowing fragmentation but we are including a > reasonable ID value, so if packets get fragmented, we won't be able to > reasemeble them, cause all packet will contain the same ID... what am > i missing? > > Regards, marcelo > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From dwing@cisco.com Thu Oct 29 08:41:56 2009 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 0C6523A6885 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 08:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.315 X-Spam-Level: X-Spam-Status: No, score=-6.315 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vd0733srMY1R for <behave@core3.amsl.com>; Thu, 29 Oct 2009 08:41:55 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0AAF73A67F4 for <behave@ietf.org>; Thu, 29 Oct 2009 08:41:55 -0700 (PDT) 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: Aq8EALJU6UqrR7Ht/2dsb2JhbACKX7tLmBWEPQQ X-IronPort-AV: E=Sophos;i="4.44,646,1249257600"; d="scan'208";a="263402560" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 29 Oct 2009 15:42:11 +0000 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9TFg9qA020279; Thu, 29 Oct 2009 15:42:11 GMT From: "Dan Wing" <dwing@cisco.com> To: "Behave WG" <behave@ietf.org> Date: Thu, 29 Oct 2009 08:42:11 -0700 Message-ID: <1ca701ca58ae$614b5080$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpYrmEb9pKIA0L+SGKLOCUUXMVMMA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: draft-ietf-behave-turn@tools.ietf.org, behave-chairs@tools.ietf.org Subject: [BEHAVE] TURN port assignment and IANA port registry 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, 29 Oct 2009 15:41:56 -0000 The IANA section in TURN [1] does not request a port assignment for TURN. However, due to existing IANA procedures, IANA is assigning port numbers for TURN. When [2] is adopted, the IANA procedures will be changed so that a port number registration is not required; however, [2] is not yet adopted. This email is to confirm there is no objection in BEHAVE for the following IANA action to the IANA port registry [3]: OLD: stun 3478/tcp Session Traversal Utilities for NAT (STUN) port stun 3478/udp Session Traversal Utilities for NAT (STUN) port # [RFC5389] ... stuns 5349/tcp STUN over TLS stuns 5349/udp Reserved for a future enhancement of STUN # [RFC5389] NEW: stun 3478/tcp Session Traversal Utilities for NAT (STUN) port stun 3478/udp Session Traversal Utilities for NAT (STUN) port # [RFC5389] turn 3478/tcp TURN over TCP turn 3478/udp TURN over UDP # [RFC-ietf-behave-turn-16.txt] ... stuns 5349/tcp STUN over TLS stuns 5349/udp Reserved for a future enhancement of STUN # [RFC5389] turns 5349/tcp TURN over TLS turns 5349/udp Reserved for a future enhancement of TURN If you have an objection, please send email to behave-chairs@tools.ietf.org. Thanks. [1] http://tools.ietf.org/html/draft-ietf-behave-turn-16#section-18 [2] http://tools.ietf.org/html/draft-ietf-tsvwg-iana-ports-03 [3] http://www.iana.org/assignments/port-numbers From ajs@shinkuro.com Thu Oct 29 09:05:18 2009 Return-Path: <ajs@shinkuro.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 5090E3A68C3 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 09:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.633, 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 Z2xD8KlVOgn7 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 09:05:17 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 850DC3A6835 for <behave@ietf.org>; Thu, 29 Oct 2009 09:05:17 -0700 (PDT) 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 143632FE8CDC; Thu, 29 Oct 2009 16:05:33 +0000 (UTC) Date: Thu, 29 Oct 2009 12:05:31 -0400 From: Andrew Sullivan <ajs@shinkuro.com> To: Dan Wing <dwing@cisco.com> Message-ID: <20091029160531.GI65688@shinkuro.com> References: <1ca701ca58ae$614b5080$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1ca701ca58ae$614b5080$c5f0200a@cisco.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: draft-ietf-behave-turn@tools.ietf.org, Behave WG <behave@ietf.org>, behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] TURN port assignment and IANA port registry 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, 29 Oct 2009 16:05:18 -0000 On Thu, Oct 29, 2009 at 08:42:11AM -0700, Dan Wing wrote: > The IANA section in TURN [1] does not request a port assignment for TURN. > However, due to existing IANA procedures, IANA is assigning port numbers for > TURN. When [2] is adopted, the IANA procedures will be changed so that a port > number registration is not required; however, [2] is not yet adopted. This seems like an insane waste of port numbers, since they're not needed. Is there some way to include the text "not used" or something like that in these assignments, so that (1) naive firewall people don't immediately start trying to make rules based on these numbers and (2) future port assignments can re-use these numbers without fear? (I don't want actually to object to the assignment, since we obviously need to get around this bureaucratic issue somehow.) A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dwing@cisco.com Thu Oct 29 09:31:41 2009 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 9CA7F3A67E7 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 09:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.327 X-Spam-Level: X-Spam-Status: No, score=-6.327 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEnq9siu7XwU for <behave@core3.amsl.com>; Thu, 29 Oct 2009 09:31:40 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id B1A123A67D1 for <behave@ietf.org>; Thu, 29 Oct 2009 09:31:40 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8EAF5g6UqrR7Ht/2dsb2JhbACKX7tjmBiEPQQ X-IronPort-AV: E=Sophos;i="4.44,646,1249257600"; d="scan'208";a="199901523" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 29 Oct 2009 16:31:57 +0000 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9TGVu5N024074; Thu, 29 Oct 2009 16:31:57 GMT From: "Dan Wing" <dwing@cisco.com> To: "'Andrew Sullivan'" <ajs@shinkuro.com> References: <1ca701ca58ae$614b5080$c5f0200a@cisco.com> <20091029160531.GI65688@shinkuro.com> Date: Thu, 29 Oct 2009 09:31:56 -0700 Message-ID: <1ce001ca58b5$55024f20$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpYsaXxs4JBwoiFQT25dReOYgzB1AAAyRQA In-Reply-To: <20091029160531.GI65688@shinkuro.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: draft-ietf-behave-turn@tools.ietf.org, 'Behave WG' <behave@ietf.org>, behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] TURN port assignment and IANA port registry 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, 29 Oct 2009 16:31:41 -0000 > -----Original Message----- > From: Andrew Sullivan [mailto:ajs@shinkuro.com] > Sent: Thursday, October 29, 2009 9:06 AM > To: Dan Wing > Cc: Behave WG; draft-ietf-behave-turn@tools.ietf.org; > behave-chairs@tools.ietf.org > Subject: Re: [BEHAVE] TURN port assignment and IANA port registry > > On Thu, Oct 29, 2009 at 08:42:11AM -0700, Dan Wing wrote: > > The IANA section in TURN [1] does not request a port > assignment for TURN. > > However, due to existing IANA procedures, IANA is assigning > port numbers for > > TURN. When [2] is adopted, the IANA procedures will be > changed so that a port > > number registration is not required; however, [2] is not > yet adopted. > > This seems like an insane waste of port numbers, since they're not > needed. An additional port was not assigned; the port number for TURN is the same as STUN (3478). See http://www.iana.org/assignments/port-numbers which contains the assignment. > Is there some way to include the text "not used" or something > like that in these assignments, so that (1) naive firewall people > don't immediately start trying to make rules based on these numbers > and (2) future port assignments can re-use these numbers without fear? > (I don't want actually to object to the assignment, since we obviously > need to get around this bureaucratic issue somehow.) STUN need a default port, partially to deal with applications, and libraries that don't support SRV. TURN is an extension to STUN so can use the same port. The TURN port is expected to be configurable via SRV (with same requirements on applications and libraries for SRV support) or also via its URI defined in draft-ietf-behave-turn-uri. -d > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. From dwing@cisco.com Thu Oct 29 09:42:17 2009 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 EC8373A6893 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 09:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.338 X-Spam-Level: X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xa-eqojv7-wa for <behave@core3.amsl.com>; Thu, 29 Oct 2009 09:42:17 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2687F3A6836 for <behave@ietf.org>; Thu, 29 Oct 2009 09:42:17 -0700 (PDT) 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: Aq8EALdi6UqrR7H+/2dsb2JhbACKX7twmBmEPQSBYg X-IronPort-AV: E=Sophos;i="4.44,647,1249257600"; d="scan'208";a="263439828" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 29 Oct 2009 16:42:33 +0000 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9TGgXf3004823; Thu, 29 Oct 2009 16:42:33 GMT From: "Dan Wing" <dwing@cisco.com> To: "'Andrew Sullivan'" <ajs@shinkuro.com>, <behave@ietf.org> References: <004501ca5879$938933d0$3a0c6f0a@china.huawei.com><4AE96AFB.5000406@it.uc3m.es><3db7b9d60910290759k4314a976p1b8750417b0c03d8@mail.gmail.com> <20091029151219.GG65688@shinkuro.com> Date: Thu, 29 Oct 2009 09:42:33 -0700 Message-ID: <1d1001ca58b6$d05fec80$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpYqjkmxBf5dr+vQYqwGtGaqoMC3gAC+nGw In-Reply-To: <20091029151219.GG65688@shinkuro.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 29 Oct 2009 16:42:18 -0000 > On Thu, Oct 29, 2009 at 10:59:35PM +0800, Kai Ju wrote: > > jiang sheng's pre condition is quite clear, by including > > other author, this draft could be adopted. > > I'm not sure how our Chairs prefer to work these matters, but it is my > understanding that the editors of a draft which is to be a WG product > normally serve at the pleasure of the Chairs. Therefore, I don't > believe the WG participants are in a position to insist on one or > another editor for the draft as a condition of making it a WG work > item. "Is the _draft_ to be worked on by the WG?" is the question, as > I understand it. The Chairs might well decide that someone previously > entirely unconnected to this effort will hold the pen, and that's > something they get to choose after the WG has expressed its > willingness to adopt the work item. Yes, the question at hand is 'shall we adopt this document'. I did not ask 'who wants to be an author'. I have not seen a substantive objection since I asked a week ago (Oct 22). -d From ajs@shinkuro.com Thu Oct 29 09:46:14 2009 Return-Path: <ajs@shinkuro.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 25FD93A691F for <behave@core3.amsl.com>; Thu, 29 Oct 2009 09:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.615, 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 8J9uh3xlRDHq for <behave@core3.amsl.com>; Thu, 29 Oct 2009 09:46:13 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 6C0413A691D for <behave@ietf.org>; Thu, 29 Oct 2009 09:46:13 -0700 (PDT) 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 81C732FE8CDC; Thu, 29 Oct 2009 16:46:28 +0000 (UTC) Date: Thu, 29 Oct 2009 12:46:26 -0400 From: Andrew Sullivan <ajs@shinkuro.com> To: Dan Wing <dwing@cisco.com> Message-ID: <20091029164626.GJ65688@shinkuro.com> References: <1ca701ca58ae$614b5080$c5f0200a@cisco.com> <20091029160531.GI65688@shinkuro.com> <1ce001ca58b5$55024f20$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1ce001ca58b5$55024f20$c5f0200a@cisco.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: draft-ietf-behave-turn@tools.ietf.org, 'Behave WG' <behave@ietf.org>, behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] TURN port assignment and IANA port registry 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, 29 Oct 2009 16:46:14 -0000 On Thu, Oct 29, 2009 at 09:31:56AM -0700, Dan Wing wrote: > An additional port was not assigned; the port number for TURN > is the same as STUN (3478). Oh, well, then, I'll shut up. I guess I should have checked this first. No objection here. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dwing@cisco.com Thu Oct 29 09:52:29 2009 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 263443A68EE for <behave@core3.amsl.com>; Thu, 29 Oct 2009 09:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.123 X-Spam-Level: X-Spam-Status: No, score=-5.123 tagged_above=-999 required=5 tests=[AWL=-0.974, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ey4EpyiJewGM for <behave@core3.amsl.com>; Thu, 29 Oct 2009 09:52:27 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id C01933A6882 for <behave@ietf.org>; Thu, 29 Oct 2009 09:52:27 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEEAEtl6UqrR7H+/2dsb2JhbACEcoVtu3mHDAiRA4EugjhXBIFigQU X-IronPort-AV: E=Sophos;i="4.44,647,1249257600"; d="scan'208";a="219380349" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 29 Oct 2009 16:52:44 +0000 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9TGqhP9018284; Thu, 29 Oct 2009 16:52:43 GMT From: "Dan Wing" <dwing@cisco.com> To: "'liu dapeng'" <maxpassion@gmail.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> <25e1aaa40910230404m4517c64ew2a04e610cc6f2bcd@mail.gmail.com> <D1DA2BB2-E064-4656-B75A-A10339A1B9FB@muada.com> <86F15BB9FC58443ABF2071A5CC843384@JiangXiong> <09be01ca5660$7a1de870$c5f0200a@cisco.com> <25e1aaa40910262003u3779279fxa614487c9d304f87@mail.gmail.com> Date: Thu, 29 Oct 2009 09:52:43 -0700 Message-ID: <1d1901ca58b8$3c316fa0$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpWsgdKcBfeHUmVRsC/4T39Ztf4bgCBOmtw In-Reply-To: <25e1aaa40910262003u3779279fxa614487c9d304f87@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: shengjiang@huawei.com, behave@ietf.org, =?GB2312?B?J8H1tPPF9Cc=?= <liudapeng@chinamobile.com>, 'bo zhou' <zhouboyj@gmail.com>, =?GB2312?B?J7Lc1fEn?= <caozhen@chinamobile.com>, 'Behave Chairs' <behave-chairs@tools.ietf.org> Subject: [BEHAVE] draft-van-beijnum-behave-ftp64-06 and PASV retrying [was Re: adopt draft-van-beijnum-behave-ftp64-06] 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, 29 Oct 2009 16:52:29 -0000 =20 (sorry to come back to this Monday post, but I wanted to follow up on = this specific email.) > -----Original Message----- > From: liu dapeng [mailto:maxpassion@gmail.com]=20 > Sent: Monday, October 26, 2009 8:03 PM > To: Dan Wing > Cc: shengjiang@huawei.com; Iljitsch van Beijnum; =C1=F5=B4=F3=C5=F4; = =B2=DC=D5=F1;=20 > behave@ietf.org; Behave Chairs; bo zhou > Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06=20 > as WG item >=20 > Hi Dan, >=20 > We updated the ftp64 draft: > http://tools.ietf.org/html/draft-liu-behave-ftp64-04. > As you mentioned, attitude toward FTP ALG is one of the ideas that > merged by draft-van-beijnum-behave-ftp64-06.txt; Furthermore, the > handling of FTP client when retrying with PASV command is another > important idea that merged by draft-van-beijnum-behave-ftp64-06.txt. specific text was not cited so I can only guess that you are referring = to this text, Based on the survey, this document recommends that all FTP servers and client implement EPSV and that IPv6 FTP clients are updated to retry with PASV when EPSV fails under the assumptiont that they are communicating through an IPv6-to-IPv4 translator. which originally appeared in http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-03, published = May 19. http://tools.ietf.org/html/draft-liu-behave-ftp64-00 was published = August 19. Was there an earlier email where you had suggested that FTP servers = retry with PASV when EPSV fails? > The original handling method will cause problems and probably does not > work. Please substantiate how/where it would break, with details. I have run = tests against public IPv4 FTP servers, published the results of those tests to BEHAVE, and made Perl code available so others could repeat the tests. = It's all at ftp://ftpeng.cisco.com/dwing/ftp-epsv. -d > We believe that draft-van-beijnum-behave-ftp64-06 still need=20 > more improvement, > so we upgrade draft-liu-behave-ftp64-04 to reflect our thoughts more > precisely. We would like the WG to review and comments on this draft > and to see whether it is more suitable to be the working foundation to > further proceed the ftp64 issue in IPv6 transition scenario. If it is > convenient, we would like to present it in the coming meeting(5-10 > minutes). Thanks for your comments and kindly help. > > BR, > Dapeng Liu >=20 > 2009/10/27, Dan Wing <dwing@cisco.com>: > > Looking at > >=20 > http://tools.ietf.org/rfcdiff?url2=3Ddraft-van-beijnum-behave-ft > p64-06.txt and > > reviewing draft-liu-behave-ftp64-03, I believe the change caused by > > draft-liu-behave-ftp64 was the new paragraph in Section 6, "ALG > > Functionality" > > starting with "On the other hand,". Is that correct? If=20 > that is all that > > was > > incorporated, it falls below my threshold for adding a=20 > second author, and > > rewording the Acknowledgements to better acknowledge the=20 > contribution seems > > adequate along the lines of "Dapeng Liu and Zhen Cao=20 > suggested that network > > operators encourage upgrading FTP clients rather than=20 > deploy an FTP ALG." > > > > -d > > > > > >> -----Original Message----- > >> From: Sheng Jiang [mailto:shengjiang@huawei.com] > >> Sent: Saturday, October 24, 2009 2:48 AM > >> To: 'Iljitsch van Beijnum'; 'liu dapeng' > >> Cc: '=C1=F5=B4=F3=C5=F4'; '=B2=DC=D5=F1'; behave@ietf.org; 'Behave = Chairs'; 'Dan > >> Wing'; 'Sheng Jiang' > >> Subject: RE: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 > >> as WG item > >> > >> Hi, > >> > >> I support to adopt the draft as WG documentation. > >> > >> However, the author wrote in the draft: =A1=B0Versions -05 and=20 > -06 of this > >> document adopts several important design decisions from > >> [I-D.liu-behave-ftp64].=A1=B1 Should at least one author from > >> draft-liu-behave-ftp64 deserve to be co-author of this > >> draft-van-beijnum-behave-ftp64? > >> > >> Best wishes, > >> > >> Sheng > >> > >> > -----Original Message----- > >> > From: behave-bounces@ietf.org > >> [mailto:behave-bounces@ietf.org] On Behalf > >> Of > >> > Iljitsch van Beijnum > >> > Sent: Friday, October 23, 2009 7:11 PM > >> > To: liu dapeng > >> > Cc: =C1=F5=B4=F3=C5=F4; =B2=DC=D5=F1; behave@ietf.org; Behave = Chairs; Dan Wing > >> > Subject: Re: [BEHAVE] adopt > >> draft-van-beijnum-behave-ftp64-06 as WG item > >> > > >> > On 23 okt 2009, at 13:04, liu dapeng wrote: > >> > > >> > > We know that there are two drafts discussing the ftp64 > >> issue. Would > >> > > the WG consider merging draft-van-beijnum-behave-ftp64 and > >> > > draft-liu-behave-ftp64 as the WG document? > >> > > >> > Do you feel the current text in draft-van-beijnum-behave-ftp64-06 > >> > doesn't address your previous objections? > >> > _______________________________________________ > >> > Behave mailing list > >> > Behave@ietf.org > >> > https://www.ietf.org/mailman/listinfo/behave > >> > > > > >=20 From maxpassion@gmail.com Thu Oct 29 10:16:08 2009 Return-Path: <maxpassion@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 80FF83A68AA for <behave@core3.amsl.com>; Thu, 29 Oct 2009 10:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[AWL=-1.072, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfSUluivCMOb for <behave@core3.amsl.com>; Thu, 29 Oct 2009 10:16:07 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id 741783A6882 for <behave@ietf.org>; Thu, 29 Oct 2009 10:16:07 -0700 (PDT) Received: by pzk42 with SMTP id 42so1584148pzk.31 for <behave@ietf.org>; Thu, 29 Oct 2009 10:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Og7nxzMk9JrERODSdFbSDSGHGJobHDj92vXa+CavVgg=; b=qBZflGUqTGzCWmpv4FbT4WD8tqsWgJUWhnqs52CcL/PR1g2IknB5/ihSRrGCyBpA7E AljEIYrPKAgKh03sl8qb55/X40p6lafbzbn1tX4draTYknDSBCa9Sba/ZRHhnFh4r8rh tUzdYgzKzrdiSf8oqh7RZ9HML237ROxnZe+rc= 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=JHWfzL43dy9ETPyhsDhH+EFJjnBayL4mXReoACaw7zef+zRMYqtq/pj8vIy4BJEYSk zsjPnjLVMTnYihqqZ9WfaacBNiZthcPCWM0EKdvZDjub/djtAq3jHYC7eBYCNVev+WWx LTfzI0iyyO4nG57v68DAQT9jf8tBC2nTyPNCE= MIME-Version: 1.0 Received: by 10.142.59.20 with SMTP id h20mr28691wfa.279.1256836580947; Thu, 29 Oct 2009 10:16:20 -0700 (PDT) In-Reply-To: <1d1901ca58b8$3c316fa0$c5f0200a@cisco.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> <25e1aaa40910230404m4517c64ew2a04e610cc6f2bcd@mail.gmail.com> <D1DA2BB2-E064-4656-B75A-A10339A1B9FB@muada.com> <86F15BB9FC58443ABF2071A5CC843384@JiangXiong> <09be01ca5660$7a1de870$c5f0200a@cisco.com> <25e1aaa40910262003u3779279fxa614487c9d304f87@mail.gmail.com> <1d1901ca58b8$3c316fa0$c5f0200a@cisco.com> Date: Fri, 30 Oct 2009 01:16:20 +0800 Message-ID: <25e1aaa40910291016y75b64232w608d17ba41469d06@mail.gmail.com> From: liu dapeng <maxpassion@gmail.com> To: Dan Wing <dwing@cisco.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: shengjiang@huawei.com, behave@ietf.org, =?GB2312?B?wfW088X0?= <liudapeng@chinamobile.com>, =?GB2312?B?stzV8Q==?= <caozhen@chinamobile.com>, bo zhou <zhouboyj@gmail.com>, Behave Chairs <behave-chairs@tools.ietf.org> Subject: Re: [BEHAVE] draft-van-beijnum-behave-ftp64-06 and PASV retrying [was Re: adopt draft-van-beijnum-behave-ftp64-06] 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, 29 Oct 2009 17:16:08 -0000 Hi, Dan thanks for the discussion, please see inline. 2009/10/30, Dan Wing <dwing@cisco.com>: > > (sorry to come back to this Monday post, but I wanted to follow up on thi= s > specific email.) > >> -----Original Message----- >> From: liu dapeng [mailto:maxpassion@gmail.com] >> Sent: Monday, October 26, 2009 8:03 PM >> To: Dan Wing >> Cc: shengjiang@huawei.com; Iljitsch van Beijnum; =C1=F5=B4=F3=C5=F4; =B2= =DC=D5=F1; >> behave@ietf.org; Behave Chairs; bo zhou >> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 >> as WG item >> >> Hi Dan, >> >> We updated the ftp64 draft: >> http://tools.ietf.org/html/draft-liu-behave-ftp64-04. >> As you mentioned, attitude toward FTP ALG is one of the ideas that >> merged by draft-van-beijnum-behave-ftp64-06.txt; Furthermore, the >> handling of FTP client when retrying with PASV command is another >> important idea that merged by draft-van-beijnum-behave-ftp64-06.txt. > > specific text was not cited so I can only guess that you are referring to > this > text, > > Based on the survey, this document recommends that all FTP servers > and client implement EPSV and that IPv6 FTP clients are updated to > retry with PASV when EPSV fails under the assumptiont that they are > communicating through an IPv6-to-IPv4 translator. > > which originally appeared in > http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-03, published M= ay > 19. http://tools.ietf.org/html/draft-liu-behave-ftp64-00 was published > August > 19. Was there an earlier email where you had suggested that FTP servers > retry > with PASV when EPSV fails? > >> The original handling method will cause problems and probably does not >> work. > > Please substantiate how/where it would break, with details. I have run > tests > against public IPv4 FTP servers, published the results of those tests to > BEHAVE, and made Perl code available so others could repeat the tests. I= t's > all at ftp://ftpeng.cisco.com/dwing/ftp-epsv. Actually, I mean the using of only control connection's IP address to establish data connection when retry with PASV and gets a response from server. The original document propose the client to test whether to have IPv4 connection, if it has IPv4 connection, then it recommends to use its IPv4 address to make the data connection. This may have potential problems as we discussed before: If the client has an private IPv4 connection it will not succeed using it to make the data connection. BR, Dapeng > -d > >> We believe that draft-van-beijnum-behave-ftp64-06 still need >> more improvement, >> so we upgrade draft-liu-behave-ftp64-04 to reflect our thoughts more >> precisely. We would like the WG to review and comments on this draft >> and to see whether it is more suitable to be the working foundation to >> further proceed the ftp64 issue in IPv6 transition scenario. If it is >> convenient, we would like to present it in the coming meeting(5-10 >> minutes). Thanks for your comments and kindly help. >> >> BR, >> Dapeng Liu >> >> 2009/10/27, Dan Wing <dwing@cisco.com>: >> > Looking at >> > >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-van-beijnum-behave-ft >> p64-06.txt and >> > reviewing draft-liu-behave-ftp64-03, I believe the change caused by >> > draft-liu-behave-ftp64 was the new paragraph in Section 6, "ALG >> > Functionality" >> > starting with "On the other hand,". Is that correct? If >> that is all that >> > was >> > incorporated, it falls below my threshold for adding a >> second author, and >> > rewording the Acknowledgements to better acknowledge the >> contribution seems >> > adequate along the lines of "Dapeng Liu and Zhen Cao >> suggested that network >> > operators encourage upgrading FTP clients rather than >> deploy an FTP ALG." >> > >> > -d >> > >> > >> >> -----Original Message----- >> >> From: Sheng Jiang [mailto:shengjiang@huawei.com] >> >> Sent: Saturday, October 24, 2009 2:48 AM >> >> To: 'Iljitsch van Beijnum'; 'liu dapeng' >> >> Cc: '=C1=F5=B4=F3=C5=F4'; '=B2=DC=D5=F1'; behave@ietf.org; 'Behave Ch= airs'; 'Dan >> >> Wing'; 'Sheng Jiang' >> >> Subject: RE: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 >> >> as WG item >> >> >> >> Hi, >> >> >> >> I support to adopt the draft as WG documentation. >> >> >> >> However, the author wrote in the draft: =A1=B0Versions -05 and >> -06 of this >> >> document adopts several important design decisions from >> >> [I-D.liu-behave-ftp64].=A1=B1 Should at least one author from >> >> draft-liu-behave-ftp64 deserve to be co-author of this >> >> draft-van-beijnum-behave-ftp64? >> >> >> >> Best wishes, >> >> >> >> Sheng >> >> >> >> > -----Original Message----- >> >> > From: behave-bounces@ietf.org >> >> [mailto:behave-bounces@ietf.org] On Behalf >> >> Of >> >> > Iljitsch van Beijnum >> >> > Sent: Friday, October 23, 2009 7:11 PM >> >> > To: liu dapeng >> >> > Cc: =C1=F5=B4=F3=C5=F4; =B2=DC=D5=F1; behave@ietf.org; Behave Chair= s; Dan Wing >> >> > Subject: Re: [BEHAVE] adopt >> >> draft-van-beijnum-behave-ftp64-06 as WG item >> >> > >> >> > On 23 okt 2009, at 13:04, liu dapeng wrote: >> >> > >> >> > > We know that there are two drafts discussing the ftp64 >> >> issue. Would >> >> > > the WG consider merging draft-van-beijnum-behave-ftp64 and >> >> > > draft-liu-behave-ftp64 as the WG document? >> >> > >> >> > Do you feel the current text in draft-van-beijnum-behave-ftp64-06 >> >> > doesn't address your previous objections? >> >> > _______________________________________________ >> >> > 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 maxpassion@gmail.com Thu Oct 29 10:34:22 2009 Return-Path: <maxpassion@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 95C4F3A68BF for <behave@core3.amsl.com>; Thu, 29 Oct 2009 10:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[AWL=-0.953, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsgQcN8BwyLs for <behave@core3.amsl.com>; Thu, 29 Oct 2009 10:34:17 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id 9B5863A67B5 for <behave@ietf.org>; Thu, 29 Oct 2009 10:34:17 -0700 (PDT) Received: by pzk42 with SMTP id 42so1597123pzk.31 for <behave@ietf.org>; Thu, 29 Oct 2009 10:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RyDdWlrlNUOrNS1KQCU3KEpetsgkFUjCf9yRJu484jQ=; b=vTtJ7kAziKQfyfD95kCwM23uFcQVEaQnGaDAnQz9TFY5+W0QJi+VkR1KDHlD84sNgR HoUSGKOqXaa/ga1aUiBOC9Z34sGx6IwuYiKfIxs5JoKTFMOAEnJM78g2Fjme6Ko3AsAW ExYQmxRm4CeMx1arhTGDjuGyT63EWbaRtYi+s= 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=lUS165lBDzCBU0mYQNPn6+h7NnDK98OZc+CcdoxXEBcWDh3hp2TLyF8H/9Q+TyNw/S 1DwvJI/9vdRAgJv5JH4whZYd+62lmd4dMnc+8ud6UI21Ypz3tjF0IUbWxpDh+GGJeQ/c OSk9i48GlcW9muAur0LiQqcp0jmg3TCF5k8IA= MIME-Version: 1.0 Received: by 10.142.3.37 with SMTP id 37mr32431wfc.146.1256837673275; Thu, 29 Oct 2009 10:34:33 -0700 (PDT) In-Reply-To: <1d1901ca58b8$3c316fa0$c5f0200a@cisco.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> <25e1aaa40910230404m4517c64ew2a04e610cc6f2bcd@mail.gmail.com> <D1DA2BB2-E064-4656-B75A-A10339A1B9FB@muada.com> <86F15BB9FC58443ABF2071A5CC843384@JiangXiong> <09be01ca5660$7a1de870$c5f0200a@cisco.com> <25e1aaa40910262003u3779279fxa614487c9d304f87@mail.gmail.com> <1d1901ca58b8$3c316fa0$c5f0200a@cisco.com> Date: Fri, 30 Oct 2009 01:34:33 +0800 Message-ID: <25e1aaa40910291034u15f5d401g66198eb32695a133@mail.gmail.com> From: liu dapeng <maxpassion@gmail.com> To: Dan Wing <dwing@cisco.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: shengjiang@huawei.com, behave@ietf.org, =?GB2312?B?wfW088X0?= <liudapeng@chinamobile.com>, =?GB2312?B?stzV8Q==?= <caozhen@chinamobile.com>, bo zhou <zhouboyj@gmail.com>, Behave Chairs <behave-chairs@tools.ietf.org> Subject: Re: [BEHAVE] draft-van-beijnum-behave-ftp64-06 and PASV retrying [was Re: adopt draft-van-beijnum-behave-ftp64-06] 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, 29 Oct 2009 17:34:22 -0000 Hi Dan, 2009/10/30, Dan Wing <dwing@cisco.com>: > > (sorry to come back to this Monday post, but I wanted to follow up on thi= s > specific email.) > >> -----Original Message----- >> From: liu dapeng [mailto:maxpassion@gmail.com] >> Sent: Monday, October 26, 2009 8:03 PM >> To: Dan Wing >> Cc: shengjiang@huawei.com; Iljitsch van Beijnum; =C1=F5=B4=F3=C5=F4; =B2= =DC=D5=F1; >> behave@ietf.org; Behave Chairs; bo zhou >> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 >> as WG item >> >> Hi Dan, >> >> We updated the ftp64 draft: >> http://tools.ietf.org/html/draft-liu-behave-ftp64-04. >> As you mentioned, attitude toward FTP ALG is one of the ideas that >> merged by draft-van-beijnum-behave-ftp64-06.txt; Furthermore, the >> handling of FTP client when retrying with PASV command is another >> important idea that merged by draft-van-beijnum-behave-ftp64-06.txt. > > specific text was not cited so I can only guess that you are referring to > this > text, > > Based on the survey, this document recommends that all FTP servers > and client implement EPSV and that IPv6 FTP clients are updated to > retry with PASV when EPSV fails under the assumptiont that they are > communicating through an IPv6-to-IPv4 translator. > > which originally appeared in > http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-03, published M= ay > 19. http://tools.ietf.org/html/draft-liu-behave-ftp64-00 was published > August > 19. Was there an earlier email where you had suggested that FTP servers > retry > with PASV when EPSV fails? > >> The original handling method will cause problems and probably does not >> work. > > Please substantiate how/where it would break, with details. I have run > tests > against public IPv4 FTP servers, published the results of those tests to > BEHAVE, and made Perl code available so others could repeat the tests. I= t's > all at ftp://ftpeng.cisco.com/dwing/ftp-epsv. > > -d It reminds me that there is another issue that we are not very clearly: when trying with EPSV command, it may result to a long delay from the server. according to previous discussion we guess that it may caused by the middle box that does not handling the control channel correctly, but we can not make sure what exactly happening. Since we have CNGI (China Next Generation Internet, which is a wide area IPv6 test network) and also have NAT-PT deployed, I am happy to make an experiment to see what exactly happening. If it is needed, I can also implement an IPv6 FTP client running code which complies with the ftp64 document to see whether this solution could really work properly and to see whether there is other issues that have not been identified. BR, Dapeng >> We believe that draft-van-beijnum-behave-ftp64-06 still need >> more improvement, >> so we upgrade draft-liu-behave-ftp64-04 to reflect our thoughts more >> precisely. We would like the WG to review and comments on this draft >> and to see whether it is more suitable to be the working foundation to >> further proceed the ftp64 issue in IPv6 transition scenario. If it is >> convenient, we would like to present it in the coming meeting(5-10 >> minutes). Thanks for your comments and kindly help. >> >> BR, >> Dapeng Liu >> >> 2009/10/27, Dan Wing <dwing@cisco.com>: >> > Looking at >> > >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-van-beijnum-behave-ft >> p64-06.txt and >> > reviewing draft-liu-behave-ftp64-03, I believe the change caused by >> > draft-liu-behave-ftp64 was the new paragraph in Section 6, "ALG >> > Functionality" >> > starting with "On the other hand,". Is that correct? If >> that is all that >> > was >> > incorporated, it falls below my threshold for adding a >> second author, and >> > rewording the Acknowledgements to better acknowledge the >> contribution seems >> > adequate along the lines of "Dapeng Liu and Zhen Cao >> suggested that network >> > operators encourage upgrading FTP clients rather than >> deploy an FTP ALG." >> > >> > -d >> > >> > >> >> -----Original Message----- >> >> From: Sheng Jiang [mailto:shengjiang@huawei.com] >> >> Sent: Saturday, October 24, 2009 2:48 AM >> >> To: 'Iljitsch van Beijnum'; 'liu dapeng' >> >> Cc: '=C1=F5=B4=F3=C5=F4'; '=B2=DC=D5=F1'; behave@ietf.org; 'Behave Ch= airs'; 'Dan >> >> Wing'; 'Sheng Jiang' >> >> Subject: RE: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 >> >> as WG item >> >> >> >> Hi, >> >> >> >> I support to adopt the draft as WG documentation. >> >> >> >> However, the author wrote in the draft: =A1=B0Versions -05 and >> -06 of this >> >> document adopts several important design decisions from >> >> [I-D.liu-behave-ftp64].=A1=B1 Should at least one author from >> >> draft-liu-behave-ftp64 deserve to be co-author of this >> >> draft-van-beijnum-behave-ftp64? >> >> >> >> Best wishes, >> >> >> >> Sheng >> >> >> >> > -----Original Message----- >> >> > From: behave-bounces@ietf.org >> >> [mailto:behave-bounces@ietf.org] On Behalf >> >> Of >> >> > Iljitsch van Beijnum >> >> > Sent: Friday, October 23, 2009 7:11 PM >> >> > To: liu dapeng >> >> > Cc: =C1=F5=B4=F3=C5=F4; =B2=DC=D5=F1; behave@ietf.org; Behave Chair= s; Dan Wing >> >> > Subject: Re: [BEHAVE] adopt >> >> draft-van-beijnum-behave-ftp64-06 as WG item >> >> > >> >> > On 23 okt 2009, at 13:04, liu dapeng wrote: >> >> > >> >> > > We know that there are two drafts discussing the ftp64 >> >> issue. Would >> >> > > the WG consider merging draft-van-beijnum-behave-ftp64 and >> >> > > draft-liu-behave-ftp64 as the WG document? >> >> > >> >> > Do you feel the current text in draft-van-beijnum-behave-ftp64-06 >> >> > doesn't address your previous objections? >> >> > _______________________________________________ >> >> > 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 dwing@cisco.com Thu Oct 29 11:04:47 2009 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 6EE3C3A6841 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 11:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.087 X-Spam-Level: X-Spam-Status: No, score=-5.087 tagged_above=-999 required=5 tests=[AWL=-0.938, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJs-1g8nzia8 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 11:04:46 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 1A4B63A6835 for <behave@ietf.org>; Thu, 29 Oct 2009 11:04:46 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEEAKN26UqrR7H+/2dsb2JhbACEcoVtvDuHDAiRAYEugjhXBIFigQU X-IronPort-AV: E=Sophos;i="4.44,647,1249257600"; d="scan'208";a="199947641" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 29 Oct 2009 18:05:02 +0000 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9TI51x4018643; Thu, 29 Oct 2009 18:05:02 GMT From: "Dan Wing" <dwing@cisco.com> To: "'liu dapeng'" <maxpassion@gmail.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> <25e1aaa40910230404m4517c64ew2a04e610cc6f2bcd@mail.gmail.com> <D1DA2BB2-E064-4656-B75A-A10339A1B9FB@muada.com> <86F15BB9FC58443ABF2071A5CC843384@JiangXiong> <09be01ca5660$7a1de870$c5f0200a@cisco.com> <25e1aaa40910262003u3779279fxa614487c9d304f87@mail.gmail.com> <1d1901ca58b8$3c316fa0$c5f0200a@cisco.com> <25e1aaa40910291034u15f5d401g66198eb32695a133@mail.gmail.com> Date: Thu, 29 Oct 2009 11:05:01 -0700 Message-ID: <1d9901ca58c2$5600e780$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpYvhOjdCN2BD9ZQgOhOBCx3urfnwAA4ylA In-Reply-To: <25e1aaa40910291034u15f5d401g66198eb32695a133@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: shengjiang@huawei.com, behave@ietf.org, =?GB2312?B?J8H1tPPF9Cc=?= <liudapeng@chinamobile.com>, =?GB2312?B?J7Lc1fEn?= <caozhen@chinamobile.com>, 'bo zhou' <zhouboyj@gmail.com>, 'Behave Chairs' <behave-chairs@tools.ietf.org> Subject: Re: [BEHAVE] draft-van-beijnum-behave-ftp64-06 and PASV retrying [was Re: adopt draft-van-beijnum-behave-ftp64-06] 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, 29 Oct 2009 18:04:47 -0000 =20 > -----Original Message----- > From: liu dapeng [mailto:maxpassion@gmail.com]=20 > Sent: Thursday, October 29, 2009 10:35 AM > To: Dan Wing > Cc: shengjiang@huawei.com; behave@ietf.org; =C1=F5=B4=F3=C5=F4; bo = zhou; =B2=DC=D5=F1;=20 > Behave Chairs > Subject: Re: [BEHAVE] draft-van-beijnum-behave-ftp64-06 and=20 > PASV retrying [was Re: adopt draft-van-beijnum-behave-ftp64-06] >=20 > Hi Dan, >=20 > 2009/10/30, Dan Wing <dwing@cisco.com>: > > > > (sorry to come back to this Monday post, but I wanted to=20 > follow up on this > > specific email.) > > > >> -----Original Message----- > >> From: liu dapeng [mailto:maxpassion@gmail.com] > >> Sent: Monday, October 26, 2009 8:03 PM > >> To: Dan Wing > >> Cc: shengjiang@huawei.com; Iljitsch van Beijnum; = =C1=F5=B4=F3=C5=F4; =B2=DC=D5=F1; > >> behave@ietf.org; Behave Chairs; bo zhou > >> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 > >> as WG item > >> > >> Hi Dan, > >> > >> We updated the ftp64 draft: > >> http://tools.ietf.org/html/draft-liu-behave-ftp64-04. > >> As you mentioned, attitude toward FTP ALG is one of the ideas that > >> merged by draft-van-beijnum-behave-ftp64-06.txt; Furthermore, the > >> handling of FTP client when retrying with PASV command is another > >> important idea that merged by=20 > draft-van-beijnum-behave-ftp64-06.txt. > > > > specific text was not cited so I can only guess that you=20 > are referring to > > this > > text, > > > > Based on the survey, this document recommends that all=20 > FTP servers > > and client implement EPSV and that IPv6 FTP clients are=20 > updated to > > retry with PASV when EPSV fails under the assumptiont=20 > that they are > > communicating through an IPv6-to-IPv4 translator. > > > > which originally appeared in > >=20 > http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-03,=20 > published May > > 19. http://tools.ietf.org/html/draft-liu-behave-ftp64-00=20 > was published > > August > > 19. Was there an earlier email where you had suggested=20 > that FTP servers > > retry > > with PASV when EPSV fails? You didn't answer that question. > >> The original handling method will cause problems and=20 > probably does not > >> work. > > > > Please substantiate how/where it would break, with details.=20 > I have run > > tests > > against public IPv4 FTP servers, published the results of=20 > those tests to > > BEHAVE, and made Perl code available so others could repeat=20 > the tests. It's > > all at ftp://ftpeng.cisco.com/dwing/ftp-epsv. > > > > -d >=20 > It reminds me that there is another issue that we are not=20 > very clearly: >=20 > when trying with EPSV command, it may result to a long delay from the > server. according to previous discussion we guess that it may caused > by the middle box that does not handling the control channel > correctly, but we can not make sure what exactly happening. Since we > have CNGI (China Next Generation Internet, which is a wide area IPv6 > test network) and also have NAT-PT deployed, I am happy to make an > experiment to see what exactly happening. If it is needed, I can also > implement an IPv6 FTP client running code which complies with the > ftp64 document to see whether this solution could really work properly > and to see whether there is other issues that have not been > identified. I still don't understand. You had written "The original handling method = will cause problems and=20 probably does not work." What, specifically, was the "original handling method", and what, specifically, is your fix? Testing is easy, just use the Perl code that I have provided to the = community. EPSV doesn't work with ftp.dell.com and times out: > perl ftp-epsv.pl ftp.dell.com ftp.dell.com PASV: Ok EPSV: Timeout 00:22 That has been known since I posted the results of my testing and = Iljitsch incorporated text into http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-03. -d > BR, > Dapeng >=20 > >> We believe that draft-van-beijnum-behave-ftp64-06 still need > >> more improvement, > >> so we upgrade draft-liu-behave-ftp64-04 to reflect our=20 > thoughts more > >> precisely. We would like the WG to review and comments on=20 > this draft > >> and to see whether it is more suitable to be the working=20 > foundation to > >> further proceed the ftp64 issue in IPv6 transition=20 > scenario. If it is > >> convenient, we would like to present it in the coming meeting(5-10 > >> minutes). Thanks for your comments and kindly help. > >> > >> BR, > >> Dapeng Liu > >> > >> 2009/10/27, Dan Wing <dwing@cisco.com>: > >> > Looking at > >> > > >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-van-beijnum-behave-ft > >> p64-06.txt and > >> > reviewing draft-liu-behave-ftp64-03, I believe the=20 > change caused by > >> > draft-liu-behave-ftp64 was the new paragraph in Section 6, "ALG > >> > Functionality" > >> > starting with "On the other hand,". Is that correct? If > >> that is all that > >> > was > >> > incorporated, it falls below my threshold for adding a > >> second author, and > >> > rewording the Acknowledgements to better acknowledge the > >> contribution seems > >> > adequate along the lines of "Dapeng Liu and Zhen Cao > >> suggested that network > >> > operators encourage upgrading FTP clients rather than > >> deploy an FTP ALG." > >> > > >> > -d > >> > > >> > > >> >> -----Original Message----- > >> >> From: Sheng Jiang [mailto:shengjiang@huawei.com] > >> >> Sent: Saturday, October 24, 2009 2:48 AM > >> >> To: 'Iljitsch van Beijnum'; 'liu dapeng' > >> >> Cc: '=C1=F5=B4=F3=C5=F4'; '=B2=DC=D5=F1'; behave@ietf.org; = 'Behave Chairs'; 'Dan > >> >> Wing'; 'Sheng Jiang' > >> >> Subject: RE: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 > >> >> as WG item > >> >> > >> >> Hi, > >> >> > >> >> I support to adopt the draft as WG documentation. > >> >> > >> >> However, the author wrote in the draft: =A1=B0Versions -05 and > >> -06 of this > >> >> document adopts several important design decisions from > >> >> [I-D.liu-behave-ftp64].=A1=B1 Should at least one author from > >> >> draft-liu-behave-ftp64 deserve to be co-author of this > >> >> draft-van-beijnum-behave-ftp64? > >> >> > >> >> Best wishes, > >> >> > >> >> Sheng > >> >> > >> >> > -----Original Message----- > >> >> > From: behave-bounces@ietf.org > >> >> [mailto:behave-bounces@ietf.org] On Behalf > >> >> Of > >> >> > Iljitsch van Beijnum > >> >> > Sent: Friday, October 23, 2009 7:11 PM > >> >> > To: liu dapeng > >> >> > Cc: =C1=F5=B4=F3=C5=F4; =B2=DC=D5=F1; behave@ietf.org; Behave = Chairs; Dan Wing > >> >> > Subject: Re: [BEHAVE] adopt > >> >> draft-van-beijnum-behave-ftp64-06 as WG item > >> >> > > >> >> > On 23 okt 2009, at 13:04, liu dapeng wrote: > >> >> > > >> >> > > We know that there are two drafts discussing the ftp64 > >> >> issue. Would > >> >> > > the WG consider merging draft-van-beijnum-behave-ftp64 and > >> >> > > draft-liu-behave-ftp64 as the WG document? > >> >> > > >> >> > Do you feel the current text in=20 > draft-van-beijnum-behave-ftp64-06 > >> >> > doesn't address your previous objections? > >> >> > _______________________________________________ > >> >> > 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 maxpassion@gmail.com Thu Oct 29 11:36:00 2009 Return-Path: <maxpassion@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 D4E6E3A69B2 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 11:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.006 X-Spam-Level: X-Spam-Status: No, score=-1.006 tagged_above=-999 required=5 tests=[AWL=-0.858, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p234+4F8EJhE for <behave@core3.amsl.com>; Thu, 29 Oct 2009 11:35:59 -0700 (PDT) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 54BC53A685E for <behave@ietf.org>; Thu, 29 Oct 2009 11:35:59 -0700 (PDT) Received: by pwi4 with SMTP id 4so222748pwi.29 for <behave@ietf.org>; Thu, 29 Oct 2009 11:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QBi6XIk8/qFNsr5Fr2EbljyFQQ3PSMHbiTaFh7Deows=; b=cvX3Yd0dqz6GCS80TDc+DzNKkhKF6PqW1lJM1Rvhm+RTb8Qb+PAsr6jrVBwq/4A3R/ WWY1atgRfA9+QJf1G0dSZk224BR/CwLwWl8J6ZUkFZGNeTrpJMKCbctpmAMvcPtNK5Tl Q/39UUHJK2/a6qb8f3dc0ypmUtRR+ijdE/sCE= 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=AgS7F6crD4Qf4vuY8irdQahDmFj2qY3qaXiQRwlSXSbJwsRw8dfC3UZd6WYxPAWdUj hOurn//zM14rS9cPhR8y5aHOB7BCBi1C8ZAi36n87b7sghHawyGSVZQJNCcui0oUtJEw NJWDCK06+MsafofA85IV02ya5UgBqXWMxbcF4= MIME-Version: 1.0 Received: by 10.142.75.10 with SMTP id x10mr37032wfa.153.1256841372512; Thu, 29 Oct 2009 11:36:12 -0700 (PDT) In-Reply-To: <1d9901ca58c2$5600e780$c5f0200a@cisco.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> <25e1aaa40910230404m4517c64ew2a04e610cc6f2bcd@mail.gmail.com> <D1DA2BB2-E064-4656-B75A-A10339A1B9FB@muada.com> <86F15BB9FC58443ABF2071A5CC843384@JiangXiong> <09be01ca5660$7a1de870$c5f0200a@cisco.com> <25e1aaa40910262003u3779279fxa614487c9d304f87@mail.gmail.com> <1d1901ca58b8$3c316fa0$c5f0200a@cisco.com> <25e1aaa40910291034u15f5d401g66198eb32695a133@mail.gmail.com> <1d9901ca58c2$5600e780$c5f0200a@cisco.com> Date: Fri, 30 Oct 2009 02:36:12 +0800 Message-ID: <25e1aaa40910291136q5723bf2dk7e29067077b2779c@mail.gmail.com> From: liu dapeng <maxpassion@gmail.com> To: Dan Wing <dwing@cisco.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: shengjiang@huawei.com, behave@ietf.org, =?GB2312?B?wfW088X0?= <liudapeng@chinamobile.com>, =?GB2312?B?stzV8Q==?= <caozhen@chinamobile.com>, bo zhou <zhouboyj@gmail.com>, Behave Chairs <behave-chairs@tools.ietf.org> Subject: Re: [BEHAVE] draft-van-beijnum-behave-ftp64-06 and PASV retrying [was Re: adopt draft-van-beijnum-behave-ftp64-06] 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, 29 Oct 2009 18:36:00 -0000 Hi Dan, Thanks for the discussion, I guess I reply your question in the previous mail... anyway, please see inline below. 2009/10/30, Dan Wing <dwing@cisco.com>: > > >> -----Original Message----- >> From: liu dapeng [mailto:maxpassion@gmail.com] >> Sent: Thursday, October 29, 2009 10:35 AM >> To: Dan Wing >> Cc: shengjiang@huawei.com; behave@ietf.org; =C1=F5=B4=F3=C5=F4; bo zhou;= =B2=DC=D5=F1; >> Behave Chairs >> Subject: Re: [BEHAVE] draft-van-beijnum-behave-ftp64-06 and >> PASV retrying [was Re: adopt draft-van-beijnum-behave-ftp64-06] >> >> Hi Dan, >> >> 2009/10/30, Dan Wing <dwing@cisco.com>: >> > >> > (sorry to come back to this Monday post, but I wanted to >> follow up on this >> > specific email.) >> > >> >> -----Original Message----- >> >> From: liu dapeng [mailto:maxpassion@gmail.com] >> >> Sent: Monday, October 26, 2009 8:03 PM >> >> To: Dan Wing >> >> Cc: shengjiang@huawei.com; Iljitsch van Beijnum; =C1=F5=B4=F3=C5=F4; = =B2=DC=D5=F1; >> >> behave@ietf.org; Behave Chairs; bo zhou >> >> Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 >> >> as WG item >> >> >> >> Hi Dan, >> >> >> >> We updated the ftp64 draft: >> >> http://tools.ietf.org/html/draft-liu-behave-ftp64-04. >> >> As you mentioned, attitude toward FTP ALG is one of the ideas that >> >> merged by draft-van-beijnum-behave-ftp64-06.txt; Furthermore, the >> >> handling of FTP client when retrying with PASV command is another >> >> important idea that merged by >> draft-van-beijnum-behave-ftp64-06.txt. >> > >> > specific text was not cited so I can only guess that you >> are referring to >> > this >> > text, >> > >> > Based on the survey, this document recommends that all >> FTP servers >> > and client implement EPSV and that IPv6 FTP clients are >> updated to >> > retry with PASV when EPSV fails under the assumptiont >> that they are >> > communicating through an IPv6-to-IPv4 translator. >> > >> > which originally appeared in >> > >> http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-03, >> published May >> > 19. http://tools.ietf.org/html/draft-liu-behave-ftp64-00 >> was published >> > August >> > 19. Was there an earlier email where you had suggested >> that FTP servers >> > retry >> > with PASV when EPSV fails? > > You didn't answer that question. Actually, I mean the using of only control connection's IP address to establish data connection when retry with PASV and gets a response from server. The original document propose the client to test whether to have IPv4 connection, if it has IPv4 connection, then it recommends to use its IPv4 address to make the data connection. This may have potential problems as we discussed before: If the client has an private IPv4 connection it will not succeed using it to make the data connection. the email discussion is: http://www.ietf.org/mail-archive/web/behave/current/msg06210.html >> >> The original handling method will cause problems and >> probably does not >> >> work. >> > >> > Please substantiate how/where it would break, with details. >> I have run >> > tests >> > against public IPv4 FTP servers, published the results of >> those tests to >> > BEHAVE, and made Perl code available so others could repeat >> the tests. It's >> > all at ftp://ftpeng.cisco.com/dwing/ftp-epsv. >> > >> > -d >> >> It reminds me that there is another issue that we are not >> very clearly: >> >> when trying with EPSV command, it may result to a long delay from the >> server. according to previous discussion we guess that it may caused >> by the middle box that does not handling the control channel >> correctly, but we can not make sure what exactly happening. Since we >> have CNGI (China Next Generation Internet, which is a wide area IPv6 >> test network) and also have NAT-PT deployed, I am happy to make an >> experiment to see what exactly happening. If it is needed, I can also >> implement an IPv6 FTP client running code which complies with the >> ftp64 document to see whether this solution could really work properly >> and to see whether there is other issues that have not been >> identified. > > I still don't understand. You had written "The original handling method > will > cause problems and > probably does not work." What, specifically, was the "original handling > method", and what, specifically, is your fix? The draft-van-beijnum-behave-ftp64-04 proposed that:"However, the server will respond to the PASV command with an IPv4 address that the client must use to connect to for the data connection. If the client has IPv4 reachability, it SHOULD set up a data connection towards the IPv4 address." This may have potential problems: If the client has an private IPv4 connection it will not succeed using it to make the data connection. > Testing is easy, just use the Perl code that I have provided to the > community. But since there is no NAT64 or NAT-PT in the network, is it better to write a IPv6 FTP client and with NAT64 or NAT-PT deployed in the IPv6 network to make sure the test is comply with the ftp64 document? > EPSV doesn't work with ftp.dell.com and times out: > > > perl ftp-epsv.pl ftp.dell.com > ftp.dell.com PASV: Ok EPSV: Timeout 00:22 > > That has been known since I posted the results of my testing and Iljitsch > incorporated text into > http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-03. Yes, I know that this issue has been identified long time before, but it seems that we do not know very clearly what exactly cause this problem, right? that is the motivation that I want to do the experiment. BR, Dapeng > -d > > >> BR, >> Dapeng >> >> >> We believe that draft-van-beijnum-behave-ftp64-06 still need >> >> more improvement, >> >> so we upgrade draft-liu-behave-ftp64-04 to reflect our >> thoughts more >> >> precisely. We would like the WG to review and comments on >> this draft >> >> and to see whether it is more suitable to be the working >> foundation to >> >> further proceed the ftp64 issue in IPv6 transition >> scenario. If it is >> >> convenient, we would like to present it in the coming meeting(5-10 >> >> minutes). Thanks for your comments and kindly help. >> >> >> >> BR, >> >> Dapeng Liu >> >> >> >> 2009/10/27, Dan Wing <dwing@cisco.com>: >> >> > Looking at >> >> > >> >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-van-beijnum-behave-ft >> >> p64-06.txt and >> >> > reviewing draft-liu-behave-ftp64-03, I believe the >> change caused by >> >> > draft-liu-behave-ftp64 was the new paragraph in Section 6, "ALG >> >> > Functionality" >> >> > starting with "On the other hand,". Is that correct? If >> >> that is all that >> >> > was >> >> > incorporated, it falls below my threshold for adding a >> >> second author, and >> >> > rewording the Acknowledgements to better acknowledge the >> >> contribution seems >> >> > adequate along the lines of "Dapeng Liu and Zhen Cao >> >> suggested that network >> >> > operators encourage upgrading FTP clients rather than >> >> deploy an FTP ALG." >> >> > >> >> > -d >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From: Sheng Jiang [mailto:shengjiang@huawei.com] >> >> >> Sent: Saturday, October 24, 2009 2:48 AM >> >> >> To: 'Iljitsch van Beijnum'; 'liu dapeng' >> >> >> Cc: '=C1=F5=B4=F3=C5=F4'; '=B2=DC=D5=F1'; behave@ietf.org; 'Behave= Chairs'; 'Dan >> >> >> Wing'; 'Sheng Jiang' >> >> >> Subject: RE: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 >> >> >> as WG item >> >> >> >> >> >> Hi, >> >> >> >> >> >> I support to adopt the draft as WG documentation. >> >> >> >> >> >> However, the author wrote in the draft: =A1=B0Versions -05 and >> >> -06 of this >> >> >> document adopts several important design decisions from >> >> >> [I-D.liu-behave-ftp64].=A1=B1 Should at least one author from >> >> >> draft-liu-behave-ftp64 deserve to be co-author of this >> >> >> draft-van-beijnum-behave-ftp64? >> >> >> >> >> >> Best wishes, >> >> >> >> >> >> Sheng >> >> >> >> >> >> > -----Original Message----- >> >> >> > From: behave-bounces@ietf.org >> >> >> [mailto:behave-bounces@ietf.org] On Behalf >> >> >> Of >> >> >> > Iljitsch van Beijnum >> >> >> > Sent: Friday, October 23, 2009 7:11 PM >> >> >> > To: liu dapeng >> >> >> > Cc: =C1=F5=B4=F3=C5=F4; =B2=DC=D5=F1; behave@ietf.org; Behave Ch= airs; Dan Wing >> >> >> > Subject: Re: [BEHAVE] adopt >> >> >> draft-van-beijnum-behave-ftp64-06 as WG item >> >> >> > >> >> >> > On 23 okt 2009, at 13:04, liu dapeng wrote: >> >> >> > >> >> >> > > We know that there are two drafts discussing the ftp64 >> >> >> issue. Would >> >> >> > > the WG consider merging draft-van-beijnum-behave-ftp64 and >> >> >> > > draft-liu-behave-ftp64 as the WG document? >> >> >> > >> >> >> > Do you feel the current text in >> draft-van-beijnum-behave-ftp64-06 >> >> >> > doesn't address your previous objections? >> >> >> > _______________________________________________ >> >> >> > 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 ajs@shinkuro.com Thu Oct 29 13:27:43 2009 Return-Path: <ajs@shinkuro.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 0D1433A6A65 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 13:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=0.598, 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 DSv8JfDy0oh2 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 13:27:42 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 3B0263A6A57 for <behave@ietf.org>; Thu, 29 Oct 2009 13:27:42 -0700 (PDT) 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 E5CE32FE8CDC for <behave@ietf.org>; Thu, 29 Oct 2009 20:27:57 +0000 (UTC) Date: Thu, 29 Oct 2009 16:27:56 -0400 From: Andrew Sullivan <ajs@shinkuro.com> To: behave@ietf.org Message-ID: <20091029202756.GP65688@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [BEHAVE] DNS64 and limiting data sharing across interfaces 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, 29 Oct 2009 20:27:43 -0000 Dear colleagues, The dns64-02 draft contains this text: 5.6. DNS64 and multihoming Synthetic AAAA records may be constructed on the basis of the network context in which they were constructed. Therefore, a synthetic AAAA received from one interface MUST NOT be used to resolve hosts via another network interface. Because it will be hard (if not impossible) for a multihomed system to tell whether a given AAAA is synthetic, a host SHOULD treat any AAAA record received on a given interface as local to that interface; the alternative risks communication failures when the AAAA is used to communicate on another interface. See the discussion in [I-D.savolainen-mif-dns-server-selection]. Off-list someone pointed out to me that there are cases where you have effectively dual-stack hosts for legacy reasons: the host is connected to the Internet via NAT64 but is talking to v4-only hosts in a local network or something. That reminded us that some v6-capable hosts use v4 only to do their DNS, which means that the only way such hosts are going to get DNS answers is on the v4-only interface. The above text, as written, appears to discourage such a practice. Does anyone have a better idea? I have been thinking about it, but I don't. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From simon.perreault@viagenie.ca Thu Oct 29 13:51:45 2009 Return-Path: <simon.perreault@viagenie.ca> 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 2F0663A694A for <behave@core3.amsl.com>; Thu, 29 Oct 2009 13:51:45 -0700 (PDT) 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 3cnstp9VooUC for <behave@core3.amsl.com>; Thu, 29 Oct 2009 13:51:44 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 62BAF3A6912 for <behave@ietf.org>; Thu, 29 Oct 2009 13:51:44 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id 1DBBA20E33 for <behave@ietf.org>; Thu, 29 Oct 2009 16:52:00 -0400 (EDT) Message-ID: <4AEA006F.30607@viagenie.ca> Date: Thu, 29 Oct 2009 16:51:59 -0400 From: Simon Perreault <simon.perreault@viagenie.ca> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4 MIME-Version: 1.0 To: behave@ietf.org References: <20091029202756.GP65688@shinkuro.com> In-Reply-To: <20091029202756.GP65688@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] DNS64 and limiting data sharing across interfaces 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, 29 Oct 2009 20:51:45 -0000 Andrew Sullivan wrote, on 2009-10-29 16:27: > Off-list someone pointed out to me that there are cases where you have > effectively dual-stack hosts for legacy reasons: the host is connected > to the Internet via NAT64 but is talking to v4-only hosts in a local > network or something. That reminded us that some v6-capable hosts use > v4 only to do their DNS, which means that the only way such hosts are > going to get DNS answers is on the v4-only interface. > > The above text, as written, appears to discourage such a practice. > > Does anyone have a better idea? I have been thinking about it, but I don't. Maybe we won't have a good answer until the MIF WG gives us one. Suggestion: Write the text according to the underlying principle and let operations decide what it means in practice. For example: Records synthesized by a DNS64 can only be used on a network where a NAT64 device is available and is configured with the same Pref64::/n as the DNS64. This principle is valid in all cases. But it doesn't tell exactly how to enforce it. That's probably the best advice we can give right now. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From ajs@shinkuro.com Thu Oct 29 14:02:37 2009 Return-Path: <ajs@shinkuro.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 335EF3A6995 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 14:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=0.581, 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 lFfOluzpcgee for <behave@core3.amsl.com>; Thu, 29 Oct 2009 14:02:36 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 55FEC3A68E7 for <behave@ietf.org>; Thu, 29 Oct 2009 14:02:36 -0700 (PDT) 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 538672FE8CDC for <behave@ietf.org>; Thu, 29 Oct 2009 21:02:52 +0000 (UTC) Date: Thu, 29 Oct 2009 17:02:50 -0400 From: Andrew Sullivan <ajs@shinkuro.com> To: behave@ietf.org Message-ID: <20091029210250.GS65688@shinkuro.com> References: <20091029202756.GP65688@shinkuro.com> <4AEA006F.30607@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AEA006F.30607@viagenie.ca> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] DNS64 and limiting data sharing across interfaces 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, 29 Oct 2009 21:02:37 -0000 On Thu, Oct 29, 2009 at 04:51:59PM -0400, Simon Perreault wrote: > Records synthesized by a DNS64 can only be used on a network where a NAT64 > device is available and is configured with the same Pref64::/n as the DNS64. > > This principle is valid in all cases. But it doesn't tell exactly how to enforce > it. That's probably the best advice we can give right now. I'm sort of loathe to make a requirement that can't actually be achieved. The problem here AFAICT is that we simply don't have a mechanism to find any of that out, as you correctly point out. One thing that occurs to me is to remove the normative language, and just warn that using data from some other interface could easily cause communication failures, sub-optimal communication paths, and maybe even leakage of split-brain data across the network boundaries; but that in practice, many deployed nodes in fact use DNS responses from one interface to communicate on a different interface, and there's not much one can do to prevent it in such cases. This amounts to a warning that the orderly picture one might have from reading the document is a false one. Would that be enough? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dthaler@microsoft.com Thu Oct 29 14:56:17 2009 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 91E613A69A8 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 14:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yn7g8UoStG32 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 14:56:16 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id C26613A6840 for <behave@ietf.org>; Thu, 29 Oct 2009 14:56:16 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 29 Oct 2009 14:56:46 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server id 14.0.639.20; Thu, 29 Oct 2009 14:56:31 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Thu, 29 Oct 2009 14:56:32 -0700 From: Dave Thaler <dthaler@microsoft.com> To: Andrew Sullivan <ajs@shinkuro.com>, "behave@ietf.org" <behave@ietf.org> Thread-Topic: [BEHAVE] DNS64 and limiting data sharing across interfaces Thread-Index: AQHKWNZrD2/lmCuyo0ytqKoOIMTRJZEdEwBg Date: Thu, 29 Oct 2009 21:56:30 +0000 Message-ID: <E4561B14EE2A3E4E9D478EBFB5416E1B29B25AB0@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> References: <20091029202756.GP65688@shinkuro.com> In-Reply-To: <20091029202756.GP65688@shinkuro.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] DNS64 and limiting data sharing across interfaces 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, 29 Oct 2009 21:56:17 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Andrew Sullivan > Sent: Thursday, October 29, 2009 1:28 PM > To: behave@ietf.org > Subject: [BEHAVE] DNS64 and limiting data sharing across interfaces >=20 > Dear colleagues, >=20 > The dns64-02 draft contains this text: >=20 > 5.6. DNS64 and multihoming >=20 > Synthetic AAAA records may be constructed on the basis of the > network > context in which they were constructed. Therefore, a synthetic AAAA > received from one interface MUST NOT be used to resolve hosts via > another network interface. Because it will be hard (if not > impossible) for a multihomed system to tell whether a given AAAA is > synthetic, a host SHOULD treat any AAAA record received on a given > interface as local to that interface; the alternative risks > communication failures when the AAAA is used to communicate on > another interface. See the discussion in > [I-D.savolainen-mif-dns-server-selection]. >=20 > Off-list someone pointed out to me that there are cases where you have > effectively dual-stack hosts for legacy reasons: the host is connected > to the Internet via NAT64 but is talking to v4-only hosts in a local > network or something. That reminded us that some v6-capable hosts use > v4 only to do their DNS, which means that the only way such hosts are > going to get DNS answers is on the v4-only interface. >=20 > The above text, as written, appears to discourage such a practice. It's not clear to me whether the quoted text is talking about the DNS64 itself being multihomed, or a client using it. I think it would be inappropriate for the DNS64 document (which specifies a DNS64 and hence a DNS64 implementation would claim conformance to) to use RFC 2119 language that would apply to other entities, like end hosts / DNS clients using the DNS64 unknowingly. -Dave >=20 > Does anyone have a better idea? I have been thinking about it, but I > don't. >=20 > A >=20 > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From stig@venaas.com Thu Oct 29 15:35:48 2009 Return-Path: <stig@venaas.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 B6E193A6A3E for <behave@core3.amsl.com>; Thu, 29 Oct 2009 15:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.155, 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 fT6hpnY1TTB0 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 15:35:47 -0700 (PDT) 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 626473A6940 for <behave@ietf.org>; Thu, 29 Oct 2009 15:35:47 -0700 (PDT) Received: from [IPv6:2001:420:1:fff:0:5efe:10.32.214.37] (unknown [IPv6:2001:420:1:fff:0:5efe:a20:d625]) by ufisa.uninett.no (Postfix) with ESMTP id 5FBEF22FAD; Thu, 29 Oct 2009 23:36:02 +0100 (CET) Message-ID: <4AEA18CE.8040302@venaas.com> Date: Thu, 29 Oct 2009 15:35:58 -0700 From: Stig Venaas <stig@venaas.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Iljitsch van Beijnum <iljitsch@muada.com> References: <4AE94ED6.5050600@it.uc3m.es> <B7943394-8740-4292-B0FF-1050B0DFD3FF@muada.com> In-Reply-To: <B7943394-8740-4292-B0FF-1050B0DFD3FF@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Amount of fragmentation resulting from translation 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, 29 Oct 2009 22:35:48 -0000 Iljitsch van Beijnum wrote: > On 29 okt 2009, at 09:14, marcelo bagnulo braun wrote: > >> So, my question is whether this behaviour would not result is massive >> fragmentation. I mean, one could guess that 1500 byte long packet are >> fairly common, and that the defined behavour would imply fragmentation >> of all these packets for example. > > Right. Of course most traffic is TCP which has PMTUD enabled so DF=1, > but there is some TCP with DF=0 and UDP video streaming usually has ~ > 1470 byte packets and DF=0. A hybrid approach might be useful. E.g. if the IPv4 packet is translated into an IPv6 packet > 1280, try to send it. If you get ICMP back, just do 1280. Anyway, I think this should be left to the implementation. Doing PMTUD would be good in my opinion, but alternatively, just assume 1280. Just like IPv6 hosts have to do. > The problem is that if you translate IPv4 packets with DF=0 and they're > too big on the IPv6 side, an IPv6 router will send back a too big > message, and if you translate that message to an IPv4 too big message it > will probably be ignored because UDP protocols have to do their own > PMTUD in IPv4 which they don't AFAIK, and in the case of TCP with DF=0 > PMTUD was almost certainly turned off. Yes. I think if DF=0 you just have to fragment. You cannot assume PMTUD will work. You still have the choice whether to do PMTUD or assume 1280 on IPv6 side of course. > So in the case where the IPv6 MTU is smaller than the IPv4 MTU (and 20 > bytes for the difference between the v6/v4 header sizes) for packets > with DF=0 you need to fragment. That means the only question is whether > you simply always fragment, or track the PMTU on the IPv6 side and only > fragment when necessary. > > Since any IPv6 host needs to track the PMTU for any host it talks to > anyway (if it wants to send > 1280 byte packets, at least) the state > requirement doesn't seem very unusual so I would go for that. But maybe > others would prefer the other choice. Yes, I think it's OK doing PMTUD. But I still think it can be optional. I prefer the additional state (if translator can cope with it) to having all the extra fragmentation. Of course there will probably be some issues due to some IPv4 senders sending 1500 byte packets, where the IPv6 receiver is also likely to handle at most 1500. Stig > On 29 okt 2009, at 09:40, Reinaldo Penno wrote: > >> As far as PMTUD goes although it creates state, you need to remember such >> values per outgoing interface and not really per NAT binding. > > No, it's per IPv6 destination address. Could be that one host that uses > the translator can handle 1500 byte packets while another can only > handle 1480 or 1280. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From stig@venaas.com Thu Oct 29 15:47:18 2009 Return-Path: <stig@venaas.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 298FF3A689E for <behave@core3.amsl.com>; Thu, 29 Oct 2009 15:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.133, 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 f+WRTaYKf5Th for <behave@core3.amsl.com>; Thu, 29 Oct 2009 15:47:17 -0700 (PDT) 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 4C5793A6914 for <behave@ietf.org>; Thu, 29 Oct 2009 15:47:17 -0700 (PDT) Received: from [IPv6:2001:420:1:fff:0:5efe:10.32.214.37] (unknown [IPv6:2001:420:1:fff:0:5efe:a20:d625]) by ufisa.uninett.no (Postfix) with ESMTP id 9EC1F22FAD; Thu, 29 Oct 2009 23:47:32 +0100 (CET) Message-ID: <4AEA1B81.1030804@venaas.com> Date: Thu, 29 Oct 2009 15:47:29 -0700 From: Stig Venaas <stig@venaas.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dan Wing <dwing@cisco.com> References: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> In-Reply-To: <02b101ca5337$8f3fcbf0$5ba36b80@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 29 Oct 2009 22:47:18 -0000 Dan Wing wrote: > We are considering adopting draft-van-beijnum-behave-ftp64-06 as a WG document > to meet our milestone "Jan 2010 Submit to IESG: FTP ALG for IPv6/IPv4 > translation (std)", > http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-06 > > The author believes the document now incorporates all feedback. > > Please reply to the list. I support adopting this. While I'm sure there may be some improvements possible, I think it's already a very solid document. Stig > -d > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From marka@isc.org Thu Oct 29 16:29:39 2009 Return-Path: <marka@isc.org> 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 47E143A6936 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 16:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 eTvTkKCHpw06 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 16:29:38 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id 31C553A681D for <behave@ietf.org>; Thu, 29 Oct 2009 16:29:37 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id C5021E6026; Thu, 29 Oct 2009 23:29:51 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n9TNTmCx075617; Fri, 30 Oct 2009 10:29:48 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200910292329.n9TNTmCx075617@drugs.dv.isc.org> To: Stig Venaas <stig@venaas.com> From: Mark Andrews <marka@isc.org> References: <4AE94ED6.5050600@it.uc3m.es> <B7943394-8740-4292-B0FF-1050B0DFD3FF@muada.com> <4AEA18CE.8040302@venaas.com> In-reply-to: Your message of "Thu, 29 Oct 2009 15:35:58 PDT." <4AEA18CE.8040302@venaas.com> Date: Fri, 30 Oct 2009 10:29:48 +1100 Sender: marka@isc.org Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Amount of fragmentation resulting from translation 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, 29 Oct 2009 23:29:39 -0000 In message <4AEA18CE.8040302@venaas.com>, Stig Venaas writes: > Iljitsch van Beijnum wrote: > > On 29 okt 2009, at 09:14, marcelo bagnulo braun wrote: > > > >> So, my question is whether this behaviour would not result is massive > >> fragmentation. I mean, one could guess that 1500 byte long packet are > >> fairly common, and that the defined behavour would imply fragmentation > >> of all these packets for example. > > > > Right. Of course most traffic is TCP which has PMTUD enabled so DF=1, > > but there is some TCP with DF=0 and UDP video streaming usually has ~ > > 1470 byte packets and DF=0. > > A hybrid approach might be useful. E.g. if the IPv4 packet is translated > into an IPv6 packet > 1280, try to send it. If you get ICMP back, just > do 1280. Anyway, I think this should be left to the implementation. > Doing PMTUD would be good in my opinion, but alternatively, just assume > 1280. Just like IPv6 hosts have to do. > > > The problem is that if you translate IPv4 packets with DF=0 and they're > > too big on the IPv6 side, an IPv6 router will send back a too big > > message, and if you translate that message to an IPv4 too big message it > > will probably be ignored because UDP protocols have to do their own > > PMTUD in IPv4 which they don't AFAIK, and in the case of TCP with DF=0 > > PMTUD was almost certainly turned off. > > Yes. I think if DF=0 you just have to fragment. You cannot assume PMTUD > will work. You still have the choice whether to do PMTUD or assume 1280 > on IPv6 side of course. > > > So in the case where the IPv6 MTU is smaller than the IPv4 MTU (and 20 > > bytes for the difference between the v6/v4 header sizes) for packets > > with DF=0 you need to fragment. That means the only question is whether > > you simply always fragment, or track the PMTU on the IPv6 side and only > > fragment when necessary. > > > > Since any IPv6 host needs to track the PMTU for any host it talks to > > anyway (if it wants to send > 1280 byte packets, at least) the state > > requirement doesn't seem very unusual so I would go for that. But maybe > > others would prefer the other choice. > > Yes, I think it's OK doing PMTUD. But I still think it can be optional. > I prefer the additional state (if translator can cope with it) to having > all the extra fragmentation. Of course there will probably be some > issues due to some IPv4 senders sending 1500 byte packets, where the > IPv6 receiver is also likely to handle at most 1500. > > Stig I think turning on PMTUD in the middle of the network is just plain wrong. There are OS which incorrectly turn on PMTUD for IPv4 for all packets. This causes problems for applications like DNS servers. There is only one choice and that is to fragment at network MTU. Anything else will cause operational problems. > > On 29 okt 2009, at 09:40, Reinaldo Penno wrote: > > > >> As far as PMTUD goes although it creates state, you need to remember such > >> values per outgoing interface and not really per NAT binding. > > > > No, it's per IPv6 destination address. Could be that one host that uses > > the translator can handle 1500 byte packets while another can only > > handle 1480 or 1280. > > _______________________________________________ > > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From aeh@db.org Thu Oct 29 16:38:32 2009 Return-Path: <aeh@db.org> 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 47AF63A69A8 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 16:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGeemwFIYNaA for <behave@core3.amsl.com>; Thu, 29 Oct 2009 16:38:31 -0700 (PDT) Received: from submit-tmp.sysedata.no (submit-tmp.sysedata.no [195.159.29.133]) by core3.amsl.com (Postfix) with ESMTP id 657F33A696C for <behave@ietf.org>; Thu, 29 Oct 2009 16:38:31 -0700 (PDT) Received: from [82.71.93.162] (helo=alfred-heggestads-macbook-pro.local) by submit-tmp.sysedata.no with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <aeh@db.org>) id 1N3eZo-0007kl-EI; Fri, 30 Oct 2009 00:38:44 +0100 Message-ID: <4AEA2783.10100@db.org> Date: Fri, 30 Oct 2009 00:38:43 +0100 From: "Alfred E. Heggestad" <aeh@db.org> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: derek.macdonald@gmail.com, bbl@lowekamp.net, 'Behave WG' <behave@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEHAVE] Comments on draft-ietf-behave-nat-behavior-discovery-08 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, 29 Oct 2009 23:38:32 -0000 Hi here are some comments on draft-ietf-behave-nat-behavior-discovery-08: 6.1, last paragraph: typo: s/reponse/response/ 7.5: typos: s/REPONSE-PORT/RESPONSE-PORT/ s/transmited/transmitted/ "Allowed values" should be 0-65535 9.1: CACHE-TIMEOUT is still defined here, should be removed 10: "Requests containing both RESPONSE-PORT and PADDING are rejected by the server" ----> how is the request rejected, which error code should be used? From stig@venaas.com Thu Oct 29 16:46:51 2009 Return-Path: <stig@venaas.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 187C23A69AC for <behave@core3.amsl.com>; Thu, 29 Oct 2009 16:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.116, 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 HnNELYPRDwby for <behave@core3.amsl.com>; Thu, 29 Oct 2009 16:46:50 -0700 (PDT) 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 0FEA23A696C for <behave@ietf.org>; Thu, 29 Oct 2009 16:46:50 -0700 (PDT) Received: from [IPv6:2001:420:1:fff:0:5efe:10.32.214.37] (unknown [IPv6:2001:420:1:fff:0:5efe:a20:d625]) by ufisa.uninett.no (Postfix) with ESMTP id ED0CF22F71; Fri, 30 Oct 2009 00:47:04 +0100 (CET) Message-ID: <4AEA2974.6060800@venaas.com> Date: Thu, 29 Oct 2009 16:47:00 -0700 From: Stig Venaas <stig@venaas.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Mark Andrews <marka@isc.org> References: <4AE94ED6.5050600@it.uc3m.es> <B7943394-8740-4292-B0FF-1050B0DFD3FF@muada.com> <4AEA18CE.8040302@venaas.com> <200910292329.n9TNTmCx075617@drugs.dv.isc.org> In-Reply-To: <200910292329.n9TNTmCx075617@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Amount of fragmentation resulting from translation 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, 29 Oct 2009 23:46:51 -0000 Mark Andrews wrote: [...] > I think turning on PMTUD in the middle of the network is just plain > wrong. There are OS which incorrectly turn on PMTUD for IPv4 for > all packets. This causes problems for applications like DNS servers. > > There is only one choice and that is to fragment at network MTU. Anything > else will cause operational problems. I actually agree, see below. I've seen some of those issues too. You do have a point. I think one should only do IPv6 PMTUD if the IPv4 packet has DF set. I think the issue with UDP and PMTUD is that the stack does not resend the packet if "packet too big" (or equiv IPv4) is returned. So the application would need to be triggered to send a new request. Otherwise you just hang around waiting for an application retry. The question is if the translator does PMTUD, should it then cache the packets until PMTUD is successful? That is of course problematic. But just dropping the packets on the floor in the middle of the network is bad too. I think this would be an issue if the translator were to do IPv6 PMTUD when IPv4 DF is not set. So if IPv4 DF is not set, better not do IPv6 PMTUD. Just assume PMTU 1280. If IPv4 DF is set, then you can do PMTUD end to end, which I think is fine. Stig From rpenno@juniper.net Thu Oct 29 18:59:38 2009 Return-Path: <rpenno@juniper.net> 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 958393A68EC for <behave@core3.amsl.com>; Thu, 29 Oct 2009 18:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Moc3WVKX0mw2 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 18:59:37 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 3D1093A67A2 for <behave@ietf.org>; Thu, 29 Oct 2009 18:59:24 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSupIhhhjvBrFnGoaYzihy2PxJdunJnlG@postini.com; Thu, 29 Oct 2009 18:59:54 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 29 Oct 2009 18:57:10 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 29 Oct 2009 21:57:10 -0400 From: Reinaldo Penno <rpenno@juniper.net> To: Stig Venaas <stig@venaas.com>, Mark Andrews <marka@isc.org> Date: Thu, 29 Oct 2009 21:57:06 -0400 Thread-Topic: [BEHAVE] Amount of fragmentation resulting from translation Thread-Index: AcpY8iJWGfnkv8FGRXao3PyhR2739wAEiXlQ Message-ID: <C70F9602.7445%rpenno@juniper.net> In-Reply-To: <4AEA2974.6060800@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Amount of fragmentation resulting from translation 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, 30 Oct 2009 01:59:38 -0000 I find this email talking about IPv6 PMTUD issues and the following thread very interesting. It contain very useful data. [Ipv6-techsig] IPv6 PMTUD issues, some data http://listserver.internetnz.net.nz/pipermail/ipv6-techsig/2009-October/000= 7 08.html Although PMTUD is enabled by default but if it is not as reliable as hoped fragmentation will be common within TCP connections. In that case it would be massive fragmentation in the translator since TCP WebServer/Video traffi= c is overwhelming and packets > 1280 are very common. Thanks, Reinaldo On 10/29/09 4:47 PM, "Stig Venaas" <stig@venaas.com> wrote: > Mark Andrews wrote: > [...] >> I think turning on PMTUD in the middle of the network is just plain >> wrong. There are OS which incorrectly turn on PMTUD for IPv4 for >> all packets. This causes problems for applications like DNS servers. >>=20 >> There is only one choice and that is to fragment at network MTU. Anythi= ng >> else will cause operational problems. >=20 > I actually agree, see below. >=20 > I've seen some of those issues too. You do have a point. I think one > should only do IPv6 PMTUD if the IPv4 packet has DF set. >=20 > I think the issue with UDP and PMTUD is that the stack does not resend > the packet if "packet too big" (or equiv IPv4) is returned. So the > application would need to be triggered to send a new request. Otherwise > you just hang around waiting for an application retry. >=20 > The question is if the translator does PMTUD, should it then cache the > packets until PMTUD is successful? That is of course problematic. But > just dropping the packets on the floor in the middle of the network is > bad too. >=20 > I think this would be an issue if the translator were to do IPv6 PMTUD > when IPv4 DF is not set. >=20 > So if IPv4 DF is not set, better not do IPv6 PMTUD. Just assume PMTU > 1280. >=20 > If IPv4 DF is set, then you can do PMTUD end to end, which I think is > fine. >=20 > Stig > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From caozhenpku@gmail.com Thu Oct 29 20:44:38 2009 Return-Path: <caozhenpku@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 DCD113A6848 for <behave@core3.amsl.com>; Thu, 29 Oct 2009 20:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.375, 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 O7RHxsGjfbJx for <behave@core3.amsl.com>; Thu, 29 Oct 2009 20:44:38 -0700 (PDT) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 20C123A67EF for <behave@ietf.org>; Thu, 29 Oct 2009 20:44:38 -0700 (PDT) Received: by pwi4 with SMTP id 4so456664pwi.29 for <behave@ietf.org>; Thu, 29 Oct 2009 20:44:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2Alghxpp0KTmyciGtJINPa4JPtu0L6r5q3NEC2PjSO0=; b=j4bT0cZeiccd8W2OPYbuFsoVUNbBIjWMQwrf8168fFeBG16ecWAb/rSzQqCgdRh9Jz S8jUOOSMpDqCLnQ6w5+w1iZ6Bt+ztPYYQol8DsEFNktUo/g6voD9T4y4rqIv4/UE1LJQ +D5tGZkX01Enw9ds3sTGw8EdJRSPlN+vT4p8E= 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=KFvjHiJawqK0q23Q/Okq16rN0kcaFbef6ifoMpaGWg8KJ+MOlu7pjfms44nM41Rwpc hJ8ajB3eVR2yhcm4edrJKnim0B1qaYuHzxp8A67B8/PcRD0El7gYKfy8YCprSkEGB+MJ iTCiMAMc0jQv3uFm1/Pr3YAVuFJFyGS1FcYPk= MIME-Version: 1.0 Received: by 10.143.26.29 with SMTP id d29mr93348wfj.281.1256874289812; Thu, 29 Oct 2009 20:44:49 -0700 (PDT) In-Reply-To: <1d1001ca58b6$d05fec80$c5f0200a@cisco.com> References: <004501ca5879$938933d0$3a0c6f0a@china.huawei.com> <4AE96AFB.5000406@it.uc3m.es> <3db7b9d60910290759k4314a976p1b8750417b0c03d8@mail.gmail.com> <20091029151219.GG65688@shinkuro.com> <1d1001ca58b6$d05fec80$c5f0200a@cisco.com> Date: Fri, 30 Oct 2009 11:44:49 +0800 Message-ID: <a7c8d0a30910292044t40f28931v9262cecac516f26a@mail.gmail.com> From: Zhen Cao <caozhenpku@gmail.com> To: Dan Wing <dwing@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Andrew Sullivan <ajs@shinkuro.com>, behave@ietf.org Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 30 Oct 2009 03:44:39 -0000 On Fri, Oct 30, 2009 at 12:42 AM, Dan Wing <dwing@cisco.com> wrote: >> On Thu, Oct 29, 2009 at 10:59:35PM +0800, Kai Ju wrote: >> > jiang sheng's pre condition is quite clear, by including >> > other author, this draft could be adopted. >> >> I'm not sure how our Chairs prefer to work these matters, but it is my >> understanding that the editors of a draft which is to be a WG product >> normally serve at the pleasure of the Chairs. =A0Therefore, I don't >> believe the WG participants are in a position to insist on one or >> another editor for the draft as a condition of making it a WG work >> item. =A0"Is the _draft_ to be worked on by the WG?" is the question, as >> I understand it. =A0The Chairs might well decide that someone previously >> entirely unconnected to this effort will hold the pen, and that's >> something they get to choose after the WG has expressed its >> willingness to adopt the work item. > > Yes, the question at hand is 'shall we adopt this document'. =A0I > did not ask 'who wants to be an author'. > > I have not seen a substantive objection since I asked a week ago > (Oct 22). Note that i raised some questions and do not think the current draft is a solid basis, although chairs do not think they are fundamental issues. I do not know what can be a 'fundamental' issue. Thanks. > > -d > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From marcelo@it.uc3m.es Fri Oct 30 01:18:22 2009 Return-Path: <marcelo@it.uc3m.es> 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 5A5EB3A6A46 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 01:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.402 X-Spam-Level: X-Spam-Status: No, score=-6.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5ZxTZDqMcGz for <behave@core3.amsl.com>; Fri, 30 Oct 2009 01:18:21 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 5904F3A6A3E for <behave@ietf.org>; Fri, 30 Oct 2009 01:18:21 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp01.uc3m.es (Postfix) with ESMTP id 3B602BA8249; Fri, 30 Oct 2009 09:18:36 +0100 (CET) Message-ID: <4AEAA15C.4060900@it.uc3m.es> Date: Fri, 30 Oct 2009 09:18:36 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Mark Andrews <marka@isc.org> References: <4AE94ED6.5050600@it.uc3m.es> <B7943394-8740-4292-B0FF-1050B0DFD3FF@muada.com> <4AEA18CE.8040302@venaas.com> <200910292329.n9TNTmCx075617@drugs.dv.isc.org> In-Reply-To: <200910292329.n9TNTmCx075617@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16978.003 Cc: Stig Venaas <stig@venaas.com>, Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Amount of fragmentation resulting from translation 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, 30 Oct 2009 08:18:22 -0000 Mark Andrews escribió: > > > I think turning on PMTUD in the middle of the network is just plain > wrong. There are OS which incorrectly turn on PMTUD for IPv4 for > all packets. This causes problems for applications like DNS servers. > > There is only one choice and that is to fragment at network MTU. Anything > else will cause operational problems. > > Just to be clear, you support the option that the translator always sends IPv6 packet of 1280 bytes rahter than the translator doing pmtud to figure out which is the mtu availbale for that path, correct? Regards, marcelo From marcelo@it.uc3m.es Fri Oct 30 01:24:00 2009 Return-Path: <marcelo@it.uc3m.es> 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 EC0CF3A6A3E for <behave@core3.amsl.com>; Fri, 30 Oct 2009 01:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.409 X-Spam-Level: X-Spam-Status: No, score=-6.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X68VN+CiWs+n for <behave@core3.amsl.com>; Fri, 30 Oct 2009 01:24:00 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 21EC73A684D for <behave@ietf.org>; Fri, 30 Oct 2009 01:23:59 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id 0C336659D19; Fri, 30 Oct 2009 09:24:15 +0100 (CET) Message-ID: <4AEAA2AE.2040205@it.uc3m.es> Date: Fri, 30 Oct 2009 09:24:14 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Stig Venaas <stig@venaas.com> References: <4AE94ED6.5050600@it.uc3m.es> <B7943394-8740-4292-B0FF-1050B0DFD3FF@muada.com> <4AEA18CE.8040302@venaas.com> <200910292329.n9TNTmCx075617@drugs.dv.isc.org> <4AEA2974.6060800@venaas.com> In-Reply-To: <4AEA2974.6060800@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16978.003 Cc: Behave WG <behave@ietf.org>, Mark Andrews <marka@isc.org> Subject: Re: [BEHAVE] Amount of fragmentation resulting from translation 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, 30 Oct 2009 08:24:01 -0000 Stig Venaas escribió: > > So if IPv4 DF is not set, better not do IPv6 PMTUD. Just assume PMTU > 1280. > > If IPv4 DF is set, then you can do PMTUD end to end, which I think is > fine. > This is what the current stateless does. I am reading that people still support this option, so unless we have strong oposition, i guess we should go this path Regards, marcelo > Stig > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From marcelo@it.uc3m.es Fri Oct 30 01:34:16 2009 Return-Path: <marcelo@it.uc3m.es> 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 AC8723A69EF for <behave@core3.amsl.com>; Fri, 30 Oct 2009 01:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.416 X-Spam-Level: X-Spam-Status: No, score=-6.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BU7jioF9czWl for <behave@core3.amsl.com>; Fri, 30 Oct 2009 01:34:15 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 51D973A6A2B for <behave@ietf.org>; Fri, 30 Oct 2009 01:34:15 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp01.uc3m.es (Postfix) with ESMTP id CAAE1BA84E5; Fri, 30 Oct 2009 09:34:30 +0100 (CET) Message-ID: <4AEAA516.1040605@it.uc3m.es> Date: Fri, 30 Oct 2009 09:34:30 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Reinaldo Penno <rpenno@juniper.net> References: <C70F9602.7445%rpenno@juniper.net> In-Reply-To: <C70F9602.7445%rpenno@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16978.003 Cc: Stig Venaas <stig@venaas.com>, Behave WG <behave@ietf.org>, Mark Andrews <marka@isc.org>, Ben@wand.net.nz Subject: [BEHAVE] How to set the DF and the ID values for IPv4 packets (was Re: Amount of fragmentation resulting from translation 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, 30 Oct 2009 08:34:16 -0000 Hi, thank you very much for the pointer, this is interesting data i agree. However, i am not sure i read it in the same way you do. In particular, what i extract from this analysis is that there is a non negligible amount of IPv6 hosts/sites that filter the packet too big errors and simply send packets of 1280 bytes (about 15% if i read it correctly). This actually affects other part of the fragmentation discussion and it is related to the the question about how to set the DF and the id field for ipv4 packets resulting from translating IPv6 packets wihtout the fragment header. So, consider that the translator receives an IPv6 packet without a fragment header. Those packets without the fragment header do not contain any ID value. The stateless document defines that the ID value is set to 0 and the DF set to 1. That works modulo the following black hole situation: Suppose that an IPv6 site is configured to drop ICMP packet too big msgs and configure its hosts to only send packet of 1280 bytes. That would work for any communication with other IPv6 hosts, but it would break for a communication with an IPv4 host behind a translator and sitting on a link with MTU smaller than 1280. In order to solve this problem, we should set the ID value different for different packets and set DF to zero. In order to do that, we should generate values for the ID field so that they do not clash That would require changing the stateless document or if we don't want to keep the seq number state in that document, but we consider the problem is real and want to solve it int he stateful case, then take a different approach in the stateless and the staefull document. Comments? regards, marcelo Reinaldo Penno escribió: > I find this email talking about IPv6 PMTUD issues and the following thread > very interesting. It contain very useful data. > > [Ipv6-techsig] IPv6 PMTUD issues, some data > > http://listserver.internetnz.net.nz/pipermail/ipv6-techsig/2009-October/0007 > 08.html > > Although PMTUD is enabled by default but if it is not as reliable as hoped > fragmentation will be common within TCP connections. In that case it would > be massive fragmentation in the translator since TCP WebServer/Video traffic > is overwhelming and packets > 1280 are very common. > > Thanks, > > Reinaldo > > > On 10/29/09 4:47 PM, "Stig Venaas" <stig@venaas.com> wrote: > > >> Mark Andrews wrote: >> [...] >> >>> I think turning on PMTUD in the middle of the network is just plain >>> wrong. There are OS which incorrectly turn on PMTUD for IPv4 for >>> all packets. This causes problems for applications like DNS servers. >>> >>> There is only one choice and that is to fragment at network MTU. Anything >>> else will cause operational problems. >>> >> I actually agree, see below. >> >> I've seen some of those issues too. You do have a point. I think one >> should only do IPv6 PMTUD if the IPv4 packet has DF set. >> >> I think the issue with UDP and PMTUD is that the stack does not resend >> the packet if "packet too big" (or equiv IPv4) is returned. So the >> application would need to be triggered to send a new request. Otherwise >> you just hang around waiting for an application retry. >> >> The question is if the translator does PMTUD, should it then cache the >> packets until PMTUD is successful? That is of course problematic. But >> just dropping the packets on the floor in the middle of the network is >> bad too. >> >> I think this would be an issue if the translator were to do IPv6 PMTUD >> when IPv4 DF is not set. >> >> So if IPv4 DF is not set, better not do IPv6 PMTUD. Just assume PMTU >> 1280. >> >> If IPv4 DF is set, then you can do PMTUD end to end, which I think is >> fine. >> >> 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 iljitsch@muada.com Fri Oct 30 03:01:45 2009 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 9B4A63A68CE for <behave@core3.amsl.com>; Fri, 30 Oct 2009 03:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhkkMD4s3sTj for <behave@core3.amsl.com>; Fri, 30 Oct 2009 03:01:44 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 9B1D53A67A7 for <behave@ietf.org>; Fri, 30 Oct 2009 03:01:44 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.216]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n9UA1Fv7077873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Oct 2009 11:01:20 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <4AEAA2AE.2040205@it.uc3m.es> Date: Fri, 30 Oct 2009 11:01:48 +0100 Content-Transfer-Encoding: 7bit Message-Id: <36C72C83-80A1-41F0-88C7-4D2FA9C8E0DD@muada.com> References: <4AE94ED6.5050600@it.uc3m.es> <B7943394-8740-4292-B0FF-1050B0DFD3FF@muada.com> <4AEA18CE.8040302@venaas.com> <200910292329.n9TNTmCx075617@drugs.dv.isc.org> <4AEA2974.6060800@venaas.com> <4AEAA2AE.2040205@it.uc3m.es> To: marcelo bagnulo braun <marcelo@it.uc3m.es> X-Mailer: Apple Mail (2.1076) Cc: Stig Venaas <stig@venaas.com>, Behave WG <behave@ietf.org>, Mark Andrews <marka@isc.org> Subject: Re: [BEHAVE] Amount of fragmentation resulting from translation 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, 30 Oct 2009 10:01:45 -0000 On 30 okt 2009, at 09:24, marcelo bagnulo braun wrote: >> So if IPv4 DF is not set, better not do IPv6 PMTUD. Just assume PMTU >> 1280. >> If IPv4 DF is set, then you can do PMTUD end to end, which I think is >> fine. > This is what the current stateless does. > I am reading that people still support this option, so unless we > have strong oposition, i guess we should go this path I prefer that the translator "terminates" PMTUD, this avoids unnecessary fragmentation and avoids some PMTUD black holes. However, I'm in favor of leaving this up to implementers, I don't think we should require one solution or the other. From marcelo@it.uc3m.es Fri Oct 30 03:04:13 2009 Return-Path: <marcelo@it.uc3m.es> 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 1CDBC3A6A4B for <behave@core3.amsl.com>; Fri, 30 Oct 2009 03:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.427 X-Spam-Level: X-Spam-Status: No, score=-6.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9PzPayUHjju for <behave@core3.amsl.com>; Fri, 30 Oct 2009 03:04:12 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 6477C3A6A3F for <behave@ietf.org>; Fri, 30 Oct 2009 03:04:11 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id 049776C1925 for <behave@ietf.org>; Fri, 30 Oct 2009 11:04:27 +0100 (CET) Message-ID: <4AEABA2A.8060605@it.uc3m.es> Date: Fri, 30 Oct 2009 11:04:26 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Behave WG <behave@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16978.003 Subject: [BEHAVE] nit on stateless document 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, 30 Oct 2009 10:04:13 -0000 the stateless document reads: An IPv6 link has to have an MTU of 1280 bytes or greater. The corresponding limit for IPv4 is 68 bytes. I guess it is 576 bytes? Regards, marcelo From marcelo@it.uc3m.es Fri Oct 30 03:10:44 2009 Return-Path: <marcelo@it.uc3m.es> 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 CA7283A686D for <behave@core3.amsl.com>; Fri, 30 Oct 2009 03:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkkGUh7BpYlX for <behave@core3.amsl.com>; Fri, 30 Oct 2009 03:10:43 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 76CE13A682C for <behave@ietf.org>; Fri, 30 Oct 2009 03:10:43 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp03.uc3m.es (Postfix) with ESMTP id 5DF367F2BEF for <behave@ietf.org>; Fri, 30 Oct 2009 11:10:58 +0100 (CET) Message-ID: <4AEABBB2.1090708@it.uc3m.es> Date: Fri, 30 Oct 2009 11:10:58 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Behave WG <behave@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16978.003 Subject: [BEHAVE] Summary of the issues related to fragmentation and v4/v6 translation 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, 30 Oct 2009 10:10:44 -0000 Hi, I attach next a summary of the issues related to fragmentation some of which are common to the stateless and stateful cases and some of which are specific to the stateful case. I think we should decide what to do with these in the next meeting. Comments are welcome? Summary of the issues related to fragmentation ----------------------------------------------- Incoming IPv4 packet - Full packet, DF=1: Resulting IPv6 packet does NOT include the fragment header (PMUTD should work e2e) Issue: If the packet is too big for the outgoing MTU in IPv6, should the translator generate and ICMP error Packet too big? This is not specified in the stateless document AFAICT. This affects both stateless and stateful, should we use the same approach to both? - Full packet, DF=0: Resulting IPv6 packets MUST fit in 1280 bytes, so add the fragment header if needed. The fields of the fragment header are copied from the IPv4 fields. Issue: Would this result in significant amount of fragmentation? Should the translator perform PMUTD for IPv6 destinations? This affects both stateless and stateful, should we use the same approach to both? see thread in behave ml - My reading so far is that we should send 1280 byte long packets (As currently defined) - Fragment: Add fragment header, copy fields from IPv4 header, also make sure that the packet does not exceeds 1280 bytes. Issue: how to determine the session for fragments, reassembly or keep state. This issue is described in detail in (*) below and it is specific to the stateful case Incoming IPv6 packet - Without Fragment header: Id set to all zeros and DF set to 1. Issue: Black hole in cases the IPv6 side filters ICMP packet too big and simply sends packets of 1280 bytes. This may be not negligible according to the analysis from Ben. This affects both stateless and stateful, should we use the same approach to both? The issue is detailed in (**) Issue: If the outgoing IPv4 MTU is smaller than the packet, should the translator send an ICMP packet too big back? This affects both stateless and stateful, should we use the same approach to both? - With Fragment header: copy fields from the fragment header to the IPv4 header fragmentation fields Issue: higher probability of clashes on the ID fields for the stateful case This is somehow specific to the stateful case, see the issue detailed in (***) Detailed description of issues (mostly) specific to the stateful translation ---------------------------------------------------------------------------- (*) - Issue#1: Processing of incoming IPv4 packets containing a fragment other than the first one. In order to translate an IPv4 packet, we need to know the 5-tuple. When an IPv4 packet contains a fragment other than the first one, the port information is not available, so the port information must be retrieved from somewhere else. The possibilities are: a)- Reassemble the IPv4 packet, and translate it. b)- Store state that allows to translate packets containing fragments other than the first one. The state needed is the ID value. The state is learned from the packet containing the first segment. So the procedure would be: If packets that contain fragments that are not the first arrive and the ID does not match to any of the stored ID values for the src and dst addreses, then store the packets. If packets that contain fragments that are not the first arrive and the ID does match to any of the stored ID values for the src and dst addresses, then use the corresponding session to translate the packet. If packet that contain the first fragment arrive, then store the ID value in the session state and forward the packet. The differences between the two approaches are: - The approach a) will require more memory for storing fragments. - The approach b) will require additional complexity and state. In particular, it is important to deal with the attacks defined in RFC3128 and RFC1858 (that i understand that do not apply if we use approach a) (***) Issue#2: Setting the ID value for outgoing IPv4 packets. The ID field of outgoing IPv4 packets must be different for different packets. Since multiple IPv6 addresses potentially communicating with the same destination may share the same IPv4 address, we need to avoid clashes in the ID field. We have two types of incoming IPv6 packets: those with the fragment header and those without the fragment header. (**)----- this is common for the stateful and the stateless---------- Those without the fragment header do not contain any ID value. The stateless document defines that the ID value is set to 0 and the DF set to 1. That works modulo the following black hole situation: Suppose that an IPv6 site is configured to drop ICMP packet too big msgs and configure its hosts to only send packet of 1280 bytes. That would work for any communication with other IPv6 hosts, but it would break for a communication with an IPv4 host behind a translator and sitting on a link with MTU smaller than 1280. In order to solve this problem, we should set the ID value different for different packets and set DF to zero. In order to do that, we should generate values for the ID field so that they do not clash ----- end of common part----------- Those IPv6 packets coming with the fragment header, the stateless document recommends to set the DF to 0 and copy the lower 16 bits of the ID field of the IPv6 fragment header into the ID value of the IPv4 header. This may result in clashes in the stateless case, but the problem in the stateful case is that there may be several IPv6 source using the same ID value would result in a higher probability of clashes. The probability increases even more if we decide to use a non zero value for the IPv4 packets resulting from IPv6 packet without the fragment header. There are three possible approaches to approach this issue: a) We decide that the clash probability is still negligible and we keep it as it is. b) Reassemble all the IPv6 fragments, translate as a normal packet (with DF set to 0 and setting a valid value of ID) c) Split the IPv4 ID value space into two. Use the ID witht he MSB set to 0 for IPv6 packets with the fragment header (And copy the lower 15 bits) and use the ID with the MSB set to 1 for the IPv6 packets without the fragment header (and generate ID values and set DF to 0) From iljitsch@muada.com Fri Oct 30 03:19:02 2009 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 5BB513A6816 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 03:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y181jx7oDSzD for <behave@core3.amsl.com>; Fri, 30 Oct 2009 03:19:01 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 29BF03A63EB for <behave@ietf.org>; Fri, 30 Oct 2009 03:19:00 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.216]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n9UAIamE078079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Oct 2009 11:18:37 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <4AEAA516.1040605@it.uc3m.es> Date: Fri, 30 Oct 2009 11:19:10 +0100 Content-Transfer-Encoding: 7bit Message-Id: <91797A55-22AF-42C9-9EB0-A0ED5C177AF3@muada.com> References: <C70F9602.7445%rpenno@juniper.net> <4AEAA516.1040605@it.uc3m.es> To: marcelo bagnulo braun <marcelo@it.uc3m.es> X-Mailer: Apple Mail (2.1076) Cc: Stig Venaas <stig@venaas.com>, Behave WG <behave@ietf.org>, Mark Andrews <marka@isc.org>, Ben@wand.net.nz Subject: Re: [BEHAVE] How to set the DF and the ID values for IPv4 packets (was Re: Amount of fragmentation resulting from translation 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, 30 Oct 2009 10:19:02 -0000 On 30 okt 2009, at 09:34, marcelo bagnulo braun wrote: > In particular, what i extract from this analysis is that there is a > non negligible amount of IPv6 hosts/sites that filter the packet too > big errors and simply send packets of 1280 bytes (about 15% if i > read it correctly). Actual PMTUD failures were only 9 out of 380 = 2.4%. All failures together were 12% (51 out of 423). That isn't too terrible considering that IPv6 is rarely production quality yet. (Note though that non-working IPv6 is often not much of a problem because most applications fall back to IPv4, but PMTUD failures are a big deal because there is no fallback.) >> Although PMTUD is enabled by default but if it is not as reliable >> as hoped >> fragmentation will be common within TCP connections. I don't see this... For fragmentation to happen with TCP, you need: 1. The IPv4 host has to have a "large" MTU 2. The IPv6 host hass to have a "large" MTU 3. There must be a link with a "small" MTU on the IPv6 path 4. The IPv4 host has to set DF=0 Of course 1 and 2 are common. 3 is probably pretty common today because of tunnels, but assuming a NAT64 run by an ISP, it would make sense that the IPv6 path would be native so there is no reduction in MTU size along the IPv6 path. 4 is quite uncommon, although it does happen. I'd say that these conditions will only hold in a fraction of a percent of all cases. It would be more common for video streaming over UDP, though. From marcelo@it.uc3m.es Fri Oct 30 03:22:51 2009 Return-Path: <marcelo@it.uc3m.es> 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 276073A6830 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 03:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+ybi-yjCpHc for <behave@core3.amsl.com>; Fri, 30 Oct 2009 03:22:50 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 1A0043A682C for <behave@ietf.org>; Fri, 30 Oct 2009 03:22:49 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp01.uc3m.es (Postfix) with ESMTP id 4C6E1BA852B; Fri, 30 Oct 2009 11:23:05 +0100 (CET) Message-ID: <4AEABE89.9090301@it.uc3m.es> Date: Fri, 30 Oct 2009 11:23:05 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Iljitsch van Beijnum <iljitsch@muada.com> References: <C70F9602.7445%rpenno@juniper.net> <4AEAA516.1040605@it.uc3m.es> <91797A55-22AF-42C9-9EB0-A0ED5C177AF3@muada.com> In-Reply-To: <91797A55-22AF-42C9-9EB0-A0ED5C177AF3@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16978.003 Cc: Stig Venaas <stig@venaas.com>, Behave WG <behave@ietf.org>, Mark Andrews <marka@isc.org>, Ben@wand.net.nz Subject: Re: [BEHAVE] How to set the DF and the ID values for IPv4 packets (was Re: Amount of fragmentation resulting from translation 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, 30 Oct 2009 10:22:51 -0000 Iljitsch van Beijnum escribió: > On 30 okt 2009, at 09:34, marcelo bagnulo braun wrote: > >> In particular, what i extract from this analysis is that there is a >> non negligible amount of IPv6 hosts/sites that filter the packet too >> big errors and simply send packets of 1280 bytes (about 15% if i read >> it correctly). > > Actual PMTUD failures were only 9 out of 380 = 2.4%. yes, but the author says: In addition to the outright failures (PMTUD_FAILs), we believe that the results RX_NODATA and RX_NOACK also indicate PMTUD failure. They could result when the server's HTTP response packets are discarded somewhere along the path for being too big and the server never learns that this is occurring (and neither do we). The server's response packets are disappearing into a PMTU black hole. So, we are close to 31 of 371. Anyway, i would liek to hear what people think whether we need to worry about this black holes or not Regards, marcelo > All failures together were 12% (51 out of 423). > > That isn't too terrible considering that IPv6 is rarely production > quality yet. > > (Note though that non-working IPv6 is often not much of a problem > because most applications fall back to IPv4, but PMTUD failures are a > big deal because there is no fallback.) > >>> Although PMTUD is enabled by default but if it is not as reliable as >>> hoped >>> fragmentation will be common within TCP connections. > > I don't see this... > > For fragmentation to happen with TCP, you need: > > 1. The IPv4 host has to have a "large" MTU > 2. The IPv6 host hass to have a "large" MTU > 3. There must be a link with a "small" MTU on the IPv6 path > 4. The IPv4 host has to set DF=0 > > Of course 1 and 2 are common. 3 is probably pretty common today > because of tunnels, but assuming a NAT64 run by an ISP, it would make > sense that the IPv6 path would be native so there is no reduction in > MTU size along the IPv6 path. 4 is quite uncommon, although it does > happen. > > I'd say that these conditions will only hold in a fraction of a > percent of all cases. > > It would be more common for video streaming over UDP, though. > From iljitsch@muada.com Fri Oct 30 03:25:25 2009 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 E2F783A68CD for <behave@core3.amsl.com>; Fri, 30 Oct 2009 03:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsvJHVanS5Kn for <behave@core3.amsl.com>; Fri, 30 Oct 2009 03:25:25 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id BB16E3A686D for <behave@ietf.org>; Fri, 30 Oct 2009 03:25:24 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.216]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n9UAP0Is078211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Oct 2009 11:25:01 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <4AEABA2A.8060605@it.uc3m.es> Date: Fri, 30 Oct 2009 11:25:34 +0100 Content-Transfer-Encoding: 7bit Message-Id: <8C0D13AE-87FB-41E8-B08F-737E67D84F38@muada.com> References: <4AEABA2A.8060605@it.uc3m.es> To: marcelo bagnulo braun <marcelo@it.uc3m.es> X-Mailer: Apple Mail (2.1076) Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] nit on stateless document 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, 30 Oct 2009 10:25:26 -0000 On 30 okt 2009, at 11:04, marcelo bagnulo braun wrote: > the stateless document reads: > An IPv6 link has to have an MTU of 1280 bytes or greater. The > corresponding limit for IPv4 is 68 bytes. > I guess it is 576 bytes? RFC 791: Every internet module must be able to forward a datagram of 68 octets without further fragmentation. This is because an internet header may be up to 60 octets, and the minimum fragment is 8 octets. Every internet destination must be able to receive a datagram of 576 octets either in one piece or in fragments to be reassembled. RFC 1144: To illustrate, note that for a 9600 bps line with header compression there is essentially no benefit in increasing the MTU beyond 200 bytes: If the MTU is increased to 576, the average delay increases by 188% while throughput only improves by 3% (from 96 to 99%). RFC 1191: Plateau MTU Comments Reference ------ --- -------- --------- 65535 Official maximum MTU RFC 791 65535 Hyperchannel RFC 1044 65535 32000 Just in case 17914 16Mb IBM Token Ring ref. [6] 17914 8166 IEEE 802.4 RFC 1042 8166 4464 IEEE 802.5 (4Mb max) RFC 1042 4352 FDDI (Revised) RFC 1188 4352 (1%) 2048 Wideband Network RFC 907 2002 IEEE 802.5 (4Mb recommended) RFC 1042 2002 (2%) 1536 Exp. Ethernet Nets RFC 895 1500 Ethernet Networks RFC 894 1500 Point-to-Point (default) RFC 1134 1492 IEEE 802.3 RFC 1042 1492 (3%) 1006 SLIP RFC 1055 1006 ARPANET BBN 1822 1006 576 X.25 Networks RFC 877 544 DEC IP Portal ref. [10] 512 NETBIOS RFC 1088 508 IEEE 802/Source-Rt Bridge RFC 1042 508 ARCNET RFC 1051 508 (13%) 296 Point-to-Point (low delay) RFC 1144 296 68 Official minimum MTU RFC 791 (note that "296" doesn't appear in RFC 1144.) From marcelo@it.uc3m.es Fri Oct 30 04:19:35 2009 Return-Path: <marcelo@it.uc3m.es> 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 5D7473A689A for <behave@core3.amsl.com>; Fri, 30 Oct 2009 04:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHzeHONdN+1H for <behave@core3.amsl.com>; Fri, 30 Oct 2009 04:19:34 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 5B71B3A6889 for <behave@ietf.org>; Fri, 30 Oct 2009 04:19:34 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp01.uc3m.es (Postfix) with ESMTP id E54D0BA592B for <behave@ietf.org>; Fri, 30 Oct 2009 12:19:49 +0100 (CET) Message-ID: <4AEACBD5.7090700@it.uc3m.es> Date: Fri, 30 Oct 2009 12:19:49 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Behave WG <behave@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16978.003 Subject: [BEHAVE] ICMP extensions 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, 30 Oct 2009 11:19:35 -0000 Hi, I am trying to understand how to handle ICMP extensions. In the current draft, the text covering extensions is: 2.3. Translating ICMPv4 Headers into ICMPv6 Headers ... ICMP Error Payload The [RFC4884] length field should be updated to reflect the changed length of the datagram. There are two cases for the length field modifications. That the translated packet is created from scratch and the length field never is filled in. Then an ICMP extension will result in that it will be treated as part of the original datagram field. If the IP payload is copied and then modified then the length field will be unmodified while the original datagram field will become longer by the address translation from v4->v6. Thus cutting off the end of the original datagram field for ICMP extension aware receivers. information. However, i have not found text covering the ICMP extension translation in the other direction and afaiu, icmpv6 messages can also contain extension, correct? Regards, marcelo From rpenno@juniper.net Fri Oct 30 04:21:01 2009 Return-Path: <rpenno@juniper.net> 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 CADC83A6889 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 04:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.534 X-Spam-Level: X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wctpjyx6bkw3 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 04:21:01 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id B17FD3A67D4 for <behave@ietf.org>; Fri, 30 Oct 2009 04:20:42 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSurMGxjKW8ytanvyPP3Se2Zo6Im+VVCK@postini.com; Fri, 30 Oct 2009 04:21:18 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 30 Oct 2009 04:18:18 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 30 Oct 2009 07:18:18 -0400 From: Reinaldo Penno <rpenno@juniper.net> To: Iljitsch van Beijnum <iljitsch@muada.com>, marcelo bagnulo braun <marcelo@it.uc3m.es> Date: Fri, 30 Oct 2009 07:18:15 -0400 Thread-Topic: [BEHAVE] How to set the DF and the ID values for IPv4 packets (was Re: Amount of fragmentation resulting from translation Thread-Index: AcpZSnWtwQyp1zvxTnuPTp2a+ImFGQACDbVs Message-ID: <C7101987.74EF%rpenno@juniper.net> In-Reply-To: <91797A55-22AF-42C9-9EB0-A0ED5C177AF3@muada.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Stig Venaas <stig@venaas.com>, Behave WG <behave@ietf.org>, Mark Andrews <marka@isc.org>, "Ben@wand.net.nz" <Ben@wand.net.nz> Subject: Re: [BEHAVE] How to set the DF and the ID values for IPv4 packets (was Re: Amount of fragmentation resulting from translation 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, 30 Oct 2009 11:21:01 -0000 Inline.... On 10/30/09 3:19 AM, "Iljitsch van Beijnum" <iljitsch@muada.com> wrote: > On 30 okt 2009, at 09:34, marcelo bagnulo braun wrote: >=20 >> In particular, what i extract from this analysis is that there is a >> non negligible amount of IPv6 hosts/sites that filter the packet too >> big errors and simply send packets of 1280 bytes (about 15% if i >> read it correctly). >=20 > Actual PMTUD failures were only 9 out of 380 =3D 2.4%. All failures > together were 12% (51 out of 423). >=20 > That isn't too terrible considering that IPv6 is rarely production > quality yet. >=20 > (Note though that non-working IPv6 is often not much of a problem > because most applications fall back to IPv4, but PMTUD failures are a > big deal because there is no fallback.) >=20 >>> Although PMTUD is enabled by default but if it is not as reliable >>> as hoped >>> fragmentation will be common within TCP connections. >=20 > I don't see this... >=20 > For fragmentation to happen with TCP, you need: >=20 > 1. The IPv4 host has to have a "large" MTU > 2. The IPv6 host hass to have a "large" MTU > 3. There must be a link with a "small" MTU on the IPv6 path > 4. The IPv4 host has to set DF=3D0 >=20 > Of course 1 and 2 are common. 3 is probably pretty common today > because of tunnels, but assuming a NAT64 run by an ISP, it would make > sense that the IPv6 path would be native so there is no reduction in > MTU size along the IPv6 path. 4 is quite uncommon, although it does > happen. If IPV6 MTU on the IPv6 side of the translator is 1280 (proposed default without PMTUD), IPv4 MTU on host is 1492, and DF=3D1, then the problem beco= mes the number ICMP too big messages. >=20 > I'd say that these conditions will only hold in a fraction of a > percent of all cases. >=20 > It would be more common for video streaming over UDP, though. From iljitsch@muada.com Fri Oct 30 04:44:18 2009 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 94E8F3A68A8 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 04:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2zzrvLLmykG for <behave@core3.amsl.com>; Fri, 30 Oct 2009 04:44:17 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id CF5133A68A0 for <behave@ietf.org>; Fri, 30 Oct 2009 04:44:15 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.216]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n9UBhjEM079817 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Oct 2009 12:43:45 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <C7101987.74EF%rpenno@juniper.net> Date: Fri, 30 Oct 2009 12:44:18 +0100 Content-Transfer-Encoding: 7bit Message-Id: <68544CCF-65CE-4478-9048-B91474761707@muada.com> References: <C7101987.74EF%rpenno@juniper.net> To: Reinaldo Penno <rpenno@juniper.net> X-Mailer: Apple Mail (2.1076) Cc: Stig Venaas <stig@venaas.com>, Behave WG <behave@ietf.org>, Mark Andrews <marka@isc.org>, "Ben@wand.net.nz" <Ben@wand.net.nz> Subject: Re: [BEHAVE] How to set the DF and the ID values for IPv4 packets (was Re: Amount of fragmentation resulting from translation 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, 30 Oct 2009 11:44:18 -0000 On 30 okt 2009, at 12:18, Reinaldo Penno wrote: > If IPV6 MTU on the IPv6 side of the translator is 1280 (proposed > default > without PMTUD), IPv4 MTU on host is 1492, and DF=1, then the problem > becomes > the number ICMP too big messages. Not sure why the IPv4 MTU would be 1492 and not 1500 (you would be inviting a world of hurt with that), but a 1280 MTU on the IPv6 side is a very bad idea for exactly the reason that you mention: now you have to send too big messages for pretty much every TCP session. If the MTU on both sides of the translator is 1500, on the other hand, the TCP MSS option will make sure that IPv4 hosts send 1480-byte packets (1440 MSS + 20 bytes of IP + 20 bytes of TCP) which will then be translated into 1500-byte IPv6 packets and life is good. This way, we only have to worry about packets with DF=0, as per the previous discussion. Just in case anyone missed it: either fragment IPv4 packets with DF=0 into max 1280-byte fragments in all cases, or act as an IPv6 host and track the PMTU of IPv6 destinations and fragment as necessary. But for DF=1 you really want to be able to handle 1500-byte packets to avoid ugly hacks and/or unnecessarily triggering PMTUD black holes. (Although you must still be prepared to send back too bigs to IPv4 hosts when the IPv6 host announces an MSS larger than 1440, which would happen if the IPv6 host has a local MTU larger than 1500.) From ajs@shinkuro.com Fri Oct 30 06:11:54 2009 Return-Path: <ajs@shinkuro.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 324D53A6926 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 06:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.033 X-Spam-Level: X-Spam-Status: No, score=-2.033 tagged_above=-999 required=5 tests=[AWL=0.566, 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 174VwmOxNhiu for <behave@core3.amsl.com>; Fri, 30 Oct 2009 06:11:53 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 74C793A699D for <behave@ietf.org>; Fri, 30 Oct 2009 06:11:53 -0700 (PDT) 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 ECC202FE8CDC for <behave@ietf.org>; Fri, 30 Oct 2009 13:12:07 +0000 (UTC) Date: Fri, 30 Oct 2009 09:12:03 -0400 From: Andrew Sullivan <ajs@shinkuro.com> To: behave@ietf.org Message-ID: <20091030131202.GA76006@shinkuro.com> References: <20091029202756.GP65688@shinkuro.com> <E4561B14EE2A3E4E9D478EBFB5416E1B29B25AB0@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <E4561B14EE2A3E4E9D478EBFB5416E1B29B25AB0@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] DNS64 and limiting data sharing across interfaces 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, 30 Oct 2009 13:11:54 -0000 On Thu, Oct 29, 2009 at 09:56:30PM +0000, Dave Thaler wrote: > It's not clear to me whether the quoted text is talking about the > DNS64 itself being multihomed, or a client using it. It's supposed to be for a client using it (which client could, of course, also be doing the dns64 function, but that's irrelevant). > I think it would be inappropriate for the DNS64 document (which specifies > a DNS64 and hence a DNS64 implementation would claim conformance to) > to use RFC 2119 language that would apply to other entities, like > end hosts / DNS clients using the DNS64 unknowingly. Good point. I'll see whether I can rework it along the lines I suggested yesterday. If so, I'll post a proposed revision. The window for full document updates is closed until Hiroshima, of course. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From marka@isc.org Fri Oct 30 06:20:18 2009 Return-Path: <marka@isc.org> 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 BCC8F3A6945 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 06:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 lt0iUStgWjDZ for <behave@core3.amsl.com>; Fri, 30 Oct 2009 06:20:18 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id D77803A67A1 for <behave@ietf.org>; Fri, 30 Oct 2009 06:20:17 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 47A50E6026; Fri, 30 Oct 2009 13:20:33 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n9UDKTOs099079; Sat, 31 Oct 2009 00:20:30 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200910301320.n9UDKTOs099079@drugs.dv.isc.org> To: marcelo bagnulo braun <marcelo@it.uc3m.es> From: Mark Andrews <marka@isc.org> References: <4AE94ED6.5050600@it.uc3m.es> <B7943394-8740-4292-B0FF-1050B0DFD3FF@muada.com> <4AEA18CE.8040302@venaas.com> <200910292329.n9TNTmCx075617@drugs.dv.isc.org> <4AEAA15C.4060900@it.uc3m.es> In-reply-to: Your message of "Fri, 30 Oct 2009 09:18:36 BST." <4AEAA15C.4060900@it.uc3m.es> Date: Sat, 31 Oct 2009 00:20:29 +1100 Sender: marka@isc.org Cc: Stig Venaas <stig@venaas.com>, Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Amount of fragmentation resulting from translation 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, 30 Oct 2009 13:20:18 -0000 In message <4AEAA15C.4060900@it.uc3m.es>, marcelo bagnulo braun writes: > Mark Andrews escribió: > > > > > > I think turning on PMTUD in the middle of the network is just plain > > wrong. There are OS which incorrectly turn on PMTUD for IPv4 for > > all packets. This causes problems for applications like DNS servers. > > > > There is only one choice and that is to fragment at network MTU. Anything > > else will cause operational problems. > > > > > Just to be clear, you support the option that the translator always > sends IPv6 packet of 1280 bytes rahter than the translator doing pmtud > to figure out which is the mtu availbale for that path, correct? > > Regards, marcelo Yes. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dwing@cisco.com Fri Oct 30 08:39:41 2009 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 F28293A67E6 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 08:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.278 X-Spam-Level: X-Spam-Status: No, score=-6.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKLx9BiYclr3 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 08:39:40 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 3351B3A6782 for <behave@ietf.org>; Fri, 30 Oct 2009 08:39:40 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAOul6kqrR7Ht/2dsb2JhbACKYL8NmC2EPQSBYg X-IronPort-AV: E=Sophos;i="4.44,654,1249257600"; d="scan'208";a="47424440" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 30 Oct 2009 15:39:57 +0000 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9UFdvtA025317; Fri, 30 Oct 2009 15:39:57 GMT From: "Dan Wing" <dwing@cisco.com> To: "'Zhen Cao'" <caozhenpku@gmail.com> References: <004501ca5879$938933d0$3a0c6f0a@china.huawei.com> <4AE96AFB.5000406@it.uc3m.es> <3db7b9d60910290759k4314a976p1b8750417b0c03d8@mail.gmail.com> <20091029151219.GG65688@shinkuro.com> <1d1001ca58b6$d05fec80$c5f0200a@cisco.com> <a7c8d0a30910292044t40f28931v9262cecac516f26a@mail.gmail.com> Date: Fri, 30 Oct 2009 08:39:57 -0700 Message-ID: <207301ca5977$3c0e4970$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpZE1USQnkTxvm0QN6BojEMPTGFOwAYxxZw In-Reply-To: <a7c8d0a30910292044t40f28931v9262cecac516f26a@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: 'Andrew Sullivan' <ajs@shinkuro.com>, behave@ietf.org Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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, 30 Oct 2009 15:39:41 -0000 > On Fri, Oct 30, 2009 at 12:42 AM, Dan Wing <dwing@cisco.com> wrote: > >> On Thu, Oct 29, 2009 at 10:59:35PM +0800, Kai Ju wrote: > >> > jiang sheng's pre condition is quite clear, by including > >> > other author, this draft could be adopted. > >> > >> I'm not sure how our Chairs prefer to work these matters,=20 > but it is my > >> understanding that the editors of a draft which is to be a=20 > WG product > >> normally serve at the pleasure of the Chairs. =A0Therefore, I don't > >> believe the WG participants are in a position to insist on one or > >> another editor for the draft as a condition of making it a WG work > >> item. =A0"Is the _draft_ to be worked on by the WG?" is the=20 > question, as > >> I understand it. =A0The Chairs might well decide that=20 > someone previously > >> entirely unconnected to this effort will hold the pen, and that's > >> something they get to choose after the WG has expressed its > >> willingness to adopt the work item. > > > > Yes, the question at hand is 'shall we adopt this document'. =A0I > > did not ask 'who wants to be an author'. > > > > I have not seen a substantive objection since I asked a week ago > > (Oct 22). >=20 > Note that i raised some questions and do not think the current draft > is a solid basis, although chairs do not think they are fundamental > issues. Yes, I made note of the comments, and as I indicated in my reply they can be corrected. Documents are not perfect -- or complete -- when adopted by the working group. Once the working group adopts the document, the working group has change control over the=20 document and can direct the authors to make the changes the WG deems necessary. > I do not know what can be a 'fundamental' issue. Thanks. For example, the technique described in the document will=20 not work as expected / desired. -d From simon.perreault@viagenie.ca Fri Oct 30 08:49:35 2009 Return-Path: <simon.perreault@viagenie.ca> 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 3B0C13A6A87 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 08:49:35 -0700 (PDT) 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 SzXncwBEdVvU for <behave@core3.amsl.com>; Fri, 30 Oct 2009 08:49:34 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 94FEC28C114 for <behave@ietf.org>; Fri, 30 Oct 2009 08:49:29 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPA id 8633421BBB for <behave@ietf.org>; Fri, 30 Oct 2009 11:49:46 -0400 (EDT) Message-ID: <4AEB0B1A.8020703@viagenie.ca> Date: Fri, 30 Oct 2009 11:49:46 -0400 From: Simon Perreault <simon.perreault@viagenie.ca> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4 MIME-Version: 1.0 To: behave@ietf.org References: <4AEABBB2.1090708@it.uc3m.es> In-Reply-To: <4AEABBB2.1090708@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] Summary of the issues related to fragmentation and v4/v6 translation 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, 30 Oct 2009 15:49:35 -0000 Adding to your question list... marcelo bagnulo braun wrote, on 2009-10-30 06:10: > - Fragment: Add fragment header, copy fields from IPv4 header, also make > sure > that the packet does not exceeds 1280 bytes. If the fragment exceeds 1280 bytes, do you just fragment the fragment by itself, or wait for the other fragments to arrive then fragment the reassembled packet as a whole? If you're going to do reassembly anyway you might as well fragment the packet as a whole. However that would need changing text in the stateless draft (section 2.1, first paragraph). Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From rpenno@juniper.net Fri Oct 30 09:34:08 2009 Return-Path: <rpenno@juniper.net> 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 C287C28C106 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 09:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJHe68WS-q5D for <behave@core3.amsl.com>; Fri, 30 Oct 2009 09:34:08 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id BA31728C102 for <behave@ietf.org>; Fri, 30 Oct 2009 09:33:52 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKSusVgWcvl/15AQhy6hX/jJSjh/993c+L@postini.com; Fri, 30 Oct 2009 09:34:25 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 30 Oct 2009 09:30:42 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 30 Oct 2009 12:30:37 -0400 From: Reinaldo Penno <rpenno@juniper.net> To: Iljitsch van Beijnum <iljitsch@muada.com> Date: Fri, 30 Oct 2009 12:30:33 -0400 Thread-Topic: [BEHAVE] How to set the DF and the ID values for IPv4 packets (was Re: Amount of fragmentation resulting from translation Thread-Index: AcpZVmLfdaaRfOzkQXCmoDxlnTWBvwAJ+pcT Message-ID: <C71062B9.754B%rpenno@juniper.net> In-Reply-To: <68544CCF-65CE-4478-9048-B91474761707@muada.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Stig Venaas <stig@venaas.com>, Behave WG <behave@ietf.org>, Mark Andrews <marka@isc.org>, "Ben@wand.net.nz" <Ben@wand.net.nz> Subject: Re: [BEHAVE] How to set the DF and the ID values for IPv4 packets (was Re: Amount of fragmentation resulting from translation 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, 30 Oct 2009 16:34:08 -0000 It is the norm in on ADSL/PPPoE deployments. Thanks, On 10/30/09 4:44 AM, "Iljitsch van Beijnum" <iljitsch@muada.com> wrote: > Not sure why the IPv4 MTU would be 1492 and not 1500 (you would be > inviting a world of hurt with that), From iljitsch@muada.com Fri Oct 30 09:38:56 2009 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 E5D083A69B8 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 09:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id we+jcyU4+NK6 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 09:38:56 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id EB5623A685B for <behave@ietf.org>; Fri, 30 Oct 2009 09:38:55 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.216]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n9UGcR47082975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Oct 2009 17:38:28 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <C71062B9.754B%rpenno@juniper.net> Date: Fri, 30 Oct 2009 17:39:01 +0100 Content-Transfer-Encoding: 7bit Message-Id: <D64DA65F-1E67-4F5F-9294-CEF83EEA2BC7@muada.com> References: <C71062B9.754B%rpenno@juniper.net> To: Reinaldo Penno <rpenno@juniper.net> X-Mailer: Apple Mail (2.1076) Cc: Stig Venaas <stig@venaas.com>, Behave WG <behave@ietf.org>, Mark Andrews <marka@isc.org>, "Ben@wand.net.nz" <Ben@wand.net.nz> Subject: Re: [BEHAVE] How to set the DF and the ID values for IPv4 packets (was Re: Amount of fragmentation resulting from translation 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, 30 Oct 2009 16:38:57 -0000 On 30 okt 2009, at 17:30, Reinaldo Penno wrote: > It is the norm in on ADSL/PPPoE deployments. But weren't we talking about the translator's MTU? I would assume those aren't hooked up to an ADSL link. From stig@venaas.com Fri Oct 30 10:00:23 2009 Return-Path: <stig@venaas.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 44AC43A69E7 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 10:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.103, 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 I-2ECqw8vQ-9 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 10:00:22 -0700 (PDT) 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 277783A67EC for <behave@ietf.org>; Fri, 30 Oct 2009 10:00:22 -0700 (PDT) Received: from [IPv6:2001:420:1:fff:0:5efe:10.32.214.37] (unknown [IPv6:2001:420:1:fff:0:5efe:a20:d625]) by ufisa.uninett.no (Postfix) with ESMTP id 8DE5E23181; Fri, 30 Oct 2009 18:00:36 +0100 (CET) Message-ID: <4AEB1BB4.6070903@venaas.com> Date: Fri, 30 Oct 2009 10:00:36 -0700 From: Stig Venaas <stig@venaas.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Iljitsch van Beijnum <iljitsch@muada.com> References: <C71062B9.754B%rpenno@juniper.net> <D64DA65F-1E67-4F5F-9294-CEF83EEA2BC7@muada.com> In-Reply-To: <D64DA65F-1E67-4F5F-9294-CEF83EEA2BC7@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Ben@wand.net.nz" <Ben@wand.net.nz>, Behave WG <behave@ietf.org>, Mark Andrews <marka@isc.org> Subject: Re: [BEHAVE] How to set the DF and the ID values for IPv4 packets (was Re: Amount of fragmentation resulting from translation 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, 30 Oct 2009 17:00:23 -0000 Iljitsch van Beijnum wrote: > On 30 okt 2009, at 17:30, Reinaldo Penno wrote: > >> It is the norm in on ADSL/PPPoE deployments. > > But weren't we talking about the translator's MTU? I would assume those > aren't hooked up to an ADSL link. The main issue is really that with the typical IPv4 end-point MTU, you will need to fragment because of the increased size of the IPv6 header. It doesn't help much with 1492. I would argue anyway that there are lots of deployments where the IPv4 end-point MTU is 1500. Stig From dwing@cisco.com Fri Oct 30 10:09:11 2009 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 D5AA23A6A87 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 10:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGancqkfgMwI for <behave@core3.amsl.com>; Fri, 30 Oct 2009 10:09:11 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 083163A69CA for <behave@ietf.org>; Fri, 30 Oct 2009 10:09:11 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEABK66kqrR7Ht/2dsb2JhbACKX75wmC+EPQSBYg X-IronPort-AV: E=Sophos;i="4.44,654,1249257600"; d="scan'208";a="101628320" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 30 Oct 2009 17:09:28 +0000 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9UH9SX6006177; Fri, 30 Oct 2009 17:09:28 GMT From: "Dan Wing" <dwing@cisco.com> To: <mohamed.boucadair@orange-ftgroup.com> References: <20091019180002.1AFBE3A692D@core3.amsl.com><20091019181555.GC9536@shinkuro.com><18034D4D7FE9AE48BF19AB1B0EF2729F3EF10EF424@NOK-EUMSG-01.mgdnok.nokia.com><6B55F0F93C3E9D45AF283313B8D342BA211C9BC9@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <23132_1256211881_4AE045A9_23132_13404_1_94C682931C08B048B7A8645303FDC9F30781B159F8@PUEXCB1B.nanterre.francetelecom.fr> <02d401ca533a$4893ba10$5ba36b80@cisco.com> <25123_1256477648_4AE453D0_25123_1358_1_94C682931C08B048B7A8645303FDC9F30781B161A8@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 30 Oct 2009 10:09:27 -0700 Message-ID: <20d101ca5983$bd269290$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AQHKUOZcB4qVxczK40+zVvgdVO4zY5ENo/MAgAFHKICAAUzkUIABPuwwgABYBaCABH3VwIAIFv2A In-Reply-To: <25123_1256477648_4AE453D0_25123_1358_1_94C682931C08B048B7A8645303FDC9F30781B161A8@PUEXCB1B.nanterre.francetelecom.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: ajs@shinkuro.com, draft-boucadair-behave-dns-a64@tools.ietf.org, behave@ietf.org Subject: Re: [BEHAVE] draft-boucadair-behave-dns-a64-00.txt [was RE: I-D Action:draft-ietf-behave-dns64-01.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: Fri, 30 Oct 2009 17:09:11 -0000 =20 > -----Original Message----- > From: mohamed.boucadair@orange-ftgroup.com=20 > [mailto:mohamed.boucadair@orange-ftgroup.com]=20 > Sent: Sunday, October 25, 2009 6:34 AM > To: Dan Wing > Cc: 'Christian Huitema'; teemu.savolainen@nokia.com;=20 > ajs@shinkuro.com; behave@ietf.org;=20 > draft-boucadair-behave-dns-a64@tools.ietf.org > Subject: RE: draft-boucadair-behave-dns-a64-00.txt [was RE:=20 > [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt] >=20 >=20 > Hi Dan, all, >=20 > I'm aware about that mode. In fact it is also part of=20 > draft-boucadair spec.=20 Where? I cannot find the string "CD", "DO", or "bit". > The procedure described in=20 > draft-ietf-behave-dns64 is assumed as the first step.=20 > draft-boucadair is a step forward to solve some pending=20 > issues as elaborated in 01 version of draft-boucadair. Please=20 > refer to Section Q/A of the updated draft for more discussion. >=20 > Do you have in mind explicit "disadvantages"? DNS64 already supports the ability for a host to get an=20 un-synthesized response (that is, effectively send a query that does not invoke the DNS64 function). A dual-stack host can simply do that -- without needing changes to the DNS64 specification and without needing a new RR. -d > Cheers, > Med=20 >=20 > -----Message d'origine----- > De : Dan Wing [mailto:dwing@cisco.com]=20 > Envoy=E9 : jeudi 22 octobre 2009 19:09 > =C0 : BOUCADAIR Mohamed NCPI/NAD/TIP > Cc : 'Christian Huitema'; teemu.savolainen@nokia.com;=20 > ajs@shinkuro.com; behave@ietf.org;=20 > draft-boucadair-behave-dns-a64@tools.ietf.org > Objet : draft-boucadair-behave-dns-a64-00.txt [was RE:=20 > [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt] >=20 > > FYI, we have submitted a draft to describe the A64 record for=20 > > IPv4-mapped IPv6 addresses. An updated version of the draft will be=20 > > submitted soon >=20 > draft-boucadair-behave-dns-a64-00 requires the DNS64 and the=20 > host to implement a new DNS resource record, A64, in order to=20 > learn if the DNS64 synthesized a response. >=20 > Instead, have you considered just having the host query an=20 > existing DNS64 with the CD and DO bits set (which disables=20 > the DNS64's AAAA synthesis) and have the host do its own=20 > DNS64 processing? See item #3 in > http://tools.ietf.org/html/draft-ietf-behave-dns64-01#section-5.5 >=20 > If you have considered that technique, I expect you found=20 > some sort of disadvantage to that technique. Please share. >=20 > -d >=20 >=20 > ********************************* > This message and any attachments (the "message") are=20 > confidential and intended 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=20 > altered, changed or falsified. > If you are not the intended addressee of this message, please=20 > cancel it immediately and inform the sender. > ******************************** >=20 From iljitsch@muada.com Fri Oct 30 10:14:50 2009 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 2BA7B3A67F1 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 10:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRHG1XTMLGo1 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 10:14:49 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id F3DCF3A67CF for <behave@ietf.org>; Fri, 30 Oct 2009 10:14:48 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.216]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n9UHEOh2083336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Oct 2009 18:14:25 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <4AEB1BB4.6070903@venaas.com> Date: Fri, 30 Oct 2009 18:14:58 +0100 Content-Transfer-Encoding: 7bit Message-Id: <A86EDB2F-BBD7-4D2A-9581-48C52A19F6B9@muada.com> References: <C71062B9.754B%rpenno@juniper.net> <D64DA65F-1E67-4F5F-9294-CEF83EEA2BC7@muada.com> <4AEB1BB4.6070903@venaas.com> To: Stig Venaas <stig@venaas.com> X-Mailer: Apple Mail (2.1076) Cc: "Ben@wand.net.nz" <Ben@wand.net.nz>, Behave WG <behave@ietf.org>, Mark Andrews <marka@isc.org> Subject: Re: [BEHAVE] How to set the DF and the ID values for IPv4 packets (was Re: Amount of fragmentation resulting from translation 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, 30 Oct 2009 17:14:50 -0000 On 30 okt 2009, at 18:00, Stig Venaas wrote: > The main issue is really that with the typical IPv4 end-point MTU, you > will need to fragment because of the increased size of the IPv6 > header. > It doesn't help much with 1492. I would argue anyway that there are > lots > of deployments where the IPv4 end-point MTU is 1500. The TCP maximum segment size option hides a multitude of sins. :-) IPv6 host with MTU = 1500 IPv4 host with MTU = 1500 IPv6 host sends SYN with MSS=1440 (1500 - 40 bytes IP - 20 bytes TCP) IPv4 host sends SYN/ACK with MSS=1460 (1500 - 20 bytes IP - 20 bytes TCP) This means that the IPv6 host will send packets that are 1500 bytes. Based on the IPv4 host's MSS it could send 1460 + 40 IP + 20 TCP = 1520 bytes but since it has a 1500 MTU it will be sending 1500-byte packets which are translated into 1480-byte packets. The IPv4 host will send packets that are 1480 bytes: 1440 bytes from the MSS + 20 IP + 20 TCP. These packets will be translated into 1500- byte IPv6 packets. Note that PMTUD doesn't come into play here for TCP. Also note that nothing changes with an MTU of 1492 on the IPv4 side. Other example: IPv6 host with MTU = 9000 IPv4 host with MTU = 1500 Translator with MTUs = 1500 In this case, the IPv4 host will send 1500-byte packets which are translated into 1520-byte packets so the translator has to send an ICMP packet too big message if DF=1 to the IPv4 host, and fragment if DF=0. So in this case there is an increased possibility of PMTUD black holes, but that is to be expected with a > 1500 MTU. From rpenno@juniper.net Fri Oct 30 10:49:56 2009 Return-Path: <rpenno@juniper.net> 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 311823A6782 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 10:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQceiwd91erp for <behave@core3.amsl.com>; Fri, 30 Oct 2009 10:49:55 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id EB04F3A691F for <behave@ietf.org>; Fri, 30 Oct 2009 10:49:42 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSusnRqI5xHJg8cvKJfcTLkocIDYdQzXK@postini.com; Fri, 30 Oct 2009 10:50:12 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 30 Oct 2009 10:46:44 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 30 Oct 2009 13:46:43 -0400 From: Reinaldo Penno <rpenno@juniper.net> To: Stig Venaas <stig@venaas.com>, Iljitsch van Beijnum <iljitsch@muada.com> Date: Fri, 30 Oct 2009 13:46:42 -0400 Thread-Topic: [BEHAVE] How to set the DF and the ID values for IPv4 packets (was Re: Amount of fragmentation resulting from translation Thread-Index: AcpZgoNSIxCVbhiXQtGd+eVAYqDyBAABm0/x Message-ID: <C7107492.7583%rpenno@juniper.net> In-Reply-To: <4AEB1BB4.6070903@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Ben@wand.net.nz" <Ben@wand.net.nz>, Behave WG <behave@ietf.org>, Mark Andrews <marka@isc.org> Subject: Re: [BEHAVE] How to set the DF and the ID values for IPv4 packets (was Re: Amount of fragmentation resulting from translation 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, 30 Oct 2009 17:49:56 -0000 I agree that many deployments where the MTU is 1500. The 1492 was just an example of a type of MTU that is common in ADSL/PPPoE deployments. On 10/30/09 10:00 AM, "Stig Venaas" <stig@venaas.com> wrote: > Iljitsch van Beijnum wrote: >> On 30 okt 2009, at 17:30, Reinaldo Penno wrote: >>=20 >>> It is the norm in on ADSL/PPPoE deployments. >>=20 >> But weren't we talking about the translator's MTU? I would assume those >> aren't hooked up to an ADSL link. >=20 > The main issue is really that with the typical IPv4 end-point MTU, you > will need to fragment because of the increased size of the IPv6 header. > It doesn't help much with 1492. I would argue anyway that there are lots > of deployments where the IPv4 end-point MTU is 1500. >=20 > Stig >=20 From marcelo@it.uc3m.es Fri Oct 30 11:25:20 2009 Return-Path: <marcelo@it.uc3m.es> 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 435143A6808 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 11:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-Ggr4K6Qfwz for <behave@core3.amsl.com>; Fri, 30 Oct 2009 11:25:19 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 7137A3A6872 for <behave@ietf.org>; Fri, 30 Oct 2009 11:25:19 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.30.173]) by smtp03.uc3m.es (Postfix) with ESMTP id E760C72D110; Fri, 30 Oct 2009 19:25:33 +0100 (CET) Message-ID: <4AEB2F90.7040500@it.uc3m.es> Date: Fri, 30 Oct 2009 19:25:20 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Simon Perreault <simon.perreault@viagenie.ca> References: <4AEABBB2.1090708@it.uc3m.es> <4AEB0B1A.8020703@viagenie.ca> In-Reply-To: <4AEB0B1A.8020703@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16980.000 Cc: behave@ietf.org Subject: Re: [BEHAVE] Summary of the issues related to fragmentation and v4/v6 translation 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, 30 Oct 2009 18:25:20 -0000 right thanks, marcelo Simon Perreault escribió: > Adding to your question list... > > marcelo bagnulo braun wrote, on 2009-10-30 06:10: > >> - Fragment: Add fragment header, copy fields from IPv4 header, also make >> sure >> that the packet does not exceeds 1280 bytes. >> > > If the fragment exceeds 1280 bytes, do you just fragment the fragment by itself, > or wait for the other fragments to arrive then fragment the reassembled packet > as a whole? > > If you're going to do reassembly anyway you might as well fragment the packet as > a whole. However that would need changing text in the stateless draft (section > 2.1, first paragraph). > > Simon > From marcelo@it.uc3m.es Fri Oct 30 11:27:09 2009 Return-Path: <marcelo@it.uc3m.es> 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 128DA3A68AE for <behave@core3.amsl.com>; Fri, 30 Oct 2009 11:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QK5gaOL8-7Rn for <behave@core3.amsl.com>; Fri, 30 Oct 2009 11:27:08 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 453DE3A68BF for <behave@ietf.org>; Fri, 30 Oct 2009 11:27:08 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.30.173]) by smtp02.uc3m.es (Postfix) with ESMTP id 9A4346C1982; Fri, 30 Oct 2009 19:27:23 +0100 (CET) Message-ID: <4AEB2FFF.40206@it.uc3m.es> Date: Fri, 30 Oct 2009 19:27:11 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Iljitsch van Beijnum <iljitsch@muada.com> References: <C71062B9.754B%rpenno@juniper.net> <D64DA65F-1E67-4F5F-9294-CEF83EEA2BC7@muada.com> In-Reply-To: <D64DA65F-1E67-4F5F-9294-CEF83EEA2BC7@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16980.000 Cc: Stig Venaas <stig@venaas.com>, Behave WG <behave@ietf.org>, Mark Andrews <marka@isc.org>, "Ben@wand.net.nz" <Ben@wand.net.nz> Subject: Re: [BEHAVE] How to set the DF and the ID values for IPv4 packets (was Re: Amount of fragmentation resulting from translation 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, 30 Oct 2009 18:27:09 -0000 Iljitsch van Beijnum escribió: > On 30 okt 2009, at 17:30, Reinaldo Penno wrote: > >> It is the norm in on ADSL/PPPoE deployments. > > But weren't we talking about the translator's MTU? I would assume > those aren't hooked up to an ADSL link. > why not? you could put a nat64 in the cpe, right? From mrw@lilacglade.org Fri Oct 30 11:31:58 2009 Return-Path: <mrw@lilacglade.org> 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 BABE13A6841 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 11:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.532 X-Spam-Level: X-Spam-Status: No, score=-1.532 tagged_above=-999 required=5 tests=[AWL=-0.733, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0sYtbrVCQDz for <behave@core3.amsl.com>; Fri, 30 Oct 2009 11:31:57 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 37A4C3A68AA for <behave@ietf.org>; Fri, 30 Oct 2009 11:31:57 -0700 (PDT) Received: from OMTA15.westchester.pa.mail.comcast.net ([76.96.62.87]) by QMTA10.westchester.pa.mail.comcast.net with comcast id yzZ11c0051swQuc5A6YFL5; Fri, 30 Oct 2009 18:32:15 +0000 Received: from [10.2.0.20] ([69.33.111.74]) by OMTA15.westchester.pa.mail.comcast.net with comcast id z6g51c0011cMU3H3b6g7N7; Fri, 30 Oct 2009 18:40:14 +0000 Message-Id: <9009E8A3-5FFE-4692-8EC6-BD038C5E728D@lilacglade.org> From: Margaret Wasserman <mrw@lilacglade.org> To: Marc Petit-Huguenin <petithug@acm.org> In-Reply-To: <4AE4A119.5050007@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 30 Oct 2009 14:32:03 -0400 References: <01c101ca509f$f314a8c0$8e27460a@china.huawei.com> <61FFB311-CA42-4EE4-A6F9-3DE0581A9E8F@lilacglade.org> <4ADE0BAB.1040402@acm.org> <FF53CDBF-9204-490D-8D04-9DF806EFE275@lilacglade.org> <4AE0A9F0.2010106@acm.org> <839B17D7-0BDE-4F11-8DC6-BDF694F7521D@lilacglade.org> <4AE4A119.5050007@acm.org> X-Mailer: Apple Mail (2.936) Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Opsdir Review of draft-ietf-behave-turn-uri-03.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: Fri, 30 Oct 2009 18:31:58 -0000 Hi Marc, On Oct 25, 2009, at 3:03 PM, Marc Petit-Huguenin wrote: >> >> Were these tradeoffs discussed in the WG? > > No. Do you think they should be? > >> What were the reasons for >> choosing the current implicit processing approach? > > This design is inspired by RFC 3263. The idea is that domain > administrators can > choose to implement either A/AAAA or SRV+A/AAAA or NAPTR+SRV+A/AAAA > as they see > fit for their environment, but still use the same TURN URI. I understand that the current mechanism supports this type of fallback, but you could allow this type of fallback without deciding whether or not to try the S-NAPTR or DNS SRV lookups based on the presence (or lack) of the <port> and <transport> fields in the URI. For example, you could ignore the <port> and <transport> fields for the S-NAPTR lookup, and ignore the <transport> field for the DNS SRV lookup, and still fall back to using both them the (if present) when you do an A/AAAA lookup. In that case, the administrator would have even more flexibility, because he could run his servers on a non-default port and/or specify a specific transport, without needing to change the configuration of the end-user devices to allow them to step up to DNS SRV and/or S-NAPTR. At this point, the upgrade path you have described only works if the site is running TURN or TURNS on the default port. There are a number of alternatives here, and it seems to me that the one chosen in the draft is the least flexible. I am not saying that the choice in the draft is the wrong choice, because I don't know all of the tradeoffs that were considered, but this is something I definitely think would warrant some discussion in the WG, so that folks could reach informed consent on the right approach to use. >> (2) TURNS vs. TURN URIs: >> > > You are absolutely right, this is a bug in the spec, the ordered > list of TURN > transports should have been filtered by the <scheme> used. > > I propose to replace "...the TURN transports supported by the > application..." by > "...the filtered TURN transports supported by the application..." in > step #1 and > #2 and to add the following paragraph before paragraph 6: > > "After verifying the validity of the URI elements, the algorithm > filters the list of TURN transports supported by the application by > keeping only the UDP and TCP TURN transports if the <scheme> is > defined as "turn" and by keeping only the TLS TURN transport if the > <scheme> is defined as "turns". If the list of TURN transports is > empty after this filtering, the resolution MUST stop with an error." Looks good. > > and to modify paragraph 6 (now 7) like this: > > "After filtering the list of TURN transports supported by the > application, the algorithm applies the steps described below. Note > that in some steps, <scheme> and <transport> have to be converted to > [...]" Looks good. > > New proposed text: > > "2. If <host> is a domain name and <port> is defined, then <host> is > resolved to a list of IP addresses via DNS A and AAAA queries. > If <transport> is defined, then <scheme> and <transport> are > converted to a TURN transport as specified in Table 1. If > <transport> is not defined, the filtered TURN transports > supported by the application are tried in preference order. The > TURN client can choose the order to contact the resolved IP > addresses in any implementation-specific way. If the TURN client > cannot contact a TURN server with this port, the transport or > list of transports, and the resolved IP addresses, then the > resolution MUST stop with an error." Looks good. > I still think that examples must not be added until the text is so > clear that > the examples are useless. If no one else supports my position that example would be valuable, I will yield to your opinion on this point, as document editor. >> >> Will these connection attempts also use the <transport> defined >> above? Or will they use all of the transports supported by the >> application? > > This is specified by RFC 2782 section "Usage Rules": > > "else > Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A > > for each address record found, try to connect to the (protocol, > address, > service)" > > protocol been already defined as <transport>. Okay. That makes sense. Thanks. > >> >>> this specification modifies the SRV algorithm by recommending an A >>> and AAAA query. If the TURN client cannot contact a TURN server at >>> any of the IP address, port and transport tuples returned by the SRV >>> algorithm then the resolution MUST stop with an error." >> >> This has the same problem as the one you fixed in section 4. We >> don't return an error if the SRV fails, only if both the SRV lookup >> and the subsequent A/AAAA lookup fail, right? > > I disagree here. The text says "SRV algorithm" not "SRV query". > The fallback > to A is part of the SRV algorithm, not something added by this text, > so the > tuples returned by the SRV algorithm eventually contains the result > of the A > query (and AAAA as modified by the text). > > And thinking of it, I am not sure I should have modified step 4, but > see below. I understand what you are trying to say, but you haven't defined the term "SRV algorithm" (to include the A/AAAA lookup) anywhere, so it is my opinion that the meaning of this paragraph is still ambiguous. This is the type of thing that I think could be made very clear by an example, but if you don't want to include examples, you need to be very clear about the step by step process in each of these paragraphs. > "4. If <host> is a domain name and <port> and <transport> are not > defined, then <host> is converted to an ordered list of IP > address, port and transport tuples via the S-NAPTR algorithm > defined in [RFC3958] by using <host> as the initial target domain > name and "RELAY" as the Application Service Tag. The TURN > transports supported by the application are converted in > Application Protocol Tags by using "turn.udp" if the TURN > transport is UDP, "turn.tcp" if the TURN transport is TCP and > "turn.tls" if the TURN transport is TLS. The order to try the > Application Protocol Tags is provided by the ranking of the first > set of NAPTR records. If multiple Application Protocol Tags have > the same ranking, the preferred order set by the application is > used. If the TURN client cannot contact a TURN server with any > of the IP address, port and transport tuples returned by the > S-NAPTR algorithm then the resolution MUST stop with an error. > > 5. If the first NAPTR query in the previous step does not return any > result then <host> is converted to a list of IP address and port > tuples via a DNS SRV query as defined in [I-D.ietf-behave-turn] > section 6.1. The filtered TURN transports supported by the > application are tried in preference order for the Protocol, > <host> is used for the Name and <scheme> is used for the Service > in the SRV algorithm [RFC2782]. The SRV algorithm recommends > doing an A query if the SRV query returns an error or no SRV RR; > in this case the default port declared in [I-D.ietf-behave-turn] > for the SRV service name defined in <scheme> MUST be used for > contacting the TURN server. Also in this case, this > specification modifies the SRV algorithm by recommending an A and > AAAA query. If the TURN client cannot contact a TURN server at > any of the IP address, port and transport tuples returned by the > SRV algorithm then the resolution MUST stop with an error." I am not sure that it is valid to indicate that section 4 stops with an error, and then indicate that there are some cases where you would continue (presumably) without an error... Maybe you should add a line to section 4, in the middle, indicating that if the NAPTR query returns an error, you should proceed to step 5? Also, you mention "the first NAPTR query". Will there be more than one? If so, why and what will the subsequent queries contain? >> >> It is still not clear to me, from your text, how the S-NAPTR lookup >> would be constructed, but that may reflect my limited understanding >> of S-NAPTR. Could you give me an example of how the NAPTR query would be constructed from the URI? Margaret From rpenno@juniper.net Fri Oct 30 11:40:58 2009 Return-Path: <rpenno@juniper.net> 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 9C3723A6841 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 11:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6N1fC8QzvzDs for <behave@core3.amsl.com>; Fri, 30 Oct 2009 11:40:57 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 14AD83A6767 for <behave@ietf.org>; Fri, 30 Oct 2009 11:40:46 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKSuszPslbw4dG1o9qDCBKXTxSj7mCPStV@postini.com; Fri, 30 Oct 2009 11:41:15 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 30 Oct 2009 11:37:51 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 30 Oct 2009 14:37:47 -0400 From: Reinaldo Penno <rpenno@juniper.net> To: marcelo bagnulo braun <marcelo@it.uc3m.es>, Iljitsch van Beijnum <iljitsch@muada.com> Date: Fri, 30 Oct 2009 14:37:45 -0400 Thread-Topic: [BEHAVE] How to set the DF and the ID values for IPv4 packets (was Re: Amount of fragmentation resulting from translation Thread-Index: AcpZjqLibSQgRZdlRgCLj866B9GdBAAAW9je Message-ID: <C7108089.75B1%rpenno@juniper.net> In-Reply-To: <4AEB2FFF.40206@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Stig Venaas <stig@venaas.com>, Behave WG <behave@ietf.org>, Mark Andrews <marka@isc.org>, "Ben@wand.net.nz" <Ben@wand.net.nz> Subject: Re: [BEHAVE] How to set the DF and the ID values for IPv4 packets (was Re: Amount of fragmentation resulting from translation 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, 30 Oct 2009 18:40:58 -0000 Yes, it could. There was a discussion about NAT64 scenarios before and it served to point out that people have different views on the deployment scenarios.=20 As far as the ISP running the NAT64, one could argue that even if the NAT64 is in the CPE, that is 'run by the ISP' as well. There was also a Microsoft direct access scenario sent to the list. Suggestion:=20 My suggestion then was that the NAT64 document should have an 'applicability' section (was many RFCs have) so that it is clear the scenarios the solution covers. Personally I feel the NAT64 could be at the CPE or deeper within the network. It could be run by the ISP or an Enterprise. Thanks, Reinaldo On 10/30/09 11:27 AM, "marcelo bagnulo braun" <marcelo@it.uc3m.es> wrote: > Iljitsch van Beijnum escribi=F3: >> On 30 okt 2009, at 17:30, Reinaldo Penno wrote: >>=20 >>> It is the norm in on ADSL/PPPoE deployments. >>=20 >> But weren't we talking about the translator's MTU? I would assume >> those aren't hooked up to an ADSL link. >>=20 > why not? > you could put a nat64 in the cpe, right? >=20 From iljitsch@muada.com Fri Oct 30 11:45:03 2009 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 7A6043A68C2 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 11:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEB7WqR7Qvib for <behave@core3.amsl.com>; Fri, 30 Oct 2009 11:45:02 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 750703A6767 for <behave@ietf.org>; Fri, 30 Oct 2009 11:45:02 -0700 (PDT) Received: from [192.168.2.11] (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 n9UIia9L083950 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Oct 2009 19:44:36 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <4AEB2FFF.40206@it.uc3m.es> Date: Fri, 30 Oct 2009 19:45:09 +0100 Content-Transfer-Encoding: 7bit Message-Id: <8DAE1B79-1385-4D03-A448-D503B0DFEE68@muada.com> References: <C71062B9.754B%rpenno@juniper.net> <D64DA65F-1E67-4F5F-9294-CEF83EEA2BC7@muada.com> <4AEB2FFF.40206@it.uc3m.es> To: marcelo bagnulo braun <marcelo@it.uc3m.es> X-Mailer: Apple Mail (2.1076) Cc: Stig Venaas <stig@venaas.com>, Behave WG <behave@ietf.org>, Mark Andrews <marka@isc.org>, "Ben@wand.net.nz" <Ben@wand.net.nz> Subject: Re: [BEHAVE] How to set the DF and the ID values for IPv4 packets (was Re: Amount of fragmentation resulting from translation 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, 30 Oct 2009 18:45:03 -0000 On 30 okt 2009, at 19:27, marcelo bagnulo braun wrote: >> But weren't we talking about the translator's MTU? I would assume >> those aren't hooked up to an ADSL link. > why not? > you could put a nat64 in the cpe, right? Hm, wouldn't it be easier to do NAT44 like people do today if each customer CPE has its own IPv4 address? I would think NAT64 in an ADSL CPE would be an unusual situation. From marcelo@it.uc3m.es Fri Oct 30 11:45:13 2009 Return-Path: <marcelo@it.uc3m.es> 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 B270228C0F1 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 11:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtqfoacFVaSZ for <behave@core3.amsl.com>; Fri, 30 Oct 2009 11:45:12 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id BF87928C0EF for <behave@ietf.org>; Fri, 30 Oct 2009 11:45:12 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.30.173]) by smtp02.uc3m.es (Postfix) with ESMTP id 0B0A66BA238; Fri, 30 Oct 2009 19:45:27 +0100 (CET) Message-ID: <4AEB343B.2040200@it.uc3m.es> Date: Fri, 30 Oct 2009 19:45:15 +0100 From: marcelo bagnulo braun <marcelo@it.uc3m.es> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Reinaldo Penno <rpenno@juniper.net> References: <C7108089.75B1%rpenno@juniper.net> In-Reply-To: <C7108089.75B1%rpenno@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16980.000 Cc: Stig Venaas <stig@venaas.com>, Behave WG <behave@ietf.org>, Mark Andrews <marka@isc.org>, "Ben@wand.net.nz" <Ben@wand.net.nz> Subject: Re: [BEHAVE] How to set the DF and the ID values for IPv4 packets (was Re: Amount of fragmentation resulting from translation 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, 30 Oct 2009 18:45:13 -0000 The draft has section 8. Application scenarios which describe the scenarios that are defined in the framework document that the nat64 apply. Not sure if more is needed. If you think it does, please propose text so that wg can comment. Regards, marcelo Reinaldo Penno escribió: > Yes, it could. There was a discussion about NAT64 scenarios before and it > served to point out that people have different views on the deployment > scenarios. > > As far as the ISP running the NAT64, one could argue that even if the NAT64 > is in the CPE, that is 'run by the ISP' as well. There was also a Microsoft > direct access scenario sent to the list. > > > Suggestion: > > My suggestion then was that the NAT64 document should have an > 'applicability' section (was many RFCs have) so that it is clear the > scenarios the solution covers. > > Personally I feel the NAT64 could be at the CPE or deeper within the > network. It could be run by the ISP or an Enterprise. > > Thanks, > > Reinaldo > > > On 10/30/09 11:27 AM, "marcelo bagnulo braun" <marcelo@it.uc3m.es> wrote: > > >> Iljitsch van Beijnum escribió: >> >>> On 30 okt 2009, at 17:30, Reinaldo Penno wrote: >>> >>> >>>> It is the norm in on ADSL/PPPoE deployments. >>>> >>> But weren't we talking about the translator's MTU? I would assume >>> those aren't hooked up to an ADSL link. >>> >>> >> why not? >> you could put a nat64 in the cpe, right? >> >> > > > From mrw@lilacglade.org Fri Oct 30 11:54:18 2009 Return-Path: <mrw@lilacglade.org> 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 7E1233A68E8 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 11:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.534, 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 tkkYR5AcZGJu for <behave@core3.amsl.com>; Fri, 30 Oct 2009 11:54:17 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 7A7EF3A68FE for <behave@ietf.org>; Fri, 30 Oct 2009 11:54:17 -0700 (PDT) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA05.westchester.pa.mail.comcast.net with comcast id z3J01c0GT16LCl0556ubjq; Fri, 30 Oct 2009 18:54:35 +0000 Received: from [10.2.0.20] ([69.33.111.74]) by OMTA06.westchester.pa.mail.comcast.net with comcast id z6uQ1c0071cMU3H3S6uTdZ; Fri, 30 Oct 2009 18:54:33 +0000 Message-Id: <65811B44-C3BD-474A-A1BA-DB2B5EB0DAC8@lilacglade.org> From: Margaret Wasserman <mrw@lilacglade.org> To: Marc Petit-Huguenin <petithug@acm.org> In-Reply-To: <4AE4A119.5050007@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 30 Oct 2009 14:54:23 -0400 References: <01c101ca509f$f314a8c0$8e27460a@china.huawei.com> <61FFB311-CA42-4EE4-A6F9-3DE0581A9E8F@lilacglade.org> <4ADE0BAB.1040402@acm.org> <FF53CDBF-9204-490D-8D04-9DF806EFE275@lilacglade.org> <4AE0A9F0.2010106@acm.org> <839B17D7-0BDE-4F11-8DC6-BDF694F7521D@lilacglade.org> <4AE4A119.5050007@acm.org> X-Mailer: Apple Mail (2.936) Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Opsdir Review of draft-ietf-behave-turn-uri-03.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: Fri, 30 Oct 2009 18:54:18 -0000 Hi Marc, I have some further questions about your last e-mail. Sorry for not including them in the previous message... On Oct 25, 2009, at 3:03 PM, Marc Petit-Huguenin wrote: > > This design is inspired by RFC 3263. The idea is that domain > administrators can > choose to implement either A/AAAA or SRV+A/AAAA or NAPTR+SRV+A/AAAA > as they see > fit for their environment, but still use the same TURN URI. > > Let's use as example the growth of a VoIP provider. The TURN URI > provisioned in > the VoIP end-user devices is "turn:example.com", and cannot be > easily changed. > The provider starts with few identical TURN boxes and use an A RR > for each box. > Each endpoint queries for NAPTR, which fails; then for SRV, which > fails; then > for A, which succeeds. I think there is a problem with this example.... (1) While I don't fully understand how "turn:example.com" would be transformed into an S-NAPTR query, that is more likely a weakness in my understanding than a problem in your draft. (2) I understand how "example.com" could be turned into a (set of) DNS SRV queries for the TURN transports supported by the application. (3) But, how could you transform "turn:example.com" into an A/AAAA record query? Where do you get the host name? It doesn't make sense to just do an A/AAAA query on "example.com" when you are trying to find a specific server... This was what I was dancing around in an earlier post, when I indicated some confusion about whether the <name> portion of the URI was intended to be a FQDN or just a domain... The specification seems to have some ambiguity in this area. Margaret From rpenno@juniper.net Fri Oct 30 12:02:25 2009 Return-Path: <rpenno@juniper.net> 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 7A5083A6767 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 12:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAs6heFX1Ou2 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 12:02:24 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 7C8653A6A42 for <behave@ietf.org>; Fri, 30 Oct 2009 12:02:14 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSus4R5LIhRAGllxoz/gob1DWb8zs3LHI@postini.com; Fri, 30 Oct 2009 12:02:42 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 30 Oct 2009 12:00:27 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 30 Oct 2009 15:00:26 -0400 From: Reinaldo Penno <rpenno@juniper.net> To: marcelo bagnulo braun <marcelo@it.uc3m.es> Date: Fri, 30 Oct 2009 15:00:24 -0400 Thread-Topic: [BEHAVE] How to set the DF and the ID values for IPv4 packets (was Re: Amount of fragmentation resulting from translation Thread-Index: AcpZkSof4rgcTN2HQnqXDGx5O5HO+AAAhIqS Message-ID: <C71085D8.75C7%rpenno@juniper.net> In-Reply-To: <4AEB343B.2040200@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Stig Venaas <stig@venaas.com>, Behave WG <behave@ietf.org>, Mark Andrews <marka@isc.org>, "Ben@wand.net.nz" <Ben@wand.net.nz> Subject: Re: [BEHAVE] How to set the DF and the ID values for IPv4 packets (was Re: Amount of fragmentation resulting from translation 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, 30 Oct 2009 19:02:25 -0000 Hi Marcelo, Those scenarios are fine from the point of view of mapping to the framework doc. But given the discussion we had/are having it seems to me that who run= s the GW and where it could be located in the network was not clear. Small nit: Section 8.2 is labeled as 'scenario 3'. There is no scenario 2. On 10/30/09 11:45 AM, "marcelo bagnulo braun" <marcelo@it.uc3m.es> wrote: > The draft has section 8. Application scenarios which describe the > scenarios that are defined in the framework document that the nat64 > apply. Not sure if more is needed. > If you think it does, please propose text so that wg can comment. Sure, something like (if there is consensus): X. Applicability Statement The GW could be located on the demarcation point between the ISP and its customer or deeper within the ISP network. When the GW is located within a CPE it could be managed by the customer or the ISP. note: 'CPE' here should not be seen only as a small modem Home network, but anything from a home network, SOHO till full fledge enterprise. >=20 > Regards, marcelo >=20 >=20 >=20 > Reinaldo Penno escribi=F3: >> Yes, it could. There was a discussion about NAT64 scenarios before and i= t >> served to point out that people have different views on the deployment >> scenarios.=20 >>=20 >> As far as the ISP running the NAT64, one could argue that even if the NA= T64 >> is in the CPE, that is 'run by the ISP' as well. There was also a Micros= oft >> direct access scenario sent to the list. >>=20 >>=20 >> Suggestion:=20 >>=20 >> My suggestion then was that the NAT64 document should have an >> 'applicability' section (was many RFCs have) so that it is clear the >> scenarios the solution covers. >>=20 >> Personally I feel the NAT64 could be at the CPE or deeper within the >> network. It could be run by the ISP or an Enterprise. >>=20 >> Thanks, >>=20 >> Reinaldo >>=20 >>=20 >> On 10/30/09 11:27 AM, "marcelo bagnulo braun" <marcelo@it.uc3m.es> wrote= : >>=20 >> =20 >>> Iljitsch van Beijnum escribi=F3: >>> =20 >>>> On 30 okt 2009, at 17:30, Reinaldo Penno wrote: >>>>=20 >>>> =20 >>>>> It is the norm in on ADSL/PPPoE deployments. >>>>> =20 >>>> But weren't we talking about the translator's MTU? I would assume >>>> those aren't hooked up to an ADSL link. >>>>=20 >>>> =20 >>> why not? >>> you could put a nat64 in the cpe, right? >>>=20 >>> =20 >>=20 >>=20 >> =20 >=20 From iljitsch@muada.com Fri Oct 30 12:15:16 2009 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 900773A6842 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 12:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqL7zuzrwxTw for <behave@core3.amsl.com>; Fri, 30 Oct 2009 12:15:15 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 7DEFE3A6839 for <behave@ietf.org>; Fri, 30 Oct 2009 12:15:15 -0700 (PDT) Received: from [192.168.2.11] (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 n9UJEpP5084134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Oct 2009 20:14:52 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <4AEB343B.2040200@it.uc3m.es> Date: Fri, 30 Oct 2009 20:15:24 +0100 Content-Transfer-Encoding: 7bit Message-Id: <14D2169E-5C8B-467F-9287-14AAB73DEAAD@muada.com> References: <C7108089.75B1%rpenno@juniper.net> <4AEB343B.2040200@it.uc3m.es> To: marcelo bagnulo braun <marcelo@it.uc3m.es> X-Mailer: Apple Mail (2.1076) Cc: Stig Venaas <stig@venaas.com>, Behave WG <behave@ietf.org>, Mark Andrews <marka@isc.org>, "Ben@wand.net.nz" <Ben@wand.net.nz> Subject: Re: [BEHAVE] How to set the DF and the ID values for IPv4 packets (was Re: Amount of fragmentation resulting from translation 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, 30 Oct 2009 19:15:16 -0000 On 30 okt 2009, at 19:45, marcelo bagnulo braun wrote: > The draft has section 8. Application scenarios which describe > the scenarios that are defined in the framework document that the > nat64 apply. Not sure if more is needed. > If you think it does, please propose text so that wg can comment. A stateful NAT64 can be deployed anywhere wwhere there is a globally routable IPv4 address available for use by the translator and there is an IPv6 path towards the hosts that are served by the translator. Secondary considerations are: - paths with at least a 1500-byte MTU to both the IPv6 hosts served by the translator and the IPv4 internet are highly recommended - the ability to provide the IPv6 hosts served by the translator with DNS resolver addresses that point to the DNS64 (through DHCPv6 or RFC 5006) - the ability to restrict access to the IPv6 side of the translator by filtering addresses (i.e., if IPv6 source addresses can be spoofed the translator may be abused to hide attacks towards third parties) Deployment within an ISP network or a reasonably sized enterprise network will easily accommodate all of the above. Deployment in a SOHO environment or across the public internet is not impossible, but does require compromises and/or extra complexity. From petithug@acm.org Fri Oct 30 12:36:39 2009 Return-Path: <petithug@acm.org> 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 8C7B93A686B for <behave@core3.amsl.com>; Fri, 30 Oct 2009 12:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.065 X-Spam-Level: X-Spam-Status: No, score=-102.065 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 rkZsLQoSfXUC for <behave@core3.amsl.com>; Fri, 30 Oct 2009 12:36:38 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id C4C1C3A67BD for <behave@ietf.org>; Fri, 30 Oct 2009 12:36:38 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 447C56C984CC; Fri, 30 Oct 2009 19:36:55 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 192FA6C984B4; Fri, 30 Oct 2009 19:36:52 +0000 (UTC) Message-ID: <4AEB4054.5060500@acm.org> Date: Fri, 30 Oct 2009 12:36:52 -0700 From: Marc Petit-Huguenin <petithug@acm.org> User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: Margaret Wasserman <mrw@lilacglade.org> References: <01c101ca509f$f314a8c0$8e27460a@china.huawei.com> <61FFB311-CA42-4EE4-A6F9-3DE0581A9E8F@lilacglade.org> <4ADE0BAB.1040402@acm.org> <FF53CDBF-9204-490D-8D04-9DF806EFE275@lilacglade.org> <4AE0A9F0.2010106@acm.org> <839B17D7-0BDE-4F11-8DC6-BDF694F7521D@lilacglade.org> <4AE4A119.5050007@acm.org> <65811B44-C3BD-474A-A1BA-DB2B5EB0DAC8@lilacglade.org> In-Reply-To: <65811B44-C3BD-474A-A1BA-DB2B5EB0DAC8@lilacglade.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Opsdir Review of draft-ietf-behave-turn-uri-03.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: Fri, 30 Oct 2009 19:36:39 -0000 I'll respond later to your previous email. See inline for my response to this email. Margaret Wasserman wrote: > > Hi Marc, > > I have some further questions about your last e-mail. Sorry for not > including them in the previous message... > > On Oct 25, 2009, at 3:03 PM, Marc Petit-Huguenin wrote: >> >> This design is inspired by RFC 3263. The idea is that domain >> administrators can >> choose to implement either A/AAAA or SRV+A/AAAA or NAPTR+SRV+A/AAAA as >> they see >> fit for their environment, but still use the same TURN URI. >> >> Let's use as example the growth of a VoIP provider. The TURN URI >> provisioned in >> the VoIP end-user devices is "turn:example.com", and cannot be easily >> changed. >> The provider starts with few identical TURN boxes and use an A RR for >> each box. >> Each endpoint queries for NAPTR, which fails; then for SRV, which >> fails; then >> for A, which succeeds. > > I think there is a problem with this example.... > > (1) While I don't fully understand how "turn:example.com" would be > transformed into an S-NAPTR query, that is more likely a weakness in my > understanding than a problem in your draft. > > (2) I understand how "example.com" could be turned into a (set of) DNS > SRV queries for the TURN transports supported by the application. > > (3) But, how could you transform "turn:example.com" into an A/AAAA > record query? Where do you get the host name? It doesn't make sense to > just do an A/AAAA query on "example.com" when you are trying to find a > specific server... $host example.com example.com has address 192.0.32.10 > > This was what I was dancing around in an earlier post, when I indicated > some confusion about whether the <name> portion of the URI was intended > to be a FQDN or just a domain... The specification seems to have some > ambiguity in this area. "FQDN" is never used in the draft, so I do not understand why you are referring to this. A <host> can be a FQDN and a domain name at the same time. Even "com" could be a FQDN if someone adds a A record for it, why not? As there is absolutely no way to distinguish between a FQDN and a domain name, I do not see the point of using this terminology. If you really want to think in term of FQDN and domain name, then the algorithm is to take whatever is in the <host> if it is not an IP address, use it first as a domain name and if the NAPTR/SRV query fails, use it as a FQDN. -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From mrw@lilacglade.org Fri Oct 30 12:59:41 2009 Return-Path: <mrw@lilacglade.org> 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 C5E463A68B0 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 12:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.356, 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 CH5vewvRToWH for <behave@core3.amsl.com>; Fri, 30 Oct 2009 12:59:41 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id E0F563A6899 for <behave@ietf.org>; Fri, 30 Oct 2009 12:59:40 -0700 (PDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id z2Bq1c0040FhH24A67zzYy; Fri, 30 Oct 2009 19:59:59 +0000 Received: from [10.2.0.20] ([69.33.111.74]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id z7zm1c0071cMU3H8U7zpGl; Fri, 30 Oct 2009 19:59:56 +0000 Message-Id: <D5A2180D-0373-4C11-A2D0-54DA86DE7DFD@lilacglade.org> From: Margaret Wasserman <mrw@lilacglade.org> To: Marc Petit-Huguenin <petithug@acm.org> In-Reply-To: <4AEB4054.5060500@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 30 Oct 2009 15:59:44 -0400 References: <01c101ca509f$f314a8c0$8e27460a@china.huawei.com> <61FFB311-CA42-4EE4-A6F9-3DE0581A9E8F@lilacglade.org> <4ADE0BAB.1040402@acm.org> <FF53CDBF-9204-490D-8D04-9DF806EFE275@lilacglade.org> <4AE0A9F0.2010106@acm.org> <839B17D7-0BDE-4F11-8DC6-BDF694F7521D@lilacglade.org> <4AE4A119.5050007@acm.org> <65811B44-C3BD-474A-A1BA-DB2B5EB0DAC8@lilacglade.org> <4AEB4054.5060500@acm.org> X-Mailer: Apple Mail (2.936) Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Opsdir Review of draft-ietf-behave-turn-uri-03.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: Fri, 30 Oct 2009 19:59:41 -0000 Hi Marc, On Oct 30, 2009, at 3:36 PM, Marc Petit-Huguenin wrote: >> >> (3) But, how could you transform "turn:example.com" into an A/AAAA >> record query? Where do you get the host name? It doesn't make >> sense to >> just do an A/AAAA query on "example.com" when you are trying to >> find a >> specific server... > > $host example.com > example.com has address 192.0.32.10 I didn't say that you _couldn't_ send a query for example.com, just that it wouldn't make sense to do so... Are you expecting that administrators will accept a requirement to run their TURN servers at an IP address returned for their domain, in order to maintain their ability to move to DNS SRV records or S-NAPTR later without changing the URIs on their end-user devices? Isn't it more likely that they will want to name their TURN servers something like turn1.example.com, or something like that? >> This was what I was dancing around in an earlier post, when I >> indicated >> some confusion about whether the <name> portion of the URI was >> intended >> to be a FQDN or just a domain... The specification seems to have >> some >> ambiguity in this area. > > "FQDN" is never used in the draft, so I do not understand why you > are referring > to this. A <host> can be a FQDN and a domain name at the same time. > Even "com" > could be a FQDN if someone adds a A record for it, why not? As > there is > absolutely no way to distinguish between a FQDN and a domain name, I > do not see > the point of using this terminology. If you really want to think in > term of > FQDN and domain name, then the algorithm is to take whatever is in > the <host> if > it is not an IP address, use it first as a domain name and if the > NAPTR/SRV > query fails, use it as a FQDN. I am not attempting to argue about the term FQDN vs. the term domain name... I am arguing that if you won't want to use the same <name> value for the DNS SRV lookup as the A/AAAA in most cases. So, I am not sure how well the fallback you have described will work in practice. Are there cases where people do something like this today and it works? Margaret From petithug@acm.org Fri Oct 30 13:14:07 2009 Return-Path: <petithug@acm.org> 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 2A2B53A68AC for <behave@core3.amsl.com>; Fri, 30 Oct 2009 13:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.083 X-Spam-Level: X-Spam-Status: No, score=-102.083 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 8VLfDuSGvmE8 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 13:14:06 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 2CA993A67BD for <behave@ietf.org>; Fri, 30 Oct 2009 13:14:06 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 6ADF76C984CC; Fri, 30 Oct 2009 20:14:23 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 798F26C984B4; Fri, 30 Oct 2009 20:14:22 +0000 (UTC) Message-ID: <4AEB491D.6060002@acm.org> Date: Fri, 30 Oct 2009 13:14:21 -0700 From: Marc Petit-Huguenin <petithug@acm.org> User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: Margaret Wasserman <mrw@lilacglade.org> References: <01c101ca509f$f314a8c0$8e27460a@china.huawei.com> <61FFB311-CA42-4EE4-A6F9-3DE0581A9E8F@lilacglade.org> <4ADE0BAB.1040402@acm.org> <FF53CDBF-9204-490D-8D04-9DF806EFE275@lilacglade.org> <4AE0A9F0.2010106@acm.org> <839B17D7-0BDE-4F11-8DC6-BDF694F7521D@lilacglade.org> <4AE4A119.5050007@acm.org> <65811B44-C3BD-474A-A1BA-DB2B5EB0DAC8@lilacglade.org> <4AEB4054.5060500@acm.org> <D5A2180D-0373-4C11-A2D0-54DA86DE7DFD@lilacglade.org> In-Reply-To: <D5A2180D-0373-4C11-A2D0-54DA86DE7DFD@lilacglade.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Opsdir Review of draft-ietf-behave-turn-uri-03.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: Fri, 30 Oct 2009 20:14:07 -0000 Margaret Wasserman wrote: > > Hi Marc, > > On Oct 30, 2009, at 3:36 PM, Marc Petit-Huguenin wrote: >>> >>> (3) But, how could you transform "turn:example.com" into an A/AAAA >>> record query? Where do you get the host name? It doesn't make sense to >>> just do an A/AAAA query on "example.com" when you are trying to find a >>> specific server... >> >> $host example.com >> example.com has address 192.0.32.10 > > I didn't say that you _couldn't_ send a query for example.com, just that > it wouldn't > make sense to do so... > > Are you expecting that administrators will accept a requirement to run > their TURN > servers at an IP address returned for their domain, in order to maintain > their ability to > move to DNS SRV records or S-NAPTR later without changing the URIs on their > end-user devices? > > Isn't it more likely that they will want to name their TURN servers > something like > turn1.example.com, or something like that? Or better turn.example.com. A provider starts with A/AAAA RR, so turn.example.com is an FQDN, then later they can convert it into a domain name by adding NAPTR/SRV. > >>> This was what I was dancing around in an earlier post, when I indicated >>> some confusion about whether the <name> portion of the URI was intended >>> to be a FQDN or just a domain... The specification seems to have some >>> ambiguity in this area. >> >> "FQDN" is never used in the draft, so I do not understand why you are >> referring >> to this. A <host> can be a FQDN and a domain name at the same time. >> Even "com" >> could be a FQDN if someone adds a A record for it, why not? As there is >> absolutely no way to distinguish between a FQDN and a domain name, I >> do not see >> the point of using this terminology. If you really want to think in >> term of >> FQDN and domain name, then the algorithm is to take whatever is in the >> <host> if >> it is not an IP address, use it first as a domain name and if the >> NAPTR/SRV >> query fails, use it as a FQDN. > > I am not attempting to argue about the term FQDN vs. the term domain > name... I > am arguing that if you won't want to use the same <name> value for the DNS > SRV lookup as the A/AAAA in most cases. So, I am not sure how well the > fallback > you have described will work in practice. > > Are there cases where people do something like this today and it works? SIP (RFC 3263). Yes it works, I used it for the VoIP service I developed for my former employer. -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From brian.e.carpenter@gmail.com Fri Oct 30 18:58:05 2009 Return-Path: <brian.e.carpenter@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 9E9B43A68AD for <behave@core3.amsl.com>; Fri, 30 Oct 2009 18:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 M3Uqgs3lppY6 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 18:58:04 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id DCF5A3A6781 for <behave@ietf.org>; Fri, 30 Oct 2009 18:58:04 -0700 (PDT) Received: by pzk42 with SMTP id 42so2580262pzk.31 for <behave@ietf.org>; Fri, 30 Oct 2009 18:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=nI7rhVj771VwDshZRTVNOfMh/YVgiLhr8lqli4gcKVA=; b=eqdjSlUCawhH+p3zmNKopxzZaVZ+/UoP/w0rtFqtgsknjufk9FSOqpfmqwoY7wR1fP 5xJFgTkCARQisi3wdxisawqQTLS11SxkrQuyOkn3huMYrngYXge5HQjptJ03884Q/4FP fYQEExjHfrGppKnRVNK/cPJVTmUtyNYg0WkAM= 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=UvZRAzWzHCmM/WTDdAp56e6jLlW3F2uebE5HESjlq6d6ZGb1xB15TAeaaysS6YNsXq xqylh4Sf6J1rOG634TmqdiyLec5RjASrQYZ9+C/uxVWISahV0cTrWzdxOzCn0SDAMlDJ 7XlvDymUCXjVEHJoQ9azl5dUBxrt0JXg9SjsY= Received: by 10.114.69.18 with SMTP id r18mr1838958waa.209.1256954298276; Fri, 30 Oct 2009 18:58:18 -0700 (PDT) Received: from ?10.1.1.4? ([121.98.142.15]) by mx.google.com with ESMTPS id 23sm677449pxi.1.2009.10.30.18.58.15 (version=SSLv3 cipher=RC4-MD5); Fri, 30 Oct 2009 18:58:17 -0700 (PDT) Message-ID: <4AEB99B5.8080106@gmail.com> Date: Sat, 31 Oct 2009 14:58:13 +1300 From: Brian E Carpenter <brian.e.carpenter@gmail.com> Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Andrews <marka@isc.org> References: <4AE94ED6.5050600@it.uc3m.es> <B7943394-8740-4292-B0FF-1050B0DFD3FF@muada.com> <4AEA18CE.8040302@venaas.com> <200910292329.n9TNTmCx075617@drugs.dv.isc.org> <4AEAA15C.4060900@it.uc3m.es> <200910301320.n9UDKTOs099079@drugs.dv.isc.org> In-Reply-To: <200910301320.n9UDKTOs099079@drugs.dv.isc.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Stig Venaas <stig@venaas.com>, Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Amount of fragmentation resulting from translation 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: Sat, 31 Oct 2009 01:58:05 -0000 On 2009-10-31 02:20, Mark Andrews wrote: > In message <4AEAA15C.4060900@it.uc3m.es>, marcelo bagnulo braun writes:= >> Mark Andrews escribi=EF=BF=BD: >>> >>> I think turning on PMTUD in the middle of the network is just plain >>> wrong. There are OS which incorrectly turn on PMTUD for IPv4 for >>> all packets. This causes problems for applications like DNS servers.= >>> >>> There is only one choice and that is to fragment at network MTU. Any= thing >>> else will cause operational problems. >>> >>> =20 >> Just to be clear, you support the option that the translator always=20 >> sends IPv6 packet of 1280 bytes rahter than the translator doing pmtud= =20 >> to figure out which is the mtu availbale for that path, correct? >> >> Regards, marcelo >=20 > Yes. BTW, the MTU data observed in draft-defeche-ipv6-traffic-in-p2p-networks strongly support this for today's IPv6 world. Average observed IPv4 MTU was 1498 bytes and average observed IPv6 MTU was 1289, obviously telling us that 1280 is the dominant value in practice (at least for hosts running BitTorrent). So it's not only the safe value to use, but it's also not very sub-optimal. Brian From rpenno@juniper.net Fri Oct 30 19:37:20 2009 Return-Path: <rpenno@juniper.net> 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 AD5183A6AB7 for <behave@core3.amsl.com>; Fri, 30 Oct 2009 19:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id monbWEkP0d+k for <behave@core3.amsl.com>; Fri, 30 Oct 2009 19:37:19 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 770033A6A72 for <behave@ietf.org>; Fri, 30 Oct 2009 19:37:06 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSuui4hm43/SAYyGTJaV84/tR4ykfaLgi@postini.com; Fri, 30 Oct 2009 19:37:37 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 30 Oct 2009 19:34:26 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 30 Oct 2009 22:34:25 -0400 From: Reinaldo Penno <rpenno@juniper.net> To: Iljitsch van Beijnum <iljitsch@muada.com>, marcelo bagnulo braun <marcelo@it.uc3m.es> Date: Fri, 30 Oct 2009 22:34:19 -0400 Thread-Topic: [BEHAVE] How to set the DF and the ID values for IPv4 packets (was Re: Amount of fragmentation resulting from translation Thread-Index: AcpZlWCslt28zQ0dRuqoLQrYBfst1wAPUTyZ Message-ID: <C710F03B.76AD%rpenno@juniper.net> In-Reply-To: <14D2169E-5C8B-467F-9287-14AAB73DEAAD@muada.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Stig Venaas <stig@venaas.com>, Behave WG <behave@ietf.org>, Mark Andrews <marka@isc.org>, "Ben@wand.net.nz" <Ben@wand.net.nz> Subject: Re: [BEHAVE] How to set the DF and the ID values for IPv4 packets (was Re: Amount of fragmentation resulting from translation 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: Sat, 31 Oct 2009 02:37:20 -0000 This seems like a good summary, including the secondary considerations. One suggestion: I would change the following text by removing references what is Internet and what is network. Change: "- paths with at least a 1500-byte MTU to both the IPv6 hosts served by the translator and the IPv4 internet are highly recommended" To:=20 " paths with at least a 1500-byte MTU to both the IPv6 and IPv4 hosts serve= d by the translator are highly recommended" Since there are scenarios in the NAT64 doc and framework where the 'Internet' is IPv6 and IPV4 is a network. On 10/30/09 12:15 PM, "Iljitsch van Beijnum" <iljitsch@muada.com> wrote: > On 30 okt 2009, at 19:45, marcelo bagnulo braun wrote: >=20 >> The draft has section 8. Application scenarios which describe >> the scenarios that are defined in the framework document that the >> nat64 apply. Not sure if more is needed. >> If you think it does, please propose text so that wg can comment. >=20 > A stateful NAT64 can be deployed anywhere wwhere there is a globally > routable IPv4 address available for use by the translator and there is > an IPv6 path towards the hosts that are served by the translator. >=20 > Secondary considerations are: >=20 > - paths with at least a 1500-byte MTU to both the IPv6 hosts served by > the translator and the IPv4 internet are highly recommended >=20 > - the ability to provide the IPv6 hosts served by the translator with > DNS resolver addresses that point to the DNS64 (through DHCPv6 or RFC > 5006) >=20 > - the ability to restrict access to the IPv6 side of the translator by > filtering addresses (i.e., if IPv6 source addresses can be spoofed the > translator may be abused to hide attacks towards third parties) >=20 > Deployment within an ISP network or a reasonably sized enterprise > network will easily accommodate all of the above. Deployment in a SOHO > environment or across the public internet is not impossible, but does > require compromises and/or extra complexity. From tena@huawei.com Sat Oct 31 00:30:54 2009 Return-Path: <tena@huawei.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 DFCC43A66B4 for <behave@core3.amsl.com>; Sat, 31 Oct 2009 00:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.127 X-Spam-Level: X-Spam-Status: No, score=-100.127 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 xGwAFrdcrt+M for <behave@core3.amsl.com>; Sat, 31 Oct 2009 00:30:53 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 884C63A63C9 for <behave@ietf.org>; Sat, 31 Oct 2009 00:30:53 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSD003W5BJOSU@szxga03-in.huawei.com> for behave@ietf.org; Sat, 31 Oct 2009 15:31:00 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSD00J9JBJO9E@szxga03-in.huawei.com> for behave@ietf.org; Sat, 31 Oct 2009 15:31:00 +0800 (CST) Received: from z24109b ([10.70.39.142]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSD005VCBJM08@szxml06-in.huawei.com> for behave@ietf.org; Sat, 31 Oct 2009 15:31:00 +0800 (CST) Date: Sat, 31 Oct 2009 15:30:57 +0800 From: Tina TSOU <tena@huawei.com> To: Dan Wing <dwing@cisco.com>, 'Zhen Cao' <caozhenpku@gmail.com> Message-id: <003501ca59fc$17fbd090$8e27460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_WAW9IRXPtlFYQR0qMUx6WQ)" X-Priority: 3 X-MSMail-priority: Normal References: <004501ca5879$938933d0$3a0c6f0a@china.huawei.com> <4AE96AFB.5000406@it.uc3m.es> <3db7b9d60910290759k4314a976p1b8750417b0c03d8@mail.gmail.com> <20091029151219.GG65688@shinkuro.com> <1d1001ca58b6$d05fec80$c5f0200a@cisco.com> <a7c8d0a30910292044t40f28931v9262cecac516f26a@mail.gmail.com> <207301ca5977$3c0e4970$c5f0200a@cisco.com> Cc: 'Andrew Sullivan' <ajs@shinkuro.com>, behave@ietf.org Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item 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: Sat, 31 Oct 2009 07:30:55 -0000 This is a multi-part message in MIME format. --Boundary_(ID_WAW9IRXPtlFYQR0qMUx6WQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, Iljitsch has done good job. draft-van-beijnum-behave-ftp64 is his own draft, it is up to him to add one more author or not. In my mind, the draft from Iljitsch includes some content from draft-liu-behave-ftp64. 1, regarding return PASV command, if the response message from the server includes the address and the port, use the IPv6 rather than address of the client to set up the connection. 2, Regarding ALG, draft-van-beijnum-behave-ftp64 seems accepting the concept that first to have FTP client and server to avoid ALG issues, if it is not possible, can then provide how to implement ALG. There could be something addressed in draft-ietf-behave-ftp64-00. 1) Refine the scenario 2) Describe more details about the ALG part The WG chair will tell the editor, presumably Iljitsch, who should be the co-author (s) if there is any, based on the WG consensus. B. R. Tina http://tinatsou.weebly.com/contact.html ----- Original Message ----- From: Dan Wing To: 'Zhen Cao' Cc: 'Andrew Sullivan' ; behave@ietf.org Sent: Friday, October 30, 2009 11:39 PM Subject: Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item > On Fri, Oct 30, 2009 at 12:42 AM, Dan Wing <dwing@cisco.com> wrote: > >> On Thu, Oct 29, 2009 at 10:59:35PM +0800, Kai Ju wrote: > >> > jiang sheng's pre condition is quite clear, by including > >> > other author, this draft could be adopted. > >> > >> I'm not sure how our Chairs prefer to work these matters, > but it is my > >> understanding that the editors of a draft which is to be a > WG product > >> normally serve at the pleasure of the Chairs. Therefore, I don't > >> believe the WG participants are in a position to insist on one or > >> another editor for the draft as a condition of making it a WG work > >> item. "Is the _draft_ to be worked on by the WG?" is the > question, as > >> I understand it. The Chairs might well decide that > someone previously > >> entirely unconnected to this effort will hold the pen, and that's > >> something they get to choose after the WG has expressed its > >> willingness to adopt the work item. > > > > Yes, the question at hand is 'shall we adopt this document'. I > > did not ask 'who wants to be an author'. > > > > I have not seen a substantive objection since I asked a week ago > > (Oct 22). > > Note that i raised some questions and do not think the current draft > is a solid basis, although chairs do not think they are fundamental > issues. Yes, I made note of the comments, and as I indicated in my reply they can be corrected. Documents are not perfect -- or complete -- when adopted by the working group. Once the working group adopts the document, the working group has change control over the document and can direct the authors to make the changes the WG deems necessary. > I do not know what can be a 'fundamental' issue. Thanks. For example, the technique described in the document will not work as expected / desired. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave --Boundary_(ID_WAW9IRXPtlFYQR0qMUx6WQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=Content-Type content="text/html; charset=iso-8859-1"> <META content="MSHTML 6.00.2900.3603" name=GENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=#ffffff> <DIV> <DIV><FONT face=Arial size=2> <P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT face="Times New Roman" size=3>Hi,</FONT></SPAN></P> <P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT face="Times New Roman" size=3>Iljitsch has done good job. draft-van-beijnum-behave-ftp64 is his own draft, it is up to him to add one more author or not.</FONT></SPAN></P> <P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p><FONT face="Times New Roman" size=3> </FONT></o:p></SPAN></P> <P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT face="Times New Roman" size=3>In my mind, the draft from Iljitsch includes some content from draft-liu-behave-ftp64.</FONT></SPAN></P> <P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT face="Times New Roman" size=3>1, regarding return PASV command, if the response message from the server includes the address and the port, use the IPv6 rather than address of the client to set up the connection.</FONT></SPAN></P> <P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT face="Times New Roman" size=3>2, Regarding ALG, draft-van-beijnum-behave-ftp64 seems accepting the concept that first to have FTP client and server to avoid ALG issues, if it is not possible, can then provide how to implement ALG.</FONT></SPAN></P> <P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><o:p><FONT face="Times New Roman" size=3> </FONT></o:p></SPAN></P> <P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT face="Times New Roman" size=3>There could be something addressed in draft-ietf-behave-ftp64-00. </FONT></SPAN></P> <P class=MsoNormal style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt; mso-list: l0 level1 lfo1; tab-stops: list 18.0pt"><FONT face="Times New Roman"><SPAN lang=EN-US style="mso-fareast-font-family: 'Times New Roman'"><SPAN style="mso-list: Ignore"><FONT size=3>1)</FONT><SPAN style="FONT: 7pt 'Times New Roman'">      </SPAN></SPAN></SPAN><SPAN dir=ltr><SPAN lang=EN-US><FONT size=3>Refine the scenario</FONT></SPAN></SPAN></FONT></P> <P class=MsoNormal style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt; mso-list: l0 level1 lfo1; tab-stops: list 18.0pt"><FONT face="Times New Roman"><SPAN lang=EN-US style="mso-fareast-font-family: 'Times New Roman'"><SPAN style="mso-list: Ignore"><FONT size=3>2)</FONT><SPAN style="FONT: 7pt 'Times New Roman'">      </SPAN></SPAN></SPAN><SPAN dir=ltr><SPAN lang=EN-US><FONT size=3>Describe more details about the ALG part</FONT></SPAN></SPAN></FONT></P> <P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><o:p><FONT face="Times New Roman" size=3> </FONT></o:p></SPAN></P> <P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT face="Times New Roman" size=3>The WG chair will tell the editor, presumably Iljitsch, who should be the co-author (s) if there is any, based on the WG consensus.</FONT></SPAN></P></FONT></DIV></DIV> <DIV> </DIV> <DIV> </DIV> <DIV>B. R.<BR>Tina<BR><A href="http://tinatsou.weebly.com/contact.html">http://tinatsou.weebly.com/contact.html</A><BR></DIV> <BLOCKQUOTE style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"> <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV> <DIV style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> <A title=dwing@cisco.com href="mailto:dwing@cisco.com">Dan Wing</A> </DIV> <DIV style="FONT: 10pt arial"><B>To:</B> <A title=caozhenpku@gmail.com href="mailto:caozhenpku@gmail.com">'Zhen Cao'</A> </DIV> <DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=ajs@shinkuro.com href="mailto:ajs@shinkuro.com">'Andrew Sullivan'</A> ; <A title=behave@ietf.org href="mailto:behave@ietf.org">behave@ietf.org</A> </DIV> <DIV style="FONT: 10pt arial"><B>Sent:</B> Friday, October 30, 2009 11:39 PM</DIV> <DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [BEHAVE] adopt draft-van-beijnum-behave-ftp64-06 as WG item</DIV> <DIV><BR></DIV>> On Fri, Oct 30, 2009 at 12:42 AM, Dan Wing <<A href="mailto:dwing@cisco.com">dwing@cisco.com</A>> wrote:<BR>> >> On Thu, Oct 29, 2009 at 10:59:35PM +0800, Kai Ju wrote:<BR>> >> > jiang sheng's pre condition is quite clear, by including<BR>> >> > other author, this draft could be adopted.<BR>> >><BR>> >> I'm not sure how our Chairs prefer to work these matters, <BR>> but it is my<BR>> >> understanding that the editors of a draft which is to be a <BR>> WG product<BR>> >> normally serve at the pleasure of the Chairs. Therefore, I don't<BR>> >> believe the WG participants are in a position to insist on one or<BR>> >> another editor for the draft as a condition of making it a WG work<BR>> >> item. "Is the _draft_ to be worked on by the WG?" is the <BR>> question, as<BR>> >> I understand it. The Chairs might well decide that <BR>> someone previously<BR>> >> entirely unconnected to this effort will hold the pen, and that's<BR>> >> something they get to choose after the WG has expressed its<BR>> >> willingness to adopt the work item.<BR>> ><BR>> > Yes, the question at hand is 'shall we adopt this document'. I<BR>> > did not ask 'who wants to be an author'.<BR>> ><BR>> > I have not seen a substantive objection since I asked a week ago<BR>> > (Oct 22).<BR>> <BR>> Note that i raised some questions and do not think the current draft<BR>> is a solid basis, although chairs do not think they are fundamental<BR>> issues.<BR><BR>Yes, I made note of the comments, and as I indicated in my reply<BR>they can be corrected.  Documents are not perfect -- or complete --<BR>when adopted by the working group.  Once the working group adopts<BR>the document, the working group has change control over the <BR>document and can direct the authors to make the changes the WG<BR>deems necessary.<BR><BR>> I do not know what can be a 'fundamental' issue.  Thanks.<BR><BR>For example, the technique described in the document will <BR>not work as expected / desired.<BR><BR>-d<BR><BR>_______________________________________________<BR>Behave mailing list<BR><A href="mailto:Behave@ietf.org">Behave@ietf.org</A><BR><A href="https://www.ietf.org/mailman/listinfo/behave">https://www.ietf.org/mailman/listinfo/behave</A></BLOCKQUOTE></BODY></HTML> --Boundary_(ID_WAW9IRXPtlFYQR0qMUx6WQ)-- From Washam.Fan@huaweisymantec.com Sat Oct 31 01:29:47 2009 Return-Path: <Washam.Fan@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 E2DA23A6826 for <behave@core3.amsl.com>; Sat, 31 Oct 2009 01:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.25 X-Spam-Level: X-Spam-Status: No, score=0.25 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, FRT_VALIUM2=2.643, FUZZY_VLIUM=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 Uo7nMdzopMD9 for <behave@core3.amsl.com>; Sat, 31 Oct 2009 01:29:47 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 13DCF3A67AD for <behave@ietf.org>; Sat, 31 Oct 2009 01:29:47 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KSD00JBJE9I6770@hstga01-in.huaweisymantec.com> for behave@ietf.org; Sat, 31 Oct 2009 16:29:43 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KSD009JQE9I3D10@hstml01-in.huaweisymantec.com> for behave@ietf.org; Sat, 31 Oct 2009 16:29:42 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Sat, 31 Oct 2009 16:29:42 +0800 From: WashamFan <Washam.Fan@huaweisymantec.com> To: Margaret Wasserman <mrw@lilacglade.org> Message-id: <fc04d8cd4041.4aec65f6@huaweisymantec.com> Date: Sat, 31 Oct 2009 16:29:42 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <9009E8A3-5FFE-4692-8EC6-BD038C5E728D@lilacglade.org> References: <01c101ca509f$f314a8c0$8e27460a@china.huawei.com> <61FFB311-CA42-4EE4-A6F9-3DE0581A9E8F@lilacglade.org> <4ADE0BAB.1040402@acm.org> <FF53CDBF-9204-490D-8D04-9DF806EFE275@lilacglade.org> <4AE0A9F0.2010106@acm.org> <839B17D7-0BDE-4F11-8DC6-BDF694F7521D@lilacglade.org> <4AE4A119.5050007@acm.org> <9009E8A3-5FFE-4692-8EC6-BD038C5E728D@lilacglade.org> Cc: Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Opsdir Review of draft-ietf-behave-turn-uri-03.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: Sat, 31 Oct 2009 08:29:48 -0000 Hi, > > "After verifying the validity of the URI elements, the algorithm > > filters the list of TURN transports supported by the application by > > keeping only the UDP and TCP TURN transports if the <scheme> is > > defined as "turn" and by keeping only the TLS TURN transport if the > > <scheme> is defined as "turns". If the list of TURN transports is > > empty after this filtering, the resolution MUST stop with an error." Please look at the example illustrated in section 5, "turn:example.com" URI turns out to be keeping UDP, TCP, and TLS. washam > Looks good. From iljitsch@muada.com Sat Oct 31 02:18:06 2009 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 AB7F13A68DF for <behave@core3.amsl.com>; Sat, 31 Oct 2009 02:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sm4x85bn7Krl for <behave@core3.amsl.com>; Sat, 31 Oct 2009 02:18:06 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id BA4103A67C2 for <behave@ietf.org>; Sat, 31 Oct 2009 02:18:05 -0700 (PDT) Received: from [192.168.2.11] (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 n9V9HY8h000947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 31 Oct 2009 10:17:34 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum <iljitsch@muada.com> In-Reply-To: <4AEB99B5.8080106@gmail.com> Date: Sat, 31 Oct 2009 10:18:08 +0100 Content-Transfer-Encoding: 7bit Message-Id: <073AB33C-10FF-47F5-B4CA-9AF8F5A1AF93@muada.com> References: <4AE94ED6.5050600@it.uc3m.es> <B7943394-8740-4292-B0FF-1050B0DFD3FF@muada.com> <4AEA18CE.8040302@venaas.com> <200910292329.n9TNTmCx075617@drugs.dv.isc.org> <4AEAA15C.4060900@it.uc3m.es> <200910301320.n9UDKTOs099079@drugs.dv.isc.org> <4AEB99B5.8080106@gmail.com> To: Brian E Carpenter <brian.e.carpenter@gmail.com> X-Mailer: Apple Mail (2.1076) Cc: Stig Venaas <stig@venaas.com>, Behave WG <behave@ietf.org>, Mark Andrews <marka@isc.org> Subject: Re: [BEHAVE] Amount of fragmentation resulting from translation 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: Sat, 31 Oct 2009 09:18:06 -0000 On 31 okt 2009, at 02:58, Brian E Carpenter wrote: > BTW, the MTU data observed in draft-defeche-ipv6-traffic-in-p2p- > networks > strongly support this for today's IPv6 world. Average observed IPv4 > MTU was 1498 bytes and average observed IPv6 MTU was 1289, obviously > telling us that 1280 is the dominant value in practice (at least > for hosts running BitTorrent). So it's not only the safe value to use, > but it's also not very sub-optimal. Disagree. I've been looking at IPv6 in BitTorrent a bit, and nearly all peers participating in BitTorrent over IPv6 use 6to4. Obviously there will be little overlap between 6to4 users and NAT64 users... I'll see if I can dig up some info from people visiting my websites over IPv6. From petithug@acm.org Sat Oct 31 07:45:38 2009 Return-Path: <petithug@acm.org> 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 C952A3A6931 for <behave@core3.amsl.com>; Sat, 31 Oct 2009 07:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.768 X-Spam-Level: X-Spam-Status: No, score=-100.768 tagged_above=-999 required=5 tests=[AWL=-1.147, BAYES_00=-2.599, FRT_VALIUM2=2.643, FUZZY_VLIUM=0.001, IP_NOT_FRIENDLY=0.334, 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 0uWa3tl2gjgg for <behave@core3.amsl.com>; Sat, 31 Oct 2009 07:45:37 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id D56CA3A692C for <behave@ietf.org>; Sat, 31 Oct 2009 07:45:37 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 7EA306C984CE; Sat, 31 Oct 2009 14:45:55 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 05DAD6C984B8; Sat, 31 Oct 2009 14:45:53 +0000 (UTC) Message-ID: <4AEC4DA1.8020405@acm.org> Date: Sat, 31 Oct 2009 07:45:53 -0700 From: Marc Petit-Huguenin <petithug@acm.org> User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: WashamFan <Washam.Fan@huaweisymantec.com> References: <01c101ca509f$f314a8c0$8e27460a@china.huawei.com> <61FFB311-CA42-4EE4-A6F9-3DE0581A9E8F@lilacglade.org> <4ADE0BAB.1040402@acm.org> <FF53CDBF-9204-490D-8D04-9DF806EFE275@lilacglade.org> <4AE0A9F0.2010106@acm.org> <839B17D7-0BDE-4F11-8DC6-BDF694F7521D@lilacglade.org> <4AE4A119.5050007@acm.org> <9009E8A3-5FFE-4692-8EC6-BD038C5E728D@lilacglade.org> <fc04d8cd4041.4aec65f6@huaweisymantec.com> In-Reply-To: <fc04d8cd4041.4aec65f6@huaweisymantec.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman <mrw@lilacglade.org>, Behave WG <behave@ietf.org> Subject: Re: [BEHAVE] Opsdir Review of draft-ietf-behave-turn-uri-03.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: Sat, 31 Oct 2009 14:45:38 -0000 Hi Washam, WashamFan wrote: > Hi, > >> > "After verifying the validity of the URI elements, the algorithm >> > filters the list of TURN transports supported by the application by >> > keeping only the UDP and TCP TURN transports if the <scheme> is >> > defined as "turn" and by keeping only the TLS TURN transport if the >> > <scheme> is defined as "turns". If the list of TURN transports is >> > empty after this filtering, the resolution MUST stop with an error." > > Please look at the example illustrated in section 5, "turn:example.com" > URI turns out to be keeping UDP, TCP, and TLS. The example is generated by my reference implementation. After implementing the new filtering rule, the I-D will automatically contain the correct text. A new I-D will be released as soon the blackout period is over (should be Monday 9th). Thanks. -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From brian.e.carpenter@gmail.com Sat Oct 31 13:00:47 2009 Return-Path: <brian.e.carpenter@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 3FC1B3A67D7 for <behave@core3.amsl.com>; Sat, 31 Oct 2009 13:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 E+FD5sY0fbJ1 for <behave@core3.amsl.com>; Sat, 31 Oct 2009 13:00:46 -0700 (PDT) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id 3EACB3A6767 for <behave@ietf.org>; Sat, 31 Oct 2009 13:00:46 -0700 (PDT) Received: by pxi1 with SMTP id 1so2740410pxi.32 for <behave@ietf.org>; Sat, 31 Oct 2009 13:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=BJRikB4lMzYtMQyYEaKupAYB4gLsxP7/4E/ylVF//3s=; b=R8+Q3zj5H77amIoxvtWj5+MrjwprDtvjJD4SAdroSYTX7/L2x/8MUuqGbZueYaXtq3 HHeuaX0Odud0Mfno7wp6g7/w+bfmAt+prbaIi4pk0RH5rKKF2OMzClPpX6UhUJh9az6q 5ReEEMiGpt6ZdFFRohSNoKkExOtNmQu9/b94k= 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=aptjWlGwbvQqpssM0Mmtkmdj/iuJUklKgolTglJMHMPpkml9nQ1PWiXmXlmdZ6VepV Ni8DqqZ1RuSBDXIcYTwgyruPyx/W9eIq2vN41QZDEWuta2wPC2CAzi4BbCKDl3OyqAsG VmGw9cCenXDlp4vzVVZ27nHn45h+xnsV/2Erc= Received: by 10.115.38.32 with SMTP id q32mr3894957waj.8.1257019261103; Sat, 31 Oct 2009 13:01:01 -0700 (PDT) Received: from ?10.1.1.4? ([121.98.142.15]) by mx.google.com with ESMTPS id 20sm294448pxi.3.2009.10.31.13.00.58 (version=SSLv3 cipher=RC4-MD5); Sat, 31 Oct 2009 13:01:00 -0700 (PDT) Message-ID: <4AEC9777.6070607@gmail.com> Date: Sun, 01 Nov 2009 09:00:55 +1300 From: Brian E Carpenter <brian.e.carpenter@gmail.com> Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Iljitsch van Beijnum <iljitsch@muada.com> References: <4AE94ED6.5050600@it.uc3m.es> <B7943394-8740-4292-B0FF-1050B0DFD3FF@muada.com> <4AEA18CE.8040302@venaas.com> <200910292329.n9TNTmCx075617@drugs.dv.isc.org> <4AEAA15C.4060900@it.uc3m.es> <200910301320.n9UDKTOs099079@drugs.dv.isc.org> <4AEB99B5.8080106@gmail.com> <073AB33C-10FF-47F5-B4CA-9AF8F5A1AF93@muada.com> In-Reply-To: <073AB33C-10FF-47F5-B4CA-9AF8F5A1AF93@muada.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Stig Venaas <stig@venaas.com>, Behave WG <behave@ietf.org>, Mark Andrews <marka@isc.org> Subject: Re: [BEHAVE] Amount of fragmentation resulting from translation 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: Sat, 31 Oct 2009 20:00:47 -0000 On 2009-10-31 22:18, Iljitsch van Beijnum wrote: > On 31 okt 2009, at 02:58, Brian E Carpenter wrote: > >> BTW, the MTU data observed in draft-defeche-ipv6-traffic-in-p2p-networks >> strongly support this for today's IPv6 world. Average observed IPv4 >> MTU was 1498 bytes and average observed IPv6 MTU was 1289, obviously >> telling us that 1280 is the dominant value in practice (at least >> for hosts running BitTorrent). So it's not only the safe value to use, >> but it's also not very sub-optimal. > > Disagree. > > I've been looking at IPv6 in BitTorrent a bit, and nearly all peers > participating in BitTorrent over IPv6 use 6to4. Obviously there will be > little overlap between 6to4 users and NAT64 users... Actually draft-defeche shows that Teredo is twice as important as 6to4, but yes, most of the 1280s come from automatic tunnels. But I don't get your argument: if the PMTU is limited to 1280 anywhere in the IPv6 domain, it's a problem, for some of the deployment scenarios for draft-ietf-behave-v6v4-xlate. > > I'll see if I can dig up some info from people visiting my websites over > IPv6. Yes, that would be valuable. Brian