From roberta.maglione@telecomitalia.it Thu Sep 1 00:46:48 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A9121F8AF6 for ; Thu, 1 Sep 2011 00:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.312 X-Spam-Level: X-Spam-Status: No, score=0.312 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jR7aA0PdBxzd for ; Thu, 1 Sep 2011 00:46:47 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 633AC21F8AD3 for ; Thu, 1 Sep 2011 00:46:47 -0700 (PDT) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 1 Sep 2011 09:48:11 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Thu, 1 Sep 2011 09:48:11 +0200 From: Maglione Roberta To: 'Mikael Abrahamsson' , Simon Perreault Date: Thu, 1 Sep 2011 09:48:11 +0200 Thread-Topic: [BEHAVE] Question on draft-ietf-behave-lsn-requirements-03.txt Thread-Index: AcxoZP5Dodfw1F12RxiKCdLHdYJaLAAFZdEg Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53DCB@GRFMBX704BA020.griffon.local> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53DAC@GRFMBX704BA020.griffon.local> <4E5E44C5.3030400@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Question on draft-ietf-behave-lsn-requirements-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2011 07:46:48 -0000 In my country the law requires to keep logs for 5 years and we are not allo= wed to log destination information for privacy reasons. Having the possibility to use port range would help reducing the amount of = data we need to store. Roberta -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Mikael Abrahamsson Sent: gioved=EC 1 settembre 2011 7.07 To: Simon Perreault Cc: behave@ietf.org Subject: Re: [BEHAVE] Question on draft-ietf-behave-lsn-requirements-03.txt On Wed, 31 Aug 2011, Simon Perreault wrote: > Mikael Abrahamsson wrote, on 08/27/2011 02:31 AM: >> I support making it a MUST requirement, due to the fact that without it,= it's >> nearly impossible to handle the logging load. > > According to previous calculations, the logging load is not unmanageable. > See . There are markets where there is either already a requirement, or talk about putting into law a requirement to save such data for 3 years. When one is talking about many tens of gigabits/s of traffic we're talking really serious storage systems (hundreds of terabytes if not thousands of terabytes of storage). Avoiding logging any kind of destination information is to be preferred, only logging the source port range being made available for the customer and requiring the party wanting information to supply time,IP address and port to track an individual user, makes the logging load go down by factor 1000 or more in our calculations. -- Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From mohamed.boucadair@orange-ftgroup.com Thu Sep 1 06:44:06 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A73D21F95F6 for ; Thu, 1 Sep 2011 06:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIlk-oYhJu4M for ; Thu, 1 Sep 2011 06:44:05 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC6E21F95EB for ; Thu, 1 Sep 2011 06:44:05 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 56AD53B440B; Thu, 1 Sep 2011 15:45:37 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 3F74C27C08F; Thu, 1 Sep 2011 15:45:37 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Thu, 1 Sep 2011 15:45:36 +0200 From: To: "'behave@ietf.org'" Date: Thu, 1 Sep 2011 15:45:36 +0200 Thread-Topic: Request to adopt draft-boucadair-behave-bittorrent-address-sharing as WG document Thread-Index: Acwn1eguJRRv7kJmQ+Kd8tITmtQ4RwOOTDigAADynkAMpl0mkA== Message-ID: <94C682931C08B048B7A8645303FDC9F3516735E978@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.9.1.114814 Cc: Dan Wing Subject: [BEHAVE] Request to adopt draft-boucadair-behave-bittorrent-address-sharing as WG document X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2011 13:44:06 -0000 Dear all, I would like to have a feedback from the WG whether there is an interest to= adopt http://tools.ietf.org/html/draft-boucadair-behave-bittorrent-address= -sharing-00 as WG document. Comments and suggestions are welcome. Cheers, Med > -----Original Message----- > From: behave-bounces@ietf.org=20 > [mailto:behave-bounces@ietf.org] On Behalf Of Dan Wing > Sent: Friday, June 10, 2011 9:22 PM > To: Behave WG > Cc: behave-chairs@tools.ietf.org; 'Dave Thaler' > Subject: [BEHAVE] BEHAVE presentations at IETF81 >=20 >=20 > * draft-boucadair-behave-bittorrent-address-sharing -- I=20 > believe this was > going to be published AD-sponsored, unless there is interest=20 > in the working > group on this document? If folks want to look at it, and=20 > decide if they > could provide peer review, we might consider adopting this as=20 > a WG document. > Please let me know. >=20 From Tina.Tsou.Zouting@huawei.com Thu Sep 1 09:53:11 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F0F21F97C7 for ; Thu, 1 Sep 2011 09:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.267 X-Spam-Level: X-Spam-Status: No, score=-6.267 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BldTlNZ7hVl4 for ; Thu, 1 Sep 2011 09:53:09 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 20E9321F978B for ; Thu, 1 Sep 2011 09:53:08 -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 <0LQU00H6GSB477@szxga04-in.huawei.com> for behave@ietf.org; Fri, 02 Sep 2011 00:54:40 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQU0053JSB4KV@szxga04-in.huawei.com> for behave@ietf.org; Fri, 02 Sep 2011 00:54:40 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADT00477; Fri, 02 Sep 2011 00:54:39 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 02 Sep 2011 00:54:29 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.177]) by szxeml409-hub.china.huawei.com ([169.254.89.141]) with mapi id 14.01.0270.001; Fri, 02 Sep 2011 00:54:36 +0800 Date: Thu, 01 Sep 2011 16:54:35 +0000 From: Tina TSOU X-Originating-IP: [10.193.34.96] To: "behave@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_OUeLvzpq0lIZHTBT2RYLGw)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: [BEHAVE] Question on draft-ietf-behave-lsn-requirements-03.txt Thread-index: Acxj7567MSyHFhmhToaipwwx7VuprAAUE7sAANnGdoAABp0SgAAA0kEAAAFuuIAAE+pGEAAraNNw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [BEHAVE] FW: Question on draft-ietf-behave-lsn-requirements-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2011 16:53:11 -0000 --Boundary_(ID_OUeLvzpq0lIZHTBT2RYLGw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT From: Tina TSOU Sent: Wednesday, August 31, 2011 1:24 PM To: 'Jean-Francois.TremblayING@videotron.com'; simon.perreault@viagenie.ca Cc: behave-bounces@ietf.org; behave@ietf.org Subject: RE: [BEHAVE] Question on draft-ietf-behave-lsn-requirements-03.txt Jean-Francois and Simon, I think log and data retention is a normal requirement for CGN, and little data storage size is desired. The log capacity should not impact device performance. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Jean-Francois.TremblayING@videotron.com Sent: Wednesday, August 31, 2011 11:41 AM To: simon.perreault@viagenie.ca Cc: behave-bounces@ietf.org; behave@ietf.org Subject: Re: [BEHAVE] Question on draft-ietf-behave-lsn-requirements-03.txt >> The rationale here is that in many countries, law enforcement agencies mandate >> to keep these logs for at least a year, sometimes even longer. > Not disagreeing with you, but I fear that this rationale would go against RFC2804: > > The IETF has decided not to consider requirements for wiretapping as > part of the process for creating and maintaining IETF standards. > > I feel like it would make a stronger rationale if we focus on other advantages > of bulk port allocation... Good point. The definition of wiretapping in RFC2804 is wide enough that logging source ports is probably (barely) included in this context. Other advantages would be interesting, but I can't see any other reason to keep logs on the long term besides heating a building with spinning hard drives. >> With the numbers you refered >> to above (2.7 TB/day), this means nearly 1 Petabyte of storage per year *per CGN >> device*. > That with 1,000,000 bindings/sec, which is a lot. That's 15 IP addresses worth > of external ports consumed per second. That's a really big NAT! Of course, but even if logging is an order of magnitude smaller, this is only one NAT box in a network presumably using several CGNs. CGN is, by definition, a really big NAT. Logging without port ranges remains a non-trivial an operational problem. /JF --Boundary_(ID_OUeLvzpq0lIZHTBT2RYLGw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

 

 

From: Tina TSOU
Sent: Wednesday, August 31, 2011 1:24 PM
To: 'Jean-Francois.TremblayING@videotron.com'; simon.perreault@viagenie.ca
Cc: behave-bounces@ietf.org; behave@ietf.org
Subject: RE: [BEHAVE] Question on draft-ietf-behave-lsn-requirements-03.txt

 

Jean-Francois and Simon,

I think log and data retention is a normal requirement for CGN, and little data storage size is desired. The log capacity should not impact device performance.

 

 

Best Regards,

Tina TSOU

http://tinatsou.weebly.com/contact.html

 

From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Jean-Francois.TremblayING@videotron.com
Sent: Wednesday, August 31, 2011 11:41 AM
To: simon.perreault@viagenie.ca
Cc: behave-bounces@ietf.org; behave@ietf.org
Subject: Re: [BEHAVE] Question on draft-ietf-behave-lsn-requirements-03.txt

 


>> The rationale here is that in many countries, law enforcement agencies mandate
>> to keep these logs for at least a year, sometimes even longer.
> Not disagreeing with you, but I fear that this rationale would go against RFC2804:
>
>   The IETF has decided not to consider requirements for wiretapping as
>   part of the process for creating and maintaining IETF standards.
>
> I feel like it would make a stronger rationale if we focus on other advantages
> of bulk port allocation...

Good point. The definition of wiretapping in RFC2804 is wide enough that logging
source ports is probably (barely) included in this context.

Other advantages would be interesting, but I can't see any other reason to keep
logs on the long term besides heating a building with spinning hard drives.


>> With the numbers you refered
>> to above (2.7 TB/day), this means nearly 1 Petabyte of storage per year *per CGN
>> device*.
> That with 1,000,000 bindings/sec, which is a lot. That's 15 IP addresses worth
> of external ports consumed per second. That's a really big NAT!

Of course, but even if logging is an order of magnitude smaller, this is only one
NAT box in a network presumably using several CGNs. CGN is, by definition,
a really big NAT. Logging without port ranges remains a non-trivial an operational problem.

/JF

--Boundary_(ID_OUeLvzpq0lIZHTBT2RYLGw)-- From lee.howard@twcable.com Thu Sep 1 05:02:54 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E536B21F8D70 for ; Thu, 1 Sep 2011 05:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.138 X-Spam-Level: X-Spam-Status: No, score=-0.138 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUIe7DlIx2D5 for ; Thu, 1 Sep 2011 05:02:54 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB1F21F8C83 for ; Thu, 1 Sep 2011 05:02:54 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,459,1309752000"; d="scan'208";a="254124791" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 01 Sep 2011 08:03:18 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Thu, 1 Sep 2011 08:04:11 -0400 From: "Howard, Lee" To: Simon Perreault , "Jean-Francois.TremblayING@videotron.com" Date: Thu, 1 Sep 2011 08:04:09 -0400 Thread-Topic: [BEHAVE] Question on draft-ietf-behave-lsn-requirements-03.txt Thread-Index: AcxoB91YK9uiSyt8RdCQ1KABdRAoXQAlwthw Message-ID: References: <4E5E76AA.3050208@viagenie.ca> In-Reply-To: <4E5E76AA.3050208@viagenie.ca> 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-Mailman-Approved-At: Thu, 01 Sep 2011 11:26:11 -0700 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Question on draft-ietf-behave-lsn-requirements-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2011 12:02:55 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf = Of Simon > Perreault > Jean-Francois.TremblayING@videotron.com wrote, on 08/31/2011 01:36 PM: > > The rationale here is that in many countries, law enforcement agencies = mandate > > to keep > > these logs for at least a year, sometimes even longer. > > Not disagreeing with you, but I fear that this rationale would go against= RFC2804: > > The IETF has decided not to consider requirements for wiretapping as > part of the process for creating and maintaining IETF standards. Wiretapping is not the same as logging. But the rationales for rfc2804 wou= ld apply in this case. Response to abuse complaints would be pretty operational. One form of abus= e complaint is the subpoena. Without logs, there's no way to know who the accused abuser is. Lee This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From Tina.Tsou.Zouting@huawei.com Wed Aug 31 13:23:03 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C42921F8E1B; Wed, 31 Aug 2011 13:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.257 X-Spam-Level: X-Spam-Status: No, score=-6.257 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrIy4FHwbcds; Wed, 31 Aug 2011 13:23:02 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id CAE9C21F8DBF; Wed, 31 Aug 2011 13:23:01 -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 <0LQT00ILJ7CTU1@szxga03-in.huawei.com>; Thu, 01 Sep 2011 04:24:29 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQT00BMA7CPZJ@szxga03-in.huawei.com>; Thu, 01 Sep 2011 04:24:29 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADR65770; Thu, 01 Sep 2011 04:24:28 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 01 Sep 2011 04:24:23 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.177]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Thu, 01 Sep 2011 04:24:26 +0800 Date: Wed, 31 Aug 2011 20:24:25 +0000 From: Tina TSOU In-reply-to: X-Originating-IP: [10.193.34.96] To: "Jean-Francois.TremblayING@videotron.com" , "simon.perreault@viagenie.ca" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_jhMeYW31gxSwpH2+WYrEqA)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: [BEHAVE] Question on draft-ietf-behave-lsn-requirements-03.txt Thread-index: Acxj7567MSyHFhmhToaipwwx7VuprAAUE7sAANnGdoAABp0SgAAA0kEAAAFuuIAAE+pGEA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4E5E76AA.3050208@viagenie.ca> X-Mailman-Approved-At: Thu, 01 Sep 2011 11:26:21 -0700 Cc: "behave@ietf.org" , "behave-bounces@ietf.org" Subject: Re: [BEHAVE] Question on draft-ietf-behave-lsn-requirements-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 20:23:03 -0000 --Boundary_(ID_jhMeYW31gxSwpH2+WYrEqA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Jean-Francois and Simon, I think log and data retention is a normal requirement for CGN, and little data storage size is desired. The log capacity should not impact device performance. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Jean-Francois.TremblayING@videotron.com Sent: Wednesday, August 31, 2011 11:41 AM To: simon.perreault@viagenie.ca Cc: behave-bounces@ietf.org; behave@ietf.org Subject: Re: [BEHAVE] Question on draft-ietf-behave-lsn-requirements-03.txt >> The rationale here is that in many countries, law enforcement agencies mandate >> to keep these logs for at least a year, sometimes even longer. > Not disagreeing with you, but I fear that this rationale would go against RFC2804: > > The IETF has decided not to consider requirements for wiretapping as > part of the process for creating and maintaining IETF standards. > > I feel like it would make a stronger rationale if we focus on other advantages > of bulk port allocation... Good point. The definition of wiretapping in RFC2804 is wide enough that logging source ports is probably (barely) included in this context. Other advantages would be interesting, but I can't see any other reason to keep logs on the long term besides heating a building with spinning hard drives. >> With the numbers you refered >> to above (2.7 TB/day), this means nearly 1 Petabyte of storage per year *per CGN >> device*. > That with 1,000,000 bindings/sec, which is a lot. That's 15 IP addresses worth > of external ports consumed per second. That's a really big NAT! Of course, but even if logging is an order of magnitude smaller, this is only one NAT box in a network presumably using several CGNs. CGN is, by definition, a really big NAT. Logging without port ranges remains a non-trivial an operational problem. /JF --Boundary_(ID_jhMeYW31gxSwpH2+WYrEqA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Jean-Francois and Simon,

I think log and data retention is a normal requirement for CGN, and little data storage size is desired. The log capacity should not impact device performance.

 

 

Best Regards,

Tina TSOU

http://tinatsou.weebly.com/contact.html

 

From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Jean-Francois.TremblayING@videotron.com
Sent: Wednesday, August 31, 2011 11:41 AM
To: simon.perreault@viagenie.ca
Cc: behave-bounces@ietf.org; behave@ietf.org
Subject: Re: [BEHAVE] Question on draft-ietf-behave-lsn-requirements-03.txt

 


>> The rationale here is that in many countries, law enforcement agencies mandate
>> to keep these logs for at least a year, sometimes even longer.
> Not disagreeing with you, but I fear that this rationale would go against RFC2804:
>
>   The IETF has decided not to consider requirements for wiretapping as
>   part of the process for creating and maintaining IETF standards.
>
> I feel like it would make a stronger rationale if we focus on other advantages
> of bulk port allocation...

Good point. The definition of wiretapping in RFC2804 is wide enough that logging
source ports is probably (barely) included in this context.

Other advantages would be interesting, but I can't see any other reason to keep
logs on the long term besides heating a building with spinning hard drives.


>> With the numbers you refered
>> to above (2.7 TB/day), this means nearly 1 Petabyte of storage per year *per CGN
>> device*.
> That with 1,000,000 bindings/sec, which is a lot. That's 15 IP addresses worth
> of external ports consumed per second. That's a really big NAT!

Of course, but even if logging is an order of magnitude smaller, this is only one
NAT box in a network presumably using several CGNs. CGN is, by definition,
a really big NAT. Logging without port ranges remains a non-trivial an operational problem.

/JF

--Boundary_(ID_jhMeYW31gxSwpH2+WYrEqA)-- From fbrockne@cisco.com Fri Sep 2 09:35:35 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15ACF21F8C07 for ; Fri, 2 Sep 2011 09:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.478 X-Spam-Level: X-Spam-Status: No, score=-10.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0+Au7TL0h1a for ; Fri, 2 Sep 2011 09:35:32 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id E02E121F8C06 for ; Fri, 2 Sep 2011 09:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fbrockne@cisco.com; l=18975; q=dns/txt; s=iport; t=1314981428; x=1316191028; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=/puxZW7fDl6r3ibPdtpqmpou/mmZzCD+FAnGuHJOwvQ=; b=BmBF3K5Ta2/R6mQCSM6zI9bgayIrsto0yqvJsfMYvAbxT1vqJkeSPuWj 3aQrh6ABZePaPeRgT93qPAuUSRqKBY08GP3iq80x9SP5yOLVj38garUiN UeKf36gXPZys5lW6tdQ8waihP6PszRWvY1XgiNq3gDI/2staISyHtVVT4 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsAANwFYU6Q/khR/2dsb2JhbABCgk2WJo90eIFGAQEBAQECEgEJEQNJEAIBCA4DBAEBCwYXAQYBRQkIAQEEARIIGodUmgIBnxCGBWAEmESLdw X-IronPort-AV: E=Sophos;i="4.68,320,1312156800"; d="scan'208,217";a="113726559" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 02 Sep 2011 16:37:06 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p82Gb62K005133; Fri, 2 Sep 2011 16:37:06 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Sep 2011 18:37:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC698E.8D27B55C" Date: Fri, 2 Sep 2011 18:37:01 +0200 Message-ID: <0D212BD466921646B58854FB79092CEC06898727@XMB-AMS-106.cisco.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B1CD01D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] My review of draft-ietf-dime-nat-control-09 Thread-Index: AcxTA1pwEoFdHujaQPeAdI8rofSx2AWidiSw References: <9B57C850BB53634CACEC56EF4853FF653B1CD01D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> From: "Frank Brockners (fbrockne)" To: "Dave Thaler" , , X-OriginalArrivalTime: 02 Sep 2011 16:37:06.0682 (UTC) FILETIME=[8D7AF5A0:01CC698E] Cc: behave@ietf.org, David Harrington , "Romascanu, Dan \(Dan\)" Subject: Re: [BEHAVE] My review of draft-ietf-dime-nat-control-09 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 16:35:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC698E.8D27B55C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dave, =20 thanks for your comments and detailed review and sorry for the delay in getting the draft updated. We just posted a new revision (draft-ietf-dime-nat-control-11), reflecting your comments. Please see additional comments inline... =20 From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Dave Thaler Sent: Friday, August 05, 2011 2:13 AM To: draft-ietf-dime-nat-control@tools.ietf.org; dime-chairs@tools.ietf.org Cc: David Harrington; behave@ietf.org; Romascanu, Dan (Dan) Subject: [BEHAVE] My review of draft-ietf-dime-nat-control-09 =20 My review of this draft is at http://research.microsoft.com/en-us/um/people/dthaler/draft-ietf-dime-na t-control-09.pdf or (same content) http://research.microsoft.com/en-us/um/people/dthaler/draft-ietf-dime-na t-control-09.docx =20 High level questions: 1) The model discussed in the draft appears to assume there's only one NAT device in the domain. In contrast, the models in the Behave WG allow for multiple. What happens if there are multiple NAT-devices (for failover or load balancing or whatever else)? .....FB: We clarified that DNCA applies to n:m scenarios, with n NAT-Controllers and m NAT-devices. Section 3.3 now discusses this: =20 3.3. Deployment Scenarios For DNCA =20 DNCA can be deployed in different ways. DNCA supports deployments with "n" NAT-controllers and "m" NAT-devices, with n and m equal to or greater than 1. For DNCA, the session representing a particular endpoint is atomic. Any deployment MUST ensure that for every given endpoint only a single NAT-controller and only a single NAT-device are active at any point in time. This is to ensure that NAT-devices controlled by multiple NAT-controllers do not receive conflicting control requests for a particular endpoint, or would be unclear which NAT-controller to send accounting information to. =20 =20 2) Security seems to be a MAY. Why not a SHOULD or a MUST? Using only a MAY warrants an explanation. ...FB: Agreed. And we refer to security as a SHOULD throughout the document. =20 3) There's no mention of DoS attack by filling up logs. Is that a concern? =20 ...FB: It could be a concern, if the logging infrastructure is not designed with potential DoS attacks in mind. We've updated the security section to reflect this (see section 12): =20 [..] Failing of any of the two DNCA Diameter peers to provide the required credentials should be subject to logging. The corresponding logging infrastructure of the operator SHOULD be built in a way that it can mitigate potential denial of service attacks resulting from large amounts of logging events. This could include proper dimensioning of the logging infrastructure combined with policing the maximum amount of logging events accepted by the logging system to a threshold which the system is known to be able to handle. =20 =20 Rest is mostly editorial nits. ...FB: Thanks for catching all these nits. Really helpful (and hopefully we reflected all of them in revision -11) =20 I also reviewed it for consistency with RFC 4008 and for consistency with draft-ietf-behave-lsn-requirements, and I didn't spot any inconsistencies other that in question 1 above. =20 Regards, Frank =20 =20 -Dave ------_=_NextPart_001_01CC698E.8D27B55C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dave,

 

thanks for your = comments and detailed review and sorry for the delay in getting the draft updated. We = just posted a new revision (draft-ietf-dime-nat-control-11), reflecting your comments. Please see additional comments inline...

 

From:= behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of = Dave Thaler
Sent: Friday, August 05, 2011 2:13 AM
To: draft-ietf-dime-nat-control@tools.ietf.org; dime-chairs@tools.ietf.org
Cc: David Harrington; behave@ietf.org; Romascanu, Dan (Dan)
Subject: [BEHAVE] My review of = draft-ietf-dime-nat-control-09

 

My review of this draft is at

http://research.microsoft.com/en-us/um/people/dt= haler/draft-ietf-dime-nat-control-09.pdf

or (same content)

http://research.microsoft.com/en-us/um/people/d= thaler/draft-ietf-dime-nat-control-09.docx

 

High level questions:

1)      The model discussed in the draft appears to assume there’s only one = NAT device in the domain.  In contrast, the models in the Behave WG = allow for multiple.   What happens if there are multiple NAT-devices = (for failover or load balancing or whatever else)?

…..FB: We clarified that DNCA applies to = n:m scenarios, with n NAT-Controllers and m NAT-devices. Section 3.3 now = discusses this:

 

3.3.  Deployment Scenarios For = DNCA

 

   DNCA can be deployed in different = ways.  DNCA supports deployments

   with "n" NAT-controllers and "m" NAT-devices, with n and m equal to

   or greater than 1.  For DNCA, the = session representing a particular

   endpoint is atomic.  Any deployment = MUST ensure that for every given

   endpoint only a single NAT-controller and = only a single NAT-device

   are active at any point in time.  This = is to ensure that NAT-devices

   controlled by multiple NAT-controllers do = not receive conflicting

   control requests for a particular endpoint, = or would be unclear which

   NAT-controller to send accounting = information to.

 

 

2)      Security seems to be a MAY.   Why not a SHOULD or a MUST?   = Using only a MAY warrants an explanation.

…FB: Agreed. And we refer to security as a SHOULD throughout the = document.

 

3)      There’s no mention of DoS attack by filling up logs.   Is that a = concern?

 

...FB: It could be a concern, if the logging = infrastructure is not designed with potential DoS attacks in mind. We've updated the =  security section to reflect this (see section 12):

 

   [..] = Failing

   of = any of the two DNCA Diameter peers to provide the required

   = credentials should be subject to logging.  The corresponding = logging

   = infrastructure of the operator SHOULD be built in a way that it = can

   = mitigate potential denial of service attacks resulting from = large

   = amounts of logging events.  This could include proper dimensioning = of

   the = logging infrastructure combined with policing the maximum = amount

   of = logging events accepted by the logging system to a threshold = which

   the = system is known to be able to handle.

 

 

Rest is mostly editorial nits.

…FB: Thanks for = catching all these nits. Really helpful (and hopefully we reflected all of them = in revision -11)

 

I also reviewed it for consistency with RFC 4008 = and for consistency with draft-ietf-behave-lsn-requirements, and I didn’t = spot any inconsistencies other that in question 1 above.

 

Regards, = Frank

 

 

-Dave

------_=_NextPart_001_01CC698E.8D27B55C-- From simon.perreault@viagenie.ca Mon Sep 5 13:34:44 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36F421F87D3; Mon, 5 Sep 2011 13:34:44 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLgoZMKnqqxD; Mon, 5 Sep 2011 13:34:44 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4BC21F86EE; Mon, 5 Sep 2011 13:34:44 -0700 (PDT) Received: from balaise.nomis80.org (modemcable065.20-22-96.mc.videotron.ca [96.22.20.65]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E427B21E3E; Mon, 5 Sep 2011 16:36:28 -0400 (EDT) Message-ID: <4E6532CC.1090607@viagenie.ca> Date: Mon, 05 Sep 2011 16:36:28 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: opsawg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: [BEHAVE] NAT-MIB bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2011 20:34:45 -0000 Hello, This was just posted: http://tools.ietf.org/html/draft-perreault-opsawg-natmib-bis-00 There's been some work on MIBs in BEHAVE lately. There are a number of new things that require an update to RFC 4008: - DS-Lite (shared internal address pools) - CGNs (thresholds, alarms, statistics, etc.) - NAT64 and RFC 4008 itself is in need of some polishing independent of those. That's why we started a NAT-MIB bis draft. You can see in section 2 that most of the items are marked TO-DO. We will continue working on this draft. At this point we would like some early feedback on the worthiness of this effort. Will NAT vendors implement this? Do operators need this? Does this make technical sense? Text contribution is also very welcome. As BEHAVE is shutting down, we would like to invite discussion on the OPSAWG mailing list. We would like this draft to be adopted by a working group eventually, and would appreciate guidance on this as well. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From iljitsch@muada.com Tue Sep 6 06:48:18 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3990D21F87D9 for ; Tue, 6 Sep 2011 06:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLzOi4ZOYGqA for ; Tue, 6 Sep 2011 06:48:17 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 70EF021F87C5 for ; Tue, 6 Sep 2011 06:48:17 -0700 (PDT) Received: from [IPv6:2001:720:410:100f:21b:63ff:fe95:7d9b] ([IPv6:2001:720:410:100f:21b:63ff:fe95:7d9b]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p86Dnn6o018669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 6 Sep 2011 15:49:49 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Iljitsch van Beijnum In-Reply-To: <94C682931C08B048B7A8645303FDC9F3516735E978@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 6 Sep 2011 15:49:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <878C4AEF-F4B6-4FF4-BBEA-1A8AFABB990B@muada.com> References: <94C682931C08B048B7A8645303FDC9F3516735E978@PUEXCB1B.nanterre.francetelecom.fr> To: "behave@ietf.orgWG WG" X-Mailer: Apple Mail (2.1084) Subject: Re: [BEHAVE] Request to adopt draft-boucadair-behave-bittorrent-address-sharing as WG document X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2011 13:48:18 -0000 On 1 sep 2011, at 15:45, = wrote: > = http://tools.ietf.org/html/draft-boucadair-behave-bittorrent-address-shari= ng-00=20 > Comments and suggestions are welcome. Why did you use the address 193.51.145.206 as the shared address rather = than an RFC 1918 address? This way special case logic for address = sharing in the application, if any, will probably remain unused. Also, = this address is in the same subnet as the other non-shared peers, which = may trigger other special case logic. Testing with both regular and private addresses would be best. A lot of text is presented in narrow columns in long, page break = spanning tables. Don't do this. I can't stand to read it. Considering the fact that the found issue (under one of two possible = configuration settings two peers sharing an address can't connect to a = single other peer) is a pretty extreme corner case which doesn't even = preclude eventual successful downloading and the BitTorrent protocol = (unless I missed something) isn't published as an RFC, I don't think = this work is in the right place here so it shouldn't be adopted as a WG = document and it shouldn't be published as an RFC. Even if the "belongs = here" isn't found persuasive both the strange test setup and the = unfortunate formatting make this document too immature for WG adoption.= From cb.list6@gmail.com Tue Sep 6 13:02:05 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFE421F8E03 for ; Tue, 6 Sep 2011 13:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1Ffv2Qu0Lyf for ; Tue, 6 Sep 2011 13:02:04 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9847021F8E02 for ; Tue, 6 Sep 2011 13:01:51 -0700 (PDT) Received: by pzk33 with SMTP id 33so16994871pzk.18 for ; Tue, 06 Sep 2011 13:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=qVVEOJkOz4Hs/l7qeyqxFIujidaJnt3fpZXOFQYOAKA=; b=UZmLLmAW0dWXQZZ7ls3PO2Qj7Ki7i4wlkIuH4Me//3p8BvCaxMj6XLMIyxAhKTONcE Mnc2Jl7Na6SFDfbVu9bKAMpJlKtyNvZ0nhW4//vmLfUQyrOtdeZeQEuF+83mc8RAuOPH yVNOtVS6sVbHAzTT+mF13ii8chfm7mj4yKPUA= MIME-Version: 1.0 Received: by 10.68.28.103 with SMTP id a7mr619839pbh.160.1315339418936; Tue, 06 Sep 2011 13:03:38 -0700 (PDT) Received: by 10.143.41.1 with HTTP; Tue, 6 Sep 2011 13:03:38 -0700 (PDT) In-Reply-To: <000101cc48b3$a9f87500$fde95f00$@com> References: <000101cc48b3$a9f87500$fde95f00$@com> Date: Tue, 6 Sep 2011 13:03:38 -0700 Message-ID: From: Cameron Byrne To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org, draft-ietf-behave-nat64-learn-analysis@tools.ietf.org Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-nat64-learn-analysis-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2011 20:02:05 -0000 On Fri, Jul 22, 2011 at 2:09 PM, Dan Wing wrote: > This starts a 3 week WGLC (extra time to accommodate IETF travel) for > draft-ietf-behave-nat64-learn-analysis-00. =A0This document analyzes the > available approaches for a host to learn its NAT64 prefix. =A0Abstract: > > =A0 Hosts and applications may benefit from the knowledge if an IPv6 > =A0 address is synthesized, which would mean a NAT64 is used to reach the > =A0 IPv4 network or Internet. =A0This document analyses a number of > =A0 proposed solutions for communicating whether the synthesis is taking > =A0 place, used address format, and the IPv6 prefix used by the NAT64 and > =A0 DNS64. =A0The solutions enable both NAT64 avoidance and intentional > =A0 utilization by allowing local IPv6 address synthesis. =A0The document > =A0 concludes by recommending selection of heuristic discovery based > =A0 solution. > > Please send comments to behave@ietf.org. =A0WGLC ends in 3 weeks on > August 12. > Sorry for writing late. I believe this is a good document and that we should move forward with the recommendation of publishing a well known name for learning the PREF64. This path is consistent with the the overall NAT64 / DNS64 philosophy of working within the existing technology to the greatest extent possible. Cameron From despres.remi@laposte.net Wed Sep 7 02:48:11 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5CE21F8540 for ; Wed, 7 Sep 2011 02:48:11 -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.065, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYq6B+tcTU1e for ; Wed, 7 Sep 2011 02:48:10 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.4]) by ietfa.amsl.com (Postfix) with ESMTP id 84FD721F853A for ; Wed, 7 Sep 2011 02:48:10 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2116.sfr.fr (SMTP Server) with ESMTP id 21C4B700021F; Wed, 7 Sep 2011 11:49:59 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2116.sfr.fr (SMTP Server) with ESMTP id E2AD670000A6; Wed, 7 Sep 2011 11:49:58 +0200 (CEST) X-SFR-UUID: 20110907094958928.E2AD670000A6@msfrf2116.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <94C682931C08B048B7A8645303FDC9F3516735E978@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 7 Sep 2011 11:49:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94C682931C08B048B7A8645303FDC9F3516735E978@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 07 Sep 2011 10:02:52 -0700 Cc: "'behave@ietf.org'" , Dan Wing Subject: Re: [BEHAVE] Request to adopt draft-boucadair-behave-bittorrent-address-sharing as WG document X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2011 09:48:11 -0000 Le 1 sept. 2011 =E0 15:45, = a =E9crit : > Dear all, >=20 > I would like to have a feedback from the WG whether there is an = interest to adopt = http://tools.ietf.org/html/draft-boucadair-behave-bittorrent-address-shari= ng-00 as WG document. >=20 > Comments and suggestions are welcome. +1 to make it a WG document. RD >=20 > Cheers, > Med >=20 >=20 >> -----Original Message----- >> From: behave-bounces@ietf.org=20 >> [mailto:behave-bounces@ietf.org] On Behalf Of Dan Wing >> Sent: Friday, June 10, 2011 9:22 PM >> To: Behave WG >> Cc: behave-chairs@tools.ietf.org; 'Dave Thaler' >> Subject: [BEHAVE] BEHAVE presentations at IETF81 >>=20 >=20 >>=20 >> * draft-boucadair-behave-bittorrent-address-sharing -- I=20 >> believe this was >> going to be published AD-sponsored, unless there is interest=20 >> in the working >> group on this document? If folks want to look at it, and=20 >> decide if they >> could provide peer review, we might consider adopting this as=20 >> a WG document. >> Please let me know. >>=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From brian.e.carpenter@gmail.com Wed Sep 7 21:27:14 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D84121F8A7D for ; Wed, 7 Sep 2011 21:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.586 X-Spam-Level: X-Spam-Status: No, score=-103.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeqmINYlvae9 for ; Wed, 7 Sep 2011 21:27:13 -0700 (PDT) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by ietfa.amsl.com (Postfix) with ESMTP id D213021F8A57 for ; Wed, 7 Sep 2011 21:27:13 -0700 (PDT) Received: by gxk9 with SMTP id 9so624112gxk.40 for ; Wed, 07 Sep 2011 21:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=cjl6O/qNaAQ65za9gFoHUMrJiPoQf7RGtL2dTLjon9Q=; b=QGqmxYyL8HAYnsxADe8IE1kEgE0+bQx6uluLd6Rz5wLLfd01dvW0vbxHuP9nRvjCcI iWiBsVKvLqzc6MigFu0tcgUH8QwJODkMdPEyVP7f57Rru5lE9OYAFyEU9HpDWlwkZyQY dhrdoOGk1smxrq1mt3nf3l6aInX9eZKI+K6b8= Received: by 10.236.89.70 with SMTP id b46mr1182248yhf.38.1315456142337; Wed, 07 Sep 2011 21:29:02 -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 l69sm2315393yhj.21.2011.09.07.21.29.00 (version=SSLv3 cipher=OTHER); Wed, 07 Sep 2011 21:29:01 -0700 (PDT) Message-ID: <4E68448A.5040905@gmail.com> Date: Thu, 08 Sep 2011 16:28:58 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: behave@ietf.org References: <20110831135349.14909.10061.idtracker@ietfa.amsl.com> In-Reply-To: <20110831135349.14909.10061.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2011 04:27:14 -0000 Hi, (Not copied to the IETF list, as it is an editorial point really. I'm sorry I didn't see it before. Please view in Courier font.) I have a little trouble with Figure 2: | +------------------------------------------+ +---------+ | | | IPv4 | | | | | +------------------------------------------+ | Address | | | +------------------+ +---------------------+ | Mapper | | | | Protocol | | Extension Name | | | | | | Translator | | Resolver | | | | | +------------------+ +---------------------+ | | | | +------------------------------------------+ | | | | | IPv4 / IPv6 | | | | | +------------------------------------------+ +---------+ | +------------------------------------------------------------+ Figure 2: Architecture of a dual-stack host using protocol translation at the network layer The label "IPv4 / IPv6" is confusing. The only pathway we care about is IPv4->translator/resolver->IPv6. I suppose IPv4 is shown because this is *also* a dual stack node, but in that case you should also show an optional direct IPv4 pathway. Something like this: | +------------------------------------------+ +---------+ | | | IPv4 | | | | | +------------------------------------------+ | Address | | | | +-----------------+ +------------------+ | Mapper | | | | | Protocol | | Extension Name | | | | | | | Translator | | Resolver | | | | | | +-----------------+ +------------------+ | | | | | +---------------------------------------+ | | | | | | IPv6 | | | | | | +---------------------------------------+ +---------+ | +---V--------------------------------------------------------+ Regards Brian Carpenter On 2011-09-01 01:53, The IESG wrote: > The IESG has received a request from the Behavior Engineering for > Hindrance Avoidance WG (behave) to consider the following document: > - 'Dual Stack Hosts Using "Bump-in-the-Host" (BIH)' > 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 2011-09-14. 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. > > Abstract > > > Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol > translation mechanism that allows a class of IPv4-only applications > that work through NATs to communicate with IPv6-only peers. The host > on which applications are running may be connected to IPv6-only or > dual-stack access networks. BIH hides IPv6 and makes the IPv4-only > applications think they are talking with IPv4 peers by local > synthesis of IPv4 addresses. This draft obsoletes RFC 2767 and RFC > 3338. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From jiangdong345@gmail.com Thu Sep 8 01:26:12 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8ADB21F84FA for ; Thu, 8 Sep 2011 01:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=-2.272, BAYES_20=-0.74, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03HKF2aU3VGM for ; Thu, 8 Sep 2011 01:26:12 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 756BB21F84AD for ; Thu, 8 Sep 2011 01:26:12 -0700 (PDT) Received: by yxj20 with SMTP id 20so486258yxj.31 for ; Thu, 08 Sep 2011 01:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:references:subject:message-id:x-mailer:mime-version :content-type:content-transfer-encoding; bh=qIK4MxNBgaUTM6FAee3Dy1oq8Kqf6wQ5k4LbhliKIRE=; b=bPhfX9e+lmK/MbxL9CqlI9rciTHhGVylD7nQZNktYXxmndPxsYLEvKA745g4dWuisN OIsZGNuw50rgDxyZyDNkFeD7CWHCAoZz6WzuE+txlRtndvqOizMKCvk5ClfmS2zflX8P KCJCFZ9hyKezSJxsOwLEfTDVObBtuXtWTU+Ws= Received: by 10.43.45.74 with SMTP id uj10mr163629icb.217.1315470483750; Thu, 08 Sep 2011 01:28:03 -0700 (PDT) Received: from DJ-PC ([166.111.68.231]) by mx.google.com with ESMTPS id v2sm4325583ibg.2.2011.09.08.01.28.01 (version=SSLv3 cipher=OTHER); Thu, 08 Sep 2011 01:28:03 -0700 (PDT) Date: Thu, 8 Sep 2011 16:28:51 +0800 From: Jiang Dong To: "behave" References: <20110831135349.14909.10061.idtracker@ietfa.amsl.com> Message-ID: <201109081628463511658@gmail.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Subject: [BEHAVE] Are there any experiment drafts talking about how CGN influence applications like p2p? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2011 08:26:13 -0000 SGmjrA0KCUFyZSB0aGVyZSBhbnkgZXhwZXJpbWVudCBkcmFmdHMgdGFsa2luZyBhYm91dCAgaG93 IENHTiBpbmZsdWVuY2UgYXBwbGljYXRpb25zIGxpa2UgcDJwPw0KCVRoYWsgeW91IGZvciB5b3Vy IGtpbmRseSBoZWxwIGlmIHNvbWVvbmUgY2FuIGdpdmUgbWUgYSBsaW5rLg0KDQoJQmVzdCBSZWdh cmRzIQ0KCUppYW5nIERvbmcNCg0K From mohamed.boucadair@orange-ftgroup.com Thu Sep 8 01:35:17 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DCB21F8B74 for ; Thu, 8 Sep 2011 01:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.197 X-Spam-Level: X-Spam-Status: No, score=-3.197 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hg43nl2OLiv2 for ; Thu, 8 Sep 2011 01:35:16 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6670521F8B70 for ; Thu, 8 Sep 2011 01:35:16 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id E64BE18C3CF; Thu, 8 Sep 2011 10:37:06 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id C8F6F23807B; Thu, 8 Sep 2011 10:37:06 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Thu, 8 Sep 2011 10:37:06 +0200 From: To: Jiang Dong , behave Date: Thu, 8 Sep 2011 10:37:05 +0200 Thread-Topic: [BEHAVE] Are there any experiment drafts talking about how CGN influence applications like p2p? Thread-Index: AcxuAUCIGh8lkBxRTWeJfhIP2j5YqgAAElwg Message-ID: <94C682931C08B048B7A8645303FDC9F351674475F2@PUEXCB1B.nanterre.francetelecom.fr> References: <20110831135349.14909.10061.idtracker@ietfa.amsl.com> <201109081628463511658@gmail.com> In-Reply-To: <201109081628463511658@gmail.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F351674475F2PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.9.8.60018 Subject: Re: [BEHAVE] Are there any experiment drafts talking about how CGN influence applications like p2p? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2011 08:35:17 -0000 --_000_94C682931C08B048B7A8645303FDC9F351674475F2PUEXCB1Bnante_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBKaWFuZywNCg0KV2UgaGF2ZSBkb25lIGV4dGVuc2l2ZSB0ZXN0aW5nIHdpdGggQ0dOIChE Uy1MaXRlKSBpbXBsZW1lbnRhdGlvbnMgZnJvbSB2YXJpb3VzIHZlbmRvcnMgdG8gYXNzZXNzIHRo ZSBiZWhhdmlvdXIgb2YgUDJQIGFwcGxpY2F0aW9ucyAoZS5nLiwgZW11bGUsIFNreXBlLCBCaXR0 b3JlbnQpLiBUaGUgdGVzdGluZyBoYXZlIGJlZW4gdW5kZXJ0YWtlbiBpbiB0d28gY29uZmlndXJh dGlvbiAocG9ydCBmb3J3YXJkaW5nIGFjdGl2YXRlZCB2cy4gbm8gcG9ydCBmb3J3YXJkaW5nKS4g V2UgZGlkbid0IHB1Ymxpc2hlZCBhbnkgcmVwb3J0IGFib3V0IGFsbCB0aGVzZSB2YWxpZGF0aW9u IHRlc3RpbmcuDQoNCkJUVywgd2UgaGF2ZSBwdWJsaXNoZWQgYSBkZXRhaWxlZCByZXBvcnQgYWJv dXQgdGhlIGJlaGF2aW91ciBvZiBCaXR0b3JlbnQgaW4gYSBzaGFyZWQgZW52aXJvbm5lbW50ICh0 aGUgY29uY2x1c2lvbiBvZiB0aGF0IEktRCBhcHBsaWVzIGZvciB0aGUgQ0dOIGNhc2UgYWxzbyku IFRoZSBkb2N1bWVudCBpcyBhdmFpbGFibGUgYXQ6DQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWJvdWNhZGFpci1iZWhhdmUtYml0dG9ycmVudC1hZGRyZXNzLXNoYXJpbmctMDAN Cg0KQ2hlZXJzLA0KTWVkDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGUgOiBiZWhh dmUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmJlaGF2ZS1ib3VuY2VzQGlldGYub3JnXSBEZSBs YSBwYXJ0IGRlIEppYW5nIERvbmcNCkVudm95w6kgOiBqZXVkaSA4IHNlcHRlbWJyZSAyMDExIDEw OjI5DQrDgCA6IGJlaGF2ZQ0KT2JqZXQgOiBbQkVIQVZFXSBBcmUgdGhlcmUgYW55IGV4cGVyaW1l bnQgZHJhZnRzIHRhbGtpbmcgYWJvdXQgaG93IENHTiBpbmZsdWVuY2UgYXBwbGljYXRpb25zIGxp a2UgcDJwPw0KDQpIae+8jA0KICAgICAgICBBcmUgdGhlcmUgYW55IGV4cGVyaW1lbnQgZHJhZnRz IHRhbGtpbmcgYWJvdXQgIGhvdyBDR04gaW5mbHVlbmNlIGFwcGxpY2F0aW9ucyBsaWtlIHAycD8N CiAgICAgICAgVGhhayB5b3UgZm9yIHlvdXIga2luZGx5IGhlbHAgaWYgc29tZW9uZSBjYW4gZ2l2 ZSBtZSBhIGxpbmsuDQoNCiAgICAgICAgQmVzdCBSZWdhcmRzIQ0KICAgICAgICBKaWFuZyBEb25n DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpCZWhh dmUgbWFpbGluZyBsaXN0DQpCZWhhdmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vYmVoYXZlDQo= --_000_94C682931C08B048B7A8645303FDC9F351674475F2PUEXCB1Bnante_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT48L1RJVExFPg0KPE1FVEEgY29udGVudD0idGV4 dC9odG1sOyBjaGFyc2V0PXV0Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIG5h bWU9R0VORVJBVE9SIGNvbnRlbnQ9Ik1TSFRNTCA4LjAwLjYwMDEuMTg3MDIiPjwvSEVBRD4NCjxC T0RZPjwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9wbGFpbiBmb3JtYXQgLS0+DQo8UD48Rk9OVCBz aXplPTI+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPkRlYXIgSmlhbmcsPEJSPjxCUj5XZSBoYXZl IGRvbmUgDQpleHRlbnNpdmUgdGVzdGluZyB3aXRoIENHTiAoRFMtTGl0ZSkgaW1wbGVtZW50YXRp b25zIGZyb20gdmFyaW91cyB2ZW5kb3JzIHRvIA0KYXNzZXNzIHRoZSBiZWhhdmlvdXIgb2YgUDJQ IGFwcGxpY2F0aW9ucyAoZS5nLiwgZW11bGUsIFNreXBlLCBCaXR0b3JlbnQpLiBUaGUgDQp0ZXN0 aW5nIGhhdmUgYmVlbiB1bmRlcnRha2VuIGluIHR3byBjb25maWd1cmF0aW9uIChwb3J0IGZvcndh cmRpbmcgYWN0aXZhdGVkIHZzLiANCm5vIHBvcnQgZm9yd2FyZGluZykuIFdlIGRpZG4ndCBwdWJs aXNoZWQgYW55IHJlcG9ydCBhYm91dCBhbGwgdGhlc2UgdmFsaWRhdGlvbiANCnRlc3RpbmcuIDxC Uj48QlI+QlRXLCB3ZSBoYXZlIHB1Ymxpc2hlZCBhIGRldGFpbGVkIHJlcG9ydCBhYm91dCB0aGUg YmVoYXZpb3VyIG9mIA0KQml0dG9yZW50IGluIGEgc2hhcmVkIGVudmlyb25uZW1udCAodGhlIGNv bmNsdXNpb24gb2YgdGhhdCBJLUQgYXBwbGllcyBmb3IgdGhlIA0KQ0dOIGNhc2UgYWxzbykuIFRo ZSBkb2N1bWVudCBpcyBhdmFpbGFibGUgYXQ6PEJSPjxCUj48L0ZPTlQ+PEEgDQpocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3VjYWRhaXItYmVoYXZlLWJpdHRvcnJlbnQt YWRkcmVzcy1zaGFyaW5nLTAwIj48Rk9OVCANCmZhY2U9IkNvdXJpZXIgTmV3Ij5odHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3VjYWRhaXItYmVoYXZlLWJpdHRvcnJlbnQtYWRkcmVz cy1zaGFyaW5nLTAwPC9GT05UPjwvQT48QlI+PEJSPjxGT05UIA0KZmFjZT0iQ291cmllciBOZXci PkNoZWVycyw8QlI+TWVkPEJSPjxCUj4tLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08QlI+RGUg OiANCmJlaGF2ZS1ib3VuY2VzQGlldGYub3JnIFs8L0ZPTlQ+PEEgaHJlZj0ibWFpbHRvOmJlaGF2 ZS1ib3VuY2VzQGlldGYub3JnIj48Rk9OVCANCmZhY2U9IkNvdXJpZXIgTmV3Ij5tYWlsdG86YmVo YXZlLWJvdW5jZXNAaWV0Zi5vcmc8L0ZPTlQ+PC9BPjxGT05UIA0KZmFjZT0iQ291cmllciBOZXci Pl0gRGUgbGEgcGFydCBkZSBKaWFuZyBEb25nPEJSPkVudm95w6kgOiBqZXVkaSA4IHNlcHRlbWJy ZSAyMDExIA0KMTA6Mjk8QlI+w4AgOiBiZWhhdmU8QlI+T2JqZXQgOiBbQkVIQVZFXSBBcmUgdGhl cmUgYW55IGV4cGVyaW1lbnQgZHJhZnRzIHRhbGtpbmcgDQphYm91dCBob3cgQ0dOIGluZmx1ZW5j ZSBhcHBsaWNhdGlvbnMgbGlrZSANCnAycD88QlI+PEJSPkhp77yMPEJSPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBcmUgdGhlcmUgYW55IA0KZXhwZXJpbWVudCBk cmFmdHMgdGFsa2luZyBhYm91dCZuYnNwOyBob3cgQ0dOIGluZmx1ZW5jZSBhcHBsaWNhdGlvbnMg bGlrZSANCnAycD88QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFRoYWsgeW91IGZvciB5b3VyIGtpbmRseSBoZWxwIA0KaWYgc29tZW9uZSBjYW4gZ2l2ZSBtZSBh IGxpbmsuPEJSPjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQpCZXN0IFJlZ2FyZHMhPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBKaWFuZyANCkRvbmc8QlI+PEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPEJSPkJlaGF2ZSBtYWlsaW5nIA0KbGlzdDxCUj5CZWhhdmVAaWV0Zi5v cmc8QlI+PC9GT05UPjxBIA0KaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9iZWhhdmUiPjxGT05UIA0KZmFjZT0iQ291cmllciBOZXciPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYmVoYXZlPC9GT05UPjwvQT48QlI+PC9GT05UPjwvUD48L0JP RFk+PC9IVE1MPg0K --_000_94C682931C08B048B7A8645303FDC9F351674475F2PUEXCB1Bnante_-- From yding@cs.helsinki.fi Thu Sep 8 01:51:45 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2213F21F8B53 for ; Thu, 8 Sep 2011 01:51:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrc9GB6bjdTm for ; Thu, 8 Sep 2011 01:51:44 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630F721F8B46 for ; Thu, 8 Sep 2011 01:51:44 -0700 (PDT) Received: from [192.168.0.184] (host-94-101-2-145.igua.fi [94.101.2.145]) (AUTH: PLAIN yding, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 08 Sep 2011 11:53:34 +0300 id 0009C805.4E68828E.00001BB8 Message-ID: <4E68828F.5010506@cs.helsinki.fi> Date: Thu, 08 Sep 2011 11:53:35 +0300 From: "Yi DING(Aaron)" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Dan Wing References: <000101cc48b3$a9f87500$fde95f00$@com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org, draft-ietf-behave-nat64-learn-analysis@tools.ietf.org Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-nat64-learn-analysis-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2011 08:51:45 -0000 Some comments on "draft-ietf-behave-nat64-learn-analysis-00": * Issue 1-5 could be emphasized as a separate section / subsection under Section 3 * As DNS query for well-known name becomes the recommendation, for clarity as well as highlight, we should move it up as the first solution in Section 4. The document is well-written, concise, and coupled with an extensive survey of existing mechanisms to learn NAT64 prefix. The comparison chart is very valuable for networking research as well. I agree with Cameron that we shall push this document forward. -- Aaron On 06/09/11 23:03, Cameron Byrne wrote: > On Fri, Jul 22, 2011 at 2:09 PM, Dan Wing wrote: >> This starts a 3 week WGLC (extra time to accommodate IETF travel) for >> draft-ietf-behave-nat64-learn-analysis-00. This document analyzes the >> available approaches for a host to learn its NAT64 prefix. Abstract: >> >> Hosts and applications may benefit from the knowledge if an IPv6 >> address is synthesized, which would mean a NAT64 is used to reach the >> IPv4 network or Internet. This document analyses a number of >> proposed solutions for communicating whether the synthesis is taking >> place, used address format, and the IPv6 prefix used by the NAT64 and >> DNS64. The solutions enable both NAT64 avoidance and intentional >> utilization by allowing local IPv6 address synthesis. The document >> concludes by recommending selection of heuristic discovery based >> solution. >> >> Please send comments to behave@ietf.org. WGLC ends in 3 weeks on >> August 12. >> > Sorry for writing late. I believe this is a good document and that we > should move forward with the recommendation of publishing a well known > name for learning the PREF64. This path is consistent with the the > overall NAT64 / DNS64 philosophy of working within the existing > technology to the greatest extent possible. > > Cameron > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From mohamed.boucadair@orange-ftgroup.com Thu Sep 8 02:32:42 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8505321F8B1A for ; Thu, 8 Sep 2011 02:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8u6mUzypR6-x for ; Thu, 8 Sep 2011 02:32:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id C6D9221F8B10 for ; Thu, 8 Sep 2011 02:32:41 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id E04391B8860; Thu, 8 Sep 2011 11:34:30 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id C5883180042; Thu, 8 Sep 2011 11:34:30 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Thu, 8 Sep 2011 11:34:30 +0200 From: To: Dan Wing , "behave@ietf.org" Date: Thu, 8 Sep 2011 11:34:29 +0200 Thread-Topic: [BEHAVE] WGLC: draft-ietf-behave-nat64-learn-analysis-00 Thread-Index: AcxImw6xYcizfz1QRMOj/AxfKwvyXAlbhS0A Message-ID: <94C682931C08B048B7A8645303FDC9F3516744765B@PUEXCB1B.nanterre.francetelecom.fr> References: <000101cc48b3$a9f87500$fde95f00$@com> In-Reply-To: <000101cc48b3$a9f87500$fde95f00$@com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.9.8.85414 Cc: "draft-ietf-behave-nat64-learn-analysis@tools.ietf.org" Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-nat64-learn-analysis-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2011 09:32:42 -0000 Dear all, The document is in a good shape and I support its publication. I have one minor comment, the conclusion says:=20 "None of the discussed solutions support learning of possible new or indicating support for multiple algorithms for address synthesis other than the one described in [RFC6052]." Which is not actually true for one of the solutions discussed in Section 4.= 6. Please refer to http://tools.ietf.org/html/draft-boucadair-dhcpv6-shared= -address-option-01#section-5 for more details. Cheers, Med =20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Dan Wing Envoy=E9 : vendredi 22 juillet 2011 23:10 =C0 : behave@ietf.org Cc : draft-ietf-behave-nat64-learn-analysis@tools.ietf.org Objet : [BEHAVE] WGLC: draft-ietf-behave-nat64-learn-analysis-00 This starts a 3 week WGLC (extra time to accommodate IETF travel) for draft-ietf-behave-nat64-learn-analysis-00. This document analyzes the available approaches for a host to learn its NAT64 prefix. Abstract: Hosts and applications may benefit from the knowledge if an IPv6 address is synthesized, which would mean a NAT64 is used to reach the IPv4 network or Internet. This document analyses a number of proposed solutions for communicating whether the synthesis is taking place, used address format, and the IPv6 prefix used by the NAT64 and DNS64. The solutions enable both NAT64 avoidance and intentional utilization by allowing local IPv6 address synthesis. The document concludes by recommending selection of heuristic discovery based solution. Please send comments to behave@ietf.org. WGLC ends in 3 weeks on=20 August 12. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From sm@resistor.net Thu Sep 8 07:41:46 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF5321F8669 for ; Thu, 8 Sep 2011 07:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hp9qokRT99+k for ; Thu, 8 Sep 2011 07:41:44 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B135321F8498 for ; Thu, 8 Sep 2011 07:41:44 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id p88EhVAO000515 for ; Thu, 8 Sep 2011 07:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1315493015; bh=UVx9rysAzoOWatBaIg8inVW3xwvezu7ps/pXNYr5ChM=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=MXDkT3j1l5d4HlocQCUVnfQSkhOS4chAV0A+uS3WDS/kChFZTKLw1wbynIrupDXKr zzP9bkf5qhD3eRErbtQB4v3dphYM+Y0Qmzr3tHYJ16rJD8nYPPHg/QNg7D4KbSIYrb DWeNsuR7qRUZ6CA+fK5Dm+y/A1/BbRkW7YfZde0M= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1315493015; bh=UVx9rysAzoOWatBaIg8inVW3xwvezu7ps/pXNYr5ChM=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=jHGrs1XWHaUmYK/wTnAJ6Wzz63Wfew4KyVCtRuCxH6FMskkr7M8PNownPuDL/pK77 +LATEUwskgkK6mM0mZ4t9N3FFF5gq8dMRwt306b7EtBMAETI/4sN9pz9bIERHkqiiv GwWCaB5+1XyrutTHI6yj8abdgprFKiNER1tNt4kc= Message-Id: <6.2.5.6.2.20110908070031.0a1a2b68@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 08 Sep 2011 07:22:20 -0700 To: behave@ietf.org From: SM In-Reply-To: <878C4AEF-F4B6-4FF4-BBEA-1A8AFABB990B@muada.com> References: <94C682931C08B048B7A8645303FDC9F3516735E978@PUEXCB1B.nanterre.francetelecom.fr> <878C4AEF-F4B6-4FF4-BBEA-1A8AFABB990B@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [BEHAVE] Request to adopt draft-boucadair-behave-bittorrent-address-sharing as WG document X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2011 14:41:47 -0000 At 06:49 06-09-2011, Iljitsch van Beijnum wrote: >Considering the fact that the found issue (under one of two possible >configuration settings two peers sharing an address can't connect to >a single other peer) is a pretty extreme corner case which doesn't >even preclude eventual successful downloading and the BitTorrent >protocol (unless I missed something) isn't published as an RFC, I >don't think this work is in the right place here so it shouldn't be >adopted as a WG document and it shouldn't be published as an RFC. >Even if the "belongs here" isn't found persuasive both the strange >test setup and the unfortunate formatting make this document too >immature for WG adoption. The BitTorrent protocol has not been published as a RFC. It's odd to have the two ends on the same IPv4 /24 unless the intent is to use "shared transition" IPv4 address space. The document requires some editorial work. The tables in Section 4 are difficult to read. Concluding that the results are valid for all IP shared address solutions in a stretch (Section 6). What do the authors expect by having the document adopted by this working group? Regards, -sm From dwing@cisco.com Thu Sep 8 09:10:25 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448F921F8AAF for ; Thu, 8 Sep 2011 09:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.309 X-Spam-Level: X-Spam-Status: No, score=-103.309 tagged_above=-999 required=5 tests=[AWL=-0.709, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocjbmtN5iP+c for ; Thu, 8 Sep 2011 09:10:24 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 333EC21F8AAA for ; Thu, 8 Sep 2011 09:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=930; q=dns/txt; s=iport; t=1315498336; x=1316707936; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=l+iNY/WQsCAhRxJ2o3br39T0D7zFxLXOJRB6/nLoZRA=; b=S010qVLyrfpgtUFR4OOTTguhMiSeeAOevVH6LMsrobPcNw/4mTBeK4TK yTqh0InGUfBPFwpwHgbuE8RP/dEr4DTqtWZQdrVKzWrXQnWp1XotM4Rl7 LJUFOj4DsufufSHs//5gWjdOEJkBMk7uEMznhIakNP1ms4xTuld35bm9b M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8AAHroaE6rRDoG/2dsb2JhbABDhFWUGoFsjSd4gUYBAQEBAgEBAQEFCgEOAQhEEAcBAwIJDwIEAQECAwsYAgMCGQ4VCgkIAQEEARILF4dTBJlXAYwyAZF7gSmEMIEUBIdsnH0 X-IronPort-AV: E=Sophos;i="4.68,351,1312156800"; d="scan'208";a="962220" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 08 Sep 2011 16:12:14 +0000 Received: from dwingWS (sjc-vpn7-187.cisco.com [10.21.144.187]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p88GCEJq012497; Thu, 8 Sep 2011 16:12:14 GMT From: "Dan Wing" To: "'Jiang Dong'" , "'behave'" References: <20110831135349.14909.10061.idtracker@ietfa.amsl.com> <201109081628463511658@gmail.com> In-Reply-To: <201109081628463511658@gmail.com> Date: Thu, 8 Sep 2011 09:12:14 -0700 Message-ID: <026801cc6e42$127842f0$3768c8d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxuAT+4E5H1vNpqTsiP4ifMuonLegAQIQsw Content-Language: en-us Subject: Re: [BEHAVE] Are there any experiment drafts talking about how CGN influence applications like p2p? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2011 16:10:25 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Jiang Dong > Sent: Thursday, September 08, 2011 1:29 AM > To: behave > Subject: [BEHAVE] Are there any experiment drafts talking about how CGN > influence applications like p2p? > > Hi$B!$(B > Are there any experiment drafts talking about how CGN influence > applications like p2p? What do you mean by "p2p". Yes, I know it means "peer to peer", but lots of things are peer to peer -- Octoshape, SIP, XMPP, Skype, BitTorrent, approximately 49315 different Internet-enabled game applications on various hardware platforms (XBox, PC, others). -d > Thak you for your kindly help if someone can give me a link. > > Best Regards! > Jiang Dong > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From jiangdong345@gmail.com Thu Sep 8 19:35:11 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357A621F8B46 for ; Thu, 8 Sep 2011 19:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utyLqVi54MXJ for ; Thu, 8 Sep 2011 19:35:10 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 900D021F8B33 for ; Thu, 8 Sep 2011 19:35:10 -0700 (PDT) Received: by yxj20 with SMTP id 20so1354025yxj.31 for ; Thu, 08 Sep 2011 19:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:references:subject:message-id:x-mailer:mime-version :content-type:content-transfer-encoding; bh=jShGL04QFMspLSML5Is2hpEeUgaW1+SU8lUcA6kcTCQ=; b=kbVKELkpsYABMa4dzxfpSVEx53Lttp12hVepFAdgygmlfvKczsn7xRM8XwluModEY5 6umOe5T8vaC6Xv7GKilxl2Mb0K+KECADTINjOgkzZlsd6u5JHSYoTrk/wulyM2ikbohI 8zreJDqfZGj9rUlP2RqkhEAq6Sc63J9ohwtzQ= Received: by 10.42.145.194 with SMTP id g2mr98753icv.36.1315535821861; Thu, 08 Sep 2011 19:37:01 -0700 (PDT) Received: from DJ-PC ([166.111.68.231]) by mx.google.com with ESMTPS id n14sm6831140ibi.4.2011.09.08.19.36.59 (version=SSLv3 cipher=OTHER); Thu, 08 Sep 2011 19:37:01 -0700 (PDT) Date: Fri, 9 Sep 2011 10:37:50 +0800 From: Jiang Dong To: "Dan Wing" , "'behave'" References: <20110831135349.14909.10061.idtracker@ietfa.amsl.com>, <201109081628463511658@gmail.com> Message-ID: <201109091037462826505@gmail.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] Are there any experiment drafts talking about how CGN influence applications like p2p? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 02:35:11 -0000 Hi, Dan, You are right. I'd like to find some drafts which describe how LSN influnence applications from the angle of function, performance and so on. The applications could be not only P2P, but also any others that may be influenced. draft-donley-nat444-impacts (Lee informed me, thaks a lot) is an useful one which described a variety of apps that would be influenced by NAT444. It seems not explain why these applications would be troubled... Best Regards! Jiang Dong >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf Of Jiang Dong >> Sent: Thursday, September 08, 2011 1:29 AM >> To: behave >> Subject: [BEHAVE] Are there any experiment drafts talking about how CGN >> influence applications like p2p? >> >> Hi$B!$(B >> Are there any experiment drafts talking about how CGN influence >> applications like p2p? > >What do you mean by "p2p". Yes, I know it means "peer to peer", but >lots of things are peer to peer -- Octoshape, SIP, XMPP, Skype, >BitTorrent, approximately 49315 different Internet-enabled game >applications on various hardware platforms (XBox, PC, others). > >-d > > >> Thak you for your kindly help if someone can give me a link. >> >> Best Regards! >> Jiang Dong >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > From dwing@cisco.com Fri Sep 9 08:01:38 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2D921F8B5C for ; Fri, 9 Sep 2011 08:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.28 X-Spam-Level: X-Spam-Status: No, score=-103.28 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7MHXy9WX13R for ; Fri, 9 Sep 2011 08:01:37 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id AFCF921F8A56 for ; Fri, 9 Sep 2011 08:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2594; q=dns/txt; s=iport; t=1315580613; x=1316790213; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=3DPLWjz+vTSQADOp82pgfq7PG8u8Vz/G/vp9/zlk2Jg=; b=Dr2AAgarHesgu6OtSECrjuvBnKrafiyndyOZUyZt1RwuBtCW0BmcFwLD Gwbczi8d6txyfspocI0O9ea99IYtnFA2mt9CqYuDC4rbj96RWyxULOrvz BaRpa8TOkeVuXz8qud4QgOi+nx3YDpFFghL8DxM5X5bI/a/RgGrB7FbQH E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwBAGYpak6rRDoG/2dsb2JhbABBhFWUIoFshnGGO3iBUgEBAQECAQEBAQUKAQ4BCEQQBwEDAgkPAgQBAQIDCxgCAwIZDhUKCQgBAQQBEgsXh1QEmF8BjDIBkiCBKYQxgRQEh22dBQ X-IronPort-AV: E=Sophos;i="4.68,356,1312156800"; d="scan'208";a="1175311" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 09 Sep 2011 15:03:32 +0000 Received: from dwingWS (sjc-vpn7-187.cisco.com [10.21.144.187]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p89F3V47014489; Fri, 9 Sep 2011 15:03:31 GMT From: "Dan Wing" To: "'Jiang Dong'" , "'behave'" References: <20110831135349.14909.10061.idtracker@ietfa.amsl.com>, <201109081628463511658@gmail.com> <201109091037462826505@gmail.com> In-Reply-To: <201109091037462826505@gmail.com> Date: Fri, 9 Sep 2011 08:03:31 -0700 Message-ID: <070e01cc6f01$a3a32410$eae96c30$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxumV+b8Z9oUXeARKmqDc6p3ByN4wAZ3dQQ Content-Language: en-us Subject: Re: [BEHAVE] Are there any experiment drafts talking about how CGN influence applications like p2p? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 15:01:38 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Jiang Dong > Sent: Thursday, September 08, 2011 7:38 PM > To: Dan Wing; 'behave' > Subject: Re: [BEHAVE] Are there any experiment drafts talking about how > CGN influence applications like p2p? > > Hi, Dan, > You are right. I'd like to find some drafts which describe how > LSN influnence > applications from the angle of function, performance and so on. The > applications > could be not only P2P, but also any others that may be influenced. > > draft-donley-nat444-impacts (Lee informed me, thaks a lot) is an > useful one > which described a variety of apps that would be influenced by NAT444. > It seems > not explain why these applications would be troubled... draft-donley-nat444-impacts combines analysis of bandwidth constraint (running over a cable plant) with in-home NAT with CGN. Scientific studies analyzing the effect of a treatment always have a "control group" -- a group that does not receive the treatment, in order to judge the effect of the treatment. draft-donley-nat444-impacts does not have a control; that is, it did not perform the same exact tests in the absence of the CGN, nor did it compare CGN-without- in-home-NAT (which is the anticipated Dual Stack-Lite deployment). I am hoping for a better analysis. -d > Best Regards! > Jiang Dong > >> -----Original Message----- > >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > >> Behalf Of Jiang Dong > >> Sent: Thursday, September 08, 2011 1:29 AM > >> To: behave > >> Subject: [BEHAVE] Are there any experiment drafts talking about how > CGN > >> influence applications like p2p? > >> > >> Hi$B!$(B > >> Are there any experiment drafts talking about how CGN influence > >> applications like p2p? > > > >What do you mean by "p2p". Yes, I know it means "peer to peer", but > >lots of things are peer to peer -- Octoshape, SIP, XMPP, Skype, > >BitTorrent, approximately 49315 different Internet-enabled game > >applications on various hardware platforms (XBox, PC, others). > > > >-d > > > > > >> Thak you for your kindly help if someone can give me a link. > >> > >> Best Regards! > >> Jiang Dong > >> > >> _______________________________________________ > >> 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 lionel.morand@orange-ftgroup.com Fri Sep 9 00:30:13 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B03A21F8B54 for ; Fri, 9 Sep 2011 00:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.211 X-Spam-Level: X-Spam-Status: No, score=-103.211 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reNAJBy3H1Y6 for ; Fri, 9 Sep 2011 00:30:10 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4E41D21F8AD3 for ; Fri, 9 Sep 2011 00:30:09 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C4B578B8006; Fri, 9 Sep 2011 09:32:55 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id B46148B8005; Fri, 9 Sep 2011 09:32:55 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Sep 2011 09:30:24 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6EC2.567BD934" Date: Fri, 9 Sep 2011 09:30:23 +0200 Message-ID: In-reply-to: <0D212BD466921646B58854FB79092CEC06898727@XMB-AMS-106.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [BEHAVE] My review of draft-ietf-dime-nat-control-09 Thread-index: AcxTA1pwEoFdHujaQPeAdI8rofSx2AWidiSwAU0/2eA= References: <9B57C850BB53634CACEC56EF4853FF653B1CD01D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <0D212BD466921646B58854FB79092CEC06898727@XMB-AMS-106.cisco.com> From: To: , , , X-OriginalArrivalTime: 09 Sep 2011 07:30:24.0800 (UTC) FILETIME=[56ED3A00:01CC6EC2] X-Mailman-Approved-At: Fri, 09 Sep 2011 12:01:47 -0700 Cc: behave@ietf.org, ietfdbh@comcast.net, rdroms.ietf@gmail.com, dromasca@avaya.com Subject: Re: [BEHAVE] My review of draft-ietf-dime-nat-control-09 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 07:30:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC6EC2.567BD934 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dave, =20 Are you OK with the last version of the draft and the answers provided = by Franck? =20 Regards, =20 Lionel=20 =20 De : Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com]=20 Envoy=E9 : vendredi 2 septembre 2011 18:37 =C0 : Dave Thaler; draft-ietf-dime-nat-control@tools.ietf.org; = dime-chairs@tools.ietf.org Cc : David Harrington; behave@ietf.org; Romascanu, Dan (Dan) Objet : RE: [BEHAVE] My review of draft-ietf-dime-nat-control-09 =20 Dave, =20 thanks for your comments and detailed review and sorry for the delay in = getting the draft updated. We just posted a new revision = (draft-ietf-dime-nat-control-11), reflecting your comments. Please see = additional comments inline... =20 From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf = Of Dave Thaler Sent: Friday, August 05, 2011 2:13 AM To: draft-ietf-dime-nat-control@tools.ietf.org; = dime-chairs@tools.ietf.org Cc: David Harrington; behave@ietf.org; Romascanu, Dan (Dan) Subject: [BEHAVE] My review of draft-ietf-dime-nat-control-09 =20 My review of this draft is at http://research.microsoft.com/en-us/um/people/dthaler/draft-ietf-dime-nat= -control-09.pdf or (same content) http://research.microsoft.com/en-us/um/people/dthaler/draft-ietf-dime-nat= -control-09.docx =20 High level questions: 1) The model discussed in the draft appears to assume there's only = one NAT device in the domain. In contrast, the models in the Behave WG = allow for multiple. What happens if there are multiple NAT-devices = (for failover or load balancing or whatever else)? .....FB: We clarified that DNCA applies to n:m scenarios, with n = NAT-Controllers and m NAT-devices. Section 3.3 now discusses this: =20 3.3. Deployment Scenarios For DNCA =20 DNCA can be deployed in different ways. DNCA supports deployments with "n" NAT-controllers and "m" NAT-devices, with n and m equal to or greater than 1. For DNCA, the session representing a particular endpoint is atomic. Any deployment MUST ensure that for every given endpoint only a single NAT-controller and only a single NAT-device are active at any point in time. This is to ensure that NAT-devices controlled by multiple NAT-controllers do not receive conflicting control requests for a particular endpoint, or would be unclear which NAT-controller to send accounting information to. =20 =20 2) Security seems to be a MAY. Why not a SHOULD or a MUST? = Using only a MAY warrants an explanation. ...FB: Agreed. And we refer to security as a SHOULD throughout the = document. =20 3) There's no mention of DoS attack by filling up logs. Is that a = concern? =20 ...FB: It could be a concern, if the logging infrastructure is not = designed with potential DoS attacks in mind. We've updated the security = section to reflect this (see section 12): =20 [..] Failing of any of the two DNCA Diameter peers to provide the required credentials should be subject to logging. The corresponding logging infrastructure of the operator SHOULD be built in a way that it can mitigate potential denial of service attacks resulting from large amounts of logging events. This could include proper dimensioning of the logging infrastructure combined with policing the maximum amount of logging events accepted by the logging system to a threshold which the system is known to be able to handle. =20 =20 Rest is mostly editorial nits. ...FB: Thanks for catching all these nits. Really helpful (and hopefully = we reflected all of them in revision -11) =20 I also reviewed it for consistency with RFC 4008 and for consistency = with draft-ietf-behave-lsn-requirements, and I didn't spot any = inconsistencies other that in question 1 above. =20 Regards, Frank =20 =20 -Dave ------_=_NextPart_001_01CC6EC2.567BD934 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Dave,

 

Are you OK = with the last version of the draft and the answers provided by = Franck?

 

Regards,

 

Lionel =

 

De : Frank = Brockners (fbrockne) [mailto:fbrockne@cisco.com] =
Envoy=E9 : vendredi 2 septembre 2011 = 18:37
=C0 : Dave Thaler; = draft-ietf-dime-nat-control@tools.ietf.org; = dime-chairs@tools.ietf.org
Cc : David Harrington; = behave@ietf.org; Romascanu, Dan (Dan)
Objet : RE: = [BEHAVE] My review of = draft-ietf-dime-nat-control-09

 

Dave,

 

thanks for = your comments and detailed review and sorry for the delay in getting the = draft updated. We just posted a new revision = (draft-ietf-dime-nat-control-11), reflecting your comments. Please see = additional comments inline...

 

From:= = behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of = Dave Thaler
Sent: Friday, August 05, 2011 2:13 = AM
To: draft-ietf-dime-nat-control@tools.ietf.org; = dime-chairs@tools.ietf.org
Cc: David Harrington; = behave@ietf.org; Romascanu, Dan (Dan)
Subject: [BEHAVE] My = review of = draft-ietf-dime-nat-control-09

 

My review of this draft is = at

http://research.microsoft.com/en-us/um/people/dt= haler/draft-ietf-dime-nat-control-09.pdf

or (same = content)

http://research.microsoft.com/en-us/um/people/d= thaler/draft-ietf-dime-nat-control-09.docx

 

High level = questions:

1)      The model discussed in the draft appears to assume = there’s only one NAT device in the domain.  In contrast, the = models in the Behave WG allow for multiple.   What happens if = there are multiple NAT-devices (for failover or load balancing or = whatever else)?

…..FB: We clarified that DNCA applies to = n:m scenarios, with n NAT-Controllers and m NAT-devices. Section 3.3 now = discusses this:

 

3.3.  Deployment Scenarios For = DNCA

 

   DNCA can be deployed in different = ways.  DNCA supports deployments

   with "n" NAT-controllers and = "m" NAT-devices, with n and m equal to

   or greater than 1.  For DNCA, the = session representing a particular

   endpoint is atomic.  Any = deployment MUST ensure that for every given

   endpoint only a single NAT-controller = and only a single NAT-device

   are active at any point in time.  = This is to ensure that NAT-devices

   controlled by multiple NAT-controllers = do not receive conflicting

   control requests for a particular = endpoint, or would be unclear which

   NAT-controller to send accounting = information to.

 

 

2)      Security seems to be a MAY.   Why not a SHOULD or = a MUST?   Using only a MAY warrants an = explanation.

…FB: Agreed. And we refer to security as a = SHOULD throughout the document.

 

3)      There’s no mention of DoS attack by filling up = logs.   Is that a concern?

 

...FB: It could be a concern, if the logging infrastructure is not = designed with potential DoS attacks in mind. We've updated the =  security section to reflect this (see section = 12):

 

   [..] = Failing

   of any of the two DNCA Diameter = peers to provide the required

   credentials should be subject to = logging.  The corresponding logging

   infrastructure of the operator = SHOULD be built in a way that it can

   mitigate potential denial of = service attacks resulting from large

   amounts of logging events.  = This could include proper dimensioning of

   the logging infrastructure combined = with policing the maximum amount

   of logging events accepted by the = logging system to a threshold which

   the system is known to be able to = handle.

 

 

Rest is mostly editorial = nits.

…FB: Thanks for catching all these nits. = Really helpful (and hopefully we reflected all of them in revision = -11)

 

I also reviewed it for consistency with RFC 4008 and for = consistency with draft-ietf-behave-lsn-requirements, and I didn’t = spot any inconsistencies other that in question 1 = above.

 

Regards, = Frank

 

 

-Dave

------_=_NextPart_001_01CC6EC2.567BD934-- From j.schoenwaelder@jacobs-university.de Fri Sep 9 07:34:37 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809F721F8B53; Fri, 9 Sep 2011 07:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.103 X-Spam-Level: X-Spam-Status: No, score=-103.103 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9z60To-zMcEk; Fri, 9 Sep 2011 07:34:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6899F21F8B4B; Fri, 9 Sep 2011 07:34:36 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CA78E20C75; Fri, 9 Sep 2011 16:36:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eqP2pEpqagZZ; Fri, 9 Sep 2011 16:36:29 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A9D6620C6E; Fri, 9 Sep 2011 16:36:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D8D7F1A59540; Fri, 9 Sep 2011 16:36:17 +0200 (CEST) Date: Fri, 9 Sep 2011 16:36:17 +0200 From: Juergen Schoenwaelder To: Simon Perreault Message-ID: <20110909143617.GE34772@elstar.local> Mail-Followup-To: Simon Perreault , opsawg@ietf.org, behave@ietf.org References: <4E6532CC.1090607@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E6532CC.1090607@viagenie.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Fri, 09 Sep 2011 12:01:47 -0700 Cc: opsawg@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] [OPSAWG] NAT-MIB bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 14:34:37 -0000 On Mon, Sep 05, 2011 at 04:36:28PM -0400, Simon Perreault wrote: > This was just posted: > http://tools.ietf.org/html/draft-perreault-opsawg-natmib-bis-00 A few quick comments: Is it useful that NatAddrMapId and NatSharedAddrMapId use distinct number spaces? This means the number always needs to be qualified. natInterfaceSharedAddrMapIndex OBJECT-TYPE SYNTAX NatSharedAddrMapId MAX-ACCESS not-accessible STATUS current DESCRIPTION "Link to a NatSharedAddrMapEntry. If NULL, it is expected that there exist at least one NatAddrMapEntry pointing to this interface entry." ::= { natInterfaceEntry 8 } What does NULL mean here?? natSharedAddrMapIndex OBJECT-TYPE SYNTAX NatSharedAddrMapId MAX-ACCESS not-accessible STATUS current DESCRIPTION "Along with ifIndex, this object uniquely identifies an entry in the natAddrMapTable. Address map entries are applied in the order specified by natAddrMapIndex." ::= { natSharedAddrMapEntry 1 } I thought ifIndex is not indexing this... natSharedAddrMapName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "Name identifying all map entries in the table associated with the same interface. All map entries with the same ifIndex MUST have the same map name." ::= { natSharedAddrMapEntry 2 } Again, ifIndex? natSharedAddrMapInTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of inbound packets pertaining to this address map entry that were translated. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natSharedAddrMapEntry 16 } Since this is not per interface, ifCounterDiscontinuityTime is not a suitable discontinuity indicator anymore. natSharedAddrMapOutTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of outbound packets pertaining to this address map entry that were translated. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natSharedAddrMapEntry 17 } See above... natSharedAddrMapDiscards OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets pertaining to this address map entry that were dropped due to lack of addresses in the address pool identified by this address map. The value of this object must always be zero in case of static address map. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natSharedAddrMapEntry 18 } See above... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dwing@cisco.com Fri Sep 9 17:04:19 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE02721F8678 for ; Fri, 9 Sep 2011 17:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.267 X-Spam-Level: X-Spam-Status: No, score=-103.267 tagged_above=-999 required=5 tests=[AWL=-0.668, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dfDIrWPJnSp for ; Fri, 9 Sep 2011 17:04:18 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id C0E2021F84B1 for ; Fri, 9 Sep 2011 17:04:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5649; q=dns/txt; s=iport; t=1315613175; x=1316822775; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=RtvRTrG58/G7FOjATSaXTU1o5FcUD9BLwTXgMQbjlNc=; b=am8H1JfRIWapwkCJzvvAdYoOX/hBQBPIp9hj1an0nYC6ilvbbkpOTOSH cPP2URwLYGoPbyQ7mxG+cPNDvGD6huTsN+sFw4vLqGsveRobqbOfkgpAD cvIuMmicfcti65GE0qyBlzkQvF1e/P6z5QS8yANUE2vMauH4daAeWvcZh A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsBAEypak6rRDoI/2dsb2JhbABChFWUK4FshnGGO3iBUgEBAQECAQEBAQUKAQ4BCEQEDAcBAwIJDwIEAQECAwsYAgMCGQ4VCgkIAQEEARILCQ6HVASZLwGMMgGSFIEphDGBFASHbZ0F X-IronPort-AV: E=Sophos;i="4.68,358,1312156800"; d="scan'208";a="1268043" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 10 Sep 2011 00:06:15 +0000 Received: from dwingWS (sjc-vpn7-187.cisco.com [10.21.144.187]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8A06Ej5003387; Sat, 10 Sep 2011 00:06:14 GMT From: "Dan Wing" To: "'Howard, Lee'" , "'Jiang Dong'" , "'behave'" References: <20110831135349.14909.10061.idtracker@ietfa.amsl.com>, <201109081628463511658@gmail.com> <201109091037462826505@gmail.com> <070e01cc6f01$a3a32410$eae96c30$@com> In-Reply-To: Date: Fri, 9 Sep 2011 17:06:15 -0700 Message-ID: <09ce01cc6f4d$75336850$5f9a38f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxumV+b8Z9oUXeARKmqDc6p3ByN4wAZ3dQQAAFKt/AAEa+TIA== Content-Language: en-us Subject: Re: [BEHAVE] Are there any experiment drafts talking about how CGN influence applications like p2p? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2011 00:04:19 -0000 > -----Original Message----- > From: Howard, Lee [mailto:lee.howard@twcable.com] > Sent: Friday, September 09, 2011 4:46 PM > To: Dan Wing; 'Jiang Dong'; 'behave' > Subject: RE: [BEHAVE] Are there any experiment drafts talking about how > CGN influence applications like p2p? > > > > > > > Hi, Dan, > > > You are right. I'd like to find some drafts which describe how > > > LSN influnence > > > applications from the angle of function, performance and so on. The > > > applications > > > could be not only P2P, but also any others that may be influenced. > > > > > > draft-donley-nat444-impacts (Lee informed me, thaks a lot) is > an > > > useful one > > > which described a variety of apps that would be influenced by > NAT444. > > > It seems > > > not explain why these applications would be troubled... > > That's true; in some cases it wasn't possible to tell why a given > application > was "troubled," and in other cases the authors simply did not have > resources to investigate. Many of them I think are well understood, > though maybe not clearly described in the document. For instance, p2p > seeding is pretty clear; a seed behind a CGN contacts a tracker, which > lists the inside address, which is an unreachable address from outside > the CGN. This occurs today with home NATs, too, if there isn't port forwarding on the NAT (e.g., UPnP IGD disabled on the NAT and manual port forwarding isn't configured). Fortunately, BitTorrent seeds can be asked to make outgoing connections. So, all is not lost. Things are _better_ when incoming connections work, for sure. But of all the protocols on the Internet, I expect bittorrent applications and bittorrent users will be very able to accommodate most anything thrown in their way. Same with Skype. > > draft-donley-nat444-impacts combines analysis of bandwidth constraint > > (running over a cable plant) with in-home NAT with CGN. Scientific > > studies analyzing the effect of a treatment always have a "control > > group" -- a group that does not receive the treatment, in order > > to judge the effect of the treatment. draft-donley-nat444-impacts > > does not have a control; that is, it did not perform the same exact > > tests in the absence of the CGN, nor did it compare CGN-without- > > in-home-NAT (which is the anticipated Dual Stack-Lite deployment). > > Not entirely true; at least for the tests I ran, we first ran each test > without a CGN, and then changed the routing to use the CGN. Unfortunately that is not reflected in the text of draft-donley-nat444-impacts. > Testing DS-Lite would be a different report. > > I concede the document has significant limitations, and agree that more > thorough description of why things failed would have been useful to > the community. I can't speak for all authors, but for myself, I simply > did not have the resources to continue work, so the draft expired. > For the issues I saw, I decided native dual-stack deployment would be > easier than fixing the CGN issues, so that's where I have spent my > time, money, and energy. You are in the fortunate position to have sufficient IPv4 addresses for your anticipated growth, so that you can defer IPv4 address sharing until a future date. -d > Lee > > > > > I am hoping for a better analysis. > > > > -d > > > > > > > Best Regards! > > > Jiang Dong > > > >> -----Original Message----- > > > >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] > On > > > >> Behalf Of Jiang Dong > > > >> Sent: Thursday, September 08, 2011 1:29 AM > > > >> To: behave > > > >> Subject: [BEHAVE] Are there any experiment drafts talking about > how > > > CGN > > > >> influence applications like p2p? > > > >> > > > >> Hi$B!$(B > > > >> Are there any experiment drafts talking about how CGN > influence > > > >> applications like p2p? > > > > > > > >What do you mean by "p2p". Yes, I know it means "peer to peer", > but > > > >lots of things are peer to peer -- Octoshape, SIP, XMPP, Skype, > > > >BitTorrent, approximately 49315 different Internet-enabled game > > > >applications on various hardware platforms (XBox, PC, others). > > > > > > > >-d > > > > > > > > > > > >> Thak you for your kindly help if someone can give me a link. > > > >> > > > >> Best Regards! > > > >> Jiang Dong > > > >> > > > >> _______________________________________________ > > > >> 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 > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject > to copyright belonging to Time Warner Cable. This E-mail is intended > solely for the use of the individual or entity to which it is > addressed. If you are not the intended recipient of this E-mail, you > are hereby notified that any dissemination, distribution, copying, or > action taken in relation to the contents of and attachments to this E- > mail is strictly prohibited and may be unlawful. If you have received > this E-mail in error, please notify the sender immediately and > permanently delete the original and any copy of this E-mail and any > printout. From lee.howard@twcable.com Fri Sep 9 16:44:24 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A906721F872A for ; Fri, 9 Sep 2011 16:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.203 X-Spam-Level: X-Spam-Status: No, score=-0.203 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKh8bAWEXJXo for ; Fri, 9 Sep 2011 16:44:24 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id CC07821F8715 for ; Fri, 9 Sep 2011 16:44:23 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,504,1309752000"; d="scan'208";a="257063795" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 09 Sep 2011 19:44:58 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Fri, 9 Sep 2011 19:46:18 -0400 From: "Howard, Lee" To: Dan Wing , 'Jiang Dong' , 'behave' Date: Fri, 9 Sep 2011 19:46:17 -0400 Thread-Topic: [BEHAVE] Are there any experiment drafts talking about how CGN influence applications like p2p? Thread-Index: AcxumV+b8Z9oUXeARKmqDc6p3ByN4wAZ3dQQAAFKt/A= Message-ID: References: <20110831135349.14909.10061.idtracker@ietfa.amsl.com>, <201109081628463511658@gmail.com> <201109091037462826505@gmail.com> <070e01cc6f01$a3a32410$eae96c30$@com> In-Reply-To: <070e01cc6f01$a3a32410$eae96c30$@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="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 12 Sep 2011 11:01:33 -0700 Subject: Re: [BEHAVE] Are there any experiment drafts talking about how CGN influence applications like p2p? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 23:44:24 -0000 > > > > Hi, Dan, > > You are right. I'd like to find some drafts which describe how > > LSN influnence > > applications from the angle of function, performance and so on. The > > applications > > could be not only P2P, but also any others that may be influenced. > > > > draft-donley-nat444-impacts (Lee informed me, thaks a lot) is an > > useful one > > which described a variety of apps that would be influenced by NAT444. > > It seems > > not explain why these applications would be troubled... That's true; in some cases it wasn't possible to tell why a given applicati= on was "troubled," and in other cases the authors simply did not have resources to investigate. Many of them I think are well understood, though maybe not clearly described in the document. For instance, p2p seeding is pretty clear; a seed behind a CGN contacts a tracker, which lists the inside address, which is an unreachable address from outside the CGN. > draft-donley-nat444-impacts combines analysis of bandwidth constraint > (running over a cable plant) with in-home NAT with CGN. Scientific > studies analyzing the effect of a treatment always have a "control > group" -- a group that does not receive the treatment, in order > to judge the effect of the treatment. draft-donley-nat444-impacts > does not have a control; that is, it did not perform the same exact > tests in the absence of the CGN, nor did it compare CGN-without- > in-home-NAT (which is the anticipated Dual Stack-Lite deployment). Not entirely true; at least for the tests I ran, we first ran each test without a CGN, and then changed the routing to use the CGN. Testing DS-Lite would be a different report. I concede the document has significant limitations, and agree that more thorough description of why things failed would have been useful to the community. I can't speak for all authors, but for myself, I simply did not have the resources to continue work, so the draft expired. For the issues I saw, I decided native dual-stack deployment would be easier than fixing the CGN issues, so that's where I have spent my time, money, and energy. Lee > I am hoping for a better analysis. > > -d > > > > Best Regards! > > Jiang Dong > > >> -----Original Message----- > > >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > >> Behalf Of Jiang Dong > > >> Sent: Thursday, September 08, 2011 1:29 AM > > >> To: behave > > >> Subject: [BEHAVE] Are there any experiment drafts talking about how > > CGN > > >> influence applications like p2p? > > >> > > >> Hi=1B$B!$=1B(B > > >> Are there any experiment drafts talking about how CGN influence > > >> applications like p2p? > > > > > >What do you mean by "p2p". Yes, I know it means "peer to peer", but > > >lots of things are peer to peer -- Octoshape, SIP, XMPP, Skype, > > >BitTorrent, approximately 49315 different Internet-enabled game > > >applications on various hardware platforms (XBox, PC, others). > > > > > >-d > > > > > > > > >> Thak you for your kindly help if someone can give me a link. > > >> > > >> Best Regards! > > >> Jiang Dong > > >> > > >> _______________________________________________ > > >> 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 This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From satoru.matsushima@gmail.com Mon Sep 12 20:49:00 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAB321F8AF4; Mon, 12 Sep 2011 20:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkbxMjsOB5Kr; Mon, 12 Sep 2011 20:49:00 -0700 (PDT) Received: from mail-gx0-f170.google.com (mail-gx0-f170.google.com [209.85.161.170]) by ietfa.amsl.com (Postfix) with ESMTP id BC9B721F8AF5; Mon, 12 Sep 2011 20:48:59 -0700 (PDT) Received: by gxk27 with SMTP id 27so183626gxk.15 for ; Mon, 12 Sep 2011 20:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=jqzMIC4W5Ao2ZpDBGiB8KLv968HzJbF1XqXAgfLznp8=; b=mF7CGYSuPgJmKX0nYS0PiLQH/qYUH7wvHuWR95c1c6isAa0F99Dh7nzbNi+3Dr5n7k B020UkA3IYtDoCl3ckDdyP8iGd7U6fd+OFXxfnx2CTP3NddO3xDXSla+no218ZlV4iEt IShbbAdp8D0jATFGKv89LvvmXmOSGMNw92Eak= Received: by 10.42.140.138 with SMTP id k10mr2101578icu.396.1315885863481; Mon, 12 Sep 2011 20:51:03 -0700 (PDT) Received: from [10.201.82.34] ([202.45.12.174]) by mx.google.com with ESMTPS id v16sm652837ibe.0.2011.09.12.20.51.01 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Sep 2011 20:51:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: <20110831135349.14909.10061.idtracker@ietfa.amsl.com> Date: Tue, 13 Sep 2011 12:50:59 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110831135349.14909.10061.idtracker@ietfa.amsl.com> To: ietf@ietf.org X-Mailer: Apple Mail (2.1244.3) Cc: behave@ietf.org, Satoru Matsushima Subject: Re: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2011 03:49:00 -0000 The introduction in the draft says: > IETF recommends using dual-stack or tunneling based solutions for > IPv6 transition and specifically recommends against deployments > utilizing double protocol translation. Use of BIH together with a > NAT64 is NOT RECOMMENDED [RFC6180]. >=20 This statement makes a strong obstacle when we develop stateless = solution with translation in softwires wg. I think that it is still remained a room to make decision whether = removing the statement or remaining it.=20 The discussion which we'll have in the softwires interim meeting would = be helpful to decide it. Best regards, --satoru On 2011/08/31, at 22:53, The IESG wrote: >=20 > The IESG has received a request from the Behavior Engineering for > Hindrance Avoidance WG (behave) to consider the following document: > - 'Dual Stack Hosts Using "Bump-in-the-Host" (BIH)' > as a Proposed Standard >=20 > 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 2011-09-14. 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. >=20 > Abstract >=20 >=20 > Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol > translation mechanism that allows a class of IPv4-only applications > that work through NATs to communicate with IPv6-only peers. The = host > on which applications are running may be connected to IPv6-only or > dual-stack access networks. BIH hides IPv6 and makes the IPv4-only > applications think they are talking with IPv4 peers by local > synthesis of IPv4 addresses. This draft obsoletes RFC 2767 and RFC > 3338. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From cb.list6@gmail.com Mon Sep 12 20:54:16 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D86D21F8BA9; Mon, 12 Sep 2011 20:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.773 X-Spam-Level: X-Spam-Status: No, score=-3.773 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qko+yM2txtTM; Mon, 12 Sep 2011 20:54:15 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 901D321F8B6C; Mon, 12 Sep 2011 20:54:13 -0700 (PDT) Received: by pzk33 with SMTP id 33so737457pzk.18 for ; Mon, 12 Sep 2011 20:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4tVEF2ruIi11G4DYYgYmv8ILAp55ZtyMl5qy1kfHa0M=; b=AXunZgw0sUtevuIoJZHn9/k7QNRc9AGMmdLBQotpssC6uii38/Ra3uEgHwEKUy2NA9 K4tHGHXlS9cednbaMKC7cjLOwNzJabOV5Uu2Wg1hSVRdcb15RxOuXXKktJpzh2yy47mb QLQ5aYfIURyV28EBRcsTte2zeEH/wlKz4wC/4= MIME-Version: 1.0 Received: by 10.68.30.201 with SMTP id u9mr699060pbh.361.1315886177530; Mon, 12 Sep 2011 20:56:17 -0700 (PDT) Received: by 10.143.41.1 with HTTP; Mon, 12 Sep 2011 20:56:17 -0700 (PDT) Received: by 10.143.41.1 with HTTP; Mon, 12 Sep 2011 20:56:17 -0700 (PDT) In-Reply-To: References: <20110831135349.14909.10061.idtracker@ietfa.amsl.com> Date: Mon, 12 Sep 2011 20:56:17 -0700 Message-ID: From: Cameron Byrne To: Satoru Matsushima Content-Type: multipart/alternative; boundary=bcaec520eadd2d33b804accaa049 Cc: behave@ietf.org, ietf@ietf.org Subject: Re: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2011 03:54:16 -0000 --bcaec520eadd2d33b804accaa049 Content-Type: text/plain; charset=ISO-8859-1 On Sep 12, 2011 8:51 PM, "Satoru Matsushima" wrote: > > The introduction in the draft says: > > > > IETF recommends using dual-stack or tunneling based solutions for > > IPv6 transition and specifically recommends against deployments > > utilizing double protocol translation. Use of BIH together with a > > NAT64 is NOT RECOMMENDED [RFC6180]. > > > > > This statement makes a strong obstacle when we develop stateless solution with translation in softwires wg. > I think that it is still remained a room to make decision whether removing the statement or remaining it. > The discussion which we'll have in the softwires interim meeting would be helpful to decide it. > +1 Nat464 has been shown to overcome real world issues, it solves a real problem. Additionally the bih mapper should not have to require DNS so that ipv4 literals can be overcome Cb > Best regards, > --satoru > > > > On 2011/08/31, at 22:53, The IESG wrote: > > > > > The IESG has received a request from the Behavior Engineering for > > Hindrance Avoidance WG (behave) to consider the following document: > > - 'Dual Stack Hosts Using "Bump-in-the-Host" (BIH)' > > 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 2011-09-14. 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. > > > > Abstract > > > > > > Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol > > translation mechanism that allows a class of IPv4-only applications > > that work through NATs to communicate with IPv6-only peers. The host > > on which applications are running may be connected to IPv6-only or > > dual-stack access networks. BIH hides IPv6 and makes the IPv4-only > > applications think they are talking with IPv4 peers by local > > synthesis of IPv4 addresses. This draft obsoletes RFC 2767 and RFC > > 3338. > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf --bcaec520eadd2d33b804accaa049 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sep 12, 2011 8:51 PM, "Satoru Matsushima" <satoru.matsushima@gmail.com> wrote: >
> The introduction in the draft says:
>
>
> > =A0 IETF recommends using dual-stack or tunneling based solutions= for
> > =A0 =A0IPv6 transition and specifically recommends against deploy= ments
> > =A0 =A0utilizing double protocol translation. =A0Use of BIH toget= her with a
> > =A0 =A0NAT64 is NOT RECOMMENDED [RFC6180].
> >
>
>
> This statement makes a strong obstacle when we develop stateless solut= ion with translation in softwires wg.
> I think that it is still remained a room to make decision whether remo= ving the statement or remaining it.
> The discussion which we'll have in the softwires interim meeting w= ould be helpful to decide it.
>

+1

Nat464 has been shown to overcome real world issues, it solves a real pr= oblem.

Additionally the bih mapper should not have to require DNS so that ipv4 = literals can be overcome

Cb

> Best regards,
> --satoru
>
>
>
> On 2011/08/31, at 22:53, The IESG wrote:
>
> >
> > The IESG has received a request from the Behavior Engineering for=
> > Hindrance Avoidance WG (behave) to consider the following documen= t:
> > - 'Dual Stack Hosts Using "Bump-in-the-Host" (BIH)&= #39;
> > =A0<draft-ietf-behave-v4v6-bih-06.txt> as a Proposed Standa= rd
> >
> > The IESG plans to make a decision in the next few weeks, and soli= cits
> > final comments on this action. Please send substantive comments t= o the
> > ietf@ietf.org mailing lists = by 2011-09-14. Exceptionally, comments may be
> > sent to iesg@ietf.org instea= d. In either case, please retain the
> > beginning of the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> > =A0 Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol<= br> > > =A0 translation mechanism that allows a class of IPv4-only applic= ations
> > =A0 that work through NATs to communicate with IPv6-only peers. = =A0The host
> > =A0 on which applications are running may be connected to IPv6-on= ly or
> > =A0 dual-stack access networks. =A0BIH hides IPv6 and makes the I= Pv4-only
> > =A0 applications think they are talking with IPv4 peers by local<= br> > > =A0 synthesis of IPv4 addresses. =A0This draft obsoletes RFC 2767= and RFC
> > =A0 3338.
> >
> >
> >
> >
> > The file can be obtained via
> > http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/
> >
> > IESG discussion can be tracked via
> > http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://= www.ietf.org/mailman/listinfo/behave
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.iet= f.org/mailman/listinfo/ietf

--bcaec520eadd2d33b804accaa049-- From fernando.gont.netbook.win@gmail.com Wed Sep 14 20:03:21 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2702C21F867F; Wed, 14 Sep 2011 20:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+y14H2SkIB4; Wed, 14 Sep 2011 20:03:20 -0700 (PDT) Received: from mail-gx0-f170.google.com (mail-gx0-f170.google.com [209.85.161.170]) by ietfa.amsl.com (Postfix) with ESMTP id F2AA021F8678; Wed, 14 Sep 2011 20:03:16 -0700 (PDT) Received: by gxk27 with SMTP id 27so3384061gxk.15 for ; Wed, 14 Sep 2011 20:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=cEN4nYDT36bhOj2YUZcJAQ/9+6rIDL7ENXKrEyN9TCI=; b=JcEFIIuZ1KdLxWjSZMOrTTE3E/XSGm1lvjk6JNT8W+VZ1sCmZ1Kgv1Mg6JdNGiIpQ3 0taz2z3Qjqp8Plt4y/YJltKeOu/OmjtVaRwJykufy6HDuF2iAZLwzIGdqXCplhVrlMVh eZEb+kbBq8UOLVmdq+9qmFxGkfLAZ1LOHRIpU= Received: by 10.151.4.16 with SMTP id g16mr666333ybi.170.1316055927451; Wed, 14 Sep 2011 20:05:27 -0700 (PDT) Received: from [192.168.0.114] ([190.48.249.134]) by mx.google.com with ESMTPS id v6sm11934285anj.7.2011.09.14.20.05.22 (version=SSLv3 cipher=OTHER); Wed, 14 Sep 2011 20:05:26 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E716B6E.2050409@gont.com.ar> Date: Thu, 15 Sep 2011 00:05:18 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: draft-ietf-behave-v4v6-bih@tools.ietf.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Behave WG , "'ietf@ietf.org'" , tsv-ads@ietf.org, TSV Dir Subject: [BEHAVE] tsv-dir review of draft-ietf-behave-v4v6-bih-06 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 03:03:21 -0000 Hello, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. SUMMARY ------- This draft is on the right track but has open issues, described in the review. TECHNICAL --------- * The document mentions two possible implementation alternatives, and recommends one of them. However, lacks a discussion of the pros/cons of each alternative, and the applicability of each of them. * Section 2.2, page 8: > To avoid unnecessary fragmentation, the host's IPv4 module should be > configured with a small enough MTU (IPv6 link MTU - 20 bytes). Is the "IPv6 link MTU" the MTU of the link the host is attached to, or are you referring to the "Minimum IPv6 MTU" of 1280 bytes? * Section 2.3, page 8: > In either implementation option, if there is a real IPv4 address > available, the ENR SHOULD NOT synthesize IPv4 addresses. By default > an ENR implementation MUST NOT synthesize IPv4 addresses when real > IPv4 addresses exist. What are the reasons for which one would sinthesize IPv4 addresses when real IPv4 addresses exist? -- If there are not any, then make this a MUST (rather than a SHOULD). * Section 2.3.2, page 9: > The ENR may support DNSSEC. Should you s/may/MAY/? * Section 2.4, page 10: > (2) When the extension name resolver gets both IPv4 and IPv6 > addresses, but the IPv4 addresses contain only excluded IPv4 > addresses (e.g., 127.0.0.1). The behavior will follow case (1). Does this mean that BIH will be employed if I do "ping6 localhost"? * Section 2.4, pages 10-11: > (3) When the function mapper gets a socket API function call > triggered by a received IPv6 packet and there is no existing mapping > entry for the IPv6 source address (for example, the client sent a > UDP request to an anycast address but a response was received from a > unicast address). While I understand the scenario you're describing, it seems the description is incorrect. In the scenario you describe, it is the *user* (and not the packet) that triggers the socket API function call (e.g., a "read()) -- maybe you should be saying "when the function mapper is triggered by a received IPv6 packet..." instead?. * Page 14, Figure 6: > |<=======|<=========================| An IPv4 Socket function call. This is incorrect. You should probably say something along the lines of "Return from the IPv4 function call" -- unless you're assuming asynchronous I/O, which I'd bet you're not. * Section 4.3, page 16: > 4.3. ICMP Message Handling > > When an application needs ICMP messages values (e.g., Type, Code, > etc.) sent from the network layer, ICMPv4 message values MAY be > translated into ICMPv6 message values based on SIIT [RFC6145], and > vice versa. What do you exactly mean by "needs ICMP message values"? Do you mean "if an application needs to receive ICMP error messages.."? -- If so, shouldn't this be a "SHOULD" rather than a "MAY"? * Section 7.3, page 22: > In order to allow the BIH to defend against such attacks, the BIH > implementation MAY choose not to extend the session entry lifetime > for a specific entry upon the reception of packets for that entry > through the external interface. You should probably note that this would kill session entries for one-way communication instances. * Section 7.4, page 22: > BIH operates in combination with the DNS, and is therefore subject > to whatever security considerations are appropriate to the DNS mode > in which the BIH is operating (i.e., authoritative, recursive, or > stub- resolver mode). I don't follow why BIH could be operating in authoritative mode. Could you clarify this? * Appendix A, page 27: > Appendix A. API list intercepted by BIH > > The following informational list includes API functions that would > be appropriate to intercept by BIH module when implemented at socket > layer. Since API function call interceptions are key for this mechanism to work, I believe the contents of this section should be normative (unless you're thinking of this document as a "framework". Additionally, the list *should* be exhaustive. * Appendix A While the initial contents seem mostly informative, at the end of the Appendix there are some normative requirements. IMHO, they should be moved to the body of the document, rather than being left out in an appendix. EDITORIAL --------- *Abstract: > This draft obsoletes RFC 2767 and RFC 3338. s/draft/document/ * Section 1, page 4: > The supported class of applications includes those that use DNS for > IP address resolution and that do not embed IP address literals in > protocol payloads. s/protocol payloads/application-protocol payloads/ * Section 1, page 4: > >> BIH includes two major implementation options: a protocol >> translator between the IPv4 and the IPv6 stacks of a host, or an >> API translator between the IPv4 socket API module and the TCP/IP >> module. > > s/options/alternatives/ * Section 1.1, page 5: > which similarly provide a dual stack host means to communicate with > other IPv6 hosts using existing IPv4 applications. I'd rephrase to "which similarly provides IPv4-only applications on dual-stack hosts the means to operate over IPv6", or the like. * Section 2, page 7: > The proposed hosts in this document have an API or network-layer > translator to allow existing IPv4 applications to communicate with > IPv6-only peers. s/existing/legacy/? * Section 2, page 7: >> For example, the Extension Name Resolver may reside in the socket >> API while protocol translation takes place at the networking layer > > s/networking/network/ * Page 15, Figure 7: > | | | | | <> Should you remove the "to."? * Section 4.4, page 16: > When address mapping table clean-up is required the BIH may utilize > techniques used by network address translators, such as described in > [RFC2663], [RFC5382], and [RFC5508]. Please insert a comma between "required" and "the BIH". * Page 19: > 5. Considerations due ALG requirements Shouldn't this be "5. Considerations about ALG requirements" or "5. ALG requirements considerations", instead? * Section 7.3, page 22: > If the number of fragments is high enough, the memory of the host > could be exhausted. s/high/large/ ? * Section 7.3, page 22: > BIN implementations MUST implement proper protection against such > attacks, for instance, allocating a limited amount of memory for > fragmented packet storage. You're probably referring to one of the implementation alternatives of BIH. But since you don't use "BIN" for referring to such implementation alternative throughout the document, you shouldn't use it here, either. i.e., please rephrase. Thanks! Best 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 wes@mti-systems.com Wed Sep 14 21:42:38 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9714B21F8573 for ; Wed, 14 Sep 2011 21:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-4fJlrQPNyk for ; Wed, 14 Sep 2011 21:42:37 -0700 (PDT) Received: from omr15.networksolutionsemail.com (omr15.networksolutionsemail.com [205.178.146.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC4421F856B for ; Wed, 14 Sep 2011 21:42:37 -0700 (PDT) Received: from cm-omr6 (mail.networksolutionsemail.com [205.178.146.50]) by omr15.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p8F4ikY1012264 for ; Thu, 15 Sep 2011 00:44:46 -0400 Authentication-Results: cm-omr6 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [174.130.116.227] ([174.130.116.227:30079] helo=[192.168.1.104]) by cm-omr6 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 61/45-06799-EB2817E4; Thu, 15 Sep 2011 00:44:46 -0400 Message-ID: <4E7182BE.9000002@mti-systems.com> Date: Thu, 15 Sep 2011 00:44:46 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Bruce Lowekamp References: <20110817194223.7A46498C228@rfc-editor.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org, John Selbie , dthaler@microsoft.com, dwing@cisco.com, derek.macdonald@gmail.com, ietfdbh@comcast.net Subject: Re: [BEHAVE] [Technical Errata Reported] RFC5780 (2939) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 04:42:38 -0000 It sounds like we should proceed to verify this errata and follow Bruce's suggestion to delete the offending text. In the notes we could also include a bit of the rationale that's been shared on the list here. If there are no objections, I'll go ahead and do this. On 8/27/2011 5:15 PM, Bruce Lowekamp wrote: > On Tue, Aug 23, 2011 at 2:16 PM, John Selbie wrote: >> Could a STUN server could be selective about using either based on the >> client request type? If the client request is missing the stun magic >> cookie, then it could be assumed to be written to rfc 3489. As such the >> server sends back the legacy CHANGED-ADDRESS attribute. Otherwise send back >> OTHER-ADDRESS if the client request contains the stun magic cookie. Or just >> send both? Would that be permissible? > > Yes, one intention was that if you wanted to, you could distinguish > between the two protocols using the magic cookie. > > >> Can you elaborate on why it was "deliberately renumbered to break >> compatibility with 3489" ? As I read the behavior for handling >> "change-request" and calculating the "other address" as described in both >> 3489 (section 8.1) and 5780 (section 6.1) the text appear to be near >> identical in description. That is, the stun response always contains an >> attribute containing the other IP and other port opposite from which the >> request arrived on? Yes? Or is there some subtle difference I'm missing? > > The desire to break compatibility had more to do with the intended > (and described) uses of 3489 than with this actual aspect of the > protocol. The intention was to ensure that applications written with > 3489's characterization approach hard-coded be updated to reflect how > to use ICE, etc for NAT traversal, even if they applied some of the > same techniques that are now in 5780 for appropriate reasons. > >> Is there an email exchange discussion for STUN, TURN, and NAT traversal? > > STUN and TURN came from behave, so I guess it's still good to discuss them here. > > Bruce > > >> >> jrs >> >> >> On Wed, Aug 17, 2011 at 9:32 PM, Bruce Lowekamp wrote: >>> >>> Wow, this one really surprises me. We made that change in the -02 >>> draft and somehow missed that paragraph the entire time after. >>> >>> Looking back on my slides from the change, I believe the paragraph in 7.4: >>> >>> OTHER-ADDRESS uses the same attribute number as CHANGED-ADDRESS from >>> RFC 3489 [RFC3489] because it is simply a new name with the same >>> semantics as CHANGED-ADDRESS. It has been renamed to more clearly >>> indicate its function. >>> >>> should be deleted in its entirety. It was deliberately renumbered to >>> break compatibility with 3489 clients. >>> >>> Bruce >>> >>> On Wed, Aug 17, 2011 at 3:42 PM, RFC Errata System >>> wrote: >>>> >>>> The following errata report has been submitted for RFC5780, >>>> "NAT Behavior Discovery Using Session Traversal Utilities for NAT >>>> (STUN)". >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata_search.php?rfc=5780&eid=2939 >>>> >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: John Selbie >>>> >>>> Section: 9.1 >>>> >>>> Original Text >>>> ------------- >>>> Section 9.1 >>>> ... >>>> 0x802c: OTHER-ADDRESS >>>> >>>> >>>> Corrected Text >>>> -------------- >>>> >>>> >>>> Notes >>>> ----- >>>> Section 7.4 of RFC 5780 states: "OTHER-ADDRESS uses the same attribute >>>> number as CHANGED-ADDRESS from RFC 3489". (Defined as 0x0005 in rfc 3489). >>>> >>>> But section 9.1 of RFC 5780 defines the value of OTHER-ADDRESS as being >>>> 0x802c. >>>> >>>> Suggestion: Either update section 7.4 to not reference RFC 3489 or >>>> update the STUN attribute registry such that OTHER-ADDRESS remains at >>>> 0x0005. >>>> >>>> Instructions: >>>> ------------- >>>> This errata is currently posted as "Reported". If necessary, please >>>> use "Reply All" to discuss whether it should be verified or >>>> rejected. When a decision is reached, the verifying party (IESG) >>>> can log in to change the status and edit the report, if necessary. >>>> >>>> -------------------------------------- >>>> RFC5780 (draft-ietf-behave-nat-behavior-discovery-08) >>>> -------------------------------------- >>>> Title : NAT Behavior Discovery Using Session Traversal >>>> Utilities for NAT (STUN) >>>> Publication Date : May 2010 >>>> Author(s) : D. MacDonald, B. Lowekamp >>>> Category : EXPERIMENTAL >>>> Source : Behavior Engineering for Hindrance Avoidance >>>> Area : Transport >>>> Stream : IETF >>>> Verifying Party : IESG >>>> >> >> > > -- Wes Eddy MTI Systems From linfeng.john.zheng@gmail.com Wed Sep 14 22:44:36 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EF521F856B for ; Wed, 14 Sep 2011 22:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFE3KbrkhDXi for ; Wed, 14 Sep 2011 22:44:36 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 57A8121F85AE for ; Wed, 14 Sep 2011 22:44:36 -0700 (PDT) Received: by iaby26 with SMTP id y26so1006091iab.31 for ; Wed, 14 Sep 2011 22:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=yW04VM4CQ+/w6gI0Hbuh8DpZTEEq8EBpjkzFt4iXLts=; b=s8o3yN1ocoyZPI1kQU3fP0YIQlADqF4/PzVBNNu1XHJGEwaQ9ZdxHyWVcqxO0ObedL 6Q7hVu1R33JM8dn7EtzJHfPAqYeehx+Unsdd26mNNTjvGTEIooBRPvSINu5PX8QxEVkd BUgjehKNVoP1g+VaAjslAFZH0oq8NnV4K3CeE= MIME-Version: 1.0 Received: by 10.231.26.132 with SMTP id e4mr1224489ibc.41.1316065606971; Wed, 14 Sep 2011 22:46:46 -0700 (PDT) Received: by 10.231.183.9 with HTTP; Wed, 14 Sep 2011 22:46:46 -0700 (PDT) Date: Thu, 15 Sep 2011 13:46:46 +0800 Message-ID: From: Linfeng Zheng To: behave@ietf.org Content-Type: multipart/alternative; boundary=0015177413ee01323f04acf467cb Subject: Re: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard, X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 05:44:37 -0000 --0015177413ee01323f04acf467cb Content-Type: text/plain; charset=ISO-8859-1 >On Sep 12, 2011 8:51 PM, "Satoru Matsushima" wrote: >> >> The introduction in the draft says: >> >> >> > IETF recommends using dual-stack or tunneling based solutions for >> > IPv6 transition and specifically recommends against deployments >> > utilizing double protocol translation. Use of BIH together with a >> > NAT64 is NOT RECOMMENDED [RFC6180]. >> > >> >> >> This statement makes a strong obstacle when we develop stateless solution with >translation in softwires wg. >> I think that it is still remained a room to make decision whether removing the >statement or remaining it. >> The discussion which we'll have in the softwires interim meeting would be helpful to >decide it. >> >+1 >Nat464 has been shown to overcome real world issues, it solves a real problem. >Additionally the bih mapper should not have to require DNS so that ipv4 literals can be >overcome >Cb + my 0.01 L.Z. --0015177413ee01323f04acf467cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

>On Sep 12, 2011 8:51 PM, "Satoru Matsushima" <satoru.mats= ushima at gmail.com> wrote:
>>
>> The introduction= in the draft says:
>>
>>
>> > =A0 IETF recommends using dual-stack = or tunneling based solutions for
>> > =A0 =A0IPv6 transition an= d specifically recommends against deployments
>> > =A0 =A0utili= zing double protocol translation. =A0Use of BIH together with a
>> > =A0 =A0NAT64 is NOT RECOMMENDED [RFC6180].
>> >>>
>>
>> This statement makes a strong obstacle w= hen we develop stateless solution with >translation in softwires wg.
>> I think that it is still remained a room to make decision whether = removing the >statement or remaining it.
>> The discussion whic= h we'll have in the softwires interim meeting would be helpful to >d= ecide it.
>>

>+1

>Nat464 has been shown to overcome real world issues, it solves a rea= l problem.

>Additionally the bih mapper should not have to require DNS so that i= pv4 literals can be >overcome

>Cb

+ my 0.01
=A0
L.Z.
--0015177413ee01323f04acf467cb-- From wwwrun@rfc-editor.org Fri Sep 16 10:43:45 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3A821F8A97 for ; Fri, 16 Sep 2011 10:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9w+U4HgfJMe for ; Fri, 16 Sep 2011 10:43:44 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 940B921F8888 for ; Fri, 16 Sep 2011 10:43:44 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id ECB1C98C22D; Fri, 16 Sep 2011 10:45:59 -0700 (PDT) To: jdrosen@cisco.com, rohan@ekabal.com, philip_matthews@magma.ca, dwing@cisco.com, ietfdbh@comcast.net, wes@mti-systems.com, dthaler@microsoft.com, dwing@cisco.com From: RFC Errata System Message-Id: <20110916174559.ECB1C98C22D@rfc-editor.org> Date: Fri, 16 Sep 2011 10:45:59 -0700 (PDT) Cc: jack@nottheoilrig.com, behave@ietf.org, rfc-editor@rfc-editor.org Subject: [BEHAVE] [Editorial Errata Reported] RFC5389 (2972) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 17:43:45 -0000 The following errata report has been submitted for RFC5389, "Session Traversal Utilities for NAT (STUN)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5389&eid=2972 -------------------------------------- Type: Editorial Reported by: Jack Bates Section: 15.9 Original Text ------------- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute 1 Type | Attribute 2 Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute 3 Type | Attribute 4 Type ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Corrected Text -------------- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute 1 Type | Attribute 2 Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute 3 Type | Attribute 4 Type ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Notes ----- Attribute 1 Type and Attribute 3 Type are 17-bits in original figure, Attribute 2 Type and Attribute 4 Type are 15-bits This is a very cosmetic nit, since the meaning is perfectly clear (a list of 16-bit values) In general however I find the decimal indices make all figures like this harder to read. I find hex indices an improvement: 
       0 1 2 3 4 5 6 7 8 9 A B C D E F 0 1 2 3 4 5 6 7 8 9 A B C D E F
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Attribute 1 Type        |       Attribute 2 Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Attribute 3 Type        |       Attribute 4 Type    ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5389 (draft-ietf-behave-rfc3489bis-18) -------------------------------------- Title : Session Traversal Utilities for NAT (STUN) Publication Date : October 2008 Author(s) : J. Rosenberg, R. Mahy, P. Matthews, D. Wing Category : PROPOSED STANDARD Source : Behavior Engineering for Hindrance Avoidance Area : Transport Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Sun Sep 18 00:22:49 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B8F21F853B for ; Sun, 18 Sep 2011 00:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpFMCGE1C2xB for ; Sun, 18 Sep 2011 00:22:49 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 36C5821F8538 for ; Sun, 18 Sep 2011 00:22:49 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9DBF198C22D; Sun, 18 Sep 2011 00:25:08 -0700 (PDT) To: marcelo@it.uc3m.es, ajs@shinkuro.com, philip_matthews@magma.ca, iljitsch@muada.com, ietfdbh@comcast.net, wes@mti-systems.com, dthaler@microsoft.com, dwing@cisco.com From: RFC Errata System Message-Id: <20110918072508.9DBF198C22D@rfc-editor.org> Date: Sun, 18 Sep 2011 00:25:08 -0700 (PDT) Cc: behave@ietf.org, ipolcak@fit.vutbr.cz, rfc-editor@rfc-editor.org Subject: [BEHAVE] [Technical Errata Reported] RFC6147 (2975) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 07:22:49 -0000 The following errata report has been submitted for RFC6147, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6147&eid=2975 -------------------------------------- Type: Technical Reported by: Libor Polcak Section: 5.1.4 Original Text ------------- An implementation SHOULD include the ::ffff/96 network in that range by default. Corrected Text -------------- An implementation SHOULD include the ::ffff:0:0/96 network in that range by default. Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6147 (draft-ietf-behave-dns64-11) -------------------------------------- Title : DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers Publication Date : April 2011 Author(s) : M. Bagnulo, A. Sullivan, P. Matthews, I. van Beijnum Category : PROPOSED STANDARD Source : Behavior Engineering for Hindrance Avoidance Area : Transport Stream : IETF Verifying Party : IESG From marcelo@it.uc3m.es Sun Sep 18 01:46:59 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9D321F84CF for ; Sun, 18 Sep 2011 01:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrpBsCLWu7I2 for ; Sun, 18 Sep 2011 01:46:58 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id A3AF321F84A2 for ; Sun, 18 Sep 2011 01:46:57 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (154.30.18.95.dynamic.jazztel.es [95.18.30.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id CA28A9C5D66; Sun, 18 Sep 2011 10:49:11 +0200 (CEST) Message-ID: <4E75B086.9070809@it.uc3m.es> Date: Sun, 18 Sep 2011 10:49:10 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: RFC Errata System References: <20110918072508.9DBF198C22D@rfc-editor.org> In-Reply-To: <20110918072508.9DBF198C22D@rfc-editor.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-6.8.0.1017-18392.003 Cc: behave@ietf.org, ajs@shinkuro.com, dthaler@microsoft.com, wes@mti-systems.com, ipolcak@fit.vutbr.cz, dwing@cisco.com, ietfdbh@comcast.net, philip_matthews@magma.ca Subject: Re: [BEHAVE] [Technical Errata Reported] RFC6147 (2975) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 08:46:59 -0000 Hi, Good catch, the errata should be accepted imho. Regards, marcelo El 18/09/11 09:25, RFC Errata System escribió: > The following errata report has been submitted for RFC6147, > "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6147&eid=2975 > > -------------------------------------- > Type: Technical > Reported by: Libor Polcak > > Section: 5.1.4 > > Original Text > ------------- > An implementation SHOULD include the ::ffff/96 network in that range by default. > > Corrected Text > -------------- > An implementation SHOULD include the ::ffff:0:0/96 network in that range by default. > > Notes > ----- > > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6147 (draft-ietf-behave-dns64-11) > -------------------------------------- > Title : DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers > Publication Date : April 2011 > Author(s) : M. Bagnulo, A. Sullivan, P. Matthews, I. van Beijnum > Category : PROPOSED STANDARD > Source : Behavior Engineering for Hindrance Avoidance > Area : Transport > Stream : IETF > Verifying Party : IESG > From fred@cisco.com Sun Sep 18 23:35:02 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F394421F8B9A for ; Sun, 18 Sep 2011 23:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.628 X-Spam-Level: X-Spam-Status: No, score=-102.628 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jO2EflYl-b4U for ; Sun, 18 Sep 2011 23:35:01 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 704DD21F8B98 for ; Sun, 18 Sep 2011 23:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=4764; q=dns/txt; s=iport; t=1316414243; x=1317623843; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=6inZo3ZU/3C81Kzasdr8VO0ceCqSbSPyOvCOKVt/AqE=; b=C6O+/EzhDaGhB2ImbxYQwuh3hiSC7lVApRZWvKltit5G8SXdqYHyJ8/n sMjjcYgfXWFO90OfZNqzxIHtkNXBLz2S9QjS7A7ZQtGsQpspwU7fo2n7f SFyy+uyP8Nm25FGfyNva3uBkdBdY/NuDFiaVHwDgbL47EA3pHNj0RJpmr E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIvidk6rRDoI/2dsb2JhbABChFWiZneBUwEBAQMBEgEQVgULCQIaAiYCAlcGNYdVl00BjDqQUYEshDsxYASHb4tahR2MMA X-IronPort-AV: E=Sophos;i="4.68,403,1312156800"; d="scan'208";a="2898433" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 19 Sep 2011 06:37:23 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8J6bMJi005843; Mon, 19 Sep 2011 06:37:23 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Sun, 18 Sep 2011 23:37:23 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Sun, 18 Sep 2011 23:37:23 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4E75AFDA.8080800@fit.vutbr.cz> Date: Sun, 18 Sep 2011 23:37:13 -0700 Message-Id: <4B451A10-73B8-4157-A8F0-87480B935C91@cisco.com> References: <4E75AFDA.8080800@fit.vutbr.cz> To: =?utf-8?Q?Libor_Pol=C4=8D=C3=A1k?= X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org, congxiao@cernet.edu.cn, xing@cernet.edu.cn, mrw@painless-security.com Subject: Re: [BEHAVE] Are NAT translators routers? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 06:35:02 -0000 On Sep 18, 2011, at 1:46 AM, Libor Pol=C4=8D=C3=A1k wrote: > Hello, >=20 > I am getting familiar with recent RFCs concerning NAT translators in = IPv6 environment. I believe that I have found little inconsistency in = RFC 6145 and RFC 6296 wording. >=20 > RFC 6145 reads: >=20 > Section 4.1: >=20 > Hop Limit: The hop limit is derived from the TTL value in the IPv4 = header. Since the translator is a router, as part of forwarding the = packet it needs to decrement either the IPv4 TTL (before the = translation) or the IPv6 Hop Limit (after the translation). As part of = decrementing the TTL or Hop Limit, the translator (as any router) MUST = check for zero and send the ICMPv4 "TTL Exceeded" or ICMPv6 "Hop Limit = Exceeded" error. >=20 > Section 5.1: >=20 > Time to Live: Time to Live is derived from Hop Limit value in IPv6 = header. Since the translator is a router, as part of forwarding the = packet it needs to decrement either the IPv6 Hop Limit (before the = translation) or the IPv4 TTL (after the translation). As part of = decrementing the TTL or Hop Limit the translator (as any router) MUST = check for zero and send the ICMPv4 "TTL Exceeded" or ICMPv6 "Hop Limit = Exceeded" error. >=20 > On the other hand RFC 6296 does not explicitly says that the = translator needs to decrement Hop Limit. What is the desired behaviour = of NPTv6 translator? It is in every sense a router, and obeys the expectations of a router. = In addition, it does as the RFC describes. In writing 6296 we didn't see = any point in saying most of the things a router does - it already does = them. The same is true of a NAT64 translator, with the exception that it must = translate the headers entirely if possible, and do something sensible = when it can't. In translating everything entirely, in most cases RFC = 6145 makes a reversible translation - a source address that has an IPv6 = prefix and an embedded IPv4 address becomes that exact IPv4 address in = the source position and in the destination position of the reply. Going = through the translator, the destinatoin of the translated packet is = precisely the value of that original source address. The Hop Limit/TTL = bears special notice because it follows a different rule - the = translator being a router, the HL/TTL is decremented, which is not = reversible. > I also want to propose change in wording of the above mentioned = snippets of RFC 6145 to accommodate RFC 2119 language. >=20 > Instead of: >=20 > Since the translator is a router, as part of forwarding the packet it = needs to decrement either the IPv4 TTL (before the translation) or the = IPv6 Hop Limit (after the translation). >=20 > Say: >=20 > Since the translator is a router, as part of forwarding the packet it = MUST decrement either the IPv4 TTL (before the translation) or the IPv6 = Hop Limit (after the translation). >=20 > And similarly instead of: >=20 > Since the translator is a router, as part of forwarding the packet it = needs to decrement either the IPv6 Hop Limit (before the translation) or = the IPv4 TTL (after the translation). >=20 > Say: >=20 > Since the translator is a router, as part of forwarding the packet it = MUST decrement either the IPv6 Hop Limit (before the translation) or the = IPv4 TTL (after the translation). >=20 > The reason is that reading the current wording I am not sure if "needs = to" actually means MUST or SHOULD. I could fill errata for the change = but I want to discuss the suggestion first. I have no objection to the erratum.=20 I'll note that we came by it honestly. The source text is in RFC 2765: Hop Limit: TTL value copied from IPv4 header. Since the translator is a router, as part of forwarding the packet it needs to decrement either the IPv4 TTL (before the translation) or the IPv6 Hop Limit (after the translation). As part of decrementing the TTL or Hop Limit the translator (as any router) needs to check for zero and send the ICMPv4 or ICMPv6 "ttl exceeded" error. Time to Live: Hop Limit value copied from IPv6 header. Since the translator is a router, as part of forwarding the packet it needs to decrement either the IPv6 Hop Limit (before the translation) or the IPv4 TTL (after the translation). As part of decrementing the TTL or Hop Limit the translator (as any router) needs to check for zero and send the ICMPv4 or ICMPv6 "ttl exceeded" error. From ipolcak@fit.vutbr.cz Sun Sep 18 01:44:12 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4CF21F8509 for ; Sun, 18 Sep 2011 01:44:12 -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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLm7pmNF5Kcy for ; Sun, 18 Sep 2011 01:44:11 -0700 (PDT) Received: from kazi.fit.vutbr.cz (kazi6.fit.vutbr.cz [IPv6:2001:67c:1220:808::93e5:80c]) by ietfa.amsl.com (Postfix) with ESMTP id 83ACA21F84D5 for ; Sun, 18 Sep 2011 01:44:10 -0700 (PDT) Received: from [147.229.13.162] (pcpolcak.fit.vutbr.cz [147.229.13.162]) (authenticated user=ipolcak mech=PLAIN bits=0) by kazi.fit.vutbr.cz (envelope-from ipolcak@fit.vutbr.cz) (8.14.5/8.14.4) with ESMTP id p8I8kIKI086028 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 18 Sep 2011 10:46:19 +0200 (CEST) Message-ID: <4E75AFDA.8080800@fit.vutbr.cz> Date: Sun, 18 Sep 2011 10:46:18 +0200 From: =?UTF-8?B?TGlib3IgUG9sxI3DoWs=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110830 Firefox/6.0 SeaMonkey/2.3.1 MIME-Version: 1.0 To: xing@cernet.edu.cn, congxiao@cernet.edu.cn, fred@cisco.com, mrw@painless-security.com Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.71 on 147.229.8.12 X-Mailman-Approved-At: Mon, 19 Sep 2011 10:38:01 -0700 Cc: behave@ietf.org Subject: [BEHAVE] Are NAT translators routers? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 08:44:12 -0000 Hello, I am getting familiar with recent RFCs concerning NAT translators in IPv6 environment. I believe that I have found little inconsistency in RFC 6145 and RFC 6296 wording. RFC 6145 reads: Section 4.1: Hop Limit: The hop limit is derived from the TTL value in the IPv4 header. Since the translator is a router, as part of forwarding the packet it needs to decrement either the IPv4 TTL (before the translation) or the IPv6 Hop Limit (after the translation). As part of decrementing the TTL or Hop Limit, the translator (as any router) MUST check for zero and send the ICMPv4 "TTL Exceeded" or ICMPv6 "Hop Limit Exceeded" error. Section 5.1: Time to Live: Time to Live is derived from Hop Limit value in IPv6 header. Since the translator is a router, as part of forwarding the packet it needs to decrement either the IPv6 Hop Limit (before the translation) or the IPv4 TTL (after the translation). As part of decrementing the TTL or Hop Limit the translator (as any router) MUST check for zero and send the ICMPv4 "TTL Exceeded" or ICMPv6 "Hop Limit Exceeded" error. On the other hand RFC 6296 does not explicitly says that the translator needs to decrement Hop Limit. What is the desired behaviour of NPTv6 translator? I also want to propose change in wording of the above mentioned snippets of RFC 6145 to accommodate RFC 2119 language. Instead of: Since the translator is a router, as part of forwarding the packet it needs to decrement either the IPv4 TTL (before the translation) or the IPv6 Hop Limit (after the translation). Say: Since the translator is a router, as part of forwarding the packet it MUST decrement either the IPv4 TTL (before the translation) or the IPv6 Hop Limit (after the translation). And similarly instead of: Since the translator is a router, as part of forwarding the packet it needs to decrement either the IPv6 Hop Limit (before the translation) or the IPv4 TTL (after the translation). Say: Since the translator is a router, as part of forwarding the packet it MUST decrement either the IPv6 Hop Limit (before the translation) or the IPv4 TTL (after the translation). The reason is that reading the current wording I am not sure if "needs to" actually means MUST or SHOULD. I could fill errata for the change but I want to discuss the suggestion first. Best wishes, Libor PolÄák From ipolcak@fit.vutbr.cz Mon Sep 19 03:43:22 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E0221F8B91 for ; Mon, 19 Sep 2011 03:43:22 -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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vasqT7Jz73op for ; Mon, 19 Sep 2011 03:43:22 -0700 (PDT) Received: from kazi.fit.vutbr.cz (kazi6.fit.vutbr.cz [IPv6:2001:67c:1220:808::93e5:80c]) by ietfa.amsl.com (Postfix) with ESMTP id DD23721F8B85 for ; Mon, 19 Sep 2011 03:43:21 -0700 (PDT) Received: from [10.0.0.5] (244.186.broadband10.iol.cz [90.177.186.244]) (authenticated user=ipolcak mech=PLAIN bits=0) by kazi.fit.vutbr.cz (envelope-from ipolcak@fit.vutbr.cz) (8.14.5/8.14.4) with ESMTP id p8JAjT60023093 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 19 Sep 2011 12:45:31 +0200 (CEST) Message-ID: <4E771D49.2030605@fit.vutbr.cz> Date: Mon, 19 Sep 2011 12:45:29 +0200 From: =?UTF-8?B?TGlib3IgUG9sxI3DoWs=?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0) Gecko/20110915 Firefox/6.0 SeaMonkey/2.3.1 MIME-Version: 1.0 To: Fred Baker References: <4E75AFDA.8080800@fit.vutbr.cz> <4B451A10-73B8-4157-A8F0-87480B935C91@cisco.com> In-Reply-To: <4B451A10-73B8-4157-A8F0-87480B935C91@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.71 on 147.229.8.12 X-Mailman-Approved-At: Mon, 19 Sep 2011 10:38:15 -0700 Cc: behave@ietf.org, congxiao@cernet.edu.cn, xing@cernet.edu.cn, mrw@painless-security.com Subject: Re: [BEHAVE] Are NAT translators routers? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 10:43:23 -0000 Fred Baker wrote: > > It is in every sense a router, and obeys the expectations of a router. In addition, it does as the RFC describes. In writing 6296 we didn't see any point in saying most of the things a router does - it already does them. > > The same is true of a NAT64 translator, with the exception that it must translate the headers entirely if possible, and do something sensible when it can't. In translating everything entirely, in most cases RFC 6145 makes a reversible translation - a source address that has an IPv6 prefix and an embedded IPv4 address becomes that exact IPv4 address in the source position and in the destination position of the reply. Going through the translator, the destinatoin of the translated packet is precisely the value of that original source address. The Hop Limit/TTL bears special notice because it follows a different rule - the translator being a router, the HL/TTL is decremented, which is not reversible. Hello Fred, yes, I agree with you. You have a point, NPTv6 is a L3 device and as such has to decrement the TTL. I was probably confused because I am preparing a project for students that doesn't have much experience in network programming and tried to see the text from their point of view. Nevertheless, I agree that RFC 6145 has to mention the decrement since it copies the value stored in Hop Limit/TTL field. Thank you for your time, Libor PolÄák From edward.jankiewicz@sri.com Mon Sep 19 11:57:47 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB3F21F8C76 for ; Mon, 19 Sep 2011 11:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.773 X-Spam-Level: X-Spam-Status: No, score=-4.773 tagged_above=-999 required=5 tests=[AWL=1.273, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chPW7nu6zcz2 for ; Mon, 19 Sep 2011 11:57:47 -0700 (PDT) Received: from mail1.sri.com (newmail.SRI.COM [128.18.30.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2F10021F8C89 for ; Mon, 19 Sep 2011 11:57:47 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=UTF-8; format=flowed Received: from [128.18.208.96] ([unknown] [128.18.70.8]) by mail.sri.com (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPS id <0LRS00FM0A49TD30@mail.sri.com> for behave@ietf.org; Mon, 19 Sep 2011 12:00:10 -0700 (PDT) Message-id: <4E779164.1000407@sri.com> Date: Mon, 19 Sep 2011 15:00:52 -0400 From: Ed Jankiewicz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 To: behave@ietf.org References: <4E75AFDA.8080800@fit.vutbr.cz> <4B451A10-73B8-4157-A8F0-87480B935C91@cisco.com> <4E771D49.2030605@fit.vutbr.cz> In-reply-to: <4E771D49.2030605@fit.vutbr.cz> Subject: Re: [BEHAVE] Are NAT translators routers? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 18:57:48 -0000 Interesting discussion at this point in time. When I was involved with a translator implementation (IPv4 host to IPv6 network) long ago in a galaxy far away, we interpreted our role as "fronting" the host, and that host behavior w.r.t. hop count was the right interpretation. I would tend to agree that a translator "in the network" is at least acting like a router, and should observe the router requirements, so the normative MUST would be appropriate I believe our translator was a special case, i.e. an edge device, where router requirements would not apply. On 9/19/2011 6:45 AM, Libor PolÄák wrote: > Fred Baker wrote: >> >> It is in every sense a router, and obeys the expectations of a >> router. In addition, it does as the RFC describes. In writing 6296 we >> didn't see any point in saying most of the things a router does - it >> already does them. >> >> The same is true of a NAT64 translator, with the exception that it >> must translate the headers entirely if possible, and do something >> sensible when it can't. In translating everything entirely, in most >> cases RFC 6145 makes a reversible translation - a source address that >> has an IPv6 prefix and an embedded IPv4 address becomes that exact >> IPv4 address in the source position and in the destination position >> of the reply. Going through the translator, the destinatoin of the >> translated packet is precisely the value of that original source >> address. The Hop Limit/TTL bears special notice because it follows a >> different rule - the translator being a router, the HL/TTL is >> decremented, which is not reversible. > > Hello Fred, > > yes, I agree with you. You have a point, NPTv6 is a L3 device and as > such has to decrement the TTL. I was probably confused because I am > preparing a project for students that doesn't have much experience in > network programming and tried to see the text from their point of > view. Nevertheless, I agree that RFC 6145 has to mention the decrement > since it copies the value stored in Hop Limit/TTL field. > > Thank you for your time, > > Libor PolÄák > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Edward J Jankiewicz, Senior Technical Advisor ESG/ISD - Center for Navigation and Survivability Systems SRI International, Inc. edward.jankiewicz@sri.com Direct: 443-502-5815 Google Voice: 908-718-1335 From kristian.poscic@alcatel-lucent.com Thu Sep 22 11:54:21 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54DE21F8B94 for ; Thu, 22 Sep 2011 11:54:21 -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.370, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lo5mrZl1j5mY for ; Thu, 22 Sep 2011 11:54:21 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id B6B8921F8B8E for ; Thu, 22 Sep 2011 11:54:20 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p8MIupLX015269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 22 Sep 2011 13:56:51 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p8MIupMc021833 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 22 Sep 2011 13:56:51 -0500 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.139]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Thu, 22 Sep 2011 13:56:51 -0500 From: "Poscic, Kristian (Kristian)" To: "behave@ietf.org" Date: Thu, 22 Sep 2011 13:56:44 -0500 Thread-Topic: predictable translations Thread-Index: Acx5WV97aAu68hVNTaay9qYQdmoSIA== Message-ID: <2073A6C5467C99478898544C6EBA3F4602BC3C8163@USNAVSXCHMBSC3.ndc.alcatel-lucent.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_2073A6C5467C99478898544C6EBA3F4602BC3C8163USNAVSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: [BEHAVE] predictable translations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 18:54:22 -0000 --_000_2073A6C5467C99478898544C6EBA3F4602BC3C8163USNAVSXCHMBSC_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi there - Does anyone knows of any draft that is addressing a more predictable transl= ations between the inside IP and outside IP + port range when it comes to N= AT44. For example in order to avoid logging, IPv4 inside address would be automat= ically (via an algorithm) be converted to an outside IPv4 address + a port= range. This mapping would be unique so that no logging is required. The re= vertive algo would be able to convert the outside IP + port back to the in= side IP. I've seen some drafts addressing something similar in the softwire WG but t= hey all deal with IPv4/IPv6 translations. Thanks, Kris --_000_2073A6C5467C99478898544C6EBA3F4602BC3C8163USNAVSXCHMBSC_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi there –=

Does anyone knows of any draft that is= addressing a more predictable translations between the inside IP and outsi= de IP + port range when it comes to NAT44.

For example in order to avoid logging, IPv4 inside address would be auto= matically (via an algorithm) be converted to an outside IPv4 address  = + a port range. This mapping would be unique so that no logging is required= . The revertive algo would be able to convert the outside IP + port back &n= bsp;to the inside IP.

 <= /p>

I’ve seen some drafts addressing something si= milar in the softwire WG but they all deal with IPv4/IPv6 translations.

Thanks,

= Kris

= --_000_2073A6C5467C99478898544C6EBA3F4602BC3C8163USNAVSXCHMBSC_-- From kristian.poscic@alcatel-lucent.com Thu Sep 22 16:26:02 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522B51F0C3C for ; Thu, 22 Sep 2011 16:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.321 X-Spam-Level: X-Spam-Status: No, score=-6.321 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FRCDbxViTD2 for ; Thu, 22 Sep 2011 16:26:01 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0A021F8C40 for ; Thu, 22 Sep 2011 16:26:00 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p8MNSVYF005382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 22 Sep 2011 18:28:31 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p8MNSUh7012416 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 22 Sep 2011 18:28:31 -0500 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.139]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 22 Sep 2011 18:28:31 -0500 From: "Poscic, Kristian (Kristian)" To: "'behave@ietf.org'" Date: Thu, 22 Sep 2011 18:28:28 -0500 Thread-Topic: predictable translations Thread-Index: Acx5WV97aAu68hVNTaay9qYQdmoSIAAJTlUg Message-ID: <2073A6C5467C99478898544C6EBA3F4602BC3C820D@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> References: <737DDEA1297B0348BA6AB9EA3216A67F02CDB54BE4@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> In-Reply-To: <737DDEA1297B0348BA6AB9EA3216A67F02CDB54BE4@USNAVSXCHMBSC3.ndc.alcatel-lucent.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_2073A6C5467C99478898544C6EBA3F4602BC3C820DUSNAVSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [BEHAVE] predictable translations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 23:26:02 -0000 --_000_2073A6C5467C99478898544C6EBA3F4602BC3C820DUSNAVSXCHMBSC_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I looked at this draft draft-bsd-softwire-stateless-port-index-analysis-00<= http://datatracker.ietf.org/doc/draft-bsd-softwire-stateless-port-index-ana= lysis/> which examines 6 different algorithms for predictable translation a= pplicable to v4/v6 translation but I guess it can be potentially adopted fo= r v4 to v4 conversions as well. As my coworker (who is probably on this list) says "too many deterministic = nat drafts make for non-deterministic behaviours". Is there any plan to adopt one as a standard? Thanks, Kris From: Poscic, Kristian (Kristian) Sent: Thursday, September 22, 2011 11:57 AM To: behave@ietf.org Subject: predictable translations Hi there - Does anyone knows of any draft that is addressing a more predictable transl= ations between the inside IP and outside IP + port range when it comes to N= AT44. For example in order to avoid logging, IPv4 inside address would be automat= ically (via an algorithm) be converted to an outside IPv4 address + a port= range. This mapping would be unique so that no logging is required. The re= vertive algo would be able to convert the outside IP + port back to the in= side IP. I've seen some drafts addressing something similar in the softwire WG but t= hey all deal with IPv4/IPv6 translations. Thanks, Kris --_000_2073A6C5467C99478898544C6EBA3F4602BC3C820DUSNAVSXCHMBSC_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I looked at this draft = draft-bsd-softwire-stateless-port-in= dex-analysis-00 which examines 6 different algorithms for predictable t= ranslation applicable to v4/v6 translation but I guess it can be potentiall= y adopted for v4 to v4 conversions as well.

&= nbsp;

As my coworker (who is probably on this list) say= s “too many deterministic nat drafts make for non-de= terministic behaviours”.

<= span style=3D'font-size:9.0pt;font-family:"Tahoma","sans-serif";color:black= '>Is there any plan to adopt one as a standard?

Thanks,

Kris=

 

From: Poscic, Kristian (Kristian)
Sent: Thu= rsday, September 22, 2011 11:57 AM
To: behave@ietf.org
Subj= ect: predictable translations

 

Hi there –

Does anyone knows of any draft that is add= ressing a more predictable translations between the inside IP and outside I= P + port range when it comes to NAT44.

F= or example in order to avoid logging, IPv4 inside address would be automati= cally (via an algorithm) be converted to an outside IPv4 address  + a = port range. This mapping would be unique so that no logging is required. Th= e revertive algo would be able to convert the outside IP + port back  = to the inside IP.

 

<= p class=3DMsoNormal>I’ve seen some drafts addressing something simila= r in the softwire WG but they all deal with IPv4/IPv6 translations.

Thanks,

Kris=

= --_000_2073A6C5467C99478898544C6EBA3F4602BC3C820DUSNAVSXCHMBSC_-- From dwing@cisco.com Thu Sep 22 22:22:13 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027A521F85AE for ; Thu, 22 Sep 2011 22:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.135 X-Spam-Level: X-Spam-Status: No, score=-103.135 tagged_above=-999 required=5 tests=[AWL=-0.536, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cq57h1twP+P2 for ; Thu, 22 Sep 2011 22:22:12 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 77F4621F8495 for ; Thu, 22 Sep 2011 22:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1149; q=dns/txt; s=iport; t=1316755485; x=1317965085; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=hGW8jLwQXqXYA35GbJmH2K3F3L52iubndXdXzhErvPs=; b=mJdmoxLjQ9s0M+O273Xe/qH6oT67gizmKWHDKT0fGhjvOMUR77YvO50x TxdhdFZm9rmpKg3bfAZMygJqPG3/S+GeowBVeWwt+cDtiHc14NwEx+j2s TQRKrQWvafKbJwMYroYJHOAMkNPahKrfa024QgOFm56nwl6yVc4g1ijah M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYAAPUWfE6rRDoI/2dsb2JhbABDmQ+BbI0ReIFTAQEBAQIBCAoBFxBLAQMCCQ8CBAEBKAcZIwoJCAEBBAESCxeHV5ZnAZ4nhn0Eh3KdMQ X-IronPort-AV: E=Sophos;i="4.68,427,1312156800"; d="scan'208";a="3823609" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 23 Sep 2011 05:24:42 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8N5OgiL003966; Fri, 23 Sep 2011 05:24:42 GMT From: "Dan Wing" To: "'Poscic, Kristian \(Kristian\)'" , References: <2073A6C5467C99478898544C6EBA3F4602BC3C8163@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> In-Reply-To: <2073A6C5467C99478898544C6EBA3F4602BC3C8163@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> Date: Thu, 22 Sep 2011 22:24:42 -0700 Message-ID: <088401cc79b1$194de790$4be9b6b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acx5WV97aAu68hVNTaay9qYQdmoSIAAV4bjA Content-Language: en-us Subject: Re: [BEHAVE] predictable translations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 05:22:13 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Poscic, Kristian (Kristian) > Sent: Thursday, September 22, 2011 11:57 AM > To: behave@ietf.org > Subject: [BEHAVE] predictable translations > > Hi there - > > Does anyone knows of any draft that is addressing a more predictable > translations between the inside IP and outside IP + port range when it > comes to NAT44. > > For example in order to avoid logging, IPv4 inside address would be > automatically (via an algorithm) be converted to an outside IPv4 > address + a port range. This mapping would be unique so that no > logging is required. The revertive algo would be able to convert the > outside IP + port back to the inside IP. Sure, a NAT could be built that does exactly that. Some vendors have been doing exactly that, or something very similar. How does the IETF fit into that, though? That is, why is a standard necessary? -d > > > I've seen some drafts addressing something similar in the softwire WG > but they all deal with IPv4/IPv6 translations. > > Thanks, > > Kris From kristian.poscic@alcatel-lucent.com Thu Sep 22 22:34:40 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A147121F8AD1 for ; Thu, 22 Sep 2011 22:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.377 X-Spam-Level: X-Spam-Status: No, score=-6.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4bwa1vUu24C for ; Thu, 22 Sep 2011 22:34:39 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id C8C5521F8ACE for ; Thu, 22 Sep 2011 22:34:39 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p8N5bBYM027743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Sep 2011 00:37:12 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p8N5bBIo023483 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 23 Sep 2011 00:37:11 -0500 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.139]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Fri, 23 Sep 2011 00:37:11 -0500 From: "Poscic, Kristian (Kristian)" To: Dan Wing , "behave@ietf.org" Date: Fri, 23 Sep 2011 00:37:09 -0500 Thread-Topic: [BEHAVE] predictable translations Thread-Index: Acx5WV97aAu68hVNTaay9qYQdmoSIAAV4bjAAAA4URA= Message-ID: <2073A6C5467C99478898544C6EBA3F4602BC3C8266@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> References: <2073A6C5467C99478898544C6EBA3F4602BC3C8163@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <088401cc79b1$194de790$4be9b6b0$@com> In-Reply-To: <088401cc79b1$194de790$4be9b6b0$@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-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [BEHAVE] predictable translations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 05:34:40 -0000 In my opinion two points: - if this is implemented to eliminate logging then there must be systems th= at do reverse conversion to find out who do original user was. It would mak= e more sense that that systems doing the reverse conversion uses common (st= andardized) algorithm. Otherwise this solution will be very vendor specific= and customers will be tied into vendor specific version of the algo. - other potential issues are legal issues with patents, etc. Kris=20 -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: Thursday, September 22, 2011 10:25 PM To: Poscic, Kristian (Kristian); behave@ietf.org Subject: RE: [BEHAVE] predictable translations > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Poscic, Kristian (Kristian) > Sent: Thursday, September 22, 2011 11:57 AM > To: behave@ietf.org > Subject: [BEHAVE] predictable translations >=20 > Hi there - >=20 > Does anyone knows of any draft that is addressing a more predictable > translations between the inside IP and outside IP + port range when it > comes to NAT44. >=20 > For example in order to avoid logging, IPv4 inside address would be > automatically (via an algorithm) be converted to an outside IPv4 > address + a port range. This mapping would be unique so that no > logging is required. The revertive algo would be able to convert the > outside IP + port back to the inside IP. Sure, a NAT could be built that does exactly that. Some vendors have been doing exactly that, or something very similar. How does the IETF fit into that, though? That is, why is a standard necessary? -d >=20 >=20 > I've seen some drafts addressing something similar in the softwire WG > but they all deal with IPv4/IPv6 translations. >=20 > Thanks, >=20 > Kris From dwing@cisco.com Thu Sep 22 22:44:59 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260DF21F8B29 for ; Thu, 22 Sep 2011 22:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.126 X-Spam-Level: X-Spam-Status: No, score=-103.126 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgqzqKFM58Kl for ; Thu, 22 Sep 2011 22:44:58 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id D87D721F8B27 for ; Thu, 22 Sep 2011 22:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2839; q=dns/txt; s=iport; t=1316756844; x=1317966444; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=4PYk6la1WfxKLJvOxUt+2AFp/eoXCxx4j5B83KPHDIk=; b=KpEpmUvohbwMFCFuA6P26gboU1OkdRTPoiNcKXKcY1YmsIN+3vP6aia7 PvyXDDCU+z1RFpZRZoTc+K+0z13Gh8KfLidaiDUyCtliv/owZdzTwQtEE XIsqVGozi2TzHogp6wbm4+ISXWIQ0PdpiA9pLUdb/K77ABmFAsgYpAEUB c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYAAMMcfE6rRDoH/2dsb2JhbABDmQ+BbI0ReIFTAQEBAQIBCAoBFxBEBwEDAgkPAgQBASgHGSMKCQgBAQQBEgsQB4dXlmwBniaGfQSHcp0x X-IronPort-AV: E=Sophos;i="4.68,427,1312156800"; d="scan'208";a="3826452" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 23 Sep 2011 05:47:24 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8N5lOrf017480; Fri, 23 Sep 2011 05:47:24 GMT From: "Dan Wing" To: "'Poscic, Kristian \(Kristian\)'" , References: <2073A6C5467C99478898544C6EBA3F4602BC3C8163@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <088401cc79b1$194de790$4be9b6b0$@com> <2073A6C5467C99478898544C6EBA3F4602BC3C8266@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> In-Reply-To: <2073A6C5467C99478898544C6EBA3F4602BC3C8266@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> Date: Thu, 22 Sep 2011 22:47:24 -0700 Message-ID: <089801cc79b4$44e03400$cea09c00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acx5WV97aAu68hVNTaay9qYQdmoSIAAV4bjAAAA4URAAAHQNsA== Content-Language: en-us Subject: Re: [BEHAVE] predictable translations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 05:44:59 -0000 > -----Original Message----- > From: Poscic, Kristian (Kristian) [mailto:kristian.poscic@alcatel- > lucent.com] > Sent: Thursday, September 22, 2011 10:37 PM > To: Dan Wing; behave@ietf.org > Subject: RE: [BEHAVE] predictable translations > > In my opinion two points: > - if this is implemented to eliminate logging then there must be > systems that do reverse conversion to find out who do original user > was. It would make more sense that that systems doing the reverse > conversion uses common (standardized) algorithm. Otherwise this > solution will be very vendor specific and customers will be tied into > vendor specific version of the algo. It's not possible to accomplish that, unless there is guarantee / assurance that the subscriber's address (assigned to their CPE) did not also change. A+P/dIVI/4rd can't guarantee that. Only the ISP can do that with the combination of its knowledge of what address it assigned to the CPE and how its address sharing device was configured on that particular day. Consider, for example, a Tuesday night where users are changed from 300 ports to 200 ports. Only the ISP is aware of that change and when that change occurred. An entity on the Internet won't be aware. I don't see how the requirement you're stating can be met. > - other potential issues are legal issues with patents, etc. -d > Kris > > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Thursday, September 22, 2011 10:25 PM > To: Poscic, Kristian (Kristian); behave@ietf.org > Subject: RE: [BEHAVE] predictable translations > > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of Poscic, Kristian (Kristian) > > Sent: Thursday, September 22, 2011 11:57 AM > > To: behave@ietf.org > > Subject: [BEHAVE] predictable translations > > > > Hi there - > > > > Does anyone knows of any draft that is addressing a more predictable > > translations between the inside IP and outside IP + port range when > it > > comes to NAT44. > > > > For example in order to avoid logging, IPv4 inside address would be > > automatically (via an algorithm) be converted to an outside IPv4 > > address + a port range. This mapping would be unique so that no > > logging is required. The revertive algo would be able to convert the > > outside IP + port back to the inside IP. > > Sure, a NAT could be built that does exactly that. Some vendors > have been doing exactly that, or something very similar. > > How does the IETF fit into that, though? That is, why is a standard > necessary? > > -d > > > > > > > > I've seen some drafts addressing something similar in the softwire WG > > but they all deal with IPv4/IPv6 translations. > > > > Thanks, > > > > Kris From mohamed.boucadair@orange.com Thu Sep 22 22:57:39 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE80C21F86EC for ; Thu, 22 Sep 2011 22:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F04QS9X+9Vl4 for ; Thu, 22 Sep 2011 22:57:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 6094421F86D0 for ; Thu, 22 Sep 2011 22:57:37 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 8E3182AC61D; Fri, 23 Sep 2011 08:00:09 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 74B06C8060; Fri, 23 Sep 2011 08:00:09 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Fri, 23 Sep 2011 08:00:09 +0200 From: To: "Poscic, Kristian (Kristian)" , "'behave@ietf.org'" Date: Fri, 23 Sep 2011 08:00:07 +0200 Thread-Topic: predictable translations Thread-Index: Acx5WV97aAu68hVNTaay9qYQdmoSIAAJTlUgAA1r3VA= Message-ID: <94C682931C08B048B7A8645303FDC9F355A8E5A5FC@PUEXCB1B.nanterre.francetelecom.fr> References: <737DDEA1297B0348BA6AB9EA3216A67F02CDB54BE4@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <2073A6C5467C99478898544C6EBA3F4602BC3C820D@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> In-Reply-To: <2073A6C5467C99478898544C6EBA3F4602BC3C820D@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F355A8E5A5FCPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.9.23.22414 Subject: Re: [BEHAVE] predictable translations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 05:57:39 -0000 --_000_94C682931C08B048B7A8645303FDC9F355A8E5A5FCPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Kris, Could please precise more what you mean by "predictable translation"? (1) Do you want to eliminate the volume of CGN logs (e.g, few entries per c= ustomer) or (2) you want to eliminate the CGN logging (e.g., rely on DHCP r= ecords)? (1) can be done in the CGN itself by design or configuration of the CGN to = use port ranges. This is already supported by CGN implementation including = A(..)U ;-) (2) can be supported only if you eliminate the NAT function in the CGN whic= h should be a PRR (Port Range Router; http://tools.ietf.org/html/draft-bouc= adair-port-range-02#section-6) instead. Cheers, Med ________________________________ De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Poscic, Kristian (Kristian) Envoy=E9 : vendredi 23 septembre 2011 01:28 =C0 : 'behave@ietf.org' Objet : Re: [BEHAVE] predictable translations I looked at this draft draft-bsd-softwire-stateless-port-index-analysis-00<= http://datatracker.ietf.org/doc/draft-bsd-softwire-stateless-port-index-ana= lysis/> which examines 6 different algorithms for predictable translation a= pplicable to v4/v6 translation but I guess it can be potentially adopted fo= r v4 to v4 conversions as well. As my coworker (who is probably on this list) says "too many deterministic = nat drafts make for non-deterministic behaviours". Is there any plan to adopt one as a standard? Thanks, Kris From: Poscic, Kristian (Kristian) Sent: Thursday, September 22, 2011 11:57 AM To: behave@ietf.org Subject: predictable translations Hi there - Does anyone knows of any draft that is addressing a more predictable transl= ations between the inside IP and outside IP + port range when it comes to N= AT44. For example in order to avoid logging, IPv4 inside address would be automat= ically (via an algorithm) be converted to an outside IPv4 address + a port= range. This mapping would be unique so that no logging is required. The re= vertive algo would be able to convert the outside IP + port back to the in= side IP. I've seen some drafts addressing something similar in the softwire WG but t= hey all deal with IPv4/IPv6 translations. Thanks, Kris --_000_94C682931C08B048B7A8645303FDC9F355A8E5A5FCPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Kris,
 
Could please precise more what you mean by=20 "predictable translation"?
 
(1) Do you want to eliminate the volume of CG= N logs=20 (e.g, few entries per customer) or (2) you want to eliminate the CGN loggin= g=20 (e.g., rely on DHCP records)?
 
(1) can be done in the CGN itself by design o= r=20 configuration of the CGN to use port ranges. This is already supported by C= GN=20 implementation including A(..)U ;-)
 
(2) can be supported only if you eliminate th= e NAT=20 function in the CGN which should be a PRR (Port Range Router; http://tools.ietf.org/html/draft-boucadair-port-range-02#section-6)=20 instead.
 
 
Cheers,
Med

De : behave-bounces@ietf.org=20 [mailto:behave-bounces@ietf.org] De la part de Poscic, Kristian=20 (Kristian)
Envoy=E9 : vendredi 23 septembre 2011=20 01:28
=C0 : 'behave@ietf.org'
Objet : Re: [BE= HAVE]=20 predictable translations

I looked at this draft= =20 draft-bsd-softwire-stateless-port-index-analysis-00=20 which examines 6 different algorithms for predictable translation applicabl= e to=20 v4/v6 translation but I guess it can be potentially adopted for v4 to v4=20 conversions as well.

 

As=20 my coworker (who is probably on this list) says =93= too=20 many deterministic nat drafts make for non-deterministic behaviours=94.=20

= Is=20 there any plan to adopt one as a standard?

= Thanks,

= Kris

 

From:<= /B> Poscic, Kris= tian=20 (Kristian)
Sent: Thursday, September 22, 2011 11:57 AM
To:= =20 behave@ietf.org
Subject: predictable=20 translations

 

Hi there =96

Does anyone knows of any draft that is addressing a mo= re=20 predictable translations between the inside IP and outside IP + port range = when=20 it comes to NAT44.

For example in order to avoid logging, IPv4 inside add= ress=20 would be automatically (via an algorithm) be converted to an outside IPv4=20 address  + a port range. This mapping would be unique so that no loggi= ng is=20 required. The revertive algo would be able to convert the outside IP + port= back=20  to the inside IP.

 

I=92ve seen some drafts addressing something similar i= n the=20 softwire WG but they all deal with IPv4/IPv6 translations.

Thanks,

Kris

--_000_94C682931C08B048B7A8645303FDC9F355A8E5A5FCPUEXCB1Bnante_-- From kristian.poscic@alcatel-lucent.com Fri Sep 23 09:08:45 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F36421F8C6A for ; Fri, 23 Sep 2011 09:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.414 X-Spam-Level: X-Spam-Status: No, score=-6.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYU3lMQseMFC for ; Fri, 23 Sep 2011 09:08:44 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4E05821F8C2D for ; Fri, 23 Sep 2011 09:08:44 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p8NGBFko010054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Sep 2011 11:11:15 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p8NGBFDP025056 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 23 Sep 2011 11:11:15 -0500 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.139]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Fri, 23 Sep 2011 11:11:15 -0500 From: "Poscic, Kristian (Kristian)" To: Dan Wing , "behave@ietf.org" Date: Fri, 23 Sep 2011 11:11:06 -0500 Thread-Topic: [BEHAVE] predictable translations Thread-Index: Acx5WV97aAu68hVNTaay9qYQdmoSIAAV4bjAAAA4URAAAHQNsAAVyhmw Message-ID: <2073A6C5467C99478898544C6EBA3F4602BC3C82B5@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> References: <2073A6C5467C99478898544C6EBA3F4602BC3C8163@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <088401cc79b1$194de790$4be9b6b0$@com> <2073A6C5467C99478898544C6EBA3F4602BC3C8266@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <089801cc79b4$44e03400$cea09c00$@com> In-Reply-To: <089801cc79b4$44e03400$cea09c00$@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-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [BEHAVE] predictable translations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 16:08:45 -0000 Ok, so you're saying that the backward conversion must be limited to the NA= T device itself. In other words one would via CLI 'show/display' commands o= n the NAT device enter the outside IP + port and the output would be the in= side IP. Of course the NMS could also query the NAT device remotely. But th= ere would be no external systems (back-end) that would be running the algor= ithm so do this conversion. Ok, makes sense. Thanks, Kris=20 -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: Thursday, September 22, 2011 10:47 PM To: Poscic, Kristian (Kristian); behave@ietf.org Subject: RE: [BEHAVE] predictable translations > -----Original Message----- > From: Poscic, Kristian (Kristian) [mailto:kristian.poscic@alcatel- > lucent.com] > Sent: Thursday, September 22, 2011 10:37 PM > To: Dan Wing; behave@ietf.org > Subject: RE: [BEHAVE] predictable translations >=20 > In my opinion two points: > - if this is implemented to eliminate logging then there must be > systems that do reverse conversion to find out who do original user > was. It would make more sense that that systems doing the reverse > conversion uses common (standardized) algorithm. Otherwise this > solution will be very vendor specific and customers will be tied into > vendor specific version of the algo. It's not possible to accomplish that, unless there is guarantee / assurance that the subscriber's address (assigned to their CPE) did not also change. A+P/dIVI/4rd can't guarantee that. Only the ISP can do that with the combination of its knowledge of what address it assigned to the CPE and how its address sharing device was configured on that particular day. Consider, for example, a Tuesday night where users are changed from 300 ports to 200 ports. Only the ISP is aware of that change and when that change occurred. An entity on the Internet won't be=20 aware. I don't see how the requirement you're stating can be met. > - other potential issues are legal issues with patents, etc. -d > Kris >=20 > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Thursday, September 22, 2011 10:25 PM > To: Poscic, Kristian (Kristian); behave@ietf.org > Subject: RE: [BEHAVE] predictable translations >=20 > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of Poscic, Kristian (Kristian) > > Sent: Thursday, September 22, 2011 11:57 AM > > To: behave@ietf.org > > Subject: [BEHAVE] predictable translations > > > > Hi there - > > > > Does anyone knows of any draft that is addressing a more predictable > > translations between the inside IP and outside IP + port range when > it > > comes to NAT44. > > > > For example in order to avoid logging, IPv4 inside address would be > > automatically (via an algorithm) be converted to an outside IPv4 > > address + a port range. This mapping would be unique so that no > > logging is required. The revertive algo would be able to convert the > > outside IP + port back to the inside IP. >=20 > Sure, a NAT could be built that does exactly that. Some vendors > have been doing exactly that, or something very similar. >=20 > How does the IETF fit into that, though? That is, why is a standard > necessary? >=20 > -d >=20 >=20 > > > > > > I've seen some drafts addressing something similar in the softwire WG > > but they all deal with IPv4/IPv6 translations. > > > > Thanks, > > > > Kris From kristian.poscic@alcatel-lucent.com Fri Sep 23 09:18:55 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3F021F8CB7 for ; Fri, 23 Sep 2011 09:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.44 X-Spam-Level: X-Spam-Status: No, score=-6.44 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXt67P646u+i for ; Fri, 23 Sep 2011 09:18:53 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id D9C8921F8CAD for ; Fri, 23 Sep 2011 09:18:52 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p8NGLQBl015014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Sep 2011 11:21:27 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p8NGLL6P005503 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 23 Sep 2011 11:21:26 -0500 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.139]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Fri, 23 Sep 2011 11:21:22 -0500 From: "Poscic, Kristian (Kristian)" To: "mohamed.boucadair@orange.com" , "'behave@ietf.org'" Date: Fri, 23 Sep 2011 11:21:13 -0500 Thread-Topic: predictable translations Thread-Index: Acx5WV97aAu68hVNTaay9qYQdmoSIAAJTlUgAA1r3VAAFchtkA== Message-ID: <2073A6C5467C99478898544C6EBA3F4602BC3C82BF@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> References: <737DDEA1297B0348BA6AB9EA3216A67F02CDB54BE4@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <2073A6C5467C99478898544C6EBA3F4602BC3C820D@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <94C682931C08B048B7A8645303FDC9F355A8E5A5FC@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F355A8E5A5FC@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: multipart/alternative; boundary="_000_2073A6C5467C99478898544C6EBA3F4602BC3C82BFUSNAVSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [BEHAVE] predictable translations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 16:18:55 -0000 --_000_2073A6C5467C99478898544C6EBA3F4602BC3C82BFUSNAVSXCHMBSC_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, By predictable translation I mean deterministic NAT. For now, I'm just trying to evaluate (for my own sake) if this deterministi= c NAT makes any sense since 1) would take care of the concerns that I have.= If deterministic NAT makes deployable sense [for a reason that I yet need = to find, since 1) already takes care of my concerns], then I'm trying to ev= aluate surrounding issues related to ease of integration into existing OS = (which it looks like does not come into play) and any other legal issues re= lated to use of already possibly patented algorithms. Thanks, Kris From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Thursday, September 22, 2011 11:00 PM To: Poscic, Kristian (Kristian); 'behave@ietf.org' Subject: RE: predictable translations Dear Kris, Could please precise more what you mean by "predictable translation"? (1) Do you want to eliminate the volume of CGN logs (e.g, few entries per c= ustomer) or (2) you want to eliminate the CGN logging (e.g., rely on DHCP r= ecords)? (1) can be done in the CGN itself by design or configuration of the CGN to = use port ranges. This is already supported by CGN implementation including = A(..)U ;-) (2) can be supported only if you eliminate the NAT function in the CGN whic= h should be a PRR (Port Range Router; http://tools.ietf.org/html/draft-bouc= adair-port-range-02#section-6) instead. Cheers, Med ________________________________ De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Poscic, Kristian (Kristian) Envoy=E9 : vendredi 23 septembre 2011 01:28 =C0 : 'behave@ietf.org' Objet : Re: [BEHAVE] predictable translations I looked at this draft draft-bsd-softwire-stateless-port-index-analysis-00<= http://datatracker.ietf.org/doc/draft-bsd-softwire-stateless-port-index-ana= lysis/> which examines 6 different algorithms for predictable translation a= pplicable to v4/v6 translation but I guess it can be potentially adopted fo= r v4 to v4 conversions as well. As my coworker (who is probably on this list) says "too many deterministic = nat drafts make for non-deterministic behaviours". Is there any plan to adopt one as a standard? Thanks, Kris From: Poscic, Kristian (Kristian) Sent: Thursday, September 22, 2011 11:57 AM To: behave@ietf.org Subject: predictable translations Hi there - Does anyone knows of any draft that is addressing a more predictable transl= ations between the inside IP and outside IP + port range when it comes to N= AT44. For example in order to avoid logging, IPv4 inside address would be automat= ically (via an algorithm) be converted to an outside IPv4 address + a port= range. This mapping would be unique so that no logging is required. The re= vertive algo would be able to convert the outside IP + port back to the in= side IP. I've seen some drafts addressing something similar in the softwire WG but t= hey all deal with IPv4/IPv6 translations. Thanks, Kris --_000_2073A6C5467C99478898544C6EBA3F4602BC3C82BFUSNAVSXCHMBSC_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

By predictable translation I mean deterministic NAT.

=  

F= or now, I’m just trying to evaluate (for my own sake) if this determi= nistic NAT makes any sense since 1) would take care of the concerns that I = have. If deterministic NAT makes deployable sense [for a reason that I yet = need to find, since 1) already takes care of my concerns], then I’m t= rying to evaluate surrounding issues related to ease of integration into ex= isting OS =A0(which it looks like does not come into play) and any other le= gal issues related to use of already possibly patented algorithms.

 =

Thanks,=

Kr= is

=  

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> mohamed.= boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent:= Thursday, September 22, 2011 11:00 PM
To: Poscic, Kristian (Kris= tian); 'behave@ietf.org'
Subject: RE: predictable translations

 

 

Could please precise more what you mean = by "predictable translation"?

 

(1) Do you want to elimin= ate the volume of CGN logs (e.g, few entries per customer) or (2) you want = to eliminate the CGN logging (e.g., rely on DHCP records)?

 

(= 1) can be done in the CGN itself by design or configuration of the CGN to u= se port ranges. This is already supported by CGN implementation including A= (..)U ;-)

 =

(2) can be supported only if you eliminate the NAT func= tion in the CGN which should be a PRR (Port Range Router; http://tools.= ietf.org/html/draft-boucadair-port-range-02#section-6) instead.<= span style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'>=

 

 

Cheers,

Med

&n= bsp;

<= p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part = de Poscic, Kristian (Kristian)
Envoy=E9 : vendredi 23 se= ptembre 2011 01:28
=C0 : 'behave@ietf.org'
Objet = : Re: [BEHAVE] predictable translations<= /p>

I looked at this draf= t draft-bsd-softwire-stateless-port-index-analysis-00 which examines = 6 different algorithms for predictable translation applicable to v4/v6 tran= slation but I guess it can be potentially adopted for v4 to v4 conversions = as well.

 

As my cow= orker (who is probably on this list) says “too many= deterministic nat drafts make for non-deterministic behaviours”. =

Is there any plan to adopt one as = a standard?

Thanks,=

Kris

<= o:p> 

From: Poscic, K= ristian (Kristian)
Sent: Thursday, September 22, 2011 11:57 AMTo: behave@ietf.org
Subject: predictable translations

 

Hi there –

Doe= s anyone knows of any draft that is addressing a more predictable translati= ons between the inside IP and outside IP + port range when it comes to NAT4= 4.

For example in order to avoid logging= , IPv4 inside address would be automatically (via an algorithm) be converte= d to an outside IPv4 address  + a port range. This mapping would be un= ique so that no logging is required. The revertive algo would be able to co= nvert the outside IP + port back  to the inside IP.

 

I’ve seen = some drafts addressing something similar in the softwire WG but they all de= al with IPv4/IPv6 translations.

Thanks,<= o:p>

Kris

= --_000_2073A6C5467C99478898544C6EBA3F4602BC3C82BFUSNAVSXCHMBSC_-- From teemu.savolainen@nokia.com Mon Sep 26 07:26:10 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B541221F8D5F; Mon, 26 Sep 2011 07:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbEFeRVUDY+U; Mon, 26 Sep 2011 07:26:09 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECC721F8D53; Mon, 26 Sep 2011 07:26:09 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8QESjrO014606; Mon, 26 Sep 2011 17:28:48 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 17:28:35 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 26 Sep 2011 16:28:35 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.8]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0339.002; Mon, 26 Sep 2011 16:28:34 +0200 From: To: , Thread-Topic: tsv-dir review of draft-ietf-behave-v4v6-bih-06 Thread-Index: AQHMc1RjP+KeJQLr8UyA/4w/v6oRZZVfyEEA Date: Mon, 26 Sep 2011 14:28:34 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696203771764@008-AM1MPN1-037.mgdnok.nokia.com> References: <4E716B6E.2050409@gont.com.ar> In-Reply-To: <4E716B6E.2050409@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IuVUqU990PH/KmYdU5d8L7GlV9odQ+YBs9ZD3jediQ4GBImoE7kbu7KY7eEGlzyIvGhKuZryAIp98I8Fis/NS6cMBIN9ljUNft78olS7+tG96EMPr+435HoYTNDgRWBU+P1EPfG2moQsKOIcAXrkBZpk/8HX8CDOXgLIO6uRJLKwA2KX1ek/KG8FGZ09F4LGkVKesvQ5tFR3TPPHJVrpAItKsQOWukuNfZHzbE1FF+g+J/LpGYle25JjccF+Y5pdDg== x-originating-ip: [10.162.60.47] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_024F_01CC7C71.B6CB0990" MIME-Version: 1.0 X-OriginalArrivalTime: 26 Sep 2011 14:28:35.0792 (UTC) FILETIME=[93588500:01CC7C58] X-Nokia-AV: Clean Cc: behave@ietf.org, ietf@ietf.org, tsv-ads@ietf.org, tsv-dir@ietf.org Subject: Re: [BEHAVE] tsv-dir review of draft-ietf-behave-v4v6-bih-06 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2011 14:26:10 -0000 ------=_NextPart_000_024F_01CC7C71.B6CB0990 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thank you Fernando for your review. Comments are inline: > -----Original Message----- > From: Fernando Gont [mailto:fernando.gont.netbook.win@gmail.com] On > Behalf Of ext Fernando Gont > Sent: 15. syyskuuta 2011 06:05 > To: draft-ietf-behave-v4v6-bih@tools.ietf.org > Cc: TSV Dir; 'ietf@ietf.org'; tsv-ads@ietf.org; Behave WG > Subject: tsv-dir review of draft-ietf-behave-v4v6-bih-06 =20 > * The document mentions two possible implementation alternatives, and > recommends one of them. However, lacks a discussion of the pros/cons = of > each alternative, and the applicability of each of them. I believe the pros/cons are included here and there in the document, but = I guess we could write a small section that summarizes the pros/cons of = both approaches.=20 > * Section 2.2, page 8: > > To avoid unnecessary fragmentation, the host's IPv4 module should be > > configured with a small enough MTU (IPv6 link MTU - 20 bytes). >=20 > Is the "IPv6 link MTU" the MTU of the link the host is attached to, or = are you > referring to the "Minimum IPv6 MTU" of 1280 bytes? MTU of the link the host is attached to. We can clarify. =20 > * Section 2.3, page 8: > > In either implementation option, if there is a real IPv4 address > > available, the ENR SHOULD NOT synthesize IPv4 addresses. By default > > an ENR implementation MUST NOT synthesize IPv4 addresses when real > > IPv4 addresses exist. >=20 > What are the reasons for which one would sinthesize IPv4 addresses = when > real IPv4 addresses exist? -- If there are not any, then make this a = MUST > (rather than a SHOULD). One would synthesize IPv4 address, if the real IPv4 address was excluded = (see section 2.3.1). > * Section 2.3.2, page 9: > > The ENR may support DNSSEC. >=20 > Should you s/may/MAY/? I think MAY is fine, SHOULD may be too strong as of currently. > * Section 2.4, page 10: > > (2) When the extension name resolver gets both IPv4 and IPv6 > > addresses, but the IPv4 addresses contain only excluded IPv4 = addresses > > (e.g., 127.0.0.1). The behavior will follow case (1). >=20 > Does this mean that BIH will be employed if I do "ping6 localhost"? If the "localhost" has both IPv4 and IPv6 addresses, then the ping6 = would use IPv6.. and if it has only IPv4 name, then how could the BIH = map any synthesized name to IPv6 address (that is not there)? So I = don=E2=80=99t think BIH would be employed=EF=81=8A The bigger question maybe is that does the exclusion set include only = addresses received over wire, or also addresses configured in = hosts-file.. Maybe the exclusion should not exclude addresses that are = locally configured. > * Section 2.4, pages 10-11: > > (3) When the function mapper gets a socket API function call = triggered > > by a received IPv6 packet and there is no existing mapping entry = for > > the IPv6 source address (for example, the client sent a UDP request = to > > an anycast address but a response was received from a unicast > > address). >=20 > While I understand the scenario you're describing, it seems the = description is > incorrect. In the scenario you describe, it is the *user* (and not the = packet) > that triggers the socket API function call (e.g., a > "read()) -- maybe you should be saying "when the function mapper is > triggered by a received IPv6 packet..." instead?. Agree, the proposed text is better. > * Page 14, Figure 6: > > = |<=3D=3D=3D=3D=3D=3D=3D|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D| An IPv4 Socket function call. >=20 > This is incorrect. You should probably say something along the lines = of > "Return from the IPv4 function call" -- unless you're assuming = asynchronous > I/O, which I'd bet you're not. That is directly from RFC3338. If you think first arrow as = =E2=80=9Csend()=E2=80=9D-call and the quoted one as = =E2=80=9Crecv()=E2=80=9D-call, would those arrows then make sense? > * Section 4.3, page 16: > > 4.3. ICMP Message Handling > > > > When an application needs ICMP messages values (e.g., Type, Code, > > etc.) sent from the network layer, ICMPv4 message values MAY be > > translated into ICMPv6 message values based on SIIT [RFC6145], and > > vice versa. >=20 > What do you exactly mean by "needs ICMP message values"? Do you mean > "if an application needs to receive ICMP error messages.."? -- If so, = shouldn't > this be a "SHOULD" rather than a "MAY"? Maybe that should be even MUST, as why the translator would not pass on = ICMP information? > * Section 7.3, page 22: > > In order to allow the BIH to defend against such attacks, the BIH > > implementation MAY choose not to extend the session entry lifetime = for > > a specific entry upon the reception of packets for that entry = through > > the external interface. >=20 > You should probably note that this would kill session entries for = one-way > communication instances. Like NATs usually do=E2=80=A6 but a note of this can be added. > * Section 7.4, page 22: > > BIH operates in combination with the DNS, and is therefore subject = to > > whatever security considerations are appropriate to the DNS mode in > > which the BIH is operating (i.e., authoritative, recursive, or > > stub- resolver mode). >=20 > I don't follow why BIH could be operating in authoritative mode. Could = you > clarify this? Copy paste bug from RFC6147, will remove = =E2=80=9Cauthoritative=E2=80=9D. > * Appendix A, page 27: > > Appendix A. API list intercepted by BIH > > > > The following informational list includes API functions that would = be > > appropriate to intercept by BIH module when implemented at socket > > layer. >=20 > Since API function call interceptions are key for this mechanism to = work, I > believe the contents of this section should be normative (unless = you're > thinking of this document as a "framework". Additionally, the list = *should* be > exhaustive. The list is just informational and non-exhaustive, as it depends on = implementation what API functions there are =E2=80=93 and implementation = may not even utilize POSIX API conventions. Hence we did not want to = have this normative. That reasoning could be added of course. =20 > * Appendix A > While the initial contents seem mostly informative, at the end of the > Appendix there are some normative requirements. IMHO, they should be > moved to the body of the document, rather than being left out in an > appendix. The appendix is informative, so the keywords will be removed. > EDITORIAL > --------- These were ok, will be handled. > * Section 7.3, page 22: > > BIN implementations MUST implement proper protection against such > > attacks, for instance, allocating a limited amount of memory for > > fragmented packet storage. >=20 > You're probably referring to one of the implementation alternatives of = BIH. > But since you don't use "BIN" for referring to such implementation > alternative throughout the document, you shouldn't use it here, = either. > i.e., please rephrase. Typo, that should be BIH, but maybe better could be =E2=80=9Cnetwork = layer implementation of option of BIH=E2=80=9D as there probably are no = fragments on socket level implementation.. Best regards, Teemu ------=_NextPart_000_024F_01CC7C71.B6CB0990 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTI2MTQyODMyWjAjBgkqhkiG9w0B CQQxFgQUzXzVToZ6mbiluaP4WWxbcN9cruIwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAHV9WLVuYvLWceQZCS6w p/TRL60/3Kb8NGDXBlVLeKaIubJCe9JJ3x5qZOSRDCyt/MKaezwNP8KTU8nhjIMgz6giIydvGmx7 j4WLV3BB7Na6UccTRD8ejDsrAoquINyfF8dLrdWiDgsl8mDd3Y2nyN78oUy3OG0NgN1DIRVjF8gU uUm8TZsY7d2aO7vE3VUoJ7r+35S7SYUXmzmsYlHc+JQTvn4VofyhmPM9wj8gVsorByV5mt7H1WYw Rz1K5EQikaIIVeqeCFeKqfMrOa7Lt9JOcq0R4i3Diq7ZdToDUfB2syvAVWKkXEvra7OPMeFD1N6Q 6E/2McNdNmTv1ZCXlLoAAAAAAAA= ------=_NextPart_000_024F_01CC7C71.B6CB0990-- From teemu.savolainen@nokia.com Mon Sep 26 08:18:02 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D980221F8D74; Mon, 26 Sep 2011 08:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3M6mCtFU3th; Mon, 26 Sep 2011 08:18:02 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id D881321F8D68; Mon, 26 Sep 2011 08:18:01 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8QFKahm010688; Mon, 26 Sep 2011 18:20:43 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 18:19:55 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 26 Sep 2011 17:19:55 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.8]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0339.002; Mon, 26 Sep 2011 17:19:54 +0200 From: To: , Thread-Topic: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard Thread-Index: Acx8XrGT3LPZ/umGSqyAQmFBTGHJTg== Date: Mon, 26 Sep 2011 15:19:54 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ili3MCvCLXmrxYjzLlJRY6EmZaqCLgxWgL9U8rnNM82CuD5+v00s+B6rNvhV7DPY+SM/In0cx92oRHang+R5hgiMyIoI03Er7sc1TlPZR1iVeAwzuvIEvF9C4WSriAJSEApEzC3cWtkrbRBgt8eqLi9xL3BeA9Kbd7cnR5KgY6zYIlVUmUnvVQBVLUguDohOJZ1kNXXcLNNTXApPp6UZWv5S0RCzCWXj7dZN2f+2sEIzoBUhRFGhPhJgcz/K46YNuJd3tRQJ3Fbspb7ltrO3iFFpHycdLAV6I/HFHU0o9f3goBe9a580t/xnmKSCAJabYVqtcYkAR91gr294fYuGs6Y= x-originating-ip: [10.162.60.47] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0266_01CC7C78.E2F15BD0" MIME-Version: 1.0 X-OriginalArrivalTime: 26 Sep 2011 15:19:56.0003 (UTC) FILETIME=[BF4B6B30:01CC7C5F] X-Nokia-AV: Clean Cc: softwires@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2011 15:18:03 -0000 ------=_NextPart_000_0266_01CC7C78.E2F15BD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Please note that this statement was included after quite long and heated discussion in behave WG and because it came clear that IETF recommendation is against double protocol translation (in favor of dual-stack and tunneling). It may be that the recommendation is specifically against *stateful* double translation (although that was not said aloud, if I recall correctly). I would assume softwires follows these same IETF guidelines and therefore is now focusing solely on stateless approaches(?). If the IETF opinion has changed so that also stateful double translation solutions are now ok for IETF, then that should perhaps be reflected in this document as well. Unfortunately, I did not have chance to go to softwires interim, but please let us know if the discussions there impact also the quoted recommendation. Best regards, Teemu > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of ext Satoru Matsushima > Sent: 13. syyskuuta 2011 06:51 > To: ietf@ietf.org > Cc: behave@ietf.org; Satoru Matsushima > Subject: Re: [BEHAVE] Last Call: (Dual > Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard > > The introduction in the draft says: > > > > IETF recommends using dual-stack or tunneling based solutions for > > IPv6 transition and specifically recommends against deployments > > utilizing double protocol translation. Use of BIH together with a > > NAT64 is NOT RECOMMENDED [RFC6180]. > > > > > This statement makes a strong obstacle when we develop stateless solution > with translation in softwires wg. > I think that it is still remained a room to make decision whether removing the > statement or remaining it. > The discussion which we'll have in the softwires interim meeting would be > helpful to decide it. > > Best regards, > --satoru > > > > On 2011/08/31, at 22:53, The IESG wrote: > > > > > The IESG has received a request from the Behavior Engineering for > > Hindrance Avoidance WG (behave) to consider the following document: > > - 'Dual Stack Hosts Using "Bump-in-the-Host" (BIH)' > > 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 2011-09-14. 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. > > > > Abstract > > > > > > Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol > > translation mechanism that allows a class of IPv4-only applications > > that work through NATs to communicate with IPv6-only peers. The host > > on which applications are running may be connected to IPv6-only or > > dual-stack access networks. BIH hides IPv6 and makes the IPv4-only > > applications think they are talking with IPv4 peers by local > > synthesis of IPv4 addresses. This draft obsoletes RFC 2767 and RFC > > 3338. > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > > 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 ------=_NextPart_000_0266_01CC7C78.E2F15BD0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTI2MTUxOTUzWjAjBgkqhkiG9w0B CQQxFgQUMC4q3tZo9Tw8TXY9EMhNwF7o/bMwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAHUR9RTc3iQlANErDJ03 o2LvASH7nSTkkg54Q0Ys4zodid9ZprkMa1tKKYtsxyL1eBbggrA5LN7UBept/YIMRHR02gL+1JU6 gtCzWbsxcqF7olSI9SVXDfOwRo9YO6AGOcnC8nAs5x6pe1kxl2ksVenb3CvyQce3ZbAcxdf7VELV PsvrQgWrhhMqoKMkzKHjVQFUxConL0Ofp12jUHCn19gC5tBWTwDTSF/HY5naFWuA4MOVJcxvLz09 LNtnANrT65idMPXlo6q9Bdeg/sxAVgnW3QWn/TydMNeG1WadqGo0EOQXgGHKi2fzHfr3ryrgYyDU q60yEiktS5EyPQWwcLUAAAAAAAA= ------=_NextPart_000_0266_01CC7C78.E2F15BD0-- From rajiva@cisco.com Mon Sep 26 08:50:01 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A19211E80A0; Mon, 26 Sep 2011 08:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epsrk2NTRq-1; Mon, 26 Sep 2011 08:50:00 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE4111E809C; Mon, 26 Sep 2011 08:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=5371; q=dns/txt; s=iport; t=1317052363; x=1318261963; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=sEOjYbL98Ldz5qoKMNIQDrPMmjlkUZ+vsFaRvkfsxg4=; b=XrTergRmgZGTXb95LHiWVu9YkOsLs/Ip4799hLHdTPy0kcWA+EOiYFhd sQQDY93Fa9cY/3eWeerJ0IYgYKlMX6BKSMGTWV3DQsrNzFZxln0N5lfSI +figARZXQqbmlPQp2ibZd6iqazZKiLyHjU5seyaqqQ4EqJ32DRTKAvEvG E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0AAMGegE6tJV2Y/2dsb2JhbABBmQqPB3iBUwEBAQECAQEBAQ8BHQo0CwUHBAIBCBEEAQEBCgYTBAEGASAGHwkIAQEEARIIEweHVgacMAGeEIYrYASHcpELhGyHOg X-IronPort-AV: E=Sophos;i="4.68,445,1312156800"; d="scan'208";a="24071123" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 26 Sep 2011 15:52:40 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8QFqdqa004307; Mon, 26 Sep 2011 15:52:39 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 10:52:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Sep 2011 10:52:38 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C060633BA@XMB-RCD-111.cisco.com> In-Reply-To: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] [BEHAVE] Last Call: (Dual Stack Hosts Using"Bump-in-the-Host" (BIH)) to Proposed Standard Thread-Index: Acx8XrGT3LPZ/umGSqyAQmFBTGHJTgAA3Z/w References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> From: "Rajiv Asati (rajiva)" To: , , X-OriginalArrivalTime: 26 Sep 2011 15:52:40.0006 (UTC) FILETIME=[51EE7E60:01CC7C64] Cc: softwires@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] [Softwires] Last Call: (Dual Stack Hosts Using"Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2011 15:50:01 -0000 > tunneling). It may be that the recommendation is specifically against > *stateful* double translation =20 That may be reasonable. And the document may reflect that. > > > IETF recommends using dual-stack or tunneling based solutions for > > > IPv6 transition and specifically recommends against deployments > > > utilizing double protocol translation. Use of BIH together with a > > > NAT64 is NOT RECOMMENDED [RFC6180]. =09 One could suggest rephrasing that para with something like this - This document doesn't recommend using BIH together with NAT64=20 [RFC6180]. Of course, the adoption of this or any solution (e.g dual-stack and/or any solution that eases the path to IPv6=20 (and accommodate residual IPv4)) would be subjected to the=20 overall cost-effectiveness, as determined by operators per their environments/constraints. Cheers, Rajiv > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf > Of teemu.savolainen@nokia.com > Sent: Monday, September 26, 2011 11:20 AM > To: satoru.matsushima@gmail.com; ietf@ietf.org > Cc: softwires@ietf.org; behave@ietf.org > Subject: Re: [Softwires] [BEHAVE] Last Call: 06.txt> (Dual Stack Hosts Using"Bump-in-the-Host" (BIH)) to Proposed Standard >=20 > Please note that this statement was included after quite long and heated > discussion in behave WG and because it came clear that IETF recommendation > is against double protocol translation (in favor of dual-stack and > tunneling). It may be that the recommendation is specifically against > *stateful* double translation (although that was not said aloud, if I recall > correctly).=09 >=20 > I would assume softwires follows these same IETF guidelines and therefore is > now focusing solely on stateless approaches(?). If the IETF opinion has > changed so that also stateful double translation solutions are now ok for > IETF, then that should perhaps be reflected in this document as well. >=20 > Unfortunately, I did not have chance to go to softwires interim, but please > let us know if the discussions there impact also the quoted recommendation. >=20 > Best regards, >=20 > Teemu >=20 > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of ext Satoru Matsushima > > Sent: 13. syyskuuta 2011 06:51 > > To: ietf@ietf.org > > Cc: behave@ietf.org; Satoru Matsushima > > Subject: Re: [BEHAVE] Last Call: (Dual > > Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard > > > > The introduction in the draft says: > > > > > > > IETF recommends using dual-stack or tunneling based solutions for > > > IPv6 transition and specifically recommends against deployments > > > utilizing double protocol translation. Use of BIH together with a > > > NAT64 is NOT RECOMMENDED [RFC6180].=09 > > > > > > > > > This statement makes a strong obstacle when we develop stateless solution > > with translation in softwires wg. > > I think that it is still remained a room to make decision whether removing > the > > statement or remaining it. > > The discussion which we'll have in the softwires interim meeting would be > > helpful to decide it. > > > > Best regards, > > --satoru > > > > > > > > On 2011/08/31, at 22:53, The IESG wrote: > > > > > > > > The IESG has received a request from the Behavior Engineering for > > > Hindrance Avoidance WG (behave) to consider the following document: > > > - 'Dual Stack Hosts Using "Bump-in-the-Host" (BIH)' > > > 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 2011-09-14. 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. > > > > > > Abstract > > > > > > > > > Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol > > > translation mechanism that allows a class of IPv4-only applications > > > that work through NATs to communicate with IPv6-only peers. The host > > > on which applications are running may be connected to IPv6-only or > > > dual-stack access networks. BIH hides IPv6 and makes the IPv4-only > > > applications think they are talking with IPv4 peers by local > > > synthesis of IPv4 addresses. This draft obsoletes RFC 2767 and RFC > > > 3338. > > > > > > > > > > > > > > > The file can be obtained via > > > http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ > > > > > > IESG discussion can be tracked via > > > http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ > > > > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > > _______________________________________________ > > > 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 C.Donley@cablelabs.com Mon Sep 26 10:53:27 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974821F0C51 for ; Mon, 26 Sep 2011 10:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.168 X-Spam-Level: X-Spam-Status: No, score=0.168 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLyUtm+e1X3v for ; Mon, 26 Sep 2011 10:53:26 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 80E9D1F0C4F for ; Mon, 26 Sep 2011 10:53:26 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p8QHu6nq015801; Mon, 26 Sep 2011 11:56:06 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 26 Sep 2011 11:56:06 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 26 Sep 2011 11:56:06 -0600 From: Chris Donley To: "Poscic, Kristian (Kristian)" , "mohamed.boucadair@orange.com" , "'behave@ietf.org'" Date: Mon, 26 Sep 2011 11:56:03 -0600 Thread-Topic: [BEHAVE] predictable translations Thread-Index: Acx8dZBE4v1iOZCYR2OjsHqh53Jj/g== Message-ID: In-Reply-To: <2073A6C5467C99478898544C6EBA3F4602BC3C82BF@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CAA6171B24580cdonleycablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: Re: [BEHAVE] predictable translations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2011 17:53:27 -0000 --_000_CAA6171B24580cdonleycablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Kris, We've been working on such an idea at CableLabs. I've been a little slow to= post. We're definitely interested in your feedback on our proposal. Chris A new version of I-D, draft-donley-behave-deterministic-cgn-00.txt has been= successfully submitted by Chris Donley and posted to the IETF repository. Filename: draft-donley-behave-deterministic-cgn Revision: 00 Title: Deterministic Address Mapping to Reduce Logging in Carrier Grade NA= Ts Creation date: 2011-09-26 WG ID: Individual Submission Number of pages: 9 Abstract: Many Carrier Grade NAT solutions require per-connection logging. Unfortunately, such logging is not scalable to many residential broadband services. This document suggests a way to manage Carrier Grade NAT translations in such a way as to significantly reduce the amount of logging required while providing traceability for abuse response. This method also provides a way of including geo-location significance in such assignments. The IETF Secretariat From: "Poscic, Kristian (Kristian)" > Date: Fri, 23 Sep 2011 10:21:13 -0600 To: "mohamed.boucadair@orange.com" >, "'behave@= ietf.org'" > Subject: Re: [BEHAVE] predictable translations Hi Med, By predictable translation I mean deterministic NAT. For now, I=92m just trying to evaluate (for my own sake) if this determinis= tic NAT makes any sense since 1) would take care of the concerns that I hav= e. If deterministic NAT makes deployable sense [for a reason that I yet nee= d to find, since 1) already takes care of my concerns], then I=92m trying t= o evaluate surrounding issues related to ease of integration into existing = OS (which it looks like does not come into play) and any other legal issue= s related to use of already possibly patented algorithms. Thanks, Kris From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Thursday, September 22, 2011 11:00 PM To: Poscic, Kristian (Kristian); 'behave@ietf.org' Subject: RE: predictable translations Dear Kris, Could please precise more what you mean by "predictable translation"? (1) Do you want to eliminate the volume of CGN logs (e.g, few entries per c= ustomer) or (2) you want to eliminate the CGN logging (e.g., rely on DHCP r= ecords)? (1) can be done in the CGN itself by design or configuration of the CGN to = use port ranges. This is already supported by CGN implementation including = A(..)U ;-) (2) can be supported only if you eliminate the NAT function in the CGN whic= h should be a PRR (Port Range Router; http://tools.ietf.org/html/draft-bouc= adair-port-range-02#section-6) instead. Cheers, Med ________________________________ De : behave-bounces@ietf.org [mailto:behave= -bounces@ietf.org] De la part de Poscic, Kristian (Kristian) Envoy=E9 : vendredi 23 septembre 2011 01:28 =C0 : 'behave@ietf.org' Objet : Re: [BEHAVE] predictable translations I looked at this draft draft-bsd-softwire-stateless-port-index-analysis-00<= http://datatracker.ietf.org/doc/draft-bsd-softwire-stateless-port-index-ana= lysis/> which examines 6 different algorithms for predictable translation a= pplicable to v4/v6 translation but I guess it can be potentially adopted fo= r v4 to v4 conversions as well. As my coworker (who is probably on this list) says =93too many deterministi= c nat drafts make for non-deterministic behaviours=94. Is there any plan to adopt one as a standard? Thanks, Kris From: Poscic, Kristian (Kristian) Sent: Thursday, September 22, 2011 11:57 AM To: behave@ietf.org Subject: predictable translations Hi there =96 Does anyone knows of any draft that is addressing a more predictable transl= ations between the inside IP and outside IP + port range when it comes to N= AT44. For example in order to avoid logging, IPv4 inside address would be automat= ically (via an algorithm) be converted to an outside IPv4 address + a port= range. This mapping would be unique so that no logging is required. The re= vertive algo would be able to convert the outside IP + port back to the in= side IP. I=92ve seen some drafts addressing something similar in the softwire WG but= they all deal with IPv4/IPv6 translations. Thanks, Kris --_000_CAA6171B24580cdonleycablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Kris,
We've been working on such an idea at CableLabs. I've = been a little slow to post. 

We're definitely interested in your feedback on our proposal= .

=
Chris

A new version of I-D, draft-do= nley-behave-deterministic-cgn-00.txt has been successfully submitted by Chr= is Donley and posted to the IETF repository.

Filename:  draft-donley-behave-deterministic-cgn
Revision:  00
Title:  Deterministic Addr= ess Mapping to Reduce Logging in Carrier Grade NATs
Creation date:  2011-09-26
WG ID:  Individual Submission
Number of pages= : 9

Abstract:
=
   Many= Carrier Grade NAT solutions require per-connection logging.
   Unfortunately= , such logging is not scalable to many residential
   broadband services.&nbs= p; This document suggests a way to manage Carrier
   Grade NAT translati= ons in such a way as to significantly reduce the
   amount of logging require= d while providing traceability for abuse
   response.  This method = also provides a way of including geo-location
   significance in such assignm= ents.


   &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   


The= IETF Secretariat

From: "Poscic, Kristian (Kristian)" <kristian.poscic@alcatel-lucent.= com>
Date: Fri, 23 Sep 2= 011 10:21:13 -0600
To: "mohamed.boucadair@orange.com<= /a>" <mohamed.bouca= dair@orange.com>, "'behave@= ietf.org'" <behave@ietf.org<= /a>>
Subject: Re: [BEHAVE] p= redictable translations

Hi Med,

By predictable translation I mean deterministic = NAT.

 

For now, I=92m just trying to evaluate (for my own sake) if this = deterministic NAT makes any sense since 1) would take care of the concerns = that I have. If deterministic NAT makes deployable sense [for a reason that= I yet need to find, since 1) already takes care of my concerns], then I=92= m trying to evaluate surrounding issues related to ease of integration into= existing OS  (which it looks like does not come into play) and any ot= her legal issues related to use of already possibly patented algorithms.

 

Thanks,

Kris

 

F= rom: mohamed.boucadair@o= range.com [mailto:moham= ed.boucadair@orange.com]
Sent: Thursday, September 22, 2011 = 11:00 PM
To: Poscic, Kristian (Kristian); 'behave@ietf.org'
Subject: RE: predictable trans= lations

 =

Dear Kris,

 

Could pl= ease precise more what you mean by "predictable translation"?

 

(1) Do you want to eliminate the volume of CGN logs (e.= g, few entries per customer) or (2) you want to eliminate the CGN logging (= e.g., rely on DHCP records)?

 

(1) can be done in= the CGN itself by design or configuration of the CGN to use port ranges. T= his is already supported by CGN implementation including A(..)U ;-)<= span style=3D"font-size: 12pt; font-family: 'Times New Roman', serif; ">

 

(2) can be supported only if you eliminate the NAT function= in the CGN which should be a PRR (Port Range Router; http://tools.ietf= .org/html/draft-boucadair-port-range-02#section-6) instead.

 

 

Cheers,=

Med

 

De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de Posci= c, Kristian (Kristian)
Envoy=E9 : vendredi 23 septembre 2011= 01:28
=C0 : 'behave@iet= f.org'
Objet : Re: [BEHAVE] predictable translations

I looked at this draft draft-bsd-softwire-stateless-port-index-analysis-00 which e= xamines 6 different algorithms for predictable translation applicable to v4= /v6 translation but I guess it can be potentially adopted for v4 to v4 conv= ersions as well.

 

As my coworker (who is probably on this list) say= s =93too many deterministic nat drafts make for non-dete= rministic behaviours=94.

Is= there any plan to adopt one as a standard?

Thanks,

 

From: Poscic, Kristian (Kristian)
S= ent: Thursday, September 22, 2011 11:57 AM
To: behave@ietf.org
Subject: predictable tra= nslations

&nbs= p;

Hi there =96

Does anyone knows of any draft that is addressing a more predict= able translations between the inside IP and outside IP + port range whe= n it comes to NAT44.

For example in or= der to avoid logging, IPv4 inside address would be automatically (via an al= gorithm) be converted to an outside IPv4 address  + a port range. = This mapping would be unique so that no logging is required. The revertive = algo would be able to convert the outside IP + port back  to the i= nside IP.

 

I=92ve seen some drafts addressing something similar in the= softwire WG but they all deal with IPv4/IPv6 translations.

<= p class=3D"MsoNormal">Thanks,

Kris

--_000_CAA6171B24580cdonleycablelabscom_-- From Tina.Tsou.Zouting@huawei.com Mon Sep 26 10:58:15 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94AD1F0C3C for ; Mon, 26 Sep 2011 10:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.267 X-Spam-Level: X-Spam-Status: No, score=-6.267 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upM7FLuB4aUT for ; Mon, 26 Sep 2011 10:58:12 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id EF3FF21F8D67 for ; Mon, 26 Sep 2011 10:58:11 -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 <0LS500EDU61IL1@szxga04-in.huawei.com> for behave@ietf.org; Tue, 27 Sep 2011 02:00:54 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS5006X661I2R@szxga04-in.huawei.com> for behave@ietf.org; Tue, 27 Sep 2011 02:00:54 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADX23519; Tue, 27 Sep 2011 02:00:53 +0800 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 27 Sep 2011 02:00:52 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.147]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0270.001; Tue, 27 Sep 2011 02:00:42 +0800 Date: Mon, 26 Sep 2011 18:00:41 +0000 From: Tina TSOU In-reply-to: X-Originating-IP: [10.193.34.158] To: Chris Donley , "Poscic, Kristian (Kristian)" , "mohamed.boucadair@orange.com" , "'behave@ietf.org'" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Aw3MQaxBYs9c0+ON5QDhUA)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: [BEHAVE] predictable translations Thread-index: Acx5WV97aAu68hVNTaay9qYQdmoSIAAJTlUgAA1r3VAAFchtkACJxZaAABDheKA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <2073A6C5467C99478898544C6EBA3F4602BC3C82BF@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> Subject: Re: [BEHAVE] predictable translations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2011 17:58:16 -0000 --Boundary_(ID_Aw3MQaxBYs9c0+ON5QDhUA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Chris, Does this draft work with http://tools.ietf.org/html/draft-tsou-behave-natx4-log-reduction-02 ? Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Chris Donley Sent: Monday, September 26, 2011 10:56 AM To: Poscic, Kristian (Kristian); mohamed.boucadair@orange.com; 'behave@ietf= .org' Subject: Re: [BEHAVE] predictable translations Kris, We've been working on such an idea at CableLabs. I've been a little slow to= post. We're definitely interested in your feedback on our proposal. Chris A new version of I-D, draft-donley-behave-deterministic-cgn-00.txt has been= successfully submitted by Chris Donley and posted to the IETF repository. Filename: draft-donley-behave-deterministic-cgn Revision: 00 Title: Deterministic Address Mapping to Reduce Logging in Carrier G= rade NATs Creation date: 2011-09-26 WG ID: Individual Submission Number of pages: 9 Abstract: Many Carrier Grade NAT solutions require per-connection logging. Unfortunately, such logging is not scalable to many residential broadband services. This document suggests a way to manage Carrier Grade NAT translations in such a way as to significantly reduce the amount of logging required while providing traceability for abuse response. This method also provides a way of including geo-location significance in such assignments. The IETF Secretariat From: "Poscic, Kristian (Kristian)" > Date: Fri, 23 Sep 2011 10:21:13 -0600 To: "mohamed.boucadair@orange.com" >, "'behave@= ietf.org'" > Subject: Re: [BEHAVE] predictable translations Hi Med, By predictable translation I mean deterministic NAT. For now, I'm just trying to evaluate (for my own sake) if this deterministi= c NAT makes any sense since 1) would take care of the concerns that I have.= If deterministic NAT makes deployable sense [for a reason that I yet need = to find, since 1) already takes care of my concerns], then I'm trying to ev= aluate surrounding issues related to ease of integration into existing OS = (which it looks like does not come into play) and any other legal issues re= lated to use of already possibly patented algorithms. Thanks, Kris From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Thursday, September 22, 2011 11:00 PM To: Poscic, Kristian (Kristian); 'behave@ietf.org' Subject: RE: predictable translations Dear Kris, Could please precise more what you mean by "predictable translation"? (1) Do you want to eliminate the volume of CGN logs (e.g, few entries per c= ustomer) or (2) you want to eliminate the CGN logging (e.g., rely on DHCP r= ecords)? (1) can be done in the CGN itself by design or configuration of the CGN to = use port ranges. This is already supported by CGN implementation including = A(..)U ;-) (2) can be supported only if you eliminate the NAT function in the CGN whic= h should be a PRR (Port Range Router; http://tools.ietf.org/html/draft-bouc= adair-port-range-02#section-6) instead. Cheers, Med ________________________________ De : behave-bounces@ietf.org [mailto:behave= -bounces@ietf.org] De la part de Poscic, Kristian (Kristian) Envoy=E9 : vendredi 23 septembre 2011 01:28 =C0 : 'behave@ietf.org' Objet : Re: [BEHAVE] predictable translations I looked at this draft draft-bsd-softwire-stateless-port-index-analysis-00<= http://datatracker.ietf.org/doc/draft-bsd-softwire-stateless-port-index-ana= lysis/> which examines 6 different algorithms for predictable translation a= pplicable to v4/v6 translation but I guess it can be potentially adopted fo= r v4 to v4 conversions as well. As my coworker (who is probably on this list) says "too many deterministic = nat drafts make for non-deterministic behaviours". Is there any plan to adopt one as a standard? Thanks, Kris From: Poscic, Kristian (Kristian) Sent: Thursday, September 22, 2011 11:57 AM To: behave@ietf.org Subject: predictable translations Hi there - Does anyone knows of any draft that is addressing a more predictable transl= ations between the inside IP and outside IP + port range when it comes to N= AT44. For example in order to avoid logging, IPv4 inside address would be automat= ically (via an algorithm) be converted to an outside IPv4 address + a port= range. This mapping would be unique so that no logging is required. The re= vertive algo would be able to convert the outside IP + port back to the in= side IP. I've seen some drafts addressing something similar in the softwire WG but t= hey all deal with IPv4/IPv6 translations. Thanks, Kris --Boundary_(ID_Aw3MQaxBYs9c0+ON5QDhUA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Chris,

Does this draft work with

http://tools.ietf.org/html/draft-tsou-behave-natx4-log-red= uction-02

?

 

Best Regards,

Tina TSOU

http://tinatsou.weebly.com/contact.html

 

From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Chris Donley
Sent: Monday, September 26, 2011 10:56 AM
To: Poscic, Kristian (Kristian); mohamed.boucadair@orange.com; 'beha= ve@ietf.org'
Subject: Re: [BEHAVE] predictable translations

 

Kris,

We've bee= n working on such an idea at CableLabs. I've been a little slow to post.&nb= sp;

&nbs= p;

We're def= initely interested in your feedback on our proposal.

&nbs= p;

Chris

&nbs= p;

A new ver= sion of I-D, draft-donley-behave-deterministic-cgn-00.txt has been successf= ully submitted by Chris Donley and posted to the IETF repository.

&nbs= p;

Filename:=  draft-donley-behave-deterministic-cgn=

Revision:=  00

Title:  &nb= sp;      Deterministic Address Mapping to Reduce Logging in Carr= ier Grade NATs

Creation = date:  2011-09-26

WG ID:  &nb= sp;      Individual Submission

Number of= pages: 9

&nbs= p;

Abstract:=

 &nb= sp; Many Carrier Grade NAT solutions require per-connection logging.

 &nb= sp; Unfortunately, such logging is not scalable to many residential

 &nb= sp; broadband services.  This document suggests a way to manage C= arrier

 &nb= sp; Grade NAT translations in such a way as to significantly reduce the

 &nb= sp; amount of logging required while providing traceability for abuse<= /o:p>

 &nb= sp; response.  This method also provides a way of including geo-l= ocation

 &nb= sp; significance in such assignments.

&nbs= p;

&nbs= p;

 &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;     

&nbs= p;

&nbs= p;

The IETF = Secretariat

 

 

Hi Med,

By predictable transla= tion I mean deterministic NAT.

 

For now, I’m jus= t trying to evaluate (for my own sake) if this deterministic NAT makes any = sense since 1) would take care of the concerns that I have. If deterministi= c NAT makes deployable sense [for a reason that I yet need to find, since 1) already takes care of my concerns], then= I’m trying to evaluate surrounding issues related to ease of integra= tion into existing OS  (which it looks like does not come into play) a= nd any other legal issues related to use of already possibly patented algorithms.

 

Thanks,

Kris

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Thursday, September 22, 2011 11:00 PM
To: Poscic, Kristian (Kristian); 'behave@ietf.org'
Subject: RE: predictable translations

 =

Dear Kris,

 

Could please precise more what you mean by &quo= t;predictable translation"?

 

(1) Do you want to eliminate the volume of CGN = logs (e.g, few entries per customer) or (2) you want to eliminate the CGN l= ogging (e.g., rely on DHCP records)?

 

(1) can be done in the CGN itself by design or = configuration of the CGN to use port ranges. This is already supported by C= GN implementation including A(..)U ;-)

 

(2) can be supported only if you eliminate the = NAT function in the CGN which should be a PRR (Port Range Router; http://tools.ietf.org/html/draft-boucadair-port-range-02#section-6)= instead.

 

 

Cheers,=

Med

 

De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de Poscic, Kristian (Kristian)
Envoy=E9 : vendredi 23 septembre 2011 01:28
=C0 : 'behave@ietf.org'=
Objet : Re: [BEHAVE] predictable translations

I looked at this draft= draft-bsd-softwire-stateless-port-index-analysis-0= 0 which examines 6 different algorithms for predictable translation applicab= le to v4/v6 translation but I guess it can be potentially adopted for v4 to= v4 conversions as well.

 <= /o:p>

As my coworker (who is probably on this list) says = 220;too many deterministic nat drafts make for non-deterministic behaviours”= .

Is there any plan to adopt on= e as a standard?

Thanks,

Kris

 

From: Poscic, Kristian (Kristian)
Sent: Thursday, September 22, 2011 11:57 AM
To: behave@ietf.org
Subject: predictable translations=

 =

Hi there –

Does anyone knows of any= draft that is addressing a more predictable translations between the insid= e IP and outside IP + port range when it comes to NAT44.

For example in order to = avoid logging, IPv4 inside address would be automatically (via an algorithm= ) be converted to an outside IPv4 address  + a port range. This ma= pping would be unique so that no logging is required. The revertive algo would be able to convert the outside IP + port back=  to the inside IP.

 =

I’ve seen some dra= fts addressing something similar in the softwire WG but they all deal with = IPv4/IPv6 translations.

Thanks,

Kris <= /p>

--Boundary_(ID_Aw3MQaxBYs9c0+ON5QDhUA)-- From dwing@cisco.com Mon Sep 26 11:37:09 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E29B21F8C85 for ; Mon, 26 Sep 2011 11:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.118 X-Spam-Level: X-Spam-Status: No, score=-103.118 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lEME32NoYPb for ; Mon, 26 Sep 2011 11:37:08 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id B1C9721F8C6C for ; Mon, 26 Sep 2011 11:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4029; q=dns/txt; s=iport; t=1317062392; x=1318271992; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=goofpTu+IuOwh50aJTfattieq7Q3jqpLoLwZ6NEZv5o=; b=UDU8ZdmVOUkeRcmt8tB+KQsjzcP+sreE7VN0FH0Nb4fUMcjf4rnCtGZ3 QE9irnxJiM9Gu0L7uaMd74Q7cQF4egND/YZJM2CAKdXCjkTtvFPpTFHfS 1BBR6FmGkQ9q22h7p2R5LgbR2j+VOwo6COKXRMKkymIRr1tAWQSScaeOg A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0AALXFgE6rRDoJ/2dsb2JhbABCmQyBbI0beIFTAQEBAQIBCAoBFxBEBwEDAgkPAgQBASgHGSMKCQgBAQQBEgsQB4dWnFYBnimHCwSHcp0z X-IronPort-AV: E=Sophos;i="4.68,445,1312156800"; d="scan'208";a="4387359" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 26 Sep 2011 18:39:51 +0000 Received: from dwingWS ([10.89.10.9]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8QIdo8N024473; Mon, 26 Sep 2011 18:39:51 GMT From: "Dan Wing" To: "'Poscic, Kristian \(Kristian\)'" , References: <2073A6C5467C99478898544C6EBA3F4602BC3C8163@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <088401cc79b1$194de790$4be9b6b0$@com> <2073A6C5467C99478898544C6EBA3F4602BC3C8266@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <089801cc79b4$44e03400$cea09c00$@com> <2073A6C5467C99478898544C6EBA3F4602BC3C82B5@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> In-Reply-To: <2073A6C5467C99478898544C6EBA3F4602BC3C82B5@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> Date: Mon, 26 Sep 2011 11:39:50 -0700 Message-ID: <066101cc7c7b$ad3efdf0$07bcf9d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acx5WV97aAu68hVNTaay9qYQdmoSIAAV4bjAAAA4URAAAHQNsAAVyhmwAJw3iMA= Content-Language: en-us Subject: Re: [BEHAVE] predictable translations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2011 18:37:09 -0000 > -----Original Message----- > From: Poscic, Kristian (Kristian) [mailto:kristian.poscic@alcatel- > lucent.com] > Sent: Friday, September 23, 2011 9:11 AM > To: Dan Wing; behave@ietf.org > Subject: RE: [BEHAVE] predictable translations > > Ok, so you're saying that the backward conversion must be limited to > the NAT device itself. In other words one would via CLI 'show/display' > commands on the NAT device enter the outside IP + port and the output > would be the inside IP. Of course the NMS could also query the NAT > device remotely. But there would be no external systems (back-end) that > would be running the algorithm so do this conversion. Ok, makes sense. Yes, I'm saying it's entirely the ISP's responsibility for how that translation happens. -d > Thanks, > Kris > > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Thursday, September 22, 2011 10:47 PM > To: Poscic, Kristian (Kristian); behave@ietf.org > Subject: RE: [BEHAVE] predictable translations > > > -----Original Message----- > > From: Poscic, Kristian (Kristian) [mailto:kristian.poscic@alcatel- > > lucent.com] > > Sent: Thursday, September 22, 2011 10:37 PM > > To: Dan Wing; behave@ietf.org > > Subject: RE: [BEHAVE] predictable translations > > > > In my opinion two points: > > - if this is implemented to eliminate logging then there must be > > systems that do reverse conversion to find out who do original user > > was. It would make more sense that that systems doing the reverse > > conversion uses common (standardized) algorithm. Otherwise this > > solution will be very vendor specific and customers will be tied into > > vendor specific version of the algo. > > It's not possible to accomplish that, unless there is guarantee / > assurance that the subscriber's address (assigned to their CPE) > did not also change. A+P/dIVI/4rd can't guarantee that. Only > the ISP can do that with the combination of its knowledge of > what address it assigned to the CPE and how its address sharing > device was configured on that particular day. Consider, for > example, a Tuesday night where users are changed from 300 ports > to 200 ports. Only the ISP is aware of that change and when > that change occurred. An entity on the Internet won't be > aware. > > I don't see how the requirement you're stating can be met. > > > - other potential issues are legal issues with patents, etc. > > -d > > > Kris > > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Thursday, September 22, 2011 10:25 PM > > To: Poscic, Kristian (Kristian); behave@ietf.org > > Subject: RE: [BEHAVE] predictable translations > > > > > -----Original Message----- > > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > > Behalf Of Poscic, Kristian (Kristian) > > > Sent: Thursday, September 22, 2011 11:57 AM > > > To: behave@ietf.org > > > Subject: [BEHAVE] predictable translations > > > > > > Hi there - > > > > > > Does anyone knows of any draft that is addressing a more > predictable > > > translations between the inside IP and outside IP + port range when > > it > > > comes to NAT44. > > > > > > For example in order to avoid logging, IPv4 inside address would be > > > automatically (via an algorithm) be converted to an outside IPv4 > > > address + a port range. This mapping would be unique so that no > > > logging is required. The revertive algo would be able to convert > the > > > outside IP + port back to the inside IP. > > > > Sure, a NAT could be built that does exactly that. Some vendors > > have been doing exactly that, or something very similar. > > > > How does the IETF fit into that, though? That is, why is a standard > > necessary? > > > > -d > > > > > > > > > > > > > I've seen some drafts addressing something similar in the softwire > WG > > > but they all deal with IPv4/IPv6 translations. > > > > > > Thanks, > > > > > > Kris From C.Donley@cablelabs.com Mon Sep 26 11:43:25 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C8A21F8E17 for ; Mon, 26 Sep 2011 11:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.078 X-Spam-Level: X-Spam-Status: No, score=0.078 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Bkz3qIv+f3X for ; Mon, 26 Sep 2011 11:43:18 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA2C21F8E16 for ; Mon, 26 Sep 2011 11:43:18 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p8QIjOGY021759; Mon, 26 Sep 2011 12:45:24 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 26 Sep 2011 12:45:24 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 26 Sep 2011 12:45:25 -0600 From: Chris Donley To: Tina TSOU , "Poscic, Kristian (Kristian)" , "mohamed.boucadair@orange.com" , "'behave@ietf.org'" Date: Mon, 26 Sep 2011 12:45:20 -0600 Thread-Topic: [BEHAVE] predictable translations Thread-Index: Acx8fHNnFxGJWsgAT0O7RKMBA3Y2kg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CAA623B0245A2cdonleycablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: Re: [BEHAVE] predictable translations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2011 18:43:25 -0000 --_000_CAA623B0245A2cdonleycablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Tina, Yes, this draft makes use of bulk port assignments once a user exceeds the = deterministic port range. We view your draft as a component of a determinis= tic NAT. Chris From: Tina TSOU > Date: Mon, 26 Sep 2011 12:00:41 -0600 To: Chris Donley >, "= Poscic, Kristian (Kristian)" >, "mohamed.boucadair@orange.com" >, "'behave@ietf.org'" > Subject: RE: [BEHAVE] predictable translations Chris, Does this draft work with http://tools.ietf.org/html/draft-tsou-behave-natx4-log-reduction-02 ? Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: behave-bounces@ietf.org [mailto:behav= e-bounces@ietf.org] On Behalf Of Chris Donley Sent: Monday, September 26, 2011 10:56 AM To: Poscic, Kristian (Kristian); mohamed.boucadair@orange.com; 'behave@ietf.org' Subject: Re: [BEHAVE] predictable translations Kris, We've been working on such an idea at CableLabs. I've been a little slow to= post. We're definitely interested in your feedback on our proposal. Chris A new version of I-D, draft-donley-behave-deterministic-cgn-00.txt has been= successfully submitted by Chris Donley and posted to the IETF repository. Filename: draft-donley-behave-deterministic-cgn Revision: 00 Title: Deterministic Address Mapping to Reduce Logging in Carrier G= rade NATs Creation date: 2011-09-26 WG ID: Individual Submission Number of pages: 9 Abstract: Many Carrier Grade NAT solutions require per-connection logging. Unfortunately, such logging is not scalable to many residential broadband services. This document suggests a way to manage Carrier Grade NAT translations in such a way as to significantly reduce the amount of logging required while providing traceability for abuse response. This method also provides a way of including geo-location significance in such assignments. The IETF Secretariat From: "Poscic, Kristian (Kristian)" > Date: Fri, 23 Sep 2011 10:21:13 -0600 To: "mohamed.boucadair@orange.com" >, "'behave@= ietf.org'" > Subject: Re: [BEHAVE] predictable translations Hi Med, By predictable translation I mean deterministic NAT. For now, I=92m just trying to evaluate (for my own sake) if this determinis= tic NAT makes any sense since 1) would take care of the concerns that I hav= e. If deterministic NAT makes deployable sense [for a reason that I yet nee= d to find, since 1) already takes care of my concerns], then I=92m trying t= o evaluate surrounding issues related to ease of integration into existing = OS (which it looks like does not come into play) and any other legal issue= s related to use of already possibly patented algorithms. Thanks, Kris From:mohamed.boucadair@orange.com [mai= lto:mohamed.boucadair@orange.com] Sent: Thursday, September 22, 2011 11:00 PM To: Poscic, Kristian (Kristian); 'behave@ietf.org' Subject: RE: predictable translations Dear Kris, Could please precise more what you mean by "predictable translation"? (1) Do you want to eliminate the volume of CGN logs (e.g, few entries per c= ustomer) or (2) you want to eliminate the CGN logging (e.g., rely on DHCP r= ecords)? (1) can be done in the CGN itself by design or configuration of the CGN to = use port ranges. This is already supported by CGN implementation including = A(..)U ;-) (2) can be supported only if you eliminate the NAT function in the CGN whic= h should be a PRR (Port Range Router; http://tools.ietf.org/html/draft-bouc= adair-port-range-02#section-6) instead. Cheers, Med ________________________________ De :behave-bounces@ietf.org [mailto:behave-= bounces@ietf.org] De la part de Poscic, Kristian (Kristian) Envoy=E9 : vendredi 23 septembre 2011 01:28 =C0 : 'behave@ietf.org' Objet : Re: [BEHAVE] predictable translations I looked at this draft draft-bsd-softwire-stateless-port-index-analysis-00<= http://datatracker.ietf.org/doc/draft-bsd-softwire-stateless-port-index-ana= lysis/> which examines 6 different algorithms for predictable translation a= pplicable to v4/v6 translation but I guess it can be potentially adopted fo= r v4 to v4 conversions as well. As my coworker (who is probably on this list) says =93too many deterministi= c nat drafts make for non-deterministic behaviours=94. Is there any plan to adopt one as a standard? Thanks, Kris From: Poscic, Kristian (Kristian) Sent: Thursday, September 22, 2011 11:57 AM To: behave@ietf.org Subject: predictable translations Hi there =96 Does anyone knows of any draft that is addressing a more predictable transl= ations between the inside IP and outside IP + port range when it comes to N= AT44. For example in order to avoid logging, IPv4 inside address would be automat= ically (via an algorithm) be converted to an outside IPv4 address + a port= range. This mapping would be unique so that no logging is required. The re= vertive algo would be able to convert the outside IP + port back to the in= side IP. I=92ve seen some drafts addressing something similar in the softwire WG but= they all deal with IPv4/IPv6 translations. Thanks, Kris --_000_CAA623B0245A2cdonleycablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Tina,

= Yes, this draft makes use of bulk port assignments once a user exceeds the = deterministic port range. We view your draft as a component of a determinis= tic NAT.

Chris

From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
Date: Mon, 26 Sep 2011 12:00:41 -0600
To: Chris Donley <c.donley@cablelabs.com>, "Poscic, Kris= tian (Kristian)" <kristian.poscic@alcatel-lucent.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "'behave@ietf.org'"= ; <behave@ietf.org>
Subject: RE: [BEHAVE] predictable transla= tions

Chris,

Does this draft work= with

http://tools.ietf.org/html/draft-tso= u-behave-natx4-log-reduction-02

?=

 =

Best Regards,

Tina TSOU

http://tinatsou.= weebly.com/contact.html

&nb= sp;

From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org= ] On Behalf Of Chris Donley
Sent: Monday, September 26= , 2011 10:56 AM
To: Poscic, Kristian (Kristian); mohamed.boucadair@orange.com; 'behave@ietf.org'
Subject: Re: [= BEHAVE] predictable translations

 

Kris,

=

We've bee= n working on such an idea at CableLabs. I've been a little slow to post.&nb= sp;

 

We're definitely = interested in your feedback on our proposal.

&n= bsp;

Chris

 

A new version of I-D, draft-donley-behave-deterministic-cgn-00.txt h= as been successfully submitted by Chris Donley and posted to the IETF repository.

 

=

File= name:=  draft-donley-behave-deterministic-cgn

R= evision: 00

<= span style=3D"font-size:13.5pt;font-family:Consolas;mso-fareast-font-family= :"Times New Roman";color:black">Title:      &nb= sp;  Deterministic Address Mapping to Reduce Logging in Carr= ier Grade NATs

Creation date: 2011-09-26=

WG ID:         Individual Submission

<= p class=3D"MsoNormal">Number of = pages: 9

 

Abstract:

   Many Carrier Grade NAT solutions require p= er-connection logging.

   Unfortunately, s= uch logging is not scalable to many residential

=

&nbs= p;  broadband services.  This document suggests a way to man= age Carrier

   Grade NAT translations in s= uch a way as to significantly reduce the

  = ; amount of logging required while providing traceability for abuse

   response.  This method also provides= a way of including geo-location

   sign= ificance in such assignments.

 

 

      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;

 

 

The IETF Secretariat

 

&= nbsp;

Hi Med,

By predictable t= ranslation I mean deterministic NAT.

&nbs= p;

For now, I=92m just trying to evaluate= (for my own sake) if this deterministic NAT makes any sense since 1) would= take care of the concerns that I have. If deterministic NAT makes deployab= le sense [for a reason that I yet need to find, since 1) already takes care of my concerns], then= I=92m trying to evaluate surrounding issues related to ease of integration= into existing OS  (which it looks like does not come into play) and a= ny other legal issues related to use of already possibly patented algorithms.

&n= bsp;

Thanks,

Kris

 

From:m= ohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Thursday, September 22, 2011 11:00 PM
To: Poscic= , Kristian (Kristian); 'behave@ietf.org= '
Subject: RE: predictable translations

 

<= span style=3D"font-size: 10pt; color: blue; font-family: 'Courier New'; ">D= ear Kris,

 

Could please precise more what you me= an by "predictable translation"?

 

(1) D= o you want to eliminate the volume of CGN logs (e.g, few entries per custom= er) or (2) you want to eliminate the CGN logging (e.g., rely on DHCP r= ecords)?

 

(1) can be done in the CGN itself by = design or configuration of the CGN to use port ranges. This is already supp= orted by CGN implementation including A(..)U ;-)

 

(2) can be supported only if you eliminate the NAT function in the CGN whi= ch should be a PRR (Port Range Router; http://tools.ietf.org/html/draft-boucadair-port-range-02#section-6)= instead.

 

 

Cheers,

Med

 

=

De :behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de Poscic, Kristian (Kristian)
Envoy=E9 : = vendredi 23 septembre 2011 01:28
=C0 : 'behave@ietf.org'
Objet : Re: [BEHAVE] pr= edictable translations=

I looked at this d= raft draft-bsd-softwire-= stateless-port-index-analysis-00 which examines 6 different algorithms for predictable translation applicab= le to v4/v6 translation but I guess it can be potentially adopted for v4 to= v4 conversions as well.

 <= /span>

As my coworker (who is probably on this list) = says =93too many deterministic nat drafts make for non-deterministic behaviours=94.

Is there any plan to adopt one as a standard?

Thanks,

= Kris

 

From: Poscic, Kristian (Kristian)
Sent: Thursday, September 22, 2011 11:57 AM
To: behave@ietf.org
Subject: predict= able translations

<= /div>

 

Hi there = =96

Does anyone knows of any draft that is addressing a more predictable tran= slations between the inside IP and outside IP + port range when it come= s to NAT44.

For example in order to avoid logging, IPv4 inside address would b= e automatically (via an algorithm) be converted to an outside IPv4 address =  + a port range. This mapping would be unique so that no logging i= s required. The revertive algo would be able to convert the outside IP + port back=  to the inside IP.

 

I=92ve seen some drafts addressing something simi= lar in the softwire WG but they all deal with IPv4/IPv6 translations.<= /o:p>

Thanks,<= o:p>

Kri= s

--_000_CAA623B0245A2cdonleycablelabscom_-- From kristian.poscic@alcatel-lucent.com Mon Sep 26 12:16:37 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F9E1F0C4D for ; Mon, 26 Sep 2011 12:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sG-5I0DKo8T for ; Mon, 26 Sep 2011 12:16:33 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 96B1D1F0C35 for ; Mon, 26 Sep 2011 12:16:33 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p8QJJDUD013529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2011 14:19:13 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p8QJJBqZ022275 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 26 Sep 2011 14:19:13 -0500 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.139]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Mon, 26 Sep 2011 14:19:11 -0500 From: "Poscic, Kristian (Kristian)" To: Chris Donley , "mohamed.boucadair@orange.com" , "'behave@ietf.org'" Date: Mon, 26 Sep 2011 14:18:54 -0500 Thread-Topic: [BEHAVE] predictable translations Thread-Index: Acx8dZBE4v1iOZCYR2OjsHqh53Jj/gACBjZw Message-ID: <2073A6C5467C99478898544C6EBA3F4602BC3C85BF@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> References: <2073A6C5467C99478898544C6EBA3F4602BC3C82BF@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2073A6C5467C99478898544C6EBA3F4602BC3C85BFUSNAVSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [BEHAVE] predictable translations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2011 19:16:37 -0000 --_000_2073A6C5467C99478898544C6EBA3F4602BC3C85BFUSNAVSXCHMBSC_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Chris! I was wondering how would one extend the port-block in deterministic-CGN fo= r an inside IP address if all the ports in the originally assigned port-blo= ck are exhausted. It looks like that you combined deterministic NAT with the dynamic port ass= ignment through the D variable, which I think is a good compromise. As I understand In you example, you eliminated inside addresses 192.168.0.0= and 192.168.0.15 from the range 192.168.0.0/28, and in essence allocated t= heir share of outside ports via the D factor to the dynamic allocation. Nic= e. A few questions: - Do you always assume that the 0 and bcast host part of the insid= e IP address range is automatically excluded from 'I'? - You mentioned on page 4, point 2 in the last sentence: " Subscri= bers could be restricted to ports from a single IPv4 address, or could be a= llocated ports across all addresses in a pool, for example". Do you mean th= at this can be done in a deterministic fashion? In other words, can an ins= ide IP address spawn more outside IP addresses in a deterministic fashion (= along with outside port ranges)? - It is up to the vendor to figure out how will ports be assigned = (in block, staggered fashion, etc). There are requirements out there that t= he ISPs run the algorithm on external nodes to do to reverse conversions. S= o this inconsistency will make life for ISP little bit more difficult, but = I guess as people mentioned here, we can't mandate the details of the algor= ithm to the vendors. - I know that this is the first version of the draft, but in the f= uture maybe you can mention load balancing across the modules performing th= e NAT function in the system and if there is anything in particular that yo= u had in mind about this... Thanks, Kris From: Chris Donley [mailto:C.Donley@cablelabs.com] Sent: Monday, September 26, 2011 10:56 AM To: Poscic, Kristian (Kristian); mohamed.boucadair@orange.com; 'behave@ietf= .org' Subject: Re: [BEHAVE] predictable translations Kris, We've been working on such an idea at CableLabs. I've been a little slow to= post. We're definitely interested in your feedback on our proposal. Chris A new version of I-D, draft-donley-behave-deterministic-cgn-00.txt has been= successfully submitted by Chris Donley and posted to the IETF repository. Filename: draft-donley-behave-deterministic-cgn Revision: 00 Title: Deterministic Address Mapping to Reduce Logging in Carrier G= rade NATs Creation date: 2011-09-26 WG ID: Individual Submission Number of pages: 9 Abstract: Many Carrier Grade NAT solutions require per-connection logging. Unfortunately, such logging is not scalable to many residential broadband services. This document suggests a way to manage Carrier Grade NAT translations in such a way as to significantly reduce the amount of logging required while providing traceability for abuse response. This method also provides a way of including geo-location significance in such assignments. The IETF Secretariat From: "Poscic, Kristian (Kristian)" > Date: Fri, 23 Sep 2011 10:21:13 -0600 To: "mohamed.boucadair@orange.com" >, "'behave@= ietf.org'" > Subject: Re: [BEHAVE] predictable translations Hi Med, By predictable translation I mean deterministic NAT. For now, I'm just trying to evaluate (for my own sake) if this deterministi= c NAT makes any sense since 1) would take care of the concerns that I have.= If deterministic NAT makes deployable sense [for a reason that I yet need = to find, since 1) already takes care of my concerns], then I'm trying to ev= aluate surrounding issues related to ease of integration into existing OS = (which it looks like does not come into play) and any other legal issues re= lated to use of already possibly patented algorithms. Thanks, Kris From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Thursday, September 22, 2011 11:00 PM To: Poscic, Kristian (Kristian); 'behave@ietf.org' Subject: RE: predictable translations Dear Kris, Could please precise more what you mean by "predictable translation"? (1) Do you want to eliminate the volume of CGN logs (e.g, few entries per c= ustomer) or (2) you want to eliminate the CGN logging (e.g., rely on DHCP r= ecords)? (1) can be done in the CGN itself by design or configuration of the CGN to = use port ranges. This is already supported by CGN implementation including = A(..)U ;-) (2) can be supported only if you eliminate the NAT function in the CGN whic= h should be a PRR (Port Range Router; http://tools.ietf.org/html/draft-bouc= adair-port-range-02#section-6) instead. Cheers, Med ________________________________ De : behave-bounces@ietf.org [mailto:behave= -bounces@ietf.org] De la part de Poscic, Kristian (Kristian) Envoy=E9 : vendredi 23 septembre 2011 01:28 =C0 : 'behave@ietf.org' Objet : Re: [BEHAVE] predictable translations I looked at this draft draft-bsd-softwire-stateless-port-index-analysis-00<= http://datatracker.ietf.org/doc/draft-bsd-softwire-stateless-port-index-ana= lysis/> which examines 6 different algorithms for predictable translation a= pplicable to v4/v6 translation but I guess it can be potentially adopted fo= r v4 to v4 conversions as well. As my coworker (who is probably on this list) says "too many deterministic = nat drafts make for non-deterministic behaviours". Is there any plan to adopt one as a standard? Thanks, Kris From: Poscic, Kristian (Kristian) Sent: Thursday, September 22, 2011 11:57 AM To: behave@ietf.org Subject: predictable translations Hi there - Does anyone knows of any draft that is addressing a more predictable transl= ations between the inside IP and outside IP + port range when it comes to N= AT44. For example in order to avoid logging, IPv4 inside address would be automat= ically (via an algorithm) be converted to an outside IPv4 address + a port= range. This mapping would be unique so that no logging is required. The re= vertive algo would be able to convert the outside IP + port back to the in= side IP. I've seen some drafts addressing something similar in the softwire WG but t= hey all deal with IPv4/IPv6 translations. Thanks, Kris --_000_2073A6C5467C99478898544C6EBA3F4602BC3C85BFUSNAVSXCHMBSC_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks Chris!

I was wondering how would one = extend the port-block in deterministic-CGN for an inside IP address if all = the ports in the originally assigned port-block are exhausted.

It looks like t= hat you combined deterministic NAT with the dynamic port assignment through= the D variable, which I think is a good compromise.

=

 =

As I understand In y= ou example, you eliminated inside addresses 192.168.0.0 and 192.168.0.15 fr= om the range 192.168.0.0/28, and in essence allocated their share of outsid= e ports via the D factor to the dynamic allocation. Nice.=

 

A few questions:=

-          Do you always assume that t= he 0 and bcast host part of the inside IP address range is automatically ex= cluded from ‘I’?

-      &nbs= p;   You mentioned on page 4, point 2 in the last sentence: “ Subscribers= could be restricted to ports from a single IPv4 address, or could be alloc= ated ports across all addresses in a pool, for example”. Do you mean = that this can be done in=A0 a deterministic fashion? In other words, can an= inside IP address spawn more outside IP addresses in a deterministic fashi= on (along with outside port ranges)?

-     &n= bsp;    It is up to the vendor to figure out how will ports be assigned (i= n block, staggered fashion, etc). There are requirements out there that the= ISPs run the algorithm on external nodes to do to reverse conversions. So = this inconsistency will make life for ISP little bit more difficult, but I = guess as people mentioned here, we can’t mandate the details of the a= lgorithm to the vendors.

-       &n= bsp;  I k= now that this is the first version of the draft, but in the future maybe yo= u can mention load balancing across the modules performing the NAT function= in the system and if there is anything in particular that you had in mind = about this…

 

Thanks,

Kris =A0

=  

 

 

 

From: Chris Donley [mailto:C.Donley@cablelabs.= com]
Sent: Monday, September 26, 2011 10:56 AM
To: Pos= cic, Kristian (Kristian); mohamed.boucadair@orange.com; 'behave@ietf.org'Subject: Re: [BEHAVE] predictable translations

 

Kris,

We've been working o= n such an idea at CableLabs. I've been a little slow to post. 

 

We're definitely interested in your feedback on our proposal.<= o:p>

 

Chris

=  

A new version of I-D, draft-d= onley-behave-deterministic-cgn-00.txt has been successfully submitted by Ch= ris Donley and posted to the IETF repository.

 

= Filename:=  draft-donley-behave-deterministi= c-cgn

Revision:  00

T= itle:=A0=A0=A0=A0=A0=A0=A0  Determ= inistic Address Mapping to Reduce Logging in Carrier Grade NATs<= /span>

Creation date:  2011-09-26

WG ID= :=A0=A0=A0=A0=A0=A0=A0  Individual= Submission

Number of pages: 9<= o:p>

 

Abstract:

&= nbsp;  Many Carrier Grade NAT solutions require per-connection logging= .

   Unfortunately, s= uch logging is not scalable to many residential

=

   broadband services.  This document = suggests a way to manage Carrier

   Grade NAT translations in such a way as to significantly r= educe the

   amount = of logging required while providing traceability for abuse

   response.  This method a= lso provides a way of including geo-location

   significance in such assignments.

 

 

   =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =     

&= nbsp;

 

The IETF Secretariat

=

 

From: "Poscic,= Kristian (Kristian)" <kristian.poscic@alcatel-lucent.com>
Date: Fri, 2= 3 Sep 2011 10:21:13 -0600
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, &q= uot;'behave@ietf.org'" <behave@ietf.org>
Subject: = Re: [BEHAVE] predictable translations

 

Hi Med,

By predictable translation I= mean deterministic NAT.

 

For now, I’m just trying to evaluate (for my own= sake) if this deterministic NAT makes any sense since 1) would take care o= f the concerns that I have. If deterministic NAT makes deployable sense [fo= r a reason that I yet need to find, since 1) already takes care of my conce= rns], then I’m trying to evaluate surrounding issues related to ease = of integration into existing OS  (which it looks like does not come in= to play) and any other legal issues related to use of already possibly pate= nted algorithms.

 

Thanks,=

Kris

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@= orange.com]
Sent: Thursday, September 22, 2011 11:00 PM
<= b>To: Poscic, Kristian (Kristian); = 'behave@ietf.org'
Subject: RE: predictable translations

 

Dear Kris,

=

 =

Could please precise more what you mean by= "predictable translation"?

 

(1) Do you want to elim= inate the volume of CGN logs (e.g, few entries per customer) or (2) you wan= t to eliminate the CGN logging (e.g., rely on DHCP records)?

 

(1) can be done in the CGN itself by design or configuration of the CG= N to use port ranges. This is already supported by CGN implementation inclu= ding A(..)U ;-)

 

(2) can be supported only if you eliminate th= e NAT function in the CGN which should be a PRR (Port Range Router; htt= p://tools.ietf.org/html/draft-boucadair-port-range-02#section-6) instea= d.

 

 

Cheers,

Med

 

De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part = de Poscic, Kristian (Kristian)
Envoy=E9 : vendredi 23 se= ptembre 2011 01:28
=C0 : 'behave@ietf.org'
Objet : Re: [BEHAVE] predictable tran= slations

I looked at this draft draft-b= sd-softwire-stateless-port-index-analysis-00 which examines 6 different= algorithms for predictable translation applicable to v4/v6 translation but= I guess it can be potentially adopted for v4 to v4 conversions as well.

 

<= span class=3Dapple-style-span>As my coworker (who is pr= obably on this list) says “too many deterministic na= t drafts make for non-deterministic behaviours”.

Is there any= plan to adopt one as a standard?

Thanks,

Kris

 <= /p>

From: Poscic, K= ristian (Kristian)
Sent: Thursday, September 22, 2011 11:57 AMTo: behave@ietf.org
S= ubject: predictable translations

 

Hi there –

Does anyone knows of any draft that is addressing a more= predictable translations between the inside IP and outside IP + port range= when it comes to NAT44.

For example in order to avoid logging, IPv4 inside addr= ess would be automatically (via an algorithm) be converted to an outside IP= v4 address  + a port range. This mapping would be unique so that no lo= gging is required. The revertive algo would be able to convert the outside = IP + port back  to the inside IP.

 

I’ve seen some drafts addressing = something similar in the softwire WG but they all deal with IPv4/IPv6 trans= lations.

Thanks,

Kris

= --_000_2073A6C5467C99478898544C6EBA3F4602BC3C85BFUSNAVSXCHMBSC_-- From C.Donley@cablelabs.com Mon Sep 26 12:49:49 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0563A1F0CC8 for ; Mon, 26 Sep 2011 12:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.011 X-Spam-Level: X-Spam-Status: No, score=0.011 tagged_above=-999 required=5 tests=[AWL=0.473, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7NndY90J2Qw for ; Mon, 26 Sep 2011 12:49:47 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 865681F0CC1 for ; Mon, 26 Sep 2011 12:49:47 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p8QJqRFi029969; Mon, 26 Sep 2011 13:52:27 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 26 Sep 2011 13:52:27 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 26 Sep 2011 13:52:27 -0600 From: Chris Donley To: "Poscic, Kristian (Kristian)" , "mohamed.boucadair@orange.com" , "'behave@ietf.org'" Date: Mon, 26 Sep 2011 13:52:24 -0600 Thread-Topic: [BEHAVE] predictable translations Thread-Index: Acx8hdEuSN0kAh9tQAWm0444eDYjTg== Message-ID: In-Reply-To: <2073A6C5467C99478898544C6EBA3F4602BC3C85BF@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CAA62F0A245E8cdonleycablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: Re: [BEHAVE] predictable translations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2011 19:49:49 -0000 --_000_CAA62F0A245E8cdonleycablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Kris, Please see in-line. Chris From: "Poscic, Kristian (Kristian)" > Date: Mon, 26 Sep 2011 13:18:54 -0600 To: Chris Donley >, "= mohamed.boucadair@orange.com" >, "'behave@ietf.= org'" > Subject: RE: [BEHAVE] predictable translations Thanks Chris! I was wondering how would one extend the port-block in deterministic-CGN fo= r an inside IP address if all the ports in the originally assigned port-blo= ck are exhausted. It looks like that you combined deterministic NAT with the dynamic port ass= ignment through the D variable, which I think is a good compromise. As I understand In you example, you eliminated inside addresses 192.168.0.0= and 192.168.0.15 from the range 192.168.0.0/28, and in essence allocated t= heir share of outside ports via the D factor to the dynamic allocation. Nic= e. A few questions: - Do you always assume that the 0 and bcast host part of the insid= e IP address range is automatically excluded from =91I=92? I suppose that it could go either way, but in our analysis, we think ISPs w= ill deploy CGNs in such a way as to not allocate the network/bcast addresse= s to subscribers. YMMV, and it would be up to CGN vendors and ISPs to decid= e whether to include them, or whether there were additional addresses to ex= clude. - You mentioned on page 4, point 2 in the last sentence: =93 Subsc= ribers could be restricted to ports from a single IPv4 address, or could be= allocated ports across all addresses in a pool, for example=94. Do you mea= n that this can be done in a deterministic fashion? In other words, can an= inside IP address spawn more outside IP addresses in a deterministic fashi= on (along with outside port ranges)? Sure. Simplistic example =96 4 subs/2 outside addresses. You could chop u= p each of the outside addresses in 4 blocks: 0-16K, 16-32K, 32-48K, 48-64K.= Sub 1 gets the low address range on both outside addresses, sub 2 gets the= next highest range, etc. - It is up to the vendor to figure out how will ports be assigned = (in block, staggered fashion, etc). There are requirements out there that t= he ISPs run the algorithm on external nodes to do to reverse conversions. S= o this inconsistency will make life for ISP little bit more difficult, but = I guess as people mentioned here, we can=92t mandate the details of the alg= orithm to the vendors. Perhaps vendors could include their algorithm in the daily log message, doc= ument it somewhere so that the ISPs could script the reverse mapping, or su= pply a tool. ISPs will be able to determine what CGN is hosting which addr= ess and run the appropriate tool, if necessary. - I know that this is the first version of the draft, but in the f= uture maybe you can mention load balancing across the modules performing th= e NAT function in the system and if there is anything in particular that yo= u had in mind about this=85 Sure. We'll definitely consider it for a future update. Thanks, Kris From: Chris Donley [mailto:C.Donley@cablelabs.com] Sent: Monday, September 26, 2011 10:56 AM To: Poscic, Kristian (Kristian); mohamed.boucadair@orange.com; 'behave@ietf.org' Subject: Re: [BEHAVE] predictable translations Kris, We've been working on such an idea at CableLabs. I've been a little slow to= post. We're definitely interested in your feedback on our proposal. Chris A new version of I-D, draft-donley-behave-deterministic-cgn-00.txt has been= successfully submitted by Chris Donley and posted to the IETF repository. Filename: draft-donley-behave-deterministic-cgn Revision: 00 Title: Deterministic Address Mapping to Reduce Logging in Carrier G= rade NATs Creation date: 2011-09-26 WG ID: Individual Submission Number of pages: 9 Abstract: Many Carrier Grade NAT solutions require per-connection logging. Unfortunately, such logging is not scalable to many residential broadband services. This document suggests a way to manage Carrier Grade NAT translations in such a way as to significantly reduce the amount of logging required while providing traceability for abuse response. This method also provides a way of including geo-location significance in such assignments. The IETF Secretariat From: "Poscic, Kristian (Kristian)" > Date: Fri, 23 Sep 2011 10:21:13 -0600 To: "mohamed.boucadair@orange.com" >, "'behave@= ietf.org'" > Subject: Re: [BEHAVE] predictable translations Hi Med, By predictable translation I mean deterministic NAT. For now, I=92m just trying to evaluate (for my own sake) if this determinis= tic NAT makes any sense since 1) would take care of the concerns that I hav= e. If deterministic NAT makes deployable sense [for a reason that I yet nee= d to find, since 1) already takes care of my concerns], then I=92m trying t= o evaluate surrounding issues related to ease of integration into existing = OS (which it looks like does not come into play) and any other legal issue= s related to use of already possibly patented algorithms. Thanks, Kris From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Thursday, September 22, 2011 11:00 PM To: Poscic, Kristian (Kristian); 'behave@ietf.org' Subject: RE: predictable translations Dear Kris, Could please precise more what you mean by "predictable translation"? (1) Do you want to eliminate the volume of CGN logs (e.g, few entries per c= ustomer) or (2) you want to eliminate the CGN logging (e.g., rely on DHCP r= ecords)? (1) can be done in the CGN itself by design or configuration of the CGN to = use port ranges. This is already supported by CGN implementation including = A(..)U ;-) (2) can be supported only if you eliminate the NAT function in the CGN whic= h should be a PRR (Port Range Router; http://tools.ietf.org/html/draft-bouc= adair-port-range-02#section-6) instead. Cheers, Med ________________________________ De : behave-bounces@ietf.org [mailto:behave= -bounces@ietf.org] De la part de Poscic, Kristian (Kristian) Envoy=E9 : vendredi 23 septembre 2011 01:28 =C0 : 'behave@ietf.org' Objet : Re: [BEHAVE] predictable translations I looked at this draft draft-bsd-softwire-stateless-port-index-analysis-00<= http://datatracker.ietf.org/doc/draft-bsd-softwire-stateless-port-index-ana= lysis/> which examines 6 different algorithms for predictable translation a= pplicable to v4/v6 translation but I guess it can be potentially adopted fo= r v4 to v4 conversions as well. As my coworker (who is probably on this list) says =93too many deterministi= c nat drafts make for non-deterministic behaviours=94. Is there any plan to adopt one as a standard? Thanks, Kris From: Poscic, Kristian (Kristian) Sent: Thursday, September 22, 2011 11:57 AM To: behave@ietf.org Subject: predictable translations Hi there =96 Does anyone knows of any draft that is addressing a more predictable transl= ations between the inside IP and outside IP + port range when it comes to N= AT44. For example in order to avoid logging, IPv4 inside address would be automat= ically (via an algorithm) be converted to an outside IPv4 address + a port= range. This mapping would be unique so that no logging is required. The re= vertive algo would be able to convert the outside IP + port back to the in= side IP. I=92ve seen some drafts addressing something similar in the softwire WG but= they all deal with IPv4/IPv6 translations. Thanks, Kris --_000_CAA62F0A245E8cdonleycablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Kris,

= Please see in-line.

Chris

From: "Poscic, Kristian (Kri= stian)" <kris= tian.poscic@alcatel-lucent.com>
= Date: Mon, 26 Sep 2011 13:18:54 -0600
To: Chris Donley <c.donley@cablelabs.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "<= a href=3D"mailto:'behave@ietf.org">'behave@ietf.org'" <behave@ietf.org>
Subject: RE: [BEHAVE] predictable translations

Thanks Chris!

I was wondering how woul= d one extend the port-block in deterministic-CGN for an inside IP address i= f all the ports in the originally assigned port-block are exhausted.

It look= s like that you combined deterministic NAT with the dynamic port assignment= through the D variable, which I think is a good compromise.

 

As I und= erstand In you example, you eliminated inside addresses 192.168.0.0 and 192= .168.0.15 from the range 192.168.0.0/28, and in essence allocated their sha= re of outside ports via the D factor to the dynamic allocation. Nice.<= /o:p>

&= nbsp;

= A few questions:

-     &nbs= p;    Do you always assume that the 0 and bcast host part of the insid= e IP address range is automatically excluded from =91I=92?

=
I suppose that it could go either way, but in our a= nalysis, we think ISPs will deploy CGNs in such a way as to not allocate th= e network/bcast addresses to subscribers. YMMV, and it would be up to CGN v= endors and ISPs to decide whether to include them, or whether there were ad= ditional addresses to exclude.

-       &= nbsp;  You mentioned on page 4, point 2 in the last sentence: =93 Subscribers co= uld be restricted to ports from a single IPv4 address, or could be allocate= d ports across all addresses in a pool, for example=94. Do you mean that th= is can be done in  a deterministic fashion? In other words, can an ins= ide IP address spawn more outside IP addresses in a deterministic fashion (= along with outside port ranges)?

Su= re.  Simplistic example =96 4 subs/2 outside addresses.  You coul= d chop up each of the outside addresses in 4 blocks: 0-16K, 16-32K, 32-48K,= 48-64K. Sub 1 gets the low address range on both outside addresses, sub 2 = gets the next highest range, etc.

-      &nbs= p;   It is up to the vendor to figure out how will ports be assigned (in bl= ock, staggered fashion, etc). There are requirements out there that the ISP= s run the algorithm on external nodes to do to reverse conversions. So this= inconsistency will make life for ISP little bit more difficult, but I gues= s as people mentioned here, we can=92t mandate the details of the algorithm= to the vendors.

Perhaps vendors co= uld include their algorithm in the daily log message, document it somewhere= so that the ISPs could script the reverse mapping, or supply a tool.  = ;ISPs will be able to determine what CGN is hosting which address and run t= he appropriate tool, if necessary.  

= -     &= nbsp;    I know that this is the first version of the draft, but in th= e future maybe you can mention load balancing across the modules performing= the NAT function in the system and if there is anything in particular that= you had in mind about this=85

Sure= . We'll definitely consider it for a future update. 
=

 

Thanks,

<= p class=3D"MsoNormal">Kris  <= /span>

 <= /o:p>

&= nbsp;

=  

 

= From:= Chris Donley [mailto:C.Donley@ca= blelabs.com]
Sent: Monday, September 26, 2011 10:56 AM
To: Poscic, Kristian (Kristian); mohamed.boucadair@orange.com; 'behave@ietf.org'
Subject: Re: [BEHAVE] predictable tra= nslations

&nbs= p;

Kris,

<= p class=3D"MsoNormal">We've been working on such an idea at CableLabs. I've been a l= ittle slow to post. 

 

We're definitely interest= ed in your feedback on our proposal.

 

Chris

 

A new version of I-D, draft-donley-behave-deterministic-cgn= -00.txt has been successfully submitted by Chris Donley and posted to the I= ETF repository.

 

Filename:  draft-donley-behave-deterministic-cgn<= /p>

Revision:  00

Title:         = ;Deterministic Address Mapping to Reduce Logging in Carrier Grade NATs=

Creation date:  2011-09-26

WG ID:     =     Individual Submission

=

Number of pages: 9

 

Abstract:

   Many Carrier Grade = NAT solutions require per-connection logging.

   Unfortunately, such logging is not scalable t= o many residential

<= span style=3D"font-size:13.5pt;font-family:Consolas;color:black"> &nbs= p; broadband services.  This document suggests a way to manage Ca= rrier

   Grade NAT = translations in such a way as to significantly reduce the=

   amount of logging required while = providing traceability for abuse

   response.  This method also provides a way of = including geo-location

 =   significance in such assignments.

 

<= span style=3D"font-size:13.5pt;font-family:Consolas;color:black"> = ;

     &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp; 

 <= /span>

 

<= p class=3D"MsoNormal">The IETF Secretariat

 = ;

From: "Poscic, Kris= tian (Kristian)" <kristian.poscic@alcatel-lucent.com>
Date: Fri, 23 Sep= 2011 10:21:13 -0600
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "<= a href=3D"mailto:'behave@ietf.org">'behave@ietf.org'" <behave@ietf.org>
Subject: Re: = [BEHAVE] predictable translations

 

Hi Med,

By predictable translatio= n I mean deterministic NAT.

 =

For now, I=92m just trying to evaluate (for my = own sake) if this deterministic NAT makes any sense since 1) would take car= e of the concerns that I have. If deterministic NAT makes deployable sense = [for a reason that I yet need to find, since 1) already takes care of my co= ncerns], then I=92m trying to evaluate surrounding issues related to ease o= f integration into existing OS  (which it looks like does not come int= o play) and any other legal issues related to use of already possibly paten= ted algorithms.

 

Thanks,

Kris

 

From:= mohamed.boucadair@or= ange.com [mailto:mohame= d.boucadair@orange.com]
Sent: Thursday, September 22, 2011 1= 1:00 PM
To: Poscic, Kristian (Kristian); 'behave@ietf.org'
Subject: RE: predictable transl= ations

=

 =

Dear Kris,

 

Could plea= se precise more what you mean by "predictable translation"?

<= span style=3D"font-size: 12pt; color: black; font-family: 'Times New Roman'= , serif; "> 

<= p class=3D"MsoNormal">(1) Do you want to eliminate the volume of CGN logs (= e.g, few entries per customer) or (2) you want to eliminate the CGN logging= (e.g., rely on DHCP records)?=

 

(1) can be = done in the CGN itself by design or configuration of the CGN to use port ra= nges. This is already supported by CGN implementation including A(..)U ;-)<= /span>

 =

(2) can be supported only if you eliminate the N= AT function in the CGN which should be a PRR (Port Range Router; http:/= /tools.ietf.org/html/draft-boucadair-port-range-02#section-6) instead.<= /span>

 =

 

Cheers,

Med<= span style=3D"color:black">

 

De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de Poscic, Krist= ian (Kristian)
Envoy=E9 : vendredi 23 septembre 2011 01:28=C0 : 'behave@ietf.org'
Objet : Re: [BEHAVE] predictable translations

I looked at this draft draft-bsd-softwire-stateless-port-index-analysis-00 which examines 6 different algorithms for predictable translation applic= able to v4/v6 translation but I guess it can be potentially adopted for v4 = to v4 conversions as well.

 

As my coworker (who is probably on this list= ) says =93too many deterministic nat drafts make for non= -deterministic behaviours=94.

Is there any plan to adopt one as a= standard?

Thanks,

Kris

 

&n= bsp;

Hi there =96

Does anyone knows of any draft that is addressing a more predi= ctable translations between the inside IP and outside IP + port range w= hen it comes to NAT44.

For example in order to avoid logging, IPv4 inside addr= ess would be automatically (via an algorithm) be converted to an outside IP= v4 address  + a port range. This mapping would be unique so that n= o logging is required. The revertive algo would be able to convert the outs= ide IP + port back  to the inside IP.

 

I=92ve seen some drafts add= ressing something similar in the softwire WG but they all deal with IPv4/IP= v6 translations.

Thanks,

Kris

--_000_CAA62F0A245E8cdonleycablelabscom_-- From dwing@cisco.com Mon Sep 26 17:26:44 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F272D21F8E37; Mon, 26 Sep 2011 17:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.11 X-Spam-Level: X-Spam-Status: No, score=-103.11 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjtLkFchGIRM; Mon, 26 Sep 2011 17:26:43 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1600621F8E36; Mon, 26 Sep 2011 17:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5320; q=dns/txt; s=iport; t=1317083367; x=1318292967; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Bipe9RZdGTogi+YitrmHtJKTTp+qcs3/ws01ostbugM=; b=TpzYOpp85Bfqw9kMKpfVZbRPFakYrBfh0OGUlQf+0/Z7SG4RzqRhJkE/ XT5gUhsBNmvz/1SdMvZYREFLaOXyqZWTThVYohb0UR03UYnoywHrQFlkS X1soDU33bOj5jjPRYUTzVEH5lBGqHqx4T9GKLucvdMOfKlL26/YHPw6tB A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoBANsXgU6rRDoI/2dsb2JhbABCmGiBbI0ceIFTAQEBAQIBAQEBBQoBFxA0CwUHAQMCCQ8CBAEBASMEBxkIBhUKCQgBAQQBEgsQB4dWBptOAZ5YhwsEh3KVd4c8 X-IronPort-AV: E=Sophos;i="4.68,447,1312156800"; d="scan'208";a="4446572" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 27 Sep 2011 00:29:27 +0000 Received: from dwingWS ([10.89.10.9]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8R0TP8c018471; Tue, 27 Sep 2011 00:29:26 GMT From: "Dan Wing" To: , , References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> Date: Mon, 26 Sep 2011 17:29:25 -0700 Message-ID: <081701cc7cac$837a9610$8a6fc230$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acx8XrGT3LPZ/umGSqyAQmFBTGHJTgATRZdA Content-Language: en-us Cc: softwires@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2011 00:26:44 -0000 > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of > teemu.savolainen@nokia.com > Sent: Monday, September 26, 2011 8:20 AM > To: satoru.matsushima@gmail.com; ietf@ietf.org > Cc: softwires@ietf.org; behave@ietf.org > Subject: RE: [BEHAVE] Last Call: > (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard > > Please note that this statement was included after quite long and > heated > discussion in behave WG and because it came clear that IETF > recommendation > is against double protocol translation (in favor of dual-stack and > tunneling). It may be that the recommendation is specifically against > *stateful* double translation (although that was not said aloud, if I > recall correctly). I believe the objection is against "non-deterministic translation", rather than stateful versus stateless. By non-deterministic, I mean that the subscriber's equipment (e.g., CPE) cannot determine the mapping it will have on the Internet. A+P mechanisms are deterministic (including 4rd, Dual-IVI, and draft-ymbk-aplus-p). A stateful CGN, as commonly deployed, is not deterministic. However -- and this is my point in this email -- a stateful CGN can be configured and deployed so that it deterministically maps traffic. That is, it can function very much like A+P/4rd/Dual-IVI so that port "N" from subscriber "A" is always mapped to public port "Z" on IPv4 address "Y". We could have the CPE know about that fixed mapping using the same DHCP options that A+P/4rd/ Dual-IVI would use, or use PCP, or use some other protocol. -d > I would assume softwires follows these same IETF guidelines and > therefore is > now focusing solely on stateless approaches(?). If the IETF opinion has > changed so that also stateful double translation solutions are now ok > for > IETF, then that should perhaps be reflected in this document as well. > > Unfortunately, I did not have chance to go to softwires interim, but > please > let us know if the discussions there impact also the quoted > recommendation. > > Best regards, > > Teemu > > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of ext Satoru Matsushima > > Sent: 13. syyskuuta 2011 06:51 > > To: ietf@ietf.org > > Cc: behave@ietf.org; Satoru Matsushima > > Subject: Re: [BEHAVE] Last Call: > (Dual > > Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard > > > > The introduction in the draft says: > > > > > > > IETF recommends using dual-stack or tunneling based solutions for > > > IPv6 transition and specifically recommends against deployments > > > utilizing double protocol translation. Use of BIH together with > a > > > NAT64 is NOT RECOMMENDED [RFC6180]. > > > > > > > > > This statement makes a strong obstacle when we develop stateless > solution > > with translation in softwires wg. > > I think that it is still remained a room to make decision whether > removing > the > > statement or remaining it. > > The discussion which we'll have in the softwires interim meeting > would be > > helpful to decide it. > > > > Best regards, > > --satoru > > > > > > > > On 2011/08/31, at 22:53, The IESG wrote: > > > > > > > > The IESG has received a request from the Behavior Engineering for > > > Hindrance Avoidance WG (behave) to consider the following document: > > > - 'Dual Stack Hosts Using "Bump-in-the-Host" (BIH)' > > > 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 2011-09-14. 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. > > > > > > Abstract > > > > > > > > > Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol > > > translation mechanism that allows a class of IPv4-only > applications > > > that work through NATs to communicate with IPv6-only peers. The > host > > > on which applications are running may be connected to IPv6-only > or > > > dual-stack access networks. BIH hides IPv6 and makes the IPv4- > only > > > applications think they are talking with IPv4 peers by local > > > synthesis of IPv4 addresses. This draft obsoletes RFC 2767 and > RFC > > > 3338. > > > > > > > > > > > > > > > The file can be obtained via > > > http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ > > > > > > IESG discussion can be tracked via > > > http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ > > > > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > > _______________________________________________ > > > 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 denghui02@gmail.com Mon Sep 26 22:46:55 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891F921F8BE9; Mon, 26 Sep 2011 22:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.498 X-Spam-Level: X-Spam-Status: No, score=-103.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tfYeGqmg2CZ; Mon, 26 Sep 2011 22:46:54 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D099C21F84C9; Mon, 26 Sep 2011 22:46:51 -0700 (PDT) Received: by wyh21 with SMTP id 21so5137412wyh.31 for ; Mon, 26 Sep 2011 22:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VoXAX8Pqz/YBPN3cbI6m77ITNZFiFGlhTEMro9HxiiM=; b=dKxRppDpkB8Fq0u22LYshpDwfhlF0SGfkLbi7K8o8jKwFhEccIDkMZyl2NZMz8PKMM mcsP6BrRr6xn67gpp++lYCeBL9dNQPXpA4dd6vh9/1LXrJkVI2MwnOy2zavKFxTULH+t XgX8Fa1UwPP/gvy0jsusleWG8nYJx9bqfSqjA= MIME-Version: 1.0 Received: by 10.216.6.211 with SMTP id 61mr7933120wen.94.1317102574406; Mon, 26 Sep 2011 22:49:34 -0700 (PDT) Received: by 10.216.186.13 with HTTP; Mon, 26 Sep 2011 22:49:34 -0700 (PDT) In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C060633BA@XMB-RCD-111.cisco.com> References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <067E6CE33034954AAC05C9EC85E2577C060633BA@XMB-RCD-111.cisco.com> Date: Tue, 27 Sep 2011 13:49:34 +0800 Message-ID: From: Hui Deng To: "Rajiv Asati (rajiva)" Content-Type: multipart/alternative; boundary=0016364c7765148f7104ade5d72e Cc: softwires@ietf.org, behave@ietf.org, satoru.matsushima@gmail.com, ietf@ietf.org Subject: Re: [BEHAVE] [Softwires] Last Call: (Dual Stack Hosts Using"Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2011 05:46:55 -0000 --0016364c7765148f7104ade5d72e Content-Type: text/plain; charset=ISO-8859-1 May I know what's the reason to against stateful other than stateless? -Hui 2011/9/26 Rajiv Asati (rajiva) > > > tunneling). It may be that the recommendation is specifically against > > *stateful* double translation > > That may be reasonable. And the document may reflect that. > > > > > > IETF recommends using dual-stack or tunneling based solutions > for > > > > IPv6 transition and specifically recommends against deployments > > > > utilizing double protocol translation. Use of BIH together > with a > > > > NAT64 is NOT RECOMMENDED [RFC6180]. > > One could suggest rephrasing that para with something like this - > > This document doesn't recommend using BIH together with NAT64 > [RFC6180]. Of course, the adoption of this or any solution (e.g > dual-stack and/or any solution that eases the path to IPv6 > (and accommodate residual IPv4)) would be subjected to the > overall cost-effectiveness, as determined by operators per their > environments/constraints. > > Cheers, > Rajiv > > > > -----Original Message----- > > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] > On Behalf > > Of teemu.savolainen@nokia.com > > Sent: Monday, September 26, 2011 11:20 AM > > To: satoru.matsushima@gmail.com; ietf@ietf.org > > Cc: softwires@ietf.org; behave@ietf.org > > Subject: Re: [Softwires] [BEHAVE] Last > Call: > 06.txt> (Dual Stack Hosts Using"Bump-in-the-Host" (BIH)) to Proposed > Standard > > > > Please note that this statement was included after quite long and > heated > > discussion in behave WG and because it came clear that IETF > recommendation > > is against double protocol translation (in favor of dual-stack and > > tunneling). It may be that the recommendation is specifically against > > *stateful* double translation (although that was not said aloud, if I > recall > > correctly). > > > > I would assume softwires follows these same IETF guidelines and > therefore is > > now focusing solely on stateless approaches(?). If the IETF opinion > has > > changed so that also stateful double translation solutions are now ok > for > > IETF, then that should perhaps be reflected in this document as well. > > > > Unfortunately, I did not have chance to go to softwires interim, but > please > > let us know if the discussions there impact also the quoted > recommendation. > > > > Best regards, > > > > Teemu > > > > > -----Original Message----- > > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > > Behalf Of ext Satoru Matsushima > > > Sent: 13. syyskuuta 2011 06:51 > > > To: ietf@ietf.org > > > Cc: behave@ietf.org; Satoru Matsushima > > > Subject: Re: [BEHAVE] Last Call: > (Dual > > > Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard > > > > > > The introduction in the draft says: > > > > > > > > > > IETF recommends using dual-stack or tunneling based solutions > for > > > > IPv6 transition and specifically recommends against deployments > > > > utilizing double protocol translation. Use of BIH together > with a > > > > NAT64 is NOT RECOMMENDED [RFC6180]. > > > > > > > > > > > > > This statement makes a strong obstacle when we develop stateless > solution > > > with translation in softwires wg. > > > I think that it is still remained a room to make decision whether > removing > > the > > > statement or remaining it. > > > The discussion which we'll have in the softwires interim meeting > would be > > > helpful to decide it. > > > > > > Best regards, > > > --satoru > > > > > > > > > > > > On 2011/08/31, at 22:53, The IESG wrote: > > > > > > > > > > > The IESG has received a request from the Behavior Engineering for > > > > Hindrance Avoidance WG (behave) to consider the following > document: > > > > - 'Dual Stack Hosts Using "Bump-in-the-Host" (BIH)' > > > > 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 2011-09-14. 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. > > > > > > > > Abstract > > > > > > > > > > > > Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol > > > > translation mechanism that allows a class of IPv4-only > applications > > > > that work through NATs to communicate with IPv6-only peers. The > host > > > > on which applications are running may be connected to IPv6-only > or > > > > dual-stack access networks. BIH hides IPv6 and makes the > IPv4-only > > > > applications think they are talking with IPv4 peers by local > > > > synthesis of IPv4 addresses. This draft obsoletes RFC 2767 and > RFC > > > > 3338. > > > > > > > > > > > > > > > > > > > > The file can be obtained via > > > > http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ > > > > > > > > IESG discussion can be tracked via > > > > http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ > > > > > > > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > > > > > _______________________________________________ > > > > 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 > --0016364c7765148f7104ade5d72e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
May I know what's the reason to against stateful other than statel= ess?
=A0
-Hui

2011/9/26 Rajiv Asati (rajiva) <rajiva@cisco.com>

> tunneling). It may be that the recommendation is= specifically against
> *stateful* double translation

Th= at may be reasonable. And the document may reflect that.


> > > =A0 IETF recommends using dual-sta= ck or tunneling based solutions
for
> > > =A0 =A0IPv6 transi= tion and specifically recommends against deployments
> > > =A0 = =A0utilizing double protocol translation. =A0Use of BIH together
with a
> > > =A0 =A0NAT64 is NOT RECOMMENDED [RFC6180].

=
One could suggest rephrasing that para with something like this -
=
This document doesn't recommend using BIH together with NAT64
= =A0[RFC6180]. Of course, the adoption of this or any solution (e.g
=A0dual-stack and/or any solution that eases the path to IPv6
(and accom= modate residual IPv4)) would be subjected to the
overall cost-effectiven= ess, as determined by operators per their
environments/constraints.

Cheers,
Rajiv


> -----Original Message-----
> From: softwires-bounces@ietf.org [= mailto:softwires-bounces@ietf= .org]
On Behalf
> Of te= emu.savolainen@nokia.com
> Sent: Monday, September 26, 2011 11:20= AM
> To: satoru.matsu= shima@gmail.com; ietf@ietf.org
> Cc: softwires@ietf.org; behave@ietf.org
> Subject: Re: [So= ftwires] [BEHAVE] Last
Call:<draft-ietf-behave-v4v6-bih-
> 06.txt> (= Dual Stack Hosts Using"Bump-in-the-Host" (BIH)) to Proposed
St= andard
>
> Please note that this statement was included after q= uite long and
heated
> discussion in behave WG and because it came clear that IETF<= br>recommendation
> is against double protocol translation (in favor = of dual-stack and
> tunneling). It may be that the recommendation is = specifically against
> *stateful* double translation (although that was not said aloud, if I<= br>recall
> correctly).
>
> I would assume softwires foll= ows these same IETF guidelines and
therefore is
> now focusing sol= ely on stateless approaches(?). If the IETF opinion
has
> changed so that also stateful double translation solutions are = now ok
for
> IETF, then that should perhaps be reflected in this d= ocument as well.
>
> Unfortunately, I did not have chance to go= to softwires interim, but
please
> let us know if the discussions there impact also the quoted<= br>recommendation.
>
> Best regards,
>
> =A0 =A0 = =A0 Teemu
>
> > -----Original Message-----
> > From= : behave-bounces@ietf.org [m= ailto:behave-bounces@ietf.org] On
> > Behalf Of ext Satoru Matsushima
> > Sent: 13. syyskuuta = 2011 06:51
> > To: ietf@ietf.org<= /a>
> > Cc: behave@ietf.org= ; Satoru Matsushima
> > Subject: Re: [BEHAVE] Last Call: <draft-ietf-behave-v4v6-bih-0= 6.txt>
(Dual
> > Stack Hosts Using "Bump-in-the-Host&qu= ot; (BIH)) to Proposed Standard
> >
> > The introduction = in the draft says:
> >
> >
> > > =A0 IETF recommends using dual-sta= ck or tunneling based solutions
for
> > > =A0 =A0IPv6 transi= tion and specifically recommends against deployments
> > > =A0 = =A0utilizing double protocol translation. =A0Use of BIH together
with a
> > > =A0 =A0NAT64 is NOT RECOMMENDED [RFC6180].
>= > >
> >
> >
> > This statement makes a st= rong obstacle when we develop stateless
solution
> > with trans= lation in softwires wg.
> > I think that it is still remained a room to make decision whether=
removing
> the
> > statement or remaining it.
> &g= t; The discussion which we'll have in the softwires interim meeting
would be
> > helpful to decide it.
> >
> > Best = regards,
> > --satoru
> >
> >
> >
&g= t; > On 2011/08/31, at 22:53, The IESG wrote:
> >
> > = >
> > > The IESG has received a request from the Behavior Engineerin= g for
> > > Hindrance Avoidance WG (behave) to consider the fol= lowing
document:
> > > - 'Dual Stack Hosts Using "B= ump-in-the-Host" (BIH)'
> > > =A0<draft-ietf-behave-v4v6-bih-06.txt> as a Proposed S= tandard
> > >
> > > The IESG plans to make a decisi= on in the next few weeks, and
solicits
> > > final comments = on this action. Please send substantive comments to
the
> > > ietf@ietf.org ma= iling lists by 2011-09-14. Exceptionally, comments
may
> > >= be sent to iesg@ietf.org instead. In = either case, please retain
the
> > > beginning of the Subject line to allow automated sort= ing.
> > >
> > > Abstract
> > >
>= > >
> > > =A0 Bump-In-the-Host (BIH) is a host-based IPv= 4 to IPv6 protocol
> > > =A0 translation mechanism that allows a class of IPv4-onlyapplications
> > > =A0 that work through NATs to communicate = with IPv6-only peers. =A0The
host
> > > =A0 on which applica= tions are running may be connected to IPv6-only
or
> > > =A0 dual-stack access networks. =A0BIH hides IPv6 and = makes the
IPv4-only
> > > =A0 applications think they are ta= lking with IPv4 peers by local
> > > =A0 synthesis of IPv4 addr= esses. =A0This draft obsoletes RFC 2767 and
RFC
> > > =A0 3338.
> > >
> > >
>= > >
> > >
> > > The file can be obtained via=
> > > http://datatracker.ietf.org/doc/draft-iet= f-behave-v4v6-bih/
> > >
> > > IESG discussion can be tracked via
>= > > http://datatracker.ietf.org/doc/draft-ietf-behave= -v4v6-bih/
> > >
> > >
> > > No IPR declarations have= been submitted directly on this I-D.
> > >
> > >> > > _______________________________________________
> &g= t; > Behave mailing list
> > > Behave@ietf.org
&g= t; > > https://www.ietf.org/mailman/listinfo/behave
> ><= br> > > _______________________________________________
> > Beha= ve mailing list
> > Behave@ietf= .org
> > https://www.ietf.org/mailman/listinfo/behave
_______________________________________________
Behave mailing list
<= a href=3D"mailto:Behave@ietf.org">Behave@ietf.org
https://www.ietf.o= rg/mailman/listinfo/behave

--0016364c7765148f7104ade5d72e-- From denghui02@gmail.com Mon Sep 26 22:58:06 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F73521F8E22; Mon, 26 Sep 2011 22:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.501 X-Spam-Level: X-Spam-Status: No, score=-103.501 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Njuo0lcItEu; Mon, 26 Sep 2011 22:58:04 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 28FF521F8E20; Mon, 26 Sep 2011 22:58:04 -0700 (PDT) Received: by wyh21 with SMTP id 21so5148765wyh.31 for ; Mon, 26 Sep 2011 23:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3c5tmkc6e83dDyAl7YQMFyMs/1O+1mDa1ZKOktk3PEQ=; b=rav5p7+x48dtMubMPz0t8esVREPDoGsJGPtKDYn4QzImoDus4z7HDbC9AA4gh8T9uq hUHPLDVYih1axpyRowTNq1NAJJwG84khoXs2PEJ6IqIcwFz0OaZjmtBqW8X5gLQWUQfM il2Y0iJ8rjYNvu0EWOUFt3a+o07HG1hxcXJgM= MIME-Version: 1.0 Received: by 10.216.184.66 with SMTP id r44mr8051657wem.109.1317103248186; Mon, 26 Sep 2011 23:00:48 -0700 (PDT) Received: by 10.216.186.13 with HTTP; Mon, 26 Sep 2011 23:00:48 -0700 (PDT) In-Reply-To: <081701cc7cac$837a9610$8a6fc230$@com> References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> Date: Tue, 27 Sep 2011 14:00:48 +0800 Message-ID: From: Hui Deng To: Dan Wing Content-Type: multipart/alternative; boundary=001485f1dbbc3d9c3304ade5ff86 Cc: softwires@ietf.org, behave@ietf.org, satoru.matsushima@gmail.com, ietf@ietf.org Subject: Re: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2011 05:58:06 -0000 --001485f1dbbc3d9c3304ade5ff86 Content-Type: text/plain; charset=ISO-8859-1 Hi Dan inline please, > I believe the objection is against "non-deterministic translation", > rather than stateful versus stateless. By non-deterministic, I mean > that the subscriber's equipment (e.g., CPE) cannot determine the > mapping it will have on the Internet. A+P mechanisms are > Could you help be more elaboration on CPE can't determine the ampping? > deterministic (including 4rd, Dual-IVI, and draft-ymbk-aplus-p). > By the way, I would say you are missing one early draft: http://tools.ietf.org/html/draft-murakami-softwire-4v6-translation-00 which is align with 4rd about 4v6 translation which has been contributed by major operators which is also align with NAT64 deployment. -Hui > > A stateful CGN, as commonly deployed, is not deterministic. > > However -- and this is my point in this email -- a stateful CGN > can be configured and deployed so that it deterministically maps > traffic. That is, it can function very much like A+P/4rd/Dual-IVI > so that port "N" from subscriber "A" is always mapped to public > port "Z" on IPv4 address "Y". We could have the CPE know about > that fixed mapping using the same DHCP options that A+P/4rd/ > Dual-IVI would use, or use PCP, or use some other protocol. > > -d > > > I would assume softwires follows these same IETF guidelines and > > therefore is > > now focusing solely on stateless approaches(?). If the IETF opinion has > > changed so that also stateful double translation solutions are now ok > > for > > IETF, then that should perhaps be reflected in this document as well. > > > > Unfortunately, I did not have chance to go to softwires interim, but > > please > > let us know if the discussions there impact also the quoted > > recommendation. > > > > Best regards, > > > > Teemu > > > > > -----Original Message----- > > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > > Behalf Of ext Satoru Matsushima > > > Sent: 13. syyskuuta 2011 06:51 > > > To: ietf@ietf.org > > > Cc: behave@ietf.org; Satoru Matsushima > > > Subject: Re: [BEHAVE] Last Call: > > (Dual > > > Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard > > > > > > The introduction in the draft says: > > > > > > > > > > IETF recommends using dual-stack or tunneling based solutions for > > > > IPv6 transition and specifically recommends against deployments > > > > utilizing double protocol translation. Use of BIH together with > > a > > > > NAT64 is NOT RECOMMENDED [RFC6180]. > > > > > > > > > > > > > This statement makes a strong obstacle when we develop stateless > > solution > > > with translation in softwires wg. > > > I think that it is still remained a room to make decision whether > > removing > > the > > > statement or remaining it. > > > The discussion which we'll have in the softwires interim meeting > > would be > > > helpful to decide it. > > > > > > Best regards, > > > --satoru > > > > > > > > > > > > On 2011/08/31, at 22:53, The IESG wrote: > > > > > > > > > > > The IESG has received a request from the Behavior Engineering for > > > > Hindrance Avoidance WG (behave) to consider the following document: > > > > - 'Dual Stack Hosts Using "Bump-in-the-Host" (BIH)' > > > > 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 2011-09-14. 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. > > > > > > > > Abstract > > > > > > > > > > > > Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol > > > > translation mechanism that allows a class of IPv4-only > > applications > > > > that work through NATs to communicate with IPv6-only peers. The > > host > > > > on which applications are running may be connected to IPv6-only > > or > > > > dual-stack access networks. BIH hides IPv6 and makes the IPv4- > > only > > > > applications think they are talking with IPv4 peers by local > > > > synthesis of IPv4 addresses. This draft obsoletes RFC 2767 and > > RFC > > > > 3338. > > > > > > > > > > > > > > > > > > > > The file can be obtained via > > > > http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ > > > > > > > > IESG discussion can be tracked via > > > > http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ > > > > > > > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > > > > > _______________________________________________ > > > > 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 > --001485f1dbbc3d9c3304ade5ff86 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dan
=A0
inline please,
=A0
I believe the objection is against "non-deterministi= c translation",
rather than stateful versus stateless. =A0By non-de= terministic, I mean
that the subscriber's equipment (e.g., CPE) cann= ot determine the
mapping it will have on the Internet. =A0A+P mechanisms are
Could you help be more elaboration on CPE can't determine the ampp= ing?
=A0
deterministic (including 4rd, Dual-IVI, and draft-ymbk-ap= lus-p).
By the way, I would say you are missing one early draft: http:/= /tools.ietf.org/html/draft-murakami-softwire-4v6-translation-00
which is align with 4rd=A0 about 4v6 translation which has been contri= buted by major operators which is also align with NAT64 deployment.

-Hui
=A0
=A0

A stateful CGN, as commonly deployed, is not determin= istic.

However -- and this is my point in this email -- a stateful C= GN
can be configured and deployed so that it deterministically maps
traffic. =A0That is, it can function very much like A+P/4rd/Dual-IVI
so = that port "N" from subscriber "A" is always mapped to p= ublic
port "Z" on IPv4 address "Y". =A0We could have= the CPE know about
that fixed mapping using the same DHCP options that A+P/4rd/
Dual-IVI wo= uld use, or use PCP, or use some other protocol.

-d

> I would assume softwires follows these same IETF= guidelines and
> therefore is
> now focusing solely on statele= ss approaches(?). If the IETF opinion has
> changed so that also stat= eful double translation solutions are now ok
> for
> IETF, then that should perhaps be reflected in this docume= nt as well.
>
> Unfortunately, I did not have chance to go to s= oftwires interim, but
> please
> let us know if the discussions= there impact also the quoted
> recommendation.
>
> Best regards,
>
> =A0 =A0 = =A0 Teemu
>
> > -----Original Message-----
> > From= : behave-bounces@ietf.org [m= ailto:behave-bounces@ietf.org] On
> > Behalf Of ext Satoru Matsushima
> > Sent: 13. syyskuuta = 2011 06:51
> > To: ietf@ietf.org<= /a>
> > Cc: behave@ietf.org= ; Satoru Matsushima
> > Subject: Re: [BEHAVE] Last Call: <draft-ietf-behave-v4v6-bih-0= 6.txt>
> (Dual
> > Stack Hosts Using "Bump-in-the-Ho= st" (BIH)) to Proposed Standard
> >
> > The introduc= tion in the draft says:
> >
> >
> > > =A0 IETF recommends using dual-sta= ck or tunneling based solutions for
> > > =A0 =A0IPv6 transitio= n and specifically recommends against deployments
> > > =A0 =A0= utilizing double protocol translation. =A0Use of BIH together with
> a
> > > =A0 =A0NAT64 is NOT RECOMMENDED [RFC6180].
>= > >
> >
> >
> > This statement makes a st= rong obstacle when we develop stateless
> solution
> > with = translation in softwires wg.
> > I think that it is still remained a room to make decision whether=
> removing
> the
> > statement or remaining it.
&g= t; > The discussion which we'll have in the softwires interim meetin= g
> would be
> > helpful to decide it.
> >
> > = Best regards,
> > --satoru
> >
> >
> ><= br>> > On 2011/08/31, at 22:53, The IESG wrote:
> >
> = > >
> > > The IESG has received a request from the Behavior Engineerin= g for
> > > Hindrance Avoidance WG (behave) to consider the fol= lowing document:
> > > - 'Dual Stack Hosts Using "Bump= -in-the-Host" (BIH)'
> > > =A0<draft-ietf-behave-v4v6-bih-06.txt> as a Proposed S= tandard
> > >
> > > The IESG plans to make a decisi= on in the next few weeks, and
> solicits
> > > final comm= ents on this action. Please send substantive comments to
> the
> > > ietf@ietf.org mailing lists by 2011-09-14. Exceptionally, comments
> may
>= > > be sent to iesg@ietf.org in= stead. In either case, please retain the
> > > beginning of the Subject line to allow automated sorting.> > >
> > > Abstract
> > >
> > &= gt;
> > > =A0 Bump-In-the-Host (BIH) is a host-based IPv4 to IP= v6 protocol
> > > =A0 translation mechanism that allows a class of IPv4-only> applications
> > > =A0 that work through NATs to communi= cate with IPv6-only peers. =A0The
> host
> > > =A0 on whi= ch applications are running may be connected to IPv6-only
> or
> > > =A0 dual-stack access networks. =A0BIH hides IPv6= and makes the IPv4-
> only
> > > =A0 applications think = they are talking with IPv4 peers by local
> > > =A0 synthesis o= f IPv4 addresses. =A0This draft obsoletes RFC 2767 and
> RFC
> > > =A0 3338.
> > >
> > >> > >
> > >
> > > The file can be obtaine= d via
> > > http://datatracker.ietf.org/doc/draf= t-ietf-behave-v4v6-bih/
> > >
> > > IESG discussion can be tracked via
>= > > http://datatracker.ietf.org/doc/draft-ietf-behave= -v4v6-bih/
> > >
> > >
> > > No IPR declarations have= been submitted directly on this I-D.
> > >
> > >> > > _______________________________________________
> &g= t; > Behave mailing list
> > > Behave@ietf.org
&g= t; > > https://www.ietf.org/mailman/listinfo/behave
> ><= br> > > _______________________________________________
> > Beha= ve mailing list
> > Behave@ietf= .org
> > https://www.ietf.org/mailman/listinfo/behave

_______________________________________________
Behave mailing list<= br>Behave@ietf.org
https://www.ie= tf.org/mailman/listinfo/behave

--001485f1dbbc3d9c3304ade5ff86-- From teemu.savolainen@nokia.com Mon Sep 26 23:11:23 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DA621F8E44; Mon, 26 Sep 2011 23:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvzS5wv6zgKA; Mon, 26 Sep 2011 23:11:23 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3601A21F8E40; Mon, 26 Sep 2011 23:11:22 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8R6BoVZ027015; Tue, 27 Sep 2011 09:14:03 +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.4675); Tue, 27 Sep 2011 09:13:54 +0300 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 27 Sep 2011 08:13:53 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.8]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0339.002; Tue, 27 Sep 2011 08:13:53 +0200 From: To: , , Thread-Topic: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard Thread-Index: Acx8XrGT3LPZ/umGSqyAQmFBTGHJTgATRZdAAAwNkVA= Date: Tue, 27 Sep 2011 06:13:53 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696203771FAB@008-AM1MPN1-037.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> In-Reply-To: <081701cc7cac$837a9610$8a6fc230$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ili3MCvCLXmrxYjzLlJRY6EmZaqCLgxWgL9U8rnNM82CuD5+v00s+B6rNvhV7DPY+SM/In0cx92oRHang+R5hgiMyIoI03Er7sc1TlPZR1iVeAwzuvIEvF9C4WSriAJSEApEzC3cWtkrbRBgt8eqLi9xL3BeA9Kbd7cnR5KgY6zYIlVUmUnvVQBVLUguDohOJZ1kNXXcLNNTXApPp6UZWv5S0RCzCWXj7dZN2f+2sEIzoBUhRFGhPhJgcz/K46YNuJd3tRQJ3Fbspb7ltrO3iFFpHycdLAV6I/HFHU0o9f3goBe9a580t/xnmKSCAJabYVqtcYkAR91gr294fYuGs6Y= x-originating-ip: [10.162.58.120] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0281_01CC7CF5.C667E0B0" MIME-Version: 1.0 X-OriginalArrivalTime: 27 Sep 2011 06:13:54.0760 (UTC) FILETIME=[A27C3480:01CC7CDC] X-Nokia-AV: Clean Cc: softwires@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2011 06:11:24 -0000 ------=_NextPart_000_0281_01CC7CF5.C667E0B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > I believe the objection is against "non-deterministic translation", rather than > stateful versus stateless. By non-deterministic, I mean that the subscriber's > equipment (e.g., CPE) cannot determine the mapping it will have on the > Internet. A+P mechanisms are deterministic (including 4rd, Dual-IVI, and > draft-ymbk-aplus-p). > > A stateful CGN, as commonly deployed, is not deterministic. I don't understand why that is significant enough factor for IETF to (not) recommend some double translation variants. I mean does existing applications work better if double translation is done in deterministic manner? One reasoning against double translation has been that it breaks some class of applications. Is it now so that some forms of double translation do not break applications while some others do? Teemu ------=_NextPart_000_0281_01CC7CF5.C667E0B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTI3MDYxMzUyWjAjBgkqhkiG9w0B CQQxFgQUq/YHSVR76T18d1CkbBD1LwiVAzcwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAK3oF0KLY/RoF2oalxuR PJBKAtpa2xWXKFWTdRdXU72RGeb3trPx95wURd+S1e4PjvenGd+a9K6r1zyIgQ5ufNmZ/WVgybv5 /2kd6/FDAd4js8qDcFrr5kMIRxOx9EhD3miXwcZmlKaXRahXSs4tjZSBP5CaviVGUZUGCD8UUoG2 zcqBvETbghXmgQ9BpEJW2XShocPNS/JknQT+ANZ9qaf+rrgh0nD0hmjVnzdxcbEu14Dtm0N46Fsb DtTg0d0pX2IXTWA0uUp/ThoPHDQfFF+roiebqJHaSu5fDyqCYHORDpOx73e4mc7XXOoD8GqtAGtW pbP3tjeEWgIcX4zYg1MAAAAAAAA= ------=_NextPart_000_0281_01CC7CF5.C667E0B0-- From dwing@cisco.com Tue Sep 27 06:04:45 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1877E21F8C98; Tue, 27 Sep 2011 06:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.091 X-Spam-Level: X-Spam-Status: No, score=-103.091 tagged_above=-999 required=5 tests=[AWL=-0.492, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kv8JEVXGmdg; Tue, 27 Sep 2011 06:04:44 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 313EB21F8C8F; Tue, 27 Sep 2011 06:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=6232; q=dns/txt; s=iport; t=1317128850; x=1318338450; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=IdxGcZ3gxtZWM8zVr4I7wrJMI5Cylc3VUoaCpV7F2dU=; b=di+ry2tuRjfhbwC7fdg3A7cf9KSqR9gpJehqaLCqe1N3cg1musevcVBB eNUJdR6uM+mFMYw7omGDBFkOpnbyaVhNHUBTXcfA8zGVp+6MrxJNFJf8+ WqdblyS4v/rsR7ED+XoXVdFo3/6REAI1bUlCaTSwU5jpq6p4MTSuqM7M4 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIAAL3JgU6rRDoI/2dsb2JhbABBmHOBbI0aeIFTAQEBAwEBAQEFCgEXEDQLBQcBAwIJDwIEAQEBIwQHGQgGFQoJCAEBBBMLEAeHVgaaKQGeNIcLBIdylXiHPA X-IronPort-AV: E=Sophos;i="4.68,449,1312156800"; d="scan'208";a="4547331" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 27 Sep 2011 13:07:29 +0000 Received: from dwingWS ([10.89.10.9]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8RD7Sox002657; Tue, 27 Sep 2011 13:07:28 GMT From: "Dan Wing" To: "'Hui Deng'" References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> In-Reply-To: Date: Tue, 27 Sep 2011 06:07:27 -0700 Message-ID: <09b701cc7d16$6943df30$3bcb9d90$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acx82s9Txj12pmnbQGyVCLRR0o3kbwAO1wtw Content-Language: en-us Cc: softwires@ietf.org, behave@ietf.org, satoru.matsushima@gmail.com, ietf@ietf.org Subject: Re: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2011 13:04:45 -0000 > -----Original Message----- > From: Hui Deng [mailto:denghui02@gmail.com] > Sent: Monday, September 26, 2011 11:01 PM > To: Dan Wing > Cc: teemu.savolainen@nokia.com; satoru.matsushima@gmail.com; > ietf@ietf.org; softwires@ietf.org; behave@ietf.org > Subject: Re: [BEHAVE] Last Call: > (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard > > Hi Dan > > inline please, > > > I believe the objection is against "non-deterministic > translation", > rather than stateful versus stateless. By non-deterministic, I > mean > that the subscriber's equipment (e.g., CPE) cannot determine the > mapping it will have on the Internet. A+P mechanisms are > > > Could you help be more elaboration on CPE can't determine the ampping? It can't determine the public IP address and port of a mapping on the NAT64 (CGN), and it can't create a mapping on the NAT64 (CGN) -- because the CGN is going to make a dynamic mapping when it sees a UDP, TCP, or ICMP packet from the subscriber. > deterministic (including 4rd, Dual-IVI, and draft-ymbk-aplus-p). > > > By the way, I would say you are missing one early draft: > http://tools.ietf.org/html/draft-murakami-softwire-4v6-translation-00 > which is align with 4rd about 4v6 translation which has been > contributed by major operators which is also align with NAT64 > deployment. Sorry. -d > -Hui > > > > > A stateful CGN, as commonly deployed, is not deterministic. > > However -- and this is my point in this email -- a stateful CGN > can be configured and deployed so that it deterministically maps > traffic. That is, it can function very much like A+P/4rd/Dual- > IVI > so that port "N" from subscriber "A" is always mapped to public > port "Z" on IPv4 address "Y". We could have the CPE know about > that fixed mapping using the same DHCP options that A+P/4rd/ > Dual-IVI would use, or use PCP, or use some other protocol. > > -d > > > > I would assume softwires follows these same IETF guidelines and > > therefore is > > now focusing solely on stateless approaches(?). If the IETF > opinion has > > changed so that also stateful double translation solutions are > now ok > > for > > IETF, then that should perhaps be reflected in this document as > well. > > > > Unfortunately, I did not have chance to go to softwires > interim, but > > please > > let us know if the discussions there impact also the quoted > > recommendation. > > > > Best regards, > > > > Teemu > > > > > -----Original Message----- > > > From: behave-bounces@ietf.org [mailto:behave- > bounces@ietf.org] On > > > Behalf Of ext Satoru Matsushima > > > Sent: 13. syyskuuta 2011 06:51 > > > To: ietf@ietf.org > > > Cc: behave@ietf.org; Satoru Matsushima > > > Subject: Re: [BEHAVE] Last Call: 06.txt> > > (Dual > > > Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed > Standard > > > > > > The introduction in the draft says: > > > > > > > > > > IETF recommends using dual-stack or tunneling based > solutions for > > > > IPv6 transition and specifically recommends against > deployments > > > > utilizing double protocol translation. Use of BIH > together with > > a > > > > NAT64 is NOT RECOMMENDED [RFC6180]. > > > > > > > > > > > > > This statement makes a strong obstacle when we develop > stateless > > solution > > > with translation in softwires wg. > > > I think that it is still remained a room to make decision > whether > > removing > > the > > > statement or remaining it. > > > The discussion which we'll have in the softwires interim > meeting > > would be > > > helpful to decide it. > > > > > > Best regards, > > > --satoru > > > > > > > > > > > > On 2011/08/31, at 22:53, The IESG wrote: > > > > > > > > > > > The IESG has received a request from the Behavior > Engineering for > > > > Hindrance Avoidance WG (behave) to consider the following > document: > > > > - 'Dual Stack Hosts Using "Bump-in-the-Host" (BIH)' > > > > 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 2011-09-14. 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. > > > > > > > > Abstract > > > > > > > > > > > > Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 > protocol > > > > translation mechanism that allows a class of IPv4-only > > applications > > > > that work through NATs to communicate with IPv6-only > peers. The > > host > > > > on which applications are running may be connected to > IPv6-only > > or > > > > dual-stack access networks. BIH hides IPv6 and makes the > IPv4- > > only > > > > applications think they are talking with IPv4 peers by > local > > > > synthesis of IPv4 addresses. This draft obsoletes RFC > 2767 and > > RFC > > > > 3338. > > > > > > > > > > > > > > > > > > > > The file can be obtained via > > > > http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ > > > > > > > > IESG discussion can be tracked via > > > > http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ > > > > > > > > > > > > No IPR declarations have been submitted directly on this I- > D. > > > > > > > > > > > > _______________________________________________ > > > > 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 dwing@cisco.com Tue Sep 27 06:07:34 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACCA21F8AB8; Tue, 27 Sep 2011 06:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.084 X-Spam-Level: X-Spam-Status: No, score=-103.084 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnWSgSVghFi8; Tue, 27 Sep 2011 06:07:33 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9520021F8B4A; Tue, 27 Sep 2011 06:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1418; q=dns/txt; s=iport; t=1317129019; x=1318338619; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=9EpsqLX7czoklaHSWZsmdPTF89hQRVGkbsSI1HYIsl4=; b=ZYhaKnjtistrzY27uCAL250NHjfRq7JNiLtEyzqpnWeV4Zv7Kkxy7bKP 6Cq1DJTqMIftFPQSwIFp5qvyeSBTLVf9WscpSilTXKt4MDCtFXp4d/qDv Lzv1tZU2cBLWZnaMjDS86g+LvWPXG04dvRy66fUfliQ9elMeNAS+6h509 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIAADrKgU6rRDoH/2dsb2JhbABBmHOBbI0aeIFTAQEBAwEICgEXED8FBwEDAgkPAgQBASQEBxkIGwoJCAEBBAESCxeHVpoyAZ40hwsEh3KVeIc8 X-IronPort-AV: E=Sophos;i="4.68,449,1312156800"; d="scan'208";a="4530510" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 27 Sep 2011 13:10:17 +0000 Received: from dwingWS ([10.89.10.9]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8RDAGVw015677; Tue, 27 Sep 2011 13:10:16 GMT From: "Dan Wing" To: , , References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> <916CE6CF87173740BC8A2CE44309696203771FAB@008-AM1MPN1-037.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696203771FAB@008-AM1MPN1-037.mgdnok.nokia.com> Date: Tue, 27 Sep 2011 06:10:16 -0700 Message-ID: <09bd01cc7d16$cd715190$6853f4b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acx8XrGT3LPZ/umGSqyAQmFBTGHJTgATRZdAAAwNkVAADptiEA== Content-Language: en-us Cc: softwires@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2011 13:07:34 -0000 > -----Original Message----- > From: teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com] > Sent: Monday, September 26, 2011 11:14 PM > To: dwing@cisco.com; satoru.matsushima@gmail.com; ietf@ietf.org > Cc: softwires@ietf.org; behave@ietf.org > Subject: RE: [BEHAVE] Last Call: > (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard > > > I believe the objection is against "non-deterministic translation", > rather > than > > stateful versus stateless. By non-deterministic, I mean that the > subscriber's > > equipment (e.g., CPE) cannot determine the mapping it will have on > the > > Internet. A+P mechanisms are deterministic (including 4rd, Dual-IVI, > and > > draft-ymbk-aplus-p). > > > > A stateful CGN, as commonly deployed, is not deterministic. > > I don't understand why that is significant enough factor for IETF to > (not) > recommend some double translation variants. I mean does existing > applications work better if double translation is done in deterministic > manner? Yes, it allows the CPE to implement an ALG -- if an application needs an ALG (e.g., active-mode FTP). -d > One reasoning against double translation has been that it > breaks > some class of applications. Is it now so that some forms of double > translation do not break applications while some others do? > > Teemu > From teemu.savolainen@nokia.com Tue Sep 27 07:21:09 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D7C21F8C80; Tue, 27 Sep 2011 07:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6po0+Dhi6xzs; Tue, 27 Sep 2011 07:21:08 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 64CFF21F8C82; Tue, 27 Sep 2011 07:21:07 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8RENXAn028872; Tue, 27 Sep 2011 17:23:49 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Sep 2011 17:23:43 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 27 Sep 2011 16:23:41 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.8]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0339.002; Tue, 27 Sep 2011 16:23:35 +0200 From: To: , , Thread-Topic: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard Thread-Index: Acx8XrGT3LPZ/umGSqyAQmFBTGHJTgATRZdAAAwNkVAADptiEAACIkfA Date: Tue, 27 Sep 2011 14:23:35 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620377279D@008-AM1MPN1-037.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> <916CE6CF87173740BC8A2CE44309696203771FAB@008-AM1MPN1-037.mgdnok.nokia.com> <09bd01cc7d16$cd715190$6853f4b0$@com> In-Reply-To: <09bd01cc7d16$cd715190$6853f4b0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ili3MCvCLXmrxYjzLlJRY6EmZaqCLgxWgL9U8rnNM82CuD5+v00s+B6rNvhV7DPY+SM/In0cx92oRHang+R5hgiMyIoI03Er7sc1TlPZR1iVeAwzuvIEvF9C4WSriAJSEApEzC3cWtkrbRBgt8eqLi9xL3BeA9Kbd7cnR5KgY6zYIlVUmUnvVQBVLUguDohOJZ1kNXXcLNNTXApPp6UZWv5S0RCzCWXj7dZN2f+2sEIzoBUhRFGhPhJgcz/K46YNuJd3tRQJ3Fbspb7ltrO3iFFpHycdLAV6I/HFHU0o9f3goBe9a580t/xnmKSCAJabYVqtcYkAR91gr294fYuGs6Y= x-originating-ip: [10.162.93.230] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_031F_01CC7D3A.2F5B75C0" MIME-Version: 1.0 X-OriginalArrivalTime: 27 Sep 2011 14:23:43.0776 (UTC) FILETIME=[0FB42A00:01CC7D21] X-Nokia-AV: Clean Cc: softwires@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2011 14:21:09 -0000 ------=_NextPart_000_031F_01CC7D3A.2F5B75C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > > I don't understand why that is significant enough factor for IETF to > > (not) > > recommend some double translation variants. I mean does existing > > applications work better if double translation is done in > > deterministic manner? > > Yes, it allows the CPE to implement an ALG -- if an application needs an ALG > (e.g., active-mode FTP). Good point, but still in my eyes that does not count as too significant factor, as it is impossible to have a generic ALG and I've understood ALGs in CPEs are not very much desired? So.. then.. is this sentence really still the IETF recommendation in the current state of affairs: -- IETF recommends using dual-stack or tunneling based solutions for IPv6 transition and specifically recommends against deployments utilizing double protocol translation. -- Teemu ------=_NextPart_000_031F_01CC7D3A.2F5B75C0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTI3MTQyMzM0WjAjBgkqhkiG9w0B CQQxFgQUD3imdtis4mtmudU3zEp6GGvfKCgwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAIABqpsxLUNZW2MkX2ka 4WZgAdynQ+Go0WyIgM2IFqLeKgp2xNABXc+yJCeQRAnLkc5U7ETYGtrNHfDT+lBXU9Le3Z8LRs48 YSA3UAme8NhfYGqUwZ4iUOvinuaEEjNgpYpE5IQmoszE3gSLD3IK9Q/ixdnSpzb8PCIu9sgmvbym VETftwjYXfeOL9pbn7FKc5N1lmZqlwAK23rJtophjvOyrxxb/3uZ9iGTyfczdXh3qkpSFK6X4J1Q h7jvdwCys2ZzddwX636hYLkI9CvcNpkRRIkbRUzq55QttF+31ZbYkeFg9BMWzEzjCPAGan3IgIn0 GvEjSKtP1yDrgVcq3UYAAAAAAAA= ------=_NextPart_000_031F_01CC7D3A.2F5B75C0-- From dwing@cisco.com Tue Sep 27 07:54:51 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE25621F8D72; Tue, 27 Sep 2011 07:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.077 X-Spam-Level: X-Spam-Status: No, score=-103.077 tagged_above=-999 required=5 tests=[AWL=-0.478, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtvUrbXg9eAu; Tue, 27 Sep 2011 07:54:50 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id DA5C421F8D67; Tue, 27 Sep 2011 07:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1464; q=dns/txt; s=iport; t=1317135454; x=1318345054; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=EG4GErkSOUxqAjp1yjKl/pGIJcXIcRyEG/+WV7CSq7k=; b=cAH9J4o8wSj15+JV8qARU+AnzU4iSHYeuJOTLyCIzimwghVw+5QRMIxj VmgrDvddSTA/Igch9V0SedoF1W9Fjtbl9a3zo0AfOmmsWjIk3q1AI+xgw N6KsXHai8Ks2c6R8zPPioct9+EoObwmDc1wWGiu87iN380MEA5KtEYfZA 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIAANzjgU6rRDoG/2dsb2JhbABBmHaBbI0aeIFTAQEBAwEICgEXED8FBwEDAgkPAgQBASQEBxkIGwoJCAEBBAESCxAHh1abdgGeJ4cLBIdylXiHPA X-IronPort-AV: E=Sophos;i="4.68,449,1312156800"; d="scan'208";a="4554408" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 27 Sep 2011 14:57:32 +0000 Received: from dwingWS ([10.89.10.9]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8REvURr007641; Tue, 27 Sep 2011 14:57:31 GMT From: "Dan Wing" To: , , References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> <916CE6CF87173740BC8A2CE44309696203771FAB@008-AM1MPN1-037.mgdnok.nokia.com> <09bd01cc7d16$cd715190$6853f4b0$@com> <916CE6CF87173740BC8A2CE4430969620377279D@008-AM1MPN1-037.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE4430969620377279D@008-AM1MPN1-037.mgdnok.nokia.com> Date: Tue, 27 Sep 2011 07:57:30 -0700 Message-ID: <0a4601cc7d25$c8bc7e40$5a357ac0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acx8XrGT3LPZ/umGSqyAQmFBTGHJTgATRZdAAAwNkVAADptiEAACIkfAAAGugYA= Content-Language: en-us Cc: softwires@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2011 14:54:51 -0000 > -----Original Message----- > From: teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com] > Sent: Tuesday, September 27, 2011 7:24 AM > To: dwing@cisco.com; satoru.matsushima@gmail.com; ietf@ietf.org > Cc: softwires@ietf.org; behave@ietf.org > Subject: RE: [BEHAVE] Last Call: > (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard > > > > I don't understand why that is significant enough factor for IETF > to > > > (not) > > > recommend some double translation variants. I mean does existing > > > applications work better if double translation is done in > > > deterministic manner? > > > > Yes, it allows the CPE to implement an ALG -- if an application needs > an > ALG > > (e.g., active-mode FTP). > > Good point, but still in my eyes that does not count as too significant > factor, as it is impossible to have a generic ALG and I've understood > ALGs in CPEs are not very much desired? Yes, it is impossible to build a successful 'generic' ALG which fixes up all protocols. ALGs need to be specific to each application they're trying to 'fix'. > So.. then.. is this sentence really still the IETF recommendation in > the > current state of affairs: > -- > IETF recommends using dual-stack or tunneling based solutions for > IPv6 transition and specifically recommends against deployments > utilizing double protocol translation. > -- -d From dwing@cisco.com Tue Sep 27 17:00:04 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0236221F8CBE for ; Tue, 27 Sep 2011 17:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.05 X-Spam-Level: X-Spam-Status: No, score=-103.05 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prMW0FPix8OF for ; Tue, 27 Sep 2011 17:00:03 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 64D2121F8C5D for ; Tue, 27 Sep 2011 17:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=480; q=dns/txt; s=iport; t=1317168170; x=1318377770; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=eBDLOfn4HaXgL5s1I8Rkio3/x1XYfQ+p98TcrjkLeto=; b=WZ22oB8fzKLTbpW3Q6KP7uxWKk4e76MvOxkqGTaIHxAbxYecij/DgEHP ag1A6jV7iT9TOD260hqUUliLP4iMubBs2owZuhcMR+H1ZCQm+hJNgpLAP 2FChtkeofKJAmqSYm4Wr1dXPg/l54GuoWrdk38zlLILiEv7sdFrpDA4pX g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkGAAtkgk6rRDoI/2dsb2JhbABBmT6BKY0beIFaCAoBFQIQNAsNBRhQIwoSAQQTCxeiZgGeIIcLBIdynTQ X-IronPort-AV: E=Sophos;i="4.68,452,1312156800"; d="scan'208";a="4658334" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 28 Sep 2011 00:02:39 +0000 Received: from dwingWS (rcdn-vpn-client-10-89-7-226.cisco.com [10.89.7.226]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8S02ceu008842; Wed, 28 Sep 2011 00:02:39 GMT From: "Dan Wing" To: Date: Tue, 27 Sep 2011 17:02:38 -0700 Message-ID: <003c01cc7d71$efbc4010$cf34c030$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acx9ce8CjQWRmdE+TtelErQ7nsHzVg== Content-Language: en-us Cc: behave-chairs@tools.ietf.org Subject: [BEHAVE] presentations at IETF82 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2011 00:00:04 -0000 We requested a 2 hour slot for BEHAVE. If you would like to present in BEHAVE at IETF82, please send to behave-chairs@tools.ietf.org: - topic title - presenter's name - Internet Draft filename(s) - time requested We will give priority to: 1. working group items 2. items actively discussed on the mailing list 3. new topics Please send the request by October 24th, which is also the cutoff date for initial Internet Drafts (-00). -Dan and Dave From marc.blanchet@viagenie.ca Tue Sep 27 17:19:34 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D974421F8DFB for ; Tue, 27 Sep 2011 17:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.68 X-Spam-Level: X-Spam-Status: No, score=-102.68 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0h5FA6VmWck for ; Tue, 27 Sep 2011 17:19:34 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 4411321F8D59 for ; Tue, 27 Sep 2011 17:19:34 -0700 (PDT) Received: from [IPv6:2607:fa48:6e6b:c280:291d:6afc:237d:df8a] (unknown [IPv6:2607:fa48:6e6b:c280:291d:6afc:237d:df8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 89BE420CF1; Tue, 27 Sep 2011 20:22:20 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: <003c01cc7d71$efbc4010$cf34c030$@com> Date: Tue, 27 Sep 2011 20:22:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <003c01cc7d71$efbc4010$cf34c030$@com> To: "Dan Wing" X-Mailer: Apple Mail (2.1244.3) Cc: behave@ietf.org, behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] presentations at IETF82 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2011 00:19:35 -0000 Dan, I'm puzzled. Behave was shutting down. And then out of the blue, a = meeting. Can you explain in general, and also in this context, what = means "working group items"? Marc. Le 2011-09-27 =E0 20:02, Dan Wing a =E9crit : > We requested a 2 hour slot for BEHAVE. >=20 > If you would like to present in BEHAVE at IETF82, please send to > behave-chairs@tools.ietf.org: > - topic title > - presenter's name > - Internet Draft filename(s) > - time requested >=20 > We will give priority to: > 1. working group items > 2. items actively discussed on the mailing list > 3. new topics >=20 > Please send the request by October 24th, which is also the cutoff > date for initial Internet Drafts (-00). >=20 > -Dan and Dave >=20 >=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Tue Sep 27 18:36:21 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA0E21F8DFC for ; Tue, 27 Sep 2011 18:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.044 X-Spam-Level: X-Spam-Status: No, score=-103.044 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmOHeqzTILhK for ; Tue, 27 Sep 2011 18:36:20 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCF421F8DFA for ; Tue, 27 Sep 2011 18:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3354; q=dns/txt; s=iport; t=1317173947; x=1318383547; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Qo/BNpGrJZ1Im7vF+c51BwjMvU25Hjqj7pFY9fNBba8=; b=Ze3EcK+JIrf4xWgdFOCqpHT12h4bsD/eKtVr/xs1t82mKhIIwYjoQX0s cueNVgseAfKkQqz9QizxMOGHan5Qye2ozNl/UI6wFwKTkCZujCTLZ3dB0 be1lr8pXpET3WCNiUkF1NSlqcyiz7SfDlU1aXjR1DbVJycEkTp6FcqCpW w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEAAO15gk6rRDoH/2dsb2JhbABBmHyBbI0beIFTAQEBAQIBAQEBBQoBFQJECwUHAQMCCQ8CBAEBKAcZDhUKCQgBAQQTCxeHVgaabgGeHgOHCwSHQjCdNA X-IronPort-AV: E=Sophos;i="4.68,452,1312156800"; d="scan'208";a="4663940" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 28 Sep 2011 01:39:07 +0000 Received: from dwingWS (rcdn-vpn-client-10-89-7-226.cisco.com [10.89.7.226]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8S1d6b0031641; Wed, 28 Sep 2011 01:39:06 GMT From: "Dan Wing" To: "'Marc Blanchet'" References: <003c01cc7d71$efbc4010$cf34c030$@com> In-Reply-To: Date: Tue, 27 Sep 2011 18:39:06 -0700 Message-ID: <006401cc7d7f$69a632c0$3cf29840$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acx9dLE6mitJyDqPRuGia1nFpogrDwABQ+yg Content-Language: en-us Cc: behave@ietf.org, behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] presentations at IETF82 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2011 01:36:21 -0000 > -----Original Message----- > From: Marc Blanchet [mailto:marc.blanchet@viagenie.ca] > Sent: Tuesday, September 27, 2011 5:22 PM > To: Dan Wing > Cc: behave@ietf.org; behave-chairs@tools.ietf.org > Subject: Re: [BEHAVE] presentations at IETF82 >=20 > Dan, I'm puzzled. Behave was shutting down. And then out of the blue, = a > meeting. Can you explain in general, and also in this context, what > means "working group items"? Yes. Let me explain from my perspective what I see happening with BEHAVE: BEHAVE is at an inflection point -- we are changing direction. We have completed our initial work (STUN, TURN, multicast/TCP/UDP/ICMP behavior documents) and completed what might be called our=20 "NAT-PTbis" work (the document set related to NAT64/DNS64). As you all recall, we had very little discussion on the list prior to IETF81, which is why we had allocated only an hour. Participant=20 energy was going away because we had completed our major milestones. So, we asked if we could close BEHAVE. We spent about half of our meeting time at IETF81 talking about the future of BEHAVE rather=20 than discussing documents. After IETF81, the chairs built a list of I-Ds that had been=20 proposed into the working group, and have shared that with=20 David Harrington, our AD. Some of these documents seem like they=20 fit into BEHAVE's existing charter and some don't. David Harrington is currently on vacation, and will return from=20 vacation next week. I don't know what he will decide. I=20 know that activity on the Behave mailing list and updated=20 documents will likely keep the working group energized and=20 keep the chairs energized. And I would expect such activity=20 will also keep the working group open. =20 To answer your specific question: In the spirit of keeping=20 things moving along, I had requested more agenda time (two hours)=20 than we had at IETF81 (one hour) and I sent out the 'presentations=20 for IETF82' email to ensure existing work continues and that=20 we learn of new work (-00 or updates to existing documents)=20 that is aimed at BEHAVE. This will provide additional input to David Harrington to decide if Behave should have additional milestones, charter update, or be closed. With multicast translation and the Mon/Tue Softwire interim in Beijing (which I did not attend, but I know included=20 discussions on double translation (Dual-IVI)), there may well be more work coming towards Behave, towards Softwire, another working group, or a new working group. -d > Marc. >=20 > Le 2011-09-27 =E0 20:02, Dan Wing a =E9crit : >=20 > > We requested a 2 hour slot for BEHAVE. > > > > If you would like to present in BEHAVE at IETF82, please send to > > behave-chairs@tools.ietf.org: > > - topic title > > - presenter's name > > - Internet Draft filename(s) > > - time requested > > > > We will give priority to: > > 1. working group items > > 2. items actively discussed on the mailing list > > 3. new topics > > > > Please send the request by October 24th, which is also the cutoff > > date for initial Internet Drafts (-00). > > > > -Dan and Dave > > > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave From denghui02@gmail.com Wed Sep 28 02:48:19 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F155C21F8CE7; Wed, 28 Sep 2011 02:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.504 X-Spam-Level: X-Spam-Status: No, score=-103.504 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfHssqImZCiv; Wed, 28 Sep 2011 02:48:17 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB9E21F8CCA; Wed, 28 Sep 2011 02:48:11 -0700 (PDT) Received: by wyh21 with SMTP id 21so6734469wyh.31 for ; Wed, 28 Sep 2011 02:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=83HreAfpVmXQI7Li9kMhqirgt2a0yfLDeCm2mhAnnz0=; b=kX7joaalyoHeuiuIvBj6x1PVBdQi7C0cWRxZ8nyZhuv/2h5CDLn0S+h8/jJNB50X7L gjCNyeKmnbkz6YMg8t87Pb+EzEsbsHYMqd5gvLykP7TUBxnd54TZCTyYg+dQyev9QBtL izrqCqfsdkP1KXA/AVwqq1tFNwIQmxHgm8DXw= MIME-Version: 1.0 Received: by 10.216.184.66 with SMTP id r44mr9859085wem.109.1317203457341; Wed, 28 Sep 2011 02:50:57 -0700 (PDT) Received: by 10.216.166.202 with HTTP; Wed, 28 Sep 2011 02:50:57 -0700 (PDT) In-Reply-To: <09b701cc7d16$6943df30$3bcb9d90$@com> References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> <09b701cc7d16$6943df30$3bcb9d90$@com> Date: Wed, 28 Sep 2011 17:50:57 +0800 Message-ID: From: Hui Deng To: Dan Wing Content-Type: multipart/alternative; boundary=001485f1dbbc2bf90204adfd5473 Cc: softwires@ietf.org, behave@ietf.org, satoru.matsushima@gmail.com, ietf@ietf.org Subject: Re: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2011 09:48:19 -0000 --001485f1dbbc2bf90204adfd5473 Content-Type: text/plain; charset=ISO-8859-1 Hi Dan, Inline please, 2011/9/27 Dan Wing > > -----Original Message----- > > From: Hui Deng [mailto:denghui02@gmail.com] > > Sent: Monday, September 26, 2011 11:01 PM > > To: Dan Wing > > Cc: teemu.savolainen@nokia.com; satoru.matsushima@gmail.com; > > ietf@ietf.org; softwires@ietf.org; behave@ietf.org > > Subject: Re: [BEHAVE] Last Call: > > (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard > > > > Hi Dan > > > > inline please, > > > > > > I believe the objection is against "non-deterministic > > translation", > > rather than stateful versus stateless. By non-deterministic, I > > mean > > that the subscriber's equipment (e.g., CPE) cannot determine the > > mapping it will have on the Internet. A+P mechanisms are > > > > > > Could you help be more elaboration on CPE can't determine the ampping? > > It can't determine the public IP address and port of a mapping on the > NAT64 (CGN), and it can't create a mapping on the NAT64 (CGN) -- because > the CGN is going to make a dynamic mapping when it sees a UDP, TCP, > or ICMP packet from the subscriber. > I don't see it matters > > > deterministic (including 4rd, Dual-IVI, and draft-ymbk-aplus-p). > > > > > > By the way, I would say you are missing one early draft: > > http://tools.ietf.org/html/draft-murakami-softwire-4v6-translation-00 > > which is align with 4rd about 4v6 translation which has been > > contributed by major operators which is also align with NAT64 > > deployment. > > Sorry. > > -d > > > > -Hui > > > > > > > > > > A stateful CGN, as commonly deployed, is not deterministic. > > > > However -- and this is my point in this email -- a stateful CGN > > can be configured and deployed so that it deterministically maps > > traffic. That is, it can function very much like A+P/4rd/Dual- > > IVI > > so that port "N" from subscriber "A" is always mapped to public > > port "Z" on IPv4 address "Y". We could have the CPE know about > > that fixed mapping using the same DHCP options that A+P/4rd/ > > Dual-IVI would use, or use PCP, or use some other protocol. > > > > -d > > > > > > > I would assume softwires follows these same IETF guidelines and > > > therefore is > > > now focusing solely on stateless approaches(?). If the IETF > > opinion has > > > changed so that also stateful double translation solutions are > > now ok > > > for > > > IETF, then that should perhaps be reflected in this document as > > well. > > > > > > Unfortunately, I did not have chance to go to softwires > > interim, but > > > please > > > let us know if the discussions there impact also the quoted > > > recommendation. > > > > > > Best regards, > > > > > > Teemu > > > > > > > -----Original Message----- > > > > From: behave-bounces@ietf.org [mailto:behave- > > bounces@ietf.org] On > > > > Behalf Of ext Satoru Matsushima > > > > Sent: 13. syyskuuta 2011 06:51 > > > > To: ietf@ietf.org > > > > Cc: behave@ietf.org; Satoru Matsushima > > > > Subject: Re: [BEHAVE] Last Call: > 06.txt> > > > (Dual > > > > Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed > > Standard > > > > > > > > The introduction in the draft says: > > > > > > > > > > > > > IETF recommends using dual-stack or tunneling based > > solutions for > > > > > IPv6 transition and specifically recommends against > > deployments > > > > > utilizing double protocol translation. Use of BIH > > together with > > > a > > > > > NAT64 is NOT RECOMMENDED [RFC6180]. > > > > > > > > > > > > > > > > > This statement makes a strong obstacle when we develop > > stateless > > > solution > > > > with translation in softwires wg. > > > > I think that it is still remained a room to make decision > > whether > > > removing > > > the > > > > statement or remaining it. > > > > The discussion which we'll have in the softwires interim > > meeting > > > would be > > > > helpful to decide it. > > > > > > > > Best regards, > > > > --satoru > > > > > > > > > > > > > > > > On 2011/08/31, at 22:53, The IESG wrote: > > > > > > > > > > > > > > The IESG has received a request from the Behavior > > Engineering for > > > > > Hindrance Avoidance WG (behave) to consider the following > > document: > > > > > - 'Dual Stack Hosts Using "Bump-in-the-Host" (BIH)' > > > > > 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 2011-09-14. 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. > > > > > > > > > > Abstract > > > > > > > > > > > > > > > Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 > > protocol > > > > > translation mechanism that allows a class of IPv4-only > > > applications > > > > > that work through NATs to communicate with IPv6-only > > peers. The > > > host > > > > > on which applications are running may be connected to > > IPv6-only > > > or > > > > > dual-stack access networks. BIH hides IPv6 and makes the > > IPv4- > > > only > > > > > applications think they are talking with IPv4 peers by > > local > > > > > synthesis of IPv4 addresses. This draft obsoletes RFC > > 2767 and > > > RFC > > > > > 3338. > > > > > > > > > > > > > > > > > > > > > > > > > The file can be obtained via > > > > > http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ > > > > > > > > > > IESG discussion can be tracked via > > > > > http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ > > > > > > > > > > > > > > > No IPR declarations have been submitted directly on this I- > > D. > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > --001485f1dbbc2bf90204adfd5473 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dan,
=A0
Inline please,

2011/9/27 Dan Wing <dwing@cisco.com>
> -----Original Message-----<= br>> From: Hui Deng [mailto:dengh= ui02@gmail.com]
> Sent: Monday, September 26, 2011 11:01 PM
> To: Dan Wing
>= Cc: teemu.savolainen@nokia.c= om; satoru.matsushima@gm= ail.com;
> ietf@ietf.org; softwires@ietf.org; behave@ietf.org
> Subject: Re: [BEHAVE] Last Call: <draft-ietf-beha= ve-v4v6-bih-06.txt>
> (Dual Stack Hosts Using "Bump-in-the-Ho= st" (BIH)) to Proposed Standard
>
> Hi Dan
>
> inline please,
>
>= ;
> =A0 =A0 =A0 I believe the objection is against "non-determin= istic
> translation",
> =A0 =A0 =A0 rather than stateful v= ersus stateless. =A0By non-deterministic, I
> mean
> =A0 =A0 =A0 that the subscriber's equipment (e.g., CP= E) cannot determine the
> =A0 =A0 =A0 mapping it will have on the Int= ernet. =A0A+P mechanisms are
>
>
> Could you help be more= elaboration on CPE can't determine the ampping?

It can't determine the public IP address and port of a mappin= g on the
NAT64 (CGN), and it can't create a mapping on the NAT64 (CG= N) -- because
the CGN is going to make a dynamic mapping when it sees a = UDP, TCP,
or ICMP packet from the subscriber.
I don't see it matters
=A0

> =A0 =A0 =A0 deterministic (including 4rd, Dual-I= VI, and draft-ymbk-aplus-p).
>
>
> By the way, I would sa= y you are missing one early draft:
> http://= tools.ietf.org/html/draft-murakami-softwire-4v6-translation-00
> which is align with 4rd =A0about 4v6 translation which has been
>= ; contributed by major operators which is also align with NAT64
> dep= loyment.

Sorry.

-d


> -Hui
>
>
>
>
>= =A0 =A0 =A0 A stateful CGN, as commonly deployed, is not deterministic.>
> =A0 =A0 =A0 However -- and this is my point in this email -- = a stateful CGN
> =A0 =A0 =A0 can be configured and deployed so that it deterministicall= y maps
> =A0 =A0 =A0 traffic. =A0That is, it can function very much l= ike A+P/4rd/Dual-
> IVI
> =A0 =A0 =A0 so that port "N"= ; from subscriber "A" is always mapped to public
> =A0 =A0 =A0 port "Z" on IPv4 address "Y". =A0We co= uld have the CPE know about
> =A0 =A0 =A0 that fixed mapping using th= e same DHCP options that A+P/4rd/
> =A0 =A0 =A0 Dual-IVI would use, o= r use PCP, or use some other protocol.
>
> =A0 =A0 =A0 -d
>
>
> =A0 =A0 =A0 > I woul= d assume softwires follows these same IETF guidelines and
> =A0 =A0 = =A0 > therefore is
> =A0 =A0 =A0 > now focusing solely on state= less approaches(?). If the IETF
> opinion has
> =A0 =A0 =A0 > changed so that also stateful dou= ble translation solutions are
> now ok
> =A0 =A0 =A0 > for> =A0 =A0 =A0 > IETF, then that should perhaps be reflected in this= document as
> well.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Unfortunately,= I did not have chance to go to softwires
> interim, but
> =A0 = =A0 =A0 > please
> =A0 =A0 =A0 > let us know if the discussions= there impact also the quoted
> =A0 =A0 =A0 > recommendation.
> =A0 =A0 =A0 >
> =A0 = =A0 =A0 > Best regards,
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >= ; =A0 =A0 =A0 Teemu
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > > = -----Original Message-----
> =A0 =A0 =A0 > > From: behave-bounces@ietf.org [mailto:behave-
> bounces@ietf.org] On
> = =A0 =A0 =A0 > > Behalf Of ext Satoru Matsushima
> =A0 =A0 =A0 &= gt; > Sent: 13. syyskuuta 2011 06:51
> =A0 =A0 =A0 > > To: <= a href=3D"mailto:ietf@ietf.org">ietf@ietf.org
> =A0 =A0 =A0 > > Cc: behave@ie= tf.org; Satoru Matsushima
> =A0 =A0 =A0 > > Subject: Re: [B= EHAVE] Last Call: <draft-ietf-behave-v4v6-bih-
> 06.txt>
>= ; =A0 =A0 =A0 > (Dual
> =A0 =A0 =A0 > > Stack Hosts Using "Bump-in-the-Host" (= BIH)) to Proposed
> Standard
> =A0 =A0 =A0 > >
> = =A0 =A0 =A0 > > The introduction in the draft says:
> =A0 =A0 = =A0 > >
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > > =A0 IETF recommends using dual-stack or tun= neling based
> solutions for
> =A0 =A0 =A0 > > > =A0 = =A0IPv6 transition and specifically recommends against
> deployments<= br>> =A0 =A0 =A0 > > > =A0 =A0utilizing double protocol transla= tion. =A0Use of BIH
> together with
> =A0 =A0 =A0 > a
> =A0 =A0 =A0 > >= > =A0 =A0NAT64 is NOT RECOMMENDED [RFC6180].
> =A0 =A0 =A0 > &= gt; >
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > >
>= ; =A0 =A0 =A0 > > This statement makes a strong obstacle when we deve= lop
> stateless
> =A0 =A0 =A0 > solution
> =A0 =A0 =A0 > &= gt; with translation in softwires wg.
> =A0 =A0 =A0 > > I think= that it is still remained a room to make decision
> whether
> = =A0 =A0 =A0 > removing
> =A0 =A0 =A0 > the
> =A0 =A0 =A0 > > statement or remain= ing it.
> =A0 =A0 =A0 > > The discussion which we'll have i= n the softwires interim
> meeting
> =A0 =A0 =A0 > would be> =A0 =A0 =A0 > > helpful to decide it.
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > Best regards,
&= gt; =A0 =A0 =A0 > > --satoru
> =A0 =A0 =A0 > >
> = =A0 =A0 =A0 > >
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 >= ; > On 2011/08/31, at 22:53, The IESG wrote:
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > >
> =A0 = =A0 =A0 > > > The IESG has received a request from the Behavior> Engineering for
> =A0 =A0 =A0 > > > Hindrance Avoidanc= e WG (behave) to consider the following
> document:
> =A0 =A0 =A0 > > > - 'Dual Stack Hosts U= sing "Bump-in-the-Host" (BIH)'
> =A0 =A0 =A0 > > = > =A0<draft-ietf-behave-v4v6-bih-06.txt> as a Proposed Standard> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > > The IESG plans to make a decision in the ne= xt few weeks,
> and
> =A0 =A0 =A0 > solicits
> =A0 =A0= =A0 > > > final comments on this action. Please send substantive<= br>> comments to
> =A0 =A0 =A0 > the
> =A0 =A0 =A0 > > > ietf@ietf.org mailing lists by 2011-09-14. Exception= ally,
> comments
> =A0 =A0 =A0 > may
> =A0 =A0 =A0 >= ; > > be sent to iesg@ietf.org i= nstead. In either case, please
> retain the
> =A0 =A0 =A0 > > > beginning of the Subject= line to allow automated sorting.
> =A0 =A0 =A0 > > >
>= ; =A0 =A0 =A0 > > > Abstract
> =A0 =A0 =A0 > > >> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > > =A0 Bump-In-the-Host (BIH) is a host-based = IPv4 to IPv6
> protocol
> =A0 =A0 =A0 > > > =A0 transl= ation mechanism that allows a class of IPv4-only
> =A0 =A0 =A0 > a= pplications
> =A0 =A0 =A0 > > > =A0 that work through NATs t= o communicate with IPv6-only
> peers. =A0The
> =A0 =A0 =A0 > host
> =A0 =A0 =A0 > &= gt; > =A0 on which applications are running may be connected to
> = IPv6-only
> =A0 =A0 =A0 > or
> =A0 =A0 =A0 > > > = =A0 dual-stack access networks. =A0BIH hides IPv6 and makes the
> IPv4-
> =A0 =A0 =A0 > only
> =A0 =A0 =A0 > > >= =A0 applications think they are talking with IPv4 peers by
> local> =A0 =A0 =A0 > > > =A0 synthesis of IPv4 addresses. =A0This = draft obsoletes RFC
> 2767 and
> =A0 =A0 =A0 > RFC
> =A0 =A0 =A0 > > &g= t; =A0 3338.
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > &g= t; >
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > &g= t;
> =A0 =A0 =A0 > > > The file can be obtained via
> =A0 =A0 =A0 > > > http://datatracker.ietf.org/= doc/draft-ietf-behave-v4v6-bih/
> =A0 =A0 =A0 > > >
&= gt; =A0 =A0 =A0 > > > IESG discussion can be tracked via
> =A0 =A0 =A0 > > > http://datatracker.ietf.org/= doc/draft-ietf-behave-v4v6-bih/
> =A0 =A0 =A0 > > >
&= gt; =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > > No IPR declarations have been submitted dir= ectly on this I-
> D.
> =A0 =A0 =A0 > > >
> =A0 = =A0 =A0 > > >
> =A0 =A0 =A0 > > > _________________= ______________________________
> =A0 =A0 =A0 > > > Behave mailing list
> =A0 =A0 =A0 >= ; > > Behave@ietf.org
> = =A0 =A0 =A0 > > > https://www.ietf.org/mailman/listinfo/behave=
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > __________________= _____________________________
> =A0 =A0 =A0 > > Behave mailing = list
> =A0 =A0 =A0 > > Behav= e@ietf.org
> =A0 =A0 =A0 > > https://www.ietf.org/mailman/l= istinfo/behave
>
> =A0 =A0 =A0 _______________________________________________> =A0 =A0 =A0 Behave mailing list
> =A0 =A0 =A0 Behave@ietf.org
> =A0 =A0 =A0 https://www.ietf.= org/mailman/listinfo/behave
>
>



--001485f1dbbc2bf90204adfd5473-- From denghui02@gmail.com Wed Sep 28 02:49:07 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4B821F8D23; Wed, 28 Sep 2011 02:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.507 X-Spam-Level: X-Spam-Status: No, score=-103.507 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmBSoo9tDtSz; Wed, 28 Sep 2011 02:49:06 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1212521F8CCA; Wed, 28 Sep 2011 02:49:05 -0700 (PDT) Received: by wwf22 with SMTP id 22so5771472wwf.13 for ; Wed, 28 Sep 2011 02:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TpAZr0GpvEnHFR0yv8Lk5dwFRtD7LAAemVi1af9us3Q=; b=xYCxTasq1feweXX5SUARnjij2STVKJaODafPImrjHQMNFVau/vNs6RUEDr2OUYljLU /f/keQeXo6A4QV9w7fGW44y988z52c0CFoBS0aKzdFLtcdtr2qH+voLwEPIVSSiHDvQi xyv+AiKJy0nwk/g7Pudo+TPRzAqRfDJNyLeNw= MIME-Version: 1.0 Received: by 10.216.6.211 with SMTP id 61mr9732511wen.94.1317203513305; Wed, 28 Sep 2011 02:51:53 -0700 (PDT) Received: by 10.216.166.202 with HTTP; Wed, 28 Sep 2011 02:51:53 -0700 (PDT) In-Reply-To: <09bd01cc7d16$cd715190$6853f4b0$@com> References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> <916CE6CF87173740BC8A2CE44309696203771FAB@008-AM1MPN1-037.mgdnok.nokia.com> <09bd01cc7d16$cd715190$6853f4b0$@com> Date: Wed, 28 Sep 2011 17:51:53 +0800 Message-ID: From: Hui Deng To: Dan Wing Content-Type: multipart/alternative; boundary=0016364c776581e98d04adfd578b Cc: softwires@ietf.org, behave@ietf.org, satoru.matsushima@gmail.com, ietf@ietf.org Subject: Re: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2011 09:49:07 -0000 --0016364c776581e98d04adfd578b Content-Type: text/plain; charset=ISO-8859-1 inline please, 2011/9/27 Dan Wing > > -----Original Message----- > > From: teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com] > > Sent: Monday, September 26, 2011 11:14 PM > > To: dwing@cisco.com; satoru.matsushima@gmail.com; ietf@ietf.org > > Cc: softwires@ietf.org; behave@ietf.org > > Subject: RE: [BEHAVE] Last Call: > > (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard > > > > > I believe the objection is against "non-deterministic translation", > > rather > > than > > > stateful versus stateless. By non-deterministic, I mean that the > > subscriber's > > > equipment (e.g., CPE) cannot determine the mapping it will have on > > the > > > Internet. A+P mechanisms are deterministic (including 4rd, Dual-IVI, > > and > > > draft-ymbk-aplus-p). > > > > > > A stateful CGN, as commonly deployed, is not deterministic. > > > > I don't understand why that is significant enough factor for IETF to > > (not) > > recommend some double translation variants. I mean does existing > > applications work better if double translation is done in deterministic > > manner? > > Yes, it allows the CPE to implement an ALG -- if an application needs > an ALG (e.g., active-mode FTP). > Are you saying distrbiuted ALG is much better than centralized ALG? -Hui > > -d > > > One reasoning against double translation has been that it > > breaks > > some class of applications. Is it now so that some forms of double > > translation do not break applications while some others do? > > > > Teemu > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > --0016364c776581e98d04adfd578b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable inline please,

2011/9/27 Dan Wing <dwing@cisco.com>
> -----Original Message-----
> From: teemu.savolainen@nokia.com [mailto:<= a href=3D"mailto:teemu.savolainen@nokia.com">teemu.savolainen@nokia.com= ]
> Sent: Monday, September 26, 2011 11:14 PM
> To: dwing@cisco.com; satoru.matsushima@gmail.com; ietf@ietf.org
> Cc: softwires@ietf.org; behave@ietf.org
> Subject: RE: [BE= HAVE] Last Call: <draft-ietf-behave-v4v6-bih-06.txt>
> (Dual St= ack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard >
> > I believe the objection is against "non-de= terministic translation",
> rather
> than
> > sta= teful versus stateless. =A0By non-deterministic, I mean that the
> su= bscriber's
> > equipment (e.g., CPE) cannot determine the mapping it will have o= n
> the
> > Internet. =A0A+P mechanisms are deterministic (i= ncluding 4rd, Dual-IVI,
> and
> > draft-ymbk-aplus-p).
> >
> > A stateful CGN, as commonly deployed, is not determi= nistic.
>
> I don't understand why that is significant enou= gh factor for IETF to
> (not)
> recommend some double translati= on variants. I mean does existing
> applications work better if double translation is done in deterministi= c
> manner?

Yes, it allows the CPE to implement an ALG -= - if an application needs
an ALG (e.g., active-mode FTP).

Are you saying distrbiuted ALG is much better than centralized ALG= ?
=A0
-Hui
=A0

-d

> One reasoning against double translation has bee= n that it
> breaks
> some class of applications. Is it now so t= hat some forms of double
> translation do not break applications whil= e some others do?
>
> =A0 =A0 =A0 Teemu
>

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

--0016364c776581e98d04adfd578b-- From cb.list6@gmail.com Wed Sep 28 08:13:25 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4F51F0C49; Wed, 28 Sep 2011 08:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.415 X-Spam-Level: X-Spam-Status: No, score=-3.415 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtolQNbf92Vf; Wed, 28 Sep 2011 08:13:24 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 39CEF1F0C4A; Wed, 28 Sep 2011 08:13:24 -0700 (PDT) Received: by iaby26 with SMTP id y26so8725871iab.31 for ; Wed, 28 Sep 2011 08:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NkkxYVDRM2wc4zLD9ZXGX7wbsh8ThKXIAtlRCMuzYFA=; b=v8W5KLFfbNMxvZ/wfcpsKwfYy086FX5jtI6TN7VJo3WZD+fVDK63oEFe0p9sqIY5cR Lo7CHKYV6PVgRJEW1E+cnptM3TpVHJEhxcFVRoKR7lgg2Jul3TBYO61PSnEYKtFdQ3N3 qrQQRh3VevIwfREYB7OqnslcjdfrNXeL/GSiw= MIME-Version: 1.0 Received: by 10.68.15.194 with SMTP id z2mr44610438pbc.47.1317222961042; Wed, 28 Sep 2011 08:16:01 -0700 (PDT) Received: by 10.142.89.1 with HTTP; Wed, 28 Sep 2011 08:16:00 -0700 (PDT) Received: by 10.142.89.1 with HTTP; Wed, 28 Sep 2011 08:16:00 -0700 (PDT) In-Reply-To: References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> <09b701cc7d16$6943df30$3bcb9d90$@com> Date: Wed, 28 Sep 2011 08:16:00 -0700 Message-ID: From: Cameron Byrne To: Hui Deng Content-Type: multipart/alternative; boundary=bcaec51f995faed39704ae01de50 Cc: softwires@ietf.org, behave@ietf.org, ietf@ietf.org, Dan Wing Subject: Re: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2011 15:13:25 -0000 --bcaec51f995faed39704ae01de50 Content-Type: text/plain; charset=ISO-8859-1 On Sep 28, 2011 2:51 AM, "Hui Deng" wrote: > > Hi Dan, > > Inline please, > > 2011/9/27 Dan Wing >> >> > -----Original Message----- >> > From: Hui Deng [mailto:denghui02@gmail.com] >> > Sent: Monday, September 26, 2011 11:01 PM >> > To: Dan Wing >> > Cc: teemu.savolainen@nokia.com; satoru.matsushima@gmail.com; >> > ietf@ietf.org; softwires@ietf.org; behave@ietf.org >> > Subject: Re: [BEHAVE] Last Call: >> > (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard >> > >> > Hi Dan >> > >> > inline please, >> > >> > >> > I believe the objection is against "non-deterministic >> > translation", >> > rather than stateful versus stateless. By non-deterministic, I >> > mean >> > that the subscriber's equipment (e.g., CPE) cannot determine the >> > mapping it will have on the Internet. A+P mechanisms are >> > >> > >> > Could you help be more elaboration on CPE can't determine the ampping? >> >> It can't determine the public IP address and port of a mapping on the >> NAT64 (CGN), and it can't create a mapping on the NAT64 (CGN) -- because >> the CGN is going to make a dynamic mapping when it sees a UDP, TCP, >> or ICMP packet from the subscriber. > > I don't see it matters > +1 ... since the alternative is that apps that require ipv4 sockets and pass ipv4 literals are stranded on ipv6 only networks. Running code on the n900 shows that nat464 provides real user and network benefit Cb >> >> >> > deterministic (including 4rd, Dual-IVI, and draft-ymbk-aplus-p). >> > >> > >> > By the way, I would say you are missing one early draft: >> > http://tools.ietf.org/html/draft-murakami-softwire-4v6-translation-00 >> > which is align with 4rd about 4v6 translation which has been >> > contributed by major operators which is also align with NAT64 >> > deployment. >> >> Sorry. >> >> -d >> >> >> > -Hui >> > >> > >> > >> > >> > A stateful CGN, as commonly deployed, is not deterministic. >> > >> > However -- and this is my point in this email -- a stateful CGN >> > can be configured and deployed so that it deterministically maps >> > traffic. That is, it can function very much like A+P/4rd/Dual- >> > IVI >> > so that port "N" from subscriber "A" is always mapped to public >> > port "Z" on IPv4 address "Y". We could have the CPE know about >> > that fixed mapping using the same DHCP options that A+P/4rd/ >> > Dual-IVI would use, or use PCP, or use some other protocol. >> > >> > -d >> > >> > >> > > I would assume softwires follows these same IETF guidelines and >> > > therefore is >> > > now focusing solely on stateless approaches(?). If the IETF >> > opinion has >> > > changed so that also stateful double translation solutions are >> > now ok >> > > for >> > > IETF, then that should perhaps be reflected in this document as >> > well. >> > > >> > > Unfortunately, I did not have chance to go to softwires >> > interim, but >> > > please >> > > let us know if the discussions there impact also the quoted >> > > recommendation. >> > > >> > > Best regards, >> > > >> > > Teemu >> > > >> > > > -----Original Message----- >> > > > From: behave-bounces@ietf.org [mailto:behave- >> > bounces@ietf.org] On >> > > > Behalf Of ext Satoru Matsushima >> > > > Sent: 13. syyskuuta 2011 06:51 >> > > > To: ietf@ietf.org >> > > > Cc: behave@ietf.org; Satoru Matsushima >> > > > Subject: Re: [BEHAVE] Last Call: > > 06.txt> >> > > (Dual >> > > > Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed >> > Standard >> > > > >> > > > The introduction in the draft says: >> > > > >> > > > >> > > > > IETF recommends using dual-stack or tunneling based >> > solutions for >> > > > > IPv6 transition and specifically recommends against >> > deployments >> > > > > utilizing double protocol translation. Use of BIH >> > together with >> > > a >> > > > > NAT64 is NOT RECOMMENDED [RFC6180]. >> > > > > >> > > > >> > > > >> > > > This statement makes a strong obstacle when we develop >> > stateless >> > > solution >> > > > with translation in softwires wg. >> > > > I think that it is still remained a room to make decision >> > whether >> > > removing >> > > the >> > > > statement or remaining it. >> > > > The discussion which we'll have in the softwires interim >> > meeting >> > > would be >> > > > helpful to decide it. >> > > > >> > > > Best regards, >> > > > --satoru >> > > > >> > > > >> > > > >> > > > On 2011/08/31, at 22:53, The IESG wrote: >> > > > >> > > > > >> > > > > The IESG has received a request from the Behavior >> > Engineering for >> > > > > Hindrance Avoidance WG (behave) to consider the following >> > document: >> > > > > - 'Dual Stack Hosts Using "Bump-in-the-Host" (BIH)' >> > > > > 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 2011-09-14. 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. >> > > > > >> > > > > Abstract >> > > > > >> > > > > >> > > > > Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 >> > protocol >> > > > > translation mechanism that allows a class of IPv4-only >> > > applications >> > > > > that work through NATs to communicate with IPv6-only >> > peers. The >> > > host >> > > > > on which applications are running may be connected to >> > IPv6-only >> > > or >> > > > > dual-stack access networks. BIH hides IPv6 and makes the >> > IPv4- >> > > only >> > > > > applications think they are talking with IPv4 peers by >> > local >> > > > > synthesis of IPv4 addresses. This draft obsoletes RFC >> > 2767 and >> > > RFC >> > > > > 3338. >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > The file can be obtained via >> > > > > http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ >> > > > > >> > > > > IESG discussion can be tracked via >> > > > > http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ >> > > > > >> > > > > >> > > > > No IPR declarations have been submitted directly on this I- >> > D. >> > > > > >> > > > > >> > > > > _______________________________________________ >> > > > > 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 >> > >> > >> >> > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > --bcaec51f995faed39704ae01de50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sep 28, 2011 2:51 AM, "Hui Deng" <denghui02@gmail.com> wrote:
>
> Hi Dan,
> =A0
> Inline please,
>
> 2011/9/27 Dan Wing <dwing@cisco.= com>
>>
>> > -----Original Message-----
>> > From: Hui Deng [mailto:denghui02@gmail.com]
>> > Sent: Monday, September 26, 2011 11:01 PM
>> > To: Dan Wing
>> > Cc: teemu.savol= ainen@nokia.com; satoru.= matsushima@gmail.com;
>> > ietf@ietf.org; softwires@ietf.org; behave@ietf.org
>> > Subject: Re: [BEHAVE] Last Call: <draft-ietf-behave-v4v6-b= ih-06.txt>
>> > (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) t= o Proposed Standard
>> >
>> > Hi Dan
>> >
>> > inline please,
>> >
>> >
>> > =A0 =A0 =A0 I believe the objection is against "non-dete= rministic
>> > translation",
>> > =A0 =A0 =A0 rather than stateful versus stateless. =A0By non-= deterministic, I
>> > mean
>> > =A0 =A0 =A0 that the subscriber's equipment (e.g., CPE) c= annot determine the
>> > =A0 =A0 =A0 mapping it will have on the Internet. =A0A+P mech= anisms are
>> >
>> >
>> > Could you help be more elaboration on CPE can't determine= the ampping?
>>
>> It can't determine the public IP address and port of a mapping= on the
>> NAT64 (CGN), and it can't create a mapping on the NAT64 (CGN) = -- because
>> the CGN is going to make a dynamic mapping when it sees a UDP, TCP= ,
>> or ICMP packet from the subscriber.
>
> I don't see it matters
> =A0

+1 ... since the alternative is that apps that require ipv4 sockets and = pass ipv4 literals are stranded on ipv6 only networks.

Running code on the n900 shows that nat464 provides real user and networ= k benefit

Cb
>>
>>
>> > =A0 =A0 =A0 deterministic (including 4rd, Dual-IVI, and draft= -ymbk-aplus-p).
>> >
>> >
>> > By the way, I would say you are missing one early draft:
>> > http://tools.ietf.org/html/draft-murakami-softwire-4v6= -translation-00
>> > which is align with 4rd =A0about 4v6 translation which has be= en
>> > contributed by major operators which is also align with NAT64=
>> > deployment.
>>
>> Sorry.
>>
>> -d
>>
>>
>> > -Hui
>> >
>> >
>> >
>> >
>> > =A0 =A0 =A0 A stateful CGN, as commonly deployed, is not dete= rministic.
>> >
>> > =A0 =A0 =A0 However -- and this is my point in this email -- = a stateful CGN
>> > =A0 =A0 =A0 can be configured and deployed so that it determi= nistically maps
>> > =A0 =A0 =A0 traffic. =A0That is, it can function very much li= ke A+P/4rd/Dual-
>> > IVI
>> > =A0 =A0 =A0 so that port "N" from subscriber "= A" is always mapped to public
>> > =A0 =A0 =A0 port "Z" on IPv4 address "Y".= =A0We could have the CPE know about
>> > =A0 =A0 =A0 that fixed mapping using the same DHCP options th= at A+P/4rd/
>> > =A0 =A0 =A0 Dual-IVI would use, or use PCP, or use some other= protocol.
>> >
>> > =A0 =A0 =A0 -d
>> >
>> >
>> > =A0 =A0 =A0 > I would assume softwires follows these same = IETF guidelines and
>> > =A0 =A0 =A0 > therefore is
>> > =A0 =A0 =A0 > now focusing solely on stateless approaches(= ?). If the IETF
>> > opinion has
>> > =A0 =A0 =A0 > changed so that also stateful double transla= tion solutions are
>> > now ok
>> > =A0 =A0 =A0 > for
>> > =A0 =A0 =A0 > IETF, then that should perhaps be reflected = in this document as
>> > well.
>> > =A0 =A0 =A0 >
>> > =A0 =A0 =A0 > Unfortunately, I did not have chance to go t= o softwires
>> > interim, but
>> > =A0 =A0 =A0 > please
>> > =A0 =A0 =A0 > let us know if the discussions there impact = also the quoted
>> > =A0 =A0 =A0 > recommendation.
>> > =A0 =A0 =A0 >
>> > =A0 =A0 =A0 > Best regards,
>> > =A0 =A0 =A0 >
>> > =A0 =A0 =A0 > =A0 =A0 =A0 Teemu
>> > =A0 =A0 =A0 >
>> > =A0 =A0 =A0 > > -----Original Message-----
>> > =A0 =A0 =A0 > > From: behave-bounces@ietf.org [mailto:be= have-
>> > bounces@ietf.org] On<= br> >> > =A0 =A0 =A0 > > Behalf Of ext Satoru Matsushima
>> > =A0 =A0 =A0 > > Sent: 13. syyskuuta 2011 06:51
>> > =A0 =A0 =A0 > > To: ie= tf@ietf.org
>> > =A0 =A0 =A0 > > Cc: = behave@ietf.org; Satoru Matsushima
>> > =A0 =A0 =A0 > > Subject: Re: [BEHAVE] Last Call: <dr= aft-ietf-behave-v4v6-bih-
>> > 06.txt>
>> > =A0 =A0 =A0 > (Dual
>> > =A0 =A0 =A0 > > Stack Hosts Using "Bump-in-the-Hos= t" (BIH)) to Proposed
>> > Standard
>> > =A0 =A0 =A0 > >
>> > =A0 =A0 =A0 > > The introduction in the draft says:
>> > =A0 =A0 =A0 > >
>> > =A0 =A0 =A0 > >
>> > =A0 =A0 =A0 > > > =A0 IETF recommends using dual-sta= ck or tunneling based
>> > solutions for
>> > =A0 =A0 =A0 > > > =A0 =A0IPv6 transition and specifi= cally recommends against
>> > deployments
>> > =A0 =A0 =A0 > > > =A0 =A0utilizing double protocol t= ranslation. =A0Use of BIH
>> > together with
>> > =A0 =A0 =A0 > a
>> > =A0 =A0 =A0 > > > =A0 =A0NAT64 is NOT RECOMMENDED [R= FC6180].
>> > =A0 =A0 =A0 > > >
>> > =A0 =A0 =A0 > >
>> > =A0 =A0 =A0 > >
>> > =A0 =A0 =A0 > > This statement makes a strong obstacle = when we develop
>> > stateless
>> > =A0 =A0 =A0 > solution
>> > =A0 =A0 =A0 > > with translation in softwires wg.
>> > =A0 =A0 =A0 > > I think that it is still remained a roo= m to make decision
>> > whether
>> > =A0 =A0 =A0 > removing
>> > =A0 =A0 =A0 > the
>> > =A0 =A0 =A0 > > statement or remaining it.
>> > =A0 =A0 =A0 > > The discussion which we'll have in = the softwires interim
>> > meeting
>> > =A0 =A0 =A0 > would be
>> > =A0 =A0 =A0 > > helpful to decide it.
>> > =A0 =A0 =A0 > >
>> > =A0 =A0 =A0 > > Best regards,
>> > =A0 =A0 =A0 > > --satoru
>> > =A0 =A0 =A0 > >
>> > =A0 =A0 =A0 > >
>> > =A0 =A0 =A0 > >
>> > =A0 =A0 =A0 > > On 2011/08/31, at 22:53, The IESG wrote= :
>> > =A0 =A0 =A0 > >
>> > =A0 =A0 =A0 > > >
>> > =A0 =A0 =A0 > > > The IESG has received a request fr= om the Behavior
>> > Engineering for
>> > =A0 =A0 =A0 > > > Hindrance Avoidance WG (behave) to= consider the following
>> > document:
>> > =A0 =A0 =A0 > > > - 'Dual Stack Hosts Using &quo= t;Bump-in-the-Host" (BIH)'
>> > =A0 =A0 =A0 > > > =A0<draft-ietf-behave-v4v6-bih-= 06.txt> as a Proposed Standard
>> > =A0 =A0 =A0 > > >
>> > =A0 =A0 =A0 > > > The IESG plans to make a decision = in the next few weeks,
>> > and
>> > =A0 =A0 =A0 > solicits
>> > =A0 =A0 =A0 > > > final comments on this action. Ple= ase send substantive
>> > comments to
>> > =A0 =A0 =A0 > the
>> > =A0 =A0 =A0 > > > i= etf@ietf.org mailing lists by 2011-09-14. Exceptionally,
>> > comments
>> > =A0 =A0 =A0 > may
>> > =A0 =A0 =A0 > > > be sent to iesg@ietf.org instead. In either case, please
>> > retain the
>> > =A0 =A0 =A0 > > > beginning of the Subject line to a= llow automated sorting.
>> > =A0 =A0 =A0 > > >
>> > =A0 =A0 =A0 > > > Abstract
>> > =A0 =A0 =A0 > > >
>> > =A0 =A0 =A0 > > >
>> > =A0 =A0 =A0 > > > =A0 Bump-In-the-Host (BIH) is a ho= st-based IPv4 to IPv6
>> > protocol
>> > =A0 =A0 =A0 > > > =A0 translation mechanism that all= ows a class of IPv4-only
>> > =A0 =A0 =A0 > applications
>> > =A0 =A0 =A0 > > > =A0 that work through NATs to comm= unicate with IPv6-only
>> > peers. =A0The
>> > =A0 =A0 =A0 > host
>> > =A0 =A0 =A0 > > > =A0 on which applications are runn= ing may be connected to
>> > IPv6-only
>> > =A0 =A0 =A0 > or
>> > =A0 =A0 =A0 > > > =A0 dual-stack access networks. = =A0BIH hides IPv6 and makes the
>> > IPv4-
>> > =A0 =A0 =A0 > only
>> > =A0 =A0 =A0 > > > =A0 applications think they are ta= lking with IPv4 peers by
>> > local
>> > =A0 =A0 =A0 > > > =A0 synthesis of IPv4 addresses. = =A0This draft obsoletes RFC
>> > 2767 and
>> > =A0 =A0 =A0 > RFC
>> > =A0 =A0 =A0 > > > =A0 3338.
>> > =A0 =A0 =A0 > > >
>> > =A0 =A0 =A0 > > >
>> > =A0 =A0 =A0 > > >
>> > =A0 =A0 =A0 > > >
>> > =A0 =A0 =A0 > > > The file can be obtained via
>> > =A0 =A0 =A0 > > > http://datatracker.ietf.org/doc/draft= -ietf-behave-v4v6-bih/
>> > =A0 =A0 =A0 > > >
>> > =A0 =A0 =A0 > > > IESG discussion can be tracked via=
>> > =A0 =A0 =A0 > > > http://datatracker.ietf.org/doc/draft= -ietf-behave-v4v6-bih/
>> > =A0 =A0 =A0 > > >
>> > =A0 =A0 =A0 > > >
>> > =A0 =A0 =A0 > > > No IPR declarations have been subm= itted directly on this I-
>> > D.
>> > =A0 =A0 =A0 > > >
>> > =A0 =A0 =A0 > > >
>> > =A0 =A0 =A0 > > > __________________________________= _____________
>> > =A0 =A0 =A0 > > > Behave mailing list
>> > =A0 =A0 =A0 > > > Behave@ietf.org
>> > =A0 =A0 =A0 > > > https://www.ietf.org/mailman/listinfo/behave
>> > =A0 =A0 =A0 > >
>> > =A0 =A0 =A0 > > _______________________________________= ________
>> > =A0 =A0 =A0 > > Behave mailing list
>> > =A0 =A0 =A0 > > Beha= ve@ietf.org
>> > =A0 =A0 =A0 > > https://www.ietf.org/mailman/listinfo/behave
>> >
>> > =A0 =A0 =A0 _______________________________________________ >> > =A0 =A0 =A0 Behave mailing list
>> > =A0 =A0 =A0 Behave@ietf.or= g
>> > =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/behave
>> >
>> >
>>
>>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.iet= f.org/mailman/listinfo/ietf
>

--bcaec51f995faed39704ae01de50-- From dwing@cisco.com Wed Sep 28 08:45:53 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB2821F8C3D; Wed, 28 Sep 2011 08:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.038 X-Spam-Level: X-Spam-Status: No, score=-103.038 tagged_above=-999 required=5 tests=[AWL=-0.439, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+xWD+8alKFp; Wed, 28 Sep 2011 08:45:53 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5724E21F8C31; Wed, 28 Sep 2011 08:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2394; q=dns/txt; s=iport; t=1317224922; x=1318434522; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=M/X2PXafLPP/NMvqLyGwzxadpknnnHCN3LkNqj1JmYo=; b=I4vuDZVl13HxBmSha9xXgw9JD7Wgp0IIQXtaYoVif4Q2yFNaFndShOfz g1IPs9rF/+59BLMqMLo1izJH9tYpxV/jNbq1NND5stEdT+CPuK6AXpETw 5M91+uUGoA8wA+gEzVhAlpxoDmMSXHpFxy9Pa/liVQwb2/RlwRv0t9ujn c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEAAF5Bg06rRDoJ/2dsb2JhbABCmQiBa40XeIFTAQEBAQMBAQEFCgEXEDQLDAEDAgkPAgQBASQEBxkIBhUKCQgBAQQTCxeHXJovAZ4eA4cMBIdylXyHPA X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="4793997" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 28 Sep 2011 15:48:42 +0000 Received: from dwingWS (rcdn-vpn-client-10-89-7-226.cisco.com [10.89.7.226]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8SFmepX000789; Wed, 28 Sep 2011 15:48:41 GMT From: "Dan Wing" To: "'Hui Deng'" References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> <916CE6CF87173740BC8A2CE44309696203771FAB@008-AM1MPN1-037.mgdnok.nokia.com> <09bd01cc7d16$cd715190$6853f4b0$@com> In-Reply-To: Date: Wed, 28 Sep 2011 08:48:40 -0700 Message-ID: <013201cc7df6$18e96ec0$4abc4c40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acx9xEFUBJh2G1RgQnGCLa2eJAUYUwAMapMA Content-Language: en-us Cc: softwires@ietf.org, behave@ietf.org, satoru.matsushima@gmail.com, ietf@ietf.org Subject: Re: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2011 15:45:54 -0000 > -----Original Message----- > From: Hui Deng [mailto:denghui02@gmail.com] > Sent: Wednesday, September 28, 2011 2:52 AM > To: Dan Wing > Cc: teemu.savolainen@nokia.com; satoru.matsushima@gmail.com; > ietf@ietf.org; softwires@ietf.org; behave@ietf.org > Subject: Re: [BEHAVE] Last Call: > (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard > > inline please, > > > 2011/9/27 Dan Wing > > > > -----Original Message----- > > From: teemu.savolainen@nokia.com > [mailto:teemu.savolainen@nokia.com] > > Sent: Monday, September 26, 2011 11:14 PM > > To: dwing@cisco.com; satoru.matsushima@gmail.com; ietf@ietf.org > > Cc: softwires@ietf.org; behave@ietf.org > > Subject: RE: [BEHAVE] Last Call: 06.txt> > > (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed > Standard > > > > > > I believe the objection is against "non-deterministic > translation", > > rather > > than > > > stateful versus stateless. By non-deterministic, I mean that > the > > subscriber's > > > equipment (e.g., CPE) cannot determine the mapping it will > have on > > the > > > Internet. A+P mechanisms are deterministic (including 4rd, > Dual-IVI, > > and > > > draft-ymbk-aplus-p). > > > > > > A stateful CGN, as commonly deployed, is not deterministic. > > > > I don't understand why that is significant enough factor for > IETF to > > (not) > > recommend some double translation variants. I mean does > existing > > applications work better if double translation is done in > deterministic > > manner? > > > Yes, it allows the CPE to implement an ALG -- if an application > needs > an ALG (e.g., active-mode FTP). > > > > Are you saying distrbiuted ALG is much better than centralized ALG? Best is no ALG. Worse is one ALG. Even worse is two ALGs. -d > -Hui > > > > -d > > > > One reasoning against double translation has been that it > > breaks > > some class of applications. Is it now so that some forms of > double > > translation do not break applications while some others do? > > > > Teemu > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From dwing@cisco.com Wed Sep 28 08:55:49 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9388111E80C2; Wed, 28 Sep 2011 08:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.032 X-Spam-Level: X-Spam-Status: No, score=-103.032 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVSJjyHlrmhk; Wed, 28 Sep 2011 08:55:48 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 807CA11E80BD; Wed, 28 Sep 2011 08:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=9647; q=dns/txt; s=iport; t=1317225517; x=1318435117; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Hn6uINwNru82KlwNIgSP/QQobgUIvduQ9S29LQ9h8oA=; b=ek5+IT3PQep6Dbnl6t0yPRE9xdDr4BMWnK0HSpSG5Glr96WIofCggTR5 ruu4IgSdnfOk8Kf/4pAytq8H8ykY8iivgsHjGL3gdFBdXmszXz1yCGd/4 qtRXtIMgZymTHjVrdJTuO1Nv0m3qCIOABkLRn2/iF7bC8r2zQje3vVME4 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEAAOVDg06rRDoH/2dsb2JhbABCmQiBa40XeIFTAQEBAQIBAQEBBQoBFxA0CwUHAQMCCQ4BAgQBAQEjBAcZCAYVCgkIAQEEAQkJCxAHh1YGmjEBniKHDASHcpV8hzw X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="4795717" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 28 Sep 2011 15:58:37 +0000 Received: from dwingWS (rcdn-vpn-client-10-89-7-226.cisco.com [10.89.7.226]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8SFwY7X001970; Wed, 28 Sep 2011 15:58:35 GMT From: "Dan Wing" To: "'Cameron Byrne'" , "'Hui Deng'" References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> <09b701cc7d16$6943df30$3bcb9d90$@com> In-Reply-To: Date: Wed, 28 Sep 2011 08:58:34 -0700 Message-ID: <013d01cc7df7$7af51d20$70df5760$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acx98Ypu1Orzr1JORF2PQxXHjL9/XAABQmOg Content-Language: en-us Cc: softwires@ietf.org, behave@ietf.org, ietf@ietf.org Subject: Re: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2011 15:55:49 -0000 > -----Original Message----- > From: Cameron Byrne [mailto:cb.list6@gmail.com] > Sent: Wednesday, September 28, 2011 8:16 AM > To: Hui Deng > Cc: softwires@ietf.org; behave@ietf.org; teemu.savolainen@nokia.com; > ietf@ietf.org; Dan Wing > Subject: Re: [BEHAVE] Last Call: > (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard > > > On Sep 28, 2011 2:51 AM, "Hui Deng" wrote: > > > > Hi Dan, > > > > Inline please, > > > > 2011/9/27 Dan Wing > >> > >> > -----Original Message----- > >> > From: Hui Deng [mailto:denghui02@gmail.com] > >> > Sent: Monday, September 26, 2011 11:01 PM > >> > To: Dan Wing > >> > Cc: teemu.savolainen@nokia.com; satoru.matsushima@gmail.com; > >> > ietf@ietf.org; softwires@ietf.org; behave@ietf.org > >> > Subject: Re: [BEHAVE] Last Call: 06.txt> > >> > (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed > Standard > >> > > >> > Hi Dan > >> > > >> > inline please, > >> > > >> > > >> > I believe the objection is against "non-deterministic > >> > translation", > >> > rather than stateful versus stateless. By non- > deterministic, I > >> > mean > >> > that the subscriber's equipment (e.g., CPE) cannot determine > the > >> > mapping it will have on the Internet. A+P mechanisms are > >> > > >> > > >> > Could you help be more elaboration on CPE can't determine the > ampping? > >> > >> It can't determine the public IP address and port of a mapping on > the > >> NAT64 (CGN), and it can't create a mapping on the NAT64 (CGN) -- > because > >> the CGN is going to make a dynamic mapping when it sees a UDP, TCP, > >> or ICMP packet from the subscriber. > > > > I don't see it matters > > +1 ... since the alternative is that apps that require ipv4 sockets and > pass ipv4 literals are stranded on ipv6 only networks. > > Running code on the n900 shows that nat464 provides real user and > network benefit Can you run an FTP server on the BIH host, and have it do active mode transfers and passive mode transfers? I admit that isn't terribly important (nobody much loves FTP any more), but if the BIH host doesn't know its public mapping and can't create one, we lose that class of applications that listen on a port. Losing that class of applications may, or may not, be important. Many of those applications do STUN or STUN-/ICE-like things for their own NAT traversal (e.g., Skype). But some don't and work properly without a hole punched (e.g., BitTorrent). PCP can make all of this work, if it's integrated into BIH and the NAT64. -d > Cb > >> > >> > >> > deterministic (including 4rd, Dual-IVI, and draft-ymbk- > aplus-p). > >> > > >> > > >> > By the way, I would say you are missing one early draft: > >> > http://tools.ietf.org/html/draft-murakami-softwire-4v6- > translation-00 > >> > which is align with 4rd about 4v6 translation which has been > >> > contributed by major operators which is also align with NAT64 > >> > deployment. > >> > >> Sorry. > >> > >> -d > >> > >> > >> > -Hui > >> > > >> > > >> > > >> > > >> > A stateful CGN, as commonly deployed, is not deterministic. > >> > > >> > However -- and this is my point in this email -- a stateful > CGN > >> > can be configured and deployed so that it deterministically > maps > >> > traffic. That is, it can function very much like > A+P/4rd/Dual- > >> > IVI > >> > so that port "N" from subscriber "A" is always mapped to > public > >> > port "Z" on IPv4 address "Y". We could have the CPE know > about > >> > that fixed mapping using the same DHCP options that A+P/4rd/ > >> > Dual-IVI would use, or use PCP, or use some other protocol. > >> > > >> > -d > >> > > >> > > >> > > I would assume softwires follows these same IETF > guidelines and > >> > > therefore is > >> > > now focusing solely on stateless approaches(?). If the > IETF > >> > opinion has > >> > > changed so that also stateful double translation solutions > are > >> > now ok > >> > > for > >> > > IETF, then that should perhaps be reflected in this > document as > >> > well. > >> > > > >> > > Unfortunately, I did not have chance to go to softwires > >> > interim, but > >> > > please > >> > > let us know if the discussions there impact also the > quoted > >> > > recommendation. > >> > > > >> > > Best regards, > >> > > > >> > > Teemu > >> > > > >> > > > -----Original Message----- > >> > > > From: behave-bounces@ietf.org [mailto:behave- > >> > bounces@ietf.org] On > >> > > > Behalf Of ext Satoru Matsushima > >> > > > Sent: 13. syyskuuta 2011 06:51 > >> > > > To: ietf@ietf.org > >> > > > Cc: behave@ietf.org; Satoru Matsushima > >> > > > Subject: Re: [BEHAVE] Last Call: v4v6-bih- > >> > 06.txt> > >> > > (Dual > >> > > > Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed > >> > Standard > >> > > > > >> > > > The introduction in the draft says: > >> > > > > >> > > > > >> > > > > IETF recommends using dual-stack or tunneling based > >> > solutions for > >> > > > > IPv6 transition and specifically recommends against > >> > deployments > >> > > > > utilizing double protocol translation. Use of BIH > >> > together with > >> > > a > >> > > > > NAT64 is NOT RECOMMENDED [RFC6180]. > >> > > > > > >> > > > > >> > > > > >> > > > This statement makes a strong obstacle when we develop > >> > stateless > >> > > solution > >> > > > with translation in softwires wg. > >> > > > I think that it is still remained a room to make > decision > >> > whether > >> > > removing > >> > > the > >> > > > statement or remaining it. > >> > > > The discussion which we'll have in the softwires interim > >> > meeting > >> > > would be > >> > > > helpful to decide it. > >> > > > > >> > > > Best regards, > >> > > > --satoru > >> > > > > >> > > > > >> > > > > >> > > > On 2011/08/31, at 22:53, The IESG wrote: > >> > > > > >> > > > > > >> > > > > The IESG has received a request from the Behavior > >> > Engineering for > >> > > > > Hindrance Avoidance WG (behave) to consider the > following > >> > document: > >> > > > > - 'Dual Stack Hosts Using "Bump-in-the-Host" (BIH)' > >> > > > > 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 2011-09-14. > 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. > >> > > > > > >> > > > > Abstract > >> > > > > > >> > > > > > >> > > > > Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 > >> > protocol > >> > > > > translation mechanism that allows a class of IPv4- > only > >> > > applications > >> > > > > that work through NATs to communicate with IPv6-only > >> > peers. The > >> > > host > >> > > > > on which applications are running may be connected > to > >> > IPv6-only > >> > > or > >> > > > > dual-stack access networks. BIH hides IPv6 and > makes the > >> > IPv4- > >> > > only > >> > > > > applications think they are talking with IPv4 peers > by > >> > local > >> > > > > synthesis of IPv4 addresses. This draft obsoletes > RFC > >> > 2767 and > >> > > RFC > >> > > > > 3338. > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > The file can be obtained via > >> > > > > http://datatracker.ietf.org/doc/draft-ietf-behave- > v4v6-bih/ > >> > > > > > >> > > > > IESG discussion can be tracked via > >> > > > > http://datatracker.ietf.org/doc/draft-ietf-behave- > v4v6-bih/ > >> > > > > > >> > > > > > >> > > > > No IPR declarations have been submitted directly on > this I- > >> > D. > >> > > > > > >> > > > > > >> > > > > _______________________________________________ > >> > > > > 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 > >> > > >> > > >> > >> > > > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > > From mark@townsley.net Wed Sep 28 09:24:04 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DC411E809A; Wed, 28 Sep 2011 09:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sujIiZc67yHJ; Wed, 28 Sep 2011 09:24:04 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2A25721F8D50; Wed, 28 Sep 2011 09:23:51 -0700 (PDT) Received: by wyh21 with SMTP id 21so206830wyh.31 for ; Wed, 28 Sep 2011 09:26:39 -0700 (PDT) Received: by 10.227.61.79 with SMTP id s15mr3289872wbh.96.1317227199235; Wed, 28 Sep 2011 09:26:39 -0700 (PDT) Received: from ams-townsley-8713.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id z9sm41196264wbn.19.2011.09.28.09.26.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Sep 2011 09:26:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <013d01cc7df7$7af51d20$70df5760$@com> Date: Wed, 28 Sep 2011 18:26:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <989D4A28-9E89-45EB-A256-5B55D32E150F@townsley.net> References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> <09b701cc7d16$6943df30$3bcb9d90$@com> <013d01cc7df7$7af51d20$70df5760$@com> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: Hui Deng , Softwires-wg list , Behave WG , IETF Discussion , Dan Wing Subject: Re: [BEHAVE] [Softwires] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2011 16:24:05 -0000 >> +1 ... since the alternative is that apps that require ipv4 sockets = and >> pass ipv4 literals are stranded on ipv6 only networks. >>=20 >> Running code on the n900 shows that nat464 provides real user and >> network benefit Frankly, I preferred it when you were running IPv6-only without BIH on = your trial, providing pressure to get rid of all those stranded literals = and pushing apps to open ipv6 sockets :-/ - Mark= From dwing@cisco.com Wed Sep 28 11:07:55 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1828121F8C20 for ; Wed, 28 Sep 2011 11:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.021 X-Spam-Level: X-Spam-Status: No, score=-103.021 tagged_above=-999 required=5 tests=[AWL=-0.422, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9vmvNg3PUVe for ; Wed, 28 Sep 2011 11:07:54 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 32D1121F8C1C for ; Wed, 28 Sep 2011 11:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=8618; q=dns/txt; s=iport; t=1317233443; x=1318443043; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=eGcPDs5yzd52GpR0Sly7onl+VL3jrgkOv91b7nVVf7M=; b=AfNAkpZXtH/22sfgfkTp10XgwUghXzAQ6RiYpKzQx2MTZBkpPeXgC4nI uI6DdLzAbetH9X3Co19tBrRZuhnggMuJiT0Pv/ph2ajn6njfMRDiY66nO HZ8q1EWY9q8283D0/VZqLGVUuhvw/8krKwc+xwlwuO+bPLctd85d6afoJ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEAAF9ig06rRDoI/2dsb2JhbABCmQqBa40XeIFTAQEBAQMICgEXEDEDCwwBBQkPAgQBASggIwoHAQEFBAEEEwkCF4dcmhUBniyHDASHcp04 X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="4822744" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 28 Sep 2011 18:10:43 +0000 Received: from dwingWS (rcdn-vpn-client-10-89-7-226.cisco.com [10.89.7.226]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8SIAgvK003825; Wed, 28 Sep 2011 18:10:42 GMT From: "Dan Wing" To: Date: Wed, 28 Sep 2011 11:10:41 -0700 Message-ID: <020c01cc7e09$ef9d2340$ced769c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acx+CdvrwVMBj66nTp+xHLhagy+SggAAAhFQ Content-Language: en-us Cc: behave-chairs@tools.ietf.org Subject: [BEHAVE] FW: please publish draft-ietf-behave-64-analysis-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2011 18:07:55 -0000 FYI. -d -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com] Sent: Wednesday, September 28, 2011 11:10 AM To: 'David Harrington'; 'iesg-secretary@ietf.org' Cc: 'behave-chairs@tools.ietf.org'; 'draft-ietf-behave-64-analysis@tools.ietf.org' Subject: please publish draft-ietf-behave-64-analysis-04 BEHAVE's WGLC for draft-ietf-behave-64-analysis-04 has concluded, and we request advancing the document to publication. PROTO writeup is below. -d ----- (1.a) Who is the Document Shepherd for this document? document: draft-ietf-behave-64-analysis-04.txt shepherd: Dan Wing, dwing@cisco.com Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Yes. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes, sufficient review has been performed. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? No concerns. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No concerns. There are no IPR disclosures against this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This document analyzies how well BEHAVE's NAT64 documents resolve the problems described in RFC4966 (which deprecated NAT-PT). Consensus is fairly solid. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No significant conflict with this document has occurred. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? No such reviews are needed. If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. Intended status: Informational (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes, references are split, and all appear good. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? This document does not need any IANA action. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Verified. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Due to specific problems, NAT-PT was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document evaluates how the new stateful translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Nothing exciting happened. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' shepherd: Dan Wing responsible AD: David Harrington The Document Shepherd MUST send the Document Shepherd Write-Up to the Responsible Area Director and iesg-secretary@ietf.org together with the request to publish the document. The Document Shepherd SHOULD also send the entire Document Shepherd Write-Up to the working group mailing list. If the Document Shepherd feels that information which may prove to be sensitive, may lead to possible appeals, or is personal needs to be written up, it SHOULD be sent in direct email to the Responsible Area Director, because the Document Shepherd Write-Up is published openly in the ID Tracker. Question (1.f) of the Write-Up covers any material of this nature and specifies this more confidential handling. From cb.list6@gmail.com Wed Sep 28 11:09:21 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379AA21F8C28; Wed, 28 Sep 2011 11:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CemmLn-zIm4; Wed, 28 Sep 2011 11:09:20 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB7521F8C20; Wed, 28 Sep 2011 11:09:20 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so6899587vcb.31 for ; Wed, 28 Sep 2011 11:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1TfqI3N/k9a5eHwQfyePt/SzcYzu7VTKPhBv2Zw7cNQ=; b=RbXdSiI6mU7kH3f/Sx5Wr+wU3Ud2OmTnXUBG1LtnAEEpBwXJ0GpxKOb21YAo5G7gDO zxfclXqu62ztbeuh/CQqOra8P/4FdqJJNo/wNR5gA9lKxCOim3qcvzJehnkIHsnFnxJb IFi3VAB7HNsuZEr+BuQr1whjPDnrgUi00CexY= MIME-Version: 1.0 Received: by 10.68.39.230 with SMTP id s6mr46309286pbk.81.1317233528368; Wed, 28 Sep 2011 11:12:08 -0700 (PDT) Received: by 10.142.89.1 with HTTP; Wed, 28 Sep 2011 11:12:08 -0700 (PDT) In-Reply-To: <989D4A28-9E89-45EB-A256-5B55D32E150F@townsley.net> References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> <09b701cc7d16$6943df30$3bcb9d90$@com> <013d01cc7df7$7af51d20$70df5760$@com> <989D4A28-9E89-45EB-A256-5B55D32E150F@townsley.net> Date: Wed, 28 Sep 2011 11:12:08 -0700 Message-ID: From: Cameron Byrne To: Mark Townsley Content-Type: text/plain; charset=ISO-8859-1 Cc: Hui Deng , Softwires-wg list , Behave WG , IETF Discussion , Dan Wing Subject: Re: [BEHAVE] [Softwires] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2011 18:09:21 -0000 On Wed, Sep 28, 2011 at 9:26 AM, Mark Townsley wrote: > > >>> +1 ... since the alternative is that apps that require ipv4 sockets and >>> pass ipv4 literals are stranded on ipv6 only networks. >>> >>> Running code on the n900 shows that nat464 provides real user and >>> network benefit > > Frankly, I preferred it when you were running IPv6-only without BIH on your trial, providing pressure to get rid of all those stranded literals and pushing apps to open ipv6 sockets :-/ > > - Mark We're still doing that, and IPv6-only is still my philosophical preference and that is how we are launching the IPv6 + NAT64/DNS64 service into the production mobile network (real soon now). No change in that path. But some "power users" wanted their IPv4-only applications like Skype to work so they coded a NAT46 work-around for the N900. It is clever, it works. Their process of feeling the pain of a very few pesky IPv4-only apps and working around it is all documented here: http://talk.maemo.org/showthread.php?t=60320 Running NAT46 code here: http://code.google.com/p/n900ipv6/wiki/Nat64D In the end (as well as IPv6-only near term in mobile), IP version agnostic apps will prove to be more reliable and therefore will get more market share. Cameron From rajiva@cisco.com Wed Sep 28 11:18:09 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59771F0CAA; Wed, 28 Sep 2011 11:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22p4Nu5vySLK; Wed, 28 Sep 2011 11:18:09 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 13BC91F0C68; Wed, 28 Sep 2011 11:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2192; q=dns/txt; s=iport; t=1317234058; x=1318443658; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=IMOwf8fimQ9aceJincp89mekMT6xgpZ3XxsvkYNDJww=; b=WuA4bssONq3oTxWhNFkDE104oXe2YOnKt5VOoyhxgVZb3kJ53Y8FsXvU StET3kyyMbHKegNRAPLZUsibkQBBGcTG8oIowXEhQR3lWN1u0DAYxNtrA LQS8L0WtVRfJbJKuBMwHWvQQQM30zz8n0Kk0nhvKfCUVy9G6Z+/6wbOZG 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8AAERkg06tJV2Y/2dsb2JhbAAoGpkKjwJ4gVMBAQEBAwEBAQ8BHQo0CwwEAgEIDgMEAQEBCgYTBAEGASYfCQgBAQQBEggah1wkmWUBniWGK2EEh3KRDowo X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="24679127" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 28 Sep 2011 18:20:57 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8SIKvaE030657; Wed, 28 Sep 2011 18:20:57 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Sep 2011 13:20:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Sep 2011 13:20:56 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C06063D5C@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] [Softwires] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard Thread-Index: Acx+ClAy5RWx+wBXT0qRnkMXk7gtIAAAHE2w References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com><081701cc7cac$837a9610$8a6fc230$@com><09b701cc7d16$6943df30$3bcb9d90$@com><013d01cc7df7$7af51d20$70df5760$@com><989D4A28-9E89-45EB-A256-5B55D32E150F@townsley.net> From: "Rajiv Asati (rajiva)" To: "Cameron Byrne" , "Mark Townsley" X-OriginalArrivalTime: 28 Sep 2011 18:20:57.0094 (UTC) FILETIME=[5DD5E260:01CC7E0B] Cc: Hui Deng , Softwires-wg list , Behave WG , IETF Discussion , "Dan Wing \(dwing\)" Subject: Re: [BEHAVE] [Softwires] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2011 18:18:10 -0000 Hi Cameron, Very interesting (& clever indeed).=20 How does this clever code ensure that all but a few (pesky apps) continue to use IPv6 interface instead of the NAT46 interface? Cheers, Rajiv > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of > Cameron Byrne > Sent: Wednesday, September 28, 2011 2:12 PM > To: Mark Townsley > Cc: Hui Deng; Softwires-wg list; Behave WG; IETF Discussion; Dan Wing (dwing) > Subject: Re: [BEHAVE] [Softwires] Last Call: 06.txt> (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard >=20 > On Wed, Sep 28, 2011 at 9:26 AM, Mark Townsley wrote: > > > > > >>> +1 ... since the alternative is that apps that require ipv4 sockets and > >>> pass ipv4 literals are stranded on ipv6 only networks. > >>> > >>> Running code on the n900 shows that nat464 provides real user and > >>> network benefit > > > > Frankly, I preferred it when you were running IPv6-only without BIH on your > trial, providing pressure to get rid of all those stranded literals and > pushing apps to open ipv6 sockets :-/ > > > > - Mark >=20 > We're still doing that, and IPv6-only is still my philosophical > preference and that is how we are launching the IPv6 + NAT64/DNS64 > service into the production mobile network (real soon now). No change > in that path. >=20 > But some "power users" wanted their IPv4-only applications like Skype > to work so they coded a NAT46 work-around for the N900. It is clever, > it works. >=20 > Their process of feeling the pain of a very few pesky IPv4-only apps > and working around it is all documented here: > http://talk.maemo.org/showthread.php?t=3D60320 >=20 > Running NAT46 code here: http://code.google.com/p/n900ipv6/wiki/Nat64D >=20 > In the end (as well as IPv6-only near term in mobile), IP version > agnostic apps will prove to be more reliable and therefore will get > more market share. >=20 > Cameron > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From moore@network-heretics.com Wed Sep 28 11:18:33 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A34F1F0CB9; Wed, 28 Sep 2011 11:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.594 X-Spam-Level: X-Spam-Status: No, score=-3.594 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMbtAsf3SB7G; Wed, 28 Sep 2011 11:18:33 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id C67A61F0C68; Wed, 28 Sep 2011 11:18:32 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id E424720738; Wed, 28 Sep 2011 14:21:20 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute6.internal (MEProxy); Wed, 28 Sep 2011 14:21:20 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=U5N Y8oP5pAn4+EqJoOptqg76MxI=; b=qGWvioWEvm75ihH4e/P3E7NR6SjQKuAwV2a e8LR76sYbeg7sF1VE+xfFeRTpvT3feSHTPcdYHL9PJpraTqbjHRWo6mEP2h6/CNg G8IlRdWht19HYWgqLOwNvzgy+w8SSTlZOLbSgETz8Ydk7SDQNC3dQ6qNJq4ShY8f elqwBqp8= X-Sasl-enc: JGif6zJMwyFhEBnQ7wLX81FzDNM6kUeUqJUrVgd6VIeb 1317234080 Received: from khussen.hq.corp.pbs.org (unknown [149.48.225.2]) by mail.messagingengine.com (Postfix) with ESMTPA id 98B6786039F; Wed, 28 Sep 2011 14:21:20 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-40--375535786 From: Keith Moore In-Reply-To: Date: Wed, 28 Sep 2011 14:21:20 -0400 Message-Id: <83B6B5A2-A58D-4C6F-8E2F-756B1EE98C78@network-heretics.com> References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> <09b701cc7d16$6943df30$3bcb9d90$@com> <013d01cc7df7$7af51d20$70df5760$@com> <989D4A28-9E89-45EB-A256-5B55D32E150F@townsley.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg list , Behave WG , Mark Townsley , IETF Discussion Subject: Re: [BEHAVE] [Softwires] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2011 18:18:33 -0000 --Apple-Mail-40--375535786 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 28, 2011, at 2:12 PM, Cameron Byrne wrote: > In the end (as well as IPv6-only near term in mobile), IP version > agnostic apps will prove to be more reliable and therefore will get > more market share. Not clear. There's a tradeoff between the additional reliability of = being version-agile, and the decreased reliability associated with = hacks, proxies, relays, etc. needed to make the application work under = NATted v4 at all. That tradeoff will be different for different kinds = of applications. Keith --Apple-Mail-40--375535786 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
In the end = (as well as IPv6-only near term in mobile), IP version
agnostic apps = will prove to be more reliable and therefore will get
more market = share.

Not clear.   There's a = tradeoff between the additional reliability of being version-agile, and = the decreased reliability associated with hacks, proxies, relays, etc. = needed to make the application work under NATted v4 at all.  That = tradeoff will be different for different kinds of = applications.

Keith

= --Apple-Mail-40--375535786-- From mark@townsley.net Wed Sep 28 11:27:34 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C356F1F0CD2; Wed, 28 Sep 2011 11:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8oC-GLtwez3; Wed, 28 Sep 2011 11:27:34 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7D74A1F0CCD; Wed, 28 Sep 2011 11:27:33 -0700 (PDT) Received: by wwf22 with SMTP id 22so6279461wwf.13 for ; Wed, 28 Sep 2011 11:30:21 -0700 (PDT) Received: by 10.216.203.79 with SMTP id e57mr35610weo.12.1317234503061; Wed, 28 Sep 2011 11:28:23 -0700 (PDT) Received: from ams-townsley-8713.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id z9sm41629646wbn.19.2011.09.28.11.28.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Sep 2011 11:28:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Wed, 28 Sep 2011 20:28:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <581CAE88-75A7-4CF0-92B1-A79F70D703DE@townsley.net> References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> <09b701cc7d16$6943df30$3bcb9d90$@com> <013d01cc7df7$7af51d20$70df5760$@com> <989D4A28-9E89-45EB-A256-5B55D32E150F@townsley.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: Hui Deng , Softwires-wg list , Behave WG , IETF Discussion , Dan Wing Subject: Re: [BEHAVE] [Softwires] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2011 18:27:34 -0000 On Sep 28, 2011, at 8:12 PM, Cameron Byrne wrote: > On Wed, Sep 28, 2011 at 9:26 AM, Mark Townsley = wrote: >>=20 >>=20 >>>> +1 ... since the alternative is that apps that require ipv4 sockets = and >>>> pass ipv4 literals are stranded on ipv6 only networks. >>>>=20 >>>> Running code on the n900 shows that nat464 provides real user and >>>> network benefit >>=20 >> Frankly, I preferred it when you were running IPv6-only without BIH = on your trial, providing pressure to get rid of all those stranded = literals and pushing apps to open ipv6 sockets :-/ >>=20 >> - Mark >=20 > We're still doing that, and IPv6-only is still my philosophical > preference and that is how we are launching the IPv6 + NAT64/DNS64 > service into the production mobile network (real soon now). No change > in that path. >=20 > But some "power users" wanted their IPv4-only applications like Skype > to work so they coded a NAT46 work-around for the N900. It is clever, > it works. Ah, so it's not a model developed and (necessarily) supported by you. = Thanks for the clarification.=20 Yes, it makes sense that this would end up happening as the hosts evolve = to what the network provides. - Mark >=20 > Their process of feeling the pain of a very few pesky IPv4-only apps > and working around it is all documented here: > http://talk.maemo.org/showthread.php?t=3D60320 >=20 > Running NAT46 code here: http://code.google.com/p/n900ipv6/wiki/Nat64D >=20 > In the end (as well as IPv6-only near term in mobile), IP version > agnostic apps will prove to be more reliable and therefore will get > more market share. >=20 > Cameron From cb.list6@gmail.com Wed Sep 28 12:11:17 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19CA21F8B74; Wed, 28 Sep 2011 12:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.436 X-Spam-Level: X-Spam-Status: No, score=-3.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CN9YpAHI5Uxt; Wed, 28 Sep 2011 12:11:17 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id AEB6C21F8B5D; Wed, 28 Sep 2011 12:11:16 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so6976465vcb.31 for ; Wed, 28 Sep 2011 12:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xa74hXw5Pv/+v5U1n9akKrTS4he3o+8XmkNi+dykZG8=; b=drmuSSqnVERx+5G9AXrOJXU0+lI26uCpMChX9QfYu1NpHTvcWdkEcws9IXgFgBeLEb MGFjZ4Rvcdouo2T5rdQHt6+SKvhpwlOQpFiOWEcYRyJZprbSXJV1WzJRU0RAA3HuRLvZ 2UpD9UJRr5mYpknaV87EVjnETIiuF1ORcZMjk= MIME-Version: 1.0 Received: by 10.68.39.230 with SMTP id s6mr46627506pbk.81.1317237244880; Wed, 28 Sep 2011 12:14:04 -0700 (PDT) Received: by 10.142.89.1 with HTTP; Wed, 28 Sep 2011 12:14:04 -0700 (PDT) In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C06063D5C@XMB-RCD-111.cisco.com> References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> <09b701cc7d16$6943df30$3bcb9d90$@com> <013d01cc7df7$7af51d20$70df5760$@com> <989D4A28-9E89-45EB-A256-5B55D32E150F@townsley.net> <067E6CE33034954AAC05C9EC85E2577C06063D5C@XMB-RCD-111.cisco.com> Date: Wed, 28 Sep 2011 12:14:04 -0700 Message-ID: From: Cameron Byrne To: "Rajiv Asati (rajiva)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hui Deng , Behave WG , IETF Discussion , Mark Townsley , "Dan Wing \(dwing\)" , Softwires-wg list Subject: Re: [BEHAVE] [Softwires] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2011 19:11:17 -0000 On Wed, Sep 28, 2011 at 11:20 AM, Rajiv Asati (rajiva) w= rote: > Hi Cameron, > > Very interesting (& clever indeed). > > > How does this clever code ensure that all but a few (pesky apps) > continue to use IPv6 interface instead of the NAT46 interface? Rajiv, DNS64 is used. So anything that can take a AAAA will use a AAAA and the native IPv6 path, with or without NAT64 -- as needed. If the application itself delivers an IPv4 literal via protocols like MSN or Skype, there is a path and socket made available, that is what this NAT46 code does. As i mentioned before, i don't like this. But, i respect that it works and it solves a real problem for users of these ipv4-only apps. I personally find it easy to live with only IP version agnostic apps that work well in an IPv6-only NAT64/DNS64 network. I have been eating this "dog food" for over 18 months. I am happy to let the market and eco-system punish apps for not supporting IPv6, and for the market to reward apps that do support IPv6. I believe draft-ietf-behave-v4v6-bih-06 has too narrow of a scope to be useful since it explicitly does NOT support IPv4-only apps talking to IPv4 servers over an IPv6-only network Cameron > Cheers, > Rajiv > > >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of >> Cameron Byrne >> Sent: Wednesday, September 28, 2011 2:12 PM >> To: Mark Townsley >> Cc: Hui Deng; Softwires-wg list; Behave WG; IETF Discussion; Dan Wing > (dwing) >> Subject: Re: [BEHAVE] [Softwires] Last Call: > > 06.txt> (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed > Standard >> >> On Wed, Sep 28, 2011 at 9:26 AM, Mark Townsley > wrote: >> > >> > >> >>> +1 ... since the alternative is that apps that require ipv4 > sockets and >> >>> pass ipv4 literals are stranded on ipv6 only networks. >> >>> >> >>> Running code on the n900 shows that nat464 provides real user and >> >>> network benefit >> > >> > Frankly, I preferred it when you were running IPv6-only without BIH > on your >> trial, providing pressure to get rid of all those stranded literals > and >> pushing apps to open ipv6 sockets :-/ >> > >> > - Mark >> >> We're still doing that, and IPv6-only is still my philosophical >> preference and that is how we are launching the IPv6 + NAT64/DNS64 >> service into the production mobile network (real soon now). =A0No change >> in that path. >> >> But some "power users" wanted their IPv4-only applications like Skype >> to work so they coded a NAT46 work-around for the N900. =A0It is clever, >> it works. >> >> Their process of feeling the pain of a very few pesky IPv4-only apps >> and working around it is all documented here: >> http://talk.maemo.org/showthread.php?t=3D60320 >> >> Running NAT46 code here: http://code.google.com/p/n900ipv6/wiki/Nat64D >> >> In the end (as well as IPv6-only near term in mobile), IP version >> agnostic apps will prove to be more reliable and therefore will get >> more market share. >> >> Cameron >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > From dthaler@microsoft.com Wed Sep 28 14:05:41 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F051F0D26 for ; Wed, 28 Sep 2011 14:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.532 X-Spam-Level: X-Spam-Status: No, score=-110.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Xuya9m88OGR for ; Wed, 28 Sep 2011 14:05:40 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id D941C1F0CD2 for ; Wed, 28 Sep 2011 14:05:34 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 28 Sep 2011 14:08:24 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.1.339.2; Wed, 28 Sep 2011 14:08:23 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.161]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0339.002; Wed, 28 Sep 2011 14:08:23 -0700 From: Dave Thaler To: 'Marc Blanchet' Thread-Topic: [BEHAVE] presentations at IETF82 Thread-Index: Acx9ce8CjQWRmdE+TtelErQ7nsHzVgAPWbUAAAKv1wAAGhjqsA== Date: Wed, 28 Sep 2011 21:08:22 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B261C85@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <003c01cc7d71$efbc4010$cf34c030$@com> <006401cc7d7f$69a632c0$3cf29840$@com> In-Reply-To: <006401cc7d7f$69a632c0$3cf29840$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" , "behave-chairs@tools.ietf.org" , Dan Wing Subject: Re: [BEHAVE] presentations at IETF82 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2011 21:05:41 -0000 We said last time we would complete the existing milestones, including meet= ing as needed to finish them. Not doing so was never part of the question. We also said we'd consider the MIB work as being (the management) part of e= xisting work, if there's enough interest. (And there seems to be.) We will give priority to presentations that are on existing milestones. If there is still time left over, we'll allow presentations on things that = are in scope for discussion but have no milestones (even if they later move= to another group). =20 That's because even if work is happening elsewhere, some things are good to= also have the behave WG review. As long as we're meeting anyway, we can = use leftover meeting time, if any, to have a higher bandwidth review of oth= er items that should be reviewed by behave folks, rather than just using th= e mailing list. Hope that clarifies, -Dave > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Dan Wing > Sent: Tuesday, September 27, 2011 6:39 PM > To: 'Marc Blanchet' > Cc: behave@ietf.org; behave-chairs@tools.ietf.org > Subject: Re: [BEHAVE] presentations at IETF82 >=20 > > -----Original Message----- > > From: Marc Blanchet [mailto:marc.blanchet@viagenie.ca] > > Sent: Tuesday, September 27, 2011 5:22 PM > > To: Dan Wing > > Cc: behave@ietf.org; behave-chairs@tools.ietf.org > > Subject: Re: [BEHAVE] presentations at IETF82 > > > > Dan, I'm puzzled. Behave was shutting down. And then out of the blue, > > a meeting. Can you explain in general, and also in this context, what > > means "working group items"? >=20 > Yes. Let me explain from my perspective what I see happening with > BEHAVE: >=20 > BEHAVE is at an inflection point -- we are changing direction. We have > completed our initial work (STUN, TURN, multicast/TCP/UDP/ICMP behavior > documents) and completed what might be called our "NAT-PTbis" work (the > document set related to NAT64/DNS64). >=20 > As you all recall, we had very little discussion on the list prior to IET= F81, > which is why we had allocated only an hour. Participant energy was going > away because we had completed our major milestones. > So, we asked if we could close BEHAVE. We spent about half of our meetin= g > time at IETF81 talking about the future of BEHAVE rather than discussing > documents. >=20 > After IETF81, the chairs built a list of I-Ds that had been proposed into= the > working group, and have shared that with David Harrington, our AD. Some > of these documents seem like they fit into BEHAVE's existing charter and > some don't. >=20 > David Harrington is currently on vacation, and will return from vacation = next > week. I don't know what he will decide. I know that activity on the Beh= ave > mailing list and updated documents will likely keep the working group > energized and keep the chairs energized. And I would expect such activit= y > will also keep the working group open. >=20 > To answer your specific question: In the spirit of keeping things moving > along, I had requested more agenda time (two hours) than we had at IETF81 > (one hour) and I sent out the 'presentations for IETF82' email to ensure > existing work continues and that we learn of new work (-00 or updates to > existing documents) that is aimed at BEHAVE. This will provide additiona= l > input to David Harrington to decide if Behave should have additional > milestones, charter update, or be closed. >=20 > With multicast translation and the Mon/Tue Softwire interim in Beijing > (which I did not attend, but I know included discussions on double > translation (Dual-IVI)), there may well be more work coming towards Behav= e, > towards Softwire, another working group, or a new working group. >=20 > -d >=20 >=20 > > Marc. > > > > Le 2011-09-27 =E0 20:02, Dan Wing a =E9crit : > > > > > We requested a 2 hour slot for BEHAVE. > > > > > > If you would like to present in BEHAVE at IETF82, please send to > > > behave-chairs@tools.ietf.org: > > > - topic title > > > - presenter's name > > > - Internet Draft filename(s) > > > - time requested > > > > > > We will give priority to: > > > 1. working group items > > > 2. items actively discussed on the mailing list 3. new topics > > > > > > Please send the request by October 24th, which is also the cutoff > > > date for initial Internet Drafts (-00). > > > > > > -Dan and Dave > > > > > > > > > > > > _______________________________________________ > > > 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 ietfdbh@comcast.net Wed Sep 28 14:47:07 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBF421F8C0F for ; Wed, 28 Sep 2011 14:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqQnQT9va5Xm for ; Wed, 28 Sep 2011 14:47:06 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id C772B21F8C41 for ; Wed, 28 Sep 2011 14:47:02 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta06.westchester.pa.mail.comcast.net with comcast id eHMK1h0051YDfWL56MpsEC; Wed, 28 Sep 2011 21:49:52 +0000 Received: from [192.168.0.103] ([82.104.47.10]) by omta20.westchester.pa.mail.comcast.net with comcast id eMpQ1h00j0DB6QJ3gMpWDo; Wed, 28 Sep 2011 21:49:50 +0000 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Wed, 28 Sep 2011 23:49:08 +0200 From: David Harrington To: Marc Blanchet , Dan Wing Message-ID: Thread-Topic: [BEHAVE] presentations at IETF82 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: behave@ietf.org, behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] presentations at IETF82 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2011 21:47:07 -0000 Hi, There was a suggestion that behave should be shut down after its chartered work was finished. As Responsible AD, I requested feedback from the WG. My tendency is to favor closing the WG after the work completes. There is still some chartered work to be completed, so we are not closing the WG yet. Therefore a meeting is fully justified. There was discussion of whether some existing proposals would justify a new WG, or should be redirected to existing WGs. That analysis is still ongoing, and there are BOFs in development, such as the multicast transtion BOF, that might include some of the existing proposals. Some of the work could end up being addressed in softwires. Some of the work could end up being addressed in OPS area. New proposals may also be discussed at the behave meeting. We have no desire to stop discussion of worthy ideas while the IETF (and IESG) discusses how best to charter/organize the work going forward. David Harrington Transport Area Director On 9/28/11 2:22 AM, "Marc Blanchet" wrote: >Dan, I'm puzzled. Behave was shutting down. And then out of the blue, a >meeting. Can you explain in general, and also in this context, what means >"working group items"? > >Marc. > >Le 2011-09-27 =E0 20:02, Dan Wing a =E9crit : > >> We requested a 2 hour slot for BEHAVE. >>=20 >> If you would like to present in BEHAVE at IETF82, please send to >> behave-chairs@tools.ietf.org: >> - topic title >> - presenter's name >> - Internet Draft filename(s) >> - time requested >>=20 >> We will give priority to: >> 1. working group items >> 2. items actively discussed on the mailing list >> 3. new topics >>=20 >> Please send the request by October 24th, which is also the cutoff >> date for initial Internet Drafts (-00). >>=20 >> -Dan and Dave >>=20 >>=20 >>=20 >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From linfeng.john.zheng@gmail.com Wed Sep 28 23:37:28 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0468621F8A64; Wed, 28 Sep 2011 23:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.46 X-Spam-Level: X-Spam-Status: No, score=-0.46 tagged_above=-999 required=5 tests=[AWL=-1.913, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmwTZMJBhudP; Wed, 28 Sep 2011 23:37:27 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF9421F8548; Wed, 28 Sep 2011 23:37:08 -0700 (PDT) Received: by iaby26 with SMTP id y26so431678iab.31 for ; Wed, 28 Sep 2011 23:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=+BZfkZ0x0vfbRA/lyuGXO9amqdMboVsyfpvVvpymGGI=; b=pd0RDabf9wKos9PlVzR2ExOeIDVAg1EDLx5zHEAiQEcyt0Y47/aw2L/qMLOvM8EmjB 7WMCViKjwd3JwHVGET+lDuTJ/51mxRQWY1x6E5XI5l21lJQLpeF6UL2x7mpE411tEB4M IPPlXXOMy/eO/M/cciKF4X9rhNV9q/ntJ+ot0= MIME-Version: 1.0 Received: by 10.231.49.147 with SMTP id v19mr8732223ibf.64.1317278398430; Wed, 28 Sep 2011 23:39:58 -0700 (PDT) Received: by 10.231.26.234 with HTTP; Wed, 28 Sep 2011 23:39:58 -0700 (PDT) Date: Thu, 29 Sep 2011 14:39:58 +0800 Message-ID: From: Linfeng Zheng To: behave@ietf.org, softwires@ietf.org Content-Type: multipart/alternative; boundary=0015176f07b4023d3904ae0ec7d7 Subject: Re: [BEHAVE] [Softwires] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 06:37:28 -0000 --0015176f07b4023d3904ae0ec7d7 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable On Wed, Sep 28, 2011 at 11:20 AM, Rajiv Asati (rajiva) wrote: agree > Hi Cameron, > > Very interesting (& clever indeed). > > > How does this clever code ensure that all but a few (pesky apps) > continue to use IPv6 interface instead of the NAT46 interface? Rajiv, DNS64 is used. So anything that can take a AAAA will use a AAAA and the native IPv6 path, with or without NAT64 -- as needed. If the application itself delivers an IPv4 literal via protocols like MSN or Skype, there is a path and socket made available, that is what this NAT46 code does. As i mentioned before, i don't like this. But, i respect that it works and it solves a real problem for users of these ipv4-only apps. I personally find it easy to live with only IP version agnostic apps that work well in an IPv6-only NAT64/DNS64 network. I have been eating this "dog food" for over 18 months. I am happy to let the market and eco-system punish apps for not supporting IPv6, and for the market to reward apps that do support IPv6. I believe draft-ietf-behave-v4v6-bih-06 has too narrow of a scope to be useful since it explicitly does NOT support IPv4-only apps talking to IPv4 servers over an IPv6-only network Cameron > Cheers, > Rajiv > > --=20 =B9=E2=C3=F7=CB=F9=BD=E1=B5=C4=B9=FB=D7=D3=BE=CD=CA=C7=D2=BB=C7=D0=C1=BC=C9= =C6=A1=A2=B9=AB=D2=E5=A1=A2=B3=CF=CA=B5=A1=A3 =B8=A55:9 =D6=A3=C1=D6=B7=E5 John Linfeng Zheng =B5=E7=BB=B0=A3=A8Tel): 86-25-8577-1689 =CA=D6=BB=FA=A3=A8Mobile): 15195762065 --0015176f07b4023d3904ae0ec7d7 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable 
On Wed, Sep 28, 2011 at 11:20 AM, Rajiv Asati (rajiva) <rajiva at cisco.com> wrote:

agree
 
> Hi Cameron,

>
> Very interesting (& clever indeed).
>
>
> How does this clever code ensure that all but a few (pesky apps)
> continue to use IPv6 interface instead of the NAT46 interface?

Rajiv,

DNS64 is used.  So anything that can take  a AAAA will use a AAAA and
the native IPv6 path, with or without NAT64 -- as needed.

If the application itself delivers an IPv4 literal via protocols like
MSN or Skype, there is a path and socket made available, that is what
this NAT46 code does.

As i mentioned before, i don't like this.  But, i respect that it
works and it solves a real problem for users of these ipv4-only apps.
I personally find it easy to live with only IP version agnostic apps
that work well in an IPv6-only NAT64/DNS64 network.  I have been
eating this "dog food" for over 18 months.  I am happy to let the
market and eco-system punish apps for not supporting IPv6, and for the
market to reward apps that do support IPv6.

I believe draft-ietf-behave-v4v6-bih-06 has too narrow of a scope to
be useful since it explicitly does NOT support IPv4-only apps talking
to IPv4  servers over an IPv6-only network

Cameron

> Cheers,
> Rajiv
>
>


--
=B9=E2=C3=F7=CB=F9=BD=E1=B5=C4=B9=FB=D7=D3=BE=CD=CA=C7=D2=BB=C7=D0=C1= =BC=C9=C6=A1=A2=B9=AB=D2=E5=A1=A2=B3=CF=CA=B5=A1=A3    =    =B8=A55:9
 
=D6=A3=C1=D6=B7=E5 John Linfeng Zheng
=B5=E7=BB=B0=A3=A8Tel): 86-25-8577-1689
=CA=D6=BB=FA=A3=A8Mobile): 15195762065

--0015176f07b4023d3904ae0ec7d7-- From mohamed.boucadair@orange.com Thu Sep 29 04:24:07 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A007321F8C11 for ; Thu, 29 Sep 2011 04:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sR+YD3Gy6Gio for ; Thu, 29 Sep 2011 04:24:06 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 380D021F8BC5 for ; Thu, 29 Sep 2011 04:24:05 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 7B8223243DB; Thu, 29 Sep 2011 13:26:55 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 5F29E27C0BD; Thu, 29 Sep 2011 13:26:55 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Thu, 29 Sep 2011 13:26:55 +0200 From: To: "Poscic, Kristian (Kristian)" , "'behave@ietf.org'" Date: Thu, 29 Sep 2011 13:26:53 +0200 Thread-Topic: predictable translations Thread-Index: Acx5WV97aAu68hVNTaay9qYQdmoSIAAJTlUgAA1r3VAAFchtkAEjpa2Q Message-ID: <94C682931C08B048B7A8645303FDC9F355A8F48787@PUEXCB1B.nanterre.francetelecom.fr> References: <737DDEA1297B0348BA6AB9EA3216A67F02CDB54BE4@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <2073A6C5467C99478898544C6EBA3F4602BC3C820D@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <94C682931C08B048B7A8645303FDC9F355A8E5A5FC@PUEXCB1B.nanterre.francetelecom.fr> <2073A6C5467C99478898544C6EBA3F4602BC3C82BF@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> In-Reply-To: <2073A6C5467C99478898544C6EBA3F4602BC3C82BF@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F355A8F48787PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.9.29.103314 Subject: Re: [BEHAVE] predictable translations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 11:24:07 -0000 --_000_94C682931C08B048B7A8645303FDC9F355A8F48787PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Kris, Thank you for the clarification. I was confused because I thought you meant a "stateless NAT" which is not t= he case in deterministic NAT (since NAT mappings are still required for tra= nslating IP datagrams). Cheers, Med ________________________________ De : Poscic, Kristian (Kristian) [mailto:kristian.poscic@alcatel-lucent.com= ] Envoy=E9 : vendredi 23 septembre 2011 18:21 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; 'behave@ietf.org' Objet : RE: predictable translations Hi Med, By predictable translation I mean deterministic NAT. For now, I'm just trying to evaluate (for my own sake) if this deterministi= c NAT makes any sense since 1) would take care of the concerns that I have.= If deterministic NAT makes deployable sense [for a reason that I yet need = to find, since 1) already takes care of my concerns], then I'm trying to ev= aluate surrounding issues related to ease of integration into existing OS = (which it looks like does not come into play) and any other legal issues re= lated to use of already possibly patented algorithms. Thanks, Kris From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Thursday, September 22, 2011 11:00 PM To: Poscic, Kristian (Kristian); 'behave@ietf.org' Subject: RE: predictable translations Dear Kris, Could please precise more what you mean by "predictable translation"? (1) Do you want to eliminate the volume of CGN logs (e.g, few entries per c= ustomer) or (2) you want to eliminate the CGN logging (e.g., rely on DHCP r= ecords)? (1) can be done in the CGN itself by design or configuration of the CGN to = use port ranges. This is already supported by CGN implementation including = A(..)U ;-) (2) can be supported only if you eliminate the NAT function in the CGN whic= h should be a PRR (Port Range Router; http://tools.ietf.org/html/draft-bouc= adair-port-range-02#section-6) instead. Cheers, Med ________________________________ De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Poscic, Kristian (Kristian) Envoy=E9 : vendredi 23 septembre 2011 01:28 =C0 : 'behave@ietf.org' Objet : Re: [BEHAVE] predictable translations I looked at this draft draft-bsd-softwire-stateless-port-index-analysis-00<= http://datatracker.ietf.org/doc/draft-bsd-softwire-stateless-port-index-ana= lysis/> which examines 6 different algorithms for predictable translation a= pplicable to v4/v6 translation but I guess it can be potentially adopted fo= r v4 to v4 conversions as well. As my coworker (who is probably on this list) says "too many deterministic = nat drafts make for non-deterministic behaviours". Is there any plan to adopt one as a standard? Thanks, Kris From: Poscic, Kristian (Kristian) Sent: Thursday, September 22, 2011 11:57 AM To: behave@ietf.org Subject: predictable translations Hi there - Does anyone knows of any draft that is addressing a more predictable transl= ations between the inside IP and outside IP + port range when it comes to N= AT44. For example in order to avoid logging, IPv4 inside address would be automat= ically (via an algorithm) be converted to an outside IPv4 address + a port= range. This mapping would be unique so that no logging is required. The re= vertive algo would be able to convert the outside IP + port back to the in= side IP. I've seen some drafts addressing something similar in the softwire WG but t= hey all deal with IPv4/IPv6 translations. Thanks, Kris --_000_94C682931C08B048B7A8645303FDC9F355A8F48787PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Kris,
 
Thank you for the clarification.
 
I was confused because I thought you meant a= =20 "stateless NAT" which is not the case in deterministic NAT (since NAT mappi= ngs=20 are still required for translating IP datagrams).
 
Cheers,
Med

De : Poscic, Kristian (Kristian)=20 [mailto:kristian.poscic@alcatel-lucent.com]
Envoy=E9 : vend= redi 23=20 septembre 2011 18:21
=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP;=20 'behave@ietf.org'
Objet : RE: predictable=20 translations

Hi Med,

By predictable translat= ion I=20 mean deterministic NAT.

 

For now, I=92m just try= ing to=20 evaluate (for my own sake) if this deterministic NAT makes any sense since = 1)=20 would take care of the concerns that I have. If deterministic NAT makes=20 deployable sense [for a reason that I yet need to find, since 1) already ta= kes=20 care of my concerns], then I=92m trying to evaluate surrounding issues rela= ted to=20 ease of integration into existing OS  (which it looks like does not co= me=20 into play) and any other legal issues related to use of already possibly=20 patented algorithms.

 

Thanks,

Kris<= /P>

 

From:<= /B>=20 mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20
Sent: Thursday, September 22, 2011 11:00 PM
To: Poscic= ,=20 Kristian (Kristian); 'behave@ietf.org'
Subject: RE: predictable=20 translations

 

Dear=20 Kris,

 

Could pl= ease=20 precise more what you mean by "predictable translation"?

 

(1) Do y= ou want=20 to eliminate the volume of CGN logs (e.g, few entries per customer) or (2) = you=20 want to eliminate the CGN logging (e.g., rely on DHCP records)?=

 

(1) can = be done=20 in the CGN itself by design or configuration of the CGN to use port ranges.= This=20 is already supported by CGN implementation including A(..)U ;-)

 

(2) can = be=20 supported only if you eliminate the NAT function in the CGN which should be= a=20 PRR (Port Range Router; http://tools.ietf.org/html/draft-boucadair-port-range-02#section-6)=20 instead.

 

 

Cheers,<= /SPAN>

Med

&nbs= p;

De :=20 behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de=20 Poscic, Kristian (Kristian)
Envoy=E9 : vendredi 23 septembre= 2011=20 01:28
=C0 : 'behave@ietf.org'
Objet : Re: [BE= HAVE]=20 predictable translations

I looked at this draft= =20 draft-bsd-softwire-stateless-port-index-analysis-00=20 which examines 6 different algorithms for predictable translation applicabl= e to=20 v4/v6 translation but I guess it can be potentially adopted for v4 to v4=20 conversions as well.

 

As=20 my coworker (who is probably on this list) says =93= too=20 many deterministic nat drafts make for non-deterministic behaviours=94.=20

= Is=20 there any plan to adopt one as a standard?

= Thanks,

= Kris

 

From:<= /B> Poscic, Kris= tian=20 (Kristian)
Sent: Thursday, September 22, 2011 11:57 AM
To:= =20 behave@ietf.org
Subject: predictable=20 translations

 

Hi there =96

Does anyone knows of any draft that is addressing a mo= re=20 predictable translations between the inside IP and outside IP + port range = when=20 it comes to NAT44.

For example in order to avoid logging, IPv4 inside add= ress=20 would be automatically (via an algorithm) be converted to an outside IPv4=20 address  + a port range. This mapping would be unique so that no loggi= ng is=20 required. The revertive algo would be able to convert the outside IP + port= back=20  to the inside IP.

 

I=92ve seen some drafts addressing something similar i= n the=20 softwire WG but they all deal with IPv4/IPv6 translations.

Thanks,

Kris

--_000_94C682931C08B048B7A8645303FDC9F355A8F48787PUEXCB1Bnante_-- From dwing@cisco.com Thu Sep 29 08:48:12 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47F421F8DFD; Thu, 29 Sep 2011 08:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.841 X-Spam-Level: X-Spam-Status: No, score=-102.841 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMQ2fGwutLX9; Thu, 29 Sep 2011 08:48:12 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6F77A21F8DF2; Thu, 29 Sep 2011 08:48:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1332; q=dns/txt; s=iport; t=1317311464; x=1318521064; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=QlwZech+5VfkyBkIRjRWbXNRgSvs8AbrI6YjFDdKe5I=; b=IKIKOkRgkwm8cinApKJnfdzSIq9EjYm88D9TsXhuLOpF+qP6p7Oeghb7 3AUnDuL552U3E2HFgsmuTiJwOeN35mhyHy6uVu6m99BKj3+Wkk+oX8o81 HYJAx+ChwW/0YPIjm4d6ruLSsL2E81d4uhkEDEoF6w3mJ3cD0yNPe5/Bn s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4AAM2ThE6rRDoH/2dsb2JhbABBmRGBa40Td4FTAQEBAQIBCAoBF08FBwEDAgkPAgQBASgHGSMKCQgBAQQBEgsXh1iaJQGeN4cTBIdCMJ0+ X-IronPort-AV: E=Sophos;i="4.68,461,1312156800"; d="scan'208";a="5017472" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 29 Sep 2011 15:50:59 +0000 Received: from dwingWS ([10.89.10.59]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8TFovYP022338; Thu, 29 Sep 2011 15:50:58 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Despr=E9s'?=" , "'Softwires-wg'" References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> <916CE6CF87173740BC8A2CE44309696203771FAB@008-AM1MPN1-037.mgdnok.nokia.com> <09bd01cc7d16$cd715190$6853f4b0$@com> <18748250-5D4E-4470-93E6-FFA3FDB87E36@free.fr> In-Reply-To: <18748250-5D4E-4470-93E6-FFA3FDB87E36@free.fr> Date: Thu, 29 Sep 2011 08:50:57 -0700 Message-ID: <060b01cc7ebf$9500c250$bf0246f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acx+oV6qKV1e+gGiSNqKLVRSn1MLzAAHfzHQ Content-Language: en-us Cc: 'Behave WG' , 'Satoru Matsushima' , 'IETF discussion list' Subject: Re: [BEHAVE] ... Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 15:48:13 -0000 > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] > Sent: Thursday, September 29, 2011 5:14 AM > To: Softwires-wg > Cc: Dan Wing; Teemu Savolainen; Satoru Matsushima; IETF discussion > list; Behave WG > Subject: Re: [BEHAVE] ... Dual Stack Hosts Using "Bump-in-the-Host" > (BIH)) >=20 > Hi all, >=20 > Le 27 sept. 2011 =E0 21:10, Dan Wing a =E9crit : >=20 > >> -----Original Message----- > >> From: teemu.savolainen@nokia.com = [mailto:teemu.savolainen@nokia.com] > ... > >> I mean does existing > >> applications work better if double translation is done in > deterministic > >> manner? > > > > Yes, it allows the CPE to implement an ALG -- if an application = needs > > an ALG (e.g., active-mode FTP). >=20 > +1 >=20 > As Softwire is concerned, it is worth noting here that, with > encapsulation rather than double translation, NO ALG is ever needed. > (Neither in ISP Border Relay nodes, nor in CPEs, nor in BIH hosts). Do a message flow for active mode FTP with 4rd. I did one, and it needs an ALG in the 4rd NAPT44 function. -d > It is sometimes argued that double translation could be as simple than > encapsulation. > AFAIK, this discussion clearly indicates the contrary. > (No ALGs eliminates any variants about where to put them.) >=20 > RD From phdgang@gmail.com Thu Sep 29 09:06:21 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D667B21F8E70; Thu, 29 Sep 2011 09:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joQqwDhWebmj; Thu, 29 Sep 2011 09:06:21 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C7BB821F8E63; Thu, 29 Sep 2011 09:06:20 -0700 (PDT) Received: by wwf22 with SMTP id 22so916389wwf.13 for ; Thu, 29 Sep 2011 09:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4fbu4mR01f+Yjw8TI3K5LWxfwY4ROFzBSCViEXpXWqA=; b=qrdpk4KrXxBFT0c+PJf9kh3hReXivH8gumrds6kuvgZZ6/N8vL6b1oO7v9Tu3NOP/9 H0m7PFxp5LrvRD6BtFShCRz0AidJkhzlhx7zGkRyas767VIWiflf/oABEJltRmTycOIH YKAGXJ/WD7BNWKWTPDAQb8cQvDcRaAu8iBesc= MIME-Version: 1.0 Received: by 10.227.112.137 with SMTP id w9mr1578282wbp.3.1317312549212; Thu, 29 Sep 2011 09:09:09 -0700 (PDT) Received: by 10.180.84.161 with HTTP; Thu, 29 Sep 2011 09:09:08 -0700 (PDT) In-Reply-To: <013d01cc7df7$7af51d20$70df5760$@com> References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> <09b701cc7d16$6943df30$3bcb9d90$@com> <013d01cc7df7$7af51d20$70df5760$@com> Date: Fri, 30 Sep 2011 00:09:08 +0800 Message-ID: From: GangChen To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Cc: Hui Deng , behave@ietf.org, ietf@ietf.org, softwires@ietf.org, Cameron Byrne Subject: Re: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 16:06:22 -0000 Hello Dan, > Can you run an FTP server on the BIH host, and have it do active mode > transfers and passive mode transfers? Could you elaborate the scenario? You assume BIH host taking FTP sever. I'm not sure whether following scenarios are correct There are two possibilities Option 1: +---------------+ |BIH(FTP sever) |----------NAT64-------FTP Client +---------------+ Option 2: +---------------+ |BIH(FTP sever) |--------------FTP Client +---------------+ In the case of Option 1, it can't work since NAT64 couldn't support IPv4 initiated session In the case of Option 2, it could work if BIH do ALG BTW, if BIH takes the role of FTP client, I guess it works in both active and passive mode when NAT64 do ALG If there is something wrong, please correct me Many thanks Gang From rajiva@cisco.com Thu Sep 29 09:19:29 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045FB21F8CD4; Thu, 29 Sep 2011 09:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0sI7hvNJ4mj; Thu, 29 Sep 2011 09:19:28 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 15F9E21F8C96; Thu, 29 Sep 2011 09:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2198; q=dns/txt; s=iport; t=1317313334; x=1318522934; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=bFP4jBZXqhZpj0KUKO41SbJ8P2e5+rErjCzVWOUoAhk=; b=I3/Tb1u9ykUwYEDYAkdUqlnLl1QOQRi7FsCMo6eBYX3g7kQzet7cmeb+ aX9nB6i32F+z4FkCGxJLxHMKdDKT7gQLsFCqZmLDfp4LwWFk+qKZKsgOW WnMBPEZYGh4F921ndyHEEyFn08z/yEKehY4Mxfa2lwTw/0z0ENJk4WL6A s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4AANaahE6tJV2Z/2dsb2JhbAA3CpkRjn53gVMBAQEBAgEBAQEPAR0KNAsFBwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHWAaaUAGeOAODaIJKYQSHcpEQjCw X-IronPort-AV: E=Sophos;i="4.68,462,1312156800"; d="scan'208";a="24950367" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 29 Sep 2011 16:22:13 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8TGMDmM003228; Thu, 29 Sep 2011 16:22:13 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Sep 2011 11:22:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Sep 2011 11:22:12 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C0606408A@XMB-RCD-111.cisco.com> In-Reply-To: <201109291542023124831@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] the option is a issue in double-translation? Thread-Index: Acx+e2jTbKlgDLmxSzyOA5Ja7hYbCgARyn7Q References: <201109291542023124831@gmail.com> From: "Rajiv Asati (rajiva)" To: , "softwires" X-OriginalArrivalTime: 29 Sep 2011 16:22:13.0122 (UTC) FILETIME=[F207C620:01CC7EC3] Cc: Behave WG Subject: Re: [BEHAVE] [Softwires] the option is a issue in double-translation? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 16:19:29 -0000 Hi Xie, > China Telecom have placed the prototype of DIVI in its product network > and gave a systematic test , and we haven't found any reachibility problem due > to option processing in tranlation box. Moreover, during Tinghua 100th Thanks for sharing your deployment experience. This invalidates the common misconception of IP options being an issue on the internet. In fact, the usage of IP option e.g. Router Alert on the internet is discouraged/not recommended any way (see the below INT area document already in the RFC-Editor queue) https://datatracker.ietf.org/doc/draft-ietf-intarea-router-alert-conside rations/ /// Specifically, it provides recommendation against using the Router Alert in the end-to-end open Internet as well as identify controlled /// Cheers, Rajiv > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf > Of Chongfeng > Sent: Thursday, September 29, 2011 3:43 AM > To: softwires > Subject: [Softwires] the option is a issue in double-translation? >=20 >=20 >=20 > Hi, all, >=20 > This interium talked many times about whether the option processing is > harmful to double-translation, I 'd like to provide the following facts, >=20 > China Telecom have placed the prototype of DIVI in its product network > and gave a systematic test , and we haven't found any reachibility problem due > to option processing in tranlation box. Moreover, during Tinghua 100th > Anniversay, we deployed DIVI for the IPv4 traffice convery between China > Telecom and CERNET, and multiple services, such as Web, Video and sensoring > data, were supported stablely, up to now, no failure happened due to the > option processing in double translation. >=20 > Thank you! >=20 > XIE Chongfeng > 2011-09-29 > ------------------------------------------- > Network Technology Research Department > China Telecom Corporation Limited Beijing Research Institute > Tel:+86-10-58552116 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From dwing@cisco.com Thu Sep 29 09:25:21 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D9321F8E05; Thu, 29 Sep 2011 09:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.834 X-Spam-Level: X-Spam-Status: No, score=-102.834 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zq7T8SnCElr; Thu, 29 Sep 2011 09:25:20 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id A972B21F8DE0; Thu, 29 Sep 2011 09:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2662; q=dns/txt; s=iport; t=1317313691; x=1318523291; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=2D2pTgllPiQl8ctu2ECNueCJbHSjUjbAvBfCXUDutBo=; b=f1t5nAV04Bbc/aTAQ25gC5bOc4Rs2wl3HV2Nyqcxpb7qOyaLPS2D5OmG 2GilTJx03fMMtIIyupRi6J79A0XnRkxEhMSk5v1Pn2I0EOI2pfSI6Io1u jBd/9Tr15yMj5G1SaUKxs76boEJAiU4AX/V8DEUZj0/+hITBc//2zLdrU Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4AAMqbhE6rRDoJ/2dsb2JhbABBmRGBa40Td4FTAQEBAQIBAQEBBQoBF0QLBQcBAwIJDwIEAQEoBxkOFQoJCAEBBBMLF4dYBppDAZ46A4cTBIdCMJ0+ X-IronPort-AV: E=Sophos;i="4.68,462,1312156800"; d="scan'208";a="5024627" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 29 Sep 2011 16:28:11 +0000 Received: from dwingWS ([10.89.10.59]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8TGS9FA017966; Thu, 29 Sep 2011 16:28:10 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Despr=E9s'?=" References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> <916CE6CF87173740BC8A2CE44309696203771FAB@008-AM1MPN1-037.mgdnok.nokia.com> <09bd01cc7d16$cd715190$6853f4b0$@com> <18748250-5D4E-4470-93E6-FFA3FDB87E36@free.fr> <060b01cc7ebf$9500c250$bf0246f0$@com> <2A6C6CAF-1A2F-49C8-9C11-E9DAB7F72879@free.fr> In-Reply-To: <2A6C6CAF-1A2F-49C8-9C11-E9DAB7F72879@free.fr> Date: Thu, 29 Sep 2011 09:28:09 -0700 Message-ID: <065801cc7ec4$c745ec40$55d1c4c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acx+wq0cXqemJq58QZiQS0VrTHGhXQAAeAMA Content-Language: en-us Cc: 'Softwires-wg' , 'Behave WG' , 'IETF discussion list' Subject: Re: [BEHAVE] ... Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 16:25:21 -0000 > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] > Sent: Thursday, September 29, 2011 3:13 AM > To: Dan Wing > Cc: 'Softwires-wg'; 'Behave WG'; 'IETF discussion list'; 'Teemu > Savolainen' > Subject: Re: [BEHAVE] ... Dual Stack Hosts Using "Bump-in-the-Host" > (BIH)) >=20 >=20 > Le 29 sept. 2011 =E0 23:50, Dan Wing a =E9crit : >=20 > >> -----Original Message----- > >> From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] > >> Sent: Thursday, September 29, 2011 5:14 AM > >> To: Softwires-wg > >> Cc: Dan Wing; Teemu Savolainen; Satoru Matsushima; IETF discussion > >> list; Behave WG > >> Subject: Re: [BEHAVE] ... Dual Stack Hosts Using "Bump-in-the-Host" > >> (BIH)) > >> > >> Hi all, > >> > >> Le 27 sept. 2011 =E0 21:10, Dan Wing a =E9crit : > >> > >>>> -----Original Message----- > >>>> From: teemu.savolainen@nokia.com > [mailto:teemu.savolainen@nokia.com] > >> ... > >>>> I mean does existing > >>>> applications work better if double translation is done in > >> deterministic > >>>> manner? > >>> > >>> Yes, it allows the CPE to implement an ALG -- if an application > needs > >>> an ALG (e.g., active-mode FTP). > >> > >> +1 > >> > >> As Softwire is concerned, it is worth noting here that, with > >> encapsulation rather than double translation, NO ALG is ever = needed. > >> (Neither in ISP Border Relay nodes, nor in CPEs, nor in BIH hosts). > > > > Do a message flow for active mode FTP with 4rd. >=20 > Two cases (which I din't differentiate, sorry for that). > a) The hosts handles 4rd > b) The host is behind a NAT44 ( >=20 > In case b), an ALG is needed as usual, as the CPE-NAT44 does its usual > job for that. > Case a) was assumed to apply to this discussion, considering a host > that is directly the 4rd CE. >=20 > > I did one, and > > it needs an ALG in the 4rd NAPT44 function. >=20 > In case a), the host can assign to an FTP application a pair of ports > of its assigned range. > Thus no translation is needed (e2e transparency). >=20 > OK? If BIH worked that way, BIH would fail when the host has multiple interfaces running, and those interfaces have different port ranges. -d > RD >=20 >=20 >=20 > > > > -d > > > >> It is sometimes argued that double translation could be as simple > than > >> encapsulation. > >> AFAIK, this discussion clearly indicates the contrary. > >> (No ALGs eliminates any variants about where to put them.) > >> > >> RD > > > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > From rajiva@cisco.com Thu Sep 29 09:43:36 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF3C21F8E40; Thu, 29 Sep 2011 09:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iS2voZRPgKB; Thu, 29 Sep 2011 09:43:35 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A3EA921F8E3B; Thu, 29 Sep 2011 09:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=4341; q=dns/txt; s=iport; t=1317314786; x=1318524386; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=s5BZZJY23NZkHfMHsjlH7yX3plspTbsVIf+lGJRTIWU=; b=K0I2RD+8Oa+vU0OL9krufLCZH5/4b22l1Eea4aFP7kFOp+WEEm1T6pMB jsZ31A1z0syP3LYq1vQpbHUT5UMpaam+4lqJ+VIXtu0PlypQ/7U7PsCPv d2gWR1mmZWR0t86+UTA3f0vzYlbm9vAlve8KterBVT9xOCk1q8/v96x1M A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4AAGyghE6tJV2Z/2dsb2JhbAAnGpkRjn53gVMBAQEBAgEBAQEPAR0+CwUHBAIBCA4DBAEBAQoGEwQBBgEgBh8JCAEBBBMIGodYBiSaNAGePoYyYQSHQjCREIRvhz0 X-IronPort-AV: E=Sophos;i="4.68,462,1312156800"; d="scan'208";a="24959052" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 29 Sep 2011 16:46:26 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8TGkP8W017214; Thu, 29 Sep 2011 16:46:25 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Sep 2011 11:46:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Sep 2011 11:46:25 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C060640A3@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] [Softwires] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard Thread-Index: Acx+EtBF2fZPt7lFTtmSY0yp+eucTAAnAh2g References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com><081701cc7cac$837a9610$8a6fc230$@com><09b701cc7d16$6943df30$3bcb9d90$@com><013d01cc7df7$7af51d20$70df5760$@com><989D4A28-9E89-45EB-A256-5B55D32E150F@townsley.net><067E6CE33034954AAC05C9EC85E2577C06063D5C@XMB-RCD-111.cisco.com> From: "Rajiv Asati (rajiva)" To: "Cameron Byrne" X-OriginalArrivalTime: 29 Sep 2011 16:46:25.0693 (UTC) FILETIME=[53D484D0:01CC7EC7] Cc: Hui Deng , Behave WG , IETF Discussion , Mark Townsley , "Dan Wing \(dwing\)" , Softwires-wg list Subject: Re: [BEHAVE] [Softwires] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 16:43:36 -0000 Hi Cameron, > If the application itself delivers an IPv4 literal via protocols like > MSN or Skype, there is a path and socket made available, that is what > this NAT46 code does. Is there a dependency on the existence of IPv4 literal so as to use the = v4-interface provided by NAT46 code? IOW, does every IP-only app work = now on n900? Cheers, Rajiv > -----Original Message----- > From: Cameron Byrne [mailto:cb.list6@gmail.com] > Sent: Wednesday, September 28, 2011 3:14 PM > To: Rajiv Asati (rajiva) > Cc: Mark Townsley; Hui Deng; Softwires-wg list; Behave WG; IETF = Discussion; > Dan Wing (dwing) > Subject: Re: [BEHAVE] [Softwires] Last Call: = 06.txt> (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed = Standard >=20 > On Wed, Sep 28, 2011 at 11:20 AM, Rajiv Asati (rajiva) = > wrote: > > Hi Cameron, > > > > Very interesting (& clever indeed). > > > > > > How does this clever code ensure that all but a few (pesky apps) > > continue to use IPv6 interface instead of the NAT46 interface? >=20 > Rajiv, >=20 > DNS64 is used. So anything that can take a AAAA will use a AAAA and > the native IPv6 path, with or without NAT64 -- as needed. >=20 > If the application itself delivers an IPv4 literal via protocols like > MSN or Skype, there is a path and socket made available, that is what > this NAT46 code does. >=20 > As i mentioned before, i don't like this. But, i respect that it > works and it solves a real problem for users of these ipv4-only apps. > I personally find it easy to live with only IP version agnostic apps > that work well in an IPv6-only NAT64/DNS64 network. I have been > eating this "dog food" for over 18 months. I am happy to let the > market and eco-system punish apps for not supporting IPv6, and for the > market to reward apps that do support IPv6. >=20 > I believe draft-ietf-behave-v4v6-bih-06 has too narrow of a scope to > be useful since it explicitly does NOT support IPv4-only apps talking > to IPv4 servers over an IPv6-only network >=20 > Cameron >=20 > > Cheers, > > Rajiv > > > > > >> -----Original Message----- > >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of > >> Cameron Byrne > >> Sent: Wednesday, September 28, 2011 2:12 PM > >> To: Mark Townsley > >> Cc: Hui Deng; Softwires-wg list; Behave WG; IETF Discussion; Dan = Wing > > (dwing) > >> Subject: Re: [BEHAVE] [Softwires] Last Call: > > >> 06.txt> (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to = Proposed > > Standard > >> > >> On Wed, Sep 28, 2011 at 9:26 AM, Mark Townsley > > wrote: > >> > > >> > > >> >>> +1 ... since the alternative is that apps that require ipv4 > > sockets and > >> >>> pass ipv4 literals are stranded on ipv6 only networks. > >> >>> > >> >>> Running code on the n900 shows that nat464 provides real user = and > >> >>> network benefit > >> > > >> > Frankly, I preferred it when you were running IPv6-only without = BIH > > on your > >> trial, providing pressure to get rid of all those stranded literals > > and > >> pushing apps to open ipv6 sockets :-/ > >> > > >> > - Mark > >> > >> We're still doing that, and IPv6-only is still my philosophical > >> preference and that is how we are launching the IPv6 + NAT64/DNS64 > >> service into the production mobile network (real soon now). =A0No = change > >> in that path. > >> > >> But some "power users" wanted their IPv4-only applications like = Skype > >> to work so they coded a NAT46 work-around for the N900. =A0It is = clever, > >> it works. > >> > >> Their process of feeling the pain of a very few pesky IPv4-only = apps > >> and working around it is all documented here: > >> http://talk.maemo.org/showthread.php?t=3D60320 > >> > >> Running NAT46 code here: = http://code.google.com/p/n900ipv6/wiki/Nat64D > >> > >> In the end (as well as IPv6-only near term in mobile), IP version > >> agnostic apps will prove to be more reliable and therefore will get > >> more market share. > >> > >> Cameron > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www.ietf.org/mailman/listinfo/behave > > From dwing@cisco.com Thu Sep 29 09:47:38 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF8C21F8A64; Thu, 29 Sep 2011 09:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.978 X-Spam-Level: X-Spam-Status: No, score=-102.978 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g191mwgW8ZWo; Thu, 29 Sep 2011 09:47:37 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 15A4F21F8586; Thu, 29 Sep 2011 09:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2333; q=dns/txt; s=iport; t=1317315025; x=1318524625; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=mNa4O+KEE15t7W//SLmFov7QWVbuu+uRnZzH75qQsRA=; b=M/Ia3p8igHEynukaJbwUPxeQsZkFg+WeJCo3WxGGABwhl5wh9UEytHwt BrqdCHzChPa1sMpXRccM926EIoXvBciwuAvWoQBhI6n/Oa7WICFuHZ5Fd anK8YFgE6r8NEYgCe1Ft/7SXe8ojmhYZNvuJT3cvzavJXxEsNZA4GJn9k Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4AABihhE6rRDoI/2dsb2JhbABBmRGBa40Td4FTAQEBAQIBAQEBBQoBFxA0CwUHAQMCCQ8CBAEBJAQHGQ4VCgkIAQEECgkLF4dYBppPAZ47A4cTBIdynT4 X-IronPort-AV: E=Sophos;i="4.68,462,1312156800"; d="scan'208";a="5030956" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 29 Sep 2011 16:50:24 +0000 Received: from dwingWS ([10.89.10.59]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8TGoMjC012359; Thu, 29 Sep 2011 16:50:22 GMT From: "Dan Wing" To: "'GangChen'" References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> <09b701cc7d16$6943df30$3bcb9d90$@com> <013d01cc7df7$7af51d20$70df5760$@com> In-Reply-To: Date: Thu, 29 Sep 2011 09:50:21 -0700 Message-ID: <067d01cc7ec7$e1fc9400$a5f5bc00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acx+wiSe6suuvx38QEOzQXrMgihNbAABNMOQ Content-Language: en-us Cc: 'Hui Deng' , softwires@ietf.org, 'Cameron Byrne' , behave@ietf.org, ietf@ietf.org Subject: Re: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 16:47:38 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of GangChen > Sent: Thursday, September 29, 2011 9:09 AM > To: Dan Wing > Cc: Hui Deng; behave@ietf.org; ietf@ietf.org; softwires@ietf.org; > Cameron Byrne > Subject: Re: [BEHAVE] Last Call: > (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard > > Hello Dan, > > > Can you run an FTP server on the BIH host, and have it do active mode > > transfers and passive mode transfers? > > Could you elaborate the scenario? The FTP server, using BIH, is an IPv4-only FTP server. It needs to listen on port 21 (the FTP control port), although if a URI is used to access the FTP server, an alternate control port can work alright (ftp://ftp.example.com:12345). For a passive-mode transfer, the FTP server only needs to know the "PASV" command (because that is all that's necessary for an IPv4 FTP server; IPv4 FTP servers don't need to support EPSV and many on the Internet do not support EPSV). Also for a passive-mode transfer, the FTP client needs to initiate the TCP connections to a port on the FTP server. For an active-mode transfer, the FTP server connects back to the client, using the IPv4 address indicated in the FTP control channel. > You assume BIH host taking FTP sever. > I'm not sure whether following scenarios are correct > > There are two possibilities > > Option 1: > > +---------------+ > |BIH(FTP sever) |----------NAT64-------FTP Client > +---------------+ > > > Option 2: > > +---------------+ > |BIH(FTP sever) |--------------FTP Client > +---------------+ > > In the case of Option 1, it can't work since NAT64 couldn't support > IPv4 initiated session I agree it would fail with a passive-mode transfer. But it should work with an active-mode transfer. > In the case of Option 2, it could work if BIH do ALG Yep. > > > BTW, if BIH takes the role of FTP client, I guess it works in both > active and passive mode when NAT64 do ALG > > If there is something wrong, please correct me -d > Many thanks > > Gang > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Thu Sep 29 09:52:36 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F5621F8C4D; Thu, 29 Sep 2011 09:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.824 X-Spam-Level: X-Spam-Status: No, score=-102.824 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Y8Pa6LM673S; Thu, 29 Sep 2011 09:52:36 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1610721F8C28; Thu, 29 Sep 2011 09:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1148; q=dns/txt; s=iport; t=1317315328; x=1318524928; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=dKZgUbMI5WEfRMZJpQCBVLXYiSo41YG3BvakVo87jN4=; b=LE8s6zr4dqc4ukvxS42XHbj5WiCdPD7YTXBqZACnOYZLmw0e7buJPvLP 6k63MiWfrnLSZlXskM1rDOhswZeFrbgH+MKYjGoonVptV+qZwbC1j1DBK e75Kgo9VxSwA9j1NeJytlzv2WeA4FfOZKZu+dxezQRhECVV6OcpV6nguy w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANGhhE6rRDoG/2dsb2JhbABBmnyNE3eBUwEBAQECAQgKARdPBQgDAgkPAzQZIw0OAQEEHheHWJpWAZ47hxMEh0IwnT4 X-IronPort-AV: E=Sophos;i="4.68,462,1312156800"; d="scan'208";a="5030047" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 29 Sep 2011 16:55:27 +0000 Received: from dwingWS ([10.89.10.59]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8TGtQvK022691; Thu, 29 Sep 2011 16:55:26 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Despr=E9s'?=" References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> <916CE6CF87173740BC8A2CE44309696203771FAB@008-AM1MPN1-037.mgdnok.nokia.com> <09bd01cc7d16$cd715190$6853f4b0$@com> <18748250-5D4E-4470-93E6-FFA3FDB87E36@free.fr> <060b01cc7ebf$9500c250$bf0246f0$@com> <2A6C6CAF-1A2F-49C8-9C11-E9DAB7F72879@free.fr> <065801cc7ec4$c745ec40$55d1c4c0$@com> In-Reply-To: Date: Thu, 29 Sep 2011 09:55:26 -0700 Message-ID: <067f01cc7ec8$96b5d640$c42182c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acx+xgWhT7009IunTVKtBs5IFVNGYAAAh0iA Content-Language: en-us Cc: 'Softwires-wg' , 'Behave WG' , 'IETF discussion list' Subject: Re: [BEHAVE] [Softwires] ... Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 16:52:36 -0000 > If a host has several interfaces, each interface must have its own > private IPv4 address (case b) at this interface), or its own IPv4 > address, possibly with a restricted port set (case a)). > > The host must handle ports according to what applies to its chosen > interface. Agreed. But it's not "the host", rather it is the application running on the host that needs to have that awareness. Said another way, it cannot mindlessly bind to port 0, like applications do today -- but has to bind to a free port on a specific interface. > This isn't AFAIK specific of 4rd scenarios. It is a problem common to all of the port-restricted scenarios if we move the port restriction into the host (A+P, 4rd, dIVI). Either the application is aware of the port restriction (which is how you avoid an ALG in the host) and require the application to change, or the application is unaware of the port restriction (which means an ALG is necessary, for some applications, in the host) but the application doesn't have to change. So -- which way is the architecture going to go? I have not seen this written down anywhere. -d From cb.list6@gmail.com Thu Sep 29 09:53:09 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE24921F8EB9; Thu, 29 Sep 2011 09:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.452 X-Spam-Level: X-Spam-Status: No, score=-3.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZM1zaO6KlY0; Thu, 29 Sep 2011 09:53:08 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id AFE8621F8EBA; Thu, 29 Sep 2011 09:53:08 -0700 (PDT) Received: by pzk37 with SMTP id 37so2095082pzk.9 for ; Thu, 29 Sep 2011 09:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GkIb6KcYpirRyGTcFo1tJjPzka7dj49jFt34A1XOHo4=; b=NyRnckalQSO/TzZs87R+ocXz51BRpo0WCc/ltyMVPdRHE8ats0G0fyOl1VHwVh8R7/ 8bnm2+CAkykoU4SbDN10or+GbvsSCCHWexAhQ9eZdJq7ec22F4YK5Wsj9sGTOJSpBjSt dCSJUtLmD/gM0DaODnxxU5nC5N3xdcylXQRXs= MIME-Version: 1.0 Received: by 10.68.27.102 with SMTP id s6mr52115221pbg.43.1317315360108; Thu, 29 Sep 2011 09:56:00 -0700 (PDT) Received: by 10.143.2.8 with HTTP; Thu, 29 Sep 2011 09:56:00 -0700 (PDT) In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C060640A3@XMB-RCD-111.cisco.com> References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> <09b701cc7d16$6943df30$3bcb9d90$@com> <013d01cc7df7$7af51d20$70df5760$@com> <989D4A28-9E89-45EB-A256-5B55D32E150F@townsley.net> <067E6CE33034954AAC05C9EC85E2577C06063D5C@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C060640A3@XMB-RCD-111.cisco.com> Date: Thu, 29 Sep 2011 09:56:00 -0700 Message-ID: From: Cameron Byrne To: "Rajiv Asati (rajiva)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hui Deng , Behave WG , IETF Discussion , Mark Townsley , "Dan Wing \(dwing\)" , Softwires-wg list Subject: Re: [BEHAVE] [Softwires] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 16:53:09 -0000 On Thu, Sep 29, 2011 at 9:46 AM, Rajiv Asati (rajiva) wr= ote: > Hi Cameron, > >> If the application itself delivers an IPv4 literal via protocols like >> MSN or Skype, there is a path and socket made available, that is what >> this NAT46 code does. > > Is there a dependency on the existence of IPv4 literal so as to use the v= 4-interface provided by NAT46 code? IOW, does every IP-only app work now on= n900? > > Cheers, > Rajiv No, not "all" apps will work due to ALG dependencies associated with NAT in general. If the app does not work via NAT, it still will not work. What this code provides is the ability for IPv4-only apps on IPv6-only networks to work using their normal NAT traversal techniques + IPv4 literals .. this includes, Skype, MSN, and the ability to type http://x.x.x.x into your browser. There is no panacea, except making the apps and services IPv6 native on IPv6 native networks, everything else is a hack and time to market is important ipv4 exhausted. Cameron > >> -----Original Message----- >> From: Cameron Byrne [mailto:cb.list6@gmail.com] >> Sent: Wednesday, September 28, 2011 3:14 PM >> To: Rajiv Asati (rajiva) >> Cc: Mark Townsley; Hui Deng; Softwires-wg list; Behave WG; IETF Discussi= on; >> Dan Wing (dwing) >> Subject: Re: [BEHAVE] [Softwires] Last Call: > 06.txt> (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed St= andard >> >> On Wed, Sep 28, 2011 at 11:20 AM, Rajiv Asati (rajiva) >> wrote: >> > Hi Cameron, >> > >> > Very interesting (& clever indeed). >> > >> > >> > How does this clever code ensure that all but a few (pesky apps) >> > continue to use IPv6 interface instead of the NAT46 interface? >> >> Rajiv, >> >> DNS64 is used. =A0So anything that can take =A0a AAAA will use a AAAA an= d >> the native IPv6 path, with or without NAT64 -- as needed. >> >> If the application itself delivers an IPv4 literal via protocols like >> MSN or Skype, there is a path and socket made available, that is what >> this NAT46 code does. >> >> As i mentioned before, i don't like this. =A0But, i respect that it >> works and it solves a real problem for users of these ipv4-only apps. >> I personally find it easy to live with only IP version agnostic apps >> that work well in an IPv6-only NAT64/DNS64 network. =A0I have been >> eating this "dog food" for over 18 months. =A0I am happy to let the >> market and eco-system punish apps for not supporting IPv6, and for the >> market to reward apps that do support IPv6. >> >> I believe draft-ietf-behave-v4v6-bih-06 has too narrow of a scope to >> be useful since it explicitly does NOT support IPv4-only apps talking >> to IPv4 =A0servers over an IPv6-only network >> >> Cameron >> >> > Cheers, >> > Rajiv >> > >> > >> >> -----Original Message----- >> >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> > Behalf Of >> >> Cameron Byrne >> >> Sent: Wednesday, September 28, 2011 2:12 PM >> >> To: Mark Townsley >> >> Cc: Hui Deng; Softwires-wg list; Behave WG; IETF Discussion; Dan Wing >> > (dwing) >> >> Subject: Re: [BEHAVE] [Softwires] Last Call: >> > > >> 06.txt> (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed >> > Standard >> >> >> >> On Wed, Sep 28, 2011 at 9:26 AM, Mark Townsley >> > wrote: >> >> > >> >> > >> >> >>> +1 ... since the alternative is that apps that require ipv4 >> > sockets and >> >> >>> pass ipv4 literals are stranded on ipv6 only networks. >> >> >>> >> >> >>> Running code on the n900 shows that nat464 provides real user and >> >> >>> network benefit >> >> > >> >> > Frankly, I preferred it when you were running IPv6-only without BIH >> > on your >> >> trial, providing pressure to get rid of all those stranded literals >> > and >> >> pushing apps to open ipv6 sockets :-/ >> >> > >> >> > - Mark >> >> >> >> We're still doing that, and IPv6-only is still my philosophical >> >> preference and that is how we are launching the IPv6 + NAT64/DNS64 >> >> service into the production mobile network (real soon now). =A0No cha= nge >> >> in that path. >> >> >> >> But some "power users" wanted their IPv4-only applications like Skype >> >> to work so they coded a NAT46 work-around for the N900. =A0It is clev= er, >> >> it works. >> >> >> >> Their process of feeling the pain of a very few pesky IPv4-only apps >> >> and working around it is all documented here: >> >> http://talk.maemo.org/showthread.php?t=3D60320 >> >> >> >> Running NAT46 code here: http://code.google.com/p/n900ipv6/wiki/Nat64= D >> >> >> >> In the end (as well as IPv6-only near term in mobile), IP version >> >> agnostic apps will prove to be more reliable and therefore will get >> >> more market share. >> >> >> >> Cameron >> >> _______________________________________________ >> >> Behave mailing list >> >> Behave@ietf.org >> >> https://www.ietf.org/mailman/listinfo/behave >> > > From denghui02@gmail.com Thu Sep 29 22:09:18 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD1921F8C55; Thu, 29 Sep 2011 22:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.509 X-Spam-Level: X-Spam-Status: No, score=-103.509 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClvkcDuhwco3; Thu, 29 Sep 2011 22:09:18 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 952C421F8C53; Thu, 29 Sep 2011 22:09:17 -0700 (PDT) Received: by wyh21 with SMTP id 21so776093wyh.31 for ; Thu, 29 Sep 2011 22:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1D1hXVjUqySqg20su9lIZk1SqMZPmuKLGDQFVmyLdy4=; b=PQ9h+/Fno0myjyQv0xmxDEfCBY8yvjBexYqrteUTfFs/ceSpoG0nUWpuAN1aEuQQGx 9ESecGSzVVS0am0AqMHOIphY9LJhNXpIWn0xytfMaESMtp52HRCkjmgal2I+f1ELG5zp 9E5cl2sLm01XhiYK9Os9DMKOn+2NER5XP71cQ= MIME-Version: 1.0 Received: by 10.216.221.132 with SMTP id r4mr8573870wep.64.1317359528715; Thu, 29 Sep 2011 22:12:08 -0700 (PDT) Received: by 10.216.172.19 with HTTP; Thu, 29 Sep 2011 22:12:08 -0700 (PDT) In-Reply-To: <013201cc7df6$18e96ec0$4abc4c40$@com> References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> <916CE6CF87173740BC8A2CE44309696203771FAB@008-AM1MPN1-037.mgdnok.nokia.com> <09bd01cc7d16$cd715190$6853f4b0$@com> <013201cc7df6$18e96ec0$4abc4c40$@com> Date: Fri, 30 Sep 2011 13:12:08 +0800 Message-ID: From: Hui Deng To: Dan Wing Content-Type: multipart/alternative; boundary=0016e64c1bbac0275704ae21aa95 Cc: softwires@ietf.org, behave@ietf.org, satoru.matsushima@gmail.com, ietf@ietf.org Subject: Re: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 05:09:18 -0000 --0016e64c1bbac0275704ae21aa95 Content-Type: text/plain; charset=ISO-8859-1 Best is no ALG. Worse is one ALG. Even worse is two ALGs. > > -d > OK, I have see that there is two solutions for just one ALG. -Hui --0016e64c1bbac0275704ae21aa95 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Best is no ALG. =A0Worse is one = ALG. =A0Even worse is two ALGs.

-d
OK, I have see that there is two solutions for just one ALG.
=A0
-Hui
--0016e64c1bbac0275704ae21aa95-- From denghui02@gmail.com Thu Sep 29 22:14:04 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11D421F8C60; Thu, 29 Sep 2011 22:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.512 X-Spam-Level: X-Spam-Status: No, score=-103.512 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIzjKRmZqq6R; Thu, 29 Sep 2011 22:14:04 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5D221F8B6B; Thu, 29 Sep 2011 22:14:03 -0700 (PDT) Received: by wwf22 with SMTP id 22so1511900wwf.13 for ; Thu, 29 Sep 2011 22:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n9PdKfGFaYEOKOLvecGSqNdcEmOeKveM8GeKFYmS1js=; b=csAiL9M8reAKr52JCd5JQYhr4+/s3iuV0N5C8WqIU1bbBKh1069/sIw0DIJhPQJeEv 6BXsJTd6Ii3Oci6g5gk9ll7g13oRDJOAYWbPr2GlMCV2BqI8QmEdbh0pkxURFzySxlhy LtUOlwH5MlsYXXZ9sd2bCENJHRgTWagDiKiY8= MIME-Version: 1.0 Received: by 10.216.6.211 with SMTP id 61mr12411059wen.94.1317359814064; Thu, 29 Sep 2011 22:16:54 -0700 (PDT) Received: by 10.216.172.19 with HTTP; Thu, 29 Sep 2011 22:16:53 -0700 (PDT) In-Reply-To: <013d01cc7df7$7af51d20$70df5760$@com> References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> <09b701cc7d16$6943df30$3bcb9d90$@com> <013d01cc7df7$7af51d20$70df5760$@com> Date: Fri, 30 Sep 2011 13:16:53 +0800 Message-ID: From: Hui Deng To: Dan Wing Content-Type: multipart/alternative; boundary=0016364c7765c23ae104ae21bb65 Cc: softwires@ietf.org, Cameron Byrne , behave@ietf.org, ietf@ietf.org Subject: Re: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 05:14:04 -0000 --0016364c7765c23ae104ae21bb65 Content-Type: text/plain; charset=ISO-8859-1 inline please, > +1 ... since the alternative is that apps that require ipv4 sockets and > pass ipv4 literals are stranded on ipv6 only networks. > > Running code on the n900 shows that nat464 provides real user and > network benefit Can you run an FTP server on the BIH host, and have it do active mode > transfers and passive mode transfers? I admit that isn't terribly > important (nobody much loves FTP any more), but if the BIH host > doesn't know its public mapping and can't create one, we lose that > class of applications that listen on a port. Losing that class > of applications may, or may not, be important. Many of those > applications do STUN or STUN-/ICE-like things for their own NAT > traversal (e.g., Skype). But some don't and work properly > without a hole punched (e.g., BitTorrent). > > PCP can make all of this work, if it's integrated into BIH and > the NAT64. > > -d > You are jumping into another discussion how to reach from outside, There has other way to do it ,not just BIH+NAT64. Hui --0016364c7765c23ae104ae21bb65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
inline please,
=A0
> +1 ... since the alternative is that apps that require ipv4 socke= ts and
> pass ipv4 literals are stranded on ipv6 only networks.
&g= t;
> Running code on the n900 shows that nat464 provides real user an= d
> network benefit

Can you run an FTP server on the= BIH host, and have it do active mode
transfers and passive mode transfe= rs? =A0I admit that isn't terribly
important (nobody much loves FTP any more), but if the BIH host
doesn= 9;t know its public mapping and can't create one, we lose that
class= of applications that listen on a port. =A0Losing that class
of applicat= ions may, or may not, be important. =A0Many of those
applications do STUN or STUN-/ICE-like things for their own NAT
traversa= l (e.g., Skype). =A0But some don't and work properly
without a hole = punched (e.g., BitTorrent).

PCP can make all of this work, if it'= ;s integrated into BIH and
the NAT64.

-d
=A0
You are jumping into another discussion how to reach from outside,
There has other way to do it ,not just BIH+NAT64.
=A0
Hui
=A0
--0016364c7765c23ae104ae21bb65-- From phdgang@gmail.com Fri Sep 30 02:50:05 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F38F21F8B1F; Fri, 30 Sep 2011 02:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VA-lz5LXB2Wz; Fri, 30 Sep 2011 02:50:04 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D153521F8B24; Fri, 30 Sep 2011 02:50:03 -0700 (PDT) Received: by wyh21 with SMTP id 21so1027053wyh.31 for ; Fri, 30 Sep 2011 02:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WUX3+xFcQjfdW5Se1rqNLpbKwenjPaTDUTAca812Ers=; b=nrvGw9uasUQeqRBUcY7ndmSTLPGl6sQia9TWJ0qs+K7T/T+NGbIGifgverWRb53kRK 1q32gATmC8FWFipG5SoiAA4nJelRqK6E0FM8uDAKH+Ono1cve15i9vazw8zNfiG04tTT 2dYEX7eVjqP5ezN4LrHGbZTsg0sSvbiefBcAc= MIME-Version: 1.0 Received: by 10.216.132.129 with SMTP id o1mr2691295wei.3.1317376376710; Fri, 30 Sep 2011 02:52:56 -0700 (PDT) Received: by 10.180.84.161 with HTTP; Fri, 30 Sep 2011 02:52:56 -0700 (PDT) In-Reply-To: <067d01cc7ec7$e1fc9400$a5f5bc00$@com> References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> <09b701cc7d16$6943df30$3bcb9d90$@com> <013d01cc7df7$7af51d20$70df5760$@com> <067d01cc7ec7$e1fc9400$a5f5bc00$@com> Date: Fri, 30 Sep 2011 17:52:56 +0800 Message-ID: From: GangChen To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Cc: Hui Deng , softwires@ietf.org, Cameron Byrne , behave@ietf.org, ietf@ietf.org Subject: Re: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 09:50:05 -0000 >> >> Option 1: >> >> +---------------+ >> |BIH(FTP sever) |----------NAT64-------FTP Client >> +---------------+ >> >> >> Option 2: >> >> +---------------+ >> |BIH(FTP sever) |--------------FTP Client >> +---------------+ >> >> In the case of Option 1, it can't work since NAT64 couldn't support >> IPv4 initiated session > > I agree it would fail with a passive-mode transfer. But it should > work with an active-mode transfer. > In an active-mode transfer, IPv4 client needs initiate the TCP connection to a port on the FTP sever in advance. Afterwards, FTP server connects back to the client. I'm not sure how could NAT64 support the first step (i.e. IPv4 initiated TCP connection)? Many thanks Gang From dwing@cisco.com Fri Sep 30 09:02:38 2011 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D43B21F8586; Fri, 30 Sep 2011 09:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.964 X-Spam-Level: X-Spam-Status: No, score=-102.964 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84GbyRpRrGLf; Fri, 30 Sep 2011 09:02:37 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 698E821F8569; Fri, 30 Sep 2011 09:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1419; q=dns/txt; s=iport; t=1317398731; x=1318608331; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=6QpeDEjkiH0i7zVjQ1Yoy0AzzlShSL7BkuBGESFsHKg=; b=QXkAOBv6QjiSmOEw188r3/Z3FyQ4crqsLFDJIZhjGoWjpRX0NeSrGL/i 2lZBj2fE4evnYNVv2keWOpGVTd+/w+GRuxD27l7MeTuXpeQUSps/LiKvZ MazLi0MT1DptT5GaYUfsiIW6AO54Wl2BPXaX00GK2WRqkRipztlpvyLcJ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEAAM/nhU6rRDoG/2dsb2JhbABBmSGBa40mgQWBUwEBAQMBCAoBFxA/BQcBAwIJDwIEAQEkBAcZCBsKCQgBAQQKCQsXh1mYQAGeIYcgBId2lgSHPw X-IronPort-AV: E=Sophos;i="4.68,468,1312156800"; d="scan'208";a="5243596" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 30 Sep 2011 16:05:31 +0000 Received: from dwingWS ([10.89.10.59]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8UG5UMQ026253; Fri, 30 Sep 2011 16:05:30 GMT From: "Dan Wing" To: "'GangChen'" References: <916CE6CF87173740BC8A2CE4430969620377183F@008-AM1MPN1-037.mgdnok.nokia.com> <081701cc7cac$837a9610$8a6fc230$@com> <09b701cc7d16$6943df30$3bcb9d90$@com> <013d01cc7df7$7af51d20$70df5760$@com> <067d01cc7ec7$e1fc9400$a5f5bc00$@com> In-Reply-To: Date: Fri, 30 Sep 2011 09:05:29 -0700 Message-ID: <09a301cc7f8a$c71cce70$55566b50$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acx/VrxNxXhenxCMR8+rfhMJiRB4HQAM5dvA Content-Language: en-us Cc: 'Hui Deng' , softwires@ietf.org, 'Cameron Byrne' , behave@ietf.org, ietf@ietf.org Subject: Re: [BEHAVE] Last Call: (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 16:02:38 -0000 > -----Original Message----- > From: GangChen [mailto:phdgang@gmail.com] > Sent: Friday, September 30, 2011 2:53 AM > To: Dan Wing > Cc: Hui Deng; behave@ietf.org; ietf@ietf.org; softwires@ietf.org; > Cameron Byrne > Subject: Re: [BEHAVE] Last Call: > (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard > > >> > >> Option 1: > >> > >> +---------------+ > >> |BIH(FTP sever) |----------NAT64-------FTP Client > >> +---------------+ > >> > >> > >> Option 2: > >> > >> +---------------+ > >> |BIH(FTP sever) |--------------FTP Client > >> +---------------+ > >> > >> In the case of Option 1, it can't work since NAT64 couldn't support > >> IPv4 initiated session > > > > I agree it would fail with a passive-mode transfer. But it should > > work with an active-mode transfer. > > > > In an active-mode transfer, IPv4 client needs initiate the TCP > connection to a port on the FTP sever in advance. Afterwards, FTP > server connects back to the client. > I'm not sure how could NAT64 support the first step (i.e. IPv4 > initiated TCP connection)? Static mapping in the NAT64, for the FTP control channel (port 21 or an alternate port). That could be done by the user's profile (draft-cheng-behave-nat-fwd-port-radius-ext), PCP, or a web portal that manages the NAT64's configuration. -d > Many thanks > > Gang